翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
スマートフラッシュキャッシュ
Exadata スマートフラッシュキャッシュ機能は、データベースオブジェクトをフラッシュメモリにキャッシュして、データベースオブジェクトへのアクセス速度を向上させます。スマートフラッシュキャッシュは、キャッシュする必要があるデータセグメントとオペレーションのタイプを判断できます。さまざまなタイプの I/O リクエストを認識して、再現不可能なデータアクセス (RMAN バックアップ I/O など) がキャッシュからデータベースブロックをフラッシュしないようにします。ALTER コマンドを使用して、ホットテーブルとインデックスを Smart Flash Cache に移動できます。フラッシュキャッシュの書き込み機能を使用すると、スマートフラッシュはデータベースブロックの書き込みオペレーションをキャッシュすることもできます。
Exadata ストレージサーバーソフトウェアは、REDO ログの書き込みオペレーションを高速化し、ログファイル同期イベントのサービス時間を短縮するための Smart Flash Logging も提供します。この機能は、フラッシュメモリとディスクコントローラーキャッシュの両方に対して REDO 書き込みオペレーションを同時に実行し、2 つのうちの 1 つが完了すると書き込みオペレーションを完了します。
次の 2 つの統計は、Exadata Smart Flash キャッシュのパフォーマンスに関する簡単なインサイトを提供します。これらは、AWR レポートの グローバルアクティビティ統計またはインスタンスアクティビティ統計セクションの V$SYSSTATや などの動的パフォーマンスビューで使用できます。
-
Cell Flash Cache read hits– Smart Flash キャッシュで一致を検出した読み取りリクエストの数を記録します。 -
Physical read requests optimized– Smart Flash Cache またはストレージインデックスを通じて最適化された読み取りリクエストの数を記録します。
ストレージセルから収集された Exadata メトリクスは、ワークロードが Smart Flash キャッシュをどのように使用するかを理解するのにも役立ちます。次の CellCLI
CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME,DESCRIPTION WHERE OBJECTTYPE = FLASHCACHE FC_BYKEEP_DIRTY "Number of megabytes unflushed for keep objects on FlashCache" FC_BYKEEP_OLTP "Number of megabytes for OLTP keep objects in flash cache" FC_BYKEEP_OVERWR "Number of megabytes pushed out of the FlashCache because of space limit for keep objects" FC_BYKEEP_OVERWR_SEC "Number of megabytes per second pushed out of the FlashCache because of space limit for keep objects" ...
への移行 AWS
スマートフラッシュキャッシュが存在しません AWS。Exadata ワークロードを に移行するときに、この課題を軽減し AWS、パフォーマンスの低下を回避するには、いくつかのオプションがあります。これらのオプションについては、以下のセクションで説明します。
-
拡張メモリインスタンスの使用
-
NVMe ベースのインスタンスストアでのインスタンスの使用
-
低レイテンシーと高スループットのための AWS ストレージオプションの使用
ただし、これらのオプションでは Smart Flash キャッシュの動作を再現できないため、ワークロードのパフォーマンスを評価して、引き続きパフォーマンス SLAs を満たしていることを確認する必要があります。
拡張メモリインスタンス
Amazon EC2 は、12 TiB および 24 TiB のメモリを持つインスタンスなど、多くのハイメモリインスタンス
NVMe ベースのインスタンスストアを持つインスタンス
インスタンスストアは、インスタンスの一時的なブロックレベルのストレージを提供します。このストレージは、ホストコンピュータに物理的にアタッチされたディスク上にあります。インスタンスストアを使用すると、NVMe ベースのディスクにデータを保存することで、ワークロードは低レイテンシーと高スループットを実現できます。インスタンスストア内のデータはインスタンスの存続期間中のみ保持されるため、インスタンスストアは一時的なテーブルスペースやキャッシュに最適です。インスタンスストアは、インスタンスのタイプと I/O サイズに応じて、数百万 IOPS と 10 Gbps を超えるスループットをマイクロ秒のレイテンシーでサポートできます。さまざまなインスタンスクラスのインスタンスストアの読み取り/書き込み IOPS とスループットのサポートの詳細については、Amazon EC2 ドキュメントの「汎用インスタンス、コンピューティング最適化インスタンス、メモリ最適化インスタンス、ストレージ最適化インスタンス」を参照してください。
Exadata では、データベースフラッシュキャッシュにより、ユーザーはインスタンスストアボリュームで平均 I/O レイテンシーが 100 マイクロ秒の 2 番目のバッファキャッシュ層を定義して、読み取りワークロードのパフォーマンスを向上させることができます。このキャッシュは、2 つのデータベース初期化パラメータを設定することでアクティブ化できます。
-
db_flash_cache_file = /<device_name> -
db_flash_cache_size = <size>G
Amazon EC2 でホストされている Oracle データベースの高性能アーキテクチャを設計するには、データベースファイルをインスタンスストアに配置し、Oracle Automatic Storage Management (ASM) と Data Guard が提供する冗長性を使用して、インスタンスストアでデータが失われた場合のデータ保護と復旧を行います。これらのアーキテクチャパターンは、低レイテンシーで極端な I/O スループットを必要とするアプリケーションに最適であり、特定の障害シナリオでシステムを回復するためにより高い RTO を提供することができます。以下のセクションでは、NVMe ベースのインスタンスストアでホストされるデータベースファイルを含む 2 つのアーキテクチャについて簡単に説明します。
アーキテクチャ 1。データベースは、データ保護のために Data Guard を使用して、プライマリインスタンスとスタンバイインスタンスの両方のインスタンスストアでホストされます。
このアーキテクチャでは、データベースは Oracle ASM ディスクグループでホストされ、I/O を複数のインスタンスストアボリュームに分散して、高スループット、低レイテンシーの I/O を実現します。 Data Guard スタンバイは、インスタンスストア内のデータ損失から保護するために、同じアベイラビリティーゾーンまたは別のアベイラビリティーゾーンに配置されます。ディスクグループの設定は、RPO とコミットレイテンシーによって異なります。何らかの理由でインスタンスストアがプライマリインスタンスで失われた場合、データベースはゼロまたは最小限のデータ損失でスタンバイにフェイルオーバーする可能性があります。Data Guard オブザーバープロセスを設定してフェイルオーバーを自動化できます。読み取りオペレーションと書き込みオペレーションはどちらも、インスタンスストアが提供する高スループットと低レイテンシーの恩恵を受けます。
アーキテクチャ 2。データベースは、EBS ボリュームとインスタンスストアの両方を組み合わせた 2 つの障害グループを持つ ASM ディスクグループでホストされます。
このアーキテクチャでは、すべての読み取りオペレーションは ASM_PREFERRED_READ_FAILURE_GROUPパラメータを使用してローカルインスタンスストアから実行されます。書き込みオペレーションは、インスタンスストアボリュームと Amazon Elastic Block Store (Amazon EBS) ボリュームの両方に適用されます。ただし、Amazon EBS 帯域幅は、読み取りオペレーションがインスタンスストアボリュームにオフロードされるため、書き込みオペレーション専用です。インスタンスストアでデータが失われた場合、EBS ボリュームまたはスタンバイデータベースに基づいて ASM 障害グループからデータを復元できます。詳細については、Oracle ホワイトペーパー「Mirroring and Failure Groups with ASM
Amazon RDS for Oracle は、インスタンスストアで Database Smart Flash Cache と一時テーブルスペースをサポートしています。Oracle データベースワークロードは、この機能を使用して、読み取りオペレーションのレイテンシーを短縮し、スループットを高め、他のデータベース I/O オペレーションの Amazon EBS 帯域幅を効率的に使用できます。この機能は現在、db.m5d、db.r5d、db.x2idn、および db.x2iedn インスタンスクラスでサポートされています。最新情報については、Amazon RDS ドキュメントの「RDS for Oracle インスタンスストアでサポートされているインスタンスクラス」を参照してください。
低レイテンシーと高スループットを必要とするワークロード用の AWS ストレージオプション
Amazon RDS for Oracle が現在サポートしている EBS ボリュームタイプ、gp2、gp3、io1
Amazon EC2 での自己管理型 Oracle データベースデプロイの場合、Amazon EBS io2 および io2 Block Express EBS ボリューム
より高いスループットまたはマイクロ秒のレイテンシーを必要とするワークロードは、Amazon EC2 にセルフマネージド Oracle データベースとしてデプロイするときに、Amazon EBS に基づいていないストレージボリュームを使用できます。例えば、Amazon FSx for OpenZFS
