Sql server のバックアップとリストアの基礎

SQL Server のバックアップとリストアの基礎

小澤真之 (@Masayuki_Ozawa)

http://engineermemo.wordpress.com

データベースの基本構成とデータ更新時の流れ

復旧モデルとバックアップの種類

バックアップの基礎

リストアの基礎

SQLTO 第 1 回勉強会 http://www.sqlto.net

本日の Agenda

2011/7/23 2

データベースの基本構成とデータ更新時の流れ


2011/7/23 3

なぜバックアップの前にこの章が?

2011/7/23 SQLTO 第 1 回勉強会 http://www.sqlto.net

4

バックアップとリストアを勉強するためには SQL Server のデータベースの構成を理解しておく必要があります。

データベースの構成とバックアップの取得単位には密接な関わりがあります。

データ更新の流れを理解することでバックアップ / リストアに影響のある設定の理解が深まります

なぜ、そのバックアップを取得する必要があるかの理解につながります。


まずはデータベースの基本構成をおさらい

2011/7/23 5

データベース

データ

ログ

ファイルグループ (PRIMARY)

データファイル (.mdf)

ログファイル (.ldf)

Table_1 Table_2 Index_1

各構成要素の役割


6

構成要素説明

データベース

データ

ファイルグループデータファイルを束ねるための論理名 PRIMARY というファイルグループが必ず作成される

データファイル

実際にデータが格納される領域データファイルは必ず一つのファイルグループに所属する (複数のファイルグループには所属できない) デフォルトは～.mdf (プライマリデータファイル) ２個目以降は～.ndf (セカンダリデータファイル) 複数のファイルを用意することで書き込みが分散される

ログ

ログファイル

データベースの変更に対してのログ (履歴) を格納する領域デフォルトは～.ldf 2 個目以降も～.ldf ログはシーケンシャル (順次) 書き込みされるため、複数のファイルを用意しても書き込みは分散されない


複数のファイルグループを使用した構成

2011/7/23 7

データベース

データ

ログ


データファイル 1 (.mdf)


Table_1 Table_2

データファイル 2 (.ndf)

ファイルグループ (INDEX)


Index_1 Index_2


データ変更の基本動作


8

クライアント

SQL Server ①データ更新

データベースメモリ

データファイル (mdf)

ログファイル (ldf)

②更新内容をログに先行書き込み

③メモリ上のデータを更新 (ダーティーページが発生)

⑤チェックポイント発生時にダーティーページを

データファイルに書き込み

④クライアントからみて処理完了

ダーティー (汚れた) ページ：物理書き込みが行われていないメモリ上のページ

チェックポイント：メモリ上のダーティーページをディスク上のデータファイルに反映

2011/7/23

データ変更時の流れのおさらい


9

変更内容は最初にログファイルに書き込まれるログレコードを先行書き込みする

データの変更は最初にメモリ上のデータに対して変更が行われるログファイルに書き込まれた内容が不要になるのは、メモリ上

でのみ変更されているデータの内容 (ダーティーページ) がデータファイルにも反映されたタイミング

チェックポイントというプロセスが発生するとメモリ上のダーティーページがデータファイルに書き込まれるチェックポイントが自動的に発生する頻度を制御するのが [復

旧間隔] という設定デフォルトの設定 [0] だと約 1 分間隔でチェックポイントが発生

する

CHECKPOINT を実行することで手動でチェックポイントを発生させることも可能

参考) 復旧間隔の設定画面


10

データベースを復旧するのに必要な時間の最大値を分単位で設定 SQL Server 起動時にデータベースの復旧 (ロールバック / ロールフォワード)にかかる時間を設定する設定値が大きいとチェックポイントの発生頻度が低くなるためディスク負荷が下がるが、SQL Server 起動時の復旧時間が長くなる

参考)Indirect Checkpoints


11

Denali ではデータベース単位に設定できるようになるようです Indirect Checkpoints

http://technet.microsoft.com/en-us/library/ms189573(SQL.110).aspx#IndirectChkpt

http://technet.microsoft.com/en-us/library/ms189573(SQL.110).aspx




復旧モデルとバックアップの関係


12

復旧モデルの種類と利用可能なバックアップ


13

復旧モデル復旧可能タイミング取得可能なバックアップ作業の損失の可能性

単純バックアップの終了時点 - 完全バックアップ - 差分バックアップログのバックアップは取得できない

