前述の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクルの製品に関して記載されている機能の開発、リリース、時期、および価格は変更になる場合があり、その決定は弊社独自の裁量で行われます。

オラクルの将来の計画、予測、信念、意図、および見込みに関するこのプレゼンテーションの記述は“将来を見越した記述”であり、重大なリスクや不確実性を伴う可能性があります。弊社のビジネスに影響するこれらの要素や他のリスクに関する詳細については、直近のForm 10-KおよびForm 10-Qによる報告書の“リスク要素”セクションを含め、オラクルの米国証券取引委員会（SEC）への提出書類に記載されています。これらの書類は、SECのWebサイト、またはオラクルのWebサイトhttp://www.oracle.com/investorで参照できます。このプレゼンテーションのすべての情報は2019年9月現在のものであり、オラクルは、いずれの記述についても、新しい情報または将来のイベントを踏まえて更新する義務を負いません。

免責条項

Copyright © 2019 Oracle and/or its affiliates.

Oracle Maximum Availability Architecture（Oracle MAA）

オンプレミス、Exadataベース、またはクラウドベースのOracle Databaseの計画停止時間と計画外停止時間の短縮構想

プログラムのアジェンダ

可用性が重要な理由オンプレミスのOracle向けMAAブループリント

サマリーとリソース

1

2

3

3

Maximum Availability Architecture（MAA）

可用性が重要な理由

Copyright © 2019 Oracle and/or its affiliates.

オンプレミス

MAAのソリューション：オンプレミスからクラウドまで

自律型データベース

DBCS／ExaCS／ExaCC

オンプレミスExadataおよびRecovery Appliance

MAA統合型エンジニアド・システム（構成プラクティス、exachk、最短の一時停止時間、HA QoS、データ保護）

MAAの構成とライフサイクル操作の追加、管理者所有権からオラクル／

MAA SLAへのシフト

5

MAAリファレンス・アーキテクチャとベスト・プラクティス

1時間あたりの停止時間の平均コスト

データセンターの計画外停止や災害の平均コスト

年間平均停止時間過去24か月以内にデータセンターの計画外停止を経験した企業の割合

データベース停止時間の影響

91%

1000万ドル35万ドル

出典：Gartner、Data Center Knowledge、IT Process Institute、Forrester Research

87時間6

Oracle Maximum Availability Architecture（MAA）

世界各地のHAに関する困難な問題の解決で得た30年を超える経験を適用ワークロードと要件への要求がもっとも厳しいエンタープライズ顧客向けの、計画停止および計画外停止の時間を短縮するソリューションサービス・レベル指向のMAAリファレンス・アーキテクチャ 書籍、ホワイト・ペーパー、ブループリントMAA統合型エンジニアド・システム

高可用性、ディザスタ・リカバリ、データ保護本番 コピー

データベース・レプリケーション

R製品への継続的フィードバック

https://oracle.com/goto/maa 7

MAAリファレンス・アーキテクチャ停止時間（RTO）とデータ損失（RPO）のSLAを遵守

停止時間&データ損失

MAAリファレンス・アーキテクチャ トポロジ ふさわしいデータベース

BRONZE 単一インスタンス+バックアップ 開発、テスト、本番

SILVER HAクラスタリング+バックアップ 本番／部門

GOLD HAクラスタリング+ディザスタ・リカバリ+バックアップ ミッション・クリティカル

PLATINUM データ損失ゼロ&停止時間ゼロ 極めてクリティカル

計画停止時および計画外停止時のデータ損失および停止時間に関するSLAに対処8

Oracle MAA – 何千もの顧客により実証済み

99Copyright © 2019 Oracle and/or its affiliates.All rights reserved. |

Oracle Maximum Availability Architecture（MAA）

リファレンス・アーキテクチャ

HA機能、構成、運用方法

顧客インサイトと専門家からの推奨事項

デプロイメントの選択肢

Platinum

Gold

Silver

Bronze

レプリケーション

データ保護

継続的な可用性

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

Global Data Services

汎用システム エンジニアド・システム

DBCSExaCS／ExaCC

Autonomous DB

フラッシュバック RMAN + ZDLRA

Active Data Guard GoldenGate

スケールアウト

RAC シャーディングASM

レプリケートされたサイト本番サイト

アクティブ・レプリケーション

Oracle MAAあらゆるビジネス要件に対処するように設計

