exadata database machine上でのデータベース統合 …...て、1つのoracle exadata database...

Oracleホワイト・ペーパー 2013年10月

Exadata Database Machine上でのデータベース統合に関するベスト・プラクティス

Oracle Maximum Availability Architecture Exadata統合に関するベスト・プラクティス

概要 ......................................................................................................................................................... 2 はじめに ............................................................................................................................................... 2 Exadata統合の計画 ......................................................................................................................... 3 安定性確保のための主要なリソースのセットアップと管理 ................................... 6

推奨されるストレージ・グリッド（ディスク・グループ）の構成 .............. 6 推奨されるデータベース・グリッド（クラスタ）の構成 ................................. 8 推奨されるパラメータ設定 ................................................................................................. 9 システムの監視と確認の開始 .......................................................................................... 19

リソース管理 ................................................................................................................................... 19 Resource Managerによるデータベース間（スキーマ）統合 ......................... 19 Resource Managerによるデータベース統合 ............................................................ 20 使用例1：OLTP DBとの統合 ............................................................................................. 23 使用例2:混合ワークロードとの統合 ............................................................................. 24 使用例3：データウェアハウスとの統合 .................................................................... 24 使用例4：混合カテゴリの統合........................................................................................ 25 リソース管理に関するベスト・プラクティス ........................................................ 25

メンテナンスと管理に関する考慮事項.............................................................................. 25 Oracle Softwareおよびファイル・システム領域 ................................................... 25 セキュリティおよび管理ロール ..................................................................................... 26 統合用のExadata MAA ......................................................................................................... 27 パッチ適用とアップグレード .......................................................................................... 29 バックアップとリカバリ .................................................................................................... 30 Data Guard ................................................................................................................................. 31 スキーマ統合によるリカバリ .......................................................................................... 32

まとめ .................................................................................................................................................. 32


2

概要複数のスキーマ、アプリケーション、データベースをターゲット・システムでホストする場合は、統合によってアイドル・リソースを最小限に減らし、コストを削減できます。統合によって、パブリック・クラウドやプライベート・クラウドにOracle Databaseをデプロイしやすくなります。

本書ではExadata Database Machine（Exadata）統合に関するベスト・プラクティスを紹介し、安定性と可用性を最大限高めるためのシステムおよびアプリケーションのセットアップと管理方法を説明します。

はじめに

IT部門において、統合は組織の運用効率向上のための主要な戦略の1つです。統合によって組織はITリソースの使用率を高め、アイドル・サイクルを最小化することができます。このため、同じ結果を出すのに必要なリソースが減り、コストを削減できます。たとえば、1日のピーク・ロード時間が異なる複数のアプリケーションで同じハードウェアを共有できます。このためピーク時以外はアイドル状態となる専用ハードウェアを使用する必要がありません。

使用するシステムや環境によって、データベース統合の方法はさまざまです。たとえば、1つのデータベースで複数のアプリケーション・スキーマを実行したり、1つのプラットフォームで複数のデータベースをホストしたり、これらの2つの方法を組み合わせたりすることができます。

ExadataはOracle Data WarehouseとOLTPデータベースのワークロード用に最適化されており、データベース・サーバーとストレージ・グリッド・インフラストラクチャがバランス良く構成されているため、データベース統合に最適なプラットフォームです。Oracle Databaseでは、ストレージおよびネットワークのグリッド・アーキテクチャとOracleリソース管理機能が組み合わされており、（ハードウェアやオペレーティング・システムの仮想化などの）他の仮想化戦略よりも簡単かつ柔軟にデータベースを統合できます。Exadataでは現在、シンプルなOracleリソース管理によって効率的にデータベースを統合しています。Exadataは現時点では仮想マシンやSolaris Zonesに対応していません。

このホワイト・ペーパーでは、Exadataでの統合で推奨されるアプローチについて説明します。たとえば、共有リソースを使用する複数のアプリケーションとデータベースのサポートで、安定性と可用性の最大化に必要な初期計画、設定、管理のフェーズなどが含まれます。


3

また、関連する他のホワイト・ペーパーへの参照が含まれており、ExadataとOracle Maximum Availability Architecture（Oracle MAA）の他のベスト・プラクティスを補完しています。SPARC Supercluster、Oracle Exalogic、仮想マシン、Oracle 12c Multitenantアーキテクチャでのデータベース統合については記載していません。Oracle 12c Exadata MAA統合のホワイト・ペーパーについては、2013年の終わりか2014年の初めに別途公開することを予定しています。

Exadata統合の計画 1. 高可用性（HA）、計画メンテナンス、ビジネス要件を定義する。

Exadata上で統合を行う場合、いくつかの原則に従う必要があります。まず、ターゲット・データベースの可用性と計画メンテナンスの目的が同様である必要があります。そうでないと、必然的にいずれかのアプリケーションに悪影響が出ます。たとえば、ミッション・クリティカルなアプリケーションが開発またはテスト・システムと同じ環境を共有している場合、開発およびテスト・システムを頻繁に変更すると、ミッション・クリティカルなアプリケーションの可用性や安定性に影響を及ぼします。オラクルでは共通のインフラストラクチャ（たとえば Oracle Clusterware と Oracle Automatic Storage Management（Oracle ASM）から成るOracle Grid InfrastructureおよびExadata Storageセル）とオペレーティング・システム環境を管理するほうが効率的で比較的簡単であることから、類似のサービス・レベルのターゲット・データベースを統合するという方法をとっています。この特長が、ターゲット・アプリケーションのサービス・レベル要件が異なる場合はかえって障害となる可能性があります。

企業はまず、リカバリ時間目標（RTOまたはアプリケーションのターゲット・リカバリ時間）、リカバリ・ポイント目標（RPOまたはアプリケーションのデータ損失の最大許容範囲）、ディザスタ・リカバリ

（DR）のリカバリ時間、計画メンテナンス時間の割当てなどの主要なHA要件を定義する必要があります。

統合対象の各種アプリケーション間の互換性を確保するため、ピーク予測を含むパフォーマンス目標、平均およびアイドル・ワークロード期間、システム要件、セキュリティおよび組織の境界といったその他の点についても考慮する必要があります。

2. データベースをグループに分類する。

ステップ1で決定したHA要件に基づき、統合を予定しているデータベースをグループ化します。たとえば、データベースは次のグループに分類できます。

• Gold：収益性のある顧客向けのミッション・クリティカル・データベースで、RTOとRPOの要件がゼロまたはほぼゼロであることが必要

• Silver：RTOとRPOの要件が少し高いビジネス・クリティカルなデータベース

• Bronze：その他のクリティカルでない本番データベース、または開発およびテスト用のデータベース

必要に応じて各グループをさらに細かく分類し、すべてのアプリケーションが、HA要件や計画メンテナンス時間について競合しないようにすることができます。

3. Exadataハードウェア・プールを作成する。


4

ハードウェア・プールという用語は、統合のターゲット・プラットフォームとして使用するマシン、またはマシン・グループを指します。エンタープライズ用途では複数のハードウェア・プールを作成することで、統合用の各ターゲット・プラットフォームの管理を容易にすることができます。ハードウェア・プールの最小推奨サイズはExadataハーフ・ラックで、最大推奨サイズは2台のExadata Database Machineフル・ラック（必要に応じてExadataストレージ拡張ラックを追加）です。この範囲内のハードウェア・プールが、統合用のもっとも一般的なExadata構成であり、効率的なデータベース統合に十分な容量があります。

エントリ・レベルの統合では、Exadata X3-2クォーター・ラックまたは1/8ラックで構成される、より小規模なハードウェア・プールをデプロイすることもできます。別のExadataにスタンバイ・データベースをデプロイしている場合は、このオプションをクリティカル・アプリケーションに使用できます。Oracle Exadata Database Machine X3-2クォーター・ラックや1/8ラックには、高冗長性ディスク・グループに投票ディスクを常駐させるためのExadataセルが不足するという、HA上の若干の欠点があります。この問題は、Exadataセルを2つ追加して拡張することで解決できます。投票ディスクには、5つの障害グループまたは5つのExadataセルが必要です。これが、Exadataハーフ・ラックが推奨最小サイズであるおもな理由の1つです。ストレージ障害によって、Oracle ASMディスク・グループ（投票ディスクが常駐している場所）のマウントが解除されると、Oracle ASMとOracle Clusterwareに障害が発生する可能性があります。この場合はすべてのデータベースで障害が発生しますが、My Oracle Support（MOS）Note 1339373.1に従って手動で再起動できます（「impact due to loss of DBFS_DG」の項を参照）。

8台以上のOracle Exadata Database Machineフル・ラックで構成されるハードウェア・プールをデプロイすることもできます。ただし、この種の統合環境におけるスケジューリングや管理の手間が増え、統合によって得られる利点が損なわれてしまうためお勧めしません。

また、ノードとExadataストレージ・セル（いわゆるExadataセル）をパーティション化することによって、1つのOracle Exadata Database Machineに複数のハードウェア・プールを共存させることもできますが、この構成もお勧めしません。パーティション化することでリソースの利用効率が低下し、次のような不利益が発生する可能性があるためです。

• サーバーとストレージ・グリッド全体の帯域幅へのアクセスが制限される

• 複雑化する

• InfiniBandファブリック、Ciscoスイッチ、物理ラック自体などの共通コンポーネントによって、障害とメンテナンスを完全に分離できなくなる

4. 特定のハードウェア・プールにデータベースとアプリケーションのグループをマッピングする。

上記の例に続いて、データベースとアプリケーションの各グループを固有のハードウェア・プール（GOLD、SILVER、BRONZE）にデプロイします。同じハードウェア・プール内の別々のカテゴリのデータ

ベースは統合しないでください。コスト削減のために、複数のグループが含まれる多目的なハードウェア・プール（GOLD、SILVER、BRONZEなど）がある場合は、最上位のデータベース・カテゴリに従ってハードウェア・プールを管理する必要があります。このような多目的ハードウェア・プールの例としては、Active Data GuardのGOLDスタンバイ・データベースとBRONZEテスト・データベースの統合などがあります。多目的ハードウェア・プールにも、InfiniBandネットワークおよびソフトウェア、Exadataストレージ・セル、Oracle Grid Infrastructureなどの共有コンポーネントは多数あります。また、多目的ハードウェア・プールにはHA要件や計画メンテナンス時間が競合するデータベースが含まれるため、運用管理がより難しくなります。


5

単一ハードウェア・プールより多くの容量を必要とするグループでは、メモリのアップグレード、ストレージの追加、Oracle Exadata Database Machineのラック間接続などによって拡張できます。ハードウェア・プールの最大サイズに達した場合は、そのグループ内のターゲット・データベースを2つのグループに分け、各グループを固有のハードウェア・プールにデプロイします。Oracle Exadata Database Machineフル・ラック2台と追加のExadataストレージ拡張ラック（ハードウェア・プールの推奨最大サイズ）より多くの容量を必要とする単一データベースの場合は、統合によるメリットはありません。このようなデータベースは、必要な数のExadataシステムで構成される専用クラスタにデプロイすることをお勧めします。

以下の表に、各種のHA（高可用性）要件に必要な、Exadataハードウェア・プールを使用する各種アーキテクチャの例を示します。

表1.高可用性要件と推奨アーキテクチャ

高可用性要件推奨アーキテクチャ

GOLD

次の要件を満たすミッション・クリティカル・アプリケーション：

• RTO < 1分

• RPO=0

• 計画メンテナンス 4時間/四半期（週末）

