A S T E C リレーショナルデータベース —Version 2.9 Motif のためのアプリケーシンジェネレータ db-tJIM INFORMIX Online 6 、 Online 7 ORACLE 7 対応テータベース : SYBASE 4.9. x 、 system 10 他の機種 OS についてはお問い合わせください。 HP9000 / 700 HP-UX 9.0.3 以降 動作環境 : SPARCstation SunOS 4.1 .3 以降 /SoIaris 2.4 以降、 わりました。 てが使えます。また、サポート対象のデータベースとして INFORM Ⅸが加 ⅵ、 emacs などの標準的なエデイタのサポートなど UIM/X 2.9 の新機能すべ db-UIM/X 2.9 では、初心者モード、強化された C + + 開発環境、実行モード、 すぐにテストすることができます。 データベースの入出力を含むアプリケーションのすべての機能を、開発中に 応することができます。また、 UIM / X の C インタープリタの機能を使って、 アプリケーションにも、部分的に C や SQL のコードを入力することにより対 ジェクトをマウスの操作で結び付けるだけで開発することができます。複雑な ケーションなら、 db-UIM/X の画面で GUI オプジェクトとデータベースオプ タです。データベースの検索や史新など基本的な操作だけを行うアプリ 基づいた RDB アプリケーションのためのアプリケーションジェネレー db-UIM/X は、 Motif 用 GUI ビルダーのベストセラー UIM/X に お問い合わせ先 株式会社アステック営業部〒 162 東京都新宿区南町 6 BR 市ヶ谷電話 ( 03 ) 5261-5972 ( 直通 ) FAX ( 03 ) 5261-8574 info@astec.co.jp ( E - ma ⅱでのお問い合わせは商用ネットをご利用ください。 ) E-mail : URL : http://www.astec.co.jp/DBUIMX/dbuimx29.html 資料請求 No. 059

データベースのホット・バックアッフ by Earl Jones ■ f 「 om LJNIX REVIEW 信頼匪の高い、高生能なデータベース・バックアッフ やデータ障害復旧システムを求める声は、かってないほど 大きくなっている。ホット・バックアップとは、データ べース・エンジンやアプリケーションを不力させながら実 行でき、ユーサー刎則からみると、システムがまったく通 常どおりに動いている状態で、データベースのバックアッ フ。ができるガ去のことである。 より多くの重要な情報が、 UNIX の RDBMS (Rela- tional DataBase Management System) に格糸内・管理 されるようになり、 1 日 24 時間年中無休というように、 情幸をのアクセス要求の頻度も増している。リレーショナ ル・データベースが充となっている現在の工竟では、従 来の UNIX におけるデータ・バックアッフ。方式はもはや 適当とはいえない。 RDBMS ューザーのあいだでは、ホッ ト・バックアップを主要な角夬ガ去として採用しようとい う動きか強まっている。 ・バックアップへの要望か咼まっている背景に は 2 つの要因がある。 1 つは、大規模化したデータベース では適正な時間内にオフラインでバックアップをおこなう のがもはや不可能であること、もう 1 つは、システムを運 用していくうえでデータベースか不可欠なものになってい るということである。 こでは、 UNIX における RDBMS のホット クアップに里するイ乍業、ホット・バックアップや章害 復旧プランを作成するうえて考慮すべき点、ホット ・ノ、ツ クアップを実施する際にデータベース管理者が留意すべき 点について、物理的およひ論理的な手法の両面から検討を 加えることにする。さらに、ホット・バックアッフ。方針 の立案や ( データベース・べンダー、サードバーティ あるいは両者を組み合わせた ) バックアップ・ソフトウェ 98 ア製品の尺についても触れていく。 不適当な UN Ⅸツール UNIX MAGAZINE 1996.3 旧用ユーティリティの用途は限られている。その大半は、 ない。これに対し、 UNIX のバックアップおよし斗章害復 に、テープメディア・ライプラリ全体を詩べなければなら らに、リストアされている構成要素の位置を石忍するため らディスクにコピーするためのコマンドも必要である。さ スの各構成要素については、バックアップ・メディアか きるものでなければならない。リストアされるデータベー フ。製品は、個々の UNIX ファイルを効率的にリストアで 性もある。その際に利用するユーティリテイやヾックアッ れば、ひとつひとつの UNIX ファイルを対象にする可能 場合はバックアッフ。から本をまとめて書き戻すこともあ い。ただし、データベースの構成要素を個別に復旧させる 要素は、複数の UNIX ファイルにまたがってもかまわな る。個々のテープルなど、データベースのさまざまな本友 アップ・ファイルにアクセスできるような手順が必喫であ 容のカタログ情報や、テープに内された個々のバック ホット・バックアップにおいては、すべてのテーフ。内 あるような使いやすい機能か欠けている。 やメディアの管理をはじめ、ローエンドの市販製品にすら らに、バックアップ・データの一覧であるカタログの作成 数のテープテパイスに同時に書き込むこともできない。さ のテーフ。デバイスに書き込んだりすることができない。複 ディスクから同時にデータを読み出したり、それを 1 つ い。これらはシングルスレッドで動作するため、複数の は、 RDBMS のホット・バックアップには適していな tar 、 cpio 、 dd など、 UNIX の既存のユーティリティ

