form 10 -k form 10 -q sec web // · oracle exadata cloud. のサービス ....

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

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

免責条項

Copyright © 2019 Oracle and/or its affiliates.

http://www.oracle.com/investor

Exadata Database Machine：Maximum Availability Architecture（MAA）

技術に関するプレゼンテーション

2019年11月

プログラムのアジェンダ

ExadataとMaximum Availability Architecture

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

ExadataにおけるMAAの特徴

MAA Exadataライフサイクル操作

まとめ

1

2

3

3

4

5



ExadataとMaximum Availability Architecture


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

オンプレミス

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

DBCS/ExaCS/ExaCC

自律型データベース

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

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

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

SLAへのシフト

5Copyright © 2019 Oracle and/or its affiliates.

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

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

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

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

91%

1000万ドル

35万ドル

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

87時間


高可用性（HA）に関するビジネス上の課題

停止時間とデータ損失のリスクを排除

ROIを増加させながらサービスを向上


Exadataで高可用性の課題に対処計画停止および計画外停止からの保護


停止の種類高可用性に関する課題 Exadataの使用による保護

計画停止

混乱を引き起こすスキーマ変更（変化し続けるビジネス要件に対応するためのアプリケーション変更に起因）

スキーマ変更による影響は、迅速な変更、インデックスとオブジェクトの再構築および再編成により大幅に縮小

ライフサイクル管理に必要な停止時間（ファームウェアやソフトウェアの定期アップグレード、データの移行など）

高速なオンライン・アップグレード、サービスの移行に伴うパッチ適用の自動化、Standby First Patch、および停止時間ゼロでの移行により、ライフサイクル管理に必要な停止時間を短縮

計画外停止

データの破損（ハードウェア/ソフトウェアの障害、メディアの問題に起因）

破損の予防、検出、自動修復の追加により、データ破損を回避、または潜在的な停止時間を大幅に短縮

アプリケーションの一時停止（サーバー、インスタンス・ストレージの障害または計画メンテナンスに起因）

高速なインスタンス・リカバリにより、アプリケーションの一時停止が秒未満にまで短縮

ディザスタ・リカバリ（DR）の課題（DRサイトが本番環境に追従しきれていない場合）

ディザスタ・リカバリ（DR）の課題は高速なREDOの適用により低減され、リカバリ時間目標が短縮

数十年にわたるデータベース・イノベーション。何百万ものミッション・クリティカルなデプロイでの実績

Exadata：ハードウェア+ソフトウェア+データベース+可用性

9

Exadata DB Machineのイノベーション

Oracle Databaseのイノベーション

Multitenant

インメモリDB

Real Application Clusters

Active Data Guard

パーティション化

Oracle Advanced Compression

Advanced Security、Label Security、DB Vault

Real Application Testing

Advanced Analytics、Spatial and Graph

Oracleデータベース用管理パック

InfiniBandファブリック

Columnar Flash Cache

HCC

10:1

I/OI/OI/O

ストレージ索引

Hybrid Columnar Compression

ExafusionDirect-to-Wireプロトコル

ストレージへのSQLのオフロード

I/Oリソース管理ネットワーク・リソース

Management

インメモリのフォルト・トレランス

PCIフラッシュ

Smart Flash Cache、ログ

最適化された冗長ハードウェアCopyright © 2019 Oracle and/or its affiliates.

Oracle Exadataの利点

理想的なデータベース・ハードウェア最先端のエンタープライズ・レベルのコンポーネントでパフォーマンスと価値を最大化する

スマート・システム・ソフトウェアデータベース対応アルゴリズムがあらゆるワークロードの効率を劇的に改善する

自動化Oracle Autonomous Databaseと統合される自動化されたインフラストラクチャ


オンプレミスとクラウドで同一

Oracle Exadata Cloudのサービス

中核となるExadataプラットフォーム

お客様の選択したデータセンターで

稼働

Exadata Cloud at Customer

データベースPaaSサービス

柔軟なサブスクリプション・モデル

オラクルが管理するExadataインフラストラク

チャ

セキュアな仮想ネットワーク

クラウドのセキュリティとハードニング

Exadata Public Cloud Service


オラクルのパブリック・クラウドのデータセンターで稼働

第2世代のExadata Cloud@Customer新機能

• 第2世代のパブリック・クラウドが第2世代のExadata Cloud at Customerを管理– お客様のデータセンターでControl Planeラックを追加する必要がなくなる– シンプルで低コスト、価値実現までの時間が短い

• 新しいExadata Cloud at Customer X8ハードウェア– ExaCC X7と比較してCPUが高速になり、コア数とストレージ容量が増加

• お客様のネットワークへの接続がシンプルに– お客様のネットワーク標準および要件に適応

• Oracle Database 19cをサポート– 12.2ファミリの長期サポート

• Autonomous Database at Customerに対応

パブリック・クラウドのUI

と管理

お客様のデータセンター

セキュア・トンネル

最高のクラウド、最高のプラットフォームで、最高のデータベースがお客様のデータセンターで稼働


• 冗長データベース・サーバークラスタ化された高可用性のアクティブ-アクティブ・サーバーホットスワップ対応の電源とファン冗長配電ユニット統合されたHAソフトウェア/ファームウェア・スタック

• 冗長ネットワーク冗長な40 Gb/s IB接続およびスイッチHAボンディング・ネットワークを使用したクライアント・アクセス統合されたHAソフトウェア/ファームウェア・スタック

• 冗長ストレージ・グリッド複数のストレージ・サーバーにまたがってミラー化されたデータ冗長なノンブロッキングI/Oパス統合されたHAソフトウェア/ファームウェア・スタック

Exadata:組込み済みの高可用性


Oracle Maximum Availability Architecture（MAA）

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

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

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

R製品への絶え間ないフィードバック

https://oracle.com/goto/maa14Copyright © 2019 Oracle and/or its affiliates.

https://oracle.com/goto/maa

Oracle Maximum Availability Architecture（Oracle MAA）

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

HA機能、構成、運用方法

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

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

Platinum

Gold

Silver

Bronze

レプリケーション

データ保護

継続的な可用性

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

Global Data Services

汎用システム

エンジニアド・システム

DBCSExaCS/ExaCC

Autonomous DB

フラッシュバック RMAN + ZDLRA

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

Active Data Guard GoldenGate