以下で構成される3つのクリティカル・ハードウェア・プール

• Oracle RACを使ったプライマリ・クリティカル

• Active Data Guardを使ったローカルData Guardクリティカル

• Data Guardを使ったリモートData Guardクリティカル

• テスト

• Data Guardフェイルオーバーとアプリケーション・フェイルオーバーに

基づくRTO/RPO

SILVER

次の要件を満たすクリティカル・アプリケーション：

• 1分 > RTO < 2時間

• 2秒 > RPO < 2時間

• 計画メンテナンス 8時間/四半期（週末）

以下で構成される2つのクリティカル・ハードウェア・プール

• Oracle RAC OneまたはOracle RACを使ったプライマリ・クリティカル

• Active Data Guardを使ったリモートData Guardクリティカル

• テスト

• Data Guardフェイルオーバーとアプリケーション・フェイルオーバーに

基づくRTO/RPOアプリケーション・フェイルオーバーにほとんどの時間

が費やされる可能性があります。

BRONZE

次の要件を満たす標準アプリケーション：

• 12時間 > RTO < 24時間

• 12時間 > RPO < 24時間

• 計画メンテナンス 48時間/四半期

以下で構成される1つの標準ハードウェア・プール

• 単一インスタンスまたはOracle RAC Oneを使ったSTDPOOL1

• バックアップからのリストアとリカバリに基づくRTO/RPO。バックアッ

プ頻度とリストア速度が、RTOとRPOに影響します。

次の要件を満たす開発用アプリケーション：

• 開発用の高可用性

• 24時間 > RTO < 72時間

• 計画メンテナンス 48時間/月

以下で構成される1つの非本番ハードウェア・プール

• 単一インスタンスまたはOracle RAC Oneを使ったDEVPOOL1

• 本番バックアップからのリストアとリカバリに基づくRTO/RPO。バック

アップ頻度とリストア速度が、RTOとRPOに影響します。

次の要件を満たすテスト用アプリケーション：

• システムの変更とパッチを検証し、新しい機能性、パフォーマンス、

HAを評価するためのテスト・システム

• これは、すべての本番アプリケーションの推奨事項です

本番環境と同じであることを推奨

または

最小限のExadata 1/8ラック

• TESTPOOL1


6

5. Exadataハードウェア・プールに移行する前にサイズ要件を評価する。

既存のシステムからデータベースを移行する場合は、現行のCPU、I/Oおよびメモリ使用率を推定し、社内で将来的な成長予測を検討します。これらの計算に基づき、ハードウェア・プールに収容するデータベースとアプリケーションの適切な数を評価します。サイジングについて詳しくは、オラクル・コンサルティングおよびOracle Advanced Customer Support Services（ACS）にお問い合わせください。

その他に以下の点についても考慮する必要があります。

• 高可用性（HA）およびローリング・アップグレードの各種アクティビティ（Oracle Real Application Clusters（Oracle RAC）やExadataセルのローリング・アップグレード・アクティビティなど）に対応できるように、システム容量を予約します。

• クリティカル・ハードウェア・プール用にシステム容量を予約し、最大限の安定性を実現します。たとえばクリティカル・ハードウェア・プールの場合は、スパイクに対応するため、リソースの25%を割り当てずに構成することが一般的なベスト・プラクティスです。

• クリティカル・ハードウェア・プールにOracle Automatic Storage Management（Oracle ASM）高冗長性ディスク・グループを使用すると、使用できるデータ・ストレージ領域が少なくなるので注意してください。

• アプリケーションとデータベース間のビジネスまたはワークロードのサイクルで、追加の統合が可能かどうかを検討します。たとえば、アプリケーションAでは、アプリケーションBが比較的アイドルな状態のときに、ピーク・ワークロードが発生することがあります。

6. アプリケーションおよびデータベースごとに、正確なパフォーマンス要件を収集する。

各アプリケーションのスループットとレスポンス時間について、正確なパフォーマンス予測を収集します。Oracle Enterprise Manager（Oracle EM）Grid ControlまたはOracle EM Cloud Controlを使用して、主要なアプリケーション・メトリック（アプリケーション、データベース、システムのパフォーマンス統計の履歴など）を管理します。将来パフォーマンス上の問題が発生した場合に、このデータが必要になります。

安定性確保のための主要なリソースのセットアップと管理初期計画とサイジングを完了したら、Exadataハードウェア・プールをセットアップします。ここでは、Exadataでデータベースを統合する際の、初期デプロイメントや特定の構成設定に関する推奨事項について説明します。

推奨されるストレージ・グリッド（ディスク・グループ）の構成

推奨されるストレージ構成は、ハードウェア・プールごとに1つの共有Exadataストレージ・グリッドを使用する方法です。このストレージ・グリッドにはすべてのExadataセルとExadataディスクが含まれており、Oracle ASMの高冗長性または通常の冗長性機能（Oracle ASMの冗長性については後述します）で構成します。


7

図1.共有Exadataストレージ・グリッド

おもな利点は次のとおりです。

• シンプルで管理が容易

• 使用および検証の実績がもっとも多い構成

• アプリケーションがI/O帯域幅とストレージに完全にアクセスできる、バランスのとれた構成

• 障害とローリング・アップグレードに対する耐性

1つの共有Exadataストレージ・グリッドの管理は簡単で、管理コストも安く済みます。ストレージを共有することで、領域や帯域幅の使用効率も向上します。必要なストレージ領域とI/O帯域幅がExadataフル・ラックで使用可能な範囲を超えている場合は、Exadataストレージ拡張ラックを追加するか、アプリケーションを別のハードウェア・プールに移行できます。

これがクリティカル・ハードウェア・プールである場合は、DATAおよびRECOのディスク・グループ用にOracle ASMの高冗長性を使用して、特にExadataストレージ・セルのローリング・アップグレードやその他のメンテナンス・アクティビティの間に発生するストレージ障害に対する耐性を最大限に強化します。DATAおよびRECOのディスク・グループ構成、Oracle MAAのストレージ・グリッド構成、Exadataクォーター・ラックおよび1/8ラックの制限事項については、『Oracle Exadata Storage Server Software User's Guide』の“About Oracle ASM for Maximum Availability”を参照してください。領域が制限されており、Oracle Data Guardを使ったスタンバイ・ハードウェア・プール（スタンバイ・プール）もデプロイしてある場合は、DATAディスク・グループとRECOディスク・グループの両方にOracle ASMの通常の冗長性を使用することを検討してください。スタンバイ・プールを使用すると、データベース、クラスタ、ストレージに障害が発生してもデータが破損しないように包括的に保護し、迅速にフェイルオーバーできます。このため、プライマリ・ハードウェア・プールで高冗長性を利用しないことによるHAおよびデータ保護のリスクを軽減できます。

領域が制限されており、スタンバイ・プールをデプロイできない場合は、DATAディスク・グループに高冗長性、RECOディスク・グループに通常の冗長性を使用するという方法もあります。この場合、ストレージに障害が発生すると、可用性と簡易性が低下する可能性があります。DATAまたはRECOのOracle ASMディスク・グループが失われた場合のリカバリ方法について詳しくは、My Oracle Support （MOS ）Note 1339373.1を参照してください。

OneCommand構成プロセスで作成したディスク・グループ構成を使用する必要があります（『Exadata Database Machineオーナーズ・ガイド』に記載）。ディスクデフォルトでは、最初の高冗長性ディスク・グループにオンライン・ログ、制御ファイル、spfile、クラスタウェア、投票デバイスが保存されます。DATA


8

ディスク・グループにはデータベース・ファイルが保存され、RECOディスク・グループにはファスト・リカバリ領域（FRA）のリカバリ関連ファイルが含まれます。アプリケーションの分離が必要な場合は、DATAディスク・グループとRECOディスク・グループを個別に作成できます。「セキュリティおよび管理ロール」またはOracle MAAのホワイト・ペーパー『Oracle Exadata Database Machine Consolidation: Segregating Databases and Roles（Oracle Exadata Database Machineの統合：データベースとロールの分離）』を参照してください。

また Oracle ASM ディスク・グループを作成する場合は、 Oracle ASM ディスク・グループのCOMPATIBLE.RDBMS属性が、ハードウェア・プール上のOracle Databaseソフトウェアの最小バージョンに設定されていることを確認します。

推奨されるデータベース・グリッド（クラスタ）の構成

Oracle Grid Infrastructure（Oracle ClusterwareとOracle ASMを含む）のセットアップには、ハードウェア・プールごとに1つのクラスタを使用することをお勧めします。Oracle Clusterwareによって管理されるOracle Databaseサービスを使用して、クラスタ内の特定のOracleデータベース・インスタンスに対し、アプリケーションの負荷分散とルーティングを行う必要があります。おもな利点は次のとおりです。

• シンプルで管理が容易

• アプリケーションが必要に応じてデータベースCPU帯域幅とメモリ帯域幅に完全にアクセスできる、バランスのとれた構成

• 障害耐性

• Oracle RACとGrid Infrastructureのローリング・アップグレード機能

アプリケーション・リソースの増減に合わせて、使用可能なデータベース・インスタンスとノードに対し、簡単かつ透過的にサービスをルーティングおよび負荷分散できます。

Oracle Grid Infrastructureソフトウェアのバージョンは、クラスタで使用予定のOracle RACソフトウェアの最新バージョン以上である必要があります。Grid Infrastructureソフトウェアはいつでもアップグレードできますが、個々のデータベースのアップグレード・スケジュールが異なる場合は、Grid Infrastructureのパッチ適用頻度が少なくなるように計画を立てる必要があります。すべてのGrid Infrastructureアップグレードはローリング形式で行う必要があります。

クリティカル・ハードウェア・プールの場合はData Guardハードウェア・プール（スタンバイ・プール）を割り当てて、クラスタ障害、データベース障害、データ破損、災害から保護します。サイト、システム、データベースのメンテナンスの際に、スタンバイ・プールにスイッチオーバーすることもできます。

注：Oracle 11g Release 1以降の場合、1つのクラスタに対するデータベース・インスタンスの最大数は512です。X2-2またはX3-2データベース・ノードあたりのデータベース・インスタンス数の上限は128、X2-8またはX3-8データベース・ノードの場合は256をお勧めします。実際のデータベース・ノードまたはクラスタあたりのデータベース・インスタンス数は、アプリケーション・ワークロードとそれに対応するシステム・リソース消費量によって異なります。

http://www.oracle.com/technetwork/jp/database/availability/maa-exadata-consolidated-roles-459605-ja.pdf

http://www.oracle.com/technetwork/jp/database/availability/maa-exadata-consolidated-roles-459605-ja.pdf


9

推奨されるパラメータ設定

以下のパラメータ設定は、各ハードウェア・プールで特に重要です。システム・リソースを効率よく割り当て、制限するために役立ちます。ワークロードの変更、データベースの追加や削除に応じて、設定の調整やチューニングを定期的に行う必要があります。

オペレーティング・システム・パラメータ

• /proc/meminfo内のPageTablesが物理メモリ・サイズの2%超に設定されている場合は、オペレーティング・システムのHugePagesパラメータを、共有するメモリ・セグメントの合計に設定する（Linuxの場合のみ）。

HugePagesは、Linuxカーネルが複数ページ・サイズ機能を活用するためのメカニズムです。Linuxではページをメモリの基本単位として使用しており、基本ページ単位で物理メモリのパーティション化、アクセスを行います。デフォルト・ページ・サイズは4096バイトです。Hugepagesによって大量のメモリを少ないオーバーヘッドで活用できます。LinuxはCPUアーキテクチャ内でTransaction Lookaside Buffers