グを指定できる。 ト・バックアップからの復旧は、コールド・バック アップからのリストアよりも複雑になりがちである。なせ なら、データベースの附冓成要素が異なるスケジュールで バックアップされる可能性があるからだ。障害復旧の必要 がある構成要素を特定したうえでリストアするため、デー タベース管理者はシステム管理者と協力して、障害状況に 応した対処をしなければならない。だが、データベース構 成要素お尺的にリストアできれば、障害復旧時間を冨 に矢噌できる。これがホット・バックアップを実装する うえでのもう 1 つのメリットである。 データベースの論理的破損が発生した場合は、いっそ う捉えどころがなく、鮹夬も格段に難しい。このような破 損は、ユーサーの財巣作やアプリケーション・エラーに よって間違ったデータがデータベースに書き込まれた場 合に起こりうる。いつ破損されたのか、そしてそオゞどの 程度の莫なのかを石忍するのがもっとも難しい。だが、 RDBMS の情報を復旧するためにどういう手順をとるべ きかを決定するうえで、この確認イ乍業は欠カせない。これ と同時に、原因がどこにあるのか、どのようなダメージを 受けたのか、 RDBMS のはかのアプリケーションが景グ を受けていないかといった点も考慮する必喫がある。 論理的畷員が大莫すぎて稼動中のデータベースを耐妾 イ夏できない場合は、ます景受けた構成要素を最終ホ ト・バックアップから復旧させる。次に バックアップ から取り出したデータに対して、データベースが正常であ ると分かっている時点までのトランサクション / 更新清報 ログを応央させる。燧変に、破損発 4 畤点 : までの更新清報 ログを調べ不正なトランサクションを含む部分を取り除 く際の方針を立てねばならない。これによって、磁員発生 前の状態にまて復旧できる。可能なかぎりデータベースを 復旧させたら、 RDBMS に入力されなかった情報を復旧 させる手段を考えねばならないに麪爰ドキュメンテーショ ンからの更新内容の再入力を含め、さまざまなガ去が考え られる。 パックアップの実行 UNIX MAGAZINE 1996.3 スのリストアにあるが、バックアッフ。の実行がサイトの運 バックアップ / 障害復旧プランの最終目標はデータベー Hot Backup ■ 用に大きな景をケえることを忘れてはならない。実用性 の高いデータベースは、 24 時間体制で稼動しなければな らない。このことだけをとっても、ホット・バックアッ プ方式の利点は明らかである。バックアッフ対象のデー タベースの莫と、利用できるバックアッフ。用デバイスの データ容量や速度を勘案すると同時に、その速度に遅れる ことなくデバイスを扱えるバックアップ・ソフトウェア の機能も検討しなければならない。データベースかバック アップ・モードになる時間を去鉄豆に抑えるためには、高速 性は欠かすことのできない要素である。これは、ホット・ バックアップにかかわるリスクの轤咸にもつながる。 それでは、バックアップ・メディアには何が適してい るのだろうか。磁気テープは、価格、イ生、データ容量 などの点で依然として重要なメディアである。着実に増大 していくデータベースでは、複数のテーブドライプが使用 でき、時間の矢併宿と増加する一方の利用要求に耐える機能 を備えたバックアッフ製品の採用を検詞すべきであろう。 ホット・バックアップを実行しているあいだは、ユー サーの操作に対する ) 芯りが遅くなる点に注意が必要で ある。バックアップ中もユーサーはデータベースを利用 できるが、データをディスクから読み出し、テープに書き 込むという竹業がおこなわれているため、システムの I/O 能力もそのぶん消費されている。したがって、データベー スにアクセスするユーザーへの景珈もっとも少ない時間 帯の予測か重要になってくる。 ト・バックアッフ。やトランザクション・ログのバッ クアップをおこなう場合は、どのデータがバックアップ・ メディアのどこにオ褓内されているかを管理しておかなくて はならない。ホット・バックアップならば、データベー スの破損部分だけをイ夏できる。障害からの復旧時間を短 縮するためにも、バックアップ・メディアのどこに、ど のようなデータがあるのかをに知らせる機能は不可欠 である。 ホット・バックアップを実行する場合、データベース 本をバックアップ・モードに設定するのは現実的でな い。トランサクション・ログの量が膨大になり、 UNIX のファイルシステムの限界を超えてしまうおそオ功ゞあるか らだ。 RDBMS の容量の増大を考えると、データベース の一 - 緇 ; を対象にしてバックアップをとり、それに関する更 辛用青報ログを言当求してから、別の部分のバックアップにと 101

