| >> はじめに |
|
前回大まかにMS SQL APMのバックアップ・オプションについて説明しましたが、それだけでは豊富な機能を使いこなすことができません。というのも、様々なバックアップ方法は、SQL Server側での各データベースに対する設定によって、出来るものと出来ないものがあるからです。
今回は、バックアップ機能にとって一番重要なトランザクションログの仕組みと、その設定項目である復旧モデルの関係を中心に考えてきます。
| >> トランザクションログとは？ |
|
データファイルとトランザクションログの関係は、第2回の講座で説明しましたが、もう少し細かくその役割について確認しておきましょう。
トランザクションログは、各データベースのデータファイルに対となるように構成されます。OracleやDB2では、複数のログファイルを切り替えて使用しますが、SQL Serverの場合は同じファイルの中で、デフォルトでは無制限に自動拡張するように設定されています。
 |
 |
そのため、何の処理も行われないと、いつかディスクがいっぱいになってしまいます。SQL Serverのトランザクションログの場合、切り捨てるという操作を行うことで空き領域を作り出し、その領域を再利用することでログサイズが大きくならないような工夫がされています。
当然ながら自然に切り捨てが行われるのではなく、データベースの動作上矛盾が無い形で処理が行われなくてはなりません。そのタイミングは大きく3種類に分かれています。
- チェックポイント実行時にトランザクションログを切り捨てるように設定する
トランザクションログのもっとも重要な役割は、チェックポイントによるデータファイルへの更新結果が反映される前でも、更新履歴をログとして保存することで、コミットされたトランザクションの整合性を保証することです。そのため、チェックポイント後はデータファイルに反映された部分のログは必要ないということになります （詳細は講座の第2回をご参考ください）。
各データベース（新規で作成するデータベースのベースとなるmodelデータベースは除く）は、このチェックポイントごとにトランザクションログを切り捨てるという処理を行い、ログのサイズを最小限に抑えることができるようデフォルﾄで設定されています。その代わり、古いログがないため特定時点を指定してのリストアや、トランザクションログのバックアップ、差分バックアップができず、復旧できる時点が決まっています。
このような処理は、後述する復旧モデルを シンプル に設定することで実現できます。
- トランザクションログのバックアップを取る
トランザクションログのバックアップを実行すると、バックアップされたログ部分は自動的に切り捨てられます。チェックポイントごとに切り捨てる方法では、ログが常に消えていってしまうため、特定時点へのリカバリはできませんが、トランザクションログのバックアップがあれば、ログの存在する範囲内での、比較的自由なリカバリが実現できます。
復旧モデルが、フルもしくは一括ログ記録になっている場合に設定できますが、ログを削除するには、当然定期的なバックアップが必須ということになります。
- BACKUP LOG データベース名 WITH TRUNCATE_ONLYコマンドの使用
2番の方法の場合、トランザクションログのバックアップが定期的に実行されていれば、ログによりディスクがいっぱいになってしまうことはありませんが、適切に計画が行われていない場合、ディスクフルになりデータベースが動作しなくなってしまうケースもあります。そのような時の緊急回避手段として、ログをバックアップせず、即時切り捨てを行うことも可能です。
以上のようにトランザクションログの活用には、復旧モデルが重要になってきます。
復旧モデルはSQL ServerのEnterprise Managerで、各データベースのプロパティの設定のオプションタブにて設定可能です。
以下でそれぞれの違いについて確認してみましょう。
[単純復旧モデル]
データベースのプロパティで復旧モデルを"シンプル" に設定します。常にログが切り捨てられてしまうために、直前にバックアップされた時点にのみ復旧が可能であり、特定時点や障害発生時点を指定しての復旧はできません。良い点としては、やはりログのサイズが大きくならないため、ログ容量をあまり気にしなくても良いということです。SQL Serverインストール時のmodelを除くデータベースのデフォルト設定です。[完全復旧モデル]
データベースのプロパティで復旧モデルを"フル"に設定します。常にすべてのトランザクションが記録されるため、ログの生成量はもっとも大きくなりますが、データベースのバックアップとトランザクションログのバックアップを的確に行うことで、任意の時点に復旧可能という利点があります。なお、modelデータベースという新規でデータベースを作成する際のテンプレートのデフォルト設定であるため、標準では新規データベースはすべて完全復旧モデルになります。[一括ログ復旧モデル]
データベースのプロパティで復旧モデルを"一括ログ記録"に設定します。フルのようにすべてのトランザクションが記録されるのではなく、以下のような一括で処理が行われるトランザクションについては記録を行わないため、パフォーマンスとデータ保護のバランスが良いと言えます。
- SELECT INTO
- bcpユーティリティー
- BULK INSERT
- CREATE INDEX
- text操作とimage操作
しかしながら、障害復旧の際には上記の処理の記録が無い為、別途再実行する必要があります。
| >> MS SQL APMで使用するには |
|
各復旧モデル毎にトランザクションログの仕組みが違う為、当然MS SQL APMを使用してバックアップを行う際にも、影響があります。
復旧モデルによるバックアップの制約の違い
|
通常はきちんとEnterprise Managerから設定を確認して欲しいのですが、特に単純復旧モデルになっている場合には、バックアップの方法に制約がでてくるため、MS SQL APMからデータベースの設定を確認できるようになっています。
バックアップウィンドウから、MS SQL APMのアイコンをドリルダウンで表示し、更にインスタンス名、データベース名を確認し、もう一段ドリルダウンすると、復旧モデルが "シンプル" になっている場合は、"Recovery Model is 'Simple'"が表示され、それ以外の場合はデータファイル名が表示されます。
この例では、2つの復旧モデルが混在しているため、インスタンス全体を指定しての、差分バックアップやトランザクションログのバックアップはできないことになります。フルバックアップのみ可能です。個別にデータベースを指定してのバックアップであれば、混在していてもトランザクションログのバックアップ等は不可能ではありませんが、管理上は統一した復旧モデルにした方が、復旧時にもトラブルが少なくなります。
試しに、すべてのデータベースを指定したフルバックアップを実行してみましょう。
何も問題がなければ、ジョブの実行結果は Backup Completed になるはずです。
差分やトランザクションログのバックアップを実行してエラーが発生する場合、復旧モデルの設定に問題があることがほとんどです。エラー発生時のログを見て、設定を確認するようにしてください。
| >> 次回は・・・ |
|
次回は、バックアップオプションの中で、ファイルとグループに関しての説明を行います。また、各バックアップ方法を組み合わせた実践的な運用方法も取り上げたいと思います。お楽しみに。