（TLB）を使用します。このバッファには、実際の物理メモリ・アドレスへの仮想メモリのマッピングが含まれています。このため、ページ・サイズが大きいシステムのTLBエントリの密度が上がり、ページテーブル領域が減ります。また、各プロセスで使用されるプライベート・ページテーブルが小さくなり、プロセス数が増えるとこのようなメモリを大幅に節減できます。

一般に/proc/meminfo内のPageTablesが物理メモリの2%を超える場合に、HugePagesが必要になります。HugePagesは、すべてのデータベース・インスタンスで使用されている共有メモリ・セグメントの合計と同じになるように設定する必要があります。すべてのデータベース・インスタンスの実行時、共有メモリの使用量は、ipcs -mコマンドの出力を分析して計算できます。MOS Note 401749.1には、共有メモリの使用量を判断するスクリプトが提供されています。MOS Note 361468.1にはHugePagesの設定方法が記載されています。

11.2.0.2以降では、データベース初期化パラメータUSE_LARGE_PAGES=ONLYをすべてのインスタンスに設定することで、十分なHugePagesがない場合はインスタンスを起動させないようにすることができます。

注：データベース・パラメータSGA_TARGETやデータベース・インスタンス数が変更された場合は、HugePagesで使用する値を再計算する必要があります。HugepagesはSGAでしか使用できないため、割り当て過ぎないでください。また HugePages が有効な場合は、MEMORY_MAX_TARGETとMEMORY_TARGETの互換性がありません。

注：Solarisでは、HugePagesはISM（Intimate Shared Memory）によって自動的に構成および使用されます。

• 共有メモリ・セグメント数（kernel.shmmni）は、データベース数よりも大きい値を設定する。

共有メモリ識別子の数は、ノードで実行されるデータベース・インスタンスの数よりも大きい値を設定する必要があります。sysctl コマンドを使用して、kernel.shmmniの設定を確認します（たとえば/sbin/sysctl -a | grep shmmni）。Linuxシステムでは、必要に応じて/etc/sysctl.confのkernel.shmmniを設定して調整を行います。SHMMNIのデフォルト設定（4096）で、すべてのケースに対応できます。

• 共有メモリ・セグメントの最大サイズ（kernel.shmmax）を、物理メモリ・サイズの85%（デフォルト）に設定する。


10

共有メモリ・セグメントの最大サイズは、データベース・サーバーの物理メモリ・サイズの85%に設定する必要があります。sysctlコマンドを使用してkernel.shmmaxの設定を確認します。Linuxシステムでは、必要に応じて/etc/sysctl.confのkernel.SHMMAXを設定して調整を行います。

• システム・セマフォの最大合計数（SEMMNS）を、すべてのデータベース・プロセスの合計数より大きい値に設定する。

システムで実行されるすべてのデータベース・インスタンスについて、システムのセマフォの最大数を、（データベースのPROCESSESパラメータで指定されている）プロセスの合計数より大きい値に設定する必

要があります。sysctlコマンドを使用してkernel.semの設定を確認します。kernel.semの設定には4つの数値から成る一覧が含まれます。SEMMNSと呼ばれる、システム上のセマフォの合計数の設定は、この一覧に含まれている2番目の値です。必要に応じて、/etc/sysctl.confのkernel.semを設定して調整を行います。SEMMNSのデフォルト設定（60000）で、すべてのケースに対応できます。

• すべての単一データベースで、セマフォ・セット中のセマフォの最大数（SEMMSL）を、プロセスの最大数より大きい値に設定する。

データベース・サーバーで実行されるすべての単一データベース・インスタンスで、セマフォ・セット中のセマフォの最大数を、プロセスの最大数より大きい値に設定する必要があります。sysctlコマンドを使用してkernel.semの設定を確認します。SEMMSLと呼ばれる、セマフォ・セット内のセマフォの最大数の設定は、一覧の最初の値です。Linuxシステムでは、必要に応じて/etc/sysctl.confのkernel.s emを設定して調整を行います。

データベース・メモリ設定

Exadataの場合は、システムに以下の物理メモリが含まれています。

• Exadata X3-2では256GB

• Exadata X3-8ではデータベース・サーバーあたり2TB

• Sun Fire X4170 Oracle Database ServersベースのExadata X2-2（別名V2）では、データベース・サーバーあたり72GB

• Exadata X2-2ではデフォルト構成で96ギガバイト（GB）、（Exadataメモリ拡張キットによって）144GBまで拡張可能

• Exadata X2-8では、データベース・サーバーあたり1テラバイト（TB）（X4800の場合）または2TB（X4800M2の場合）

過剰なメモリ・ページングや“ページ・アウト”は避けてください。アプリケーション・パフォーマンスが低下したり、ノードが不安定になったりします。システム・メモリでページ・アウト・アクティビティを定期的に監視します。

注：

• Linuxのfreeコマンドを使用して、システム上の空きメモリと使用中のメモリに関する情報を表示します。

• vmstatコマンドを使用して、ページ・アウトがゼロまたは低すぎる値でないかどうかを監視します。

• オペレーティング・システムのコマンドps top（Linux）またはprstat（Solaris）を使用して、プロセスレ


11

ベルの詳細情報（プライベート・メモリや共有メモリの使用率など）を確認します。

V$PROCESSのデータベース問合せを行い、PGA_USED_MEMがアプリケーションのしきい値を超える場合は注意してください。プロセスを終了して、データベース・ノードのすべてのデータベースとアプリケーションに影響を与えるノードの不安定性を解消することが必要な場合もあります。たとえばOLTPで1GB、データウェアハウス・レポートで10GBを超えるPGAメモリを消費するプロセスは、終了したほうがよい可能性があります。正確なしきい値は、アプリケーションの既知の動作や要件によって変わりますが、PGA_AGGREGATE_TARGETより小さい値にしてください。

以下は問合せと操作フローの一例です。

SELECT s.inst_id, s.sid, s.serial#, p.spid, s.username, s.program, p.pga_used_mem FROM gv$session s JOIN gv$process p ON p.addr = s.paddr AND p.inst_id = s.inst_id WHERE s.type != 'BACKGROUND' and s.program not like '%(P%' and

p.pga_used_mem > <APPLICATION_MEMORY_THRESHOLD> order by s.inst_id, s.sid, s.serial#;

<APPLICATION_MEMORY_THRESHOLD>をアプリケーション・メモリのしきい値に置き換えて、上記の問合せを15分ごとに実行します。

共有メモリを適切に使用していない疑いのあるプロセスを調査します。問題のプロセスがメモリしきい値を超過しており、クリティカルなものでなければ、このプロセスを終了して、他のクライアントのためにノードの安定性とパフォーマンスを維持することが重要です。たとえば、SQL文ALTER SYSTEM

KILL SESSION ‘<S.SID>,<S.SERIAL#>,@<S.INST_ID>’を使用してセッションを終了するか、最終手段としてオペレーティング・システムのコマンドKILL -9 <SPID>を使用します。

初期デプロイメントとハードウェア・プールへのアプリケーション移行の場合は、次の式を使用して、SGA、PGA、および各サーバーのプロセスに十分なメモリを使用できることを確認します。パフォーマンス要件を満たすために、アプリケーションに追加のSGAまたはPGAメモリを割り当てる必要があり、物理メモリが足りない場合は、別のハードウェア・プールを使用します。クリティカル・ハードウェア・プールの場合は、より慎重に、データベース・ノードごとに75%の物理メモリを超えないようにすることを推奨します。メモリのスワップはなるべく発生させないようにしてください。

OLTPアプリケーション：

データベースの使用メモリ合計（SGA_TARGET + PGA_AGGREGATE_TARGET） + 4MB *（最大PROCESSES数） < データベース・ノードあたりの物理メモリ

DW/BIアプリケーション：

データベースの使用メモリ合計（SGA_TARGET + 3 * PGA_AGGREGATE_TARGET） < データベース・ノードあたりの物理メモリ

注：

プロセスあたりのメモリ量はさまざまですが、ExadataでオラクルのアプリケーションOracle MAAを調べたところ、メモリの割当て量は4MBでした。実際のプロセスでのメモリ使用を監視してから、こ


12

の値を計算して再調整します。

正確に計算するには、自動ワークロード・リポジトリ（AWR）レポートでメモリ統計情報を長期間継続的に監視します。たとえば、以下の表は、PGAの増加を示すAWRレポートからの抜粋です。

表2.PGAメモリ

コンポーネント BEGIN SNAP SIZE(MB)

CURRENT SIZE（MB）

MIN SIZE（MB） MAX SIZE（MB） OPER COUNT LAST OP TYP/MOD

PGA_TARGET 16,384.00 16,384.00 16,384.00 29,384.00 0 STA/

表3.メモリ統計

開始終了

ホスト・メモリ（MB） 96,531.5 96,531.5

SGA使用量（MB） 24,576.0 24,576.0

PGA使用量（MB） 577.7 578.2

SGA+PGAのホスト・メモリ使用率（%） 26.06 26.06

上記の例のとおり、PGA_AGGREGATE_TARGETはハード・リミットではありません。一部のデータウェアハウス・アプリケーションでは、PGAメモリの累積使用量がPGA_AGGREGATE_TARGETの3倍となりました。OLTPアプリケーションの場合は、アプリケーションで多くのPL/SQLを使用しないかぎり、通常は超過の可能性がずっと低くなります。現在のターゲット設定、合計使用量、合計割当て量、最大割当て量を含む、PGAメモリの使用量に関するインスタンス・レベルの統計情報を得るには、V$PGASTATの問合せを行います。PGAの使用量が増えた場合は、これが予想された現象であるかどうかと、この状況に対応できるだけのメモリがデータベース・サーバーにあるかどうかを特定する必要があります。これらの条件に該当しない場合は、PGA_AGGREGATE_TARGETの設定値を上げ、SGA_TARGETの設定値を下げてPGAメモリの割当て量の増加に対応するか、アプリケーションを根本的に別のデータベース・サーバーまたはハードウェア・プールに移動することが必要な可能性があります。

Oracle 12c以降では、初期化パラメータPGA_AGGREGATE_LIMITでPGAメモリの使用に関するハード・リミットを指定できます。Oracle 11gでは、追加の文書化されていないイベントを使用して、PGAの使用率を制限できます。たとえば、次のspfileを設定できます。

• event=”10261 trace name context forever, level <MEM in KB>”または

• ALTER [SYSTEM | SESSION] SET EVENTS ‘10261 TRACE NAME CONTEXT FOREVER, LEVEL <MEM IN KB>’

制限値を超えると、次のエラーが表示されます。

− 11.2.0.4および12.1.0.1+ではORA-10260

− 11.1～11.2.0.3ではORA-600 [723]


13

データベースのCPU設定およびインスタンス・ケージング

インスタンス・ケージングは、データベースごとのCPU使用状態の管理と制限のための重要なツールです。インスタンス・ケージングを使用すると、リソース集中型のプロセスや高いアプリケーション負荷によってシステムへの負荷が大幅に上がり、システムの不安定化や他のデータベースのパフォーマンス低下を防ぐことができます。

インスタンス・ケージングを有効にするには、サーバー上の各インスタンスで以下を実行します。

