标签: sql-server

我们的第 3 方生产系统之一经历了重大升级，通过 sp_whoisactive，我现在看到很多查询（1 个事务深度），这些查询阻止了我读取 dm_db_missing_index_details 的任何尝试。

我尝试过设置事务隔离级别并使用 NOLOCK，但 SQL 只是当着我的面笑。

汉娜·弗农 (Hannah Vernon) 能够在这里复制这种行为。

有谁知道如何解决这个问题？

上周我们的系统遇到了一些奇怪的阻塞，Redgate Intellisense 是阻塞链的一部分，是否有其他DMV也有同样的问题？

我的任务是通过 t-sql 将 SQL Server 中保存的图像（作为 varbinary）提取到平面文件中。我已经有十多年没有做过 ETL 工作了，除了使用 sp_OACreate、sp_OAMethod 等之外，我不记得通过 t-sql 执行此操作的任何其他方法。

是否有一些新方法可以解决这个问题？更“可靠”并且不需要打开 OLE 自动化程序并做所有这些疯狂的事情的东西？

这将是一个持续的过程。不是一次性运行。

我多年来一直在寻找这些信息，但似乎找不到它：

learn.microsoft.com上是否有任何文档提供了一个表，其中包含 SQL Server 和 LocalDB 的所有有效连接字符串参数、它们的有效参数值、它们的默认值及其含义？

我找到的只是一些教程和示例页面，但没有完整的参考页面。

SQL Server 分配有110GB 内存。

它正在消耗整个内存。

我想了解是否存在内存压力。

通常，SQL Server 将从内存中删除旧页面（当前不需要）并从磁盘中提取所需的页面。然而，当存在内存压力时——（假设内存中的所有页面都被需要并被积极使用）SQL Server将利用磁盘上的页面文件作为备用内存区域。

什么 perfmon 指标可以帮助我监控 SQL Server 内存是否面临压力（即正在使用磁盘页面文件）？

我知道内存：页面错误/秒 - 但这不仅限于 SQL 服务器内存压力。还有哪些其他性能指标可以帮助我？

当 INSERT 查询被触发时，SQL Server 将其记录在其日志中并向用户发送查询已完成的确认。同时它还更新数据页面。这两者（日志和数据页）都驻留在内存中。

无论恢复模式如何（简单、批量或完整），每当发生检查点时，SQL Server 都会将日志和脏页从内存刷新到磁盘。

问题：假设在向用户发送确认后、检查点之前发生电源故障，那么，由于内存中的日志尚未写入磁盘，即使用户已收到确认，此 INSERT 操作是否会丢失？这是否违反了 ACID 的持久特性？

我尝试更新 的值cost threshold for parallelism，但由于我的数据库是 Azure SQL 数据库，我无法运行以下命令：

EXEC sp_configure 'cost threshold for parallelism', 40 ;
GO
RECONFIGURE

由于错误“无法找到存储过程‘sp_configure’。 ”

是否可以在 Azure SQL 数据库中更新此设置？

这是一个奇怪的场景。事务日志已满。它等待AG。AG一切都好。无延迟，最后提交/硬化时间在所有节点上几乎都是实时的。预计恢复时间为零。我也从主节点和辅助节点检查了这一点（以防仪表板未更新）。此页面仅列出了此错误的两个原因：传递延迟和重做延迟。没有任何内容适用于我的系统。如何进一步解决这个问题？

编辑 1。我们对环境所做的唯一更改是添加了两个 SQL Server 2019 节点以准备迁移。但它不应该出现这样的问题。

编辑2。我发现的唯一解决方法是将数据库重新添加到AG。

我希望使用户能够查看查询执行计划以调整查询。在 SQL Server 中向数据库用户启用 SHOWPLAN 权限有什么缺点吗？我只是想确保这不会对总体性能产生负面影响。

我们有 2 个完全相同的数据库环境。第二个环境包含生产数据库的副本并在发票表中托管大约 11M 条记录。此环境的目标是用于查看特定升级查询需要多长时间才能知道是否会出现任何停机（因为表在架构更改期间被锁定）

在第二个环境中执行 add 语句时

alter table Invoice add IsVerified bit not null default(0)

查询立即退出，这很奇怪，因为里面有11M条记录。我预计至少会有一点延迟。即使是 select count(*) 也需要更长的时间。然而，在主生产数据库上，它需要更长的时间，超过 30 秒，因此我们必须将此查询计划到一个特殊的维护窗口中。执行查询时，没有任何东西阻止 SPID（使用 sp_who2 检查）

可能是什么原因，数据库的第二个副本似乎根本没有在 11M 记录数据库中添加列，而另一个主数据库无法及时完成（<30 秒）。也许一些特殊设置允许您添加默认值列而不需要写入所有记录？难道是因为我们的测试环境是Developer版而生产环境是Standard版？也许开发版中的某些特殊功能在 SQLStandard 中未激活？

select count(*) from Invoice //result: 11701200
SQL Server Execution Times:
   CPU time = 2375 ms,  elapsed time = 608 ms.

要添加的脚本：

alter table Invoice add IsVerified bit not null default(0)
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server …

这是在 SQL Server 2019 上运行的，在具有 64GB 或 RAM 的 Windows 10 上运行。尝试解决内存问题时，我发现了一篇使用以下查询的帖子：

SELECT virtual_address_space_reserved_kb as Reserved, 
       virtual_address_space_committed_kb Committed,
       physical_memory_in_use_kb as Physical
FROM sys.dm_os_process_memory 

在我的服务器上运行查询产生以下结果：

Reserved     Committed   Physical

101,881,000  3,123,124   2,747,764

所以提交的内存比物理内存更多。我觉得这很奇怪，所以我重新启动了服务器，再次运行查询，数字发生了变化，但承诺仍然大于物理：

Reserved     Committed   Physical

102,000,616  2,259,624   1,743,392

这正常吗？如果没有，我的服务器是否存在严重问题？