我正在尝试检索特定数据库对象的缓存执行计划,但由于缓存计划属于处于 MIRROR 状态的镜像数据库,因此失败。
下面的查询,没有任何额外的 WHERE 子句失败,并出现以下 SQL 错误:
消息 954,级别 14,状态 1,第 1 行 无法打开数据库“DatabaseName”。它充当镜像数据库。
SELECT *
FROM sys.dm_exec_query_stats AS deqs
CROSS APPLY sys.dm_exec_query_plan(deqs.plan_handle) AS deqp
Run Code Online (Sandbox Code Playgroud)
我怀疑 sys.dm_exec_query_plan 函数首先尝试解析缓存中的所有计划句柄,但在镜像数据库的缓存对象上失败。
有谁知道是否有任何方法可以解决这个问题,T-SQL 明智的?
当然,我可以执行 DBCC FREEPROCCACHE 来清除缓存,但是我希望有其他解决方案。我有点惊讶这个函数在尝试解析计划时没有丢弃镜像数据库中的任何对象。
我在同一个子网的工作组中新安装了 Win 2008 R2 机器,当然还有 SQL Server 2012。
我允许使用 SQL Server 身份验证登录,认为这可能有助于每个工作站拥有不同的用户帐户数据库。我为三台机器中的每台都创建了相同的登录名。两个拥有完整的 SQL Server 软件,一个拥有 SQL Server Express。然后我尝试镜像两个不同的数据库,产生相同的结果。
首先,我在 SQL Server Management Studio 中右键单击数据库,创建一个新数据库,然后确认恢复模式设置为完整。备份它和事务日志。将这两个项目恢复到我的另一台服务器。(首先,我还没有使用 Witness,希望让它尽可能简单)在恢复数据和日志时,我正在恢复它而没有恢复。然后当我尝试镜像时,我收到一条关于完全限定域名的警告,点击它,因为我的服务器不在域中,然后当它尝试镜像并返回时:
开始镜像时出错。
附加信息:
数据库“test”的更改失败。(Microsoft.SqlServer.Smo)
执行 Transact-SQL 语句或批处理时发生异常。(Microsoft.SqlServer.ConnectionInfo)
服务器网络地址“TCP://(SERVERNAME):5022”无法访问或不存在。检查网络地址名称以及本地和远程端点的端口是否可操作。(Microsoft SQL Server,错误L 1418)
我也用 AdventureWorks 数据库尝试过,结果相同。
在事件查看器中,我看到“数据库镜像连接错误 4。'接收数据时发生错误。' '10054(现有连接被远程主机强行关闭。)'。对于“TCP://(镜像服务器名称):5022”。
在我看到的 SQL Server 日志中
错误 1443。严重性 16。状态 2
数据库“test”的数据库镜像已终止。这仅供参考。无需用户操作。
和
错误 1474。严重性 16。状态 1。
数据库镜像连接错误 4。“接收数据时出错。” '10054(现有连接被远程主机强行关闭。)'。对于“TCP://(镜像服务器名称):5022”。
我一直在谷歌上搜索试图解决这个问题,但我认为因为我对这一切都不熟悉,所以我很难理解从哪里开始。
我即将设置Ola Hallengrens数据库维护计划。我们有我们的数据库镜像,我只是想知道我是否需要在我的两个 Sql Server 实例上运行脚本还是只在主实例上运行脚本?
sql-server-2008 sql-server maintenance mirroring ola-hallengren
假设两个 SQL Server 实例(S1 和 S2)处于同步镜像或同步可用性组中。现在发生以下情况:
现在 S2 更进一步了!它有一个 S1 没有的写操作。两个复制品已经分道扬镳。
在这种情况下会发生什么?当更多写入到达 S1 并将 S1 带入与 S2 不兼容的历史时会发生什么?写历史看起来像一个叉子。
我知道 SQL Server 2012 和 2014 提供了提供此功能的AlwaysOn 可用性组,但我仍然停留在 SQL Server 2008 R2 上一段时间。
我最近看到了这个 AWS 白皮书:http : //media.amazonwebservices.com/AWS_RDBMS_MS_SQLServer.pdf
我对第 11 页的这张图表感到困惑:
这似乎表明镜像数据库可以用于读取(检查“可读副本”功能列),就像使用日志传送时一样,因为根据我的经验,镜像数据库根本无法使用--它的唯一目的是用于故障转移。
这个问题的答案:数据库镜像仅限于原始数据库似乎证实了我的怀疑,即镜像数据库不可读,尽管只是顺便说一句。
这份白皮书是错误的,还是 SQL Server 2008 R2 镜像数据库确实可读?
如果是,需要做什么,因为尝试在 SSMS 中连接会导致一个窗口连接到主数据库,并且运行USE [database]会出现以下错误:
Msg 954, Level 14, State 1, Line 1
The database "database" cannot be opened. It is acting as a mirror database.
Run Code Online (Sandbox Code Playgroud)
更新:我知道有一些方法可以解决这个问题,并从镜像和延时中获取一些可读的东西,我想有人可以争论快照是“可读副本”,但那是与您通过日志传送或事务复制获得的可读副本类型非常不同,因为这两者都会自动更新,即使稍微过时(也许快照也可能是 - 我坚持标准Edition,所以我对Enterprise Edition功能集不太熟悉)。除此之外,一个真正可读的同步镜像(比如使用AlwaysOn Availability Groups在 2012+ 中)将提供一个完美同步的可读版本——这更有用,因为镜像可用于分配读取查询负载并避免返回过时数据的所有问题。我的主要目的(如上面的问题所述)实际上是获得关于镜像本身可读性的明确答案(不是快照或它的副本)。虽然提供的答案与我自己的经验一致,但所提供的确定来源的唯一链接是实现类似结果的可能方法——它们都没有明确说明镜像不可读。我将接受提供此类链接的第一个答案。
所以我知道当修补两个主要的数据库服务器(记录为 SQL Server)时,你会做镜像、故障转移,然后当一切都赶上时做新的镜像,但是见证盒呢?只是打补丁然后重新启动它并且(理论上)它会再次恢复是否安全?
设置
服务水平协议
我要满足的 SLA 条款在这一点上没有严格的限制(我知道很奇怪!):
网络瓶颈
看起来最大的瓶颈之一是大约 300mb 的网络管道,它似乎因需要同步镜像到另一个 EC2 实例而过载。我可以在同一个实例上维护更多的数据库,如果我删除镜像,可能会降低成本。
镜像或替代方法以获得具有合理可用性的性能
我正在寻找最佳价值,同时仍能提供合理的正常运行时间。由于我使用的是 SQL 标准,这意味着异步镜像不是一个选项(我们正在运行 sql 2014)。
当我评估了选项时,我很欣赏有关基本灾难恢复的另一种观点。镜像的开销似乎是一个很大的瓶颈,但如果我删除它,那么我会担心如何提供更好的可用性。理想情况下,我会异步运行镜像,但我们需要在 sql server 版本中向后移动,并且不确定这是否是最好的方法
始终在高可用性组上
由于此时复杂性和许可成本增加,因此不继续进行此操作。对未来的探索持开放态度,但目前希望避免企业许可成本。
sql-server mirroring disaster-recovery amazon-ec2 sql-server-2014
嗨,我正在尝试备份事务日志文件以在 SQL Server 中设置镜像
我执行
BACKUP LOG CUSTOMER TO DISK ='K:\JonDB\CUSTOMER.trn' WITH INIT
GO
Run Code Online (Sandbox Code Playgroud)
我收到
Processed 6587361 pages for database 'CUSTOMER', file 'CUSTOMER' on file 1.
Processed 0 pages for database 'CUSTOMER', file 'CUSTOMER_log' on file 1.
Processed 6 pages for database 'CUSTOMER', file 'CUSTOMER_log2' on file 1.
BACKUP DATABASE successfully processed 6587368 pages in 969.013 seconds (46.948 MB/sec).
Msg 3049, Level 16, State 1, Line 5
BACKUP detected corruption in the database log. Check the errorlog for more information. …Run Code Online (Sandbox Code Playgroud) 我们在镜像中配置了两台 SQL 2012 数据库服务器,并带有用于自动故障转移的见证。
昨天主服务器遭遇硬盘降级,触发了故障转移,但是当辅助服务器成为原则时,我们开始看到一些 SPROC 执行时出现许多错误。
对象 '[sp_name]' 的定义自编译后已更改
我知道这可以通过运行sp_recompile新原则来解决,这将强制对所有 SPROC、函数和触发器进行重新编译。
这并不理想,因为它需要对故障转移进行手动干预。这是我可以通过修改配置解决的问题,还是已知的 SQL Server 错误?
当镜像伙伴关闭时,在故障转移后收到下面提到的错误。
错误 :
故障转移到未配置为数据库镜像的数据库。代码:22037,文本:'无效的连接字符串属性无法打开登录请求的数据库“DBName”。登录失败。用户“域\用户”登录失败。连接尝试故障转移到未配置数据库镜像的数据库。
设想 :
执行上述步骤后,复制开始抛出错误。当镜像打开时,复制正在工作,否则会引发提到的错误。
你能建议我解决它的步骤吗?