Questions tagged «dbcc-checkdb»

我有一个空间索引用于该DBCC CHECKDB报告损坏： DBCC CHECKDB(MyDB) WITH EXTENDED_LOGICAL_CHECKS, DATA_PURITY, NO_INFOMSGS, ALL_ERRORMSGS, TABLERESULTS 空间索引，XML索引或索引视图'sys.extended_index_xxx_384000'（对象ID xxx）不包含视图定义生成的所有行。这不一定代表此数据库中数据的完整性问题。 空间索引，XML索引或索引视图'sys.extended_index_xxx_384000'（对象ID xxx）包含视图定义未生成的行。这不一定代表此数据库中数据的完整性问题。 CHECKDB在表'sys.extended_index_xxx_384000'（对象ID xxx）中发现了0个分配错误和2个一致性错误。 维修等级为repair_rebuild。 删除并重新创建索引不会删除这些损坏报告。没有EXTENDED_LOGICAL_CHECKS但没有DATA_PURITY错误，则不会报告。 同样，CHECKTABLE此表花费45分钟，尽管它的CI大小为30 MB，大约有3万行。该表中的所有数据都是点geography数据。 在任何情况下都可以预期这种行为吗？它说：“这不一定代表完整性问题”。我应该做些什么？CHECKDB失败了，这是一个问题。 此脚本重现了该问题： CREATE TABLE dbo.Cities( ID int NOT NULL, Position geography NULL, CONSTRAINT PK_Cities PRIMARY KEY CLUSTERED ( ID ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, …

23 sql-server  sql-server-2014  spatial  dbcc-checkdb 

我们有一个非常大的数据库（〜6TB），该数据库的事务日志文件已删除（在SQL Server关闭的同时，我们已经尝试过： 分离并重新附加数据库；和 删除事务日志文件 ...但是到目前为止没有任何效果。 我们目前正在运行： ALTER DATABASE <dbname> REBUILD LOG ON (NAME=<dbname>,FILENAME='<logfilepath>') ...但是鉴于数据库的大小，这可能需要几天才能完成。 问题 上面的命令与下面的命令有区别吗？ DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS) 我们应该REPAIR_ALLOW_DATA_LOSS代替执行吗？ 值得注意的是，数据是从其他来源派生的，因此可以重建数据库，但是我们怀疑，与重新插入所有数据相比，修复数据库要快得多。 更新资料 对于那些得分较高的用户：该ALTER DATABASE/REBUILD LOG命令在36小时后完成并报告： 警告：数据库“ dbname”的日志已重建。事务一致性已丢失。RESTORE链已损坏，并且服务器不再在先前的日志文件上具有上下文，因此您将需要知道它们是什么。 您应该运行DBCC CHECKDB来验证物理一致性。数据库已置于仅dbo模式。当准备好使数据库可用时，您将需要重置数据库选项并删除所有额外的日志文件。 然后，我们运行了一个DBCC CHECKDB（花了大约13个小时），这是成功的。可以说，我们都已经了解了数据库备份的重要性（并授予项目经理对服务器的访问权限...）。

20 sql-server  sql-server-2005  recovery  dbcc-checkdb 

tl; dr：为什么CHECKDB读取具有内存优化表的用户数据库的事务日志？ 似乎CHECKDB在检查我的一个数据库-特别是使用内存中OLTP表的数据库时，正在读取用户数据库的事务日志文件。 该数据库的CHECKDB仍会在相当长的时间内完成，因此我主要是对行为感到好奇。但绝对是此实例上所有数据库中CHECKDB的最长持续时间。 从Paul Randal的史诗《从各个角度看CHECKDB：完整描述所有CHECKDB阶段》中，我看到SQL 2005以前的CHECKDB 用于读取日志，以便获得数据库的一致视图。但是由于这是2016年，因此它使用内部数据库快照。 但是，快照的先决条件之一是： 源数据库不得包含MEMORY_OPTIMIZED_DATA文件组 我的用户数据库具有这些文件组之一，因此看起来快照不在桌面上。 根据CHECKDB文档： 如果无法创建快照，或者指定了TABLOCK，则DBCC CHECKDB将获取锁以获取所需的一致性。在这种情况下，需要排他数据库锁来执行分配检查，并且需要共享表锁来执行表检查。 好的，所以我们正在执行数据库和表锁定而不是快照锁定。但这仍然不能解释为什么它必须读取事务日志。那有什么呢？ 我在下面提供了一个脚本来重现该场景。它用于sys.dm_io_virtual_file_stats标识日志文件读取。 请注意，大多数情况下，它读取日志的一小部分（480 KB），但偶尔读取的日志则更多（48.2 MB）。在我的生产场景中，当我们运行CHECKDB时，它每天晚上在午夜读取大多数日志文件（约占2 GB文件的1.3 GB）。 这是到目前为止我通过脚本获得的输出示例： collection_time num_of_reads num_of_bytes_read 2018-04-04 15:12:29.203 106 50545664 或这个： collection_time num_of_reads num_of_bytes_read 2018-04-04 15:25:14.227 1 491520 如果我用常规表替换内存优化的对象，则输出如下所示： collection_time num_of_reads num_of_bytes_read 2018-04-04 15:21:03.207 0 0 为什么CHECKDB读取日志文件？尤其是为什么它偶尔会读取日志文件的很大一部分？ 这是实际的脚本： -- let's have …

16 sql-server  sql-server-2016  transaction-log  dbcc-checkdb 

如果文件组包含列存储索引，则似乎设置了文件组以read_only防止dbcc checkdb整个数据库使用。尝试运行checkdb或checkfilegroup（对于数据库中的任何文件组，包括读写辅助文件和[PRIMARY]）时，返回以下错误... Msg 8921, Level 16, State 1, Line 24 Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors. 是否存在将列存储数据存储在只读文件组中的受支持方法？还是在这种情况下无法进行完整性检查？ 复制 create database check_fg_ro go use check_fg_ro go exec sp_changedbowner 'sa'; go alter database check_fg_ro add …

15 sql-server  dbcc-checkdb  columnstore  filegroups  read-only-database 

TL; DR：我在索引视图中有无法修复的损坏。详细信息如下： 跑步 DBCC CHECKDB([DbName]) WITH EXTENDED_LOGICAL_CHECKS, DATA_PURITY, NO_INFOMSGS, ALL_ERRORMSGS 在我的一个数据库上产生以下错误： 消息8907，级别16，状态1，第1行空间索引，XML索引或索引视图“ ViewName”（对象ID 784109934）包含视图定义未生成的行。这不一定表示此数据库中数据的完整性问题。（...） CHECKDB在表'ViewName'中发现0个分配错误和1个一致性错误。 repair_rebuild是最低修复级别（...）。 我确实知道，该消息表明索引视图“ ViewName”的物化数据与基础查询生成的数据不同。但是，手动验证数据不会出现任何差异： SELECT * FROM ViewName WITH (NOEXPAND) EXCEPT SELECT ... from T1 WITH (FORCESCAN) join T2 on ... SELECT ... from T1 WITH (FORCESCAN) join T2 on ... EXCEPT SELECT * FROM ViewName …

14 sql-server  corruption  materialized-view  dbcc-checkdb 

我正在执行带有physical_only选项的checkdb，并且失败，并显示以下多个错误： 消息8965，级别16，状态1，第1行 表错误：对象ID 1557580587，索引ID 1，分区ID 72057594088456192，分配单元ID 72057594177454080（类型为行内数据）。页面（1：13282192），插槽3，文本ID 6370769698816的行外数据节点由页面（0：0），插槽0引用，但未在扫描中看到。消息8965，级别16，状态1，第1行 表错误：对象ID 1557580587，索引ID 1，分区ID 72057594088456192，分配单元ID 72057594177454080（类型为行内数据）。页面（1：13282192）插槽5的行外数据节点由页面（0：0）插槽0引用文本ID 6370769764352，但在扫描中未看到。 CHECKDB在表'TableX'（对象ID 1557580587）中发现了0个分配错误和5255个一致性错误。CHECKDB在数据库'DatabaseX'中发现0个分配错误和5255个一致性错误。repair_allow_data_loss是DBCC CHECKDB（DWH_LAND）发现的错误的最低修复级别。 但是完整的checkdb是成功的： CHECKDB在数据库'DatabaseX'中发现0个分配错误和0个一致性错误。DBCC执行完成。如果DBCC打印了错误消息，请与系统管理员联系。 TableX大约有20万行，并在其上具有群集的列存储索引。 我们正在使用以下版本的SQL Server： Microsoft SQL Server 2017（RTM-CU13）（KB4466404）-14.0.3048.4 我应该担心吗？

13 sql-server  sql-server-2017  dbcc-checkdb 

我有一个数据库，在其中运行备份命令 BACKUP DATABASE [MyDatabase] TO DISK = 'G:\Backup\MyDatabase_01_01_2018.bak' WITH NOFORMAT, NOSKIP, COMPRESSION, INIT, BUFFERCOUNT = 100 我收到错误消息 消息3043，级别16，状态1，第8行 BACKUP'MyDatabase'在文件'F：\ Data \ MyDatabase_1.ndf'中的页面（1：745345）中检测到错误。 消息3013，级别16，状态1，第8行 BACKUP DATABASE异常终止。 我运行了一个完整的CHECKDB，但恢复正常。我确实注意到页面验证选项已设置为NONE（不是我的工作），所以我将其更改为CHECKSUM并重建了数据库中的所有索引，使其可以写入所有页面并生成校验和。此后，备份仍然失败，并且checkdb仍显示为干净（因此无更改）。 DBCC CHECKDB('MyDatabase') WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY, EXTENDED_LOGICAL_CHECKS; 从SQL日志中： 由xxx执行的具有all_errormsgs，no_infomsgs和data_purity的DBCC CHECKDB（MyDatabase）发现0个错误，并修复了0个错误。经过时间：0小时21分46秒。内部数据库快照的拆分点LSN = 000ab776：0000112f：0001和第一个LSN = 000ab776：0000112d：0001。 我运行了DBCC PAGE，但是它出错了（起初似乎都没有返回正确的页面）。我可以使用打印选项2运行它，但它会返回，但说实话我不知道我在那儿寻找什么。 DBCC PAGE ('MyDatabase',1,745345,3) 页面：（3：513793） 缓冲： BUF @ 0x00000003811F8280 …

12 sql-server  corruption  dbcc-checkdb 

我正在实施Paul Randal的方法，以针对大型数据库在几天内手动分布DBCC CHECKDB，该方法主要包括： 在7个存储桶之间大致平均地划分数据库中的表 每周运行一次DBCC CHECKALLOC 每周运行一次DBCC CHECKCATALOG 每周每天在一个存储桶上运行DBCC CHECKTABLE 有人使用过这种技术吗？有没有现有的脚本？ 我担心这可能无法涵盖CHECKDB所做的一切；CHECKDB的联机丛书文档说，除了CHECKALLOC，CHECKCATALOG和CHECKTABLE外，它还： 验证数据库中每个索引视图的内容。 使用FILESTREAM将varbinary（max）数据存储在文件系统中时，验证表元数据与文件系统目录和文件之间的链接级一致性。（仅适用于SQL 2008） 验证数据库中的Service Broker数据。 所以这是我的问题： 这些额外检查是否必要/重要？（索引视图可能与我有关，我认为我们还没有使用Service Broker或FILESTREAM。） 如果是这样，是否有办法分别执行这些附加检查？ CHECKALLOC和CHECKCATALOG似乎运行非常快，即使在大型数据库上也是如此。有什么理由不每天运行这些？ （注意：这将是数百个服务器中成千上万个现有数据库的标准例程，或者至少是一定规模的每个数据库的标准例程。这意味着诸如重组所有数据库以使用CHECKFILEGROUP之类的选项对我们而言并不实际。）

10 sql-server  dbcc-checkdb  vldb 

我们的SQL Server之一最近报告了以下错误： DATE/TIME: 2/25/2013 9:15:14 PM DESCRIPTION: No catalog entry found for partition ID 9079262474267394048 in database 2. The metadata is inconsistent. Run DBCC CHECKDB to check for a metadata corruption. 不到15分钟后，我连接到服务器并运行： SELECT name FROM sys.databases WHERE database_id = 2; 哪个返回'tempdb'。然后我跑了： DBCC CHECKDB ('tempdb') WITH NO_INFOMSGS, TABLERESULTS; 其中未返回任何结果，表明受影响的数据库没有问题。 数据库中的损坏如何导致上面的错误消息而又DBCC CHECKDB未报告问题？我假设页面校验和计算失败，导致该页面被标记为怀疑无法引用该页面的任何对象，但是我一定是错误的。 …

9 sql-server  sql-server-2012  tempdb  dbcc-checkdb 

我们一直在监视一些SQLServer: Memory Manager指标，并注意到DBCC CheckDB工作后指标 Database Cache Memory (KB) 下降明显。确切地说，它从140 GB缓存的DB内存降至60 GB。之后，请在一周内慢慢增加速度。（“ Free Memory KB”的数量从之后的20 GB变为100 GB CheckDB） DBCC CheckDB 在每个星期日运行，因此数据库高速缓存内存必须每周再次增加 What is the behavior of this ? Why CheckDB pushes database pages out of memory ? 第二个问题是为什么“ buffer cache hit ratio” DBCC CheckDB完成后没有变化？ 它平均为99.99％，而在DBCC CheckDB工作后下降至〜98.00％，并很快恢复至99％，而我预计buffer cache hit ratio会大幅下降，因为数据库数据必须再次从存储读取到RAM？

8 sql-server  sql-server-2017  dbcc-checkdb  buffer-pool  performance-monitor