1. 初期化パラメータRESOURCE_MANAGER_PLANにリソース・プランを割り当てて、Oracle Database Resource Managerを有効にします。インスタンス・ケージングを有効にするには、リソース・プランにCPUディレクティブが含まれる必要があります。手順については、『Oracle Database Administration’s Guide 11g Release 2』の"Enabling Oracle Database Resource Manager and Switching Plans"を参照してください。データベース内のワークロードを管理する予定がない場合は、RESOURCE_MANAGER_PLANを“DEFAULT_PLAN”に設定します。

SQL> ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'DEFAULT_PLAN' SID=’*’ SCOPE=’BOTH’;

2. 初期化パラメータCPU_COUNTを、インスタンスで常時使用されるCPUの最大数に設定します。デフォルトでは、CPU_COUNTはサーバー上のCPUの合計数に設定されています。ハイパースレッドCPUの場合は、CPU_COUNTにCPUスレッドが含まれます。CPU_COUNTは動的パラメータであるため値はいつでも変更できますが、インスタンスの起動時の設定が最適です。これは、CPU_COUNTパラメータが他のOracleパラメータおよび内部構造（PARALLEL_MAX_SERVERS、バッファ・キャッシュ、ラッチ構造の割当てなど）に影響するためです。

CPU_COUNTの最小値は2です。これはデータベース・インスタンスで2基のCPUがすべて使用されるということではなく、2基のCPUのスレッドにアクセスできるということです。運用時にインスタンスで2基のCPUすべてを使用する必要がない場合は、後述するオーバーサブスクリプションを使用できます。

CPU_COUNTを1に設定すると、次の理由から、データベース・インスタンスのハングやパフォーマンスの低下が発生しやすくなります。

• CTL-Cに応答しない問合せがある

• 1つのスレッドの処理能力が低い

• プロセスの停止後に、プロセスのクリーンアップ速度が低下する

サーバーのピーク時の潜在的な負荷は、サーバー上のすべてのデータベース・インスタンスのCPU_COUNTパラメータの合計と同じです。ピーク時の潜在的な負荷とサーバーごとのCPU数を比較することで、データベース・インスタンスのリソース競合の可能性を評価できます。Exadataにはサーバーごとに以下の数のCPUがあります。この数はコアやソケットではなく、CPUスレッド数である点に注意してください。


14

• Exadata X3-2には、データベース・サーバーあたり16個のCPUコアまたは32のCPUスレッドがあります。



• Exadata V2には、データベース・サーバーあたり8個のCPUコアまたは16のCPUスレッドがあります。

• Exadata X2-8には、X4800データベース・サーバーの場合64個のCPUコアまたは128のCPUスレッドがあります。

• Exadata X2-8には、X4800 M2データベース・サーバーの場合80個のCPUコアまたは160基のCPUスレッドがあります。

インスタンス・ケージングの構成でもっとも重要な手順は、各データベース・インスタンスのCPU_COUNT値と、サーバー全体のCPU_COUNT値の合計を特定することです。このためには、次の2つの方法があります。

• ミッション・クリティカルなGOLDおよびSILVERのハードウェア・プールをパーティション化する。ターゲット・データベース・サーバー上の全データベース・インスタンスのCPU_COUNT値の合計が、サーバー上のCPU数を超えなければ、サーバーのパーティション化を行います。この場合は、データベース・インスタンス間でCPUリソースの競合はありません。ただし、割り当てられたCPUリソースを使用しないデータベース・インスタンスがある場合に、他のデータベース・インスタンスでこのCPUリソースを利用することはできません。

パーティション化の利点はCPUの競合がない点ですが、CPUが十分に活用されない可能性があります。このためパーティション化は、クリティカルなハードウェア・プール内のミッション・クリティカルなデータベース用に推奨します。

特定のサイジングの推奨事項は次のとおりです。CPU_COUNT値の合計を、サーバー上のCPUの合計数の100%未満に制限すると、サイジングを分析し、CPUの使用履歴の最大値を考慮することで、各インスタンスのCPU割当てがわかります。

sum(CPU_COUNT) <= 100% * CPUの合計

• クリティカルでないBronzeハードウェア・プールのオーバーサブスクリプション。ターゲット・データベース・サーバー上の全データベース・インスタンスのCPU_COUNT値の合計が、サーバー上のCPU数を超えている場合を、サーバーのオーバーサブスクリプションと呼びます。この場合は、すべてのデータベースの負荷が同時に高くなると、CPUリソースの競合が発生し、パフォーマンスが低下します。

オーバーサブスクリプションの利点は、リソースの使用率が高くなることですが、CPU競合発生の可能性を伴います。したがってオーバーサブスクリプションは、ピーク時間帯が重複しないテストまたはクリティカルではないデータベース・ハードウェア・プールにお勧めします。

CPU_COUNT値の合計を、次のようにCPU数の3倍に制限することをお勧めします。

sum (CPU_COUNT) <= 最大3 * CPUの合計

たとえば上記の式を使用すると、ターゲット・データベース・サーバー（32基のCPUを搭載したX3-2）上のすべてのデータベース・インスタンスのCPU_COUNT値の合計の最大値は、3 * 32 = 96となります。このため、インスタンスが4個の場合は各インスタンスのCPU_COUNTが24、8個の場合は各インスタンスの CPU_COUNT が 12 となります。すべてのインスタンスの CPU_COUNT 値が異なる場合は、CPU_COUNTの合計を96以下とします。インスタンス・ケージングによって、CPU_COUNT値は各データ


15

ベース・インスタンスが、指定された数より多いCPU数を使用しないようにします。

インスタンス・ケージングを構成後、MOS Note 1362445.1のスクリプトを使用して各インスタンスの実際のCPU使用状態を監視できます。この情報を基に、適宜各インスタンスに応じてCPU_COUNT値を調整し、インスタンス・ケージングのチューニングを行うことができます。非常にアクティブなOracle RACシステムの場合、バックグラウンド・プロセス（SMON、PMON、LMSなど）が継続的に有効に機能するには、各データベース・インスタンスに2基以上のCPUを割り当てる必要があります。インスタンス・ケージング用の推奨パッチについては、MOS Note 1340172.1も参照してください。

プロセス数の設定

Oracle ASMとOracle Databaseの次のプロセス数の設定と運用上の実例は、一般的なプロセス構成の失敗を回避するのに役立ちます。

• Oracle ASMインスタンスの場合、PROCESSES= 50 * MIN（データベース・ノード上のデータベース・インスタンス+ 1, 11）+ 10 * MAX（データベース・ノード上のデータベース・インスタンス – 10, 0）を設定する。

1つのデータベース・ノードに複数のインスタンスがある場合、またはインスタンスを追加または削除した場合は、Oracle ASMの初期化パラメータであるPROCESSESを調整する必要があります。上記のガイドラインを使用すると、Oracle ASMでの割当ておよび割当て解除リクエストの際のエラーを回避できます。上記の数式を使用すると、5つのデータベース・インスタンスには300のOracle ASMプロセスが必要で、20のデータベース・インスタンスには650のOracle ASMプロセスが必要です。

• PARALLEL_MAX_SERVERSを制限する。

• X2-2およびX3-2：すべてのインスタンスのsum(PARALLEL_MAX_SERVERS) <= 240

• X2-8およびX3-8：すべてのインスタンスのsum(PARALLEL_MAX_SERVERS) <= 1280

PARALLEL_MAX_SERVERSでは、インスタンスのパラレル実行プロセスとパラレル・リカバリ・プロセスの最大値を指定します。需要が増えると、OracleデータベースではPARALLEL_MAX_SERVERSで定義された数まで、パラレル実行プロセス数が増加します。各アプリケーションが低い値でパフォーマンス要件を満たせることを確認します。PARALLEL_MAX_SERVERSが高い値に設定されていると、ピーク時にメモリ・リソース不足が発生し、パフォーマンス低下や、データベース・ノードの不安定化につながります。

• REDO Applyのパラレル化を制限する。

Oracle Data Guardでは、デフォルトのREDO Applyのパラレル化が暗黙的にCPU数に設定されています。この設定ではシステム・リソースが無駄に消費され、しかもそれほどメリットはありません。代わりに、以下のコマンドを使用して、16（以下）に限定したリカバリ・パラレル化を明示的に使用します。

SQL> RECOVER MANAGED STANDBY DATABASE … PARALLEL 16

• プロセス数と接続数をデータベース・サーバーの数に限定する。

少ないプロセス数や適切な数のプロセスを設定することで、メモリ、CPU、データベース・ラッチの競合、log file syncの待機、全体的なアプリケーション・フェイルオーバー回数の軽減や回避といった利点があります。プロセス数や接続数が減れば、パフォーマンスやスループットが向上する可能性もあります。プロセス数および接続数とパフォーマンスの関係については、http://www.youtube.com/watch?v=xNDnVOCdvQ0のReal World Performance教育ビデオを参照してください。

http://www.youtube.com/watch?v=xNDnVOCdvQ0


16

オラクルのパフォーマンス・エキスパートは、アクティブ・プロセス数1をCPUコア数の5倍にすることを推奨しています。また、オプションとして、SiebelなどのCPU使用量の多いアプリケーションでは、アクティブ・プロセス数をCPUコア数の1～2倍にすることを推奨しています。以下の技法を1つ以上使用することで、全体的なプロセス数を削減してパフォーマンスを向上させることができます。

1. 最小設定と最大設定によるアプリケーション接続のプーリング

アプリケーション接続プールを使用することで、過剰な接続開閉プロセスを回避し、貴重なシステム・リソースの無駄をなくすことができます。接続プール内で最小設定と最大設定を使用すると、迅速な応答時間とメモリおよびCPUの効率的な利用を実現し、ログオン・ストームを回避できます。全体的な接続数は大幅に減少し、パフォーマンス目標への悪影響もありません。

接続プールはデータベース接続オブジェクトのキャッシュです。このオブジェクトは、アプリケーションがデータベースに接続するために使用できる物理的なデータベース接続を示します。実行時、アプリケーションは接続プールから接続を要求します。接続プール内にリクエスト内容と一致する接続がある場合は、アプリケーションにその接続を返します。該当する接続がない場合は、新しい接続を作成し、アプリケーションに返します。アプリケーションはデータベース上で何らかの作業を行うために接続を使用し、接続プールにオブジェクトを返します。その後、その接続は次の接続リクエストに使用できるようになります。

接続プールによって接続オブジェクトを再利用しやすくなり、接続オブジェクトの作成回数を減らすことができます。接続オブジェクトの作成には時間もリソースも多く必要になるため、接続プールはデータベースを多用したアプリケーションのパフォーマンスを大幅に改善します。接続オブジェクトの作成に必要なネットワーク通信、接続文字列の読込み、認証、トランザクションの登録、メモリ割当てなどのタスクはすべて、時間とリソースの消費につながります。さらに、接続がすでに作成されているので、アプリケーションが接続を待機する時間が短くて済みます。

接続プールには、接続プールのパフォーマンスを最適化するためのプロパティがある場合があります。この種のプロパティは接続プール内で許可される最小および最大接続数や、接続プールに返されるまでに接続がアイドル状態を維持することができる時間などの動作を制御することができます。最適な構成の接続プールでは、応答時間と、接続プール内の接続の維持に使用されるメモリのバランスが取れています。多くの場合、特定のアプリケーションに最適なバランスが得られるまで、異なる設定を試してみる必要があります。

さらに、アプリケーション接続プールの構成はアプリケーションごとに異なり、一部のアプリケーションでは使用できない場合があります。詳しくは、アプリケーションのドキュメントを参照してください。