Hot Backup 0 ティスクレ 0 について RDBMS には、さまざまなデータベース実装去がある。数 多くの〕尺肢からデータベース管理者か決めなければならない のは、ファイルの物理的なオタ手段として何を利用するかであ る。基本的に、 UNIX では 2 不鶤頁の物理ファイル構造カリ用 できる。 raw?S—ティションと UNIX ファイルシステムで ある。 raw?€—ティションを利用すると、 RDBMS はディスク 領域を直接アクセスデバイスとして使用できる。この去のお もな利点は、データベース性能力舶止することである。これに よって、パーティションに対してデータを読み書きする際の UNIX の I/O オーバーヘッドはなくなるが、 RDBMS 自体 が UNIX のファイルシステムの機能を肩代りしなけれは・なら raw パーティションを利用すれば性能は止するが、管理 は難しくなる。おもに raw'€—ティションを使う RDBMS では、テープルのサイズを大きくしたり、 RDBMS に新たな テープルを設定する作業はさらに複雑になる。どこに情報か格 納されているかを調べる場合も、構造名さえ見れは分かるわけ ではない。 一方、 UNIX ファイルシステムでは、 RDBMS はそ窈青報 を標準の UNIX ファイルとしてタできる。 RDBMS の管 理や拡張は柔軟におこなえるが、データの物理的更新の一部は UNIX の I/O システムによっておこなわれるため、データの 読み書きに関する性能低ードは避けられない。 どちらのガ去でも、テープルがバックアップ・モードに置か れた段階で、データベース・エンジンがすべての I/O バッファ RDBMS 工ンジンを用いてデータをテープルに挿入し なければならないが、物理的パックアップでは、 UNIX のファイルシステムをリストアするとデータベースの構 造も再構築される。 ・テープルの同期をとるためにトランサクション・ログを 反映させる場合は、論理重勺バックアップのはうか高速に 実行できる。なぜなら、 1 つのテープルを更新づ - るだけ ですむからである。これに対し、物理的パックアップ や復旧では、復旧された領域のすべてのテープルを更新 しなければならない。 ・物理的パックアップからの復旧は、災害状況下でも比 較的簡単である。一方、論理的パックアップからの復 旧では、データをテープルに央させる前にデータベー ス構造を構築しなければならない。 いすれの場合にも、トランザクション・ログはきわめ て重要である。物理的パックアップ、論理的パックアッ UNIX MAGAZINE 1996.3 を消去する。通常、データベースに反映されるトランザクショ ンは、あとで書き込むためにトランサクション・ログへ翻タさ れているため、バックアッフ。対象のデータベースの一貫性カイ呆 てる。 UNIX ファイルを利用する場合、データベース管理者は標準 的な命名規則を適用できるので、物理的なファイルを見るだけ で、どんな情報やテープルを使っているのかが分かる。 1 つの テープルを置く領域の拡大や、 RDBMS へのテープルの追加も 容易である。この場合、ファイルシステムにテープルを加える だけですむが、一方て性能をキ生にしなけれはならない。一部 の RDBMS では、両者を混合した竟でシステムを構築する ことかできる。このような竟では、高性能の構成要素を raw パーティションに置き、残る構成要素を UNIX ファイルシス テムに置けば、両者の利点を活用できる。 ホット・バックアップと障鬻夏旧のための方針を立案し、実 行に移すための選択肢は限られている。はとんどの UNIX の ユーティリティは、 raw パーティションを読むことができな い。さらに、サードバーティーのすべてのバックアッフ。製品で UNIX の raw パーティションを直接バックアップできるわけ ではない。その場合は、 raw'f—ティションのコピーを UNIX のファイルシステム上に作成し、それからテープメディアに移 すという作業が必要になる。 raw?S—ティションに対応してい るユーティリテイやバックアッフ。製品であれば、 raw2S—ティ ションを読んでテープにコピーする際に、より高い性能力碍ら れる。 プのどちらの手段をとるにせよ、トランザクション・ロ グはデータベースを原状に戻難リを果たしてくれるだろ う。データベースを明冓築したり、更新内容を央しよう としても、トランザクション・ログがなければ、そのデー タベースの情報はバックアップを実行した点の内容にし カ唳らない。それは間、場合によっては数日前のもの である可能性もある。したがって、ホット・バックアッ フ。の手順には、トランザクション・ログをとるという竹喋 カ哈まれていなくてはならない。トランザクション・ログ のバックアッフ。が去も丘のものであればあるはど、復旧後の データベースの情報も原状に近いものとなる。 トランザクション・ログのバックアッフ。手法は、 RDB- MS のべンダーごとに異なる。たとえば、 Oracle は、、危 ド剱 M ⅵ去 " (hight-water-mark method) と呼はれる手法 を用いている。これは、トランサクションが一定以上の大 きさになると、ログのサイズにもとづいてトランサクショ 103

