查询持有的锁的数量，我得到一个几百的数字：
SELECT count(*) from
SYS.dm_tran_locks
但是查询性能计数器‘锁定块’给我一个大约 45,000 的数字。
SELECT object_name, counter_name, cntr_value
FROM sys.dm_os_performance_counters
WHERE [counter_name] in ('Lock Blocks', 'Lock Blocks Allocated', 'Lock Memory (KB)', 'Lock Owner Blocks')
Microsoft 对锁块的定义如下：
指定服务器上当前正在使用的锁块数（定期刷新）。锁块代表单个锁定的资源，例如表、页面或行。
所以我希望数字相同，或者至少大致相同。我的理解显然有些欠缺，所以我正在努力更好地理解这一点。任何帮助都将不胜感激。
我正在将数据库迁移到 Azure SQL 数据库。我阅读了有关 Azure SQL 数据库和 Azure 托管实例之间的差异，并注意到 Azure SQL 数据库不支持 CLR 函数。
这让我很惊讶，因为我已经将测试版数据库加载到 Azure SQL 数据库中，没有人抱怨出现问题。我查看了一下，果然，CLR 程序集就在那里，使用 CLR 函数运行查询工作正常。
因此我在网上搜索，看到的所有信息都是 CLR 不适用于 Azure SQL 数据库。但我在这里，Azure SQL 数据库中有一个可以运行的 CLR 程序集。
所以现在我想知道，我是否应该告诉企业我们必须改用托管实例，因为这是唯一支持 CLR 的地方？还是坚持使用 Azure SQL 数据库，因为它运行良好？还是我错过了什么？微软是否在没有告诉任何人的情况下重新启用了 CLR？
我正在将 SSIS 包从 SQL Server 2012 迁移到新的 2022 服务器。该包在循环内使用执行包任务来运行项目中的另一个包。我发现第一次运行执行包任务时似乎需要相当长的时间才能启动，并且我不知道为什么或在哪里寻找原因。
主包的相关部分是这样的：
从执行时间来看，第一次调用通用解析包需要 10 多秒（最后一列以毫秒为单位），但该包的组件只花费了该时间的一小部分。通用解析的后续执行（也显示在结果中）按预期运行，没有初始延迟。
我有一个没有注册 SPN 的实时 SQL Server 2012 环境 - 这以前不是问题，因为不需要 Kerberos 身份验证。但现在它是必需的。
我已经正确配置了所有内容，但是在进行了这些更改之后，我想确保 SQL Server 可以成功注册 SPN——最好不要重新启动服务，因为这是一个实时环境。
有没有办法做到这一点？
PS 我知道我可以手动注册 SPN，但我想确保它们可以自动注册。
我有一个非常繁忙的数据库，我被要求寻找回滚的事务。
我使用 SQL Server Profiler 来监视TM: RollbackTran 完成事件，这表明每分钟都会发生数十个这样的事件，但它没有给我任何关于正在回滚的事务、回滚影响的对象的任何指示，或者回滚发生的原因。简而言之，它的用途似乎非常有限。
例如，如果我还尝试监视，以便SQL:StmtStarting为回滚提供一些上下文，那么在这个繁忙的环境中就会有太多噪音，无法识别哪个语句负责回滚。
我也尝试运行语句
SELECT *
FROM fn_dblog (NULL, NULL)
WHERE Operation = 'LOP_ABORT_XACT';
但这并没有返回任何结果（考虑到 SQL Profiler 报告的回滚次数，这似乎很奇怪）。
有什么方法可以生成显示已回滚事务的报告？
蒂亚！
在 SSRS 数据源的属性中，我可以指定要使用的 Windows 域帐户，如下所示：
此数据源最初是从 SSDT 项目部署的，我需要将这些设置反映在该项目中——否则下次部署该项目时数据源将不再正常工作。
不幸的是，SSDT 似乎没有提供这样做的方法。如果我在此处指定凭据，它会自动采用 SQL Server 身份验证（这对我没有用）。
我是否遗漏了什么，或者我再次成为 Microsoft 无法保持一致的受害者？
我在实时服务器 (SQL Server 2008 R2) 上创建了一个非聚集索引，结果证明并没有带来我所希望的性能优势。所以我想再次删除索引。
不幸的是，我无法锁定正在使用的索引。它可能总是会被使用。重新启动 SQL Server 并不是一个真正的选择。
过去，当我想重建索引时，我也遇到过同样的问题，我不得不通过重新组织来解决这个问题（这有时效率很低）。
有没有办法告诉 SQL Server 停止使用索引？或者是否可以运行一个查询来尝试获取索引的排他锁，无限期地等待，然后删除索引？还有其他选择吗？还是我只需要等到出现某种中断，然后希望我记得在一切恢复在线之前将其删除？
在 SQL Server 2008 中使用数据库镜像时，可以在最旧的未发送事务超过特定阈值时设置警报。我们可以使用 Launch Database Mirroring Monitor 菜单命令检查任何数据库镜像的状态。
在 SQL Server 2012 中，我们现在有了可用性组。在我看来，存在同样的潜在问题，如果事务无法发送到辅助服务器，则镜像将被暂停，并且事务日志可能会填满我们所有的磁盘空间。但是，数据库镜像监视器工具似乎无法将可用性组中的数据库识别为已镜像。
如果最旧的未发送交易超过某个值，是否有办法设置警报？有没有办法设置该特定值？
我有一个数据库似乎运行良好，没有明显的错误，除了任何完整备份被破坏 - 尝试恢复失败并出现错误“RESTORE detected an error on page (18469:-1767164485)”
数据库上的 DBCC CheckDB 完成且没有错误。
编辑#1
使用以下命令创建备份：
BACKUP DATABASE @DatabaseName
TO
DISK = @backupFile1,
DISK = @backupFile2,
DISK = @backupFile3
WITH COMPRESSION, RETAINDAYS = 0, FORMAT, INIT, SKIP, NAME = @DatabaseName
编辑#2
我刚刚使用 GUI 数据库备份完成了备份，以防我的脚本以某种方式出错 - 这给出了与损坏备份相同的结果。
--
这是昨晚才开始发生的。我知道的唯一重大变化是我更改了数据库的“自动收缩”选项（它最初设置为 true）。
有人知道 SQL Server 2012 在这方面的问题吗（特别是我的版本是 11.0.3128）？这可能只是巧合或完全与其他事情有关，但目前看来这是最有可能的原因。
此外，有人对在这种情况下该怎么做有什么建议吗？数据库运行良好（据我所知），但我不在乎长时间没有备份......！
我有一个第三方数据库，其中大量表都有一个“companyID”列，并且针对这些表的大部分查询都包含companyID = @companyID在 where 子句中。
[编辑：除了 where 子句之外，companyID 通常也用在大多数查询的 order by 子句中：例如order by companyId, otherField1, otherField2 etc..
]
在我们的组织中，companyID 列始终填充 1（尽管在未来某个时候可能会发生变化）。
现在我正在考虑在这些表上创建一些索引。SQL Server 推荐了一些“缺失索引”，所有推荐都包含 companyID 字段作为索引中的第一列。
按照首先指定最具选择性的列的原则，我认为我应该将 companyID 列放在最后，或者甚至根本不在索引中。但是后来我想知道为什么 SQL Server 的缺失索引视图总是建议把它放在第一位——当然 SQL Server 足够聪明，知道每一行都包含该列的相同值？
纯粹是一个理论问题，因为我一直在考虑可能的 DR 场景......
在这种情况下：
是否可以将增量日志备份恢复到镜像上以使其保持最新并重新联机，或者您是否需要从头开始恢复完整备份？
根据数据库的大小，差异可能是停机时间，所以很高兴知道。我主要对 SQL Server 2008 R2 和 2012 感兴趣，但如果存在差异，其他人可能会对其他版本感兴趣。
Microsoft 建议不要费心重建少于 1,000 页的索引（从内存我认为这是因为它们太小以至于它们将保存在 RAM 中）。
如果我不重建它们，那么它们将变得支离破碎。在那种情况下，拥有它们还有什么意义吗？我在想象一本电话簿，其中每一个条目都在错误的位置——这将毫无用处！
为了澄清，我主要谈论非聚集索引，但我很想知道聚集索引的答案是否不同。
这个问题的答案表明索引可以帮助避免行锁背后的阻塞问题，如果它是正确的并且适用于 SQL Server，这将是索引可能仍然有用的原因。
我有一个托管数据仓库数据库的 SQL Server 2008 R2 数据库服务器。在这台服务器上还安装了 SQL Server Reporting Services，以及它的两个数据库 ReportServer 和 ReportServerTempDB。
出于性能原因，我想将数据仓库数据库和 Reporting Services 分开。我有另一台可用于安装 SSRS 的服务器。两台服务器都是虚拟的，因此它们的规格很容易更改，或者在必要时可以“创建”其他服务器。
我无法理解的是托管 ReportServer 和 ReportServerTempDB 的最佳位置。我可以看到三个选项：
对于选项 1，我担心将 Reporting Services 与其数据库分开会影响数据仓库服务器，或者会影响报告。对于选项 2，我担心在服务器上安装数据库引擎会影响 Reporting Services 服务器的性能，而对于选项 3，我担心我会浪费资源来创建几乎不会做任何事情的服务器，并且还会通过分离来影响报告Reporting Services 来自其数据库。
我认为我需要的关键信息是了解 Reporting Services 的哪个部分是资源最密集的部分。如果是 Reporting Services 应用程序，那么我可以将数据库留给数据仓库。如果是资源密集型数据库，那么我需要将它们放在 Reporting Services 应用程序中，或者创建一个新服务器。
有人可以解释一下吗？
谢谢！
如果我在表的聚集索引上设置压缩（页或行），这与在表上设置压缩相同吗？
SQL Server 提供了两者的选项，这表明它们是不同的，但我的印象是聚集索引和表本质上是相同的，我对聚集索引如何工作的心理模型告诉我压缩聚集索引还必须压缩表。
我将大量数据导入一个空数据库，在开始之前，我禁用了所有非唯一非聚集索引，看看是否可以提高导入性能。
现在我想重新启用索引，我想知道是否可以做些什么来优化它。
有超过 100 个表和近 2,000 个索引需要重建。数据库大小为 200GB。
我正在运行的脚本的关键部分是：
declare c_toggle_index cursor FORWARD_ONLY READ_ONLY for
select 'alter index ' + QUOTENAME(i.name) + ' on ' + o.name + ' rebuild'
from sys.indexes as i
Inner Join sys.objects o
On o.object_id = i.object_id
Where o.is_ms_shipped = 0
And i.index_id >= 1
and i.type > 1
and i.is_disabled = 1
我考虑为alter index 语句设置ONLINE=OFF，但是当索引开始被禁用时，我不确定这个设置是否会产生任何影响。我还考虑设置 SORT_IN_TEMPDB = ON，但由于 tempdb 文件与数据库的 .mdf 文件位于同一驱动器上，因此我认为这样做也没有任何好处。
在运行重建脚本时，我注意到我有很多 CXPACKET 等待类型。我真的不明白为什么会这样，或者这是否是我应该寻求解决的问题。
最后一点可能相关：除了将数据导入数据库之外，我的整个服务器当前处于非活动状态。无需考虑或担心其他用户活动；我唯一关心的是在尽可能短的时间内将数据导入数据库。
我有一个执行数据库备份的存储过程。因为我正在查看 SQL Server 2012 中的可用性组，所以我想利用该脚本中的 *sys.fn_hadr_backup_is_preferred_replica* 函数来测试脚本是否应该生成备份。
如果脚本是手动运行而不是作为计划的 SQL 代理作业的一部分，或者如果 SQL 代理作业是手动执行而不是通过计划执行，那么我希望作业失败并显示错误消息以允许用户看到由于不在首选副本上，备份未成功。如果作业按计划运行，那么我显然不希望它失败，因为它会产生错误并整天在不是首选副本的服务器上发送警报。
我不知道该怎么做的唯一一点是检查作业是按计划执行还是手动执行。这可能吗？
如果做不到这一点，有没有其他方法可以提醒用户脚本没有生成备份，同时不会导致计划任务失败并产生警报？
我在我们的 SQL Server 上启用了即时文件初始化，因此数据库文件的“空”部分在分配之前不会清零。我的理解是，这意味着该文件可能包含“已删除”的数据。
所以现在我想向公司外部发送一份数据库副本（可能是备份文件）。但是文件中存在所有可能敏感的“已删除”数据。现在我想将文件未使用的部分归零。
那可能吗？我想我可以创建一个新的数据库并将所有内容复制过来，或者可能将数据库的副本恢复到另一台服务器而不启用即时文件初始化，然后使用 ShrinkFile 命令积极删除数据库文件的大部分或全部未使用部分，但有没有更省时省力的方法呢？理想情况下，一个命令告诉 SQL 将文件清零，就像在未启用即时文件初始化时它会做的那样。
我意识到我的问题不是严格意义上的“数据库”，但我知道很多 DBA 会使用 SQLIO 工具来检查他们系统上的 I/O 性能，所以我希望这里有人能够回答这个问题：
当我运行 SQLIO 时，输出的第三行是这样的：
使用系统计数器进行延迟计时，每秒 14318180 次计数
这意味着什么？我在不同的系统上得到不同的值，并且因为我正在比较不同的系统，所以我想知道这个数字告诉我什么（如果有的话）。
我目前正在做一些监视 SQL Server 性能的工作。我发现以下脚本 [1] 计算“页面查找百分比” - 建议“好”值小于 100。
SELECT 1.0*cntr_value /
(SELECT 1.0*cntr_value
FROM sys.dm_os_performance_counters
WHERE counter_name = 'Batch Requests/sec')
AS [PageLookupPct]
FROM sys.dm_os_performance_counters
WHERE counter_name = 'Page lookups/sec'
现在我已经在十几个不同的服务器上运行了这个脚本——大部分是虚拟的，但也有一些物理的，主要是 2008R2 Enterprise，但有几个 2005，一些是实时的，一些是开发的，甚至是一个仅作为见证的物理 2008R2 Express 版本服务器并且当前处于休眠状态（没有使用主动故障转移设置镜像）。只有其中一台服务器的值低于 100。在大多数情况下，它一直在 1000 或至少在 100 的中间。在休眠的见证服务器上，价值是荒谬的 20,000！
这是否表明我们在这一领域存在广泛的问题，或者是否有一些无辜的解释来解释为什么这个数字在这么多不同的服务器上应该如此之高？我们在其中一些服务器上遇到了性能缓慢的问题，因此更好地了解这个数字告诉我的内容对我很有用。
[1] - http://thomaslarock.com/2012/05/are-you-using-the-right-sql-server-performance-metrics/