スケールアウト

RAC シャーディングASM


本番サイト

デプロイメントの選択肢

あらゆる障害シナリオに対処できるよう設計とテスト済みExadata Maximum Availability Architecture

最良のMAAデータベース・プラットフォーム | 最速のRACインスタンス/ノード障害リカバリ | 最速バックアップ -RMANによるストレージへのオフロード詳細なASMミラー化統合 | 最速のData Guard REDO適用 | 一時停止を最小

に抑えた完全な障害テスト頻繁に更新されるヘルス・チェック

HAフェイルオーバーのためのローカル・スタンバイデータの整合

性をチェックしながらREDOベースの変更レプリケーション

オンラインのパッチ適用、再構成、拡張

LAN WAN

サーバー、ディスク、フラッシュ、

ネットワーク、電力

サイト内サイト間ディザスタ・リカバリのためのリモート・スタンバイ

Oracle D

atabase In-M

emory

Database In-M

emory

Database In-M

emory


冗長ソフトウェアアクティブ・クラスタ、ディスク/フラッシュ・

ミラー化

Exadata内冗長ハードウェア

冗長システム

冗長データベース

冗長システム

冗長データベース

2019年9月 - Exadata MAA誕生

10年にわたる数多くのHA機能とベスト・プラクティス、世界クラスのHAhttps://www.oracle.com/jp/database/technologies/high-availability/exadata-maa-best-practices.html


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

Exadata MAAの進化

オンプレミス

オンプレミスExadata

データベース/Exadata Cloud データベース

• インフラストラクチャ管理

• アーキテクチャ• 構成、チューニング• データベースの管理• ライフサイクル操作• アプリケーション・パフォーマンス

• 構想• 製品と機能へのフィードバック

• インフラストラクチャ管理• アーキテクチャ• データベースの管理• 構成、チューニング• ライフサイクル操作• アプリケーション・パフォーマンス

• ブループリント• Exadataは最高の統合MAA DBプラットフォーム

• アーキテクチャ• データベース管理（ツール）• 構成、チューニング• ライフサイクル操作（ツール）• アプリケーション・パフォーマンス

自律型

• オラクルが、最高の統合MAA DBプラットフォームを所有し、管理

• プロビジョニングおよびライフサイクル操作のためのクラウド自動化

• SLAポリシーの選択• アプリケーション・パフォーマンス

• オラクルがインフラストラクチャを所有し、管理

• ポリシー主導のデプロイメント

• MAA統合クラウド• 完全に自動化された自己稼働、自己保護、自己修復データベース

お客様オラクル


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

• Exadata Database Machine• Data Guard / Active Data Guard• Multitenant• Zero Data Loss Recovery Appliance（ZDLRA）• Oracle Recovery Manager（Oracle RMAN）• Real Application Clusters（RAC）• エディションベースの再定義（EBR）• Oracle Sharding• Oracle GoldenGate（OGG） – 監視とアラート専用



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


21

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

オラクルが開発、認定したブループリント数万のオラクルの顧客によって検証レベルの上昇に合わせて機能が増加所定のサービス・レベルを達成するための要件：

• 規定の機能を活用• 規定の構成と運用のベスト・プラクティスを活用• 本番前テストでデュー・デリジェンスを実施• すべてのライフサイクル操作でデュー・デリジェンスを実施• 推奨されているパッチ・レベルとバージョンの維持


Oracle Maximum Availability Architecture（MAA）ソリューションの選択肢


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

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

数分～1時間

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

計画メンテナンス

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

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

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

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

ローカル・バックアップ

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

アップ

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

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

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

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

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

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

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

ブロンズ

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


データセンター内のZero Data Loss Recovery Appliance保護されたデータベース

データセンター内のすべてのDBを保護• ペタバイト単位のデータ• Oracle 10.2～18c、あらゆるプラットフォーム

• 高コストのDBバックアップ・エージェントは不要

Delta Store• 検証および圧縮されたデータをディスクに保存• どの時点にも高速リストアが可能• Exadataのスケーリングとレジリエンスが基盤• Enterprise Managerによるエンド・ツー・エンドの制御

Recovery Appliance

リモートのリカバリ・アプライアンスへのレプリケート

テープ・バックアップのオフロードDelta Push

•増分変更のみを送信し、全体バックアップは不要

•リアルタイム・トランザクションをコピーし、継続的にデータを保護

統合管理


テープ・ライブラリ• オフサイト・バックアップ• ボールティング

InfiniBandネットワーク

Storage Expansion RackとX8-2 Extended（XT）• 高速なバックアップとリストア• ILM履歴アーカイブ• セカンド・ディスク・グループ• DATAの拡張

Exadataのバックアップ

Recovery Appliance• Delta Pushおよびバックアップ検証• 永久的増分• データ損失ゼロのリカバリ能力

Database Backup Cloud Service• オフサイト・ストレージ

• 低コストパブリック・ネットワーク

ファイバ・チャネルSAN

IB、10 GigE、または25 GigE

ファイバ・チャネルSAN

10 GigEまたは25 GigE

メディア・サーバー


本番/部門

シルバー

Bronze +• Real Application Clustering（RAC）• アプリケーション・コンティニュイティ

計画外停止 RTO/RPO*

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

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


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

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

停止のマトリックス

RACデータベース

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


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

* RPO=0（明示的に指定されていない場合）Copyright © 2019 Oracle and/or its affiliates. 27

Oracle Real Application Clusters（Oracle RAC）

アプリケーション層

データベース・サービスデータベース

層

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

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

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

• 高いスケーラビリティ• すべてのインスタンスをアクティブ化、オンライン容量を追加、データベース統合に最適

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


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

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

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

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

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

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

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

リクエスト

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

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


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

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

• タイムラインを検証• 新しい接続を作成• ターゲット・データベースが再実行に適していることを確認

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

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

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

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

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

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

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

通常の操作• クライアントがリクエストを明示的かつ検出済みとしてマーク

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

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


アプリケーションの停止時間ゼロ達成のためのチェックリスト1. Oracle Clusterware Serviceを使用（デフォルトのサービスは使用しない）

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

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

3.フリートのパッチ適用およびプロビジョニングによるMAAプラクティスの採用


https://www.oracle.com/technetwork/database/options/clustering/applicationcontinuity/adb-continuousavailability-5169724.pdf

