1. システム概要
  2. Oracle Exadata Database Machineの新機能
  3. Oracle Exadata Database Machine 12cリリース1 (12.1.2.3.0)の新機能

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

Oracle Exadata Database Machine 12cリリース1 (12.1.2.3.0)の新機能は次のとおりです。

Oracle Exadata System Softwareの更新のパフォーマンス向上

Oracle Exadata System Softwareの更新に要する時間が大幅に短縮されました。内部処理をさらに最適化することで、セル更新プロセスが以前のリリースに比べて最大2.5倍高速化されました。

クォーラム・ディスク・マネージャ・ユーティリティ

以前のリリースでは、ストレージ・サーバーが5台未満のOracle Exadataシステムが高冗長性(HIGH)でデプロイされる場合、クラスタの投票ディスクは標準冗長性(NORMAL)を持つディスク・グループで作成されていました。こうしたシステムで2つのセルが停止した場合、高冗長性(HIGH)によってデータは引き続き保持されますが、投票ディスクは標準冗長性(NORMAL)を持つディスク・グループにあるため、クラスタ・ソフトウェアは停止します。

定数ディスクにより、ユーザーはデータベース・サーバー上にディスクをデプロイして利用し、クォータ・ラックまたは小規模構成で最高の冗長性を実現することができます。定数ディスクはデータベース・サーバー上に作成され、定数障害グループに追加されます。

高冗長性(HIGH)で構成する新規システムのストレージ・サーバーが5台未満の場合、Oracle Exadata Deployment Assistantを使用してこのような定数ディスクを自動的に作成できます。

こうしたシステムをデプロイする際、新しいquorumdiskmgrユーティリティを手動で使用できます。quorumdiskmgrによって、データベース・サーバー上の定数ディスクを管理できます。このユーティリティを使用して、定数ディスク構成、ターゲットおよびデバイスを作成、リスト、削除および変更できます。

詳細は、Oracle Exadata Database Machineメンテナンス・ガイドの高冗長性ディスク・グループのための定数ディスクの管理に関する項を参照してください。

必要な最小ソフトウェア:

  • Oracle Exadata Storage Server Softwareリリース12.1.2.3.0

  • Grid Infrastructureリリース12.1.0.2.160119(パッチ22722476および22682752を適用)またはGrid Infrastructureリリース12.1.0.2.160419以降

  • すべてのデータベース・ホームにパッチ23200778を適用

VLANサポート

OEDAでは現在、管理ネットワーク、ILOM、クライアントおよびバックアップ・アクセス・ネットワークのために、計算ノードおよびストレージ・サーバーでのVLANの作成をサポートしています。次の点に注意してください。

  • クライアント・ネットワークとバックアップVLANネットワーク・ネットワークが結合されている必要があります。管理ネットワークは結合しないでください。

  • バックアップ・ネットワークが、タグ付けされたVLANネットワーク上にある場合、クラスタ・ネットワークは、タグ付けされた異なるVLANネットワークにある必要があります。

  • バックアップおよびクライアント・ネットワークは、同一のネットワーク・ケーブルを共有できます。

  • OEDAは物理デプロイメントと仮想デプロイメントの両方でVLANタグ付けをサポートしています。

  • IPv6 VLANは、X2およびV2システムを除くすべてのOracle Exadataシステムのベア・メタルでサポートされています。

    現在、VMを使用したIPv6 VLANはサポートされていません。

注意:

システムがクラスタで10個のVIPアドレスを超えて使用し、Oracle Clusterwareクライアント・ネットワークにVLANを構成している場合、3桁のVLAN IDを使用する必要があります。VLAN名が15文字のオペレーティング・システム・インタフェースの名前制限を超える可能性があるため、4桁のVLAN IDを使用しないでください。

次の表に、管理ネットワーク、クライアント・ネットワークおよびバックアップ・ネットワークでの様々なExadataシステムおよびOracle Databaseバージョン向けのIPv4およびIPv6サポートを示します。

Oracle Databaseのリリース 管理ネットワークでのVLANタグ付け クライアントおよびバックアップ・ネットワーク

11.2.0.4

2ソケット・サーバー用のX3-2以上、および8ソケット・サーバー用のX4-8以上でのIPv4アドレスでのみサポートされています。

すべてのハードウェア・モデルでのIPv4およびIPv6でサポートされています。

12.1.0.2

