運用計画による効果的なバックアップ法：Oracleマイスター養成講座（6）

　データベースが運用段階になると、そのバックアップが重要になる。しかし、その方法はデータベースの運用形態によって異なる。バックアップの方法や仕組みを理解し、運用形態に最適なバックアップ計画を立案しよう。

　前回まで、データベースの作成について解説してきました。Oracleのインストール時に作成されるデフォルトデータベースとは一味違う、自分のデータベースが作成できるようになればもう立派なOracleマイスターです。

　いよいよデータベースの運用を始めなければなりませんが、それにはバックアップ計画が欠かせません。基本的な運用計画とバックアップ方法を身に付けましょう。

オンラインバックアップとコールドバックアップ

　データベースのバックアップには、大きく分けて「コールドバックアップ」と「オンラインバックアップ」の2つがあります。

• コールドバックアップ
  　データベースをすべて停止（shutdown）した状態で行うバックアップ。「オフラインバックアップ」とか「一貫性のあるバックアップ」などとも呼ばれます。
  
  
• オンラインバックアップ
  　データベースを停止せずに行うバックアップ。「ホットバックアップ」とも呼ばれます。

　また、バックアップ方法に大きく関係するデータベースのモードに、「アーカイブログモード」があります。

• アーカイブログモード（ARCHIVE LOG MODE）
  　オンラインREDOログファイルが満杯になるたびに、アーカイブ（バックアップ）を行います。通常、このバックアップは自動的に行われます。アーカイブログは、放置しておくと永遠に増え続けます。

オンラインREDOログファイルは回帰的（サイクリック）に使用されるが、1つ書き終わるごとにアーカイブログファイルが1つ作成される

• ノーアーカイブログモード（NOARCHIVE LOG MODE）
  　アーカイブを行わないモードです。オンラインREDOログファイルは回帰的に使用されるため、1周すると以前のREDOログ情報はなくなります。

■パラメータファイルの設定

　実際の設定の変更は、いったんデータベースをshutdownしてからパラメータファイルに以下の内容を追加し、svrmgrlでコマンドを実行します。

#
log_archive_start = true
# archive log directory
log_archive_dest = /oracle/oradata/arch
# archive log file name
log_archive_format = "arch_%s.arc"

■モード切り替えコマンド

　アーカイブログモードに切り替えるには、一度startup mount（ユーザーが使えない状態）で立ち上げてalter databaseを実行します。

$ svrmgrl
SVRMGR> connect internal
SVRMGR> startup mount
SVRMGR> alter database archivelog;
SVRMGR> alter database open
SVRMGR> alter system archive log start;

　オンラインバックアップを行うためには、「アーカイブログモード」を選択する必要があります。どちらを使用するかは、データベースの「運用計画」とデータベースに格納されているデータの性質と重要性に大きく依存します。このモードと、2種類のバックアップ方法を組み合わせて綿密な「運用計画」を立てることこそOracleマイスターの重要な仕事となります。主な運用計画を挙げてみましょう。

■ノーアカイブログモード＋コールドバックアップ

　最も簡単で手間のかからない運用計画です。例えば、1日に一度データベースを停止し、コールドバックアップを取得する計画にします。何らかの障害が発生したときには、コールドバックアップを行った時点のデータまで復旧できます。多くの検索系データベースに適した運用です。ここでいう検索系データベースとは、1日に1回ほかのシステムから情報を持ってきて（多くは夜間処理で）日中は検索サービスのみ行うシステムのことを指しています。

　想定される運用計画は以下のようになります。

■アーカイブログモード＋オンラインバックアップ

　情報が逐次更新される、いわゆるトランザクション系データベースには、多くの場合この運用計画が必要とされます。もしノーアカイブログモードだった場合、障害発生時に前回のコールドバックアップ以降の更新情報がすべて失われてしまいます。アーカイブログモード＋オンラインバックアップで運用していれば、通常想定される障害（例えばディスク障害など）が起きても、障害発生直前までは復旧することができます。

　もちろん、そのためには綿密な運用計画を立てて復旧手段を熟知しておく必要があります。この場合、ある周期でオンラインバックアップを取り、アーカイブログファイルを削除する運用となります。

　オンラインバックアップを一度取れば、アーカイブログは基本的には必要なくなるので削除可能となります。気を付けなければいけない点は、「オンラインバックアップを取る直前までにアーカイブを終了していたものが削除できる」ということです。オンラインバックアップ中に作成されたアーカイブログは次回までは消してはいけません。アーカイブログはファイル名に連番が付くので、オンラインバックアップを開始する時点でのその番号を確認しておき、バックアップ終了後にその番号以前のファイルを削除するようにします。