https://support.oracle.com/rs?type=doc&id=2385790.1

https://docs.oracle.com/en/database/oracle/oracle-database/19/cwadd/rapid-home-provisioning.html#GUID-CCEC5960-EDA4-4A3F-9643-0CA308EA49AA


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

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

数秒

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


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

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

セカンダリ・リージョン


リモート・スタンバイ

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


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

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

Silver +• Active Data Guard• 包括的なデータ保護

MAAアーキテクチャ：• ADまたはリージョン全体で少な

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

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

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

ゴールド

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

33

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

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

一般 - すべてのファイルへの書込みを送信することが必須….破損ブロックや不適切なデータを含む

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

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

• Oracleの検証なし• 7倍のネットワーク・ボリューム

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


Data Guardがストレージ・レプリケーションの欠点に対処不十分な独立性、アプリケーション・レベルの検証なし

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

整合性に関するEMC BLOG


機能物理的なブロック破損論理的なブロック破損Dbverify、Analyze 物理的なブロック・チェックブロック内およびオブジェクト間の

整合性に関する論理チェック

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

Active Data Guard

• スタンバイでの物理的な継続的ブロック・チェック• 厳密な分離により、シングル・ポイント障害を防止• 物理的な破損の自動修復• 自動データベース・フェイルオーバー（書込み損失時のオプション）

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

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

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

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

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

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

実行時

手動


Active Data Guardの概要

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

読取り専用ワークロード、またはほぼ読取りのワークロードをスタンバイ・データベースにオフロードスタンバイ

読取り専用でオープン

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

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

DMLリダイレクト

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

自動ブロック修復機能

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

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


Gold +

• Oracle GoldenGateアクティブ/アクティブ・レプリケーション

• 任意のエディションベースの再定義

MAAアーキテクチャ：• おのおののGoldenGate“プライマリ”レプリ

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

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

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

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

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

非常にクリティカル

プラチナセカンダリ・リージョン


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

GGレプリケーション

AD1 AD2

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

リ

停止のマトリックス

* RPO=0（明示的に指定されていない場合）** アプリケーション・フェイルオーバーはカスタム

計画外停止 RTO/RPO*

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

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

計画メンテナンスソフトウェアおよびハードウェアの更新ゼロ

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

ゼロ**


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

Oracle GoldenGateを使用必須

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

任意Oracle Shardingを使用

代替手段


Oracle GoldenGate Microservices Architecture

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

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

取得

デリバリー

証跡ファイル

Dist.Service

証跡ファイル

配信

キャプチャ

双方向

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

証跡ファイル

証跡ファイル

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

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

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

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

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

Dist.サービス

ReceiverService

Receiver Service


• アプリケーションのアップグレードをオンラインで実行可能

• コード変更は新しいエディションに内部的にインストール

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

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

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

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


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

44

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

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

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

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

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

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

データベース

表1

シャード1

サーバー1

表1

シャード2

サーバー2

表1

シャード3

サーバー3


Active Data Guard、Oracle RAC、Oracle GoldenGateを用いたシャーディングを使用

シャーディング構成の選択肢

45

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

Active Data Guardとファスト・スタート・フェイルオーバー任意 – Oracle RACによるレプリケーションでサーバーHAを補完

https://www.oracle.com/database/technologies/high-availability/sharding.htmlCopyright © 2019 Oracle and/or its affiliates.

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

Maximum Availability Architecture（MAA）

ExadataにおけるMAAの特徴


Exadata:Maximum Availability Architectureの特徴

データ保護

サービス品質

Managementパフォーマンス

一時停止の削減

コードおよび構成




データ保護

サービス品質




Exadata:データ保護ストレージ障害

• ドライブの障害が報告されているが、物理的な障害でない場合擬似的ドライブ障害を回避するため、ドライブ電源の自動再投入

• High Capacity DisksとExtreme Flash Cellsの両方で作業

• ストレージ障害の発生時に、• データベース認識型の優先順位に基づくリストアを実行

• 制御ファイル、ログ・ファイル、SPファイル、TDEキー・ストア、OCR、ウォレット、データベース・ファイルの順（MOS 1968607.1）

• 12.2以上：• ストレージ損失後の冗長リストアに要する時間を大幅に短縮

• 新規のREBUILDフェーズを最初に実行してREDUNDANCYをリストアし、その後BALANCEをリストア

• リバランス読取りにExadataフラッシュ・キャッシュを活用し、冗長リストアのパフォーマンスを最大30 %向上


Exadata:データ保護サービス・レベルを保護しながら効率的なリバランス

• インテリジェントで柔軟な電力設定のリバランス• 冗長リストアのタイミングとサービス・レベル保護の間で最良のバランスを探るためMAAラボにてテスト

• MAAのベスト・プラクティスのデフォルトは4（クラスタ間全体、デプロイ時に設定）

• MAAのベスト・プラクティスの最大値は64（クラスタ間全体、必要に応じて設定可能）

• 詳細情報とガイドを含むMOSノート757552.1が利用可能• データベース認識型の優先順位に基づくリストアを実行

• 制御ファイル、ログ・ファイル、SPファイル、TDEキー・ストア、OCR、ウォレット、続いてデータベース・ファイル（MOS 1968607.1）

• 冗長性を優先してリストアする12.2+ ASMリバランスにより、二次的な障害の可能性を大幅に低減

• リバランス読取りにフラッシュ・キャッシュを活用する12.2+ Exadataにより、冗長性リストアのパフォーマンスが最大30 %向上


Exadata ASM構成のベスト・プラクティスExadata:データ保護

1/8ラックおよび1/4ラックのASM高冗長性投票デバイス/クォーラム・ディスクのベ

スト・プラクティス・チェックリバランスの確実な実行のためのASM電力リミット・ベスト・プラクティス・チェック

現在は、各データベース・ノードで追加の投票デバイスを収容可能なiscsiベースのクォーラム・ディスクのチェックも実行3つのストレージ・セルそれぞれに、すでに投票デバイスを搭載済み


Do-Not-Service LED（X7以上）

• データセンターのテクノロジーで視覚的な利便性が向上し、停止の原因となる可能性のあるものを回避

• ストレージ・パートナー対応のASMDeactivationOutcomeセル属性を利用


