Open棟梁Project - マイクロソフト系技術情報 Wiki
目次 †
概要 †
障害復旧に関するオプションの説明。
SQL Server の復旧モデル †
SQL Serverでは、「データ消失に対する保護」、「性能」、および「ディスクとテープの容量」
などの要件に対応するための目的とした３種類の「復旧モデル」を用意されている。
このため、「復旧モデル」を選択する場合は、次の業務上の条件とトレードオフを考慮する必要がある。
- コミットされたトランザクションの消失など、「データ消失の可能性」。
- インデックスの作成や一括ロードなど、大量操作の「性能」。
- 「トランザクション ログ」が使用する領域の「容量」。
- バックアップ リストアの「手順の単純さ」。
概要 †
実行する操作の種類によっては、適切な「復旧モデル」が複数あることもある。
「復旧モデル」を選択した後は、バックアップ、リストアの手順を計画する必要がある。
次に、SQL Server の3 種類の「復旧モデル」の機能概要を示す。
単純 復旧モデル †
- 「単純 復旧モデル」は、処理性能に優れる一括コピーであるが、「チェック ポイント」が発生するたびに「トランザクション ログ」が切り捨てられる。
- このため、必要なスペースを抑制できるが、最新の「完全バックアップ」または「差分バックアップ」の時点にしか復旧できない。
- バックアップ、リストアの手順は、「完全バックアップ」または「差分バックアップ」のみサポートしている。
- 「トランザクション ログ」が切り捨てられるため、「トランザクション ログ バックアップ」はサポートされない
- 最小限の管理で済むが、「データ ファイル」が損傷を受けた場合のデータ消失の可能性が高い。
- 最新の変更内容の消失が許されないOLTPシステムの場合、
顧客要件や、ストレージの信頼性によるが、「単純 復旧モデル」は適切ではない場合がある。
- ケース バイ ケースで、「データ消失」と「性能」を考慮したバックアップ間隔に調整する。
- バックアップのオーバーヘッドが業務に影響しない程度に長いバックアップ間隔に調整する。
- 大量のデータを消失しないで済む程度に短いバックアップ間隔に調整する。
完全 復旧モデル †
データが最大限に保護される。これらのモデルは「トランザクション ログ」からデータを復旧することができる。
- 「完全 復旧モデル」では、全てのトランザクションが、「トランザクション ログ」に記録されるため、完全な復旧が可能である。
- 「トランザクション ログ」には、全ての操作が記録される。このため、
- 大規模な操作の場合は、性能が問題となる。
- 「トランザクション ログ」を保持する、ある程度のログ領域が必要になる。
- 復元の手順は、
- 「完全バックアップ」のリストア、
- 「差分バックアップ」のリストア、
- 「トランザクション ログ バックアップ」のリストアを実施する。
一括ログ 復旧モデル †
データが最大限に保護される。これらのモデルは「トランザクション ログ」からデータを復旧することができる。
- 「一括ログ 復旧モデル」では、特定の大規模な操作を除いた、全てのトランザクションが、「トランザクション ログ」に記録されるため、ほぼ完全な復旧が可能である。
- 特定の大規模操作の際に、「トランザクション ログ」には、エクステントのビットだけが記録される。
このため、高い性能を実現し、「トランザクション ログ」のスペースを抑制できる。
「一括ログ 復旧モデル」でログが記録されない大規模操作は以下のとおり。
- SELECT INTO操作（検索結果をテーブルに挿入する処理）
- bcpユーティリティを使用した大量データのインポート、エクスポート
- BULK INSERTを使用した大量データのインポート
- CREATE INDEX（その他、INDEXのデフラグなど）
- text操作と、image操作
- 大規模操作を実行した後に「トランザクション ログ」をバックアップすれば、その際に、「データ ファイル」のエクステントから、最後のバックアップ以降の大規模操作が「トランザクション ログ バックアップ」に反映される。
- このため、大規模操作を実行した後は、「トランザクション ログ バックアップ」を利用したデータの復旧ができなくなるが、大規模操作後、直ちに「トランザクション ログ」をバックアップすれば、その時点までの復旧が可能になる。
- 「完全 復旧モデル」では、「一括読み込み」「インデックス作成」などの大規模操作に長い時間がかかるので、場合によっては「完全 復旧モデル」と「一括ログ 復旧モデル」を切り替える。
利点、欠点 †
以下の表に、それぞれの「復旧モデル」の利点と欠点を示す。
| 復旧モデル | データ消失の影響度 | 性能 | 運用手順の難易度 | 必要なログ領域の容量 |
| 単純 | 大 | 高 | 容易 | 小 |
| 完全 | 最小 | 低 | 普通 | 大 |
| 一括ログ | 小 | 中 | 難しい | 中 |
設定方法 †
- 既定の「復旧モデル」を変更するには、「model」DBの「復旧モデル」を変更する。
- 作成済みのDBの「復旧モデル」を変更するには、各DBの「復旧モデル」を変更する。
Management Studio †
「sp_configure」による設定 †
- [復旧モデル]に指定する文字列は以下の通り。
| 「FULL」 | 「完全 復旧モデル」 |
| 「BULK_LOGGED」 | 「一括ログ 復旧モデル」 |
| 「SIMPLE」 | 「単純 復旧モデル」 |
参考 †
SQL Server の復旧時間の最大値 †
「チェック ポイント」処理 †
「チェック ポイント」処理とは、「バッファ キャッシュ」中のデータを「データ ファイル」にフラッシュする処理である。
※ データ変更は、コミット、未コミットに関係なく、すべて「トランザクション ログ ファイル」に書き込まれる。
復旧処理（ロールバック、ロールフォワード） †
復旧処理では、「データ ファイル」にフラッシュされていなかった変更を「トランザクション ログ」上の記録を元に、「データ ファイル」に反映する。
この際、「コミット」されたトランザクションは、「ロール フォワード」され、「未コミット」のトランザクションは、「ロール バック」される。
「recovery interval」オプション †
障害発生後、SQL Serverインスタンスを再起動した場合に発生する
といった、復旧にかかる時間（分単位）の最大値を設定する。
- SQL Serverインスタンスは、この設定と内部アルゴリズムにより、「自動チェック ポイントの実行頻度」を判断し、
復旧時間が「recovery interval」オプションで指定された時間以上にならないようにする。
SQL Serverインスタンスは内部の処理量に応じて、「チェック ポイント」の間隔を決める。
- 内部の作業量（データ変更処理など）が多いほど、「チェック ポイント」処理は頻繁に実行される。
これは、「データ ファイル」にフラッシュされていないデータ変更が少ないほど、復旧時の処理時間が短くなるためである。
チューニングの考え方 †
復旧時間を短くしたい場合 †
「recovery interval」オプションで復旧時間を短く設定する。
この場合、「チェック ポイント」処理は頻繁に実行されるためI/Oが増える。
I/Oを減らしたい場合 †
「recovery interval」オプションで復旧時間を長く設定すれば、
「チェック ポイント」処理の間隔を長くすることができる。
このため、I/Oが減少するので、（I/Oに関する）性能向上が期待できる。
設定方法 †
Management Studio †
「sp_configure」による設定 †
- 値を５に設定した場合
この場合、復旧時間は５分未満で、
EXEC sp_configure 'recovery interval', n
RECONFIGURE
EXEC sp_configure
GO
nの単位は、分で指定する。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