最新のバックアップ以降の変更は保護されないチェックポイント発生時にログの切り捨てが自動で行われる

一括ログバックアップの終了時点特定の時点への復旧はサポートされていない (特定の条件を満たしていれば特定の時点に復旧も可能)

- 完全バックアップ - 差分バックアップ - トランザクションログバックアップ

ログバックアップを取得しないとログは切り捨てられない

ログ末尾のバックアップが取得できれば障害発生の直前まで復元可能ただし、時間指定の復元はできない場合もある

完全 (デフォルト)

特定の時点に復旧 - 完全バックアップ - 差分バックアップ - トランザクションログバックアップ

ログバックアップを取得しないとログは切り捨てられない

ログ末尾のバックアップが取得できれば障害発生の直前まで復元可能

どの時点のデータまで戻しますか？


14

バックアップ終了時点までのデータを担保すればよいのであれば [単純] で本番運用も可 SQL Server のバックアップはバックアップ取得中に発生した

変更点のログをバックアップの最後に取得するためバックアップの開始時点のデータには戻らない

それより細かい粒度でリストアをするのであれば、[一括ログ] [完全] を使用一括ログと完全の使い分けは最小ログ記録に該当する操作をす

るかどうかインデックスの再構築 / 一括インポート (BCP ツールや BULK

INSERT) は最小ログ記録に該当する操作

[一括ログ] の場合は、最小ログ記録に該当する操作を実施した場合、ログの記録量を抑えることができるただし、最小ログ記録の操作を行った時間帯のログのバックアッ

プからは、特定の時間帯に戻すことはできない

最小ログ記録について


15

最小ログ記録の操作をするときに、復旧モデルを [単純] または [一括ログ] にすることでログに記録される内容を最小限にすることができる一括インポート操作 (BCP ツールや BULK INSERT) に

ついては特定の条件を満たす必要がある

一括インポートで最小ログ記録を行うための前提条件 http://msdn.microsoft.com/ja-jp/library/ms190422.aspx

データローディングパフォーマンスガイド http://technet.microsoft.com/ja-jp/library/dd425070(SQL.100).aspx

通常は復旧モデルを [完全] で運用し、最小ログ記録操作を行うときに [一括ログ] に変更することでログへの書き込みを最適化することも可能完全復旧モデルまたは一括ログ復旧モデルからの切り替え

http://msdn.microsoft.com/ja-jp/library/ms190203.aspx





http://technet.microsoft.com/ja-jp/library/dd425070(SQL.100).aspx








インデックス再構築時のログの比較


16

約20 MB のインデックスを再構築した場合のログレコードのサイズ比較

復旧モデル = 完全

復旧モデル = 一括ログ

同じ操作でも一括ログのほうが書き込まれるログレコードが少ない!!

約 22MB

約 1MB

バックアップの基礎


17

バックアップの種類


18

バックアップの種類バックアップの特徴

完全バックアップ特定のデータベース、またはファイルグループやファイルのデータがすべて含まれるバックアップには使用済みの領域のみ含まれるため、未使用の領域はバックアップには含まれないデータを復旧するために必要なログも含まれる (データを復旧するために必要でないログは含まれていないためバックアップのサイズはデータファイルの使用領域+ログファイルの使用領域とはならない)

差分バックアップ差分バックアップには、最後に実施した完全バックアップ以降に変更されたデータのみが含まれる時間の経過と共にデータベースが更新されるにつれて、差分バックアップに含まれるデータ量が増える (全データが更新された場合は完全バックアップと同等のサイズになる) 復元時には、完全バックアップを先に復元し、続いて最新の差分バックアップを復元する

トランザクションログバックアップ

完全復旧モデルまたは一括ログ復旧モデルでは、トランザクションログバックアップ (ログバックアップ) が必要になる。トランザクションログは、通常のログバックアップ後に毎回切り捨てられる (バックアップを取らないとログは切り捨てられない) 完全復旧モデル、および一括ログ復旧モデル (条件あり) では、ログチェーン (ログの連続性) が途切れていなければデータベースを任意の時点に復元できる。

2011/7/23

参考) バックアップのクエリ


19

完全バックアップ

BACKUP DATABASE [DB 名] TO [取得先]

差分バックアップ

BACKUP DATABASE [DB 名] TO [取得先] WITH DIFFERENTIAL

トランザクションログバックアップ

BACKUP LOG [DB 名] TO [取得先]


