小编Hea*_*ore的帖子

我们有几十个主服务器和相应的镜像，大多数都运行良好，但其中1个运行异常。具体来说，sp_dbmmonitorresults对于给定的主数据库，proc 将所有列返回为 NULL，而sp_dbmmonitorresults在镜像上返回有效信息：

现在，我大致知道原因是什么；当设置主服务器和镜像服务器时，主服务器上的区域设置不正确（时间正确但使用的是 +4 区域（美国等），在设置镜像后，时间区域更正为 GMT +0我知道男孩的错误，但是c'est la vie！）

编辑：19/12/2012

今天我删除了镜像，删除了镜像上的副本并重新设置了镜像，但是这并没有解决问题！我将在这个问题上悬赏以尝试找出问题的根源。

确认一下，如果我EXEC sp_dbmmonitorresults @database_name = 'ProScript'在每台服务器上手动运行，它会为主要服务器上的大多数值返回 NULL，但在镜像上返回正常，如下所示：

在主要运行时：

缩放：点击查看全尺寸版本

对着镜子跑的时候：

缩放：点击查看全尺寸版本

如您所见，时间是当前的并且数据库是同步的，但是主数据库上的 log_generation_rate、unsent_log、send_rate 等变量都为 NULL？

两台服务器都有监控作业每分钟运行一次，exec sys.sp_dbmmonitorupdate作为作业步骤等。

查看 sys.sp_dbmmonitorupdate 的来源，它从中获取这些值sys.dm_os_performance_counters- 所以如果我在镜像上运行以下内容：

SELECT  counter_name ,
        cntr_value
FROM    sys.dm_os_performance_counters
WHERE   instance_name = 'ProScript'
        AND counter_name IN ( N'Log Send Queue KB', N'Log Bytes Sent/sec', N'Redo Queue KB', N'Redo Bytes/sec', N'Transaction Delay', N'Log Bytes Flushed/sec', N'Transactions/sec' )

我得到了很好的结果：

但是，如果我在主数据库上运行相同的 SQL，则没有行！ …

我们有十多个 SQL 服务器，其中一个托管数百个 sage 数据库，当我右键单击 SSMS 中的数据库节点时，延迟很长，然后我收到以下错误（并且还原对话框没有加载）：

我认为 SSMS 正在从 msdb 或后台加载备份历史记录并且空间不足 - 这是否意味着我的系统数据库中有过多的备份历史记录？如果是这样，维护它的最佳方法是什么？

我有清理磁盘上的 trn 和 .bak 文件的维护计划，但我认为我没有维护系统数据库中的任何日志。

我们内部拥有主 SQL Server（目前有 15 个主服务器（总共约 500 个数据库），大多数服务器具有十六进制核心处理器）。

这些被镜像到附近建筑物中的其他备份服务器（通过专用的 0ms 光纤链路）。

我们想要做的是在数英里外的异地数据中心维护我们数据的实时副本（作为更大的 DR 项目的一部分 - 即如果我们所在地区存在通信问题）。

目前我们使用 SQL Server 2008 R2 - 标准版。

显然，使用 SQL Server 2008 R2 的“标准版”将我们限制为同步镜像，因为异步是“企业版”功能。

我们已经完成了异地同步镜像的测试，但延迟使它成为不可能。

我很想升级到 SQL Server 2012 Enterprise 并实施 AlwaysOn 可用性组，但该公司不愿意花费 100,000 英镑以上来升级 SQL 许可（2012 年的每核许可 + 我们的六核处理器 = 史诗般的失败）-他们甚至不愿意花钱升级到 2008 Enterprise，所以这也是窗口之外的异步镜像。

因此，由于这些财务限制，我的手被束缚在 2008 R2 标准版上。

留给我的唯一选择是日志传送和复制（如果我遗漏了什么，请纠正我）——日志传送很粗糙——但是如果管理得当是可行的——所以我们现在把它放在次要位置。

我的问题：

1. SQL Server 2008 R2 Standard 是否具有我们进行异地复制所需的所有复制功能？
2. 在不以任何方式影响主服务器性能的情况下，将内部服务器复制到异地数据中心（20-30 毫秒延迟）是否可行（我们是否可以在“原则”服务器上设置复制分发服务器）？
3. 鉴于复制不是实例级复制解决方案 - 这是否会超过 1 个 DBA 可以处理的管理？（鉴于我已经在管理 15 台 Principle 服务器及其镜像服务器 - 诚然有很多自动化）
4. 是否可以在不影响现有镜像配置的情况下从我们的主复制 - 我的理解是最佳实践是镜像订阅服务器而不是发布服务器 - 这是正确的吗？ …

假设您有一个带有“链接服务器”的 SQL Server 到另一台服务器 - 所说的“链接服务器”设置为使用“使用登录的当前安全上下文进行”作为其身份验证模型。

当所有服务器都拥有一个哈希时，SQL Server 如何向其他服务器提供正确的密码（在处理非 W​​indows 凭据时）。

我之前已经将登录名从服务器传输到服务器，我知道哈希值单独存储在 SQL 中，并且在使用密码创建登录名时，这通常显示为十六进制值，例如：

create login test with password = '0x22A9AE652CFC38938D56A9C3872B266B192D16E4' hashed

如果 SQL 只有一个可用的散列 - 它可以使用散列登录到远程服务器吗？或者原始（未散列的）密码是否在整个连接期间都保存在用户的会话/内存中，然后 SQL 可以检索并传递到远程服务器进行登录？

如果服务器可以使用哈希而不是密码登录 - 这可以在正常登录中完成还是纯粹是链接服务器的内部功能？

纯粹是一个好奇的问题——喜欢了解这些东西是如何运作的。

我负责管理多个 SQL Server 实例，其中大多数使用 SQL Server 镜像来复制数据以用于 DR 目的。

我会自动为镜像编写登录、角色和作业的脚本，在发生故障转移时，我们实际上需要运行一个脚本来使镜像联机、应用登录、应用滚动和作业，然后它们就会消失（给予或采取一些不匹配的 SID 和通常的小问题）。

现在，我已经记录了这个故障转移过程，以防万一发生故障时我不在现场；然而，管理层认为这个过程过于复杂，并一直试图推动诸如DoubleTake等可以进行实例级复制的3rd方复制产品。

（公司不想在实例级别使用集群，因为共享存储将成为单点故障——他们不愿意购买多个复制 SAN。）

我们拥有从几兆到 200GB+ 的数据库。

以这种方式，DoubleTake 对于 DR 真的实用吗？我可以相信数据会在主要和次要之间保持最新吗？（正是出于这个原因，我们运行高安全模式镜像。）

我在论坛上读过很多意见，但总是有偏见或未经证实；我对这些产品有一些第一手的经验。

SQL Server 2008 R2

我们有一个名为“JoeBlogs”的登录和用户，这个用户有它自己的默认schemaJoeBlogs——它Public只能访问数据库。

然后我们SELECT在一个dbo视图上授予它-dbo但是该视图从属于非 dbo模式的基础表中选择数据- 所以我们从视图中选择数据时出现错误，说明对基础表的访问被拒绝。

如何将用户配置为对dbo视图有选择访问权限，但对底层非 dbo表没有访问权限？