小编Tim*_*der的帖子

我现在正在成为一名在工作中有点不自觉的 DBA，真的需要一些帮助。

我们在完全恢复模式下有一个 40GB 的数据库，没有配置日志备份和一个 84GB 的巨大日志文件。到目前为止，我挽救这种情况的计划是在数据库上运行完整日志备份，缩小日志文件并制定维护计划，每晚使用数据库备份运行日志备份，以帮助控制它。

我的问题是我不希望日志文件缩小到零并在星期一的第一个早上不断增长。我对文件应该是什么（大约数据库的 20%）有一个粗略的估计，并希望从一开始就设置它以确保尽可能多的连续空间。这只是在数据库属性-> 文件下更改“初始大小”的情况吗？我也猜想数据库需要离线才能发生这种情况？

提前致谢

我正在尝试对我们用于文档管理服务器的 SQL Server 的性能进行故障排除，但今天的性能已经创下历史新低。

查看我最近设置的管理数据仓库 (MDW)，我可以看到缓冲区 I/O 中出现了巨大的峰值。合并的 SQL 等待时间在 1500-2000 毫秒的范围内，这远高于正常情况（大约 500 毫秒）。这种增加的很大一部分是缓冲区 I/O。

不是 DBA 并且出于必要而这样做，我大大超出了我的深度。

有什么方法可以说明为什么缓冲区 I/O 会大幅增加？这可能是由于查询提取了大量数据或 SQL Server 内存限制配置不正确吗？有什么具体的（或一般的）我应该查看或我可以查询的 DMV 以帮助排除故障？

服务器是 SQL Server 2008 R2。它是一个运行两个 vCPU 和 8GB RAM 的虚拟机，磁盘托管在 SAN 上的单独阵列上。

上面的图表都是使用 SQL Server Management Data Warehouse生成的。

犯了一个错误，错误地为 tempdb 输入了一个更改数据库命令。

现在实例不会启动。我无法使用 -m 在单用户模式下启动，因为它指出找不到 tempdb。我尝试使用：

net start msqsqlserver /f /t3608

但是我实际上根本无法使用sqlcmd或连接到实例ssms。

最近我一直在努力解决 SQL 服务器的性能问题，尽管我们已经修复了配置中的大量基本错误，但它的性能仍然很差。澄清这不是整体性能，而是相当频繁的超时（来自客户端应用程序）。 以前我曾将内存视为原因，但现在已解决，我们仍然得到相同的行为。

查看来自管理数据仓库的图表，我可以看到 LCK_M_U/X/IX 在用户遇到超时时导致了我们的大部分等待。我正在阅读的所有内容都表明我需要查看正在运行的查询和进程，但我还没有找到任何针对我可以理解的级别的内容。如下图所示，锁似乎尖峰，这与用户端的错误一致。是否有一个聪明的 DMV 或一些我可以解决的问题，以尝试找出正在运行的查询正在创建锁定？是否是通过跟踪来查找详细信息的情况？如果信息不清楚，任何指导都非常感谢和道歉。