2ソケット・サーバー用のX3-2以上、および8ソケット・サーバー用のX4-8以上でのIPv4アドレスでのみサポートされています。

すべてのハードウェア・モデルでのIPv4でサポートされています。

22289350が修正済であるすべてのハードウェア・モデルでのIPv6でサポートされています。

詳細は、『Oracle Exadata Database Machineインストレーションおよび構成ガイド』のOracle Exadata Database MachineでのネットワークVLANタグ付けの使用に関する項を参照してください。

適応性のある修正スケジュール

Oracle Exadata System Softwareは、ハード・ディスクがアイドル状態のときに定期的にハード・ディスクを自動で検査して修復します。修正のデフォルト・スケジュールは2週間置きです。

ただし、ハード・ディスクで不良セクターが発生し始めるようになったら、より多くの不良セクターが発生する可能性があるため、ディスクをもっと頻繁に修正することが推奨されます。リリース12.1.2.3.0では、現在の修正ジョブでハード・ディスクに不良セクターが検出された場合、Oracle Exadata System Softwareはそのディスクに対して1週間以内にフォローアップ修正ジョブをスケジュールします。そのディスクの修正ジョブで不良セクターが検出されなかった場合、hardDiskScrubInterval属性で指定された修正スケジュールに戻ります。

hardDiskScrubIntervalを週次以下に変更した場合、不良セクターが検出された場合でも、Oracle Exadata System Softwareは週次フォローアップ・スケジュールではなくユーザーが構成した間隔を使用します。修正の詳細は、Oracle Exadata System Softwareユーザーズ・ガイドのALTER CELLを参照してください。

必要な最小ソフトウェア:

  • Oracle Exadata System Softwareリリース12.1.2.3.0

  • Grid Infrastructureホーム:

    • 11.2.0.4.16 (2015年4月)以上

    • 12.1.0.2.4 (2015年1月)以上

ASRマネージャでのIPv6サポート

IPv6を使用するシステムで、ASR Manager 5.4を使用してAuto Service Request (ASR)に接続できるようになりました。

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

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

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

マシン・タイプ InfiniBandボンディング・タイプ パラレル問合せを含まないプロセスの最大数 実行中のすべてのパラレル問合せを含むプロセスの最大数

8ソケット(X2-8、X3-8)

アクティブ・パッシブ

28,500

25,000

8ソケット(X4-8、X5-8)

アクティブ・ボンディング

100,000

44,000

2ソケット(X2-2、X3-2)

アクティブ・パッシブ

12,500

10,000

2ソケット(X4-2、X5-2、X6-2)

アクティブ・ボンディング

25,000

14,000

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

表-45 Oracle VMユーザー・ドメイン当たりの最大データベース・プロセス数

マシン・タイプ InfiniBandボンディング・タイプ パラレル問合せを含まないプロセスの最大数 実行中のすべてのパラレル問合せを含むプロセスの最大数

2ソケット(X2-2、X3-2)

アクティブ・パッシブ

11,500

8,000

2ソケット(X4-2、X5-2、X6-2)

アクティブ・ボンディング

23,000

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およびX6-2)では、1つのInfiniBandカード(2つのInfinibandポート)上に2つのIPアドレスがあります。

  • アクティブ-パッシブInfiniBand構成の2ソケット・データベース・ノード(X2-2およびX3-2)では、1つのInfiniBandカード(2つのInfinibandポート)上に1つのIPアドレスがあります。

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

Exadata 12.1.2.3.0以降、セル側の接続制限はありません。

ExadataイメージとOracleカーネルによってサポートされる最大プロセス数のほかに、次の関連製品も拡張されました。

  • Oracle Exadata Deployment Assistantによって、デプロイ時にGrid_home/crs/install/s_crsconfig_nodenameenv.txtで自動的に上限が構成されます。

  • Exadata Patch Manager (patchmgrとdbnodeupdate.sh)によって、データベース・ノードのアップグレード時にGrid_home/crs/install/s_crsconfig_nodenameenv.txtで自動的に上限が構成されます。