去麒月的な特定のファイルシステムやディレクトリ・ツリー のバックアップ、サイト間のデータ交換、ソフトウェア 配布、個人的用途のカタログ化されていないデータのバッ クアップである。 テープメディアを定期的に交換する場合も、 UNIX の ューティリテイだけではうまくいかない。交換をスムーズ に進めるためには、すべてのバックアップ・ポリューム の位置や内容をつねに孑当屋し、カタログ化しておかねはな らない。 ホット・バックアップ UNIX MAGAZINE 1996.3 なければならない。また、バックアップの時間帯、デー ン・ログのみを対象にしたバックアップについても考慮し プをとるだけではなく、更新情報 (redo)/ トランサクショ を実施する際は、 UNIX ファイルシステムのバックアッ プも言 1 画に含めるべきであろう。ホット・バックアップ ル・バックアッフ。方式だけではなく、ホット・バックアッ ます、従来のコールド・バックアッフ。やインクリメンタ 述べるように多岐にわたる。 の言にあたり、本寸しなければならなし頓目は、以下に 信頼性の高いホット・バックアッフ。や障害復旧プラン タベース本をまるごとコピーする方式である。 バックアップを得るためのもう 1 つのガ去であり、デー を実行するガ去を好むかもしれない。これは、、コールド " な側のデータベース・ファイルのコピーからバックアップ ーリングを一判勺に中止し、ミラー化された非アクテイプ RAIDI ( ミラー ) ファイルを使っているのなら、ミラ 境でおこなうよりもさらに複雑である。 ト・バックアッフ。方針の立案と実施は、メインフレーム環 サーバー環竟、う州攵型アプリケーションを前提としたホッ 者にとっては大きな譏題となる。 UN Ⅸのクライアント・ 理するかといった点を理解することが、データベース管理 かに実行するか、バックアップ用テープメディアをどう管 いか、トランサクション・ログの頻繁なバックアップをい を実施する場合にどのような障害復旧プランを立てれはい ス・システムをいかに枷及するか、ホット・バックアップ ことである。ホット・バックアップのためにデータベー MS をつねに稼動伏態にしておきたいという要求を満たす データベースのホット・バックアップの目的は、 RDB- Hot Backup ■ タベースの運用に関する要件、ハードウェアの設置場所、 環竟全体に占める異イ重の比率、 RDBMS の物理的実装、 障害復旧のための組師勺なガイドラインなどについても検 討する必要がある。 数十ギガバイトにまで大規模化したデータベースでは、 ホット・バックアップカ印隹ーの現実的なバックアッフ。方 法であろう。個々のテープルについて、別々 ( ンヾックアッ プがとれるからである。テラバイト莫のデータか著積さ れたデータベースになると、ホット・バックアップが常 時実施されている可能がある。この場合、データベース 構成要素の一部がつねにバックアップの対象になって いる。 ト・バックアップのためのプランを日 t する際、デ ータベース管理者は、プラン全体の一貫性を保っため、ま す適正な障害復旧プランを作成すべきである。障鬻夏旧プ ランでは、異常か認められたデータベースの復旧速度と、 その際にとるべき手順の複雑さを考慮する必喫がある。ま た、テープノい麪員から自然災害まで、緊急事態に備えた対 策も検討しなければならない。 障害復旧プラン プ・スケジュールは異なる可育旨生がある。したがって、ト はないからだ。データベースの本枷友要素ごと ( ンヾックアッ にデータベースをまるごとコピーすればよいというもので ればならない。なぜなら、ホット・バックアップは、たん にあたっては、ホット・バックアップの構造を考慮しなけ るかを理解しておかねは・ならない。障害復旧プランの言 t 要素と、それらがシステム本の運用にどのように景す べース管理者は、自分カ理するシステムのファイル構成 ータベース全体の手夏が必要なケースは稀である。データ ノ、一ドウェアか沽郊章したりデータか破損された場合、デ 時間は大幅に去される。 にならざるをえないが、エラーや嶂害からの復旧にかかる 数が多ければ、ホット・バックアッフ竹喋の手順は複雑 ラーコピーが含まれる。 RDBMS のファイル構成要素の デックス、制御ファイル、またはこれらのファイルのミ には、データテープル、トランサクション・ロ久イン を十分に理解すべきである。 RDBMS のアーキテクチャ 障害復旧プランを作成する際は、 RDBMS の構成要素 99

