【SAP】テーブルのバッファリングを3分で解説

ABAP

本ページでは、SAPにおけるテーブルのバッファリングの仕組みを解説します。

バッファリングとは、通常データベースサーバ上にあるレコードをプログラムが動くアプリケーションサーバ上に格納することで、レコードへのアクセスを高速化する技術のこと。このページでは、SAPにおけるテーブルバッファの仕組みを3分で分かりやすく解説します。

このページで学べる内容
  • テーブルバッファリングとは?
    • 単一レコードバッファ
    • ジェネリックエリアバッファ
    • フルバッファ(完全にバッファ)
  • テーブルバッファリングの設定方法
  • テーブルバッファリングの注意点

本設定を理解することでパフォーマンスに優れたシステム構築を行うことが可能になります。SAPエンジニアであれば知っておいて損はない重要知識の1つですので、是非最後までご覧ください。

スポンサーリンク

【SAP】テーブルバッファリングとは?

テーブルのバッファリングとは、通常データベースサーバ上にあるレコードをプログラムが動くアプリケーションサーバ上に格納することで、レコードへのアクセスを高速化する技術のことです。

普通、ABAPプログラム(SELECT文など)でレコード検索を行う場合以下のような流れで処理が行われます。

この図が示す通り、レコード検索を行う際にはアプリケーションサーバとデータベース間で通信が発生します。通常この通信がパフォーマンスに深刻な影響を与えることはありませんが、よく参照されるレコードを毎回データベースから引っ張ってくるのは効率的ではありません。

そこで、このよく参照されるレコードをあらかじめアプリケーションサーバに格納しておき、検索効率を高める仕組みがテーブルバッファリングです。

レコードがバッファされていれば、都度データベースを参照する必要はなくなり、アプリケーションサーバ内で処理が完結します。それに伴い、プログラムの実行速度が向上するという仕組みです。

バッファの仕組み

レコードがバッファされるのは、レコードを検索したタイミングです。したがって、レコードがバッファされるのはテーブル設定を行ったタイミングではなく、プログラムが実際にそのレコードを検索したタイミングとなる点に注意が必要です。

バッファの仕組み
  1. プログラムがレコードを検索を行う
  2. バッファを参照する
  3. もしバッファ内に対象のレコードがあれば検索終了
  4. バッファ内に対象のレコードがなければデータベースへアクセス
  5. 次回アクセスに備えて対象レコードをバッファへ格納する

テーブルバッファリングを適切に設定することで、パフォーマンス効率は10倍~100倍になることが期待されます。

ここからはテーブルバッファリングの実際の設定方法を見ていきながら、テーブルバッファリングの種類や利用上の注意点を解説します。

3層アーキテクチャ

3層アーキテクチャとは、クライアントサーバシステムを3階層に分割して構築するシステム形態のことを言います。SAPも通常この構成で構築されるため、ITの基礎知識として押さえておきましょう。

3層アーキテクチャについては、以下の記事で詳しく解説しております。

テーブルバッファリングの設定

テーブルバッファリングの設定は、以下の画面―テーブルの「技術設定」画面で行います。赤枠内がバッファリングに関する設定箇所です。

テーブル設定画面

テーブルの設定は以下のメニューから遷移します。

SAPメニュー > ツール > ABAPワークベンチ > 開発 > ABAPディクショナリ(SE11)

詳しい画面操作は以下の記事で解説しておりますので、詳しく知りたい方は合わせてご参照ください。

まずは、バッファリングを不可とするか可とするかを設定します。

バッファリングを有効化する場合は「バッファリング有効化済」を選択。バッファリング有効化済を選択した場合、バッファタイプを選択する必要があります。

以下では、それぞれのバッファタイプにつて解説します。

3つのテーブルバッファタイプ

バッファタイプには以下の3種類存在します。

それぞれの特徴を知り、適切なバッファタイプを選択できるようにしましょう。

バッファタイプ
  • 単一レコードバッファ
  • ジェネリックバッファ
  • 完全にバッファ

単一レコードバッファ