最大プロセス数で最適なリソース使用率を実現するために、次のベスト・プラクティスに従う必要があります。

  • ローカルのBequeath接続を使用するのではなく、Exadataデータベースで実行されている一連のOracleリスナーを介して、アプリケーションが開始したOracleフォアグラウンドを確立する必要があります。

  • リスナー数はデータベース・ノードCPUソケット数と同じかそれ以上である必要があり、どのデータベース・ノードCPUソケットも同じ数のリスナーを実行する必要があります。たとえば、Oracle Exadata X5-8データベース・ノードでは8つのリスナーを構成できます(データベース・ノードCPUソケット当たり1つ)。

  • リスナーは、データベース・ノードCPUソケット間で均等にOracleプロセスを生成する必要があります。これは、起動時にこれらが実行されるソケットを指定することで実現できます。たとえば、リスナー0から7にlistener.oraファイルが適切に構成されていて、次のスクリプトを使用してX5-8データベース・ノードで8つのリスナーをそれぞれ別個のソケット上に生成するとします。 

    #!/bin/bash
export ORACLE_HOME=/u01/app/oracle/product/12.1.0.2/dbhome_1
for socket in `seq 0 7`
do
 numactl --cpunodebind=${socket} $ORACLE_HOME/bin/lsnrctl start LISTENER${socket}
done

  • リスナー接続レート・スロットルを使用してログイン・ストームを制御し、最大プロセス数でシステムの安定性を実現します。

  • 過度のクライアント接続タイムアウトおよびサーバー側のエラーを防止するために、1秒当たりに確立される接続数合計、すなわちすべてのリスナーのrate_limitの合計は400以下にする必要があります。

必要な最小ソフトウェア:

  • Oracle Exadata Storage Server Softwareリリース12.1.2.3.0

  • Oracle Database 12cリリース1 (12.1)リリース12.1.0.2.160119と次のパッチ: 22711561、22233968および22609314

セルからセルへのリバランスにおけるストレージ索引の保持

ストレージ索引を使用してスマート・スキャン時にI/Oをプルーニングすることで、パフォーマンスが著しく向上します。ディスクで予測障害または本当の障害が発生した場合、データを他のセルのディスクに移動してリバランスする必要があります。この機能により、失敗したディスクのデータ領域に作成されたストレージ索引エントリを、セルからセルへのオフロードによるリバランス時にデータとともに移動させて、アプリケーションのパフォーマンスを維持できます。

この機能により、前のリリースと比較して、ディスク障害によるリバランス時のアプリケーションのパフォーマンスが著しく向上します。

必要な最小ソフトウェア:

  • Oracle Exadata Storage Server Softwareリリース12.1.2.3.0

  • Grid Infrastructureリリース12.1.0.2.160119(パッチ22682752適用)

グリッド・ディスク・サイズを減少させる際のASMディスク・サイズのチェック

12.1.2.3.0より前のリリースでは、ディスク・グループの一部であるASMディスクのサイズを減少させる前に、ユーザーが誤ってグリッド・ディスクのサイズを減少させる可能性がありました。リリース12.1.2.3.0では、グリッド・ディスクのサイズをASMディスクより小さくできないように、サイズ変更の順序がチェックされます。

ASMディスク・サイズ問合せをサポートするために、新しい属性asmDiskSizeがグリッド・ディスクに追加されます。ALTER GRIDDISKを実行してグリッド・ディスクのサイズを変更する際、ユーザーがグリッド・ディスクをASMディスクより小さくしないように、コマンドによってASMディスク・サイズがチェックされるようになりました。

このチェックは、通常のデータ・ディスクとスパース・ディスクの両方に対して機能します。スパース・グリッド・ディスクの場合、仮想サイズの変更時にチェックが実行されます。通常のグリッド・ディスクの場合は、サイズの変更時にチェックが実行されます。

たとえば、次のコマンドを考えてみます。

CellCLI> list griddisk DATAC1_CD_00_adczarcel04 attributes name,asmdisksize

次のような出力が返されます。

DATAC1_CD_00_adczarcel04     14880M

グリッド・ディスクのサイズをASMディスクより小さくしようとした場合:

CellCLI> alter griddisk DATAC1_CD_00_adczarcel04 size=10G

コマンドによってエラーが返されます。

CELL-02894: Requested grid disk size is smaller than ASM disk size. Please resize ASM disk DATAC1_CD_00_ADCZARCEL04 first.

必要な最小ソフトウェア:

  • Oracle Exadata Storage Server Softwareリリース12.1.2.3.0

  • Grid Infrastructureリリース12.1.0.2.160119(パッチ22347483適用)

CREATE DIAGPACKでのアラートのサポート

CREATE DIAGPACKコマンドで、alertNameパラメータを使用して指定したアラートの診断パッケージの作成がサポートされるようになりました。

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