Oracle Database 12c：ポリシー管理型Oracle RACデータベースの推奨理由と使用方法

Size: px

Start display at page:

Download "Oracle Database 12c：ポリシー管理型Oracle RACデータベースの推奨理由と使用方法"

ほのかさだい
5 years ago
Views:

1 Oracle ホワイトペーパー 2014 年 1 月 Oracle Database 12c: ポリシー管理型 Oracle RAC データベースの推奨理由と使用方法

2 Oracle Database 12c: ポリシー管理型 Oracle RAC データベースの推奨理由と使用方法はじめに... 2 Oracle RACのデプロイメント例... 3 ユースケース1: データベースサービスの起動順序の保証... 4 ユースケース2: 改善されたHAフェイルオーバー戦略... 6 ユースケース3: 最後に残るサービスの管理... 8 ユースケース4: 動的なリソースプロビジョニング... 9 ポリシー管理型 RACデータベースとポリシーセットポリシー管理データベース : マルチテナントRACデータベースのデフォルトのデプロイメントポリシー管理型 RACデータベースに関する考慮事項とヒント結論および詳細情報

3 はじめにデータベースはもはや世界の中心ではありません少し前までならこのような言い方は異端視されたかもしれませんがデータベースクラウドとDBaaSの登場によりデプロイメントの戦略とデータベース管理要件は一変しました単にパフォーマンススケーラビリティ高可用性を実現する計画では十分とは言えません新しいデプロイメントモデルでは統合プロビジョニングサービス品質も考慮に入れる必要がありますそのためにはデータベースインスタンスとサーバーからデータベースサービスおよびサーバープールへと焦点を移したクラスタデータベースを新しい方法でデプロイし管理する必要がありますマルチノードであるかOracle RAC One Nodeであるかに関係なく Oracle RACデータベースを2 種類の方法でデプロイおよび管理できるようになりましたデータベースを中心とする従来の方法は管理者管理デプロイメントと呼ばれており Oracle Database 11g Release 2より前に存在したRACのデプロイメントタイプに基づいていますこの方法では特定のノードで実行されるように各データベースインスタンスを静的に構成する必要がありまた preferredおよびavailable 宛先を使用して特定のインスタンス上で実行されるようにデータベースサービスを設定する必要がありますクラウドベースのサービスを中心とする新しいモードはポリシー管理デプロイメントと呼ばれておりサーバープールに基づいていますこの場合データベースサービスはサーバープール内の単一ノード上のシングルトンサービスとしてまたはサーバープール内の全ノードにわたって実行される均一サービスとしてサーバープール内で実行されますデータベースは1つまたは複数のサーバープールにデプロイされデプロイ環境内のサーバープールのサイズによってデータベースインスタンスの数が決まりますこれは新しい12cのマルチテナントRACデータベースで推奨されるデフォルトのデプロイメント手法でもありサーバープールがPDBのコレクションと関連サービスをホストしますこのモデルはDBaaSクラウド環境に必要とされる柔軟なリソース割当て機能を提供するだけでなく長年にわたる多数のOracle RACデータベースの管理課題を解決しますポリシー管理デプロイメントを作成するかまたはポリシー管理デプロイメントへ変換するかを決定するにははじめにクラスタ内でサーバープールが提供する機能について理解する必要がありますサーバープールの概要 Oracle Grid Infrastructure 11g Release 2ではクラスタを論理的にパーティション化してデータベースサービスやアプリケーションサービスを提供するサーバーのグループを作成する方法としてサーバープールが導入されていますデータベースとアプリケーションのスケーラビリティおよび可用性はサーバープールの作成時または更新時に定義されるサーバープールプロパティで制御されますそれぞれのサーバープールに最小サイズと最大サイズを設定するとプール内でホストされるサービスのスケーラビリティを調整できますプール間での可用性は重要度の値を設定することで管理できますサーバープールへのサーバーの割当てにはサーバー名ではなくカーディナリティ数を使用しますこのため任意のサーバーで任意のデータベースを実行できるように構成する必要がありますサーバーの異種性やストレージの接続性などが原因でこれを実現できない場合はサーバープールのメンバーシップ資格を決定するサーバーカテゴリ定義を使用することでサーバーに制限を設定できます 2

