タグ付けされた質問 「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エラーが報告されていません。 また、CHECKTABLECIのサイズは30 MBで、約3万行ありますが、このテーブルには45分かかります。そのテーブルのすべてのデータはポイント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, …

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

トランザクションログファイルが（SQL Serverがシャットダウンされている間に）削除された非常に大きなデータベース（〜6TB）があります。 データベースの切り離しと再接続。そして トランザクションログファイルの削除の取り消し ...しかし、これまでのところ何も機能していません。 現在実行中です： 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は、データベースの1つ（特に、インメモリOLTPテーブルを使用するデータベース）をチェックするときに、ユーザーデータベースのトランザクションログファイルを読み取っているようです。 このデータベースのCHECKDBはまだ妥当な時間内に終了するため、ほとんどの場合、動作に興味があります。ただし、このインスタンス上のすべてのデータベースのCHECKDBの期間は間違いなく最長です。 Paul Randalの叙事詩「あらゆる角度からのCHECKDB：すべてのCHECKDBステージの完全な説明」を見ると、データベースの一貫性のあるビューを取得するために、SQL 2005より前のCHECKDB がログを読み取っていたことがわかります。ただし、これは2016年なので、内部データベーススナップショットを使用します。 ただし、スナップショットの前提条件の 1つは次のとおりです。 ソースデータベースに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 …

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、テキストID 6370769764352の行外データノードは、ページ（0：0）、スロット0で参照されますが、スキャンでは表示されませんでした。 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 バックアップ 'MyDatabase'は、ファイル 'F：\ Data \ MyDatabase_1.ndf'のページ（1：745345）でエラーを検出しました。 メッセージ3013、レベル16、状態1、行8 BACKUP DATABASEが異常終了しています。 完全なCHECKDBを実行しましたが、正常に戻りました。ページ検証オプションが（自分ではなく）NONEに設定されていることに気付いたので、それをCHECKSUMに変更し、DB内のすべてのインデックスを再構築して、すべてのページに書き込み、チェックサムを生成しました。この後もバックアップは失敗し、checkdbはまだクリーン（変更がない）を示しています。 DBCC CHECKDB('MyDatabase') WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY, EXTENDED_LOGICAL_CHECKS; SQLログから： DBCC CHECKDB（MyDatabase）with all_errormsgs、no_infomsgs、xxxによって実行されたdata_purityは0エラーを検出し、0エラーを修復しました。経過時間：0時間21分46秒。内部データベースのスナップショットには、分割ポイントLSN = 000ab776：0000112f：0001と最初のLSN = 000ab776：0000112d：0001があります。 DBCC PAGEを実行しましたが、エラーが発生しました（そもそも正しいページが返されていないようです）。印刷オプション2で実行できますが、戻りますが、正直なところ、何を探しているのかわかりません。 DBCC PAGE ('MyDatabase',1,745345,3) ページ：（3：513793） バッファ： …

12 sql-server  corruption  dbcc-checkdb 

Paul Randal がDBCC CHECKDBを手動で数日間に渡って分散する、非常に大規模なデータベースの実装に取り​​組んでいます。 データベース内のテーブルを7つのバケット間でほぼ均等に分割する 週2回のDBCC CHECKALLOCの実行 週に1回、DBCC CHECKCATALOGを実行する 曜日ごとに1つのバケットでDBCC CHECKTABLEを実行する 誰かがこのテクニックを使用しましたか？既存のスクリプトはありますか？ これが実際にCHECKDBが行うすべてをカバーしていないのではないかと心配しています。CHECKDBのBooks Onlineドキュメントでは、CHECKALLOC、CHECKCATALOG、およびCHECKTABLEに加えて、次のことも述べられています。 データベース内のすべてのインデックス付きビューの内容を検証します。 FILESTREAMを使用してファイルシステムにvarbinary（max）データを格納するときに、テーブルメタデータとファイルシステムディレクトリおよびファイルの間のリンクレベルの整合性を検証します。（SQL 2008のみ） データベース内のService Brokerデータを検証します。 だからここに私の質問があります： これらの追加のチェックは必要ですか/重要ですか？（インデックス付きビューは、おそらく私にとっては少し心配です。まだService BrokerやFILESTREAMを使用しているとは思いません。） もしそうなら、これらの追加のチェックを個別に実行する方法はありますか？ CHECKALLOCとCHECKCATALOGは、大きなdbでも非常に高速に実行されるようです。これらを毎日実行しない理由はありますか？ （注：これは、数百のサーバーにわたる数千の既存のデータベース、または少なくとも特定のサイズを超えるすべてのデータベースの標準ルーチンになります。つまり、CHECKFILEGROUPを使用するようにすべてのデータベースを再構築するようなオプションは、実際には実用的ではありません。）

10 sql-server  dbcc-checkdb  vldb 

SQL Serverの1つが最近次のエラーを報告しました： 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 ? 2番目の質問は、「buffer cache hit ratio」がDBCC CheckDB完了後に変更されなかった理由です。 データベースのデータをストレージからRAMに再度読み込む必要があるため、平均して99.99％で、DBCC CheckDBジョブ終了後は約98.00％に低下し、99％にかなり速くbuffer cache hit ratio戻ります。

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