検索
連載

バックアップの所要時間を短縮するテクニックOracleバックアップ/リカバリ講座(9)(2/4 ページ)

本記事では、Oracleデータベースのバックアップ/リストア/リカバリについて、そのアーキテクチャ、代表的なバックアップ手法、論理/物理バックアップ、RMANといった全般的な内容を解説していく。(編集部)

PC用表示 関連情報
Share
Tweet
LINE
Hatena

増分バックアップの取得例

 ここからは具体的に増分バックアップを行うコマンドについて説明します。増分バックアップを行うには、まずベースとなるバックアップ(LEVEL 0)を取得する必要があります。リスト1がその例になります。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

 次に差分増分バックアップ(LEVEL 1)の取得方法を見てみましょう。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

 リスト2の差分増分バックアップコマンドに「cumulative」句を付けると累積増分バックアップになります。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

 また、差分増分と累積増分バックアップは組み合わせて使用することもできます。例えば、ベースとなるバックアップ(LEVEL 0)を月に1回のみとし、週末に累積増分バックアップ(LEVEL 1 cumulative)、平日は差分増分バックアップ(LEVEL 1)というバックアップ運用も可能です。

増分バックアップの高速化

 増分バックアップの最初で説明したように、増分バックアップは更新したブロックのみを書き込むため、バックアップファイルサイズは小さくなり、保存先のDISKやTAPEへの書き込み時間が短縮されます。しかし、更新したブロックを確認するためには、バックアップ対象のデータファイルをすべて読み込む必要があります。そのため、バックアップ対象ブロックを確認するI/O負荷や、その処理時間については効果的であるといえません。

 しかし、Oracle 10gからの新機能であるブロック・チェンジ・トラッキング機能を設定することで、この部分のパフォーマンスを改善できます。この機能では、データベースに対する更新が発生したときに、変更されたブロックの情報をブロック・チェンジ・トラッキングファイルに記録しておきます。そして、増分バックアップの実行時には、そのブロック・チェンジ・トラッキングファイル内の変更されたブロック情報を参照し、変更されたブロックのみにアクセスします(図5)。そのため、増分バックアップ時の変更ブロックを確認する時間が短縮され、結果的に大幅なバックアップ時間の短縮が可能となります。

図5 ブロック・チェンジ・トラッキング機能を利用した増分バックアップ 日曜日に全体バックアップ、平日に差分増分バックアップを行う例。
図5 ブロック・チェンジ・トラッキング機能を利用した増分バックアップ
日曜日に全体バックアップ、平日に差分増分バックアップを行う例。

 ブロック・チェンジ・トラッキング機能を設定するには、DBA権限を持つ管理者で接続し、SQL*Plusを使用してリスト4のコマンドを実行します。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

 それでは実際に、ブロック・チェンジ・トラッキング機能の有無により、どれだけ処理時間が短縮されるかを確認してみましょう。今回は、ベースとなる全体バックアップとして、リスト1のコマンドを実行後、テーブルを1万行(約3500ブロック)更新し、その後、リスト2の差分増分バックアップをブロック・チェンジ・トラッキング機能が有効になっている場合と、そうでない場合で処理時間を比較したものが表1になります。

バックアップ方法 処理時間
全体バックアップ(LEVEL 0) 3分16秒
差分バックアップ(LEVEL 1、ブロック・チェンジ・トラッキング機能なし) 2分6秒
差分バックアップ(LEVEL 1、ブロック・チェンジ・トラッキング機能あり) 7秒
表1 ブロック・チェンジ・トラッキング機能の有無による処理時間の違い

 表1のとおり、ブロック・チェンジ・トラッキング機能を使用することにより、処理時間が改善されたことが分かります。ただし、実際のシステムでどれぐらい改善されるかについては、事前に検証して確認を行ってください。

 また、ブロック・チェンジ・トラッキングファイルを使用するうえで、以下のような注意点があります。

  • ブロック・チェンジ・トラッキングを使用することにより、わずかながらではありますが、更新処理時にデータベース全体に対するオーバーヘッドが発生します。

  • ブロック・チェンジ・トラッキングファイルのために別途領域が必要です。目安としての見積もりサイズはバックアップ対象全データ・ブロックの約3万分の1程度です。

  • ブロック・チェンジ・トラッキングファイルは冗長化構成が取れませんので、OSやハードウェアレベルでRAIDなどを使用した冗長化が推奨されます。

  • データベース自体には影響がありませんが、ブロック・チェンジ・トラッキングファイルが壊れた状態ではデータファイルのバックアップを取得するとエラーとなります。このため、一度リスト5にあるコマンドでブロック・チェンジ・トラッキング機能を無効にしてバックアップを取得するか、再作成を行う必要があります。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る