～パフォーマンスを支える小さな巨人、適切なバッファ設計とは～
■ はじめに
Oracleのマスタテーブルは、更新頻度は低くても、高頻度で参照されるため、性能に大きく影響します。
特に、バッファキャッシュにどれだけ効率よく保持できるかが、トランザクション処理性能に直結します。
この記事では、マスタテーブルの設計と合わせて、キャッシュ戦略（KEEPバッファ）によるメリットとデメリット、
キャッシュから追い出された場合に性能が劣化する仕組みまで掘り下げて解説します。
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？
■ マスタテーブルとは
| 項目 | 内容 |
|---|---|
| データ量 | 数十件～数百件程度 |
| 更新頻度 | 非常に低い（マスタ更新はリリース時のみ等） |
| 参照頻度 | 極めて高い（トランザクションごとにJOINされる） |
| 例 | 都道府県マスタ、ステータスマスタ、商品分類マスタなど |
📘【図1】トランザクションテーブルとマスタテーブルの関係
M_STATUS（ステータスマスタ） T_ORDER（注文テーブル）
┌─────────────┐ ┌────────────────┐
│STATUS_ID PK │◄────┐│STATUS_ID FK │
│STATUS_CODE │ │ORDER_ID │
│STATUS_NAME │ │ORDER_DATE │
└─────────────┘ └────────────────┘
1件の注文につき1回参照される
→ 1日10万件の注文 → マスタが10万回アクセスされる
■ KEEPバッファプールによるキャッシュ戦略
OracleはデータブロックをSGA内のバッファキャッシュ（DB Cache）に格納して処理します。
特定のテーブルをKEEPバッファプールに指定することで、キャッシュから追い出されにくくなり、I/Oを抑制できます。
ALTER TABLE m_status STORAGE (BUFFER_POOL KEEP);
■ KEEPバッファのメリット
| 項目 | 内容 |
|---|---|
| I/O回避 | ディスクアクセスが不要になり、バッファから即座に取得可能 |
| レスポンス高速化 | マスタ参照時の遅延が減少し、JOINや表示処理が高速化 |
| 一貫性確保 | 繰り返し使われるマスタが常にメモリにあるため、性能のばらつきが減少 |
📘【図2】KEEPバッファのイメージ
+-------------------------------+
| バッファキャッシュ（SGA） |
| ┌─────────────┐ |
| │DEFAULT CACHE │ ← 通常の表 |
| ├─────────────┤ |
| │KEEP CACHE │ ← M_STATUS等のマスタ│
| └─────────────┘ |
+-------------------------------+
■ KEEPバッファのデメリット（過剰な利用はNG）
KEEPバッファは万能ではありません。
特に以下のような 設計ミスや過剰指定によって、逆にSGA全体の効率が落ちることがあります。
| デメリット | 内容 |
|---|---|
| 限定サイズの競合 | DB_KEEP_CACHE_SIZE は静的に割り当てられるため、使用可能領域が限定的 |
| 大規模テーブルの指定NG | KEEPに数万件規模のテーブルを指定すると、他の重要な小テーブルが入らない |
| 誤った指定で効果なし | アクセス頻度の低い表をKEEPにしても、バッファを無駄に使うだけ |
| 運用難易度の上昇 | どの表をKEEP対象にするかの選定が属人的になりやすく、再検証が必要 |
📘【図3】KEEPバッファの競合イメージ
NG例：
KEEPバッファにM_PRODUCT（10万件）を指定した結果…
┌──────────────┐
│ KEEP BUFFER │ ← M_PRODUCTで占有（サイズ2GB）
│ │ ← M_STATUSなどが入り切らず、性能劣化
└──────────────┘
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？
■ バッファから追い出されると性能が劣化する理由
Oracleはメモリ（バッファキャッシュ）にデータブロックがあれば、直接メモリから読み取り可能ですが、
キャッシュから追い出されると、毎回ディスクI/Oが発生することになります。
🔍 性能劣化の原因
| 項目 | 内容 |
|---|---|
| 物理I/Oの増加 | ディスクからの読み込みはメモリより桁違いに遅いため、SQL応答時間が増加 |
| ラッチ・競合発生 | キャッシュを再取得するための排他制御が発生し、ラッチ競合につながる |
| CPU時間の増大 | 無駄な読み込みとI/O待機時間により、CPUリソースを圧迫 |
📘【図4】キャッシュヒット率が下がると起きること
正常： SQL実行 → バッファキャッシュにあり → 即取得（ヒット）
性能劣化時： SQL実行 → バッファにない → ディスクI/O発生（ミス）
結果： 1行取得に数ms→数十msの遅延 → 全体性能が低下
■ KEEP対象の選定基準
KEEPバッファに入れるべき対象は、以下すべてを満たすものが原則です。
| チェック項目 | 推奨基準 |
|---|---|
| テーブルサイズ | 数百件以内（最大でも数千件程度） |
| 参照頻度 | 1日1万回以上の参照が発生している |
| 更新頻度 | 月1以下、または設計上更新されないことが明確である |
| 重要度 | JOIN先でパフォーマンスに影響を与える中心的な表 |
■ アプリ側キャッシュの併用
マスタの内容がアプリ側で使われるだけであれば、
JavaやPHP等のアプリケーション層でメモリ保持するキャッシュも極めて効果的です。
1. 起動時に全マスタをSELECTして読み込み
2. メモリ内のMap/Dictに格納
3. DBにアクセスせずに利用可能
更新が必要な場合は、バッチや再読み込みフラグで制御可能です。
■ まとめ
| 観点 | 内容 |
|---|---|
| マスタ設計の基本 | 安定したPK、ユニーク制約、論理削除カラムの設計 |
| キャッシュ戦略 | KEEPバッファプール、ヒント句、アプリ層キャッシュの併用 |
| KEEPの注意点 | 限定サイズ、過剰使用NG、誤指定によるバッファ圧迫 |
| バッファ外の性能劣化理由 | 毎回I/O発生、キャッシュミスによる待機増加、実行計画の遅延化 |
■ おわりに
マスタテーブルは小さなテーブルですが、設計・運用の仕方次第で、
Oracle全体の性能・可用性・運用効率に大きな影響を与える存在です。
正しい設計に加え、バッファを活かす戦略的なキャッシュ設計を行うことで、
業務全体の処理性能を安定させることができます。
[参考]
Oracle Database データベース開発ガイド 19c
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？
コメント