Oracle® Database

高可用性概要

12cリリース1 (12.1)

B71280-03(原本部品番号:E49097-04)

2014年8月

Oracle Database高可用性概要, 12cリリース1(12.1)

B71280-03

Copyright © 2005, 2014, Oracle and/or its affiliates.All rights reserved.

原本著者: Virginia Beecher、Viv Schupmann、Janet Stern

原本協力者: Ahmed Abbas、Lance Ashdown、Andrew Babb、Tammy Bednar、Peter Belknap、Janet Blowney、Larry Carpenter、Immanuel Chan、Tim Chien, Donna Cooksey、Tulika Das、Mark Dilman、Ray Dutcher、Richard Exley、Craig Foch、Ameet Kini、Frank Kobylanski、Rene Kundersma、Bryn Llewellyn、Barb Lundhild、Rahim Mau、Patricia McElroy、Joe Meeks、Markus Michalewicz、Valarie Moore、Dan Norris、Michael Nowak、Darryl Presley、Ashish Ray、Mark Scardina、Jia Shi、Michael TSmith, Vinay Srihari, Hubert Sun, Lawrence To, Douglas Utzig, James Viscusi, Tak Wang, Shari Yamaguchi

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

『Oracle Database高可用性概要』のこのリリースでの変更

- Oracle Database 12cリリース1(12.1)での変更

1 高可用性の概要

- 1.1 高可用性とは

- 1.2 可用性の重要性

- 1.3 停止時間のコスト

- 1.4 停止時間の原因

- 1.5 最大可用性アーキテクチャ実装のロードマップ

2 高可用性およびデータ保護 - 要件からのアーキテクチャの取得

- 2.1 高可用性要件

- 2.2 高可用性要件を文書化する方法

- 2.2.1 ビジネス影響分析

- 2.2.2 停止時間のコスト

- 2.2.3 リカバリ時間目標

- 2.2.4 リカバリ・ポイント目標

- 2.2.5 管理性目標

- 2.2.6 総所有コストおよび投資利益率

- 2.3 アーキテクチャへの要件のマッピング

- 2.3.1 Oracle MAA参照アーキテクチャ

- 2.3.2 Bronze参照アーキテクチャ

- 2.3.3 Silver参照アーキテクチャ

- 2.3.4 Gold参照アーキテクチャ

- 2.3.5 Platinum参照アーキテクチャ

- 2.3.6 層ごとの高可用性およびデータ保護の属性

3 可用性を最大化するための機能

- 3.1 Oracle Data Guard

- 3.1.1 Oracle Active Data Guard

- 3.1.2 従来のソリューションより優れているData Guardの利点

- 3.1.3 Data Guardおよび計画メンテナンス

- 3.1.3.1 Data Guard REDO適用およびStandby-First Patchの適用

- 3.1.3.2 Data Guard一時ロジカル・ローリング・アップグレード

- 3.1.3.3 Oracle Active Data Guardを使用したローリング・アップグレード

- 3.2 Oracle GoldenGate

- 3.2.1 Oracle GoldenGate 12c

- 3.2.2 Oracle GoldenGate 11gリリース2

- 3.2.3 Oracle GoldenGateおよび最大可用性アーキテクチャ

- 3.3 ベスト・プラクティス: Oracle Active Data GuardおよびOracle GoldenGate

- 3.3.1 Oracle Active Data Guardを使用する場合

- 3.3.2 Oracle GoldenGateを使用する場合

- 3.3.3 Oracle Active Data GuardおよびOracle GoldenGateを一緒に使用する場合

- 3.4 Recovery Manager

- 3.5 Oracle Secure Backup

- 3.6 Oracle Real Application ClustersおよびOracle Clusterware

- 3.6.1 Oracle Clusterware使用の利点

- 3.6.2 Oracle Real Application ClustersおよびOracle Clusterware使用の利点

- 3.6.3 従来のコールド・クラスタ・ソリューションより優れているOracle RACの利点

- 3.7 Oracle RAC One Node

- 3.8 Oracle Automatic Storage Management

- 3.9 高速リカバリ領域

- 3.10 破損の予防、検出および修復

- 3.11 データ・リカバリ・アドバイザ

- 3.12 Oracleセキュリティ機能

- 3.13 Oracle Flashbackテクノロジ

- 3.13.1 Oracle Flashback Query

- 3.13.2 Oracle Flashback Version Query

- 3.13.3 Oracle Flashback Transaction

- 3.13.4 Oracle Flashback Transaction Query

- 3.13.5 Oracle Flashback Table

- 3.13.6 Oracle Flashback Drop

- 3.13.7 リストア・ポイント

- 3.13.8 Oracle Flashback Database

- 3.13.9 フラッシュバック・ログまたはフィジカル・スタンバイ・データベースを使用したブロック・メディア・リカバリ

- 3.13.10 フラッシュバック・データ・アーカイブ

- 3.14 Oracle Data Pumpとデータ転送

- 3.15 データベース以外のファイルに対するOracleレプリケーション・テクノロジ

- 3.15.1 Oracle Databaseファイル・システム

- 3.15.2 Oracle ASMクラスタ・ファイル・システム

- 3.15.3 Oracle Solaris ZFS Storage Applianceレプリケーション

- 3.16 クライアントとアプリケーションのフェイルオーバー

- 3.16.1 接続のクライアント・フェイルオーバー処理

- 3.16.1.1 サービス

- 3.16.1.2 高速アプリケーション通知

- 3.16.2 トランザクション・フェイルオーバーおよび保護

- 3.16.2.1 トランザクション・ガード

- 3.16.2.2 アプリケーション・コンティニュイティ

- 3.16.3 Global Data Servicesを使用したOracle Database

- 3.17 Oracle Multitenant

- 3.18 Oracle Restart

- 3.19 Oracle Site Guard

4 計画外停止時間用Oracle Database高可用性ソリューション

5 計画停止時間用Oracle Database高可用性ソリューション

- 5.1 移行用高可用性ソリューション

- 5.1.1 プラットフォームの移行

- 5.1.1.1 Oracle Exadata Database MachineまたはOracle SuperClusterへのデータベースの移行

- 5.1.1.2 プラットフォームの移行ソリューション

- 5.1.1.3 データ・ポンプの表領域トランスポータブル・エクスポート/インポート

- 5.1.1.4 データベース移行の停止時間を短縮する方法

- 5.1.2 異なるキャラクタ・セットへのデータベースの移行

- 5.1.3 マルチテナント・アーキテクチャへの移行

- 5.1.4 Oracle ASM記憶域への移行

- 5.1.4.1 Data Guardを使用したOracle ASM管理対象ストレージへの移行

- 5.1.4.2 Oracle ASMリバランスを使用した新しいストレージへの移行

- 5.1.4.3 オンライン・データ・ファイルの再配置によるOracle ASMの移行

- 5.1.5 単一インスタンス・システムからOracle RACクラスタへのデータベースの移行

- 5.2 動的およびオンライン・リソース・プロビジョニング

- 5.2.1 オンライン・データファイルの名前変更と再配置

- 5.2.2 データベースの動的再構成

- 5.2.3 メモリー管理の自動チューニング

- 5.2.4 データ・ファイル、制御ファイルおよびログ・ファイルの分散の自動化

- 5.3 オンライン再編成および再定義

- 5.4 システムおよびソフトウェア・メンテナンス用Oracle高可用性ソリューション

- 5.4.1 オペレーティング・システムのアップグレードおよびハードウェアのアップグレード

- 5.4.2 オンライン・パッチの適用

- 5.4.3 Data Guardを使用したシステムおよびクラスタのアップグレード

- 5.4.3.1 フィジカル・スタンバイ・データベースのアップグレード

- 5.4.3.2 システムおよびクラスタのアップグレードのベスト・プラクティス

- 5.4.4 Oracle Real Application Clustersを使用したパッチ適用およびローリング・アップグレード

- 5.4.4.1 Oracle Real Application Clustersを使用したローリング・パッチ・インストール

- 5.4.4.2 Data Guardを使用したローリング・パッチ・インストール

- 5.4.5 Oracle Clusterwareを使用したローリング・アップグレード

- 5.4.6 Oracle Automatic Storage Managementを使用したローリング・アップグレード

- 5.4.7 Exadata Storage Serverソフトウェアのローリング・アップグレード

- 5.4.8 Data Guardを使用したDatabaseのローリング・アップグレード

- 5.4.8.1 Data Guardおよびフィジカル・スタンバイ・データベースを使用したデータベース・アップグレードの実行

- 5.4.8.2 データ・ポンプの全体トランスポータブル・エクスポート/インポート使用のデータベース・アップグレード

- 5.4.8.3 トランスポータブル表領域を使用したデータベース・アップグレードの実行

- 5.4.8.4 Oracle GoldenGateを使用したデータベース・アップグレードの実行

- 5.4.8.5 Oracle GoldenGateおよびData Guardを使用したデータ・アップグレードの実行

- 5.5 アプリケーションのオンライン・メンテナンスおよびオンライン・アップグレード

- 5.5.1 エディションベースの再定義

- 5.5.1.1 エディション

- 5.5.1.2 エディショニング・ビュー

- 5.5.1.3 crosseditionトリガー

- 5.5.2 ローリング・アップグレードに使用するOracle GoldenGate

- 5.5.3 WAITオプションを使用したDDL

- 5.5.4 CREATE TRIGGERのENABLE、DISABLEおよびFOLLOWS句

- 5.5.5 ADD COLUMN機能の拡張

- 5.5.6 きめ細かな依存性

- 5.5.7 不可視の索引

- 5.5.8 不可視の列

- 5.5.9 同じ列セットに対する複数の索引

- 5.5.10 表のオンライン再定義後の依存PL/SQLの再コンパイル

6 可用性を最大化するための運用前提条件

- 6.1 可用性およびパフォーマンスのSLAの理解

- 6.2 SLAを満たす高可用性アーキテクチャの実装および検証

- 6.3 テスト・プラクティスおよび環境の構築

- 6.3.1 テスト・システムおよびQA環境の構成

- 6.3.2 本番前の検証手順の実行

- 6.4 セキュリティ・ベスト・プラクティスの設定および使用

- 6.5 変更管理手順の確立

- 6.6 推奨パッチおよびソフトウェアの定期的な適用

- 6.7 Data Guardのロール移行の実行

- 6.8 エスカレーション管理手順の確立

- 6.9 高可用性のための監視およびサービス要求インフラストラクチャの構成

- 6.9.1 データベース・ヘルス・チェックの定期的な実行

- 6.9.2 高可用性のためのOracle Enterprise Manager監視インフラストラクチャの構成

- 6.9.3 自動サービス要求インフラストラクチャの構成

- 6.10 最新のMAAベスト・プラクティスの確認

7 高可用性アーキテクチャ

- 7.1 MAA参照アーキテクチャの概要

- 7.2 Bronze層 - 単一インスタンスのHAアーキテクチャ

- 7.2.1 Oracle DatabaseのHAおよびデータ保護

- 7.2.2 Bronze層でのデータベース統合

- 7.2.3 ライフサイクル管理およびDBaaS

- 7.2.4 Oracle Engineered Systems

- 7.2.5 Bronzeの概要: データ保護、RTOおよびRPO

- 7.3 Silver層 - 自動フェイルオーバーによる高可用性

- 7.3.1 Oracle RAC

- 7.3.2 Oracle RAC One Node

- 7.3.3 Silver層の概要: データ保護、RTOおよびRPO

- 7.4 Gold層 - 包括的な高可用性および障害時リカバリ

- 7.4.1 Oracle Active Data Guard - リアル・タイムのデータ保護および可用性

- 7.4.2 Oracle GoldenGate

- 7.4.3 Oracle Site Guard

- 7.4.4 Goldの概要: データ保護、RTOおよびRPO

- 7.5 Platinum層 - 停止しないPlatinum対応アプリケーション

- 7.5.1 アプリケーション・コンティニュイティ

- 7.5.2 Oracle Active Data Guardの遠隔同期

- 7.5.3 Oracle GoldenGateの停止時間ゼロのメンテナンスおよびアクティブ-アクティブ・レプリケーション

- 7.5.4 エディションベース再定義

- 7.5.5 グローバル・データ・サービス

- 7.5.6 Platinumの概要: データ保護、RTOおよびRPO

- 7.6 Oracle Fusion Middlewareの高可用性の統合

- 7.6.1 Oracle WebLogic Serverの高可用性アーキテクチャ

- 7.6.2 冗長アーキテクチャ

- 7.6.3 Oracle Fusion Middlewareでの高可用性サービス

- 7.7 すべてのアプリケーションの高可用性の統合

8 Oracle Engineered Systems

- 8.1 Oracle Exadata Database Machine

- 8.2 Oracle SuperCluster

- 8.3 Oracle Database Appliance

9 投資利益率の最適化

- 9.1 グリッド・コンピューティングを使用した高ROI

- 9.1.1 データベース・サーバー・グリッド

- 9.1.2 データベース・ストレージ・グリッド

- 9.2 アクティブ・スタンバイ・データベースを使用した高ROI

- 9.2.1 フィジカル・スタンバイ・データベースのOracle Active Data Guardオプション

- 9.2.2 Oracle Active Data Guardリーダー・ファーム

- 9.2.3 Data GuardおよびCloud (Data Protection as a Service)

- 9.3 Oracle Database統合を使用した高ROI

- 9.3.1 マルチテナント・アーキテクチャ

- 9.3.2 Oracle Virtualization

- 9.4 Oracleグローバル・データ・サービスを使用した高ROI

用語集

索引

表一覧

- 1-1 計画外停止時間の原因

- 1-2 計画停止時間の原因

- 2-1 層ごとの高可用性およびデータ保護の属性

- 3-1 ブロック破損チェックの概要

- 3-2 データベース以外のファイルに対するOracleレプリケーション・テクノロジ

- 3-3 接続のクライアント・フェイルオーバー処理

- 4-1 計画外停止時間の停止タイプとOracle高可用性ソリューション

- 4-2 MAA参照アーキテクチャおよびマルチテナント・アーキテクチャの計画外停止マトリックス

- 5-1 移行用高可用性ソリューション

- 5-2 設計されたシステムへのプラットフォームの移行

- 5-3 データベース移行シナリオおよびソリューション

- 5-4 プラガブル・データベース移行ソリューション

- 5-5 MEMORY_MAX_TARGETおよびMEMORY_TARGET

- 5-6 各リリースの新規データ再編成機能

- 5-7 システムおよびソフトウェア・メンテナンス用Oracle高可用性ソリューション

- 5-8 MAA参照アーキテクチャおよびマルチテナント・アーキテクチャの計画メンテナンス・マトリックス

- 6-1 各種のテストおよびQA環境のトレードオフ

- 7-1 Bronze層のデータ保護

- 7-2 Bronze層のリカバリ時間(RTO)およびデータ損失の可能性(RPO)

- 7-3 Silver層のリカバリ時間(RTO)およびデータ損失の可能性(RPO)

- 7-4 Gold層のデータ保護

- 7-5 Gold層のリカバリ時間(RTO)およびデータ損失の可能性(RPO)

- 7-6 Platinum層のリカバリ時間(RTO)およびデータ損失の可能性(RPO)

はじめに

このマニュアルでは、可用性の高いデータベース環境をデプロイするOracleベスト・プラクティスを紹介します。また、高可用性について概説し、高可用性要件の特定を支援します。高可用性をサポートするよう設計されたOracle Databaseの製品と機能、およびビジネスの高可用性実現に役立つ主要なデータベース・アーキテクチャについても説明します。

「はじめに」では、次の項目について説明します。

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

対象読者

このマニュアルは、次の仕事を遂行するCTO(最高技術責任者)、情報テクノロジ・アーキテクト、データベース管理者、システム管理者、ネットワーク管理者およびアプリケーション管理者を対象としています。

- データ・センターの計画

- データ・センター・ポリシーの実装

- 高可用性システムのメンテナンス

- 高可用性ソリューションの計画および構築

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWeb サイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

Oracleサポート・サービスでは、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

このマニュアルで説明されている構成と実装の詳細を理解するには、Oracle Database、Oracle RACおよびData Guardの概念および用語に関する知識が必要です。詳細は、Oracle Databaseのドキュメント・セットを参照してください。特に関連性の高いドキュメントを次に示します。

- 『Oracle Database高可用性ベスト・プラクティス』
ベスト・プラクティスを確定するには広範囲なテストが必要なため、このマニュアルは通常『Oracle Database高可用性概要』よりも遅れます。リリース11.2のマニュアルが使用可能になるまで、リリース11.1.0.7用の『Oracle Database高可用性ベスト・プラクティス』に有用な方法がある可能性があります。

- 『Oracle Database管理者ガイド』

- 『Oracle Database 2日でReal Application Clustersガイド』

- 『Oracle Clusterware管理およびデプロイメント・ガイド』

- 『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

- 『Oracle Automatic Storage Management管理者ガイド』

- 『Oracle Data Guard概要および管理』

- 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』

マニュアルの多くで、Oracle Databaseのインストール時にデフォルトでインストールされるシード・データベースのサンプル・スキーマを使用しています。これらのスキーマの使用方法については、『Oracle Databaseサンプル・スキーマ』を参照してください。

また、Oracle MAAベスト・プラクティス・ホワイト・ペーパーはhttp://www.oracle.com/goto/maaでダウンロードできます。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ドキュメントのタイトル、強調またはユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

『Oracle Database高可用性概要』のこのリリースでの変更

この章の内容は次のとおりです。

- Oracle Database 12cリリース1(12.1)での変更

Oracle Database 12cリリース1(12.1)での変更

Oracle Database 12cリリース1(12.1)の『Oracle Database高可用性概要』での変更は、次のとおりです。

新機能

このリリースの新機能は次のとおりです。

- Global Data Services
Global Data Servicesでは、Oracle Real Application Clustersサービス・モデルをグローバルに分散された異機種のデータベースのセットに適用し、複数のデータベースにより提供されるサービスであるグローバル・サービスを使用して、ロード・バランシングおよびフェイルオーバー機能をデータベース・クラウドに提供します。

3.16.3項「グローバル・データ・サービスを使用したOracle Database」を参照してください。

- Oracle Flex ClustersおよびOracle Flex ASM
Oracle ClusterwareおよびOracle Real Application Clustersは、Oracle Flex Clusterと呼ばれる大規模クラスタに構成できます。Oracle Flex ASMは、Oracle ASMインスタンスをデータベース・サーバーから切り離します。Oracle ASMインスタンスは、(データベース・サーバーとは)別の物理サーバーで実行することができます。任意の数のOracle ASMサーバーをクラスタ化して、データベースの大規模なセットに対応することができます。

3.6項「Oracle Real Application ClustersおよびOracle Clusterware」および3.8項「Oracle Automatic Storage Management」を参照してください。

- 遠隔同期
Data Guard遠隔同期インスタンスは、プライマリ・データベースからのREDOを受け入れ、そのREDOをData Guard構成の別のメンバーに送信するリモートData Guard宛先です。遠隔同期インスタンスは制御ファイルを管理し、REDOをスタンバイREDOログ(SRL)に受け取り、それらのSRLをローカルのアーカイブREDOログにアーカイブしますが、スタンバイとの類似点はそこまでです。遠隔同期インスタンスにはユーザー・データ・ファイルは含まれず、アクセスのために開くことも、REDO適用を実行することも、プライマリ・ロールとして機能することもできず、スタンバイ・データベースのいずれかのタイプに変換されることもありません。

「Oracle Active Data Guardの利点」を参照してください。

- 統合とマルチテナント・アーキテクチャ
マルチテナント・アーキテクチャの機能によって移植可能な一連のスキーマ、オブジェクトおよび関連構造をOracle Databaseに含めることができ、アプリケーションには論理的に別のデータベースのように見えます。

9.3項「Oracle Database統合を使用した高ROI」を参照してください。

- Oracle Active Data Guardを使用したローリング・アップグレード
Oracle Active Data Guardを使用したローリング・アップグレードでは、新しいPL/SQLパッケージが提供され、フィジカル・スタンバイ・データベースを使用して、データベースのローリング・アップグレードを実行する多くのプロセスを自動化します。

5.4.8.1項「Data Guardおよびフィジカル・スタンバイ・データベースを使用したデータベース・アップグレードの実行」を参照してください。

- Oracle Active Data Guardの拡張機能
グローバル一時表、XMLType表および列のレプリケーション、強化されたセキュリティ用にサポート。

「Oracle Active Data Guardの利点」を参照してください。

- アプリケーション・フェイルオーバーの改善
アプリケーションの可用性は、高速アプリケーション通知の強化、Oracle Services、およびGlobal Data Services、アプリケーション・コンティニュイティ、トランザクション・ガードの追加により向上しました。

3.16項「クライアントとアプリケーションのフェイルオーバー」を参照してください。

その他の変更

このリリースでのその他の変更は、次のとおりです。

- Oracle MAA参照アーキテクチャ
Oracle MAA参照アーキテクチャは、単一のデータベースやアプリケーションの他に、多数のデータベースやアプリケーション、DBaaSクラウドまたはデータベース統合にも適用できます。MAA参照アーキテクチャについての理解が深まるよう、このマニュアルの内容全体を変更しました。

第7章「高可用性アーキテクチャ」を参照してください。

1 高可用性の概要

この章の内容は、次のとおりです。

- 高可用性とは

- 可用性の重要性

- 停止時間のコスト

- 停止時間の原因

- 最大可用性アーキテクチャ実装のロードマップ

1.1 高可用性とは

可用性は、要求に応じてアプリケーション、サービスまたは機能がどの程度使用可能であるかを表しています。可用性は、アプリケーションのユーザーの感覚を基準に評価されます。データが使用できない場合やコンピュータ・システムが予想どおりに機能しない場合、ユーザーは不満を感じます。ユーザーがソリューション全体の複雑なコンポーネントを理解したり、区別しようと考えたりすることはありません。予想を超える使用状況が原因で発生したパフォーマンス障害は、アーキテクチャの重要なコンポーネントに障害が発生した場合と同じ混乱をもたらします。ユーザーがシステムにアクセスできないことを使用不可といいます。一般的に、システムの使用不可期間は停止時間と呼ばれます。

システムをいつでも使用できる状態にしておくには、高可用性が必要です。可用性の高いシステムは、主要期間、年間を通じて毎日毎時間、割込みのない計算処理を提供するように設計されています。これは24x365と表されます。このようなシステムにも、システムのハードウェアまたはソフトウェアのアップグレードなど、計画メンテナンス操作のための高可用性ソリューションが必要です。

信頼性、リカバリ可能性、タイムリなエラー検出および継続的稼働は、高可用性ソリューションの主な特徴です。

- 信頼性: 信頼できるハードウェアは高可用性ソリューションの1つの要素です。信頼できるソフトウェア(データベース、Webサーバー、アプリケーションなど)も同様に、高可用性ソリューションを実現する上で重要です。関連する特性はリジリエンスです。たとえば、低コストの汎用ハードウェアをOracle Real Application Clusters(Oracle RAC)などのソフトウェアを組み合せることで、非常に信頼性の高いシステムの実装に使用できます。Oracle RACデータベースのリジリエンスが高ければ、個々のサーバーに障害が発生しても、処理は続行できます。

- リカバリ能力: 障害からのリカバリには多数の方法がある場合があります。したがって、高可用性の環境でどのようなタイプの障害が発生する可能性があるかを判断し、ビジネスの要件を満たして迅速にそれらの障害からリカバリする方法を決めることが重要です。たとえば、重要な表が誤ってデータベースから削除された場合、その表をリカバリするにはどのような処置を取ればよいでしょうか。アーキテクチャには、品質保証契約(SLA)で規定された時間内にリカバリする能力があるでしょうか。

- タイムリなエラー検出: アーキテクチャのコンポーネントに障害が発生した場合、予期しない障害からリカバリするには素早い検出が重要です。停止から素早くリカバリできても、問題の検出にさらに90分かかったとしたら、SLAを遵守できない可能性があります。環境の状態を監視するには、状態を素早く表示するための信頼できるソフトウェア、およびデータベース管理者に問題を通知する機能が必要です。

- 継続的稼働: データへの継続的なアクセスを提供することが、メンテナンス・アクティビティを実行するための停止時間をほとんど、あるいはまったく許容できないという場合に不可欠です。表をデータベース内の別の場所に移動したり、ハードウェアにCPUを追加したりといったアクティビティは、高可用性アーキテクチャではユーザーに対して透過的に行う必要があります。

より具体的に言えば、高可用性アーキテクチャは次の特徴を備えている必要があります。

- 中断を最小限またはゼロにして、処理が継続するように障害を許容すること

- システム、データまたはアプリケーションの変更に対して透過的である(または耐性がある)こと

- 予防措置が組み込まれていること

- 障害のアクティブな監視と素早い検出が可能であること

- 素早いリカバリが可能であること

- 検出操作およびリカバリ操作が自動化されていること

- データ損失を最小限に抑えるか防止するためにデータを保護すること

- 運用面でのベスト・プラクティスを実施して環境を管理していること

- できるかぎり安価な総所有コストでSLA(リカバリ時間目標(RTO)やリカバリ・ポイント目標(RPO)など)で設定した目標を達成すること

1.2 可用性の重要性

高可用性がどの程度重要であるかはアプリケーションによって異なります。データベースとインターネットは、組織やコミュニティの隅々にまでデータベース・アプリケーションを行き渡らせ、世界的なコラボレーションと情報共有を可能にしました。こうしたデータベース・アプリケーションの浸透により、データ管理ソリューションにおける高可用性の重要性が浮き彫りになっています。中小企業もグローバルな企業も、1日24時間データへのアクセスを必要とするユーザーを世界中に抱えています。このデータ・アクセスが行えなければ、業務は停止し、収益が失われます。これらのソリューションに依存する傾向が強まったことを反映して、ユーザーは情報技術(IT)部門やソリューション提供者の品質保証契約を求めるようになりました。可用性は、時間と利便性のみでなく、ドル、ユーロおよび円で評価されることがますます増えています。

企業は、そのITインフラストラクチャを利用して、競争力を付け、生産性を高め、より多くの情報に基づいてより迅速に決定を下す力をユーザーに与えてきました。しかし、こうした利点により、インフラストラクチャへの依存度はますます高まりました。重要なアプリケーションが使用できなくなった場合、ビジネスが危機に瀕します。ビジネスの収益が減少し、違約金を被り、顧客や会社の株価に対する影響が続く悪評を呼ぶ可能性があります。

データの保護方法を決定する要因について検討し、ユーザーへの可用性を最大限に高めることが非常に重要です。

1.3 停止時間のコスト

企業がソリューションを再構築して競争力を強めるにつれて、より高いレベルの可用性を提供する必要性は高まる一方です。ほとんどの場合、こうした新しいソリューションは重要なビジネス・データへの即時アクセスに依存しています。データが使用できない場合、業務が停止する可能性もあります。停止時間は、生産性の低下、収益の損失、カスタマ・リレーションシップの悪化、悪評および訴訟につながりかねません。

停止時間の直接のコストを試算するのは必ずしも容易ではありません。顧客の怒り、従業員の空き時間、悪評などはすべてコストに結び付きますが、通貨に直接換算することはできません。その一方で、SLAの目標が達成されないことによる収益の損失や法的処罰は容易に定量化可能です。ソリューションに依存してサービスを提供している業界では、停止時間のコストが急速に増大する可能性があります。

停止時間のコストという点で考慮が必要なその他の要因は、次のとおりです。

- 1回の計画外停止の最大許容時間
イベントの継続時間が30秒未満の場合、イベントが与える影響は非常に小さく、ユーザーがイベントを感じ取ることはほとんどありません。停止時間が長くなるにつれて、その影響は著しく大きくなり、ビジネスにも悪影響を及ぼすことになります。

- 許容できるインシデントの最大頻度
停止の頻度が高くなると、停止が短時間であったとしても、同様に業務が中断する可能性があります。

ソリューションを設計する場合、停止時間の実際のコストを把握して、可用性が向上することでどのように利益が得られるのかを認識することが重要です。

オラクル社では、規模に関係なくあらゆる組織に適する幅広い高可用性ソリューションを提供しています。小規模なワークグループもグローバルな企業も同様に、重要なビジネス・アプリケーションの利用範囲を拡大できます。Oracleとインターネットがあれば、いつでもどこからでも、アプリケーションおよびデータへの信頼性の高いアクセスが可能になります。

1.4 停止時間の原因

高可用性ソリューションを設計する上での課題の1つは、停止時間のあらゆる原因を検討し、対処することです。フォルト・トレラントおよびリジリエンスがあるITインフラストラクチャを設計する際、計画外停止時間と計画停止時間の両方の原因を考慮することは重要です。複数のタイムゾーンのユーザーをサポートするグローバル企業では特に、計画停止時間も計画外停止時間と同じく業務に悪影響を及ぼします。

表1-1は、計画外停止のタイプと説明、および各タイプの例を示しています。

表1-1 計画外停止時間の原因

タイプ

説明

例

サイト障害

サイト障害は、データ・センターでのすべての処理か、またはデータ・センターでサポートされているアプリケーションのサブセットに影響する可能性があります。

- サイト全体に及ぶ停電

- サイト全体のネットワーク障害

- データ・センターを操業不可能にする自然災害

- 業務またはサイトへのテロまたは悪意のある攻撃

クラスタ全体の障害

Oracle RACデータベースのホストであるクラスタ全体が使用不可能になるか、故障します。次のような機能があります。

- クラスタ内のノードの障害

- クラスタが使用不可能になる原因となった他のコンポーネントの障害および使用不可能なサイト上のOracleデータベースやインスタンスの障害

- Oracle RACクラスタ上で最後まで動作しているノードに障害が発生し、ノードまたはデータベースが再起動不能

- 冗長クラスタのインターコネクトが両方故障またはクラスタウェアの障害

- データベースの破損が、現行データベース・サーバーでの継続が不可能になるほど深刻

- ディスク・ストレージ障害

コンピュータ障害

コンピュータ障害による停止は、データベースを実行しているシステムが停止または利用不可能になり、使用できない状態になったときに発生します。データベースがOracle RACを使用している場合、コンピュータ障害はシステムのサブセットを表します(データへの完全なアクセスを維持)。

- データベース・システム・ハードウェア障害

- オペレーティング・システム障害

- Oracleインスタンス障害

ネットワーク障害

ネットワーク障害停止は、ネットワーク・デバイスが停止するか、アプリケーション・サービスの処理に不可欠な、アプリケーションからデータベース、データベースからストレージ、またはシステムからシステムのネットワーク・トラフィックや通信が減少したときに発生します。

- ネットワーク切替え障害

- ネットワーク・インタフェース障害

- ネットワーク・ケーブル障害

ストレージ障害

ストレージ障害による停止は、データベース・コンテンツの一部またはすべてが格納されているストレージが停止または利用不可能になり、使用できない状態になったときに発生します。

- ディスク・ドライブ障害

- ディスク・コントローラ障害

- ストレージ・アレイ障害

データ破損

破損ブロックは変更されたブロックです。そのため、Oracle Databaseが検出するものとは異なります。ブロック破損は、物理的破損と論理的破損に分類されます。

- 物理ブロック破損はメディア破損とも呼ばれ、ブロックがデータベースにまったく認識されません。チェックサムが無効になるか、ブロック内容がすべてゼロになります。より複雑なブロック破損の例として、ブロックのヘッダーとフッターが一致しない場合があげられます。

- 論理ブロック破損では、ブロックの内容は物理的には正常で、物理ブロック・チェックを通過します。ただし、ブロックが論理的に一貫性を欠いている場合があります。論理ブロック破損の例には、不正なブロック・タイプ、不正なデータまたはREDOブロック順序番号、行ピースや索引エントリの破損、あるいはデータ・ディクショナリの破損があります。

ブロック破損は、さらにインターブロック破損とイントラブロック破損に分類できます。

- イントラブロック破損の場合、破損はブロック内部で発生し、物理ブロック破損または論理ブロック破損のいずれかになります。

- インターブロック破損の場合、破損はブロック間で発生し、論理ブロック破損になります。

データ破損による停止は、ハードウェア、ソフトウェアまたはネットワークのコンポーネントで、読取りまたは書込み対象のデータが破損したときに発生します。データ破損による停止から受けるサービス・レベルの影響は、アプリケーションまたはデータベースの一部(単一データベース・ブロック・レベル)から大部分(基本的に使用不可にする)まで、大きく異なります。

- オペレーティング・システムまたはストレージ・デバイス・ドライバ障害

- 障害のあるホスト・バス・アダプタ

- ディスク・コントローラ障害

- ディスクの不正な読取りまたは書込みの原因となるボリューム・マネージャ・エラー

- ソフトウェアまたはハードウェアの不具合

人的エラー

人的エラーによる停止は、データベース内のデータを破損または使用不可能の状態にする意図的でない操作やその他の操作が行われた場合に発生します。人的エラーによる停止から受けるサービス・レベルの影響は、影響を受けたデータの量および重大性によって大きく異なります。

- (ファイル・システム・レベルの)ファイルの削除

- 削除されたデータベース・オブジェクト

- 故意でないデータ変更

- 悪意のあるデータ変更

書込み欠落または宛先違いの書込み

データ破損の別の形である書込み欠落や宛先違いの書込みは、素早く検出し修復することがさらに困難です。データ・ブロックの宛先違いの書込みまたは書込み欠落は次の場合に発生します。

- 書込み欠落は、書込みI/Oが永続記憶域で発生しなくても、I/Oサブシステムがブロック書込みの完了を確認する場合。プライマリ・データベースでの後続ブロック読取りのときに、I/Oサブシステムが、データベースの他のブロックの更新に使用される古いバージョンのデータ・ブロックを返すため、ブロックが破損します。

- 宛先違いの書込みは、書込みI/Oは完了したが、他の場所に書き込まれ、後続の読取り操作で古い値が返される場合。

- Oracle RACシステムでは、1つのクラスタ・ノードからの読取りI/Oで、別のノードからの書込みI/O完了後に古いデータが返される場合(書込みの欠落)。たとえば、属性キャッシュを無効にせずに(noacオプションを使用しないなど)ネットワーク・ファイル・システム(NFS)がOracle RACでマウントされている場合に発生します。この場合、1つのノードからの書込みI/Oは、キャッシュされるために別のノードに即時表示されません。

宛先違いの書込みや書込み欠落が原因のブロック破損は、データベースの可用性を大きく損ねる可能性があります。データ・ブロックが物理的または論理的に正しくても、後続のディスク読取りで、古いブロックやOracle Databaseのブロック・アドレスが正しくないブロックが表示されます。

- オペレーティング・システムまたはストレージ・デバイス・ドライバ障害

- 障害のあるホスト・バス・アダプタ

- ディスク・コントローラ障害

- ボリューム・マネージャ・エラー

- その他のアプリケーション・ソフトウェア

- クラスタ全体で見えないネットワーク・ファイル・システム(NFS)書込み

遅延または減速

遅延または減速が発生するのは、リソースやロックの競合が原因でデータベースまたはアプリケーションがトランザクションを処理できなくなったときです。認識される遅延は、システム・リソースの不足が原因で引き起こされます。

- データベースまたはアプリケーションのデッドロック

- システム・リソースを消費する暴走プロセス

- ログオン・ストームまたはシステム・フォルト

- アプリケーションのピークとシステムまたはデータベースのリソース不足の同時発生。リソースが適切に管理されていない統合データベース環境では、1つのアプリケーションで起こることも、多数のアプリケーションで起こることもあります。

- アーカイブREDOログの宛先または高速リカバリ領域の宛先がいっぱいになった場合

表1-2は、計画停止のタイプと説明、および各タイプの例を示しています。

表1-2 計画停止時間の原因

タイプ

説明

例

システム変更およびデータベース変更

計画されたシステム変更は、日常的、定期的なメンテナンス業務および新しいデプロイメントが行われるときに発生します。

計画されたシステム変更には、データベース内の組織データ構造外で発生する計画的な業務環境への変更が含まれます。

計画されたシステム変更から受けるサービス・レベルの影響は、計画停止時間の性質および範囲、変更の実装前に行われるテストと検証作業、影響を最小化するためのテクノロジならびに機能により、大きく異なります。

- SMPサーバーへのプロセッサの追加、またはSMPサーバーからの削除

- クラスタへのノードの追加、またはクラスタからのノードの削除

- ディスク・ドライブまたはストレージ・アレイの追加および削除

- 任意のフィールド交換可能ユニット(FRU)の交換

- 構成パラメータの変更

- システム・ハードウェアおよびソフトウェアのアップグレードまたはパッチ適用

- Oracleソフトウェアのアップグレードまたはパッチ適用

- アプリケーション・ソフトウェアのアップグレードまたはパッチ適用

- システム・プラットフォームの移行

- データベースの再配置

- 32ビットから64ビットへの移動

- クラスタ・アーキテクチャへの移行

- 新しい記憶域への移行

データ変更

計画されたデータ変更は、Oracle Databaseオブジェクトの論理的構造または物理的組織に変更があった場合に発生します。この変更を行うのは主に、パフォーマンスまたは管理性を改善するためです。

- 表定義の変更

- 表のパーティション化の追加

- 索引の作成および再構築

アプリケーション変更

計画されたアプリケーション変更には、データ変更やスキーマおよびプログラムの変更などがあります。この変更を行うのは主に、パフォーマンス、管理性および機能性を改善するためです。

- アプリケーションのアップグレード

オラクル社では、計画外停止時間と計画停止時間の回避、および障害からのリカバリに役立つ高可用性ソリューションを提供しています。これらの高可用性ソリューションの詳細は、第4章および第5章で説明します。

1.5 最大可用性アーキテクチャ実装のロードマップ

Oracleの高可用性ソリューションと正常な操作実行が、ITインフラストラクチャの実装を成功させる鍵です。ただし、テクノロジのみでは十分ではありません。

可用性要件に最も適したアーキテクチャを選択し、実装するのは、きわめて困難な作業です。最大可用性アーキテクチャ(MAA)は、ビジネス要件に適した高可用性アーキテクチャを選択し実装するプロセスを簡略化します。MAAには次の特長があります。

- すべてのコンポーネントに冗長性を持たせること

- コンピュータ障害、ストレージ障害、人的エラー、データ破損、書込み欠落、システムの遅延または減速、およびサイト障害からの保護および許容が可能であること

- できるだけ素早く透過的に停止からリカバリすること

- 計画停止時間をなくすか短縮するソリューションを提供すること

- 一貫した高パフォーマンスと堅牢なセキュリティを実現すること

- デプロイメント、管理、スケーラビリティおよび可用性を簡単に実行できるようOracle Engineered Systemオプションを提供すること

- できるかぎり安価な総所有コストでSLAを遵守すること

この種のアーキテクチャを構築、実装および維持するには、次のことが必要です。

1. ITシステムおよびビジネス・プロセスの技術面および運営面の両方を含め、固有の高可用性の要件を分析します(第2章「高可用性要件の特定 - 要件からアーキテクチャへの取得」を参照してください)。

2. Oracle高可用性機能を理解します。第3章「可用性を最大化するための機能」を参照してください。

3. 各MAA層や、業務とアプリケーションに関する様々な高可用性機能に対する可用性の影響を理解します(第4章「計画停止時間用Oracle Database高可用性ソリューション」および第5章「計画外停止時間用Oracle Database高可用性ソリューション」を参照してください)。

4. 運用のベスト・プラクティスを使用してMAAを正常に実装します。第6章「可用性を最大化するための運用前提条件」を参照してください。

5. 高可用性アーキテクチャを選択します(第7章「高可用性アーキテクチャ」を参照してください)。

6. Oracle Exadata Database Machine、Oracle SuperCluster、Oracle Database ApplianceといったOracleのエンジニアド・システムがMAA全体とどのような関係にあるかを理解します(第8章「Oracle Engineered Systems」を参照してください)。

7. Oracle Grid Computing、Oracle Active Data Guardのリアルタイムのレポートおよび使用、プラガブル・データベースまたはOracle VirtualizationおよびOracle Data Cloudを使用したOracle Databaseマルチテナント・アーキテクチャにより、あらゆる高可用性アーキテクチャおよびソリューションの投資利益率(ROI)を最適化します。第9章「投資利益率の最適化」を参照してください。

8. 次のリソースを使用して、高可用性アーキテクチャを実装します。

- MAAおよび高可用性ベスト・プラクティスのホワイト・ペーパーおよびその他の情報
オラクル社では、各種ベスト・プラクティス・ホワイト・ペーパー、概念実証を伴うカスタマMAAペーパー、カスタマ・ケース・スタディ、記録されているWebキャスト、デモンストレーションおよびプレゼンテーションを提供しています。これらのリソースは、MAAの様々な高可用性テクノロジに関する技術的な詳細を、そのようなテクノロジを構成および使用するためのベスト・プラクティス推奨事項とともに提供します。

これらのMAAリソースは、http://www.oracle.com/goto/maaで入手できます。

2 高可用性およびデータ保護 - 要件からのアーキテクチャの取得

この章では、エンタープライズの高可用性要件を効果的に評価するためのフレームワークを示します。次の項で構成されます。

- 高可用性要件

- 高可用性要件を文書化する方法

- アーキテクチャへの要件のマッピング

2.1 高可用性要件

Oracle Databaseに高可用性戦略を設計して実装する作業は、ビジネス影響分析を徹底的に実行し、原因が計画外停止であるか計画停止であるかによって、停止時間やデータ損失でエンタープライズにどのような影響があるかを確認することから始めます。エンタープライズが営利企業であるか、政府機関であるか、あるいは非営利団体であるかを意識しなくてよいように、ビジネス影響という言葉を使用しています。いずれの場合も、データ損失や停止時間は、エンタープライズの業務遂行能力に深刻な影響を及ぼします。高可用性の実現は、次のような重要な課題を伴います。

- レガシー・システムの廃止

- より高度で堅牢なシステムや設備への投資

- この高可用性モデルに合せたITアーキテクチャと操作全体の再設計

- 高可用性インフラストラクチャを最大限に利用するための既存アプリケーションの変更

- ビジネス・プロセスの再設計

- 人員の雇用およびトレーニング

ビジネス要件を分析した上で、様々な高可用性ソリューションの実装に必要な投資レベルを理解することで、ビジネス面と技術面の両方の目的を達成する高可用性アーキテクチャの開発が可能になります。

図2-1 可用性の高い企業の計画および実現

2.2 高可用性要件を文書化する方法

この分析フレームワークは次の要素で構成されます。

- ビジネス影響分析

- 停止時間のコスト

- リカバリ時間目標

- リカバリ・ポイント目標

- 管理性目標

- 総所有コストおよび投資利益率

2.2.1 ビジネス影響分析

厳密なビジネス影響分析では、次のことが行われます。

- 組織内の重要なビジネス・プロセスの特定

- 各ビジネス・プロセスに影響を与える計画外IT停止および計画IT停止の定量化可能な損失リスクの算出

- 停止が与える影響の概略のまとめ

- 基本的なビジネス機能、人的リソースおよびシステム・リソース、政府規制、内部および外部のビジネス依存関係の考慮

- 豊富な知識を持つ経験豊かな人員とのインタビューで収集した客観的、主観的データの使用

- ビジネス手法の履歴や財務報告書、ITシステム・ログなどの調査

ビジネス影響分析では、IT関連の停止の影響の重大度に基づいてビジネス・プロセスを分類します。たとえば、世界各地にチップ製造工場を持つ半導体製造業者について考えてみましょう。半導体製造業は、高生産量で償却される、巨額な財政投資を必要とする非常に競争の激しいビジネスです。工場管理で使用される人的リソース・アプリケーションは、工場の製造プロセスを制御するアプリケーションほどミッションクリティカルであるとみなされない傾向があります。製造をサポートするアプリケーションに障害が発生すると、その影響は生産レベルに及び、企業の決算報告に直接の影響が出ます。

同様に、経営コンサルティング企業では内部ナレッジ管理システムがミッションクリティカルであるとみなされる傾向があります。これは、クライアントを重視する企業のビジネスにとって、コンサルタントやナレッジ・ワーカーが内部調査にアクセスできることが基本であるためです。このようなシステムの停止時間のコストは、このビジネスにとってきわめて高くつきます。

2.2.2 停止時間のコスト

ビジネス影響分析を完全に実施すれば、計画外停止時間および計画停止時間のコストの定量化に必要な見通しが得られます。このコストは、高可用性の投資の優先付けに役立ち、停止時間のリスクを最小限に抑えるために選択する高可用性テクノロジに直接影響を与えるため、必ず理解しておく必要があります。

様々な業界の停止時間のコストをまとめた各種レポートが発行されています。コストは、仲買業務やクレジット・カード販売の1時間当たり数百万ドルから、荷物輸送サービスの1時間当たり数万ドルまで、多岐にわたります。

まさに驚くべき数字です。インターネットでは、ビジネスと何百万もの顧客を直接結び付けることができます。アプリケーションの停止時間によってこの結び付きは分断され、ビジネスと顧客が切り離されてしまいます。停止時間は収益の損失を生むだけでなく、カスタマ・リレーションシップ、競争力、法的義務、業界での評価、株主の信頼などにも悪影響を及ぼす可能性があります。

2.2.3 リカバリ時間目標

ビジネス影響分析では、リカバリ時間目標(RTO)とも呼ばれる、停止時間の許容範囲を決定します。RTOは、ITベースのビジネス・プロセスが停止しても、組織に受け入れがたい影響(経済的損失、顧客不満足、風評など)が生じない、最大時間として定義されます。RTOは、一般的に、ビジネス・プロセスまたは組織の許容停止時間に相当します。

RTO要件はビジネスのミッションクリティカル性によって左右されます。したがって、証券取引所を運営するシステムの場合、RTOはゼロまたはゼロに近い数値になります。

組織には、各種ビジネス・プロセスにまたがる様々なRTO要件があるものです。したがって、大規模なE-Commerce Webサイトの場合、高速のレスポンスが期待され、顧客のスイッチング・コストが非常に小さいため、E-Commerceの売上を押し上げるWebベースの顧客対応システムのRTOはゼロまたはゼロに近くなります。しかし、出荷や請求などのバックエンド業務をサポートするシステムのRTOはそれより長くてもかまいません。このようなバックエンド・システムが停止した場合は、一時的に手動操作に切り替えて、重大な影響が出るのを防ぐことができます。

E-Commerce Webサイトを介してすばやく注文を受けられること(RTO)のほうがRPOより重要です。失われたデータは後でリロードできるためです。

2.2.4 リカバリ・ポイント目標

ビジネス影響分析では、リカバリ・ポイント目標(RPO)とも呼ばれる、データ損失の許容範囲も決定します。RPOは、組織に損害を与えずに、ITベースのビジネス・プロセスで失うことのできる最大データ量です。RPOは、一般的に、ビジネス・プロセスまたは組織の許容データ損失量を計測します。このデータ損失は、通常、データ損失ゼロ、何秒分、何時間分または何日分のデータ損失というように、時間に換算して測定されます。

毎分数百万ドルに相当するトランザクションが発生する証券取引所では、データを失うわけにはいきません。したがって、RPOをゼロにする必要があります。E-Commerceの例について言えば、Webベースの販売システムではRPOがゼロであることが求められるわけではありませんが、顧客満足のためにはRPOを抑えることが不可欠です。ただし、バックエンドのマーチャンダイジング・システムおよび在庫更新システムでは、RPOが大きくなることもあります。失ったデータの再入力が可能であるためです。

2.2.5 管理性目標

管理性目標は、RPOやRTOよりも主観的です。これは、組織で使用できるスキル・セット、管理リソースおよびツールといった客観的な評価、および組織が高可用性アーキテクチャのすべての要素を正常に管理できる程度に起因します。RPOおよびRTOが停止時間やデータ損失に対する組織の許容差を測定するのと同様に、管理性目標はIT環境の複雑さに対する組織の許容差を測定します。複雑さがそれほど要求されない場合、高可用性を実現するには、管理が複雑な方法よりも単純な方法が好まれ、複雑な方法の方が積極的なRTOおよびRPO目標を達成できる場合でも当てはまります。管理性目標を理解すれば、組織で実現が可能と思われる事項と実現が実用的である事項とを区別する際に役立ちます。

2.2.6 総所有コストおよび投資利益率

総所有コスト(TCO)と投資利益率(ROI)の目標を理解することは、組織のビジネス目標を達成する高可用性アーキテクチャを選択する際に不可欠です。TCOには、選択するソリューションの耐用年数におけるすべてのコスト(取得、実装、システム、ネットワーク、設備、スタッフ、トレーニングおよびサポートなど)が含まれます。同様に、ROIの計算では、指定の高可用性アーキテクチャで発生するすべての金銭的利益が算出されます。

たとえば、リモートのスタンバイ・サイトのITシステムおよびストレージがアイドル状態の高可用性アーキテクチャがあり、そのスタンバイ・システムで処理できるビジネス用途が他にないとします。このスタンバイ・サイトの投資利益率に含まれるのは、フェイルオーバー・シナリオで使用された場合に回避される停止時間関連のコストのみです。これを、スタンバイ・サイトのITシステムおよびストレージがスタンバイ・ロール(レポート作成や、ユーザー問合せのプライマリ・システムのオーバーヘッドをオフロードする場合または読取り/書込みワークロードを分散する場合など)のときに、生産的に使用できる別の高可用性アーキテクチャと比較します。そのようなアーキテクチャの投資利益率には、回避された停止時間のコストと、高可用性やデータ保護を可能にすると同時に、生産的に使用した場合に発生する金銭的利益の両方が含まれます。

2.3 アーキテクチャへの要件のマッピング

ビジネス影響分析を行うと、すでに把握していることが文書化されます。様々なアプリケーションやそれらをサポートするいくつものデータベースがありますが、エンタープライズにとっての重要度は、それぞれに異なります。停止したとしても、すぐさまエンタープライズに影響するわけではないアプリケーションにとっては、高可用性インフラストラクチャへの高額の投資も意味を成しません。では、何から始めたらよいのでしょうか。

ビジネス影響分析の結果により、エンタープライズ内のデータベースが、同じようなRTOおよびRPOの目標を持つ別のデータベースとグループ化されます。そのグループを、統制された高可用性参照アーキテクチャのセットにマップすると、必要なサービス・レベルに最大限近づけることが可能です。データベース間に依存性がある場合は、高可用性要件が最も厳しいデータベースとグループ化されることに注意してください。

2.3.1 Oracle MAA参照アーキテクチャ

Oracle MAAのベスト・プラクティスでは、4つの高可用性参照アーキテクチャを定義し、あらゆる規模や業種のエンタープライズで必要とされる可用性とデータ保護のすべての範囲に対応しています。このアーキテクチャ(または層)には、Platinum、Gold、SilverおよびBronzeが指定されています。これらは、図2-2に記載されているサービス・レベルに対応します。

図2-2 Oracle MAA参照アーキテクチャ

各層では異なるMAA参照アーキテクチャを使用して、Oracle高可用性機能の最適なセットがデプロイされ、指定されたサービス・レベルが、最小限のコストと複雑さで確実に達成されます。これらの層は、メンテナンス、移行またはその他の目的による計画停止のみでなく、データ破損、コンポーネント障害、システムやサイトの停止など、あらゆるタイプの計画外停止にも明示的に対応します。

2.3.2 Bronze参照アーキテクチャ

Bronze層は、単純な再起動やバックアップからのリストアができれば、可用性は十分に高いというデータベースに適しています。Bronze層は単一インスタンスのOracle Databaseに基づいており、そこに組み込まれているMAAベスト・プラクティスでは、Oracle Enterprise Editionの全ライセンスに含まれている、データ保護と高可用性のための数多くの機能が使用されます。Oracle Recovery Manager (RMAN)を使用してOracleに最適化されたバックアップによりデータが保護され、停止によってデータベースが再起動しないよう、可用性をリストアするために使用されます。

2.3.3 Silver参照アーキテクチャ

Silver層では、様々なタイプの計画メンテナンスのみでなく、データベース・インスタンスやサーバー障害の際に、停止時間を最小限またはゼロにする必要があるデータベースの高可用性のレベルが高くなります。Silver層では、クラスタリング・テクノロジ(Oracle RACまたはOracle RAC One Node)が追加されます。RMANにより、データベースに最適化されたバックアップが作成されてデータが保護され、停止によってクラスタが再起動しないよう、可用性がリストアされます。

2.3.4 Gold参照アーキテクチャ

Gold層では、単一点障害に対する脆弱性を許容できない、ビジネス上重要なアプリケーションのリスクが大幅に低くなります。この層では、データベース対応のレプリケーション・テクノロジ(Oracle Active Data GuardおよびOracle GoldenGate)が追加され、本番データベースのレプリカが1つ以上同期されて、リアル・タイムのデータ保護と可用性が実現されます。データベース対応のレプリケーションにより、ストレージ・レプリケーション・テクノロジで可能な範囲を超えて、高可用性とデータ保護が大幅に強化されます。すべてのレプリカが常時、積極的に使用されるため、投資利益率が向上すると同時に、コストも削減されます。

2.3.5 Platinum参照アーキテクチャ

Platinum層には、Oracle Database 12cの複数の新機能と、以前から使用されていた製品で、最新リリースにおいて拡張されたものが導入されています。アプリケーション・コンティニュイティはそうした機能のうちの1つで、処理中のトランザクションが確実にリプレイされるため、ユーザーは停止したことに気が付きません。Oracle Active Data Guard Far Syncは、距離にかかわらず、データ損失ゼロの保護を可能にします。Oracle GoldenGateは、停止時間ゼロのアップグレードと移行を実現するために拡張されています。グローバル・データ・サービスは、レプリケートされたデータベース環境における、自動サービス管理とワークロードのバランシングを目的としています。これらのテクノロジのいずれも、実装に追加の作業が必要ですが、停止時間やデータ損失が許されない、最も重要なアプリケーションにとっては十分な価値があります。

2.3.6 層ごとの高可用性およびデータ保護の属性

表2-1に、各層に固有の高可用性およびデータ保護の属性をまとめます。それぞれの層には、その前の層の機能がすべて含まれ、そのアーキテクチャ上に層を構築することで、対応範囲が広がった障害の領域に対処しています。各アーキテクチャに含まれる様々なコンポーネントや、達成されるサービス・レベルについては、別のトピックで説明します。

表2-1 層ごとの高可用性およびデータ保護の属性

停止クラス/高可用性層

計画外停止(ローカル・サイト)

計画メンテナンス

データ保護

リカバリ不能なローカル停止および障害時リカバリ

Platinum

Platinum対応アプリケーションではアプリケーションの停止なし

アプリケーションの停止なし

包括的なランタイム検証と手動チェックの組合せ

Platinum対応アプリケーションではアプリケーションの停止なし、処理中のトランザクションを維持、データ損失ゼロ

Gold

包括的な高可用性と障害時リカバリ

すべてがローリングまたはオンライン

包括的なランタイム検証と手動チェックの組合せ

リアルタイム・フェイルオーバー、ゼロまたはゼロに近いデータ損失

Silver

自動フェイルオーバーを含む高可用性

一部ローリング、一部オンライン、一部オフライン

基本的なランタイム検証と手動チェックの組合せ

バックアップからのリストア、最後のバックアップ以降に生成されたデータを失う可能性

Bronze

単一インスタンス、リカバリ可能なインスタンスおよびサーバー障害での自動再起動

一部オンライン、大部分オフライン

基本的なランタイム検証と手動チェックの組合せ

バックアップからのリストア、最後のバックアップ以降に生成されたデータを失う可能性

3 可用性を最大化するための機能

この章では、MAAソリューションで使用されるOracle Databaseの機能について説明します。

- Oracle Data Guard

- Oracle GoldenGate

- ベスト・プラクティス: Oracle Active Data GuardおよびOracle GoldenGate

- Recovery Manager

- Oracle Secure Backup

- Oracle Real Application ClustersおよびOracle Clusterware

- Oracle RAC One Node

- Oracle Automatic Storage Management

- 高速リカバリ領域

- 破損の予防、検出および修復

- データ・リカバリ・アドバイザ

- Oracleセキュリティ機能

- Oracle Flashbackテクノロジ

- Oracle Data Pumpとデータ転送

- データベース以外のファイルに対するOracleレプリケーション・テクノロジ

- クライアントとアプリケーションのフェイルオーバー

- Oracle Multitenant

- Oracle Restart

- Oracle Site Guard

関連項目:

- 『Oracle Database概要』の高可用性の概要

- 『Oracle Database新機能ガイド』の新しい高可用性機能の一覧

3.1 Oracle Data Guard

Oracle Data Guardは、企業データの高可用性、データ保護および障害時リカバリを保証します。Data Guardは、Oracleデータベースが自然災害やデータ破損などのあらゆる種類の停止に耐えられるよう、1つ以上のスタンバイ・データベースの作成、メンテナンス、管理および監視を行うサービスの包括的なセットを提供します。Data Guardスタンバイ・データベースは本番データベースの正確なレプリカなので、従来のバックアップ、リストア、フラッシュバックおよびクラスタ技術と組み合せて透過的に利用し、可能なかぎり高いレベルのデータ保護とデータ可用性を提供できます。Data GuardはOracle Enterprise Editionに含まれています。

Data Guard構成は、1つのプライマリ・データベースと1つ以上のスタンバイ・データベースからなります。プライマリ・データベースは、単一インスタンスOracleデータベースまたはOracle RACデータベースのいずれかになります。プライマリ・データベースと同様に、スタンバイ・データベースは、単一インスタンスOracleデータベースまたはOracle RACデータベースのいずれかになります。プライマリ・データベースのバックアップ・コピーを使用してプライマリ・データベースからREDOを直接受信するスタンバイ・データベースを最大で30作成できます。オプションで、カスケード・スタンバイを使用して、プライマリがREDOを単一のリモート宛先に転送し、その宛先がREDOを複数のスタンバイ・データベースに転送する、Data Guard構成を作成することができます。これにより、プライマリ・データベースは必要に応じて、30よりも多くのスタンバイ・データベースと効率的に同期することができます。

注意:
Oracle Active Data Guardは基本Data Guardの拡張で、様々なタイプの処理を本番データベースからオフロードする高度な機能を提供し、データ損失ゼロの保護をどんな距離にでも拡張して、高可用性を強化します。Oracle Active Data GuardはOracle Database Enterprise Editionとは別のライセンスです。Oracle Active Data Guardについては、3.1.1項「Oracle Active Data Guard」で詳しく説明します。

スタンバイ・データベースにはいくつかのタイプがあります。Data Guardフィジカル・スタンバイ・データベースはデータ保護および障害時リカバリについてのMAAベスト・プラクティスで、最も一般的に使用されるスタンバイ・データベースのタイプです。フィジカル・スタンバイ・データベースはREDO適用(Oracleメディア・リカバリの拡張)を使用して、本番データベースの正確なフィジカル・レプリカを保持します。MAAベスト・プラクティスを使用して構成する場合、REDO適用は複数のOracle対応検証チェックを使用して、プライマリに影響を与える可能性のある破損がスタンバイに影響を与えることを防ぎます。その他のタイプのData Guardスタンバイ・データベースには、スナップショット・スタンバイ(テストまたはその他の目的で読取り/書込みでオープンするスタンバイ)、ロジカル・スタンバイ(計画停止時間の短縮のために使用)があります。

Data Guard使用の利点

- 更新がスタンバイ・データベースに適用される前に、Oracleデータ・ブロックおよびREDO内の構造の物理的および論理的整合性に対する複数のチェックを使用した、すべての変更のOracle対応の継続的な検証。これにより、スタンバイ・データベースが分離され、プライマリ・システムで発生する可能性のあるデータ破損による影響を受けることを防ぎます。

- 透過的な操作 - データ保護のためのData Guardフィジカル・スタンバイの使用には制約がありません。REDO適用はすべてのデータおよびストレージタイプ、すべてのDDL操作、およびすべてのアプリケーション(カスタムおよびパッケージ・アプリケーション)をサポートし、プライマリとスタンバイ・データベース間の整合性を保証します。

- 最高のパフォーマンス: 最高のリカバリ・ポイントの目標のための高速REDO転送、最高のリカバリ時間の目標のための高速適用パフォーマンス。

- なんらかの理由でプライマリ・データベースに障害が発生した場合の、可用性を維持するためのスタンバイ・データベースへの高速フェイルオーバー。フェイルオーバーはData Guardの構成方法により、手動または自動の操作になります。

- フェイルオーバーの発生後、アプリケーション・クライアントが新しいプライマリ・データベースに接続できるようにする、統合されたクライアント通知フレームワーク。

- フェイルオーバーの発生後、障害の発生したプライマリ・データベースの自動または自動化された(構成による)再同期化、同期化されたスタンバイ・データベースへの迅速な変換。

- すべてのネットワーク構成、可用性およびパフォーマンスSLA、ビジネス要件をサポートする、柔軟なデータ保護レベルの選択。

- Data Guard Brokerコマンド・ライン・インタフェースまたはOracle Enterprise Manager Cloud Controlのいずれかを使用して、プライマリおよびそのスタンバイ・データベースのすべてを単一の構成として管理し、管理と監視を簡略化。

- Data Guard Broker 12cは次の追加機能により大幅に管理容易性が向上しています。どの時点でも、構成によるリカバリ・ポイントの目標およびリカバリ時間の目標のSLAのサポートを自動的に監視するための、包括的な構成のヘルス・チェック、再開可能スイッチオーバー操作、ストリームライン・ロール・トランジション、カスケード・スタンバイ構成のサポート、転送および適用ラグに対するユーザー構成可能なしきい値。

- プライマリ本番データベースから送信されてカスケード・スタンバイ・データベースにより転送される単一のREDOストリームを使用した、複数のリモート宛先への効果的な転送。

- スナップショット・スタンバイにより、フィジカル・スタンバイ・データベースをテストおよび本番データのレプリカの読取り/書込みが必要なアクティビティ用に読取り/書込みでオープン可能。スナップショット・スタンバイは受信は続行しますが、プライマリにより生成された更新の適用は行いません。テストが完了すると、読取り/書込みでオープンしている間の変更を最初に破棄し、次にプライマリ・データベースから受信したREDOを適用することで、スナップショット・スタンバイは同期されたフィジカル・スタンバイ・データベースへと変換されて戻されます。プライマリ・データは常に保護されます。スナップショット・スタンバイはOracle Real Application Testingと一緒に使用される場合に特に有用です(スタンバイ・データベース(本番の正確なレプリカ)でのリプレイおよび後続のパフォーマンス分析のためにワークロードが本番データベースで取得されます)。

- スタンバイ・データベースを使用してローリング方式でメンテナンスを実行することにより、計画停止時間を短縮。停止時間はData Guardスイッチオーバーの実行に必要な時間だけです。つまりアプリケーションはメンテナンスの実行中も使用可能なままです。(詳細は、3.3.3項「Oracle Active Data GuardおよびOracle GoldenGateを一緒に使用する場合」および表5-7「システムおよびソフトウェア・メンテナンス用Oracle高可用性ソリューション」を参照してください。)

- プライマリ・システムとスタンバイ・システムで異なるCPUアーキテクチャまたはオペレーティング・システムが使用されているData Guard構成の柔軟性の向上は、My Oracle Support(http://support.oracle.com/)のノート413484.1に定義されている制限が前提です。

- Oracle Database 12cコンテナ・データベース(CDB)の効率的な障害時リカバリ。Data Guardフェイルオーバーおよびスイッチオーバーは、CDBに統合されたデータベース(プラガブル・データベースまたはPDB)の数にかかわらず、CDBレベルで1つのコマンドを使用して実行されます。

- Data Guard 12cにより、特定の管理特権であるSYSDGで、Data Guardに対する標準の管理業務を処理できるようになります。この新しい権限は、特定の機能を実行するのに必要な権限のみユーザーに付与され、それ以上は付与されない、最低限の権限の原則に基づいています。SYSDBA権限は以前のリリースでも引き続き動作します。

3.1.1 Oracle Active Data Guard

Oracle Active Data Guardはフィジカル・レプリケーション・プロセスを使用した、Oracleデータベースのリアルタイムのデータ保護および障害時リカバリに対するOracleの戦略的ソリューションです。Oracle Active Data Guardはまた、プライマリ・データベースから受信した変更を適用する間もスタンバイ・システムを読取り専用でオープンできることにより、障害時リカバリ・システムで高い投資利益率を提供します。Oracle Active Data Guardは、Oracle Enterprise Editionに含まれるData Guard機能を大幅に拡張する高度な機能を提供する、別個のライセンス製品です。

図3-1 Oracle Active Data Guardアーキテクチャ

Oracle Active Data Guardにより、プライマリ・データベースから受信した変更を適用する間も読取り専用でオープンできるフィジカル・スタンバイ・システムに、プライマリ・データベースから処理をオフロードすることにより、管理者はパフォーマンスを向上できます。Oracle Active Data Guard 12cのオフロード機能は、次のものを含むように強化されました。読取り専用レポート作成およびグローバル一時表および一意のグローバルまたはセッション順序へのDMLを含む非定型問合せ、データの抽出、高速増分バックアップ、REDO転送圧縮、複数のリモート宛先の効果的な処理、およびプライマリ・データベースのパフォーマンスに影響を与えずにデータ損失ゼロの保護をリモート・スタンバイ・データベースへ拡張する機能。Oracle Active Data Guardはまた、自動ブロック修復を実行し、高可用性アップグレードを可能にする(データベース・ローリング・アップグレードをより容易に実装するためのOracle Database 12cでの新しい自動化)ことにより、可用性を向上させます。

注意:
Oracle Active Data GuardはOracle Database Enterprise Editionのデータベース・オプション・ライセンスとして、別個にライセンスされます。すべてのOracle Active Data Guard機能も、Oracle Enterprise EditionのOracle Golden Gateライセンスに含まれます。これにより顧客は、Oracle Active Data Guardのスタンドアロン・ライセンス、またはすべての高度なOracleレプリケーション機能へのアクセスを取得するためのOracle GoldenGateのライセンスを選択できるようになります。

Oracle Active Data Guardの利点

Oracle Active Data Guardは前述のData Guardの利点のすべてと、次の内容を継承します。

- プライマリ・データベースのパフォーマンスの向上: 読取り専用アプリケーション、レポート作成および非定型問合せのOracle Active Data Guardスタンバイ・データベースへの本番オフロード。読取り専用データベースと互換性のあるアプリケーションはOracle Active Data Guardスタンバイで実行できます。Oracleは多くのOracle E-Business Suite Reports、PeopleToolsのレポート作成、Oracle Business Intelligence Enterprise Edition (OBIEE)およびOracle TopLinkアプリケーションのOracle Active Data Guardスタンバイ・データベースへのオフロードを可能にする統合も提供します。

- Oracle Active Data Guard 12cでは、グローバル一時表へのDMLの新しいサポートおよびスタンバイ・データベースでの順序の使用を提供します。これにより本番データベースからOracle Active Data Guardスタンバイ・データベースへオフロードできる読取り専用アプリケーションの数が大幅に増加します。

- 複数のOracle Active Data Guardスタンバイ・データベースを使用して、読取りパフォーマンスを容易に高めることのできるユニークな機能は、リーダー・ファームとも呼ばれます。

- Oracle Data Pumpまたはその他のソース・データベースから直接読み取る手法を使用した、データの抽出の本番オフロード。

- プライマリとスタンバイ・データベースが数百または数千マイルも離れている、同期したデータ損失ゼロの構成で、ネットワーク待機時間からのパフォーマンスの影響の本番オフロード。Oracle Active Data Guard 12c遠隔同期はプライマリ・データベースとは独立したシステムにデプロイされた軽量インスタンス(制御ファイルおよびアーカイブ・ログ・ファイル、しかしリカバリ・ファイルおよびデータ・ファイルではない)を使用します。遠隔同期インスタンスは、アプリケーションが同期転送のパフォーマンスの影響に耐えて最適な保護を提供できる、プライマリ・システムから最も離れた場所に配置するのが理想的です。Data GuardはREDOを遠隔同期インスタンスに同期して転送し、遠隔同期はそのREDOを最終フェイルオーバー・ターゲットであるリモート・スタンバイ・データベースに非同期に転送します。プライマリ・データベースに障害が発生すると、Data Guard構成で使用される同じフェイルオーバー・コマンドまたはOracle Enterprise Manager 12cを使用したマウスのクリック、またはData Guardファスト・スタート・フェイルオーバーを使用した自動フェイルオーバーは、リモート宛先へのデータ損失ゼロのフェイルオーバーを実行します。この透過性は、同期構成でのWANネットワーク待機時間のプライマリ・データベースのパフォーマンスの影響を回避しながら、REDOをプライマリ・データベースから直接受け取っているかのように、データ損失ゼロの保護をリモート・スタンバイ・データベースに拡張します。

- 遠隔同期を使用した複数のリモート・スタンバイ宛先にサービスするオーバーヘッドの本番オフロード。遠隔同期構成では、プライマリ・データベースは同期または非同期転送を使用して、REDOの単一のストリームを遠隔同期インスタンスへ送信します。遠隔同期インスタンスは、ソース・データベースの増分オーバーヘッドなしで、REDOを29のリモート宛先に非同期で転送できます。

- Data Guardの最大可用性では、NOAFFIRMREDO転送属性がサポートされます。REDOがメモリーで受信されるとすぐに、スタンバイ・データベースは受領通知をプライマリ・データベースに返します。スタンバイ・データベースでは、リモート・ファイル・サーバー(RFS)によるスタンバイREDOログ・ファイルへの書込みを待っていません。
この機能により、最大可用性とSYNCREDO転送を使用するData Guard構成でのプライマリ・データベースのパフォーマンスが向上します。高速同期により、最大可用性構成内のプライマリ・データベースが、スタンバイ・データベースでの遅いI/Oによるパフォーマンスの影響から隔離されます。この新しいFAST SYNC機能は、フィジカル・スタンバイ・ターゲットとともに使用することも、遠隔同期構成内で使用することも可能です。

- REDO転送圧縮の実行に必要なCPUサイクルの本番オフロード。Data Guard構成がOracle Advanced Compression用にライセンスされている場合、REDO転送圧縮は遠隔同期インスタンスにより実行できます。これはプライマリ・データベースの増分オーバーヘッドなしでバンド幅を保存します。

- RMANブロック変更のトラッキングのためにOracle Active Data Guardサポートを使用することで、高速増分バックアップをプライマリ・データベースからスタンバイ・データベースへ移動することによる、本番オフロードおよびバックアップ・パフォーマンスの向上。

- プライマリまたはスタンバイのいずれかで検出されたブロック破損を、アプリケーションおよびユーザーに透過的に修復するために、Oracle Active Data Guard自動ブロック修復を使用した高可用性の向上。

- Oracle Active Data Guard 12cの新しい機能の高可用性アップグレードにより提供される追加の自動化を使用して(3.1.3.3項「Active Data Guardを使用したローリング・アップグレード」参照)、新しいOracle Databaseパッチ・セットおよびデータベース・リリースへのアップグレードの計画停止時間を短縮することにより、高可用性を向上。

3.1.2 従来のソリューションより優れているData Guardの利点

Data Guardには、従来のソリューションよりも優れた次のような多くの利点があります。

- データ破損、書込み欠落、データベースおよびサイト障害に対するデータベース・フェイルオーバーは、高速かつ自動で実行され、従来のソリューションを使用した場合は数時間かかるリカバリが、Data Guardでは数秒になります

- Oracle Active Data Guard遠隔同期の使用時、Wide Area Network(WAN)経由でデータ損失ゼロ

- Active Data Guard遠隔同期を使用したREDO転送圧縮処理のオフロードおよび最大29のリモート宛先へのREDO送信

- 破損自動修復の機能により、プライマリ・データベースまたはフィジカル・スタンバイ・データベースの物理ブロックの破損を、フィジカル・スタンバイ・データベースまたはプライマリ・データベースの良好なブロックをコピーして自動的に置換

- プライマリ・データベースでのデータ破損と書込み欠落に対する最も包括的な保護

- ストレージ、Oracle ASM、Oracle RAC、システムの移行と一部のプラットフォームの移行、およびData Guardスイッチオーバーを使用した変更による停止時間の短縮

- Data Guardのローリング・アップグレード機能による停止時間の短縮

- リアルタイム問合せの適用ラグ機能を使用して、スタンバイ・データベースを読取り専用リソースとして使用するRTOおよびRPOの機能を犠牲にせずに、プライマリ・データベースのアクティビティ(バックアップ、問合せまたはレポート作成など)のオフロードが可能

- サイト全体のフェイルオーバー操作の一部としてOracle Database File System (DBFS)またはOracle Automatic Storage Managementクラスタ・ファイル・システム(Oracle ACFS)を使用したデータベース以外のファイルの統合機能(3.15項「データベース以外のファイルに対するOracleレプリケーション・テクノロジ」を参照してください)

- サイト障害の後で、インスタンスの再起動、ストレージの再マスタリングまたはアプリケーションの再接続が不要

- アプリケーションに対する透過性

- アプリケーション・フェイルオーバーに対する透過的な統合サポート(アプリケーション・コンティニュイティおよびトランザクション・ガード)

- ネットワーク使用の効率化

Oracle Databaseに常駐するデータの場合、データ損失ゼロ機能が組み込まれているData Guardは、データ保護および障害時リカバリに関して従来のリモート・ミラー化ソリューションよりも効率的かつ安価でより最適化されています。Data Guardには、障害時リカバリとデータ保護のテクノロジを選択する際に、従来のリモート・ミラー化ソリューションよりもData Guardを採用する方が正しいとする、技術上およびビジネス上の理由があります。

3.1.3 Data Guardおよび計画メンテナンス

Data Guardスタンバイ・データベースを使用してローリング方式でメンテナンスを実行することにより、計画停止時間を短縮できます。スタンバイ・データベースで変更が最初に実装されます。新しいバージョンが本番用に確実に準備できるまで、古いバージョンでプライマリを実行し、新しいバージョンでスタンバイを実行する構成が可能です。次にData Guardスイッチオーバーが実行され、本番が新しいバージョンに遷移します。データベースの停止時間はスイッチオーバーを実行するのに必要な時間のみです。

Data Guardスタンバイを使用してローリング方式でメンテナンスを実行するには、いくつかの方法があります。顧客の要件および好みにより、どの方法を使用するかが決まります。このドキュメントで説明する方法は、次のとおりです。

- Data Guard REDO適用およびStandby-First Patchの適用

- Data Guard一時ロジカル・ローリング・アップグレード

- Oracle Active Data Guardを使用したローリング・アップグレード

3.1.3.1 Data Guard REDO適用およびStandby-First Patchの適用

Oracle Database 10gから、Data Guard REDO適用を使用してクロス・プラットフォームのサポートの柔軟性が向上しました。特定のData Guard構成で、プライマリおよびスタンバイ・データベースは、異なるオペレーティング・システム(WindowsとLinuxなど)、ワード・サイズ(32ビット/64ビット)またはハードウェア・アーキテクチャのシステムで実行できます。REDO適用を使用して、Oracle Automatic Storage Management (ASM)への移行、単一インスタンスOracle DatabasesからOracle RACへの移行、テクノロジ・リフレッシュの実行、またはあるデータ・センターから次のデータ・センターへの移動を実行することもできます。

Oracle Database 11g リリース2 (11.2)から、Standby-First Patchの適用(REDO適用を使用したフィジカル・スタンバイ)は、ローリング方式でOracleパッチを適用および検証する目的で、プライマリ・データベースとそのフィジカル・スタンバイ・データベース間で異なるソフトウェア・パッチ・レベルをサポートします。Standby-First Patchの適用が可能なパッチには次のものがあります。

- データベースのパッチ・セット更新(PSU)

- データベースのクリティカル・パッチ・アップデート(CPU)

- データベースのバンドル・パッチ

- Oracle Exadata Database Machineバンドル・パッチ

- Exadata Storage Server Softwareパッチ

- 既存のOracleデータベースのバージョンと互換性のあるあらゆるオペレーティング・システム、システム・ファームウェアまたはシステム変更

Standby-First Patchの適用は、Oracle Database Enterprise Edition 11g リリース2 (11.2)以降の認定ソフトウェア・パッチでサポートされます。

前述の計画メンテナンスの各タイプで、構成はプライマリおよびフィジカル・スタンバイ・データベースから始まります(新しいプラットフォームまたはASM、Oracle RACへの移行の場合、スタンバイは新しいプラットフォームに作成されます)。すべての変更がフィジカル・スタンバイ・データベースで実装されると、REDO適用(フィジカル・レプリケーション)が使用されてスタンバイとプライマリが同期します。Data Guardスイッチオーバーが使用され、本番がスタンバイ(新しい環境)に転送されます。

関連項目:

- Data Guard構成でサポートされる混在プラットフォームの組合せの詳細は、My Oracle Supportのノート413484.1(http://support.oracle.com/)を参照してください。

- Standby First Patchの適用の詳細は、My Oracle Supportのノート1265700.1(http://support.oracle.com/)、ターゲット・パッチがStandby-First Patchとして認定されているかどうか判断するには、各パッチのREADMEを参照してください。

3.1.3.2 Data Guard一時ロジカル・ローリング・アップグレード

データベースの元のバージョンと変更後またはアップグレードされたバージョンを同期するのに、REDO適用(フィジカル・レプリケーション)を使用できない、多くのタイプのメンテナンス・タスクがあります。次のようなタスクがあります。

- Standby-First Patchの適用に適格ではないデータベース・パッチまたはアップグレード。これにはデータベース・パッチ・セット(11.2.0.2から11.2.0.3)および新しいOracle Databaseのリリース(11.2.0.3から12.1)が含まれます。

- 停止時間を必要とするデータベースの物理構造を変更するメンテナンスが実行される必要があります(パーティション化されていない表へのパーティションの追加、Basicfile LOBからSecurefile LOBへの変更、XML-CLOBからBinary XMLへの変更、表のOLTP圧縮への変更など)。

Data Guard SQL Apply (ロジカル・レプリケーション)を使用して、以前のタイプのすべてのメンテナンスを、Data Guardスタンバイ・データベースを使用したローリング方式で実行し、古いバージョンのデータベースと新しいバージョンのデータベースを同期できます。Oracle Database 11g以前、これにはロジカル・スタンバイ・データベースの作成、ロジカル・スタンバイでのメンテナンスの実行、スタンバイとプライマリの再同期、およびスイッチオーバーが必要でした。さらに、フィジカル・スタンバイが障害時リカバリに使用された場合、新しいフィジカル・スタンバイ・データベースは新しいバージョンで本番データベースのバックアップから作成される必要があります。これは複数のTBデータベースのアップグレード時の、多くのロジスティックおよびコスト上の課題を表しています。

Oracle Database 11g以降、データベースのローリング・アップグレードでは、一時ロジカルと呼ばれる、フィジカル・スタンバイ・データベースで始まりフィジカル・スタンバイ・データベースで終わる、新しいプロシージャを使用できます。SQL Applyは、Data Guardが古いバージョンと新しいバージョンで同期している場合のフェーズ中でのみ使用されます。フィジカル・スタンバイがすでに所定の場所にある場合、新しいロジカル・スタンバイ・データベースを作成する必要はありません。メンテナンスが完了した後に、新しいフィジカル・スタンバイ・データベースを、新しいバージョンで本番データベースのバックアップから作成する必要はありません。インプレース・フィジカル・スタンバイを持つData Guard構成のアップグレードの従来のプロセスと同様に、元のプライマリは新しいプライマリ・データベースからのREDOおよびREDO適用を使用してアップグレードまたは変更されます(単一カタログのアップグレードではプライマリおよびスタンバイ・データベースの両方を新しいOracleリリースに移行します)。

一時ロジカル・アップグレードでは、プライマリ・データベースがOracle Database 11g リリース1(11.1)以降で、データベースがSQL Applyの前提条件を満たしていることが必要です。

一時ロジカル・ローリング・アップグレード・プロセスに必要ないくつかの手動の手順を自動化するBourneシェル・スクリプトが用意されています。詳細は、MAAベスト・プラクティス・ペーパー『容易になったデータベースのローリング・アップグレード』(http://www.oracle.com/technetwork/database/features/availability/maa-wp-11g-upgrades-made-easy-131972.pdf )を参照してください。

関連項目:
MAA Best Practice Paper『Database Rolling Upgrades Made Easy』(http://www.oracle.com/goto/maa)

3.1.3.3 Oracle Active Data Guardを使用したローリング・アップグレード

Oracle Database 12cでは、Oracle Active Data Guardを使用したローリング・アップグレードが導入され、前述の手動一時ロジカル・ローリング・アップグレードで表される方法よりも、より簡単で、自動化された、容易に繰返し可能な、計画停止時間を短縮するための方法が提供されます。Oracle Active Data Guardを使用したローリング・アップグレードでは、手動プロシージャで必要な42以上の手順が、いくつかの使いやすいDBMS_ROLLING PL/SQLパッケージに変換されます。

Oracle Active Data Guardを使用したローリング・アップグレードの手順は次のとおりです。

- DBMS_ROLLING.INIT_PLANのコール

- アップグレード・プロセスを管理者にガイドするための、構成に固有の指示セットを含むアップグレード・プランを生成

- DBMS_ROLLING.SET_PARAMETERのコール

- ローリング・アップグレードのパラメータを変更

- アップグレードに関連するすべてのデータベースで新しいソフトウェアをインストール

- DBMS_ROLLING.START_PLANのコール

- アップグレードに関連するプライマリおよびスタンバイ・データベースを構成

- スタンバイ・データベースをアップグレードまたは変更

- DBMS_ROLLING.SWITCHOVERのコール

- スイッチオーバーによる本番の新しいバージョンへの移行

- スイッチオーバーは必要な停止時間のみ

- 可能な場合、新しいバイナリを使用して前のプライマリを再起動

- DBMS_ROLLING.FINISH_PLANのコール

- Data Guard構成で古いプライマリと追加のスタンバイ・データベースのアップグレードを完了し、新しいプライマリと同期

Oracle Active Data Guardを使用したローリング・アップグレードには次のメリットがあります。

- 簡単な指定-コンパイル-実行プロトコルを提供

- コンパイル手順で構成エラーを検出

- 実行時エラーを実行中に検出

- 状態をデータベースに保持

- 信頼できる、繰返し可能なプロセスが可能

- 含まれるデータベースの数に関係なく、実行時の手順は一定

- 元のプライマリ・データベースでエラーを処理

- アップグレードされたプライマリに対するデータ保護がいつでも可能

Oracle Active Data Guardを使用するローリング・アップグレードは、Oracle Active Data Guardライセンスと、プライマリ・データベースがOracle Database 12c リリース1(12.1)以降で、データベースがSQL Applyの前提条件を満たしていることが必要です。プライマリ・データベースが以前のOracle Databaseリリースの場合、MAAホワイト・ペーパー『容易になったデータベースのローリング・アップグレード』(http://www.oracle.com/goto/maa)を参照してください。

関連項目:
『Oracle Data Guard概要および管理』のDBMS_ROLLINGを使用したローリング・アップグレードの実行に関する項。

3.2 Oracle GoldenGate

Oracle GoldenGateはデータ分散およびデータ統合のためのOracleの戦略的ロジカル・レプリケーション・ソリューションです。他のベンダーのレプリケーション・ソリューションとは違い、Oracle GoldenGateはOracle Databaseとより密接に統合されながらも、異機種データベース管理システム間のレプリケーションに最適な、オープンなモジュラー・アーキテクチャも提供します。これらの性質の組合せにより妥協が排されるため、Oracle GoldenGateはOracle Database環境と非Oracle Database環境にまたがる要件に対処するための優先のレプリケーション・ソリューションとなります。

Oracle GoldenGateはリアルタイムのログ・ベースの変更データの取得およびレプリケーション・ソフトウェア・プラットフォームを提供します。このソフトウェアでは、異種のデータベース間で、トランザクション・データのキャプチャ、ルーティング、変換および配信をリアルタイムに行います。

典型的な環境として、取得、ポンプおよび配信プロセスがあります。これらの各プロセスは、Oracle Databaseおよび非Oracleデータベースを含む、ほとんどの一般的なオペレーティング・システムおよびデータベースで実行できます。データのすべてまたは一部をレプリケートすることができ、プロセス内のデータは、異機種環境だけでなく、異なるデータベース・スキーマでも操作できます。Oracle GoldenGateはマルチマスター・レプリケーション、ハブ・アンド・スポーク方式のデプロイメントおよびデータ変換をサポートします。

3.2.1 Oracle GoldenGate 12c

Oracle GoldenGate 12cはレプリケーション機能とOracle Databaseとの統合が大幅に強化された重要な新しい機能を提供します。新しい機能は次のとおりです。

- マルチテナント・アーキテクチャやクラウド環境でのデータ取得と配信のサポートなど、Oracle Database12cが最適化されました。クラウド環境のサポートは、リリース11.2.1から使用可能でした。

- Oracle GoldenGate用に作成された軽量のストリーミングAPIを利用しているOracle Databaseへの配信が統合され、パフォーマンスとスケーラビリティが向上しました。単一のReplicat構成内において、元のトランザクションのアトミック性を保持しながら、複数のインバウンド・サーバーの子プロセス(適用サーバーとも言う)により、トランザクションを並行して適用します。この並列度は、Replicatプロセスを構成する際に、ターゲット・システムの数だけ増やすことも、必要に応じて動的に調整することも可能です。この機能は、Oracle 11.2.0.4および12cでのみ使用できます。

- 調整配信は、複数のReplicatプロセスを管理する複雑さを軽減します。調整配信により、調整イベント(DDL、SQLEXEC文、EVENTACTIONSなど)の適用が管理され、SCNの順序で適用されます。これにより、スケーラビリティとパフォーマンスの向上を必要としているユーザーが、DDL操作のレプリケートや、データに対する特定の問合せまたはチェックを実行できるようになります。

- 統合キャプチャは、データベースに表を含めることで、表のレプリケートが可能かどうかを判断しやすくして、使用性が向上するよう拡張され、DDL解決機能も、データベース・レベルのトリガーなしでREDOログから直接DDLを読み取れるよう拡張されました。この機能は、統合Extractとともに、Oracle Database 11gリリース11.2.0.4以降およびOracle Database 12cリリース12.1.0.2以降でのみ使用できます。

- 使用性を向上し、実装を簡素化するために、多数のパラメータが変更されました。DISCARDFILEにデフォルト値が設定されたため、Replicatでこのパラメータを指定する必要がなくなりました。デバッグ、エラー・ロギング、スキーマのワイルドカード検索機能のみでなく、システムを完全にレプリケートできるようデータベース全体を拡張しました。

- Oracle Walletおよび資格証明ストアの機能が追加され、ユーザー名とパスワードのセキュリティが向上しました。

- 取得と配信の両方で、Informixリリース11.5、11.7および12.1がサポートされます。

3.2.2 Oracle GoldenGate 11gリリース2

Oracle GoldenGate 11gリリース2はレプリケーション機能とOracle Databaseとの統合が大幅に強化された重要な新しい機能を提供します。新しい機能は次のとおりです。

- 統合キャプチャのパフォーマンスの向上 - Oracle GoldenGate 11gリリース2で導入された統合キャプチャが、より高速なパフォーマンスを実現するよう改善されました。この拡張はユーザーに対して透過的であり、構成を変更する必要はありません。

- 統合Replicat - Oracle用のReplicatを統合モードで使用できるようになり、Oracleターゲット環境でのスケーラビリティが向上しました。統合モードにおいて、Replicatプロセスでは、Oracleデータベース内で使用可能な適用処理機能が使用されます。統合Replicatでは、参照整合性およびデータ定義言語(DDL)の操作が処理され、それらの操作が適切な順序で実行されていることが確認されるため、管理者は、親子関係や、複数の表が関連するDDLまたは単一の表内における構造の変更などに注意を払う必要がありません。

- マルチテナント・コンテナ・データベースへの取得および適用 - Oracle GoldenGateで、Oracleマルチテナント・コンテナ・データベース(CDB)からの取得と配信がサポートされるようになりました。

- ネイティブDDLキャプチャ - このリリースのOracle GoldenGateには、統合モードでのExtractに対するネイティブDDLキャプチャが導入されています。ネイティブDDLキャプチャを使用することにより、サポートされているOracleバージョンのDDLを取得するために、DDLトリガー(およびサポートされているオブジェクト)を使用する必要がなくなります。ネイティブDDLキャプチャにより、DDLの取得がデータベース・ローミング・サーバーに統合されます。

関連項目:

- Oracle GoldenGateのドキュメント(http://www.oracle.com/technetwork/middleware/goldengate/documentation/index.html)

3.2.3 Oracle GoldenGateおよび最大可用性アーキテクチャ

Oracle GoldenGate論理レプリケーションにより、Oracle GoldenGate構成のすべてのデータベース(ソースおよびターゲット・データベースの両方)を読取り/書込みで開くことができます。この事実とOracle GoldenGateのアドバンスト・レプリケーション機能との組合せにより、停止時間ゼロのメンテナンス、クロス・プラットフォームの移行を使用したデータの連続可用性に対する広範囲の挑戦に対処するための、MAAの主要なコンポーネントになっています。具体的には次のとおりです。

- ゼロまたはゼロに近い停止時間でのメンテナンス。この点においてOracle GoldenGateでは、Data Guardで提供される基本機能よりも高い柔軟性が提供されます。Oracle GoldenGateのソースおよびターゲット・データベースは、異なるフィジカルおよびロジカル構造を持つことが可能で、異なるハードウェアおよびオペレーティング・システム・アーキテクチャに存在でき、異なるOracle Databaseリリースに拡張(たとえば9iから12c)、またはOracleと非Oracleシステムの混在が可能です。メンテナンスは本番がソースで実行している間に、まずターゲット・データベースで実行されます。メンテナンスが完了すると、Data Guardスイッチオーバーのように、本番を一度にすべてソースに移動できます。オプションで、双方向レプリケーションを使用して、停止時間ゼロと認識させて、ユーザーを新しいシステムへ徐々に移動できます。いずれの場合も、Oracle GoldenGateレプリケーションは、遷移中、逆方向に元のソース・システム・データベースの同期化を保持することが可能で、これにより、必要な場合、最小限の停止時間でデータの損失なしで、簡単に前のバージョンへの計画フォールバックが実行できます。

- ゼロまたはゼロに近い停止時間でのアプリケーションのアップグレード。バックエンド・データベース・オブジェクトを変更するアプリケーション・アップグレードでは、通常、メンテナンスの実行中、大幅な計画停止時間が発生します。Oracle GoldenGateレプリケーションでは、アプリケーションの前のバージョンにより使用されたデータベース・オブジェクトを、アプリケーションの新しいバージョンで変更されたオブジェクトにマップするデータ変換が可能です。これにより、アプリケーションの可用性に影響を与えずに、本番データベースの別のコピーで、データベース・メンテナンスの実行が可能になります。メンテナンスが完了し、Oracle GoldenGateの古いバージョンと新しいバージョンの同期が終了すると、ユーザーはアプリケーションの新しいバージョンにスイッチできます。

- Oracle GoldenGateでは、ソース・データベースと同期化されている間も、レプリカ・データベースへの読取り/書込みアクセスが可能です。これは、レポート・アプリケーションが動作のためにデータベースへの読取り/書込みを必要とする場合の、本番データベースのコピーへのレポート作成のオフロードに最も頻繁に使用されます。しかしこれは、アプリケーション層に使用されるテクノロジの性質が、リカバリ時間の目標を満たすために常にDRデータベースへのアクティブな読取り/書込み接続を必要とする、特定の障害時リカバリ環境にも関係します。Oracle GoldenGateがOracle Active Data Guardのかわりに後者のケースで使用される場合、Oracle Active Data Guardスタンバイにより提供される追加のデータ保護、簡略性および透過性が、常に読取り/書込みでオープンされているフェイルオーバー・ターゲットと引換えにされます。

- すべてが同じデータを含み、Oracle GoldenGateと同期された複数のデータベースが存在する、マルチマスターおよび双方向レプリケーション・アーキテクチャ。どのデータベースでの更新も他のすべてのデータベースに即座にレプリケートされます。更新の競合は、アプリケーションにより処理されるか、またはOracle GoldenGateを使用して構成された競合ハンドラで処理されるか、あるいは手動で解決されます。これはワークロードのバランシングおよびデータの可用性と操作の簡略性の対比を強調するアーキテクチャです。Oracle GoldenGateの各ソースはまた、最適な障害保護のために、Data Guardスタンバイ・データベースにより保護されます。オプションで、コスト上の考慮事項より、Data Guard物理スタンバイ・データベースの追加のコストをかけずに、各Oracle GoldenGateレプリカを使用してデータの可用性とDR保護の両方を提供できます。

関連項目:
Oracle GoldenGateのドキュメント

3.3 ベスト・プラクティス: Oracle Active Data GuardおよびOracle GoldenGate

Oracle Active Data GuardおよびOracle GoldenGateはそれぞれOracle Databaseの同期化されたコピーを保持できますが、要件に応じて、1つのテクノロジまたは別のテクノロジ、あるいは同時に両方を使用できる高可用性アーキテクチャになる、ユニークな特徴があります。Oracle Database 12cに関連するユースケースに対するMAAベスト・プラクティス・ガイドラインの例は次のとおりです。

3.3.1 Oracle Active Data Guardを使用する場合

簡易性、データ保護および可用性が重要視される場合、Oracle Active Data Guardを使用します。

- Oracle Database全体の最も簡単で高速な一方向レプリケーション。

- 制約なし: Data Guard REDO適用はすべてのデータ型と記憶域のタイプおよびOracle機能、DDLの透過的レプリケーションをサポートします。

- データ保護に最適化された機能: ソースまたはターゲットに発生する可能性のあるサイレントな破損を検出し、破損ブロックを自動的に修復

- 同期されたスタンバイの読取り専用でのオープンにより、最大ROIのための簡単な読取り専用オフロードが提供

- バックアップの透過性: Data Guardのプライマリおよびスタンバイはお互いに物理的に正確なコピーであり、RMANバックアップは完全に代替可能

- データベースのパフォーマンスに影響を与えず、どんな距離でもデータ損失なしの保護

- Standby-First Patchの適用、データベースのローリング・アップグレード、プラットフォームの移行の選択を使用した計画停止時間およびリスクの最小化

- Data Guardスナップショット・スタンバイを使用したテスト用の二重目的のDRシステムによる変更の導入のリスクの減少

- 統合されたデータベースおよびクライアントの自動フェイルオーバー

- 構成全体の統合された管理: Data Guard Brokerコマンド・ラインまたはOracle Enterprise Manager Cloud Control

3.3.2 Oracle GoldenGateを使用する場合

Oracle Active Data Guardで対処されない高度なレプリケーション要件が重要視される場合、Oracle GoldenGateを使用します。

- プライマリ・データベースと同期しながら、レプリカ・データベースを読取り/書込みでオープンする必要がある要件

- マルチマスターおよび双方向レプリケーション、サブセットのレプリケーション、多対1レプリケーションおよびデータ統合などのデータ・レプリケーション要件。

- エンディアン形式のプラットフォーム間またはデータベース全体のメジャー・バージョン間で、データ・レプリケーションが必要な場合。

- ゼロまたはゼロに近い停止時間が必要なメンテナンスまたは移行。Oracle GoldenGateを使用して、停止時間なしで、Application 1.0からApplication 2.0へなど、アプリケーションのバージョン間で移行できます。

- 高速フォールバックの目的で、新しいバージョンから古いバージョンにレプリケートする場合のデータベースのローリング・アップグレードは、うまくいきません。

- 双方向レプリケーションを使用して、停止時間ゼロを認識させて、ユーザーを新しいシステムへ徐々に移動する場合の、停止時間ゼロの計画メンテナンス。双方向レプリケーションでは異種のデータベースで発生する可能性のある更新の競合を回避または解決する必要があります。

3.3.3 Oracle Active Data GuardおよびOracle GoldenGateを一緒に使用する場合

Oracle Active Data GuardおよびOracle GoldenGateは相互に排他的ではありません。次に示すのは、Oracle Active Data GuardとOracle GoldenGateの同時使用を含む、高可用性アーキテクチャのユースケースです。

- Oracle Active Data Guardスタンバイは、ミッション・クリティカルなOLTPデータベースに対する障害保護およびデータベースのローリング・アップグレード用に使用されます。同時に、Oracle GoldenGateは、エンタープライズ・データ・ウェアハウスのETL更新に対し、Data Guardプライマリ・データベースから(またはOracle GoldenGate ALOモードを使用してスタンバイ・データベースから)データをレプリケートするのに使用されます。

- Oracle GoldenGateサブセットのレプリケーションを使用して、多数のデータ・ストアからデータを抽出、変換および集計する、操作データ・ストア(ODS)を作成します。ODSは企業に多くの収益をもたらす、ミッション・クリティカルなアプリケーション・システムをサポートします。Oracle Active Data Guardスタンバイ・データベースを使用して、ODSを保護し、最適なデータ保護と可用性を提供します。

- Oracle GoldenGateの双方向レプリケーションは、数千マイル離れた2つのデータベースを同期させるために使用されます。ユーザー・ワークロードは、Oracle 12cグローバル・データ・サービス(GDS)を使用して、地理、ワークロードおよびサービス・レベルに基づき各データベース間で分散されます。Oracle GoldenGateのコピーは、停止が発生した場合にデータ損失ゼロのフェイルオーバーを可能にする、固有のローカル同期Data Guardスタンバイ・データベースを持ちます。Oracle GoldenGateのキャプチャおよび適用プロセスは、プライマリとスタンバイがお互いに正確で最新のレプリカであるので、フェイルオーバー後の新しいプライマリ・データベースで容易に再起動されます。

- 障害保護用に使用されているOracle Active Data Guardスタンバイ・データベースは、Data Guardによりサポートされない計画メンテナンスの実行のために、一時的にOracle GoldenGateターゲットに変換されます。たとえば、バックエンド・データベース・オブジェクトの変更を必要とするSiebelアプリケーションのアップグレードで、ユーザーを新しいシステムにスイッチオーバーする前に包括的なテストが必要な場合です。

- Oracle Active Data Guardは、停止時間がゼロまたはゼロに近い状態で、データベースのメジャー・バージョンのアップグレード(Oracle 11.2.0.3から12cなど)が必要な場合に、本番環境の保護に使用されます。新しいバージョンのデータベースを使用して、プライマリ/スタンバイ環境がもう1つ作成され、Oracle GoldenGateは、本番環境からコピーの環境へ、一方向または双方向のレプリケーションでデータをレプリケートするために使用されます。Oracle GoldenGateで古い環境と新しい環境の同期が完了すると、本番は新しい環境に切り替わり、古い環境は廃止されます。これによって、構成により停止時間はゼロまたは最小となり、古い環境と新しい環境が完全に分離されることでリスクが軽減され、アップグレード・プロセス中に問題が発生しても、データ保護および可用性SLAへの影響が回避されます。

3.4 Recovery Manager

Recovery Manager (RMAN)は、データベースを効率的にバックアップおよびリカバリするための包括的な基盤を提供します。RMANは、操作の複雑さを排除するとともに、データベースの優れたパフォーマンスおよび可用性をもたらします。

RMANは、リクエストされたバックアップ、リストアまたはリカバリの操作を実行する最も効率的な方法を決定し、Oracle Databaseサーバーでの処理のために、これらの操作を発行します。RMANおよびサーバーは、データベース構造に加えられた変更を自動的に識別し、変更に適応するために必要な操作を動的に調整します。

RMANには次のような利点があります。

- クロス・プラットフォームのバックアップおよびリストアのサポート(Oracle Database 12cでの新機能)。

- RESTORE操作によりデータ・ファイルをデータベース間でネットワークを介して直接コピーできる、ネットワーク対応のRESTORE操作(Oracle Database 12cでの新機能)

- RECOVER TABLEコマンドを使用した簡略化された表のリストア(Oracle Database 12cでの新機能)。

- 個々のプラガブル・データベースのバックアップおよびリカバリを含む、Oracle Multitenantのサポート(Oracle Database 12cの新機能)

- バックアップおよびリストア操作での自動チャネル・フェイルオーバー

- リストア操作で欠落した、または破損したバックアップが検出された場合に、前回のバックアップへの自動フェイルオーバー

- リカバリ中の一時ファイルおよび新規データベースの自動作成

- 前回のポイント・イン・タイム・リカバリを使用した自動リカバリ(リセットログによるリカバリ)

- ブロック・メディア・リカバリでは、データ・ファイルをオンラインに保ったまま、ブロックの破損を修復

- ブロック・チェンジ・トラッキングを使用した高速増分バックアップ

- イントラファイルおよびインターファイルの並列処理による高速バックアップ操作とリストア操作

- 仮想プライベート・リカバリ・カタログによるセキュリティの強化

- 増分バックアップがイメージ・コピーにマージされ、最新の状態にリカバリ可能

- 必要なファイルのみ、バックアップおよびリストアを最適化

- 保存方針により、関連のバックアップを確実に保存

- 失敗した場合に、操作のバックアップおよびリストアを再開可能

- 制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップを行うことにより、データベース構造の変化や、メディア障害や災害の発生時に、バックアップ・メタデータの使用が可能

- 既存のバックアップから、またはDUPLICATEコマンドを使用して本番データベースから直接(この場合ステージング領域は不要)、新しいデータベースを簡単に再インスタンス化

関連項目:
『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』

3.5 Oracle Secure Backup

Oracle Secure Backupは、UNIX、Linux、WindowsおよびNetwork Attached Storage(NAS)の分散環境で実行される異種データ保護を提供する、集中型のテープ・バックアップ管理ソリューションです。ファイル・システムとOracle Databaseのデータを保護することにより、Oracle Secure BackupはIT環境に完全なテープ・バックアップ・ソリューションを提供します。

Oracle Secure BackupはRMANと密接に統合され、RMANのメディア管理レイヤーを提供します。Oracle Secure BackupとRMANは、最適化された統合ポイントを使用して、Oracle Databaseに最速で効率性が最も高いテープ・バックアップ機能を提供します。

バックアップ・ポリシーを使用して、分散サーバーをOracle Secure Backup中央管理サーバーからローカルおよびリモートのテープ・デバイスにバックアップできます。完全自動操作の場合はカレンダーに基づくスケジュールで、迅速な要件の場合はオンデマンドでバックアップされます。高度にスケーラブルなクライアント/サーバー・アーキテクチャにより、Oracle Secure Backupは安全なイントラドメイン通信と双方向サーバー認証のためにSecure Sockets Layer(SSL)を利用して、ローカルおよびリモートのデータ保護を提供します。

Oracle Secure Backupには次のような利点があります。

- 比較可能なメディア管理製品よりも25-40%高速なOracle Databaseのバックアップと、CPU使用率の最大10%の低下を達成する、最適化されたパフォーマンス

- 未使用ブロックとUNDOブロックの圧縮

- RMANとのテープ・バッファの共有

- ポリシーに基づく管理により、バックアップ管理者はバックアップ・ドメインの正確な制御が可能

- 動的ドライブ共有によるテープ・リソースの使用率の向上

- 異種ストレージ・エリア・ネットワーク(SAN)のサポートにより、NAS、UNIX、WindowsおよびLinuxでテープ・ドライブとメディアの共有が可能

- 完全および増分オフサイト・バックアップ・スケジューリングによる、ファイル、ディレクトリ、ファイル・システムまたはRAWパーティション・レベルでのファイル・システム・バックアップ

- Oracle Enterprise Managerとの統合による、直感的で使いやすいインタフェースの提供

- Oracle Secure Backupのホスト・ベースの暗号化またはハードウェア暗号化(テープ・ドライブ)のいずれかを利用する、ポリシー・ベースの暗号化鍵管理を使用したテープへのバックアップの暗号化

- SANおよびSCSI環境における新しいテープ・デバイスと従来の幅広テープ・デバイスのサポート

- Network Data Management Protocol(NDMP)のサポートによる、NASファイルの効率性の高いバックアップ

- スケーラブルで低コストのライセンス・モデルによる、ITコストの削減と運用面の考慮事項の軽減

- Exadata Database Machine環境で最大のバックアップおよびリストアのパフォーマンスのための、インフィニバンド・ネットワーク経由のReliable Datagram Socket over Remote Direct Memory Access (RDS/RDMA)の強化されたデータ・スループット

- OSBおよびOracleデータベース・バックグラウンド・プロセスが最適なパフォーマンスのために同じNUMA領域で通信することを保証する、不均一メモリー・アクセス(NUMA)マシンでのOracle対応のバックアップとリストア

関連項目:
『Oracle Secure Backup管理者ガイド』

3.6 Oracle Real Application ClustersおよびOracle Clusterware

Oracle Real Application Clusters(Oracle RAC)とOracle Clusterwareを使用すると、Oracle Databaseはクラスタ化された一連のサーバー全体にパッケージまたはカスタム・アプリケーションを実行できます。この機能により、高いレベルの可用性および最も柔軟的なスケーラビリティが得られます。クラスタ化されたサーバーに障害がある場合でも、Oracle Databaseは残りのサーバー上で稼働し続けます。より高い処理能力が必要なときは、データへのユーザーのアクセスを中断することなく、他のサーバーを追加できます。

Oracle RACを使用すると、インターコネクトでリンクされた複数のインスタンスによるOracleデータベースへのアクセスの共有が可能になります。Oracle RAC環境では、単一の共有データベースに同時にアクセスしている間、Oracle Databaseはクラスタ内の2つ以上のシステム上で稼働します。その結果、複数のハードウェア・システムにまたがる単一データベース・システムとなり、Oracle RACではクラスタ内での障害時に高可用性と冗長性を提供できます。Oracle RACは、読取り専用のデータ・ウェアハウス・システムから更新頻度の高いオンライン・トランザクション処理(OLTP)システムまで、あらゆるタイプのシステムに対応しています。

Oracle Clusterwareは、同じオペレーティング・システムを実行するサーバーにインストールされる場合、これらのサーバーが連係して単一サーバーとして機能できるようにして、ユーザー・アプリケーションとOracleデータベースの可用性を管理するソフトウェアです。また、ノードのメンバーシップ、グループ・サービス、グローバルなリソース管理、高可用性機能といったクラスタ管理に必要な機能もすべて提供します。

- 高可用性については、Oracleデータベース(単一インスタンスまたはOracle RACデータベース)とユーザー・アプリケーション(OracleおよびOracle以外)をOracle Clusterwareの管理と保護の下に置いて、プロセス障害時にはデータベースとアプリケーションが再起動し、ノード障害後には別のノードへのフェイルオーバーが行われるようにすることができます。

- クラスタ管理については、複数の独立したサーバーがまるで単一システムのイメージまたは単一の仮想サーバーであるかのように示されます。この単一の仮想サーバーは、すべての管理操作に対してクラスタ全体で維持されるため、管理者はインストール、構成、バックアップ、アップグレードおよび監視の機能を実行できます。その後、Oracle Clusterwareが、これらの管理機能の実行を、クラスタ内の該当するノードに自動的に分散します。

Oracle Clusterwareは、Oracle RACを使用するための要件です。Oracle RACが動作するほとんどのプラットフォームにおいて、必要なクラスタウェアはOracle Clusterwareのみです。Oracle Databaseでは引き続きサード・パーティのクラスタウェア製品を指定されたプラットフォームでサポートしますが、Oracle Clusterwareを使用すれば、次の主な利点があります。

- ベンダー独自開発のクラスタウェアが不要

- ローカルまたはリモートのOracle Automatic Storage Management(Oracle Flex ASM)によるディスク管理を提供するOracleから、Oracle DatabaseおよびOracle RACによるデータ管理まで、統合ソフトウェア・スタックを使用

- Oracle Flex Clusterと呼ばれる大規模クラスタに構成可能

さらに、OracleサービスなどのOracle Database機能では、Oracle Clusterwareの基本的なメカニズムを使用して、それらの機能を提供します。

Oracle Clusterwareには2つのクラスタウェア・コンポーネントが必要です。1つはノード・メンバーシップ情報を記録する投票ディスク、もう1つはクラスタ構成情報を記録するOracle Cluster Registry(OCR)です。投票ディスクとOCRは共有ストレージに存在する必要があります。Oracle Clusterwareでは、各ノードがプライベート・インターコネクト経由でプライベート・ネットワークに接続されている必要があります。

関連項目:
『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

3.6.1 Oracle Clusterware使用の利点

Oracle Clusterwareには次のような利点があります。

- コンピュータおよびインスタンス障害を許容し、迅速にリカバリします。

- Oracle ClusterwareとOracle Databaseの併用により、管理およびサポートを単純に行えます。少数のベンダーとすべてのOracleスタックを使用することで、サード・パーティ・クラスタウェアを使用した場合より優れた統合を得られます。

- システム変更およびハードウェア変更のローリング・アップグレードを実行します。たとえば、ローリング方式で、Oracle Clusterwareのアップグレード、パッチ・セットおよび個別パッチを適用できます。
Oracle Database 12cにアップグレードすると、Oracle ClusterwareおよびOracle ASMバイナリがOracle Grid Infrastructureという1つのバイナリとしてインストールされます。Oracle Clusterwareは、Oracle Clusterware 10gおよびOracle Clusterware 11gからローリング方式でアップグレードできますが、Oracle ASMはOracle Database 11gリリース1(11.1)からの場合のみローリング方式でアップグレードできます。

- エラーが発生したOracleプロセスを自動的に再開。

- 仮想IP(VIP)アドレスを自動的に管理。ノードに障害がある場合、そのノードのVIPアドレスは、VIPアドレスが接続を受け入れられる他のノードにフェイルオーバーされます。

- 障害が発生したノードのリソースを残りのノードで自動的に再開。

- Oracleプロセスを次のように制御します。

- Oracle RACデータベースの場合、すべてのOracleプロセスはデフォルトでOracle Clusterwareによって制御されます。

- 単一インスタンスのOracleデータベースの場合、Oracle Clusterwareで制御されるリソース・グループへのOracleプロセスを構成できます。

- OracleアプリケーションおよびOracle以外のアプリケーションの場合、Application Programming Interface(API)が提供され、Oracle Clusterwareによるその他のOracleプロセス(再開、または障害や特定のルールへの応答など)を制御できます。

- ノードのメンバーシップを管理し、2つ以上のインスタンスがデータベースを制御する際のスプリット・ブレイン・シンドロームを防止。

- アプリケーションの停止時間ゼロで、Oracle Clusterwareのローリング・リリース・アップグレードの実行が可能。

関連項目:
『Oracle Clusterware管理およびデプロイメント・ガイド』

3.6.2 Oracle Real Application ClustersおよびOracle Clusterware使用の利点

Oracle RACとOracle Clusterwareの併用には、3.6.1項に示したOracle Clusterwareのすべての利点に加え、次のような利点があります。

- すべてのOracleソフトウェア・スタックを使用することで、サード・パーティ・クラスタウェアを使用した場合より優れたOracle Databaseの統合およびサポートを提供します。

- Oracle Serviceの自動的再配置。さらに、高速アプリケーション通知(FAN)とクライアント構成を追加で実行する場合は、高速かつ自動のインテリジェントな接続とフェイルオーバーを実現するために、アプリケーションが素早く反応できるようなFANイベントの配信。

- 接続障害を高速に自動検出し、Oracle Universal Connection Pool(Oracle UCP)、高速接続フェイルオーバーおよびFANイベントを使用するJavaアプリケーションの終了済接続を削除します。

- Oracle UCPランタイム接続ロード・バランシングを使用して作業リクエストを均等に分散します。

- Oracle UCP、Oracle Call Interface(OCI)およびOracle Data Provider for .NET(ODP.NET)でランタイム接続ロード・バランシングを使用します。

- ロード・バランシング・アドバイザを使用して、使用可能なすべてのインスタンスに作業を分散します。

- 停止時間またはアプリケーションへの変更なしで、汎用ハードウェアを使用して処理能力を向上できる柔軟性を提供します。

- データベースおよびクラスタの機能を統合する包括的な管理性を提供します。

- データベース・インスタンス全体にわたるスケーラビリティを提供します。

- プールされていない接続の高速接続フェイルオーバーを実装します。

3.6.3 従来のコールド・クラスタ・ソリューションより優れているOracle RACの利点

- データベース・インスタンス全体にわたるスケーラビリティ

- 停止時間またはアプリケーションへの変更なしで、汎用ハードウェアを使用して処理能力を向上できる柔軟性

- コンピュータおよびインスタンスの障害の許容および障害からの迅速なリカバリが可能(秒単位)

- アプリケーションの停止を、コールド・クラスタ・ソリューションの場合の数分から数時間と比べて、ゼロまたは数秒にすることが可能

- 結合またはその他のテクノロジを使用せずに、冗長ネットワーク・インタフェースを使用したクラスタでの通信を最適化
Oracle Grid InfrastructureおよびOracle RACによる、ネットワーク・トラフィックを分散し、クラスタ内の最適な通信を保証する冗長インターコネクトの使用。この機能はOracle Database 11gリリース2(11.2.0.2)から使用可能になりました。それまでのリリースでは、結合またはトランキングのようなテクノロジを使用してインターコネクト用の冗長ネットワークを使用していました。

- システム変更およびハードウェア変更のローリング・アップグレード

- 個別パッチ、セキュリティ・パッチ、CPUおよびクラスタ・ソフトウェアのローリング・パッチ・アップグレード

- 高速、自動およびインテリジェントな接続とサービスの再配置ならびにフェイルオーバー

- データベースおよびクラスタの機能を統合する包括的な管理性(グリッド・プラグ・アンド・プレイ、およびポリシーに基づくクラスタ管理と容量管理を使用)

- ロード・バランシング・アドバイザおよびランタイム接続ロード・バランシングによる、適切なリソース全体での作業のリダイレクトおよび均等な分散

- データベース・ワークロードへのリソース割当てをポリシーベースでランタイム管理するためのOracle Quality of Service(QoS)管理(動的状況下でのビジネス・ニーズの順にサービス・レベルが満たされます)。これはデータベースが実行しているサーバー・プールにサービスを割り当てることにより行われます。プールからのリソースを使用して、必要な容量が使用可能になるようにします。

- Oracle Enterprise Managementによる、Oracle ASMおよびOracle ACFS、グリッド・プラグ・アンド・プレイ、クラスタ・リソース管理、Oracle ClusterwareとOracle RACのプロビジョニングとパッチ適用のサポート。

- Oracle RACに接続しているクライアントへの単一の名前としての、SCAN(単一クライアント・アクセス名)サポート。この名前は、クラスタのノードを追加または削除しても、クラスタの存続期間中は変更されません。

図3-2は、Oracle RAC使用のOracle Databaseアーキテクチャを示しています。この図は、パーティション化された3つのノードからなるデータベースの、Oracle RACを使用したOracle Databaseアーキテクチャを示しています。Oracle RACデータベースは、異なるノード上の3つのインスタンスに接続されています。各インスタンスは、サービス(人事、販売およびコール・センター)に関連付けられています。インスタンスはハートビートを確認することでお互いを監視します。Oracle Net Servicesは、図の最上部にあるアプリケーション/Webサーバー層へのクライアント・アクセスを提供します。

図3-2 Oracle RAC使用のOracle Databaseアーキテクチャ

注意:
Oracleバージョン11.2以降では、Oracle Clusterware (コールド・クラスタ・フェイルオーバー)を使用するよりも、より完全で、機能豊富なソリューションであるOracle RAC One NodeまたはOracle RACをお薦めします。

3.7 Oracle RAC One Node

Oracle Real Application Clusters One Node(Oracle RAC One Node)は、クラスタ内の1つのノードで実行されるOracle RACデータベースの単一インスタンスです。この機能により、最小限のオーバーヘッドで多数のデータベースを1つのクラスタに統合し、計画済および計画外の両方の停止から保護することができます。統合されたデータベースはフェイルオーバー保護、アプリケーションのオンライン・ローリング・パッチ適用、オペレーティング・システムおよびOracle Clusterwareのローリングアップグレードという、高可用性の利点を得ます。

Oracle RAC One Nodeでは、オンライン・データベース再配置と呼ばれるOracleテクノロジにより、単一インスタンス・データベースのコールド・フェイルオーバーよりも高い可用性が可能になります。このテクノロジは高可用性とロード・バランシングのためにデータベース・インスタンスと接続を別のクラスタ・ノードへとインテリジェントに移行します。オンライン・データベース再配置はServer Control Utility(SRVCTL)を使用して実行されます。

Oracle RAC One Nodeでは次のことが提供されます。

- 単一インスタンス・データベース・サービスが常に使用可能

- 高可用性のための組込みクラスタ・フェイルオーバー

- サーバーをまたがるインスタンスのライブ・マイグレーション

- 単一インスタンス・データベースに対するオンライン・ローリング・パッチ適用およびローリング・アップグレード

- 単一インスタンスから複数インスタンスOracle RACへのオンライン・アップグレード

- データベース・サーバーの優れた統合

- 拡張されたサーバーの仮想化

- 完全Oracle RACの開発およびテスト・プラットフォームのコストの低減

- Data Guardとともに構成されているOracle RACプライマリおよびスタンバイ・データベースの再配置。この機能はOracle Database 11gリリース2(11.2.0.2)から使用可能になりました。

また、Oracle RAC One Nodeはデータベース記憶域の統合を促進し、データベース環境を標準化し、必要な場合は、完全な複数インスタンスOracle RACデータベースに停止時間または中断なしに移行することができます。

3.8 Oracle Automatic Storage Management

Oracle ASMは、垂直方向に統合されたファイル・システムおよびボリューム・マネージャを直接Oracle Databaseカーネル内に構築し、次の機能を提供します。

- データベース・ストレージのプロビジョニングに必要な作業量を大幅に削減

- より高いレベルの可用性

- 特殊なストレージ製品のコスト、インストールおよびメンテナンスを排除

- データベース・アプリケーションの固有の機能

最適なパフォーマンスを実現するため、Oracle ASMは、ファイルをすべての使用可能なストレージ間で分散させます。また、データ損失から保護するために、Oracle ASMは、SAME(Stripe and Mirror Everything)の概念を拡大して、ディスク全体のレベルではなくデータベース・ファイル・レベルでのミラー化が可能となるように、SAMEにより柔軟性を持たせます。

さらに重要なことに、Oracle ASMは、ミラー化の設定、ディスクの追加および削除プロセスを簡素化します。数百または数千にもなりうる(大規模なデータ・ウェアハウスの場合)多数のファイルを管理するかわりに、データベース管理者は、Oracle ASMを使用してディスク・グループと呼ばれるさらに大きなオブジェクトを作成および管理します。ディスク・グループは、論理ユニットとして管理されるディスク・セットを識別します。ファイルの名前付け、および基礎となるデータベース・ファイルの配置を自動化することにより、データベース管理者の時間を節約でき、標準的なベスト・プラクティスの適用を保証できます。

Oracle ASMネイティブ・ミラー化メカニズム(2方向または3方向)がストレージ障害から保護します。Oracle ASMミラー化を使用して、障害グループを使用する場合により高いレベルのデータ保護を実現できます。障害グループとは、障害が許容される、共通のリソース(ディスク・コントローラまたはディスク・アレイ全体)を共有するディスク・セットのことです。Oracle ASMの障害グループを定義することで、データの冗長コピーが個別の障害グループにインテリジェントに配置されます。これにより、ストレージのサブシステム内のいずれかのコンポーネントで障害が発生した場合でも、このデータを使用でき、また、透過的に保護されるようになります。

Oracle ASMを使用すると、次のことが可能です。:

- ドライブおよびストレージ・アレイ間でのミラー化とストライプ化

- 障害が発生したドライブから残りのドライブへの自動再ミラー化

- データベースがオンラインのまま、ディスクの追加または削除時に格納されたデータの自動リバランスが可能

- Oracle Automatic Storage Managementクラスタ・ファイル・システム(Oracle ACFS)を使用したOracleデータベース・ファイルおよびデータベース以外のファイルのサポート

- データベース・ストレージ管理の操作の簡素化が可能

- Oracle Cluster Registry(OCR)および投票ディスクの管理

- インスタンスのローカル・ディスク上の優先読取り機能による、拡張クラスタのパフォーマンスの向上

- 大規模データベースのサポート

- Oracle ASMローリング・アップグレードのサポート

- ミラー・ディスクを使用したロジカル・データ破損の検出および修復のためのOracle ASMディスクのスクラブ・プロセスを使用した可用性と信頼性の向上

- チューニングおよびセキュリティのきめ細かな粒度のサポート

- ミラーのいずれかに適切なコピーが存在する場合、Oracle ASMの高速ミラー再同期およびブロック破損自動修復の機能を使用した、一時的なディスク障害発生後の高速修復を提供

- Oracle ACFSのネットワーク経由でのリモート・サイトへのレプリケーションを可能にすることにより、ファイル・システムの障害時リカバリ機能を提供

- Oracle Flex ASMを使用して、サービス中のクライアントに影響を与えることなく、Oracle ASMインスタンスのパッチを適用します。接続されている現在のOracle ASMインスタンスが計画メンテナンスでオフラインになっている間、データベース・インスタンスは、別の場所からOracle ASMメタデータにアクセスするように指定できます。

- Oracle ASMディスク再同期化およびリバランス操作の速度と状態の監視および管理

- Oracle ASM再同期化の指数制限を使用して再同期化の並列度を制御することにより、複数のディスクを同時にオンラインにし、パフォーマンスをより適切に管理します。セルまたはディスクの障害、および再同期を実行中のインスタンスのエラーの後の高速リカバリ。再同期化を最初から始めるかわりに中断または停止した時点から再開することができるディスク再同期チェックポイントを使用することでこれが可能です。

- Oracle Flex ASMを使用したデータベース・インスタンスの別のOracle ASMインスタンスへの自動的な接続計画外停止によりOracle ASMインスタンスに障害が発生した場合、ローカル・データベース・インスタンスは必要なメタデータおよびデータに引き続きアクセスできます。

関連項目:
ACFSの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

3.9 高速リカバリ領域

高速リカバリ領域は、Oracle Database内のすべてのリカバリ関連ファイルおよびアクティビティを対象とした一元的な格納場所です。この機能を有効にすると、すべてのRMANバックアップ、アーカイブREDOログ・ファイル、制御ファイルの自動バックアップ、フラッシュバック・ログおよびデータ・ファイルのコピーが自動的に特定のファイルシステムまたはOracle ASMディスク・グループに書き込まれ、このディスク領域はRMANとデータベース・サーバーによって管理されます。

高速リカバリ領域を使用するとテープへの書込みのボトルネックが解消されるため、ディスクへのバックアップ実行が高速化されます。さらに重要なことに、データベースのメディア・リカバリを行う必要がある場合は、データ・ファイルのバックアップがすぐに使用できます。必要なデータ・ファイルおよびアーカイブREDOログ・ファイルをリストアするためのテープおよび空きテープ・デバイスを見つける必要がないため、リストアおよびリカバリの時間が短縮されます。

高速リカバリ領域には、次の利点があります。

- 関連リカバリ・ファイルの格納場所の一元化

- リカバリ・ファイルに割り当てられたディスク領域を管理し、データベース管理タスクを簡素化

- 高速で信頼性の高いディスクベースのバックアップおよびリストア

関連項目:
『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』

3.10 破損の予防、検出および修復

データ・ブロック破損は、業務に多大の悪影響をおよぼし、修復が困難なことがあります(1.4項(「停止時間の原因」)を参照)。破損が発生すると、アプリケーションやデータベースに重大な停止時間が生じる原因になることがあります。悪くすると数時間、数日、場合によっては数週にわたり破損が気づかれず、検出後に、さらに長いアプリケーション停止時間を招くことがあります。あいにく、破損のソースおよび原因はメモリー、ハードウェア、ファームウェア、記憶域、オペレーティング・システム、ソフトウェアまたはユーザー・エラーのどこにでも存在する可能性があるので、データベース内のデータ破損を包括的に防止、検出および修復する手段は存在しません。さらに悪いことには、Oracleデータ・ブロックのセマンティクスやOracleのデータ・ブロックの変更方法を理解していないサード・パーティのソリューションでは、データ・ブロック破損の防止および検出ができません。サード・パーティのリモート・ミラーリング・テクノロジは、データ破損をデータベース・レプリカ(スタンバイ)に伝播する可能性があり、これは二重障害、データ損失および停止時間の長期化につながります。

Oracle MAAには、物理ブロック破損、論理ブロック破損、逸脱した書込みおよび書込みの欠落を含む、あらゆる形のデータ・ブロック破損を防止、検出および修復する包括的な計画があります。これらの追加の保護手段は、最も包括的なOracleデータ・ブロック破損の防止、検出および修復ソリューションを提供します。この計画の詳細は、My Oracle Supportのノート「Data Guard構成における破損の検出、防止および自動修復のベスト・プラクティス」に記載されています。

表3-1に、様々な手動操作チェック、およびランタイムやバックグラウンドの破損チェックに対するブロック破損チェックをまとめます。データベース管理者と作業チームは、RMANバックアップの実行、RMANのCHECK LOGICAL検証、または重要なオブジェクトに対するANALYZE VALIDATE STRUCTUREコマンドの実行など、手動チェックを組み込むことができます。手動チェックは、更新や問合せがあまり行われないデータを検証する際に、特に重要です。

ランタイム・チェックは、問合せや更新が頻繁に行われるデータの破損を、即座にまたはランタイムに検出する点で非常に優れています。ランタイム・チェックにより、破損が回避されたり、自動的に修正されたりするため、より強力にデータを保護し、アプリケーションの可用性をさらに高めることが可能です。Exadataに新しいバックグラウンド・チェックが導入され、アプリケーション・オーバーヘッドなしで、ディスクのスキャンと修正が自動的かつインテリジェントに行われ、物理的に破損したブロックは自動的に修正されます。

表3-1 ブロック破損チェックの概要

チェック

機能

物理ブロック破損

論理ブロック破損

手動チェック

Dbverify、Analyze

物理的ブロック・チェック

ブロック内およびオブジェクト間の論理的な一貫性チェック

手動チェック

RMAN

バックアップおよびリストア操作中の物理的ブロック・チェック

ブロック内論理チェック

手動チェック

ASMの修正

物理的ブロック・チェック

ブロック内の複数の論理チェック

ランタイム・チェック

Oracle Active Data Guard

1. 転送および適用中に、物理的ブロック・チェックをスタンバイにおいて継続的に実行

2. 強力なデータベース分離により、データベースの単一点障害を排除

3. ブロック破損の自動修復

4. データベースの自動フェイルオーバー

1. DB_LOST_WRITE_PROTECTが有効化されている場合、書込み欠落を検出(11.2以降)。11.2.0.4およびData Guard Brokerでは、プライマリ・データベースで書込み欠落が検出された場合に、プライマリを停止可能。

2. スタンバイでDB_BLOCK_CHECKINGが有効化されている場合、ブロック内の追加の論理チェックが可能

ランタイム・チェック

データベース

DB_BLOCK_CHECKSUMにより、インメモリー・データ・ブロックおよびREDOチェックサムを検証

DB_BLOCK_CHECKINGにより、インメモリーのブロック内チェックを検証

ランタイム・チェック

ASM

書込み中に、正常なASMエクステント・ブロックのペアが存在する場合、読取りおよび書込みの暗黙的なデータ破損検出と自動修復を実行

ランタイム・チェック

DIX + T10 DIF

オペレーティング・システムからHBAコントローラ、ディスク(ファームウェア)に至るまでのチェックサム検証。認定済のLinux、HBAおよびディスクに対する読取りと書込みを検証。

ランタイム・チェック

ハードウェアおよびストレージ

Oracle統合が行われていないため、限定的なチェック。チェックサムが最も一般的。

Oracle統合が行われていないため、限定的なチェック。チェックサムが最も一般的

ランタイム・チェック

Exadata

書込みに対する包括的なHARDチェック

書込みに対するHARDチェック

バックグラウンド・チェック

Exadata

ハード・ディスクの自動修正および修復。不良セクターの検出および修正。

関連項目:

- これらのビューと初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

- My Oracle SupportのNote 1302539.1 (http://support.oracle.com/)

3.11 データ・リカバリ・アドバイザ

データ・リカバリ・アドバイザは、永続的な(ディスク上の)データ障害を自動的に診断し、適切な修復オプションを示し、リクエストに応じて修復操作を実行します。

データ・リカバリ・アドバイザを使用して、プライマリ・データベース、ロジカル・スタンバイ・データベース、フィジカル・スタンバイ・データベースおよびスナップショット・スタンバイ・データベースをトラブルシューティングできます。

データ・リカバリ・アドバイザには、次の機能があります。

- 障害診断
通常、データベース障害の最初の兆候は、エラー・メッセージ、アラーム、トレース・ファイルおよびダンプ、ヘルス・チェックの失敗などです。これらの兆候を評価する作業はたいてい複雑で間違いやすく、時間がかかります。データ・リカバリ・アドバイザを使用すると、データ障害が自動的に診断され、これらの詳細が通知されます。

- 障害の影響の評価
障害の診断後、修復戦略について検討する前に、障害の範囲を把握し、アプリケーションに与える影響を評価する必要があります。データ・リカバリ・アドバイザを使用すると、障害の影響が自動的に評価され、わかりやすい形式でその結果が表示されます。

- 修復の生成
障害が正しく診断されたとしても、正しい修復方法の選択は容易ではなく、負担になります。さらに、判断を誤ると、停止時間の増加やデータ損失という点で大きな不利益を被ることになります。データ・リカバリ・アドバイザは、自動的に一連の障害に関する最善の修復方法を判断して提示します。

- 修復の実行可能性チェック
データ・リカバリ・アドバイザでは、修復オプションが示される前に、特定の環境や提案される修復処理を完了するために必要なメディア・コンポーネントの可用性に関して、ファイルをプライマリまたはスタンバイ・データベースから直接リストアして提案された修復を完了するなどの、これらの修復オプションが検証されます。

- 修復の自動化
提示された修復オプションを使用すると、この修復オプションが自動的に実行され、修復が成功したかどうかが検証されて、該当する障害が処置済となります。

- データの整合性およびデータベースのリカバリ可能性の検証
データ・リカバリ・アドバイザでは、選択すればいつでも、データ、バックアップおよびREDOストリームの整合性を検証できます。

- 破損の早期検出
状態モニターを使用して、データ・リカバリ・アドバイザによる診断チェックを定期的に実行するようスケジュール設定できます。これにより、トランザクションを実行しているデータベース・プロセスによって破損が検出されてエラーが通知される前に、データ障害を検出できます。早期の警告により、破損による損害を制限できます。

- データの検証および修復の統合
データ・リカバリ・アドバイザは、データの検証および修復用の単一のツールです。

注意:
データ・リカバリ・アドバイザでは、単一インスタンス・データベースのみがサポートされています。Oracle RACデータベースはサポートされていません。データ・リカバリ・アドバイザでサポートされているデータベース構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

関連項目:
『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』

3.12 Oracleセキュリティ機能

人的エラーに対する最大の保護とは、その発生を防ぐことです。人的エラーの最高の保護方法は、ユーザー・アクセスを、ビジネス機能の実行に必要なデータおよびサービスのみに限定することです。Oracle Databaseでは、データベース・ユーザーの認証によりアプリケーション・データへのアクセスを制御し、管理者が任務の遂行に必要な権限のみをユーザーに与えることができる多種多様なセキュリティ・ツールを提供しています。

さらに、Oracle Databaseのセキュリティ・モデルでは、Oracle Virtual Private Databaseを使用して行レベルにデータ・アクセスを制限し、アクセスする必要がないデータをデータベース・ユーザーから分離することが可能です。

Oracle Databaseには次のようなセキュリティ上の利点があります。

- ネットワーク、データベースおよびアプリケーションを使用したエンティティのアイデンティティを検証するための認証制御。データベース間のネットワーク・セッション(REDO転送セッションなど)も認証されます。

- データベース・ユーザー・アイデンティティおよびロールにリンクされているアクセスおよびアクションを制限するための認証制御。

- オブジェクトへのアクセスを制御し、エンティティの要求がオブジェクトに対するアクセスまたは変更のいずれであろうとオブジェクトを保護。

- 特定のデータベース・アクティビティに関するデータの監視および収集、不審なアクティビティの調査、ユーザー(またはその他)の不適切なアクティビティの防止、および認証あるいはアクセス制御の実装による問題の検出を行う監査制御。

- プロファイルを使用したセキュリティ・ポリシー管理。

- データベースおよびバックアップ内に存在する、またはデータベース間で転送されるデータの暗号化。

- SYSDBA権限が付与されないクラスのユーザーに、Data Guard構成の管理を委任することができます。

関連項目:

- 『Oracle Databaseセキュリティ・ガイド』

- 『Oracle Data Guard概要および管理』

3.13 Oracle Flashbackテクノロジ

Oracle Flashbackテクノロジは、Oracle Database機能のグループで、データベース、データベース・オブジェクト、トランザクションまたは行の過去の状態を表示し、データベース、データベース・オブジェクト、トランザクションまたは行を、ポイント・イン・タイム・メディア・リカバリを使用せずに前の状態に戻すことができます。

フラッシュバック機能を使用すると、次のことができます。

- 過去のある時点でのデータの様子を表示する問合せの実行

- データベースに対する変更の詳細履歴を示したメタデータを戻す問合せを実行します。

- 表または行を前の時点にリカバリします。

- トランザクション・データの変更を自動的に追跡およびアーカイブします。

- データベースがオンラインである間にトランザクションおよびその依存トランザクションをロールバックします。

- 表の削除取消

- リストア操作なしでのポイント・イン・タイムへのデータベースのリカバリ

フラッシュバック・データベース機能以外に、ほとんどのOracle Flashback機能では、自動UNDO管理(AUM)システムにより、トランザクションに関するメタデータおよび履歴データが取得されます。フラッシュバック機能はUNDOデータに依存します。UNDOデータは、個々のトランザクションの結果のレコードです。たとえば、ユーザーが給与を1000から1100に変更するUPDATE文を実行すると、Oracle DatabaseによってUNDOデータに値1000が格納されます。

UNDOデータは永続的であり、データベース停止時にも失われません。フラッシュバック機能を使用すると、UNDOデータを使用して過去のデータを問い合せたり、論理的な損害をリカバリしたりすることができます。UNDOデータは、フラッシュバック機能以外でも、Oracle Databaseによって次の処理に使用されます。

- アクティブなトランザクションのロールバック

- データベースまたはプロセス・リカバリを使用した終了済トランザクションのリカバリ

- SQL問合せに対する読取り一貫性の提供

Oracle Flashbackは、不注意または悪意でデータを変更し、不正なインストールおよびアップグレードの原因となり、アプリケーションでのロジカル・エラーを招く様々なヒューマン・エラーまたはオペレータによるエラーにより損なわれたデータに対処して巻き戻すことができます。これらの問題は次の各フェーズで対処され、フラッシュバック・トランザクション、フラッシュバック・ドロップ、表のフラッシュバック、データベースのフラッシュバックなどの機能を使用します。

フェーズ1: 通常はアプリケーションにより実行されるロジカル・エラーの検出

フェーズ2: フラッシュバック問合せ、フラッシュバック・バージョン問合せ、フラッシュバック・トランザクション問合せおよびDBMS_FLASHBACKパッケージなどの機能を使用した調査。

フェーズ3: エラー・リカバリ。

3.13.1 Oracle Flashback Query

Oracle Flashback Query (フラッシュバック問合せ)では、自動UNDO管理システムを利用してトランザクションのメタデータおよび履歴データを取得することで、過去に存在したデータを表示できます。UNDOデータは永続的で、データベースの異常や停止の際にも失われません。フラッシュバック問合せの独自の機能により、表の以前のバージョンの問合せが可能になり、誤った操作からリカバリするための強力なメカニズムも提供されます。

フラッシュバック問合せの用途は次のとおりです。

- 失われたデータをリカバリしたり、コミット済の不適切な変更を取り消す場合。たとえば、削除または更新された行を、コミット後でもただちに修復できます。

- 現行のデータと過去のある時点の対応するデータとを比較します。たとえば、前日のデータの変更を示す日次レポートを使用すると、表データの個々の行を比較したり、一連の行の共通部分または和集合を検索したりできます。

- 特定の日の勘定残高を確認するなど、ある時点におけるトランザクション・データの状態をチェックします。

- 特定のタイプの一時データを格納する必要をなくすことで、アプリケーションの設計を簡素化します。フラッシュバック問合せを使用すると、過去のデータをデータベースから直接取得できます。

- レポート生成ツールなどのパッケージ・アプリケーションを過去のデータに適用します。

- アプリケーションのセルフサービス・エラー修正を実現し、ユーザーが自分のエラーの取消しおよび修正を行えるようにします。

関連項目:
Oracle Database開発ガイド

3.13.2 Oracle Flashback Version Query

Oracle Flashback Version QueryはSQLの拡張機能で、特定の表から特定の期間に存在した行のバージョンを取得するために使用できます。Oracle Flashback Version Queryでは、指定期間に存在した行のバージョンごとに1行が返されます。どの表についても、COMMIT文が実行されるたびに行のバージョンが新たに作成されます。

Oracle Flashback Version Queryは、データベース管理者が問題の原因特定の分析を実行するために使用できる強力なツールです。さらに、アプリケーション開発者はOracle Flashback Version Queryを使用して、監査目的のカスタム・アプリケーションを作成できます。

関連項目:
Oracle Database開発ガイド

3.13.3 Oracle Flashback Transaction

Oracle Flashback Transactionは、トランザクションとその依存トランザクションをバックアウトします。DBMS_FLASHBACK.TRANSACTION_BACKOUT()プロシージャは、データベースがオンラインのまま、トランザクションとその依存トランザクションをロール・バックします。このリカバリ操作ではUNDOデータを使用して、影響を受けたデータを元の状態に戻す補正トランザクションを作成および実行します。DBA_FLASHBACK_TRANSACTION_STATEビューに問い合せることで、トランザクションが依存ルールを使用してバックアウトされたか、次のいずれかで強制的に取り消されたかを確認できます。

- 競合していない行のバックアウト

- UNDO SQLの適用

Oracle Flashback Transactionでは、特定のトランザクション、またはトランザクションのセットとその依存トランザクションを迅速にバックアウトすることにより、論理リカバリ時の可用性が向上します。データベースがオンラインのまま、1つのコマンドを使用してトランザクションをバックアウトします。

関連項目:

- Oracle Database開発ガイド

- 『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』

3.13.4 Oracle Flashback Transaction Query

Oracle Flashback Transaction Queryは、データベースに加えられたすべての変更をトランザクション・レベルで表示するためのメカニズムを提供します。Oracle Flashback Version Queryと併用した場合、人的エラーまたはアプリケーションのエラーからリカバリする高速で効率的な手段となります。Oracle Flashback Transaction Queryでは、行を変更したデータベース・ユーザーが返されるため、データベースの問題のオンライン診断を実行する能力が強化されます。また、トランザクションの分析および監査も実行されます。

関連項目:
Oracle Database開発ガイド

3.13.5 Oracle Flashback Table

Oracle Flashback Tableを使用すると、過去のある時点の状態に表をリカバリできます。人的エラーまたはアプリケーションのエラーによって変更された1つの表または一連の表をリカバリするための高速なオンライン・ソリューションを提供します。ほとんどの場合、Oracle Flashback Tableを使用することで、管理者がより複雑なポイント・イン・タイム・リカバリ操作を実行する必要性は軽減されます。元の表のデータは、Oracle Flashback Tableを使用すると表を元の状態に戻せるため失われません。

関連項目:
『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』

3.13.6 Oracle Flashback Drop

オブジェクトの誤った削除は、データベース・ユーザーにも、データベース管理者にも問題です。削除された表、索引、制約またはトリガーをリカバリする簡単な方法はありませんが、Oracle Flashback Dropでは、オブジェクトを削除する際の安全策が提供されます。表を削除すると、その表は自動的にごみ箱に入ります。ごみ箱は、すべての削除済オブジェクトが入っている仮想コンテナです。削除した表のデータは、引き続き問い合せることができます。

関連項目:
『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』

3.13.7 リストア・ポイント

Oracle Flashbackのリカバリ操作がデータベースで実行されるとき、DBAは、適切な時間内に(システム変更番号(SCN)またはタイムスタンプで識別)、後でフラッシュバック可能なポイントを決定する必要があります。Oracle Flashbackのリストア・ポイントとは、フラッシュバック・データベース、フラッシュバック表およびOracle Recovery Manager(RMAN)操作で使用されるSCNまたはトランザクション時間に置き換えるためにユーザーが定義できるラベルです。さらに、データベースは、前回のデータベースのリカバリを通じてフラッシュバックでき、保証されたリストア・ポイントを使用して、OPEN RESETLOGSコマンドと同様に開くことができます。保証されたリストア・ポイントを使用して、データベースの巻戻しに必要なUNDOが保存されるようにすることで、データベースのバッチ・ジョブ、アップグレードまたはパッチなどの主なデータベース変更を素早く元に戻すことができます。

リストア・ポイント機能を使用すると、次の利点があります。

- 一貫性のある状態、つまり失敗した計画操作(バッチ・ジョブ、Oracleソフトウェア・アップグレードまたはアプリケーション・アップグレードの失敗など)より前の適切なポイントに素早くリストアすることが可能

- スナップショット・スタンバイ・データベースをプライマリ・データベースと再同期させる機能

- テスト・データベースまたはクローン化されたデータベースを元の状態に戻す迅速なメカニズム

関連項目:
『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』

3.13.8 Oracle Flashback Database

Oracle Flashback Databaseは高速巻戻しボタンのようなもので、データベースを過去の時点にすばやく巻き戻します。バックアップやアーカイブ・ログを使用したリストアやロール・フォワードに時間をかける必要がありません。データベースのサイズが大きくなるほど、Oracle Flashback Databaseを使用する高速なポイント・イン・タイム・リカバリの利点も大きくなります。

Oracle Flashback Databaseを有効にすると、次の利点があります。

- ポイント・イン・タイム・リカバリで論理破損(管理エラーを原因とする破損など)を高速に修復。

- Oracleリストア・ポイントと組み合わせた反復テストに便利。リストア・ポイントの設定、データベースの変更の実装、影響を評価するためのワークロードのテスト実行が可能。Oracle Flashback Databaseを使用して、変更を破棄して元の起点に戻り、別の変更を行ってから、同じワークロードでもう一度テスト実行することで、正当な基盤に基づいて異なる構成変更の影響を比較することができます。

- Data GuardはOracle Flashback Databaseを使用して、障害の発生したプライマリ・データベースを、(フェイルオーバー後に)新しいスタンバイとしてすばやく再インスタンス化します(障害の発生したプライマリをバックアップからリストアする必要はありません)。

- マルチテナント環境では、コンテナ・データベース・レベルでフラッシュバック・データベースが実行されます。すべてのPDBが一緒にフラッシュバックされます。

関連項目:

- 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』

- 『Oracle Database SQL言語リファレンス』

3.13.9 フラッシュバック・ログまたはフィジカル・スタンバイ・データベースを使用したブロック・メディア・リカバリ

自動的な破損ブロック修復の試行後、ブロック・メディア・リカバリ機能で、フラッシュバック・ログからデータ・ブロックの最新コピーを必要に応じて取得して、リカバリ時間を短縮できます。自動ブロック修復を使用すると、検出されたプライマリ・データベースの破損ブロックをフィジカル・スタンバイ・データベースの良好なブロックを使用してただちに自動修復できます。

その上、インスタンスのリカバリで発生した破損ブロックによってインスタンスのリカバリが失敗することはありません。このようなブロックは破損として自動的にマークされ、V$DATABASE_BLOCK_CORRUPTION表のRMANの破損リストに追加されます。その後、RMANのRECOVER BLOCKコマンドを発行して関連ブロックを修正できます。また、フィジカル・スタンバイ・データベースが使用可能な場合には、RMAN RECOVER BLOCKコマンドはフィジカル・スタンバイ・データベースからブロックをリストアします。

関連項目:

- ブロック・メディア修復の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- RMAN RECOVER BLOCKコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

3.13.10 フラッシュバック・データ・アーカイブ

フラッシュバック・データ・アーカイブは表領域に格納され、レコードの存続期間中に表のすべてのレコードに対して行われたトランザクションの変更が含まれます。アーカイブされたデータは、UNDO表領域で提供される保存期間よりも長く保存でき、分析および修復のために非常に古いデータを取得するために使用されます。

関連項目:
Oracle Database開発ガイド

3.14 Oracle Data Pumpとデータ転送

Oracle Data Pumpテクノロジを使用すると、データおよびメタデータをデータベース間で非常に高速に移動できます。Data Pumpは、次の計画メンテナンス・アクティビティを実行するために使用されます。

- 異なるプラットフォームへのデータベース移行

- プラガブル・データベースへのデータベース移行

- データベース・アップグレード

この計画メンテナンス用テクノロジの使用法の詳細は、5.4項「システムおよびソフトウェア・メンテナンス用Oracle高可用性ソリューション」を参照してください。

前述の計画メンテナンス・アクティビティを可能にするData Pump機能は次のとおりです。

- データベース全体を異なるデータベース・インスタンスに移動するフル・トランスポータブル・エクスポート/インポート

- データベース間で一連の表領域を移動するトランスポータブル表領域

3.15 データベース以外のファイルに対するOracleレプリケーション・テクノロジ

表3-2は、データベース以外のファイルに対するOracleレプリケーション・テクノロジの説明です。

表3-2 データベース以外のファイルに対するOracleレプリケーション・テクノロジ

テクノロジ

推奨される使用方法

コメント

Oracle Database File System,

Exadata Database Machineシステムまたはデータベースおよびデータベース以外のシステム間で完全な同期が必要な場合に推奨

- データベースの変更とファイル・システムの変更間で完全に一貫性を保持するためにデータベースとの統合が可能

- データベースに保存され、Oracle Active Data Guardと使用して障害時リカバリと読取り専用アクセスの両方を提供できるすべてのデータ

- Oracleデータベースのすべての機能を利用可能

Oracle ASMクラスタ・ファイル・システム

Oracle ASM、Oracle ClusterwareおよびOracle Enterprise Managerテクノロジと統合された単一ノードおよびクラスタ全体のファイルシステム・ソリューションの提供を推奨

- Oracle ACFSでは、Oracle ASMインスタンスおよびディスク・グループのステータス更新やディスク・グループのリバランスなどのOracle ASMの状態遷移に関与するために、Oracle ASMインスタンスとの通信を確立し、維持します。

- 実行可能ファイル、データベース・トレース・ファイル、データベース・アラート・ログ、アプリケーション・レポート、BFILE、構成ファイルなど、様々なデータベース・ファイルおよびアプリケーション・ファイルがサポートされます。他にも、ビデオ、オーディオ、テキスト、イメージ、設計図、その他の汎用アプリケーションのファイル・データがサポートされます。

- ポイント・イン・タイム・リカバリの発生時にデータベースの変更とファイル・システムの変更間で時間整合性をほぼ提供可能

- NFSやCIFSなどの標準NASファイル・アクセス・プロトコルを使用してリモート・クライアントからアクセスおよびエクスポートできます。

Oracle Solaris ZFS Storage Applianceレプリケーション

データベース以外のファイルに対する障害時リカバリ保護、特にOracle Fusion Middlewareのデータベース外に保存されたクリティカル・ファイルに推奨します。

- Oracle Fusion Middlewareバイナリ構成を含む、データベース以外のすべてのオブジェクトのレプリケート

- ポイント・イン・タイム・リカバリの発生時にデータベースの変更とファイル・システムの変更間で時間整合性をほぼ提供可能

3.15.1 Oracle Database ファイル・システム

Oracle Database File System(DBFS)は、ファイルを格納するデータベースの利点と、リレーショナル・データを効率的に管理するデータベースの強度を活用して、データベースに格納されたファイルに対する標準のファイルシステム・インタフェースを実装します。このインタフェースを使用すると、BLOBおよびCLOBプログラム・インタフェースを使用するために特別に記述されたプログラムに制限されずに、データベースにファイルを格納できるようになります。これで、ファイルに作用する任意のオペレーティング・システム(OS)プログラムを使用して、データベース内のファイルに透過的にアクセスできるようになります。たとえば、ETL(抽出、変換およびロード)ツールは、ステージング・ファイルを透過的にデータベースに格納します。

Oracle DBFSには次のような利点があります。

- フルスタックの統合リカバリおよびフェイルオーバー: ファイル・システムをデータベース構造に格納することにより、データベース・オブジェクトとファイル・システム・データの両方のポイント・イン・タイム・リカバリの容易な実行が可能です。

- 障害時リカバリ・システムの投資利益率(ROI): DBFSに含まれるファイルへのすべての変更も、OracleデータベースのREDOログ・ストリーム経由で記録され、Data Guardフィジカル・スタンバイ・データベースに渡すことができます。Oracle Active Data Guardテクノロジを使用して、DBFSファイル・システムは、ソースとしてフィジカル・スタンバイ・データベースを使用して読取り専用でマウントできます。プライマリでの変更はスタンバイ・データベースに伝播され、スタンバイに適用されると表示できます。

- ファイル・システム・バックアップ: DBFSはデータベースにデータベース・オブジェクトとして格納されるので、標準RMANバックアップおよびリカバリ機能をファイル・システム・データに適用できます。データベースまたはデータベース内オブジェクト上で実行できるバックアップ、リストアまたはリカバリ操作は、DBFSファイルシステムに対して実行することもできます。

3.15.2 Oracle ASMクラスタ・ファイル・システム

Oracle ASMクラスタ・ファイル・システム(ACFS)は、マルチプラットフォームのスケーラブル・ファイルシステムであり、Oracle Automatic Storage Management(Oracle ASM)機能を拡張して、Oracle Databaseの外部で保持されているカスタマ・ファイルをサポートするストレージ管理テクノロジです。Oracle ACFSでは、実行可能ファイル、データベース・トレース・ファイル、データベース・アラート・ログ、アプリケーション・レポート、BFILE、構成ファイルなど、様々なデータベース・ファイルおよびアプリケーション・ファイルがサポートされます。他にも、ビデオ、オーディオ、テキスト、イメージ、設計図、その他の汎用アプリケーションのファイル・データがサポートされます。

Oracle ACFSでは次のOracle ASM機能を利用できます。

- Oracle ACFSの動的なファイル・システムのサイズ変更

- Oracle ASMディスク・グループ・ストレージへの直接アクセスによるフォーマンスの最大化

- I/Oの並列性向上によるOracle ASMディスク・グループ・ストレージ全体でのOracle ACFSの分散の平均化

- Oracle ASMミラー化保護メカニズムによるデータの信頼性の確保

Oracle ACFSの追加機能はOracle ACFSレプリケーションで、データベースに対するData Guardと同様、これによりネットワーク経由でのOracle ACFSファイルシステムのリモート・サイトへのレプリケーションが可能になり、ファイルシステムに対する障害時リカバリ機能が提供されます。Oracle ACFSレプリケーションはプライマリ・ファイルシステムのディスクに書き込まれた変更を取得し、その変更をレプリケーション・ログと呼ばれるファイルに記録します。このログは、関連するスタンバイ・ファイルシステムをホストするサイトに転送され、そこでバックグラウンド・プロセスがログを読み取り、ログに記録された変更をスタンバイ・ファイルシステムへ適用します。レプリケーション・ログに記録された変更がスタンバイ・ファイルシステムに正常に適用された後、レプリケーション・ログはプライマリおよびスタンバイ・ファイルシステムをホストしているサイトから削除されます。

3.15.3 Oracle Solaris ZFS Storage Applianceレプリケーション

Oracle Solaris ZFS Storage Applianceシリーズは、プロジェクトのスナップショット・ベースのレプリケーションをサポートし、次のユースケースに対し、スケジュールされてまたは連続で、ソース・アプライアンスから任意の数のターゲット・アプライアンスへ手動で分配します。

- 障害回復: レプリケーションを使用して障害時リカバリのためにアプライアンスをミラーリングできます。プライマリ・アプライアンス(またはデータ・センター全体)のサービスに影響を与える障害イベント時に、管理者は障害時リカバリ・サイトでサービスをアクティブ化し、最新のレプリケートされたデータを使用して引き継ぎます。プライマリ・サイトがリストアされると、障害時リカバリ・サイトがサービス中に変更されたデータは、プライマリ・サイトに移行して戻され、通常のサービスがリストアされます。このようなシナリオは、障害が発生する前に完全にテストすることができます。

- データ破損: レプリケーションを使用して、ターゲット・アプライアンスのクライアントが通常はソース・アプライアンスに直接到達できない、またはそのような設定では待機時間が非常に長くなるような状況で、データ(仮想マシン・イメージまたはメディア)を世界中のリモート・システムに分散できます。1つの例ではこのローカル・キャッシングのスキーマを使用して、読取り専用データ(ドキュメントなど)の待機時間を改善します。

- ディスク・ツー・ディスク・バックアップ: レプリケーションをテープ・アックアップが実行可能でない環境に対するバックアップ・ソリューションとして使用できます。たとえば、使用可能なバンド幅が不足しているため、またはリカバリの待機時間が長すぎるために、テープ・バックアップが実行可能でない場合があります。

- データ移行: レプリケーションを使用して、ハードウェアのアップグレード時または記憶域のリバランス時に、Oracle Solaris ZFS Storageアプライアンス間でデータおよび構成を移行できます。シャドウ移行はこの目的でも使用できます。

Oracle Solaris ZFS Storage Applianceのアーキテクチャによっても、これはOracle Fusion Middlewareの障害時リカバリに対しData Guardを補完するための理想的なプラットフォームになります。Oracle Fusion Middlewareにはデータベース外に保管された多数の重要なファイルがあります。これらのバイナリ、構成データ、メタデータ、ログなども、Oracle Fusion Middlewareの可用性を確保するためにデータ保護が必要です。これらに対し、ZFS Storage Applianceの組込みレプリケーション機能を使用してこのデータをリモートの障害時リカバリ・サイトに移動します。

Oracle Solaris ZFS Storage ApplianceをOracle Fusion Middlewareと使用する場合の利点には次のものがあります。

- Oracle Fusion Middlewareのリモート・レプリケーションの活用

- DRサイトのROIを向上させるデータベースのクローンおよびスナップショットを迅速に作成する機能

3.16 クライアントとアプリケーションのフェイルオーバー

高可用性アーキテクチャでは、アプリケーション層が生き残っているインスタンスまたはデータベースに透過的にフェイルオーバーして必要なサービスを通知することが必要です。これにより、ノード障害、インスタンス障害、データ破損またはデータベース障害時に、アプリケーションが通常どおり使用可能であることが保証されるか、または影響を最小限に抑えることができます。透過的なクライアント・フェイルオーバーにより、アプリケーションは別の使用可能なOracle RACインスタンスまたは別のデータベースにフェイルオーバーできます(Data Guardロール・トランジションまたはOracle GoldenGateの場合など)。

クライアント・フェイルオーバーには、障害の通知、接続のクリーンアップ、自動再接続、および別のOracle RACインスタンスまたはデータベースに存在するデータベース・サービスの再試行が含まれ、問合せの再試行も含まれる可能性があります。

高いレベルで、次のコンポーネントを使用してシームレスなクライアント・フェイルオーバーを提供します。

- サービス
企業のグリッド構想を可能にするために、Oracle Databaseでは、サービスと呼ばれる強力な自動ワークロード管理機能が導入されています。サービスは、Oracleデータベースで定義できるエンティティで、これを使用してデータベース・ワークロードをグループ化し、サービスの提供を割り当てられている最適なインスタンスに作業をルーティングし、計画済および計画外のアクションの高可用性を実現できます。

- 高可用性フレームワーク
Oracle Databaseがコンポーネントを実行状態に維持できるOracle RACコンポーネント。

- 高速アプリケーション通知(FAN)
FANは、UPまたはDOWNイベントなどのサービス・ステータスの変更を含む、構成レベルおよびサービス・レベルの情報を他のプロセスに通知するためにOracle RACが使用する高可用性通知メカニズムです。また、FANには、ロード・アドバイザ通知もあります。Oracleクライアント・ドライバおよびOracle接続プールは、FANイベントに応答し、ただちに処理します。FANのUPイベントおよびDOWNイベントは、インスタンス、サービスおよびノードに適用できます。

- トランザクション・ガード
トランザクション・ガードは、計画外停止および重複送信の場合に、トランザクションの実行を1回以下にするためのプロトコルおよびAPIを提供するツールです。

- アプリケーション・コンティニュイティ
アプリケーション・コンティニュイティは、リカバリ可能なエラーが発生した場合に、多くのシステム、通信、記憶域の停止およびハードウェア障害をマスクして、処理中の要求をリプレイする汎用インフラストラクチャを提供します。既存のリカバリ・テクノロジとは異なり、この機能では、アプリケーション下でトランザクションおよび非トランザクション・セッション状態をリカバリしようとするため、停止はアプリケーションにとって実行の遅延のように見えます。

- 接続ロード・バランシング
コネクション・ロード・バランシングは、要求されたデータベース・サービスを提供するすべてのインスタンスで、受信する接続を均等に分散するOracle Net Servicesの機能です。

ランタイム接続ロード・バランシングを使用すると、アプリケーションは、ロード・バランシング・アドバイザ・イベントを使用して、ユーザーにより適切なサービスを提供できます。Oracle JDBC、Oracle Universal Connection Pool for Java、OCIセッション・プール、ODP.NETおよびOracle WebLogic Server Active GridLink for Oracle RACクライアントは、ロード・バランシング・アドバイザリ・イベントを利用するために自動的に統合されます。ロード・バランシング・アドバイザは、サービスに対してインスタンスで提供されている現在のサービス・レベルをクライアントに通知します

- 高速接続フェイルオーバー
高速接続フェイルオーバーは、FANイベントをサブスクライブすることによって、高速な接続のフェイルオーバーを提供する、Oracleクライアントの機能です。

- 透過的アプリケーション・フェイルオーバー(TAF)
透過アプリケーション・フェイルオーバーは、高可用性環境を対象としたランタイム・フェイルオーバーであり、アプリケーションからサービスへの接続のフェイルオーバーおよび再確立を意味します。TAFにより、クライアント・アプリケーションは接続障害の発生時にデータベースに自動的に再接続でき、実行中だったSELECT文を再開することも可能です。この再接続は、Oracle Call Interface(OCI)ライブラリ内から自動的に実行されます。

- 単一クライアント・アクセス名(SCAN)
SCANはOracle RACに接続しているクライアントに単一の名前を提供し、この名前は、クラスタのノードを追加または削除しても、クラスタの存続期間中は変更されません。SCANに接続しているクライアントでは、Thin JDBC URLやEZConnectなどの単一の接続文字列を使用でき、ロード・バランシングおよびクライアントの接続フェイルオーバーが実現されます。

- グローバル・データ・サービス
グローバル・データ・サービス(GDS)は新しいOracle Databaseの機能で、サービスの概念を、単一インスタンス、Oracle RAC、Oracle Active Data GuardおよびOracle GoldenGateの組合せを含む、グローバルにレプリケートされた構成に拡張します。これにより、サービスはこのグローバルにレプリケートされた構成内のどこにでもデプロイでき、ロード・バランシング、高可用性、データベース・アフィニティなどをサポートします。

- 接続時フェイルオーバー
Oracle Netでは、それぞれ独自の特性を備えた複数のアドレス・リストを持つ接続記述子もサポートされます。接続時フェイルオーバーを使用すると、あるアドレスへの接続失敗時に、新しい接続試行を別のアドレスにフェイルオーバーすることができます。

関連項目:

- データベースのトランザクション処理の方法の詳細は、『Oracle Database概要』を参照してください。

- 動的データベース・サービスの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- 動的データベース・サービスの詳細は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。

- 『Oracle Database Global Data Services概要および管理ガイド』

3.16.1 接続のクライアント・フェイルオーバー処理

高レベルで、MAA環境での自動クライアント・フェイルオーバーには、データベース・サービスの使用可能リソースへの再配置、障害が発生したことのクライアントへの通知、TCPタイムアウトからそれらの潜在的なブレーク、データベース・サービスがアクティブな使用可能リソースへのアプリケーション接続のリダイレクトが含まれます。特定のクライアントまたはアプリケーションの構成およびベスト・プラクティスについては、My Oracle Supportのノート1617163.1「クライアントおよびアプリケーションのフェイルオーバー検証マトリックス」を参照してください。

アプリケーション接続のフェイルオーバーの処理に使用される、この章の導入部で説明したコンポーネントは、MAA環境の構成により異なります。

表3-3 接続のクライアント・フェイルオーバー処理

MAA構成

サービスの再配置

アプリケーション通知

セッションのフェイルオーバーおよびリカバリ脚注1

Data Guard使用の単一インスタンス

- DB_ROLE_CHANGEシステム・イベントで記述されたトリガーを使用したData Guardフェイルオーバー後のサービスの開始

- グローバル・データ・サービスの使用

アプリケーション・レイヤーを実行しているホストでのオペレーティング・システムの効率的なTCPタイムアウトの構成

OCIクライアントに対する透過的Oracleフェイルオーバー(TAF)の構成。TAFを使用しない場合、OCI、JDBC ThinまたはODP用にアプリケーションにトランザクション・ガードを含めることができます。

Oracle RAC DatabaseまたはOracle RAC One Node

- Oracle Clusterwareにより管理されたサービスの使用

高速アプリケーション通知の構成

OCIクライアントに対する透過的Oracleフェイルオーバー(TAF)の構成。Thin JDBCクライアントのためのアプリケーション・コンティニュイティの構成。

これらを使用しない場合、OCI、JDBC ThinまたはODP用にアプリケーションにトランザクション・ガードを含めることができます。(TAFおよびACにはトランザクション・ガードが含まれます)

Data Guard使用のOracle RAC Database

- 各クラスタ内のサービス・フェイルオーバーのためのOracle Clusterwareにより管理されたサービスの使用

- サイト間のサービス・フェイルオーバーのためのOracle Clusterwareにより管理されたロール・ベースのサービスの使用

高速アプリケーション通知の構成

OCIクライアントに対する透過的Oracleフェイルオーバー(TAF)の構成。JDBCシン・クライアントのためのアプリケーション・コンティニュイティの構成。

これらを使用しない場合、OCI、JDBC ThinまたはODP用にアプリケーションにトランザクション・ガードを含めることができます。(TAFおよびACにはトランザクション・ガードが含まれます)

レプリケート・データベース

- グローバル・データ・サービスの使用

アプリケーション・レイヤーを実行しているホストでのオペレーティング・システムの効率的なTCPタイムアウトの構成

BASICのみを使用したOCIクライアントに対する透過的Oracleフェイルオーバー(TAF)の構成。

脚注1 クライアントがJDBC、UCPまたはAGLである場合、アプリケーション・コンティニュイティは、レプリケートされたデータベースを除いて、これらすべての構成のオプションでもあります。

次の項では、サービスの再配置とアプリケーション通知の詳細を説明します。

関連項目:

- 特定のクライアントまたはアプリケーションの構成およびベスト・プラクティスについては、My Oracle Supportのノート1617163.1 (http://support.oracle.com/)を参照してください

3.16.1.1 サービス

サービス名とは、クライアント接続に使用するサービスの論理表現です。クライアントは、リスナーに接続するときにサービスへの接続をリクエストします。データベース・インスタンスは、起動時にインスタンス自体をリスナーに登録し、1つ以上のサービスとして名前で指定できるようになります。リスナーとして知られているように、単一サービスはOracle RACまたはData Guard環境の1つまたは複数のデータベース・インスタンスを識別できます。各データベース・インスタンスは、1つ以上のサービスをリスナーに登録できます。

3.16.1.1.1 単一インスタンス・データベースおよびData Guard環境でのサービスの使用

アプリケーションはプライマリ特有のサービス名、つまり、プライマリ・データベースでのみアクティブなユーザー作成サービスを使用してデータベースに接続する必要があります。Data Guardのフェイルオーバーのイベントで、このサービスは現在プライマリ・ロールを保持しているいずれかのデータベースに移行されます。これはON_STARTUPシステム・イベントに基づき実行されるトリガーを作成することによりインストールされたOracle Clusterwareのない単一インスタンス環境で実行できます。このトリガーはV$DATABASEビューのDATABASE_ROLE値をチェックし、値がPRIMARYの場合、ユーザー作成サービスを開始します。

3.16.1.1.2 Oracle RAC Database環境でのサービスの使用

サービスを定義すると、リソース・プロファイルは自動的に作成されます。リソース・ファイルには、Oracle Clusterwareによるサービスの管理方法と、PREFERREDインスタンスが停止した場合にサービスがフェイルオーバーされるインスタンスが定義されています。また、リソース・プロファイルでは、インスタンスおよびデータベースに対するサービスの依存性も定義します。この依存性の情報によって、データベースが停止した場合に、インスタンスおよびサービスが自動的に正しい順序で停止されます。

管理者管理データベースに対してサービスを定義する場合は、SRVCTLに-preferredパラメータを使用して、そのサービスを通常サポートするインスタンスを定義します。このようなインスタンスを、優先インスタンスといいます。サービスの優先インスタンスが失敗した場合に備えて、-availableパラメータを指定してSRVCTLを使用し、サービスをサポートするその他のインスタンスを定義することもできます。このようなインスタンスを、使用可能インスタンスといいます。

優先インスタンスを指定する場合は、サービスが通常実行されるインスタンスの数を指定します。これは、サービスの最大カーディナリティです。Oracle Clusterwareは、サービスを構成したインスタンス数でサービスが実行されることを確認しようとします。その後は、インスタンス障害またはサービスの計画的な再配置のために、使用可能インスタンスでサービスが実行される場合があります。

インスタンスが失敗した場合、リストに複数のインスタンスがあると、Oracle Clusterwareによってサービスがどの使用可能インスタンスに再配置されるかは制御できません。ただし、計画済操作時は、サービスを現在提供していない、優先リストまたは使用可能リスト内のインスタンスにサービスを手動で転送できます。

3.16.1.1.3 Oracle RAC DatabaseおよびData Guard環境でのサービスの使用

ご使用のOracle RAC環境でData Guardを構成してある場合は、SRVCTLに-lパラメータを使用して、各サービスにロールを定義できます。サービスにロールを指定すると、Oracle Clusterwareは、データベース・ロールがそのサービスに指定したロールに一致した場合にのみ自動的にサービスを起動します。有効なロールは、PRIMARY、PHYSICAL_STANDBY、LOGICAL_STANDBYおよびSNAPSHOT_STANDBYで、1つのサービスに複数のロールを指定できます。

クラスタ内の複数のデータベースが同じサービス名を提供すると、Oracle RACは、該当するすべてのデータベースにわたってそのサービスへの接続を均等に分散します。これはData Guardのスタンバイ・データベースおよびアクティブ・データベースに役に立ちますが、サービスへのクライアント接続を特定のデータベースに割り当てる必要がある場合、サービス名はクラスタ内で一意である(他のデータベースによって提供されない)必要があります。

関連項目:
データベース・ロールの詳細は、『Oracle Data Guard概要および管理』を参照してください。

3.16.1.1.4 レプリケートされた環境またはOracle Active Data Guard環境でのサービスの使用

グローバル・データ・サービス・フレームワークはグローバル・サービス向けのソフトウェア・インフラストラクチャです。このフレームワークはデータベース・クラウドの構成、メンテナンスおよび監視を自動化および集中化し、グローバル・サービスのロード・バランシングおよびフェイルオーバーを可能にします。このフレームワークでは、これらの仮想化リソースを最小限の管理オーバーヘッドで管理し、追加のクライアント要求を処理するために迅速にクラウドを有効化します。

Global Data Servicesフレームワークは、次の既存のOracle Databaseのテクノロジを中心に構築されます。

- Oracle Active Data Guard
読取り専用データベースの高パフォーマンス・ファームを可能にします。

- Data Guard Broker
プライマリ・データベースと最大30のスタンバイ・データベースを含むData Guard構成の作成、管理および監視を可能にします。

- Oracle GoldenGate
複数のデータベース間のレプリケーション更新を可能にします。

3.16.1.2 高速アプリケーション通知

FANを使用して、Oracle RAC、Data Guardおよびグローバル・データ・サービスに構築された連続した動的データベース・サービスは、アプリケーションおよび中間層サーバーに拡張されています。データベース・サービスの状態が変わると(起動、停止または再起動なしなど)、新しいステータスがFANイベントを介して、関係のあるサブスクライバにポストされます。Oracleドライバおよびアプリケーションは、これらのイベントを使用して、障害を非常にすばやく検出し、障害後の接続プールを均等に分散し、障害の発生したコンポーネントが修復されると接続プールを再度分散します。たとえば、インスタンスのサービスが起動されると、そのリソースに作業をルーティングするためにFANイベントが即時に使用されます。インスタンスまたはモードのサービスが失敗すると、リカバリするアプリケーションを中断するために、FANイベントが即時に使用されます。

データベース接続で高可用性の問題を解決するには、サービスの状態が変わるとすぐに、Oracle ClusterwareおよびData Guard BrokerでFANイベントをポストし、さらにサーバー側のコールアウトを実行します。イベント・ペイロードにはOracle RACでのサービスのステータスを説明する関連情報が含まれます。FANイベントを受信すると同時に、アプリケーションでは、障害が発生したインスタンスまたはノードと通信中のセッションを終了し、操作の再開を待つセッションに通知し、補助のリソースが使用可能になると、着信する作業を再編成できます。処理すべきセッションを識別するために、Oracle Databaseを使用するどのセッションにも、一意の接続署名があります。接続署名は、FANペイロードと一致します。

計画停止の場合、構成されたFANで接続プールを使用します。OCI、UCP、ICC、WebLogic Server Active Grid LinkまたはODP.Netです。FAN計画イベントの場合、リクエスト境界で作業を排出します。すぐにFANイベントが計画停止のために受信され、そのサービスまたはインスタンスのプールからアイドル接続が削除され、アクティブ(借りた)接続は、プールに返されるときに解放のマークが付けられます。これにより、ユーザーを妨げることなく、計画停止のために作業が効果的にドレインされます。アプリケーションを中断せずに、計画メンテナンス操作を正常に実行する手順は、My Oracle Supportのノート1593712.1を参照してください。

FANは、ランタイム接続のロード・バランシング、Web親和性およびデータ依存型ルーティングについてのアドバイザをポストする場合にも使用されます。

関連項目:

- 動的データベース・サービスの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- アプリケーションを中断しない計画メンテナンスの詳細は、My Oracle Supportのノート1593712.1 (http://support.oracle.com/)を参照してください

3.16.1.2.1 OracleクライアントへのFANの有効化

Oracle RACデータベースへの接続に使用される多くの一般的なクライアント・アプリケーション環境は、FANと統合されました。そのため、FANを使用する最も簡単な方法は、Oracle統合クライアントを使用することです。

FANとの統合によって、Oracle統合クライアントはOracle RACクラスタの最新のステータスをより迅速に認識します。これによって、クライアント接続が使用できなくなったインスタンスやサービスを待機したり接続試行することがなくなります。インスタンスが起動すると、Oracle RACでは、最近起動されたインスタンスへの接続を接続プールで作成し、このインスタンスで提供される追加リソースを接続プールで使用できるように、FANを使用して接続プールに通知します。

FANと統合されたOracleクライアント・ドライバでは次のことが適用されます。

- 終了した接続を削除すると同時に、サービスがインスタンスでDOWNとして宣言され、ノードも同時にDOWNとして宣言されます。

- サービスが再起動を繰り返し試行する間クライアントを待機させるかわりに、NOT RESTARTING状態がOracle Databaseで検出されるとすぐにエラーをクライアントにレポートします。

FANと統合されたOracle接続プールでは、次の処理を実行できます。

- サービスの起動時に、Oracle RACのすべてのインスタンス間で接続を均等に分散します。この方法は、接続プールで定義されているセッションを、サービスがサポートされている最初のOracle RACインスタンスに割り当てるよりも有効です。

- ロード・バランシング・アドバイザのイベントを使用して、実行時の作業要求を均等に分散します。

関連項目:
すべてのOracleクライアントでFANを有効化する方法の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

3.16.1.2.2 FANを使用できないアプリケーションの考慮事項

アプリケーション・レイヤーを実行しているホストでオペレーティング・システムの効率的なTCPタイムアウトを構成します。OS TCPタイムアウトは、データベース・レイヤーがフェイルオーバーするのにかかる時間およびデータベース・サービスが開始するのにかかる時間に設定される必要があります。TCPタイムアウトを適切に構成する方法については、オペレーティング・システムのマニュアルを参照してください。

例外のイベントに適切に応答するように、アプリケーション内の再接続ロジックを構成します。たとえば、接続プールからのセッションが切断となる例外(ORA-3113エラーなど)を受信すると、アプリケーションはそのセッションへの再接続を自動的に試みます。再接続の試行は、データベース・レイヤーをフェイルオーバーするのにかかる時間継続し、アプリケーション・サービスをオンラインにするように構成する必要があります。

3.16.2 トランザクション・フェイルオーバーおよび保護

トランザクションのフェイルオーバーおよび保護テクノロジには、トランザクション・ガードとアプリケーション・コンティニュイティがあります。

3.16.2.1 トランザクション・ガード

トランザクション・ガードは、アプリケーションで、計画済および計画外の停止に続くトランザクションに、信頼できる既知の結果を提供する汎用ツールです。アプリケーションでは論理トランザクションIDという新しい概念を使用して、停止に続くデータベース・セッション内でオープンになっている最終トランザクションの結果が判断されます。トランザクション・ガードを使用しないと、アプリケーションが停止の後に操作を実行しようとして、トランザクションが重複してコミットされ論理破損が発生する可能性があります。

最後の送信がコミットされたか、近いうちにコミットされるか、または完了まで実行されていないかを識別できない場合、アプリケーションがリプレイを試みることにより、すでに永続化されている変更の再発行が試みられる可能性があるため、トランザクションの送信が重複し、他の形式の論理的破損が発生する可能性があります。

トランザクション・ガードを使用しないと、トランザクションが開始され、コミットが発行された場合、クライアントに返されるコミット・メッセージに継続性がありません。クライアントは、トランザクションがコミットされたかどうかわからないままになります。トランザクションは、非トランザクション状態が不正確な場合、またはそのトランザクションがすでにコミットされている場合は、有効に再送信できません。保障されたコミットや完了情報がないと、再送信により、トランザクションが複数回適用され、不適切な状態になる可能性があります。

関連項目:

- Oracle RACおよび動的データベース・サービスでのトランザクション・ガードの詳細は、『Oracle Database 2日でReal Application Clustersガイド』

- 『Oracle Database開発ガイド』のアプリケーション開発者のためのSQL処理およびトランザクション・ガードの使用の項

- 『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』のDBMS_APP_CONTパッケージの項

3.16.2.2 アプリケーション・コンティニュイティ

高可用性アーキテクチャでは、アプリケーション層が生き残っているインスタンスまたはデータベースに透過的にフェイルオーバーして必要なサービスを通知する機能が必要です。これにより、ノード障害、インスタンス障害、データ破損またはデータベース障害時に、アプリケーションが通常どおり使用可能であることが保証されるか、または影響を最小限に抑えることができます。Javaのアプリケーション・コンティニュイティでは、別の使用可能なOracle RACインスタンスで、または別のデータベースに対して(Data Guardロール遷移の場合など)、リクエストをリプレイすることで、リカバリ可能な停止をマスキングしようとします。

アプリケーション・コンティニュイティには次のものが含まれます。

- FAN: 障害の通知

- 接続のクリーンアップ

- 別のOracle RACインスタンスまたはデータベースに存在するデータベース・サービスの自動再接続および再試行

- 進行中のリクエストのリプレイ

データベース・セッションの停止のマスキングはアプリケーション開発にとって複雑なタスクのため、結果的にエラーおよびタイムアウトが頻繁にユーザーに公開されます。アプリケーション・コンティニュイティは、リカバリ可能な停止(計画外および計画)に続いてデータベース・セッションをリカバリすることで、ユーザーおよびアプリケーションから停止をマスキングしようとします。アプリケーション・コンティニュイティはこのリカバリをアプリケーション直下で実行するため、アプリケーションにとっては、その停止が遅延された実行のように見えます。リカバリを成功させるには、アプリケーション・コンティニュイティによりクライアントに対してリストアされたデータやメッセージが、アプリケーションで表示され、決定が下された可能性のあるものと同じであることが必要です。

アプリケーション・コンティニュイティは、通常、基本となるソフトウェア、フォアグラウンド、ハードウェア、通信、ネットワークまたは記憶域の層に関連する、リカバリ可能な停止に対して起動されます。アプリケーション・コンティニュイティは計画外停止および計画停止の両方を処理するときのユーザーの操作性を向上させるために使用されます。

Oracle Database 12cリリース1では、Java用のアプリケーション・コンティニュイティは、次のものとの一般的使用が可能です。

- JDBC-Thin Oracleドライバ

- JDBCユニバーサル接続プール

- WebLogic Server Active Grid Link

関連項目:

- トランザクションの詳細は、『Oracle Database概要』を参照してください。

- トランザクションの詳細は、『Oracle Database開発ガイド』を参照してください。

- 動的データベース・サービスの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- 動的データベース・サービスの詳細は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。

3.16.3 グローバル・データ・サービスを使用したOracle Database

グローバル・データ・サービスにより、管理者は共通のサービスを提供するレプリケートされたデータベース全体でクライアント・ワークロードを自動的および透過的に管理できます。データベース・サービスは1つまたは複数のデータベース・インスタンスの名前付の表現です。サービスにより、データベース・ワークロードをグループ化し、特定の作業リクエストを適切なインスタンスへルーティングできます。グローバル・サービスはデータ・レプリケーションにより同期化された複数のデータベースにより提供されます。

グローバル・データ・サービスでは、共有サービスを提供する一連のレプリケート・データベースに動的ロード・バランシング、フェイルオーバーおよびサービスの集中管理を提供します。データベースのセットには、Oracle RACとOracle Data Guardを介して相互に関連するクラスタ以外のOracleデータベース、Oracle Multitenantの元で統合されたデータベース、Oracle GoldenGateまたはその他のレプリケーション技術を含めることができます。

グローバル・データ・サービスの利点は次のとおりです。

- グローバルに分散されたマルチ・データベース構成を含む、グローバル・リソースの集中管理が可能

- グローバルなスケーラビリティ、可用性、実行時ロード・バランシングの提供

- シームレスなフェイルオーバーのサポート

- GDS構成へのデータベースの動的な追加、およびグローバル・サービスの動的な移行が可能

- 最適なリソース使用率が可能

グローバル・サービス管理フレームワークはグローバル・サービス向けのソフトウェア・インフラストラクチャです。このフレームワークはGDS構成の構成、メンテナンスおよび監視を自動化および集中化し、サービスのロード・バランシングおよびフェイルオーバーを可能にします。このフレームワークでは、これらの仮想化リソースを最小限の管理オーバーヘッドで管理し、追加のクライアント要求を処理するために構成を有効化します。

グローバル・サービス管理のフレームワークは、次の既存のOracle Databaseテクノロジを中心に構築されます。

- Oracle Real Application Clusters(Oracle RAC)
1つのクラスタでの動的ロード・バランシングおよびワークロード管理が可能になります。

- Oracle Active Data Guard
読取り専用データベースの高いパフォーマンスのファームを可能にします。

- Data Guard Broker
プライマリ・データベースと最大30のスタンバイ・データベースを含むData Guard構成の作成、管理および監視を可能にします。

- Oracle GoldenGate
複数のデータベース間のレプリケーション更新を可能にします。

図3-3 グローバル・データ・サービスのアーキテクチャ

関連項目:
『Oracle Database Global Data Services概要および管理ガイド』

3.17 Oracle Multitenant

Oracle Multitenantは、Oracle Database 12c以降の最適なデータベース統合方法です。マルチテナント・アーキテクチャでは、これまでの統合方法に付きものであったトレードオフはなくし、それぞれの一番よい特性が結合されています。

Oracle MultitenantはOracle Database 12cの新しいオプションで、統合やプロビジョニング、アップグレードなどを簡素化することにより、ITコストの削減を支援します。この新しいアーキテクチャでは、コンテナ・データベースに多数のプラガブル・データベースを保持できます。アプリケーションでは、これらのプラガブル・データベースはスタンドアロン・データベースとして認識され、プラガブル・データベースにアクセスするためにアプリケーションを変更する必要はありません。複数のデータベースをプラガブル・データベースとして1つのコンテナ・データベースに統合することにより、複数のデータベースを1つのデータベースとして管理できるようになります。ビジネスで必要な場合には、分離してプラガブル・データベースを操作する柔軟性もあります。

Oracle Multitenantは、Oracle Real Application Clusters、Oracle Data GuardおよびOracle Golden Gateなど、その他の高可用性機能に完全に準拠しています。

Oracle Multitenantを使用する利点

- 統合密度の高さ - 1つのコンテナ・データベースに、多数のプラガブル・データベースを格納できます。これらのプラガブル・データベースでは、バックグラウンド・プロセスとメモリー構造が共有され、それぞれの単一データベースのオーバーヘッドが取り除かれたり、低減したりするため、単一データベースより多くのプラガブル・データベースを実行できます。

- 高速なプロビジョニングおよびクローニング - プラガブル・データベースは、あるコンテナ・データベースから切断して、別のコンテナ・データベースに接続できます。また、プラガブル・データベースを、同じコンテナまたは別のコンテナにクローニングすることも可能です。DBaaSまたはSaaS環境では、クローニングにより、ゴールド・イメージやシード・データベースを作成できます。このプラガブル・データベースをクローニングすれば、新規顧客用にデータベース環境を簡単に設定できます。

- パッチ適用およびアップグレードの新オプション - コンテナ・データベースをアップグレードまたはパッチ適用する場合、そのコンテナ内のすべてのプラガブル・データベースもアップグレードまたはパッチ適用されます。分離する必要がある場合は、プラガブル・データベースを切断して、より新しいバージョンのコンテナ・データベースに接続できます。

- データベースのバックアップおよびリカバリ - 複数のデータベースをプラガブル・データベースとして統合することで、バックアップや障害時リカバリなどの操作がコンテナ・レベルで実行されます。Oracle Multitenantでも、同じコンテナ・データベース内の、実行されているその他のプラガブル・データベースに影響を与えずに、個々のプラガブル・データベースを柔軟にバックアップおよびリストアできます。

- Oracle Data Guardを使用した操作 - コンテナ・データベース・レベルでは、Data Guard構成が維持されます。Data Guardのロール・トランジション(フェイルオーバーかスイッチオーバーのいずれか)が実行されると、すべてのプラガブル・データベースが新しいプライマリ・データベースに移行されます。単一データベースの場合には必要になりますが、プラガブル・データベースごとに複数のData Guard構成を作成したり管理したりする必要はありません。Data Guard Standby-First PatchやData Guard一時ロジカル・ローリング・アップグレードなどの既存ツールを使用して停止時間を短くすることが可能で、コンテナ・レベルで実行されるため、すべてのプラガブル・データベースを一度の操作でメンテナンスできます。

- Oracle Golden Gateを使用した操作 - Oracle Multitenantには、Oracle Golden Gateで提供されているすべての機能があります。Golden Gateにも、プラガブル・データベース・レベルで操作する柔軟性があるため、コンテナ・データベース内のプラガブル・データベースのサブセットにレプリケーションを実行できます。Golden Gateを使用して、コンテナ・データベース・レベルまたは個々のプラガブル・データベース・レベルで、停止時間が最小限またはゼロのアップグレードを実行できます。

- リソース管理 - Oracle Resource Managerで単一データベース間のリソース使用率を制御できるのと同じように、コンテナ内の個々のプラガブル・データベースのリソース使用率も制御できます。これにより、1つのプラガブル・データベースが、割り当てられている量を超えてシステム・リソースにアクセスすることはありません。

- Oracle Flashback Databaseの操作 - 高速のポイント・イン・タイム・リカバリが必要な場合は、Oracle Multitenantの初期リリースを使用すると、CDBレベルでフラッシュバック・データベースを使用できます。今後のリリースのOracle Multitenantでは、その他のPDBの可用性に影響を与えずに、個々のPDBでフラッシュバック・データベースを使用できるようにする予定です。

3.18 Oracle Restart

Oracle RestartはOracle 11gリリース2(11.2)の新機能で、単一インスタンスの(クラスタ化されていない)Oracle Databaseとそのコンポーネントの可用性を強化します。Oracle Restartは、単一インスタンス環境でのみ使用されます。Oracle Real Application Clusters(Oracle RAC)環境では、Oracle Clusterwareによってコンポーネントを自動再起動する機能が提供されます。

Oracle Restartをインストールすると、ハードウェアまたはソフトウェア障害の後、あるいはデータベースのホスト・コンピュータが再起動するときは必ず、データベース、リスナー、およびその他のOracleコンポーネントは自動的に再起動します。また、Oracleコンポーネントが、コンポーネントの依存性に応じて、確実に正しい順序で再起動します。

Oracle Restartでは、Oracle Restartと統合されているコンポーネント(SQL*Plus、リスナー制御ユーティリティ(LSNRCTL)、ASMCMDおよびOracle Data Guardなど)の状態を定期的に監視します。コンポーネントのヘルス・チェックに失敗すると、Oracle Restartはそのコンポーネントを停止し、再起動します。

Oracle Restartは、Oracle Databaseホームとは別にインストールするOracle Grid Infrastructureホームから実行されます。

統合されたクライアント・フェイルオーバー・アプリケーションは、Oracle Clusterwareにより管理されているロール・ベースのサービスや高速アプリケーション通知イベントに依存して、アプリケーションに障害の警告を行います。単一インスタンス・データベースで、統合されたクライアント・フェイルオーバーを実現するには、Oracle Restartが必要です。

関連項目:

- Oracle Restart機能のインストールおよび構成の詳細は、『Oracle Database管理者ガイド』を参照してください。

- ご使用のプラットフォーム用のOracle Grid Infrastructureのインストレーション・ガイドを参照してください。

3.19 Oracle Site Guard

Oracle Site Guardは障害時リカバリ・ソリューションで、管理者は、サイトの完全なスイッチオーバーやフェイルオーバーを自動化できるようになります。

Oracle Site Guardは、Oracle Fusion Middleware、Oracle Fusion ApplicationsおよびOracleデータベースの調整されたフェイルオーバーを編成して自動化します。また、拡張して、別のデータ・センターのソフトウェア・コンポーネントを組み込むことも可能です。

Oracle Site Guardは、プライマリ環境とスタンバイ環境を同期し、ミッション・クリティカルなデータを保護する基礎となるレプリケーション・メカニズムと統合できます。Oracleデータベース用のOracle Data GuardやOracle Sun ZFSのサポートが組み込まれています。また、Oracle Site Guardは、他のストレージ・レプリケーション・テクノロジをサポートすることも可能です。

関連項目:
Oracle Enterprise Manager Oracle® Site Guard管理者ガイド

4 計画外停止時間用Oracle Database高可用性ソリューション

Oracle Databaseは、可用性を高め、計画停止時間と計画外停止時間のいずれもゼロまたは最小限に抑える高可用性ソリューションの統合スイートを提供します。これらのソリューションは、企業が24時間年中無休でビジネスの継続性を維持する場合に役立ちます。一方で、Oracle高可用性ソリューションは、プライマリ・システムおよびセカンダリ・システムでのシステム使用効率を高め、パフォーマンス、スケーラビリティおよび管理性全体の向上を支援するソリューションを提供することにより、停止時間の短縮にとどまらない機能を実現します。

表4-1は、計画外停止時間に対する様々なOracle高可用性ソリューションの説明です。この表は、後続の項で説明する機能を使用して、計画外停止時間の様々な原因に対処する方法を示しています。いくつかのOracleソリューションがリストされている場合、MAA推奨ソリューションはOracleソリューション列に示しています。

表4-2は、MAA参照アーキテクチャおよびマルチテナント・アーキテクチャにおける、各MAAサービス・レベル層の高可用性ソリューションの説明です。

個々のOracle高可用性アーキテクチャの計画外停止時間タイプすべての達成可能なリカバリ時間に関する概要は、第7章「高可用性アーキテクチャ」を参照してください。

表4-1 計画外停止時間の停止タイプとOracle高可用性ソリューション

停止範囲

Oracleソリューション

利点

サイトの障害

Oracle Data Guard (MAA推奨)およびOracle Applicationフェイルオーバー・ソリューション

- 統合されたクライアントとアプリケーションのフェイルオーバー

- 最も高速で簡単なデータベースのレプリケーション

- すべてのデータ型のサポート

- 伝播遅延の解消によるデータ損失ゼロ

- プライマリの負荷をオフロードするためのOracle Active Data Guardの読取り専用サービス、グローバル一時表および順序でのDMLのサポート

Oracle GoldenGate

- 柔軟な論理レプリケーション・ソリューション(ターゲットは読取り/書取りで開く)

- アクティブ-アクティブな高可用性(競合解決を含む)

- 異機種プラットフォームおよび異機種データベースのサポート

Recovery ManagerとOracle Secure Backup

- 完全に管理されたデータベース・リカバリおよびOracle Secure Backupとの統合

- 非リアルタイム・リカバリ

インスタンスまたはコンピュータの障害

Oracle Real Application ClustersおよびOracle Clusterware(MAA推奨)

- 統合されたクライアントとアプリケーションのフェイルオーバー

- 障害が発生したノードとインスタンスの自動リカバリ

- Oracle Real Application Clustersによる最小限のアプリケーション低下

Oracle RAC One Node

- 統合されたクライアントとアプリケーションのフェイルオーバー

- オンライン・データベースの再配置による接続とインスタンスの別のノードへの移行

- 従来のコールド・フェイルオーバー・ソリューションよりも高いデータベースの可用性

Oracle Data Guard

- 統合されたクライアントとアプリケーションのフェイルオーバー

- 最も高速で簡単なデータベースのレプリケーション

- すべてのデータ型のサポート

- 伝播遅延の解消によるデータ損失ゼロ

- プライマリの負荷をオフロードするためのOracle Active Data Guardの読取り専用サービス、グローバル一時表および順序でのDMLのサポート

Oracle GoldenGate

- 柔軟な論理レプリケーション・ソリューション(ターゲットは読取り/書取りで開く)

- アクティブ-アクティブな高可用性(競合解決を含む)

- 異機種プラットフォームおよび異機種データベースのサポート

ストレージ障害

Oracle Automatic Storage Management(MAA推奨)

- ミラー化およびオンライン自動リバランスによる、個別の障害グループへのデータの冗長コピーの配置。

Oracle Data Guard(MAA推奨)

- 統合されたクライアントとアプリケーションのフェイルオーバー

- 最も高速で簡単なデータベースのレプリケーション

- すべてのデータ型のサポート

- 伝播遅延の解消によるデータ損失ゼロ

- プライマリの負荷をオフロードするためのOracle Active Data Guardの読取り専用サービス、グローバル一時表および順序でのDMLのサポート

高速リカバリ領域およびOracle Secure Backupを使用するRecovery Manager (MAA推奨)

- 完全に管理されたデータベース・リカバリとディスクおよびテープのバックアップ

Oracle GoldenGate

- 柔軟な論理レプリケーション・ソリューション(ターゲットは読取り/書取りで開く)

- アクティブ-アクティブな高可用性(競合解決を含む)

- 異機種プラットフォームおよび異機種データベースのサポート

データ破損

破損の予防、検出および修復(MAA推奨)

DB_BLOCK_CHECKING、DB_BLOCK_CHECKSUMおよびDB_LOST_WRITE_PROTECTなどのデータベース初期化設定

- 様々なレベルのデータおよびREDOブロック破損予防とデータベース・レベルでの検出

データ破損

Oracle Data Guard(MAA推奨)

Oracle Active Data Guard自動ブロック修復

DB_LOST_WRITE_PROTECT初期化パラメータ

- Oracle Active Data GuardスタンバイがあるData Guard構成では、プライマリ・データベースで検出された物理ブロック破損は、スタンバイから取得されたブロックの良好なコピーを使用して自動的に修復されます。修復は、ユーザーとアプリケーションに対して透過的です。

- Oracle Active Data Guardを使用して、データ破損がデータベースから強力に分離されます。

- MAAの推奨初期化設定では、Oracle Active Data GuardおよびOracle Exadata Database Machineで、最も包括的でフル・スタックの破損保護が実現されます。

- DB_LOST_WRITE_PROTECTが有効化されている場合、プライマリ・データベースで発生した書込み欠落がフィジカル・スタンバイ・データベースによって、またはプライマリ・データベースのメディア・リカバリ時に検出されると、リカバリはデータベースの一貫性を保つために停止します。Data Guardを使用してスタンバイ・データベースにフェイルオーバーすると、データの一部が失われます。Oracle Database 12cリリース1 (12.1.0.2)およびData Guard Brokerでは、プライマリ・データベースで書込み欠落が検出された場合に、Data Guard BrokerのPrimaryLostWriteプロパティで、SHUTDOWNとCONTINUE (Oracle Database 11gリリース2 (11.2.0.4)と同様)の他に、FAILVOERとFORCEFAILOVERオプションもサポートされます。『Oracle Data Guard Broker』を参照してください

- 書込み欠落がスタンバイ・データベースで検出される場合、書込み欠落を分離させて、ハードウェアの問題を修正できれば、影響を受けたファイルをリストアして、REDO Applyを再起動できます。

- DB_LOST_WRITE_PROTECT初期化パラメータでは、書込み欠落が検出されます。
注意: 書込み欠落はデータベース全体を破損する可能性があり、ハードウェアの問題を解決した後に、影響を受けたデータベースを再構築することが必要になります。

Dbverify、Analyze、データ・リカバリ・アドバイザとRecovery Manager、高速リカバリ領域を使用するASM修正(MAA推奨)

- これらのツールを使用すると、管理者が手動チェックを実行できるため、様々なデータ破損を検出し、可能な場合には修復できます。

- DbverifyとAnalyzeでは、物理的ブロック・チェックおよび論理的ブロック内チェックが実行されます。Analyzeでは、オブジェクト間の一貫性チェックを実行できます。

- データ・リカバリ・アドバイザでは、データ破損が自動的に検出され、最適なリカバリ計画が推奨されます。

- RMAN操作では、物理チェックとブロック内論理チェックの両方を実行できます。

- RMANでは、フラッシュバック・ログ、バックアップまたはスタンバイ・データベースを使用してオンライン・ブロックメディア・リカバリを実行して、物理ブロック破損からリカバリできます。

- ASM修正では、標準冗長性および高冗長性のディスク・グループ内のASMペアを使用して、物理的および論理的データ破損が検出され、修復が試行されます。

データ破損

Oracle Exadata Database MachineおよびOracle Automatic Storage Management(MAA推奨)

DIX + T10 DIF拡張(該当する場合はMAA推奨)

- Oracle ASMでは、破損を検出し、良好なミラーがある場合、良好なブロックを返し、後続の書込みI/O中にその破損を修復

- Exadataが、不正または誤った記憶域I/Oを原因とするデータ破損を防止する、暗黙のHARD対応チェックを提供。

- Exadataでは、ハード・ディスク修正および修復が自動的に行われます。不良セクターの検出および修正。

- DIX +T10 DIF拡張では、ベンダーのホスト・アダプタからストレージ・デバイスに対するチェックサム検証を通じて、読取りおよび書込みのエンドツーエンドのデータ整合性が保証されます

Oracle GoldenGate

- 柔軟な論理レプリケーション・ソリューション(ターゲットは読取り/書取りで開く)。パートナ・レプリカが破損している場合、フェイルオーバー・ターゲットとして論理レプリカを使用可能

- アクティブ-アクティブな高可用性(競合解決を含む)

- 異機種プラットフォームおよび異機種データベースのサポート

人為的エラー

Oracleセキュリティ機能 (MAA推奨)

- ヒューマン・エラーを防ぐためのアクセスの制限

Oracle Flashbackのテクノロジ(MAA推奨)

- 不適切な結果のファイングレイン・エラー調査

- ファイングレインおよびデータベース全体の巻戻しとリカバリ機能

遅延または減速

Oracle DatabaseおよびOracle Enterprise Manager

Oracle Data Guard (MAA推奨)およびOracle Applicationフェイルオーバー・ソリューション

- Oracle Databaseでは、インスタンスおよびデータベースの遅延またはクラスタの減速を自動的に監視し、ブロックしているプロセスまたはインスタンスを取り除いて、遅延の長期化や不要なノード削除を防ごうとします。

- アプリケーションまたはレスポンス時間の減速を検出し、これらのSLA違反に対応するようにOracle Enterprise Managerまたはカスタマイズしたアプリケーションのハートビートを構成できます。
たとえば、Enterprise Managerのビーコンを構成して、アプリケーションのレスポンス時間を監視および検出できます。一定のしきい値に到達すると、Enterprise ManagerによってData GuardのDBMS_DG.INITIATE_FS_FAILOVER PL/SQLプロシージャがコールされ、フェイルオーバーが開始されます。『Oracle Data Guard Broker』の、アプリケーションによって開始されるファスト・スタート・フェイルオーバーに関する項を参照してください。

ファイル・システム・データ

データベース以外のファイルに対するOracleレプリケーション・テクノロジ

- データベース以外のファイルを含むフル・スタック・フェイルオーバーの有効化

DBaaSで多数のデータベースを管理している場合は、2.3.1項「Oracle MAA参照アーキテクチャ」に示すように、MAA層およびOracle Multitenantの使用をお薦めします。表4-2は、マルチテナント・アーキテクチャのデータベースに影響を及ぼす、様々な計画外停止を示します。また、HAの各層で使用可能なOracle HAソリューションで、その停止に対応するものも示します。

表4-2 MAA参照アーキテクチャおよびマルチテナント・アーキテクチャの計画外停止マトリックス

イベント

MAA層ごとのソリューション

リカバリ期間(RTO)

データ消失(RPO)

インスタンス障害

BRONZE: Oracle Restart

サーバーを再起動できる場合は数分

ゼロ

SILVER: Oracle RACまたはオプションでOracle RAC One Node

Oracle RACの場合は数秒、Oracle RAC One Nodeの場合は数分

ゼロ

GOLD: Oracle RAC

数秒

ゼロ

PLATINUM: Oracle RAC(アプリケーション・コンティニュイティ機能あり)

アプリケーションの停止なし

ゼロ

永続的なノード障害(ただし、ストレージは使用可能)

BRONZE: リストアおよびリカバリ

数時間から1日

ゼロ

SILVER: Oracle RAC

数秒

ゼロ

SILVER: Oracle RAC One Node

数分

ゼロ

GOLD: Oracle RAC

数秒

ゼロ

PLATINUM: Oracle RAC(アプリケーション・コンティニュイティ機能あり)

アプリケーションの停止なし

ゼロ

ストレージ障害

すべて: Automatic Storage Management

停止時間ゼロ

ゼロ

データ破損

BRONZE/SILVER: 基本的な保護。一部の破損では、リカバリ、リストアおよびプラガブル・データベース(PDB)、マルチテナント・コンテナ・データベース(CDB)全体またはコンテナ以外のデータベース(非CDB)のリカバリが必要

数時間から数日

リカバリ不能な場合は、最後のバックアップ以降

GOLD/PLATINUM: Oracle Active Data Guardによる包括的な破損保護および自動ブロック修復

自動ブロック修復によりゼロ

破損の原因が書込み欠落で、Data Guardファスト・スタート・フェイルオーバーを使用している場合は、数秒から数分。

破損の原因が書込み欠落でない場合はゼロ

人的エラー

すべて: 論理障害はフラッシュバック・ドロップ、フラッシュバック表、フラッシュバック・トランザクション、フラッシュバック問合せおよびUNDOにより解決。

検出時間による異なるが、それらのオブジェクトを使用してPDBやアプリケーションに分離。

論理障害により異なる

すべて: RMANポイント・イン・タイム・リカバリ(PDB)またはフラッシュバック・データベースを必要とするデータベースおよびPDB全体に影響を与える包括的な論理障害

検出時間により異なる

論理障害により異なる

GOLD/PLATINUM: Oracle GoldenGateを使用している場合は、1つのPDBのみのフェイルオーバーが可能

検出時間により異なるが、実際のフェイルオーバーは数秒

論理障害により異なる

データベース使用不可、システム障害、サイト障害、ストレージ障害、大規模な破損または災害

BRONZE/SILVER: リストアおよびリカバリ

数時間から数日

最後のバックアップ以降

GOLD: セカンダリへのフェイルオーバー(Oracle Active Data GuardまたはOracle GoldenGate)

数秒

ゼロからほぼゼロ

PLATINUM: Active Data Guardフェイルオーバー(アプリケーション・コンティニュイティ機能あり)

アプリケーションの停止なし

ゼロ

パフォーマンスの低下

すべて: データベース・リソース・マネージャおよびチューニング

停止時間はないがサービスは低下

ゼロ

5 計画停止時間用Oracle Database高可用性ソリューション

計画停止時間は、計画外停止時間と同様、業務に悪影響を及ぼします。これは、特に、複数のタイムゾーンのユーザーをサポートする必要がある、または顧客に24時間年中無休でインターネット・アクセスを提供する必要があるグローバル企業に当てはまります。

以前は、次のような作業を実行する場合に停止時間が必要でした。

- データベース、アプリケーション、オペレーティング・システム、ミドルウェアまたはネットワークを更新するためのパッチ適用またはシステムの再構成などの定期的なメンテナンス。

- ハードウェア、データベース、アプリケーション、オペレーティング・システム、ミドルウェアまたはネットワークの主要アップグレードまたは新規導入などの新規デプロイメント。

この章の内容は次のとおりです。

- 移行用高可用性ソリューション

- 動的およびオンライン・リソース・プロビジョニング

- オンライン再編成および再定義

- システムおよびソフトウェア・メンテナンス用Oracle高可用性ソリューション

- アプリケーションのオンライン・メンテナンスおよびオンライン・アップグレード

5.1 移行用高可用性ソリューション

表5-1は、移行に対する高レベルな高可用性ソリューションの説明です。各ソリューションについては、表に示した各項で説明しています。

表5-1 移行用高可用性ソリューション

移行タイプ

推奨されるOracleソリューション

ソリューションの説明

停止時間

異なるプラットフォームへのデータベースの移行

Oracle Data Guard、データ・ポンプ、Recovery ManagerおよびOracle GoldenGate

5.1.1項「プラットフォームの移行」

Oracle Data GuardまたはGoldenGateの場合数秒から数分

データ・ポンプおよびRecovery Managerの場合数秒から数分

異なるキャラクタ・セットへのデータベースの移行

Oracle GoldenGate

5.1.2項「異なるキャラクタ・セットへのデータベースの移行」

数秒から数分

プラガブル・データベースまたは別のプラガブル・データベースに移行

プラガブル・データベースのリモート・クローニング

データ・ポンプ、Recovery ManagerおよびOracle GoldenGate

SQL*Plus

第5.1.3項「マルチテナント・アーキテクチャへの移行」

GoldenGateの場合数秒から数分

データ・ポンプおよびRecovery Managerの場合数秒から数分

プラガブル・データベースのリモート・クローニングの場合は数分から数時間

ストレージの移行

Oracle Automatic Storage ManagementおよびOracle Data Guard

5.1.4項「Oracle ASM記憶域への移行」

Oracle ASMの場合停止時間ゼロ

Data Guardの場合数秒から数分

単一インスタンス・システムからOracle RACクラスタへのデータベースの移行

Oracle Data Guard

5.1.5項「単一インスタンス・システムからOracle RACクラスタへのデータベースの移行」

数秒から数分

5.1.1 プラットフォームの移行

既存のデータベースを現在のシステムとは異なるオペレーティング・システムが実行しているシステムへと移動する場合、異なるプラットフォームへのデータベースの移行が必要です。たとえば、Microsoft WindowsからLinuxへ、またはAIXやHP-UXからOracle Linuxを実行中のOracle Exadata Database Machineへデータベースを移動する場合、データベースの移行が必要です。データベース移行オプションは、ソース・データベースのプラットフォームとソース・データベースのバージョンに大きく依存します。異なるプラットフォームへのデータベースの移行は、次のいずれかのソリューションにより実行できます。

- Data Guard異機種間フィジカル・スタンバイ

- データ・ポンプの全体トランスポータブル・エクスポート/インポート

- データ・ポンプの表領域トランスポータブル・エクスポート/インポート

次の機能を前述の移行ソリューションと組み合せて使用して、データベース移行の停止時間を短縮できます。

- Recovery Managerの非一貫性表領域のクロス・プラットフォーム・トランスポート

- Oracle GoldenGate

5.1.1.1 Oracle Exadata Database MachineまたはOracle SuperClusterへのデータベースの移行

Oracle Exadata Database MachineまたはOracle SuperClusterへのデータベースの移行は、この項で説明するプラットフォーム間の移行と同じ方法を使用します。Oracle ExadataおよびOracle SuperClusterのターゲット・プラットフォームについて、表5-2で説明します。

表5-2 設計されたシステムへのプラットフォームの移行

設計されたシステム

データベース・プラットフォーム

Oracle Exadata Database Machine

Oracle Linux x86 64ビット(リトル・エンディアン)または

Oracle Solaris x86-64 (リトル・エンディアン)

Oracle SuperCluster

Oracle Solaris SPARC (ビッグ・エンディアン)

関連項目:
MAAホワイト・ペーパー『Exadata Database Machineへの移行のベスト・プラクティス』(http://www.oracle.com/goto/maa)

5.1.1.2 プラットフォームの移行ソリューション

表5-3に、データベース移行シナリオに使用する推奨ソリューションを示します。各ソリューションについては、表に示した各項で説明しています。

表5-3 データベース移行シナリオおよびソリューション

データベース移行シナリオ

使用するソリューション

同じエンディアン形式のプラットフォームへの移行

1. Data Guardの異種構成

2. Data Guard異機種間フィジカル・スタンバイが使用できない場合のデータ・ポンプの全体トランスポータブル・エクスポート/インポート

3. データ・ポンプの全体トランスポータブル・エクスポート/インポートが使用できない場合のデータ・ポンプの表領域トランスポータブル・エクスポート/インポート

4. Data Guard異機種間フィジカル・スタンバイが使用できず、データ・ポンプでは不可能なほど停止時間を短くする必要がある場合のOracle Golden Gate

異なるエンディアン形式のプラットフォームへの移行

1. データ・ポンプの全体トランスポータブル・エクスポート/インポート

2. データ・ポンプの全体トランスポータブル・エクスポート/インポートが使用できない場合のデータ・ポンプの表領域トランスポータブル・エクスポート/インポート

3. データ・ポンプでは不可能なほど停止時間を短くする必要がある場合のOracle Golden Gate

5.1.1.2.1 Data Guardの異種構成

Data Guardは、制限された数のプラットフォームの組合せに対し(WindowsからLinuxなど)、フィジカル・スタンバイ・データベースのプライマリ・システムとは異なるプラットフォームでの実行をサポートします。異機種間プライマリ/スタンバイの組合せをサポートするプラットフォーム間移行は、Data Guardのスイッチオーバー操作のみで実行できます。この方法を使用するには、次の条件を満たす必要があります。

- プラットフォームの組合せは、My Oracle Supportのノート413484.1にサポート対象として記載されている必要があります。

- ソース・データベースとターゲット・データベースのOracle Databaseリリースは同じである必要があります。

関連項目:
My Oracle SupportのNote 413484.1 (http://support.oracle.com/)

5.1.1.2.2 データ・ポンプの全体トランスポータブル・エクスポート/インポート

全体トランスポータブル・エクスポート/インポート機能を使用すると、データベース全体をあるプラットフォームから別のプラットフォームにコピーできます。データ・ポンプを使用してエクスポート・ダンプ・ファイルを生成し、必要な場合、ダンプ・ファイルとユーザー定義の表領域のデータ・ファイルをターゲット・データベースに転送し、その後、エクスポート・ダンプ・ファイルをインポートできます。全体トランスポータブル・エクスポートは、Oracle Database 11g リリース2(11.2.0.3)以降を実行しているソース・データベースでサポートされます。

データのトランスポートの一般的な制限および完全トランスポータブル・エクスポート/インポート特有の制限については、『Oracle Database管理者ガイド』のデータのトランスポートに関する項を参照してください。

全体トランスポータブル・エクスポートでは、データベースの完全なコピーを作成するために必要なすべてのオブジェクトおよびデータがエクスポートされます。次のデータ移動方法の組合せが使用されます。

- トランスポータブル表領域に存在するオブジェクトは、そのメタデータのみがダンプ・ファイル・セットにアンロードされ、データ自体はデータ・ファイルをターゲット・データベースにコピーしたときに移動されます。コピーする必要のあるデータ・ファイルは、エクスポート操作のログ・ファイルの最後に表示されます。

- 非トランスポータブル表領域に存在するオブジェクト(SYSTEMやSYSAUXなど)は、ダイレクト・パス・アンロードおよび外部表を使用して、そのメタデータとデータの両方がダンプ・ファイル・セットにアンロードされます。

データベースを新しいプラットフォームに移行するのに必要な時間は次の要因により異なります。

- データ・サイズ

- メタデータ・サイズ

データベース移行の手順の概要は、次のとおりです。

1. 新しい空のデータベースをターゲット・プラットフォーム上に作成します。

2. アプリケーションを停止します(データへの読取り専用アクセスは引き続き許可されます)。

3. ソース・データベースでユーザー表領域を読取り専用にします。

4. ソース・データベースの全体トランスポータブル・エクスポートを実行します。

5. ユーザー表領域のデータ・ファイルとエクスポート・ダンプ・ファイルを宛先システムに送信します。

6. RMANを使用して、データ・ファイルを移動先システムのエンディアン形式に変換します(必要な場合)。

7. ターゲット・データベースへの全体トランスポータブル・インポートを実行します。

8. ターゲット・データベースでユーザー表領域を読取り/書込みにします。

9. アプリケーションを開始し、ターゲット・データベースに接続します。

移行による停止時間を短縮するために、Recovery Managerの非一貫性表領域のクロス・プラットフォーム・トランスポートを、データ・ポンプの全体トランスポータブル・エクスポート/インポートとあわせて使用します。

関連項目:
詳細は、5.1.1.4項「データベース移行の停止時間を短縮する方法」を参照してください。

5.1.1.3 データ・ポンプの表領域トランスポータブル・エクスポート/インポート

表領域トランスポータブル・エクスポート/インポート機能を使用して、ユーザー定義の表領域全体を、あるプラットフォームのデータベースから別のプラットフォームで実行しているデータベースにコピーできます。表領域トランスポータブル・エクスポートでは、ユーザー定義の表領域の特定のセット内にある表のメタデータ(およびその表の依存オブジェクト)のみがエクスポートされます。表領域データ・ファイルは別の操作でコピーされます。次に、トランスポータブル表領域インポートが実行され、メタデータを含むダンプ・ファイルのインポートと、使用するデータ・ファイルの指定が行われます。表領域トランスポータブル・エクスポートは、バージョン10.0互換以降のソース・データベースおよびターゲット・データベース用の異なるプラットフォーム間でサポートされます。

データのトランスポートの一般的な制限および表領域のトランスポータブル・エクスポート/インポート特有の制限については、『Oracle Database管理者ガイド』のデータのトランスポートに関する項を参照してください。

データベースを新しいプラットフォームに移行するのに必要な時間は次の要因により異なります。

- データ・サイズ

- メタデータ・サイズ

高度な手順は次のとおりです。

1. 新しい空のデータベースをターゲット・プラットフォーム上に作成します。

2. アプリケーションを停止します(データへの読取り専用アクセスは引き続き許可されます)。

3. トランスポート操作に必要なオブジェクトを、ターゲット・データベースにインポートします。

4. ソース・データベースでユーザー表領域を読取り専用にします。

5. ソース・データベースの全体トランスポータブル・エクスポートを実行します。

6. ユーザー表領域のデータ・ファイルとエクスポート・ダンプ・ファイルを宛先システムに送信します。

7. RMANを使用して、データ・ファイルを移動先システムのエンディアン形式に変換します(必要な場合)。

8. すべてのユーザー表領域のトランスポータブル・インポートを実行します。

9. トランスポートできないデータベース・オブジェクトをエクスポートおよびインポートします。

10. ターゲット・データベースでユーザー表領域を読取り/書込みにします。

11. アプリケーションを開始し、ターゲット・データベースに接続します。

移行による停止時間を短縮するために、Recovery Managerの非一貫性表領域のクロス・プラットフォーム・トランスポートを、データ・ポンプの表領域トランスポータブル・エクスポート/インポートとあわせて使用します。

関連項目:
5.1.1.4項「データベース移行の停止時間を短縮する方法」

5.1.1.4 データベース移行の停止時間を短縮する方法

以降の項で説明する方法を前述の移行方法と組み合せて使用して、データベース移行の停止時間を短縮できます。

- Recovery Managerの非一貫性表領域のクロス・プラットフォーム・トランスポート

- Oracle GoldenGate

5.1.1.4.1 Recovery Managerの非一貫性表領域のクロス・プラットフォーム・トランスポート

データ・ポンプの全体または表領域トランスポータブル・エクスポート/インポートを使用したデータベースの移行に必要な停止時間は、主に次の2つの要因で決定されます。

- データ・サイズ

- メタデータ・サイズ

移行による停止時間を短縮するために、Recovery Managerの非一貫性表領域のクロス・プラットフォーム・トランスポートを、データ・ポンプの全体または表領域トランスポータブル・エクスポート/インポートとあわせて使用します。移行による停止時間は、ソース・データベースをオンラインにしたまま、ほとんどのデータの移動を許可することにより短縮されます。Recovery Managerの非一貫性表領域のクロス・プラットフォーム・トランスポートを、データ・ポンプの全体または表領域トランスポータブル・エクスポート/インポートとあわせて使用する場合、必要な停止時間は、主に次の要因で決定されます。

- データの変更率

- メタデータ・サイズ

RMANにより、ソース・システムのユーザー定義の表領域の非一貫性バックアップを作成し、それをターゲット・システムにリストアすることで、ソース・システムのデータベースをオンラインにしたままで、データベースの大部分をターゲット・システムにトランスポートできます。最初のバックアップ/リストア操作は時間がかかる可能性があるので、非一貫性バックアップで生成されたデータ・ファイルには、クロス・プラットフォームの増分バックアップを使用して、1回または複数回のロール・フォワードが行われる可能性があります。トランスポートを完了するためにデータ・ファイルの一貫性を保つには、表領域が読取り専用モードのときに取得した、最終クロス・プラットフォーム増分バックアップを適用します。最後の手順は、データ・ポンプの全体または表領域トランスポータブル・エクスポート/インポートを使用して移行を完了することです。

ターゲット・システムにデータベースを移動する手順の概要は、次のとおりです。

フェーズ1: 準備フェーズ

1. すべてのユーザー定義表領域のRMANクロス・プラットフォーム非一貫性バックアップを作成します。

2. クロス・プラットフォーム非一貫性バックアップをターゲット・システムにリストアします。ターゲット・システムで作成されたターゲット・データ・ファイルは外部データ・ファイルと呼ばれます。

フェーズ2: ロール・フォワード・フェーズ

1. すべてのユーザー定義表領域のRMANクロス・プラットフォーム増分バックアップを作成します。

2. クロス・プラットフォーム増分バックアップを適用することによって、ターゲット・システムの外部データファイルをリカバリします。
ロール・フォワード・フェーズは必要な回数繰り返され、ソース・データベースまで外部データ・ファイルを取り込みます。

フェーズ3: トランスポート・フェーズ

1. アプリケーションを停止します。

2. ユーザー定義の表領域を読取り専用にします。

3. フェーズ2(ロール・フォワード・フェーズ)をもう一度繰り返します。

4. データ・ポンプの全体トランスポータブル・エクスポート/インポートを使用してデータベースを移行するか、またはデータ・ポンプの表領域トランスポータブル・エクスポート/インポートを使用してユーザー定義の表領域を移行します。

5. アプリケーションを開始し、ターゲット・データベースに接続します。

関連項目:
『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』

5.1.1.4.2 Oracle GoldenGate

Oracle GoldenGateを使用して移行の停止時間を短縮します。移行による停止時間は、ソース・データベースをオンラインにしたまま、ターゲット・データベースを作成し、同期を維持することを許可することにより短縮されます。Oracle GoldenGateを使用したときに必要な停止時間は、アプリケーションがターゲット・データベースに再接続するのにかかる時間です。

高度な手順は次のとおりです。

1. Oracle GoldenGate Extractグループを開始して、実行中のデータの変更を抽出します。

2. データ・ポンプの全体トランスポータブル・エクスポート/インポート、またはデータ・ポンプの表領域トランスポータブル・エクスポート/インポートを使用して、ターゲット・データベースを作成します。

3. Oracle GoldenGate Replicatグループを開始し、ターゲット・データベースの作成中に変更された行を再同期します。

4. アプリケーションを停止します。

5. Oracle GoldenGate Replicatの終了を待機して、証跡ファイルの残りの変更を適用します。

6. アプリケーションを開始し、ターゲット・データベースに接続します。

関連項目:

- 3.2項「Oracle GoldenGate」

- https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1276058.1のOracle GoldenGateベスト・プラクティス: Oracleソース・データベースからのインストール

5.1.2 異なるキャラクタ・セットへのデータベースの移行

Oracle GoldenGateを使用してキャラクタ・セットの移行の停止時間を短縮します。キャラクタ・セットの移行による停止時間は、ソース・データベースをオンラインにしたまま、ターゲット・データベースを作成し、同期を維持することを許可することにより短縮されます。Oracle GoldenGateを使用したときに必要な停止時間は、アプリケーションがターゲット・データベースに再接続するのにかかる時間です。

高度な手順は次のとおりです。

1. 目的のキャラクタ・セットで空のターゲット・データベースを作成します。

2. 変更－同期「抽出」グループを開始して、実行中のデータの変更を抽出します。

3. データ・ポンプの全体トランスポート不可能なエクスポート/インポートを実行します。インポート・プロセス中に、データは新しいキャラクタ・セットに自動的に変換されます。

4. 変更-同期「Replicat」グループを開始し、ターゲット・データベースの作成中に変更された行を再同期します。

5. アプリケーションを停止します。

6. アプリケーションを開始し、ターゲット・データベースに接続します。

関連項目:
3.2項「Oracle GoldenGate」

5.1.3 マルチテナント・アーキテクチャへの移行

非コンテナ・データベース(非CDB)または切断されたプラガブル・データベース(PDB)の、ターゲットCDB内のPDBへの移行は、次のいずれかのソリューションにより実行できます。

- CREATE PLUGGABLE DATABASE文

- データ・ポンプの全体トランスポータブル・エクスポート/インポート

- データ・ポンプの表領域トランスポータブル・エクスポート/インポート

表5-4 プラガブル・データベース移行ソリューション

ソリューション

使用する場合

CREATE PLUGGABLE DATABASE文

非CDBまたは切断されたPDBがOracle Database 12 cであり、ターゲットCDBと同じエンディアン形式の場合に使用します。

データ・ポンプの全体トランスポータブル・エクスポート/インポート

非CDBがOracle Database 11g リリース2(11.2.0.3)以降であるか、非CDBがCDBとは異なるエンディアン形式である場合に使用します。

データ・ポンプの表領域トランスポータブル・エクスポート/インポート

非CDBのバージョンがOracle Database 11g リリース2(11.2.0.3)より前の場合に使用します。

プラガブル・データベースのリモート・クローニング

既存のPDBをあるCDBから別のCDBへクローニングする場合に使用します。

以降の項で説明する方法を前述のソリューションと組み合せて使用して、移行の停止時間を短縮できます。

- Recovery Managerの非一貫性表領域のクロス・プラットフォーム・トランスポート

- Oracle GoldenGate

マルチテナント・アーキテクチャへの移行時の停止時間を短縮するためにこれらの機能を使用することは、異なるプラットフォームへのデータベースの移行の停止時間を短縮するためにこれらの機能を使用することと同じです。

関連項目:

- http://www.oracle.com/technetwork/database/availability/maa-consolidation-2186395.pdfのMAAホワイト・ペーパー『データベース統合の高可用性ベスト・プラクティス - Database-as-a-Serviceの基盤』

- 『Oracle Database管理者ガイド』

5.1.4 Oracle ASM記憶域への移行

5.1.4.1 Data Guardを使用したOracle ASM管理対象ストレージへの移行

データベースでストレージの管理にOracle ASMを現在使用してしていない場合、データベースの全体または一部をOracle ASMに移行して、データベース管理を簡略化できます。Data Guardを使用して、Oracle ASMへの移行時の停止時間を最小化します。高度な手順は次のとおりです。

1. Oracle ASM記憶域を使用したスタンバイ・データベースの作成

2. Data Guardスイッチオーバーを実行する時間

関連項目:

- MAAホワイト・ペーパー『ASMへの移行の最小限の停止時間』(http://www.oracle.com/goto/maa)

- 『Oracle Automatic Storage Management管理者ガイド』のRMANでのOracle ASMデータ移行の実行に関する項

5.1.4.2 Oracle ASMリバランスを使用した新しいストレージへの移行

既存のストレージ・デバイスがすでにOracle ASMによって管理されており、新しいストレージに配置される予定で、新しいストレージは既存のデータベース・サーバーまたはクラスタに接続される場合、Oracle ASMを使用してストレージの移行を実行します。Oracle ASMを使用して、新しいストレージのすべてのディスクを追加し、既存のストレージからすべてのディスクを削除できます。Oracle ASMは、データベースが稼働したままの状態で、自動的にデータのリバランスを行い、新規ストレージに移行します。既存のストレージ・デバイスを削除する前に、リバランスが完了したかどうか確認してください。

高度な手順は次のとおりです。

1. 新しいストレージを既存のシステムに接続して構成します。

2. Oracle ASMコマンドを使用して、新しいストレージをOracle ASMに追加し、元のストレージをOracle ASMから削除します。

3. データを新しいストレージに移動するOracle ASMリバランス操作の完了を待ちます。

4. 元のストレージ・デバイスを切断します。

関連項目:
『Oracle Automatic Storage Management管理者ガイド』

5.1.4.3 オンライン・データ・ファイルの再配置によるOracle ASMの移行

ALTER DATABASE MOVE DATAFILE SQL文を使用して、データファイルをASMに再配置する方法の詳細は、5.2.1項「オンライン・データファイルの名前変更と再配置」を参照してください。

5.1.5 単一インスタンス・システムからOracle RACクラスタへのデータベースの移行

単一インスタンスのOracle Databaseが実行している非クラスタ・システムからOracle RACが実行しているクラスタ環境への移行時にData Guardを使用します。スイッチオーバーを実行するのに必要な時間は発生する停止時間のみです。

関連項目:
MAAホワイト・ペーパー『高速Oracle RACスタンバイ・デプロイメント』(http://www.oracle.com/goto/maa)

5.2 動的およびオンライン・リソース・プロビジョニング

システムおよびデータベースの変更には、次の各項で説明する動的リソース・プロビジョニング機能を使用します。

- オンライン・データファイルの名前変更と再配置

- データベースの動的再構成

- メモリー管理の自動チューニング

- データ・ファイル、制御ファイルおよびログ・ファイルの分散の自動化

5.2.1 オンライン・データファイルの名前変更と再配置

すべてのデータファイルは、オンライン(使用可能)またはオフライン(使用不可能)のいずれかです。個々のデータ・ファイルまたは一時ファイルの可用性は、ファイルをオフラインにするか、オンラインにして変更できます。オフラインのデータファイルには、ファイルが再びオンラインになるまでアクセスできません。

Oracle Database 12cリリース1(12.1)から、SQLを使用して、データベースがオープンで、ファイルにアクセスしている間に、オンライン・データ・ファイルを1つのフィジカル・ファイルから別のファイルへ移動できます。

ALTER DATABASE MOVE DATAFILE SQL文を使用して、オンライン・データファイルの名前変更や再配置が可能です。この文を使用すると、データベースのオープン時にユーザーがデータ・ファイルにアクセスしている際、データ・ファイルを名前変更または再配置できます。

オンライン・データファイルを名前変更または再配置すると、データベースの制御ファイルに記録されている、データファイルへのポインタが変更されます。ファイルはオペレーティング・レベルでも物理的に名前の変更や再配置が行われます。

次のいずれかのタスクを実行する場合、ユーザーがデータファイルにアクセスできるようにする必要があるため、オンライン・データファイルを名前変更または再配置することができます。

- あるタイプの記憶域から別のタイプの記憶域に、データファイルを移動します。

- 頻繁にアクセスしないデータファイルを、より低コストの記憶域に移動します。

- 表領域を読取り専用にし、そのデータファイルを1回のみ書込み可能な記憶域に移動します。

- データベースをOracle Automatic Storage Management (Oracle ASM)に移動

- データフェイルの名前をより説明的な名前に変更

関連項目:
オンライン・データ・ファイルの名前の変更または再配置方法に詳細は、『Oracle Database管理者ガイド』を参照してください。

5.2.2 データベースの動的再構成

Oracleでは、サービスを中断することなく、ハードウェアの要求の変化に適応できるように、データベースの動的再構成のサポートを継続的に拡大しています。

Oracle Clusterwareのオンラインでのリソース属性の変更を使用すると、リソースの特定の属性を変更でき、変更を有効にするためにリソースを再起動する必要がありません。オンラインでのリソース属性の変更は、SRVCTLおよびCRSCTLコマンドを使用すれば可能です。

Oracle Databaseは、ハードウェアおよびデータベース構成への様々な変更に対して、次の機能を提供して動的に対応します。

- 対称型マルチプロセッシング(SMP)サーバーからのプロセッサの追加および削除

- Oracle RAC環境でのノードとインスタンスの追加および削除

- 自動共有メモリー管理を使用した、共有メモリーの割当ての動的な拡張と縮小、およびオンラインでのメモリーのチューニング

- データベース・アクティビティに影響しない、Oracle ASMを使用したオンラインによるデータベース・ディスクの追加および削除

- データベース・アクティビティに影響しない、Oracle ASMを使用したオンラインによるストレージ・アレイまたはExadataセルの追加および削除脚注1

- 停止時間なしで、Quarter Rack、Half Rack、Full Rackへのアップグレード、およびMultiple Full Rackまでのすべての方法により、Exadataシステムを拡張

- Oracle ASMを使用したデータベース・ストレージ全体のI/Oロードの自動リバランス

- ストレージ構成が変更するたびに自動的にデータベース・ストレージのリバランスを行う、Oracle ASMを使用したディスクの追加または削除時のオンラインによるデータ・ファイルの移動

- リソース・マネージャのコンシューマ・グループおよびプランを使用して、データベース・セッション・リソース使用量を動的に制御

- 次のいずれかのSQL*Plus文を使用することで、インスタンスを停止せずに、ほとんどすべての初期化パラメータを変更

- ALTER SESSION文は、セッション中にパラメータの値を変更します。

- ALTER SYSTEM文は、インスタンスの期間中、インスタンスのすべてのセッションでパラメータの値を変更します。

これらの機能により、エンタープライズ・グリッド・コンピューティングの基本要件であるシステム変更およびキャパシティ・オンデマンド・プロビジョニングがコストなしで実現されます。

関連項目:
自動メモリー管理をサポートするプラットフォームの詳細は、『Oracle Database管理者ガイド』を参照してください。

5.2.3 メモリー管理の自動チューニング

2つのメモリー管理初期化パラメータ、MEMORY_TARGETとMEMORY_MAX_TARGETは、システム・グローバル領域(SGA)、プログラム・グローバル領域(PGA)およびOracle Databaseの実行に必要なその他のメモリーの自動管理を可能にします。

MEMORY_MAX_TARGETパラメータは、MEMORY_TARGETの動的な最大値を指定します。

表5-5 MEMORY_MAX_TARGETおよびMEMORY_TARGET

条件

2つ目の条件

結果

MEMORY_MAX_TARGETを省略する

MEMORY_TARGETを省略する

初期化パラメータはデフォルト値(0)のままで、Oracle Databaseでは、メモリーは自動的にチューニングされません。

MEMORY_MAX_TARGETを省略する

MEMORY_TARGETの値を含める

データベースでは、MEMORY_MAX_TARGETがMEMORY_TARGETの値に自動的に設定されます。

MEMORY_TARGETを省略する

MEMORY_MAX_TARGETの値を含める

MEMORY_TARGETパラメータがデフォルトでゼロになります。

Oracle Databaseでは非集中型ポリシーを使用して、SGAおよびPGAの各サブコンポーネントのメモリーを解放して取得します。また、メモリーのグラニュルをあまり必要としないコンポーネントから、より必要とするコンポーネントに転送するようオペレーティング・システムに要求することにより、メモリーを自動的にチューニングします。メモリー転送の粒度は、現在の空きメモリーと、サービスに支障のない基本レベルを維持するためにオペレーティング・システムが必要とするメモリー量によって決まります。

注意:
MEMORY_TARGETおよびMEMORY_MAX_TARGET初期化パラメータを使用する自動メモリー管理は、Linux、Windows、Solaris、HP-UXおよびAIXでサポートされます。サポートされるすべてのプラットフォームの詳細は、『Oracle Database概要』および『Oracle Database管理者ガイド』を参照してください。

5.2.4 データ・ファイル、制御ファイルおよびログ・ファイルの分散の自動化

Oracle ASMでは、使用可能なディスク全体にデータ・ファイル、制御ファイルおよびログ・ファイルを自動的に分散します。ディスク、Exadataセルまたはストレージ・アレイの追加と削除など、ストレージ構成に変更があった場合に、データベース・ストレージのリバランスが行われます。Oracle ASMは、データベース・ファイルのミラー化を通じて冗長性を提供するとともに、使用可能なすべてのディスクにわたりデータベース・ファイルを自動的にストライプ化することにより最適なパフォーマンスを提供します。

関連項目:
Oracle ASMの詳細は、次のマニュアルを参照してください。

- Oracle Database概要

- 『Oracle Automatic Storage Management管理者ガイド』

5.3 オンライン再編成および再定義

可用性および管理性を強化する1つの方法として、データの再編成操作中、データベースへの通常のアクセス権をユーザーに与えます。Oracle Databaseのオンライン再編成および再定義機能により、管理者は、データベースへの通常のアクセス権をユーザーに与えたまま、表の物理属性を変更したり、データおよび表構造の両方を変換したりするなど多くの柔軟性が得られます。この機能によって、データの可用性、問合せのパフォーマンス、レスポンス時間およびディスク領域の使用率が向上します。これらは、すべてミッションクリティカルな環境において重要で、アプリケーションのアップグレード・プロセスをより簡単、安全かつ高速なものにします。

オンライン再編成および再定義アーキテクチャには次のような利点があります。

- オンラインの表編成および再定義:

- 表の物理属性をオンラインで変更します(新しい場所への表の移動、表のパーティショニング、1つの構成(ヒープ構成など)から別の構成(索引構成など)への表の変換、およびデータ圧縮(高度な行圧縮)の有効化など)。

- 名前、型、サイズなどの多くの論理属性を変更します。列を追加、削除またはマージできます。ただし、表の主キーは変更できません。

- REDEF_TABLEプロシージャは、1つのコマンドで1つの表のオンライン表再構成を自動化します(Oracle Database 12cでの新機能)。

- 未使用の列をオンラインに設定します(Oracle Database 12cでの新機能)。

- オンライン索引操作:

- 索引をオンラインで作成し、それらを同時に分析します。論理ROWIDの物理的推測コンポーネント(索引構成表の2次索引およびマッピング表で使用)のオンライン修復も使用できます。

- 索引構成表および2次索引をオンラインで再編成して、再編成のメンテナンス・ウィンドウを排除できます。2次索引は、ブロック・ヒント(物理的推測)の効率的な使用をサポートします。索引編成表で2次索引に格納される論理ROWIDの無効な物理的推測のオンライン修復も実行できます。

- 2次索引を再構築せずに索引構成表または表パーティションを再編成できるため、再編成のメンテナンス期間が短縮されます。

- Oracle Database 12cの新機能には、オンラインでの索引の削除、索引の表示可能/不可視の変更、オンラインでの索引使用禁止の変更、およびオンラインでの制約の削除があります。

- パーティション化された表のオンライン移動

- 高度な圧縮オプションのライセンスを所有している場合は、基本圧縮、高度な行圧縮、およびオンラインのパーティションに対するハイブリッド列圧縮が可能。

- アドバンスト・キュー、クラスタ表、マテリアライズド・ビューおよび抽象データ型(オブジェクト)に対するオンラインで再編成のサポート

- デフォルト値による高速なADD COLUMN操作(すべての行をデフォルト値に更新する必要はありません)

- 不可視の索引によるアプリケーションの移行とテストの高速化

- 明示的なヒントで移行の速度を上げ、終了したらヒントを削除します。

- 新しく作成された索引の早まった使用を防止します。

- 必要に応じて、索引を可視化してDROP INDEXの影響をテストするため、索引の再構築は必要ありません。

- DML操作の実行を中断しない索引のオンライン作成(DMLの排他ロックは不要)

- オンラインでの表DDL操作の簡略化(停止ではなく、アクティブなDML操作を待つオプション)

- 複数のパーティションを再定義する完了時間を短縮するための、単一の再定義セッションでの複数のパーティションの再定義(Oracle Database 12cの新機能)。

- これらの表の再定義の停止時間をなくすための、定義された仮想プライベート・データベース(VPD)ポリシーのある表の再定義(Oracle Database 12cの新機能)。

- 最適化されたマテリアライズド・ビュー・ログの処理によるSYNC_INTERIM_TABLEパフォーマンスの向上(Oracle Database 12cの新機能)。

- 最適化されたマテリアライズド・ビュー・ログの処理によるFINISH_REDEF_TABLEパフォーマンスの向上(Oracle Database 12cの新機能)。

物理表属性の変更、およびデータと表構造の両方を変換する機能は、Oracle8iリリース以降に使用可能になりました。データ再編成の機能を表5-6に包括的に示します。

表5-6 各リリースの新規データ再編成機能

機能

Oracle Database 9i

Oracle Database 10gリリース1

Oracle Database 10gリリース2

Oracle Database 11g

Oracle Database 12c

パッケージDBMS_REDEFINITIONを使用したオンライン再編成

表記憶域パラメータの変更

異なる表領域への表の移動

パラレル問合せのサポートの追加

パーティション化サポートの追加または削除

表の再作成による断片化の回避

表から索引構成表への変更、またはその逆

列の追加または削除

関数を使用した列の変換

権限、制約およびトリガーのクローニング

LONGからLOBへの変換

一意キーを使用した再編成

表順序の基準となる列の指定

単一のパーティションの再編成

アドバンスト・キューおよびクラスタ表

ADTを含んだ表

統計の保存およびクローニング

チェック制約およびNOT NULL制約

ネストした表の依存オブジェクトのコピー

マテリアライズド・ビュー・ログやマテリアライズド・ビューを含む表

再定義が論理的にオブジェクトに影響を与えない場合、依存オブジェクトの再コンパイルは不要

複数パーティションの再定義完了にかかる時間を短縮するための、単一の再定義セッションでの複数パーティションの再定義。

表の再定義に対する停止時間をなくすために、Oracle Virtual Private Database (VPD)ポリシーが定義されている表の再定義。

オンラインでの索引の削除(リリース10gおよび11gでの索引のオンライン作成/再構築)

索引の表示可能/不可視の変更、オンラインでの索引使用禁止の変更

オンラインでの制約の削除(リリース11 gのオンラインでの制約作成)

オンラインでの未使用列の設定(リリース11gのオンラインでの列の追加)

パーティションのオンラインでの移行(内部的にオンライン再定義を利用)

単一セッションでのオンライン、複数パーティションの再定義

Oracle Virtual Private Databseポリシーを含む表のオンライン再定義

新しいREDEF_TABLEプロシージャを使用した単一コマンドの再定義

エディションベースの再定義の拡張

未使用領域の再利用

適用不可

次の文でSHRINK SPACE句を使用:

ALTER TABLE

ALTER INDEX

ALTER MATERIALIZED VIEW

ALTER MATERIALIZED VIEW LOG

適用不可

適用不可

適用不可

オンラインでの索引の作成

CREATE INDEX emp.ename.idx ON emp(ename) ONLINE;

- パラレル操作をサポート

- パーティションをサポート

- クラスタを除くすべての索引タイプ

適用不可

適用不可

DMLをロックしないオンライン索引作成(ワークロードに依存しない透過的な作成が可能)

適用不可

オンラインでの索引の結合

ALTER INDEX emp.ename_idx COALESCE;

- パラレル操作をサポート

- パーティションをサポート

- すべての索引タイプ

適用不可

適用不可

適用不可

適用不可

オンラインでの索引構成表の移動

ALTER TABLE emp MOVE ONLINE;

- パラレル操作はサポート対象外

- パーティションをサポート

- 索引構成表のみ

適用不可

適用不可

適用不可

適用不可

関連項目:
『Oracle Database管理者ガイド』

5.4 システムおよびソフトウェア・メンテナンス用Oracle高可用性ソリューション

Oracleでは、あらゆるタイプの計画メンテナンスに対して停止時間を防止、許容および短縮するための高可用性ソリューションを提供しています。表5-7および表5-8では、計画停止時間用の各種Oracle高可用性ソリューション、および各ソリューションで達成可能な停止時間について説明しています。

どのような場合でも、計画メンテナンス操作を実行する前に広範囲なテストを行うことをお薦めします。個々のOracle高可用性アーキテクチャの計画停止時間タイプすべての達成可能なリカバリ時間に関する概要は、第7章「高可用性アーキテクチャ」の表を参照してください。

表5-7 システムおよびソフトウェア・メンテナンス用Oracle高可用性ソリューション

メンテナンス・タイプ

推奨されるOracleソリューション

ソリューションの説明

停止時間

オペレーティング・システムおよびハードウェアのアップグレード

Oracle Real Application ClustersおよびOracle Clusterware、Oracle RAC One NodeまたはData Guard Standby-First Patchの適用

5.4.1項「オペレーティング・システムのアップグレードおよびハードウェアのアップグレード」

Oracle RACおよびOracle RAC One Nodeの場合停止時間ゼロ。

Standby-First Patchの適用の場合数秒から数分

Oracle仮パッチまたは診断パッチ

Oracle Real Application ClustersおよびOracle Clusterware、Oracle RAC One Nodeまたはオンライン・パッチ

5.4.2項「オンライン・パッチ」

停止時間ゼロ脚注1

Oracle DatabaseおよびOracle Grid Infrastructureバンドル・パッチ、パッチ・セット・アップデート(PSU)、クリティカル・パッチ・アップデート(CPU)

Data Guard Standby-First Patchの適用、Oracle Real Application ClustersおよびOracle ClusterwareまたはOracle RAC One Node

5.4.3項「Data Guardを使用したシステムおよびクラスタのアップグレード」

Standby-First Patchの適用の場合数秒から数分

Oracle RACおよびOracle RAC One Nodeの場合停止時間ゼロ

Oracle DatabaseおよびOracle Grid Infrastructureパッチ・セット(Oracle Database 11.2.0.2または11.2.0.3など)およびメジャー・アップグレード(Oracle Database 11.2から12.1など)

Oracle Data Guard

5.4.8項「Data Guardを使用したDatabaseのローリング・アップグレード」

数秒から数分

Exadata Storageのアップグレード

Exadata PatchMgrユーティリティ

5.4.7項「Exadata Storage Serverソフトウェアのローリング・アップグレード」

停止時間ゼロ

アプリケーションのアップグレード

アプリケーションのオンライン・メンテナンスおよびオンライン・アップグレード

5.5項「アプリケーションのオンライン・メンテナンスおよびオンライン・アップグレード」

停止時間ゼロ

脚注1ローリング・アップグレードの実行で適用できないパッチは、パッチ適用による可用性の影響が少ないOPatchユーティリティのMINIMIZE_DOWNTIMEオプションで適用できます。

表5-8 MAA参照アーキテクチャおよびマルチテナント・アーキテクチャの計画メンテナンス・マトリックス

イベント

Bronze、Silver、GoldおよびPlatinumサービス・レベル層のソリューション

予想される停止時間

移行

関連項目: http://www.oracle.com/technetwork/database/availability/maa-consolidation-2186395.pdfのMAAホワイト・ペーパー『データベース統合の高可用性ベスト・プラクティス: Database-as-a-Serviceの基盤』のマルチテナント・アーキテクチャの移行に関する項

状況により異なる

動的およびオンライン・リソース・プロビジョニングまたは

オンライン再編成および再定義

すべての層: それぞれのPDB内で選択されたオブジェクトのオンライン再編成および再定義

関連項目: 5.2項「動的およびオンライン・リソース・プロビジョニング」および5.3項「オンライン再編成および再定義」

ゼロ

オンライン・パッチ

すべての層: 関連している場合は、CDB全体のオンライン・パッチ適用が可能

ゼロ

データベースおよびグリッド・インフラストラクチャのパッチおよび個別パッチ

すべての層: PDBを切断して、ソフトウェア・リリースがターゲット対象である別のCDBに接続可能

SILVER: 関連する場合は、CDB全体で、Oracle RAC One Nodeのローリング・アップグレードを使用可能

GOLD/PLATINUM: 関連する場合は、CDB全体で、Oracle RACのローリング・アップグレードを使用可能。PLATINUM層には、アプリケーション・コンティニュイティも追加されます。

GOLD: CDB全体で、Data Guard Standby-First Patch適用を使用でき、Data Guardスイッチオーバーを発行可能

PLATINUM: CDB全体で、Data Guard Standby-First Patch適用を使用でき、Data Guardスイッチオーバーとアプリケーション・コンティニュイティを発行可能

データファイル・コピー・オプションがない場合、予想される時間は数秒から数時間

サービスの再配置によりゼロ

サービスの再配置によりゼロ

アプリケーションの停止なし

数秒から数分

アプリケーションの停止なし

データベース・パッチセット

すべての層: PDBを切断して、ソフトウェア・リリースがターゲット対象である別のCDBに接続可能

GOLD/PLATINUM: パッチセットおよびデータベースのメジャー・リリースに対して、CDB全体で、Data Guardデータベース・ローリング・アップグレードを使用可能

PLATINUM: ターゲットのソフトウェア・バージョンに存在するセカンダリGoldenGateレプリカに、CDBまたはPDBをフェイルオーバー可能

データファイル・コピー・オプションがない場合、予想される時間は数秒から数時間

数秒から数分

停止時間ゼロ

アプリケーションのアップグレード

PLATINUM: エディションベースの再定義は、この機能を利用するために、開発者による設計が必要

PLATINUM: ターゲット・アプリケーションを変更すれば、PDBをGoldenGateレプリカにスイッチオーバー可能

関連項目: 5.5項「アプリケーションのオンライン・メンテナンスおよびオンライン・アップグレード」

ゼロ

移動サービスにより、停止時間はゼロからほぼゼロ

関連項目:

- SQL ApplyでData Guardを使用してOracle Databaseをアップグレードするには、『Oracle Data Guard概要および管理』を参照してください。

- ローリング・アップグレードのベスト・プラクティスに関するMAAホワイト・ペーパーは、次のWebサイトから入手できます。

http://www.oracle.com/goto/maa

5.4.1 オペレーティング・システムのアップグレードおよびハードウェアのアップグレードs

システムとハードウェアのアップグレード時の停止時間を回避するには、Oracle RACを使用するソリューションをお薦めします。単一インスタンスOracle RACデータベースの場合は、Oracle RAC One Nodeを使用できます。

5.4.3項に示すように、Oracle RACまたはOracle RAC One Nodeを使用してアップグレードを実行できない場合は、Data Guardとフィジカル・スタンバイ・データベースを使用するソリューションをお薦めします。もしくは、5.4.5項に示すように、Oracle Clusterwareを使用したコールド・クラスタ・フェイルオーバーを使用することもできます。

次のリストに、Oracle RACを使用してアップグレードする場合の手順の高レベルの概要を示します。

1. 次の前提条件チェックを実行します。

- 計画メンテナンスがオペレーティング・システムの観点からローリング形式で行うことができるかどうかを確認します。

- データベースとクラスタウェアのバージョンが、新規システムおよびハードウェアの変更で動作保証されているかどうかを確認します。

2. クラスタ内の複数のインスタンスでアプリケーション・サービスが稼働している場合は、アプリケーション・サービスを停止します。アップグレード対象のインスタンスのみでアプリケーション・サービスが稼働している場合は、クラスタ内の別のノードにサービスを再配置します。
高速アプリケーション通知(FAN)を使用している場合、アプリケーション・サービスを停止すると、接続が接続先インスタンスから暗黙的にリダイレクトされます。

3. IMMEDIATEオプションを指定して接続先インスタンスを停止します。

4. Oracle Clusterwareを停止して無効にします。
Oracle Clusterwareを無効にすると、自動起動しなくなります。

5. メンテナンスを実行します。

6. Oracle Clusterwareを有効にして、起動します。
この手順により、データベース・インスタンスが暗黙的に起動されます。

7. アプリケーション・サービスを起動します。
この手順により、FANを使用している場合、接続先インスタンスに接続が暗黙的にリダイレクトされます。

8. 次のノードですべての手順を繰り返します。

使用しているオペレーティング・システム別のOracle Real Application Clustersのインストレーション・ガイドを参照してください。

5.4.2 オンライン・パッチ適用

通常、仮パッチおよび診断パッチは、ローリング方法で一度に1つのノードに適用されます。ソフトウェア・ホームへのパッチの適用中、ホームから実行中のソフトウェア(データベース・インスタンスなど)はシャットダウンされます。ただし、パッチを緊急にインストールする必要があり、現時点でシャットダウンできない場合には、ソフトウェアが実行中のまま、適格な仮パッチおよび診断パッチをオンラインで適用できます。

次の場合にのみ、パッチをオンラインで適用してください。

- パッチのREADMEには、オンラインで適用できることが記載されています。

- パッチはすぐに適用する必要がありますが、通常(オフライン)バージョンのパッチを適用する場合は、データベース・インスタンスを停止できません。

OPatchコマンドライン・ユーティリティを使用してOracleデータベースでオンライン・パッチ適用を実行できます。

オンライン・パッチを実行するときは、次の点に注意してください。

- オラクル社では、正規の個別または診断パッチをコンボ・パッチとして提供しており、同じバグ修正でオンライン・パッチとオフライン・パッチの両方が含まれています。
そのため、このオンライン・パッチを最初に適用すると、計画外停止時間を回避できます。ただし、オンライン・パッチではメモリーのオーバーヘッドが発生するため、計画停止時にオンライン・パッチをロールバックしてオフライン・パッチを適用する必要があります。

- オンライン・パッチを適用すると、各Oracleプロセスではパッチの適用時にプログラム・グローバル領域(PGA)のメモリーを多く使用するため、システムのメモリー消費が増加します。オンライン・パッチを適用する前に、メモリー要件を考慮してください。各オンライン・パッチは独自のものであり、メモリー要件はパッチごとに異なります。パッチをまずテスト・システムに適用することで、本番システムでのオンライン・パッチの効果を評価し、追加のメモリー使用量を予測できます。

関連項目:

- My Oracle Supportのノート761111.1「RDBMSオンライン・パッチAkaホット・パッチ」
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=761111.1

- オンラインでのパッチ適用とOPatchユーティリティの詳細は、Oracle Universal Installer NextGenインストレーション・ガイドを参照してください。

- ローリング・アップグレードおよびローリング・パッチの概要は、『Oracle Databaseアップグレード・ガイド』を参照してください。

5.4.3 Data Guardを使用したシステムおよびクラスタのアップグレード

Data Guardとフィジカル・スタンバイ・データベースは、Oracle RACローリング・アップグレードを使用してアップグレードできないシステムとクラスタのアップグレード(Oracle Grid Infrastructureのアップグレードなど)を実行する場合に推奨されるソリューションです。

Data Guardは、Oracle ASM、Oracle RACおよび64ビット・システムへの移行、WindowsとLinux間での移行、あるいは同じプロセッサ・アーキテクチャのプラットフォームへの移行にも推奨されます。次に例を示します。

- システムの制限によりOracle RACのローリング・アップグレードを使用してアップグレードできないシステム・アップグレードには、Data Guardを使用します。

- Oracle ASMへの移行、クラスタ化されていない環境からOracle RACへの移行、同じエンディアン形式の別のプラットフォームへの移行、または同じプロセッサ・アーキテクチャの別のプラットフォームへの移行を行う場合、Data Guardを使用します。スイッチオーバーを実行するのに必要な時間は発生する停止時間のみです。詳細は、My Oracle Supportのノート413484.1の「同一Data Guard構成の異機種間プライマリ・スタンバイおよびフィジカル・スタンバイに関するData Guardのサポート」を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=413484.1

通常、フィジカル・スタンバイ・データベースが実行されているシステムまたはクラスタを最初にアップグレードしてから、フィジカル・スタンバイ・データベースに対してData Guardスイッチオーバーを実行します。データベース・ソフトウェアがアップグレードされている場合は、5.4.4.2項「Data Guardを使用したローリング・パッチ・インストール」を参照してください。

5.4.3.1 フィジカル・スタンバイ・データベースのアップグレード

フィジカル・スタンバイ・データベースのアップグレードおよびスイッチオーバーの実行手順:

1. システムをアップグレードするか、またはフィジカル・スタンバイ・データベース・システムを移行先環境に変更します。
たとえば、Oracle ASMを使用して、スタンバイ・データベースを単一インスタンス・データベースからOracle RACデータベースに変換できます。プライマリ・データベースへの影響はありません。次に、スタンバイ・データベースを再起動し、これが移行先環境に合っているかどうかを確認して、REDO Applyによるスタンバイ・データベースへのREDOデータの適用が終わるまで待機します。

2. Data Guardスイッチオーバーの実行。最適なスイッチオーバーの所要時間は、数秒から数分程度です。

3. 元のプライマリ・データベースを停止します(これでスタンバイ・データベースになる)。

4. アップグレードするか、元のプライマリ・データベースへのシステム変更を行います。

5. スタンバイ・データベースとしてアップグレードしたデータベースを再起動し、リカバリでデータベースを自動的に同期化します。

6. 必要に応じて、Data Guardスイッチオーバーを実行して、スタンバイ・データベースをプライマリ・データベース・ロールに戻します。

注意:
Oracle Databaseパッチ・セットの適用またはOracle Databaseのアップグレードを同時に行う場合、32ビットから64ビットへの変換は自動的に行われます。オペレーティング・システムのみをアップグレードする場合は、My Oracle Supportのノート414043.1(http://support.oracle.com/)に記述されている追加のアップグレード後の手順を実行する必要があります。アップグレードの詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。

5.4.3.2 システムおよびクラスタのアップグレードのベスト・プラクティス

システムおよびクラスタのアップグレードと移行では、次のベスト・プラクティスおよびガイドラインを考慮します。

- スイッチオーバーを高速化するには、スタンバイ・データベースでリアルタイム適用が使用されるように構成し、できれば、アーカイブ・ログ・ギャップが存在しないように、スイッチオーバー操作の開始前にデータベースがほとんど同期化されているようにします。

- Oracle RACローリング・アップグレードまたはオンライン・パッチを使用できない場合は、Data Guardおよびフィジカル・スタンバイ・データベースを使用して、システムおよびクラスタのアップグレードを実行します。詳細は、『Oracle Data Guard概要および管理』を参照してください。

5.4.4 Oracle Real Application Clustersを使用したパッチ適用およびローリング・アップグレード

通常、データベース・ソフトウェアへのOracleパッチは、ソフトウェアの問題に対する既知の修正を実装するため、または診断パッチを適用して問題に関する情報を収集するために適用します。アップグレードやパッチ適用は、スケジュールされたメンテナンス期間中に実行するよう計画してください。ビジネス・ニーズに最適なローリング・パッチ適用または非ローリング・パッチ適用のオプションを使用してください。

パッチには複数の種類があります。

- 個別パッチ
個別パッチは、Exadataの後続のパッチ・セット・リリースまたはデータベース・パッチより前に修正が必要なユーザーに提供されるバグ修正です。個別パッチのインストールは必要に応じて行われるため、定期的にスケジュールされる計画メンテナンス・イベントではありません。

- バンドル・パッチ
パッチ・セット間で発行されるパッチを集めたもの。パッチ・バンドルは通常は累積されます。Oracle Database用のMicrosoft Windowsバグ修正は、通常は個別パッチではなくパッチ・バンドルで発行されます。

- パッチ・セット
パッチ・セットには主にバグ修正が含まれますが、小規模な新機能や機能変更が含まれる場合もあります。

- パッチ・セット更新(PSU)
該当製品の最重要の修正を含む四半期ごとのパッチ(セキュリティ修正を含む)で、1つのパッチを適用して多くの問題を解決できます。

- クリティカル・パッチ・アップデート(CPU)
四半期ごとに提供される優先度の高い修正(通常はセキュリティ上の問題)を集めたもの。CPUは、セキュリティの事前修正の観点から累積されますが、セキュリティ以外のパッチ(マージ・リクエストの必要性を軽減)と競合するパッチに対処できるように他の修正が含まれる場合があります。

- 診断パッチ
バグの修正ではなく、問題の診断に限定して作成されるパッチ。

5.4.4.1 Oracle Real Application Clustersを使用したローリング・パッチ・インストール

Oracleデータベース・パッチを適用する際に停止時間を回避するには、Oracle RACを使用してローリング・パッチ・アップグレードを実行します。Oracle RACを使用するとパッチの約90%を適用できます。Oracleには、OPatchコマンドライン・ユーティリティを使用した、データベースの停止時間がほとんどないかゼロの、Oracle RACを使用したローリング・パッチのアップグレードを行う機能があります。Oracle RACを使用できない場合は、Data Guardおよびフィジカル・スタンバイ・データベースを使用します。詳細は、5.4.3項を参照してください。

Oracle RACのローリング・アップグレードでは、計画停止の間、Oracle RACデータベースのインスタンスを、1つを除いてすべて使用できるため、計画メンテナンスに必要なアプリケーション停止時間に対する影響はさらに減少します。OracleのOPatchユーティリティを使用すると、Oracle RACデータベースの異なるインスタンスに対してパッチを連続的に適用できます。

ローリング・アップグレードの実行は、ローリング・アップグレード用に認可されているパッチの場合のみ可能で、それについてはREADMEに記載されています。

関連項目:
アプリケーションを中断せずに、ローリング・パッチを正常に適用する手順は、My Oracle Supportのノート1593712.1 (http://support.oracle.com)を参照してください。

5.4.4.2 Data Guardを使用したローリング・パッチ・インストール

ローリング方式での更新の適用にOracle RACを使用できない場合は、Data Guardおよびフィジカル・スタンバイ・データベースを使用します。Data Guard Standby-First Patchの適用では、ローリング方式でOracleパッチを適用および検証する目的で、プライマリ・データベースとそのフィジカル・スタンバイ・データベース間で、異なるパッチ・セット更新(PSU)、バンドル・パッチまたは個別パッチを使用できます。

ターゲット・パッチがData Guard Standby-Firstのインストール対応と認定されているかどうかを判断するには、パッチのREADMEを確認してください。

関連項目:

- Oracle Data Guard Standby First Patchの適用の詳細は、My Oracle Supportのノート1265700.1 (http://support.oracle.com)を参照してください。

5.4.5 Oracle Clusterwareを使用したローリング・アップグレード

Oracle Clusterwareのアップグレード時の停止時間を回避するには、Oracle Clusterwareのローリング・アップグレードを実行するソリューションをお薦めします。単一インスタンスOracle RACデータベースの場合は、Oracle RAC One Nodeの使用を検討してください。

ローリング・アップグレードでは、停止時間が回避され、ソフトウェアが新しいバージョンにアップグレードされる間、Oracle Clusterwareの連続的な可用性が確保されます。Oracle Clusterware 12cにアップグレードすると、Oracle ClusterwareおよびOracle ASMバイナリは、グリッド・インフラストラクチャという単一バイナリとしてインストールされます。Oracle Clusterwareをローリング方式でOracle Clusterware 10gおよびOracle Clusterware 11gからアップグレードできます。

Oracle Clusterwareへのアップグレードはすべて、ローリング方式で実行できます。

関連項目:

- 使用するオペレーティング・システム別のOracle Clusterwareのインストレーション・ガイド

- 使用するオペレーティング・システム別のOracle Real Application Clustersのインストレーション・ガイドを参照してください。

5.4.6 Oracle Automatic Storage Managementを使用したローリング・アップグレード

Oracle ASMのアップグレードには、ローリング・アップグレードの実行をお薦めします。Oracle Database 11g(およびこれ以降のリリース)でのアップグレードはすべて、ローリング方式で実行できます。

Oracle Clusterware 12cにアップグレードすると、Oracle ClusterwareおよびOracle ASMバイナリは、グリッド・インフラストラクチャという単一バイナリとしてインストールされます。Oracle ASMはローリング方式でOracle Database 11gリリース1 (11.1)からのみアップグレードできます。

詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

5.4.7 Exadata Storage Serverソフトウェアのローリング・アップグレード

Exadata Storage Serverソフトウェアのローリング・アップグレード中、ストレージ・サーバーには一度に1つずつ、すべてのサーバーが更新されるまでパッチが適用されます。ローリング・パッチ適用は、Oracle ASMの冗長性と自動ディスク再同期化を利用して、パッチの適用中でもデータベースが稼働し続けられるようにします。Exadata Storage Serverソフトウェアのローリング・アップグレード・オーケストレーションは、Exadata Storage Serverソフトウェアとともに提供されるPatchMgrユーティリティにより管理されます。

関連項目:

- My Oracle Supportのノート888828.1(http://support.oracle.com/)に含まれる次の資料

- Oracle Exadata Storage ServerのWebサイト(http://www.oracle.com/exadata)

5.4.8 Data Guardを使用したDatabaseのローリング・アップグレード

パッチ・セットおよびデータベースのアップグレードを最小の停止時間で実行するには、SQL Applyを使用するData Guardのソリューションをお薦めします。ソース・データベースがSQL Applyでネイティブにサポートされていないデータ型を使用している場合、拡張データ型サポート(EDS)を使用することで、対応する拡張データ型をさらにいくつか増やすことができます。

ソース・データベースが、SQL Applyのローリング・アップグレードでサポートされていないソフトウェア・バージョンを使用している場合(Oracle Databaseリリース10.1.0.3より前のリリース)、またはEDSを使用してもSQL Applyのデータ型の競合を十分に解決できない場合、Oracle Active Data Guardを使用したローリング・アップグレード、Database Upgrade Assistant(DBUA)脚注2、トランスポータブル表領域またはOracle GoldenGateの使用を検討します。

- Oracle Active Data Guardを使用したローリング・アップグレードでは、Data Guardのフィジカル・スタンバイ・データベースおよびSQL Applyプロセスを使用します。5.4.8.1項で、Oracle Active Data Guard機能を使用したローリング・アップグレードについて説明します。

- DBUAには、アップグレード・プロセスの手順を示すグラフィカル・ユーザー・インタフェース(GUI)ユーティリティが備わっており、データベースのアップグレードの方法としては最も簡単で推奨できる方法です。ただし、DBUAでデータベースのアップグレードにかかる時間が定義されたメンテナンス・ウィンドウの期間に納まらない場合は、1時間未満でデータベース・アップグレードを実行するために、トランスポータブル表領域機能の使用を検討してください。

- SQL Applyを使用できず、メンテナンス・ウィンドウで停止時間を1時間未満にする必要がある場合、およびアップグレードされるデータベースに単純なスキーマや、トランスポート・プロセスの一部として転送する必要のないデータ・ファイル(データ・ファイルが所定の場所で使用される場合など)が少ない場合には、トランスポータブル表領域を使用します。トランスポータブル表領域ソリューションについては5.4.8.3項で説明します。

- Oracle GoldenGateは、データベース・アップグレードを実行する際の最も柔軟な方法と、追加のデータ型サポートを提供します。このソリューションについては、5.4.8.4項で説明します。

Oracle RACを使用してパッチ・セットのローリング・アップグレードを実行しないでください。使用しているオペレーティング・システム別のOracle Real Application Clustersのインストレーション・ガイドを参照してください。

5.4.8.1 Data Guardおよびフィジカル・スタンバイ・データベースを使用したデータベース・アップグレードの実行

Oracle Active Data Guardを使用したローリング・アップグレードでは、新しいPL/SQLパッケージが提供され、フィジカル・スタンバイ・データベースを使用して、データベースのローリング・アップグレード(Oracle Databaseの後続のリリースまたは新しいパッチ・セットへ、または別のデータベース・メンテナンスを実行するとき)を実行する多くのプロセスを自動化します。アップグレード計画を入力すると、PL/SQLパッケージにより、その計画に従ってアップグレードの3つのフェーズ(起動、切替えおよび終了)が自動化されます。

アップグレード中、SQL Applyがすべてのバージョンにわたってスタンバイを同期させるために使用されますが、アップグレードが完了すると、Data Guard構成がプライマリ・データベースおよびフィジカル・データベースの元の状態に戻されます。

スタンバイ・データベースがアップグレード・モードでオープンされている間にプライマリ・データベースのREDOを継続して受信するために、アップグレードのターゲットであるスタンバイ・データベースを有効化することによって、Data Guardデータベースのローリング・アップグレード処理中にデータ保護が維持されます。

プロセス中にエラーが発生した場合、エラーを修正してアップグレードを再開するか、構成の元の状態に戻るかのいずれかを選択できます。これは、Oracle Database 12c リリース1(12.1)以降のデータベース・ローリング・アップグレード用にサポートされています。

Oracle Database 12cリリースには、データベース・ローリング・アップグレードをサポートするために、Data Guard SQL Apply用のREDOベースの追加のネイティブ・レプリケーションが含まれています(一時ロジカル・スタンバイ)。サポートされるデータ型には、Oracle Securefile、XML、Database File System (DBFS)、XDB、Oracle Spatial、Oracle TextおよびOracle Multimediaなどがあります。サポートされるデータ型の全リストは、『Oracle Data Guard概要および管理』の付録Cを参照してください。

Data Guardブローカもデータベース・ローリング・アップグレードをサポートします。

Oracle Database 12c以降、Oracle Enterprise Manager Cloud Control (Cloud Control)では、Data Guard構成のデータベースのローリング・アップグレードを実行するためのオプションが提供されています。手順は、Cloud Control内のオンライン・ヘルプで説明されています。

関連項目:

- サポートされるデータ型の全リストは、『Oracle Data Guard概要および管理』の付録C

- 『Oracle Data Guard Broker』

5.4.8.2 データ・ポンプの全体トランスポータブル・エクスポート/インポート使用のデータベース・アップグレード

フル・トランスポータブル・エクスポート/インポートを使用すると、データベースをリリース11.2.0.3以上からOracle Database 12cにアップグレードできます。そのためには、Oracle Database 12cをインストールし、空のデータベースを作成します。次に、フル・トランスポータブル・エクスポート/インポートを使用して、リリース11.2.0.3データベースをOracle Database 12cデータベースにトランスポートします。

手順の概要は、5.1.1.2.2項「データ・ポンプの全体トランスポータブル・エクスポート/インポート」を参照してください。

データのトランスポートの一般的な制限および全体トランスポータブル・エクスポート/インポート特有の制限については、『Oracle Database管理者ガイド』を参照してください。

5.4.8.3 トランスポータブル表領域を使用したデータベース・アップグレードの実行

データ型が競合するためにSQL Applyを使用できず、テストの結果、DBUAでのアップグレードが稼働時間の要件を満たせないことがわかる場合、トランスポータブル表領域ソリューションを利用したデータベースのアップグレードを検討してください。

トランスポータブル表領域機能を利用してOracle Databaseをアップグレードするには、次の手順に従います。

1. トランスポート先システムにOracle Databaseソフトウェアをインストールし、ソース・データベースで最初の手順を実行し、トランスポート・プロセスの準備をします。

2. ソースおよびトランスポート先データベースを準備します。

1. ソース・データベースから情報を収集します。

2. Database Configuration Assistant(DBCA)でトランスポート先データベースを作成します。

3. Oracle Data Pump使用のためと、トランスポートされる表領域を受け入れるために、トランスポート先データベースの準備をします。

3. 次の手順でユーザー表領域をトランスポートします。

1. ユーザーを切断し、ソース・データベースへのアクセスを制限することで、ソース・データベースのトランスポートの準備をし、すべてのユーザー表領域をREAD ONLYにして、ソース・データベースから順序の開始値を取得します。

2. ユーザー表領域をトランスポートします。

4. トランスポート先データベースが完全であり機能することを確認した上でバックアップします。

トランスポータブル表領域の機能を使用する場合、次の点を考慮してください。

- トランスポータブル表領域機能は、単純なスキーマを持ち、トランスポート・プロセスの一部としてデータ・ファイルを転送する必要がない(データ・ファイルが所定の場所で使用される場合など)データベースに対して、1時間未満でデータベース・アップグレードを実行するためのオプションです。次のWebサイトにあるMAAホワイト・ペーパー「Database Upgrade Using Transportable Tablespace」を参照してください。
http://www.oracle.com/goto/maa

- トランスポータブル表領域機能を使用すると、以前のリリースのソフトウェアが稼働するデータベースから、現行リリースのソフトウェアが稼働する空のトランスポート先データベースに、すべてのユーザー表領域を移動することにより、データベースのアップグレード時間が短縮されます。トランスポータブル表領域を持つ表領域データ・ファイルは、データ・ファイルをトランスポート先データベースにコピーし、オブジェクト・メタデータをトランスポート先データベースにインポートすることで、データベースに接続されます。

5.4.8.4 Oracle GoldenGateを使用したデータベース・アップグレードの実行

Oracle GoldenGateを使用してデータベースのアップグレードの停止時間を短縮します。データベースのアップグレードによる停止時間は、ソース・データベースがオンラインのままで現在のバージョンを実行して、ターゲット・データベースを新しいバージョンのアップグレードし、同期を維持することを許可することにより短縮されます。Oracle GoldenGateを使用したときに必要な停止時間は、アプリケーションがターゲット・データベースに再接続するのにかかる時間です。

高度な手順は次のとおりです。

1. 変更－同期「抽出」グループを開始して、実行中のデータの変更を抽出します。

2. 複製ターゲット・データベースを作成します。理想的な複製ターゲット・データベースは、最新のフィジカル・スタンバイ・データベースとして始まります。

3. ターゲット・データベースをターゲット・バージョンにアクティブ化してアップグレードします(または、表7-6に示すメンテナンス・アクションを実行します)。

4. 変更-同期「Replicat」グループを開始し、ターゲット・データベースの作成およびアップグレード中に変更された行を再同期します。

5. アプリケーションを停止します。

6. アプリケーションを開始し、ターゲット・データベースに接続します。

関連項目:

- オンライン・データベース・アップグレードの実行の詳細は、Oracle GoldenGateのドキュメントを参照してください。参照: http://www.oracle.com/technetwork/middleware/goldengate/overview/index.html

- Oracle GoldenGateを使用した停止時間ゼロのデータベース・アップグレード(http://www.oracle.com/technetwork/middleware/goldengate/overview/ggzerodowntimedatabaseupgrades-174928.pdf)

- データベースの複製に関する詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

5.4.8.5 Oracle GoldenGateおよびData Guardを使用したデータ・アップグレードの実行

図5-1の構成は、Data Guardデータベース・ローリング・アップグレードによりサポートされないアップグレードおよび移行などによる、停止時間および計画停止の危険性を最小限に抑えるためのOracle GoldenGateおよびData Guardの構成方法を示します。これには、異なるハードウェア・アーキテクチャおよびオペレーティング・システムへの移行、データベース・オブジェクトを変更するアプリケーション・アップグレードの実行などが含まれます。この構成では、フィジカル・スタンバイ・データベースにより、移行の前後および移行中の停止時間またはデータ損失を防く災害からの保護が提供されます。また、移行の実行に必要な作業から本番データベースを分離することにより、パフォーマンスへの影響または操作上の危険性を回避します。

図5-1 計画停止時間を最小限に抑えるためのOracle GoldenGate構成

スタンバイ・データベース(図5-1の右上)から新しい本番データベース(右下)にGoldenGateをレプリケートするには、Oracle GoldenGateアーカイブ・ログ・モードが必要です。アーカイブ・ログ・モードの要件を満たすことができない場合は、元の本番データベース(左上のデータベース)から直接レプリケートします。

スタンバイ(図5-1の左上)からの抽出は可能ですが、ALOモードでのクラシック・キャプチャが必要です。スタンバイ・データベースに対するALOの詳細は、Oracle Data Guardのドキュメントを参照してください。

http://docs.oracle.com/goldengate/1212/gg-winux/GIORA/classic_capture.htm#A1740233

これらの要件は、新しいプラットフォーム上にパラレル環境を作成することにより達成されます。計画された移行のタイプによっては、新規プライマリ・データベースのインスタンス化が、既存のスタンバイ・データベースのバックアップのリストアと同じくらい単純になる可能性があります。より複雑な移行の場合は、Oracleトランスポータブル・テクノロジやOracle Data Pumpなどの、別のOracleテクノロジを使用して新規プライマリ・データベースをインスタンス化します。インスタンス化の後、新しい本番システム上で追加の変更を実装します。すべての変更が実装されると、新規フィジカル・スタンバイ・データベースが作成され、稼働開始後の継続的なデータ保護が提供されます。Oracle GoldenGateの異機種間レプリケーション(以前に構成済)が使用されて、新しい本番システムと、新しい環境の実装中に古いシステムで発生したすべてのトランザクションが同期化されます。同期化が完了すると、本番システムは新しい環境で稼働できるようになります。また、しばらくの間、新しい本番システムと同期された古い環境を保持するために、稼働後にOracle GoldenGate異機種間レプリケーションを使用するオプションもあります。ファスト・フォールバック・オプションでは、予期せぬ問題が発生する可能性があります。

5.5 オンライン・アプリケーションのメンテナンスおよびアップグレード

アプリケーションの変更には次に示す機能を使用します。これらの機能を使用することで、アプリケーションのデータベース・オブジェクトの変更に必要なアプリケーションの停止時間を大幅に短縮する(またはゼロにする)ことができます。

- エディションベースの再定義

- ローリング・アップグレードに使用するOracle GoldenGate

- WAITオプションを使用したDDL

- CREATE TRIGGERのENABLE、DISABLEおよびFOLLOWS句

- ADD COLUMN機能の拡張

- きめ細かな依存性

- 不可視の索引

- 不可視の列

- 同じ列セットに対する複数の索引

- 表のオンライン再定義後の依存PL/SQLの再コンパイル

5.5.1 エディションベースの再定義

エディションベースの再定義(EBR)を使用すると、アプリケーションの使用中にそのデータベース・コンポーネントをアップグレードでき、停止時間を最小化あるいは排除することができます。

アプリケーションを使用中にアップグレードするには、アプリケーションを構成するデータベース・オブジェクトをコピーし、コピーしたオブジェクトを個別に再定義します。アプリケーションのユーザーは、この変更による影響を受けず、変更されていないアプリケーションを引き続き実行します。変更が正しいことを確認できたら、アップグレードしたアプリケーションをすべてのユーザーが使用できるようにします。

この後の項では、エディションベースの再定義のエディション、エディショニング・ビューおよびcrosseditionトリガーの機能について説明します。

詳細は、『Oracle Database開発ガイド』を参照してください。

5.5.1.1 エディション

エディションは非スキーマ・オブジェクトであり、所有者が存在しません。エディションは単一のネームスペースで作成され、データベース内で複数のエディションが共存できます。エディション機能を使用すると、データベース・オブジェクトをコピーし、コピーしたオブジェクトを分離して再定義できます。

データベースには少なくとも1つのエディションが必要です。新規作成またはアップグレードされたOracle Databaseはすべて、ora$baseという名前の1つのエディションから開始されます。

エディションにより、新しいコードのインストールや、データ変更を行うためのプライバシ・メカニズムが提供され、実行中の本番アプリケーションではその変更は見えません。必要な変更がすべて非公開で行われ、1つの動作で公開されます。カットオーバーはセッションが使用するエディションによってのみ決定されます。

5.5.1.2 エディショニング・ビュー

1つ以上の表の構造を変更する場合、オンライン・アプリケーション・アップグレード中に基礎となる表に加えられる変更からアプリケーション・コードを隔離するには、エディショニング・ビュー機能も使用する必要があります。表は編集できません。

基礎となる表に列が追加され、それらを公開してデータを移入するために、アップグレード後のエディションで新しいエディショニング・ビューが作成されます。

エディショニング・ビューにはトリガーを作成でき、ビューの列はSQLのヒントで使用できます。エディショニング・ビューの副問合せの定義は、選択した列の別名を推定または定義できるのみです。SELECTリストを使用して、表の列のサブセットを推定し、通常はそれらの名前を変更します。その結果、このリストにより物理列の論理列へのマッピングが定義されます。

5.5.1.3 crosseditionトリガー

crosseditionトリガーは、エディションベースの再定義の一部として使用され、アップグレード前のエディションとアップグレード後のエディションのデータが互いに一致するように保ちます。アップグレード前のアプリケーションは、変更が適用され、アップグレード前のエディションがアップグレード後のエディションに再定義されている間もそのまま使用されます。

表構造の変更中に、ユーザーが表のデータを変更できるようにするには、forward crosseditionトリガーを使用します。他のユーザーがアプリケーションの古いバージョンを使用し続けている間、アップグレード済のアプリケーションを一部のユーザーが使用できるようにするには、reverse crosseditionトリガーも使用します。crosseditionトリガーは、アップグレードしたアプリケーションをユーザー全員が使用できるようにしたら削除するか無効にするため、アプリケーションの永続的な部品ではありません。

5.5.2 ローリング・アップグレードに使用するOracle GoldenGate

高速ローリング・アップグレードにOracle GoldenGateを使用することを検討してください。ただし、Oracle GoldenGateによるアップグレードでは、データベースの停止時間を最小限またはゼロにできますが、このソリューションを構成するには、運用面での投資がある程度必要になります。必要に応じて、3.2項「Oracle GoldenGate」およびOracle GoldenGateのドキュメントを参照してください。

5.5.3 WAITオプションを使用したDDL

データ定義言語(DDL)コマンドには、内部構造で排他ロックが必要です。DDLコマンドが発行されると、これらのロックは使用できず、DDLが何秒か後に成功する場合があっても、文はすぐに失敗します。WAITオプション(新しいデフォルト)でDDLを指定すると、この問題が解決します。待機時間をインスタンス全体(初期化パラメータ・ファイル)で指定し、セッション・レベルで待機時間を変更します。

WAITオプションでDDLコマンドを指定すると、すぐにエラーが発生するのではなく、コマンドが成功するまでの猶予期間を定義する柔軟性が得られるため、このようなエラーに対処する追加のアプリケーション・ロジックが必要になります。詳細は、『Oracle Database管理者ガイド』を参照してください。

5.5.4 CREATE TRIGGERのENABLE、DISABLEおよびFOLLOWS句

状態(ENABLEおよびDISABLE)と順序付け(FOLLOWS)はトリガーの起動を制御するためのトリガーです。このような状態が追加されたことで、トリガーの管理制御が向上しています。CREATE TRIGGER文を無効な状態で使用すれば、有効にする前にコンパイルが成功したかどうかを検証できます。また、トリガーの順序をFOLLOWS句で制御できます。詳細は、『Oracle Database開発ガイド』を参照してください。

5.5.5 ADD COLUMN機能の拡張

列のデフォルト値は、NOT NULLとして指定された列のデータ・ディクショナリで管理されます。

DEFAULT値とNOT NULL制約を指定して新しい列を追加する場合、デフォルト値を既存のすべてのレコードに格納する必要がなくなります。この拡張は、既存のデータ量に関係なく動作し、スキーマ変更を数秒以内に行えるほか、領域を消費することもありません。詳細は、『Oracle Database管理者ガイド』を参照してください。

5.5.6 きめ細かな依存性

Oracle Database 11gより前のリリースでは、メタデータはオブジェクト全体の粒度でオブジェクト間の相互の依存性を記録します。(たとえば、PL/SQLの単位PはPL/SQLの単位Qに依存し、ビューVは表Tに依存するとします。)このような場合、依存オブジェクトは場合によって不必要に無効になっていました。たとえば、ビューVが表Tの列C1、C2およびC3にのみ依存し、新しい列C99が追加される場合、ビューVの有効性は論理的に影響を受けません。それにもかかわらず、以前のリリースでは、Vは列C99が加えられたことによって無効になっていました。

Oracle Database 11gリリース1(11.1)から、依存性メタデータはよりきめ細かい粒度レベルで記録されるため、C99が追加されたことでビューVが無効になることはありません。同様に、プロシージャPがパッケージPKGの要素E1およびE2にのみ依存し、要素E99がPKGに追加される場合も、プロシージャPは無効になりません。(Oracle Database 10gでは、PKGに要素E99が加えられると、プロシージャPは無効になります)。

依存対象のオブジェクトの変更に応じて依存オブジェクトが結果的に無効になることが少なくなることで、アプリケーションの可用性を向上させることができます。これは、開発環境や、アクティブなアプリケーションを解析またはアップグレードする場合に役立ちます。スキーマ・オブジェクトに対する変更には互換性が必要であるため、Oracle Databaseのパッチ・セットを適用する場合にこれが役立ちます。詳細は、『Oracle Database開発ガイド』を参照してください。

5.5.7 不可視の索引

不可視の索引は、索引を使用できなくしたり、索引を削除したりすることの代替方法です。不可視の索引はDML操作に対して維持されますが、ヒントで索引を明示的に指定しないかぎり、オプティマイザで使用されません。

アプリケーション全体をオフラインにできないときでも、アプリケーションの変更が必要になることがしばしばあります。不可視の索引を使用すると、アプリケーション全体に影響を与えることなく、アプリケーションの特定の操作やモジュールに対して一時的な索引構造を利用できます。さらに、不可視の索引を使用して、索引をすぐに削除せずに削除のテストを行うことができるため、本番環境でテストするための猶予期間ができます。詳細は、『Oracle Database管理者ガイド』を参照してください。

5.5.8 不可視の列

不可視の列は、列を名前で明示的に指定した場合のみ表示されるユーザー指定の列です。既存のアプリケーションに影響を与えることなく不可視の列を表に追加でき、必要ならばその列を表示可能にできます。

その表を使用するアプリケーションを破壊することなく、表に変更を加える場合、不可視の列を使用できます。表に不可視の列を追加すると、その不可視の列にアクセスする必要のある問合せやその他の操作では、名前で明示的にその列を参照する必要があります。不可視の列を説明するためのアプリケーションを移行する場合、不可視の列を表示することができます。

詳細は、『Oracle Database管理者ガイド』を参照してください。

5.5.9 同じ列セットに対する複数の索引

Oracle Database 12cでは、Bツリー索引とビットマップ索引の両方を同じ列のセットに作成できます。この機能を使用すれば、特徴が異なってさえいれば、既存の索引と同じ列のセットに、索引を作成できます。この機能により、アプリケーションを破壊することなく、索引のタイプをパッチ・エディションで変更できます。複数の索引のうちいつでも表示できるのは1つのみです。

詳細は、『Oracle Database管理者ガイド』の「同じ列セットでの複数索引の作成」を参照してください。

5.5.10 表のオンライン再定義後の依存PL/SQLの再コンパイル

この機能は、表のオンライン再定義後に依存PL/SQLパッケージを再コンパイルする必要性を最小限に抑えます。再定義によってPL/SQLパッケージに論理的な影響が出ない場合、再コンパイルは必要ありません。この最適化はデフォルトで有効です。

再コンパイルが必要な場合、この機能によって、表のオンライン再定義後に依存PL/SQLパッケージを手動で再コンパイルする時間が短縮され、その手間が軽減されます。再コンパイルには、再定義によって論理的に影響を受けないビュー、シノニム、その他の表依存オブジェクト(トリガーを除く)なども含まれます。オンラインでの表の再定義の詳細は、『Oracle Database管理者ガイド』を参照してください。

脚注の凡例

脚注 1: : Exadataのホワイト・ペーパー『Oracle Exadata Storage Serverへの移行のベスト・プラクティス』(http://www.oracle.com/technetwork/database/exadata/index.htm)を参照してください。
脚注 2: : DBUAでは停止時間が発生します。停止時間の量は、要因の数によって異なります。アップグレード・オプションとしてDBUAを選択したときの追加の考慮事項は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。Oracle DatabaseソフトウェアのアップグレードにDBUAを使用する手順は、『Oracle Databaseアップグレード・ガイド』を参照してください。

6 可用性を最大化するための運用前提条件

MAAの実装を成功させるには、運用ベスト・プラクティスを使用します。

この章の内容は次のとおりです。

- 可用性およびパフォーマンスのSLAの理解

- SLAを満たす高可用性アーキテクチャの実装および検証

- テスト・プラクティスおよび環境の構築

- セキュリティ・ベスト・プラクティスの設定および使用

- 変更管理手順の確立

- 推奨パッチおよびソフトウェアの定期的な適用

- Data Guardのロール移行の実行

- エスカレーション管理手順の確立

- 高可用性のための監視およびサービス要求インフラストラクチャの構成

- 最新のMAAベスト・プラクティスの確認

6.1 可用性およびパフォーマンスのSLAの理解

高可用性およびパフォーマンスに関するサービス・レベル合意(SLA)を理解して文書化します。

- 第1章「高可用性の概要」に示すように、高可用性の属性と、停止時間の様々な原因を理解します。

- 2.1項「高可用性要件」および2.2項「高可用性要件を文書化する方法」に示すように、部門、経営幹部および高可用性とパフォーマンスに関するサービス・レベル合意の技術チームから同意を得ます。

6.2 SLAを満たす高可用性アーキテクチャの実装および検証

高可用性とパフォーマンスに関するサービス・レベル合意の同意を得たら、第2章「高可用性およびデータ保護 - 要件からのアーキテクチャの取得」に示すように、標準で検証済のOracleのアーキテクチャの1つに要件をマップします。第4章「計画外停止時間用Oracle Database高可用性ソリューション」および第5章「計画停止時間用Oracle Database高可用性ソリューション」にあるアーキテクチャに類似した、MAA参照アーキテクチャに関連する停止と計画メンテナンスのマトリックスを評価してください。選択したMAA参照アーキテクチャの詳細は、第7章「高可用性アーキテクチャ」を参照してください。

関連項目:

- 第7章「高可用性アーキテクチャ」

- http://www.oracle.com/technetwork/database/availability/maa-consolidation-2186395.pdfのMAAホワイト・ペーパー『データベース統合の高可用性ベスト・プラクティス: Database-as-a-Serviceの基盤』

6.3 テスト・プラクティスおよび環境の構築

修復作業を検証および自動化して、ターゲット高可用性の品質保証契約(SLA)に準拠していることを確認します。バックアップ、リストアおよびリカバリの操作を検証して、可能性のある各種の停止に対するすべての修復作業を定期的に評価します(詳細は表4-1、表4-2、表5-7および表5-8を参照してください)。

Data Guardを障害回復とデータ保護に使用する場合は、定期的なスイッチオーバー作業を実行するか、完全なアプリケーションおよびデータベースのフェイルオーバー・テストを実施することをお薦めします。また、アプリケーションおよびData Guardのスイッチオーバーを定期的に実行して、すべてのロール移行手順を完全に検証します。

よいテスト環境や適切なテスト・プラクティスは、本番環境で最高の安定性と可用性を達成するための重要な前提条件です。テスト環境であらゆる変更を完全に検証することで、本番で同じ変更を適用する前に、問題を事前に検知して防ぐことができます。

実際の作業には次のようなものがあります。

- テスト・システムおよびQA環境の構成

- 本番前の検証手順の実行

6.3.1 テスト・システムおよびQA環境の構成

テスト・システムは本番MAA環境のレプリカ(MAAのGold層を使用するなど)にする必要があります。テスト・システムが、選択したMAAサービス・レベルで運用される標準の参照アーキテクチャと同一でない場合は、トレードオフがあります。本番をまねたワークロードで、機能、パフォーマンスおよび可用性テストを実行することをお薦めします。可用性とパフォーマンスSLA (6.1項参照)が各変更後も維持されているかを評価し、本番環境に変更を適用している間になにか失敗した場合に、明確なフォールバックまたは修復プロシージャの準備が整っていることを確認します。

適切に構成されたテスト・システムによって、多くの問題を回避できます。変更が検証されるのは同等の本番およびスタンバイ・データベース構成で、これには完全なデータ・セットが含まれ、本番を模倣するためのワークロード・フレームワーク(たとえば、Oracle Real Application Testing)が使用されるためです。

テスト・システムの廃止によってコストを削減しようとしないでください。この決断は後々、本番アプリケーションの安定性と可用性に影響を及ぼすことになります。テストおよびQAのためにシステム・リソースのサブセットのみを使用すると、表6-1に示されているトレードオフがあります(MAAのGold層の例です)。

表6-1 各種のテストおよびQA環境のトレードオフ

テスト環境

利点とトレードオフ

本番システムとスタンバイ・システムの完全レプリカ

すべてのパッチとソフトウェアの変更を検証します。

すべての機能テストを検証します。

本番スケールにおける完全パフォーマンス検証。

完全な高可用性の検証。

本番システムの完全レプリカ

すべてのパッチとソフトウェアの変更を検証します。

すべての機能テストを検証します。

本番スケールにおける完全パフォーマンス検証。

完全な高可用性検証からスタンバイ・システムをマイナスしたもの。

スタンバイ・データベースによる機能、パフォーマンス、高可用性および障害時リカバリの検証はなし。

スタンバイ・システム

ほとんどのパッチとソフトウェアの変更を検証します。すべての機能テストを検証します。

Data Guardスナップショット・スタンバイの使用時は、完全なパフォーマンス検証。ただし、フェイルオーバーが必要な場合はリカバリ時間が長くなる可能性があります。

ロール移行の検証。

スタンバイ・データベースとテスト・データベースが同じシステムに存在する場合は、リソース管理およびスケジューリングが必要です。

共有システム・リソース

ほとんどのパッチとソフトウェアの変更を検証します。すべての機能テストを検証します。

本番の模倣に十分なシステム・リソースを割当てできれば、この環境はパフォーマンス・テストに適している場合があります。

ただし、通常は、環境に本番システム・リソースのサブセットが含まれ、パフォーマンスの検証には欠落が生じます。

リソース管理およびスケジューリングが必要です。

システム・リソースの小規模バージョンまたはサブセット

すべてのパッチとソフトウェアの変更を検証します。すべての機能テストを検証します。

本番スケールにおけるパフォーマンス・テストなし。

限定的な、完全スケールの高可用性評価。

異なるハードウェアまたはプラットフォームのシステム・リソース(同一オペレーティング・システム)

ほとんどのパッチとソフトウェアの変更を検証します。限定的な、ファームウェア・パッチ適用テスト。

すべての機能テストを、ハードウェアの新機能で制限されていないかぎり、検証します。

限定的な、本番スケールのパフォーマンス・テスト。

限定的な、完全スケールの高可用性評価。

関連項目:
『Oracle Databaseテスト・ガイド』

6.3.2 本番前の検証手順の実行

ハードウェア、ソフトウェア、データベース、アプリケーションまたはすべての変更を本番前に検証およびテストすることは、安定性を維持するために重要です。上位レベルの本番前検証の手順は次のとおりです。

1. パッチまたはアップグレードのドキュメントや、対象の変更に関連するドキュメントを確認します。SLAで停止時間をゼロまたは最小限にすることが必要な場合、ローリング・アップグレードの実行の可能性を評価します。計画済停止時間を最小化または排除するローリング・アップグレードの機会を評価します。パッチまたは変更がStandby-First Patchに適格かどうか評価します。

注意:
Standby-First Patchを使用すると、プライマリ・データベースは以前のソフトウェア・リリースのまま、パッチを最初にフィジカル・スタンバイ・データベースに適用できます(この適用対象は特定のパッチ・タイプで、Oracleパッチ・セットおよびメジャー・リリース・アップグレードには適用されません。パッチ・セットおよびメジャー・リリースにはData Guardの一時ロジカル・スタンバイのメソッドを使用してください)。変更作業が終了したら、スタンバイ・データベースへのスイッチオーバーを実行します。フォールバックは必要な場合にスイッチオーバーすることです。もう1つの方法として次の手順に進み、本番環境に変更を適用することもできます。詳細は、My Oracle Supportのノート1265700.1(https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1265700.1)『Oracle Patchの保証 - Data Guard Standby-First Patch適用』を参照してください。

2. テスト環境でアプリケーションを検証し、機能、パフォーマンスおよび可用性の要件を変更が満たしている、または上回っていることを確認します。手順を自動化して、フォールバック手順の文書化およびテストも確認します。これには、テストでパッチ適用の前後に取得されたメトリックを、本番システムで取得されたメトリックと比較することが必要です。Real Application Testingは、本番システムでワークロードを取得し、それをテスト・システムで再現するために使用できます。AWRとSQLパフォーマンス・アナライザは、パッチによって引き起こされたパフォーマンスの向上または低下を評価するために使用できます。
本番環境を模倣するテスト・システムで新規ソフトウェアを検証し、機能、パフォーマンスおよび可用性の要件を変更が満たしている、または上回っていることを確認します。パッチまたはアップグレードの手順を自動化して、フォールバックを確認します。この手順をひととおり実施することで、パッチまたはアップグレードの実施中および実施後における最も致命的な問題を回避できます。

3. 部門で決められているセキュリティ上の制約にも準拠しながら、アプリケーションを包括的に検証するには、Oracle Real Application Testingおよびテスト・データ管理機能を使用します。Oracle Real Application Testing (個別のデータベース・オプション)を使用すると、Oracle Databaseを現実的な環境でテストできます。Oracle Real Application Testingでは、本番環境にデプロイメントを行う前に、本番環境のワークロードを取得し、こららのワークロードに対するシステムの変更の影響を評価することで、システム変更が原因で不安定になるリスクを最小限にします。Oracle Real Application Testingの主要コンポーネントは、SQLパフォーマンス・アナライザおよびデータベース・リプレイです。テストするシステム変更の性質とその影響、およびテストを実行するシステムの種類に応じて、テストの実行にいずれかまたは両方のコンポーネントを使用できます。
現実的な環境でテストを行う場合、テスト環境の本番ではないユーザーに機密データが公開されてしまうリスクがあります。Oracle Databaseのテスト・データの管理機能では、テスト・データに対してデータ・マスキングおよびデータ・サブセット化を実行し、このリスクを最小限にできます。

4. 適用可能な場合、すべての変更の最終的な本番前検証をData Guardスタンバイ・データベースで実行してから、それを本番に適用してください。適用可能な場合、Data Guard環境で変更を適用します。Data Guard Standby-First Patch適用および一時ロジカル・スタンバイ方式の詳細は、3.1.3.1項「Data Guard REDO適用およびStandby-First Patchの適用」および3.1.3.2項「Data Guard一時ロジカル・ローリング・アップグレード」を参照してください。

5. 本番環境で変更を適用します。

関連項目:

- 『Oracle Databaseテスト・ガイド』

- フィジカル・スタンバイ・データベースのスナップショット・スタンバイ・データベースへの変換の詳細は、『Oracle Data Guard概要および管理』を参照してください。

- 既存のフィジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行の詳細は、『Oracle Data Guard概要および管理』を参照してください。

- Oracle GoldenGateの詳細は、『Oracle GoldenGate Windows and UNIX管理者ガイド』を参照してください。

- MAAホワイト・ペーパー(http://www.oracle.com/goto/maa)のOracle DatabaseのMAAベスト・プラクティスの分野で『容易になったデータベースのローリング・アップグレード』を参照してください。

- My Oracle Supportのノート1265700.1(https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1265700.1)『Oracle Patchの保証 - Data Guard Standby-First Patch適用』を参照してください。

6.4 セキュリティ・ベスト・プラクティスの設定および使用

適切なセキュリティ基準のないシステムまたはデータベースに配置された企業データは、深刻なリスクに直面している可能性があります。明確に定義されたセキュリティ・ポリシーは、システムに対する不正アクセスを遮断し、企業の機密情報を破壊行為から保護するのに役立ちます。適切なデータ保護により、セキュリティの侵害によるシステム停止の可能性を抑制できます。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

6.5 変更管理手順の確立

システムの安定性を維持し、テスト・システムまたはMAAサービスレベル層の基本アーキテクチャのいずれかで厳密に評価されるまで変更がプライマリ・データベースに適用されないように、変更を管理および制御する手順を設けます。

変更を確認して、変更管理チームからフィードバックと承認を受け取ります。このチームにはビジネス要件、機能性、パフォーマンスおよびシステムの可用性に影響する、あらゆるコンポーネントの代表が含まれることが必要です。たとえば、チームにはエンドユーザー、アプリケーション、データベース、ネットワークおよびシステムの代表を含むことができます。

6.6 推奨パッチおよびソフトウェアの定期的な適用

最新の推奨パッチおよびソフトウェア・バージョンに対する定期的なテストと適用によって、最新のセキュリティおよびソフトウェアの修正がシステムで確実に行われるようにします。これは、安定性を維持し、多くの既知の問題を回避するために必要です。本番システムでアップグレードを実行する前に、テスト・システムですべての更新および変更を必ず検証してください。

さらに、orachk (単一インスタンスおよびOracle RACシステムをサポート)、odachk (Oracle Data Applianceシステムをサポート)およびexachk (Oracle Exadata Database MachineおよびOracle SuperClusterシステムをサポート)などのOracleヘルス・チェック・ツールにより、重要なソフトウェア更新の推奨事項が提供されます。

関連項目:

- My Oracle Supportのノート756671.1『Oracle推奨パッチ - Oracle Database』
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=756671.1

- My Oracle Supportのノート888828.1『Database MachineおよびExadata Storage Server 11gリリース2 (11.2)サポート・バージョン』
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=888828.1

- My Oracle Supportのノート1268927.2「ORAchk - Oracleスタックのヘルス・チェック」
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1268927.2

- My Oracle Supportのノート1070954.1『Oracle Exadata Database Machine exachkまたはHealthCheck』
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1070954.1

6.7 Data Guardのロール移行の実行

スタンバイ・データベースがある場合、事前に定められたしきい値に従って、プライマリ・データベースが停止または機能が低下した場合はいつでもスタンバイ・データベースを使用できるように、運用およびDBAチームが十分に準備できていることが重要です。効率的に応答および実行すること(フェイルオーバーの検知と決定が含まれます)で、全体的な停止時間を時間単位から分単位に削減できます。

Data Guardを高可用性、障害時リカバリ、データ保護のために使用する場合、3～6か月ごとに定期的なスイッチオーバーの操作を実行するか、完全なアプリケーションおよびデータベースのフェイルオーバー・テストを実行することをお薦めします。

関連項目:
My Oracle Supportに用意されているData Guardスイッチオーバーのためのノートは次のとおりです。

- 『Oracle Data Guard概要および管理』の第9章「ロール・トランジション」

- 『Oracle Data Guard Broker』の第5章「スイッチオーバーとフェイルオーバー操作」

6.8 エスカレーション管理手順の確立

修復を妨げないためのエスカレーション管理手順を確立します。ほとんどの修復ソリューションは、適切に実施されていればMAAソリューションで自動的かつ透過的です。問題が発生するのは、プライマリ・データベースまたはシステムが可用性またはパフォーマンスのSLAに適合せず、フェイルオーバー手順がData Guardの一部のフェイルオーバー・シナリオのように自動で行われるのではない場合です。適切なエスカレーション・ポリシーが施行されず、決定が迅速に行われないと、停止時間が長引く可能性があります。

可用性が最優先である場合、修復およびフェイルオーバー操作を最初に実行し、アプリケーション・サービスが再構築されてから、根本原因分析(RCA)用のログおよび情報の収集を続行します。

関連項目:

- 表4-1「計画外停止時間の停止タイプとOracle高可用性ソリューション」

- 表4-2「MAA参照アーキテクチャおよびマルチテナント・アーキテクチャの計画外停止マトリックス」

- 表5-7「システムおよびソフトウェア・メンテナンス用Oracle高可用性ソリューション」

- 表5-8「MAA参照アーキテクチャおよびマルチテナント・アーキテクチャの計画メンテナンス・マトリックス」

- MAAの停止および修復の詳細は、Oracle Technology Network(OTN) (http://www.oracle.com/goto/maa)でMAA Webページを確認してください。

6.9 高可用性のための監視およびサービス要求インフラストラクチャの構成

高可用性環境を維持するには、停止時間が発生する前に、パフォーマンスおよび高可用性に関連したしきい値を検出し、それに対応する監視インフラストラクチャを構成する必要があります。また、可能な場合は、ユーザーが操作しなくても、Oracleが障害を検出し、フィールド・エンジニアを派遣して、障害が発生したディスク、フラッシュ・カード、ファン、電源などのハードウェア・コンポーネントを置き換えることができます。

6.9.1 データベース・ヘルス・チェックの定期的な実行

Oracleデータベース・ヘルス・チェックは、ハードウェアおよびソフトウェアの構成とベスト・プラクティスに対するMAA準拠を評価するように設計されています。Oracleヘルス・チェック・ツールはすべて、Oracle Grid Infrastructure、Oracle Databaseを評価し、自動MAAスコアカードを提供するか、または主要なアーキテクチャおよび構成の設定が失敗に対する耐性がない、または高速リカバリに対応していない場合にその強調部分を確認します。Exadata Database MachineなどのOracleの設計されたシステムには、数百の追加のソフトウェア、エラーおよび構成のチェックが存在します。

Oracleでは、定期的に(たとえば、Exadata Database Machineの場合毎月)最新のデータベース・ヘルス・チェックのダウンロードと実行、および主要なFAILURES、WARNINGS、およびINFOメッセージへの対処をお薦めしています。ExadataおよびOracle SuperClusterエンジニアド・システムではexachkを使用し、Oracle Database Applianceではodachk、および単一インスタンス環境を含むその他のOracleデータベース・デプロイメントではorachkを使用します。

さらに、計画メンテナンス・アクティビティの前と後に、ヘルス・チェックを実行することもお薦めします。

関連項目:

- My Oracle Supportのノート1268927.2「ORAchk - Oracleスタックのヘルス・チェック」
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1268927.2

- My Oracle Supportのノート1070954.1『Oracle Exadata Database Machine exachkまたはHealthCheck』
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1070954.1

- My Oracle Supportのノート1485630.1『ODAchk- Oracle Database Appliance (ODA)構成監査ツール』
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1485630.1

6.9.2 高可用性のためのOracle Enterprise Manager監視インフラストラクチャの構成

可能性のある停止時間を回避するには、Enterprise Managerと、パフォーマンスおよび高可用性に関連したしきい値を検出し、それに対応する監視インフラストラクチャの両方を構成および使用する必要があります。監視インフラストラクチャを使用すると、ユーザーは高可用性を監視しやすくなり、次の作業も実行できます。

- システム、ネットワーク、アプリケーション、データベースおよびストレージの統計の監視

- パフォーマンスおよびサービスの統計の監視

- システムまたはアプリケーションの問題の初期警告インジケータとなる、パフォーマンスおよび高可用性のしきい値の作成

- パフォーマンスおよび可用性アドバイスの提供

- 確立されたアラート、ツール、およびデータベース・パフォーマンス

- 設計されたシステムのハードウェア障害のアラートの受信

関連項目:

- 潜在的な問題および障害の検出と対応の詳細は、『Oracle Enterprise Manager管理者ガイド』を参照してください。

- My Oracle Supportのノート1110675.1『Enterprise ManagerおよびPluginを使用したExadata Database Machineの監視』
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1110675.1

6.9.3 自動サービス要求インフラストラクチャの構成

Oracle高可用性環境でのEnterprise Managerによる監視インフラストラクチャに加えて可能な場合は、ユーザーが操作しなくても、Oracleが障害を検出し、フィールド・エンジニアを派遣して、障害が発生したハードウェアを置き換えることができます。たとえば、Oracle Automatic Service Request (ASR)は安全かつスケーラブルな、ユーザーがインストール可能なソフトウェア・ソリューションで、これは機能として使用できます。特定のハードウェア障害が発生したとき、OracleのSolarisサーバーおよびストレージ・システムの自動ケース生成を使用することで、このソフトウェアでは問題をより早く解決します。

関連項目:
My Oracle Supportのノート1185493.1『Oracle自動サービス要求』
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1185493.1

6.10 最新のMAAベスト・プラクティスの確認

Oracle Databases、Exadata Database Machine、Oracle SuperCluster、Oracle Fusion Middleware、Oracle Applications、およびOracle Enterprise Manager Grid Controlに対するMAAソリューションおよびベスト・プラクティスは、継続的に開発され、Oracle Technology Network (OTN)で公開されています

http://www.oracle.com/goto/maa

7 高可用性アーキテクチャ

Oracle MAAは、Oracle Databaseに対する高可用性アーキテクチャの設計、実装および操作に関するベスト・プラクティスの推奨事項を提示します。この章では、MAA参照アーキテクチャの各層で使用される主なコンポーネントと、実現されるサービス・レベルの詳細な説明を示します。

この章の内容は次のとおりです。

- MAA参照アーキテクチャの概要

- Bronze層 - 単一インスタンスのHAアーキテクチャ

- Silver層 - 自動フェイルオーバーによる高可用性

- Gold層 - 包括的な高可用性および障害時リカバリ

- Platinum層 - 停止しないPlatinum対応アプリケーション

- Oracle Fusion Middlewareの高可用性の統合

- すべてのアプリケーションの高可用性の統合

7.1 MAA参照アーキテクチャの概要

第2章「高可用性およびデータ保護 - 要件からのアーキテクチャの取得」には、Bronze、Silver、GoldおよびPlatinumの4つのMAA参照アーキテクチャの概要が記載されています。各参照アーキテクチャ(別名HA層)には、ともにデプロイされた場合に、高可用性およびデータ保護の指定されたサービス・レベルを確実に実現する、Oracleの最適な機能セットが使用されています。図7-1に、各HA層で使用されているテクノロジの概要を示します。

図7-1 Oracle MAA参照アーキテクチャ

上で説明されている各アーキテクチャは、第6章「可用性を最大化するための運用前提条件」、MAAのテクニカル・ホワイト・ペーパーに記載されているその他のベスト・プラクティス、および『Oracle Database高可用性ベスト・プラクティス』に記述されている運用上および構成上のベスト・プラクティスを使用して実装します。MAAベスト・プラクティスに関するドキュメントの参照情報の詳細は、1.5項「最大可用性アーキテクチャ実装のロードマップ」を参照してください。

7.2 Bronze層 - 単一インスタンスのHAアーキテクチャ

Bronze層では、できるかぎり少ないコストで、基本的なデータベース・サービスを提供しています。コストを削減し、実装の複雑さを低減するかわりに、HAとデータ保護のレベルが下げられています。図7-2に、Bronze層の概要を示します。

図7-2 Bronze層 - 単一インスタンスのHAアーキテクチャ

Bronzeで使用されるのは単一インスタンスのOracle Databaseで、Oracle Databaseインスタンスが実行されているサーバーが停止した場合に、自動フェイルオーバーに使用されるクラスタリング・テクノロジはありません。サーバーを使用できなくなった場合、またはデータベースをリカバリできない場合に、どれほど迅速に代替システムをプロビジョニングできるか、あるいはバックアップをリストアできるかを示す関数がRTOです。完全なサイト停止の最悪のシナリオでは、代替場所でこれらのタスクを実行するための時間も必要で、これには数日を要する場合もあります。

Oracle Recovery Manager (RMAN)は、Oracle Databaseの定期バックアップの実行に使用されます。リカバリ不可能な停止が発生した場合は、最後のバックアップ取得後に生成されたデータがRPOということになります。データベース・バックアップのコピーは、アーカイブと、プライマリ・データ・センターが災害に見舞われた場合の災害時リカバリの2つの目的で、リモートの場所またはクラウドにも保持されます。

Bronze層は、次のトピックで説明する主なコンポーネントで構成されています。

- Oracle DatabaseのHAおよびデータ保護

- Bronze層でのデータベース統合

- ライフサイクル管理およびDBaaS

- Oracle Engineered Systems

- Bronzeの概要: データ保護、RTOおよびRPO

7.2.1 Oracle DatabaseのHAおよびデータ保護

Bronzeでは、Oracle Database Enterprise Editionに含まれているHAおよびデータ保護の機能を、追加の費用なしで使用できます。

- Oracle Restartは、ハードウェアまたはソフトウェア障害の後、あるいはデータベースのホスト・コンピュータの再起動時には必ず、データベース、リスナーおよびその他のOracleコンポーネントを自動的に再起動します。

- 物理的な破損および論理的なブロック内破損を対象としたOracle破損保護チェック。インメモリー破損が検出されると、ディスクへの書込みが阻止され、多くの場合は自動的に修復されます。詳細は、Oracle Databaseのブロック破損の防止、検出および修復を参照してください。

- 自動ストレージ管理(ASM)はOracleの統合ファイル・システムで、ディスク障害から保護するためのローカル・ミラー化を含むボリューム・マネージャです。

- Oracle Flashbackテクノロジは、個々のトランザクション、表またはデータベース全体の修復に適した粒度レベルでの高速なエラー修正を可能にします。

- Oracle Recovery Manager (RMAN)を使用すると、Oracle Databaseに最適化された信頼性の高いバックアップとリカバリを低コストで実現できます。

- オンライン・メンテナンスには、データベース・メンテナンスのオンライン再定義と再編成、オンライン・ファイル移動およびオンライン・パッチ適用が含まれます。

7.2.2 Bronze層でのデータベース統合

Bronze層にデプロイされるデータベースには、開発およびテストのデータベース、およびデータベース統合やDatabase as a Service (DBaaS)としてのデプロイ候補として一番最初にあげられることが多い、比較的小規模な作業グループや部門ごとのアプリケーションをサポートしているデータベースがあります。

Oracle Multitenantは、Oracle Database 12c以降のデータベース統合および仮想化のMAAベスト・プラクティスです。その他の統合オプションは次のとおりです

- オペレーティング・システムの仮想化 - 仮想マシン

- スキーマ統合

- Oracle RACを使用した、単一の物理マシンまたはクラスタへの複数の離散データベースの統合

Oracle Multitenantとその他の統合方法との間のトレードオフの詳細は、Oracle MAAのテクニカル・ホワイト・ペーパー『データベース統合の高可用性ベスト・プラクティス』を参照してください。

7.2.3 ライフサイクル管理およびDBaaS

Oracle Enterprise Manager Cloud Controlでは、ビジネス・ユーザーが、様々なマルチテナント・アーキテクチャに対応するリソース・プール・モデルとともに、ITリソースをセルフ・サービスでデプロイできます。これらの機能は、Database as a Service (DBaaS)の実装に必要で、このパラダイムでは、エンド・ユーザー(データベース管理者、アプリケーション開発者、品質保証エンジニア、プロジェクト・リーダーなど)がデータベース・サービスをリクエストして、プロジェクトの存続期間に使用し、自動的にプロビジョニングが解除されてリソース・プールに戻されます。Cloud ControlのDatabase as a Service (DBaaS)では、次のものが提供されます。

- データベース・サービスをプロビジョニングする共有の統合プラットフォーム

- それらのリソースをプロビジョニングするセルフサービス・モデル

- データベース・リソースをスケール・アウトおよびスケール・バックする柔軟性

- データベースの使用状況に基づいたチャージバック

7.2.4 Oracle Engineered Systems

Oracle Engineered Systemsは、すべての層におけるデータベース統合とDBaaSの効率的なデプロイメント・オプションです。Oracle Database向けに事前に統合および最適化されたプラットフォームを標準とし、Oracleでサポートされているハードウェアとソフトウェアが使用されているため、Oracle Engineered Systemsを使用することで、ライフサイクル・コストが低減されます。Oracle Engineered Systemsには、次のものがあります。

- Oracle Virtual Compute Applianceは、任意のLinux、Oracle SolarisまたはMicrosoft Windowsアプリケーション向けの仮想インフラストラクチャをインストール、デプロイおよび管理する方法を徹底的に簡略化します。

- Oracle Database Applianceは、ソフトウェア、サーバー、ストレージ、ネットワーキングを簡素にすることを目的として設計された、完全で低コストなパッケージであり、データベースやアプリケーション・ワークロードのデプロイメント、メンテナンス、サポートが簡略化されているため、時間と費用を節約できます。Oracle Database Applianceでは、物理デプロイと仮想デプロイの両方がサポートされています。

- Oracle Exadata Database Machineは、Oracle Databaseを実行するためのプラットフォームで、最高のパフォーマンスとスケーラビリティ、可用性を誇ります。Oracle Exadata Database Machineは、オンライン・トランザクション処理(OLTP)、データ・ウェアハウス(DW)および混合ワークロードの統合など、あらゆるタイプのデータベース・ワークロードを実行でき、データベース統合の理想的な基盤です。

- Oracle SuperClusterエンジニアド・システムは、単一の汎用目的プラットフォーム上で、データベースやアプリケーション、プライベート・クラウド・デプロイメントおよびOracleソフトウェアを統合するのに最適です。Oracle SuperClusterには、SPARCアーキテクチャとExadataストレージを基盤として、世界最速のプロセッサが使用されています。

- Oracle ZFS Storage Applianceでは、Network Attached Storage (NAS)を使用して、設置スペース、管理およびコストの面で直接のメリットを提供します。Oracle ZFSには、管理、監視、トラブルシューティング、スナップ、クローン、レプリケーション、およびどのOracle Engineered Systemsにも無理なく追加できる高度なデータ・サービスの豊富なソフトウェア・スイートが含まれています。

7.2.5 Bronzeの概要: データ保護、RTOおよびRPO

表7-1に、Bronze層のデータ保護機能をまとめます。表7-1の1列目は、物理破損および論理破損の検証がいつ実行されるかを示しています。

- 手動チェックは、管理者が開始するか、定期的なチェックを実行するスケジュール済ジョブによって一定の間隔で実行されます。

- ランタイム・チェックは、データベースのオープン時に、バックグラウンド・プロセスによって継続的かつ自動的に実行されます。

- バックグラウンド・チェックは、スケジュールされた定期的な間隔で実行されますが、リソースがアイドルの期間にかぎられます。

それぞれのチェックはOracle Database独自のもので、Oracleのデータ・ブロックやREDO構造に関する固有の知識が使用されています。

表7-1 Bronze層のデータ保護

タイプ

機能

物理ブロック破損

論理ブロック破損

手動

Dbverify、Analyze

物理的ブロック・チェック

ブロック内およびオブジェクト間の一貫性に関する論理チェック

手動

RMAN

バックアップおよびリストア中の物理的ブロック・チェック

ブロック内論理チェック

ランタイム

データベース

インメモリー・ブロックおよびREDOチェックサム

インメモリーのブロック内論理チェック

ランタイム

ASM

ローカル・エクステント・ペアを使用した自動破損検出および修復

ランタイム

Exadata

書込みに対するHARDチェック

書込みに対するHARDチェック

バックグラウンド

Exadata

自動ハード・ディスク修正および修復脚注1

脚注1 Exadata 11.2.3.3以降およびOracle Database 11gリリース2 (11.2.0.4)以降で使用可能。

HARD検証と、自動ハード・ディスク修正および修復(表2の最後の2行)は、Exadataストレージに固有であることに注意してください。HARD検証を行うと、Oracle Databaseにより、物理的に破損したブロックがディスクに書き込まれることはありません。アイドル・リソースがある場合、自動ハード・ディスク修正および修復により、破損または消耗しているディスク・セクター(ストレージのクラスタ)のあるハード・ディスクや、その他の物理的または論理的な不具合が定期的に検査および修復されます。別のミラー・コピーからデータを読み取ることにより、不良セクターの修復リクエストがExadataからASMに送信されます。デフォルトでは、ハード・ディスクの修正は2週間ごとに実行されます。

表3に、様々な計画外停止や計画停止に対するBronze層のRTOおよびRPOをまとめます。

表7-2 Bronze層のリカバリ時間(RTO)およびデータ損失の可能性(RPO)

タイプ

イベント

停止時間

データ損失の可能性

計画外

データベース・インスタンス障害

数分

ゼロ

計画外

リカバリ可能なサーバー障害

数分から1時間

ゼロ

計画外

データ破損、リカバリ不能なサーバー障害、データベース障害またはサイト障害

数時間から数日

最後のバックアップ以降

計画

オンライン・ファイル移動、オンライン再編成および再定義、オンライン・パッチ適用

ゼロ

ゼロ

計画

ハードウェアやオペレーティング・システムのメンテナンス、およびオンラインで適用できないデータベース・パッチ

数分から数時間

ゼロ

計画

データベースのアップグレード: パッチ・セットおよび完全なデータベース・リリース

数分から数時間

ゼロ

計画

プラットフォームの移行

数時間から1日

ゼロ

計画

バックエンドのデータベース・オブジェクトを変更するアプリケーションのアップグレード

数時間から数日

ゼロ

7.3 Silver層 - 自動フェイルオーバーによる高可用性

Silver層は、計画外停止と計画メンテナンスの両方の可用性を向上させるために、クラスタリング・テクノロジを組み込んで、Bronze上に構築されています。Silverでは、リカバリ不能なデータベース・インスタンスの停止やそれが実行されているサーバーで完全な障害が発生した場合に自動フェイルオーバーを可能にすることで、データ・センター内のHAにOracle RACまたはOracle RAC One Nodeを使用します。Oracle RACがもたらす利点も大きなもので、Oracle RACノード全体にローリング方式でメンテナンスを実行することにより、様々なタイプの計画停止時間をなくします。図7-3に、Silver層の概要を示します。

図7-3 Silver層 - 自動フェイルオーバーによる高可用性

Silverには、次の各項で説明されているHAコンポーネントが含まれます。

- Oracle RAC

- Oracle RAC One Node

- Silver層の概要: データ保護、RTOおよびRPO

7.3.1 Oracle RAC

データベース・インスタンスやそれが実行されているサーバーが停止した場合、Oracle RACが、データ・センター内のアプリケーションの可用性を向上します。Oracle RACを使用したサーバーのフェイルオーバーは一瞬です。機能しているインスタンスでサービスが再開される前に、非常に短い停止時間があり、停止したインスタンスのユーザーが再接続できます。Oracle RACノード全体にローリング方式で実行できる場合は、そうした計画メンテナンス・タスクの停止時間もなくなります。ユーザーは、メンテナンスが実行されるノードでの作業を完了し、セッションを終了します。再接続すると、別のノードですでに実行されているデータベース・インスタンスに移動されます。

Oracle RACがどのように機能するかを簡単に確認することで、その利点を理解できます。コンポーネントは、Oracle DatabaseインスタンスとOracle Database自体の2つです。

- データベース・インスタンスは、サーバー・プロセスのセット、およびクライアントに対して特定のデータベースを使用可能にする単一ノード(またはサーバー)で実行中のメモリー構造として定義されます。

- データベースは、永続記憶域に存在する特定の共有ファイルのセット(データ・ファイル、索引ファイル、制御ファイルおよび初期化ファイル)で、同時に開いて、データの読取りと書込みに使用できます。

- Oracle RACにはアクティブ-アクティブ・アーキテクチャが使用されており、それぞれ別のノードで実行されている複数のデータベース・インスタンスが、同じデータベースに読取りと書込みを同時に実行できます。

Oracle RACのアクティブ-アクティブ・アーキテクチャには、多数の利点があります。

- 高可用性の向上: サーバーまたはデータベース・インスタンスが停止しても、機能しているインスタンスへの接続に影響はなく、停止したインスタンスへの接続は、クラスタ内の他のサーバーですでに実行され、オープンである機能しているインスタンスへすぐにフェイルオーバーされます。

- スケーラビリティ: Oracle RACは、容量の動的な追加や、2つ以上のサーバー間における優先度の変更を必要とする大規模なアプリケーションや統合環境に最適です。個々のデータベースのインスタンスは、クラスタの1つ以上のノードで実行されます。同様に、データベース・サービスも、1つ以上のデータベース・インスタンスで使用可能です。追加のノード、データベース・インスタンスおよびデータベース・サービスを、オンラインでプロビジョニングできます。クラスタ間でワークロードを簡単に分散できるため、Oracle RACは、Oracle Multitenantに最適なコンポーネントです。

- 信頼性の高いパフォーマンス: Oracle Quality of Service (QoS)を優先度の高いデータベース・サービスへの容量の割当てに使用して、データベース統合環境で一貫して高いパフォーマンスを実現することができます。変化する要件に迅速に対応できるよう、容量は、ワークロード間で動的に移動できます。

- 計画メンテナンス中のHA: 高可用性は、Oracle RACノード全体にローリング方式で変更を実装することにより維持されます。これには、サーバーをオフラインにする必要がある、ハードウェア、OSまたはネットワークのメンテナンス、Oracle Grid Infrastructureまたはデータベースにパッチを適用するソフトウェア・メンテナンス、または容量を増加したり、ワークロードのバランスをとるために、データベース・インスタンスを別のサーバーに移動する必要がある場合が含まれます。

Oracle RACは、サーバーHAのMAAベスト・プラクティスです。

7.3.2 Oracle RAC One Node

Oracle RAC One Nodeは、サーバーHAが要件ではあるが、スケーラビリティとインスタント・フェイルオーバーは不要な場合に、Silver層のOracle RACのオプションとなります。Oracle RAC One Nodeのライセンスは、Oracle RACのコストの半分であるため、サーバー障害を管理する際に、RTOが分単位でもかまわない場合には、よりコストのかからない選択肢です。

Oracle RAC One Nodeは、アクティブ-パッシブ・フェイルオーバー・テクノロジです。Oracle RACと同じインフラストラクチャ上に構築されていますが、Oracle RAC One Nodeの場合、通常の操作中にオープンになるデータベース・インスタンスは一度に1つのみです。これにより、特に多数のデータベースを統合する場合に、メモリー要件が大幅に引き下げられます。オープン・インスタンスをホストしているサーバーが停止すると、Oracle RAC One Nodeにより、第2ノードに新しいデータベース・インスタンスが自動的に起動され、サービスが迅速に再開されます。

Oracle RAC One Nodeには、別のアクティブ-パッシブ・クラスタリング・テクノロジに勝る利点がいくつかあります。Oracle RAC One Node構成では、Oracle Database HAサービス、グリッド・インフラストラクチャおよびデータベース・リスナーが、常に第2ノードで実行されます。フェイルオーバーする際、起動する必要があるのはデータベース・インスタンスとデータベース・サービスのみであるため、サービスの再開に要する時間が短くなり、数分でサービスを再開できます。

また、Oracle RAC One Nodeの計画メンテナンスの利点は、Oracle RACと同じです。Oracle RAC One Nodeでは、計画メンテナンスの期間中は2つのデータベース・インスタンスをアクティブにできるため、停止時間なしで、1つのノードから別のノードにユーザーを正常に移行できます。メンテナンスは、ユーザーがいつでもデータベース・サービスを使用可能な状態で、ノード全体にローリング方式で実行されます。

7.3.3 Silver層の概要: データ保護、RTOおよびRPO

データ保護のレベルは、Bronze層で提供されるものと比較して、異なる点はありません。Bronzeと比較してSilverで提供される改良点はすべて、サーバー停止のRTOや、頻繁に実行されるいくつかのタイプの計画メンテナンスに関連するものです。表7-3に、Silver層で有効になるRTOおよびRPOをまとめます。Bronzeと比較した場合に改良されている領域はカッコで囲んであります。

表7-3 Silver層のリカバリ時間(RTO)およびデータ損失の可能性(RPO)

タイプ

イベント

停止時間

データ損失の可能性

計画外

データベース・インスタンス障害

Oracle RACの場合は数秒(Bronzeでは数分)

ゼロ

計画外

リカバリ可能なサーバー障害

Oracle RACの場合は数秒(Bronzeでは数分から1時間)

Oracle RAC One Nodeの場合は数分(Bronzeでは数分から1時間)

ゼロ

ゼロ

計画外

データ破損、リカバリ不能なサーバー障害、データベース障害またはサイト障害

数時間から数日

最後のバックアップ以降

計画

オンライン・ファイル移動、オンライン再編成および再定義、オンライン・パッチ適用

ゼロ

ゼロ

計画

ハードウェアやオペレーティング・システムのメンテナンス、およびオンラインでは適用できないが、Oracle RACローリング・インストールは可能なデータベース・パッチ

ゼロ(Bronzeでは数分から数時間)

ゼロ

計画

データベースのアップグレード: パッチ・セットおよび完全なデータベース・リリース

数分から数時間

ゼロ

計画

プラットフォームの移行

数時間から1日

ゼロ

計画

バックエンドのデータベース・オブジェクトを変更するアプリケーションのアップグレード

数時間から数日

ゼロ

7.4 Gold層 - 包括的な高可用性および障害時リカバリ

Gold層はデータベース・レプリケーション・テクノロジを使用してSilver上に構築されており、単一点障害をなくして、データ破損、データベース障害やサイト障害など、あらゆるタイプの計画外停止から、より高いレベルでデータを保護してHAを提供します。レプリケートされたコピーが存在することも、計画メンテナンス期間中の停止時間を短くする上で大きな利点になっています。図7-4に、Gold層の概要を示します。RTOは数秒または数分に短縮され、付随するRPOは構成に応じて、ゼロまたはほぼゼロです。

図7-4 Gold層 - 包括的な高可用性と障害時リカバリ

GoldではサーバーHAの標準として、Silverで使用可能な、オプションの少ないOracle RAC One Nodeのかわりに、Oracle RACが使用されることに注意してください。

Gold層には、高度なHAコンポーネントが追加されており、次の各項で説明されているサービス・レベルの向上が実現されています。

- Oracle Active Data Guard - リアル・タイムのデータ保護および可用性

- Oracle GoldenGate

- Oracle Site Guard

- Goldの概要: データ保護、RTOおよびRPO

7.4.1 Oracle Active Data Guard - リアル・タイムのデータ保護および可用性

Oracle Active Data Guardでは、同期された物理レプリカ(スタンバイ・データベース)がリモートの場所に1つ以上維持され、本番データベース(プライマリ・データベース)の単一点障害をなくすために使用されます。Oracle Active Data Guardにより、Gold層に追加される機能は次のとおりです。

- データ損失の可能性をゼロまたはほぼゼロのどちらにするか選択可能。Oracle Active Data Guardでは、プライマリからスタンバイ・データベースへ、変更内容がリアルタイムでレプリケートされます。変更がプライマリのログ・バッファから直接転送されるため、伝播の遅延やオーバーヘッドが最小化され、本番データベースのI/Oスタックで発生する可能性のある破損から、レプリケーションが完全に分離されます。
管理者は、データが損失しないことを保証する場合は、同期転送と最大可用性を選択できます。また、ほぼゼロのデータ損失の場合は、非同期転送と最大パフォーマンスを選択できます。ネットワーク帯域幅が転送量の処理に十分であれば、最大パフォーマンスの場合、データ損失の危険にさらされるのは1秒未満です。

Data Guardは、データ損失ゼロの保護を実現するOracleレプリケーション・テクノロジです。

- プライマリ・データベースの可用性に影響するデータベースやサイトの停止が発生した場合、Oracle Active Data Guardのスタンバイ・データベースによって本番データベースが迅速に引き継がれ、サービスがリストアされます。Oracle Databaseは常に実行されており、プライマリ・ロールに遷移するために再起動する必要がなく、ロールの遷移は、負荷の高いシステムであっても60秒未満で完了します。
Goldでは、Data Guardのファスト・スタート・フェイルオーバーを使用して、データベースのフェイルオーバーを自動化します。これにより、管理者が通知を受けて停止に対応するまでに発生する遅延がなくなり、リカバリ時間が短縮されます。ファスト・スタート・フェイルオーバーでは、ロール固有のデータベース・サービスとOracleクライアント通知フレームワークを使用して、アプリケーションと停止したプライマリ・データベースとの接続がすぐに切断され、新しいプライマリに自動的に再接続されるようにしています。ロールの遷移は、コマンドライン・インタフェースまたはOracle Enterprise Managerを使用して、手動で実行することも可能です。

- 透過的なレプリケーション。Oracle Active Data Guardでは、Oracle Databaseの完全な一方向物理レプリケーションが実行されますが、パフォーマンスが高く、管理が簡単で、あらゆるデータ・タイプ、アプリケーションおよびワークロード(DML、DDL、OLTP、バッチ処理、データ・ウェアハウス、統合データベースなど)がサポートされるという特徴があります。Oracle Active Data Guardは、Oracle RAC、ASM、RMANおよびOracle Flashbackテクノロジと緊密に統合されています。

- 投資利益率(ROI)を高めるための本番オフロード。Oracle Active Data Guardのスタンバイ・データベースは、レプリケーションがアクティブな間は、読取り専用でオープンすることが可能で、本番データベースから非定型問合せやレポート作成ワークロードをオフロードするために使用できます。オフロードにより、アイドル状態であった容量が使用されるため、スタンバイ・システムのROIが高まり、すべてのワークロードのパフォーマンスが向上します。また、スタンバイ・システムが本番ワークロードをサポートする準備が整っているため、継続的なアプリケーションの検証にもなります。

- バックアップのオフロード。プライマリ・システムとスタンバイ・システムは完全な物理レプリカであるため、プライマリからスタンバイ・データベースにバックアップをオフロードできます。スタンバイで取得されたバックアップは、プライマリとスタンバイ・データベースのどちらのリストアにも使用可能です。このため、管理者は、バックアップの実行によるオーバーヘッドで本番システムに負荷をかけることなく、柔軟にリカバリできます。

- 計画メンテナンスの停止時間の短縮。先にスタンバイでアップグレードを実装してから、本番を新しいバージョンに切り替えることにより、新しいOracleパッチセット(パッチ・リリース11.2.0.2から11.2.0.4など)、または新しいOracleリリース(リリース11.2から12.1など)へのローリング方式でのアップグレードに、スタンバイ・データベースを使用できます。合計停止時間は、メンテナンスが完了した後に、スタンバイ・データベースをプライマリ本番ロールに切り替えるために必要な時間のみです。

- Oracle Active Data Guardのスタンバイでは、継続的にOracle検証が実行されるため、ソース・データベースから破損が伝播されることはありません。検出されるのは物理的および論理的なブロック間破損で、これはプライマリ・データベースでもスタンバイ・データベースでも、単独で発生する可能性があります。また、サイレント書込み欠落破損(I/Oサブシステムで成功と認識される書込み欠落または宛先違いの書込み)のランタイム検出を有効化する点も独特です。詳細は、My Oracle Supportのノート1302539.1「破損の検出、防止および自動修復のベスト・プラクティス」を参照してください。

- 自動ブロック修復。Oracle Active Data Guardでは、プライマリ・データベースでもスタンバイ・データベースでも、単独で発生する可能性がある断続的なランダムI/Oエラーが原因のブロックレベル破損が自動的に修復されます。これは、相手側のデータベースからブロックの正常なコピーを取得して実行されます。アプリケーションの変更は不要で、修復はユーザーに透過的です。

前述の内容は、リモート・ミラー化製品(SRDF、Hitachi社のTrueCopyなど)ではなく、Oracleレプリケーション・テクノロジをGold層に使用し、どのように同期コピーを維持しているかを説明しています。違いに関するより詳細な説明は、『Oracle Active Data Guardおよびストレージのリモート・ミラー化』を参照してください。

7.4.2 Oracle GoldenGate

Oracle GoldenGateは、本番データベース(ソース・データベース)の同期コピー(ターゲット・データベース)を保持するための論理レプリケーションのオプションを提供します。論理レプリケーションは、物理レプリケーションよりも複雑なプロセスですが、様々なレプリケーション・シナリオや異種プラットフォームを処理する際の柔軟性を高めます。

- 論理レプリケーションは、データ分散の観点から、ソース・データベースのサブセットを効率的にレプリケートし、データを他のターゲット・データベースに分散できるよう設計されています。また、複数のソース・データベースから単一のターゲット・データベース(運用データ・ストアなど)にデータを統合する際にも使用できます。

- 高可用性の観点から、論理レプリケーションを使用してソース・データベースの完全なレプリカを保持し、ソース・データベースが使用不能になった場合の迅速なフェイルオーバーに備える障害保護や高可用性を実現できます。Oracle GoldenGateには、論理レプリケーション・プロセスが使用されています。変更はソース・データベースのディスクから読み取られ、そのデータがプラットフォームに依存しないファイル形式に変換されて、ターゲット・データベースに送信された後、ターゲット・データベースにネイティブなSQL (更新、挿入および削除)にデータが変換されます。ターゲット・データベースに含まれているデータは同じものですが、データベースはソースとは異なります(たとえば、バックアップの交換はできません)。

- Oracle GoldenGateの論理レプリケーションを使用すると、Data Guardの物理レプリケーションでは不可能なローリング方式で、メンテナンスや移行を実行する際の柔軟性が高まります。たとえば、Oracle GoldenGateでは、ビッグエンディアン・プラットフォームで実行されているソースと、リトルエンディアン・プラットフォームで実行されているターゲットのレプリケーション(クロスエンディアン・レプリケーション)が可能です。これにより、カットオーバー後に、高速フォールバック用のレプリケーションを前のバージョンに戻すことができるという利点が加わった状態で、プラットフォームの移行を実行できるようになります。

Oracle GoldenGateの論理レプリケーションは、Data Guardの物理レプリケーションには適用されない数多くの前提条件がある複雑なプロセスです。そうした前提条件があるおかげで、Oracle GoldenGateには、アドバンスト・レプリケーションの要件に対応する独自の機能があります。それぞれのレプリケーション・テクノロジのトレードオフ、およびどちらか一方の使用または両方のテクノロジの補完的な使用が推奨される要件の詳細は、MAAベスト・プラクティス: Oracle Active Data GuardおよびOracle GoldenGateを参照してください。

7.4.3 Oracle Site Guard

Oracle Site Guardを使用すると、管理者は、本番サイトとリモートの障害時リカバリ・サイトの間で、Oracle環境、複数のデータベースおよびアプリケーションのスイッチオーバー(計画イベント)とフェイルオーバー(計画外停止への対応)を編成できます。Oracle Site Guardは、Oracle Enterprise Manager Life-Cycle Management Packに含まれています。

Oracle Site Guardには次のような利点があります。

- サイト障害への対応が準備されているため、エラーが減少します。Oracle Site Guardは、障害時に人的エラーが起きる可能性を低減します。障害回復計画が作成およびテストされ、準備した対応の予行がアプリケーション内で行われます。管理者が障害時リカバリ向けのSite Guardの操作を開始した後は、人間が操作する必要はありません。

- 複数のアプリケーション、データベースおよび様々なレプリケーション・テクノロジの調整が行われます。サイトを起動または停止している間、Oracle Site Guardは自動的に、異なるターゲット間の依存性を処理します。Site GuardはOracle Active Data Guardと統合して、複数の同時データベース・フェイルオーバーを調整します。また、Site Guardには、ストレージのリモート・ミラー化製品と統合するために簡単なメカニズムが用意されています。操作ワークフロー内で、任意のユーザー定義のストレージ・ロール・リバーサル・スクリプトに対するコールアウトを使用して、スイッチオーバーまたはフェイルオーバーを実行するストレージ・アプライアンスと統合します。

- リカバリ時間が短縮されます。Oracle Site Guardの自動化により、リカバリ・アクティビティの手動調整が最小限になります。これにより、手動作業がすべて正常に実行された場合と比べても、リカバリ時間が短くなります。Site Guardでは、時間がかかり、複雑な手順の手動実行を伴うことが多い、人的エラーの解決も回避できます。

7.4.4 Goldの概要: データ保護、RTOおよびRPO

表7-4に、Gold層で行われるデータ保護をまとめます。

表7-4 Gold層のデータ保護

タイプ

機能

物理ブロック破損

論理ブロック破損

手動

Dbverify、Analyze

物理的ブロック・チェック

ブロック内およびオブジェクト間の一貫性に関する論理チェック

手動

RMAN

バックアップおよびリストア中の物理的ブロック・チェック

ブロック内論理チェック

ランタイム

Oracle Active Data Guard

スタンバイにおける物理的ブロック・チェック

プライマリとスタンバイを強力に分離することで単一点障害を排除

物理破損の自動修復

データベースの自動フェイルオーバー

書込み欠落破損の検出、自動停止およびフェイルオーバー

スタンバイにおけるブロック間論理チェック

ランタイム

データベース

インメモリー・ブロックおよびREDOチェックサム

インメモリーのブロック内論理チェック

ランタイム

ASM

ローカル・エクステント・ペアを使用した自動破損検出および修復

ランタイム

Exadata

書込みに対するHARDチェック

書込みに対するHARDチェック

バックグラウンド

Exadata

ハード・ディスクの自動修正および修復

表7-5に、Gold層のRTOおよびRPOをまとめます。Gold層ではSilverと比較して、リカバリ時間およびデータ損失の可能性が大幅に減少します。Silver層と比較した場合に改良されている領域はカッコで囲んであります。

表7-5 Gold層のリカバリ時間(RTO)およびデータ損失の可能性(RPO)

タイプ

イベント

停止時間

データ損失の可能性

計画外

データベース・インスタンス障害

数秒

ゼロ

計画外

リカバリ可能なサーバー障害

数秒

ゼロ

計画外

データ破損、リカバリ不能なサーバー障害、データベース障害またはサイト障害

ゼロから数分(Silverでは数時間から数日)

ASYNCを使用している場合はほぼゼロ(Silverでは最後のバックアップ以降)

Data Guardの同期転送を使用している場合はゼロ(Silverでは最後のバックアップ以降)

計画

オンライン・ファイル移動、オンライン再編成および再定義、オンライン・パッチ適用

ゼロ

ゼロ

計画

ハードウェアやオペレーティング・システムのメンテナンス、およびオンラインで適用できないデータベース・パッチ

ゼロ

ゼロ

計画

データベースのアップグレード: パッチ・セットおよび完全なデータベース・リリース

数秒(Silverでは数分から数時間)

ゼロ

計画

プラットフォームの移行

数秒(Silverでは数時間から1日)

ゼロ

計画

バックエンドのデータベース・オブジェクトを変更するアプリケーションのアップグレード

数時間から数日

ゼロ

7.5 Platinum層 - 停止しないPlatinum対応アプリケーション

Platinum層はGold上に構築され、停止やデータ損失が許されないアプリケーションで、最高レベルのHAとデータ保護を実現します。Platinum層には、Oracle Database 12cの複数の新機能と、以前から使用されていた製品で、最新リリースにおいて拡張されたものが導入されています。Platinumでは、アプリケーションやユーザーには停止の影響が伝わらず、リカバリ可能な障害の後には処理中のトランザクションも保存されます。メンテナンス、移行およびアプリケーションのアップグレードは停止時間なしで実行できます。サイト間の距離にかかわらず、いかなる理由でプライマリ・データベースに障害が発生した場合でも、データが損失することはありません。さらに、Platinumでは、データベース・サービスの可用性と、複数のサイトに存在するデータベース・レプリカ間でのワークロードのロード・バランシングが自動的に管理されます。図7-5に、Platinum層の概要を示します。

図7-5 Platinum層 - 停止なし

一部のアプリケーションでは、アプリケーションのゼロ停止を実現するために一定の変更を行う必要がありますが、これには、Platinum層で提供されている機能を使用します。Platinumが、Platinum対応アプリケーションにアプリケーションのゼロ停止を提供すると説明されるのは、このためです。データ損失ゼロの実現には、アプリケーションの変更は必要ありません。

Platinum層では、次の各項で説明されているHA機能が有効です。

- アプリケーション・コンティニュイティ

- Oracle Active Data Guardの遠隔同期

- Oracle GoldenGateの停止時間ゼロのメンテナンスおよびアクティブ-アクティブ・レプリケーション

- エディションベース再定義

- グローバル・データ・サービス

- Platinumの概要: データ保護、RTOおよびRPO

7.5.1 アプリケーション・コンティニュイティ

アプリケーション・コンティニュイティは、インスタンス、サーバー、ストレージ、ネットワークまたはその他の関連コンポーネントを原因とするデータベース・セッション障害、さらには完全なデータベース障害からもアプリケーションを保護します。アプリケーション・コンティニュイティにより、影響を受けた処理中のリクエストが再生されるため、障害は実行のわずかな遅延としてしかアプリケーションに表れず、ユーザーは停止に気付きません。

Oracle RACクラスタ全体が停止し、データベースが使用不能になった場合は、Oracle Active Data Guardのフェイルオーバー後に、アプリケーション・コンティニュイティにより、トランザクションを含むセッションが再生されます。スタンバイ・データベースでアプリケーション・コンティニュイティを使用するには、Data Guardの最大可用性モード(データ損失なし)と、Data Guardのファスト・スタート・フェイルオーバー(自動データベース・フェイルオーバー)が必要です。

多くの場合、アプリケーション・コンティニュイティを使用するために、既存アプリケーションのコードを一部変更する必要がありますが、リカバリ可能な障害を透過的に処理できるようになるため、新しいアプリケーションの開発が簡単になります。

7.5.2 Oracle Active Data Guardの遠隔同期

Oracle Active Data Guardは唯一のOracle対応レプリケーション・テクノロジで、データを損失させずにOracle Databaseをフェイルオーバーできます。データ損失ゼロは、Data Guardの最大可用性モードで同期転送を行うことにより実現されます。同期転送を使用すると、プライマリ・サイトとスタンバイ・サイトの間のネットワーク待機時間が、データベース・パフォーマンスに影響を与えます。サイト間の距離が離れるほど、待機時間が長くなり、データベース・パフォーマンスへの影響も大きくなります。プライマリとセカンダリのデータ・センターは遠く離れていることが多いため、データ損失のないフェイルオーバーを実装しても、多くのデータベースにとって実用的ではありません。

Oracle Database 12cでOracle Active Data Guardの遠隔同期を使用すれば、プライマリとスタンバイのデータベースがどれほど離れていても、プライマリ・データベースのパフォーマンスに影響を与えずにデータ損失ゼロのフェイルオーバーを実行できるため、前述の制限がなくなります。これを可能にしているのは軽量の転送メカニズムで、デプロイが簡単な上、Oracle Active Data Guardのフェイルオーバー操作やスイッチオーバー操作に対して透過的です。また、遠隔同期をOracle拡張圧縮オプションと組み合せて使用すると、オフホスト転送圧縮が可能になり、ネットワーク帯域幅を節約できます。

遠隔同期とData Guardのファスト・スタート・フェイルオーバー(自動データベース・フェイルオーバー)を組み合せると、プライマリ・サイトとスタンバイ・サイトの距離にかかわらず、アプリケーション・コンティニュイティにより、処理中のトランザクションが停止の影響を受けません。このため、任意のデータベースに対するデータ損失なしのフェイルオーバーと、サイト間の距離にかかわらず、アプリケーション・コンティニュイティを使用できるという、Platinum層で提供されている2つの重要な拡張を可能にしているのは、遠隔同期ということになります。遠隔同期を使用するために、アプリケーションを変更する必要はありません。

7.5.3 Oracle GoldenGateの停止時間ゼロのメンテナンスおよびアクティブ-アクティブ・レプリケーション

Platinum層では、Oracle GoldenGateのアドバンスト・レプリケーション機能を使用して、停止時間ゼロのメンテナンスと双方向レプリケーションを使用した移行が実装されています。このようなシナリオでは、次のことが行われます。

- メンテナンスが、まずターゲット・データベースに実装されます。

- Oracle GoldenGateの論理レプリケーションを使用して、ソースとターゲットがバージョンを超えて同期されます。これにより、クロスエンディアン・プラットフォーム移行が処理されます。また、バックエンド・オブジェクトを変更する複雑なアプリケーション・アップグレードも処理されますが、その場合は、レプリケーション・メカニズムで、新旧のバージョン間で相互にデータを変換できる必要があります。

- 新しいバージョンまたはプラットフォームが同期されて安定すると、ユーザーが旧バージョンでセッションを終了して再接続するに従って、双方向レプリケーションにより、ユーザーが新しいプラットフォームに徐々に移行され、停止時間が意識されることはありません。Oracle GoldenGateの双方向レプリケーションは、移行プロセス中に、新旧バージョンの同期を維持します。これは、ロードの追加時に、新しいバージョンで予期しない問題が発生した場合のクイック・フォール・バック・オプションにもなります。

アクティブ-アクティブの双方向レプリケーションは、同じデータの複数のコピーに対する継続した読取り/書込み接続が必要とされる可用性サービス・レベルの向上にも使用できます。

双方向レプリケーションは、アプリケーションに対して透過的ではありません。複数のデータベースで、同じレコードに同時に変更が行われた場合には、競合の検出と解決が必要です。また、様々な障害の状態やレプリケーション・ラグの影響についても、慎重に検討する必要があります。バックエンド・データベース・オブジェクトを変更するアプリケーションのアップグレードにGoldenGateの双方向レプリケーションを使用する場合、GoldenGateでバージョンを超えたレプリケートを可能にするには、新しいリリースで変更または追加されるデータベース・オブジェクトについて、開発者レベルの知識が必要になります。アプリケーションの新しいリリースごとに、バージョン間マッピングを実装する必要があります。

定義では、GoldenGateのレプリケーションは非同期プロセスであるため、データ損失ゼロの保護は実現できません。このため、プライマリ・データベースまたはプライマリ・サイトで計画外停止が発生したときに、リモートのレプリカでデータ損失ゼロの保護を実行する必要がある場合、Platinum層では、サイト間のレプリケーションにOracle GoldenGateを使用しません。Platinumでは、GoldenGateの双方向レプリケーションをOracle Active Data Guardと組み合せて使用することで、データ損失ゼロの要件に対応しています。ローカルのGoldenGateレプリカは、停止時間のない計画メンテナンスの実行に使用され、Oracle Active Data Guardのスタンバイは、メンテナンスの進行中に計画外停止が発生した場合に、データ損失ゼロのフェイルオーバー保護を継続して提供します。

7.5.4 エディションベース再定義

エディションベース再定義(EBR)は、アプリケーションの可用性を損なわずに、バックエンド・データベース・オブジェクトを変更する、オンラインでのアプリケーションのアップグレードを可能にします。アップグレードのインストールが完了したら、アップグレード前のアプリケーションとアップグレード後のアプリケーションを同時に使用できます。既存のセッションでは、ユーザーがセッションを終了するまで、アップグレード前のアプリケーションを使用し続けることが可能で、新しいセッションはすべて、アップグレード後のアプリケーションを使用できます。アップグレード前のアプリケーションを使用するセッションがなくなったら、終了させることができます。この方法でEBRを使用すると、アップグレード前のバージョンからアップグレード後のバージョンへのホットロールオーバーが可能になります。

EBRを使用すると、オンラインでのアプリケーションのアップグレードが、次の方法で実行されます。

- コード変更は、新しいエディションにより、暗黙的にインストールされます。

- 古いエディションでは表示されない新しい列または新しい表にのみ書き込むことで、データの変更が安全に行われます。エディショニング・ビューでは、表の異なる投影がそれぞれのエディションに公開されるため、各エディションにはそれ自身の列のみが表示されます。

- クロスエディション・トリガーにより、古いエディションで行われたデータ変更が、新しいエディションの列に、あるいは(ホットロールオーバーで)相互に伝播されます。

Oracle GoldenGateの停止時間なしのアプリケーション・アップグレード同様、EBRを使用するには、アプリケーションに関する深い知識が必要で、開発者がEBRを組み込む際に手間がかかります。Oracle GoldenGateとは異なり、EBRを使用するには、一度作業が必要です。それ以降、後続の新しいリリースのアプリケーションでEBRを使用する際に必要な作業は、最小限になります。EBRは、非常に複雑なアプリケーションにも実装できることが証明されており、たとえばOracle E-Business Suite 12.2では、EBRを使用してオンライン・パッチ適用が実行されます。EBRは、費用のかからないオプションとしてOracle Databaseに含まれている機能で、アプリケーション開発者が適用することをお薦めします。

7.5.5 グローバル・データ・サービス

グローバル・データ・サービス(GDS)は、レプリケートされたデータベース向けに完全に自動化されたワークロード管理ソリューションで、Oracle Active Data GuardまたはOracle GoldenGateが使用されています。GDSを使用するとシステム使用率が高まり、レプリケートされたデータベースで実行されているアプリケーション・ワークロードのパフォーマンス、スケーラビリティおよび可用性が向上します。GDSには、レプリケートされたデータベースのセット向けに、次の機能が用意されています。

- リージョンベースのワークロード・ルーティング

- 接続時ロード・バランシング

- Oracle統合クライアント用のランタイム・ロード・バランシング・アドバイザ

- 内部データベース・サービス・フェイルオーバー

- Oracle Active Data Guard用のレプリケーション・ラグに基づいたワークロード・ルーティング

- Oracle Active Data Guard用のロールベースのグローバル・サービス

- ワークロードの集中管理フレームワーク

7.5.6 Platinumの概要: データ保護、RTOおよびRPO

Platinum層の破損保護は、Gold層と同一です。Platinum層とGold層の違いは、Platinum対応アプリケーションのリカバリ時間(RTO)とデータ損失の可能性(RPO)です。Platinum層のRTO/RPOを表7-6にまとめます。

表7-6 Platinum層のリカバリ時間(RTO)およびデータ損失の可能性(RPO)

タイプ

イベント

停止時間

データ損失の可能性

計画外

データベース・インスタンス障害

アプリケーションの停止なし(Goldでは数秒)

ゼロ

計画外

リカバリ可能なサーバー障害

アプリケーションの停止なし(Goldでは数秒)

ゼロ

計画外

データ破損、リカバリ不能なサーバー障害、データベース障害またはサイト障害

アプリケーションの停止なし(Goldではゼロから数分)

ゼロ(Goldではほぼゼロ)

計画

オンライン・ファイル移動、オンライン再編成および再定義、オンライン・パッチ適用

ゼロ

ゼロ

計画

ハードウェアやオペレーティング・システムのメンテナンス、およびオンラインで適用できないデータベース・パッチ

アプリケーションの停止なし

ゼロ

計画

データベースのアップグレード: パッチ・セットおよび完全なデータベース・リリース

アプリケーションの停止なし(Goldでは数秒)

ゼロ

計画

プラットフォームの移行

アプリケーションの停止なし(Goldでは数秒)

ゼロ

計画

バックエンドのデータベース・オブジェクトを変更するアプリケーションのアップグレード

アプリケーションの停止なし(Goldでは数時間から数日)

ゼロ

7.6 Oracle Fusion Middlewareの高可用性の統合

柔軟性のある自動高可用性ソリューションを使用することで、ビジネス目標の達成に必要な(Oracle WebLogic Serverにデプロイする)アプリケーションの可用性を確実に満たすことができます。このマニュアルで説明するソリューションの詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。

この項の内容は、次のとおりです。

- Oracle WebLogic Serverの高可用性アーキテクチャ

- 冗長アーキテクチャ

- Oracle Fusion Middlewareでの高可用性サービス

関連項目:

- 『Oracle Fusion Middlewareディザスタ・リカバリ・ガイド』

- 『Oracle Fusion Middleware管理者ガイド』の高度な管理(バックアップとリカバリ)に関する項

7.6.1 Oracle WebLogic Serverの高可用性アーキテクチャ

Oracle WebLogic Serverには、あらゆる障害に対する最大の保護を目的とした高可用性および障害時リカバリ・ソリューションがあり、インストール、デプロイメントおよびセキュリティにおける柔軟性の高いオプションが用意されています。これらのソリューションは、ローカル高可用性ソリューションと障害時リカバリ・ソリューションに分類されます。ローカル高可用性ソリューションは、単一データ・センターのデプロイメントで高可用性を提供します。障害時リカバリ・ソリューションは、一般的に地理的に分散されたデプロイメントで、洪水や広範囲のネットワーク停止などの災害からアプリケーションを保護します。

高度なレベルで、Oracle WebLogic Serverのローカルの高可用性アーキテクチャには、アクティブ-アクティブおよびアクティブ-パッシブのアーキテクチャがあります。どちらのソリューションも高可用性を提供しますが、通常、アクティブ-アクティブ・ソリューションの方が、高いスケーラビリティと高速フェイルオーバーを提供します。ただし、費用が高額になる傾向があります。アクティブ-アクティブまたはアクティブ-パッシブのカテゴリでは、インストール、コスト、スケーラビリティおよびセキュリティの容易さが異なる複数のソリューションがあります。

関連項目:

- 『Oracle Fusion Middlewareディザスタ・リカバリ・ガイド』

- MAAベスト・プラクティス- Oracle Fusion Middleware

7.6.2 冗長アーキテクチャ

Oracle WebLogic Serverでは、同じワークロードをサポートする複数のインスタンスをサポートすることにより、冗長性が得られます。このような冗長構成では、ワークロードの分散またはフェイルオーバーの設定のいずれか、またはその両方によって可用性が向上します。

Oracle WebLogic Serverシステムへのエントリ・ポイント(コンテンツのキャッシュ)からバック・エンド層(データ・ソース)まで、リクエストが通過するすべての層は、Oracle Application Serverを使用して冗長方式で構成できます。この構成は、Oracle WebLogic Server Clusterを使用したアクティブ-アクティブ構成、またはOracle WebLogic Server Cold Cluster Failoverを使用したアクティブ-パッシブ構成のいずれかになります。

7.6.3 Oracle Fusion Middlewareでの高可用性サービス

『Oracle Fusion Middleware高可用性ガイド』では、次に示すOracle Fusion Middlewareの高可用性サービスを詳細に説明しています。

- プロセス停止の検出と自動再起動
Oracle WebLogic Serverノード・マネージャは管理対象サーバーを監視します。管理対象サーバーが停止すると、ノード・マネージャは、構成された回数にわたって、管理対象サーバーの再起動を試行します。

- クラスタリング
Oracle Fusion Middlewareでは、冗長性、フェイルオーバー、セッション状態レプリケーション、クラスタワイドのJNDIサービス、サーバー全体の移行、クラスタワイドの構成など、WebLogicが持つクラスタリング機能を使用します。

- 状態のレプリケーションとルーティング
Oracle WebLogic Serverは、ステートフル・アプリケーションの状態をレプリケートするように構成できます。

- ロード・バランシングおよびフェイルオーバー
Oracle Fusion Middlewareには、Oracle RACデータベースの可用性およびスケーラビリティを活用するため、ロード・バランシングおよびフェイルオーバーの周囲に総合的な機能セットがあります。Oracle Fusion Middlewareのすべてのコンポーネントには、計画停止または計画外停止によってOracle RACインスタンスが使用できなくなったことが原因で発生した、サービス、データまたはトランザクションの消失に対する組込みの保護が用意されています。

- サーバーの移行
Oracle Fusion Middlewareのコンポーネントは、WebLogic Serverの機能を活用して、フェイルオーバー時に別のクラスタ・メンバー上で自動的に再起動できます。

- ローリング・パッチ適用
Oracle WebLogic Serverでは、ローリング・パッチを使用できます。ローリング・パッチでは、クラスタ全体を停止することなく、マイナーなメンテナンス・パッチをローリング形式で製品バイナリに適用できます。

- 構成管理
Oracle Fusion Middlewareコンポーネントのほとんどは、クラスタ・レベルで構成できます。Oracle Fusion Middlewareでは、データ・ソース、EJB、JMSなど、サーバーを構成するためのWebLogic Serverのクラスタワイドの構成機能、およびコンポーネントのアプリケーション・アーティファクト、ADFおよびWebCenterのカスタム・アプリケーションを使用します。

- バックアップとリカバリ
Oracle Fusion Middlewareのバックアップとリカバリは、中間層コンポーネントのファイル・システム・コピーに基づく単純なソリューションです。

関連項目:
Oracle Fusion Middleware高可用性ガイド

7.7 すべてのアプリケーションの高可用性の統合

可用性が高く、リジリエンスがあるアプリケーションでは、アプリケーションのすべてのコンポーネントで障害および変更が許容される必要があります。可用性の高いアプリケーションは、そのアプリケーションに影響を与えるすべてのコンポーネント(ネットワーク・トポロジ、アプリケーション・サーバー、アプリケーションのフローと設計、システム、およびデータベースの構成やアーキテクチャなど)を分析する必要があります。このマニュアルでは、主にデータベースの高可用性ソリューションに焦点を当てています。

Oracle Fusion Middleware、Oracle Fusion Applications、Oracle Enterprise ManagerおよびOracle Applications Unlimitedの高可用性ソリューションおよび推奨事項を次のMAA Webサイトで参照してください。

http://www.oracle.com/goto/maa

8 Oracle Engineered Systems

Oracleは高可用性環境でOracle Databaseを実行するように特に設計された3つの設計されたシステムを提供しています。

- Oracle Exadata Database Machine - Oracle Databaseの実行に対し最も高いパフォーマンスと最も高い可用性

- Oracle SuperCluster - Oracle Databaseおよびアプリケーションに最適な多目的エンジニアリング・システム

- Oracle Database Appliance - 最も単純で高可用性なOracle Databaseアプライアンス

8.1 Oracle Exadata Database Machine

Oracle Exadata Database Machineは事前に最適化および構成が行われたソフトウェア、サーバーおよびストレージを備えた設計されたシステムで、現在のベスト・プラクティスに構成され、スキャン集中型のデータ・ウェアハウス・アプリケーションから同時実行性の高いOLTPアプリケーションまで、あらゆるデータベース・ワークロードに対して最適なソリューションを提供します。Oracle Exadata Storage Server Software、Oracle Databaseソフトウェアおよびハードウェア・コンポーネントを組み合わせることにより、可用性が高く、非常にセキュアな環境で卓越したパフォーマンスを実現します。Oracle特有のクラスタリングおよびワークロード管理機能により、Database Machineは複数のデータベースを単一グリッドへ統合するのにも適しています。

Exadata Database MachineはOLTP、データ・ウェアハウス・アプリケーション、データベースの統合、メモリー集中型のワークロードおよびクラウド・コンピューティングに高いパフォーマンス、スケーラビリティおよび可用性を提供するように設計されています。これはOracle Database機能に焦点を当てた唯一の設計されたシステムで、Exadata Smart Flashテクノロジ、Exadata I/Oリソース管理、Exadataスマート・オフロード機能を使用して、すべてのデータベース・ワークロードに対して完全に最適化されています。データベースのパフォーマンス、スケーラビリティおよび可用性の最適な組合せのために、Exadata MAAアーキテクチャを使用します。

Oracle Exadata Database Machineハードウェアは単一障害点のない状態では完全に冗長です。Oracle Exadata Database Machineで使用されるOracleソフトウェアは、MAAベスト・プラクティスとともに使用されて、次の利点を備えたフォルト・トレラント・システムを生成します。

- Oracle RACを使用したノードおよびインスタンスの障害全体にわたるデータベースの連続可用性

- Oracle ASMおよびOracle Exadata Storage Serverソフトウェアを使用したディスクおよびセルの障害全体にわたるデータ保護およびデータベースの連続アクセシビリティ

- Oracle ASM自動修復メカニズム、Exadataストレージ内の組込み破損チェックおよび推奨されるデータベースのデフォルト設定(db_block_checksum、db_lost_write_protect)を使用した、データ破損の防止および自動修復。

- アイドル・リソースがある場合に、Exadataの自動ハード・ディスク修正および修復で、破損または消耗しているディスク・セクター(ストレージのクラスタ)があるハード・ディスクや、その他の物理的または論理的な不具合を定期的に検査および修復

- 冗長およびフォルト・トレラント・ネットワーク、ケーブルおよびサーバー相互接続

- Oracle Exadata Database Machineまたはマシンが存在するデータ・センターで障害が発生した場合に、Oracle Active Data GuardまたはOracle GoldenGateを使用して、データベース・サービスを迅速に再構築できる機能を提供

計画メンテナンスに対し、Exadata Database Machineは次の利点をもたらします。

- Oracle ASM、Oracle ClusterwareおよびOracle RACローリング・アップグレードまたはソフトウェア変更のサポート

- Oracle Exadata Storage Server Softwareのパッチ用ローリング・アップグレードのサポート

- Data GuardおよびOracle GoldenGateを使用したアプリケーションおよびシステム変更が可能

- Oracle Databaseで使用できるオンライン・メンテナンス機能のすべてをサポート

- グリッド・インフラストラクチャとOracle Databaseソフトウェア、データベース・サーバーのオペレーティング・システムとファームウェア(dbnodeupdate.shのみ)、およびすべてのExadataサーバーとインフィニバンド・スイッチ(patchmgrのみ)に、ローリング方式で自動的にパッチを適用するためのツールとOracle Enterprise Manager 12cのサポートを提供。

Exadata Database Machineを使用すると、Oracle Database高可用性アーキテクチャの選択が簡略化され、ExadataがすべてのMAA参照アーキテクチャに適用されます。MAA参照アーキテクチャの詳細は、第7章「高可用性アーキテクチャ」を参照してください。

Exadataは、MAA層およびデータベース統合に推奨のプラットフォームです。http://www.oracle.com/technetwork/database/availability/maa-consolidation-2186395.pdfのMAAホワイト・ペーパー『データベース統合の高可用性ベスト・プラクティス: Database-as-a-Serviceの基盤』を参照してください。

推奨するExadata MAAアーキテクチャは次の3つの要素から構成されます。1)本番Exadataシステム(プライマリ)、2)スタンバイExadataシステム、および3)Exadataテストまたは開発システム。

2番目の要素は、プライマリのレプリカであるActive Standby Exadataシステムの場合もあり、これにはExadata Database Machineのすべての利点(3.1項「Oracle Data Guard」参照)が含まれます。

3番目の要素は、6.3項「テスト・プラクティスおよび環境の構築」の説明のとおり、プライマリおよびスタンバイExadataシステムとは独立した、開発/テストExadataシステムの場合があります。

OracleのExadataヘルス・チェック(exachk)を毎月実行することをお薦めします。これはExadataソフトウェア、ネットワーク、およびハードウェア・コンポーネントの最も包括的な構成チェックを提供し、MAAベスト・プラクティスとの差異をレポートするからです。Exadataに特有のその他のデプロイ後および運用のベスト・プラクティスは、第6章「可用性を最大化するための運用前提条件」およびOracle Exadata Database MachineのMAAベスト・プラクティスに関するMAAのホワイト・ペーパーに記述されています。exachkの詳細は、My Oracle Supportのノート1070954.1を参照してください。

MAA構成ベスト・プラクティスは、Exadata Database MachineおよびExadata Cellの最初のインストールおよびデプロイ中に引き続き統合され組み込まれます。

関連項目:

- OTN Exadata MAA Webサイト: http://www.oracle.com/technetwork/database/features/availability/exadata-maa-best-practices-155385.html

- Oracle Exadata Database MachineのMAAベスト・プラクティス(テクニカル・ホワイト・ペーパー) http://www.oracle.com/technetwork/database/features/availability/exadata-maa-131903.pdf

- 『Oracle Exadata Database Machineオーナーズ・ガイド』

- 『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』

- Oracle Technology NetworkでのOracle Exadata Database Machine:
http://www.oracle.com/us/products/database/exadata/overview/index.html

8.2 Oracle SuperCluster

Oracle SuperCluster T5-8およびM6-32は、様々なミッション・クリティカル・アプリケーションを統合し、クラウド・サービスを迅速にデプロイするための多目的エンジニアド・システムです。Oracle SuperCluster T5-8およびM6-32は、T5-8およびM6-32サーバー、ZFS Storage Appliance、インフィニバンド・テクノロジ、Oracle Solaris 11およびOracle Enterprise Manager Ops Center 12cの統合されたシステム管理と組み合された、Oracle Exadata Storage ServersとOracle Exalogic Elastic Cloudの高パフォーマンス・テクノロジを利用します。Oracle SuperClusterを加え、Oracleは、テスト済の完全なパッケージで最高レベルのパフォーマンスにより、顧客の価値を最大化するという、エンジニアド・システムの標準を示し続けます。Oracle SuperCluster M6-32は、最大32TBのメモリーと最大32基のSPARC M6プロセッサまで柔軟に拡張できるため、インメモリー処理が必要なアプリケーションに最適です。

Oracle SuperClusterは理想的には、既存のSPARCデータベースの顧客、または様々なデータベース・リリース(Exadataの場合はOracle 10g以上をOracle 11g以上とのみ比較)とアプリケーション・サーバーの組合せをホストする多目的エンジニアド・システムを好む顧客をターゲットとしています。Oracle SuperClusterにはZFSストレージ・クラスタを使用した追加の共有ストレージがあり、これはデータベース以外のファイルに使用でき、Oracle VM Server for SPARCおよびOracle Solaris Zonesによる仮想化サポートもあります。Exadata Database Machineは引き続き推奨するデータベース・マシンですが、多目的ソリューションが必要な場合、Oracle SuperClusterであれば、アプリケーション層にその他の機能が提供されます。

特に、多目的のデータベースおよびアプリケーションの処理システムが必要な場合、MAAサービス・レベル層アーキテクチャには、Oracle SuperClusterをお薦めします。Oracle SuperCluster M6-32は、どのOracleエンジニアド・システムにも、インメモリー・フットプリントを提供します。また、フルスタックのフェイルオーバーまたはスイッチオーバーの場合で、データベース以外のファイルを保護する必要がある場合、Data GuardとZFSストレージ・リモート・ミラーリングの組合せを使用できます。OracleのExadataヘルス・チェック(exachk)を毎月実行することもお薦めします。これはExadataソフトウェア、ネットワーク、およびハードウェア・コンポーネントの最も包括的な構成チェックを提供し、MAAベスト・プラクティスとの差異をレポートするからです。exachkの詳細は、My Oracle Supportのノート1070954.1を参照してください。

8.3 Oracle Database Appliance

Oracle Database Applianceは、デプロイメント、メンテナンス、および高可用性データベース・ソリューションのサポートを簡略化することにより、顧客の時間とお金を節約する、ハードウェアおよびソフトウェアから構成される設計されたシステムです。Oracle Real Applications Clusters (Oracle RAC)およびOracle Automatic Storage Managementのベスト・プラクティスで構築され、ソフトウェア、サーバー、ストレージおよびネットワークを1つのボックスに完全に統合したシステムを顧客に提供し、広範囲の自身で作成およびパッケージ化したOLTPおよびデータ・ウェアハウスのワークロードに対して高可用性データベース・サービスを提供します。Oracle Linuxで稼働する2サーバー・ノード、18TBのRAWストレージおよびSSD容量が800GBの4RU (ラック・ユニット)サーバー・アプライアンスとして出荷されますが、オプションの拡張シェルフを使用すればこれを2倍にすることが可能で、ストレージは36TBのRAW、SSDは1.6TBになります。

高可用性システムの構築は、困難で複雑である可能性があり、多くの組織が持っていないような高度な統合スキルを必要とする場合があり、ベンダーのアカウンタビリティなしでは危険でエラーが発生しやすくなります。Oracle Database Applianceは簡易で、信頼でき、値段が手ごろです。

- 簡易
Oracle Database Applianceをデプロイおよび使用するには、開封して、電源コードとネットワーク・ケーブルを差し込み、Oracle Appliance Managerインストールを実行して、クラスタ化された高可用性データベースを作成するだけです。Oracle Database Applianceおよびその特別に設計されたソフトウェアにより、ソフトウェア・スタックのすべての要素(ファームウェア、オペレーティング・システム、クラスタウェア、ストレージ・マネージャおよびデータベース・ソフトウェア)に対し「1ボタン」パッチ適用が可能になります。

- 信頼性
Oracle Database ApplianceはOracleソフトウェア・スタックに構築されて、2サーバー・ノード間の600GB SASハード・ディスク・ドライブを含む記憶域とともに完全に統合され、二重または三重ミラー化されて高可用性共有記憶域を提供できます。このアプライアンスは、インスタンス障害の場合にOracleデータベースを保護するために三重ミラー化されたSAS Solid State DrivesをREDOログ用に含むことができます。アプライアンス・マネージャはOracle Automatic Storage Management (ASM)とともに、パフォーマンスおよび可用性のためにディスクを自動的に構成、管理および監視します。Oracle Appliance Managerは、ハード・ディスク障害の場合に置換ドライブを自動的に構成するだけでなく、パフォーマンスおよび可用性イベントの場合にアラートを提供します。

- 手頃な値段
Oracle Database Applianceでは、データベースのデプロイ用に、必要に応じて容量を追加できるプラットフォームが提供されるだけでなく、最初に、ベア・メタル・オプションの最小4コアをライセンスし、追加のコアはいつでもアクティブ化できるため、ライセンス・コストを最小化できます。Oracle VMのハード・パーティショニングを使用してデータベースとその他のワークロードを分離できるため、仮想化によって、ライセンスの柔軟性がさらに高まります。

簡易さを高く評価し、高可用性データベース・ソリューションのデプロイにおいて複雑さ、コストおよびリスクを回避しようとする顧客にとって、Oracle Database Applianceは理想的なデータベース・アプライアンスです。Oracle Database Applicationは、Exadataソフトウェア機能と追加の可用性(ローリング・パッチ・アップグレード対ソフトウェア・スタックのすべての要素に対する「1ボタン・パッチ」)によるExadata Database Machineの追加のパフォーマンスおよびスケーラビリティを必要としないデータベース顧客にも理想的です。顧客は特別なスキルやHAの専門知識がなくても高可用性(HA)データベース・ソリューションの利点を得ることができます。

小規模な環境に、統合密度の高い標準プラットフォームが必要な場合、Oracle Database Applianceは、MAAサービス・レベル層アーキテクチャ向けの選択肢の1つです。推奨するOracle Database ApplianceExadata MAAアーキテクチャは次の3つの要素から構成されます。1)本番Oracle Database Applianceシステム(プライマリ)、2)スタンバイOracle Database Applianceシステム、および3)Oracle Database Applianceテストまたは開発システム。オペレーティング・システム、グリッド・インフラストラクチャおよびデータベース設定で、包括的に構成をチェックするために、Oracleヘルス・チェック(orachk)を実行することをお薦めします。orachkの詳細は、My Oracle Supportのノート1268927.2を参照してください。

Oracle Database Applianceの詳細は、http://www.oracle.com/technetwork/server-storage/engineered-systems/database-appliance/index.htmlを参照してください。

9 投資利益率の最適化

Oracle MAAリファレンス・アーキテクチャは、デプロイされているすべてのシステムおよびソフトウェアで高い投資利益率(ROI)を実現しつつ、高可用性とデータ保護を提供します。これは、統合環境でワークロードを効率的に管理し、常にすべてのシステムを生産的な目的のために積極的に利用することによって実現されます。これにより、機能停止が発生するまでアイドル状態のままのシステムでの費用のかかる過剰容量やオーバープロビジョニングを排除できます。

Oracle MAAリファレンス・アーキテクチャはどの商品プラットフォームにもデプロイ可能ですが、Oracle Engineered Systemにデプロイした場合に大きな利益を得られます。Oracle統合ハードウェアおよびソフトウェア・システムは、パフォーマンス、信頼性、管理性、サポートといった複数のディメンションに沿って、統合環境およびDBaaSで規模の経済を実現する標準および高パフォーマンス・プラットフォームを使用することで、ライフ・サイクル・コスト合計を引き下げます。　その過程で、Oracle Engineered Systemは、企業の投資利益率を高めるタスクに集中するのを妨げる日常的なシステム統合作業からITスタッフを解放します。

ひとまとめにすると、これらの機能により、プライベートまたはパブリック・クラウドでデータベース統合およびDatabase as a Service (DBaaS)のデプロイのための戦略的イニシアチブに着手する際、企業は希望する目標を達成できます。

この章の内容は次のとおりです。

- グリッド・コンピューティングを使用した高ROI

- アクティブ・スタンバイ・データベースを使用した高ROI

- Oracle Database統合を使用した高ROI

- Oracleグローバル・データ・サービスを使用した高ROI

9.1 グリッド・コンピューティングを使用した高ROI

グリッド・コンピューティングとは、あらゆる企業のコンピューティング・ニーズに応えるため、多数のサーバーおよびストレージを柔軟性のあるオンデマンド・コンピューティング・リソース内に効果的にプールするコンピューティング・アーキテクチャです。

Oracle Databaseには、パフォーマンス、スケーラビリティ、セキュリティ、管理性、機能性またはシステム可用性を犠牲にせずに、コスト面におけるグリッド・エンタープライズ・コンピューティングの利点が取り込まれています。

- データベース・サーバー・グリッドは、1つ以上のデータベースを実行するために接続された汎用サーバーの集合です。

- データベース・ストレージ・グリッドは、データベース・サーバー・グリッド内のサーバーからアクセスされる低コストのモジュラ・ストレージ・アレイの集合です。

同じグリッド・コンピューティングの概念が、スタンバイ・データベース環境と同様にプライマリにも適用されます。図9-1に、エンタープライズ・グリッド・コンピューティング環境でのデータベース・サーバー・グリッドおよびデータベース記憶域グリッドを示します。

図9-1 グリッド・コンピューティング環境

9.1.1 データベース・サーバー・グリッド

Oracle Real Application Clustersはデータベース・サーバー・グリッドを有効にするテクノロジです。Oracle RACは、Oracle Databaseの読取り/書込みワークロードをクラスタ内のノード全体に自動的に負荷分散するアクティブ/アクティブ・ソリューションです。Oracle RACによって、動的プロビジョニング・リソースおよびサービスに柔軟性が与えられ、容量への需要の変化に合せてシステムを追加したり、グリッドからシステムを削除できます。また、Oracle RACでは、クライアントの自動遷移、および障害が発生したノードから同じOracle RACデータベースが実行している残りのノードに処理を再分散することで、システム障害からの保護が提供されます。

9.1.2 データベース・ストレージ・グリッド

Oracle Storage GridはOracle Automatic Storage Management (Oracle ASM)を使用して、サードパーティ・ストレージまたはOracle Database: Oracle Exadata Storage Server、Oracle ZFSストレージまたはPillar SAN Storage Systems向けに最適化されたストレージとともに実装されます。

データベース管理者は、Oracle ASMインタフェースを使用して、Oracle ASMが管理するデータベース・ストレージ・グリッド内のディスクを指定できます。Oracle ASMは、ディスク領域をパーティション化し、ストレージ・アレイ全体でデータ記憶域を均一に分散します。さらに、ディスクまたはストレージ・アレイがデータベース・ストレージ・グリッドに追加または削除される際、Oracle ASMはデータの場所を自動的に再バランスしてホット・スポットを排除し、データを再分散します。

I/Oリソース管理(Exadataストレージにのみ使用可能)を使用してI/Oパフォーマンスを管理し、統合環境でのサービスレベル要件を満たします。リソース・マネージャは、データベース内またはデータベース間でのストレージ・グリッドおよび優先アプリケーションの管理を可能にします。

9.2 アクティブ・スタンバイ・データベースを使用した高ROI

Data Guardスタンバイ・データベースは、停止の原因や範囲に関係なく、データ保護、可用性および障害時リカバリを提供します。停止の原因は、個々のデータベースに影響するデータ破損から広い地域に影響を及ぼす自然災害まで様々です。

Data Guardの高度な機能は、スタンバイ・ロールでもスタンバイ・データベースを(読取り専用問合せやレポート作成などの)本番用に使用することを可能にし、最大のROIをもたらします。スタンバイ・データベースをアイドル状態にしておくかわりに、これらをワークロードに利用できるため、サポートのために追加の容量を購入する必要がありません。これにより、Data Guardスタンバイをデプロイするコストが効果的に削減され、最適なデータ保護および可用性が実現します。Oracle Active Data Guardはすべてのデータ・タイプ、ワークロードおよびアプリケーションをサポートすることで(制限や制約はありません)、すべてのOracle Databaseに高度なデータ保護を提供します。非定型の問合せ、レポート、データ抽出のために読取り専用で開いているデータベースを利用できるアプリケーションはすべて、Oracle Active Data Guardスタンバイ・データベースを利用してプライマリ本番システムからワークロードをオフロードできます。

次の項では、高いビジネス使用率と最大の投資利益率を提供する、Data Guardのシナリオについて説明します。

- フィジカル・スタンバイ・データベースのOracle Active Data Guardオプション

- Oracle Active Data Guardリーダー・ファーム

- Data GuardおよびCloud (Data Protection as a Service)

9.2.1 フィジカル・スタンバイ・データベースのOracle Active Data Guardオプション

Data GuardのREDO Apply(フィジカル・スタンバイ・データベース)は、相対的に簡単なことと、高パフォーマンスおよび高度なデータ保護のために、魅力的な障害時リカバリ・ソリューションになっています。Oracle Active Data Guardオプション脚注 1 (Oracle Database 11gリリース1(11.1)以降のリリースで使用可能)を使用すると、REDO適用がアクティブである間、読取り専用アクセスのためにフィジカル・スタンバイ・データベースをオープンできます。

Oracle Active Data Guard 12cは次の新機能が追加されて拡張されています。

- DMLをグローバル一時表に含むレポートおよび非定型問合せのオフロード

- アクティブ・スタンバイでの一意のグローバルまたはセッション順序のサポート

- 複数のリモート宛先に効率的にサービスを提供するためのリアルタイム・カスケード

- プライマリ・データベースのパフォーマンスに影響を与えずに、データ損失ゼロの保護をリモート・スタンバイ・データベースに拡張する機能 - Active Data Guard遠隔同期

- オフホストREDO転送圧縮を実行する機能

- データベースのローリング・アップグレードを使用して計画ダウンタイムの削減を簡易化する自動化

9.2.2 Oracle Active Data Guardリーダー・ファーム

Active Data Guardを使用して複数のアクティブ・スタンバイ・データベースをデプロイし、読取りパフォーマンスを容易に高めます。これは、リーダー・ファームとも呼ばれます。このような構成の例を図9-2に示します。この図は、プライマリ・データベースに障害が発生した場合、Data Guardのファスト・スタート・フェイルオーバーを使用してフェイルオーバーが自動的に行われることを示しています。フェイルオーバーが行われると、リーダー・ファームのすべてのスタンバイ・データベースは、新しいプライマリ・データベースを自動的に認識することに注意してください。

リーダー・ファームを使用すると、アプリケーションでは、基本的なシステムおよびストレージ・アーキテクチャのサポート可能範囲を超えて、最も要求の厳しいWebアプリケーションの読取りパフォーマンスを向上できます。これにより、単にOracle Active Data Guardスタンバイ・データベースを追加することで拡張を行う、比較的低コストの方法が可能になります。

Oracle Active Data Guardリーダー・ファームには次のような利点があります。

- 簡潔性

- フォルトの分離

- フィジカル・スタンバイ・データベースとREDO Applyによる高パフォーマンス

- REDO Applyを使用した、すべてのDDLとデータ型のシームレス・サポート

- プライマリ・データベースの変更を含めて、すべてのリーダー・データベースを最新の状態に維持

- 自動(ファスト・スタート・フェイルオーバー)または手動フェイルオーバー

- データ損失の可能性がゼロまたはほぼゼロ

- グリッド・コントロールによる一元的な構成としての管理

- 1つのライター・データベースとn個のリーダー・データベースを使用した拡張

- ローリング・アップグレード機能

- Global Data Servicesを使用した本番データベースまたはその他のスタンバイ・データベースへの統合されたクライアント・フェイルオーバー

図9-2 スタンバイ・データベースのリーダー・ファーム

図9-2のData Guard構成で、ファスト・スタート・フェイルオーバーがトリガーされるとします。

- 自動フェイルオーバーは目的のスタンバイ・データベースに対して行われます。

- すべてのスタンバイ・データベースは新しいプライマリ・データベースからデータを受け入れます。

- スイッチオーバーを適宜実行して、すべてのデータベースを元のロールに戻すことができます。

9.2.3 Data GuardおよびCloud (Data Protection as a Service)

Oracle Active Data Guardはパブリック、プライベートおよびハイブリッド・クラウドにData Protection as a Serviceを提供し、これによりOracle Enterprise Manager Grid Controlをスタンバイ・データベースのセルフサービス・プロビジョニングに使用できます。Oracle Engineered Systemは、クラウド・サービスを提供するための拡張可能なプラットフォームを提供します。クラウドにデプロイされたスタンバイ・データベースでは、開発およびテスト目的でのクローニングもサポートしています。次に例を示します。

- 構内のプライマリ・データベースは、Active Data Guard遠隔同期インスタンスを使用して、パブリック・クラウドにデプロイされたスタンバイ・データベースにREDOを直接または間接的に転送できます。構内のプライマリおよびパブリック・クラウド・スタンバイの組合せは、ハイブリッド・クラウド・デプロイメントと呼ばれます。

- スタンバイ・ハブを使用して、プライベート・クラウドにデータ保護を提供できます。スタンバイ・ハブは、多くの異なるデータ・センターに分散されたプライマリ・データベースにスタンバイ・データベースを一元的にホストするデータベース・サービス・グリッドで構成されています。

- パブリック・クラウドにデプロイされたデータベースは、データ可用性および障害保護を高めるためにパブリック・クラウド・ベンダーから提供された、別の可用性ゾーンにデプロイされたスタンバイ・データベースを持つこともできます。

- パブリック・クラウドにデプロイされたスタンバイ・データベースは開発またはテスト目的でクローニングしたり、Data Guardスナップショット・スタンバイを使用してテスト・システムとして直接使用できます。

9.3 Oracle Database統合を使用した高ROI

企業は、より少ないコストでより多くのことをこなし、リスクを減らして機動力も高める必要があるという重圧の下にあります。情報技術(IT)インフラストラクチャの積極的な統合と、パブリックまたはプライベートのクラウドへのDatabase as a Service (DBaaS)のデプロイメントは、そうした目標を達成するために、多くの企業が推し進めている戦略の1つです。

データベース統合やDBaaSによるコスト削減の可能性をすべて実現するために、欠かすことのできない、重要な要素がいくつかあります。統合密度の高さと管理のしやすさは、ハードウェアおよび管理のコストを最大限削減する上で不可欠です。こうした特性を、可用性、パフォーマンスおよびデータ保護に関するサービス・レベル合意(SLA)を達成できる、インテリジェントなソフトウェア・インフラストラクチャと結び付ける必要があります。

9.3.1 マルチテナント・アーキテクチャ

Oracle Multitenantは、マルチテナント・コンテナ・データベース(CDB)とプラガブル・データベース(PDB)の概念を導入し、Oracle Databaseのアーキテクチャを抜本的に変更したものです。既存のデータベースは、簡単にPDBに変換できます。統合は、複数のPDBを単一のCDBに接続して行います。Oracle Multitenantを備えたOracle Database 12cは、データベース統合のあらゆる面で、最も効率的なプラットフォームを実現するために設計されました。

CDBには、バックグラウンド・プロセスと共有メモリー領域(SGA)が1セット存在し、すべてのPDBによって使用されます。このアーキテクチャなら、独立した複数のデータベースを単一の物理マシンや複数の仮想マシン(VM)、あるいはOracle RACクラスタに統合する従来の方法より、CPUとメモリーが少なくてすみます。CDBは物理環境にも仮想環境にもデプロイできますが、物理マシンにデプロイすると、データベース層の管理効率とパフォーマンス効率が非常に高まります。CDB自体がデータベース層の仮想化テクノロジとなり、複数のVMやゲスト・オペレーティング・システムのオーバーヘッドがなくなります。

Oracle Multitenantの分離機能も高度なものです。PDBはあるCDBから簡単に切断して別のCDBに接続できるため、データベース管理者は、必要な場合には、PDBを個別にメンテナンスできます。同じCDB内のその他のPDBに影響を与えずに、個々のPDBのプロビジョニング、パッチ適用、クローニング、統合、リストアまたは移動を実行できます。

Oracle Multitenantは、その他の統合方法の有益な特性を取り入れ、短所を排除しているという点で唯一無二です。Oracle Multitenantは次のことを実現します。

- 統合密度やパフォーマンスに制限がなく、管理が複雑になることもない、簡素で柔軟なVM

- 実装が簡単で、柔軟性や分離性が制限されることのない、高い密度でのスキーマ統合

- Oracle RACとOracle Database 12cを組み合せて使用することにより、統合密度が制限されることや、各アプリケーション用の個別のデータベース(それぞれに独自のオーバーヘッドあり)の管理が複雑になることのない、簡素なデータベース統合のHA、スケーラビリティおよび自動ワークロード管理

Oracle Multitenantは、Oracle DatabaseのHAとデータ保護の機能をシームレスに統合します。この統合とOracle Maximum Availability Architecture (MAA)のベスト・プラクティスとの組合せが、データベース統合の画期的なテクノロジへと歩を進める進化の道となります。

関連項目:

- データベース統合にOracle Multitenantの利点を最大限に活かすには、MAAホワイト・ペーパー『データベース統合のベスト・プラクティス: Oracle Maximum Availability Architecture』を参照してください。

- プラガブル・データベースの作成と管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

9.3.2 Oracle Virtualization

現在のデータ・センターは、仮想化技術を使用して物理ハードウェアを抽象化し、CPU、メモリー、ディスク、ファイル記憶域、アプリケーション、ネットワークからなる論理リソースの大規模な集約プールを作成し、これらのリソースをアジャイルかつスケーラブルな、統合された仮想マシンの形式でユーザーまたは顧客に提供します。テクノロジと使用事例が進化を遂げても、人とハードウェア・リソースの節約を主な意図とし、コンピューティング環境で同時に複数の独立したシステムの実行を可能にするという、仮想化の中心的な意味は変わっていません。

Oracleには次の3つの主要な仮想化テクノロジがあります。

- Oracle VM for X86およびOracle VM Managerはエンタープライズ・クラス・サーバーの仮想化ソリューションです。Oracle VM Server for x86は現在、市場で最もスケーラブルなx86サーバー仮想化ソリューションで、最大160の物理CPUと2TBのメモリーをサポートし、ミッション・クリティカルなエンタープライズ・ワークロードを処理するようにテストされています。仮想マシンの場合、Oracle VM 3はゲストVM当たり最大128の仮想CPUと1TBメモリーをサポートできます。Oracle VMは業界標準のx86オペレーティング・システムと、Oracleやその他の主要ベンダーからのサーバーをサポートし、使用環境に統合しやすくする、広範囲のネットワークおよびストレージ・デバイスをサポートします。Oracle VM Managerはサーバー、ネットワーク、ストレージ・インフラストラクチャの構成に対し、ブラウザ・ベースのインタフェース(Javaクライアントが不要)から、使いやすい集中管理環境を提供します。さらに、これはどこからでもアクセスが可能です。

- Oracle VM Server for SPARCは、非常に効率的なエンタープライズ・クラスの仮想化機能をOracleのSPARC T-Seriesサーバーに提供します。Oracle VM Server for SPARCソフトウェアを使用すると、1つのシステムに最大128の仮想サーバー(論理ドメインと呼ばれます)を作成できます。この種の構成では、SPARC T-SeriesサーバーおよびOracle Solaris OSにより提供される大規模なスレッド・スケールを利用できます。

- Oracle Solaris Zonesソフトウェアのパーティション化テクノロジは、オペレーティング・システムの仮想化の手段を提供し、実行中のアプリケーションに分離された環境を作成します。この分離により、あるゾーンで実行中のプロセスが、別のゾーンで実行中のプロセスを監視したり、影響を与えたりすることを防止します。ゾーンはOracle Solaris 10またはそれ以降のOracle Solarisリリースが実行しているマシンで使用できます。1つのシステムでのゾーン数の上限は8192です。

- 注意: Oracle Virtual Compute Applianceは、任意のLinux、Oracle SolarisまたはMicrosoft Windowsアプリケーション向けの仮想インフラストラクチャをインストール、デプロイおよび管理する方法を徹底的に簡略化するために設計されたOracle Engineered Systemです。

Oracle仮想化はHA機能およびHAアーキテクチャとともに使用して、両方の目標のメリットを得ることができます。Oracle仮想化とHAアーキテクチャおよび機能を統合する場合のHAのメリットのいくつかを示します。

- 障害のイベントでのVMの自動再起動がアプリケーションをHAにします。

- Oracle Real Application Clustersはアプリケーション層でのビジネスの可用性を保証し、Oracle VMと統合されて、単一または複数の地理的な場所でアプリケーション・データだけでなくサーバーでのビジネス可用性を保証します。

- 通常、RMAN、フラッシュバック・テクノロジ、Data GuardおよびOracle GoldenGateなどの、非仮想化環境でネイティブに動作するOracle高可用性機能は、仮想化環境でシームレスに動作します。

- Oracle VMはビジネス・ニーズの変更に応じてサービスの提供を促進します。これにより、オンラインで容量を増加することができます

関連項目:

- OTN内のOracle VMのWebサイト(http://www.oracle.com/virtualization)

- 『Oracle Solaris 11.1管理: Oracle Solaris Zones、Oracle Solaris 10 Zonesおよびリソース管理』の第II部「Oracle Solaris Zones」(http://docs.oracle.com/cd/E26502_01/html/E29024/zones.intro-2.html#scrolltoc)

9.4 Oracleグローバル・データ・サービスを使用した高ROI

Oracleグローバル・データ・サービス(GDS)は、レプリケートされたデータベース向けに完全に自動化されたワークロード管理ソリューションで、Oracle Active Data GuardまたはOracle GoldenGateが使用されています。GDSを使用すると、レプリケートされたデータベースで実行されているアプリケーション・ワークロードのシステム使用率、パフォーマンス、スケーラビリティおよび可用性が向上し、ROIが向上します。GDSには、レプリケートされたデータベースのセット向けに、次の機能が用意されています。

- リージョンベースのワークロード・ルーティング

- 接続時ロード・バランシング

- Oracle統合クライアント用のランタイム・ロード・バランシング・アドバイザ

- 内部データベース・サービス・フェイルオーバー

- Oracle Active Data Guard用のレプリケーション・ラグに基づいたワークロード・ルーティング

- Oracle Active Data Guard用のロールベースのグローバル・サービス

- ワークロードの集中管理フレームワーク

GDS構成内のレプリケートされたデータベースはグローバルに分散することも、同じデータ・センターに配置することもできます。クライアントはサービス名を指定するだけでGDS構成に安全に接続でき、GDS構成のコンポーネントやトポロジについての知識は不要であるため、非常に柔軟性の高いプライベート・クラウドを、企業がデプロイできるようになっています。

地域またはグローバルのいずれでも、地理的に分散したデータ・センターは、ビジネス、スループットおよび地域の需要に基づき、実行時アプリケーションに影響を与えることなく、現在は同一のフレームワーク内で効果的に利用できています。

関連項目:
『Oracle Database Global Data Services概要および管理ガイド』

脚注の凡例

脚注1: Oracle Active Data GuardはData Guardドキュメントではリアルタイム問合せと呼ばれます。

用語集

ビジネス影響分析

IT関連の停止の影響の重大度に基づいてビジネス・プロセスを分類します。

クラスタ全体の障害

Oracle RACデータベースのホストであるクラスタ全体が使用不可能になるか、故障します。これには、クラスタ内のノードの障害や、クラスタが使用不可能になる原因となった他のコンポーネントの障害、使用不可能なサイト上のOracleデータベースやインスタンスの障害が含まれます。

コンピュータ障害

データベースが稼働しているシステムが、停止またはアクセス不可能のために使用できない状態になったときに発生する停止。

停止時間のコスト

ビジネス影響分析を完全に実施すれば、計画外停止時間および計画停止時間のコストの定量化に必要な見通しが得られます。このコストは、高可用性の投資の優先付けに役立ち、停止時間のリスクを最小限に抑えるために選択する高可用性テクノロジに直接影響を与えるため、必ず理解しておく必要があります。

データ破損

破損ブロックは変更されたブロックです。そのため、Oracle Databaseが検出するものとは異なります。ブロック破損は、物理ブロック破損と論理ブロック破損の2つに分類されます。

「物理ブロック破損」および「論理ブロック破損」も参照してください。

停止または減速

ハングまたは遅延が発生するのは、リソースやロックの競合が原因でデータベースまたはアプリケーションがトランザクションを処理できなくなったときです。認識される停止は、システム・リソースの不足が原因で起こります。

人的エラー

データベース内のデータを論理的に破損または使用不可能の状態にする意図的でない、または悪意のある操作が行われた場合に発生する停止。人的エラーによる停止から受けるサービス・レベルの影響は、影響を受けたデータの量および重大性によって大きく異なります。

論理ブロック破損

ブロックの内容が論理的に一貫していない状態。論理的破損の例として、行の一部や索引エントリの破損があげられます。

論理ユニット番号(LUN)

同じSCSI IDを持つ最大8つのデバイス(論理ユニット)を区別するために、SCSIバスで使用される3ビットの識別子。

書込み欠落

永続記憶域で実際には書込みI/Oが発生していないのに、サブシステムがブロック書込みの完了を確認したときに発生する可能性のあるデータ破損のもう1つの形。I/OサブシステムからOracle Databaseにはエラーは報告されません。

MAA環境

Oracle RACを使用したOracle Database 11gとOracle Data Guardを使用したOracle Database 11gの両方の機能とメリットが継承されるため、計画外停止と計画停止の両方に対して、最も包括的なソリューション・セットを提供するアーキテクチャ。

MAA環境は、Oracle RACプライマリ・データベースの存在するサイトと、ロジカル・スタンバイ・データベースとフィジカル・スタンバイ・データベースの両方のホストとなる標準クラスタ、または少なくとも1つのフィジカルまたはロジカル・スタンバイ・データベースが存在するもう1つのサイトで構成されます。

管理性目標

管理性目標はRPOやRTOよりも主観的であり、組織で使用できるスキル・セットや管理リソースの客観的な評価、および組織が高可用性アーキテクチャのすべての要素を正常に管理できる程度に起因します。管理性目標を理解すれば、組織で実現が可能と思われる事項と実現が実用的である事項とを区別する際に役立ちます。

ネットワークの障害

ネットワーク障害は、ネットワーク・デバイスが停止するか、アプリケーション・サービスの処理に不可欠な、アプリケーションからデータベース、データベースからストレージ、またはシステムからシステムのネットワーク・トラフィックや通信が減少したときに発生します。

ネットワーク・サーバー・プロセス

プライマリ・データベースのData Guardネットワーク・サーバー・プロセス(LNSnプロセスともいう)は、スタンバイ・データベースのRFSプロセスへのネットワーク送信を実行します。宛先ごとに1つのネットワーク・サーバー・プロセスがあります。

Oracle Active Data Guardオプション

Oracle Active Data Guardオプションのライセンスを購入していない場合、フィジカル・スタンバイ・データベースは、REDO Applyがアクティブなとき、読取り専用アクセスに対して開くことができます。この機能はOracle Active Data Guardといい、スタンバイ・データベースでブロック変更トラッキングも可能で、その結果、スタンバイで増分バックアップを実行できます。

注意: Oracle Active Data Guardオプションは、他のドキュメントではリアルタイム問合せと呼ばれる場合もあります。

物理ブロック破損

データベースがブロックをまったく認識しない状態。チェックサムは無効になり、ブロック内はすべてゼロになるか、またはブロックのヘッダーとフッターが一致しません。メディア破損とも呼ばれます。

リカバリ・ポイント目標(RPO)

組織に損害を与えずに、ITベースのビジネス・プロセスで失うことのできる最大データ量。RPOは、一般的に、ビジネス・プロセスまたは組織の許容データ損失量に相当します。このデータ損失は、通常、5時間または2日分のデータ損失というように、時間に換算して測定されます。

リカバリ時間目標(RTO)

組織に重大な物質的損失を与えずに、ITベースのビジネス・プロセスを停止できる最大時間。RTOは、一般的に、ビジネス・プロセスまたは組織の許容停止時間に相当します。

投資利益率(ROI)

投資利益率(収益率)は、金融や経済での投資効率の評価に使用されます。

サイト障害

イベントが原因で、すべてまたは大部分のアプリケーションが処理を停止したか、または使用不可のサービス・レベルまで減速した場合に発生します。サイト障害は、データ・センターでのすべての処理か、またはデータ・センターでサポートされているアプリケーションのサブセットに影響する可能性があります。

ストレージ障害

データベース・コンテンツの一部またはすべてが格納されている記憶域が停止またはアクセス不可能になり、使用できない状態になったときに発生する停止。

総所有コスト(TCO)

顧客および企業管理者が直接費と間接費を評価するのに役立つ金銭上の推定。完全な原価計算の形態として多くの業界で使用されています。

一時的なロジカル・スタンバイ・データベース

一時的なロジカル・スタンバイ・データベースでは、現在のフィジカル・スタンバイ・データベースを一時的にロジカル・スタンバイに変換して、ローリング・データベース・アップグレードを実行し、停止時間を最小限に抑えて再利用できます。

索引
A  B  C  D  E  F  G  H  I  L  M  N  O  P  R  S  T  U  V  W  Z

数字

24x365, 1.1

64ビット・システム

32ビットからの移行, 5.4.3.1

A

アクセス制御

セキュリティ, 3.12

Active Data Guard

「Oracle Active Data Guard」を参照

ADD COLUMN

列のデフォルト値, 5.5.5

分析

高可用性要件の特定, 2.1

アプリケーション

フェイルオーバー, 3.1.2

オンライン・メンテナンスおよびオンライン・アップグレード, 5.5

個別データベース・パッチの適用, 5.4.4 アーキテクチャ

障害, 1.1

MAA, 7

管理性, 2.2.5

Oracle Application Server, 7.6, 7.6.1

要件, 1.1, 2.1

ロードマップ, 1.5

同じプロセッサ・プラットフォーム, 5.4.3

ASR

「Oracle Auto Service Request (ASR)」を参照

監査

セキュリティ制御, 3.12

認証

セキュリティの制御, 3.12

自動ブロック修復, 3.13.9 自動破損修復, 3.1.2 自動共有メモリー管理

動的メモリー割当て, 5.2.2

可用性

概要, 1.1

中断, 1.3

ロードマップ, 1.5

「高可用性」も参照

B

トランザクションの取消し, 3.13.3

バックアップ

Oracle Secure Backup, 3.5

オブジェクト間, 5.5.6 ブロック・リカバリ

フラッシュバック・ログの使用, 3.13.9

ビジネス影響分析

内部ナレッジ管理システムの例, 2.2.1

半導体製造業者の例, 2.2.1

C

Cluster Ready Services(CRS)

アップグレード時の停止時間の回避, 5.4.5

列, 不可視, 5.5.8 コンポーネント

Oracle Restartと統合, 3.18

コンピュータ障害, 1.4 破損

自動修復, 3.1.2

予防と検出, 3.10

コスト

定量化, 2.2.2

CREATE TRIGGER文

句, 5.5.4

crosseditionトリガー, 5.5.1.3

D

データ破損, 1.4

検出, 3.10

予防と検出のパラメータ, 3.10

データ分散

Oracle GoldenGate, 3.2

データの暗号化, 3.12 Data Guard

概要, 3.1

利点, 3.1, 3.1.2

Oracle GoldenGate使用の構成, 5.4.8.5

システムとクラスタのアップグレード, 5.4.3

データの統合

Oracle GoldenGate, 3.2

データ保護

最大化, 1.2

データ・リカバリ・アドバイザ, 3.11 データベース・サーバー・グリッド

概要, 9.1.1

データベース・ストレージ・グリッド

概要, 9.1.2

データベースのアップグレード

トランスポータブル表領域の使用, 5.4.8.3

データベース

Oracle個別パッチの適用, 5.4.4

動的再構成, 5.2.2

セキュリティ, 3.12

データファイル, オンラインでの移行, 5.2.1 許容データ損失量, 2.2.4 DBA_FLASHBACK_TRANSACTION_STATEビュー, 3.13.3 DBMS_FLASHBACK.TRANSACTION_BACKOUT()プロシージャ, 3.13.3 WAITオプションを使用したDDL, 5.5.3 依存性, 5.5.6 DISABLE句

FOLLOWS句

CREATE TRIGGER文, 5.5.4

障害時リカバリ・ソリューション

Oracle Application Server, 7.6.1

ディスク・グループ

Oracle ASMによる管理, 3.8

停止時間

原因, 1.4

コスト, 1.3, 2.2.2

Oracle GoldenGateによる最小化, 5.4.8.4

Oracle GoldenGateおよびData Guardを使用した最小化, 5.4.8.5

軽減, 1.3

短縮, 3.1.2

ソリューションの概要

計画, 5.4

「計画外停止時間」も参照 動的再構成, 5.2.2

E

エディションベースの再定義, 5.5.1

crosseditionトリガー, 5.5.1.3

エディショニング・ビュー, 5.5.1.2

エディション, 5.5.1.1

ENABLE句

CREATE TRIGGER文, 5.5.4

暗号化

データ, 3.12

拡張データ型サポート(EDS)

パッチ・セットおよびデータベースのアップグレード, 5.4.8

F

フェイルオーバー

アプリケーション, 3.1.2

サービス, 3.6.3

障害グループ

Oracle ASMによる管理, 3.8

Oracle ASM, 3.8

障害

コンピュータ, 1.4

サイト, 1.4

ストレージ, 1.4

高速アプリケーション通知(FAN)

ハードウェアのアップグレード, 5.4.1

オペレーティング・システムのアップグレード, 5.4.1

高速接続フェイルオーバー

プールされていない接続, 3.6.2

高速ミラー再同期

Oracle ASM, 3.8

高速リカバリ領域

概要, 3.9

利点, 3.9

フラッシュバック・ログ

ブロック・リカバリ, 3.13.9

フラッシュバック・テクノロジ

「Oracle Flashbackテクノロジ」も参照

forward crosseditionトリガー, 5.5.1.3

G

グリッド・コンピューティング, 9.1

H

停止または減速, 1.4

ハードウェアのアップグレード

停止時間の回避, 5.4.1

FANの使用, 5.4.1

高可用性

24x365, 1.1

概要, 1.1, 1.1

アプリケーション, 7.6.1

アーキテクチャ, 1.1, 2.2.5, 7

ビジネス影響分析, 2.2.1

要件の特定, 2.1

重要性, 1.2

最大化, 1.2

Oracle Application Server, 7.6

計画停止時間, 5.4

管理性目標の設定, 2.2.5

単一インスタンス・データベース, 3.18

ソリューション, 1.1

計画外停止時間, 4

「可用性」も参照

人的エラー, 1.4

I

索引

不可視, 5.5.7

索引, 同じ列セットで複数, 5.5.9 インスタンス障害, 3.6.3 インターブロック破損, 1.4 イントラブロック破損, 1.4 不可視の列, 5.5.8 不可視索引, 5.5.7

L

ロード・バランシング

アドバイザ, 3.6.3

ランタイム接続, 3.6.3

ロード・バランシング・アドバイザ, 3.6.2 論理的破損, 1.4 書込み欠落, 1.4

M

データの変更, 5.5.1.1

管理性

目標, 2.2.5

オーバーヘッド(MO), 2.2.5

最大可用性アーキテクチャ

「Oracle Maximum Availability Architecture(MAA)」を参照

メディア破損

物理的破損, 1.4

メモリー

自動管理, 5.2.3

MEMORY_MAX_TARGET初期化パラメータ, 5.2.3 MEMORY_TARGET初期化パラメータ, 5.2.3 メタデータ

依存性, 5.5.6

ストレージの移行

停止時間の回避, 5.1.4

移行

32ビット・システムから64ビット・システムへ, 5.4.3.1

記憶域, 5.1.4

ミラー化

Oracle ASMネイティブ, 3.8

N

ネットワークの結合, 3.6.3

O

データベース・アクティビティのオフロード, 3.1.2

個別パッチ, 5.4.4

オンライン・メンテナンス

アプリケーション, 5.5

オンラインでの再定義

表, 5.3

表のオンライン再定義, 5.5.10 オンライン, データファイルの移行, 5.2.1 OPatchユーティリティ

Oracle RACのパッチ・アップグレード, 5.4.4.1

オペレーティング・システム

アップグレード, 5.4.1

アップグレード中のFANの使用, 5.4.1

Oracle Active Data Guard

スタンバイ・データベースの利点, 3.1.1

フィジカル・スタンバイ・データベース, 9.2.1

Oracle Application Server

高可用性アーキテクチャ, 7.6.1

セキュリティ, 7.6.1

Oracle ASMクラスタ・ファイル・システム(ACFS), 3.15.2 Oracle Auto Service Request (ASR), 6.9.3 Oracle Automatic Storage Management(Oracle ASM)

概要, 3.8

利点, 3.8

ファイルの分散, 5.2.4

障害グループ, 3.8

高速ミラー再同期, 3.8

ネイティブ・ミラー化, 3.8

ストレージの移行, 5.4.6

アップグレード, 5.4.6

Oracle Automatic Storage Managementクラスタ・ファイル・システム(Oracle ACFS), 3.8 Oracle Call Interface(OCI), 3.6.2 Oracle Clusterware

アップグレード時の停止時間の回避, 5.4.5

コールド・クラスタ・フェイルオーバー, 3.6.3

Oracle Data Guard

「Data Guard」を参照

Oracle Data Provider for .NET(ODP.NET), 3.6.2 Oracle Database File System(DBFS), 3.1.2, 3.15.1 Oracle Enterprise Manager, 3.6.3 Oracle Exadata Database Machine, 8.1 Oracle Exadata Storage Server Software

Oracle Database Machineとの組合せ, 8.1

アップグレード, 5.4.7

Oracle Flashback Data Archive, 3.13.10 Oracle Flashback Database, 3.13.8 Oracle Flashback Drop, 3.13.6 Oracle Flashback Query, 3.13.1 Oracle Flashback Table, 3.13.5 Oracle Flashbackテクノロジ, 3.13

フラッシュバック・ログを使用したブロック・リカバリ, 3.13.9

Oracle Flashback Transaction, 3.13.3 Oracle Flashback Transaction Query, 3.13.4 Oracle Flashback Version Query, 3.13.2 Oracle GoldenGate

概要, 3.2

停止時間を最小限に抑えるための構成, 5.4.8.5

ローリング・アップグレード, 5.5.2

アップグレード, 5.4.8.4

Oracle個別パッチ, 5.4.4

適用, 5.4.4

停止時間の回避, 5.4.4

Oracle Maximum Availability Architecture(MAA)

概要, 1.5

アーキテクチャ, 7

ロードマップ, 1.5

Oracle Quality of Service (QoS)管理, 3.6.3 Oracle RAC One Node, 3.6.3 Oracle Real Application Clusters(Oracle RAC)

Oracle個別データベース・パッチの適用, 5.4.4

利点, 3.6.2

オペレーティング・システムとハードウェアのアップグレード, 5.4.1

Oracle Real Application Clusters One Node

「Oracle RAC One Node」を参照

Oracle Restart, 3.18 Oracle Secure Backup

概要, 3.5

利点, 3.5

Oracle Solaris ZFS Storage Applianceレプリケーション, 3.15.3 Oracle UCPランタイム接続ロード・バランシング, 3.6.2 Oracle VM

ドメイン・ライブ・マイグレーション, 9.3.2

停止

タイプ, 1.4

P

パッチ適用

ローリング, 3.6.3

物理的破損, 1.4 フィジカル・スタンバイ・データベース

リアルタイム問合せ, 9.2.1

計画停止時間

オンライン・パッチの適用, 5.4.2

計画停止

Oracle GoldenGateによる最小化, 5.4.8.4

Oracle GoldenGateおよびData Guardを使用した最小化, 5.4.8.5

プラグ・アンド・プレイ, 3.6.3 プラガブル・データベース, 9.3 ポリシー管理

セキュリティ, 3.12

ポリシーベースのクラスタ管理, 3.6.3 ポータブル・データベース, 9.3 優先付け

高可用性の投資, 2.2.2

プログラム・グローバル領域(PGA)

自動管理, 5.2.3

R

リアルタイム問合せ, 9.2.1

再構成

データベースの動的, 5.2.2

Recovery Manager(RMAN)

概要, 3.4

利点, 3.4

リカバリ・ポイント目標(RPO)

概要, 2.2.4

リカバリ時間目標(RTO)

概要, 2.2.3

レプリケーション

Oracle GoldenGate, 3.2

リストア・ポイント

Oracle Flashback, 3.13.7

投資利益率(ROI), 2.2.6 reverse crosseditionトリガー, 5.5.1.3 最大可用性アーキテクチャ(MAA)のロードマップ, 1.5 ロールバック

トランザクション, 3.13.3

ローリング方式のパッチ適用, 3.6.3 ローリング・アップグレード, 3.6.3

Oracle GoldenGate, 5.5.2

行レベルのセキュリティ

仮想プライベート・データベース, 3.12

ランタイム接続ロード・バランシング, 3.6.2, 3.6.3

S

スケーラビリティ

Oracle RACの使用, 3.6.3

SCAN, 3.6.3 セキュリティ

概要, 3.12

利点, 3.12

データの暗号化, 3.12

Oracle Application Server, 7.6.1

Oracle ASM, 3.8

RMAN, 3.4

サービス

フェイルオーバー, 3.6.3

簡易データベース・ローリング・アップグレード, 5.4.8.1 単一インスタンス・データベース

Oracle Restart, 3.18

サイト障害, 1.4 SQL Apply, 5.4.8, 5.4.8.1 スタンバイ・データベース

アクティブ, 9.2

利点, 3.1

Oracle Active Data Guard, 9.2.1

スタンバイ・リーダー・ファーム, 9.2.2 ストレージ

障害, 1.4, 3.8

移行, 5.1.4

Oracle ASMによる保護, 3.8

システム・グローバル領域(SGA)

自動管理, 5.2.3

システムのアップグレード

停止時間の回避, 5.4.1

T

表

エディション化可能, 5.5.1.2

テープ・バックアップ

Oracle Secure Backupの使用, 3.5

総所有コスト(TCO), 2.2.6 トランザクション

フラッシュバック・トランザクションによる取消し, 3.13.3

トランスポータブル表領域

データベースのアップグレード, 5.4.8.3

U

計画外停止時間

原因, 1.4

ソリューションの概要, 4

アップグレード

簡易ローリング, 5.4.8.1

Oracle GoldenGateの使用, 5.4.8.4

アップグレード

アプリケーション, 5.5

クラスタ, 5.4.3

データベース, 5.4.8

ハードウェア, 5.4.1

オペレーティング・システム, 5.4.1, 5.4.3

Oracle ASM, 5.4.6

Oracle Clusterware, 5.4.5

Oracle Exadata Storage Server Software, 5.4.7

Oracle Real Application Clusters(Oracle RAC), 5.4.1

パッチ, 5.4.4

ローリング, 3.6.3

Oracle GoldenGateでのローリング, 5.5.2

SQL Apply, 5.4.8

crosseditionトリガーの使用, 5.5.1.3

トランスポータブル表領域の使用, 5.4.8.3

V

仮想IP(VIP)アドレス

Oracle Clusterwareによる管理, 3.6.1

仮想プライベート・データベース

セキュリティ, 3.12

仮想化

Oracle VMのドメイン・ライブ・マイグレーションの使用, 9.3.2

W

WAITオプション

DDLの指定, 5.5.3

Webスケーラビリティ

スタンバイ・リーダー・ファームの使用, 9.2.2

ワークロード

オフロード, 3.1.2

ワークロード管理, 3.6.3

Z

データ損失ゼロ, 3.1.2

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2015, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。