• 2台のM.2ドライブにオペレーティング・システムとセル・ソフトウェアを搭載。ストレージ・サーバーのハード・ディスクとフラッシュ・ドライブには、アプリケーション・データのみを格納。

• M.2ドライブはIntel RSTe RAIDにより保護

• ストレージ・サーバーでアプリケーションへのサービスを継続しながら、オンラインの状態でシャーシを開いてM.2ドライブを交換可能

M.2高速障害保護およびオンライン交換（X7以上）

USBドライブとDBFS_DG

（デフォルト）


オンライン・フラッシュ交換（X7以上）「ホットプラグ」

• ストレージ・サーバーがアプリケーションへのサービスを継続しながら、シャーシを開き、フラッシュ・ドライブをオンラインで交換可能。

• 障害の発生したドライブの場合、ready時に交換

• オンライン・ドライブの場合は、オラクルに連絡することで、オラクルによる適切な対応が可能。例：

CellCLI> alter physicaldisk FLASH_2_2 drop for replacement;




データ保護

サービス品質




Exadata:サービス品質最適なパフォーマンスのために

• セル側のIO待機時間制限（ハード・ディスクおよびフラッシュ）• PCI経由でセルに対し過剰なIOが実行される場合

• 読取りIOはパートナー・セルにリダイレクト• 書込みIOはキャンセルされ、同一セル上の問題のない

フラッシュに一時的に書込み

• セル側ディスクの拘束• ディスクに不具合が発生し、オフラインになった場合

• ディスクに対し自動的に診断が実行され状態を確認• 問題がない場合、ディスクはONLINEステータスに戻り、

再同期• 問題があった場合、ヘルス要素ドロップ、リバランスの順

に実行し、完了すると青色のLEDが点灯

1


3040

30

20

10

0Exadata 従来の

ストレージ

数秒

IOハング後のLGWR遅延

Exadata:サービス品質スマート・ストレージとIOリソース・マネージャ


• 各IOに、IO発行者、目的、優先度をタグ付け• 複数段階のパフォーマンスで、多くのデータベースからなる混合ワークロード、統合を実行可能

IOタスクの例実行されるアクション

クリティカルなデータウェアハウスからの表スキャン

優先度の高い問合せ。IORMは、フラッシュとディスク両方の他のスキャンと比較して優先順位を決定。

非定型問合せによる表スキャン読取り優先順位が低く、リソース消費の多い問合せ。フラッシュへのステージング（空きがある場合のみ）。ディスクI/OまたはフラッシュI/Oの優先順位の引き下げ。

DBWR書込み - “空きバッファ待機”の心配なし

非緊急 –十分な空きバッファ。IORMは、このI/Oの優先順位を格下げ。

“空きバッファ待機”を解決するDBWR書込み緊急 –ユーザーはブロック。IORMは、このI/Oを優先。

LGWR REDO書込み優先度の高いI/O。Exadataフラッシュ・ログ経由で加速。

OLTPトランザクション、PDBのためのバッファ・キャッシュ読取り

中程度のI/O優先順位。フラッシュへのステージング。リソース計画に基づき、他のユーザーI/Oに照らして優先順位を決定。

スマート・フラッシュ交換

• フラッシュの障害発生後、そのフラッシュを支援するハード・ドライブ・セットに対し“ヘルス要素”ステータスが設定される

• 読取りは、フラッシュの量が減ったセルではなく、問題のないパートナー・セルが実行

• ヘルス要素ステータスは、フラッシュの交換とキャッシュ・ウォームアップの完了後にクリア

• この機能により、フラッシュ障害発生後のアプリケーション・サービス・レベルへの影響が低減


計画メンテナンス時またはストレージの問題発生時におけるSLAの維持Exadata:サービス品質

• ASMリバランス操作中、Exadataフラッシュ・キャッシュ・ステートを保持。実際の例：セル・ソフトウェアのローリング更新時に発生する再同期。

• セルへのI/Oリクエストのインテリジェント・ルーティングにより、フラッシュの障害と修理後も最良のサービスを提供

• 計画外停止および計画メンテナンスの両方に適用可能

パフォーマンスは時間なり時は金なり


データベース層のIOキャンセルOracle Grid InfrastructureおよびDatabase 19c

データベース層

ストレージ層

IOが低速?

IOがハング?

ディスクの不良?

検出されないハードウェアまたはソフトウェアの問題?

セルIOの待機時間制限 ✓

IOハングの検出/修復 ✓

ディスクの拘束 ✓

データベース層 IO待機時間制限 ✓

IOが過剰?


高冗長性ディスク・グループのリバランスOracle Grid Infrastructure 19c

Problem:ディスク障害後のリバランスで領域不足が発生（ORA-15041）18c以下の場合の解決策

オラクルのMAAベスト・プラクティスの遵守状況をレポートするexachkを実行

高冗長性ディスク・グループを使用する19cの場合の解決策

スマート・リバランス -空き領域の必要なし障害発生時のリバランスに十分な領域がない場合は、ディスクをオフラインにする交換が完了すると、パートナー・ディスクから自動的に効率よく再移入される

19cの冗長性の高いディスク・グループに0 %の空き

標準または冗長性の高いディスク・グループに15 %の空き（ディスク・グループは5つ未満のExadataセルで構成され、GIのバージョンは12.2および18c）

標準または冗長性の高いディスク・グループに9 %の空き（ディスク・グループは5つ以上のExadataセルで構成され、GIのバージョンは12.2および18c）


まとめ：データベース層のIOキャンセルOracleが

提供する機能• ストレージ層の一般的でないストール/ハングからの保護

ユーザーが実装可能なベスト・プラクティス• ありません。完全に透過的。

サービス・レベルへの影響の予測

• ストール/ハング時のIOリダイレクションにより安定したサービス・レベルを達成




データ保護

サービス品質




Exadata:管理Enterprise Manager 13c – 改善されたプラグイン

• データベース統合ワークベンチ• 計画、移行、検証• 統合により節約されるIO帯域幅の予測

• パッチの自動適用• 仮想化環境におけるExadataのライフサイクル管理• RACデータベースおよび

VMの作成/削除• クラスタおよびVMのスケール・アップ/ダウン

• Exachk統合64Copyright © 2019 Oracle and/or its affiliates.

障害発生時の通知および交換のプロセスExadata:管理

障害


Managementコンポーネントの破損 ASR（Auto Service Request）による、完全に自動化された通知および交換