4 サーバープールがポリシー管理されたデータベースおよびサービスとどのようにやり取りするのかを理解するためまずは経験豊かなOracle RAC DBAであればなじみのあるいくつかのユースケースについて確認していきましょう各ユースケースはデプロイメントの課題や管理上の難点を示しておりこれらはサーバープールとポリシー管理デプロイメントへの変換によって解決されますポリシー管理デプロイメントの作成またはポリシー管理デプロイメントへの変換にはバージョン11g Release 2 以上が必要になります同じクラスタ内に古いバージョンを共存させることはできますがポリシー管理データベースと同じサーバーを共有することはできません代わりに旧バージョンのサーバーはGenericと呼ばれる特別なサーバープールに限定され管理者管理としてデプロイされます Genericプールまたはポリシー管理プール内でノード障害が発生した場合種類の異なるプール間で障害発生ノードにあるデータベースインスタンスまたはサービスのフェイルオーバーが実行されたりサーバーが移行されたりすることはありません Oracle RAC のデプロイメント例下記のユースケースと本書の後半を通じて使用するデプロイメント例では 4ノードクラスタがそれぞれが1つのデータベースサービスを含むOracle 12cマルチテナントデータベースおよび関連 PDBをホストしています図 1に示すこのデプロイメント環境では dancer dasher comet vixen という4つのノードが backofficeとfrontofficeという2つのサーバープール内で実行されています図 1: マルチテナント RAC データベースを使用したクラスタの例 3

5 サーバーは一度に1つのサーバープールに対してのみ配置できますこのクラスタは1つのマルチテナントデータベース (raccdb1) をホストしておりそれぞれが1つのサービスをホストする2つのPDB(crmsvcとhrsvc) を含みますこれは12cのマルチテナントを使用した例ですが下記のユースケースは11g Release 2または12cの標準 RACあるいはRAC One Nodeデータベースにも当てはまりますまたこの例のデータベースは2つのサーバープールにまたがって配置されていますが各サーバープール内に1つずつ別々のデータベースがある場合も同じ動きになります扱いやすい例にするため各ユースケースではプールごとに1つのサービスを含む単一のRACデータベースについて検討していきますユースケース1: データベースサービスの起動順序の保証データベースサービスが導入されて以来クラスタ全体が稼働したらサービスの再配置の必要性を排除するという起動順序の管理という問題がありましたこの問題が発生するのはクラスタに追加した最初のノード上のデータベースに割当てられたすべてのサービスがインスタンスの指定 ( 優先または使用可能 ) に関係なく開始されるためですこのような " 集団 " とそれによる再配置はクラスタの起動と調整にかかる時間を伸ばし手動による介入を増やしますポリシー管理のRACまたはRAC One Nodeデータベースをホストしているサーバープールではこの問題は解消 ( または最小化 ) されますサーバープールには一連のユーザー設定プロパティが含まれており Oracle Clusterwareが実施する配置とフェイルオーバープロセスを制御します最小 (MIN) プロパティは最小サーバー数を指定するプロパティでありワークロードの可用性要件を満たすレベルに設定する必要があります図 2では frontofficeプールとbackofficeプールの両方でこの値に2が設定されています MIN 値を0に設定することも可能でありプール内で実行されるサーバーと関連サービスがゼロになるケースも容認可能であることを意味します最大 ( MAX) プロパティには最大割当て数を指定しこの値は常にMIN 値以上である必要があります図 2では MAX 値に2が設定されていますクラスタに1つのサーバープールしか含まれていないような特殊なケースでは最大数が現在のクラスタサイズになるように設定すると便利ですこれにはMAX=-1を設定します重要度 (IMP) 値はあまり明確なものではなく多面的な影響を及ぼす可能性があります表面上はプール間での相対的な可用性の重要度をOracle Clusterwareに対して指定する 0から1000の間の値であり値が高いほど重要度も高くなりますしかしその影響によって起動とフェイルオーバーの動作が左右されますこれについてはこのユースケースと後続のユースケースを見ると分かりやすいでしょう図 2では frontofficeプールでimp=10が backofficeプールでimp=5が設定されていますつまり frontofficeプールの方が高い重要度を持ちます重要度は単純な > チェックまたは < チェックで評価されるため数値や差異の大きさは関係ないことに注意してください 4

