14 Oracle Exadata System Softwareリリース12.xの新機能

Oracle Exadata System Softwareリリース12.xの様々なバージョンにいくつかの新機能が導入されました。

14.1 Oracle Exadata Database Machine 12.2.1.1.0の新機能

Oracle Exadata Database Machine 12.2.1.1.0の新機能は次のとおりです。

14.1.1 ストレージ・サーバーでのインメモリー列指向キャッシング

Oracle Exadata System Softwareリリース12.2.1.1.0では、ストレージ・フラッシュ・キャッシュ内のデータに対して高速ベクトル処理インメモリー・アルゴリズムを使用できます。この機能は、Oracle Database In-Memory (Database In-Memory)オプションのライセンスを所有している場合に使用可能です。

Database In-Memory形式のキャッシュにより、純粋な列指向のExadata Hybrid Columnar Compression形式で提供される以上に、Database In-Memory形式で保持されるデータの量が大幅に増加し、Smart Scanパフォーマンスが大幅に向上します。

Oracle Exadata System Softwareリリース12.1.2.1.0では、フラッシュ・キャッシュに純粋な列指向のExadata Hybrid Columnar Compression形式で自動的にExadata Hybrid Columnar Compressionデータを格納する、列指向のキャッシュ形式が追加されました。このリリースでは、Exadata Hybrid Columnar Compressionデータのサポートが拡張され、キャッシュしたデータをDatabase In-Memory形式で再書込みすることや、超高速な単一命令複数データ(SIMD)の述語をSmart Scanで使用することができるようになりました。この形式では、結合や集計など、ほとんどのインメモリー・パフォーマンス拡張がSmart Scanでサポートされています。

標準表領域(暗号化されていない)および暗号化表領域からのデータを、インメモリー列指向キャッシュ形式でキャッシュできます。

Oracle Database In-Memoryを使用する場合と同様に、新しいDatabase In-Memory形式は、問合せのパフォーマンスに悪影響を及ぼさないようバックグラウンド・プロセスで作成されます。

この機能は、INMEMORY_SIZEデータベース初期化パラメータが構成されている場合はデフォルトで有効になっており、ユーザーがこの拡張機能を取得するために行う必要がある操作はありません。INMEMORY_SIZEの詳細は、『Oracle Databaseリファレンス』INMEMORY_CLAUSE_DEFAULTに関する項を参照してください。INMEMORY_SIZEが構成されていない場合は、12.1.2.1.0と同様のExadata Hybrid Columnar Compression形式の列指向キャッシュが以降も使用されます。

この機能を無効にする必要がある場合、ALTER TABLEコマンドとともに新しいDDLキーワードCELLMEMORYを使用できます。Oracle Exadata System Softwareユーザーズ・ガイドストレージ・サーバーでのインメモリー列指向キャッシングの有効化または無効化を参照してください。

最小要件:

  • Oracle Database 12cリリース1 (12.1.0.2) (必要な最小ソフトウェア・バージョンは12.1.0.2.161018DBBP)または
  • Oracle Database 12cリリース2 (12.2.0.1)
  • バグ24521608のパッチ

14.1.2 暗号化領域の列指向フラッシュ・キャッシュ

Oracle Exadata System Software 12.2.1.1.0では、列指向フラッシュ・キャッシュのサポートが暗号化表領域まで拡張されています。Oracle Database In-Memory (Database In-Memory)オプションのライセンスを所有している場合は、暗号化表領域データは、インメモリー列指向形式でストレージ・フラッシュ・キャッシュに格納されます。このオプションのライセンスがない場合、暗号化表領域データは、純粋な列指向Exadata Hybrid Columnar Compression形式でストレージ・サーバー・フラッシュ・キャッシュに格納されます。

最小要件:

  • Oracle Database 12cリリース1 (12.1.0.2) (必要な最小ソフトウェア・バージョンは12.1.0.2.161018DBBP)または

  • Oracle Database 12cリリース2 (12.2.0.1)

  • バグ24521608のパッチ

14.1.3 ストレージ索引でのセット・メンバーシップ

Oracle Exadata System Softwareリリース12.2.1.1.0では、インメモリー形式の列指向キャッシュを使用してデータが格納されている場合、Oracle Exadata Database Machineは、ディクショナリ・エンコーディングを使用して圧縮されたこれらの列を格納します。固有値が200個より少ない列の場合、ストレージ索引は、ディクショナリの非常にコンパクトなインメモリー表現を作成し、このコンパクトな表現を使用して等価条件に基づいてディスク読取りをフィルタ処理します。この機能は、セット・メンバーシップと呼ばれます。より制限されたフィルタ処理機能が、固有値400個まで拡張されています。

たとえば、ディスクの1リージョンで米国およびカナダの顧客のリストを保持しているとします。メキシコの顧客を検索する問合せを実行する場合は、Oracle Exadata Storage Serverで、新しいセット・メンバーシップ機能を使用して、メキシコからの顧客を含まないディスク・リージョンを除外することで、問合せのパフォーマンスを向上させることができます。セット・メンバーシップ機能がない、12.2.1.1.0より前のリリースのOracle Exadata System Softwareでは、通常のストレージ索引でこれらのディスク・リージョンをフィルタ処理できません。

最小要件:

  • Oracle Database 12cリリース1 (12.1.0.2) (必要な最小ソフトウェア・バージョンは12.1.0.2.161018DBBP)または

  • Oracle Database 12cリリース2 (12.2.0.1)

  • バグ24521608のパッチ

14.1.4 8列を超える列情報を格納するためのストレージ索引

12.2.1.1.0より前のリリースのOracle Exadata System Softwareでは、ストレージ索引で8列までの列情報を保持できます。Oracle Exadata System Softwareリリース12.2.1.1.0では、ストレージ索引が、24列までの列情報を格納するよう拡張されました。

8列の列情報を格納するための領域が保証されています。8列を超える場合、領域は、列のセット・メンバーシップ・サマリーと列の最小/最大サマリーとで共有されます。ワークロードのタイプによって、セット・メンバーシップ・サマリーがストレージ索引に格納されるかどうかが決定されます。

詳細は、ストレージ索引でのセット・メンバーシップを参照してください。

14.1.5 5倍高速なOracle Exadata System Softwareの更新

Oracle Exadata System Softwareの更新に要する時間がさらに短縮されました。Oracle Exadata System Softwareの更新処理が、12.1.2.3.0と比べて2倍、12.1.2.3.0より前のリリースと比べて5倍高速になりました。更新時間が短縮されることで、ソフトウェアの更新に必要なコストと労力が削減されます。

14.1.6 大量分析問合せおよび大量ロードのパフォーマンス高速化

大量の結合操作または集計操作がメモリーに適さず、ストレージにあふれさせる必要がある場合は、一時書込みおよび一時読取りを使用します。12.2.1.1.0より前のリリースのOracle Exadata System Softwareでは、一時書込みはフラッシュ・キャッシュでキャッシュされませんでした。一時書込みと後続の一時読取りは、どちらも、ハード・ディスクのみから行われていました。Oracle Exadata System Softwareリリース12.2.1.1.0では、一時書込みは、後続の一時読取りを同様にフラッシュ・キャッシュから実行できるよう、フラッシュ・キャッシュに送信されます。これにより、問合せが一時I/Oバウンドである場合に、一時にあふれる問合せが大幅に高速化されます。一定の問合せについて、パフォーマンスを最大で4倍高速化できます。これは、一時表領域全体をフラッシュに入れた場合に匹敵します。この機能を使用できるようにするためには、ライトバック・フラッシュ・キャッシュを有効にする必要があります。

Oracle Exadata System Softwareリリース12.2.1.1.0より前では、フラッシュ・キャッシュへの書込みにはサイズのしきい値がありました。128 KBを超えるほとんどの書込みは、ディスクに直接送られます。これは、これらの書込みがすぐに読み取られることが想定されていないためです。たとえば、直接ロード書込み、フラッシュバック・データベース書込み、アーカイブ済ログ書込みおよび増分バックアップ書込みは、フラッシュ・キャッシュを迂回します。Oracle Exadata System Softwareリリース12.2.1.1.0以降では、フラッシュ・キャッシュのアルゴリズムは、そのような大量の書込みによって優先度がより高いOLTPまたはスキャン・ワークロードが中断されない場合に、そのような大量の書込みをフラッシュ・キャッシュにリダイレクトするよう拡張されました。そのような書込みは、後でディスクがそれほどビジーでなくなったときにディスクにライトバックされます。この機能により、Oracle Exadata Storage Serverで、追加の予備フラッシュ容量およびI/O帯域幅を利用して全体的なパフォーマンスを向上させることができます。

この機能がV2およびX2ストレージ・サーバーを除くすべてのOracle Exadata Database Machineハードウェアでサポートされていることを覚えておいてください。X3およびX4ストレージ・サーバーでは、フラッシュ圧縮が有効になっている場合は、一時書込みおよび大量書込みのフラッシュ・キャッシングはサポートされません。

この機能に関連する新しい統計およびレポートに関するセクションが、12.1.0.2.0 2017年7月のDBBPおよび12.2.0.1.0 2017年10月のRURでも使用できるOracle Database 18c(18.1.0)自動ワークロード・リポジトリ(AWR)レポートに追加されました。

最小要件:

  • Oracle Exadata Database Machine X3-2以降

  • Oracle Exadata System Software 12.2.1.1.0

  • Oracle Database (次のいずれか):

    • Oracle Database 11gリリース2 (11.2) (バグ24944847の修正が適用済)

    • Oracle Database 12cリリース1 (12.1) — 12.1.0.2.0 2017年7月のDBBP

    • Oracle Database 12cリリース2 (12.2.0.1) — 12.2.0.1.0 2017年10月のRUR

    • Oracle Database 18c (18.1.0)