単一レコードバッファを設定した場合、バッファ(つまりアプリケーションサーバに覚えさせること)するのは対象テーブルで実際に検索されたレコードのみになります。

もし、1レコードではなく3レコード検索された場合は、バッファ領域にはこの3つのレコードが格納される仕組みです。10レコード検索された場合は、10レコードがバッファされます。

単一レコードバッファという言葉に惑わされて、1レコードのみがバッファされると誤解しないように注意しましょう。

単一レコードバッファは、確保するバッファ領域が小さくて済むという利点があります。一方で、バッファするレコードが少ないため、テーブルの内容によってはバッファ本来のメリットを発揮することができない場合もあります。

ジェネリックエリアバッファ

ジェネリックバッファは少し特殊で、検索されたレコードと同じキーを持つレコードをバッファする仕組みです。

ジェネリックエリアバッファを利用する場合、「キー項目数」を設定します。ー項目数が例えば「2」と設定されている場合、データの左から2つの項目が一致しているデータを全てバッファすることになります。

完全にバッファ(フルバッファ)

フルバッファでは、対象のテーブルに含まれる全データをバッファします。

次回レコード検索が行われる場合はデータデータベースサーバへの要求は行われません。どのようなデータでも当該のテーブルであれば、アプリケーションサーバのバッファからデータを読み込むことになります。

一番便利に見えますが、その分バッファ領域を圧迫してしまう危険性もあるため注意が必要です。

再掲:バッファ処理の流れ
  1. プログラムがレコードを検索を行う
  2. バッファを参照する
  3. もしバッファ内に対象のレコードがあれば検索終了
  4. バッファ内に対象のレコードがなければデータベースへアクセス
  5. 次回アクセスに備えて対象レコードをバッファへ格納する

テーブルバッファリングの注意点

最後に、テーブルバッファリングの注意点について。

バッファリングは便利な仕組みですが、陥りがちな罠も結構あるので要注意です!

注意点1:バッファリングは必要最低限で設定する

テーブルバッファリングを設定すると、アプリケーションサーバのバッファ領域とデータベース間で同期をとる必要が出てきます。このために、アプリケーションサーバのバッファとデータベースの同期をするために、一定期間で同期通信が発生します。

この同期通信では、対象のデータが多ければ多い程同期通信の量が増出します。したがって、あまりにも大きいテーブルをバッファしてしまうと、パフォーマンス低下につながります。バッファすることによる通信量の削減を、同期通信での通信量が上回ってしまうと結果としてパフォーマンスが低下してしまいます。

注意点:バッファされたデータが最新ではない可能性がある

同期通信が一定間隔で行われるため、アプリケーションサーバ上のデータとデータベースサーバの実際のデータに差異がでるタイミングがあります。したがって、バッファしたデータが最新のものではない可能性があることを考慮しなければなりません。

以下の記事に、バッファの苦労話がまとめられていますが、こちらはまさにその一例です。

TVARVCで痛い目をあった話【SAP ECC】

もし実際のテーブルデータとバッファリングしているデータに差異が発生した場合は、以下のコマンドを実行します。

バッファのリセット

コマンド項目:$TAB

コマンド項目(=トランザクションコードを入力する場所)に「$TAB」と入れてEnterボタンを押下し実行します。これで、アプリケーションサーバ上のバッファをリセットすることができます。

ただし、このコマンドを1度実行すると、終了まで3~7時間ほどかかるため実行には注意が必要です。また、バッファリセットの実行中はシステムパフォーマンスを大きく低下させてしまうため、非常時以外の利用は避けましょう。

SAP/ABAPを1から勉強したい方は

SAP/ABAPを1から学習したい初心者の方向けに、できるだけ網羅的にABAPが理解できるよう以下ページに知識体系を整理しています。

特に初心者のうちは、どこから学べばよいか?どう勉強すれば良いか?すらわからない状態になりがち。

ある程度の知識を持ったうえで、はじめて実践的な理解へとつながります。

是非、一度ご覧になってみてください。

タイトルとURLをコピーしました