Dbms-data-recovery

提供:Dev Guides
移動先:案内検索

DBMS-データ復旧

クラッシュ回復

DBMSは、毎秒数百のトランザクションが実行される非常に複雑なシステムです。 DBMSの耐久性と堅牢性は、その複雑なアーキテクチャとその基盤となるハードウェアとシステムソフトウェアに依存します。 トランザクションの最中に失敗またはクラッシュした場合、システムは何らかのアルゴリズムまたは手法に従って損失データを回復することが期待されます。

故障分類

問題が発生した場所を確認するには、次のように、障害をさまざまなカテゴリに一般化します-

トランザクションの失敗

トランザクションは、実行に失敗した場合、またはそれ以上進むことができないポイントに達した場合に中止する必要があります。 これはトランザクション障害と呼ばれ、少数のトランザクションまたはプロセスのみが損傷を受けます。

トランザクションの失敗の理由は次のとおりです-

  • 論理エラー-トランザクションにコードエラーまたは内部エラー条件があるためにトランザクションを完了できない場合。
  • システムエラー-DBMSが実行できないためにデータベースシステム自体がアクティブなトランザクションを終了する場合、または何らかのシステム条件のために停止する必要がある場合。 たとえば、デッドロックまたはリソースが利用できない場合、システムはアクティブなトランザクションを中止します。

システムクラッシュ

システムの外部に問題があり、システムが突然停止し、システムがクラッシュする可能性があります。 たとえば、電源の中断により、基礎となるハードウェアまたはソフトウェアの障害が発生する場合があります。

例には、オペレーティングシステムエラーが含まれる場合があります。

ディスク障害

テクノロジーの進化の初期には、ハードディスクドライブまたはストレージドライブが頻繁に故障するという一般的な問題でした。

ディスク障害には、不良セクタの形成、ディスクへの到達不能、ディスクヘッドクラッシュ、またはディスクストレージのすべてまたは一部を破壊するその他の障害が含まれます。

ストレージ構造

ストレージシステムについてはすでに説明しました。 簡単に言えば、ストレージ構造は2つのカテゴリに分けることができます-

  • 揮発性ストレージ-名前が示すように、揮発性ストレージはシステムクラッシュに耐えることができません。 揮発性ストレージデバイスは、CPUの非常に近くに配置されます。通常、それらはチップセット自体に埋め込まれます。 たとえば、メインメモリとキャッシュメモリは揮発性ストレージの例です。 高速ですが、保存できる情報はごくわずかです。
  • 不揮発性ストレージ-これらのメモリは、システムのクラッシュに耐えるように作られています。 データストレージ容量は非常に大きくなりますが、アクセス性は遅くなります。 例としては、ハードディスク、磁気テープ、フラッシュメモリ、不揮発性(バッテリーバックアップ)RAMがあります。

回復と原子性

システムがクラッシュすると、いくつかのトランザクションが実行され、データ項目を変更するためにさまざまなファイルが開かれる場合があります。 トランザクションは、本質的にアトミックなさまざまな操作で構成されています。 ただし、DBMSのACIDプロパティによれば、トランザクション全体の原子性を維持する必要があります。つまり、すべての操作が実行されるか、まったく実行されないかのいずれかです。

DBMSがクラッシュから回復するとき、それは以下を維持する必要があります-

  • 実行されていたすべてのトランザクションの状態を確認する必要があります。
  • トランザクションが何らかの操作の途中にある可能性があります。この場合、DBMSはトランザクションのアトミック性を保証する必要があります。
  • トランザクションを今すぐ完了できるか、ロールバックする必要があるかを確認する必要があります。
  • DBMSを一貫性のない状態のままにするトランザクションは許可されません。

DBMSがトランザクションの原子性を回復するだけでなく維持するのに役立つ2つのタイプのテクニックがあります-

  • 実際にデータベースを変更する前に、各トランザクションのログを維持し、安定したストレージに書き込みます。
  • 変更が揮発性メモリで行われ、実際のデータベースが更新されるシャドウページングを維持します。

ログベースの回復

ログは、トランザクションによって実行されたアクションの記録を保持する一連の記録です。 ログは実際の変更の前に書き込まれ、安定したストレージメディアに保存されることが重要です。これはフェールセーフです。

ログベースのリカバリは次のように機能します-

  • ログファイルは安定したストレージメディアに保存されます。
  • トランザクションがシステムに入り、実行を開始すると、トランザクションに関するログが書き込まれます。
<Tn, Start>
  • トランザクションがアイテムXを変更すると、次のようにログが書き込まれます-
<Tn, X, V1, V2>

T〜[.small]#n#〜がXの値をV〜[.small]#1#〜からV〜[.small]#2#〜に変更したことを読み取ります。

  • トランザクションが終了すると、ログに記録されます-
<Tn, commit>

データベースは2つのアプローチを使用して変更することができます-

  • データベースの遅延変更-すべてのログは安定したストレージに書き込まれ、トランザクションがコミットされるとデータベースが更新されます。
  • 即時データベース変更-各ログは実際のデータベース変更に続きます。 つまり、データベースはすべての操作の直後に変更されます。

並行トランザクションによる回復

複数のトランザクションが並行して実行されている場合、ログはインターリーブされます。 復旧時には、復旧システムがすべてのログをバックトラックしてから復旧を開始するのが難しくなります。 この状況を緩和するために、最新のDBMSのほとんどは「チェックポイント」の概念を使用しています。

チェックポイント

ログをリアルタイムおよび実際の環境で保持および維持すると、システムで使用可能なすべてのメモリ領域がいっぱいになる可能性があります。 時間が経過すると、ログファイルが大きくなりすぎて処理できなくなる場合があります。 チェックポイントは、以前のすべてのログがシステムから削除され、ストレージディスクに永続的に保存されるメカニズムです。 チェックポイントは、DBMSが一貫した状態になり、すべてのトランザクションがコミットされる前のポイントを宣言します。

回復

同時トランザクションを備えたシステムがクラッシュして回復すると、次のように動作します-

回復

  • 回復システムは、ログを最後から最後のチェックポイントまで逆読みします。
  • 取り消しリストとやり直しリストの2つのリストを保持します。
  • 復旧システムが<T〜[.small]#n#〜、Start>および<T〜[.small]#n#〜、Commit>または単に<T〜[.small]#n#〜のログを検出した場合、Commit>、トランザクションをredo-listに入れます。
  • 復旧システムが<T〜[.small]#n#〜、Start>のログを見つけたが、コミットまたはアボートログが見つからない場合、トランザクションを元に戻すリストに入れます。

元に戻すリスト内のすべてのトランザクションが取り消され、ログが削除されます。 REDOリスト内のすべてのトランザクションとそれらの以前のログは削除され、ログを保存する前にやり直されます。