大量の書き込みデータベース用にOracleREDOログをDRAMSSDに配置しますか？
書き込み量の多いデータベースを使用して、EMCCX4-120アレイに接続されたSunM4000があります。書き込みのピークは約1200IO/sおよび12MB/sです。
EMCによると、EMCアレイの書き込みキャッシュを飽和させています。
最も簡単な解決策は、REDOログをDRAMベースのSSDに移動することだと思います。これにより、EMCアレイの負荷が半分になり、アプリはログバッファの待機を認識しなくなります。はい、DBWRがボトルネックになる可能性がありますが、アプリはそれを待ちません（REDOコミットの場合のように！）
私は現在、約4つの4GB REDOログを循環しているので、20GB程度のSSDでも大きな違いがあります。これは短期記憶であり、常に上書きされているため、フラッシュベースのSSDはおそらく良い考えではありません。
M4000には追加のドライブロットがないため、PCI-Eカードが最適です。外部に移動するか、ブートボリュームをEMCに移動して、ローカルドライブを解放できます。
SunはFlashAccelerator F20 PCIeカードを販売していますが、これは一部のSATAディスクのキャッシュであり、DRAMSSDソリューションではないようです。詳細は大雑把で、M4000がサポートされているとは記載されていません。私は、人間の助けを求めてSunの電話ツリーと戦うのにうんざりしています。 :(
他の人は、DRAM SSDが進むべき道であることに同意しますか？ハードウェアの推奨事項はありますか？
[〜＃〜] update [〜＃〜]以下のコメントの情報に加えて、「commit_write」のさまざまな設定を試しましたが、違いはありませんでした。
「forcedirectio」オプションを使用してUFSパーティションをマウントし、Oracleパラメータ「filesystemio_options」を「setall」に設定することに関する投稿を見ました。
試してみたところ、Oracleの書き込みが4〜5倍向上しました。うん！
主な症状は、スループットが低いことでしたが、ディスクでの応答時間は良好でした。これは一部の人には役立つようですが、他の人には役立ちません。それは確かに私のために仕事をしました。
新しいサーバー用のSSDを検討するかもしれませんが、このサーバーは現在正常に動作しています。
ロバート
まず、アレイ内のディスクが非常に少ないと思います。 1200IOPSは、12個の回転ディスクで簡単にサポートできます（ディスクあたり100 IOPSが非常に合理的です）。キャッシュがそれを処理できない場合は、1200IOPSの持続的な書き込み速度がディスクがサポートできるよりもはるかに高いことを意味します。
とにかく、REDOログ用のSSDは役に立たないでしょう。まず、セッションは主にCOMMITステートメントで待機していますか？ statspack/AWRの上位の待機イベントを確認してください。 I/Oの約95％は、REDOログにはまったく使用されていないと思います。たとえば、5つのインデックスを持つテーブルへの単一行の挿入は、1つのI/Oを実行してテーブルブロック（行用のスペースがある）を読み取り、5つのインデックスブロックを読み取り（それらを更新する）、1つのデータブロックを書き込み、1つの取り消しを行うことができますブロックと5つのインデックスブロック（リーフ以外のブロックが更新されている場合はそれ以上）と1つのREDOブロック。したがって、statspackをチェックして待機イベントを確認すると、データ/インデックスの読み取りと書き込みの両方を多く待機している可能性があります。読み取りを待機するとINSERTが遅くなり、WRITEアクティビティによってREADがさらに遅くなります（同じディスクです（BTW-本当にすべてのインデックスが必要ですか？必要のないインデックスを削除すると挿入が高速化されます）。
チェックするもう1つのことは、RAID定義です。これはRAID1（ミラーリング-各書き込みは2回の書き込み）またはRAID 5（各書き込みは2回の読み取りとチェックサム計算用の2回の書き込み）です。 RAID 5は、書き込みの多い負荷でははるかに低速です。
ところで-ディスクが書き込み負荷を処理できない場合、DBWRがボトルネックになります。 SGAはダーティブロックでいっぱいになり、DBWRがダーティブロックをディスクに書き込めるまで、新しいブロック（処理/更新が必要なインデックスブロックなど）を読み取る余地がなくなります。繰り返しになりますが、statspack/awr report/addmをチェックして、通常は上位5つの待機イベントに基づいてボトルネックを診断します。
ddは、ブロックI/Oと比較して何もありません。
他のいくつかのビューについては、確認してください。anandtech.comは、さまざまな組み合わせでSAS回転vs SSD）を使用して（MS SQLサーバーで許可された）徹底的なテストを行いました。さまざまな部分（ログ、キャッシュなど）をアップします。
しかし、はい、RAID5とRAID10が同じである場合（書き込みの場合）、何か問題があります。線形書き込みを使用すると、RAID 5の方が高速になる可能性があります（つまり、メモリ内でパリティを実行してから、ストライプとパリティを一度に書き込むことができます）が、ランダムな小さなブロック（4〜8k）を使用すると、ストライプを更新することで強制終了します（他の人が指摘しているように）、RAID 10は2倍以上速いはずですが、そうでない場合は、何かが間違っています。
ハードウェアにお金をかける前に、もっと深く掘り下げる必要があります。
F20e PCIeカードは、機能的にはFusion I/Oに似ています。基本的にはPCIe接続のフラッシュSSDです。書き込みの重いワークロードでは、SSDの消去/プログラムサイクルがボトルネックになることのないように、十分な空きブロックを維持すること（何らかのドライブベースのガベージコレクションを介して）について心配する必要があります。フラッシュベースのSSDで利用可能な限られた書き込みサイクル。それは間違いなく速いですが、この仕事に最適なキットではないかもしれません。
このボックスがLinuxを実行しているx86/64ボックスだけだったとしたら、FusionIO PCIeドライブカードの1つを喜んでお勧めします。これらは驚くほど高速で、SSDのように大量の書き込みで「死ぬ」ことはありません。残念ながら、SparcとSolarisのどちらでもサポートされていませんが、これについて話し合うために連絡することをお勧めします。