Oracle Exadata Database Machine 12cリリース1 (12.1.2.2.0)の新機能

スマートFusionブロック転送

最小ソフトウェア要件: 12.1.0.2 BP13

多くのOLTPワークロードでは、Oracle Real Application Clusters (Oracle RAC)の複数のノードで頻繁に更新する必要があるホット・ブロックが発生することがあります。その一例がRight Growing Index (RGI)で、新しい行が複数のOracle RACノードからの索引付きで表に追加されます。索引のリーフ・ブロックが、すべてのノードで頻繁に更新する必要があるホット・ブロックになります。

Oracle Exadata Database MachineのスマートFusionブロック転送機能がない場合、送信側ノードがREDOログで恒久的なREDOログ・バッファに変更を加えた後にのみ、ホット・ブロックを送信側ノードから受信側ノードに転送できます。スマートFusionブロック転送により、送信側ノードでの、このREDOログ書込みの待ち時間は解消されます。ブロックは、REDOログへのIOが送信側ノードで発行されると、その完了を待たずにただちに転送されます。スマートFusionブロック転送により、RGIワークロードのスループットが増加し(約40%増)、レスポンス時間が短縮されます(約33%減)。

スマートFusionブロック転送を有効にするには:

すべてのOracle RACノードで、非表示の静的パラメータ_cache_fusion_pipelined_updatesをTRUEに設定します。これは静的パラメータであるため、この変更を反映させるにはデータベースを再起動する必要があります。
すべてのOracle RACインスタンスで、exafusion_enabledパラメータを1に設定します。

注意:

Oracle Exadata Database Machine初期化パラメータexafusion_enabledは、Oracle Database 19cでサポートが終了しました。

8TBのハード・ディスクのサポート

このソフトウェア・リリースで、Exadata Storage Serverは、8TBの大容量ディスクをサポートします。8TBの大容量ディスクのサポートには、次の利点があります。

以前のExadataマシンのディスク容量を2倍にします(ラックごとに最大1344TB)
既存のデータベースおよびデータ・ウェアハウスをスケール・アウトする追加の記憶域を提供します。

8TBの大容量ディスクを使用する要件

Exadata 12.1.2.1.2以上
グリッド・インフラストラクチャ・ホームには、次のいずれかが必要です。
- 12.1.0.2.11以上のBP
- 12.1.0.2.10以下のBPと次のパッチ: 21281532、21099555および20904530
- 11.2.0.4.18以上のBP
- 11.2.0.4.17以下のBPとパッチ21099555
- 11.2.0.3とパッチ21099555

IPv6のサポート

IPv6サポートはイーサネット向けです。

計算ノードとストレージ・サーバーでは、管理ネットワーク、ILOMおよびクライアント・アクセス・ネットワークでPv6を使用できるようになりました。これは、ベア・メタルおよび仮想化の両方のデプロイメントで有効です。次の表に、各種コンポーネントによるIPv6サポートの方法を示します。

