标签: sql-server

我们有一个 SQL Server 2008 数据库服务器（它恰好在 MS 故障转移群集下运行，但我认为这与此处无关）。

我们的应用程序运行 Hibernate 以进行数据库访问，自从我们最近从 v3.1 升级到 3.6 以来，我们经常遇到 SQL Server 崩溃（每 24-48 小时，但有时更频繁）。

有问题的具体问题似乎与内存有关。就在服务器崩溃之前（然后似乎由故障转移集群管理器自动重新启动），我们收到了这些错误的负载：

Error: 701, Severity: 17, State: 130.
There is insufficient system memory in resource pool 'internal' to run this query.

也偶尔（但定期）的消息

Error: 17300, Severity: 16, State: 1. (Params:). The error is printed in terse mode because there was error during formatting. Tracing, ETW, notifications etc are skipped.

错误：17312，严重性：16，状态：1。（参数：）。错误以简洁模式打印，因为格式化过程中出现错误。跟踪、ETW、通知等被跳过。

我还收到一些应用程序级别的错误，例如

java.sql.SQLException: A time out occurred while waiting to optimize the query. Rerun …

我LCK_M_S在使用 RCSI时看到等待共享锁 ( )。我的理解是这不应该发生，因为SELECTs在使用 RCSI 时不需要共享锁。

我怎样才能看到共享锁？是因为外键吗？

这是上一个关于为什么我无法缩小主体数据库上的日志文件的问题的后续问题。

长话短说，我设置了数据库镜像，但忘记确保备份事务日志的作业再次运行，事务日志增长到近 60GB。

由于设置了镜像，这种大小的增加在镜像服务器上重复出现，最终占用了所有磁盘空间，使镜像数据库无法使用。

根据有关镜像数据库上事务日志维护的这个问题，您无法备份镜像上的日志，但是当在有关如何缩小镜像数据库上过度增长的日志文件的评论中特别询问时，留下了一条评论

一种方法是故障转移到镜像数据库并在那里进行收缩。在非生产环境中对此进行彻底测试，以确保它具有您想要/期望的行为。

这似乎表明可能有其他方法可以缩小镜像上的日志文件，并且这种方法在生产服务器上不一定安全。

有没有办法安全地缩小数据库镜像上的事务日志文件？

出于多种原因，我的所有数据库文件只有 3 个硬盘驱动器（RAID 和 Always-On AG）：

• D：数据
• E：日志
• F：临时数据库

tempdb 日志文件应该与数据文件一起放在 F: 上还是放在 E: 上？

到目前为止，我的 tempdb 数据文件的档位最高，日志文件排在 24 个中的第 4 个。

在我有限的 DBA 经验（我是一名开发人员）中，我倾向于将 tempdb.ldf 放在 E: 上，因为写入都是顺序的。

鉴于以下代码段：

-- error checking omitted for brevity
begin tran

exec database1..my_stored_procedure
exec database2..my_other_stored_procedure

if (@@error <> 0)
  rollback

commit

事务信息将插入到哪个数据库的事务日志中？

我希望两个日志都能获得所有数据，因为如果您尝试重放database1事务日志并且它只影响该数据库，那将毫无意义。我还希望您无法database1在database2不存在的服务器上重放的事务日志，反之亦然。

.. 但我愿意接受更正！

我从客户那里收到了一个需要恢复的 .bak 文件，但恢复超过了 SQL Server 2008 R2 10240 MB 每个数据库的许可限制。我真正需要的是数据库结构。有没有办法恢复或者我只是恢复结构？

我们知道，在优化过程中，备忘录结构被修剪，一些昂贵的替代计划被丢弃。我想知道是否有任何方法可以防止这种情况发生，让优化器只考虑每个可能的计划并从所有备选方案中选择最佳方案？

我正在尝试针对 95% 的数据已存档和删除的数据库以 1GB 的块运行 dbcc 收缩文件。我有一个 235GB 的文件，其中 9GB 是数据/索引。我想把它缩小到 50GB。我知道收缩数据库文件是不好的，它会导致碎片等。作为数据清除/收缩的一部分，我们还有一个重建 idnex 脚本。

当我在自己的工作站（四核、12GB RAM、2 个 SATA 驱动器）上针对数据库运行 dbcc 收缩文件脚本时，收缩需要大约 8-10 分钟。

在数据清除后针对数据库的相同副本运行相同的代码时，在我们的测试环境中（80 多个内核、128GB RAM、SSD SAN），需要 70 分钟。请注意，在运行收缩文件时，此服务器上几乎没有活动。它已运行 4 次，结果相同。

然后我采用了不同的方法，将剩余的 9GB 移动到不同的文件组和物理文件。在我自己的工作站上对空的 230GB 文件运行 dbcc shrinkfile 以将其缩小到 50GB 需要 < 1 分钟。

使用相同的方法，在测试环境中，再次需要 70 分钟以上。

在测试环境的 70 分钟运行期间，我根据 Brent Ozar 的脚本拍摄了前后的 waitstats 快照，并且返回的 waittypes 没有显示任何值得关注的内容。下面的前 3 行：

第二采样时间 采样持续时间（以秒为单位） wait_type 等待时间（秒） 每次等待平均等待毫秒数
2013-05-28 11:24:22.893 3600 写日志 160.8 143066 1.1
2013-05-28 11:24:22.893 3600 CXPACKET 20.9 13915 1.5
2013-05-28 11:24:22.893 …

我的任务是识别生产服务器上发生的任何阻塞。我实现这一目标的计划是使用

EXECUTE sp_configure 'blocked process threshold', 5

结合服务器端跟踪来收集阻塞进程报告。

我知道这项活动会影响性能，我想找到某种方法来量化这将是什么。

这里正在进行一场冗长的辩论，所以我想听听其他意见。

我有许多带有 uniqueidentifier 聚集 PK 的表。这是否是一个好主意超出了这里的范围（并且不会很快改变）。

现在，必须合并发布数据库，并且 DEV 提倡使用单独的 rowguid 列，而不是将现有的 PK 标记为 ROWGUIDCOL。

基本上，他们说应用程序永远不应该将仅由复制使用的东西带入其域（这对他们来说只是“DBA 的东西”）。

从性能的角度来看，我认为没有理由添加一个新列来做一些我可以用现有列做的事情。而且，既然只是“DBA 的东西”，为什么不让DBA 选择呢？

我有点理解 DEV 的观点，但我仍然不同意。

想法？

编辑：我只想补充一点，我在这场辩论中是少数，质疑我立场的开发者是我尊重和信任的人。这就是我求助于征求意见的原因。
我也可能遗漏了一些东西，并且可能误解了他们的观点。