もっとも高い重要度を持つプールを探します図 2ではfrontofficeプールがこれにあたりますしたがって

6 図 2:SRVCTL サーバープールの構成プロパティこのクラスタの起動時にサーバーが1つずつ追加されますサーバープールへ配置する必要があるとき Clusterwareは最小サーバー数には達していないもっとも高い重要度を持つプールを探します図 2ではfrontofficeプールがこれにあたりますしたがって最初のサーバーの配置が保証され crmsvcプールに割り当てられたすべての自動開始サービスにより関連データベースインスタンスが起動されます図 3: サービスとインスタンスの起動順序 5

ユースケース2: 改善されたHAフェイルオーバー戦略起動順序を補完するユースケースになるのはフェイルオーバー動作の管理です 11g Release 2より前のRACクラスタでは優先インスタンスと使用可能インスタンスを使用するように指定されたサーバーおよびサービスにデータベースが接続されておりノード障害が発生するとワークロードが同じ場所に配置されるか

7 ユースケース2: 改善されたHAフェイルオーバー戦略起動順序を補完するユースケースになるのはフェイルオーバー動作の管理です 11g Release 2より前のRACクラスタでは優先インスタンスと使用可能インスタンスを使用するように指定されたサーバーおよびサービスにデータベースが接続されておりノード障害が発生するとワークロードが同じ場所に配置されるかまたは既存の優先インスタンスにオーバーロードされる場合があるため連鎖的な障害につながっていましたその結果ワークロードとデータベースが非常に多数の2 ノードクラスタにデプロイされるかまたは障害に対応するために多大な余裕が残されていましたポリシー管理データベースとサーバープールは登録されたサーバープールの外部でワークロードを混在させることなくワークロードの代わりにサーバーを移動して障害に対処することでこの問題を回避しますこの新しいフェイルオーバー戦略の実装では MINプロパティとIMPプロパティを使用して必要な動作を指定します図 3に示した例に戻ると dasherノードの障害によってすべての処理がvixenに移行するのではなく重要度の低いbackofficeサーバープール内のいずれかのサーバーがインスタンスのトランザクション処理を停止して hrsvcサービスのワークロードを徐々に減らしてfrontoffice プールに " 移行 " することで crmsrvサービスとそのインスタンスを起動しますこれを図解した図 4 では dancerがbackofficeからfrontofficeへと移行しています図 4: 新しいフェイルオーバーポリシーに基づく動作 6

8 フェイルオーバーの動作は HAイベントの結果としてサーバープールプロパティを再評価する Oracle Clusterwareによって決定されますこのケースでは frontofficeのサーバー数がmin 値の2を下回ったことが確認されこれを回復するために重要度の低いプールから1つのサーバーが移行されました反対に frontofficeのmin 値が1であった場合この状況では1つのサーバーで問題ないことがポリシーによって規定されているためサーバーの移行は発生しません再起動などにより dancerが再びクラスタに加わる際 frontofficeプールには戻らず backofficeプールに配置されて 2 つのサーバーというMIN 値を回復しますこの新しいフェイルオーバー戦略には2つのメリットがあります 1つ目は以前はデータベースとワークロードの混在を防止するために複数のデータベースを別々のクラスタに配置する必要がありましたが同じクラスタを共有できるようになります 2つ目は追加サーバーをアイドル状態や使用率の低い状態にすることなくよりビジネスクリティカルなワークロードのサポートに利用できるため高可用性が向上します 7

9 ユースケース3: 最後に残るサービスの管理ユースケース2を論理的に極限に近づけたものがユースケース3になりますこのユースケースはマルチノード障害またはスプリットブレインのクラスタ障害が発生した場合でも 1つ以上のサービスが常に使用可能となるようにしますビジネスクリティカルなサービスが管理者管理データベースに含まれる場合その存続を確実にするにはクラスタ内のすべてのノード上でサービスを実行できる必要がありますこれにはワークロードまたはデータベースの独立性を損なうというデメリットがありますサーバープール内でポリシー管理データベースを使用するとこのデメリットは生じません残ったサーバーが1つのみであってもサーバープールに含まれておりもっとも高い重要度を持っていれば Oracle Clusterwareによって登録済みのサービスとインスタンスの実行が継続されますこれを図解した図 5では dasherの障害後にdancerでも障害が発生していますこのため残っているbackofficeサーバーのcometはそのインスタンスを停止して frontofficeへ移行しますここで vixenとともにビジネスクリティカルなcrmsvcサービスを実行します図 5: ポリシーによる最終存続サービスの確保図 6でSRVCTLの出力に示すようにこの動作を可能にするのは最大のIMPプロパティを持つサーバープールに対して 0を上回るMINプロパティを指定することだけです 8

図 6:SRVCTL 構成とマルチノード障害後の出力ユースケース2と同様に dasherまたはdancerがクラスタに再び加わる際これらはbackofficeサーバープールに配置されますこれにより crmsvcサービスの中断が防止され hrsvcサービスとデータベースインスタンスが起動されますユースケース4: 動的なリソース

Cluaterware in 12cで導入されたOracle Quality of Service Managementが提供するとおりにクラスタに含まれるサーバープールのMINプロパティとMAXプロパティをポリシー内のグループとして設定しておくと QoS ManagementまたはSRVCTL 再配置サーバーコマンドを使用するか

10 図 6:SRVCTL 構成とマルチノード障害後の出力ユースケース2と同様に dasherまたはdancerがクラスタに再び加わる際これらはbackofficeサーバープールに配置されますこれにより crmsvcサービスの中断が防止され hrsvcサービスとデータベースインスタンスが起動されますユースケース4: 動的なリソースプロビジョニングユースケース3で説明したようにポリシー管理データベースとそのサービスをホストするサーバーはプール間で動的にオンライン移行できますこれは予期せぬトランザクション増加をもたらす可能性のあるイベントや一定の日数週数月数四半期数に基づいてワークロードが変化する HA 以外のケースで有効です 11g Release 2またはOracle Cluaterware in 12cで導入されたOracle Quality of Service Managementが提供するとおりにクラスタに含まれるサーバープールのMINプロパティとMAXプロパティをポリシー内のグループとして設定しておくと QoS ManagementまたはSRVCTL 再配置サーバーコマンドを使用するかあるいはSRVCTLでMINプロパティとMAXプロパティプロパティを手動変更することで計画的な需要変更を容易に予想し計画外の需要変更に対応できるようになります例に戻るとサーバープールプロパティを変更した計画変更または計画外変更に対して図 7ではSRVCTLコマンドを指定していますこのコマンドは frontofficeのサーバー数を3に増やしてから実際に変更を実施します図 7: 需要に応じた動的なサーバー割当て 9