コンポーネント	IPv6サポートの説明
Oracle Exadata Deployment Assistant (OEDA)	OEDAでは、ユーザーが顧客ネットワークの定義画面(図-8のスクリーンショットを参照)でIPv6アドレスを入力できます。IPv6アドレスが管理ネットワークで使用されている場合、DNSサーバー、NTPサーバー、SMTPサーバーおよびSNMPサーバーがIPv6ネットワーク上に配置されている必要があります。顧客ネットワークの定義画面でIPv6アドレスを使用してゲートウェイを指定し、/64接尾辞を指定してマスクを表すと、「サブネット・マスク」フィールドがグレー表示されて使用できなくなります。
Ciscoスイッチ	Cisco 4948E-Fスイッチの最小ファームウェア・バージョン15.2(3)E2を使用すれば、CiscoスイッチでIPv6アドレスを有効にできます。アップグレード手順と、SRを開いて最新のCiscoファームウェアをOracleサポートから入手する方法は、My Oracle Supportノート1415044.1を参照してください。
自動サービス・リクエスト(ASR)	ASRはIPv6アドレスでは機能しません。これは今後のリリースで対応します。ASRを有効にするには、IPv4ネットワークにブリッジします。
Enterprise Manager	Enterprise ManagerでInfiniBandスイッチ(IPv4ネットワーク上)と計算ノードやストレージ・ノード(IPv6ネットワーク上)の両方を監視できるようにするには、Enterprise Managerをブリッジ・ネットワーク上に配置する必要があります。
dbnodeupdate	dbnodeupdateには、IPv6アドレスが設定されたマシン上でホストされているリモート・リポジトリが必要です。あるいはISOファイルが使用されている必要があります。リモート・リポジトリでIPv4を使用し、ホストにIPv6 IPのみが設定されている場合、(httpなどのプロトコルを使用して)リモート・リポジトリにアクセスすることはできません。ただし、ネットワーク・ルーターやデバイスで許可されていれば、顧客のIPv6ホストからIPv4 IPにアクセスできる場合があります。ほとんどの顧客がIPv6リポジトリ・サーバーを必要とするか、ISOファイルを使用することになります。
InfiniBandネットワーク	引き続きIPv4のみを使用するには、プライベートInfiniBandネットワークが必要です。InfiniBandネットワークではプライベート・アドレスのみが使用されるので、InfiniBandをIPv6に移行するメリットはほとんどありません。
SMTPとSNMP	顧客ネットワークにIPv4とIPv6間のルーティングを行うブリッジまたはゲートウェイがない場合、SMTPサーバーとSNMPサーバーは通常、IPv6 (またはIPv6 IPアドレスに解決される名前)になります。
Platinum Support	今後のPlatinum Gatewayソフトウェア・リリースが提供されるまで、Platinum SupportはIPv6デプロイメントでは使用できません。

図-8 Oracle Exadata Deployment Assistantの顧客ネットワークの定義画面

「図-8 Oracle Exadata Deployment Assistantの顧客ネットワークの定義画面」の説明

関連トピック

My Oracle Supportノート1415044.1

計算ノードからのCellCLIコマンドの実行

新しいExaCLIユーティリティでは、データベース・サーバーからCellCLIコマンドをストレージ・サーバーに対してリモート実行できます。これは、SSHアクセスを無効にしてストレージ・サーバーをロックした場合に役立ちます(ストレージ・サーバーでのSSHの無効化を参照)。

ExaCLIには、ストレージ・サーバーの管理に対応した使いやすいインタフェースも用意され、ストレージ・ユーザーの各種ロールをストレージ管理者から分離できます。

ExaCLIを実行するには、ストレージ・サーバー上でユーザーを作成し、そのユーザーにロールを付与する必要があります。ロールを付与するとユーザーに権限が割り当てられ、ユーザーの実行可能なCellCLIコマンドが指定されます。ストレージ・サーバーへの接続時に、ExaCLIは指定されたユーザー名を認証し、そのユーザーに指定されたコマンドを実行するための適切な権限があるかどうかを確認します。

新しいexadcliユーティリティはdcliユーティリティに似ています。exadcliを使用すると、複数のストレージ・サーバーにまたがってCellCLIコマンドを実行できます。

詳細は、次を参照してください。

Oracle Exadata Database Machineメンテナンス・ガイドのExaCLIユーティリティの使用
Oracle Exadata System Softwareユーザーズ・ガイドのexadcliユーティリティの使用

ロールに権限を付与し、ユーザーにロールを付与することで、ユーザーが実行できるコマンドを制御できます。たとえば、ユーザーにLIST GRIDDISKコマンドを実行可能にしALTER GRIDDISKを実行不可にするよう指定できます。このレベルの制御は、システムへの完全なアクセスをごく少数のユーザーにのみ許可するOracle Cloud環境で役立ちます。

新しいExaCLIユーティリティを使用する場合は、ユーザーの作成も必要です。CREATE USER、GRANT PRIVILEGEおよびGRANT ROLEコマンドを使用して、ユーザーの作成、ロールへの権限の指定、およびユーザーへのロールの付与を行います。詳細は、Oracle Exadata System Softwareユーザーズ・ガイドのユーザーおよびロールの作成を参照してください。

ストレージ・サーバーでのSSHの無効化