2. データベース共有サーバー

Oracle Databaseの共有サーバー・アーキテクチャでは、ディスパッチャによって、受信する複数のネットワーク・セッション・リクエストが共有サーバー・プロセスに送信されます。このため、接続

1 アクティブなプロセス数は、STATUS=”ACTIVE”であるV$SESSIONの問合せ、またはV$ACTIVE_SESSION_HISTORYの監視によって取得できます。Enterprise Managerのパフォーマンス・ページには、これらの詳細情報と競合の可能性に関する考察がすべて表示されます。


17

ごとの専用サーバー・プロセスが不要になります。プール内でアイドル状態の共有サーバー・プロセスが、共通のキューからリクエストを選択します。

アプリケーション層が変更できない場合は、共有サーバー・アーキテクチャを多数の短いリクエストとトランザクションに使用することで、全体的なプロセス数が大幅に減ります。アプリケーションのドキュメントで、Oracle Databaseの共有サーバー・アーキテクチャの使用に関する制限事項や特定のガイドラインを確認してください。

データベース共有サーバーを初めて検討する場合は、以下のマニュアルを読み、記載されているベスト・プラクティスを実践してください。

• 『Oracle Database管理者ガイド』の“共有サーバーのOracle Databaseの設定”

• 『Oracle Databaseパフォーマンス・チューニング・ガイド』の“共通サーバーおよびディスパッチャのパフォーマンスの考慮事項”

• まずは500個のセッションあたり20～30台の共有サーバーを使用して調整する（『Oracle Net Services best practices』のスライド50）

• 50～100セッションあたり1つのディスパッチャから始めて、チューニングを行う

• 長時間の問合せ、レポート作成ジョブ、Data Guardの転送、および管理接続の場合は、引き続き専用サーバーを使用します。常に共有サーバーと専用サーバーを組み合わせることができ、データベース共有サーバーに移行する場合は便利です。

• sqlnet.oraファイルでは、USE_ENHANCED_POLL=onに設定する（『Oracle Net Services best practices』のスライド52）

3. データベース常駐接続プーリング（DRCP：Database resident connection pooling） – Oracle Database 11gの新機能

DRCPはプールされたサーバーを使用します。このサーバーは専用のサーバー・プロセス（共有サーバー・プロセスではない）およびデータベース・セッションを組み合わせたものに相当します。プールされたサーバーを使用するモデルでは、短期間データベースにアクセスする必要がある各接続に対して専用のサーバー・プロセスを使用することによるオーバーヘッドを回避できます。DRCPから接続を取得し、Oracleバックグラウンド・プロセスに接続するクライアントは接続ブローカと呼ばれます。接続ブローカはDRCPプール機能を実装し、クライアント・プロセスから受信した接続の間で、プールされているサーバーを多重化します。

共有サーバーよりも効率的ですが、DRCPではセッションの取得と解放のために、アプリケーション・コードに若干の変更が必要です。Oracle Technology Network（OTN）のホワイト・ペーパー

『データベース常駐接続プーリング（DRCP）』（http://www.oracle.com/technetwork/jp/topics/oracledrcp11g-132231-ja.pdf）を参照してください。

アプリケーションのドキュメントで、DRCPの使用に関する制限事項や特定のガイドラインを確認してください。

• Exadataソフトウェア11.2.3.1以降では、1つのハードウェア・プールに含まれる1つ以上のデータベー

https://docs.oracle.com/cd/E16338_01/server.112/b56301/toc.htm

http://docs.oracle.com/cd/E16338_01/server.112/b56312/build_db.htm#i22941

http://www.oracle.com/technetwork/jp/database/enterprise-edition/oow11-14345-net-services-514484-ja.pdf




http://www.oracle.com/technetwork/jp/topics/oracledrcp11g-132231-ja.pdf

http://www.oracle.com/technetwork/jp/topics/oracledrcp11g-132231-ja.pdf


18

ス・サーバーによって生成される最大60,000の同時接続がサポートされます。つまり、同時にセルに接続したままI/O操作を実行できるプロセスの数は、60,000個以下です。Exadataリリース11.2.2.4の上限は、32,000接続でした。リリース11.2.2.4より前のExadataの上限は、20,000接続でした。上限目標はメモリまたはCPUの消費量に依存しますが、X2-2またはX3-2の場合は1ノードあたり約7,500プロセス、X2-8またはX3-8の場合は1ノードあたり約30,000プロセスです。

ハードウェア・プールあたりのプロセス数を計算するには、Oracle ASMインスタンス、Database File System（DBFS）インスタンス、アプリケーション・データベースを含む各データベースに以下の問合せを行います。

SQL> SELECT COUNT(1) FROM GV$PROCESS;

プロセス数が増えるとメモリ・ページングが発生し、ノードの不安定化、CPUやデータベース・ラッチの競合、アプリケーションのフェイルオーバーや一時停止の長期化を招く可能性があります。プロセス数を増やす前にテストを行うことが非常に重要です。

• 受信する接続のスロットル用にOracleリスナーを構成して、データベース・ノードやインスタンスの障害後にログオン・ストームが発生しないようにします。

Oracle Net Listener内の接続速度リミッター機能により、データベース管理者（DBA）はリスナーが処理する新しい接続数を制限できます。この機能を有効にしておくと、Oracle Net Listenerはリスナーが毎秒処理する新規接続数に対して、ユーザーが指定した最大値を設定します。

構成によっては、一連のエンドポイント、または特定のエンドポイントに対して速度を指定できます。

この機能は以下の2つのlistener.ora構成パラメータによって制御されます。

• CONNECTION_RATE_<listener_name>=number_of_connections_per_secondでは、速度制限のあるすべてのリスニング・エンドポイント全体に適用されるグローバル速度が設定されます。このパラメータを指定すると、指定されているすべてのエンドポイント・レベルの速度数値より優先されます。

• RATE_LIMITは、特定のリスナー・エンドポイントに速度制限が課されていることを示します。このパラメータは、リスナー・エンドポイント構成のADDRESSセクションで指定されます。RATE_LIMITパラメータが0より大きい値に設定されている場合、エンドポイント・レベルで速度制限が課されます。

例：新しい接続のスロットルによってログオン・ストームを防止します。

APP_LSNR= (ADDRESS_LIST=

(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)(RATE_LIMIT= 10))

(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1522)(RATE_LIMIT=20))

(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1523))

)

上記の例では、エンドポイント・レベルで接続速度が指定されています。毎秒、ポート1521で最大10の接続が処理されます。ポート1522の接続は毎秒20に制限されています。ポート1523の接続は制限されていません。速度が超過すると「TNS-01158: Internal connection limit reached（内部接続制限に到達）」とログに記録されます。

『Net Servicesリファレンス・ガイド』を参照してください。

https://docs.oracle.com/cd/E16338_01/server.112/b56311/toc.htm


19

その他の設定

Exadataの構成およびパラメータに関するベスト・プラクティスは、MOS Note 1274318.1および1347995.1に記載されています。

システムの監視と確認の開始

データベースとシステム・リソースの監視と管理には、 Enterprise Manager 、 Automatic Workload Repository（AWR）を使用した統計情報収集機能、またはActive Data Guard環境のActive Data Guard Statspackが必要です。詳しくは、次のドキュメントを参照してください。

• MOS Note 1070954.1のExachk

• 『Oracle Enterprise Manager 12c：Oracle Exadata検出の説明書』およびMOS Note 1110675.1に記載された、Enterprise Manager 12cによるExadata監視のベスト・プラクティス

• Exadata Automatic Service Request（http://www.oracle. com/asr）

• MOS Note 454848.1のActive Data Guard statspack

• 『Oracle Clusterware管理およびデプロイメント・ガイド』の“クラスタ・ヘルスの監視”

リソース管理 Oracle Database Resource Manager（Resource Manager）はワークロードとデータベースの間で、システム・リソースをきめ細かく制御できるインフラストラクチャです。Resource Managerを使用してCPU、ディスクI/O、およびパラレル実行を管理します。Resource Managerは以下の2つのシナリオで役立ちます。

• データベース内での統合の場合は、リソースの使用とアプリケーション間の競合の管理。

• データベース間での統合の場合は、リソースの使用とデータベース・インスタンス間の競合の管理。

Resource Managerによるデータベース間（スキーマ）統合

Resource Managerをデータベース内（スキーマレベル）の統合に使用して、単一データベース内でのアプリケーションによるCPU、I/O、およびパラレル・サーバーの共有方法を制御できます。リソースは、データベース管理者が指定するリソース・プランに基づいて、ユーザー・セッションに割り当てられます。リソース・プランでは、リソース・コンシューマ・グループ（リソース要件によってグループ化されるユーザー・セッション）間のリソース配分が指定されます。スキーマ統合の場合、アプリケーションごとにコンシューマ・グループを作成するのが一般的です。リソース・プラン・ディレクティブによってリソース・コンシューマ・グループとリソース・プランが関連付けられ、コンシューマ・グループに対するCPU、I/O、パラレル・サーバーのリソース配分が指定されます。

CPUリソース管理によって、クリティカル・バックグラウンド・プロセス（LGWR、PMON、LMSなど）が枯渇しないという利点もあります。この結果、OLTPワークロードのパフォーマンスを向上させ、Oracle RACデータベースのインスタンス排除のリスクを軽減できます。

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=REFERENCE&id=1070954.1

http://www.oracle.com/technetwork/jp/database/features/availability/em12c-exadata-discovery-cookbook-1662643-ja.pdf

http://docs.oracle.com/cd/E16338_01/rac.112/b56289/troubleshoot.htm#CHDFCHFJ


20

各アプリケーションのリソース使用率を管理するには、リソース・プランを構成して有効にする必要があります。この方法について詳しくは、『Oracle Database管理者ガイド』の“Oracle Database Resource Managerによるリソース管理”、Oracle MAAのホワイト・ペーパー“Using Oracle Database Resource Manager（Oracle Database Resource Managerの使用）”、およびMOS Note 1339769.1のセットアップ・スクリプトの例を参照してください。

各アプリケーションのディスクI/Oを管理するには、I/O Resource Management（IORM）を有効にする必要があります。CPUの管理用のリソース・プランは、ディスクI/Oの管理にも使用されます。IORMはExadataセルのI/Oリソースをセル単位で管理します。I/Oリクエストによってセルのディスクに対するオーバーロードが発生する場合は、構成済みのリソース・プランに基づき、IORMによってI/Oリクエストがスケジューリングされます。IORMは一部のI/Oをすぐに発行し、それ以外はキューに入れてI/Oのスケジューリングを行います。IORMではリソース・プランに基づき、発行するI/Oを選択します。つまり、割当て量が多いデータベースおよびコンシューマ・グループのほうが、割当て量が少ない場合よりスケジューリング頻度が高くなります。セルが容量未満で動作している場合、IORMではI/Oリクエストがキューに保存されません。

IORMを有効にすると、バックグラウンドI/Oを自動的に管理します。ログ・ファイルの同期や制御ファイルの読み書きなど、重要なバックグラウンドI/Oは優先的に処理されます。重要性の低いバックグラウンドI/Oは後回しにされます。

Resource Managerによるデータベース統合

Resource Managerは以下の2つの面でデータベース統合に役立ちます。第1に、Resource Managerはインスタンス・ケージングによって、CPUの使用制御とCPUの競合管理をサポートします。第2に、Resource Managerでは、IORMのデータベース間リソース・プランによってディスクI/Oの使用と競合を制御できます。

