问题标签 [dbcc]

我正在寻找创建一个监控工具来跟踪我们维护的生产服务器上事务日志使用的变化。

以前，我使用DBCC SQLPERF(LOGSPACE);了 ，它提供了所有数据库及其当前事务日志内存状态的列表。但是，Microsoft 似乎建议从 2012 年开始，应该从 中查看日志详细信息sys.dm_db_log_space_usage，它提供了类似的详细信息，但似乎是特定于数据库的，而不是提供整个服务器的视图（即您必须连接到您希望的数据库采用）。

https://docs.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-sqlperf-transact-sql?view=sql-server-ver15

我想我的问题有两个方面：

1. 有没有办法sys.dm_db_log_space_usage用于所有数据库？
2. 有什么理由DBCC SQLPERF(LOGSPACE);不应该使用？

Am trying to find if there's any equivalent option DBCC SHRINKFILE T-SQL command for the option "Reorganize pages before releasing unused space" that is seen when performing through SSMS.

The usual TRUNCATEONLY/TargetSize options does reduce the file size but does it implicitly reorganise the pages also? Because no explanation is provided in the BOL - https://docs.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-shrinkfile-transact-sql?view=sql-server-ver15

--In 'thoughts'...

当我运行选择查询时，我收到错误：

消息 605，级别 21，状态 3，第 1 行尝试获取数据库 5 中的逻辑页 (1:XXXXXXX) 失败。它属于分配单元 XXXXXXXXXXX 不属于 XXXXXXXXXXXXX。

我试过运行查询DBCC CheckDB。C：查询完成前驱动器几乎已满，因此查询未完成且未出错。

我没有数据库备份。我该如何解决这个错误。

请协助，在我的生产服务器上运行 DBCC checkdb() 时出现以下错误。

消息 8921，级别 16，状态 1，线路 1 检查已终止。收集事实时检测到故障。可能是 tempdb 空间不足或系统表不一致。检查以前的错误。

我还用estimateonly执行了Dbcc checkalloc('DBname')，但这也给出了以下消息

消息 0，级别 11，状态 0，行 0 当前命令发生严重错误。结果，如果有的话，应该丢弃。

然后我还使用 no_infomsgs, all_errormsgs 执行了 Dbcc checkalloc('DBname') 这也给出了以下错误消息

消息 8921，级别 16，状态 1，线路 1 检查已终止。收集事实时检测到故障。可能是 tempdb 空间不足或系统表不一致。检查以前的错误。

这是 SQL Server 2008 R2。

有人可以帮助我解决上述问题。

我正在运行以下查询来缩小数据库的日志文件。

我担心的是，即使缩小失败，查询也会运行而不会出现任何错误。消息选项卡中只会显示一条消息。而且这个错误也不能通过错误处理来捕获。

无法收缩日志文件 2 ()，因为请求的大小 () 大于最后一个逻辑日志文件的开头。

（1 行受影响）

DBCC 执行完成。如果 DBCC 打印错误消息，请联系您的系统管理员。

在此处输入图像描述

我有大约 200 个数据库来压缩文件，并且我编写了一个脚本来一次压缩所有文件。但是滚动消息选项卡并找到所有失败的文件非常困难。

那么，是否有任何选项可以从消息选项卡中捕获内容并插入到表格中？或者有没有办法处理这种错误？

我有一台运行 SQL Server 2019 的服务器，但数据库仍在运行Compatibility level 110（这意味着基本上是 SQL Server 2012）。

我们每晚都进行一次完整备份，我确实每天都看到文件备份在正确的文件夹中。但是，如果我运行此查询，并添加backup_finish_date desc以检查上次完整备份的时间，我会看到日期是几个月前：

所以我发现这个指南说它可能是 SQL Server 中的一个错误，并要求运行这个检查：

“...在结果中，请注意 database_backup_lsn 列和 is_snapshot 列。表示实际数据库备份操作的条目具有以下特征： database_backup_lsn 列的值不是 0。is_snapshot 列的值是 0。 "

database_backup_lsn column is not 0对我来说一切都很好，它看起来像is_snapshot column is 0

然后指南说运行这个查询来验证备份的完整性：

结果什么都没有！

指南说：“......如果此查询返回任何结果，则表示您在报告日期之后没有良好的数据库备份。”

所以现在我害怕我们的备份被搞砸了。我们进行备份，CHECKSUM但我们已经很久没有运行DBCC CHECKDB了，所以我们可能（成功并使用CHECKSUM）对损坏的数据库进行备份。让我们运行：

结果什么都没有，所以看起来一切都很好。

同时日志文件（155GB）的大小与514GB的数据文件大小相比显得异常大

编辑：

我每天晚上进行完整备份，每小时进行一次日志备份

编辑2：

Brent Ozar 建议跑步SELECT name, log_reuse_wait_desc FROM sys.databases;，结果我NOTHING几乎无处不在：

这是我的功能：

1. 我想使用 DBCC CHECKDB 检查所有数据库但收到此错误：

   为什么 DBCC CHECK DB 不能与 executeQuery() 一起使用，我该如何解决？

2. 因此，如果我已经从 stmt.executeQuery() 获得了 ResultSet，我如何将这个结果读取为行或字符串？我想看看有多少错误。谢谢你。

当我在 SQL Server 2016 中运行带有 TABLERESULTS、ALL_INDEXES、NO_INFOMSGS 的 DBCC SHOWCONTIG ('schema_name.table_name') 时，它会针对某些表返回 2 行

下面的例子：

我无法理解这种行为的原因，因为理想情况下它应该只返回 1 行，有人可以提供什么吗？

我正在编写一个 C# 程序，它需要读取 SQL Server 数据页。现在我正在做的是使用 SQL Server 的DBCC PAGE命令来获取这些信息，然后解析结果。当页码很大时，性能不是很好。我想知道是否有任何 .NET API 允许我读取 SQL Server 数据页？我搜索了 SQL Server 的 SMO 文档，但没有发现任何有趣的东西。

我有一个数据库，当我启动操作时，我想缩小它以恢复磁盘空间，它在进度状态为 76% 的情况下卡住了近 5 个小时，并且它不知道谁知道它为什么会阻塞

在此处输入图像描述