日志文件磁盘错误后恢复实例

Question

这主要是理论上的，但如果将来发生这种情况，我希望有一个记录的选项列表。

今天，我们在 SAN 上遇到了一个严重的磁盘错误，这意味着保存我们一个生产实例的事务日志文件的磁盘崩溃了，最初看起来它已经死了。显然，实例、数据库以及在其上运行的应用程序都会下降。

我们的数据中心人员正忙着研究磁盘故障的原因、原因和方式，同时我很快就想出了一个数据库恢复选项列表。

好的，所以数据中心的人恢复了磁盘。这是 VPLEX 错误，而不是物理硬件故障。

但同时我发现我没有很多选择。考虑到 Sys 和 User 数据库的所有日志文件都无法访问，该实例将无法启动。如果 Sys 数据库日志文件位于“已启动”的单独磁盘上，实例是否会重新启动

我可以访问 .mdf 文件，所以我可以选择将它们复制到另一台服务器，然后将它们与另一个卷上的新日志文件附加在一起。要么使用我们相当有弹性的备份将数据库还原到另一台服务器\实例。任何一种选择都意味着适用于应用程序人员，因为所有应用程序和相关服务都需要重新指向。

我还有另一种选择，即删除服务器上的实例并使用相同的实例名称重新安装它，然后从完整的广告日志备份中恢复所有数据库。从理论上讲，这意味着 App 团队没有工作，但对我（唯一的 DBA）来说却有严重的时间开销。

我在这里缺少任何选项吗？我最近才开始这项工作，可以说这里的文档有限。在过去的几个月里，我一直忙于整理 SQL Estate 的清单，查看修补/​​升级差距等，并参与了多个项目。我认为可以公平地说，针对此类场景的记录在案的灾难恢复计划现在是我们层次结构议程的首要任务。

任何帮助表示赞赏。

Answer 1

灾难恢复计划取决于

1.可接受的停机时间
2.可接受的数据丢失

您设计的任何灾难恢复计划都将仅围绕上述两点

这两种选择都意味着应用程序人员的工作，因为所有应用程序和相关服务都需要重新指向

从理论上讲，这意味着应用程序团队不需要做任何工作，但对我（唯一的 DBA）来说却需要大量的时间开销。

您的灾难恢复选项并不取决于所涉及的工作量以及谁承担其中的份额。

您必须与业务人员坐在一起，明确他们可以承受的停机时间和数据丢失是多少。在此基础上，您必须制定计划（使用高可用性选项）并不时进行测试（模拟演练）。