デフォルトでは、ストレージ・サーバーでSSHが有効化されています。必要な場合は、ストレージ・サーバーをロックしてSSHアクセスを無効化できます。ExaCLIを使用すれば、引き続きセル上で各種操作を実行できます。ExaCLIは計算ノード上で実行され、httpsやREST APIを使用して、セル上で実行されているWebサービスと通信します。

セルへのログインを必要とする操作を実行するときは、一時的にセルのロックを解除できます。操作が完了したら、再びセルをロックできます。

詳細は、Oracle Exadata System Softwareユーザーズ・ガイドのストレージ・サーバーでのSSHの無効化を参照してください。

フラッシュ・キャッシュ内でのデータベースへの割当ての固定

ALTER IORMPLANコマンドにはflashcachesizeと呼ばれる新しい属性が用意され、これによりフラッシュ・キャッシュ内の固定領域をデータベースに割り当てることができます。flashcachesizeに指定された値は強い制限であり、この指定値を超える領域をデータベースで使用することはできません。これは、弱い上限のflashcachelimit値とは異なります(フラッシュ・キャッシュがいっぱいでなければ、データベースはこのflashcachelimit値を超過できます)。

flashcachesizeは、クラウドや従量課金制などのデプロイメントでデータベースをそれぞれの割当て済領域に制限する必要がある環境において理想的です。

詳細は、次の項を参照してください。

Oracle Exadata System Softwareユーザーズ・ガイドのI/Oリソースの管理
Oracle Exadata System Softwareユーザーズ・ガイドのALTER IORMPLANコマンド

AWRレポートのOracle Exadata Storage統計情報

AWRレポートのExadataフラッシュ・キャッシュ・パフォーマンス統計情報セクションが、次のように強化されました。

列フラッシュ・キャッシュとKEEPキャッシュのサポートの追加。
Exadataストレージ・セルの統計情報とデータベースの統計情報が要約されたフラッシュ・キャッシュ・パフォーマンス・サマリーに関するセクションの追加。

AWRレポートのExadataフラッシュ・ログ統計情報セクションに、ディスクおよびフラッシュへの最初の書込みの統計情報が含まれるようになりました。

最小ソフトウェア: Oracle Databaseリリース12.1.0.2バンドル・パッチ11

最大データベース・プロセス数の増加

最小ソフトウェア要件: 12.1.0.2 BP11または11.2.0.4 BP18

次の表に、データベース・ノード当たりサポートされる最大データベース・プロセス数を示します。これらの数は以前のリリースよりも高くなっています。ベスト・プラクティスは、プロセス数をこれらの値よりも低く抑えることです。ワークロードのサブセットがパラレル問合せを実行中の場合、最大データベース・プロセス数はパラレル問合せを含まないプロセス数列と実行中のすべてのパラレル問合せを含むプロセス数列の間になります。

表-46 ノード当たりの最大データベース・プロセス数

マシン・タイプ	InfiniBandボンディング・タイプ	パラレル問合せを含まないプロセスの最大数	実行中のすべてのパラレル問合せを含むプロセスの最大数
8ソケット(X2-8、X3-8)	アクティブ・パッシブ	28,500	25,000
8ソケット(X4-8、X5-8)	アクティブ・ボンディング	50,000	44,000
2ソケット(X2-2、X3-2)	アクティブ・パッシブ	12,500	10,000
2ソケット(X4-2、X5-2)	アクティブ・ボンディング	16,500	14,000

マシンは次のように構成されます。

アクティブ・ボンディングInfiniBand構成の8ソケット・データベース・ノード(X4-8およびX5-8)では、4枚のInfiniBandカード(8個のInfinibandポート)全体で8個のIPアドレスがあります。
アクティブ-パッシブInfiniBand構成の8ソケット・データベース・ノード(X2-8およびX3-8)では、4枚のInfiniBandカード(8個のInfinibandポート)全体で4個のIPアドレスがあります。
アクティブ・ボンディングInfiniBand構成の2ソケット・データベース・ノード(X4-2およびX5-2)では、1枚のInfiniBandカード(2個のInfinibandポート)上に2個のIPアドレスがあります。
アクティブ-パッシブInfiniBand構成の2ソケット・データベース・ノード(X2-2およびX3-2)では、1枚のInfiniBandカード(2個のInfinibandポート)上に1個のIPアドレスがあります。