共通のプラットフォーム – オンプレミス、クラウド、ハイブリッド・クラウド

大きな差別化要因

オンプレミス クラウド

Oracle Database

11

Oracle Enterprise Manager Cloud Control（OEM）構成、監視、アラート、管理

Data Guard ／ Active Data Guard MultitenantZero Data Loss Recovery Appliance（ZDLRA）Recovery Manager（RMAN）Real Application Clusters（RAC）エディションベースの再定義（EBR）Oracle ShardingOracle GoldenGate（OGG）– 監視とアラート専用

12

Maximum Availability Architecture（MAA）

オンプレミスのOracle向けMAAブループリント

Copyright © 2019 Oracle and/or its affiliates.

14

リファレンス・アーキテクチャ – レベル・セット

オラクルが開発、認定したブループリント

数万のオラクルの顧客によって検証

レベルの上昇に合わせて機能が増加 所定のサービス・レベルを

達成するための要件：

• 規定の機能を活用

• 規定の構成と運用のベスト・プラクティスを活用

• 本番前テストでデュー・デリジェンスを実施

• すべてのライフサイクル操作でデュー・デリジェンスを実施

• 推奨されているパッチ・レベルとバージョンの維持

Copyright © 2019 Oracle and/or its affiliates.

停止のマトリックス計画外停止 RTO ／ RPO*

リカバリ可能なノードまたはインスタンス障害 数分～1時間

災害：破損およびサイト障害 数時間から数日 RPOは最後のバックアップ以降、またはZDLRAによりほぼ0（ゼロ）

計画メンテナンス

ソフトウェア／ハードウェア更新 数分～1時間

データベースのメジャー・アップグレード 数分～1時間

プライマリ可用性ドメイン セカンダリ可用性ドメイン

開発、テスト、本番 - シングル・インスタンス・データベースとバックアップ

• Clusterwareによる再起動が可能なシングル・インスタンス

• RMANによる高度なバックアップ／リストア

• オプションのZDLRAで永久的増分およびほぼゼロのRPO

• ASMによるストレージの冗長化と検証

• PDB機能を持つマルチテナント・データベース／リソース管理

• オンライン・メンテナンス• 固有の破損保護• フラッシュバック・テクノロジー

BRONZE

* RPO=0（明示的に指定されていない場合）

レプリケートされたバックアップ

ローカル・バックアップ

シングルインスタンスデータベース

Oracle Clusterwareによる自動再起動

1. Oracle ClusterwareはすべてのOracle Databaseで利用可能2. HA機能とリソース管理を有効化：

• データベース・インスタンス、リスナー、その他のリソースの自動再起動• フリートのパッチ適用• 障害発生後のサービス再起動をはじめとするサービス管理• 自動ストレージ管理（ASM）によるHA、データ保護、使いやすさ

トレードオフ：グリッド・インフラストラクチャのための追加のソフトウェア・メンテナンスが発生

16

Oracle Multitenantデータベースを統合し、操作を簡素化するためのアーキテクチャ

GL OE

AP アプリケーションごとの自己完結型PDB• プラガブルな機能によりポータビリティを提供• クローンにより迅速なプロビジョニングを実現• アプリケーションを変更なしで実行可能• プラグ／アンプラグを使用したPDBアップグレード

PDB

ルート

CDB

MAAベスト・プラクティス・ペーパー：Oracle Multitenantを使用したデータベース統合

CDBレベルで実行される一般的な操作• 一元管理（アップグレード、バックアップ、HA）• きめ細かい制御（適切な場合）• シンプルなDR

共有メモリとバックグラウンド・プロセス• サーバーあたりのアプリケーション数が増加

MAAとマルチテナント• 計画／計画外停止のためのソリューション

17

プラガブル・データベースのバックアップ、リストア、リカバリ

プラガブル・データベースのバックアップとリストア…プラガブル・データベースにリストア・ポイント‘before_event’を作成…

• 通常のリストア・ポイントまたは保証付きリストア・ポイント• クリーン・リストア・ポイント

フラッシュバック・プラガブル・データベースZDLRAによる完全なサポート

Copyright © 2019 Oracle and/or its affiliates.

Oracle Recovery Manager – RMANデータベース統合型のバックアップとリカバリ

データベース・ファイル形式とリカバリ手順に関する独自の知識

• Oracleブロック検証• オンラインのブロックレベル・

リカバリ• ネイティブ暗号化、圧縮• 表レベル／パーティションレベルの

