タグ付けされた質問 「corruption」

この質問は、データベース管理者のStack Exchangeで回答できるため、Server Faultから移行されました。 2年前に移行され ました。 エラー 無効なタイムスタンプを含むタプルを削除しようとしています DELETE FROM comments WHERE date > '1 Jan 9999' OR date < '1 Jan 2000' OR date_found > '1 Jan 9999' OR date_found < '1 Jan 2000'; で終わる ERROR: attempted to delete invisible tuple 2009年には、OPで修正されたまったく同じエラーメッセージについて議論するメーリングリストがありますが、彼がそれをどのようにしたのか、またはこのエラーにつながったのかについての説明はありません。 Googleでヒットがなく、PostgreSQLの知識が限られているため、私は無力です。 腐敗の原因 OSカーネルがパニックになったときに、おそらくスワップが配置されている/ dev / md1を再構築しているときに、Debian 8で実行しているPostgreSQL 9.5.5サーバー（メモリ制限の上限を除くすべてのデフォルト設定）を実行しました。それ以前は、PostgreSQLは400GBのログファイルでほとんどすべてのディスク領域を使い果たしました。OSは二度と起動しなかったので、ディスクチェックは問題ありませんでした。念のため、LiveCDから起動し、各ブロックデバイスをイメージにバックアップしました。/ …

25 postgresql  recovery  corruption  postgresql-9.5  disaster-recovery 

マシンが突然シャットダウンすると、MySQL v5.1.61リレーが破損しました。修正しようとしましたが、うまくいきませんでした。 —どうすれば修正できますか？私は何か間違ったことをしましたか？ 私が読んだ限り、破損したMySQLリレーログは簡単に修正されます。 change master to master_log_file='<Relay_Master_Log_File>', master_log_pos=<Exec_Master_Log_Pos>; どこRelay_Master_Log_FileでExec_Master_Log_Posリストは次のとおりです。 mysql> show slave status; しかし、私がやったとき change master status ...そうすると、プライマリキー違反エラーが発生しました。そんなことがあるものか？上記の手順は正しくありませんか？ （今のところ、マスターからスレーブに--master-data mysqldumpを再インポートするだけで問題は解決しました。しかし、将来的には、これを行うのは適切ではないかもしれません。） ここに私の特定の問題に関する詳細が続きます： mysql> show slave status \G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: the-master-host Master_User: replication Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000021 Read_Master_Log_Pos: 33639968 …

25 mysql  replication  corruption 

この質問は、この以前の投稿と、次のように復元された将来の調査のためにデータベースを提出したことによって促されました。 BACKUP 'BrokenDatabase' detected an error on page (1:123456) in file ’BrokenDatabase.mdf'. Error: 3043, Severity: 16, State: 1. リンクされた質問とDBCC PAGE調査の準備ができているバックアップでは、DBCC CHECKDBはエラーなしで合格しましたが、破損が明らかに存在します。 CHECKDBはパスするがBACKUP WITH CHECKSUMは失敗することにより、どのような種類の破損が発生する可能性がありますか？

16 sql-server-2008  sql-server-2005  dbcc  corruption 

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 

SQL Server 2017（CU3）では、TDEデータベースの1つでバックアップ圧縮を有効にすると、バックアッププロセスによってデータベースの特定のページが常に破損します。圧縮せずにバックアップを実行しても、破損しません。この問題を確認して再現するために行った手順は次のとおりです。 データベース「TDE_DB1」でDBCC CheckDBを実行します。すべてが良好で、エラーはありません。 圧縮せずにデータベースを正常にバックアップします。RESTORE VERIFYONLYはすべてが良いと言っています。 データベースを「TDE_DB2」として正常に復元します。すべて良好で、DBCC CheckDBはエラーを表示しません。 「TDE_DB1」データベースを圧縮して正常にバックアップします。「バックアップセットへの損傷が検出されました」と言うVERIFYONLYエラーを復元します。 データベースを「TDE_DB2」として復元しようとします。「データベースでページ（1：92454）でエラーが検出されました」というエラー 手順1〜3を繰り返します。すべてが良いです; DROP "TDE_DB1"および "TDE_DB2"; バックアップから「TDE_DB1」を復元します。すべてが良いです; 手順1〜5を繰り返します。同じ結果が得られます。 要約すると、データベースと通常のバックアップは正常に見え、データベースでCHECKDBを実行し、バックアップでVERIFYONLYを実行してもエラーは報告されません。圧縮を使用してデータベースをバックアップすると、破損が発生するようです。 以下にエラーのあるコードサンプルを示します。（注：TDEデータベースで圧縮を使用するには、MAXTRANSFERSIZEが必要です） -- Good, completes with no corruption; BACKUP DATABASE [TDE_DB1] TO DISK = N'E:\MSSQL\Backup\TDE_DB1a.bak' WITH CHECKSUM; RESTORE VERIFYONLY FROM DISK = N'E:\MSSQL\Backup\TDE_DB1a.bak' WITH CHECKSUM; RESTORE DATABASE [TDE_DB2] FROM DISK = 'E:\MSSQL\Backup\TDE_DB1a.bak' WITH …

13 sql-server  corruption  transparent-data-encryption  sql-server-2017 