　オンラインバックアップの周期は、このアーカイブログファイルを置いておくディスクスペースがどの程度確保できるかにかかってきます。アーカイブログが作成される間隔はデータベースに対するトランザクション量（データの更新量）によるので、まずこの更新量を正しく見積もることが大切です。

　机上の計算はなかなか難しいので、実際に更新処理を行ってみて、どの程度アーカイブログが作成されるか実験してみる必要があるでしょう。

■アーカイブログモード＋コールドバックアップ＋オンラインバックアップ

　上記2つの運用形態の組み合わせです。例を挙げると、1週間に一度データベースを停止してコールドバックアップを行い、1日に一度オンラインバックアップを行うという運用です。

　実際に障害が発生すると、想定しなかったことが起こりがちです。その場合、経験上データベースを復旧するためにいろいろと試行錯誤します。コールドバックアップというのは、少なくともその取得した時点には「安全確実に」戻すことができるので併用するメリットがあります。1年を通じて少しでもシステムを停止することができる期間があるのであれば、コールドバックアップを取っておくことを検討しましょう。

バックアップの取り方

■コールドバックアップ

　コールドバックアップの取り方に特に難しいテクニックは必要ありません。通常のシステムコマンド（cp）などで必要なファイルをすべてコピー、もしくはテープのたぐいに保存しておくだけです。バックアップに必要なファイルは常時確認しておいた方がよいでしょう。

　データファイルを追加した場合など、バックアップのスクリプトに追加し忘れてしまうケースがよくあります。必要なファイルは、データベース起動中に以下のSQLで持ってくることができます。OracleにSYSでログインして、sql*plusなどで実行してください。

SQL> select name from v$controlfile

SQL> select member from v$logfile

SQL> select name from v$datafile

　これらの結果として得られるファイル名をすべてコピーしておけばよいのです。

　データベースは「安全に」停止した状態を取っておくのが望ましいので、ノーマルにshutdownしておきます。通常のshutdownで終了できないような場合（大きな更新処理が動いていた場合など）は一度≪shutdown

abort≫してstartupを行い、再度ノーマルでshutdownする、といった工夫をすることもあります。

$ svrmgrl
SVRMGR> shutdown abort
SVRMGR> startup
SVRMGR> shutdown
SVRMGR> exit

■オンラインバックアップ

　オンラインバックアップでは、コントロールファイルとデータファイルをバックアップします。オンラインREDOログファイルはバックアップしません。

　データベースを復旧する場合は、アーカイブログファイル＋オンラインREDOログファイルおよびバックアップしたコントロールファイルとデータファイルのバックアップの組み合わせで復旧します。換言すると、使用中のオンラインREDOログファイルに障害が発生した場合、たとえオンラインバックアップを取っていたとしても、完全復旧は難しくなります。そのためにオンラインREDOログファイルについては、二重化やグループ化が重要となるのです。

・コントロールファイルのバックアップ

$ svrmgrl
SVRMGR> connect internal
SVRMGR> ALTER DATABASE BACKUP CONTROLFILE TO '/backup/control.backup';

　通常コントロールファイルは複数ありますが、中身は同じなので1つで十分です。

・データベースファイルのバックアップ

　実際には、テーブルスペース単位にALTER DATABASE (TABLESPACE NAME) BEGIN BACKUP文を発行し、その間にOSのコマンドでバックアップを取ります。最近ではディスクアレイを利用して、ディスクの二重化を外すことによってバックアップを行う手法もあるようです。

　終了したらALTER DATABASE (TABLESPACE NAME) END BACKUP文を発行します。

$ svrmgrl
SVRMGR> connect internal
SVRMGR> ALTER TABLESPACE (TABLESPACE NAME) BEGIN BACKUP;
SVRMGR> exit;$ cp (上記テーブルスペースに該当するデータファイル) /backup$ svrmgrl
SVRMGR> connect internal
SVRMGR> ALTER TABLESPACE (TABLESPACE NAME) END BACKUP;
SVRMGR> exit;

　これをデータベースが所有するすべてのテーブルスペースに対して行います。

　該当するテーブルスペース名は、

SQL> select name from v$tablespace

で取得できます。必要に応じてテーブルスペースを増やしたのにバックアップスクリプトに追加するのを忘れた、ということのないように十分注意しましょう。