小编Aar*_*and的帖子

我正在使用 T-SQLCOALESCE函数，其中第一个参数在大约 95% 的运行时间不会为空。如果第一个参数是NULL，第二个参数是一个相当漫长的过程：

SELECT COALESCE(c.FirstName
                ,(SELECT TOP 1 b.FirstName
                  FROM TableA a 
                  JOIN TableB b ON .....)
                )

例如，如果 ，c.FirstName = 'John'SQL Server 仍会运行子查询吗？

我知道使用 VB.NETIIF()函数，如果第二个参数为 True，代码仍会读取第三个参数（即使不会使用它）。

我想知道如何识别实际填充 TEMPDB 数据库事务日志的确切查询或存储过程。

我经常看到这样的问题，人们想知道某件事是否发生、何时发生或是谁执行的。在很多情况下，SQL Server 不会自行跟踪此信息。例如：

• 谁最后执行了存储过程dbo.MyProcedure？
• 谁更新salary了dbo.Employees表中的列？
• 谁最后dbo.Orders从 Management Studio查询了表？

但是，SQL Server默认会临时跟踪其他几个事件，并且可以在本机回答有关问题，例如：

• AdventureWorks 数据库中上一次自动增长是什么时候？用了多长时间？
• 谁删除了dbo.EmployeeAuditData表，何时删除？
• 今天发生了多少与内存相关的错误？

我如何获得这些信息，以及它可以保持多久？

我有一个包含 64m 行的表，在磁盘上占用了 4.3 GB 的数据。

每行大约有 30 个字节的整数列，加上一个NVARCHAR(255)用于文本的变量列。

我添加了一个带有 data-type 的 NULLABLE 列Datetimeoffset(0)。

然后我为每一行更新了这一列，并确保所有新的插入都在这一列中放置了一个值。

一旦没有 NULL 条目，我就运行这个命令来使我的新字段成为强制性的：

ALTER TABLE tblCheckResult 
ALTER COLUMN [dtoDateTime] [datetimeoffset](0) NOT NULL

结果是事务日志大小大幅增长——从 6GB 增加到超过 36GB，直到空间用完！

有没有人知道 SQL Server 2008 R2 到底在为这个简单的命令做些什么来导致如此巨大的增长？

最近我们的一个 ASP.NET 应用程序显示了一个数据库死锁错误，我被要求检查并修复该错误。我设法找到死锁的原因是一个存储过程，它严格更新游标内的表。

这是我第一次看到这个错误，不知道如何有效地跟踪和修复它。我尝试了我知道的所有可能的方法，最后发现正在更新的表没有主键！幸运的是，这是一个身份栏。

后来我发现为部署编写数据库脚本的开发人员搞砸了。我添加了一个主键，问题就解决了。

我感到很高兴并回到我的项目中，并做了一些研究以找出导致僵局的原因......

显然，这是导致死锁的循环等待条件。没有主键的更新显然比有主键需要更长的时间。

我知道这不是一个明确定义的结论，这就是我在这里发布的原因......

• 缺少主键是问题吗？
• 除了（互斥、保持等待、无抢占和循环等待）之外，是否还有其他条件会导致死锁？
• 如何防止和跟踪死锁？

我今天有一个由其他人创建的 .bak 文件，通过 SSMS 2008 R2 手动创建。我正在尝试手动恢复数据库，不幸的是，当我浏览它时该文件没有出现。

我可以编写恢复过程的脚本，但我以前见过这个问题，我不确定是什么原因导致 .bak 不出现。

很多时候我在处理 SQL Server 时需要编写如下内容。

create table #table_name
(
    column1 int,
    column2 varchar(200)
    ...
)

insert into #table_name
execute some_stored_procedure;

但是，创建一个具有作为存储过程结果的精确语法的表是一项繁琐的任务。例如，sp_helppublication的结果有 48 列！我想知道是否有任何简单的方法可以做到这一点。

谢谢。

有人可以让我更好地了解兼容模式功能吗？它的行为与我预期的不同。

据我所知，兼容模式是关于不同版本的 SQL Server 之间某些语言结构的可用性和支持。

它不会影响数据库引擎版本的内部工作。它将尝试阻止使用早期版本中尚不可用的功能和构造。

我刚刚在 SQL Server 2008 R2 中创建了一个兼容级别为 80 的新数据库。创建了一个只有一个 int 列的表，并用几行填充它。

然后用一个row_number()函数执行一个 select 语句。

我的想法是，由于 row_number 函数是在 2005 年才引入的，这会在兼容 80 模式下引发错误。

但令我惊讶的是，这工作得很好。然后，当然，只有在您“保存某些内容”时才会评估兼容规则。所以我为我的 row_number 语句创建了一个存储过程。

存储过程的创建进行得很顺利，我可以完美地执行它并获得结果。

有人可以帮助我更好地了解兼容模式的工作吗？我的理解显然有问题。

我知道收缩是魔鬼：它会颠倒页面顺序并导致皮肤癌、数据碎片化和全球变暖。名单还在继续……话虽如此，假设我有一个 100 GB 的数据库，我删除了 50 GB 的数据——不是在一个表上，而是在数据库范围内对旧数据进行一般修剪，覆盖 90% 的数据表——这是否构成缩小数据库的适当用例？

如果没有，从数据库中删除如此高比例的数据后，应采取哪些适当的步骤来清理房屋？我可以想到两个：重建索引和更新统计。还有什么？

我正在寻找处理 SQL Server 2012 可用性组中计划的 SQL Server 代理作业的最佳实践。也许我错过了一些东西，但是在目前的状态下，我觉得 SQL Server 代理并没有真正与 SQL2012 的这个强大功能集成在一起。

如何让计划的 SQL 代理作业知道节点切换？例如，我有一个在主节点上运行的作业，它每小时加载数据。现在，如果主要服务器出现故障，我如何激活现在成为主要服务器的辅助服务器上的作业？

如果我总是在辅助上安排作业，它会失败，因为辅助是只读的。