14.1.7 Secure Eraser

Oracle Exadata System Softwareリリース12.2.1.1.0以降には、Oracle Exadata Database Machine内のすべてのコンポーネントに対してセキュア・イレイザと呼ばれる安全な消去のソリューションが用意されています。これは、2ソケット・サーバーと8ソケット・サーバーの両方を含めた、V2以上のすべてのExadata Database Machinesに対応する包括的なソリューションです。

Oracle Exadata Database Machineの以前のバージョンでは、DROP CELL ERASEDROP CELLDISK ERASEDROP GRIDDISK ERASEなどのCellCLIコマンドを使用してユーザー・データを安全に消去できます。ただし、これらのDROPコマンドは、ハード・ドライブとフラッシュ・デバイスのユーザー・データにのみ対応しています。セキュア・イレイザは、ユーザー・データのみでなく、オペレーティング・システム、Oracle Exadata System Software、ユーザー構成を含むすべてのコンテンツをサニタイズします。さらに、セキュア・イレイザは、ハード・ドライブ、フラッシュ・デバイス、内部USB、ILOMを含む広範囲のハードウェア・コンポーネントに対応します。

セキュア・イレイザは、データベース・サーバーとストレージ・サーバーのすべてのデータを消去し、InfiniBandスイッチ、イーサネット・スイッチおよび配電ユニットを出荷時のデフォルトにリセットします。Oracle Exadataマシンの使用を廃止するか目的を再設定する場合に、この機能を使用できます。セキュア・イレイザは、マシンの各コンポーネント上のデータおよびメタデータのすべてのトレースを完全に消去します。

セキュア・イレイザ・ユーティリティの詳細は、Oracle Exadata Database Machineセキュリティ・ガイドを参照してください。

14.1.8 ASMスコープのセキュリティのセル間オフロード・サポート

セル間のオフロード操作を効率的に実行するには、ストレージ・サーバーが、データベース・サーバーを介するのではなく他のストレージ・サーバーに直接アクセスする必要があります。

ご使用のExadata環境でASMスコープのセキュリティを構成してある場合は、ストレージ・サーバーがそれ自体を他のストレージ・サーバーに対して認証して相互に直接通信できるようにするために、セル・キーを設定する必要があります。これは、Oracle ASMの再同期、復元、再構築およびリバランスの操作、およびデータベースの高スループット書込み操作に適用されます。

関連トピック

14.1.9 Oracle Exadata Database Machine X6-2データベース・サーバーへの他のネットワーク・カードの追加

Oracle Exadata Database Machine X6-2データベース・サーバーでは、マザーボードで可用性の高い10 Gbps銅線ネットワークが提供され、スロット2のPCIカードを介して10 Gbps光ネットワークが提供されます。

Oracle Exadata System Softwareリリース12.2.1.1.0以降は、さらに接続性が必要な場合は、イーサネット・カードを追加できます。追加のカードにより、デュアルポート10 GbE光接続性(部品番号X1109A-Z)またはデュアルポート10 GbE銅線接続性(部品番号7100488)のどちらかを提供できます。この部品は、Oracle Exadata Database Machine X6-2データベース・サーバー上のPCIeスロット1に取り付けることができます。

ネットワーク・カードを取り付けてネットワークに接続すると、Oracle Exadata System Softwareリリース12.2.1.1.0は、自動的にその新しいカードを認識してデータベース・サーバー上で2つのポートをeth6およびeth7インタフェースとして構成します。これらの追加ポートを、追加でクライアント・ネットワークを提供するためや、別にバックアップまたは障害回復ネットワークを作成するために使用できます。仮想マシンを実行するデータベース・サーバーでは、このネットワーク・カードを使用して、トラフィックを2つの仮想マシンから分離できます。

14.1.10 Oracle ASRの自動Diagpackアップロード

Oracle Exadata System Software リリース12.2.1.1.0では、管理サーバー(MS)は、Oracle ASR Managerと通信し、Oracle ASRに関する情報を含む診断パッケージを自動的にアップロードします。以前のリリースでは、自動サービス・リクエスト(SR)が開かれた後、他の診断情報を手動でアップロードする必要がありました。このステップを自動化することで、この機能は、Oracle ASRの応答時間を大幅に短縮します。

この機能は、2つの新しい属性をAlertHistoryオブジェクトに追加します。

  • 新しいserviceRequestNumber属性は、関連付けられているサービス・リクエスト番号を示します。

  • 新しいserviceRequestLink属性は、関連付けられているサービス・リクエスト番号へのURLを示します。

