1

在数据库恢复之前，需要关闭我正在处理的系统。如果客户不这样做，他可能会遇到严重的问题，因为应用服务器的内存状态与数据库不匹配。损坏的数据库导致错误并且系统停止工作并且数据库无法使用可能需要一些时间。

所以我尝试检测这种情况并避免问题。

  • 应用程序服务器不一定保持连接活动，因此单用户模式和类似的东西很可能不会有帮助。
  • 我不在乎还原是否会失败或服务器是否会关闭或其他任何事情。它只是不应该忽视它。
  • 数据库可以通过任何机器上的任何 sql server 工具恢复。我不能依赖我自己的工具。

有人已经解决了这样的问题吗？

我正在使用 SQL Server 2005 及更高版本、.NET (C#)、SMO。

编辑：

由于对应用程序设计的一些误解和讨论，我需要解释一下问题出在哪里。

Hi-Lo 生成器：该应用程序使用 NHibernate，它具有Hi-Lo id 生成器的 Hi-Values 缓存。Hi-Values 从数据库中读取并允许应用程序生成特定数量的主键，直到它需要返回数据库并获取另一个数字范围。存储在数据库中的 Hi-Values 只会增加，而不会减少（除非恢复旧版本的数据库）。这是 Hi-Lo 发生器的概念，不是我自己发明的，也不是我自己实现的。

缓存：在缓存中，主键用于标识数据库中的记录。在正常使用数据库时，主键永远不会改变。在还原的情况下，主键不再标识相同的记录，并且缓存完全错误。它甚至无法检测到这一点。例如，它可能会导致在新记录中设置错误的外键。

无法将数据库还原与数据库的任何其他正常使用进行比较。还原破坏了所有数据处理规则。

我想许多应用程序在运行时保持连接打开，因此无法恢复。大多数其他应用程序可能会在数据库恢复时崩溃，然后它会尝试访问数据库。就我而言，它可能会继续运行一段时间，这是一个问题。

我猜大多数人甚至不会在应用程序运行时尝试恢复数据库。

理论上，在我的案例中证明，当应用程序仍在内存中时恢复数据库时出现完全错误的风险。我不想被告知这根本不是问题，只是因为大多数应用程序不处理它。

4

3 回答 3

0

当 SQL Server 中的数据库有任何连接时，您无法对其进行完全还原。

SQL Server 永远不会允许自己破坏 SQL Server 的内存状态。而且您必须非常努力地工作才能将其欺骗成这样。

于 2012-04-18T14:35:07.453 回答
0

不知道您是如何连接到数据库的，您可以在连接逻辑中构建一个在单独的状态或系统数据库中运行的检查，以验证数据库的状态。

也许围绕连接进行尝试/捕获，并在失败时检查状态并将其报告给此时的用户；不确定您恢复的频率，因此确定代码中的最佳位置需要一些思考。

SELECT DATABASEPROPERTYEX ('DatabaseName', 'Status')

http://msdn.microsoft.com/en-us/library/ms186823.aspx

于 2012-04-18T13:26:52.540 回答
0

我没有得到有用的答案，所以我认为这个问题没有通用的解决方案。

我只看到两种解决方法：

  • 在每个事务开始时执行查询以查看数据库是否是另一个数据库。例如，上次按此处所述恢复的时间。这可能会损害性能，也可能是权限问题
  • 我打开了一个与数据库的“保持活动”连接，以避免数据库被恢复。这可能更容易实现。这不是很好，因为它浪费了连接。
于 2012-07-18T05:38:25.410 回答