小编Pet*_*ter的帖子

我最近将一个数据库恢复到它从（SQL Server 2008 R2 Enterprise）备份的同一个实例，发现我无法访问数据库属性。

我做了以下工作：

• 使用sp_helpdb.检查数据库所有者设置是否正确。
• 将数据库所有者更改为sa. 不是修复。
• 将数据库所有者改回我的sysadmin用户。不是修复。
• DBCC updateusage针对受影响的数据库发出。不是修复。
• DBCC CheckDB在恢复的副本上运行到另一个实例。没有发现腐败。访问数据库属性窗口时，恢复的副本（来自同一个备份文件）没有抛出任何错误。

任何人都可以帮忙吗？

尝试查看属性时收到的错误消息是：

无法显示请求的对话框。(SqlMgmt)
属性大小不可用于数据库“[DBNAME]”。
此对象可能不存在此属性，或者可能由于访问权限不足而无法检索。(Microsoft.SqlServer.Smo)

我是sysadmin这个实例的一个。

更新：按照建议，我创建了一个新用户，将其设为 sysadmin 并将数据库所有者更改为它。不幸的是不是修复。我将查看探查器跟踪是否会产生任何有用的信息。

更新：Aaron - 原始数据库已重命名并脱机，但仍在该实例上。然后使用原始名称恢复该数据库的备份。新数据库文件的文件名与原始文件名不同，因为它们与原始 mdf/ldf 位于同一文件夹中。恢复的数据库目前正在正常驱动我们的关键应用程序。

我的公司使用的应用程序存在严重的性能问题。我正在解决的数据库本身存在许多问题，但许多问题纯粹与应用程序有关。

在我的调查中，我发现有数百万个查询访问 SQL Server 数据库，这些查询查询空表。我们有大约 300 个空表，其中一些表每分钟查询 100-200 次。这些表格与我们的业务领域无关，本质上是原始应用程序的一部分，供应商在与我公司签订合同为我们提供软件解决方案时并未删除这些原始应用程序。

除了我们怀疑我们的应用程序错误日志充斥着与此问题相关的错误这一事实之外，供应商向我们保证，应用程序或数据库服务器不会对性能或稳定性产生影响。错误日志泛滥到我们无法看到超过 2 分钟的错误进行诊断的程度。

就 CPU 周期等而言，这些查询的实际成本显然会很低。但是有人可以建议对 SQL Server 和应用程序产生什么影响吗？我怀疑发送请求、确认请求、处理请求、返回请求和确认应用程序接收的实际机制本身会对性能产生影响。

我们为应用程序使用 SQL Server 2008 R2、Oracle Weblogic 11g。

@Frisbee- 长话短说，我创建了一个包含查询文本的表，该表命中了应用程序数据库中的空表，然后查询它以查找我知道为空的所有表名，并得到了一个很长的列表。最重要的是在 30 天的正常运行时间内执行了 270 万次，请记住，该应用程序通常在上午 8 点至下午 6 点使用，因此这些数字更集中于运行时间。多个表，多个查询，可能有些是通过连接相关的，有些则不是。最大的成功（当时是 270 万）是从一个带有 where 子句的空表中进行简单的选择，没有连接。我希望连接到空表的更大查询可能包括对链接表的更新，但我会检查并尽快更新这个问题。

更新：有 1000 个查询的执行计数在 1043 - 4622614 之间（超过 2.5 个月）。我将不得不进一步挖掘以找出缓存计划的来源。这只是为了让您了解查询的范围。大多数都相当复杂，有 20 多个连接。

@srutzky-是的，我相信有一个与计划何时编译相关的日期列，因此我会感兴趣，所以我会检查一下。我想知道当 SQL Server 位于 VMware 集群上时，线程限制是否会成为一个因素？谢天谢地，很快就会成为专用的戴尔 PE 730xD。

@Frisbee - 抱歉回复晚了。正如您所建议的，我使用 SQLQueryStress（实际上是 240,000 次迭代）在 24 个线程上从空表中运行了 10,000 次 select * 并立即达到了 10,000 批请求/秒。然后我将 24 个线程减少到 1000 次，并达到了不到 4,000 个批处理请求/秒。我还仅在 12 …

在 3 节点可用性组中，由于 Microsoft 文档中涵盖的原因，辅助副本通常会受到重做延迟的影响：

故障排除：主副本上的更改未反映在辅助副本上

根据我的经验，我最常看到的问题似乎是：

主要副本上长时间运行的事务会阻止在次要副本上读取更新。

和

辅助副本上的重做线程被长时间运行的只读查询阻止进行数据定义语言 (DDL) 更改。重做线程必须先解除阻塞，然后才能为读取工作负载提供进一步的更新。