バックアップの取得単位

2011/7/23 20

データベース

データ

ログ


データファイル (.mdf)


Table_1 Table_2 Index_1

今回の内容

今回の内容

バックアップの取得先


21

ディスク一般的なバックアップ取得先 SQL Server のサービスアカウントがアクセスできるディレ

クトリの必要がある。 NULL デバイスに取得することも可能

共有フォルダ取得先は SQL Server のサービスアカウントがアクセスでき

る共有ディレクトリの必要がある

テープテープバックアップデバイスは、将来のバージョンの SQL

Server でサポートされなくなる予定 Code Name “Denali” CTP3 ではテープのラジオボタンがありま

した (テープ装置が自宅にないので実際には試せておらずグレーアウト)

の 3 種類に取得可能

参考) バックアップの取得先


22

ディスク BACKUP DATABASE [DB 名] TO

DISK=N‘E:¥BACKUP¥master.bak‘

NULL デバイス BACKUP DATABASE [DB 名] TO

DISK=N‘NUL‘ (NUL: でも可)

共有フォルダ BACKUP DATABASE [DB 名] TO

DISK=N‘¥¥Server¥Share¥master.bak‘

テープ BACKUP DATABASE [DB 名] TO

TAPE= '¥¥.¥tape0'

3 種類のバックアップを利用した基本設定例


23

日月火水木金土

0:00


(上書き)

0:00


(上書き)

0:00


(上書き)

0:00


(上書き)

0:00


(上書き)

0:00


(上書き)

0:00


(上書き)

1時間毎

ログバックアップ

(追記)

1時間毎


(追記)

1時間毎


(追記)

1時間毎


(追記)

1時間毎


(追記)

1時間毎


(追記)

1時間毎


(追記)

1 週間前のバックアップ

削除

2011/7/23

通常のバックアップの取得タクト


24

完全バックアップ 1

ログバックアップ２

差分バックアップ 2

完全バックアップ 1 からの差分


ログバックアップ 1

ログバックアップ 1 からの差分

臨時のバックアップを取るためには


25

完全 → 差分 → ログバックアップは基本的には相互に関連した一連のバックアップとなる

運用で一連のバックアップとは異なる臨時のバックアップを取得したい場合には [COPY_ONLY] のオプションを設定してバックアップを取得する

COPY_ONLY は [完全] または [トランザクションログ] のバックアップでのみ使用可能

差分バックアップには COPY_ONLY オプションは使用できない

普通に完全バックアップを取ると?


26







通常のバックアップとバックアップデータの関連性が変わるためリストアに影響が

COPY_ONLY を使用した場合


27




COPY_ONLY バックアップ



COPY_ONLY 既存のバックアップの関係を崩さないので途中でバックアップを取得しても差分バックアップ 2 は


COPY_ONLY バックアップの取得


28

そのバックアップ本当に大丈夫?


29

壊れた状態のデータベースのバックアップを取得しても壊れたまま

壊れていない状態のデータベースでバックアップを取得することが重要壊れている状態のデータベースのバックアップをリストアしてもデータベースは壊れたまま

バックアップの取得前に [DBCC CHECKDB] を実施、またはバックアップ取得時にチェックサムの確認を行い、取得するデータベースが破損していないかを確認することが重要

破損しているデータベース


30

メッセージ824、レベル24、状態2、行1

SQL Server で、一貫性に基づいた論理I/O エラーが検出されました: 正しくないチェックサム(必要なチェックサム: 0xc9b63224、実際のチェックサム: 0x4996b23e)。このエラーは、ファイル'E:¥SQL2008R2¥BROKEN.mdf' のオフセット0x00000000266000 にあるデータベースID が14 のページ(1:307) の読み取り中に発生しました。SQL Server エラーログま

たはシステムイベントログ内の別のメッセージで詳細情報が報告されることもあります。このエラー状態は深刻で、データベースの整合性を損なう可能性があるので、すぐに解決する必要があります。完全なデータベース一貫性確認(DBCC CHECKDB) を実行してください。このエラーには多くの要因があります。詳細については、SQL Server オンライン

ブックを参照してください。

msdb の suspect_pages テーブル ※最大 1,000 件

メンテナンスプランを使用したバックアップ設定


31

バックアップの前ジョブで整合性確認タスク

(DBCC CHECKDB) を実行

バックアップ取得時のチェックサム確認


32