リカバリ• Oracle Multitenantのサポート

テープとクラウドへのバックアップ統合管理

RMAN

データファイル

ファスト・リカバリ領域（FRA）

クラウド

テープ

ディスク テープ

20

RMANによる表リカバリ機能の強化1) 補助インスタンスのディスク領域のチェック

• 表の自動リカバリを実行するには各表領域（SYSTEM、SYSAUX、UNDO、ユーザー）のディスクに空き領域が必要

• 補助インスタンスのディスク領域の空きを事前チェックすることで処理途中での障害を回避

2) スキーマ全体のリカバリ• 異なるスキーマでの表レベルのリカバリを実現• REMAP TABLEの後に古いスキーマと新しいスキーマを記述

プライマリ・インスタンス

RMANバックアップ

RECOVER TABLE hr.department, sales.product UNTIL SCN 1234 AUXILIARY DESTINATION ’/tmp/’ REMAP TABLEhr.department:dev.testdepartment, sales.product:mkt.newproduct;

RMANリストア

Data Pumpのインポート

異なるスキーマ

補助インスタンス領域

2

21

1

推奨されるリカバリ・アプライアンス

クラウド・ストレージ

リモート・レプリカ

テープ

エンド・ツー・エンドのOracleリカバリ検証DRのデータ損失ほぼゼロ

1日目全体

a

2日目の変更

N日目の変更仮想全体バックアップ

EMリアルタイム保護ステータス

および領域監視

1日目の状態2日目の状態

N日目の状態

データベース

トランザクションのブロック変更

今後は全体バックアップは不要、永久増分

任意のプラットフォーム上の

Oracle DB 12c-19c

23

24

MAAスコア・カードMAAアーキテクチャの準備および構成のプラクティス

データベースとExadataのヘルス・チェック評価レポート

ヘルス・スコア、まとめ、検出事項

検出事項および推奨事項

問題の解決方法

注：Orachk／Exachkによる自動ヘルスチェックに関するMOS 107954.1は頻繁に更新されます

オンライン操作

• 列の追加／削除／名前変更／並べ替え• 物理ストレージ構造の切り替え• データのオンラインでの再構成および変換

DBMS_REDEFINITIONを使用する他のメリット• フォルト・トレラント（障害発生時点からの再開）機能と変更追跡機能により、以前の定義

への高速ロールバックが可能• 排他DDLロックを取得せずに再定義の全プロセスを実行可能• V$online_redefを使用して再編成を監視

オンライン再定義の改善DBMS_REDEFINITIONの使用により、オンラインでの表の再編成と再定義が可能

ソース表

追跡の更新

変換表のコピー

更新の変換

結果表

継続的な問合せと更新

更新の保存

25

オンライン操作

11.2以前 create index online、rebuild index online、rebuild index partition onlineadd column、add constraint enable novalidate

12.1 Online move partition Drop index onlineSet unused column online、alter column visible/invisible、alter index unusable online、alter index visible/invisible alter index parallel/noparallel

12.2 非パーティション表のAlter table move online 非パーティション表からパーティション表へのオンラインでの変更Alter table split partition onlineCreate table for exchange (オンラインでのパーティション交換に使用可能) パーティション・メンテナンス操作（移動／マージ／分割）でデータのフィルタリングが可能

18.1、19c 異なるパーティション方式（例：ハッシュからレンジ）へのAlter table modify partitioned table Alter table merge partition/sub-partition online

すべてのパーティション・メンテナンス操作がオンラインで可能に

26

• 高コストのリストア操作を使用しない高速なポイント・イン・タイム・リカバリ（PITR）

• エラーの調査• 以前の時点のデータを参照

• エラーの修正• トランザクションの取り消し• 誤った表の更新• データベース全体の巻戻し

フラッシュバック・テクノロジーOracle Databaseの巻戻しボタン

@T2 列1 列.. 列n

行1 tom 1234 vp

行2 ben 8834 vp

行3 charlie 9837 vp

行n tom 8793 vp

@T1 列1 列.. 列n

行1 abby 1234 officer

行2 ben 8834 mgr

行3 Charlie 9837 officer

行n tom 8793 vp 誤った更新

フラッシュバック表

DB @ T1 DB @ T2

バッチ更新

フラッシュバック・データベース

誤った更新

27

Copyright © 2019 Oracle and/or its affiliates.