Hot Backup ■ ン・データを自重加勺 ( ンヾックアップする方式である。 Sy- base と lnformix では、バックアッフ用のコマンドを定 期的に呼び出せるイはみになっている。 ト・バックアッフ。の機能があれは、 RDBMS 情報 のバックアッフ。間隔を去できる。データベースをオンラ イン状態に保っておけるため、より頻繁なバックアッフ。が 可能になり、障害回避長絶大な効果がある。バックアッ フ調隔の矢こより、トランザクション・ログから復旧す るデータを少なくすることもできる。 ■ バックアップ・ツールの選択 データベース・べンダーか提供するツールや、サード パーティーのバックアップ製品、あるいは両者を組み合 わせたものをホット・バックアッフ。や害復旧プランにと り入れてもよい。データベース・べンダーカ甘当るバッ クアップ・ツールは、一殳にハードウェアに依存しない ノヾックアップ・メディアを作成するため、別のホストへ の復旧も可能になる。サードバーティーの製品は、データ 処理のスルーブットやサポートするテープテンヾイスの豊富 さにおいて優れているものが多い。サードバーティーの統 合製品には、障害復旧、セキュリティ、一貫・Ⅱイ矍などの リテイかオ正できる。 管理できる。 は・ならない。 製尺にあたっては、 機能も組み込まれている。 すべてのバックアッフ、障害復旧およひ読出しのセキュ すべてのテーフが、データ保存期間の終了時まで確実に とくに以 - ドの点に注意しなけれ 方式ならユーサーか米続的にデータベースにアクセスでき データベース管理者のなかには、ホット・バックアップ 者の最高の機能が引き出せるであろう。 ムとを組み合わせたホット・バックアップ方式なら、両 ンと、サードバーティーによる高性能なテーフ。管理システ う。 RDBMS べンダーか開発したバックアッフ・エンジ のテープカートリッジ・ライプラリを利用してもよいだろ バックアッフ。用の機器やテーフ。装置を製造している会社 ・メディアの I/O 工ラーの j 跡機能がある。 ・サイト外に保存しているテプと容易に交換できる。 104 るので、バックアップ・ソフトウェアにそれはど高い性 能を求めなくてもよいと誤解している人もいる。そういう 考え方にもとづいて、現在の RDBMS のバックアッフ・ ーズに対応するソフトウェアを選んだり、バックアッ プやテーフ。管理に関するサイト本のニーズを考慮しない のは近ネ期期勺である。複数のテープに対して同時に読み書 きしたり、複数のデバイスを同時に扱うことができれは、 バックアッフ。や障害からの復旧能力か高まる。このような 技術を用いたバックアップ製品への投資は、結果としても たらされるシステム運用上の利益を考えれば一ト分な価値が ある。 ホット・バックアップでいう咼性能とは、ユーザーに える景グの咸を意味する。勺なバックアッフ判日 を矢可宿できるし、データベースのバックアップをとってい るあいだにトランサクションのキューに入っているデータ の量を減らせるので、より頻繁にバックアッフ。かま行でき る。さらに高匪能のテンヾイスがあれは、ド害復旧に必要な 日判りも知嘯打できる。障害からの復旧に要する日判りを可能な かぎり矢したいのなら、バックアッフ・テープをいちい ち巻き戻さなくても、必要なデータを 1 回の操作で読み出 せるような製品が必要である。 復旧したデータを別の領域に置かなくてはならない場合 は、復旧される場所に応してデータベースの構造を変えた り、名前を変史できるようなイはみを実現しなけ川まなら OracIe では、ホット・バックアップを非公式に、、曖 ltk"(fuzzy) と呼んでいるが、これはデータの一貫性に問 題があるということではない。データベースのテープルの 精確度は、バックアップ実行時に生成されるトランザク ション・ログの一貫性とその適正な反映に依存するという 意床である。適切な復旧をおこなうためには、これらのト ランサクション・ログやテープルがバックアップされて いなければならない。 統合復旧プラン UNIX MAGAZINE 1996.3 を確して、はじめて未をなすものである。統合プラン フ着理など、勺なニーズをネ f に入れた統合的な去 ごく一碚にを構成しているにすぎない。バックアッフ。やテー ホット・バックアップ自体は、障害復旧プラン全体の

Hot Backup ■ ランザクション・ログと照合して、データベース・システ ムの一部だけを復旧しなければならないかもしれない。 障害復旧プランを作成する際には、利用している物理的 な記慮装置の構造や、 RDBMS 構成要素の論理釣な位置、 RDBMS の障害復旧竹喋にかけてもよい平均的な許容時 間を検詞する必要もある。障害復旧プランの設言段階でこ れらを検討すれば、ホット・バックアップの方法や標準 的な手法も定めることかできる。 ロ ホット・バックアップからの復旧 ロ トランサクション・ログの復旧 障害復旧の目的は、 RDBMS 内の情報を一定時間内に できるかぎり原状に近いかたちに戻すことである。したが って、ホット・バックアップを実行する場合には、トラ ンザクション・ログのバックアッフ。や管理がきわめて重 要な意床をもつ。バックアップ・メディアから RDBMS 及要素をリストアした場合、 RDBMS はバックアッフ を実施した時点の状態に戻る。バックアップを実施したあ とに更新された内容をすべて復旧させるためには、データ べースの更新を言当求するトランザクション・ログを常時と るようにしておく。 RDBMS の一貫性を保っとともに、情報の夏のスピ ードアップを図るため、 1 日 24 日判町木みなくトランザク ション・ログを監視し、バックアップをとるようにする。 その頻度によって、危険な日判り帯气 wind 。 w of vulnera- b ⅲ ty ) か訣定する。 1 時間ごとにトランザクション・ログ のバックアップがとられるデータベースでは、最悪の場合 でも 1 日判前の状態窈青報を復旧できる。トランザクショ ン・ログのバックアップを 30 分ごと、あるいは 15 分ご とにおこなってもよい。運用の負担にならない範囲で、で きるだけ頻繁に実施すべきである。 残念ながら、システム障害はいつでも起こりうる。バッ クアッフ。の最中に起こるかもしれないし、障害復旧竹喋中 に発生することもあるだろう。あるいはホット ・ノヾック アップに続く更新作業中に起こる可能性もある。つまり、 システム運用のあらゆる段階において、ハードウェアやソ フトウェア障害を検知し、復旧させる町寉なプランを作成 しておかねは・ならない。 100 ホット・バックアップの夫施は、バックアップにかか る日判りの矢聾宿につながるばかりでなく、より頻繁にバック アッフ。の実行が可能になる。障鬻夏旧時には、景を受け たテープルの最終バックアップの時点までリストアし、そ れ以降に生成されたトランサクション・ログを央させれ は作業琲間の矢宿か図れる。ホット・バックアッフでは、 ューサーはオンラインで RDBMS を継続して利用できる ので、より頻繁なバックアッフ。が可能になる。 バックアッフ。の間隔が空くと、障害復旧にかかる時間 も増大する。というのは、最終バックアッフ。以降の更新 情報をすべてデータベースに反映させなければならないか らだ。斑央させる更新内容か少ないはど障害復旧も早く終 る。イ乍業の過程が複雑で慎重なプランニングを要するもの であっても、ホット・バックアップを利用すれば、企業 にとって重要な情報をより安全に保つことができる。 データベースの障害には、一イ勺に 2 つの形態がある。 もっともよくみられるのが、データベースの物理章害で ある。 ードウェアの古郊章やユーザーのミスにより、デ ータが壊れたり損傷を被るケースだ。もう 1 つは、ユー サーやアプリケーションによる論理工ラーが原因の障害で ある。これはデータベースを更新しなかったり、データ べースの勵里ファイルやテープルのすべてを適切に更新し なかったために起こる。復旧には、それぞれ異なる対処が 必要である。 データベースか物理的ダメージを受けたり UNIX のフ ァイル構造か破壊された場合、その復旧ガ去は屯である。 ます、バックアップ・メディアから破損された部分のテー プルをリストアする。そして、正しいトランサクション・ ログ ( 更新情報 / 監査ログとも呼はれる ) を復旧したテー プルと照合し、データベースのほかの構成要素との同期を とる。 Oracle を使っている場合は、損傷箇所のテープル の復旧に必要なアーカイプされた更新情報ログ名か得られ るし、さらにどんな、、非同期 "(out-of-sync) 状態も処理 できる。非同期状態には、たとえは復旧したテープルファ イルがそれに対応した制御ファイルと合致しない場合か考 えられる。その場合 Oracle では、復旧するテープルを データベースのはかの部分と同期させるための更新情報ロ UNIX MAGAZINE 1996.3