11 再配置のコマンドラインで使用する fフラグはforce( 強制 ) を意味しており指定されたサーバーがデータベースインスタンスなどのリソースを実行している場合は移行とfrontofficeリソースの起動前にこれらを停止する必要がありますこれらのコマンドを実行すると図 7に示したとおりに手動で実行するか QoS Managementの推奨またはClusterwareポリシーを使用するかに関係なく結果のクラスタでfrontofficeサーバープールに追加のリソースが割り当てられ増加したcrmsvc サービスの需要をサポートできます ( 図 8を参照 ) 図 8: 需要に合わせた動的なサーバープールサイズ変更ポリシー管理型 RAC データベースとポリシーセットユースケース4ではポリシーの概念を紹介しましたサーバープールとポリシー管理データベースはより柔軟かつ動的で順序付けされたデプロイメントを可能にするためもっとも中断の少ないグループ化された方法で変更を可能にする機能を名前付きポリシーとして提供することは理にかなっていますこれらのポリシーの集合がポリシーセットになりますこの機能は11g Release 2で QoS Managementの機能として導入され 12cでは中心的なClusterware 機能にも適用されていますサーバープールプロパティをグループとして変更する機能を通じて Clusterwareは移行による中断が最小限になるように最適化しますこれを一度に1つのコマンドで実行しようとすると非常に困難です 10

12 ポリシーセットとそこに含まれるポリシーの作成および使用方法を理解するため次のユースケースについて考えてみましょうこのユースケースではバックアップサーバープールを使用してfrontofficeおよびbackofficeサーバープールが拡大されていますクラスタ内のサーバー数は変更されていませんがいつでもサーバープールを作成してそこにサーバーを登録できますサーバーがプール内に配置されるとサービスが自動的に開始されますこのケースでは平日夜の増分バックアップと週末の全体バックアップを実行する目的でバックアップサービスを作成します図 9に示すコマンドは新しいバックアップサーバープールを作成しますまた極めてビジネスクリティカルなワークロードであるため重要度が最高になるIMP=20を設定しますがサーバーの移行を避けるため当初の最小サーバー数はゼロ (MIN=0) に設定します図 9: バックアップサーバープールの作成このプールの作成に加えて Clusterware 12cの新しいサーバープールのカテゴリ機能を使用しますこの機能は異種サーバーから成るクラスタの管理を非常に容易にしますサーバーカテゴリを使用するとサーバー属性の指定をサーバープールメンバーシップ要件に含めることができますサーバーがクラスタに加わるタイミングで CPU 数 CPU 速度メモリなどの属性とユーザーラベルが評価されますこの例では cometとdancerのi/o 容量が大きいため次のコマンドをそれぞれのローカルで実行して IOplusというラベルを付けます [GRID]> crsctl set server label IOplus コマンドが完了してClusterwareスタックが再起動されたら次のコマンドで各サーバーの全属性のステータスを問い合わせます [GRID]> crsctl status server comet dancer f 出力結果は次のようになります 11

13 あとは moreioなどといった適切なサーバーカテゴリを作成しポリシーセットに組み込むだけです次にポリシーセットをシンプルなテキストファイルとして作成します次の形式では DayTime NightTime Weekendという3つのポリシーを指定しています 12

14 13

15 このポリシーは次の CRSCTL コマンド例を使用して Clusterware に送信されます [GRID]> crsctl modify policyset file /u01/app/ /policyset.txt コマンドが完了したら次のコマンドを使用し手動またはcronなどのジョブスケジューラ経由でポリシーをアクティブ化します [GRID]> crsctl modify policyset attr LAST_ACTIVATED_POLICY=Weekend 次に示すSRVCTLステータスコマンドを使用して結果を確認できます例に基づく結果を併記します 14

16 Weekendポリシーに対してこのサーバープールを再配置することでクラスタ全体に対する新しいサーバー構成が完全にオンラインで実行されます図 10に上記の結果のサービスおよびサーバープール構成を示します 15

図 10:Weekend ポリシーによるクラスタ構成サーバーカテゴリを使用することで cometまたはdancer 上でのみバックアップサービスが実行されるため望みどおりのリソース対タスクマッピングが実現されますポリシー管理データベース : マルチテナントRACデータベースのデフォルトのデプロイメント上記の3つの例で示したとおりポリシー管理型 RACデータベースのデプロイメントは