我可以通过查看扩展事件会话“AlwayOn Health”来观察这一点：

当应用程序向辅助副本发出只读查询时，如果在主副本上运行大量记录的操作（如索引优化），同步滞后变得明显，并且我看到辅助副本上未提交的日志记录中有大量积压，如所述在上面的 MS 文档中。

我的问题是为什么我看到 CMEMTHREAD 在主副本上进行索引重组时在辅助副本上等待：

这是正常/预期的行为还是其他什么？

虽然辅助副本上有一些读取活动，但这些查询在运行时通常<1 秒，偶尔<10 秒查询。CPU 使用率在 5% 左右。

Output of @@VERSION: Microsoft SQL Server 2016 (SP1-CU10-GDR) (KB4293808) - 
13.0.4522.0 (X64)   Jul 17 2018 22:41:29   Copyright (c) Microsoft Corporation  
Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2012 R2 
Standard 6.3 <X64> (Build 9600: ) (Hypervisor) 

• 仅在辅助副本上观察到 CMEMTHREAD 等待
• 显示此等待（和滞后）的副本是主动查询的同步副本

更新：我刚刚发现在索引优化期间再次发生此 WAIT。我终止了索引作业，然后显然停止了同步延迟的增加，但是 CMEMTHREAD 等待继续并且重做似乎很慢。我还注意到偶尔 PARALLEL_REDO_FLOW_CONTROL 在重做线程上等待，所以我只是简单地执行，DBCC TRACEON (3459, -1)然后重做速度突然增加，积压开始非常快地清除。

您可以看到我在下午 …

如果我使用ntext、text或image数据类型对表进行分区并使用 重建单个分区上的索引online = off，这会锁定整个表还是仅锁定有问题的分区？

我有一个涉及全文搜索的查询，如下所示：

SELECT TOP 30 PersonId,
              PersonParentId,
              PersonName,
              PersonPostCode
FROM dbo.People
WHERE PersonDeletionDate IS NULL
      AND PersonCustomerId = 24
      AND CONTAINS(ContactFullText, '"mr" AND "ch*"')
      AND PersonGroupId IN(197, 206, 186, 198)
ORDER BY PersonParentId,
         PersonName;

这会生成两个主要计划，一个在所有情况下都非常快，另一个在大多数情况下非常慢。

我已经尝试过这个查询，这样就没有包括 FT 搜索，我发现行估计总是比它们应该的低。

如果我运行，update statistics...with fullscan我仍然会在执行计划中看到来自 NC 索引查找操作的极不准确的行估计。

当行估计值足够低时，会选择循环连接，这通常非常慢（30 秒以上）。更高的估计似乎会产生一个很好的计划，涉及合并连接而不是循环连接。

尽管仍有最新的统计信息，为什么 SQL Server 仍然不估计行数？

计划：https : //www.brentozar.com/pastetheplan/?id=rkXtE0jzX

当我删除该CONTAINS部分，从而省略全文搜索时，查询速度很快，但索引查找的行估计仍然是 1 估计，实际为 2195。

根据@Kin 的建议，我使用了 CONTAINSTABLE，它立即运行并生成了以下计划：https : //www.brentozar.com/pastetheplan/? id =S1hKainzQ有趣的是没有全文搜索运算符。

RANK在这种情况下，Containstable 需要生成相同的结果集，我已经使用AND RANK > 0它WHERE来生成我想要的结果，从而生成此计划：https …

今天早上，收到了以下电子邮件警报：

日期/时间：2/28/2018 9:26:42 AM

描述：尝试在数据库 9 中获取逻辑页 (1:3948712) 失败。它属于分配单元 72057594045857792 不属于 72059184917512192。

评论：（无）

作业运行：SQL Sentry 2.0 警报陷阱

查看辅助副本的事件日志，同一消息出现了 3 次：

源 spid138

消息 尝试获取数据库 9 中的逻辑页 (1:3948712) 失败。它属于分配单元 72057594045857792 不属于 72059184917512192。

在辅助副本（2 节点同步可用性组）上运行以下内容：

DBCC TRACEON(3604)
dbcc page (9, 1,3948712,3)
go
DBCC TRACEOff(3604)

任一副本的结果片段：

Page @0x00000070DAB8C000

m_pageId = (1:3948712)              m_headerVersion = 1               
m_type = 3 m_typeFlagBits = 0x0                m_level = 0            
m_flagBits = 0x8200 m_objId (AllocUnitId.idObj) = 129   m_indexId
(AllocUnitId.idInd) = 256  Metadata: AllocUnitId = 72057594046382080  
Metadata: PartitionId = 72057594040811520                             
Metadata: …