データベース間のIORMプランによって、Exadataセルを共有する複数のデータベースを管理できます。データベース間のIORMプランは、Cell Control Command-Line Interface（CellCLI）ユーティリティによって構成されます。データベース間のIORMプランを使用すると、データベースごとに次の内容を指定できます。

• ディスクI/Oのリソース割当て：データベースのリソース割当て量が多ければ、ディスクI/Oをより迅速に発行できます。データベース内のワークロード用のリソース割当ては、データベースのリソース・プランで指定されます。データベースのリソース・プランが有効でない場合は、データベースからのユーザーI/Oリクエストがすべて均一に処理されます。ただしその場合でも、バックグラウンドI/Oは自動的に優先処理されます。

• ディスク使用率の制限：リソース割当ての指定以外に、各データベースのディスク使用率の最大値も指定できます。たとえば、本番データベースのOLTPとOLTP2がExadataストレージを共有している場合、両方のデータベースに最大使用率を設定できます。データベースのディスク使用率の制限を設定すると、パフォーマンスが予測しやすく一貫したものになります。これは、ホストされた環境ではより重要です。

最大使用率の制限を指定すると、データベースで過剰な容量を使用できなくなります。最大使用率の制限が指定されている場合は、ディスクが全容量未満で動作する場合があります。

• フラッシュ・キャッシュの使用：Exadataソフトウェア・バージョン11.2.2.3.0以降は、IORMがフラッシュ・キャッシュ管理をサポートするようになりました。ALTER IORMPLANフラッシュ・キャッシュ属性を“オフ”に設定し、データベースでフラッシュ・キャッシュが使用されないようにすることができます。この設定によって、ミッション・クリティカル・データベース用にフラッシュ・キャッシュを予約しておくことができます。クリティカル・データベースのフラッシュ・キャッシュ・ヒット率に影響を及ぼ

http://docs.oracle.com/cd/E16338_01/server.112/b56301/dbrm.htm#i1010776

http://www.oracle.com/technetwork/jp/database/focus-areas/performance/resource-manager-twp-133705-ja.pdf

http://www.oracle.com/technetwork/jp/database/focus-areas/performance/resource-manager-twp-133705-ja.pdf


21

していることが確かな場合に限り、フラッシュ・キャッシュの使用を無効にしてください。フラッシュ・キャッシュの無効化は、ディスクI/Oロードの増加というデメリットがあります。

注：Exadata Storage Serverソフトウェア11.2.3.1以降、I/O Resource Management（IORM）ではshareベースのプランがサポートされるようになりました。このプランでは、最大1024個のデータベース、およびデータベース間プラン用に最大1024個のディレクティブをサポートできます。共有ベースのプランでは、割合ではなく共有に基づいてリソースが割り当てられます。共有とはI/Oリソースの相対的配分です。また、新しい”default”ディレクティブによって、データベース・プランで明示的に名前が付けられていないすべてのデータベースに”default”のディレティブが指定されます。以前のリリースでは、31個のデータベースまでしかサポートされていませんでした。

カテゴリ・リソース管理は高度な機能です。主として実行する作業のカテゴリごとにリソースを割り当てることができます。たとえば、すべてのデータベースに3つのワークロード・カテゴリ（OLTP、レポート、メンテナンス）があるとします。これらのワークロード・カテゴリに基づきI/Oリソースを割り当てるために、カテゴリ・リソース管理を使用することができます。『Oracle Exadata Storage Server Software User’s Guide』の“About Category Resource Management”を参照してください。

ここでは特に、Exadataの統合の主要な実例について説明しています。Exadataのリソース管理の前提条件、ベスト・プラクティス、パッチについて詳しくは、『Master Note for Oracle Database Resource Manager』

（MOS Note 1339769.1）を参照してください。

ハードウェア・プール内のCPUおよびI/Oリソースの管理ガイドライン

• インスタンス・ケージングを有効化します。サイズ設定分析に従って、各インスタンスにCPU_COUNTを設定します。

• クリティカルなハードウェア・プールの場合は、パーティション化（sum(CPU_COUNT) <= CPU数の100%）を使用します。

• クリティカルでないテスト用のハードウェア・プールの場合は、許容可能な応答時間またはスループットの要件に応じて、オーバーサブスクリプション（sum(CPU_COUNT) <= (最大3) * CPU）を使用します。

• データベース間のIORMプランを構成して有効にします。

• データベース内のワークロード用にResource Managerを構成するには、『Oracle Database管理者ガイド』の“データベースのリソース管理とタスクのスケジューリング”を参照してください。

監視とチューニング

おもな推奨事項は次のとおりです。

• 各アプリケーションのパフォーマンス・メトリックが基準を達成していることを確認します。これらのメトリックは最大の判断材料になります。

• インスタンス・ケージング用に、以下の問合せを使用して各インスタンスのCPU使用率を監視します。MOS Note 1338988.1も参照してください。

http://docs.oracle.com/cd/E16338_01/server.112/b56301/part6.htm#i996746


22

SQL> select to_char(begin_time, 'HH24:MI') time,

max(running_sessions_limit) cpu_count, sum(avg_running_sessions)

avg_running_sessions, sum(avg_waiting_sessions)

avg_waiting_sessions from v$rsrcmgrmetric_history group by

begin_time order by begin_time;

avg_running_sessionsが一貫してCPU_COUNT値未満である場合は、パフォーマンスに影響せずにCPU_COUNT値を減らすことができ、より多くのリソースを必要とする別のインスタンスのCPU_COUNT値を増やすことができます。

avg_waiting_sessionsが常にCPU_COUNT値より大きく、応答時間とスループットが許容できないほど遅い場合、（使用可能なCPUリソースがある場合は）CPU_COUNT値を大きくしてパフォーマンスを上げることができます。それ以外の場合は、このアプリケーションまたはデータベースを別のハードウェア・プールに移行することを検討してください。

• オーバーサブスクリプションによるインスタンス・ケージングを使用する場合は、システムを監視します。システムCPUの実行キューが9を超えている場合は、全インスタンスのCPU_COUNTの合計を下げることを検討します。

• MOS Note 1337265.1のスクリプトを使用してI/Oメトリックを監視します。

このスクリプトを実行すると、データベースおよびコンシューマ・グループによるディスクとフラッシュの使用に関する分単位のメトリックが表示されます。ディスクI/O待機時間のメトリックも分単位で表示します。IORMが有効化されている場合は、I/Oスロットリングのメトリックも分単位で表示します。

注：ディスク単位の最大I/O/秒（IOPS）は、高パフォーマンス・ディスクの場合は300IOPS、大容量ディスクの場合は150IOPSです。Exadataセルの最大スループットは、高性能ディスクの場合が1.5～2.0GB/秒で、大容量ディスクの場合が1GB/秒です。I/Oスループットの一般的な問題としては、I/O使用率（iostatの%util）が高い、ディスク・キュー・サイズ（iostatのavgqu-sz）が大きい、iostatやスループットの応答時間やI/O待機時間が長いなどの現象があります。

チューニングによるワークロードの待機時間短縮

OLTPワークロードでは、待機時間が短いことが何よりも重要です。以下の点を確認してください。

1. バッファ・キャッシュ・ヒット率が高い（> 98%）。バッファ・キャッシュを適宜チューニングします。

2. フラッシュ・キャッシュ・ヒット率が高い（> 90%）。必要に応じてホット・テーブルをフラッシュ・キャッシュに固定します。

3. ディスク使用率が低い（< 60%）。ディスク使用率が高くなると、スループットは改善されますが、待機時間が長くなります。このため、ディスク使用率が高い場合はI/Oメトリックを使用して、負荷の原因となっているデータベースやアプリケーションを特定します。

4. データベースの待機イベントの待機時間が短い（たとえばlog file syncで10ms未満、db file sequential readで15ms未満、cell single block physical readで15ms未満）。

5. データベースごとのディスク使用率。1つのデータベースのディスク使用率が大幅に高まった場合、他のデータベースにも影響を及ぼします。AWRおよびASHレポートのI/Oメトリックまたは上位のI/Oトランザクションを使用して監視を行います。


23

以下のように、IORMを使用してOLTP待機時間を改善できます。

1. OLTPワークロードが含まれたデータベースおよびコンシューマ・グループへのリソース割当てを増やします。

2. それでも待機時間が長い場合は、IORMの目標を“短い待機時間”に設定します。

3. それでも待機時間が長い場合は、OLTPとDSSのワークロードでストレージを共有させるにはパフォーマンス目標が高すぎる可能性があります。スループットと待機時間の間には、本質的にトレードオフがあります。ディスク待機時間を大幅に短縮するには、ディスク使用率をかなり低く設定しなければなりませんが、OLTPとDSSのワークロードでストレージを共有する意味がなくなります。この場合は、OLTPとDSSに別のストレージまたはハードウェア・プールを作成することを検討してください。

使用例1：OLTP DBとの統合

この使用例では、3つのクリティカルなGoldレベルのOLTPデータベース間でI/Oリソースを分散させ、Exadata Database Machine X3-2でインスタンス・ケージングを構成する方法について説明します。通常は、シンプルな単一レベルのリソース・プランを使用することを推奨します。以下のリソース・プランでは、割当てを指定するだけでなく、COMMERCEデータベースとSALESデータベースで50%、PAYROLLデータベースで30%のI/O制限ディレクティブを使用しています。これは、他のデータベースからの負荷によるパフォーマンスのばらつきを防ぐためです。他のデータベースがアイドル状態の場合に、各データベースがディスク・リソースを100%使用できるようにするには、制限ディレクティブを削除します。

表4.OLTPの統合

データベース名説明レベル割当て制限 CPU_COUNT

OLTP-A Gold：COMMERCE 1 35 50 8

OLTP-B Gold：SALES 1 35 50 8

OLTP-C Gold：PAYROLL 1 20 30 6

その他（その他の Goldデータベース）

1 10 30 4

ALTER IORMPLAN

dbplan=((name=oltp-a, level=1, allocation=35, limit=50), -

(name=oltp-b, level=1, allocation=35, limit=50), -

(name=oltp-c, level=1, allocation=20, limit=30), -

(name=other, level=1, allocation=10, limit=30))

インスタンス・ケージングを有効化するには、各インスタンスのCPU_COUNTを設定し、CPU Resource Managerを有効にします。たとえば以下を使用して、OLTP_Aインスタンスのインスタンス・ケージングを有効化できます。


24

SQL> ALTER SYSTEM SET CPU_COUNT = 8 SCOPE=SPFILE; SQL> ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'DEFAULT_PLAN' SID= ’*’ SCOPE=’BOTH’;

使用例2:混合ワークロードとの統合

ここでは、OLTPワークロードを他のOLTPおよびDWのワークロードより優先し、I/O待機時間を短くする使用例について説明します。

表5.OLTPを優先した混合統合

データベース名説明レベル割当て

OLTP-A Goldデータベース 1 50

OLTP-B Goldデータベース 1 20

OLTP-X Goldデータベース 1 10

DW-Y Goldデータウェアハウス 1 10

その他（その他のデータベース） 1 10

OLTPデータベースにはデータウェアハウス・データベースより多くのリソースが割り当てられているため、待機時間を短縮するためにIORMによって自動的に最適化されます。この目標を明示的に制御するには、ALTER IORMPLANを使用して目標を“短い待機時間”に設定します。IORMは混合ワークロード環境で、約15msまでディスク待機時間を短縮できます。

使用例3：データウェアハウスとの統合