図 1 WISHBONE 磅新星迂可蚤路 衛星回 九州大学 通信衛星 広島市立大 北陸先端大 みー慶應義塾大学 : ・・地上回線 衛星回線を用いて、次のリンクか張られた ( 図 1 ) 。 WIDE 京都 NOC—奈良先端科物支術た / 続た学 : ー奈良先端不斗学我術大完た ーびを先立科学オ支神 i. 大凝完 . た学 奈良先端大 ル、 l'l 大学 広島市立大学 〕山に切り替えた。 122 トを利用して生存者情報を登録、検索できるようにする ある。 IAA 訓練は、訓練参加者が . 災售時にインターネッ IAA とは、、 I Am AIive" ( 私は生きている ) の略称で IAA 訓練 予定である。 訓練の詳細な成果については機会をあらためて報告する 応ガイドラインの策定などへとつなげてゆきたい。なお、 地ーは各一衛扉迂回経路の自動切替え技術の確立、災害対 もとに、災畤に緊急利用できる通信衛星の回糸寉保や、 集できた。こうした訓練を通して得られたデータや経験を らに、今後のネットワーク構成に関する貴重なデータも収 ご理解も得て、はは完全な成功を収めることができた。さ をいただき、インターネット運用組織各方面のご協力と たにもかかわらす、多数のユーサーからの励ましの言葉 ターネットの利用者にとってはまことに迷惑な訓練だっ 運用中のネットワークを故意に切断するという、イン 4 ! 事読川練を終えて通常の地十澣糸黶習、復帰させた。 た。この状態を約 3 ほど糸し、同日午前 9 時には インターネットのバックポーン・ネットワークを回復し よって WIDE 京都 NOC は孤立状態から脱し、 WIDE 回線切断後、当初の引どおり 30 分以内に衛星経路に 図 2 登録および用アドレス 登録用アドレス touroku@iaa.wide.ad.jp http://www.iaa.wide.ad.jp/touroku.html 用アドレス kensaku@iaa.wide.ad.jp http://www.iaa.wide.ad.jp/kensaku.htrnl ことを目的とした。訓練参加者からせられた生存者情報 を管理するデータベースは、、、生存者情報データベース " ( 以降、 IAA データベース ) と呼ぶ。 阪神・淡路大震災では、被災地に居住する親類や知人 の安否を石忍する電言肋リして電話網かマヒしてしまっ た。その結果、被災地内での緊急漣絡や被災地外への状 況報告などに電話網か利用できないという事態を招いた。 IAA データベースのそもそもの構想は、このときの反省 にもとづいている。 IAA データベースの目的は、生存者 情報を被災地の外側て提供し、被災地外から被 . 也内への トラフィックを軽減することにある。 IAA 訓練では、インターネットの利用者か被災者にな った状況を想定し、 IAA データベースへの被災者の生存 者情報の登録およひ検索をおこなった。この訓練は、 1 月 17 日午前 5 時 46 分から 1 月 19 日午前 0 時まで、およ そ 2 日間にわたって実施された。 登録に利用された IAA データベースは、びを先端抔斗学 : 技術大学院大学、奈良先端科 ! 物支術大 ! 凝完大学、 WIDE 京都 NOC 、慶應滝 & に冫に設置されている 4 つの IAA クラスタ 4 につき氏 1 っすっ提供さすべてのクラス タで同一の生存者情報のデータカ甘是供できるように、登録 時には各クラスタ間で同期処理がとられた。 イ瓦想的な被災者の生存者情報の登録・検索は、図 2 のア ドレスに対して電子メールまたは WWW によっておこ なわれた。 登録される生存者情報は、本名、状況、石忍手段、情 是供者からなる必彡頁目と、年齢や生別など任意頂目か ら構成された。必彡頁目は、生存者情報データベースとし て一一 1 定以上の品質を保っために必要な項目である。たとえ ば、情是 0 緒、と石忍手段に関する項目は、検索者が受け 取った生存者情報の信生をはかる尺度として提供され るべきだと考えられた。このため、必彡ル頁目の入力を無 4 IAA データベースを提 fk$ る複数台の計算機から攤及された訓練用実験 システム。今回の訓練では SPARCstation2 x 2 台て十及さオびこ UNIX MAGAZINE 1996.3

