ログバッファを"回転寿司"で例えてみた

& Exadataの歌を作ろうよ!

* この記事は、JPOUG Advent Calendar 2017 19日目の投稿です。

*「俺のALTTER文がこんなにFullScanするわけがない」という記事と標題の記事とどちらにしようか悩みましたが、こちらの記事を投稿します。(ALTER文で外部参照整合性制約を付与した際のクエリ遅延、ALTER文に内包された再帰SQLが大暴れした話について)

みなさん、おはようございます、こんにちは、こんばんは、おやすみなさい。閲覧いただきありがとうございます。予め乱筆乱舞お詫び申し上げておきます(汗)

「はじめに」、以下(イカ)迷走いたしますので、迷子にならないための羅針盤として以下のドキュメントのリンクを載せておきます。

・待機イベント LOG FILE SWITCH COMPLETION について (ドキュメントID 1719440.1)
・REDOログバッファキャッシュのチューニング及びREDOラッチの競合の解決方法(ドキュメントID 1715931.1)
・待機イベントの説明

buffer# 同期化する必要があるREDOログ・バッファ内の物理バッファの数。

・NOLOGGINGオペレーションの実行要件(ドキュメントID 1724056.1)
・ redo wastage:統計情報の説明

今回は、標題の通り、REDOログバッファ周りについて、例える必要はないのですが「たとえ警視」のように無理矢理例えてみようと思います。

『ダウンタウンのごっつええ感じ』の「たとえ警視」

「たとえ警視」よろしくログバッファを回転寿司にと例えてみた・・・

伝われ!!
伝われ・・・!!

■ 1. ログバッファ全体を「回転寿司のレーン」とします。レーンにはお寿司に関係なく常にお皿がみっしり詰まっています。お皿は無限に湧いてくる。

■ 2. ログバッファからREDOログファイルへの書き込みはOSブロック単位(OS依存)で書き込まれるので、 その区切りを「お皿」とします。

■ 3. REDOエントリ(変更履歴)を生成は「寿司職人がお寿司を握る」行為。トランザクションは「寿司職人」とします。
同時実行トランザクションがN個あれば、N人の寿司職人が寿司を握っている状態とします。 1SQLあたり1つのREDOエントリ(1つの寿司)。関連する索引への変更も1つの寿司です。1トランザクションでM個のSQLが発行されれば、M個の寿司(REDOエントリ)が握られます。

■ 4. 「寿司」のお米にははチェンジベクタ(1つのDBブロックがどう変わったの記録。1つのSQLで変更されるDBブロック数が多いほどお寿司は大きくなります)が詰っています

■ 5. 繰り返しになりますが、REDOエントリ(寿司)はチェンジベクタ(お米)の集合。

・・・このように、ガチャガチャしていますが、見立ててみます。(苦しい)

*上記の見立てに絡んでくるv$sysstat のREDO関連の統計
redo entries: REDOへ書き込まれたエントリ数
redo size: REDOへ書き込まれたバイト数
redo wastage: REDOを浪費したバイト数
redo writes: REDOへ書き込んだ回数
redo blocks written: REDOへ書き込まれたブロック数

REDOエントリ(寿司)が、”お皿単位で”REDOログファイル/ディスクに(お客さんが回転寿司のレーンから取るように)書き込まれるタイミングは以下の通り・・・

たとえは続きます(伝われ・・・)

■ 1. REDOエントリを作ったトランザクションが確定したとき
→寿司を作った寿司職人さんへの注文が〆られた(タッチパネルからお寿司を注文する動作が一旦区切られた。コーン、マグロ、イカ・・・と。一旦これで。みたいな)とき

■ 2. REDOエントリが変更を記録しているDBブロックがバッファキャッシュからデータファイルに書き込まれたとき
→寿司の中身の内容(米)が、バッファキャッシュからデータファイルに書き込まれたとき(バッファキャッシュは、例えに包括できていない。こ、これは苦しい)

■ 3.REDOエントリがREDOログバッファの 1/3 に達したとき
→回転寿司レーンの1/3 に寿司が埋まったとき

■ 4.直近のREDOログファイルへの書き込みから3秒経過したとき
→回転寿司レーンからお皿が取れたときから3秒経過したとき

*LGWRが一部のお皿を取っている最中であっても、寿司職人はレーンにお寿司を置けます

■REDOの落ち穂拾い①■
redo wastage(浪費・消耗) については下図のイメージ(伝われ)。 上記したようにLGWRによる書き出しのタイミングは、ログバッファ(寿司レーン)が寿司でみっしり一杯になっているとは限らないので、お皿の残った領域は無駄になりますね(ここの例えは、ほんものの回転寿司とはことなる。ほんものの寿司はからなず、皿とお寿司が1:1ですよね)。細かいトランザクションが大量に実行されるようなシステム(職人さんへタッチパネルを使って細かく区切った注文が多い・一度で頼まない)では、このようなディスク領域のwastage部分が発生するのです。
・ redo wastage:統計情報の説明

redo wastage、2ブロックで浪費している図(赤く囲んだ箇所)
redo wastage、1ブロックで浪費している図(赤く囲んだ箇所)