SILVER

災害：破損およびサイト障害 数時間～数日最後のバックアップ以降RPOまたはZDLRAによりほぼ0（ゼロ）

計画メンテナンス

ソフトウェア／ハードウェア更新 0（ゼロ）

データベースのメジャー・アップグレード 数分～1時間

本番／部門

Bronze +• Real Application Clustering（RAC）• アプリケーション・

コンティニュイティ

プライマリ可用性ドメイン セカンダリ可用性ドメイン

* RPO=0（明示的に指定されていない場合）

レプリケートされたバックアップ

ローカル・バックアップ

RACデータベース

停止のマトリックス計画外停止

リカバリ可能なノードまたはインスタンス障害 数秒

PTO／PRO*

Oracle Real Application Clusters（Oracle RAC）

データ

ベース・

サービス

プライマリ・データベース

ノード障害、インスタンス障害、ローリング・メンテナンス

• Oracle Databaseの複数のインスタンスを同時に利用

• 高いスケーラビリティ• すべてのインスタンスをアクティブ化、

オンライン容量を追加、データベース統合に最適• 高可用性

• すでに実行中のインスタンスへのサービスの自動フェイルオーバー、ユーザーに停止を気付かれることなく処理中のトランザクションが完了、停止時間ゼロのローリング・メンテナンス

31

データベース

層

アプリケーション層

アプリケーションは停止中にエラーを認識しない透過的アプリケーション・コンティニュイティ（TAC）

• アプリケーション・コンティニュイティとOracle Real Application Clustersを使用

• 障害発生時にセッションの情報を透過的に追跡および記録

• アプリケーションを変更せずに機能するよう、データベースの内部に構築

• 計画外停止時にセッション状態を再作成し、処理中のトランザクションを再実行

• TACを使用して1つ以上のノードからセッションをドレインすることにより、計画メンテナンスを実施可能

• アプリケーション変更のたびに適応：未来を見据えた保護

リクエスト

エラー／タイムアウトが隠される

透過的アプリケーション・コンティニュイティ

32

フェイルオーバー・フェーズ1：再接続

• 再実行が有効であることを確認

• タイムラインを検証• 新しい接続を作成• ターゲット・データベース

が再実行に適していることを確認

• Transaction Guardを使用してコミットされた結果を保証

フェイルオーバー・フェーズ2：再実行

• セッション状態をリストアして検証

• 保持していたコールを再実行し、可変値を自動的にリストア

• 結果、状態、メッセージがオリジナルと一致することを確認

• 成功時にアプリケーションに制御を返す

透過的アプリケーション・コンティニュイティ説明

通常の操作• クライアントがリクエスト

を明示的かつ検出済みとしてマーク

• サーバーで、セッションの状態を追跡し、再実行するコールを決定し、副次的作用を無効化

• クライアントに元のコール、その入力、検証データの保持を指示

33

アプリケーションの停止時間ゼロ達成のためのチェックリスト

1. Oracle Clusterware Serviceを使用（デフォルトのサービスは使用しない）2. 推奨されている接続文字列を使用3. 接続プールに対してFANを構成4. サービスをドレイン5. アプリケーション・コンティニュイティまたは透過的アプリケーション・

コンティニュイティを使用

1) MAAホワイト・ペーパー：MAAソリューションの継続的サービスのためのアプリケーション・チェックリスト2) RHPhelperを使用して、計画メンテナンス中のExadataの停止時間を最小化（MOS 2385790.1）3) フリートのパッチ適用およびプロビジョニングによるMAAプラクティスの採用

Copyright © 2019 Oracle and/or its affiliates.

Copyright © 2019 Oracle and/or its affiliates.

停止のマトリックス計画外停止 RTO／RPO*リカバリ可能なノードまたはインスタンス障害 数秒

災害：破損およびサイト障害 数秒。 RPOゼロまたは数秒

計画メンテナンス

ソフトウェア／ハードウェア更新 0（ゼロ）

データベースのメジャー・アップグレード 数秒

セカンダリ・リージョン

ローカル・バックアップ

リモート・スタンバイプライマリローカル・

スタンバイローカル・

バックアップ

プライマリ・リージョンAD1

ミッション・クリティカル

Silver +• Active Data Guard• 包括的なデータ保護MAAアーキテクチャ：• ADまたはリージョン全体で

少なくとも1つのスタンバイが必要

