Oracle Exadata Database Machine 11gリリース2(11.2.3.2)の新機能

Oracle Exadata Database Machine 11gリリース2(11.2.3.2)の新機能は次のとおりです。

Exadata Smart Flash Cacheを使用したライトバック・フラッシュ・キャッシュ

Exadata Smart Flash Cacheは、頻繁にアクセスされるデータを高速なソリッド状態の記憶装置に透過的にキャッシュし、問合せの応答時間とスループットを向上させます。ディスクではなくフラッシュによって処理される書込み操作は、ライトバック・フラッシュ・キャッシュと呼ばれます。ライトバック・フラッシュ・キャッシュでは、1秒当たりの書込みI/OをX3システムで20倍、X2システムで10倍多く実行できます。X3システムではフラッシュ容量がより大きいため、ほぼすべての書込みがフラッシュによって処理されます。

アクティブなデータ・ブロックを、ライトバック・フラッシュ・キャッシュに数か月または数年間保持できます。最近読取りが実行されていないブロックの場合、主要なコピーのみがキャッシュに保持されます。必要に応じて、すべてのデータはディスクにコピーされます。これにより、性能のよいフラッシュ領域を効率よく使用できます。

フラッシュ・キャッシュに問題がある場合、操作はフラッシュのミラー・コピーに透過的にフェイルオーバーされます。ユーザーが介入する必要はありません。フラッシュのデータは、割当て単位に基づいてミラー化されます。これは、書き込まれるデータ量がディスク・サイズではなく損失したキャッシュ・サイズに比例することを示します。

関連項目:

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

セルの再起動後のExadataスマート・フラッシュ・キャッシュの持続性

Exadataスマート・フラッシュ・キャッシュは、停電、停止操作、セルの再起動などを行っても持続します。フラッシュ・キャッシュのデータは、セルの再起動後にディスクから読み取ることで、再移入されることはありません。サーバーからの書込み操作はフラッシュ・キャッシュに直接実行されます。これにより、ディスクでのI/O操作の数が減少します。フラッシュ・ディスクでのデータのキャッシュは管理者が設定します。

CELLSRVサービスの正常シャットダウン

セルまたはディスクがオフラインになり、管理者がCELLSRVサービスを再起動または停止しようとすると、冗長性が低下しているために、セルを停止できないというメッセージが管理者に通知されます。

ストレージ・サーバー・ディスクの取外しのLED通知

ストレージ・サーバー・ディスクを取り外す必要がある場合は、青色のLEDライトがサーバーに表示されます。青色のライトにより、保守が必要なサーバー・ディスクを簡単に確認できます。

パフォーマンスが低下しているディスクの識別

ディスクのパフォーマンスが低下すると、作業がすべてのディスクに均等に分散されるため、すべてのディスクのパフォーマンスが影響を受けます。たとえば、あるディスクのパフォーマンスが他のディスクよりも30%低下すると、システム全体のI/O容量が30%低下します。

パフォーマンスが低下しているディスクが検出されると、そのディスクはアクティブな構成から削除されます。次に、Oracle Exadata Database Machineが一連のパフォーマンス・テストを実行します。ディスクの問題が一時的な場合は、テストに合格すると、そのディスクは構成に戻ります。ディスクがテストに合格しない場合は、poor performanceとしてマークされ、ディスクを交換するための自動サービス・リクエスト(ASR)のサービス・リクエストが開きます。この機能は、ハード・ディスクとフラッシュ・ディスクの両方に適用されます。

Oracle SolarisでのOracle Database File Systemのサポート

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およびラージ・オブジェクト開発者ガイド』を参照してください。

予測障害ディスク・ドロップの状態要因

ハード・ディスクがOracle Exadata Storage Serverで予測障害になると、Oracle Exadata System SoftwareOracle Automatic Storage Management (Oracle ASM)リバランスを自動的にトリガーし、ディスクからデータを移動します。Oracle ASMリバランスでは、最初に正常なミラーから読み取り、冗長性をリストアします。他すべてのミラーが利用できない場合、Oracle ASMリバランスは予測障害ディスクからデータを読み取ります。最適なリバランスを進めることができる場合は、これにより予測障害ディスクからのリバランス読取りが回避され、リバランス・プロセスで最大限のデータ冗長性を維持できます。

ディスク・グループ内の正常な他のディスクにデータを完全に移動する前に、Oracle Exadata System Softwareは、予測障害ディスクの悪い状態をデータベース・インスタンスに通知し、そのディスクのデータに対する問合せとスマート・スキャンを他のミラーに迂回して、応答時間を改善します。

サーバーのハード・ディスク・ドライブの番号付け

Exadata Storage Server X3-2 Serverのドライブは、各行で左から右に番号付けされます。下段のドライブの番号は0、1、2および3です。中段のドライブの番号は4、5、6および7です。上段のドライブの番号は8、9、10および11です。

図-9 Exadata Storage Server X3-2 Serverのディスク・レイアウト

図-9の説明が続きます
「図-9 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になりました。

図-10 Sun Fire X4270 M2 Serverを使用したExadata Storage Serverのディスク・レイアウト

図-10の説明が続きます
「図-10 Sun Fire X4270 M2 Serverを使用したExadata Storage Serverのディスク・レイアウト」の説明