REDOログファイルへの書き込みは、OSブロック単位(お皿単位)で行われるため、1ブロックがいっぱいになる前に書き込まれると浪費する部分がでてくる。
※上図のようにお寿司が1ブロックより大きい場合や、1ブロックより小さい場合は、書き出しのタイミングによってディスク領域に浪費が生じますよね。

■REDOの落ち穂拾い②■
データファイルに対して頻繁に読み書きが繰り返される。DBWRは異なるデータファイルについてランダムに書き込みを行うため、ディスク内のヘッドの移動・シークオーバヘッドが高い。(※ASMファイルで束ねていない場合よりいっそう?)
一方で、REDOログファイルは読み取りは行われない、且つ、REDOログファイルへの書き込みはシーケンシャルで行われるためディスク内のヘッドの移動・シークオーバヘッドは低い。

さ・ら・に、Oracle ExadataでSmart Flash Logが有効であれば、ASM Disk 領域と Smart Flash Log 領域に同時に行い、どちらかに書き込みが完了した時点で、REDO ログの書き込み処理が完了します:)

■REDOの落ち穂拾い③■
例えば、60分間隔でスナップショットを取っているAWRのAWRレポートを生成したとする。1時間あたりREDOエントリ(お寿司≠お皿の取り出し)28GB。秒間 7.8MB。
この秒間は均等に1時間辺りのREDOエントリを3,600で割っただけなので、最大瞬間風力は分からない。
LGWR プロセスの性能限界については、CPU スペックにも依存するため、
一概には言えないが、実績として 30MB/秒程度の REDO 書き込みが可能
と想定すると、8M程度かあ、まだまだサチらないなあと、早合点しがちであるが、秒間の精確な最大値は、AWRレポートだけでは埋もれている可能性もあろう。箆棒な書き出しが最大瞬間風速的に行われている可能性もありんす。

ログスイッチの回数も同じことが言える。スナップショット間隔内での発生頻度を精確に確認したい場合はアラートログなどを確認するべし。

■REDOの落ち穂拾い④■
REDOログバッファ関連のラッチ

この回転寿司レーンは例えと連関していないが(例えではお皿がみっちり詰ったレーン。かつお皿が無限に湧いてくる)、職人さんが寿司を握っているイメージ。大量の寿司を握るとレーンは溢れるが、少なくともレーンの1/3は上書き可能な領域

・redo allocation
REDOログバッファにREDOエントリ(お寿司)を書き込むときに、回転寿司レーンに寿司を置く領域を確保するために必要となるラッチ。 レーンがお寿司で溢れても、少なくともレーンの1/3はすでにredoログファイルに書き込み済だからその部分は上書き可能(上記、書き込まれるタイミング参照)(職人が握った寿司を皿に乗せる際にレーン全体見渡す際の一息)

・redo copy
redo allocationラッチで確保したログバッファ領域に適切にREDOエントリを書き込むために必要となるラッチ。(複数いる職人さん同士が寿司をお皿に乗せる際の阿吽の呼吸)

たとえは以上です。

Exadata のうたをつくろうよ!

苦しまぎれに、もう1つ、小ネタを。

オラクリスト(?)にはお馴染みの歌がありますよね。「ロールバックセグメントの歌」と「データガードの歌」です。

歌は、技術も覚えられますし、我らが聖歌を高らかに歌いあげれば、オラクリストとしての志気も自然と涵養されます。歌は偉大です(瞳をゆっくり閉じる)

新しい歌がそろそろほしいところですよね・・・。

新たな歌作成の機運を高めるために試しに、鼻歌交じりですが、デモテープをつくってみました。

置いておきますね つ

Exadataのうた(デモ)を録音してみました

Exadataのうた (仮歌・デモテープ)

作詞:8273
作曲:作成中(壮大なバラードです)

Oh! 恋のインターコネクト 届いているかな Currentブロック(ほんとの気持ち)
Oh! OS を介さないなんて 二人だけの 秘密の呪文 テレパシーみたいね(ExaFusion~♪)

でもね 魔法じゃないの 伝わっていると 信じている
私ね
トマト・スパゲティは好きだけど
スパゲティ・コードは嫌いなの

So!複雑すぎるStack(かんけい)
Umm 長い旅はもう終しまい
素敵な夢を叶えましょう

— — 50名編成のコーラス隊・ココカラ— — —

Hardware and Software Engineered to Work Together
(ハヤイです!)(ハヤイです!)←汗だくで太鼓を連打する
Hardware and Software Engineered to Work Together
(鉄のオトコ!)(鉄のオンナ!) ←汗だくで尺八を吹く
Hardware and Software Engineered to Work Together
(垂直統合!) (垂直統合!)←汗だくで御神輿を担ぐ

— — 50名編成のコーラス隊・ココマデ — — —

※ ココカラ、DBサーバとストレージサーバの掛け合い を構想しています。
SmartScan や 前述のSmart Flash Log について 歌詞に盛り込む予定です

・・・・それでは、皆様、素敵なクリスマスを!
来年もadventcalendarに参加させていただけるのなら、Application Continuity (できれば、JDBC でなく OCI)に関する記事を書きたいなと考えています。精進いたします。

    八波博和(HirokazuYatsunami)

    Written by

    放送作家→起業・CEO→Oracle Japan ※this is just my personal opinion

    Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
    Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
    Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade