Oracle Database 10g High Availability

Transcription

1 Oracle Database 10g High Availability オラクル ホワイト ペーパー 2004 年 4 月

2 Oracle Database 10g High Availability 概要 企業では その情報技術 (IT) インフラストラクチャを使用して競争力を高め 生産性を向上させ より多くの情報をユーザーに提供して 迅速な判断を可能にしています ただし これらの長所には そのインフラストラクチャへの依存度が高まるという短所も伴います 重要なアプリケーション サーバーまたはデータが使用できなくなると 企業全体が危機的状態に陥りかねません そうなると 収益や顧客を失い 不利益が発生し 悪評による顧客の印象や企業イメージが長期的にダメージを受けるおそれがあります 現在の変化の激しい経済環境で 企業が成功し健全な状態を維持するには 可用性の高い ITインフラストラクチャの構築が不可欠です コンピューティング技術における傾向として グリッド コンピューティングと呼ばれる新しい ITアーキテクチャの配置も可能となっています グリッド コンピューティングは 企業のあらゆるコンピューティング ニーズに応じて 多数のサーバーとストレージを柔軟なオンデマンド コンピューティング リソースに効率よくプーリングする 新しいコンピューティング アーキテクチャです 低コストのブレード サーバー 小型で安価なマルチプロセッサ サーバー モジュール化されたストレージ技術 および Linux を始めとするオープン ソース オペレーティング システムなどの技術革新が グリッドの原動力となっています 企業は これらの技術を組み合せ Oracle Database 10g で使用可能なグリッド技術を活用することで 非常に高品質のサービスをユーザーに提供しながら IT コストを大幅に削減できます Oracle Database 10g により パフォーマンス スケーラビリティ セキュリティ 管理性 機能性およびシステム可用性を犠牲にすることなく グリッド エンタープライズ コンピューティングのコスト メリットを享受できます このホワイト ペーパーでは まず 停止の原因を調べます 次に Oracle Database 10g の新機能を特に重視しながら Oracle データベースで使用可能な技術を検証します この新機能により コストの高い停止の回避 および予防できない障害からの迅速なリカバリが可能になります 停止の原因 可用性の高い ITグリッド インフラストラクチャを設計する際の課題のひとつは 考えられるあらゆる停止原因を調べ解消することです 図 1 では 停止を計画外停止と計画停止の 2 つの主なカテゴリに分類しています フォルト トレラントでリジリエンスがある ITインフラストラクチャを設計する際は 計画外停止と計画停止の両方の要因を考慮する必要があります Oracle Database 10g High Availability 2

3 図 1: 停止の原因 計画外停止は 主にコンピュータ障害またはデータ障害が原因で発生します 計画停止の理由は 主に本番システムでの実行が必要なデータ変更またはシステム変更です 次の各項では これら 4 つの停止の理由を調べ それらの回避に対応できる技術を検証します コンピュータ障害に対する保護 コンピュータ障害は コンピュータ システムまたはデータベース サーバーに予期しない故障が起こり サービスが中断される場合に発生します この原因は通常 ハードウェアの故障です この障害に最も有効な対策は 高速データベース クラッシュ リカバリおよびクラスタ技術です 図 2: コンピュータ障害 Real Application Clusters を利用したエンタープライズ グリッド 企業は Real Application Clusters(RAC) を使用することで 可用性とスケーラビリティに優れたデータベース サーバーを複数のシステム間に構築できます Real Application Clusters 環境では Oracle はクラスタ内の複数システム上で動作し 単一の共有データベースに同時アクセスします このため 複数のハードウェア システムに分散しているにもかかわらず アプリケーションには単一の統一されたシステムとみなされるデータベース システムが実現します このシステムにより あらゆるアプリケーションの可用性とスケーラビリティが大幅に向上します Oracle Database 10g High Availability 3

4 柔軟かつ低コストの容量計画が可能になり ニーズに応じて さらにはビジネス ニーズの変化に応じて システムを任意の容量に拡張可能 クラスタ内の障害 特にコンピュータ障害に対するフォルト トレランスを実現 Real Application Clusters により エンタープライズ グリッドが可能になります エンタープライズ グリッドは プロセッサ サーバー ネットワーク ストレージなどの標準化された 市販コンポーネントで構成される大規模システムです RAC は これらのコンポーネントを組み合せて 企業に有効な処理システムを構築できる唯一の技術です Real Application Clusters およびグリッドは 運用コストを大幅に削減し これまでにない柔軟性を実現して システムに適応性 事前対応力および高速性を追加します ノード ストレージ CPU メモリーを動的に提供することにより サービス レベルを単純かつ効率的に維持する一方 使用率を高めてコストをさらに縮小できます また Real Application Clusters は RAC データベースにアクセスするアプリケーションには完全に透過的であり RAC システム上に配置するための変更が一切不要です Real Application Clusters により ユーザーは容量アップの必要性に応じてノードをクラスタに柔軟に追加できます また 段階的なシステムの拡張が可能になり 小規模な単一ノード システムから大型のシステムに移行が必要ないため コスト削減が可能になります 標準低コスト コンピュータとモジュール式ディスク アレイで構成されるグリッド プールに Oracle Database 10g を実装することにより このソリューションはより強力になります また 容量の追加も迅速で容易になります 既存システムをより大型の新しいノードとの交換ではなく ノードをクラスタに追加することでシステムをアップグレードできます Real Application Clusters に実装されているキャッシュ フュージョン技術により アプリケーションを変更することなく容量をほぼリニアに拡張できます このクラスタ アーキテクチャのもう 1 つの重要な特徴は 複数ノードにより実現するフォルト トレランスです 物理ノードがそれぞれ独立して実行されるため 1 つまたは複数のノードで障害が発生しても クラスタ内の他のノードは影響を受けません フェイルオーバーはグリッド上のどのノードでも実行できます 極端な例をあげると 1 つのノードを除く全ノードが停止しても Real Application Clusters システムによりデータベース サービスを提供し続けます このアーキテクチャにより 一部のノードを透過的にオンライン化またはメンテナンス目的でオフライン化が可能であり その場合にも クラスタ内の他のノードがデータベース サービスの提供を継続します RAC は Oracle Application Server 10g との統合により 接続プールのフェイルオーバーを実現します このため アプリケーションは障害が発生と同時に通知を受け TCP タイムアウトが起こるまで何十分も待つ必要はありません アプリケーションは 即時に適切なリカバリ処置ができます そして グリッド ロード バランシングで ロードが次第に再分散されます Oracle Database 10g High Availability 4

5 Oracle Database 10g の Real Application Clusters は クラスタを管理するための完全なクラスタウェア セットも提供します Oracle データベース クラスタウェアは ノード メンバーシップ メッセージ サービス ロックなど クラスタの実行に必要な全機能を提供します また このスタックは一般的なイベントおよび管理 API と完全に統合化されているため Oracle Enterprise Manager から集中管理できます クラスタのサポートに追加のソフトウェアを購入する必要はなく 製品間の調整も軽減され エラーを回避できます さらに Oracle データベースが使用可能なすべてのプラットフォームで 一貫したインタフェースおよび動作が保証されます オラクルは RAC によるサードパーティ製クラスタウェアのサポートも継続します RAC は また サービス と呼ばれる新しい抽象概念もサポートします サービスは データベース ユーザーまたはアプリケーションのクラスを表します ピーク処理時のノードの割当てやサーバー障害の自動処理といったタスクを実行するために ビジネス ポリシーが定義され これらのサービスに自動的に適用されます その結果 システム リソースが ビジネス目標の達成に必要とされる場所およびタイミングで適切に割り当てられます 廉価な汎用コンポーネントを使用したパラレル ハードウェア システムは データ集中型の意思決定支援アプリケーションにおいて 従来のメインフレーム システムよりも優れたコスト パフォーマンスを実現する場合もあります 密結合対称マルチプロセッサ システム (SMP) は 最も広範に使用されてきたパラレル ハードウェア システムです このシステムは 共通メモリーおよびディスク リソースを共有するマルチ プロセッサを利用するため シェアードエブリシング型 システムとしても知られています SMP システムの主な特徴には アプリケーション開発の簡単さ 容易な管理などもあげられます ただし このシステムには固有のフォルト トレランス機能がありません このため CPU などのクリティカル コンポーネントの 1 つで障害が発生すると システム全体がダウンする場合があります さらに 現在 使用可能なシステム バスの帯域幅およびオペレーティング システム ソフトウェアのスケーラビリティに制限があるため スケーラビリティや拡張の面で多少限定されています データベース クラッシュ リカバリ時間の特定 計画外停止の最も一般的な原因の 1 つは システム障害またはクラッシュです システム障害は ハードウェア障害 電源障害 およびオペレーティング システムまたはサーバーがクラシュします このような障害が引き起こす運用中断の規模は 影響を受けるユーザーの数と サービスを復旧するまでの時間で決まります 高可用性システムは 障害発生時に迅速な自動的リカバリを可能にする設計がされています 重要なシステムのユーザーが IT 組織に求めているのは 予測可能な時間内に迅速に障害からリカバリできる保証です 停止時間が保証された時間を超えた場合 運用に直接影響を及ぼし 収益と生産性の損失につながるおそれがあります Oracle データベースは システム障害およびクラッシュからの非常に高速なリカバリを可能にします さらに 高速性と同様に重要なのが 予測可能性です Oracle データベースに含まれるファスト スタート障害リカバリ テクノロジは データベース クラッシュ リカバリ時間を自動的に抑制する Oracle データベ Oracle Database 10g High Availability 5

6 ースの固有の機能です この機能により データベースはチェックポイント処理を自動調整し 目標とされるリカバリ時間を守ります このため リカバリ時間が高速かつ予測可能になり サービス レベル目標の達成が容易になります Oracle のファスト スタート リカバリ機能は 負荷の高いデータベースのリカバリ時間を 数十分から 10 秒未満に短縮します データ障害に対する保護 データ障害は 重要な企業データの損失 損傷または破損を意味します データ障害の原因は コンピュータ障害の原因より複雑で難解であり ストレージ ハードウェアの障害 人為的エラーまたはサイト障害による場合があります 図 3: データ障害 データ障害に対する保護および障害からのリカバリを可能にするソリューションの設計が重要です システムまたはネットワーク障害により データへのアクセスが不可能になりますが 適切なバックアップまたはリカバリ技術がない場合のデータ障害は リカバリ時間の長期化や データ損失につながるおそれがあります Oracle Database 10g では データ保護機能が大幅に拡張されています このような多数の拡張の要因は データ保護およびリカバリを取り巻く新しい経済環境です この 20 年間で ディスク容量は 3 桁増加しました 1980 年代初頭では 200MB のディスクが最新でしたが 現在の最新ディスクは 200GB であり この容量の増加傾向は今後も続きます 500GB または 1TB のディスクも近いうちに入手可能になるでしょう この傾向の裏で ディスク ストレージの価格は下がり続けています ディスク容量の増加に伴い メガバイト当たりのストレージのコストは 現在数円のレベルにまで下落しています この結果 ディスク ストレージが非常に安くなり バックアップ メディアとしてテープよりも安価です さらに ディスクにはオンラインである すなわち遅延なく常時使用可能であるという別の利点もあり データにランダム アクセスできます このような傾向を受けて オラクル社はこのような経済的な背景を利用するリカバリ戦略の再考および再構築を行いました ディスク ストレージを Oracle で使用可能にすることで バックアップおよびリカバリ時間を数時間から数分へと短縮できます つまり 廉価なディスク ストレージにより コストの高い停止時間を回避できます Oracle Database 10g High Availability 6

7 ストレージ障害に対する保護 企業全体に対してはもちろん シングル インスタンス データベースに対してストレージをプロビジョニングすることも 複雑になる場合があります 通常 このプロセスに含まれる作業としては 必要とされる領域の容量予測 最適なレイアウトの計画 ( 問題箇所を排除するデータ ファイルやアーカイブ ファイルなどの配置 ) 論理ボリュームの作成 ファイル システムの作成 データを保護しミラー化する方法の定義とセットアップ そのデータに対するバックアップおよびリカバリ計画の定義と実行 Oracle のインストール そして最後に データベースの作成です この後で パフォーマンスに悪影響を与える問題箇所の特定や データ ファイルの移動による競合の削減といった困難な作業が始まります そして ディスク クラッシュが発生したり領域が不足して ディスクの追加が必要になり 更新したストレージ構成を再調整するために全ファイルの再移動が必要となる状況に備えることも考えられます ただし このような状況は Oracle データベースの Automatic Storage Management (ASM) という新機能によって改善されます ASM は 垂直統合されたファイル システムとボリューム マネージャを Oracle カーネルに直接提供するため データベース ストレージのプロビジョニング作業が大幅に軽減されます そして 高可用性が実現し 特別なストレージ製品の購入 インストールおよびメンテナンスが不要になり データベース アプリケーションに固有の機能が提供されます ASM は ASM ファイルを使用可能な全ストレージに分散してパフォーマンスを最適化し ミラー化も実行できるため データ損失に対する保護機能となります ASM は ディスク全体のミラー化が必要なく データベース ファイル レベルで行えるという点で SAME(Stripe And Mirror Everything) 概念を拡張し 柔軟性を高めています ただし より重要なのは ASM がデータおよびディスク管理の複雑な作業を取り除き ミラー化の設定 ディスクの追加および削除というプロセスを大幅に簡略化することです ASM を使用するデータベース管理者は 数百 または大規模データ ウェアハウスの場合 数千単位のファイルを管理するかわりに より大きい単位のオブジェクトであるディスク グループを作成して管理します このディスク グループは 1 つの論理単位として管理される一連のディスクを識別します 基盤となるデータベース ファイルの命名と配置が自動化されるため データベース管理者の作業時間が短縮され データベース管理者はベスト プラクティスの標準に確実に従うことができます ASM に固有のミラー化メカニズムは ストレージ障害に対する保護として使用されるオプションです デフォルトでは ミラー化は使用可能で トリプル ミラー化も使用できます ASM のミラー化では 障害グループを使用することで データ保護を強化できます 障害グループとは その障害を許容できる 共通リソース ( ディスク コントローラまたはディスク アレイ全体 ) を共有する一連のディスクです ASM 障害グループを定義すると このグループはデータの冗長コピーを別の障害グループにインテリジェントに配置してデータを使用可能にし ストレージ サブシステム内のコンポーネントで障害が発生した場合にデータを透過的に保護します ASM はさらに Hardware Assisted Resilient Data 機能 ( データ破損に対する保護 の項で説明) もサポートし データを強力に保護します Oracle Database 10g High Availability 7

8 人為的エラーに対する保護 停止時間の原因に対する様々な調査では 停止時間の最大の単一の原因として 人為的エラーをあげています 不注意による重要データの削除や UPDATE 文の不適切な WHERE 句により 意図した以上の行が更新されるなどの人為的エラーを可能なかぎり防止し それに対する予防措置が取られない場合は 元に戻す必要があります Oracle データベースは このようなエラーに 管理者がそのエラーを迅速に診断してリカバリする使いやすく強力なツールを提供します また エンド ユーザーが管理者の介入なく問題からリカバリする機能も装備しているため データベース管理者サポート作業が削減され 損失データや損傷データのリカバリが高速化されます 人為的エラーに対するガードエラーの防止に最も有効な方法は ユーザーのアクセス権をそのユーザーの仕事に必要なデータおよびサービスのみに限定することです Oracle データベースが提供する幅広いセキュリティ ツールを使用すれば ユーザーを認証し 各自の仕事に必要な権限のみを管理者がユーザーに付与することで アプリケーション データへのユーザー アクセスを制御できます また Oracle データベースのセキュリティ モデルは Virtual Private Database 機能を使用してデータ アクセスを行レベルで制限できる機能を提供し アクセスの必要がないデータからユーザーをさらに分離します Oracle フラッシュバック機能許可されたユーザーがミスを犯した場合 そのエラーを修復するツールが必要です Oracle Database 10g は 人為的エラーを修復するテクノロジ ファミリを提供します これはフラッシュバックと呼ばれ データ リカバリの先進的テクノロジです 以前は データベースの破損が数分で発生したにもかかわらず そのリカバリには数時間かかることがありました フラッシュバックを使用することで エラー発生にかかった時間と同等の時間内でエラーを修復できます また フラッシュバックは非常に使いやすく 単一の短いコマンドを使用してデータベース全体をリカバリできるため 複雑な手順は必要ありません フラッシュバックは 人為的エラーを迅速に分析および修復できる SQL インタフェースを提供します 顧客オーダーを誤って削除した場合などの部分的な障害には きめ細かい分析と修復を行います また ある月の全顧客オーダーを削除した場合などの より広範囲にわたる障害も短時間で修復し 停止時間の長期化を回避します フラッシュバックは Oracle データベース固有の機能であり 行 トランザクション 表 表領域およびデータベース全体といった あらゆるレベルでのリカバリをサポートします フラッシュバック問合せ Oracle フラッシュバック問合せは Oracle9i Database で導入された機能であり 管理者やユーザーによる過去のある時点のデータの問合せを可能にします この強力な機能を使用することで 誤って削除または変更された可能性のある損失データを参照し再構築できます 例を示します Oracle Database 10g High Availability 8

9 Select * from EMPLOYEE as of 2:00 P.M. where... この文は 本日午後 2 時時点の EMPLOYEE 表の行を表示します 開発者はこの機能を使用して セルフサービス エラー修復機能をアプリケーションに追加できるため エンド ユーザーは自分のエラーを遅延なく元に戻して修復できるようになり 管理者がこのタスクを実行する必要がありません これは データベースが必要な情報を自動的に保持し 過去のある時点のデータを再構築するため フラッシュバック問合せの管理は容易です フラッシュバック バージョン問合せ フラッシュバック バージョン問合せは データベースの変更を行レベルで参照できるようにします これは SQL の拡張機能であり 指定した時間範囲での 特定行の異なるバージョンをすべて取得できます 例を示します Select * from EMPLOYEE versions between 2:00 PM and 3:00 PM where この文は 本日午後 2 時から 3 時までの 異なるトランザクションにより変更される対象行の各バージョンを表示します この機能で DBA はデータがいつどのように変更されたかを把握でき それをユーザー アプリケーションまたはトランザクションまでさかのぼってトレースできます このため DBA はデータベース内の論理的な破損の原因を追跡してそれを解決でき アプリケーション開発者は自分のコードをデバッグできます フラッシュバック トランザクション問合せ フラッシュバック トランザクション問合せにより データベースに行われた変更をトランザクション レベルで参照できます これは SQL の拡張機能であり トランザクションによる全変更の参照を可能にします 例を示します Select * from DBA_TRANSACTION_QUERY where xid = D ; この文は このトランザクションの全変更を表示します また これを差し戻す SQL 文も戻されるため この文を使用して このトランザクションで行われたすべての行への変更を元に戻すことができます DBA やアプリケーション開発者は このような精密なツールを使用することで 前述の場合と同様に データベースまたはアプリケーション内の論理的な問題を正確に診断して それを修復できます フラッシュバック データベース Oracle データベースを過去のある時点の状態に戻す従来の方法では Point-in-Time リカバリを使用していました Point-in-Time リカバリでは データベース全体をバックアップからリストアし エラーがデータベースに伝播する直前の状態を修復するため 数時間または数日もかかる場合があります データベースのサイズ増加に伴い データベース全体の単純なリストアに数時間または数日かかります Oracle Database 10g High Availability 9

10 フラッシュバック データベースは Point-in-Time リカバリを新しい方法で実行する機能です この機能は Oracle データベースを過去のある時点の状態に即時に巻き戻し 論理的なデータ破損またはユーザー エラーにより発生した問題がある場合はそれを修復します フラッシュバック ログは 古いバージョンの変更済ブロックを取得するために使用されます このログは 継続的なバックアップまたはストレージ スナップショットと考えることができます リカバリが必要な場合は フラッシュバック ログが即時再実行され エラー前の時点のデータベースがリストアされます この際 変更済ブロックのみがリストアされます これは非常に高速で リカバリ時間は数時間から数分に短縮されます また 使いやすさの面でも非常に優れています たとえば 次の単一コマンドを発行するだけで データベースを午後 2 時 5 分の状態にリストアできます FLASHBACK DATABASE to 2:05 PM ; テープからのリストア 処理のための長い停止時間 複雑なリカバリ作業は必要ありません また データベースを読取り専用でオープンし その内容を調べる場合にもフラッシュバックを使用できます フラッシュバックの対象範囲が必要以上に広範でありまたは不十分な場合は FLASHBACK コマンドを再発行し データベースの損傷前の適切な時点を検出します フラッシュバックは Data Guard とも統合されているため 本番データベースとスタンバイ データベースを同時にフラッシュバックが可能です ( Data Guard の項を参照) フラッシュバック データベースは データベースに対する 巻戻し または 元に戻す ボタンのように機能します フラッシュバック表 フラッシュバック トランザクション問合せは データベースの変更をトランザクション レベルで参照できるようにします これは SQL の拡張機能であり トランザクションによる全変更の参照を可能にします 例を示します FLASHBACK TABLE orders, order_items TO TIMESTAMP (JUL , 02:33:00); このコマンドは 現在時刻と過去の指定したタイムスタンプ間に orders および order_items 表で行われたすべての更新を巻き戻します フラッシュバック表はこの操作をオンラインおよびインプレースで実行し 各表の間に参照整合性制約がある場合はそれを保持します フラッシュバック表は 表または一連の関連表に対する 巻戻し または 元に戻す ボタンのように機能します フラッシュバック ドロップデータベース オブジェクトを誤ってドロップすること すなわち削除は 一般的なミスです 表を削除したとき テスト データベースに接続していると思っていました という説明は オラクル社カスタマ サポート センターでよく聞かれます ユーザーは自分のミスにすぐ気付きますが すでに手遅れであり 削除した表とその索引 制約およびトリガーを簡単にリカバリする方法はありません 一度削除したオブジェクトは 永久に削除されます 非常に重要な表やそ Oracle Database 10g High Availability 10

11 の他のオブジェクト ( 索引 パーティション クラスタなど ) の場合 従来の方法では DBA は Point-in-Time リカバリを実行する必要がありました これには非常に時間がかかり 直近のトランザクションが失われる場合もあります 削除のフラッシュバックは Oracle データベース 10g のオブジェクトを削除する場合の安全策です ユーザーが表を削除すると Oracle がそれをごみ箱に入れます ごみ箱内のオブジェクトは ユーザーがそれを完全に削除するまで またはその表を含む表領域の容量が上限に達するまで ごみ箱内に残されます ごみ箱は 削除されたすべてのオブジェクトが保持される仮想コンテナです ユーザーはごみ箱を調べ 削除した表とその依存オブジェクトを元の場所に戻すことができます たとえば employee 表とその全依存オブジェクトは 次のコマンドで元の場所に戻すことができます FLASHBACK TABLE employee BEFORE DROP; フラッシュバック ドロップは 表とその依存オブジェクトに対する 元の場所に戻す ボタンのように機能します SQL ベースの LogMiner ログ アナライザ Oracle のログ ファイルには Oracle データベースのアクティビティと履歴に関する大量の有益な情報が含まれています ログ ファイルは データベースのリカバリに必要な全データを保持しています また データベース内のデータとメタデータで行われる各変更を記録します LogMiner は SQL による REDO ログ ファイルの読込み 分析および解析を可能にする完全にリレーショナルなツールです LogMiner でログ ファイルを分析すると データへの変更の追跡または監査 調整および容量計画用の補足情報の提供 複雑なアプリケーションのデバッグに必要な重要情報の取得あるいは削除済データのリカバリが可能です データ破損に対する保護 破損は I/O スタック内の障害のあるコンポーネントによって引き起こされます たとえば データベースは更新トランザクションの結果として IO を発行します データベース I/O はオペレーティング システムに渡され IO コードになり その後 ファイル システムから順にボリューム マネージャ デバイス ドライバ ホストバス アダプタ ストレージ コントローラ ディスク ドライブへと渡され 最後に書込みが行われます I/O スタック内のいずれかのコンポーネントに 不具合またはハードウェア障害があると データ内の一部のビットが反転され 破損データがデータベースに書き込まれる場合があります データベース制御情報やユーザー データが破損することもあり その場合は データベースの機能性や可用性が深刻な打撃を受ける可能性があります 同様に ディスク障害もデータベース ファイルに損害を与え データベースのリカバリにバックアップが必要となる場合があります Oracle Database 10g High Availability 11

12 Oracle Hardware Assisted Resilient Data(HARD) Oracle Hardware Assisted Resilient Data(HARD) は データ破損を未然に防ぐための包括的なプログラムです データ破損は 頻繁には発生しないまでも 発生した場合には データベースに対し また結果的には企業の事業全体に壊滅的な被害をもたらすことがあります ストレージ デバイス内に Oracle のデータ妥当性チェック アルゴリズムを実装することで Oracle では破損データが永続ストレージ上のデータベース ファイルに書き込まれることを防止します 上位のソフトウェアから下位のハードウェアまでの このようなエンド トゥ エンドの妥当性チェックは オラクル社とストレージ パートナー各社が提供する独自の機能です Oracle が保護情報の妥当性をチェックしてデータベース ブロックに追加し この保護情報の妥当性がストレージ デバイスによりチェックされます HARD はデータベースとストレージ間の I/O パスに破損データが入るのを防止し データベース業界でこれまで防止が不可能だった大規模障害を除去します RAID は物理的にデータを確実に保護することで ストレージ業界から幅広い支持を得ていますが HARD は物理ビットの保護からビジネス データの保護へと進化することで データ保護を 1 つ上のレベルに高めています HARD は Oracle9i Database で初めて導入されましたが Oracle Database 10g ではさらに拡張されています 妥当性チェックの範囲が広がり データベース ファイル オンライン ログ アーカイブ ログ バックアップなどのあらゆるファイル タイプとブロックが HARD により保護されます また ASM により RAW ディスク デバイスを使用せずに HARD が実現します HARD は 多数の主要なストレージ ベンダーとの協力でサポートされています フラッシュ バックアップおよびリカバリ企業データのバックアップの代わりは存在しません 複数の障害により ストレージ サブシステム内でミラー化されているデータまでもが使用不可能になります Oracle では 全データを適切にバックアップし 以前のバックアップからデータをリストアし 障害発生直前までにそのデータに対し実行された変更をリカバリする オンライン ツールを提供しています 大規模なデータベース システムのバックアップは困難です 大規模なデータベースは 多数の異なるディスクに分散された数百のファイルで構成されている場合があります 重要なファイルのバックアップを怠ると データベース バックアップ全体が使用不可能になります 通常 破損したこのようなファイルは それが必要になり初めて検出されます Recovery Manager(RMAN) は Oracle データベースのバックアップ リストアおよびリカバリ プロセスの管理ツールです このツールは バックアップ ポリシーを作成して保持し すべてのバックアップおよびリカバリ アクティビティを分類します バックアップおよびリストア中に すべてのデータ ブロックで破損を分析することで 破損データがバックアップに伝播するのを防止します さらに重要な点は Recovery Manager により 必要な全データ ファイルがバックアップされるため データベースを確実にリカバリできることです Recovery Manager は ユーザーが指定した期間において データベースのリストアに必要なファイルを自動的に追跡し続けます 中断された操作の再起動 破損 Oracle Database 10g High Availability 12

13 したログ ファイルの処理 および個々のデータ ブロックのリストアを自動的に行う一方で データベースの残りの部分はオンライン状態で維持されます Oracle Database 10g の RMAN は データベースのバックアップおよびリカバリを大幅に強化しています RMAN は フラッシュ リカバリ領域への全データのバックアップおよびリカバリを自動管理できます フラッシュ リカバリ領域は 統一されたディスク ベースのストレージであり Oracle データベース内のすべてのリカバリ関連ファイルとアクティビティを格納します 前述のとおり ストレージを取り巻く環境が大きく変わり テープではなくディスクを使用すると より高速のバックアップが可能になります ただし データベースのメディア リカバリが必要な場合 最も重要な点は データベースのリカバリ時間を大幅に短縮するデータ ファイルのバックアップが存在することです Recovery Manager は フラッシュ リカバリ領域でリカバリ ファイルを管理します RMAN はフラッシュ リカバリ領域で全バックアップを自動的に作成し この領域を管理します アーカイバは アーカイブ ログをフラッシュ リカバリ領域に書き込み RMAN は 不要となったバックアップおよびアーカイブ ログを自動的に削除 またはテープに移動します 保存ポリシー (RETENTION POLICY) のリカバリ期間を 7 日に設定している場合 RMAN はデータベースのリカバリに必要な全バックアップを過去 7 日分保存します 7 日以上さかのぼってリカバリが必要な場合 RMAN はデータをテープからリストアします Enterprise Manager は フラッシュ バックアップおよびリカバリする完全なインタフェースを提供し これにはベスト プラクティスの実装も含まれます 増分バックアップは Oracle8 Database で最初にリリースされて以来 RMAN の一部となっています 増分バックアップ機能は 前回のバックアップ以降に変更されたブロックのみをバックアップします Oracle Database 10g は ブロック変更トラッキングの実装により 高速な増分バックアップを可能にします そして データベースの全変更の物理的な場所を追跡します RMAN は この変更追跡情報を自動的に使用して 増分バックアップ中にどのブロックの読込みが必要かを判断し そのブロックに直接アクセスしてバックアップします 増分バックアップを以前に作成したイメージ バックアップとマージすると リカバリ時間を最小化できます 増分更新バックアップに基づくバックアップ戦略で メディア リカバリに必要な時間を最小限に抑えることが可能です 変更トラッキングを使用した増分バックアップを バックアップ戦略の一部として取り入れることで 日々のバックアップに必要な時間の短縮 ネットワークを経由したバックアップ時のネットワーク帯域幅の節約 ログに記録されていない変更のデータベースへのリカバリ バックアップ ファイル ストレージの削減 およびデータベース リカバリ時間の短縮が可能です Oracle Database 10g のバックアップおよびリカバリには 次のような画期的な機能も多数含まれています バックアップの圧縮 リストアでバックアップの欠落または破損が検出された場合の以前のバックアップへの自動フェイルオーバー 以前の Point-in-Time リカバリによる自動リカバリ (resetlogs によるリカバリ ) Oracle Database 10g High Availability 13

14 リカバリ中の新規ファイルの自動作成 バックアップまたはリストア時の自動チャネル フェイルオーバー 表領域の自動 Point-in-Time リカバリ ミラーの分割を高速化するフル DB begin backup コマンド リカバリ並列性の改善 (2~4 倍 ) 表領域の名称変更 アーカイブ ログ用のプロキシ ( サードパーティ ) バックアップ バックアップの時間枠ベースのスロットリング クロス プラットフォームのトランスポータブル表領域 サイト障害に対する保護 データ保護機能は サイトの処理を不可能にする壊滅的なイベントからサイトを長期的に保護します 例としては ファイルの破損 自然災害 停電 通信障害 さらにはテロなどがあります Oracle データベースは 本番データベースのローカルまたはリモート コピーを作成し保持する 様々なデータ保護ソリューションを提供します 破損または災害の場合 データのユーザーはリモート データベースにアクセスすることで自分のタスクを続行できます データ保護の最もシンプルな形式は データベース バックアップのオフサイト ストレージです データ センターが適正な時間内にサービスを再開できない場合 バックアップを別のサイトのシステムでリストアでき ユーザーはこのバックアップ システムに接続できます ただし 別のシステムでバックアップをリストアするには時間がかかり 全部が最新ではない可能性があります より迅速なリカバリを可能にし 災害時でさえも継続的なデータベース サービスを可能にする機能として Oracle は Data Guard を提供します Data Guard Data Guard は あらゆる Oracle データベース障害時リカバリ計画の基盤となるものです Data Guard により 本番データベースのスタンバイ コピーをセットアップおよび保持できます このスタンバイ データベースは 本番データベースから見て地球の裏側 または同じデータ センターに配置することも可能です Data Guard には 複雑なタスクを自動化する拡張機能があり 優れた監視 警告および制御メカニズムを提供します このため データベースはデータ センターの障害に耐えることができます また フェイルオーバーが必要な場合にはサーバーをスタンバイ データベースに動的に追加できるため Data Guard はグリッド クラスタ間で透過的に動作します Oracle Database 10g High Availability 14

15 図 4: Data Guard のアーキテクチャ Data Guard Redo Apply Redo Apply モードの Data Guard は フィジカル スタンバイ データベースと呼ばれる本番データベースのコピーを保持し それを本番データベースと常に同期させます プライマリ データベースの REDO データはスタンバイ データベースに移され メディア リカバリを通じて物理的に適用されます スタンバイ データベースは プライマリ データベースと物理的に同一です ( ただし プライマリより遅れる場合があります ) また スタンバイ データベースは読取り専用で開くことができるため 報告作業を本番データベースからオフロードするためにも使用できます バックアップ処理も本番データベースからオフロードできます これは スタンバイ データベースで作成されたバックアップを使用して 本番データベースのリカバリができるためです フィジカル スタンバイ データベースは 障害やデータ エラーからの保護機能として有効です エラーまたは障害の発生時に フィジカル スタンバイ データベースをオープンして使用することで データ サービスをアプリケーションおよびエンド ユーザーに提供できます スタンバイ データベースへの変更の適用には優れたメディア リカバリ メカニズムが使用されているため スタンバイ データベースは各アプリケーションでサポートされ 最大のトランザクション ワークロードにも簡単に効率よく対処できます Data Guard SQL Apply SQL Apply モードの Data Guard は Oracle のアーカイブ ログを取得して SQL トランザクションに変換し それをオープン状態のスタンバイ データベースに適用します このスタンバイ データベースは ロジカル スタンバイ データベースと呼ばれ 物理的にはプライマリ データベースと異なる場合もありますが 論理的にはプライマリと同一で プライマリ データベースが破壊された場合には 処理を引き継ぐことができます トランザクションは SQL を使用してオープン状態のデータベースに適用されるため スタンバイ データベースは他の複数のタスクに同時に使用でき 本番データベースとは異なる物理構造を持つことができます たとえば ロジカル スタンバイ データベースを意思決定支援に Oracle Database 10g High Availability 15

16 使用することや プライマリ データベースに存在しない追加的な索引およびマテリアライズド ビューを使用することで 報告用に最適化が可能です Data Guard SQL Apply では データ保護が最も重要な機能です SQL Apply モードの Data Guard は ログ ファイル内の変更前の値をロジカル スタンバイ データベース内の変更後の値と比較し 論理的な破損に対する確認を行います このようにロジカル スタンバイ データベースは 非常に幅広い破損に対する保護機能を提供します ロジカル スタンバイ データベースは リカバリ中に読取り / 書込みが可能なため REDO ログへの変更が適用されている間も スタンバイ データベースの問合せができます データ損失ゼロのログ転送フィジカルとロジカルの両方のスタンバイ データベース コンポーネントで 同じログ転送サービスを使用します 従来の方法では アーカイブ ログは 作成と同時にプライマリからスタンバイに移されます Data Guard は プライマリからスタンバイ データベースに直接 REDO ログ更新を同期書込みができます このため データ損失ゼロの包括的な障害時リカバリ ソリューションが実現します プライマリ サイトに障害が発生した場合でも スタンバイ サイトのアプリケーションは 全トランザクションの保持に必要なすべての REDO データを使用できます 管理者は REDO データをスタンバイ サイトに非同期に移すこともできます この方法は データ損失の可能性を最小化しながら 長距離にわたる最適なパフォーマンスを提供し ネットワーク障害からの保護を実現します リアルタイム適用およびフラッシュバック データベース Oracle Database 10g の Data Guard の新機能には リアルタイム適用機能 およびフラッシュバック データベースとの統合があります リアルタイム適用機能により ログ適用サービスは REDO データをプライマリ データベースから受信すると同時にスタンバイ データベースに適用できます 現在のログ ファイルがスタンバイ データベースでアーカイブされるまで待機する必要はありません このため スタンバイ データベースをプライマリ データベースと密接に同期でき 最新かつリアルタイムの報告が可能です また スイッチオーバーやフェイルオーバーの所要時間も短縮されるため 事業の計画停止や計画外停止を軽減できます DBA は Oracle Database 10g のフラッシュバック データベース機能を プライマリとスタンバイの両方のデータベースで使用する選択をすれば データベースを過去のある時点の状態に短時間でリストアし ユーザー エラーも排除できます さらに スタンバイ データベースへのフェイルオーバーを選択した場合に ユーザー エラーがスタンバイ データベースにすでに適用されていても ( リアルタイム適用が有効になっていたため ) 管理者はスタンバイ データベースを過去のある安全な時点に 簡単にフラッシュバックできます これら 2 つの機能を使用すると スタンバイ データベースを最新の状態に保つか 本番データベースでの人為的エラーがスタンバイ データベースに伝播することを防ぐために Redo Apply を遅延させるかの選択が必要ありません Oracle Database 10g High Availability 16

17 Data Guard Broker Data Guard には Data Guard Manager という使いやすい GUI が提供されています この GUI は Oracle Enterprise Manager Grid Control の一部です Data Guard コンポーネントの監視 自動化および管理を行うコマンドライン インタフェースも使用できます マウスのシングル クリックにより Data Guard Manager は プライマリから 2 つのタイプのスタンバイ データベースのいずれかに処理をフェイルオーバーできます Data Guard Manager を使用すると DBA はスタンバイ データベースを簡単に管理および運用できます フェイルオーバーやスイッチオーバーなどのアクティビティが容易になることで エラーの可能性が大幅に削減します 計画停止の回避 計画停止であっても 業務が中断されることにかわりません これは 異なるタイムゾーンに属するユーザーをサポートするグローバル企業では特に問題となります このような場合 計画的な中断を最小化するシステムの設計が重要です 計画停止には 日常の操作 定期メンテナンス 新規配置などが含まれます 日常の操作とは バックアップ パフォーマンス管理 ユーザーおよびセキュリティ管理 バッチ操作などの日常的なメンテナンス作業を指します また パッチのインストールやシステムの再構成などの定期メンテナンスは データベース アプリケーション オペレーティング システム ミドルウェアまたはネットワークの更新に必要です 新規配置としては ハードウェア オペレーティング システム データベース アプリケーション ミドルウェアまたはネットワークへのメジャー アップグレードがあります アップグレードを実行するタイミングだけでなく その変更によるアプリケーション全体への影響も考慮する必要があります インターネットは データのグローバル共有を容易にしましたが データ可用性についての新しい問題と要件も提起しました 世界中のユーザーが 1 日 24 時間データにアクセスするため メンテナンスの時間帯がなくなりました 計画停止による業務の中断は 計画外停止による中断と同様に深刻な問題となっています ユーザーが影響を受けない時間枠は存在しません データベースに格納されるデータ量が膨大になると メンテナンス作業に非常に時間がかかります このような作業を データのユーザーに影響を与えずに行うことが重要です Oracle Database 10g High Availability 17

18 データ変更の停止時間の回避 図 5: データ変更 オンライン スキーマおよびデータ再編成 Oracle データベースでは データベース運用 またはユーザーによるデータ更新やデータ アクセスを中断せずに 多数のメンテナンス作業を実行できます データベースがオンライン状態で エンド ユーザーがデータの読取りまたは更新を行っている場合でも 索引の追加 再作成または断片化解消が可能です 同様に オンライン状態での表の再配置や断片化解消も可能です 表の再定義 表タイプの変更 列の追加 削除または名前変更 およびストレージ パラメータの変更は 基盤となるデータの表示または更新を行っているエンド ユーザーの操作を中断せずに実行できます Oracle Database 10g では この機能が拡張され 次の操作が可能です 表の索引 権限付与 制約およびその他の特性の簡単なクローニング long データ型から LOB データ型へのオンライン変換 主キーを必要としない一意索引の使用 Java および PL/SQL のストアド プロシージャの動的更新が可能であり Oracle データベースがすべての依存関係を管理するため 新しいプロシージャがデータベースに適切に統合され エンド ユーザーの操作への影響はありません Oracle Database 10g では この機能が拡張され 様々なタイプの表の変更をその表と関連付けられているストアド プロシージャの再コンパイルなしに行うことができます 表および索引のパーティション化データベースが大きくなると その管理作業が極端に膨大になることがあります 管理者は データベース表および索引をパーティション化する機能で 大きい表を管理の容易な小さい表に分割できます パーティション化によって ほとんどの操作やスキーマ変更をオンライン状態に維持しながら メンテナンス作業を一度に 1 パーティションずつ行うことができます このため メンテナンス中に影響を受けるデータは 最小限ですみます またパーティションは パラレル実行を可能にするため 大半の操作の実行時間が大幅に短縮されます パーティションの他の利点としては 障害の伝播防止があります メディア障害や破損などの障害は 障害が発生したディスク上のパーティション以外には伝播されません 影響を受け リカバリを必要とするのは そのパーティションのみ Oracle Database 10g High Availability 18

19 です これはリカバリ時間の短縮にはなりませんが 障害が発生したパーティションのリカバリ中に 他の影響を受けていないパーティションをオンライン状態に維持できます 一般に 大きい表の中の全データが 同じアクセス特性を持つわけではありません 通常 保留中のオーダーはクローズされたオーダーよりも頻繁にアクセスされ 前四半期の販売実績は 3 年前の四半期の販売実績よりも頻繁に分析されます パーティション化により データのインテリジェントなストレージ管理が可能になります 頻繁にアクセスされるデータは 最速のディスクに格納し アクセスの集中するデータは 多数のドライブにストライピングできます リソースの動的プロビジョニング Oracle データベースは 動的再構成に対するサポートの拡張を継続しているため 必要に応じて サービスを中断せずにハードウェア内の変更に対応できます Oracle データベースは 次のようなハードウェア構成への変更を動的にサポートします SMP サーバーとの間のプロセッサの追加 / 削除 RAC クラスタ内のノードの追加 / 削除 共有メモリー割当ての動的拡大 / 縮小 およびメモリーの自動オンライン調整 データベース アクティビティを中断しない データベース ディスクのオンライン追加 / 削除 データベース ストレージ全体での IO ロードの自動再調整 データ ファイルのオンライン移動このような機能により コスト ゼロのシステム変更とニーズに応じたプロビジョニングが 真に可能になります これは エンタープライズ グリッド コンピューティングに対する基本要件です システム変更の停止時間の回避 図 6: システム変更 Oracle Database 10g High Availability 19

20 ローリング パッチ更新 Oracle データベースは Real Application Clusters(RAC) システムのノードへのパッチ適用をローリング ( 循環 ) 方式でサポートします この方式を次の図に示します 図 7: ローリング パッチ更新 RAC システムの実行中は データベース クライアントにかわって全ノードが トランザクションをアクティブに処理します ( 図 7 の左上の RAC システム ) パッチ適用の手順 1 では パッチが適用される最初のインスタンスを静止させます ( この例ではインスタンス 1) 手順 2 では Oracle パッチ ツール (opatch) を使用して 静止中のインスタンスにパッチを適用します ( インスタンス 1 の Oracle ホームが更新されます ) 手順 3 では パッチが適用されたインスタンスが再度アクティブ化され クラスタに再結合します これで RAC システムは 1 つのインスタンスがクラスタ内の他のノードよりも高いメンテナンス レベルで実行されるようになりました RAC システムは このパッチが元の問題を解決し 別の問題を引き起こしていないことを確認するために 任意の期間にわたってこの複合モードで実行が可能です 次に この手順がクラスタ内の残りのノードに対して繰り返されます クラスタ内の全ノードにパッチが適用されると ローリング パッチ更新が完了し 全ノードが同じバージョンの Oracle データベース ソフトウェアを実行するようになります さらに opatch にはパッチの適用をロールバックする機能もあります この機能では 更新されたインスタンスで異常な動作が見られた場合 クラスタ全体を停止することなく 問題のパッチをアンインストール すなわちロー Oracle Database 10g High Availability 20

21 ルバックできます ロールバック手順はパッチ適用手順と同じですが この場合の opatch は適用されたパッチを削除できます ローリング アップグレード Oracle Database 10g はデータベース ソフトウェア アップグレードのインストールおよびパッチセットの適用を ローリング方式でサポートします この際 Data Guard SQL Apply が使用され データベースの停止はほとんどなくなります この方式を次の図に示します 図 8: スタンバイ データベースの確立 スタンバイ データベースをインスタンス化し 本番データベースでの変更をスタンバイ データベースにレプリケートするよう Data Guard を構成すると スタンバイ データベースがアップグレードされます 図 9: スタンバイ データベースのアップグレード この構成は 本番環境のアップグレードの妥当性をチェックするために 任意の期間にわたってこの複合モードで実行が可能です チェックが完了すると アップグレードされたソフトウェアは正しく動作し データベースのロール リバーサルおよびスイッチオーバーを実行できます Oracle Database 10g High Availability 21

22 図 10: ロール リバーサル ロール リバーサルは 複数の手順で構成されます たとえば 元のスタンバイ データベースを本番データベースに切り替える Data Guard スイッチオーバー 新しい本番データベースへのデータベース クライアントの再指定 スタンバイ データベースのアップグレード 両方のデータベースの互換性レベルの向上などです このプロセス中に数回 アップグレードの妥当性をチェックするために 構成が複合モードで実行されます そのタイミングでは データを損失することなくアップグレードを中断し ソフトウェアをダウングレードできます ローリング アップグレード中は スタンバイ データベースを障害時リカバリに使用できます この手順の間のデータ保護を強化するため Data Guard 構成で第 2 のスタンバイ データベースを使用できます Oracle ではローリング アップグレードおよびローリング パッチ更新をサポートしているため DBA が管理タスク用に確保しているメンテナンス時間枠の大半が不要となり 企業は 1 年 365 日にわたり継続的な業務ができます Maximum Availability Architecture(MAA) のベスト プラクティス IT インフラストラクチャの実装を成功させる鍵は 運用のベスト プラクティスです 技術のみでは不十分です Oracle の Maximum Availability Architecture (MAA) は 可用性の高いシステムを構築する完全に統合された実証済青写真です MAA に基づいたシステム アーキテクチャを持つ企業は 事業のシステム可用性に対する要件を満たすアプリケーションを 迅速かつ効率的に設計し配置できます MAA は 最適なシステム可用性と信頼性を保証するように広範囲に検討され テストされた特別な設計と構成の推奨事項を含んでいます MAA 構想は 高可用性を実現するための Oracle データベースの主な機能である Real Application Clusters Data Guard Recovery Manager Enterprise Manager などを組み合せた使用方法を検証して詳述しています また サーバー ストレージ ネットワーキング アプリケーション サーバーなど 可用性の高いシステムのその他の重要なコンポーネントの構成と統合にも対処しています このような各機能がそれぞれ オラクル社のソリューションの可用性を高めます これらを完全に統合し Maximum Availability Architecture に従い正しく組み合せることにより 最大可用性を持つシステムが実現し Unbreakable なソリューションとなります Oracle Database 10g High Availability 22

23 MAA のベスト プラクティス ガイドは現在改訂中であり Oracle Database 10g ドキュメント セットの標準ガイドとなる予定です MAA の詳細は を参照してください まとめ IT インフラストラクチャの主要コンポーネントとなる Oracle データベースは 基幹業務アプリケーションのデータ アクセスと可用性を保証する機能およびツールを提供します Oracle Database 10g の重要で画期的な可用性機能により データとデータベースを必要に応じた時と場所で 確実に使用できます さらに グリッド機能により データベース環境を配置し 変化するビジネス ニーズに対応するためのコストを最小限に抑えることができます Oracle Database 10g High Availability 23

24 Oracle Database 10g High Availability 2004 年 4 月著書 : Ron Weiss Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. 海外からのお問合せ窓口 : 電話 : ファックス : Copyright 2004, Oracle. All rights reserved. この文書はあくまで参考資料であり 掲載されている情報は予告なしに変更されることがあります オラクル社は 本ドキュメントの無謬性を保証しません また 本ドキュメントは 法律で明示的または暗黙的に記載されているかどうかに関係なく 商品性または特定の目的に対する適合性に関する暗黙の保証や条件を含む一切の保証または条件に制約されません オラクル社は 本書の内容に関していかなる保証もいたしません また 本書により 契約上の直接的および間接的義務も発生しません 本書は 事前の書面による承諾を得ることなく 電子的または物理的に いかなる形式や方法によっても再生または伝送することはできません Oracle は Oracle Corporation の登録商標です その他の名称は それぞれの所有者の商標です