postgresqlのデータベース整合性チェッカー
PostgreSQLにDBCC（データベース整合性チェッカー）コマンドはありますか？ SQLサーバーのDBCCコマンドは見つかりましたが、Postgresは見つかりませんでしたか？私は、postgresqlにパフォーマンスチューニングの組み込み機能があり、postgresで使用できるDBCCコマンドがないことを読みました。本当ですか？
PostgreSQLには、組み込みの整合性チェックコマンドまたはツールはありません。
一般的な見方では、高品質のハードウェア/ソフトウェアスタックでは破損や不整合が発生する可能性がないため、1つにする必要はありません。問題が発生した場合、何らかの一貫性チェックで問題が検出される保証はないため、誤った安心感が生じるだけです。私はその意見に同意しませんが、これがpgsql-hackersで定期的に議論されているときに出てくるようです。
いつものように、根本的な問題は、当面のニーズを満たすために一貫性チェッカーツールを特に必要としない人がいるため、かゆみを掻くために時間を費やして開発したり、商用契約や社内ベースで開発に資金を提供したりする人がいないことです。ボランティア？ ：p
PostgreSQL（9.3まで）は、ブロックレベルのチェックサムをサポートしていませんでした。そのため、検証に慣れている主なものの1つが存在しないため、検証できませんでした。すべての関係をスキャンしてチェックサムを検証するツールはPostgreSQL 9.3には存在しませんが、追加することが望ましく、将来のバージョンで表示される可能性があります。当面は、各リレーションから_SELECT *_を個別に実行するだけです。ただし、PostgreSQLが読み取りにオペレーティングシステムのバッファキャッシュを使用するため、基盤となるディスクブロックの読み取りを強制する保証はありません。これを行うには、新しいツールが必要になります。
PostgreSQLは可能な限り情報を重複して保存することを避けようとする傾向があるため、多くの場合、単一の信頼できるソースだけをチェックする必要はありません。一貫性チェッカーは、同じ情報が表示されるか、複数の異なる場所から派生する場合を除いて、多くのことはできません。
また、まだビジーでアクティブなデータベースに対して、あらゆる種類の便利なチェックを同時に実行することも非常に困難です。ほとんどのインストールでは、なんらかの整合性チェックを実行するために、データベース全体または少なくともいくつかの主要な関係を一度にロックするつもりはありません。そのため、チェッカーは、同時に変更が加えられるデータベースを操作できる必要があり、書き込みをさらに困難にし、より少ない問題を確実に検出できるようにする必要があります。
バリデータツールが記述されている場合、特に複数のリレーション排他ロックを許可されている場合、バリデータツールでできることはまだたくさんあります。
すべてのテーブルスペースがディスク上に存在することを確認してください。
各_
pg_class_エントリのrelfilenodeに対応するファイルが正しいテーブルスペースにあることを確認します。可視性マップ、フリースペースマップなどを検査して、それらが必要なときに存在し、読み取り可能で、関連付けられている関係と一致しているように見えることを確認します。
孤立したディスク上のファイルノードを報告します。 （これらはトランザクションDDLと遅延リンク解除のために正常ですが、チェッカーは強制的なリンク解除を強制し、チェックを実行する前にすべての関係をロックする可能性があります）。
各関係のすべてのブロックを読み、明らかな問題を探します。次のようなヒープ関係の場合：
xminがxmaxより大きい（xidラップアラウンドを考慮した後）- 将来のトランザクションによって作成されるタプル
- 壊れたHOTチェーン/壊れたctidチェーン
- テーブル属性と一致しないタプル構造
- _
_in_および__out_関数を変更しないか、エラーをスローしない任意のDatum - _
NOT NULL_テーブル属性に設定されたNULLビットマップフィールド CHECK制約の再実行が失敗する
関連するすべてのテーブルをロックした後、外部キーと除外制約を再確認します
...そして、おそらく、ページの破損を検出する試み、Bツリー構造の検証、GINとGistインデックスのサニティチェック、サニティチェック_pg_control_、もっとどこから始めればいいのかわからなかった。
このようなツールを使いたいと思っている場合、最善の方法は、それがどのように機能するかについての具体的な提案を思いつくために十分に学習することです。開発。
個人的には、postgresバックエンド用の特別な起動モードを使用して停止したデータベースクラスターをチェックできるものがあれば非常に嬉しいので、_pg_basebackup_で取得した物理データベースコピーを（ある程度）検証できます、pg_start_backup()、rsyncおよび_pg_stop_backup_、ファイルシステムレベルのアトミックスナップショットなど.
あるいは、ハードウェアとソフトウェアのスタックが堅牢で適切に構成されていることを確認し、適切なバックアップを保持し、ログを監視します。サーバーを稼働させる前にスタック全体を適切にテストすること、および物理（ストリーミング/ PITR）と論理（ダンプ）の両方を適切にバックアップすることに代わるものはありません。信頼できるI/Oサブシステムが実際にあることを確認するために、稼働する前に、読み込まれたデータベースでプラグプルテストを繰り返し実行します。複数の形式のバックアップを使用します。
PgCheck on pgFoundry というプロジェクトがあります。ただし、開発ステータスは「Alpha」です。
最後の活動は2012年の初めでした のようです。
提案されています 他の場所
ほとんどの人は、データベース全体のバキュームを組み合わせて使用するか、各テーブルからselect *を実行します。すなわち。どういうわけかすべての行をスキャン/処理してみてください