• データセンター（またはAD）内のプライマリを、別のデータセンター内のスタンバイにレプリケー

• プライマリとスタンバイ両方でのローカル・バックアップ

GOLD

* RPO=0（明示的に指定されていない場合）

AD2

ストレージのリモート・ミラー化アーキテクチャ

Oracleインスタンス（インメモリ）

一般 – すべてのファイルへの書込みを送信することが必須

….破損ブロックや不適切なデータを含む

プライマリ・データベース ミラー化ボリューム

• Oracleの検証なし

• 7倍のネットワーク・ボリューム

• 27倍のネットワーク I／O

38

同期または非同期ブロック・レプリケーション

Data Guardがストレージ・レプリケーションの欠点に対処

不十分な独立性、アプリケーション・レベルの検証なし

「I／Oスタックで何かが発生し、データベース書込みが正常に行われない場合、Symmetrix Aはそのことを認識しないまま破損したデータをサイトBにレプリケートし、破損は検出されない」

整合性に関するEMC BLOG

39

オラクルのデータ保護Gold – 包括的なデータ保護

実行

時手

動

機能 物理的なブロック破損 論理的なブロック破損

Dbverify、Analyze 物理的なブロック・チェック

ブロック内およびオブジェクト間の整合性に関する論理チェック

RMAN、ASM 物理的なブロック・チェック ブロック内の論理チェック

Active Data Guard

• スタンバイでの物理的な継続的ブロック・チェック

• 厳密な分離により、シングル・ポイント障害を防止

• 物理的な破損の自動修復

• 自動データベース・フェイルオーバー（書込み損失時のオプション）

• 書込み損失破損の検出、自動シャットダウン、フェイルオーバー

• スタンバイでのブロック内論理チェック

データベース インメモリのブロックおよびREDOチェックサムインメモリのブロック内チェック、シャドウ書込み損失保護

ASM エクステント・ペアを使用した自動的な破損検出と修復

Exadata 書込み時のHARDチェック、ディスクの自動的なスクラブと修復 書込み時のHARDチェック

40

Active Data Guardの概要

プライマリ読取り／書込みでオープン

読取り専用ワークロード、またはほぼ読取りの

ワークロードをスタンバイ・データベースにオフロード

スタンバイ読取り専用でオープン

• データ損失ゼロの同期レプリケーション

• データベースのローリング・アップグレードによる、計画メンテナンスの停止時間の短縮

• 自動フェイルオーバーによる高可用性

DMLリダイレクト

いかなる距離でもデータ損失ゼロ

自動ブロック修復機能

RACに対するマルチインスタンスREDO Apply

（インメモリをサポート）

41

Far Syncインスタンス• オラクルの制御ファイルとログ・ファイル• データベース・ファイルはなし• メディア・リカバリはなし• 転送圧縮および／または暗号化のオフロード

アクティブなスタンバイ・データベース

• データ損失ゼロのフェイルオーバー・ターゲット

• データベースは読取り専用でオープン• オラクルの継続的な検証• 手動または自動の

フェイルオーバー

SYNC限られた距離

ASYNCあらゆる距離

WAN経由のREDO圧縮

Active Data Guard Far Syncいかなる距離でもデータ損失ゼロの保護

プライマリ・データベース• 本番コピー

42

ADGアプリケーションのフットプリントの拡大DMLリダイレクトのサポート

• Active Data GuardのスタンバイからプライマリへのDMLリダイレクトは自動的に実行（ACIDは損なわれない）

• 新しいパラメータADG_REDIRECT_DMLでDMLリダイレクトを制御• 新しいADG_REDIRECT_DMLとADG_REDIRECT_PLSQL

• "読取りが中心で、更新がほとんどない”アプリケーションを

Oracle Database 19cでサポート

47

ロール変更時のバッファ・キャッシュの保持

読取り／書込み 読取り

読取り／書込み

Active Data Guardのスタンバイ

プライマリ障害の発生したプライマリ

プライマリ

データベース・バッファ・キャッシュの状態はロールの変更中もADGスタンバイに保持

自動的に有効化• PHYSICAL_STANDBYとPRIMARYの両方の

ロールで有効なサービスにユーザーが接続したままでいられるようにサービスを構成

サポート対象バージョン：• Oracle Database 18c – シングル・インスタンス• Oracle Database 19c – Oracle RACのサポート

51

マルチインスタンスREDO Applyのパフォーマンス