のプロセス

コンポーネントの不調完全なスタック統合により、不調なコンポーネントの対応をExadata単独で担当。Exadataは、システム/サービス・レベルの高可用性を確保。

人為的エラーの防止に役立つインテリジェントなハードウェア/ソフトウェア統合

ディスク交換が可能であることを示す青色の点灯表示。冗長性が損なわれそうな場合はセルのシャットダウンを防止して通知。X7のDo Not Service LED

アプリケーション停止を招くセル・シャットダウン

セル（またはcellsrv）シャットダウン時における、データベース層とのスマート・ハンドシェイクおよび事前対応的冗長性チェックにより、アプリケーション停止を回避。

• ドキュメント『Oracle Exadata Database Machineシステム概要』の「新機能」セクションより• Oracle Exadata Storage Software release 12.2.1.1.0では、GetExaWatcherResults.shにより、

IO、CPU利用率、セル・サーバー統計、アラート履歴のグラフを含むHTMLページを生成。IOとCPU利用率のグラフはiostatのデータを、セル・サーバー統計はcellsrvstatのデータを使用。アラート履歴は、指定の時間枠について取得。

• 次のスライドで具体例を紹介します。


Exadata:管理ExaWatcherグラフ化サポート

Exadata:管理EXAchkユーティリティを使用したヘルス・チェック


• EXAchkは、スタック全体にわたって、構成に合わせた最新のヘルス・チェックを実行• Exadata、データベース、Grid Infrastructure、ASMの重大な問題をカバー• MAA構成ギャップおよび低減のためのガイダンスを含むMAAスコアカードを提供

• 定期スケジュールに基づく自動実行（電子メール通知あり）• 構成チェックの連続的展開• EXAchkは、停止時間を大幅に削減する事前対応的ヘルス・チェックを実行し、多くの時間とお金の節約に貢献

• 現在、1ターゲットにつき、1,000種を超えるチェックを実施注：Automated Exachk Healthcheck MOS 107954.1

MAAスコアカード重大な問題、互換性のない機能の使用

EXAChk：サンプル・レポート評価レポート

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

検出事項および推奨事項

問題の解決方法


Diagnostic Pack


• ストレージ・サーバーに関するログ、トレース、関連の診断情報、およびindex.htmlを含む、圧縮されたアーカイブ

• 特定のインシデント向けにカスタマイズされたコンテンツ• アラートについて発信される電子メールは、diag packに加え、当該サーバー上のdiag packへのリンクを含む。

Diagnostic Packの例不具合の生じたコンポーネントへの対処


パフォーマンスに関する問題の手がかりを集約Exadata AWRサポート


• ストレージ・サーバー間での構成の違いを検出• Exadata Storage Serverモデル• Exadataストレージのバージョン（パッケージごと、またはパッケージ・バージョンごとのグループ）

• Exadataストレージ情報（すべての列（フラッシュ・キャッシュ・サイズ、フラッシュ・ログ・サイズ、ハード・ディスク数、フラッシュ数、グリッドディスク数）ごとのグループ）

• Exadataグリッドディスク（グリッドディスク数、グリッドディスク・サイズおよびディスク・タイプごとのグループ）

• Exadataセルディスク（ディスク・タイプ、セルディスク・サイズおよびセルディスク数ごとのグループ）

• データ・シートの限度値と比較して統計上の違いを検出• OS統計の最大IOPS/スループットは、暗い赤色で表示• OSおよびセル・サーバーの統計の外れ値は、色付きで表示（超える値はローズ色、下回る値は黄色）


Exadata AWRサポート独特の構成および外れ値の検出

Exadata AWRサポート実際の（大規模）顧客における外れ値検出例




データ保護

サービス品質




Exadataは大規模サーバーの経済性を活かし、最新テクノロジーを最良のコストで獲得

サーバーを中心に据えた最先端アーキテクチャ

最新かつ最速のプロセッサを即座に採用

超高速InfiniBandの統合

PCIフラッシュ

最速CPUによるスケールアウト


最新の超高速ネットワークを使用faults fault.chassis.device.fail

ストレージ・サーバーのスケールアウトストレージのインテリジェント機能を有効化

超高速NVMe PCIeフラッシュ

容量の大きいディスク・ドライブを即座に採用

最速のNVMe PCIeフラッシュを即座に採用PCIe

フラッシュおよび大規模ディスクの階層化

Exadata:パフォーマンスExadata独自のハードウェアおよび

ソフトウェアの特徴Exadata Smart ScanおよびReverse OffloadExadata Smart LoggingExadata Smart Persistent Write Back Flash CacheExadata Persistent MemoryExadataアクティブ/アクティブIBネットワーク

MAA機能最速のオブジェクト再編成最速のインスタンス・リカバリ最速のフラッシュバック性能Exadataへの最速バックアップ、Recovery Appliance最速のActive Data GuardおよびスタンバイREDO Apply最速のGoldenGateパフォーマンス

Exadataハードウェア+Exadataソフトウェア+Oracle Databaseが究極のパフォーマンスを提供!!


Exadata Smart System Softwareもっとも高速な分析

独自のSmart Scanが、データ処理の負荷が高いSQL操作をストレージに自動でオフロード独自のSmart Flash CacheとStorage Indexにより、データベースI/Oを自動で高速化独自のデータ自動変換により、フラッシュへのインメモリ列形式にデータを高速変換

もっとも高速なOLTPストレージのスケールアウト、RDMA、NVMeフラッシュによる最高速のOLTP I/O

独自のRDMAアルゴリズムでノード間でクラスタを調整し、最速でスケールアウト完全な冗長性、故障したコンポーネントや不具合の生じたコンポーネントから最速でリカバリ

最高の統合フル・スタック全体で、待機時間の影響を受けやすいワークロードや重要なワークロードを独自に優先順位付けフル・スタック全体で、複数のテナントからワークロードを独自に分離


Exadata X8M（X8からの変更点は赤字）


2または8ソケット・データベース・サーバーのスケールアウト最新の24コアIntel Cascade Lake

100 GbのRDMA over Converged Ethernet（RoCE）内部ファブリック

インテリジェント2ソケット・ストレージ・サーバーのスケールアウトストレージ・サーバーごとに1.5 TBのパーシステント・メモリ3層のストレージ：PMEM、NVMe、HDD

