X

オラクルエンジニア通信では、オンプレミスからクラウドまで、オラクルテクノロジーの最新情報をお届けします

Exadata Smart Flash Log Write-Back

※本ページは、"Exadata Smart Flash Log Write-Back"の翻訳です。

Exadata 20.1 (ヒント: "twenty-dot-one "と発音してください。"twenty-one "ではなく "twenty-dot-one "と発音してください。) 2020年6月にリリースされたExadata System Software 20.1では、よりスマートなインフラストラクチャ、パフォーマンスの向上、よりスマートな管理の分野で機能が追加されました。まだ読んでいない方は、Exadata 20.1 Releaseのブログ記事を読むか、Exadata開発責任者のKodiのウェブキャスト(YouTube)を見ることをお勧めします。

この新機能の前身であるExadata Smart Flash Logと混同されてはいけませんが、では最初に、Smart Flash Logを振り返ってから、Smart Flash Log Write-Backを見てみましょう

Smart Flash Logのドキュメントを見てみましょう。

"Oracle Exadata Smart Flash Logの目標は、フラッシュメモリとディスクの両方に同時にredo logの書き込み操作を実行し、2つのうちの最初の方が完了した時点で書き込み操作を完了させることです。"

基本的に、ディスクへの書き込みはそれだけでは遅くなります、フラッシュへの書き込みは時々しゃっくり(書き込みの遅れ)が発生するので、REDOログを2箇所に分けて書き込んでみましょう、完了までの時間が早い方が勝ちです。これにより、パフォーマンスの異常値が排除され、データベースが高速化されます。スマートフラッシュログの利点を示すこのようなグラフィックを見たことがあるかもしれません。

Smart Flash Logはパフォーマンスを向上させる素晴らしい機能で、レスポンスタイムを短縮し、パフォーマンスの異常値を除去します(AWRの "log file parallel write "と "log file sync "のメトリクスを確認してください)。実質的にフラッシュ容量を使用せず(0.1%未満の領域を利用)、完全に自動で透過的です。レガシー・ストレージのIOではredoログIOを他と区別できないので、Exadata独自の機能で、ここではかなり良い状況になっています。

では、これで十分ではないでしょうか?パフォーマンスを向上させ、予測不可能性を低減させたのに、なぜそこで終わらないのか?

なぜならこれがExadataだからです。最高のデータベースプラットフォームへの果てしない探求です。

Exadata Smart Flash Logは、時折発生するログ書き込みの異常値を防ぎ、平均的なREDOログ書き込みパフォーマンスを向上させたとしても、すべてのREDOログエントリは最終的に永続化のためにハードドライブに書き込まれなければならないため、総ログ書き込みスループットは(HCストレージサーバーでは)ハードドライブによって制限されています。したがって、ディスクのIO帯域幅が飽和している場合(大容量のREDOログアクティビティや、Golden Gateログマイニング、ログアーカイブ、またはRMANバックアップ/リストアのような他のIO集約的なアクティビティが原因)、ログ書き込みがパフォーマンスのボトルネックになる可能性があります。

上記の理由から、Exadata Smart Flash Log Write-Backが登場しました。

この新機能のドキュメントを見てみましょう。

"高性能なデータベース・ワークロードにおけるログ書き込みスループットを向上させるために、ハード・ドライブへのログ書き込みのやり直しは、High CapacityモデルのExadataストレージ・サーバー上のWrite-BackでExadata Smart Flash Cacheを使用して自動的かつ透過的に保存されるようになりました。GoldenGateログ・マイニング、ログ・アーカイブ、RMANバックアップおよびリストアなどのI/O集約的なアクティビティのためにハードディスク・ドライブ・リソースを解放します。システムのワークロードに応じて、ログ書き込みスループットが最大2.5倍向上します。

なるほど、Smart Flash Log Write-Backの定義は、Smart Flash Logが克服できなかったギャップそのもののように聞こえます。そうですね。

(余談ですが、Write-BackとWrite-Throughという用語をご存じでない方はご存じないかもしれません。これらは、データ・トランザクションのためにExadataのフラッシュ・キャッシュを設定できる2つの方法です。"Write-Through" キャッシュでは、フラッシュ・キャッシュからIOを読み込みますが、書き込みIOはディスクに書き込みます。一方で、"Write-Back" キャッシュでは、読み込みも書き込みもどちらもフラッシュ・キャッシュに読み書きすることで性能を向上させます)

現在、Exadata 20.1の時点では、Exadata X7(またはそれ以降)HC Storage ServerのSmart Flash CacheでWrite-Backを有効にしてARCHIVELOGモードでデータベースを実行している場合、自動的にSmart Flash LogのWrite-Backが使用されるようになっています。

しかし、それをどうやって見分けるのでしょうか?結局のところ、透過的で自動なので、使用していることはどうやってわかるのでしょうか?

AWRでわかりやすく確認できます。(セシリアのアドバイスが参考になります)


Flash Cache Redo Caching セクション- 以前のバージョンのExadataのAWRレポートや20.1以降のAWRレポートを見ると、この新機能のために特別に作られたFlash Cache Redo Cachingというセクションが追加されていることに気づくでしょう。これは20.1のAWRレポートのスクリーンショットです。

ご覧のように、レポートのこのセクションでは、ストレージサーバーの合計と個別の点で、Flash CacheのRedo LogのWrite RequestsとWrite MB/sの統計を見ることができます。


Flash Log セクション - フラッシュ・ログのライトバックのために強化された別のセクションです。


ここでハイライト表示されているのがわかると思いますが、FC Writes(Flash Cache Writes)とSkipsはAWRレポートのFlash Logテーブル内の新しいカラムで、Redo LogからFlash Cacheへの書き込み数を表示しています。

最後に、REDO生成のワークロードが多いマルチ・データベース環境を運用している場合、Exadata 20.1アップデート前とアップデート後のAWRレポートを見てみてください。キー・インスタンスのアクティビティ統計のセクションで、REDOサイズの指標が改善されているのがわかるはずです。

今日の最後にSmart Flash Log Write-Backの詳細をいくつかご紹介します。

  • Exadata X8MでPersistent Memoryを構成して実行している場合、Persistent Memory Commit AcceleratorはSmart Flash Log Write-Back(PMEMのスライスではなく、全体のREDOログファイルを保持する)の前にREDOログエントリを受信するため、Persistent Memory Commit Acceleratorの利点は継続され、実際にはSmart Flash Log Write-Back機能のパフォーマンス向上によって強化されます。
  • Data Guardを使用して実行しているデータベースは、オンラインのREDOログ・ファイルとスタンバイのREDOログ・ファイルの両方で、Smart Flash Log Write-Backにより、スループットが向上します。この場合も、透過的で、自動で、設定の必要はありません。
  • 最後に、マルチテナント・コンテナ・データベース(CDBとPDB)では、REDOログ・キャッシュはコンテナ・レベルで保持されるため、統計はコンテナ・レベルの粒度でのみ収集されることに注意してください。(REDOログ・キャッシングのスペース・アカウンティングはCDB$ROOTクォータを使用します)

これでわかりました。これでExadata Smart Flash Log Write-Backが何であるかがお分かりいただけたと思いますが、これは、Exadataがなぜソフトウェアとハードウェアの合計以上のものであるかを示すもう一つの例です。

皆様からのフィードバックをいつでもお待ちしておりますので、こちらのコメント欄やTwitter @GavinAtHQまでお気軽にお問い合わせください。

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.