Buffer テーブル

Buffer テーブルとは、頻繁に挿入・削除が発生するテーブルを指します。ここでの「テーブル」にはインデックステーブルも含まれます（メインテーブルのインデックス列を更新すると、それはインデックステーブルにおいて削除および挿入操作として反映されます）。Buffer テーブル問題は、LSM-Tree メカニズムを採用したストレージエンジンに共通する問題です。LSM-Tree アーキテクチャのストレージエンジンでは、データはベースラインデータと増分データに分かれており、増分データは主にメモリ内の MemTable に存在し、ダンプによってディスクに書き込まれるダンプ SSTable、日次マージ時にディスクに書き込まれるベースライン SSTable を経由して管理されます。クエリ実行時には、MemTable、ダンプ SSTable、ベースライン SSTable のデータを統合して最終的な結果が生成されます。このアーキテクチャでは、削除されたデータはマークされるだけであり、日次マージ前には物理的に削除されません。増分データにマークされたデータが大量に蓄積されると、上位アプリケーションから見た実際に存在する行数は非常に少なくなりますが、範囲クエリの処理では多くのマークされたデータを扱う必要があるため、SQL の実行時間が理想的でない場合があります。また、Buffer テーブルのシナリオでは、オプティマイザーが非最適な実行計画を生成しやすくなります。

以上の分析から、Buffer テーブルには以下の特徴があると言えます：

• トリガー条件：

  テーブル内のデータが頻繁にかつ大規模に更新される。

• 発生シナリオ：

  • アプリケーションロジックにおいて、大量の挿入・削除操作が発生する。

  • アプリケーションロジックにおいて、インデックス列の更新が頻繁に発生する。

• 直接的な現象：

  テーブルの行数は多くないが、クエリの実行速度が非常に遅い。

• 問題の原因：

  • マークされたデータにより、範囲クエリの処理量が増加する。

  • 実行計画が非最適である。

V$OB_SQL_AUDIT ビューで SQL 問題と判断された場合、疑わしい SQL に範囲クエリの特徴がある場合は、そのテーブルが Buffer テーブルであるかどうかをさらに確認できます。

Buffer テーブルの検出ロジック

内部ビューを使用して、テーブル単位の総行数および挿入・更新・削除の各行数の増分を集計し、以下のいずれかの条件を満たす場合、Buffer テーブルと判断できます：

• メインテーブルにおいて大量の挿入と削除が同時に発生する：挿入行数の増分と削除行数の増分が近く、かつ挿入および削除の行数が多い。

• インデックス列の更新が大量に発生し、更新行数の増分が総行数に占める割合が高く、かつ更新行数が多い。

この問題に対処する方法は以下のとおりです：

• より最適な実行計画が存在するか分析し、CREATE OUTLINE ステートメントを使用して手動でバインドする。

• マージを手動でトリガーし、マークされたデータを物理的に削除する。

より最適な実行計画がなく、マージによる解決が必要であり、かつ迅速な復旧が求められる場合は、以下の手段を試すことができます：

• スケールアウト

• システムパラメータ cpu_quota_concurrency の値を大きくする

  cpu_quota_concurrency は、テナントの各 CPU クォータが許可する最大並列数を設定します。詳細については、cpu_quota_concurrency を参照してください。

• 問題の SQL に対するトラフィック制限（可能な限り小さなトラフィック、あるいは制限・停止）