Linux KVMを使用した統合の強化

Exadata KVMのベスト・プラクティスはすべてこちらから入手できます。https://www.oracle.com/jp/database/technologies/high-availability/exadata-maa-best-practices.htmlMAAの注目すべき点の一部：

• KVMでサポートされるゲスト数は12（Xenでは8）• Exadataの前世代は、Data GuardまたはGolden Gateを通して接続可能• 標準のバックアップ手順を適用

• KVMホストは、任意でVMディスク・イメージのスナップショットを取得し、外部に保存

• patchmgrによってExadataのコア・インフラストラクチャを更新• oedacliによってGrid InfrastructureとDatabase ORACLE_HOMEを更新• vm_makerとoedacliによって、ライフサイクル操作を実行


KVMMAAの特徴

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

PMEM

ホット

ウォーム

コールド

PMEM

フラッシュ

ディスク

データベース読取り

バッファ・エビクションの実行

MAAの特徴• 比率は正確ではない• 読取りミスの発生時に、データのプライマリ・コピーをPMEMキャッシュに配置

• バッファ・エビクション時に、フラッシュ・キャッシュにデータのセカンダリ・コピーを配置

PMEMがWritethroughモードで失敗した場合、冗長リストアは不要

PMEMがWritebackモードで失敗した場合、リシルバ操作が実行されて冗長性がリストアされる

待機時間の短いフラッシュ読取りで、非常に待機時間の短いPMEMに再移入する

バッファ・キャッシュ

非常に頻繁なアクセス

Exadataデータのアクセス層

データベース・ノードストレージ・セル

X


つのアクティブ-アクティブ・ポートをすべてのRDMAネットワーク・ファブリック・アダプタに

つのRDMAネットワーク・ファブリック・スイッチをすべてのExadataシングル・ラックに

2222 個のポートをスイッチごとに内部

クラスタ・ネットワークに使用し、シングル・ポイント障害が発生しないように配線

RDMA over Converged Ethernet（RoCE）

RDMAネットワーク・ファブリック・アダプタ

RDMAネットワーク・ファブリック・スイッチ


RDMAネットワーク・ファブリックMAAの特徴

つのRDMAパスがデータベース・ノードとセル間に存在し、セルの有効性を監視。

短い中断後に4つのすべてが使用できない場合は、セルのエビクションが実行される

4

ちょっと待ってください、Exadata Fast Node Death Detection（FNDD）がInfiniBand Subnet Managerをどのように使用するか、以前に話してくれましたが、Exadata X8MにはInfiniBanスイッチがありませんよね。FNDDはどのように動作するのでしょうか？

秒でセルのエビクションは完了し、SLAに対応<1 X

データベース・ノード

セル

RDMA読取り

X X X X


RDMAネットワーク・ファブリックMAAの機能ネットワーク・ファブリック・スイッチのソフトウェア更新

• 同じツール、patchmgr

• 独立したソフトウェア更新パッケージ

• 最適化されて組み込まれたポートのダウン/アップのイベント処理

• -verify-configおよび–roceswitch-precheckオプションで事前に状態をチェック可能


• スタンバイ・データベース側のすべてのRACノードを使用してリカバリをパラレル化

• Exadata上のOLTPワークロードの大幅な拡大を確認

マルチインスタンスREDO ApplyのパフォーマンスActive Data Guardスタンバイ・データベースの待機時間を短縮

740


14801400

2752

5000

0

1000

3000

2000

7000

6000

5000

4000

700190 380

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

バッチ

OLTP

スタンバイ適用速度（MB/秒）

1インスタンス 2インスタンス

• Thomson-Reuters• Exadata上にデータウェアハウス。以前はライトバック・フラッシュ・キャッシュ

• ギャップを解消しながら、580 MB/秒の平均適用速度を記録• Allstate Insurance

• データウェアハウスのETL処理により、3時間で668 MB/秒の平均適用速度を記録。ピーク値は900 MB/秒


顧客での本番環境例（2社）Data Guard REDO Applyパフォーマンス



データ保護

サービス品質




一時停止は、サービス・レベルの大幅な低下。停止は、サービス・レベルの完全な中断一時停止および停止は、生産性の低下と収益の損失システムは多数のコンポーネントで複雑化しており、1つのレイヤーの問題が別のレイヤーに簡単に連鎖し、事態を悪化させるおそれがあるエンジニアド・システムは、この非常に難しい問題を解決する唯一の手段


一時停止および停止サービス・レベルに直結

Exadata Marquee/新たなHA機能HA一時停止の削減 – データベース・ノードおよびセルにおけるノード停止の高速検出

データベース・ノード電源障害の例（OLTPワークロードおよびCSSのミスカウント=60）


通常構成におけるアプリの一時停止アプリケーション・スタックのレイヤーごとに独自の障害検出手法ベンダーはクライアント側の障害の数を引き合いに、これらの詳細をわかりにくくするほとんどの場合、障害検出回数は付加的

たとえば、ストレージ・コントローラが故障した場合、データベース・サーバーがこの障害を検出するために2回のSCSIタイムアウトが必要

ストレージ・コントローラ

ストレージ・コントローラ

クラスタウェアタイムアウト

SAN/LAN SCSIタイムアウト

独自プロトコルのタイムアウト


サーバーが両方のInfiniBandスイッチから消えた場合、2秒未満でそのサーバーの停止を宣言

時間のかかるハートビートのタイムアウトを待つ必要なしアプリケーションの一時停止を30秒以上から2秒未満に短縮

アクティブ/アクティブIB構成により以下が実現

並外れたスループット - 40 Gb/秒QDR並外れた可用性 -数秒でのRDSフェイルオーバーでアプリケーションへの影響は最小限

Exadata:独自の一時停止削減機能Instant Failure Detectionによりアプリケーション稼働時間を最大化

0.8

300

0

50

100

150

200

250

300

350

Exadata サード・パーティのストレージ

アプリケーションの一時停止

数秒


ノード停止の高速検出（FNDD）機能に関する1分間のビデオをご覧ください。注意深くご覧いただくと、35秒近辺のマークのところで新しい機能について確認していただけます


Exadata:一時停止および停止2008年以来変わらないサービス・レベル