リソースこの使用例では、3つのデータウェアハウス・データベース間でI/Oリソースを分散させる方法について説明します。通常は、シンプルな単一レベルのリソース・プランを使用することを推奨します。以下のリソース・プランでは、割当てを指定するだけでなく、DW-XデータベースとDW-Yデータベースで40%のI/O制限ディレクティブを使用し、残りのデータベースに対する割当ては少なくしています。これは、他のデータベースからの負荷によるパフォーマンスのばらつきを防ぐためです。制限は、“ペイフォーパフォーマンス”モデルが必要なホスティング環境で便利です。

表５.データウェアハウスの統合

データベース名説明レベル割当て制限

DW-X Silverデータウェアハウス 1 40 30

DW-Y Silverデータウェアハウス 1 40 30

DW-Z Silverデータウェアハウス 1 10 20

その他（その他の Silverレベルのデータベース）

1 10 20


25

使用例4：混合カテゴリの統合

この使用例では、3つのミッション・クリティカルなGoldレベルのActive Data Guardスタンバイ・データベースと共存するBronzeレベルのテスト・データベースの間でI/Oリソースを分散させる方法について説明します。通常は、シンプルな単一レベルのリソース・プランを使用することを推奨します。以下のリソース・プランでは、割当てを指定するだけでなく、スタンバイ・データベースで30%、その他のデータベースで20%のI/O制限ディレクティブを使用しています。これは、他のデータベースからの負荷によるパフォーマンスのばらつきを防ぐためです。 Data Guardのロール移行があり、スタンバイ・データベースの1つがプライマリ・データベースになる場合は、新しいプライマリ・データベースで制限値を大きくしてテスト・データベースを実質的にシャットダウンするか、制限値をさらに小さくします。このように、ソフトウェア更新など、運用上の考慮事項が増えるため、混合カテゴリとの統合は推奨しません。例外的に使用してください。

表6.データウェアハウスの統合

データベース名説明レベル割当て制限

ADG1 Gold：Commerce Active DG1 1 20 30

ADG2 Gold：Sales Active DG2 1 20 30

ADG3 Gold：Payroll Active DG3 1 20 30

TEST1 Bronzeテスト 1 10 20

TEST2 Bronze開発 1 20 20

TEST3 Bronze Q/A 1 10 20

リソース管理に関するベスト・プラクティス

効果的なリソース管理のためのスクリプトや推奨されるソフトウェア・バージョンなど、リソース管理に関する最新のベスト・プラクティスは、MOS Note 1339769.1を参照してください。

メンテナンスと管理に関する考慮事項 Oracle Softwareおよびファイル・システム領域

アクティブなOracleホームは2～3個のバージョンを維持してください。データベース・バージョンが多すぎると、メンテナンスが複雑になるためです。またOracle Grid Infrastructureソフトウェアのバージョンは、Oracle Databaseソフトウェアのもっとも新しいバージョン以上であることが必要です。可能なかぎり共有Oracleホームを使用して、固定数の端末リリースを維持します。


26

すべてのOracleホーム、Oracle Grid Infrastructureホーム、および各種ログ・ディレクトリに対応するため、ルート・パーティション領域を最大化するには、次の操作を実行します。

• 使用するオペレーティング・システムを選択した後に、ディスク領域が回復していることを確認します。『Oracle Exadata Database Machine Owner’s Guide』の“Reclaiming Disk Space After Selecting the

Operating System”を参照してください。

• root以外のパーティション（/u01）に領域を追加できるかどうかを検証します。『Oracle Exadata Database Machine Owner’s Guide』の「Resize LVM Partitions」を参照してください。

• 段階を追った手順は、「How to Expand Exadata Compute Node File Systems」（MOS Note 1357457.1）を参照してください。

• cron（MOS Note 1298957.1）を使用して監査ファイル・ディレクトリの拡大を管理します。

• または、ログ・ディレクトリやファイルを、DBFSまたは外部のNFSディレクトリにコピーおよびパージすることができます。

セキュリティおよび管理ロール

ハードウェア・プール内で複数のデータベースが統合されている場合、特定のデータベースのコンポーネントや機能を分離して、管理と権限を明確に分けることが必要な場合があります。ホワイト・ペーパー

『Oracle Exadata Database Machine Consolidation: Segregating Databases and Roles（Oracle Exadata Database Machineの統合：データベースとロールの分離）』では、オペレーティング・システムとデータベースを対象にしたセキュリティを使用して、管理者やエンドユーザーの不正アクセスを防ぐ方法を説明しています。

注：Oracle 11gではOracle ASMディスク・グループの最大数は、1つのストレージ・グリッドあたり63です。

以下の図は、これらのセキュリティ技法を使用してアクセスを制限する方法を示しています。この方法は、デフォルトの推奨される単一DATA/RECOディスク・グループ構成とは異なります。

http://www.oracle.com/technetwork/database/focus-areas/availability/maa-exadata-consolidated-roles-459605.pdf

http://www.oracle.com/technetwork/jp/database/features/availability/maa-exadata-consolidated-roles-459605-ja.pdf

http://www.oracle.com/technetwork/jp/database/features/availability/maa-exadata-consolidated-roles-459605-ja.pdf


27

図2.アクセス制限のためのセキュリティ技法

統合用のExadata MAA

Oracle Maximum Availability Architectureは特に、アプリケーションを異種システムで実行する場合と比べて計画停止時間と計画外停止時間の影響がずっと大きい統合環境に関連しています。Exadataの一般的なベスト・プラクティスについては、ホワイト・ペーパー、『MAA best practices for Oracle Exadata（Oracle Exadataに関するMAAベスト・プラクティス）』を参照してください。次の項では、統合環境におけるOracle MAAの主要な推奨事項について説明します。

ビジネス・クリティカルなアプリケーションの統合MAA環境は、以下によって構成されています。

• 本番ハードウェア・プール（複数可）

• スタンバイ・プール（複数可）。Data Guardを使用して、本番ハードウェア・プールと正確に同期させたレプリカである、スタンバイ・プールを維持します。本番ハードウェア・プールの重要度によっては、同期によってデータ損失がゼロの保護を使用したローカル・スタンバイ・プールと、非同期トランスポートを使用したリモート・スタンバイ・プールの両方によって、地理的に広範囲の障害から保護することができます。スタンバイ・プールは、フェイルオーバーが必要な場合に同等のサービス・レベルを提供できるよう、本番ハードウェア・プールと同等の容量で構成されています。スタンバイ・ロール中のスタンバイ・プールを効率的に使用する方法がいくつかあります。詳しくは、MAAのホワイト・ペーパー『Disaster Recovery for Oracle Exadata Database Machine（Oracle Exadata Database Machineの

http://www.oracle.com/technetwork/jp/database/features/availability/exadata-maa-131903-ja.pdf


http://www.oracle.com/technetwork/database/features/availability/maa-wp-dr-dbm-130065.pdf

http://www.oracle.com/technetwork/jp/database/features/availability/maa-wp-dr-dbm-130065-ja.pdf


28

ディザスタ・リカバリ）』を参照してください。スタンバイ・プールを使用して、Standby-First Patchによるパッチおよびソフトウェアの変更を検証することもできます（MOS Note 1265700.1を参照）。

• 開発用/テスト用ハードウェア・プール。本番ハードウェア・プールとスタンバイ・ハードウェア・プールの最大限の安定性および可用性を維持するには、すべての変更を最初に開発/テスト用システムで検証する必要があるため、開発用/テスト用ハードウェア・プールも非常に重要です。

図3.ExadataのMaximum Availability Architecture：統合データベース環境の保護

Maximum Availability Architecture（図3）は、統合環境用に以下のHA機能を提供します。

• Oracle Real Application Clustersによる、ノードおよびインスタンスの障害に対する耐性の強化

• Oracle ASMおよびOracle Exadataによる、各種ストレージ障害に対する耐性の強化

• Active Data Guardによる、物理的なブロック破損の自動修復、プライマリ・ハードウェア・プールに影響を与えうるデータ破損や停止に対するスタンバイ・プールの保護、および（個々のデータベースやハードウェア・プールに何らかの理由で障害が発生した場合の）迅速なフェイルオーバーによる高可用性の維持



29

• Data Guard構成における破損の検出、防止および自動修復に関するベスト・プラクティス（MOS Note 1302539.1）

• Oracleオンライン・パッチ、Oracle Grid InfrastructureおよびOracleExadataセルのローリング・パッチ、Oracle RACのローリング・メンテナンス、Oracle Data GuardのStandby-First Patch、Oracle Data Guardデータベースの“一時ロジカル”ローリング・アップグレード、およびOracle GoldenGateの異機種間移行および停止時間ゼロのメンテナンスによる、計画メンテナンスの停止時間の最小化または解消

• フラッシュバック・テクノロジーを使用した高速ポイント・イン・タイム・リカバリによる、論理的破損からのリカバリ

上記の機能のHAベスト・プラクティスについては、ホワイト・ペーパー『MAA best practices for Oracle Exadata（Oracle Exadataに関するMAAベスト・プラクティス）』を参照してください。

次のExadata MAAの運用上の実践方法は、統合データベース環境の次のようなHA目標の達成にも重要です。

1. HAの品質保証契約を文書化

2. さまざまな停止における修復方法およびローリング・アップグレード・ソリューションを検証

3. MOS Note 1262380.1に記載されているテストおよびパッチ適用の実践方法（Standby-First Patch（MOS Note 1265700.1）を含む）に従う

4. 計画メンテナンス作業の前後および毎月1回以上、exachkユーティリティの最新バージョンを実行する（MOS Note 1070954.1）。ソフトウェアのギャップと推奨事項、およびハードウェア、ソフトウェア、

MAAのアラートと推奨事項に対応

5. Data Guardのロール・トランジションを定期的（6か月ごとなど）に実行

6. Exadata監視、Oracle Configuration Manager（OCM）、およびAutomatic Service Requestのベスト・プラクティス（MOS Note 1110675.1および1319476.1）に従って構成

7. www.oracle.com/goto/maaに掲載された最新のMAAベスト・プラクティスとホワイト・ペーパーを参照し、Exadata MAAの一般的な実践方法については、テクニカル・ホワイト・ペーパー『MAA best practices for Oracle Exadata（Oracle Exadataに関するMAAベスト・プラクティス）』も参照

次の項では、データベース統合におけるExadata MAAのその他の考慮事項について説明します。

パッチ適用とアップグレード

Exadataハードウェア・プール上で初めてソフトウェアを構成する際は、exachkを実行してソフトウェア・ガイダンスを参照します。ローリング・アップグレードの使用例を除き、Exadataセルはすべて同じバージョンである必要があります。すべてのデータベース・ノードで、同じバージョンの Oracle Grid Infrastructureソフトウェアと最大2～3個の共有Oracle Databaseホームを使用する必要があります。

Oracle Databaseソフトウェア・バージョンのアップグレード時には、アウトオブプレースのパッチ適用およびアップグレード手順に従うことをお勧めします。この方法では他のデータベースに影響を及ぼさずに、ターゲット・データベースを新しいバージョンに移行でき、予期しなかったパフォーマンス上の問題が発生した場合にも前のバージョンに簡単にフォールバックできるため、データベース統合環境では特に便利です。データベース・サーバーにはOPlanやOPatchなど、Exadataセルにはpatchmgrなどのツールを使用します。

http://www.oracle.com/technetwork/database/features/availability/exadata-maa-131903.pdf



http://www.oracle.com/technetwork/jp/database/features/availability/maa-094615-ja.html