PostgreSQLデータベースシステムを実行している場合、データベース全体の整合性が100％であることをどのように知ることができますか？基本的に、破損していないデータファイルとページがすべて100％良好であるかどうかを知るにはどうすればよいですか？ Microsoft SQL Serverの世界には、問題があるかどうかを通知するDBCC CHECKDBを実行できるコマンドがあります。コマンドの詳細を知りたい場合は、次のリンクをご覧ください。DBCC CHECKDB（Transact-SQL） 私は妄想的なデータベース整合性を重視している人であり（DBAタイプの役割でデータベースを操作する人なら誰でもそうするべきです）、この種のことは夜によく眠れないようにします。このようなユーティリティは必須です！グーグルでの検索では、このようなツールでいくつかの試みが見つかりましたが、PostgreSQLプロジェクトで公式に承認されたツールでない限り、私はこの重要なものを信用しません。 ここに、私が本当の決定的な答えとは思わないもので、同様の質問をする人々へのいくつかのリンクがあります。そして私の意見では、PostgreSQLはOracleとMicrosoft SQL Serverが持っているように見えるいくつかのツールを用意する必要があることを示しています。 最初のリンクは、このテーマで見つけた最も興味深いものです。おそらくそれを要約する記事へのコメントは、「Postgresはデータベースの破損を特定して修復するのはかなり不自由です。それを検出する唯一の方法は、データベースをダンプするか、データベース内のすべてのテーブルから*を選択することです」 」 PostgreSQLが部分的なページ書き込みとデータ破損から保護する方法 データとインデックスファイルの破損の確認-Dev Shed ヘルプ：テーブルが壊れています！ PostgreSQL：破損した主キー、一貫性のないテーブル 9.3にはいくつかの破損チェック機能がある可能性があると思います。必要に応じて、ページファイルのチェックを合計することを希望する可能性があります。そのため、ZFSやPostgresの将来のバージョンでページチェックサミングを使用することを検討している場合、状況は明るいように見えます。 https://commitfest.postgresql.org/action/patch_view?id=759 更新：2012年1月14日-ZFSに基づくファイルシステムを使用すると、データの各ブロックを合計してチェックすることで破損を検出できるようです。私はこれをさらに調べ、これがデータベースデータが静かに破損していないことを知って夜寝るのを可能にする回避策であるかどうかを確認する必要があります。 更新：2012年1月17日-ZFSで破損しているファイルを見つける方法。http://docs.oracle.com/cd/E18752_01/html/819-5461/gbbwl.html#gbcuz 更新：2014年4月14日9.3でデータチェックサムが取得されました。https://wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9.3

12 postgresql  maintenance  corruption 

バックアップコマンドを実行したときにデータベースがある 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 

を実行しDBCC CHECKDBてデータベースのステータスを取得できることはわかっています。 ご質問 データベースに破損したデータページがあるかどうかを確認するにはどうすればよいですか？ ページの破損が原因でエラーが発生した場合、破損しているページはどこにありますか？ 破損した各ページのページ番号を確認するにはどうすればよいですか。 誰かがそれらのページIDの場所を教えてもらえますか？

11 sql-server-2008  corruption 

助けて！マスターデータベースが破損しています。SQLインスタンスをオンラインにすることもできません。サーバーをバックアップするためのオプションは何ですか？ マスターのバックアップはありますが、MSDNページの「Restoring the master Database」で、インスタンスをシングルユーザーモードで起動するように求められますが、それはできません！ （注：この質問は、SQLバージョンに関しては未指定のままにしておきます。これは、より広く適用できる参照となるようにするためです。DBA.SEにも同様の質問がいくつかありますが、サーバーが起動できないことに関する質問はありません。）

11 sql-server  corruption  master-system-database 

SqlExceptionストアドプロシージャを呼び出すと、次のようになります。 データベース2の論理ページ（5：65424）をフェッチしようとして失敗しました。これは、4899918190390149120ではなく、アロケーションユニット7349876362857938944に属しています。 System.Data.SqlClient.SqlExceptionが発生しました Message = "データベース2の論理ページ（5：65424）をフェッチしようとしましたが失敗しました。これは4899918190390149120ではなく、割り当てユニット7349876362857938944に属しています。 Source = " 。Net SqlClient Data Provider" ErrorCode = -2146232060 Class = 21 LineNumber = 257 Number = 605 Procedure = "ispDisplayCount" Server = "10.10.1.1" State = 3 この例外はどういう意味ですか？上記の問題に対する解決策はありますか？ 上記のエラーで参照されているデータベースはtempdbを示していますが、メッセージ605を参照する同様のエラーは、以下の回答を使用して修正できます。 メッセージ605、レベル21、状態3、行1 データベース7の論理ページ（1：8687634）をフェッチしようとして失敗しました。これは、72057594052476928ではなく、割り当てユニット72057594364821504に属しています。

11 sql-server  sql-server-2008  corruption 

私のサーバーが今日クラッシュしました。これは、INNODBテーブルの1つでテーブルの同時切り捨てコマンドが原因で発生したと思います。サーバーを再起動できますが、起動後、SQLコマンドを発行しようとするたびに、次のエラーが発生します。 ERROR 2006 (HY000): MySQL server has gone away これはログで起こったことです： 121206 01:11:12 mysqld restarted 121206 1:11:13 InnoDB: Started; log sequence number 275 559321759 InnoDB: !!! innodb_force_recovery is set to 1 !!! 121206 1:11:13 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.0.95-log' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution InnoDB: Error: trying to …

9 mysql  innodb  corruption  index  crash