17 図 10:Weekend ポリシーによるクラスタ構成サーバーカテゴリを使用することで cometまたはdancer 上でのみバックアップサービスが実行されるため望みどおりのリソース対タスクマッピングが実現されますポリシー管理データベース : マルチテナントRACデータベースのデフォルトのデプロイメント上記の3つの例で示したとおりポリシー管理型 RACデータベースのデプロイメントはデータベースサービスの配置とHA 管理に関して豊富な機能を提供しますこれらの機能は新しいOracle 12c マルチテナントRACデータベースと複数のPDBをデプロイする際非常に効果的に利用できますポリシー管理データベースは複数のサーバープールにまたがって配置できここまでに例証したとおりプールの起動特性とフェイルオーバー特性に優先順位を付けることができますこのようなユースケースの1つを図 11に示しますここではサーバープロバイダがさまざまなサービスレベルと可用性条件の下で一連のアプリケーションをホストしています 16

需要に応じたジャストインタイムのサーバー割当てを実現できます複数のデータベースをPDBとしてマルチテナントRACデータベースに統合する際に望ましいその他の特性は同じハードウェア

18 図 11: ポリシー管理型マルチテナント RAC データベースのサービスレベル例 Gold Silver Bronzeの各サーバープールに対して適切なMIN MAX IMPプロパティを設定することでノード障害が発生した場合も効果的に可用性レベルとパフォーマンスレベルの両方を管理できます Goldレベルの顧客に最高の可用性を保証できるだけでなく RACデータベースフレームワークとサーバープール内の動的割当て機能によって需要に応じたジャストインタイムのサーバー割当てを実現できます複数のデータベースをPDBとしてマルチテナントRACデータベースに統合する際に望ましいその他の特性は同じハードウェアリソースの共有によって利益を得るデータベースをグループ化できる機能ですこの種の類似性は図 12に示すようにアプリケーションタイプやデータベースリンクの必要性使用する階層ハードウェアの違いなどに基づきます図 12: ポリシー管理型マルチテナント RAC データベースの PDB 類似例 17

19 この例では PDB をサーバープール内にデプロイすることで同じハードウェアリソースを共有しながら機能的な独立性を維持します次にビジネスの目標と要求を追跡するために各種ポリシーを使用してパフォーマンスと可用性の優先順位を調整できますポリシー管理型 RACデータベースに関する考慮事項とヒントデータベースのデプロイメントと管理に関するこの新しいパラダイムにはデプロイメントの新規作成と変換の両方の計画に関する多数の考慮事項とヒントがありますもっとも重要なのはこの機能と柔軟性を単純に採り入れるのではなくこれらを考慮に入れた計画を策定する必要があるという認識ですすでに説明したとおりノード障害によってサービスのフェイルオーバーが発生するケースとしないケースがありインスタンスとそのサービスが停止される場合もあります結果は完全に予測可能である一方でそれぞれのシナリオを入念に調査する必要があります CRSCTLコマンドとSRVCTLコマンドで使用できる新しいevalオプションはサーバープールプロパティが変更された場合やポリシーがアクティブ化された場合に起きる結果に関する詳細情報を提供します現在のWeekendポリシーを変更してDayTimeポリシーをアクティブ化する際の評価を次に示しますサーバーが固有のデータベースインスタンス以外もホストするようになりインスタンス固有のログファイルが別々のサーバー上に書き込まれる可能性があることで診断が若干難しくなりますこれらを考慮に入れることが将来的なリリースに対する優先事項ですデータベースインスタンスに関して言うとポリシー管理型 RACまたはRAC One Nodeデータベースには変更済みインスタンスのネーミング規則があるためカスタムスクリプトに影響がおよぶ可能性があります数値による単純な接尾辞 (orcl1 orcl2など ) でインスタンスを識別する代わりに追加のアンダースコアが挿入されます (orcl_1 orcl_2など ) サーバープールの拡張時に新しいインスタンスが作成されると RACデータベースのコードはこのインジケータを使用して新しい UNDO 表領域をセルフプロビジョニングしますサーバープールの使用によって新規インスタンスが動的に作成されることがない場合は SRVCTLを使用してインスタンスごとに元の名前に戻すことができます 18

