标签: dbcc

我们有一个数据库女士

DBCC CHECKDB (MS)

或者

ALTER DATABASE MS SET SINGLE_USER
DBCC CHECKDB(MS,REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE MS SET MULTI_USER

错误信息

Msg 0, Level 11, State 0, Line 0:
当前命令发生严重错误。结果，如果有的话，应该被丢弃。

Msg 0, Level 20, State 0, Line 0:
当前命令发生严重错误。结果，如果有的话，应该被丢弃。

花费数小时测试每张表后，发现有问题的表是“LC”

DBCC CHECKTABLE(LC)

错误信息

消息 211，级别 23，状态 51，第 1 行：
可能的架构损坏。运行 DBCC 检查目录。

现在，

DBCC CHECKCATALOG

信息

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

我也试着看看索引

SELECT * FROM sysindexes

错误信息

消息 211，级别 23，状态 51，第 1 行：
可能的架构损坏。运行 DBCC 检查目录。

Msg 0, Level 20, State 0, Line 0: …

我们有相当多的数据加载进程整天都在运行。这些进程为它们的连接设置 610 标志，然后在完成后将其关闭。因为这些消息被放入了 ERROR LOG，所以我们的 ERROR LOG 增长了很多。我们已经尝试使用 DBCC 的 WITH NO_INFOMSGS 参数，但它仍然将条目放入错误日志中（即使它没有将其放入查询输出中）。

有任何想法吗？

消息如下所示：

日期 10/23/2014 8:32:46 AM 登录 SQL Server（当前 - 2014/10/23 8:31:00 AM）

源 spid57

消息 DBCC TRACEON 610，服务器进程 ID (SPID) 57。这只是一条信息性消息；无需用户操作。

...

日期 10/23/2014 8:32:54 AM Log SQL Server（当前 - 2014/10/23 8:31:00 AM）

源 spid57

消息 DBCC TRACEOFF 610，服务器进程 ID (SPID) 57。这只是一条信息性消息；无需用户操作。

当我在 SQL Server 2008 中修改表时，出现以下错误：

数据库 ID 29，页 (1:235225)，LOB 数据类型节点的插槽 80 不存在。这通常是由可以读取数据页上未提交数据的事务引起的。运行 DBCC 检查表

谁能帮我？

我不得不使用 all_errormsgs 运行 dbcc checkdb repair_allow_data_loss，它已经运行了 27 多个小时。DB 大小超过 15gb，服务器（windows 2008）有 32gb 内存。我确实在 SQL 2005 上运行过它，正如我所说，它已经运行了 27 多个小时。这是正常的吗？如果没有，我可以终止它而不会对数据库造成任何问题吗？我在运行之前确实做了备份。

可能是一个快速的问题。

我们希望在我们的环境中测试几个跟踪标志作为启动参数，虽然我知道我们可以DBCC TRACESTATUS用来获取全局范围的跟踪标志，但它没有指定这是在启动时设置还是仅使用 -1 设置旗帜。解析 SQL 错误日志是唯一可用的方法吗？可能是某个地方的注册表项？

任何可以以编程方式解决的方法都是有用的。

谢谢阅读！

Microsoft SQL Server 2017 (RTM-CU14-GDR) (KB4494352) - 14.0.3103.1 (X64) 2019 年 3 月 22 日 22:33:11 版权所有 (C) 2017 Microsoft Corporation Developer Edition（64 位），Windows Server 2016（数据中心 10.0）内部版本 14393：）（管理程序）

我的生产服务器在 SQL 代理作业中执行这些命令以将结果输出到我的管理数据库中的表：

DECLARE @SQL VARCHAR(MAX) = 'master..xp_cmdshell ''SQLCMD -E -Q"DBCC CHECKDB('+@Database+') WITH NO_INFOMSGS, ALL_ERRORMSGS"'''; -- If all is well, there will be no output.
INSERT INTO DBCC_CHECKDB_Results EXEC(@SQL);

昨晚，输出一行信息，作业停止执行，作业历史记录中没有显示错误。一行信息是：

“Sqlcmd：警告：上次操作已终止，因为用户按下了 CTRL+C。”

这怎么可能？周日晚上 10:00，没有人登录到服务器。CTRL+C不在命令行中。

作为测试，我执行了此命令，并在执行时键入CTRL+C：：

USE ARC 
DBCC CHECKDB WITH NO_INFOMSGS, ALL_ERRORMSGS:
Nothing happened. 

关于什么会导致该输出行的任何想法？

谢谢，李

我一直在使用 DBCC Traceon (3502, 3504, 3605, -1) 因为它在博客中被推荐用于发现与 I/O 相关的性能问题。我正在运行 MS SQL Server 2008 R2 SP1

我的 SQL 日志文件中的结果看起来像这样（数字有点模糊）：

即将记录检查点结束

最后一个目标未完成 2，avgWriteLatency 40ms

平均吞吐量：0.67 MB/秒，I/O 饱和度：79，上下文切换 201

FlushCache：在 1447 毫秒内清理了 69 次写入的 125 个缓冲区（避免了 0 个新的脏缓冲区）

ckpt dbid 9 第一阶段结束 (8)

即将登录检查点开始。

我真的不知道如何阅读这篇文章，或者以一种我从中得到任何真正有意义的东西的方式来分解它。

“最后一个目标未完成”是什么意思？

平均写入延迟是否意味着每次写入所需的开销时间？或写入之间的时间？40ms 似乎很高，物理驱动器是 1TB，并且是 RAID5 配置。

什么是 I/O 饱和？

它与上下文切换有什么关系。我假设上下文切换与多任务处理有关。在作业/写入之间切换。

刷新缓存。我意识到这与清除缓存有关。什么是Buf？这些数据页是需要写入的吗？什么是肮脏的 Buf？为什么要避免它们？

详细的分解将不胜感激。

我正在尝试使用以下查询获取 SQL2008 R2 DEV 框中 table1 上的聚集索引使用的页面。

dbcc traceon(3604, -1) 
go 
dbcc ind (0, 'dbo.table1', 1) 
go

但它仍然显示以下输出并且不显示结果。我在这里做错了什么？

以下消息也记录在 SQL 服务器日志中

消息 DBCC TRACEON 3604，服务器进程 ID (SPID) 59。这只是一条信息性消息；无需用户操作。

我有一堆 SQL 2005 数据库，它们已经存在了很长时间，并且由于各种原因经历了事务日志自动增长。定期备份现在可以控制事务日志的使用，但文件仍然很大且碎片化。

我想通过减少 VLF 的数量来回收一些空间并提高性能。但是，我也不想中断我们的预定备份。DBCC SHRINKFILE() 如何影响事务日志备份链？或者是吗？如果我将 TRUNCATEONLY 添加到命令中，这会改变吗？

请注意，这是一次性修复。我很清楚，定期缩小日志文件是一件坏事——如果这些数据库配置了合理的初始大小和自动增长设置，并且备份在其历史记录的每一天都完美运行，这将不是问题。

我们在 SQL Server 2008 数据库上启用了一种方式的事务复制。由于一些问题，我们不得不运行DBCC checkDB，将数据库带入单用户模式。当我们完成DBCC活动并再次启用复制时，复制将不起作用。我们必须再次初始化快照才能使复制工作。

你能帮我理解为什么复制在这种情况下会中断吗？我理解DBCC删除表中的一些行和索引，但根据我的理解，当我们启用复制时，这些更改应该传播给订阅者而不会出现任何问题。

当我与我的高级团队成员核对时，我被告知这是由于 LSN 不匹配，但我无法从逻辑上理解。

任何帮助深表感谢。