この付録では、Oracle Exadata Database MachineおよびOracle Exadata Storage Server Softwareの新機能について説明します。
Oracle Exadata Database Machine 12cリリース2 (12.2.1.1.0)の新機能は次のとおりです。
Oracle Exadata Storage Server Softwareリリース12.2.1.1.0では、ストレージ・フラッシュ・キャッシュ内のデータに対して高速ベクトル処理インメモリー・アルゴリズムを使用できます。この機能は、Oracle Database In-Memoryオプションのライセンスを所有している場合に使用可能です。
Database In-Memory形式のキャッシュにより、純粋な列指向のHybrid Columnar Compression (HCC)形式で提供される以上に、Database In-Memory形式で保持されるデータの量が大幅に増加し、Smart Scanパフォーマンスが大幅に向上します。
Oracle Exadata Storage Server Softwareリリース12.1.2.1.0では、フラッシュ・キャッシュに純粋な列指向のHCC形式で自動的にHCCデータを格納する、列指向のキャッシュ形式が追加されました。このリリースでは、HCCデータのサポートが拡張され、キャッシュしたデータをDatabase In-Memory形式で再書込みすることや、超高速な単一命令複数データ(SIMD)の条件をSmart Scanで使用することができるようになりました。この形式では、結合や集計など、ほとんどのインメモリー・パフォーマンス拡張がSmart Scanでサポートされています。
標準表領域(暗号化されていない)および暗号化表領域からのデータを、インメモリー列指向キャッシュ形式でキャッシュできます。
Oracle Database In-Memoryを使用する場合と同様に、新しいDatabase In-Memory形式は、問合せのパフォーマンスに悪影響を及ぼさないようバックグラウンド・プロセスで作成されます。
この機能は、INMEMORY_SIZE
が構成されている場合はデフォルトで有効になっており、ユーザーがこの拡張機能を取得するために行う必要がある操作はありません。INMEMORY_SIZE
の詳細は、Oracle Databaseリファレンスを参照してください。INMEMORY_SIZE
が構成されていない場合は、12.1.2.1.0と同様のHCC形式の列指向キャッシュが以降も使用されます。
この機能を無効にする必要がある場合、ALTER TABLEコマンドとともに新しいDDLキーワードCELLMEMORY
を使用できます。『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』のストレージ・サーバーでのインメモリー列指向キャッシングの有効化または無効化に関する項を参照してください。
この機能は、Oracle Database 12cリリース1 (12.1.0.2)およびOracle Database 12cリリース2 (12.2.0.1)で使用できます。Oracle Database 12cリリース(12.1.0.2)を使用している場合、必要な最小ソフトウェア・バージョンは12.1.0.2.161018DBBPであり、バグ24521608に対するパッチをインストールする必要があることに注意してください。
関連トピック
Oracle Exadata Storage Serverリリース12.2.1.1.0では、列指向フラッシュ・キャッシュのサポートが暗号化表領域まで拡張されています。Oracle Database In-Memoryオプションのライセンスを所有している場合は、暗号化表領域データは、インメモリー列指向形式でストレージ・フラッシュ・キャッシュに格納されます。このオプションのライセンスがない場合、暗号化表領域データは、純粋な列指向HCC形式でストレージ・フラッシュ・キャッシュに格納されます。
この機能は、Oracle Database 12cリリース1 (12.1.0.2)およびOracle Database 12cリリース2 (12.2.0.1)で使用できます。Oracle Database 12cリリース(12.1.0.2)を使用している場合、必要な最小ソフトウェア・バージョンは12.1.0.2.161018DBBPであり、バグ24521608に対するパッチをインストールする必要があることに注意してください。
Oracle Exadata Storage Server Softwareリリース12.2.1.1.0では、インメモリー形式の列指向キャッシュを使用してデータが格納されている場合、Exadataは、ディクショナリ符号化を使用して圧縮されたこれらの列を格納します。固有値が200個より少ない列の場合、ストレージ索引は、ディクショナリの非常にコンパクトなインメモリー表現を作成し、このコンパクトな表現を使用して等価条件に基づいてディスク読取りをフィルタ処理します。この機能は、セット・メンバーシップと呼ばれます。より制限されたフィルタ処理機能が、固有値400個まで拡張されています。
たとえば、ディスクの1リージョンで米国およびカナダの顧客のリストを保持しているとします。メキシコの顧客を検索する問合せを実行する場合は、Oracle Exadata Storage Serverで、新しいセット・メンバーシップ機能を使用して、メキシコからの顧客を含まないリージョンを除外することで、問合せのパフォーマンスを向上させることができます。セット・メンバーシップ機能がない、12.2.1.1.0より前のリリースのOracle Exadata Storage Serverソフトウェアでは、通常のストレージ索引でディスクIOをフィルタ処理できません。
この機能は、Oracle Database 12cリリース1 (12.1.0.2)およびOracle Database 12cリリース2 (12.2.0.1)で使用できます。Oracle Database 12cリリース(12.1.0.2)を使用している場合、必要な最小ソフトウェア・バージョンは12.1.0.2.161018DBBPであり、バグ24521608に対するパッチをインストールする必要があることに注意してください。
12.2.1.1.0より前のリリースのOracle Exadata Storage Server Softwareでは、ストレージ索引で、8列までの列情報を保持できます。Oracle Exadata Storage Server Softwareリリース12.2.1.1.0では、ストレージ索引が、24列までの列情報を格納するよう拡張されました。
8列の列情報を格納するための領域が保証されています。8列を超える場合、領域は、列のセット・メンバーシップ・サマリーと列の最小/最大サマリーとで共有されます。ワークロードのタイプによって、セット・メンバーシップ・サマリーがストレージ索引に格納されるかどうかが決定されます。詳細は、ストレージ索引でのセット・メンバーシップを参照してください。
Oracle Exadata Storage Serverソフトウェアの更新に要する時間がさらに短縮されました。Oracle Exadata Storage Serverソフトウェアの更新処理が、12.1.2.3.0と比べて2倍、12.1.2.3.0より前のリリースと比べて5倍高速になりました。更新時間が短縮されることで、ソフトウェアの更新に必要なコストと労力が削減されます。
大量の結合操作または集計操作がメモリーに適さず、ストレージにあふれさせる必要がある場合は、一時書込みおよび一時読取りを使用します。12.2.1.1.0より前のリリースのOracle Exadata Storage Serverでは、一時書込みはフラッシュ・キャッシュでキャッシュされませんでした。一時書込みと後続の一時読取りは、どちらも、ハード・ディスクのみから行われていました。Oracle Exadata Storage Serverリリース12.2.1.1.0では、一時書込みは、後続の一時読取りを同様にフラッシュ・キャッシュから実行できるよう、フラッシュ・キャッシュに送信されます。これにより、問合せが一時I/Oバウンドである場合に、一時にあふれる問合せが大幅に高速化されます。一定の問合せについて、パフォーマンスを最大で4倍高速化できます。これは、一時表全体をフラッシュに配置するのに匹敵します。この機能を使用できるようにするためには、ライトバック・フラッシュ・キャッシュを有効にする必要があります。
Oracle Exadata Storage Serverリリース12.2.1.1.0以前では、フラッシュ・キャッシュへの書込みにはサイズのしきい値があります。128 KBを超えるほとんどの書込みは、ディスクに直接送られます。これは、これらの書込みがすぐに読み取られることが想定されていないためです。たとえば、直接ロード書込み、フラッシュバック・データベース書込み、アーカイブ済ログ書込みおよび増分バックアップ書込みは、フラッシュ・キャッシュを迂回します。Oracle Exadata Storage Serverリリース12.2.1.1.0以降では、フラッシュ・キャッシュのアルゴリズムは、そのような大量の書込みによって優先度がより高いOLTPまたはスキャン・ワークロードが中断されない場合に、そのような大量の書込みをフラッシュ・キャッシュにリダイレクトするよう拡張されました。そのような書込みは、後でディスクがそれほどビジーでなくなったときにディスクにライトバックされます。この機能により、Oracle Exadata Storage Serverで、追加の予備フラッシュ容量およびI/O帯域幅を利用して全体的なパフォーマンスを向上させることができます。
この機能がV2およびX2ストレージ・サーバーを除くすべてのOracle Exadataハードウェアでサポートされていることを覚えておいてください。X3およびX4ストレージ・サーバーでは、フラッシュ圧縮が有効になっている場合は、一時書込みおよび大量書込みのフラッシュ・キャッシングはサポートされません。
この機能は、すべてのOracle Databaseリリースで使用できます。Oracle Database 11gリリース2 (11.2)またはOracle Database 12cリリース1 (12.1)を使用している場合は、バグ24944847に対するパッチが必要なことに注意してください。この機能に関連する新しい統計およびレポートに関する項が2017年7月のDBBPで使用できるバグ25410017の一部として自動ワークロード・リポジトリ(AWR)レポートに追加されました。
Oracle Exadata Storage Serverソフトウェア・リリース12.2.1.1.0以降では、Oracle Exadata Database Machine内のすべてのコンポーネントに、セキュア・イレイザーという安全な消去のソリューションが用意されています。これは、2ソケット・サーバーと8ソケット・サーバーの両方を含めた、V2以上のすべてのExadata Database Machinesに対応する包括的なソリューションです。
Oracle Exadata Database Machineの以前のバージョンでは、DROP CELL ERASE
、DROP CELLDISK ERASE
、DROP GRIDDISK ERASE
などのCellCLIコマンドを使用してユーザー・データを安全に消去できます。ただし、これらのDROP
コマンドは、ハード・ドライブとフラッシュ・デバイスのユーザー・データにのみ対応しています。Secure Eraserは、ユーザー・データのみでなく、オペレーティング・システム、Oracle Exadataソフトウェア、ユーザー構成を含むすべてのコンテンツをサニタイズします。さらに、セキュア・イレイザーは、ハード・ドライブ、フラッシュ・デバイス、内部USB、ILOMを含む広範囲のハードウェア・コンポーネントに対応します。
セキュア・イレイザーは、データベース・サーバーとストレージ・サーバーのすべてのデータを消去し、InfiniBandスイッチ、イーサネット・スイッチおよび配電ユニットを出荷時のデフォルトにリセットします。Oracle Exadataマシンの使用を廃止するか目的を再設定する場合に、この機能を使用できます。セキュア・イレイザーは、マシンの各コンポーネント上のデータおよびメタデータのすべてのトレースを完全に消去します。
セキュア・イレイザー・ユーティリティの詳細は、Oracle Exadata Database Machineセキュリティ・ガイドを参照してください。
セル間のオフロード操作を効率的に実行するには、ストレージ・サーバーが、データベース・サーバーを介するのではなく他のストレージ・サーバーに直接アクセスする必要があります。
ご使用のExadata環境でASM範囲付セキュリティを構成してある場合は、ストレージ・サーバーがそれ自体を他のストレージ・サーバーに対して認証することで相互に直接通信できるようにするために、セル・キーを設定する必要があります。これは、Oracle ASMの再同期、ミラー分割完了、再構築およびリバランスの操作、およびデータベースの高スループット書込み操作に適用されます。
関連項目:
Oracle Exadata Storage Server Softwareユーザーズ・ガイドOracle Exadata Database Server X6-2は、非常に可用性の高い、マザーボード上の10 Gbps銅線ネットワーク、およびスロット2上のPCIカードを介した10 Gbps光ネットワークを提供します。Oracle Exadataソフトウェア・リリース12.2.1.1.0以降は、さらに接続性が必要な場合は、イーサネット・カードを追加できます。追加のカードにより、デュアルポート10 GbE光接続性(部品番号X1109A-Z)またはデュアルポート10 GbE銅線接続性(部品番号7100488)のどちらかを提供できます。この部品は、Oracle Exadata X6-2データベース・サーバー上のPCIeスロット1に取り付けることができます。
ネットワーク・カードを取り付けてネットワークに接続すると、Oracle Exadata Storage Serverソフトウェア・リリース12.2.1.1.0は、自動的にその新しいカードを認識してデータベース・サーバー上で2つのポートをeth6
およびeth7
インタフェースとして構成します。これらの追加ポートを、追加でクライアント・ネットワークを提供するためや、別にバックアップまたは障害回復ネットワークを作成するために使用できます。仮想マシンを実行するデータベース・サーバーでは、このネットワーク・カードを使用して、トラフィックを2つの仮想マシンから分離できます。
関連項目:
Oracle Exadata Database Machineメンテナンス・ガイドOracle Exadataソフトウェア・リリース12.2.1.1.0では、管理サーバー(MS)は、ASRマネージャと通信し、ASRに関する情報を含む診断パッケージを自動的にアップロードします。以前のリリースでは、自動サービス・リクエスト(SR)が開かれた後、他の診断情報を手動でアップロードする必要がありました。この手順を自動化することで、この機能は、ASRの応答時間を大幅に短縮します。
この機能は、2つの新しい属性をAlertHistory
オブジェクトに追加します。
新しいserviceRequestNumber
属性は、関連付けられているサービス・リクエスト番号を示します。
新しいserviceRequestLink
属性は、関連付けられているサービス・リクエスト番号へのURLを示します。
その他の重要機能を次に示します。
診断パッケージRESTfulページ(https://
hostname
/diagpack/download?name=
diagpackname
)には、対応するサービス・リクエストへのリンクを示す、新しい列があります。
ASRアラート電子メールに、SRリンクが含まれています。
ASRの自動Diagpackアップロードを有効化するには、ASRマネージャでhttp_receiver
を有効にする必要があります。
http_receiver
が有効になっているかどうかを確認するには、次のコマンドをASRマネージャから実行します。
asr show_http_receiver
http_receiver
を有効にするには、次のコマンド(portは、http_receiver
がリスニングするポート)を使用します。
asr enable_http_receiver -p port
注意:
ここで指定したポートは、データベース・サーバーまたはストレージ・サーバーでサブスクライバに指定したasrmPort
と同じである必要があります。次のコマンドは、データベース・サーバーおよびストレージサーバーでasrmPort
を確認する方法を示します。値が返されない場合、asrmPort
のデフォルトのポート16161が使用されます。
dbmcli -e list dbserver attributes snmpSubscriber ((host=test-engsys-asr1.example.com, port=162,community=public, type=asr,fromIP=10.242.0.55,asrmPort=16168)) cellcli -e list cell attributes snmpSubscriber
診断データをサービス・リクエストに自動的にアップロードする必要がない場合は、ALTER CELL diagPackUploadEnabled=FALSE
を実行して自動アップロードを無効にできます。
必要な最小ソフトウェア: ASR Manager Release 5.7
関連トピック
12.2.1.1.0より前のOracle Exadata Storage Serverソフトウェア・リリースでは、ストレージ・サーバーまたはデータベース・サーバーのレスキューの後、複数のコマンドを再実行して、IORM計画、しきい値、およびストレージ・サーバーおよびデータベース・サーバーの通知設定などの項目を構成する必要があります。Oracle Exadata Storage Serverソフトウェア・リリース12.2.1.1.0では、cell
およびdbserver
オブジェクトにはrescuePlan
という新しい属性があります。この属性を使用してコマンドのリストを取得でき、それにより、スクリプトとして格納し、セル・レスキューの後に実行して設定を復元できます。
rescuePlan
属性の詳細は、Oracle Exadata Database Machineメンテナンス・ガイドを参照してください。
Oracle Exadata 12.2.1.1.0では、Oracle Exadata Deployment Assistant (OEDA)を使用してIPv6 Oracle VMおよびタグ付き仮想LAN (VLAN)がサポートされています。
IPv6 VLANが、管理ネットワーク上でサポートされるようになりました。以前のリリースでは、これはサポートされていませんでした。
Oracle Exadata Database Machineインストレーションおよび構成ガイドを参照してください。
NTP、DNSまたはILOMパラメータの変更中は、その操作の間、管理サーバーをオンラインのままにでき、再起動する必要はありません。
関連項目:
Oracle Exadata Database Machineメンテナンス・ガイドOracle Exadata Storage Softwareリリース12.2.1.1.0では、GetExaWatcherResults.sh
は、IO、CPU使用率、セル・サーバー統計およびアラート履歴のチャートを含む、HTMLページを生成します。IOおよびCPU使用率のチャートではiostat
からのデータが使用されますが、セル・サーバー統計ではcellsrvstat
からのデータが使用されます。アラート履歴は、指定された時間枠の間に取得されます。
詳細は、Oracle Exadata Database Serverメンテナンス・ガイドのExaWatcherチャートを参照してください。
REDOログ書込みパフォーマンスの分析に役立つ、新しいメトリックを使用可能です。
以前は、Automatic Workload Repository (AWR)でデータベース・サーバーのREDOログ書込み待機時間に関する問題がレポートされたときに、ストレージ・セルでREDOログ書込みパフォーマンスに問題がないと示されることがよくありました。新しいメトリックは、より詳細な全体像を得るために役立ちます。これらのメトリックは、次の懸念事項を理解する上での手掛かりとなります。
I/Oレイテンシが高いかどうか、または他の要因(たとえば、ネットワーク)であるかどうか。
フラッシュ・ログを迂回したREDOログ書込みの数。
フラッシュ・ログで処理されたREDOログ書込みのみでなく、すべてのREDOログ書込みを考慮に入れた、各セルでのREDOログ書込みの全体のレイテンシ。
Oracle Exadataソフトウェア・リリース12.2.1.1.0では、REDOログ書込みリクエストに関連する次のメトリックが導入されています。
FL_IO_TM_W
: 累積的なREDOログ書込みレイテンシ。Oracle 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ログ書込みリクエストの合計数。Oracle Exadataスマート・フラッシュ・ログで処理されていないリクエストが含まれます。
Oracle Exadataスマート・フラッシュ・ログに処理されていないREDOログ書込みリクエストの数を取得するには、(FL_RQ_W - FL_IO_W
)を使用します。
隔離マネージャのサポートは、セル間オフロード操作でのリバランスおよび高スループット書込みのために有効になっています。これらの操作の間にOracle Exadataでクラッシュが検出された場合は、問題を起こす操作が隔離され、あまり最適化されていないパスを使用して操作が続行されます。
新しい隔離のための隔離タイプは、ASM_OFFLOAD_REBALANCE
およびHIGH_THROUGHPUT_WRITE
です。
詳細は、Oracle Exadata Storage Server Softwareユーザーズ・ガイドのセル間オフロード操作の隔離マネージャ・サポートを参照してください。
ストレージ・サーバーで使用可能な診断パッケージ機能が、データベース・サーバーでも使用可能になりました。データベース・ノード上の管理サーバーは、データベース・サーバー・アラート生成時の関連するログおよびトレースを含む、カスタマイズされた診断パッケージを自動的に収集します。これは、重要なすべてのデータベース・サーバー・アラートに適用されます。診断情報の適時収集は、重要なログのロールオーバーを防ぎます。
データベース・ノード上の管理サーバーは、重要なすべての電子メール・アラートで、診断パッケージを電子メール添付ファイルとして送信します。ユーザーは、新しいCREATE DIAGPACK
DBMCLIコマンドを使用して開始時刻および継続時間を指定することで、毎時間カスタム診断パッケージを作成できます。
詳細は、Oracle Exadata Database Machineメンテナンス・ガイドのCREATE DIAGPACKおよびLIST DIAGPACKを参照してください。
ExaCLIおよびREST APIは両方とも、データベース・ノード上の管理サーバー(MS)のために有効になっています。
現在、MSコマンドのリモート実行を行うことができます。WebブラウザのHTTPSを使用してインタフェース(curl)にアクセスできます。詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』を参照してください。
Oracle Grid Infrastructure 12cリリース2 (12.2.0.1)における次の新機能は、Oracle Exadataに影響します。
Oracle ASMフレックス・ディスク・グループとは、Oracle ASMファイル・グループをサポートするディスク・グループ・タイプです。
Oracle ASMファイル・グループは、データベースに属するファイルのグループを表し、ファイル・グループまたはデータベースのレベルでストレージ管理の実行を可能にします。一般に、フレックス・ディスク・グループを使用すると、ユーザーはディスク・グループ・レベルに加えて、データベースの粒度でストレージを管理できるようになります。
Oracle Automatic Storage Management管理者ガイドのフレックス・ディスク・グループの管理を参照してください。
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は、カーディナリティがALL
に設定されて出荷されます。これは、Oracle ASMインスタンスが、使用可能なすべてのノード上で作成されるということです。詳細は、次の各項を参照してください。
Oracle Automatic Storage Management管理者ガイドのManaging Oracle Flex ASMの管理
Oracle Automatic Storage Management管理者ガイドのOracle Flex ASMの設定について
Oracle Grid Infrastructureインストレーションおよびアップグレード・ガイドfor LinuxのOracle Flex ASMクラスタのネットワークについて
Oracle Grid Infrastructure 12c リリース2 (12.2)の使用では、以前のリリースよりもストレージ損失の後の冗長性回復に時間がかかりません。
新しいREBUILD
フェーズがリバランス操作に導入されました。REBUILD
フェーズがストレージ障害後に最初に冗長性を回復するため、2番目の障害が発生するリスク期間が大幅に削減されます。後続のBALANCE
フェーズが、バランスを回復します。
関連トピック
ASM_POWER_LIMITパラメータの値を動的に調整できます。
ALTER
DISKGROUP文でPOWER句を指定しなかった場合や、ディスクの追加または削除によってリバランスが暗黙的に実行される場合は、リバランス指数はデフォルトでASM_POWER_LIMIT
初期化パラメータの値になります。このパラメータの値は動的に調整できます。POWER
句の値の範囲は、ASM_POWER_LIMIT
初期化パラメータと同じです。
指数が大きくなるほど、リバランス操作の完了は早くなります。指数の値が小さいほどリバランスにかかる時間は長くなりますが、データベースなどの他のアプリケーションで共有される処理とI/Oの消費リソースは少なくなります。
Oracle Automatic Storage Management管理者ガイドのリバランス操作のチューニングを参照してください。
Oracle Grid Infrastructureのインストール中に、定数障害グループを指定できます。
Oracle Exadataサーバーでは、デプロイメント中に定数ディスク・グループが自動的に作成されます。定数障害グループは、Oracle Clusterware投票ファイルを格納する特殊なタイプの障害グループです。定数障害グループは、指定した障害グループの定数が使用可能であることを確認するために使用されます。
Oracle Grid Infrastructure 12.2のインストーラは、定数ディスク・マネージャ・ユーティリティを使用してインストール後に定数障害グループを構成するかわりに、インストール中に定数障害グループを指定できるよう、更新されました。
Oracle Grid Infrastructureインストレーションおよびアップグレード・ガイドfor LinuxのOracle Automatic Storage Managementのストレージ要件の特定を参照してください。
Oracle Database 12cリリース2 (12.2.0.1)における次の新機能は、Oracle Exadataに影響します。
ごくたまに、ネットワーク・レイテンシの異常値、ストレージ・サーバーでのハードウェア問題、またはストレージ・サーバーに関するその他のシステム問題が原因で、データベース・サーバーとストレージ・サーバーとの間で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)
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
Oracle Exadata Storage Serverソフトウェアでは、条件評価のために多数のSQL操作のオフロードがサポートされています。インメモリー集計機能は、ベクトル変換の最適化を実行しようとします。これは、スター型結合SQL問合せを特定の集計操作(たとえば、SUM
、MIN
、MAX
および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
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
Oracle Exadata Storage Server 12.2.1.1.0では、LOB演算子LENGTH
、SUBSTR
、INSTRM
CONCAT
、LPAD
、RPAD
、LTRIM
、RTRIM
、LOWER
、UPPER
、NLS_LOWER
、NLS_UPPER
、NVL
、REPLACE
、REGEXP_INSTR
、TO_CHAR
のオフロード・サポートが拡張されました。
Exadataスマート・スキャン・オフロード評価は、圧縮されていないインライン化されたLOB(サイズは4 KB未満)でのみサポートされています。
必要な最小ソフトウェア: Oracle Database 12cリリース2 (12.2.0.1.0)およびOracle Exadata Storage Serverソフトウェア・リリース12.2.1.1.0
階層型スナップショット・データベース
親(それ自体がスナップショット)から領域使用効率のよいスナップショット・データベースを作成できます。これにより、階層型スナップショット・データベースが可能になります。親スナップショットも、ベース・テスト・マスターにわたるまで、領域使用効率が優れています。複数のユーザーが、同じ親スナップショットから固有のスナップショットを作成できます。一連のスナップショットをツリーとして表現できます。この場合、ツリーのルートはベース・テスト・マスターです。ツリー内のすべての内接点は読取り専用データベースであり、ツリー内のすべてのリーフは読取り/書込みデータベースとなります。すべての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
このリリースでは、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ホーム上の両方にインストールすることをお薦めします。
Oracle Exadata Database Machine 12cリリース1 (12.1.2.3.0)の新機能は次のとおりです。
Oracle Exadata Storage Server 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を適用
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 Storage Server Softwareは、ハード・ディスクがアイドル状態のときに定期的にハード・ディスクを自動で検査して修復します。修正のデフォルト・スケジュールは2週間置きです。
ただし、ハード・ディスクで不良セクターが発生し始めるようになったら、より多くの不良セクターが発生する可能性があるため、ディスクをもっと頻繁に修正することが推奨されます。リリース12.1.2.3.0では、現在の修正ジョブでハード・ディスクに不良セクターが検出された場合、Oracle Exadata Storage Server Softwareはそのディスクに対して1週間以内にフォローアップ修正ジョブをスケジュールします。そのディスクの修正ジョブで不良セクターが検出されなかった場合、hardDiskScrubInterval属性で指定された修正スケジュールに戻ります。
hardDiskScrubIntervalを週次以下に変更した場合、不良セクターが検出された場合でも、Oracle Exadata Storage Server Softwareは週次フォローアップ・スケジュールではなくユーザーが構成した間隔を使用します。修正の詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』のALTER CELLに関する項を参照してください。
必要な最小ソフトウェア:
Oracle Exadata Storage Server Softwareリリース12.1.2.3.0
グリッド・インフラストラクチャ・ホーム:
11.2.0.4.16 (2015年4月)以上
12.1.0.2.4 (2015年1月)以上
IPv6を使用するシステムで、ASR Manager 5.4を使用してAuto Service Request (ASR)に接続できるようになりました。
表A-1に、データベース・ノード当たりサポートされる最大データベース・プロセス数を示します。これらの数は以前のリリースよりも高くなっています。ベスト・プラクティスは、プロセス数をこれらの値よりも低く抑えることです。ワークロードのサブセットがパラレル問合せを実行中の場合、最大データベース・プロセス数はパラレル問合せを含まない最大ロセス数列と実行中のすべてのパラレル問合せを含む最大プロセス数列の間になります。
表A-1 ノード当たりの最大データベース・プロセス数
マシン・タイプ | 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 |
表A-2に、Oracle VMユーザー・ドメイン当たりのサポートされる最大データベース・プロセス数を示します。これらの数は以前のリリースよりも高くなっています。ベスト・プラクティスは、プロセス数をこれらの値よりも低く抑えることです。ワークロードのサブセットがパラレル問合せを実行中の場合、最大データベース・プロセス数はパラレル問合せを含まない最大プロセス数列と実行中のすべてのパラレル問合せを含む最大プロセス数列の間になります。
表A-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 (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適用)
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適用)
Oracle Exadata Database Machine 12cリリース1 (12.1.2.2.0)の新機能は次のとおりです。
最小ソフトウェア要件: 12.1.0.2 BP13
多くのOLTPワークロードでは、Oracle Real Application Clusters (Oracle RAC)の複数のノードで頻繁に更新する必要があるホット・ブロックが発生することがあります。その一例がRight Growing Index (RGI)で、新しい行が複数のOracle RACノードからの索引付きで表に追加されます。索引のリーフ・ブロックが、すべてのノードで頻繁に更新する必要があるホット・ブロックになります。
ExadataのスマートFusionブロック転送機能がない場合、送信側ノードがREDOログで恒久的なREDOログ・バッファに変更を加えた後にのみ、ホット・ブロックを送信側ノードから受信側ノードに転送できます。スマートFusionブロック転送により、送信側ノードでの、このREDOログ書込みの待ち時間は解消されます。ブロックは、REDOログへのIOが送信側ノードで発行されると、その完了を待たずにただちに転送されます。スマートFusionブロック転送により、RGIワークロードのスループットが増加し(約40%増)、レスポンス時間が短縮されます(約33%減)。
スマートFusionブロック転送を有効にするには:
すべてのOracle RACノードで、非表示の静的パラメータ"_cache_fusion_pipelined_updates
"をTRUE
に設定します。これは静的パラメータであるため、この変更を反映させるにはデータベースを再起動する必要があります。
すべてのOracle RACインスタンスで、"exafusion_enabled
"パラメータを1
に設定します。
このソフトウェア・リリースで、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サポートはイーサネット向けです。
計算ノードとストレージ・サーバーでは、管理ネットワーク、ILOMおよびクライアント・アクセス・ネットワークでPv6を使用できるようになりました。これは、ベア・メタルおよび仮想化の両方のデプロイメントで有効です。次の表に、各種コンポーネントによるIPv6サポートの方法を示します。
コンポーネント | IPv6サポートの説明 |
---|---|
Oracle Exadata Deployment Assistant (OEDA) |
OEDAでは、ユーザーが顧客ネットワークの定義画面(図A-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 Support |
今後のPlatinum Gatewayソフトウェア・リリースが提供されるまで、Platinum SupportはIPv6デプロイメントでは使用できません。 |
図A-1 Oracle Exadata Deployment Assistantの顧客ネットワークの定義画面
新しいExaCLIユーティリティでは、セル・ノード上のCellCLIコマンドを計算ノードからリモート実行できます。これは、SSHアクセスを無効にしてセル・ノードをロックした場合に役立ちます(「ストレージ・サーバーでのSSHの無効化」を参照)。
ExaCLIには、セルの管理に対応した使いやすいインタフェースも用意され、ストレージ・ユーザーの各種ロールをストレージ管理者から分離できます。
ExaCLIを実行するには、セル・ノード上でユーザーを作成し、そのユーザーにロールを付与する必要があります。ロールを付与するとユーザーに権限が割り当てられ、ユーザーの実行可能なCellCLIコマンドが指定されます。セルへの接続時に、ExaCLIは指定されたユーザー名を認証し、そのユーザーに指定されたコマンドを実行するための適切な権限があるかどうかを確認します。
新しいexadcliユーティリティはdcliユーティリティに似ています。exadcliを使用すると、複数のセルにまたがってCellCLIコマンドを実行できます。
詳細は、次を参照してください。
『Oracle Exadata Database Machineメンテナンス・ガイド』のExaCLIユーティリティの使用
『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』のexadcliユーティリティの使用
ロールに権限を付与し、ユーザーにロールを付与することで、ユーザーが実行できるコマンドを制御できます。たとえば、ユーザーにlist griddisk
コマンドを実行可能にしalter griddisk
を実行不可にするよう指定できます。このレベルの制御は、システムへの完全なアクセスをごく少数のユーザーにのみ許可するクラウド環境で役立ちます。
新しいExaCLIユーティリティを使用する場合は、ユーザーの作成も必要です。CREATE USER
、GRANT PRIVILEGE
およびGRANT ROLE
コマンドを使用して、ユーザーの作成、ロールへの権限の指定、およびユーザーへのロールの付与を行います。詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』のユーザーとロールの作成に関する項を参照してください。
デフォルトでは、ストレージ・サーバーでSSHが有効化されています。必要な場合は、ストレージ・サーバーをロックしてSSHアクセスを無効化できます。ExaCLIを使用すれば、引き続きセル上で各種操作を実行できます。ExaCLIは計算ノード上で実行され、httpsやREST APIを使用して、セル上で実行されているWebサービスと通信します。
セルへのログインを必要とする操作を実行するときは、一時的にセルのロックを解除できます。操作が完了したら、再びセルをロックできます。
詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』のストレージ・サーバーでのSSHの無効化に関する項を参照してください。
ALTER IORMPLAN
コマンドにはflashcachesize
と呼ばれる新しい属性が用意され、これによりフラッシュ・キャッシュ内の固定領域をデータベースに割り当てることができます。flashcachesize
に指定された値は強い制限であり、この指定値を超える領域をデータベースで使用することはできません。これは、弱い上限のflashcachelimit
値とは異なります(フラッシュ・キャッシュがいっぱいでなければ、データベースはこのflashcachelimit値を超過できます)。
flashcachesize
は、クラウドや従量課金制などのデプロイメントでデータベースをそれぞれの割当て済領域に制限する必要がある環境において理想的です。
詳細は、次の項を参照してください。
『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』のI/Oリソースの管理に関する項
『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』のALTER IORMPLANコマンドに関する項
AWRレポートのExadataフラッシュ・キャッシュ・パフォーマンス統計情報セクションが、次のように強化されました。
列フラッシュ・キャッシュとKEEPキャッシュのサポートの追加。
Exadataストレージ・セルの統計情報とデータベースの統計情報が要約されたフラッシュ・キャッシュ・パフォーマンス・サマリーに関するセクションの追加。
AWRレポートのExadataフラッシュ・ログ統計情報セクションに、ディスクおよびフラッシュへの最初の書込みの統計情報が含まれるようになりました。
最小ソフトウェア: Oracle Databaseリリース12.1.0.2バンドル・パッチ11
最小ソフトウェア要件: 12.1.0.2 BP11または11.2.0.4 BP18
次の表に、データベース・ノード当たりサポートされる最大データベース・プロセス数を示します。これらの数は以前のリリースよりも高くなっています。ベスト・プラクティスは、プロセス数をこれらの値よりも低く抑えることです。ワークロードのサブセットがパラレル問合せを実行中の場合、最大データベース・プロセス数はパラレル問合せを含まないプロセス数列と実行中のすべてのパラレル問合せを含むプロセス数列の間になります。
表A-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個のデータベースが最大プロセス数で実行されると、セルの接続制限を超過します。
関連トピック
ストレージ・サーバーは、セル・アラートが生成されると、カスタマイズされた診断パッケージ(関連するログおよびトレースを含む)を自動的に収集します。これは、ハードウェア・アラートとソフトウェア・アラートの両方を含むすべてのセル・アラートに適用されます。診断情報を適切なタイミングで収集することにより、重要なログのロールオーバーが抑制されます。
管理サーバーは、電子メール・アラートごとに電子メール添付ファイルとして診断パッケージを送信します。また、ユーザーが次のURLにアクセスして、
https://hostname/diagpack
既存の診断パッケージをダウンロードすることも可能です(電子メールの添付ファイルがなかった場合)。ExaCLIを使用してパッケージをダウンロードすることもできます。前述のURLで、hostnameはセルのホスト名のことです。
ユーザーは、新しい"CREATE DIAGPACK
" CellCLIコマンドを使用して開始時間と期間を指定することにより、カスタム診断パッケージを毎時作成できます。
詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』のCREATE DIAGPACKに関する項を参照してください。
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によるデータベース・ノードの更新に関する項を参照してください。
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
"を実行すると、オフライン・ディスクと異常なディスクがすべて表示されます)、先にデータ冗長性をリストアする必要があります。オフライン・ディスクが他にある場合は、そのディスクをオンラインに戻して再同期が終了するのを待機します。障害ディスクを強制削除するために実行中のリバランス、またはフラッシュ・キャッシュのエラーを書き戻した後でデータ・ブロックを復元するために実行中のミラー復元がある場合、リバランスまたはミラー復元が完了するまで待機する必要があります。データ冗長性がリストアされたら、ストレージ・サーバーの停止を続行できます。
eth0に関連付けられているIPアドレスがASRマネージャに登録されていない場合、ALTER CELL
コマンド(ストレージ・サーバーの場合)またはALTER DBSERVER
コマンド(データベース・サーバーの場合)の新しいfromIP
フィールドを使用して、別のIPアドレスを指定できます。
詳細は、Oracle Exadata Storage Server 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つのセルから別のセルにリバランスされると、ソース・セルでキャッシュされていたデータはターゲット・セルでもキャッシュされます。
Oracle Exadata Database Machine 12cリリース1 (12.1.2.1.2)の新機能は次のとおりです。
InfiniBandパーティション化はExadata仮想環境で使用できるようになり、Oracle Exadata Deployment Assistant (OEDA)と組み合せて構成できます。
OEDAのグラフィカル・ユーザー・インタフェースを使用してInfiniBandパーティションをクラスタごとに定義し、OEDAのコマンドライン・インタフェースを使用し、適切なパーティション・キーとメンバーシップ要件を設定して、ゲストとInifniBandスイッチを構成し、InfiniBandパーティションを有効にします。
InfiniBandパーティションはクラスタごとに定義できます。ストレージ・サーバーが複数のクラスタ間で共有されている場合、すべてのクラスタで同じストレージ・パーティション・キーを使用します。
Oracle Exadata Database Machine 12cリリース1 (12.1.2.1.1)の新機能は次のとおりです。
NVMeフラッシュ・ファームウェアに変更が加えられ、バックグラウンドのリフレッシュ・アルゴリズムおよび操作に対してリソースや変更を処理するI/Oタスクが改善されています。このリリースでは、フラッシュのパフォーマンスが同じかわずかに向上しています。
統合環境では、X5-2、X4-2、X3-2およびX2-2データベース・サーバー上で、ワークロード間をより高いレベルで分離するOracle Virtual Machine (Oracle VM)が使用されるようになりました。仮想マシンの分離は、信頼できないワークロードが共有環境でセキュリティ、CPUまたはメモリー使用状況を制限する場合に好都合です。
Oracle Exadata Infrastructure as a Service (IaaS)のユーザーがキャパシティ・オンデマンド機能を使用して、データベース・サーバーのアクティブ・コア数を制限し、必要なデータベース・ソフトウェア・ライセンスの数を制限できるようになりました。Exadata 12.1.2.1.1 Softwareでは、CoDとIaaSを同じシステムに配置することができます。コアの予約済セットのオンとオフを切り替える機能(IaaS-CoD)はIaaSに含まれることに注意してください。
このリリースには、統合ブロック・キャッシュと列キャッシュのメトリックが含まれ、フラッシュ・キャッシュ・パフォーマンスをさらに詳しく分析できるようになりました。
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に更新されています
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メンテナンス・ガイド』を参照してください。
Oracle Exadata Database Machine 12cリリース1 (12.1.2.1.0)の新機能は次のとおりです。
エラスティック構成を使用すると、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)を追加できます。
関連項目:
スパース・グリッド・ディスクは、新しいデータがディスクへ書き込まれるときに領域を割り当てるため、仮想サイズが実際の物理サイズよりはるかに大きくなることがあります。スパース・グリッド・ディスクは、スパース・ディスク・グループを作成して、割り当てられた領域の小部分を使用するデータベース・ファイルを格納するために使用されます。スパース・ディスク・グループは、短時間で効率的にデータベースのスナップショットをOracle Exadata上に作成するのに特に役立ちます。従来のデータベースを、スパース・ディスク・グループを使用して作成することもできます。
最小ハードウェア: ストレージ・ノードX3以上
最小ソフトウェア: Oracle Database 12cリリース1(12.1)リリース12.1.0.2 BP5以上。
テストと開発目的のために、スペース効率のよいデータベース・スナップショットをすぐに作成できるようになりました。スナップショットは、機密情報を消去した本番データベース(またはプラガブル・データベース(PDB))の共有読取り専用コピーで開始します。各スナップショットは、変更がなされるたびに、変更されたブロックをスパース・ディスク・グループへ書き込みます。
複数のユーザーが、同じベース・データベースから別々のスナップショットを作成することもできます。このため、複数のテストおよび開発環境が、各タスク用のデータベースを別々に維持しつつ、領域を共有することができます。Exadata Storageサーバー上でスナップショットを使用すると、Smart Scanなど、Oracle Exadata Storage Server Softwareの機能を使用して、テストおよび開発をすることができます。
Exadataデータベース・スナップショットは、マルチテナント・データベース・オプションと統合されているため、きわめて簡素なインタフェースで新しいPDBスナップショットを作成することができます。
最小ハードウェア: ストレージ・ノードX3以上
最小ソフトウェア: Oracle Database 12cリリース1(12.1)リリース12.1.0.2 BP5以上。
Oracle Exadata Storage Server Softwareリリース12.1.2.1.0は、混合ワークロードを効率的にサポートしているため、OLTPと解析の両方でパフォーマンスを最適にできます。これは、トランザクショナル処理ではハイブリッド列形式で、分析処理ではそれに最適化された純粋な列形式で、データを格納することを可能にするExadata Smart Flash Cacheのデュアル・フォーマット・アーキテクチャにより実現されています。
さらに、ハイブリッド列圧縮は、OLTPと分析のニーズを均衡させます。ハイブリッド列圧縮を使用すると最高レベルのデータ圧縮が可能になり、特に分析ワークロードでI/Oが削減されるためコストが大幅に節約されてパフォーマンスが向上します。
Oracle Exadata Storage Server Software 12.1.2.1.0では、フラッシュ・キャッシュ移入時に、分析処理を最適化するために、Smart Flash Cacheソフトウェアがハイブリッド列圧縮データを純粋な列形式に変換します。フラッシュ内の純粋な列データに対するスマート・フラッシュ・キャッシュは、選択された列のみを読み取るため、高速で実行され、フラッシュI/Oとストレージ・サーバーのCPU使用量を低減します。
Oracle Exadata Storage Server Softwareリリース12.1.2.1.0は、ハイブリッド列圧縮表データを純粋な列形式レイアウトでフラッシュ・キャッシュにキャッシュすることができます。Exadata Smart Scanを使用してExadataハイブリッド列圧縮にアクセスすると、ハイブリッド列圧縮の圧縮されたデータがフラッシュ・キャッシュの記憶領域と同じ量で純粋な列形式レイアウトに再フォーマットされます。
大規模表の、圧縮ユニット(CU)内での所定の列のデータのパーセンテージは、小規模表と比較して小さくなります。これにより、列全体のデータを取得するために、ディスクとフラッシュからより多くのCUがフェッチされます。大規模なExadataハイブリッド列圧縮表の少数の列のみを読み取る問合せは、ストレージから無関係な列も読み取るため、広いI/O帯域幅を使用します。データを列形式でフラッシュ・キャッシュに格納すると、無関係な列を読む必要が軽減され、パフォーマンスが大きく改善します。
ワークロードのタイプ(OLTPまたはデータ・ウェアハウス)によって異なりますが、同じリージョンのデータを、従来のブロック形式と列形式の両方でフラッシュ・キャッシュ上にキャッシュできます。
この機能はデフォルトで有効になっており、ユーザーによる構成を必要としません。
列形式のフラッシュ・キャッシュを使用すると、OLTPスタイルの単一列参照でも優れたパフォーマンスを維持しつつ、レポーティングと分析的問合せが高速化されます。
列形式フラッシュ・キャッシュは、よくスキャンされるハイブリッド列圧縮の圧縮されたデータを、フラッシュ・キャッシュへのロード時に純粋な列形式に自動変換することによって、Oracle Exadataフラッシュのデュアル・フォーマット・アーキテクチャを実装しています。フラッシュ内の純粋な列データに対して実行されるスマート・スキャンは、選択された列のみを読み取るため、高速で実行され、フラッシュI/Oとストレージ・サーバーのCPUを低減します。
データが頻繁にOLTP参照される場合、元のハイブリッド列圧縮形式データもフラッシュ・キャッシュにキャッシュできます。このため、Exadataスマート・フラッシュ・キャッシュは、よく使用されるあらゆるタイプの操作を高速化するために、キャッシュされたデータの形式を自動的に最適化します。
この機能はデフォルトで有効になっており、ユーザーによる構成を必要としません。
最小ソフトウェア: Oracle Database 12cリリース12.1.0.2.0を実行するOracle Exadata Storage Server Softwareリリース12.1.2.1.0
関連項目:
フラッシュ・キャッシュのメトリックの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください。
この機能では、遅い読取りによって異常値を排除できます。それ以外ではアプリケーションに表示される読取りの異常値を防止します。
ディスク・ドライブ、ディスク・コントローラおよびフラッシュ・デバイスは、デバイスが内部メンテナンスまたはリカバリ操作を実行している間、場合により、待機時間が長くなることがある複雑なコンピュータです。また、障害が発生しかけているデバイスは、その発生前に待機時間が長くなる場合があります。以前は、高い待機時間を示すデバイスは、場合によりSQL応答時間が長くなることがありました。書込み操作のOracle Exadata Storage Server SoftwareのI/Oレイテンシ制限では、レイテンシが長いI/O動作をミラー・コピーに自動リダイレクトすることによって、Oracle Exadata上でのSQL I/O応答時間を確実に改善します。
Oracle Exadata Storage Server Softwareリリース11.2.3.3.1および12.1.1.1.1では、Oracle Exadataがフラッシュ・デバイスから読取りを試行し、読取りI/Oのレイテンシが適切な長さより長い場合に、Oracle ExadataがI/O読取り操作を自動的に別のセルにリダイレクトします。I/O読取りを開始したデータベースにメッセージが送信され、それによってデータベースは、読取りI/Oをデータの別のミラー・コピーにリダイレクトします。データの最新の有効なミラー・コピーに対して実行された読取りI/Oは、リダイレクトされません。
Oracle Exadata Storage Server Softwareリリース12.1.2.1.0では、レイテンシの長い書込み操作を検出すると、Oracle Exadataは、同じセルの別の正常なフラッシュ・デバイスに自動的に書込み操作をリダイレクトします。書込みが正常に完了したら、データベースで書込み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)
セルのライトバック・フラッシュ・キャッシュの有効化
ディスク・ドライブとフラッシュ・ドライブは、内部ソフトウェアがロックされるために、場合により、実際に物理的に故障していなくても故障しているように見えることがある複雑なコンピュータです。X5-2大容量セル上のハード・ディスク障害と見られる現象またはX5-2 Extreme Flashセル上のフラッシュ・ドライブ障害と見られる現象が発生した場合、Oracle Exadata Storage Server SoftwareはI/Oを他のドライブに自動的にリダイレクトし、ドライブをパワー・サイクルします。パワー・サイクルの後、ドライブが正常ステータスに戻ると、再び有効化され、再同期されます。パワー・サイクルの後もドライブの障害が継続する場合、それは削除されます。Oracle Exadata Storage Server Softwareのこの機能により、誤検知されたディスク障害を除去することが可能になり、データ冗長度を維持しつつ管理負荷を低下することができます。
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以降。
最小値または最大値機能を使用する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。
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。
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のためのドライバ・サポートが含まれます。
データベース・サーバー上の管理サーバー(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ポートおよびシステムのメトリックとしきい値を監視できます。
関連項目:
DBMCLIの詳細は『Oracle Exadata Database Machineメンテナンス・ガイド』
Oracle Exadata Storage Server Softwareは、条件評価のために多数のSQL演算子のオフロードをサポートしています。現在、次のSQL演算子のオフロードがOracle Exadata Storage Server 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。
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-*
フラッシュ・キャッシュは、共有リソースです。フラッシュ・キャッシュ領域のリソース管理を使用すると、データベース間IORM計画を使用して、フラッシュ・キャッシュ内でデータベースが使用できる最小および最大サイズを指定できます。フラッシュ・キャッシュ領域のリソース管理を使用すると、データベース・リソースIORM計画を使用して、フラッシュ・キャッシュ内でプラガブル・データベースが使用できる最小および最大サイズを指定することもできます。
最小ソフトウェア: Oracle Database 11gまたはOracle Database 12cリリース1 (12.1)リリース12.1.0.2を実行するExadataセル・ソフトウェア・リリース12.1.2.1.0
最小ハードウェア: ExadataリリースX2-*
関連項目:
Oracle Exadata Storage Server Softwareユーザーズ・ガイド
現在、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。
Extreme Flashセルでは、フラッシュ・キャッシュはデフォルトでライトバック・モードで動作し、フラッシュ領域の5パーセントを占有します。Extreme Flashセル上のフラッシュ・キャッシュはブロック・キャッシュとして使用されません。ユーザー・グリッド・ディスクがすでに作成されており、したがってフラッシュ・キャッシュが必要でないためです。ただし、それでもフラッシュ・キャッシュは、次の高度な操作に有効です。
列キャッシュは、フラッシュ・キャッシュ上のExadataハイブリッド列圧縮(EHCC)表データを、Extreme Flashセル上に純粋な列形式レイアウトでキャッシュします。
書込みI/Oレイテンシ制限は、一時的に停止したフラッシュへの書込みI/O動作をキャンセルし、Extreme Flashセル上の別の正常なフラッシュ・デバイスのライトバック・フラッシュ・キャッシュに記録するべき書込みをリダイレクトします。
高速データ・ファイル作成は、Extreme Flashセル上で、ライトバック・フラッシュ・キャッシュのブロックに関するメタデータを維持し、ユーザー・グリッド・ディスクへの実際のフォーマッティング書込みを除去します。
管理者は、フラッシュ・キャッシュをExtreme Flashセル上でライトスルー・モードに構成するように選択できます。列キャッシングはライトスルー・フラッシュ・キャッシュ・モードで動作しますが、書込みI/Oレイテンシ制限と高速データ・ファイル作成には、ライトバック・フラッシュ・キャッシュが有効になっていることが必要です。
このリリースでは、Oracle Exadata Storage Server Softwareは、Extreme Flashおよび大容量システムでの1.6TBフラッシュ・ドライブの安全な消去をサポートしています。1.6TBのフラッシュ・ドライブを安全に消去するには、約5.5時間かかります。
関連項目:
現在、Oracle Exadata X5-2およびX4-2セルは、アクティブ-アクティブ・ボンディングを使用して、1台以上のデータベース・サーバーから発信された最大120,000の同時接続をサポートできます。つまり、最大120,000のプロセスを1つのセルに同時に接続してI/O操作を実行することができます。
関連項目:
Oracle Exadata Database Machineのデータベース・サーバーおよびストレージ・サーバーは、アラート送信に関してSNMP v3をサポートします。SNMP v3は、サーバーから管理者と自動サービス・リクエストに送信されるアラートに、認証と暗号化を提供します。
関連項目:
『Oracle Exadata Database Machineメンテナンス・ガイド』
Oracle Exadata Storage Server Softwareユーザーズ・ガイド
米国連邦情報処理標準(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セキュリティ・ガイド』
統合環境では、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ソフトウェアは、そのサーバーまたはクラスタ上で実行されているすべてのデータベースが特定のオプションを必要としていなくても、サーバーまたはクラスタ・レベルでライセンスする必要があります。
Oracle Exadata Database Machine 12cリリース1 (12.1.1.1.1):の新機能は次のとおりです。
Oracle Exadata Database Machine 12cリリース1 (12.1.1.1.1)およびOracle Exadata Database Machine 11gリリース2 (11.2.3.3.1)の新機能は次のとおりです。
前のリリース11.2.3.3.1の機能は、「Oracle Exadata Database Machine 11gリリース2 (11.2.3.3.1)の新機能」を参照してください。
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およびラージ・オブジェクト開発者ガイド』を参照してください。
Oracle Exadata Database Machine 12cリリース1(12.1.1.1.0)の新機能は次のとおりです。
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 |
現行のリリース |
Oracle Database 12cリリース1 (12.1)では、マルチテナント・アーキテクチャがサポートされています。マルチテナント・アーキテクチャにおいて、コンテナは、別個のデータベースとしてアプリケーションに表示されるマルチテナント・コンテナ・データベース(CDB)の、スキーマ、オブジェクトおよび関連する構造体コレクションです。CDBにおいて、管理者は、ワークロードを実行するための1つ以上のプラガブル・データベース(PDB)を作成できます。CDBでは、共有リソースを競合する複数のPDB内に、複数のワークロードがあります。CDB計画およびPDB計画を使用することにより、I/Oリソース管理(IORM)では、異なるPDB間のI/Oリソース使用率を管理し、各PDBにおけるワークロードを管理できます。
Oracle Database 12c リリース1 (12.1)は、I/Oリソース管理(IORM)の優先度付けをサポートしているため、異なるプラガブル・データベース(PDB)間でのI/Oリソース使用率を管理したり、各PDB内のワークロードを管理することができます。
関連項目:
マルチテナント・アーキテクチャの詳細は、『Oracle Database概要』を参照してください。
IORMの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください。
以前のリリースでは、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)以降。
Oracle Exadata Database Machine 11gリリース2(11.2.3.3.1)の新機能は次のとおりです。
ユーザーは、データベース・サーバーのアクティブ・コア数を制限することにより、必要なデータベース・ソフトウェアのライセンス数を制限できます。プロセッサ・コアの削減は、Oracle Exadata Database Machine Deployment Assistant (OEDA)を使用したソフトウェア・インストール時に実装されます。アクティブ・コア数は、後でより大きな容量が必要になった場合に増やすことができますが、減らすことはできません。アクティブ・プロセッサ・コアは、データベースの各ソケットにおいて同数必要です。
キャパシティ・オンデマンドは、Oracle Exadata Infrastructure as a Service (IaaS)と次の点で異なります。
キャパシティ・オンデマンドでは、初期インストール後にアクティブ・コア数を減らせません。
キャパシティ・オンデマンドを使用する場合、必要なソフトウェア・ライセンスはアクティブ・コア用のみです。
注意:
アクティブ・コア数を削減することにより、ソフトウェア・ライセンスの初期コストを抑えられます。ハードウェアのコストは変わりません。
関連項目:
アクティブ・コア数の増加の詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』を参照してください。
ライセンスおよび制限の詳細は、『Oracle Exadata Database Machineライセンス情報ユーザーズ・ガイド』を参照してください。
ディスク・ドライブまたはフラッシュ・デバイスは、まれに、内部リカバリ操作の実行中、わずかな時間に対し待機時間が長くなる場合があります。また、障害が発生しかけているドライブは、その発生前に待機時間が長くなる場合があります。この機能によってI/O読込み操作がミラー・コピーにリダイレクトされるため、非常にまれに発生するこうしたレイテンシ・スパイクはマスクされます。
Oracle Exadata Storage Server Softwareでは、読取りI/Oのレイテンシが適切な長さよりはるかに長くなった場合に、I/O読取り操作が自動的に別のセルにリダイレクトされます。リダイレクトは、I/O読取りを開始したデータベースにメッセージが返されることによって実行されます。データベースによって、データの別のミラー・コピーにI/Oがリダイレクトされます。データの最新の有効なミラー・コピーに対して実行されたI/Oは、リダイレクトされません。
最小ソフトウェア: Oracle Database 11gリリース2 (11.2)、Monthly Database Patch For Exadata (2014年6月 - 11.2.0.4.8)。Grid Infrastructureにも、同じリリースが必要です。
Exadataセルに対して、I/Oタイムアウトしきい値を構成できます。セルI/Oは、定義されたしきい値を超える時間がかかると、キャンセルされます。I/Oは、Oracle Automatic Storage Management (Oracle ASM)によって、データの別のミラー・コピーにリダイレクトされます。データの最後の有効なミラー・コピーに対して発行された書込みI/Oは、タイムアウトしきい値を超えた場合でも取り消されません。
タイムアウトしきい値を低く設定しすぎると、システムのパフォーマンスに悪い影響を与えることがあります。ピークI/Oロードに関する自動ワークロード・リポジトリ(AWR)レポートを確認し、しきい値をピークI/Oレイテンシより大きな値に、十分なセーフティ・マージンを空けて設定することをお薦めします。
最小ソフトウェア: Oracle Database 11gリリース2 (11.2)、Monthly Database Patch For Exadata (2014年6月 - 11.2.0.4.8)。Grid Infrastructureにも、同じリリースが必要です。
関連項目:
I/Oしきい値タイムアウトのALTER CELL
属性に関する詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください。
Oracle Exadata Database Machine 11gリリース2(11.2.3.3.0)の新機能は次のとおりです。
フラッシュ・キャッシュの圧縮では、ユーザー・データがフラッシュ・キャッシュにロードされる際にデータを透過的に圧縮することによって、フラッシュ・キャッシュの論理容量が大幅に増加します。そのため、より多くのデータをフラッシュに維持することができ、ディスク・ドライブのデータにアクセスする必要が減ります。フラッシュのデータへのI/Oは、ディスク上のデータへのI/Oよりも大幅に速くなります。圧縮操作および解凍操作は、アプリケーションおよびデータベースに対して完全に透過的で、1秒当たり何百万I/Oという速度で実行してもパフォーマンスのオーバーヘッドはありません。
ユーザー・データの圧縮率に応じて、Oracle Exadata Storage Server Softwareは、フラッシュ・キャッシュ・サイズを最大2倍に動的に拡張します。圧縮の効果はデータの冗長性に応じて変わります。圧縮されていない表および索引の場合は、削減される領域が最も多くなります。OLTP圧縮された表および索引の場合は、領域が大幅に削減されます。ハイブリッド列圧縮を使用する表の場合は、削除される領域が最も少なくなります。フラッシュ・キャッシュ圧縮を有効にするには、Oracle拡張圧縮オプションが必要です。
この機能は、CellCLI ALTER CELL flashCacheCompress=true
コマンドを使用して有効にします。
最小ハードウェア: Exadata Storage Server X4-2L Server
Oracle Exadata Storage Server Softwareは、オブジェクトが読み取られる頻度に基づいて、表およびパーティションのスキャン・ワークロードで読み取られたオブジェクトをフラッシュ・キャッシュに自動的にキャッシュします。アルゴリズムでは、オブジェクトのサイズ、オブジェクトのアクセス頻度、キャッシュから削除されたデータへのオブジェクトによるアクセス頻度、およびデータベースによって実行されているスキャンのタイプが考慮されます。フラッシュ・キャッシュ・サイズおよびその他の同時発生するワークロードに応じて、表またはパーティションのすべてまたは一部のみがキャッシュされます。フラッシュ・キャッシュのサイズに比べて大きいオブジェクトのキャッシュを試行したり、メンテナンス操作でアクセスされる表をキャッシュすることによって、フラッシュ・キャッシュをスラッシングするリスクはありません。
この新機能により、フラッシュ・キャッシュに表を手動で維持する必要性がほとんどなくなりますが、例外として、特定のオブジェクトの場合は、合計ディスクI/Oを潜在的に増やすことにより、応答時間が確実に長くなります。以前のリリースでは、データベース管理者が大きなオブジェクトをKEEP
とマークして、表スキャン・ワークロード用のフラッシュ・キャッシュにキャッシュする必要がありました。
この機能は主に、データ・ウェアハウス、データ・マートなどの表スキャン集中型のワークロードに効果があります。オンライン・トランザクション処理(OLTP)に実行されるようなランダムI/Oは、以前のリリースと同じ方法で引き続きフラッシュ・キャッシュにキャッシュされます。
最小ソフトウェア: Oracle Exadata Storage Server Softwareリリース11.2.3.3
高速データファイル作成では、新規データファイルがフォーマットされる速度が2倍以上になります。フラッシュ・キャッシュでは、新しくフォーマットされたブロックをディスクまたはフラッシュに書き込むのではなく、単にブロックに関するメタデータをライトバック・フラッシュ・キャッシュに保持することにより、ディスクへの書込みの実際のフォーマットを排除します。たとえば、高速データファイル作成を使用すると、リリース11.2.3.3を実行しているOracle Exadataフル・ラックに1TBのデータファイルを作成する際に90秒かかります。以前のリリースで同じ1TBのデータファイルを作成すると、220秒かかります。この機能は、ライトバック・フラッシュ・キャッシュが有効であり、適切なソフトウェア・リリースが使用されている場合に自動的に機能します。
最小ソフトウェア: Oracle Database 11gリリース2 (11.2)リリース11.2.0.4またはOracle Database 12cリリース1 (12.1)リリース12.1.0.1を実行するOracle Exadata Storage Server Softwareリリース11.2.3.3
ネットワーク・リソース管理では、InfiniBandファブリックを使用して重要なデータベース・ネットワーク・メッセージに自動的かつ透過的に優先度を付け、レイテンシが重大な影響を及ぼす操作に関する高速の応答時間を実現します。優先度付けは、InfiniBandファブリック全体に適用されるように、データベース、データベースのInfiniBandアダプタ、Oracle Exadata Storage Server Software、ExadataストレージのInfiniBandアダプタおよびInfiniBandスイッチに実装されます。
Oracle RACキャッシュ・フュージョン・メッセージなど、レイテンシの影響を受けるメッセージには、バッチ、レポート作成およびバックアップ・メッセージよりも高い優先度が付けられます。ログ・ファイル書込み操作には、トランザクション処理時間のレイテンシを低下させるために最上位の優先度が付けられます。
この機能はCPUおよびI/Oリソース管理と連携し、統合環境での高パフォーマンスと予測可能性を実現します。たとえば、オンライン・トランザクション処理(OLTP)のワークロードがあると仮定した場合、コミット・レイテンシはログ書込みの待機時間によって決定されます。この機能により、ログ・ライター・プロセス(LGWR)のネットワーク転送に、バックアップ、レポート作成など、同一または他のデータベースにおける他のデータベース・トラフィックよりも高い優先度を付けることができます。
この機能はデフォルトで有効になっており、構成または管理は必要ありません。
最小ソフトウェア: Oracle Database 11gリリース2 (11.2)リリース11.2.0.4またはOracle Database 12cリリース1 (12.1)リリース12.1.0.1、およびスイッチ・ファームウェア・リリース2.1.3-4を実行するOracle Exadata Storage Server Softwareリリース11.2.3.3
Oracle Exadata Database Machine X4-2データベース・サーバーおよびストレージ・サーバーでは、InfiniBandカードの両方のポートのアクティブ・ボンディングのサポートが有効になります。ネットワーク・トラフィックの送信に両方のInfiniBandポートが同時に使用されるため、アクティブ・ボンディングでは以前のリリースのアクティブ・パッシブ・ボンディングに比べてネットワーク帯域幅がさらに高くなります。
アクティブ・ボンディング機能は、以前のInfiniBandカードよりもさらに高いスループットをサポートする新しいInfiniBandカードを特長としているため、Oracle Exadata Database Machine X4-2のネットワーク帯域幅を向上させます。以前のInfiniBandカードは最新世代のサーバーのPCIバスによって提供されるより高速な帯域幅を活用できるほど速くなかったため、アクティブ・ボンディングで古い世代のハードウェアの帯域幅は向上しません。
InfiniBandカードのアクティブ・ボンディングについて、次の点に注意してください。
Oracle Linuxを実行するデータベース・サーバーには、アクティブ・ボンディング機能があります。
Oracle Clusterwareでは、クラスタ内の各データベース・サーバーに同じインターコネクト名が必要です。既存のOracle Exadata Database Machine X3-2およびOracle Exadata Database Machine X2-2システムをOracle Exadata Database Machine X4-2システムで拡張する場合、データベース・サーバーにレガシー・ボンディングを保持することをお薦めします。
ネットワーク帯域幅を向上させるためには、InfiniBandカード1つ当たりに2つのIPアドレスが必要です。
次の表に、システムの構成方法のガイドラインを示します。
オペレーティング・システム | Oracle Exadata Database Machine X4-2のデータベース・サーバー | Oracle Exadata Database Machine X4-2のストレージ・サーバー | Exadata Storage Server X4-2L Serverを使用したOracle Exadata Database Machine X3-8フル・ラックのデータベース・サーバー |
---|---|---|---|
Oracle Linux |
アクティブ・ボンディング |
アクティブ・ボンディング |
従来のボンディング、HCAにつき1つのポートがアクティブ |
Oracle Solaris |
IPMP、1つのポートがアクティブ |
アクティブ・ボンディング |
IPMP、HCAにつき1つのポートがアクティブ |
最小ハードウェア: Oracle Exadata Database Machine X4世代サーバー
最小ソフトウェア: Oracle Exadata Storage Server Softwareリリース11.2.3.3
Oracle ASM appliance.mode
属性を使用すると、1つ以上のOracle ASMディスクを削除するときにディスクのリバランス完了時間が改善されます。これは、障害後に冗長性がより高速にリストアされることを意味します。属性は、新しいディスク・グループの作成時に自動的に有効になります。既存のディスク・グループでは、ALTER DISKGROUP
コマンドを使用して明示的に属性を設定する必要があります。
属性は、次の要件を満たすディスク・グループのみで有効にできます。
Oracle ASMディスク・グループ属性compatible.asm
が、リリース11.2.0.4以降に設定されている。
cell.smart_scan_capable
属性がTRUE
に設定されている。
ディスク・グループ内のすべてのディスクが同じタイプである(すべてハード・ディスクまたはExtreme Flashディスクなど)。
ディスク・グループのすべてのディスクが同じサイズである。
ディスク・グループのすべての障害グループのディスク数が等しい。
ディスク・グループにオフラインのディスクがない。
最小ソフトウェア: Oracle Database 11gリリース2 (11.2)リリース11.2.0.4またはOracle Database 12cリリース1 (12.1)リリース12.1.0.2を実行するOracle Exadata Storage Server Softwareリリース11.2.3.3
関連項目:
appliance.mode
属性の詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください。
Oracle Exadata Storage Server Softwareは、ハード・ディスクがアイドル状態のときに定期的にハード・ディスクを自動で検査して修復します。ハード・ディスクで不良セクターが検出された場合、Oracle Exadata Storage Server Softwareは、別のミラー・コピーからデータを読み取ることによって不良セクターを修復するようOracle ASMに自動的にリクエストを送信します。デフォルトでは、ハード・ディスクの修正は2週間ごとに実行されます。
最小ソフトウェア: Oracle Database 11gリリース2 (11.2)リリース11.2.0.4またはOracle Database 12cリリース1 (12.1)リリース12.1.0.2を実行するOracle Exadata Storage Server Softwareリリース11.2.3.3
関連項目:
修正間隔の設定の詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください。
障害ステータスではない正常なハード・ディスクを交換する場合、Oracle Exadata Database Machine管理者は事前にALTER PHYSICALDISK DROP FOR REPLACEMENT
コマンドを実行して成功することを確認した後で、Exadataセルからハード・ディスクを削除する必要があります。このコマンドでは、ディスク・グループの強制ディスマウントを発生させずにそのハード・ディスクのグリッド・ディスクをOracle ASMから安全にオフラインにできることを確認します。ディスク・グループの強制ディスマウントを発生させずにすべてのグリッド・ディスクをオフラインにできる場合、このコマンドによってグリッド・ディスクがOracle ASMからオフラインにされ、ハード・ディスクが無効になり、ストレージ・サーバーのサービスLEDがオンになります。
最小ソフトウェア: Oracle Exadata Storage Server Softwareリリース11.2.3.3
関連項目:
ALTER PHYSICALDISK
コマンドの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください。
Oracle Exadata Database Machineデータベース・サーバーまたはストレージ・セルでオンラインのBBU (バッテリ・バックアップ・ユニット)を交換する前に、Oracle Exadata Database Machine管理者はALTER CELL BBU DROP FOR REPLACEMENT
コマンドを実行してこのコマンドが成功することを確認する必要があります。このコマンドによって、コントローラがライトスルー・キャッシングに変更され、停電時にBBUが交換される際にデータ損失が発生しなくなります。
最小ハードウェア: ディスクフォームファクタBBUを搭載したOracle Exadata Database Machine X3-2またはOracle Exadata Database Machine X3-8フル・ラック
最小ソフトウェア: Oracle Exadata Storage Server Softwareリリース11.2.3.3
関連項目:
BBUの交換の詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』を参照してください。
ALTER CELL BBU DROP FOR REPLACEMENT
コマンドの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください。
ストレージ・セルのOracle Exadata Database Machineエイス・ラックの構成は、ALTER CELL eighthRack
コマンドを使用して有効または無効にできます。エイス・ラックの構成を使用すると、ハード・ディスクに6個以下のセル・ディスクが作成され、フラッシュ・ディスクに8個以下のセル・ディスクが作成されます。
最小ソフトウェア: Oracle Exadata Storage Server Softwareリリース11.2.3.2.1
関連項目:
Oracle Exadata Database Machineエイス・ラックの構成の詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』を参照してください。
Oracle Exadata Storage Server Softwareは、Exadataセルのすべてのオープン・アラートのサマリーを電子メールで定期的に送信します。オープン・アラート電子メール・メッセージには、セル上のすべてのオープン状態の問題の簡潔なサマリーが示されています。サマリーには次の内容が含まれます。
セル名
イベント時間
アラートの重大度
アラートの説明
アラート・サマリーの構成に関する情報
前のサマリー以降に作成されたアラートには、アスタリスクが付けられます。
最小ソフトウェア: Oracle Exadata Storage Server Softwareリリース11.2.3.3
関連項目:
アラート・サマリーの構成の詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください。
このリリースでは、Oracle Exadata Storage Server Softwareは、大きいハード・ドライブおよびフラッシュ・ドライブの安全な消去をサポートしています。次に、サポートされているアルゴリズムを使用してドライブを安全に消去するための所要時間を示します。
ドライブのタイプ | 1パス(1pass) | 3パス(3pass) | 7パス(7pass) |
---|---|---|---|
1.2 TBドライブ |
1.67時間 |
5時間 |
11.67時間 |
4 TBドライブ |
8時間 |
24時間 |
56時間 |
186 GBフラッシュ・ドライブ |
該当なし |
該当なし |
36分 |
関連項目:
ILOMは、管理サーバーのIntegrated Lights-Out Manager (ILOM)ハング検出モジュールにより、未然防止策として定期的にリセットされます。これは、ILOMが長期間稼働した後に、不安的な状態に陥るのを防ぐためです。リセット間隔は、90日です。
最小ソフトウェア: Oracle Exadata Storage Server Softwareリリース11.2.3.3.0
このリリースから、Oracle OSwatcherはOracle Exawatcherに置き換わりました。Oracle Exawatcherには、Oracle OSwatcherより高度なコレクションおよびレポート機能が備わっています。
関連項目:
Oracle Exawatcherの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください。
ハードウェアおよびソフトウェアに次の拡張が追加されています。
Sun Datacenter InfiniBand Switch 36スイッチの拡張
Oracle Exadata Database MachineのSun Datacenter InfiniBand Switch 36スイッチは、patchmgrユーティリティを使用してローリング方式でアップグレードされます。詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』を参照してください。
スイッチ・ソフトウェア・リリース2.1.3-4には、断続的なリンクを自動的に無効にする機能があります。InfiniBandの仕様には、リンクのビット・エラー率は1012よりも小さい必要があると規定されています。シンボル・エラーの数が1日当たり3546ビット・エラーまたは1時間当たり144ビット・エラーよりも多い場合、リンクは無効になります。InfiniBandスイッチのソフトウェアにはautodisable
コマンドがあり、スイッチがリリース2.1.3-4にアップグレードされる場合、この機能はpatchmgrユーティリティによって自動的に有効になります。
新しいスイッチのソフトウェア・リリース2.1.3-4では、2台のスイッチ、またはファブリック内の複数のスパイン・スイッチ間に不均衡な数のリンクがあるファットツリー・トポロジを作成できます。
サブネット・マネージャのフェイルオーバーの実行にかかる時間は、複数ラック構成でも1秒未満に削減されます。
パッチ・アプリケーションの拡張
patchmgrユーティリティには、パッチ適用の完了時の電子メール・メッセージと、ローリングおよび非ローリング・パッチ・アプリケーションのステータスを送信する機能があります。詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』およびパッチ・セットを参照してください。
ILOM/BIOS、InfiniBand HCAおよびディスク・コントローラのデータベース・サーバーのファームウェア・アップグレードは、Oracle LinuxおよびOracle Solarisを実行するラックでコンポーネントを交換する際に自動的に実行されます。
ハードウェアの堅牢性の強化
ハード・ディスクの不良セクターからリカバリする時間は、12倍に削減されています。
ハード・ドライブまたはフラッシュ・ドライブの障害状態はまれにしかブールになりません。ほとんどのドライブでは、障害が発生する前に大幅に速度が低下します。遅くて断続的なドライブがより早期に検出され、ドライブがpredictive failure
またはハード障害状態になる前にOracle Exadata Storage Server Softwareにより機能が停止されます。
ストレージ・サーバーのILOMが応答を停止すると、管理ソフトウェアはILOMを自動的にリセットできます。
Oracle Solaris 11.1 (SRU 9.5.1)のサポート
このリリースでは、データベース・サーバーでOracle Solaris 11.1 SRU 9.5.1をサポートしています。
Oracle Exadata Database Machine 11gリリース2(11.2.3.2)の新機能は次のとおりです。
Exadataスマート・フラッシュ・キャッシュは、頻繁にアクセスされるデータを高速なソリッド状態の記憶装置に透過的にキャッシュし、問合せの応答時間とスループットを向上させます。ディスクではなくフラッシュによって処理される書込み操作は、「ライトバック・フラッシュ・キャッシュ」と呼ばれます。ライトバック・フラッシュ・キャッシュでは、1秒当たりの書込みI/OをX3システムで20倍、X2システムで10倍多く実行できます。X3システムではフラッシュ容量がより大きいため、ほぼすべての書込みがフラッシュによって処理されます。
アクティブなデータ・ブロックを、ライトバック・フラッシュ・キャッシュに数か月または数年間保持できます。最近読取りが実行されていないブロックの場合、主要なコピーのみがキャッシュに保持されます。必要に応じて、すべてのデータはディスクにコピーされます。これにより、性能のよいフラッシュ領域を効率よく使用できます。
フラッシュ・キャッシュに問題がある場合、操作はフラッシュのミラー・コピーに透過的にフェイルオーバーされます。ユーザーが介入する必要はありません。フラッシュのデータは、割当て単位に基づいてミラー化されます。これは、書き込まれるデータ量がディスク・サイズではなく損失したキャッシュ・サイズに比例することを示します。
関連項目:
ライトバック・フラッシュ・キャッシュおよびライトスルー・フラッシュ・キャッシュの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください。
セルまたはディスクがオフラインになり、管理者がCELLSRVサービスを再起動または停止しようとすると、冗長性が低下しているために、セルを停止できないというメッセージが管理者に通知されます。
ストレージ・サーバー・ディスクを取り外す必要がある場合は、青色のLEDライトがサーバーに表示されます。青色のライトにより、保守が必要なサーバー・ディスクを簡単に確認できます。
ディスクのパフォーマンスが低下すると、作業がすべてのディスクに均等に分散されるため、すべてのディスクのパフォーマンスが影響を受けます。たとえば、あるディスクのパフォーマンスが他のディスクよりも30%低下すると、システム全体のI/O容量が30%低下します。
パフォーマンスが低下しているディスクが検出されると、そのディスクはアクティブな構成から削除されます。次に、Oracle Exadata Database Machineが一連のパフォーマンス・テストを実行します。ディスクの問題が一時的な場合は、テストに合格すると、そのディスクは構成に戻ります。ディスクがテストに合格しない場合は、poor performanceとしてマークされ、ディスクを交換するための自動サービス・リクエスト(ASR)のサービス・リクエストが開きます。この機能は、ハード・ディスクとフラッシュ・ディスクの両方に適用されます。
Oracle Database File System(DBFS)では、Oracleデータベースの非構造化データを管理します。DBFSのファイルはSecureFilesのデータベースに格納され、パフォーマンス、スケーラビリティ、セキュリティ、可用性、および圧縮、重複除外、暗号化、テキスト検索、XQueryなどの豊富な機能の利点のすべてを継承します。
以前のリリースでは、DBFSはLinuxを実行するOracle Exadata Database Machineでしか利用できませんでした。このリリースでは、DBFSは、Oracle Solarisを実行するOracle Exadata Database Machineでもサポートされます。
関連項目:
DBFSの詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。
ハード・ディスクがExadataセルで予測障害に入ると、Oracle Exadata Storage Server SoftwareがOracle ASMリバランスを自動的にトリガーし、ディスクからデータを移動します。Oracle ASMリバランスでは、最初に正常なミラーから読み取り、冗長性をリストアします。他すべてのミラーが利用できない場合、Oracle ASMリバランスは予測障害ディスクからデータを読み取ります。最適なリバランスを進めることができる場合は、これにより予測障害ディスクからのリバランス読取りが回避され、リバランス・プロセスで最大限のデータ冗長性を維持できます。
ディスク・グループ内の正常な他のディスクにデータを完全に移動する前に、Oracle Exadata Storage Server Softwareは、予測障害ディスクの悪い状態をデータベース・インスタンスに通知し、そのディスクのデータに対する問合せとスマート・スキャンを他のミラーに迂回して、応答時間を改善します。
Exadata Storage Server X3-2 Serverのドライブは、各行で左から右に番号付けされます。下段のドライブの番号は0、1、2および3です。中段のドライブの番号は4、5、6および7です。上段のドライブの番号は8、9、10および11です。
図A-2 Exadata Storage Server X3-2 Serverのディスク・レイアウト
Sun Fire X4270 M2サーバーおよび以前のサーバーを使用したExadata Storage Serverのドライブは左下から上へと番号が付けられ、左端の列のドライブが0、1および2となっていました。次の列のドライブは3、4および5になりました。その次の列のドライブは6、7および8になりました。右端の列のドライブは9、10および11になりました。
図A-3 Sun Fire X4270 M2 Serverを使用したExadata Storage Serverのディスク・レイアウト
Oracle Exadata Database Machine 11gリリース2(11.2.3.1)の新機能は次のとおりです。
Oracle Exadata Storage Server Software 11gリリース2(11.2)リリース11.2.3.1以降は、最小パックが非推奨になりました。データベース・サーバーの更新手順では、更新の配信にUnbreakable Linuxネットワーク(ULN)を使用し、yumユーティリティを使用して更新を適用します。
関連項目:
データベース・サーバーの更新に関する詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』を参照してください。
Oracle Exadata Database Machineは、Oracle Enterprise Manager Cloud Controlを使用して管理できます。Oracle Enterprise Manager Cloud Controlでは、サーバー、オペレーティング・システム、ファームウェア、仮想マシン、ストレージおよびネットワーク・ファブリックの管理を単一のコンソールに結合します。
I/Oリソース管理(IORM)では、共有ベースのプランがサポートされるようになり、データベース間のプランで最大1024のデータベースと1024の指令をサポートできます。共有ベースのプランでは、割合ではなく、共有に基づいてリソースを割り当てます。共有とは、I/Oリソースの相対分布です。また、新しいdefault
指令で、データベース・プランで明示的に指定されていないすべてのデータベースのデフォルト値を指定します。
関連項目:
IORMの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください。
Oracle Exadata Storage Server Software 11gリリース2 (11.2)リリース11.2.3.nのスマート・スキャンは、Oracle Databaseソフトウェア11gリリース2 (11.2)リリース11.2.0.3に存在しているテクノロジに基づいており、11.2.0.nリリースのデータベースと下位互換性があります。
Oracle Database、Oracle ASM、Oracle ClusterwareおよびOracleユーティリティは、ExadataセルでI/O操作を実行します。ExadataセルでI/O操作のプロセスを実行するには、プロセスでセルとの接続を最初に確立する必要があります。プロセスがExadataセルと接続されると、プロセス終了まで接続は維持されます。
このリリースでは、各Exadataセルで1台以上のデータベース・サーバーから最大60,000の同時接続をサポートできます。つまり、60,000を超えるプロセスを1つのセルに同時に接続してI/O操作を実行することはできません。リリース112.2.4での接続数の上限は32,000でした。リリース11.2.2.4より前は、接続数の上限は20,000でした。
Oracle Exadata Database Machine 11gリリース2(11.2.2.4)の新機能は次のとおりです。
ユーザー・トランザクションをコミットする時間は、ログ書込みのレイテンシにより大きく影響を受けます。また、領域管理や索引分割などのパフォーマンス・クリティカルな多くのデータベース・アルゴリズムも、ログ書込みのレイテンシにより影響を受けます。Oracle Exadata Storage Server Softwareでは、バッテリバックアップ式のDRAMキャッシュをディスク・コントローラで使用して、ログ書込みの速度を上げています。ディスク・コントローラ・キャッシュへの書込みは、通常は非常に高速ですが、ディスクI/Oが高い間は遅くなる場合があります。Oracle Exadataスマート・フラッシュ・ログでは、Exadata Storage Serverのフラッシュ・メモリーを利用することで、ログの書込みを高速化しています。
フラッシュ・メモリーの書込みレイテンシは平均して非常に少ないですが、平均より1から2等級遅くなるような異常値を示す場合もあります。Oracle Exadataスマート・フラッシュ・ログでは、フラッシュ・メモリーとディスク・コントローラ・キャッシュの両方に同時にREDO書込みを実行し、2つのうち最初の書込みが完了すると、書込みを完了します。これにより、ユーザー・トランザクションの応答時間が短縮し、I/Oが集中するワークロードで全体のデータベース・スループットを向上します。
Oracle Exadataスマート・フラッシュ・ログでは、REDOログ・データの一時的な格納にExadataフラッシュ・ストレージのみを使用します。Oracle Exadataスマート・フラッシュ・ログでは、デフォルトでフラッシュ・ディスクごとに32MB、各Exadataセル全体で合計512MBを使用します。自動的に構成および有効化されます。追加の構成は不要です。
Oracle Exadata Database Machine 11gリリース2(11.2.2.3)の新機能は次のとおりです。
Oracle Exadata Database Machineのデータベース・サーバーには、Linuxオペレーティング・システムおよびOracle Solarisオペレーティング・システムがあります。初期構成時に、各自の環境のオペレーティング・システムを選択します。オペレーティング・システムを選択したら、もう一方のオペレーティング・システムが使用しているディスク領域を再利用できます。
Oracle Exadata Storage Server Softwareには、再デプロイする前に物理ディスクを安全に消去してクリーンアップする方法が用意されています。ERASE
オプションでは、1パス、3パスまたは7パスでディスク上の既存の内容を上書きします。1パス・オプションでは内容を0(ゼロ)で上書きします。3パス・オプションはNNSA(米国国家核安全保障局)の勧告に準拠し、7パス・オプションはDOD(米国国防総省)の勧告に準拠します。
次の表に、サポートされているアルゴリズムを使用してドライブを安全に消去するための所要時間を示します。
ドライブのタイプ | 1パス | 3パス | 7パス |
---|---|---|---|
600 GBドライブ |
1時間 |
3時間 |
7時間 |
2 TBドライブ |
5時間 |
15時間 |
35時間 |
3 TBドライブ |
7時間 |
21時間 |
49時間 |
22.875 GBフラッシュ・ドライブ |
該当なし |
該当なし |
21分 |
93 GBフラッシュ・ドライブ |
該当なし |
該当なし |
32分 |
注意:
Oracle Exadata Storage Server Softwareの安全なデータ消去では、アクセス可能なすべてのデータの複数回上書き方式を使用します。上書き方式では、データ文字の様々な組合せを使用します。このデータ消去方式は、周知のアルゴリズムに基づきます。まれな条件下で、7パスによる消去でもデータ形跡を完全に削除できないことがあります。たとえば、ディスクに内部的なリマップ・セクターがあると、ディスク上に一部のデータが物理的に残ってしまう場合があります。通常のI/Oインタフェースでは、そのデータにアクセスできません。
データの保護に使用できる別の方法として、表領域暗号化があります。
Oracle Exadata Storage Server Softwareでは、CPU使用率を監視することにより、Exadata Storage Serverのリソースのボトルネックを検出します。ボトルネックが見つかると、処理の再割当てを行い、パフォーマンスを改善します。各Exadataセルでは、次の統計情報を保持します。
直前の30分間を対象とするExadataセルのCPU使用率とプッシュバック(戻り)率のスナップショット。
プッシュバック(戻り)が決定された1MBのブロックの合計数。
データベース・サーバーに戻されたブロックの数。
Total cpu passthru output IO size
の統計(KB)
Oracle Exadata Database Machine 11gリリース2(11.2.1.2)の新機能は次のとおりです。
Exadataスマート・フラッシュキャッシュにより、各Exadataセル上で頻繁にアクセスされるデータ用にキャッシュ・メカニズムが提供されます。このキャッシュは、ランダムな反復読取りを処理するのに役立つライトスルー・キャッシュであり、オンライン・トランザクション処理(OLTP)に非常に適しています。これにより、表または索引レベルでデータベース側のSTORAGE句のヒントを使用して、KEEP
モードでデータをキャッシュするメカニズムが提供されます。フラッシュ・ディスクのExadataスマート・フラッシュキャッシュ領域は、起動時にExadataセルに自動的に作成されます。
Oracle Exadata Storage Serverには、従来の回転型のハード・ディスクに加え、高性能なフラッシュ・ディスクが搭載されています。これらの高性能なフラッシュ・ディスクを使用して、Exadataグリッド・ディスクを作成し、頻繁にアクセスされるデータを格納できます。この場合、ユーザーは、正確な領域プランを作成して、性能のよいディスクに最もアクティブな表領域を配置する必要があります。推奨オプションとして、Exadataスマート・フラッシュキャッシュ用にフラッシュ・ディスク領域の一部または全部を提供できます。この場合、回転ディスク上で最も頻繁にアクセスされるデータは、高性能なフラッシュ・ディスクのExadataスマート・フラッシュキャッシュ領域に自動的にキャッシュされます。データベースがこのようなデータにアクセスする必要がある場合、Oracle Exadata Storage Serverでは、データを遅い回転ディスクから取得するかわりに、Exadataスマート・フラッシュキャッシュからフェッチします。
パーティションや表がデータベースによってスキャンされる場合、オブジェクトにCELL_FLASH_CACHE
属性が設定されていれば、Exadata Storage Serverでは、Exadataスマート・フラッシュキャッシュからスキャン対象のデータをフェッチできます。また、Exadata Storage Serverでは、Exadataフラッシュキャッシュからデータを提供する以外に、ハード・ディスクからスキャン対象のオブジェクトをフェッチすることもできます。
Exadata Storage ServerによってExadataスマート・フラッシュキャッシュおよびハード・ディスクからスキャン・データをフェッチする場合、そのパフォーマンスは加算的です。Exadata Storage Serverでは、Exadataスマート・フラッシュキャッシュの最大帯域幅とハード・ディスクの最大帯域幅を使用してオブジェクトをスキャンできるため、双方からの同時スキャン中は最大帯域幅が加算されます。
Oracle DatabaseとExadataスマート・フラッシュキャッシュ・ソフトウェアは、相互に緊密に連携して動作します。データベースでは、Oracle Exadata Storage Serverに読取りまたは書込みリクエストを送信する際に、そのデータが再度アクセスされる可能性があるかどうかと、そのデータをキャッシュする必要があるかどうかに関する追加情報をリクエストに含めます。たとえば、ログ・ファイルやミラー・コピーにデータを書き込む場合、データベースではキャッシュを省略するようヒントを送信します。表の索引を読み取る場合、データベースではそのデータをキャッシュするようヒントを送信します。この連携動作により、最も頻繁にアクセスされるデータのみが格納されるようにExadataスマート・フラッシュキャッシュ領域の使用が最適化されます。
ユーザーは、他のデータベース・オブジェクトよりも優先的にキャッシュするオブジェクト(表領域や表など)と、まったくキャッシュしないオブジェクトについてより詳細に制御できます。この制御を行うには、データベース・オブジェクトに割当て可能な、STORAGE句の新規属性であるCELL_FLASH_CACHE
を使用します。
たとえば、Exadataスマート・フラッシュキャッシュにCALLDETAIL
表を確保する場合、次のコマンドを使用します。
ALTER TABLE calldetail STORAGE (CELL_FLASH_CACHE KEEP)
Exadata Storage Serverでは、CALLDETAIL
表のデータを優先的にキャッシュし、そのデータを他の表のキャッシュ・データよりも長い間Exadataスマート・フラッシュキャッシュに保持するよう試みます。CALLDETAIL
表が複数のOracle Exadata Storage Serverに分散されている場合、それぞれ独自のExadataスマート・フラッシュキャッシュに表の一部がキャッシュされます。キャッシュのサイズが十分であれば、多くの場合、CALLDETAIL
表は一定期間にわたり完全にキャッシュされます。
ハイブリッド列圧縮により、ダイレクト・パス・ロードが行われるデータに高度な圧縮レベルが提供されます。この新しい圧縮機能は、更新頻度の低いデータに推奨されます。ハイブリッド列圧縮は、パーティション、表および表領域のレベルで指定できます。また、希望の圧縮レベルを指定して、ディスク使用量とCPUオーバーヘッドの間のトレードオフ関係を適切に調整することもできます。さらに、現在のアプリケーションにとって適切な圧縮レベルを決定するのに役立つ圧縮アドバイザも付属しています。
この機能によって、データベースでは表をスキャンするI/Oの回数を減らすことができます。たとえば、データを10分の1に圧縮すれば、I/Oも10分の1に減少します。また、ハイブリッド列圧縮により、同じ容量分のディスク領域を節約できます。
同様に、この機能によって、データベースではコラム圧縮表のスマート・スキャンをExadataセルにオフロードできます。圧縮表でスキャンが行われる場合、Exadataセルはスキャンのためにディスクから圧縮ブロックを読み取ります。次に、Oracle Exadata Storage Server Softwareが参照列を解凍し、データの条件評価を実行して、フィルタを適用します。その後、セルは、限定されたデータを非圧縮形式で返します。このオフロードがなければ、データ解凍はデータベース・ホストで発生することになります。Exadataセルにデータを解凍させることで、データベース・ホストのCPU処理を大幅に節約できます。
関連項目:
ハイブリッド列圧縮の詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください。
ストレージ索引は、I/O操作の回避に役立つ、Oracle Exadata Storage Server Softwareで提供される非常に優れた機能です。Oracle Exadata Storage Server Softwareでは、Exadataメモリーにストレージ索引を作成して管理します。ストレージ索引により、そのセルに格納されている表の列の最小値と最大値がストレージ・リージョン単位で追跡されます。この機能は透過的に実行されるため、ユーザーによる管理操作は必要ありません。
問合せでWHERE
句が指定されると、Oracle Exadata Storage Server Softwareでは、ストレージ索引を調査して、指定された列値を含む行がセル内ディスクのリージョンに存在しないかどうかを判断します(この処理は、ストレージ索引に保持されている最小値および最大値と列値を比較することで行われます)。列値が最小値と最大値の範囲外の場合、その問合せのためのスキャンI/Oはそのリージョンで回避されます。多数のI/O操作が少数のインメモリー検索に自動的に置き換えられるため、多くのSQL操作の実行速度が大幅に向上します。操作上のオーバーヘッドを最小限に抑えるため、Oracle Exadata Storage Server Softwareによってストレージ索引が透過的かつ自動的に作成されて管理されます。
ストレージ索引は、暗号化された表領域で効果を発揮します。ただし、ストレージ索引では、暗号化された列の最小値と最大値は保持されません。
Oracle Exadata Storage Server Softwareでは、復号化処理をオフロードし、暗号化された表領域や暗号化された列に対してスマート・スキャンを実行できます。以前のリリースのOracle Exadata Storage Server Softwareでも、暗号化された表領域と暗号化された列は完全にサポートされていましたが、Exadataオフロード処理によるメリットはありませんでした。暗号化された表領域の場合、Oracle Exadata Storage Server Softwareでは、ブロックを復号化してその復号化ブロックをOracle Databaseに返すか、または行および列を返す列のスマート・スキャンを実行できます。Oracle Exadata Storage Server Softwareがデータベースのかわりに復号化を実行すると、CPUの使用がExadataセルにオフロードされるため、CPU処理を大幅に節約できます。
グリッド・ディスクの領域は、インターリーブ形式で割り当てることができます。このタイプの領域割当てを使用するグリッド・ディスクは、インターリーブ・グリッド・ディスクと呼ばれます。この方法では、内側のトラックのグリッド・ディスクを犠牲にして外側のトラックを占有するグリッド・ディスクに優れたパフォーマンスを発揮させるのではなく、同じセル・ディスク上に存在する各グリッド・ディスクのパフォーマンスを均等化するよう試みます。
セル・ディスクは、外側半分(上部)と内側半分(下部)の2つの等しい部分に分割されます。新規グリッド・ディスクが作成されると、そのグリッド・ディスク領域の半分はセル・ディスクの外側半分に割り当てられ、グリッド・ディスク領域の残りの半分はセル・ディスクの内側半分に割り当てられます。グリッド・ディスクの上部は、外側半分の空き領域または使用済領域に応じて、外側半分で最初に使用できる最も外側のオフセットから開始します。グリッド・ディスクの下部は、内側半分で最初に使用できる最も外側のオフセットから開始します。
たとえば、100GBの領域を持つセル・ディスクCD_01_cell01
が完全に空で、そのセル・ディスクに50GBのサイズのグリッド・ディスクdata_CD_01_cell01
を作成する場合、セル・ディスクのレイアウトは次のようになります。
- Outer portion of data_CD_01_cell01 - 25GB - Free space - 25GB ------------ Middle Point ------------------ - Inner portion of data_CD_cell01 - 25GB - Free space - 25GB
関連項目:
グリッド・ディスクの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください。
Oracle Exadata Storage Server Softwareでは、現在、データ・マイニング・モデル・スコアリングがオフロードされます。これにより、Exadataセル上のデータ・ウェアハウスのデプロイメントが、より優れた高性能なデータ分析プラットフォームになります。PREDICTION_PROBABILITY
などのすべてのデータ・マイニング・スコアリング関数は、Exadataセルにオフロードされて処理されます。これにより、データベース・サーバーのCPU使用量を抑制し、データベース・サーバーとExadataストレージ間のI/O負荷を軽減しながら、ウェアハウス分析を高速化できます。
Oracle Exadata Storage Server Softwareには、現在、次の管理性機能が含まれます。
ディスク・グループに対する置換ディスクの自動追加: 物理ディスクの障害後に置換ディスクが追加された場合、ディスク・グループを再作成して元のディスク・グループに各グリッド・ディスクを追加するのに必要なすべてのExadata操作は、現在、自動的に実行されます。
ASMディスク・グループでのOCRおよび投票ディスクのサポート: Oracle Database 11gリリース2(11.2)では、ASMディスク・グループでOracle Cluster Registry(OCR)および投票ディスクがサポートされます(iSCSIパーティションは必要なくなりました)。
データベース・サーバーにおける最大4つのデュアルポートInfiniBandホスト・チャネル・アダプタのサポート。この機能により、Oracle Exadata Storage Server Softwareを使用するデータベース・サーバーとして、より大規模なOracle Exadata Database Machine X2-8フル・ラックを使用できます。