Hot Backup ■ りかかるような手法を確立しておかねはならない。バック アップに備えてデータベースをいかに論理的な構成要素に 分割するかを考える場合は、どのような情報カ呶められて いるかだけではなく、里する情報をグルーフイヒできるか どうかも調べる。そうすれは障害からスムーズに復旧でき るし、手夏したデータの一貫性も保てる。 ト・バックアッフ環竟では、テープライプラリの 管理やそれに里する作業をソフトウェアで自重加勺に実行 できる体制が不可欠である。これは、バックアップ・メ ディアをイし、コピーをサイト外に保存する場合に重要 である。バックアップ・テーフ。がどこに管理されていて、 どんな情幸師ゞ収められているかという言泉も必要である。 ■物理的パックアップと論理的パックアップ データベースのホット・バックアップには、物理的な ものと論理的なものがある。ホット・バックアップは、各 RDBMS に固有のメカニズムを用いておこなわれるため、 どちらか 1 つのカ試しか利用できないことがある。論理的 バックアップをおこなう RDBMS では、物理第勺記慮構造 のバックアップは本質的にコールド・バックアップとみ なされる。この場合、障害復旧とはデータベースを、、すべ て " 復旧させることを意味する。大莫なデータベースで は、障害復旧に要する日判りを考えると、尺肢から外した はうが無ま隹である。 物理的パックアップとは、データベースで使われる物 理第勺記慮メカニズム (raw パーティションまたは UNIX ファイル ) を読み出し、それをバックアップ・メディア ( 通常はテーフ ) にコピーすることである。 Oracle などの ように、使用している RDBMS か物理的ホット ・ノヾック アップをサポートしている場合は、いくっかの段階が必要 となる。ます、目的のテープルをバックアップ・モードに 置く。この際、該当するテープルに関する更新情報はトラ ンザクション・ログに言求される。テープルカ芍直正 ( ンヾッ クアップ・モードになったら、物理構造がバックアップ メディアにコピーされる。バックアッフ。カ鮗ると、テープ ルはバックアップ・モードから抜け、トランサクション・ ログに置かれていた更新部うゞテープルに央される。 この手法では、データベースがデータの格納に利用す る UNIX のファイル構造を物理的にバックアップする 102 が、すべての RDBMS で可能なわけではない。物理的 バックアップカ坏可能な RDBMS では、論理的パック アップをおこなう。この手順は、物理レベルでテープルの ホット・バックアップをサポートする RDBMS でも使 える。論理的パックアップを実行する際は、 RDBMS べ ンダーカ甘是供するユーティリティを使って RDBMS テー プルから情報を取り出す。これらの手順を、、取出し / 取 込み '(export/import) 機能と呼ぶ。 論理的ホット・バックアップも、物理的パックアップ と同本 ) 手順て夫行する。テープルをバックアップ・モー ドにして、データをバックアップ・メディアに書き込む。 その後テープルはバックアップ・モードを終了し、トラ ンサクション・ログからの更新がおこなわれる。 いくっかの理由で、ホット・バックアッフ。の実行時に これら 2 つの方式を併用することがある。論理的パック アップを使えば、データベースのテープルを個別に復旧で きるし、物理重勺バックアップでは、テープル用の領域とそ こに含まれるすべてのテープルの復旧が可能になる。ホッ ト・バックアップを実行する際、論理的、物理的、ある いは両方を併用した手法のどれを使うかは、バックアップ 対象の清報の不亜頁を考慮して決定する。 ・変更頻度の低いテープルでは、そのテープルの論理勺バ ックアップを実行する。 ー殳に、論理的パックアップより物理的パックアップ のほうか咼速である。データベースからバックアップ・ メディアにコピーするとき、 RDBMS 工ンジンを用い たデータ抽出をおこなわないからである。 独立していて、はかのテープルとの論理的関係をもたな いテープルは、論理的パックアッフ。の一嚇甫とみなして よい。 ・論軸勺バックアップでは、テープルを復旧する前にデー タベース構造を再構築しておかなくてはならない。した がって、テープル用の領域とそこに収めるテープルを生 成する必要がある。その後、バックアップ・メディア からとったデータをテープルに挿入する耳石ムみイ乍喋をお こなえばよい。 物理的パックアップでは、リストアをおこなうとデータ べース構造か眄構築される。 ・物理的な復旧は高速である。論理的パックアップでは UNIX MAGAZINE 1996.3