我有一个DELETE针对带有全文索引列的表运行的语句，cascade启用了一些外键。它看起来像这样：

DELETE FROM dbo.STUDENTS WHERE STUDENTID=@STUDENTID

有时会编译一个计划，其中包括对所有索引操作的非常高的行估计，因此DELETE需要很长时间并导致锁定。

我试图迫使QueryStore一个很好的计划，但是这并不实际工作，表现出last forced plan failure description的NO_PLAN。

我已确保没有可能使计划无效的架构更改。

查看执行计划，我看到这DELETE涉及到一个包含 FT 索引的系统表的连接：

加入 FT 索引是否意味着不支持计划强制？

一直在与我公司的应用程序供应商就并行性进行辩论。他们坚持认为 Maxdop = 1 对 app/db 有显着的性能改进，但他们绝对没有提供这方面的证据。

我测试了各种 DOP/CT 设置，发现在使用 Maxdop 4（8 个超线程内核）和 CT 150 时，自动化测试的整体性能提高了 28%。

供应商的 DBA 最近表示：“即使 DOP 为‘1’，MSSQL 的内部进程也能使用该值，在使用它的 MSSQL 服务器中存在低于 51 的 SPID、幽灵清理等问题这个。”

我已经对此进行了研究，尽管信息很少，但 Paul Randall 至少说 Ghost 清理始终是单线程的，所以显然供应商的 dba 不正确？

当 Maxdop =1 时，对 CT 的影响有什么想法吗？

两个节点 Always On 可用性组，一个同步副本。

我的同步副本经常不同步。我看到一种模式，当在辅助副本上进行日志备份时，会出现短暂的延迟，在此期间 redo_queue_size 会迅速填满，如下所示：

查看以下链接中的指南，似乎我的问题主要是由于尝试强化事务时重做线程遇到的争用：

https://technet.microsoft.com/en-us/library/dn135335(v=sql.110).aspx

当事务日志备份运行时，副本进一步不同步，并且在辅助副本上运行的报告也会加剧此问题。

一直以来，我的事务日志备份都很大——平均 1.2GB，但可以更大。

据我所知，我的日志备份会很大，因为我在数据库上启用了 TDE，但我真的没想到它们会这么大。我怀疑这是对辅助副本上的缓慢提交贡献最大的原因。

是否有推荐的性能计数器来诊断同步副本上的慢提交？我还能做些什么来验证我的理论？

我的问题似乎与此处描述的相同：https : //www.sqlservercentral.com/Forums/1871286/AlwaysOn-Missing-Redo-Thread

我可以只在辅助副本上启用此跟踪标志，还是需要应用于两个节点？

编辑：我在早上 6 点检查重做队列，发现一个巨大的数字，恢复时间为 15-20 分钟，并且一直在略有增加。然后我应用了跟踪标志，DBCC TRACEON (3459, -1)几分钟后发现，重做命令的数量下降得非常快。到目前为止，这个跟踪标志似乎已经缓解了这个问题，但据推测，这会将所有事务强化到单线程模式下的辅助副本日志，如 SQL Server 2014，因此，辅助副本仍有可能落后由于非并行线程，当主线程处于高写入负载时。

我知道 SQL Server 2005 不支持DATE，因此不可能将日期时间转换为日期。

我想要做的是在当前一周的一整天内列出所有具有日期时间的记录。

所以我需要在本周星期一创建的所有记录忽略时间戳。目前我正在使用以下内容，它确实显示了本周的周一至周五，但包括时间戳，这意味着我将根据查询的运行时间看到不同的输出：

set datefirst 1

select 
    DATEADD(day, 1 - DATEPART(dw, GETDATE()), CONVERT( DATETIME, GETDATE())) as Monday,
    DATEADD(day, 2 - DATEPART(dw, GETDATE()), CONVERT( DATETIME, GETDATE())) as Tuesday,
    DATEADD(day, 3 - DATEPART(dw, GETDATE()), CONVERT( DATETIME, GETDATE())) as wednesday,
    DATEADD(day, 4 - DATEPART(dw, GETDATE()), CONVERT( DATETIME, GETDATE())) as Thursday,
    DATEADD(day, 5 - DATEPART(dw, GETDATE()), CONVERT( DATETIME, GETDATE())) as Friday

任何人都可以提供帮助吗？

我的预期输出将是本周每一天的一列，每周从星期一开始（即：Datefirst 1）。最终，我将在 case 语句中使用它，例如：

CASE
WHEN DateColumn >= DATEADD(day, 1 - DATEPART(dw, GETDATE()), CONVERT( DATETIME, GETDATE())) …