20 Oracle Data Guard Brokerを使用する場合は注意する必要がありますまた新規インスタンスを作成する際にスタンバイREDOログスレッドが作成されませんすべてのインスタンス対ノードマッピングに対してこれらを事前に作成しインスタンスがどこで実行されてもログが使用できるようにしておく必要があります RMANを使用する既存のバックアップ構成も再検討する必要があります RMANチャネル用のサービスを使用したロードバランシングはしばらく前からのベストプラクティスになっていますがチャネルがインスタンス名にマッピングされている場合次の例に従い新しいネーミング規則に合わせて更新する必要があります CONFIGURE CHANNEL DEVICE TYPE sbt CONNECT CONFIGURE CHANNEL DEVICE TYPE sbt CONNECT ポリシー管理型 RACデータベースはOracle GoldenGateの使用にも影響を及ぼします変換時にデータベースインスタンスを追加した後で Extractプロセスでの手動介入が必要になります Extractグループを手動で削除して更新するまで追加インスタンスはグループに追加されません HAイベントの発生時にもサーバーが移行されるため GoldenGateのExtractおよびReplicatプロセスで同様に対応する必要がありますそのためには OTNからダウンロードできるClusterwareバンドルエージェントをデプロイします結論および詳細情報データセンターを拡張するコストなしで増加する需要に対応するために統合とオンデマンドプロビジョニングのDBaaSを求める声によって新しいインフラストラクチャ機能と管理パラダイムがもたらされましたこのパラダイムは柔軟なリソース割当てを可能にしながら稼働時と障害時に予測可能な動作を実現しますこのような変更には習熟期間が必要ですが代表的なエンタープライズ Oracle RACデータベーステクノロジーを使用すると新しい仮想アーキテクチャに変換することなくベアメタルリソースにこの種のデプロイメントを実装できますこれにより社内のオラクル専門知識を活用しながら将来的にパフォーマンスと管理性のメリットが得られますポリシー管理型 RACデータベース Clusterwareポリシーサーバープール QoS Managementについて詳しくは以下のリンク先を参照してくださいポリシー管理データベースへの変換についてはこちらを参照してください変換後のEMCAの使用についてはこちらを参照してください 19

21 Oracle Database 12c: ポリシー管理型 Oracle RACデータベースの推奨理由と使用方法 2014 年 1 月著者 :Oracle Corporation Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. 海外からのお問い合わせ窓口 : 電話 : ファクシミリ : Copyright 2014, Oracle and/or its affiliates.all rights reserved. 本文書は情報提供のみを目的として提供されておりここに記載されている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述による明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によって直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることなくいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません OracleおよびJavaはOracleおよびその子会社関連会社の登録商標ですその他の名称はそれぞれの会社の商標です IntelおよびIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARC 商標はライセンスに基づいて使用されるSPARC International, Inc. の商標または登録商標です AMD Opteron AMDロゴおよびAMD Opteronロゴは Advanced Micro Devicesの商標または登録商標です UNIXは The Open Groupの登録商標です 0113 oracle.com

Microsoft Windows向けOracle Database 12cでのOracleホーム・ユーザーの導入

Microsoft Windows向けOracle Database 12cでのOracleホーム・ユーザーの導入 Oracle ホワイトペーパー 2013 年 7 月 Microsoft Windows 向け Oracle Database 12c での Oracle ホームユーザーの導入はじめに Oracle Database 12c Release 1(12.1) 以降では Microsoft Windows 上のOracle Databaseでインストール時に指定したOracleホームユーザーの使用がサポートされています