データベースの使用に対して、IP当たり50,000 RDSソケットがプロビジョニングされます。IO対応の各データベース・プロセスは、複数のIPにまたがり均等なロード・バランスでRDSソケットを消費します。

セルには次の接続制限があります。

X4およびX5システムの場合、セルの接続制限は120,000プロセスです。
X2およびX3システムの場合、セルの接続制限は60,000プロセスです。

つまり、データベース・プロセスの合計数が前述のセル・ノードに対する制限を超えることはできません。たとえば、フル・ラックの8個のデータベースが最大プロセス数で実行されると、セルの接続制限を超過します。

関連トピック

Exadataセルの接続制限の向上

ストレージ・サーバー・アラートのカスタム診断パッケージ

Oracle Exadata Storage Serverは、セル・アラートが生成されると、カスタマイズされた診断パッケージ(関連するログおよびトレースを含む)を自動的に収集します。これは、ハードウェア・アラートとソフトウェア・アラートの両方を含むすべてのセル・アラートに適用されます。診断情報を適切なタイミングで収集することにより、重要なログのロールオーバーが抑制されます。

管理サーバー(MS)は、電子メール・アラートごとに電子メール添付ファイルとして診断パッケージを送信します。次のURLにアクセスして、既存の診断パッケージをダウンロードすることも可能です(電子メールの添付ファイルがなかった場合)。次のURLで、hostnameはセルのホスト名のことです。

https://hostname/diagpack

ExaCLIを使用してパッケージをダウンロードすることもできます。

ユーザーは、新しいCREATE DIAGPACK CellCLIコマンドを使用して開始時間と期間を指定することにより、カスタム診断パッケージを毎時作成できます。

詳細は、Oracle Exadata System Softwareユーザーズ・ガイドのCREATE DIAGPACKを参照してください。

patchmgrを使用したノードの更新

Exadataリリース12.1.2.2.0以降では、patchmgrを使用してOracle Exadataデータベース・ノード(リリース11.2.2.4.2以降)、Oracle Exadata仮想サーバー・ノード(dom0)およびOracle Exadata仮想マシン(domU)を更新、ロールバックおよびバックアップできます。スタンドアロン・モードでdbnodeupdate.shを実行することもできますが、patchmgrを使用すると、単一コマンドの実行で複数のノードを更新でき、各ノードで個別にdbnodeupdate.shを実行する必要はありません。patchmgrでは、ローリングまたは非ローリング方式でノードを更新できます。

更新されたpatchmgrとdbnodeupdate.shは、My Oracle Supportノート1553103.1からダウンロードできる、新しいdbserver.patch.zipファイルで利用できます。

詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』のpatchmgrによるデータベース・ノードの更新に関する項を参照してください。

関連トピック

My Oracle Supportノート1553103.1

8ソケット・データベース・ノードで機能するkdump

12.1.2.2.0より前のリリースでは、kdump (カーネル・クラッシュ・ダンプを作成して格納するサービス)は、vmcoreの生成に時間がかかりすぎ、領域の消費量も多すぎることから、Exadata 8ソケット・データベース・ノードで無効化されていました。Exadataリリース12.1.2.2.0以上では、次の最適化によって、kdumpは8ソケット・データベース・ノードで完全に機能します。

共有メモリーのHugepagesや他の複数の領域がLinuxカーネルによってユーザー・スペースに公開され、カーネル・クラッシュ時にはmakedumpfileによって除外されるようになりました。これにより、vmcoreの時間と領域の両方が節約されます。
kexecカーネルのメモリー構成が最適化されました。
不要なモジュールのブラックリスト化により、全体的な使用済メモリーが削減されました。
Snappy圧縮がデータベース・ノード上で有効化され、vmcoreの生成が高速化されています。

ストレージ・サーバーの電源切断時の冗長性チェック