図 4 生存者情報の登金新牛数の時間キ多 図 3 、Ⅵ厂 W ・による生存者情報の登録 登録者 ( 被災者 ) に関する記入欄 : 姓 : 馬場 第 : ばば ーともみつ ーー baba@is . a i S 1 はにい ー bunny イも 年を 3 0 : 郵便番号 631 西大寺南町 ィ主 ! 奈良県奈良市 数以 - E の回数にわたっておこなわれた。これは、訓練参 加者が IAA データベースへぶじに求されたかどうかを 所 : 奈良粁斗学技術大学院大学 知るためには、検索の結果をもって判断するしかなかっ 起さていたザ寝ていた未る思 たからである。図 5 は、電子メールで返答される検索結果 の例である。この例では、訓練参加者の baba@is.aist- 1996 年 1 月 17 日 5 時 30 分 nara ・ ac. jp さんが、名前、性別、年齢、郵便番号を検索 キーに指定して IAA データベースを検索した結果、 IAA 視した生存者情報の登録は受け付けないようにシステム クラスタである iaa-sfc-db から該当する情報が 1 件みつ を言 t した。一方、通称、性別、年齢などのイ毛頁目は、 かった旨の回答が返ってきている様子が示されている。 生存者情報を検索する際のキーとして利用された。 IAA 訓練では、延べ 6 , 000 人以上の登録を得て、 IAA 電子メールによる登録・検索の場合は、あらかじめ のような特殊な要求をもっデータベースのアーキテクチ touroku-form@iaa.wide.ad.jp か kensaku-form@iaa ャ、システム本鞠友、オペレーション、ヒューマン・イン . wide. ad. jp へ電子メールを送り、登録・検索フォーマッ ターフェイスなどに関する貴重なデータを収集すること トを入手したうえで各情報を記してもらった。図 3 は、 かて、きた。 WWW の検索用 URL を利用して生存者情報を登録中 の画面例である。 訓練を終えて IAA 訓練では、 WISHBONE 訓練と歩調を揃えて 1 月 17 日午前 5 時 46 分に求受イ寸けを開始したが、直後 今回の訓練では、 2 つの大きな成果が得られた。 1 つ に第 1 号にあたる IAA データベースへの登録メールが は、実際に稼動しているネットワーク上で多くの方々の 舞い込んだ。このとき、 IAA システムのオペレータたち 協力のもとに訓練を実施し、それによってシステムへの は思わす歓声を上げた。 フィードバックを得たことである。もう 1 つは、訓練を 図 4 は、 17 日午前 6 時から 19 日午前 0 時にかけて、 通して、 WIDE プロジェクトとはこれまで関係のなかっ www および電子メールを通して入力された生存者情報 た多くの方々と意見を交える機会がもてたことである。 の時間ごとの登録件数を示している。この図からも分か 生存者報の入力欄に、、御意見 " 欄を設けたところ、は るように、開女都芋刻が早朝だったにもかかわらず、 IAA とんどすべての参加者が今回の訓練に関する感想や提案、 データベースに登録される生存者情報は順調な伸びを示 また励ましの言葉を記入されていた。とくに、この訓練 ーこうして当求された生存者情報は、 2 日間を通して の結果や成果をぜひ公開してはしいと強く要望される意 約 6 , 000 人ぶんにおよんだ。 見が目立った。一方で、 IAA 訓練用実験システムでは予 一方、検索はすくなくとも IAA データベースへのる当求 ↑ 3 ( ) 0 件 250 数 200 第加「 150 男性マ女性 50 0 0 時刻→ 麕 に 6 0 12 6 必ー須 123 UNIX MAGAZINE 1996.3