従来の機能とベスト・プラクティスの詳細については、http://www.oracle.com/technetwork/database/availability/exadata-maa-best-practices-155385.html、MOS Note 757552.1、exachkレポート、以前のOOW MAA Exadataプレゼンテーション、およびExadataのドキュメントを参照してください。

http://www.oracle.com/technetwork/database/availability/exadata-maa-best-practices-155385.html

ASMインスタンスのクラッシュ後もFlex ASMによりRDBMSとASM間の通信が継続。サービスのフェイルオーバーは不要アプリケーションに対して完全に透過的で、サービス・レベルにも影響なし

一時停止および停止Oracle Flex ASM

カーディナリティを備えた構成のFlex ASM=Exadata上ですべて対応


Exadata:一時停止および停止ネットワーク・ポート障害関連の一時停止における最近の改善点


アクティブ/パッシブ・クライアント・アクセスにおけるネットワーク・ポート障害に関連した一時停止は、ネットワークのdowndelayパラメータ値削減を徹底した結果、60 %削減されました。OVM使用時の誤検出によるVIPフェイルオーバーも回避されます。この構成変更はデフォルトのExadataデプロイメントに含まれ、ベスト・プラクティス・チェックはexachkに含まれます。

ストレージ・サーバー停止時におけるスマート・ハンドシェイクGrid Infrastructure 12c以上/Exadata 12.1以上

• ストレージのシャットダウン時、データベース・サーバー上のdiskmonプロセスに対しクリアな通信を確保することで、エラーおよびアプリケーション停止を回避。

サービス・レベルに笑顔がこぼれます!


データベース層

ストレージ層

まとめ：ストレージ・サーバー停止時におけるスマート・ハンドシェイク


ストレージ・サーバー停止時におけるデータベース層への適切な対処

適切なシャットダウン手順を使用。関連：グリッド・ディスクが適切に扱われるため、ストレージ・サーバー・ソフトウェアの更新にはpatchmgrを使用

メンテナンスのためのストレージ層シャットダウン時に停止なしエラーまたはアラートの誤検出なし

Oracleが提供する機能

ユーザーが実装可能なベスト・プラクティス

サービス・レベルへの影響の予測

スマートOLTPキャッシング

X

19c Grid Infrastructure：ストレージ障害時もSLAを維持• 1次ミラーからデータを読み取る

SaaSアプリケーション• 1次ミラーを含むセルでストレージ障害が発生

• 問題なし。待機時間の短いフラッシュ上の2次ミラーからデータを取得するだけでよい

• 何事もうまくいかない場合に備えて、3次ミラーで保護を継続

• ストレージ障害の修復後、セルのキャッシュ状態が正常に戻ったとみなされたら、1次ミラーに復帰




データ保護

サービス品質




Exadataは多くのHA機能を備え、もっとも厳格なSLAをサポートノードおよびセル停止の高速な検出

ネットワーク障害の高速な検出

cellsrvシャットダウン時の冗長性保護

セル・シャットダウン時の冗長性保護

IOエラー破損時における自動ASMミラー読取り

Exadataディスク・スクラビングおよびASM破損修復によるIOエラー回避Exadata HARD

電源停止時の冗長性チェック

取り外しOKを知らせる青色LED通知

Exadata Smart Write Back、Smart Flash Logging、Smart Scan、およびReverse Offload最速のREDO Applyとインスタンス・リカバリ

フラッシュ障害後の効率的なリシルバ・リバランス

読取りおよび書込みにおけるI/O待機時間制限

セルIOタイムアウトしきい値

Smart Write Back Flash Cache永続性

I/Oおよびネットワークのリソース管理

障害と断定されるディスクのヘルス要素

ディスクの拘束

IO停止の検出および修復

ディスク修復時におけるセルからセルへのオフロード

セル間のリバランスによるフラッシュ・キャッシュの保持

柔軟性のあるExadata構成

インスタンス・リカバリ時の一時停止の短縮

ILOMハングの検出および修復

HARDサポートによる破損回避

ドライブ障害誤検出の排除

ハード・ディスクのドロップと交換

アクティブ・アクティブIBネットワーク BBUのドロップと交換

アプライアンス・モードのサポート

セル・アラートのサマリー

フラッシュとディスクのライフサイクル管理のアラート

ディスク取外しのための自動LEDサポート

自動オンライン

自動ディスク管理

優先順位リバランスのサポート

EM障害レポート

データベース・サーバーに対する障害モニタリングpatchmgrによるデータベース・ノードの更新

最適化、高速化されたExadataパッチ適用

セル・アラート用カスタム診断パッケージ

VLANのサポートおよび自動化

Exachk –フル・スタック・ヘルス・チェック（重大な問題のアラートあり）


Exadata MAAの利点

事前にパッケージ化されたMAA

デプロイメントの高速化*、不確定作業およびチューニング要

件の削減

停止時間の削減

数秒の停止/一時停止

破損の回避および修復

破損回避機能により停止時間ゼロ

HAサービス品質

あらゆるスケールにおけるHA SLA

の実現

信頼できるスケーラブルなパフォーマンス

あらゆるスケールにおける信頼できるネットワークおよびストレージ・パフォーマンス

エンド・ツー・エンド

管理

エンド・ツー・エンドの可視性を備えた統合

ツール/レポート


*ExaCSで事前デプロイ済み / ExaCS

Exadata MAAソリューションの統合

すべてのExadata MAA構成のベスト・プラクティスが組み込まれているExadata MAA運用のベスト・プラクティスはお客様が実装

第2世代のExadata Cloud at Customer

オンプレミスExadata

すべてのExadata MAA構成のベスト・プラクティスが組み込まれている一部のExadata MAA運用のベスト・プラクティスが組み込まれている

すべてのExadata MAA構成のベスト・プラクティスが組み込まれている

すべてのExadata MAA運用のベスト・プラクティス

が組み込まれている

第2世代のExadata Cloud / Autonomous Database




データ保護

サービス品質




アプリケーション稼働時間を最大限にする高可用性

他のAL4システムは以下のみ• IBM - z Systems• HPE - Integrity NonStop &

Superdome• Fujitsu – GS & BS2000• NEC – ftサーバー/320シリーズ• Stratus ftServer & Vシリーズ• Unisys – Dorado

「ExadataとSuperClusterはどちらも、Maximum Availability

Architecture構成においてAL4フォルト・トレランスを達成」

ファイブ・ナインズ

5x999.999%

新たなゴールド標準


