クラスタ化されたデュアル マシンのホット バックアップを使用したとしても、クラッシュを回避できるデータベース システムはありません。言うまでもなく、ほとんどのユーザーはそのような高価なハードウェア投資を行う余裕がありません。そのため、システムがクラッシュした場合、元の貴重なデータをいかに復旧するかが非常に重要な問題となります。
リカバリ中、理想的な状況はデータ ファイルとログ ファイルがそのままの状態であるため、sp_attach_db を使用してデータ ファイルを新しいデータベースに接続するか、すべてのデータ ファイル (マスターなどが必要です) をコピーするだけです。ただし、この方法は手間がかかりますが、通常は推奨されません。
ただし、データベースがクラッシュすると、システムは未完了のトランザクションやダーティ ページをディスクに書き込む時間がない場合があり、この場合、sp_attach_db は失敗します。したがって、DBA が適切な災害復旧計画を策定していることを祈りましょう。復旧計画に従って、最新の完全バックアップ、増分バックアップ、またはトランザクション ログ バックアップを復元し、アクティブなトランザクション ログがまだ読み取り可能であれば、おめでとうございます。クラッシュ前の状態に戻すことができます。
一般的なユニットにはフルタイムの DBA が存在せず、利用可能なバックアップがない場合は、最新のバックアップが古すぎる可能性が高く、許容できないデータ損失が発生し、アクティブなトランザクション ログも使用できない状態になります。これが最も厄介な状況です。
残念ながら、データベースのクラッシュは通常、ストレージ サブシステムが原因で発生し、そのような状況では、回復に使用できるログを用意することはほとんど不可能です。
その後、これらの解決策を試す必要があります。もちろん、少なくともデータ ファイルが存在する必要があります。データ ファイル、ログ ファイル、バックアップがなくなっても、屋上に行って「神様、救ってください」と歌っても構いません。
まず、sp_attach_single_file_db を試して、データ ファイルの復元を試みることができます。復元される可能性は低いですが、データベースがチェックポイントを実行した場合には成功する可能性があります。
運悪く宝くじに当たらず、最も重要なデータベースが期待どおりに接続されなかった場合でも、落胆する必要はありません。まだ他の解決策があります。
まず、データベースを緊急モードに設定します。sysdatabases のステータスが 32768 の場合は、データベースがこの状態にあることを意味します。
ただし、システム テーブルは気軽に変更することはできません。最初に設定します
Master を使用して
Go
sp_configure 'allow update'、1
override で再構成します
Go
Then
update sysdatabases set status = 32768 where name = '
さて、天空の神仏のご加護を祈り、新しいログファイルを作成します。成功する可能性は依然として非常に高く、システムは通常、新しく作成されたログを認識します。エラーが報告されなかった場合は、安堵のため息をつくことができます。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