バックアップ時にデータファイルのチェックサムからページの整合性を

検出させることもできる

障害発生時のバックアップ


33

障害が発生している状態のデータベースでログ末尾のバックアップ (現状のログのバックアップ) が取得できれば障害発生直前まで復元が可能

ログ末尾のバックアップが取得できない場合は最新のログバックアップまでしか復元できない

正常稼働障害発生




ログ末尾のバックアップ

参考) ログ末尾のバックアップ


34

BACKUP LOG [DB 名] TO [取得先] WITH NO_TRUNCATE

NO_TRUNCATE で取得できない場合は、CONTINUE_AFTER_ERROR を使用する

バックアップの時間を減らすために


35

SQL Server 2008 以降はバックアップ圧縮を実装

SQL Server 2008 では Enterprise Edition の機能であったが、SQL Server 2008 R2 では、Standard Edition から使用可能に

暗号化 / 圧縮されているデータベースに対してはサイズが大幅に減少することはない (行圧縮のテーブルに対しては効果があることも)

バックアップ実行時の CPU 使用率が非圧縮と比較して上昇することを把握しておく

リソースガバナー (CPU / メモリリソースの利用調整機能) を使用することで CPU 使用率を制限することも可能

ただし、リソースガバナーは Enterprise Edition 以上の機能

リストアの基礎


36

完全バックアップのリストア


37

単体でリストア可能 (mdf / ndf / ldf ファイルを復元) リストア時にファイルを作成してくれる瞬時初期化という設定はデータのリストア時にも有効

(今回は紹介のみ) SQL Server におけるバックアップと復元のパフォーマンスの最適化


バックアップに含まれるデータをログを含めてリストアバックアップ中の変更は含まれているログを使用してロールフォワード

データ

ログ

バックアップ開始時点のデータ

バックアップ中の変更





差分バックアップのリストア


38

単体でリストア不可。差分バックアップ取得前の完全バックアップと組み合わせてリストアをする

差分バックアップは前回の完全バックアップからの差分になるため、複数の差分バックアップがあっても、最新の差分バックアップをリストアすれば、それまでのデータがリストアされる

データ

ログ

前回完全バックアップからの変更分のデータ

バックアップ中の変更

トランザクションログバックアップのリストア


39

単体でリストア不可完全バックアップ / 差分バックアップと組み合わせてリ

ストアするトランザクションログのバックアップを使用することで、

特定の時間に戻すことが可能となる最小ログ記録操作の含まれるログバックアップでは特定の時間

に戻すことはできない

データ

ログ

最小ログ記録で変更のあったデータ

前回ログバックアップからの変更

最小ログ記録時のログバックアップの比較


40

完全バックアップのログバックアップデータベース'TESTDB' の2665 ページ、ファイル1 のファイル'TESTDB_log' を

処理しました。

BACKUP LOG により2665 ページが0.302 秒間で正常に処理されました(68.938 MB/秒)。

一括ログのログバックアップデータベース'TESTDB' の2608 ページ、ファイル1 のファイル'TESTDB' を処

理しました。

データベース'TESTDB' の117 ページ、ファイル1 のファイル'TESTDB_log' を処理しました。

BACKUP LOG により2725 ページが0.633 秒間で正常に処理されました(33.621 MB/秒)。

バックアップのログから復旧モデルが一括ログの場合で最小ログ記録操作があった場合はログバックアップ時に変更のあったデータが取得されていることが確認できる

バックアップの内容から最小ログの有無を確認


41

HasBulkLoggedData 最小ログ記録の操作を含むかのフラグ

リストアの基本手順


42

1. (ログ末尾のバックアップを取得) 1. Denali CTP3 では SSMS からのリストア時に

ログバックアップを取得することが可能

2. 最新の完全バックアップをリストア

3. 最新の差分バックアップをリストア

4. 最新の差分バックアップ以降のトランザクションログバックアップをリストア

完全バックアップ + ログバックアップのリストアでも可

5. ログ末尾のバックアップをリストア

2011/7/23


43

参考)2008 R2 と Denali CTP3 の違い 1/3

2008 R2 Denali CTP3


44


2008 R2 Denali CTP3


45


2008 R2 Denali CTP3


46

まとめ


47

どの時点までデータを保証するかを検討

バックアップの種類と含まれる内容を把握

戻せるバックアップを取得

Documents

Sql server のバックアップとリストアの基礎