标签: dbcc

DBCC ShrinkDatabase()
DBCC ShrinkFile()

1. 我是否需要同时运行两个 DBCC 命令才能缩小数据库？
2. 上面这两个有什么区别？

我有一个数据库，它有一个350 MB 的数据文件(.mdf) 和一个4.9 GB 的日志文件(.ldf)。恢复模式设置为FULL.

当我尝试缩小日志文件时，它并没有缩小。

我知道缩小数据库不好，也不应该这样做。但我仍然试图缩小日志文件。

当我跑

DBCC SQLPerf(logspace) 

我发现日志大小为4932 MB，使用的日志空间为98.76%！

然后我尝试了这个命令

USE <databasename>;
DBCC loginfo;

现在几乎所有的 VLF 都是“状态 2”，这意味着都在使用中。

我尝试进行日志备份，然后缩小日志文件。收缩并没有减小尺寸。

我将恢复模型更改为SIMPLE并再次尝试缩小，但这也无济于事。

我检查了未结交易

DBCC opentran (database);

并发现现在没有交易打开。

是什么阻止我缩小日志文件？我该如何解决这个问题？

这个问题是由这篇较早的帖子提示的，我有一个数据库归档以备将来调查，该数据库在以下情况下恢复：

BACKUP 'BrokenDatabase' detected an error on page (1:123456) in file ’BrokenDatabase.mdf'.
Error: 3043, Severity: 16, State: 1.

在链接的问题和备份中，我已准备好进行 DBCC PAGE 调查，DBCC CHECKDB 无错误通过，但显然存在损坏。

哪些类型的损坏会导致 CHECKDB 通过但 BACKUP WITH CHECKSUM 会失败？

PostgreSQL 中是否有任何 DBCC（数据库一致性检查器）命令？我可以找到 SQL 服务器 DBCC 命令，但不能找到 Postgres？我读到 postgresql 具有内置的性能调整功能，并且没有可用于 postgres 的 DBCC 命令。这是真的吗？

在为使用 SQL Server 的应用程序运行性能测试/基线之前，我希望能够将实例设置为“干净”状态，而无需重新启动实例。我倾向于遵循一些步骤，但我想构建一个按正确顺序排列的明确列表，并且没有多余的步骤。

此步骤列表是否完成将 SQL Server 设置为“干净”状态？

顺序是否合乎逻辑/正确？

有没有多余的步骤？

CHECKPOINT              -- Write all dirty pages

DBCC DROPCLEANBUFFERS   -- All should be clean after checkpoint?

DBCC FREEPROCCACHE      -- Clear the plan cache

DBCC FREESYSTEMCACHE    -- Is this necessary after FREEPROCCACHE?

DBCC FREESESSIONCACHE   -- May not be necessary if distributed queries aren't used, but want to catch all scenarios

EXEC SP_UPDATESTATS     -- Refresh stats

'BEGIN TESTING!'

我为 .ndf 创建了太多辅助数据文件 (.ndf) tempdb。要删除多余的文件，我需要清空文件（内容将移动到其他文件）：

DBCC SHRINKFILE('tempdbfile8', EMPTYFILE);

然后删除文件：

ALTER DATABASE tempdb REMOVE FILE tempdbfile8;

但是EMPTYFILE命令返回错误：

DBCC SHRINKFILE: Page 8:41920 could not be moved because it is a work table page.
Msg 2555, Level 16, State 1, Line 2
Cannot move all contents of file "tempdbfile8" to other places to complete the emptyfile operation.

不用担心，我只需要找到使用此页面的对象即可：

DBCC TRACEON (3604)
DBCC PAGE(2,8,41920) --dbid=2, fileid=8, pageid=41920

该命令返回了很多信息，其中的object_id。但：

Metadata: ObjectId = 0 

我不知道该怎么办。什么猫阻止了这个页面被移动？如何定位该对象、进程、会话或其他任何内容？任何帮助将不胜感激，但请注意保持原样或删除其他文件不是解决此问题的有效方法;)。

