我正在寻找有关在 Windows Server 2012 R2 上构建 SQL Server 2016 SP1 Always On Availability Groups HADR 解决方案的一些指导。我们有一个带有主副本和辅助副本的主站点 A 和一个带有辅助副本和文件共享见证的灾难恢复 (DR) 站点 B。我们的目标是，如果站点 A 的主副本服务器 1 发生故障，则 Always On Availability Group (AG) 故障转移到站点 A 的辅助副本服务器 2，如果站点 A 的两台服务器都发生故障，则 AG 故障转移到站点 B。

我们正在尝试按照https://technet.microsoft.com/en-us/library/cc731739(v=ws.11).aspx和此图表进行节点和文件共享多数配置：

此图显示，当一个节点和“磁盘”/文件共享见证通信时，集群运行，但在我们对这种情况的测试中，由于 WSFC 的仲裁丢失，集群失败。如果我们通过禁用 vmWare 中的 NIC 一次测试一台服务器的故障，则自动 AG 故障转移会起作用，因为 SQL Server 2016 支持两个自动故障转移目标副本。但是，如果我们同时使站点 A 的两台服务器发生故障以模拟点对点网络故障或站点电源故障，则不起作用。

以下手动干预强制仲裁的方法将起作用，但它不是自动的，这是我们在理想情况下想要的：

$node = "SQLServerC"
Stop-ClusterNode –Name $node
Start-ClusterNode –Name $node –FixQuorum

ALTER AVAILABILITY GROUP SQLServerAO FORCE_FAILOVER_ALLOW_DATA_LOSS;

$node = "SQLServerC"
Stop-ClusterNode –Name $node
Start-ClusterNode …

我们不小心删除了rm -rf /data/db 我们的MongoDB 路径目录，多亏了 extundelete，我们恢复了它并得到了目录/data/db。

这是我们在目录中的文件，文件是在 MongoDB 3.4 版本下生成的。

文件夹diagnostic.data：

文件夹journal：

第 1 步：尝试正常运行 mongod

a)我们运行mongod --port 27017 --dbpath /data/db --bind_ip_all和mongo，并期望应该有一个用户定义的数据库wecaXX，但是，它没有出现。

> show dbs
admin   0.000GB
config  0.000GB
local   0.000GB

在 Robo3T 中

b)然后我尝试运行mongod --port 27017 --dbpath /data/db --bind_ip_all --repair. 结果是：

2019-03-25T14:10:02.170+0800 I CONTROL  [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2019-03-25T14:10:02.191+0800 …

我需要建立许多生产服务器的异地副本，包括 SQL 服务器。

选择 Hyper V 复制作为一个简单的解决方案（所有服务器都是虚拟的）。这是对灾难场景的异地备份的补充。我们不需要即时故障转移、镜像或任何高级设置，只需要最关键数据和系统的合理最近的副本。

Hyper V 复制看起来很简单，一劳永逸（只需确保将 tempdbs 放在非复制的 VHD 上，设置标志以维护跨 VHD 的写入顺序）。但我仍然关心效率和健壮性，并认为简单的日志传送设置可能更好，更容易在带宽上（除了日志不需要复制任何东西）

欢迎任何关于什么（何时）选择一个而不是另一个的意见或见解

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

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

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

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

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

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

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

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

任何帮助表示赞赏。

假设我有一个手写脚本，它执行一系列架构更改，例如：（从空气中提取）：

• 向现有表添加 2 列
• 创建一个新的存储过程
• 改变现有的存储过程

并且，在运行这个之后，我们发现我们需要恢复到整个脚本运行之前。

这可能吗？

在此期间，数据将一直流入。我们不能丢弃新数据（即：我们无法恢复整个数据库的备份），但我们不关心来自 2 个新列的任何数据.

我正在寻找比DROP COLUMN每次进行架构更改时编写显式“撤消”脚本（例如，语句和旧过程定义）更好的解决方案。

• 我有一台旧 iMac，不久前就停止工作了
• 我每周对正在更新的数据库进行备份，其中包含来自多个 rss 提要的提要项目
• 我仍然缺少上周的数据
• 我目前拥有旧机器的硬盘，其中包含 postgres 数据目录（它是基于 Intel 的 iMac）
• 我的新机器是基于 Apple M1 的 mac mini，我想加载所有这些提要项目
• 我想从包含旧 postgres 文件的硬盘驱动器上的数据目录中的名为 ch_v3 的特定数据库恢复名为 feed_items 的特定表
• 如何将旧硬盘上以原始格式存储的 100k+ feed 项目恢复到新机器上的新 postgres 安装中？

Always On 故障转移群集与Always On 可用性组的优势是什么？

Basic Always On Failover Clustering 提供服务器级别的保护，（例如：2 个服务器具有 1 个共享磁盘空间；如果服务器出现故障，它可以利用共享磁盘空间上的另一台服务器）。

Always On Availability Groups 提供磁盘存储灾难恢复和服务器级 HA 保护。它为 2 个服务器提供 2 个共享空间。

那么，Always On Failover Clustering 相对于 Availability Groups 在功能上有什么好处呢？查看图表比较，我没有看到。似乎可用性组更好。

我们使用SQL Server 2016 Enterprise。谢谢。

审查文件：

• 故障转移群集和 Always On 可用性组
• SQL 永远在线

公司正在实施与快照异步的数据库镜像。这提供了一些具有报告功能的灾难恢复区域。服务器 A 主体包含镜像到服务器 B 的数据库，快照是在服务器 B 数据库上拍摄的。

为了启用更新的数据，我们将每 30 分钟在镜像服务器数据库上创建一次数据库快照。我们如何将所有 SSRS/报告存储过程查询重定向到最新快照？我们的报告查询非常短，一般在 10 秒左右。微软在下面提到了程序化解决方案，不确定那是什么？所以SalesDB1030、SalesDB1100、SalesDB1130、24clock加在dbname后面

报告查询可能是

select * from SalesDbSnapshot.dbo.SalesTransaction st
inner join SalesDbSnapshot.dbo.Customer cs
    on st.CustomerId = cs.CustomerId
inner join SalesDbSnapshot.dbo.Product pr
    on st.ProductId = pr.ProductId

创建数据库快照

“要使用数据库快照，客户端需要知道在哪里可以找到它。用户可以在创建或删除一个数据库快照时读取另一个数据库快照。但是，当您用新快照替换现有快照时，您需要将客户端重定向到新快照。用户可以通过 SQL Server Management Studio 手动连接到数据库快照。但是，为了支持生产环境，您应该创建一个编程解决方案，透明地将报表编写客户端定向到数据库的最新数据库快照。 ”

我有数据库：

-两个文件组（主要和索引）

-三个文件 .mdf(data), .ndf(index) 和 .ldf(log)

每个文件都在不同的磁盘上，昨天 NDF 文件所在的磁盘崩溃了，所以我丢失了该文件。有没有办法修复数据库，而无需恢复？

TNX！

我从 SERVER_A 进行日志传送，每 10 分钟备份一次。我每 20 分钟将日志恢复到 SERVER_B。当我从 SERVER_B 到 SERVER_C 进行 DWH 加载时，我暂停恢复

我从 SERVER_B 进行报告，我想知道在 SERVER_A 上进行备份的时间，以便我可以向用户展示他们看到的数据有多新鲜

我无法使用 SERVER_A 的上次日志备份时间，因为我不确定该日志是否已恢复到 SERVER_B。

我无法使用 SERVER_B 的上次恢复时间，因为我不知道 SERVER_A 上实际进行备份的时间。

对于获得数据新鲜度的好方法有什么想法吗？