Sql server SQL Server切换实时数据库

客户机有我公司的一个应用程序，它指向其服务器上数据库中的特定数据库和表。我们需要每天更新几次数据。我们不想更新用户在实时会话中查看的表。我们希望刷新侧面的数据，然后翻转用户正在访问的数据库/表

---

公认的做法是什么？我们是否有两个数据库并重命名这些数据库？我们是否将数据放入单独的表中，然后重命名这些表？我们还可以采取其他方法吗？

我想我理解你的意思：如果用户在屏幕上，你不想在他们查看屏幕时用新信息更新屏幕，只有在加载新数据后，当他们拉动新屏幕时才更新？如果我错了，请纠正我。Mike的问题也很好，这些数据是如何提供给用户的？可能有一种方法可以在加载新数据时暂停该操作或其他操作。有更优雅的方式来加载数据，如分区表、使用暂存表、复制、让用户查看快照等。但是我们需要知道“实时会话”是什么意思

编辑：根据您给我的额外信息，分区切换可能是答案。这个过程几乎不需要时间，它只是将指针从旧记录更改为新记录。唯一的问题是您必须在可分的对象上进行分区，例如日期或时间戳，以区分新旧数据。它也是企业版的一个特性，我不确定您运行的是哪个版本

可能更好的方法是读取提交的快照隔离。它将确保您的用户仅在提交新数据后查看这些数据；它提供了一个事务级的数据一致性视图，并具有最小的并发问题，尽管TempDB的开销更大。以下是更多研究的一些资源：

---

希望这对你有帮助，祝你好运

根据您提供的信息，我相信您最好的选择是分区切换。我为您提供了几个链接供您查看，因为它更容易引导您找到一个已经很好地解释了它的来源。对于分区切换，您可以采取几种方法

链接：及

---

希望这有帮助

问题细节有点模糊，因此需要澄清：

什么是实时会话？它是应用程序本身的会话，应用程序代码管理它自己与数据库的连接，还是每个用户/会话的低级别连接？用户是否只是在会话期间运行报告或主动从数据库读/写？会议何时结束？您如何知道

一些选择：

1将整个会话的所有数据拉入客户端

2使用其他答案中提到的读取提交或分区，但是需要仔细设置查询并增加对数据库的要求

3对所有查询使用副本数据库，必要时暂停/恢复复制更新数据应比您的过程快，但根据容量和复杂性，可能仍需要一段时间

4使用副本数据库并从主数据库自动执行备份/恢复这可能是最快的，具体取决于数据库的总体大小

---

5将多个副本数据库与复制或备份/恢复一起使用，然后切换连接字符串这允许您不断更新主数据库，然后更新副本并在某个可预测的时间进行切换

用户是否通过过程访问报告？您不必担心当您正在更新数据库2吗？这是只读数据吗？分区切换或更改为读取提交的快照隔离。分区切换需要摆弄加载过程。读取提交的快照隔离只需要使用事务，而且要简单得多。尼克提交的快照隔离听起来很有趣，因为正在更新的数据表是相当隔离的。在显示的报告中，一个表中的数据不会与另一个表中的数据混淆。如果我知道我可以一次更新一个或两个表作为一个独立的进程，那么事务更新只是那些表，这可能是足够好的，对于我想要实现的。这是一个坚实的基础，一个同时读取和写入相同数据的系统，但它们不应该互相干扰。数据会以离散块的形式返回。用户不会查看数据不断更新的表单。他们需要一组数据，然后检索并呈现。几分钟后，他们要求提供另一组数据。数据来自原始表，没有存储过程等。但用户可以在数据更新期间使用该程序。现在，我们正在根据用户的请求更新表

---

对数据进行加密。数据请求可能会在不稳定的时刻命中数据库，而不会返回数据。我正试图避免这种情况。我知道即使使用分区，用户也可能在切换过程中请求数据。但与目前的更新过程相比，这种情况发生的可能性要小一些，因为更新过程可能需要20到30分钟。更新过程一次处理一个20人的表。所以希望只有那个表的数据看起来很奇怪。但我仍然在寻找更干净的东西。SQL Server中的正常记录锁定可以停止任何“不稳定时刻”。记录是否完整。当您在代码中撒上NOLOCK fairy灰尘时，就会出现问题。然后你会让自己面对错误。不过，正常的记录锁定会引入“争用”。那么，您是否存在争用死锁、性能问题，或者是否存在一致性损坏数据的问题，这些问题只能通过NOLOCK引入