Exadata Smart Flash Log Write-Back (2020/08/29)

https://blogs.oracle.com/exadata/exadata-smart-flash-log-write-back
投稿者：Gavin Parish

はい、口だけですし、そうですね、すでに知っていることのように聞こえます。
しかし、念のため、他のことを考えていた場合に備えて、それについて説明しておきましょう。

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

この新機能の前身であるExadata Smart Flash Logと混同しないように...
実際に、Smart Flash Logを振り返ってみて、Smart Flash Log Write-Backがもたらす機能強化を確認してみましょう。

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

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

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

Smart Flash Logは、レスポンスタイムを短縮し、パフォーマンスの異常値を除去するパフォーマンス向上機能です
（AWRの "ログファイル並列書き込み "と "ログファイル同期 "のメトリクスを確認してください）。
実質的にフラッシュ容量を使用せず（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を使用してください。

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

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

うーん、スマートフラッシュログのライトバックの定義は、
スマートフラッシュログが克服できなかったギャップそのもののように聞こえます。そうなんですね。

(余談ですが、Write-BackとWrite-Throughという用語に馴染みがない方はご注意ください。
これらは、データトランザクションのためにExadataのフラッシュキャッシュを設定できる2つの方法です。
"ライトスルー」キャッシュはフラッシュキャッシュからIOを読み込みますが、ディスクへの書き込みは行います。)

さて、Exadata 20.1の時点では、X7（またはそれ以上）HCストレージサーバの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の書き込み要求と書き込みMBの個々のストレージサーバーの統計を見ることができます。

Flash Log - Flash Log Write-Backのために強化されたもう一つのセクションです。

ここでハイライトされているのがわかると思いますが、
FC 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ログエントリを受信するため、PMEM 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までお気軽にお問い合わせください。