30

バックアップとリカバリ

統合によってバックアップ、リストア、リカバリ方法を変える必要はありません。バックアップを各種のリカバリ・シナリオで使用する方法、期待しているRTO（リカバリ・タイム目標）やRPO（リカバリ・ポイント目標）、バックアップに割り当てられた時間をよく理解することから始めてください。ハードウェア・プールには、HA要件が類似しているアプリケーションとデータベースを含める必要があります。MAAハードウェア・プール・アーキテクチャを使用するクリティカル・ハードウェア・プールの場合、データベース・ノード、2重障害、破損や論理障害の場合のベア・メタル・リストアには、バックアップが使用される場合があります。次に、Exadata上のディスクベース・バックアップ（内部、またはExadata Storage Expansion Rack）、またはテープへのバックアップで何が可能なのかを理解しておいてください。バックアップとリストアで実現可能な速度と構成の実践方法については、テクニカル・ホワイト・ペーパー

『ExadataセルおよびOracle Exadata Database Machineを使用したバックアップおよびリカバリのパフォーマンスとベスト・プラクティス』、

『Sun ZFS Storage ApplianceとOracle Exadata Database Machineを使用したバックアップおよびリカバリのパフォーマンスとベスト・プラクティス』、および

『Oracle Exadata Database Machine - バックアップとリカバリのサイジング：テープ・バックアップ』を参照してください。

次の手順は、特に次のような使用可能なシステム・リソースについて、データベースのバックアップとリストアが非常に重要であることを理解するためのものです。

• バックアップとリストアのためのExadataディスクのスループット。

• ネットワーク帯域幅：ExadataベースのバックアップではInfiniBandが重要です。Exadata以外のディスクベース・バックアップまたはテープの場合は、外部ネットワークが重要です。

• サード・パーティのI/Oスループット：テープベースのバックアップの場合はテープ・スループットが重要です。Exadata以外のストレージ・ターゲットの場合は、ストレージのスループットが重要です。

次に、1つまたは複数のデータベースを同時にバックアップまたはリストアできます。ボトルネックは、上記のいずれかの要因から発生します。

例1：Exadata Database Machineからディスクへのフル・ラック・バックアップ

この例では、高性能なSASディスクを搭載したExadata Database Machine X2-2フル・ラック上に、5つのデータベースがあります。すべてのデータベースで使用するデータベース領域の合計は約50TBです。

オラクルが実施したMAAに関する調査では、RMAN操作ですべてのデータベース・ノードを活用し、データベース・ノードあたり2～8のRMANチャネルを割り当てた場合、最大20TB/時以上のバックアップ速度が期待できることがわかりました。バックアップ処理の間にアプリケーション・パフォーマンスに影響が出ないように、バックアップ速度を上げることができます。ノードあたり1つまたは2つのRMANチャネルしか割り当てない状態でも、バックアップ速度が10TB/時の場合、すべてのデータベースを5時間でバックアップできます。データベースを1つずつバックアップすることも、同時に複数のデータベースをバックアップすることもできます。重要なのはすべてのノードに作業を分散し、データベース・ノードへの影響が均等になるようにすることです。たとえば、1つのバックアップ・サービスでデータベース・ノード1～4を使用し、もう1つのバックアップ・サービスでデータベース・ノード5～8を使用する2つの別々のデータベースで、2つのRMAN操作を実行できます。この場合でも、2つのバックアップ速度の合計は10TB/時になります。オラクルが推奨する増分バックアップを使用すると、バックアップ時間を1時間未満に短縮できます。

http://www.oracle.com/technetwork/jp/database/features/availability/maa-tech-wp-sundbm-backup-11202-183503-ja.pdf

http://www.oracle.com/technetwork/jp/database/features/availability/maa-tech-wp-sundbm-backup-11202-183503-ja.pdf

http://www.oracle.com/technetwork/jp/database/features/availability/1208156-maa-wp-dbm-zfs-backup-1593252-ja.pdf

http://www.oracle.com/technetwork/jp/database/features/availability/1208156-maa-wp-dbm-zfs-backup-1593252-ja.pdf

http://www.oracle.com/technetwork/jp/database/availability/maa-exadata-backup-methodology-495297-ja.pdf


31

例2：Exadata Database Machineからテープへのフル・ラック・バックアップ

この例では、高性能なSASディスクを搭載したExadata Database Machine X2-8上に、10個のデータベースがあります。このデータベースはDATA領域により多くの使用可能領域を残すため、テープベースのバックアップ・ソリューションを使用します。すべてのデータベースで使用するデータベース領域の合計は約100TBです。2台のメディア・サーバーと16台のテープ・ドライブ（たとえば200MB/秒）があります。テープ・ドライブ数とスループットがボトルネックになります。このテープベースのインフラストラクチャでは、11TB/時に近いバックアップ/リストア・スループットを達成します。ノードあたり8つのRMANチャネルを割り当て、2つのデータベース・ノードにバックアップ・サービスを分散します。100TB全部のフル・データベース・バックアップは10時間未満で終了し、バックアップ・セットの実際のサイズによっては、毎日行う累積増分バックアップは2時間未満で終えることができます。

さらに、リソース管理によって、異なるバックアップやアプリケーション・ワークロードの優先度を設定できます。

Data Guard

ExadataでのData Guardの実例については、ホワイト・ペーパー『Oracle Data Guard：Oracle Exadata Database Machine のディザスタ・リカバリ』を参照してください。スタンバイ・プールの統合に関する主要な考慮事項は以下のとおりです。

• プライマリ・プールとスタンバイ・プールが同じInfiniBandファブリック上にないことを確認します。

• データ損失ゼロが必要な場合は、ローカル・スタンバイ・プールが必要です。また、Data Guard同期トランスポートによるパフォーマンスの影響を判断するために、パフォーマンス評価を行う必要があります。

• すべてのプライマリ・データベースとスタンバイ・データベースの間のREDOトラフィック合計を処理するために、十分なネットワーク帯域幅が必要です。プライマリ・プールとスタンバイ・プールがネットワーク帯域幅の足りないWAN上にある場合は、REDO圧縮の使用を検討してください。REDO圧縮によって、プライマリ・プールとスタンバイ・プールのCPUオーバーヘッドが5～10%消費されます。

• アプリケーションおよびData Guardのスイッチオーバーとフェイルオーバー操作を含むロール移行テストを行います。テストは単一データベース、複数データベース、そして不利な状況として、ハードウェア・プール全体で行い、あらゆる状況でRTOおよびRPO要件を達成できることを確認します。

• 本番ハードウェア・プール全体に障害が発生した場合でも、すべてのターゲット本番ワークロードをサポートできるように、スタンバイ・プールに十分なシステム・リソースがあることを確認します。

• プライマリおよびスタンバイ・プール内で多数のデータベースを管理するのは複雑な作業なので、Data GuardブローカとEnterprise Managerの使用を強く推奨します。RTOを短縮し、障害の検出および対応時間をなくすために自動フェイルオーバーが必要な場合は、Data Guardのファスト・スタート・フェイルオーバーと、MAAクライアントのフェイルオーバーのべスト・プラクティス（『Client Failover Best Practices for Data Guard 11g Release 2』）を検討してください。



http://www.oracle.com/technetwork/database/features/availability/maa-wp-11gr2-client-failover-173305.pdf

http://www.oracle.com/technetwork/database/features/availability/maa-wp-11gr2-client-failover-173305.pdf


32

スキーマ統合によるリカバリ

（1つのデータベースで複数のアプリケーション・スキーマを実行する）スキーマ・レベルの統合の場合、主要な考慮事項は、アプリケーション・スキーマが同じデータベース内での共存に適しているかどうかということです。スキーマ・レベルの統合が可能な場合は、Exadata MAAのすべての標準推奨事項に従って構成および管理する必要がある単一データベースになります。また、次の推奨事項と考慮事項が適用されます。

• 各アプリケーション・スキーマが個別の表領域または表領域セットに含まれる必要があります。これによって領域管理を簡単かつ効率的に行うことができます。このため、他のアプリケーションに影響を与えずに、表領域のポイント・イン・タイム・リカバリ（TSPITR）やフラッシュバック表の操作によって、特定のアプリケーション・スキーマのリカバリを容易に実行できます。

• 各アプリケーション・スキーマは、別々のデータベース・サービスを使用する必要があります。

• バックアップとリカバリの実践方法を調整して、他のアプリケーションに対して最小限の中断時間で個々のアプリケーション・スキーマや表領域を維持できるようにします。これには異なる方法のオーバーヘッドと要件を理解し、適切な目標を達成するために必要なシステム・リソースが提供されていることを確認する作業も含まれます。別の修復方法としては、TSPITR、フラッシュバック表またはフラッシュバック・トランザクション、エクスポートとインポート、Data Pump操作などがあります。

• TSPITRを検討している場合は、迅速なリカバリのために、イメージ・コピーを使用できるかどうかも検討してください。この場合、RMANはバックアップからデータファイルのリストアを行う必要がありません。

• 『MAA Schema Recovery Options in an Exadata Consolidate Environment practices（Exadata統合環境でのMAAスキーマ・リカバリ・オプションに関するベスト・プラクティス）』（MOS Note 1386048.1）を参照してください。

まとめ Exadataは、OLTPデータベースとデータウェアハウス・データベースの高パフォーマンスとスケーラブルな容量を実現するために設計された、最適なデータベース統合プラットフォームです。Oracle Database、ストレージおよびネットワーク・グリッド・アーキテクチャに、Oracleリソース管理機能を組み合わせることで、他の仮想化方法（たとえばハードウェアやオペレーティング・システムの仮想化）よりも簡単に、そして柔軟にデータベースを統合することができます。データベース統合環境で共有リソースを使用する複数のアプリケーションとデータベースをサポートする場合は、本書や関連する参考資料に記載のベスト・プラクティスに従って、安定性と可用性を最大限に高めてください。

Oracleホワイト・ペーパー・タイトル 2013年10月著者：Lawrence To、Sue K. Lee

共著者：Exadata MAAチーム、 Juan Loaiza、Joe Meeks、Frank Kobylanski、 Rene Kundersma、Mahesh Subramaniam、 Doug Utzig、Mike Nowak、Andrew Babb、 Hector Pujol、Virginia Beecher、 DWおよびOLTP Performanceチーム

Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A.

海外からのお問い合わせ窓口：電話： +1.650.506.7000 ファクシミリ： +1.650.506. 7200

oracle.com

Copyright © 2013, Oracle and/or its affiliates.All rights reserved.本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告

なく変更されることがあります。本文書は、その内容に誤りがないことを保証するものではなく、また、口頭による明示的保証や法律による黙示

的保証を含め、商品性ないし特定目的適合性に関する黙示的保証および条件などのいかなる保証および条件も提供するものではありません。オラ

クルは本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的または間接的に確立される契約義務はないものとします。本文書

はオラクルの書面による許可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成ま

たは送信することはできません。

OracleおよびJavaはOracleおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。

AMD、Opteron、AMDロゴおよびAMD Opteronロゴは、Advanced Micro Devicesの商標または登録商標です。IntelおよびIntel XeonはIntel

Corporationの商標または登録商標です。すべてのSPARC商標はライセンスに基づいて使用されるSPARC International, Inc.の商標または登録商標で

す。UNIXはX/Open Company, Ltd.によってライセンス提供された登録商標です。1010

exadata database machine上でのデータベース統合 …...て、1つのoracle exadata database...

Documents