前面の電源ボタンを押すか、ILOMを実行してストレージ・サーバーの正常な停止を試みると、ストレージ・サーバーはASMデータの冗長性チェックを実施します。ストレージ・サーバーを停止すると、データの冗長性が低下して、ASMディスク・グループの強制ディスマウントが生じる可能性がある場合は、停止が中止され、ストレージ・サーバーの停止は安全でないことをユーザーに警告するために、次のようにLEDが点滅します。

大容量セルでは、すべてのハード・ドライブ上のすべての3つのLEDが10秒間点滅します。
エクストリーム・フラッシュ・セルでは、取外しOKの青色のLEDが10秒間点滅し、オレンジ色のLEDが点灯します。

ストレージ・サーバーではハード・リセットを実行しないでください。

冗長性の低下により、ストレージ・サーバーを安全に停止できない場合(コマンド"cellcli -e list griddisk attributes name, deactivationOutcome"を実行すると、オフライン・ディスクと異常なディスクがすべて表示されます)、先にデータ冗長性をリストアする必要があります。オフライン・ディスクが他にある場合は、そのディスクをオンラインに戻して再同期が終了するのを待機します。障害ディスクを強制削除するために実行中のリバランス、またはフラッシュ・キャッシュのエラーを書き戻した後でデータ・ブロックを復元するために実行中のミラー復元がある場合、リバランスまたはミラー復元が完了するまで待機する必要があります。データ冗長性がリストアされたら、ストレージ・サーバーの停止を続行できます。

SNMPトラップ用IPアドレスの指定

eth0に関連付けられているIPアドレスがOracle ASR Managerに登録されていない場合、ALTER CELLコマンド(ストレージ・サーバーの場合)またはALTER DBSERVERコマンド(データベース・サーバーの場合)の新しいfromIPフィールドを使用して、別のIPアドレスを指定できます。

詳細は、次の説明を参照してください。

Oracle Exadata System Softwareユーザーズ・ガイドのALTER CELL
Oracle Exadata Database Machineメンテナンス・ガイドのALTER DBSERVER

逆オフロードの改良

最小ソフトウェア要件: 12.1.0.2 BP11

逆オフロード機能を使用すると、ストレージ・セルのCPUが飽和状態の場合、ストレージ・セルにオフロードされた作業の一部をデータベース・ノードに戻すことができます。

ストレージ・サーバーからデータベース・ノードへの逆オフロードは、Exadata環境で利用可能なすべてのデータベースCPUリソースとストレージCPUリソースの使用率をより均一にするためには欠かせません。ほとんどの構成で、ストレージCPUよりもデータベースCPUの方が多くなっており、その比率はハードウェアの世代およびデータベース・ノードとセル・ノードの数によって異なる場合があります。

同時実行中の異なる問合せを経過時間に関して適切に実行するには、それぞれに異なる逆オフロード率が必要です。別々のインスタンスで同じ問合せを実行中の場合でも、それぞれに異なる逆オフロード率が必要な場合があります。

このリリースでは、ヒューリスティックの改良が多数追加されており、複数のデータベース・インスタンスと異なる問合せのパラレル実行にかかる経過時間が最大で15%向上しています。

セルからセルへのリバランスにおけるフラッシュ・キャッシュ移入の保持

最小ソフトウェア要件: 12.1.0.2 BP11

ハードディスクで予測される障害またはtrue障害が発生し、データをリバランスして障害から回復する必要がある場合に、このハードディスク上のデータの一部が、データへのレイテンシ・アクセスと帯域幅アクセスを向上させるために、フラッシュ・ディスクにキャッシュされていていることがあります。アプリケーションの現在のパフォーマンスSLAを維持するには、セルからセルへのオフロードによるリバランス時に、ハードディスク上の異なるリージョンのキャッシュ・ステータスを保持したまま、データをリバランスすることが重要です。

この機能により、ディスク障害またはディスク交換に伴うリバランス時のアプリケーションのパフォーマンスが以前のリリースと比較して大幅に向上します。

データが1つのセルから別のセルにリバランスされると、ソース・セルでキャッシュされていたデータはターゲット・セルでもキャッシュされます。