编辑：

我正在删除这些文件，因为我们曾经遵循“最佳实践”，即为每个处理器内核创建一个文件（相同的初始大小，相同的增长率）。但据我所知，在遇到争用问题之前，没有必要在同一设备上创建额外的 tempdb 文件。在我们的例子中，这是有道理的，因为我们打开了MPIO，并且存储设备可以处理 4 个路径。但是有一个错误，我们最终得到了 …

我正在运行一些SHRINKFILE操作来清理文件组中的一堆微小的、不必要的文件。对于其中一种收缩，以下命令会导致错误：

DBCC SHRINKFILE (N'myfile' , EMPTYFILE)'

数据库 ID x 的文件 ID x 无法收缩，因为它正在被另一个进程收缩或为空

它不是空的，也不是被缩小的。它正在一个数据库上运行，除了我自己，其他人目前都没有使用它。自动收缩未启用且从未启用。但是，在我开始使用它之前，会定期对这个数据库进行手动收缩，如果这很重要的话。

在SQLServerCentral 上，十年前的一个线程建议向文件添加几 MB，因为这“会重置一个内部计数器或开关，告诉它现在不在缩小中间。”

这有效 - 太棒了。但是任何人都可以更详细地解释如何/为什么在 SQL Server 内部工作？

我目前正在运行一个脚本，该脚本对 SQL Server 2005 数据库中的每个表执行 DBCC INDEXDEFRAG，一次一个表。由于空间限制和正常运行时间要求，不能使用 DBCC DBREINDEX 代替 INDEXDEFRAG。

我注意到对某些表进行碎片整理需要很长时间。例如，如果我检查“sys.dm_exec_requests”动态管理视图，我可以看到以下 INDEXDEFRAG 当前正在处理 table_id 为 829610394 的表的聚集索引：

DBCC INDEXDEFRAG (0, 829610394, 1)

我知道在碎片整理过程完成之前需要很长时间。撇开当前运行的脚本最终会对所有表进行碎片整理的事实不谈，在当前命令执行时，我在另一个表的聚集索引上手动运行另一个 DBCC INDEXDEFRAG 有什么危害吗？如果我这样做，实际上会同时对两个表进行碎片整理吗？

我正在尝试针对 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 …

我有一个客户站点，其中包含两个类似配置的 2008r2 SQL Server“A”和“C”。在两台服务器上都启用了跟踪标志 1204 和 1222，并DBCC tracestatus在两台服务器上显示以下内容：

TraceFlag   Status  Global  Session
1204        1       1      0
1222        1       1      0
3605        1       1      0

在 A 上，跟踪标志按预期工作，当发生死锁时，我们会在错误日志中获得 1204 和 1222 死锁报告。但是，在 C 上，仅显示 1204 报告，我们从未得到 1222 报告。

对于我的生活，我看不出这种差异的任何原因。我已经广泛地搜索了这个，并阅读（并重新阅读）了关于这些跟踪标志的 MS 文档，我找不到任何关于此类行为的报告，也没有任何关于可能导致它的原因的提示。唯一接近的是偶尔声称这两个跟踪标志都不起作用，但这些都被证明是在启用命令中有拼写错误的情况。我知道这里不是这种情况，因为我已经使用 DBCC TRACESTATUS 进行了确认。

因此，对于可能导致仅跟踪标志 1222 不起作用和/或如何修复它的任何见解，将不胜感激。

嗯，这是一个有趣的发展。每当我自己生成死锁时（使用此代码：https : //stackoverflow.com/questions/7813321/how-to-deliberately-cause-a-deadlock），我都会在错误日志中得到两个跟踪报告。似乎只是触发死锁报告之一的应用程序每隔几天就会发生一次“自然”死锁。不确定这是否有帮助，是否有任何理由相信跟踪 1222 不会报告与 1204 相同的所有死锁情况？