7401480

1400

2752

5000

0

1000

3000

2000

7000

6000

5000

4000

700190

1インスタンス380

2インスタンス 4インスタンス 8インスタンス

バッチ

OLTP

Active Data Guardスタンバイ・データベースの待機時間を短縮

• スタンバイ・データベース側のすべてのRACノードを使用してリカバリをパラレル化• Exadata上のOLTPワークロードの大幅な拡大を確認

スタンバイ適用速度

（MB／秒）

52

データベースの19cへのローリング・アップグレード

DBMS_ROLLINGを使用したデータベースのローリング・アップグレード• 事前チェックと早期の問題検出• フォルト・トレラントで再開可能なロールバック機能• ロール移行の3つのステップ：開始、スイッチオーバー、終了• 可能性のあるメンテナンス期間：数時間

• 可能性のあるデータベースおよびアプリケーションの停止時間：数秒

Confidential – Oracle社外秘/極秘

Oracle Active Data GuardとDBMS_ROLLINGを使用した自動データベース・アップグレード

データベースを統合し、操作を簡素化するためのアーキテクチャOracle Multitenant

GL OE

AP アプリケーションごとの自己完結型PDB• プラガブルな機能によりポータビリティを提供• クローンにより迅速なプロビジョニングを実現• アプリケーションを変更なしで実行可能• プラグ／アンプラグを使用したPDBアップグレード

PDB

ルート

CDB

CDBレベルで実行される一般的な操作• 一元管理（アップグレード、バックアップ、HA）• きめ細かな制御• シンプルなDR

共有メモリとバックグラウンド・プロセス• サーバーあたりのアプリケーション数が増加

MAAとマルチテナント• 計画／計画外停止のためのソリューション

54

PDBフェイルオーバー：通常の実行時

PDB1 PDB2

CDB 1読取り／

書込み

CDB 1スタンバイ読取り専用Data Guard

CDB 2読取り／書込み

PDB4

PDB2 PDB3PDB1 PDB3

55

PDB 2停止後のPDBフェイルオーバーPDB2をCDB1スタンバイからアンプラグし、CDB2にプラグインして、アプリケーション接続をフェイルオーバー

PDB1

CDB 1読取り／

書込み

CDB 1スタンバイ読取り専用Data Guard

CDB 2読取り／書込み

PDB4

PDB2PDB1 PDB2 PDB3 PDB3

PDB2

56

Multitenant “Gold”MAA計画外停止 ソリューションのおもな機能 RTO RPO

Real Application Cluster（RAC）アプリケーション・コンティニュイティ（AC／TAC）

数秒 0（ゼロ）

災害：破損およびサイト障害 Active Data Guardファスト・スタート・フェイルオーバー

数秒 ゼロまたは数秒

PDBのリカバリ不能な障害または“不具合の生じた”PDB（新規）

PDBフェイルオーバー（アンプラグ／プラグ） 同じクラスタで必要な別のターゲットCDB（MOS 2088201.1）

数秒 ゼロまたは数秒

計画メンテナンス ソリューション RTOソフトウェアおよびハードウェアの更新 RAC、ACまたはTAC 0（ゼロ）

データベースのメジャー・アップグレード Active Data Guard DBMS_ROLLING 数秒

リモートCDBへの移行（新規） PDB再配置 数分

移行とアップグレード（新規） PDB再配置とアップグレード 数分

更新済みのMAAベスト・プラクティス・ペーパー：『Exadata Database Machine上でのデータベース統合に関するベスト・プラクティス』Confidential – Oracle社外秘/極秘

リカバリ可能なノードまたはインスタンス障害

リフレッシュ可能なPDBスイッチオーバー2つのCDBを管理するだけで、PDBごとのレプリカが実現サーバー1

CDB1

CDB2

サーバー2

1. create pluggable database Red;4. create pluggable database Brown;6. create pluggable database Grey

from Grey@CDB2_Linkrefresh mode every 2 minutes;

2. create pluggable database Red from Red@CDB1_Linkrefresh mode every 2 minutes;

3. create pluggable database Gold;5. create pluggable database Grey;

58

リフレッシュ可能なPDBスイッチオーバー計画スイッチオーバーサーバー1

CDB1

CDB2

サーバー2

1. alter pluggable database Grey refresh mode every 2 minutes from Grey@dblink switchover;

59

リフレッシュ可能なPDBスイッチオーバー計画外スイッチオーバーサーバー1