その他の重要機能を次に示します。

  • 診断パッケージRESTfulページ(https://hostname/diagpack/download?name=diagpackname)には、対応するサービス・リクエストへのリンクを示す、新しい列があります。

  • Oracle ASRアラート電子メールに、SRリンクが含まれています。

Oracle ASRの自動Diagpackアップロードを有効にするには、Oracle ASR Managerhttp_receiverを有効にする必要があります。

  • http_receiverが有効になっているかどうかを確認するには、次のコマンドをOracle ASR Managerから実行します。

    asr show_http_receiver
  • http_receiverを有効にするには、次のコマンド(portは、http_receiverがリスニングするポート)を使用します。

    asr enable_http_receiver -p port

    注意:

    ここで指定したポートは、データベース・サーバーまたはストレージ・サーバーでサブスクライバに指定したasrmPortと同じである必要があります。次のコマンドは、データベース・サーバーおよびストレージサーバーでasrmPortを確認する方法を示します。

    DBMCLI> LIST DBSERVER ATTRIBUTES snmpSubscriber 
         ((host=test-engsys-asr1.example.com, port=162,community=public, 
    type=ASR,fromIP=10.242.0.55,asrmPort=16168))
    
    CellCLI> LIST CELL ATTRIBUTES snmpSubscriber
         ((host=test-engsys-asr1.example.com,port=162,community=public,
    type=ASR,asrmPort=16168))
    

診断データをサービス・リクエストに自動的にアップロードする必要がない場合は、ALTER CELL diagPackUploadEnabled=FALSEを実行して自動アップロードを無効にできます。

必要な最小ソフトウェア: Oracle ASR Managerリリース5.7

14.1.11 Oracle Exadata Database Serverで使用可能なCREATE DIAGPACKおよびLIST DIAGPACKコマンド

ストレージ・サーバーで使用可能な診断パッケージ機能が、データベース・サーバーでも使用可能になりました。データベース・サーバー上の管理サーバー(MS)は、データベース・サーバー・アラート生成時の関連するログおよびトレースを含む、カスタマイズされた診断パッケージを自動的に収集します。これは、重要なすべてのデータベース・サーバー・アラートに適用されます。診断情報の適時収集は、重要なログのロールオーバーを防ぎます。

データベース・サーバー上のMSは、重要なすべての電子メール・アラートで、診断パッケージを電子メール添付ファイルとして送信します。ユーザーは、新しいCREATE DIAGPACK DBMCLIコマンドを使用して開始時刻および継続時間を指定することで、毎時間カスタム診断パッケージを作成できます。

詳細は、Oracle Exadata Database Machineメンテナンス・ガイドCREATE DIAGPACKおよびLIST DIAGPACKを参照してください。

14.1.12 レスキュー計画

12.2.1.1.0より前のリリースのOracle Exadata System Softwareでは、Oracle Exadata Database ServerまたはOracle Exadata Storage Serverのレスキューの後、複数のコマンドを再実行して、I/Oリソース管理(IORM)計画、しきい値、およびストレージ・サーバーおよびデータベース・サーバーの通知設定などの項目を構成する必要があります。

Oracle Exadata System Softwareリリース12.2.1.1.0では、cellおよびdbserverオブジェクトにはrescuePlanという新しい属性があります。この属性を使用してコマンドのリストを取得し、それをスクリプトとして格納できます。その後、セル・レスキューの後にそのスクリプトを実行して設定をリストアできます。

rescuePlan属性の詳細は、Oracle Exadata Database Machineメンテナンス・ガイドを参照してください。

14.1.13 IPv6 Oracle VMおよびタグ付きVLANのサポート

Oracle Exadata System Softwareリリース12.2.1.1.0では、Oracle Exadata Deployment Assistant (OEDA)を使用してIPv6 Oracle VMおよびタグ付き仮想LAN (VLAN)がサポートされています。

IPv6 VLANが、管理ネットワーク上でサポートされるようになりました。以前のリリースでは、これはサポートされていませんでした。

Oracle Exadata Database Machineインストレーションおよび構成ガイドを参照してください。

14.1.14 管理サーバーをNTP、DNSおよびILOMの変更中にオンラインのままにできる

NTP、DNSまたはILOMパラメータの変更中は、その操作の間、管理サーバー(MS)をオンラインのままにでき、再起動する必要はありません。

14.1.15 ExaWatcherでの新しいチャート

Oracle Exadata System Softwareリリース12.2.1.1.0では、GetExaWatcherResults.shは、IO、CPU使用率、セル・サーバー統計およびアラート履歴のチャートを含む、HTMLページを生成します。IOおよびCPU使用率のチャートではiostatからのデータが使用されますが、セル・サーバー統計ではcellsrvstatからのデータが使用されます。アラート履歴は、指定された時間枠の間に取得されます。

詳細は、Oracle Exadata Database Machineメンテナンス・ガイドExaWatcherチャートを参照してください。

14.1.16 REDOログ書込みの新しいメトリック

REDOログ書込みパフォーマンスの分析に役立つ、新しいメトリックを使用可能です。

以前は、Automatic Workload Repository (AWR)でデータベース・サーバーのREDOログ書込み待機時間に関する問題がレポートされたときに、ストレージ・セルでREDOログ書込みパフォーマンスに問題がないと示されることがよくありました。新しいメトリックは、より詳細な全体像を得るために役立ちます。これらのメトリックは、次の懸念事項を理解する上での手掛かりとなります。

  • I/Oレイテンシが高いかどうか、または他の要因(たとえば、ネットワーク)であるかどうか。

  • フラッシュ・ログを迂回したREDOログ書込みの数。

  • フラッシュ・ログで処理されたREDOログ書込みのみでなく、すべてのREDOログ書込みを考慮に入れた、各セルでのREDOログ書込みの全体のレイテンシ。

Oracle Exadata System Softwareリリース12.2.1.1.0では、REDOログ書込みリクエストに関連する次のメトリックが導入されています。

  • FL_IO_TM_W: 累積的なREDOログ書込みレイテンシ。これには、Exadataスマート・フラッシュ・ログによって処理されないリクエストのレイテンシが含まれます。

  • FL_IO_TM_W_RQ: REDOログ書込みレイテンシの平均。書込みのI/Oレイテンシのみが含まれます。

  • FL_RQ_TM_W: 累積的なREDOログ書込みリクエスト・レイテンシ。ネットワーキングおよびその他のオーバーヘッドが含まれます。

    ネットワークおよび処理などの要因によるレイテンシ・オーバーヘッドを取得するには、(FL_RQ_TM_W - FL_IO_TM_W)を使用します。

  • FL_RQ_TM_W_RQ: REDOログ書込みリクエスト・レイテンシの平均。

  • FL_RQ_W: REDOログ書込みリクエストの合計数。これには、Exadataスマート・フラッシュ・ログによって処理されないリクエストが含まれます。

    Exadataスマート・フラッシュ・ログによって処理されないREDOログ書込みリクエスト数を取得するには、(FL_RQ_W - FL_IO_W)を使用します。

14.1.17 セル間のリバランス操作および高スループット書込み操作での隔離マネージャ・サポート

隔離マネージャのサポートは、セル間オフロード操作でのリバランスおよび高スループット書込みのために有効になっています。これらの操作の間にOracle Exadata System Softwareでクラッシュが検出された場合は、問題を起こす操作が隔離され、あまり最適化されていないパスを使用して操作が続行されます。

新しい隔離のための隔離タイプは、ASM_OFFLOAD_REBALANCEおよびHIGH_THROUGHPUT_WRITEです。

詳細は、Oracle Exadata System Softwareユーザーズ・ガイドセル間オフロード操作に対する隔離マネージャのサポートを参照してください。

14.1.18 管理サーバーで有効なExaCLIおよびREST API

ExaCLIとREST APIはいずれも、データベース・サーバー上の管理サーバー(MS)で使用できます。

MSコマンドのリモート実行ができるようになりました。WebブラウザのHTTPSを使用してインタフェース(curl)にアクセスできます。詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』を参照してください。

14.1.19 Oracle Grid Infrastructure 12.2.1.1.0の新機能

Oracle Grid Infrastructure 12.2.1.1.0における次の新機能は、Oracle Exadata Database Machineに影響します。

14.1.19.1 Oracle ASMフレックス・ディスク・グループ

Oracle ASMフレックス・ディスク・グループとは、Oracle ASMファイル・グループをサポートするディスク・グループ・タイプです。

Oracle ASMファイル・グループは、データベースに属するファイルのグループを表し、ファイル・グループまたはデータベースのレベルでストレージ管理の実行を可能にします。一般に、フレックス・ディスク・グループを使用すると、ユーザーはディスク・グループ・レベルに加えて、データベースの粒度でストレージを管理できるようになります。

Oracle Automatic Storage Management管理者ガイドフレックス・ディスク・グループの管理を参照してください。

14.1.19.2 Oracle Flex ASM

Oracle Flex ASMを使用すると、データベース・サーバーとは異なる物理サーバーでOracle ASMインスタンスを実行できます。

標準のOracle ASMクラスタ内のノードのOracle ASMインスタンスに障害が発生すると、そのノード上のすべてのデータベース・インスタンスでも障害が発生します。ただし、Oracle Flex ASM構成では、Oracle 12cデータベース・インスタンスは、別のノードの別のOracle ASMインスタンスにリモートでアクセスできるため、機能が停止することはありません。

Oracle Flex ASMを使用すると、すべての記憶域の要件を、ディスク・グループの単一のセットに統合できます。これらのすべてのディスク・グループを、単一のクラスタで実行中のOracle ASMインスタンスの小さいセットでマウントおよび管理します。カーディナリティ設定で、Oracle ASMインスタンスの数を指定できます。

Oracle Flex ASMは、Oracle Database 12cリリース2 (12.2)とともにデフォルトで有効になっています。Oracle Exadata Database Machineは、カーディナリティがALLに設定されて出荷されます。これは、Oracle ASMインスタンスが、使用可能なすべてのノード上で作成されるということです。詳細は、次の各項を参照してください。

14.1.19.3 ストレージ損失後の冗長性回復の高速化

Oracle Grid Infrastructure 12c リリース2 (12.2)の使用では、以前のリリースよりもストレージ損失の後の冗長性回復に時間がかかりません。

新しいREBUILDフェーズがリバランス操作に導入されました。REBUILDフェーズがストレージ障害後に最初に冗長性を回復するため、2番目の障害が発生するリスク期間が大幅に削減されます。後続のBALANCEフェーズが、バランスを回復します。

Oracle Grid Infrastructureリリース12.1.0.2 (DBBP 12.1.0.2.170718を含む)には、リバランスのOracle ASM REBUILDフェーズも含まれています。

注意:

Oracle Grid Infrastructure 12cリリース2 (12.2)では、再構築がV$ASM_OPERATIONで別のバス(REBUILD)を介して追跡されます。Oracle Grid Infrastructure 12cリリース1 (12.1)では、再構築とリバランスの両方のフェーズが同じパス(REBALANCE)で追跡されます。
14.1.19.4 動的な電力変更

ASM_POWER_LIMITパラメータの値を動的に調整できます。

ALTER DISKGROUP文でPOWER句を指定しなかった場合や、ディスクの追加または削除によってリバランスが暗黙的に実行される場合は、リバランス指数はデフォルトでASM_POWER_LIMIT初期化パラメータの値になります。このパラメータの値は動的に調整できます。POWER句の値の範囲は、ASM_POWER_LIMIT初期化パラメータと同じです。

指数が大きくなるほど、リバランス操作の完了は早くなります。指数の値が小さいほどリバランスにかかる時間は長くなりますが、データベースなどの他のアプリケーションで共有される処理とI/Oの消費リソースは少なくなります。

Oracle Automatic Storage Management管理者ガイドリバランス操作の調整を参照してください。

14.1.19.5 Oracle Universal Installerでの定数ディスク・サポート

Oracle Grid Infrastructureのインストール中に、定数障害グループを指定できます。

Oracle Exadata Storage Serverでは、デプロイメント中に定数ディスク・グループが自動的に作成されます。定数障害グループは、Oracle Clusterware投票ファイルの格納に使用する特殊なタイプの障害グループです。定数障害グループは、指定した障害グループの定数が使用可能であることを確認するために使用されます。

Oracle Grid Infrastructure 12.2のインストーラは、定数ディスク・マネージャ・ユーティリティを使用してインストール後に定数障害グループを構成するかわりに、インストール中に定数障害グループを指定できるよう、更新されました。

Oracle Grid Infrastructureインストレーションおよびアップグレード・ガイドfor LinuxOracle Automatic Storage Managementの記憶域要件の特定を参照してください。

14.1.20 Oracle Database 12cリリース2 (12.2.0.1)の新機能

Oracle Database 12cリリース2 (12.2.0.1)における次の新機能は、Oracle Exadataに影響します。

14.1.20.1 データベース・サーバーのI/Oレイテンシ制限

ごくたまに、ネットワーク・レイテンシの異常値、ストレージ・サーバーでのハードウェア問題、またはストレージ・サーバーに関するその他のシステム問題が原因で、データベース・サーバーとストレージ・サーバーとの間でI/Oレイテンシが高くなる場合があります。Oracle ASMおよびOracle Exadata Storage Serverソフトウェアは、読取りI/Oのレイテンシが予想より非常に長いときには、読取りI/O操作を他のストレージ・サーバーに自動的にリダイレクトします。データの最新の有効なミラー・コピーに対して実行されたI/Oは、リダイレクトされません。

この機能は、Exadata Storage Softwareのすべてのリリースで使用できます。この機能を使用するために構成を行う必要はありません。

必要な最小ソフトウェア: Oracle DatabaseおよびOracle Grid Infrastructure 12cリリース2 (12.2.0.1.0)

14.1.20.2 圧縮型索引スキャンのためのExadata Smart Scanオフロード

Oracle Exadata Storage Server Software 12.1.2.3.0以前のリリースでは、スマート・スキャン・オフロードで通常の圧縮されていない索引およびビットマップ索引がサポートされていました。

Oracle Exadata Storage Server Software 12.2.1.1.0では、スマート・スキャン・オフロードが圧縮型索引のために実装されました。Oracle Exadataでの圧縮型索引スキャンに関与する問合せには、この機能が役立つ可能性があります。

必要な最小ソフトウェア: Oracle Database 12cリリース2 (12.2.0.1.0)およびOracle Exadata Storage Serverソフトウェア・リリース12.2.1.1.0

14.1.20.3 インメモリー集計(IMA)のためのExadata Smart Scanオフロード機能拡張

Oracle Exadata Storage Serverソフトウェアでは、条件評価のために多数のSQL操作のオフロードがサポートされています。インメモリー集計機能は、ベクトル変換の最適化を実行しようとします。これは、スター型結合SQL問合せを特定の集計操作(たとえば、SUMMINMAXおよびCOUNT)とともに使用し、それをより効率的な処理のために再書込みします。ベクトル変換問合せは、結合にブルーム・フィルタを使用する問合せと似ていますが、より効率的です。ベクトル変換問合せをOracle Exadata Storage Serverリリース12.1.2.1.0とともに使用する場合は、集計に使用される行のフィルタ処理をオフロードできることにより、問合せでの結合のパフォーマンスが向上します。この最適化が始まると、問合せ計画にKEY VECTOR USEと表示されます。

Oracle Exadata Storage Serverソフトウェア・リリース12.2.1.1.0では、ベクトル変換された問合せは、Exadata Storage Indexに対するグループ化列(キー・ベクトル)の適用により、さらに処理が効率化されています。

また、ストレージ・サーバー上でインメモリー列指向形式でデータをスキャンする、ベクトル変換された問合せにより、集計作業の処理をオフロードできます。これらの最適化は自動であり、ユーザー設定に依存しません。

必要な最小ソフトウェア: Oracle Database 12cリリース2 (12.2.0.1.0)およびOracle Exadata Storage Serverソフトウェア・リリース12.2.1.1.0

14.1.20.4 XMLのためのExadata Smart Scanオフロード機能拡張

4 KB未満のSecureFiles LOBを使用してXMLデータが格納される場合は、Oracle SQL条件XMLExistsのSQL WHERE句内の評価、またはOracle SQL関数XMLQueryの戻り値に適用されたOracle SQL関数XMLCastを、Oracle Exadata Storage Serverにオフロードできる場合があります。

必要な最小ソフトウェア: Oracle Database 12cリリース2 (12.2.0.1.0)およびOracle Exadata Storage Serverソフトウェア・リリース12.2.1.1.0

14.1.20.5 LOBのためのExadata Smart Scanオフロード機能拡張

Oracle Exadata Storage Server 12.2.1.1.0では、LOB演算子LENGTHSUBSTRINSTRM CONCATLPADRPADLTRIMRTRIMLOWERUPPERNLS_LOWERNLS_UPPERNVLREPLACEREGEXP_INSTRTO_CHARのオフロード・サポートが拡張されました。

Exadataスマート・スキャン・オフロード評価は、圧縮されていないインライン化されたLOB(サイズは4 KB未満)でのみサポートされています。

必要な最小ソフトウェア: Oracle Database 12cリリース2 (12.2.0.1.0)およびOracle Exadata Storage Serverソフトウェア・リリース12.2.1.1.0

14.1.20.6 Oracle Exadataスナップショットの新機能
  • 階層型スナップショット・データベース

    親(それ自体がスナップショット)から領域使用効率のよいスナップショット・データベースを作成できます。これにより、階層型スナップショット・データベースが可能になります。親スナップショットも、ベース・テスト・マスターにわたるまで、領域使用効率が優れています。複数のユーザーが、同じ親スナップショットから固有のスナップショットを作成できます。一連のスナップショットをツリーとして表現できます。この場合、ツリーのルートはベース・テスト・マスターです。ツリー内のすべての内接点は読取り専用データベースであり、ツリー内のすべてのリーフは読取り/書込みデータベースとなります。すべてのOracle Exadata機能が、階層型スナップショット・データベース上でサポートされています。階層型スナップショット・データベースでは、スナップショットの深度が深くなるほどパフォーマンスに不利になるため、スナップショット・ツリーの深度は最大でも10までにすることをお薦めします。

  • スペア・テスト・マスター・データベース

    スパース・テスト・マスターを作成および管理すると同時に、それからアクティブなスナップショットを持つこともできます。この機能では、スパース・テスト・マスターからスナップショットを直接作成している短い期間を除き、スパース・テスト・マスターをほぼ継続的にOracle Data Guardと同期できます。この機能では、読取り専用の非表示の親を作成することで、前述の階層型スナップショット機能が利用されます。Oracle Exadataスナップショット・データベースがテスト・データベースおよび開発データベースのみを対象としていることに注意してください。

  • スパース・バックアップおよびリカバリ

    DB0上でスパース・バックアップを実行する場合、その操作では、データベースの差分ストレージ領域、およびスパース・データ・ファイルの差分領域からのみデータがコピーされます。スパース・バックアップは、バックアップ・セット形式(デフォルト)、またはイメージ・コピー形式のどちらかにできます。RMANは、スパース・バックアップのスパース・データファイルをリストアし、次にそれらをアーカイブ・ログおよびREDOログからリカバリします。スパース・データファイルでは完全リカバリまたはPoint-in-Timeリカバリを実行できます。スパース・バックアップは、記憶領域の効率的な管理と、より高速なバックアップおよびリカバリを促進します。

    スパース・バックアップの詳細は、Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドを参照してください。

最小ハードウェア: ストレージ・サーバーがX3以上である必要があります。

最小ソフトウェア: Oracle Database and Grid Infrastructure 12cリリース2 (12.2)およびOracle Exadata Storage Serverソフトウェア・リリース12.2.1.1.0

14.1.21 Unbreakable Enterprise Kernel 4にアップグレードされたOracle Linuxカーネルおよび3.4.2にアップグレードされたOracle VM

このリリースでは、Oracle LinuxがUnbreakable Enterprise Kernel (UEK) 4 (4.1.12-61.28.1.el6uek.x86_64)にアップグレードされます。仮想化を使用するシステムの場合は、DOM0がOracle VM 3.4.2にアップグレードされます。これにより、dom0上でOracle Linux 6を使用できるようになります。dom0およびdomU上で使用されるLinuxカーネルが統合されるようになりました。

以前に計算ノード上で仮想化を使用していたシステムの場合は、Oracle Exadata Storage Serverソフトウェアをリリース12.2.1.1.0にアップグレードする前に、すべてのdomUでOracle Grid Infrastructureホームをリリース12.1.0.2.161018DBBP以上にアップグレードする必要があります。Oracle Exadata Storage Serverソフトウェアをリリース12.2.1.1.0にアップグレードするには、dom0をアップグレードする前に、最初にすべてのdomU上のそれらをアップグレードする必要があります。この要件は、patchmgrソフトウェアによって強制されます。

Oracle ASM Cluster File System (Oracle ACFS)を使用する場合は、Oracle Grid InfrastructureホームをアップグレードしてOracle ACFSサポートをUEK4カーネルで有効にする前に、バグ22810422に対する修正を適用する必要があります。また、OLTPワークロードのパフォーマンスを向上させるために、バグ23642667に対する修正をOracle Grid Infrastructureホーム上とOracle Databaseホーム上の両方にインストールすることをお薦めします。

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

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

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

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

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

以前のリリースでは、ストレージ・サーバーが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を適用

14.2.3 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タグ付けの使用に関する項を参照してください。

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

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

  • グリッド・インフラストラクチャ・ホーム:

    • 11.2.0.4.16 (2015年4月)以上

    • 12.1.0.2.4 (2015年1月)以上

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

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

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

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

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

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

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

アクティブ・パッシブ

28,500

25,000

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

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

64,000

44,000

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

アクティブ・パッシブ

12,500

10,000

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

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

16,000

14,000

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

表14-2 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 (patchmgrdbnodeupdate.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 System Softwareリリース12.1.2.3.0

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

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

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

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

最低限必要なソフトウェア:

  • Oracle Exadata Storage Server Softwareリリース12.1.2.3.0

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

14.2.8 グリッド・ディスク・サイズを減少させる際の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適用)

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

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

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

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

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

14.3.1 スマート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_updatesTRUEに設定します。これは静的パラメータであるため、この変更を反映させるにはデータベースを再起動する必要があります。

  • すべてのOracle RACインスタンスで、exafusion_enabledパラメータを1に設定します。

注意:

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

14.3.2 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

14.3.3 IPv6サポート

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

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

コンポーネント IPv6サポートの説明

Oracle Exadata Deployment Assistant (OEDA)

OEDAでは、ユーザーが顧客ネットワークの定義画面(スクリーンショットについては図14-1を参照)で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 Gatewayソフトウェア・リリースが提供されるまで、Platinum SupportはIPv6デプロイメントでは使用できません。

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

図14-1の説明が続きます
「図14-1 Oracle Exadata Deployment Assistantの顧客ネットワークの定義画面」の説明

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 列フラッシュ・キャッシュとKEEPキャッシュのサポートの追加。

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

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

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

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

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

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

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

マシン・タイプ 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個のデータベースが最大プロセス数で実行されると、セルの接続制限を超過します。

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

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

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

https://hostname/diagpack

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

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

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

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

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

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

14.3.11 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の生成が高速化されています。

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

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

  • 大容量セルでは、すべてのハード・ドライブ上のすべての3つのLEDが10秒間点滅します。

  • エクストリーム・フラッシュ・セルでは、取外しOKの青色のLEDが10秒間点滅し、オレンジ色のLEDが点灯します。

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

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

14.3.13 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

14.3.14 逆オフロードの改良

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

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

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

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

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

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

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

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

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

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

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

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

14.4.1 Exadata仮想環境用のInfiniBandパーティション化

InfiniBandパーティション化はExadata仮想環境で使用できるようになり、Oracle Exadata Deployment Assistant (OEDA)と組み合せて構成できます。

OEDAのグラフィカル・ユーザー・インタフェースを使用してInfiniBandパーティションをクラスタごとに定義し、OEDAのコマンドライン・インタフェースを使用し、適切なパーティション・キーとメンバーシップ要件を設定して、ゲストとInifniBandスイッチを構成し、InfiniBandパーティションを有効にします。

InfiniBandパーティションはクラスタごとに定義できます。ストレージ・サーバーが複数のクラスタ間で共有されている場合、すべてのクラスタで同じストレージ・パーティション・キーを使用します。

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

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

14.5.1 X5 Storage Serverでのフラッシュ・パフォーマンスの向上

NVMeフラッシュ・ファームウェアに変更が加えられ、バックグラウンドのリフレッシュ・アルゴリズムおよび操作に対してリソースや変更を処理するI/Oタスクが改善されています。このリリースでは、フラッシュのパフォーマンスが同じかわずかに向上しています。

14.5.2 Oracle Exadata仮想マシン

統合環境では、X5-2、X4-2、X3-2およびX2-2データベース・サーバー上で、ワークロード間をより高いレベルで分離するOracle Virtual Machine (Oracle VM)が使用されるようになりました。仮想マシンの分離は、信頼できないワークロードが共有環境でセキュリティ、CPUまたはメモリー使用状況を制限する場合に好都合です。

14.5.3 Infrastructure as a Service (IaaS)およびキャパシティ・オンデマンド(CoD)

Oracle Exadata Infrastructure as a Service (IaaS)のユーザーがキャパシティ・オンデマンド機能を使用して、データベース・サーバーのアクティブ・コア数を制限し、必要なデータベース・ソフトウェア・ライセンスの数を制限できるようになりました。Exadata 12.1.2.1.1 Softwareでは、CoDとIaaSを同じシステムに配置することができます。コアの予約済セットのオンとオフを切り替える機能(IaaS-CoD)はIaaSに含まれることに注意してください。

14.5.4 フラッシュ・キャッシュのメトリックの向上

このリリースには、統合ブロック・キャッシュと列キャッシュのメトリックが含まれ、フラッシュ・キャッシュ・パフォーマンスをさらに詳しく分析できるようになりました。

14.5.5 うるう秒の時刻調整

このリリースでは、2015年6月30日のうるう秒の調整に備えて、うるう秒がサポートされています。

14.5.6 ネットワーク・リソース管理

  • X5-2 Extreme Flash (EF) Storage Serverで、Oracle 1.6TB NVMe SSDファームウェアが8DV1RA12に更新されています

  • X5-2 High Capacity (HC) Storage Serverで、Oracle Flash Accelerator F160 PCIeカードのファームウェアが8DV1RA12に更新されています

14.5.7 DBMCLIでの/opt/oracle.cellos/compmon/exadata_mon_hw_asr.plスクリプトの置換

Oracle Exadata Storage Serverリリース12.1.2.1.0以降で、データベース・サーバーの構成、監視および管理のために、DBMCLIと呼ばれる新しいコマンドライン・インタフェースが導入されています。DBMCLIは、各データベース・サーバー上および仮想化マシンのDOM0上にプレインストールされています。DBMCLIでは、自動サービス・リクエスト、キャパシティ・オンデマンド、Infrastructure as a Serviceおよびデータベース・サーバー電子メール・アラートを構成できます。DBMCLIは、/opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl Perlスクリプトにかわって使用されます。DBMCLIの使用方法の詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』を参照してください。

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

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

14.6.1 Oracle Exadata Database Machineエラスティック構成

エラスティック構成を使用すると、Oracle Exadata Racksで、顧客が定義したデータベース・サーバーとExadata Storageサーバーの組合せを利用できます。少なくとも2台のデータベース・サーバーと3台のストレージ・サーバーをラックに設置する必要があります。ストレージ・サーバーは、すべて同タイプである必要があります。Oracle Exadata Database Machine X5-2エラスティック構成とOracle Exadata Database Machine X4-8エラスティック構成では、2台から19台のデータベース・サーバー、3台から20台のExadata Storageサーバーまたは1組のデータベース・サーバーとExadata Storageサーバーの組合せを使用できます。Oracle Exadata Storage Expansion Rack X5-2エラスティック構成では、4台から19台のストレージ・サーバーを使用できます。

エラスティック構成を使用すると、Oracle Exadata Racksで、顧客が定義したデータベース・サーバーとExadata Storageサーバーの組合せを利用できます。これにより、ハードウェア構成を、特定のワークロードに的確に適合させることができます(たとえばDatabase In-Memory、OLTP、Data WarehousingまたはData Retention)。

  • Oracle Exadata Database Machine X5-2エラスティック構成は、2台のデータベース・サーバーと3台のExadata Storageサーバーを含むクオータ・ラックから用意されています。ラックがいっぱいになるか、ラックの最大サーバー数の22台に達するまで、追加のデータベースとストレージ・サーバー(大容量(HC)またはExtreme Flash(EF))を追加できます。

  • Oracle Exadata Storage Expansion Rack X5-2エラスティック構成は、4台のExadata Storageサーバーを含むクオータ・ラックから用意されています。ラック当たり合計19台のストレージ・サーバーまで、追加のストレージ・サーバー(HCまたはEF)を追加できます。

  • Oracle Exadata Database Machine X4-8エラスティック構成は、2台のデータベース・サーバーX4-8 8ソケット・サーバーと3台のExadata Storageサーバーを含むハーフ・ラックから用意されています。ラック当たり最大2台の追加のX4-8 8ソケット・サーバーを追加できます。ラック当たり最大11台の追加のExadata Storageサーバー(HCまたはEF)を追加できます。

14.6.2 スパース・グリッド・ディスク

スパース・グリッド・ディスクは、新しいデータがディスクへ書き込まれるときに領域を割り当てるため、仮想サイズが実際の物理サイズよりはるかに大きくなることがあります。スパース・グリッド・ディスクは、スパース・ディスク・グループを作成して、割り当てられた領域の小部分を使用するデータベース・ファイルを格納するために使用されます。スパース・ディスク・グループは、短時間で効率的にデータベースのスナップショットをOracle Exadata上に作成するのに特に役立ちます。従来のデータベースを、スパース・ディスク・グループを使用して作成することもできます。

最小ハードウェア: ストレージ・ノードX3以上

最小ソフトウェア: Oracle Database 12cリリース1(12.1)リリース12.1.0.2 BP5以上。

14.6.3 テストおよび開発目的のデータベースのスナップショット

テストと開発目的のために、スペース効率のよいデータベース・スナップショットをすぐに作成できるようになりました。スナップショットは、機密情報を消去した本番データベース(またはプラガブル・データベース(PDB))の共有読取り専用コピーで開始します。各スナップショットは、変更がなされるたびに、変更されたブロックをスパース・ディスク・グループへ書き込みます。

複数のユーザーが、同じベース・データベースから別々のスナップショットを作成することもできます。このため、複数のテストおよび開発環境が、各タスク用のデータベースを別々に維持しつつ、領域を共有することができます。Exadata Storageサーバー上でスナップショットを使用すると、Smart Scanなど、Oracle Exadata Storage Server Softwareの機能を使用して、テストおよび開発をすることができます。

Exadataデータベース・スナップショットは、マルチテナント・データベース・オプションと統合されているため、きわめて簡素なインタフェースで新しいPDBスナップショットを作成することができます。

最小ハードウェア: ストレージ・ノードX3以上

最小ソフトウェア: Oracle Database 12cリリース1(12.1)リリース12.1.0.2 BP5以上。

14.6.4 列形式フラッシュ・キャッシュ

Oracle Exadata System Softwareリリース12.1.2.1.0は、混合ワークロードを効率的にサポートしているため、OLTPと分析の両方でパフォーマンスを最適にできます。これは、トランザクショナル処理ではハイブリッド列形式で、分析処理ではそれに最適化された純粋な列形式で、データを格納することを可能にするExadata Smart Flash Cacheのデュアル・フォーマット・アーキテクチャにより実現されています。

さらに、Exadata Hybrid Columnar Compressionは、OLTPと分析のワークロードのニーズを均衡させます。Exadata Hybrid Columnar Compressionを使用すると最高レベルのデータ圧縮が可能になり、特に分析ワークロードでI/Oが削減されるためコストが大幅に節約されてパフォーマンスが向上します。

Oracle Exadata System Softwareリリース12.1.2.1.0では、フラッシュ・キャッシュ移入時に、分析処理を最適化するために、Exadata Smart Flash Cacheソフトウェアがハイブリッド列圧縮データを純粋な列形式に変換します。フラッシュ内の純粋な列データに対するフラッシュ・キャッシュは、選択された列のみを読み取るため、高速で実行され、フラッシュI/Oとストレージ・サーバーのCPU使用量が減ります。

Oracle Exadata System Softwareリリース12.1.2.1.0は、Exadata Hybrid Columnar Compression表データを純粋な列形式レイアウトでフラッシュ・キャッシュにキャッシュすることができます。Smart Scanを使用してExadata Hybrid Columnar Compression表にアクセスすると、Exadata Hybrid Columnar Compressionの圧縮されたデータがフラッシュ・キャッシュの記憶領域と同じ量で純粋な列形式レイアウトに再フォーマットされます。

大規模表の、圧縮ユニット(CU)内での所定の列のデータのパーセンテージは、小規模表と比較して小さくなります。これにより、列全体のデータを取得するために、ディスクとフラッシュからより多くのCUがフェッチされます。大規模なExadata Hybrid Columnar Compression表の少数の列のみを読み取る問合せは、ストレージから無関係な列も読み取るため、広いI/O帯域幅を使用します。データを列形式でフラッシュ・キャッシュに格納すると、無関係な列を読む必要が軽減され、パフォーマンスが大きく改善します。

ワークロードのタイプ(OLTPまたはデータ・ウェアハウス)によって異なりますが、同じリージョンのデータを、従来のブロック形式と列形式の両方でフラッシュ・キャッシュ上にキャッシュできます。

この機能はデフォルトで有効になっており、この機能を使用するためにユーザーによる構成を必要としません。

列形式のフラッシュ・キャッシュを使用すると、OLTPスタイルの単一列参照でも優れたパフォーマンスを維持しつつ、レポーティングと分析的問合せが高速化されます。

列形式フラッシュ・キャッシュは、よくスキャンされるExadata Hybrid Columnar Compressionの圧縮されたデータを、フラッシュ・キャッシュへのロード時に純粋な列形式に自動変換することによって、Oracle Exadata Database Machineフラッシュのデュアル・フォーマット・アーキテクチャを実装しています。フラッシュ内の純粋な列データに対して実行されるSmart Scanは、選択された列のみを読み取るため、高速で実行され、フラッシュI/Oとストレージ・サーバーのCPUが減ります。

データが頻繁にOLTP参照される場合、元のExadata Hybrid Columnar Compression形式データもフラッシュ・キャッシュにキャッシュできます。このため、Exadataスマート・フラッシュ・キャッシュは、よく使用されるあらゆるタイプの操作を高速化するために、キャッシュされたデータの形式を自動的に最適化します。

この機能はデフォルトで有効になっており、この機能を使用するためにユーザーによる構成を必要としません。

最小ソフトウェア: Oracle Database 12cリリース12.1.0.2.0を実行するOracle Exadata System Softwareリリース12.1.2.1.0

関連項目:

フラッシュ・キャッシュのメトリックの詳細は、Oracle Exadata System Softwareユーザーズ・ガイドを参照してください

14.6.5 書込み操作のためのOracle Exadata System SoftwareのI/Oレイテンシ制限

この機能では、遅い読取りによって異常値を排除できます。それ以外ではアプリケーションに表示される読取りの異常値を防止します。

ディスク・ドライブ、ディスク・コントローラおよびフラッシュ・デバイスは、デバイスが内部メンテナンスまたはリカバリ操作を実行している間、場合により、待機時間が長くなることがある複雑なコンピュータです。また、障害が発生しかけているデバイスは、その発生前に待機時間が長くなる場合があります。以前は、高い待機時間を示すデバイスは、場合によりSQL応答時間が長くなることがありました。書込み操作のOracle Exadata System SoftwareのI/Oレイテンシ制限では、レイテンシが長いI/O動作をミラー・コピーに自動リダイレクトすることによって、Oracle Exadata Database Machine上でのSQL I/O応答時間を確実に改善します。

Oracle Exadata System Softwareリリース11.2.3.3.1および12.1.1.1.1では、Oracle Exadata Database Machineがフラッシュ・デバイスから読取りを試行し、読取りI/Oのレイテンシが適切な長さより長い場合に、Oracle Exadata System SoftwareがI/O読取り操作を自動的に別のストレージ・サーバー(セル)にリダイレクトします。I/O読取りを開始したデータベース・サーバーにメッセージが送信され、それによってデータベース・サーバーは、読取りI/Oをデータの別のミラー・コピーにリダイレクトします。データの最新の有効なミラー・コピーに対して実行された読取りI/Oは、リダイレクトされません。

Oracle Exadata System Softwareリリース12.1.2.1.0では、レイテンシの長い書込み操作を検出すると、Oracle Exadata System Softwareは、同じストレージ・サーバーの別の正常なフラッシュ・デバイスに自動的に書込み操作をリダイレクトします。書込みが正常に完了したら、データベース・サーバーで書込みI/Oが成功と認識され、それによって書込み異常値を除去します。

要件:

  • 最小ソフトウェア:

    • Oracle Database 11gリリース2 (11.2)、Monthly Database Patch For Exadata (2014年6月 - 11.2.0.4.8)

    • Oracle Grid Infrastructure 11gリリース2 (11.2)、Monthly Database Patch For Exadata (2014年6月 - 11.2.0.4.8)

  • ストレージ・サーバー(セル)のライトバック・フラッシュ・キャッシュの有効化

14.6.6 誤検知ドライブ障害の除去

ディスク・ドライブとフラッシュ・ドライブは、内部ソフトウェアがロックされるために、場合により、実際に物理的に故障していなくても故障しているように見えることがある複雑なコンピュータです。X5-2 High Capacityセル上のハード・ドライブ障害と見られる現象またはX5-2 Extreme Flashセル上のフラッシュ・ドライブ障害と見られる現象が発生した場合、Oracle Exadata System SoftwareはI/Oを他のドライブに自動的にリダイレクトし、ドライブをパワー・サイクルします。パワー・サイクルの後、ドライブが正常ステータスに戻ると、再び有効化され、再同期されます。パワー・サイクルの後もドライブの障害が継続する場合、それは削除されます。この機能により、Oracle Exadata System Softwareでは誤検知されたディスク障害を除去することが可能になるため、データ冗長度を維持しつつ管理負荷を減らすことができます。

14.6.7 フラッシュおよびディスクのライフ・サイクル管理アラート

Oracle Exadata Storage Server Softwareは、ディスクの障害と交換によるOracle ASMのリバランス操作を監視します。管理サーバーは、リバランス操作が正常に完了したか、エラーが発生したときにアラートを送信します。

以前のリリースでは、V$ASM_OPERATIONビューを問い合せることによって、ユーザーがリバランス操作の進捗を定期的に監視する必要がありました。ユーザーは管理サーバーからアラートをサブスクライブし、Oracle ASMリバランス操作に関する更新を受け取ることができるようになりました。

最小ソフトウェア: Oracle Databaseリリース12.1.0.2 BP4以降、およびOracle Exadata Storage Server Softwareリリース12.1.2.1.0以降。

14.6.8 最小値または最大値機能を備えたSQL問合せのためのパフォーマンス最適化

最小値または最大値機能を使用するSQL問合せは、Exadata Storage Serverメモリーにキャッシュされたストレージ索引列サマリーを活用するように設計されています。問合せの処理時に、その際の最小値と最大値が追跡されます。I/Oを発行する前に、データ領域のストレージ索引にキャッシュされた最小/最大値がその時点の最小/最大値とともに確認され、そのI/Oを発行するか、プルーニングするかが決定されます。全体として、この最適化により問合せ時にかなりのI/Oプルーニングが発生することがあり、問合せのパフォーマンスを向上させます。この最適化がプラスに働く問合せの例は、次のとおりです。

Select max(Salary) from EMP where Department = 'sales';

各列の最小値または最大値を問い合せることによって表の形状を取得するビジネス・インテリジェンス・ツールでは、この最適化は有益です。

次のセッション統計情報は、ストレージ索引最適化によって節約されたI/Oの量を示します。

cell physical IO bytes saved by storage index

最小ソフトウェア: Oracle Databaseリリース12.1.0.2。

14.6.9 AWRレポートのOracle Exadata Storage Server Softwareパフォーマンス統計情報

Exadata Storage Serverの構成とパフォーマンスの統計情報は、自動ワークロード・リポジトリ(AWR)で収集され、そのデータをAWRレポートで表示できます。AWRレポートのOracle Exadataセクションは、HTMLまたはアクティブ・レポート形式で表示できます。

次のセクションが、AWRレポートの3つの主要なセクションです。

  • Exadata Server構成: ハードウェアモデル情報、ソフトウェア・バージョンおよびストレージ構成

  • Exadata Serverシステム状態レポート: オフラインのディスクとオープン・アラート

  • Exadataパフォーマンス統計情報: オペレーティング・システム統計情報、ストレージ・サーバー・ソフトウェア統計情報、スマート・スキャン統計情報およびデータベースごとの統計情報

AWRレポートは、特定のインスタンスまたはデータベースに制限されず、ストレージ・レベルでパフォーマンス統計を提供します。これは、あるデータベースが別のデータベースのパフォーマンスに影響を及ぼす場合の事例を解析するのに役立ちます。

特定の色を使用して構成の相違が強調表示されるため、分析が簡単です。たとえば、他のセルとソフトウェア・リリースが異なるセルや、他のセルとメモリー構成が異なるセルが強調表示されます。

異常値は自動的に解析、表示されるため、パフォーマンス分析が簡単です。異常値は、適切にカラー表示され、詳細な統計情報にリンクされます。

最小ソフトウェア: Oracle Databaseリリース12.1.0.2、およびOracle Exadata Storage Server Softwareリリース12.1.2.1.0。

14.6.10 Exafusion Direct-to-Wireプロトコル

Exafusion Direct-to-Wireプロトコルを使用すると、データベース・プロセスが、OSカーネルに入るオーバーヘッドをバイパスし、通常のネットワーク・ソフトウェア・スタックを実行して、Oracle Real Applications Cluster(Oracle RAC)メッセージをInfinibandネットワーク経由で直接読み取ったり送信したりできます。これにより、Oracle Exadata Database Machine上でのOracle RAC環境の応答時間とスケーラビリティが改善されます。Exafusionは、特にOLTPアプリケーションで特に有効です。小さなOLTPメッセージではメッセージ当たりのオーバーヘッドが特に顕著だからです。

最小ソフトウェア: Oracle Exadata Storage Server Softwareリリース12.1.2.1.0には、OS、ファームウェアおよびExafusionとOracle Databaseソフトウェア・リリース12.1.0.2.0 BP1のためのドライバ・サポートが含まれます。

14.6.11 データベース・サーバー上の管理サーバー

データベース・サーバー上の管理サーバー(MS)は、データベース・サーバー管理コマンド用にWebサービスを実装し、バックグラウンド監視スレッドを実行します。管理サービスは、次のものを提供します。

  • ハード・ディスク、CPUおよびInfiniBandポートの監視を含む、包括的なハードウェアおよびソフトウェアの監視。

  • 強化されたアラート機能。

  • 重要なシステム・メトリック・コレクションと監視。

  • データベース・サーバーの構成、監視および管理のための、DBMCLIと呼ばれるコマンドライン・インタフェース。DBMCLIは、各データベース・サーバー上および仮想化マシンのDOM0上にプレインストールされています。DBMCLIでは、自動サービス・リクエスト、キャパシティ・オンデマンド、Infrastructure as a Serviceおよびデータベース・サーバー電子メール・アラートを構成できます。

Oracle Exadata Database Machineコマンドライン・インタフェース(DBMCLI)ユーティリティは、データベース・サーバーを管理するためのコマンドライン管理ツールです。DBMCLIは各サーバー上で動作し、個々のデータベース・サーバーを管理できるようにします。DBMCLIは、仮想マシンでも動作します。DBMCLIを使用して、データベース・サーバーを構成、監視および管理します。このコマンドライン・ユーティリティは、Oracle Exadata Database Machineの出荷時にインストール済です。

DBMCLIは、自動サービス・リクエスト、キャパシティ・オンデマンド、Infrastructure as a Serviceおよびデータベース・サーバー電子メール・アラートを構成するための統合クライアント・インタフェースです。また、ハード・ディスク、CPU、InfiniBandポートおよびシステムのメトリックとしきい値を監視できます。

14.6.12 JSONおよびXML用のSQL演算子

Oracle Exadata System Softwareは、条件評価のために多数のSQL演算子のオフロードをサポートしています。次のSQL演算子のオフロードがOracle Exadata System Softwareでサポートされるようになりました。

  • JSON演算子

    • JSON_VALUE

    • JSON_EXISTS

    • JSON_QUERY

    • IS JSON

    • IS NOT JSON

  • XML演算子

    • XMLExists

    • XMLCast(XMLQuery())

最小ソフトウェア: JSONのオフロードの場合、Oracle Databaseリリース12.1.0.2。XML演算子オフロードの場合、Oracle Databaseリリース12.1.0.2 BP1。

14.6.13 フラッシュ用のI/Oリソース管理

I/Oリソース管理(IORM)は、ディスク・ドライブのI/Oに加えてフラッシュ・ドライブのI/Oを管理して、データベース、プラガブル・データベースおよびコンシューマ・グループ間のI/Oの競合を制御するようになりました。Oracle Exadata環境がOLTP I/Oによって制限されることは非常に珍しいため、IORMはOLTPフラッシュI/Oをスマート・スキャン・フラッシュI/Oより自動的に優先し、スマート・スキャン・スループットにほとんどコストをかけずに、OLTP応答時間を確実に高速化します。

最小ソフトウェア: Oracle Database 11gまたはOracle Database 12cリリースを実行するExadataセル・ソフトウェア・リリース12.1.2.1.0

最小ハードウェア: ExadataリリースX2-*

14.6.14 フラッシュ・キャッシュ領域のリソース管理

フラッシュ・キャッシュは、共有リソースです。フラッシュ・キャッシュ領域のリソース管理を使用すると、データベース間IORM計画を使用して、フラッシュ・キャッシュ内でデータベースが使用できる最小および最大サイズを指定できます。フラッシュ・キャッシュ領域のリソース管理を使用すると、データベース・リソース計画を使用して、フラッシュ・キャッシュ内でプラガブル・データベース(PDB)が使用できる最小および最大サイズを指定することもできます。

最小ソフトウェア: Oracle Database 11gまたはOracle Database 12cリリース1 (12.1)リリース12.1.0.2を実行するOracle Exadata System Softwareリリース12.1.2.1.0

最小ハードウェア: Oracle Exadata Database MachineモデルX2-*

14.6.15 I/Oリソース管理プロファイル

現在、IORMデータベース間計画は、多データベース環境でデータベース間計画の管理負荷を低下させるサポート・プロファイルを計画します。以前は、ストレージ管理者が、データベース間計画ですべてのデータベースに対してリソースを指定する必要がありました。この計画は、新しいデータベースが作成されるたびに更新する必要がありました。IORMプロファイルは、この管理負荷を大幅に低下させます。ストレージ管理者が、性能要件に基づいて様々なプロファイル・タイプを定義するプロファイル・ディレクティブを作成できるようになりました。次に、管理者は、データベース間計画内でデータベース・パラメータDB_PERFORMANCE_PROFILEを使用して、新規および既存のデータベースを定義済プロファイルのいずれかにマップします。各データベースは、指定されたプロファイル・ディレクティブから、属性すべてを自動的に継承します。

最小ソフトウェア: Oracle Database 12cリリース1(12.1)リリース12.1.0.2 Exadata Bundle Patch 4を実行するExadataセル・ソフトウェア・リリース12.1.2.1.0。

14.6.16 Extreme Flashセル上のライトバック・フラッシュ・キャッシュ

Extreme Flashセルでは、フラッシュ・キャッシュはデフォルトでライトバック・モードで動作し、フラッシュ領域の5パーセントを占有します。Extreme Flashセル上のフラッシュ・キャッシュはブロック・キャッシュとして使用されません。ユーザー・グリッド・ディスクがすでに作成されており、したがってフラッシュ・キャッシュが必要でないためです。ただし、それでもフラッシュ・キャッシュは、次の高度な操作に有効です。

  • 列キャッシュは、フラッシュ・キャッシュ上のExadataハイブリッド列圧縮(EHCC)表データを、Extreme Flashセル上に純粋な列形式レイアウトでキャッシュします。

  • 書込みI/Oレイテンシ制限は、一時的に停止したフラッシュへの書込みI/O動作をキャンセルし、Extreme Flashセル上の別の正常なフラッシュ・デバイスのライトバック・フラッシュ・キャッシュに記録するべき書込みをリダイレクトします。

  • 高速データ・ファイル作成は、Extreme Flashセル上で、ライトバック・フラッシュ・キャッシュのブロックに関するメタデータを維持し、ユーザー・グリッド・ディスクへの実際のフォーマッティング書込みを除去します。

管理者は、フラッシュ・キャッシュをExtreme Flashセル上でライトスルー・モードに構成するように選択できます。列キャッシングはライトスルー・フラッシュ・キャッシュ・モードで動作しますが、書込みI/Oレイテンシ制限と高速データ・ファイル作成には、ライトバック・フラッシュ・キャッシュが有効になっていることが必要です。

14.6.17 Extreme Flashおよび大容量システムにおける1.6TBフラッシュ・ドライブの安全な消去

このリリースでは、Oracle Exadata System Softwareは、Extreme Flashおよび大容量システムでの1.6 TBフラッシュ・ドライブの安全な消去をサポートしています。1.6TBのフラッシュ・ドライブを安全に消去するには、約5.5時間かかります。

14.6.18 Exadataセルの接続制限の向上

現在、Oracle Exadata X5-2およびX4-2セルは、アクティブ-アクティブ・ボンディングを使用して、1台以上のデータベース・サーバーから発信された最大120,000の同時接続をサポートできます。つまり、最大120,000のプロセスを1つのセルに同時に接続してI/O操作を実行することができます。

14.6.19 SNMP v3のサポート

Oracle Exadata Database Machineのデータベース・サーバーおよびストレージ・サーバーは、アラート送信に関してSNMP v3をサポートします。SNMP v3は、サーバーから管理者とOracle Auto Service Request (ASR)に送信されるアラートに、認証と暗号化を提供します。

14.6.20 米国連邦情報処理標準(FIPS) 140-2準拠のスマート・スキャン

米国連邦情報処理標準(FIPS)140-2は、暗号化モジュールのセキュリティ要件を指定しています。FIPS 140-2要件のある顧客をサポートするために、Oracle Exadataバージョン12.1.2.1.0では、FIPS 140-2検証済暗号モジュールを使用するように構成できます。これらのモジュールは、暗号化サービス(たとえばOracle Databaseパスワード・ハッシュと検証)、ネットワーク暗号化(SSL/TLSとネイティブの暗号化)および保存データの暗号化(透過的なデータ暗号化)を提供します。

透過的データ暗号化が使用され、Oracle DatabaseがFIPS 140モード用に構成されている場合、Oracle Exadata Smart Scanオフロードは、暗号化列と暗号化表領域の暗号化および復号のための同一のFIPS 140検証済モジュールを自動的に活用します。

Oracle Databaseリリース12.1.0.2.0では、データベース・パラメータDBFIPS_140が、Oracle DatabaseおよびExadata Storage Server内部でFIPS 140暗号処理モードのオンとオフを切り替える機能を提供します。

Oracle Databaseリリース11.2.0.4.0では、アンダースコア付きのパラメータ_use_fips_modeが、Oracle DatabaseおよびExadata Storage ServerでFIPS 140暗号処理のオンまたはオフを切り替える機能を提供します。

DBFIPS_140を使用した例を次に示します。

ALTER SYSTEM SET DBFIPS_140 = TRUE;

パラメータ・ファイルでの例:

DBFIPS_140=TRUE

次のハードウェア・コンポーネントは、指定したリリースのファームウェア・アップデートでFIPS準拠になりました。

  • Oracle Server X5-2以降のシステムは、FIPS 140–2に準拠するように設計されています

  • ILOMリリース3.2.4を使用したOracle Sun Server X4-8

  • SW1.2.0およびILOMリリース3.2.4.20/22を使用したSun Server X4-2およびX4-2L

  • SW1.4.0およびILOMリリース3.2.4.26/28を使用したSun Server X3-2およびX3-2L

  • SW1.8.0およびILOMリリース3.2.7.30.aを使用したSun Server X2-2

  • Cisco Catalyst 4948E-Fイーサネット・スイッチ

Exadata Database Machine ServersのV1、X2-*およびデータベース・ノードX3-8世代のFIPS準拠は計画されていません。

最小ソフトウェア: Oracle Databaseリリース12.1.0.2.0 BP3、MES Bundle on Top of Quarterly Database Patch For Exadata (APR2014 - 11.2.0.4.6)を適用したOracle Databaseリリース11.2.0.4、Oracle Exadata Storage Server Softwareリリース12.1.2.1.0、ILOM 3.2.4。

関連項目:

FIPSの詳細は、『Oracle Databaseセキュリティ・ガイド』

14.6.21 Oracle Exadata仮想マシン

統合環境では、X5-2、X4-2、X3-2およびX2-2データベース・サーバー上で、ワークロード間をより高いレベルで分離するOracle Virtual Machine (Oracle VM)が使用されるようになりました。仮想マシンの分離は、信頼できないワークロードが共有環境でセキュリティ、CPUまたはメモリー使用状況を制限する場合に好都合です。たとえば、ホスティングされている環境、クラウド環境、クロス部門統合、テストおよび開発環境、データベース・マシンで実行されている非データベースまたはサード・パーティのアプリケーションなどです。異なるバージョンのClusterwareを必要とするワークロード(たとえば特定のClusterwareパッチおよびバージョンを必要とするSAPアプリケーション)を統合するためにOracle VMを使用することもできます。

仮想マシンを使用すると高度な分離が提供されますが、各仮想マシンに別々のオペレーティング・システムOS、Clusterwareおよびデータベースをインストールする必要があるため、リソース使用、管理負荷およびパッチング負荷の増大が代償として伴います。このため、1つの仮想マシン内で複数の信頼できるデータベースを統合することにより、Oracle VMをデータベース固有の統合と混用することが望まれます。Oracle Resource Managerを使用して、1つの仮想マシン内でデータベース用のCPU、メモリーおよびI/O使用を制御することができます。Oracle Multitenant Optionを使用すると、統合Oracle Databaseに、高度な統合とアジリティを提供することができます。

Exadata Virtual Machinesは、高速InfiniBandネットワークをSingle Root I/O Virtualization (SR-IOV)とともに使用して、仮想マシン内のパフォーマンスを、Exadataの有名なrawハードウェア・パフォーマンスに類似したものにします。Exadata Smart Scansは、仮想マシンへのメッセージ・トラフィックを激減させることによって、仮想化オーバーヘッドを、他のプラットフォームと比較して大幅に減少させます。Exadata Virtual Machinesは、その仮想マシンで動作しているアプリケーションのワークロード要件に基づいて、CPUとメモリーを動的に拡大または縮小できます。

Exadata上の仮想マシンは信頼できるパーティションとみなされるため、ソフトウェアを物理プロセッサ・レベルでなく仮想マシン・レベルでライセンスすることができます。信頼できるパーティションがない場合、データベース・オプションおよびその他のOracleソフトウェアは、そのサーバーまたはクラスタ上で実行されているすべてのデータベースが特定のオプションを必要としていなくても、サーバーまたはクラスタ・レベルでライセンスする必要があります。

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

前のリリース11.2.3.3.1の機能は、「Oracle Exadata Database Machine 11gリリース2 (11.2.3.3.1)の新機能」を参照してください。

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

14.7.1 LOBおよびCLOBの追加のSQL演算子および条件

Oracle Exadata Storage Server Softwareは、条件評価のために多数のSQL演算子および条件のオフロードをサポートしています。現在、次のSQL演算子および条件のオフロードは、Oracle Exadata Storage Server Softwareでサポートされています。

  • LOBおよびCLOB条件

    • LIKE

    • REGEXP_LIKE

LOBがインライン(表の行に格納されている)場合のみ、LOBの演算子および条件がスマート・スキャンによって評価されます。また、スマート・スキャンでは、セキュア・ファイル圧縮が行われます。セキュア・ファイル圧縮を使用すると、LOBをインラインにできるようにサイズが縮小されます。

最小ソフトウェア: LOB/CLOBのオフロードの場合、Oracle Databaseリリース12.1.0.2.

関連項目:

インラインLOBの詳細は『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。

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

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

14.8.1 Oracle Databaseリリース12c リリース1 (12.1)および11g リリース2 (11.2)のサポート

Oracle Exadata Storage Server Software 12cリリース1 (12.1)は、単一のOracle Exadata Database Machine上で実行されるOracle Databaseリリース12cリリース1 (12.1)および11gリリース2 (11.2)をサポートしています。データベース・サーバーは、Oracle Exadata Storage Server Softwareリリース 12c リリース1 (12.1)がインストールされたすべてのExadata Storage Serverから、スマート・スキャン、高速ファイル作成および高速増分バックアップなど、最高のパフォーマンスを実現します。

Oracle Exadata Storage Server Software 12cリリース1 (12.1)では、オフロード・リクエストを処理するための適切なセル・オフロード・サーバーを実行することにより、複数のデータベース・リリースをサポートできます。Oracle Database 11gリリース2 (11.2)から生成されるオフロード・リクエストは、リリース11gオフロード・サーバーによって処理され、Oracle Database 12cリリース1 (12.1)データベースから生成されるオフロード・リクエストは、12cオフロード・サーバーによって処理されます。

Oracle Exadata Storage Server Software 12c リリース1 (12.1)は、主要な各データベース・リリースに個別のオフロード・サーバーを含むようになったため、すべてのオフロード操作を完全にサポートすることができます。Oracle Database 11g リリース2 (11.2)から生成されるオフロード・リクエストは、自動的にリリース11gオフロード・サーバーによって処理され、Oracle Database 12c リリース1 (12.1)データベースから生成されるオフロード・リクエストは、自動的に12cオフロード・サーバーによって処理されます。

Exadata Storage Server 12c リリース1 (12.1)は、次のリリースのOracle Databaseをサポートできます。

データベース・リリース 最低限必要なリリース

11.2.0.2

バンドル・パッチ22

11.2.0.3

バンドル・パッチ20

11.2.0.4

現行のリリース

12.1.0.1

現行のリリース

14.8.2 CDBおよびPDBIORMサポート

Oracle Database 12cリリース1 (12.1)では、マルチテナント・アーキテクチャがサポートされています。マルチテナント・アーキテクチャにおいて、コンテナは、別個のデータベースとしてアプリケーションに論理的に表示されるOracle Multitenantコンテナ・データベース(CDB)の、スキーマ、オブジェクトおよび関連する構造体コレクションです。CDBでは、管理者は複数のプラガブル・データベース(PDB)を作成してワークロードを実行できます。CDBでは、共有リソースを競合する複数のPDB内に、複数のワークロードがあります。

CDB計画およびPDB計画を使用することにより、I/Oリソース管理(IORM)では、異なるPDB間のI/Oリソース使用率を管理し、各PDBにおけるワークロードを管理できます。

Oracle Database 12cリリース1 (12.1)は、IORMの優先度付けをサポートして、異なるPDB間でI/Oリソースの使用状況を管理したり、各PDB内のワークロードを管理します。

14.8.3 セルからセルへのデータ転送

以前のリリースでは、Exadataセルは、相互に直接通信しませんでした。セル間のデータの移動は、データベース・サーバー経由で行われていました。データは、ソース・セルからデータベース・サーバー・メモリーに読み取られ、次に宛先のセルに書き込まれていました。Oracle Exadata Storage Server Software 12c リリース1 (12.1)より、データベース・サーバー・プロセスは、セルへのデータ転送の負荷を軽減することができます。データベース・サーバーは、宛先のセルにソース・セルから直接データを読み取るよう指示し、データをそのローカル・ストレージに書き込みます。これにより、ファブリック間で転送されるデータの量が半分に削減され、InfiniBandバンド幅の消費とデータベース・サーバーのメモリー要件が削減されます。Oracle Automatic Storage Management (Oracle ASM)の再同期化、復元およびリバランスはこの機能を使用して、データ移動の負荷を軽減します。これにより、Oracle ASMインスタンスのInfiniBandファブリック・レベルでのバンド幅の使用率が向上します。この機能を利用するための構成は必要ありません。

ソフトウェアの最小要件: Oracle Database 12c リリース1 (12.1)以降およびOracle Exadata Storage Server Software 12c リリース(12.1)以降。

14.8.4 HP Oracle Database Machineハードウェアのサポート終了

Oracle Exadata System Software 12cリリース1 (12.1)は、HP Oracle Database Machineハードウェアではサポートされていません。Oracleは、引き続きOracle Exadata System Software 11gリリース2 (11.2)が実行されているHP Oracle Database Machinesをサポートしています。