IDCレポート*真のビジネス価値を提供するExadata

Global 2000にランクインする8つの企業の平均• 5年間のROI：429%

• 平均11か月で回収• 計画外停止時間が94 %減少

「…複雑な要素がはるかに少なく、保守すべきボックスはばらばらでなく、単一のテクノロジーを活用...」

—オラクルのお客様IDC：Business Value of Oracle Exadata Database Machine

2016年9月

*IDCホワイト・ペーパー（スポンサー：オラクル）2016年9月


リスクの軽減 -停止時間Oracle Exadata Database Machine

Oracle Exadata使用前

Oracle Exadata使用時

差メリット（%）

計画外停止時間年あたりのインスタンス数 7.1 0.7 6.5 90 %

MTTR（時間） 2.9 0.4 2.5 86 %

生産時間の損失（年間100ユーザーあたり） 1,021 66 955 94 %

計画外停止時間 –収益への影響総収益への影響（年あたり） 423,700ドル 5,800ドル 417,900ドル 99 %

計画停止時間年あたりのインスタンス数 10.9 6.0 4.9 45 %

MTTR（時間） 4.6 1.9 2.7 59 %

生産時間の損失（年間100ユーザーあたり） 68 60 8 12 %

出典：IDC108Copyright © 2019 Oracle and/or its affiliates.

Maximum Availability Architecture（MAA）

まとめ


高度にエンジニアドされ標準化されたExadataより低リスク、優れた稼働時間=より良い結果

• デプロイメントのリスクが低く、迅速に市場へ提供可能• 組み立てとデバッグが完了済みで提供。すぐに稼働可能

• パフォーマンスおよび可用性におけるリスクが低い• ファームウェア、OS、ネットワークを含め、データベースから

ディスクに至るまで最適化済み• スタックの各レイヤーにおいて業界の専門家が、Exadataの設計、

構築、サポートに貢献。MAAの情報提供、バグ修正、構成プラクティスを含む

• 低い運用リスク• すべての障害モードをエンド・ツー・エンドでテスト済み。

すべてのシステムが同一• 問題解決時間の短縮、ベンダー管理オーバーヘッドの削減、SLAの向上• オペレーション・プレイ・ブック（オンラインの柔軟性を含む）の確立


最高の混合ワークロード・パフォーマンス、パフォーマンスの独立性、可用性

統合のためのExadataおよびDatabase as a Service

• 統合システムではどのようなボトルネックも、すべてのワークロードの停止につながる可能性がある。Exadataは、ボトルネックを排除– 最高のネットワーク帯域幅、ストレージ・オフロード– 秒あたり数百万のI/O、独自のログ最適化

• Exadataは、プラガブル・データベース、ジョブ、ユーザー、サービスなどを基準にI/Oの優先順位を独自に決定

• Exadataは、ファブリック全体を通じ、重大なDBネットワーク・メッセージの優先順位を独自に決定

• Exadataは、エンド・ツー・エンド保証のため、I/Oの優先順位とCPUの優先順位を独自に統合

製造

マーケティング

人事管理

技術

営業

サービス

IT/オペレーション財務および会計


Exadata+MAA：何千もの重要なデプロイメント

• ペタバイト規模のウェアハウス• オンライン金融取引• ビジネス・アプリケーション

• SAP、Oracle、Siebel、PSFT…

• DBの大規模統合• パブリックなSaaSクラウド

• Oracle Fusion Apps、Salesforce、SAS、…

半分がOLTP - 半分が分析 -多くが混合

業界上位5社のうち4社がExadataを実行（銀行、通信、小売りの各業界）


Exadataは毎年常に進化を継続

• Smart Scan• InfiniBandスケールアウト

• データベース認識フラッシュ・キャッシュ• ストレージ索引• 列圧縮

• IOの優先順位• Data Mining Offload• スキャン時の復号化をオフロード

• インメモリのフォルト・トレランス• Direct-to-Wireプロトコル• JSONおよびXMLのオフロード• Instant Failure Detection

• ネットワーク・リソース管理• マルチテナント対応リソース管理• 優先順位に基づくファイル・リカバリ

• ストレージのスケールアウト

• サーバーのスケールアウト

• 統合InfiniBand

• ストレージ内のDBプロセッサ

• 階層型ディスク/フラッシュ• PCIe NVMeフラッシュ

• ソフトウェア・イン・シリコン

• 3D V-NANDフラッシュ

• Oracle Maximum Availability Architecture• Smart Fusion Block Transfer

• Exadata Cloud at Customer• インメモリOLTPアクセラレーション

• フラッシュにおけるインメモリ列

• ホットスワップ対応フラッシュ

• 25 GigEクライアントネットワーク

パフォーマンスとコストを


大幅に改善

Exadataと他のエンジニアド・システムとの組み合わせ

ExadataDatabase Machine

ZFS Backup Appliance

データ保護

Big Data Appliance

Big Data SQL

Exalogic Elastic Cloud

Private Cloud Appliance

ミドルウェア/アプリケーション

Oracle Database Appliance

部門

Zero Data LossRecoveryAppliance

Oracle MiniCluster


SuperCluster

まとめ：高可用性に関する決断がより容易に


保護が必要となる原因 Exadata+MAAの使用直観的でない二重のストレージ障害 Data Guardによる高い冗長性または標準的な冗長性データ損失および停止時間災害の場合：Data Guard、Golden Gate ->

http://www.oracle.com/goto/maaを参照リカバリを必要とするローカル障害の場合：確実に機能するようリストア/リカバリ戦略をテスト

計画メンテナンス中の予期しない問題

サービス・レベル内で停止時間を確保する余地がある場合は、停止時間を利用。そうでない場合は、各層で利用できるローリング・パッチを活用

予期しない本番ワークロード・プロファイル

本番と同様の環境、DBMS_WORKLOAD_REPLAYをテスト

既知の重大な問題月に1回、および新しいリリースが公開されたときにEXAchkを実行サービス・レベルに影響するリソースの枯渇

新規顧客のための容量計画、リソース管理、Enterprise Manager、RAS

過剰なカスタマイズできる限りオラクル製品を活用し、投資に見合った効果をエンジニアド・システムより最大限に享受

http://www.oracle.com/goto/maa

form 10 -k form 10 -q sec web // · oracle exadata cloud. のサービス ....

Documents