CDB1

CDB2

サーバー2 1. alter pluggable database Grey refresh;2. alter pluggable database Grey refresh

mode none;3. alter pluggable database Grey open read

write;

Data Guardファスト・スタート・フェイルオーバー、自動ブロック修復、DBローリング・アップグレードとは相互運用されないため、Gold MAAには含まれません

60

Copyright © 2019 Oracle and/or its affiliates.

Gold +• Oracle GoldenGateアクティブ／

アクティブ・レプリケーション• 任意のエディションベースの再定義MAAアーキテクチャ：• おのおののGoldenGate“プライマリ”

レプリカをRACおよびActive Data Guardによって保護

• データセンター（またはAD）内のプライマリをリモート・データセンター（またはAD）内の別のプライマリにレプリケート

• Oracle GGおよびエディション・ベースの再定義により、アプリケーション・アップグレードの停止時間ゼロを実現

• 両方のサイトでのローカル・バックアップ• GGレプリカへのカスタム・フェイル

オーバーにより停止時間ゼロを実現

極めてクリティカル

PLATINUM セカンダリ・リージョン

ローカル・バックアップ

プライマリ・リージョンAD1

GGレプリケーション

AD1 AD2

スタンバイローカルバックアップ スタンバイ プライマリ プライマリ

停止のマトリックス

** アプリケーション・フェイルオーバーはカスタム

計画外停止 RTO／RPO*

リカバリ可能なノードまたはインスタンス障害 数秒

災害：破損およびサイト障害 ゼロ**

計画メンテナンス

ソフトウェアおよびハードウェアの更新 ゼロ

ゼロ**

AD2

* RPO=0（明示的に指定されていない場合）

データベースのメジャー・アップグレード、アプリケーションのアップグレード移行

GoldenGateと2つのオプション・アプローチでアプリケーションの保護を強化

Oracle GoldenGateを使用必須

エディションベースの再定義を使用

任意

Oracle Shardingを使用オプション

62

Oracle Shardingを使用オプション

エディションベースの再定義を使用

任意

GoldenGateと2つのオプション・アプローチでアプリケーションの保護を強化

Oracle GoldenGateを使用必須

63

Oracle GoldenGate Microservices Architecture

ソースOracleおよびOracle以外のデータベース

ターゲットOracleおよびOracle以外の

データベース

取得

配信

証跡ファイル Dist.

Service

証跡ファイル

配信

取得

双方向

LAN ／ WAN ／ TCP／IP経由のインターネット

証跡ファイル

証跡ファイル

取得：トランザクション・ログを読み取ることで、コミットされたトランザクションを発生時に取得（およびフィルタリング可能）

証跡：ルーティングのためにデータをステージングおよびキューイング

Distribution Server／Receiver：ターゲットへルーティングするためにデータを分散

ルーティング：ターゲットへルーティングするためにデータを圧縮、暗号化

配信：トランザクションの整合性を維持したままデータを適用

Dist.Service

ReceiverService

Receiver Service

64

GoldenGateのおもな改善点により簡素化されたPlatinum

1. GoldenGate Hubはソースおよびターゲットから作業をオフロードすることにより移行と管理を簡素化

• 新しいGoldenGateクラウド・マーケット・プレイスによりGGハブのデプロイを自動化• クロス・エンディアンネスの取得によりクロス・プラットフォーム移行が可能• 停止時間ゼロの移行とGoldenGateとの今後の統合

2. GoldenGate Microservicesにより管理が簡素化

Copyright © 2019 Oracle and/or its affiliates.

Oracle GoldenGate Hub ConfigurationによるOracle Databaseの移行

Oracle Real Application Clustersを使用したOracle GoldenGate Microservices Architectureの構成のベスト・プラクティス

未来：停止時間ゼロの移行（www.oracle.com/goto/zdm）

Oracle GoldenGateMAAベスト・プラクティス

• Data Guard構成での透過的ロール移行• FSFOとDG Brokerの使用により手動操作不要

• 構成に使用するもの：• Oracle Grid Infrastructureにバンドルされたエージェント（XAG）• GoldenGateの共有ファイル（証跡ファイルおよびチェックポイント・ファイル）用の

DBFSまたはACFS• ロール・ベースのサービス• Extract（とASYNC DGのHANDLEDLFAILOVERオプションと）の統合• Microservices Architectureによる管理の簡素化

更新：MAAベスト・プラクティス・ペーパー：Data GuardとOracle GoldenGateによる

透過的なロール移行

66

デプロイ例オブザーバー

プライマリ・データベース スタンバイ・データベース

REDO転送（同期または非同期）

統合Extract

LogMiningサーバー

DBFS内の証跡ファイルおよび他のOGGファイル

REDO転送

OCI接続

ファイル I／Oウェアハウス

双方向GoldenGateレプリケーション

67

デプロイ例 – ロール移行後オブザーバー

（旧）プライマリ・データベース

REDO転送（同期または非同期）

統合ExtractLogMining

サーバー

DBFSの証跡／チェックポイント／BRファイル

LogMining サーバー

REDO転送

OCI接続

ファイル I／Oウェアハウス

双方向GoldenGateレプリケーション

68

（新）プライマリ データベース

Oracle Shardingを使用オプション

エディションベースの再定義を使用

任意

GoldenGateと2つのオプション・アプローチでアプリケーションの保護を強化

Oracle GoldenGateを使用必須

69

• アプリケーションのアップグレードをオンラインで実行可能• コード変更は新しいエディションに内部的にインストール

• データ変更を安全に実行するために、旧エディションでは表示されない新しい列や表にのみ変更を書き込み

• エディションごとに異なる表示で表を公開するエディション・ビューにより、各エディションに固有の列のみを表示

• 古いエディションでのデータ変更を新しいエディションの列に、または（ホット・ロールオーバーでは）その逆方向に、クロスエディション・トリガーで伝播

エディションベースの再定義アプリケーションのオンライン・アップグレード

70

Oracle Shardingを使用オプション

エディションベースの再定義を使用

任意

GoldenGateと2つのオプション・アプローチでアプリケーションの保護を強化

Oracle GoldenGateを使用必須

71

Platinumのオプション：シャーディング

• シャード・キーの使用のために最適化されたカスタム構築アプリケーション

• 独立したデータベース（シャード）間のデータの水平パーティショニング– 各シャードはデータのサブセットを保持– シングルノードまたはRACまたはPDBが可能– レプリケーションによる高可用性

• シェアード・ナッシング・アーキテクチャ：– シャードはいずれのハードウェア

（CPU、メモリ、ディスク）もソフトウェア（クラスタウェア）も共有しない

スケーラビリティに優れた、インターネット・アプリケーション向けのフォルト・トレラント・アーキテクチャ

データベース

表1 シャード1 サーバー1

表1 シャード2 サーバー2

表1 シャード3 サーバー3

72

単一の論理DBをN個の物理データベースにシャーディング

Data Guardを使用したシステム管理によるSDBのデプロイ

クライアント

Data Guardファスト・スタート・

フェイルオーバー

リージョンAvailabilty_Domain1

シャード・カタログshardcat_stdby

シャード・ディレクタshdir3,4

リージョンAvailabilty_Domain2

シャード・グループshgrp2

シャード・グループshgrp1

…

シャード・ディレクタshdir1,2

シャード・カタログshardcat

接続プール

プライマリ…

HAスタンバイ

73

接続プール

シャーディング構成の選択肢Active Data Guard、Oracle RAC、Oracle GoldenGateを用いたシャーディングを使用

74

GoldenGateの‘チャンクレベル’のアクティブ／アクティブ・レプリケーションと自動競合検出／解決

https://www.oracle.com/database/technologies/high-availability/sharding.html

Active Data Guardとファスト・スタート・フェイルオーバー

任意 – Oracle RACによるレプリケーションでサーバーHAを補完

Maximum Availability Architecture（MAA）

サマリーとリソース

Copyright © 2019 Oracle and/or its affiliates.

外部リソース

Maximum Availability Architecture• MAAホーム：

• http://oracle.com/goto/maa• オンプレミスMAA：

• https://www.oracle.com/database/technologies/high-availability/oracle- database-maa-best-practices.html

• Exadata MAA：• https://www.oracle.com/database/technologies/high-availability/exadata-

maa- best-practices.html• Cloud MAA：

• https://www.oracle.com/database/technologies/high-availability/oracle-cloud- maa.html

76

Oracleデータベース向けの最高のHA、DR、データ保護ソリューションを提供

検証済みのMAAソリューションを継続的に強化

お客様の成功は当社の成功です！

Copyright © 2019 Oracle and/or its affiliates.