【Db2 Genius Hub】導入前に知っておきたいサイジングの考え方 ～実環境から見積もってみた～

目次

• はじめに
• Db2 Genius Hub の構成を整理する
  • REPODB の主要テーブルカテゴリ
• DMC と Genius Hub の関係
• 実測データから見る REPODB のサイズ感
  • 実測環境の概要
  • テーブル別実測サイズ（上位 10）
  • 収集間隔の実測値
  • テーブルの「行長」と「増加要因」
• ディスク容量の見積もり
  • 消費源の優先度はモニター対象の業務特性による
  • 各消費源の計算式
  • 監視 DB 数別ディスク目安（REPODB）
• データプルーニングによる容量抑制
  • モニタリングデータのプルーニング（最重要）
  • その他のプルーニング（補足）
• CPU・メモリーの目安
  • メモリーの構成要素
  • 監視 DB 数別サーバースペック目安
  • CPU 見積もりの参考値
• まとめ
• 参考情報
• シリーズ一覧

---

はじめに

記事「概要 Db2 Genius Hubとは」 では Genius Hub の全体像を、
記事「ログフルエラー発生！～調査と対応はどうすれば？～」 では運用時のトラブル対応を取り上げました。
今回はいよいよ 「導入前に必ず決めなければならないサイジング」 がテーマです。

Genius Hub の導入を検討しているお客様から、よくこんな質問をいただきます。

よくある質問

• 「どのくらいのサーバーが必要ですか？」
• 「モニターデータはどのくらい増えますか？」
• 「10 DB 監視したら何 GB 用意すればいいですか？」

残念ながら、現時点では Genius Hub 公式マニュアルに十分なサイジング情報がありません。
そこで本記事では、

• Genius Hub の技術基盤である Db2 Data Management Console (DMC) のアーキテクチャ
• モニターデータが格納される REPODB のテーブル定義と実測データ
• IBM Redbook「IBM Optim Performance Manager for DB2 for Linux, UNIX, and Windows (SG24-7925-00)」のキャパシティープランニング情報

をもとに、実用的な見積もり方法 をご提案します。

免責事項
本記事の数値はあくまで推定・目安です。正確なサイジングは実際のワークロードに基づいて検証してください。
パーティション DB 環境や大規模構成については IBM サポートにご相談ください。

---

Db2 Genius Hub の構成を整理する

Db2 Genius Hub は、IBM が提供する AI 搭載の Db2 データベース運用管理プラットフォームです。
その中核技術は前身となった Db2 Data Management Console (DMC) であり、内部に REPODB（リポジトリーデータベース） を持ちます。

REPODB の主要テーブルカテゴリ

REPODB のテーブル定義と実測データを解析すると、大きく 4 種類のテーブルが存在します。

カテゴリ	代表テーブル	データ特性
設定・マスター系	PROFILE, JOBS, SCHEDULES, PRUNING_SETTING	行数少・固定的。サイジングへの影響は軽微
テーブル統計系	TABLEINDEX, TABLEINDEX_PERFORMANCE, tableperformance	実測で最大の消費源。テーブル数 × 収集間隔 × 保持期間で増加
セッション・ワークロード系	sessions, unitsOfWorks, INFLIGHTSTATEMENT, PACKAGE_CACHE	DB 負荷に比例して増加。プルーニング対象
監査・ログ系	AUDIT_LOG, EXECUTIONRECORD, BLACKOUT_HISTORY	監査ログ量に依存。定期プルーニングで制御可能

ポイント
全テーブルに COMPRESS YES ADAPTIVE が付与されています。
Adaptive Compression により実データは DDL 定義サイズより 30〜50% 程度圧縮 されます。
サイジングの計算式は圧縮後の実効サイズで考えましょう。

---

DMC と Genius Hub の関係

Genius Hub は DMC（Db2 Data Management Console）を技術基盤として採用しています。
DMC は旧来の Optim Performance Manager (OPM) の流れを汲む製品であり、
IBM Redbook のキャパシティープランニング手法が Genius Hub のサイジングにも参考になります。

製品	位置付け	REPODB 使用
DB2 Performance Expert	旧世代（2002年〜）	あり（Performance Warehouse）
Optim Performance Manager (OPM)	Web UI 世代（2010年〜）	あり（SHORTTERM/LONGTERM）
Db2 Data Management Console (DMC)	コンテナー対応（2019年〜）	あり（IBMCONSOLE スキーマ）
Db2 Genius Hub	AI 統合版（現行）	あり（REPODB）

---

実測データから見る REPODB のサイズ感

実測環境の概要

実際の REPODB（Db2 12.1.3、監視対象 3 DB、約1カ月稼働）を計測した結果を示します。

この検証環境の特殊性について
本検証は REPODB の内部構造確認を目的とした意図的な特殊構成です。

• 監視対象 DB はテスト用途（TPCDS ベンチマーク DB）で、業務 SQL がほとんど発行されていない
• REPODB 自身も監視対象に含めており、通常の本番運用では不要な構成

このため、セッション数・SQL 発行数に依存するテーブル（sessions・PACKAGE_CACHE 等）は 業務環境より大幅に小さい値になっています。
業務環境でのサイジングには後述の計算式を参照してください。

表スペース実測値（TS4CONSOLE）：

表スペース	使用容量	割当容量	ページサイズ
TS4CONSOLE（IBMCONSOLE 全テーブル）	10.0 GB	10.0 GB	32 KB
SYSCATSPACE（システムカタログ）	0.3 GB	0.3 GB	32 KB

テーブル別実測サイズ（上位 10）

3 DB・約1カ月稼働時の実測値（32 KB ページ換算）。

順位	テーブル名	NPAGES	概算容量	説明
1	TABLEINDEX	146,237	≒ 4.5 GB	索引統計（後述：収集構造に注意）
2	TABLEINDEX_PERFORMANCE	18,083	≒ 0.56 GB	索引パフォーマンス詳細
3	sessions	7,315	≒ 0.22 GB	アクティブ・セッション情報
4	unitsOfWorks	2,614	≒ 0.08 GB	トランザクション（UoW）情報
5	PACKAGE_CACHE	1,875	≒ 0.06 GB	パッケージ・キャッシュ SQL 情報
6	monGetMemoryPool	1,123	≒ 0.03 GB	メモリー・プール統計
7	tableperformance	915	≒ 0.03 GB	テーブル I/O パフォーマンス
8	LOCKS	565	≒ 0.02 GB	ロック情報
9	WORKLOAD	438	≒ 0.01 GB	ワークロード統計
10	TABLESPACE	422	≒ 0.01 GB	表スペース統計

収集間隔の実測値

実際の REPODB のタイムスタンプから確認した収集間隔：

テーブル	収集間隔（実測）	1スナップショット行数	備考
PACKAGE_CACHE	5 分	ユニーク SQL 文数に依存	SQL 収集が有効な場合
sessions	〜11 分	セッション数に依存	セッション発生時に収集
INFLIGHTSTATEMENT	リアルタイム	アクティブ SQL 数に依存	アクティブ SQL 発生時のみ
TABLEINDEX	1 時間	索引総数（上限 5,000 行/DB）	索引統計。MON_GET_INDEX 表関数の結果を1行ずつ保存したもの
TABLEINDEX_PERFORMANCE	1 時間	〜1,577 行/DB	索引パフォーマンス詳細

テーブルの「行長」と「増加要因」

TABLEINDEX は行長が短い（38 バイト/行）固定長カラム中心の構造です。
一方、業務 SQL が流れる環境で急増するテーブルは 行長が長く、且つ収集頻度が高い ものです。

テーブル	実測平均行長	収集間隔	増加を駆動する業務要因
PACKAGE_CACHE	194 バイト	5分	ユニーク SQL 文数（SQL 1文 = 1行・最優先）
sessions	210 バイト	〜11分	同時接続数（接続1本 = 1行、170カラム超）
INFLIGHTSTATEMENT	136 バイト	リアルタイム	実行中 SQL 数（長時間実行 SQL）
unitsOfWorks	76 バイト	〜11分	同時トランザクション数
TABLEINDEX	38 バイト	1時間	索引数（業務負荷に依存しない・固定的）

業務環境での主役は sessions と PACKAGE_CACHE
TABLEINDEX は行長が短く収集頻度も低い（1時間）ため、業務負荷が高い環境では sessions（210B・11分）や PACKAGE_CACHE（194B・5分）のほうが急増します。
OPM Redbook の想定（処理中の実行が主役）は Genius Hub でも本番 OLTP 環境では依然として有効です。

---

ディスク容量の見積もり

消費源の優先度はモニター対象の業務特性による

Genius Hub のディスク消費源は 監視対象環境の特性によって主役が変わります。

環境タイプ	最大消費源	理由
テスト・低負荷 DB	TABLEINDEX	SQL 発行・接続がなく索引統計が相対的に大きい
本番 OLTP（多接続・多SQL）	sessions + PACKAGE_CACHE	行長が長く（190〜210B）、収集頻度が高い（5〜11分）
本番 OLTP（SQL チューニング無効）	sessions + TABLEINDEX	PACKAGE_CACHE を切ればセッション系と索引統計が主役

各消費源の計算式

① パッケージ・キャッシュ（最大消費源 — SQL チューニング有効時）

PACKAGE_CACHE 容量 (GB)
  ≒ ユニーク SQL 文数 × DB数 × (24h × 60min ÷ 収集間隔(5min)) × 保持日数 × 194B ÷ 1,073,741,824

代表例（収集間隔 5 分、保持期間 28 日）：
  SQL  1,000文 × 1DB × 288スナップ/日 × 28日 × 194B ÷ 1GB ≒ 1.4 GB
  SQL  5,000文 × 1DB × 288 × 28 × 194B ÷ 1GB             ≒ 7.2 GB
  SQL 10,000文 × 3DB × 288 × 28 × 194B ÷ 1GB             ≒ 43 GB  ← 要注意

パッケージ・キャッシュのユニーク SQL 数が多い場合は特に要注意
OLTP 系アプリはプリペアド SQL が多く、SQL 文数が 5,000〜10,000 本以上になることがあります。
事前に以下で確認することができます：

SELECT COUNT(*) FROM TABLE(MON_GET_PKG_CACHE_STMT(NULL,NULL,NULL,-2)) AS T;

SQL チューニング機能を使わないなら 無効化することを推奨します。

② セッション・ワークロード系（本番 OLTP で次点の消費源）

sessions 容量 (GB)
  ≒ 同時接続数 × DB数 × (24h × 60min ÷ 収集間隔(11min)) × 保持日数 × 210B ÷ 1,073,741,824

代表例（収集間隔 11 分、保持期間 28 日）：
  同時  50接続 × 1DB × 131スナップ/日 × 28日 × 210B ÷ 1GB ≒ 0.04 GB
  同時 200接続 × 1DB × 131 × 28 × 210B ÷ 1GB          ≒ 0.16 GB
  同時 500接続 × 3DB × 131 × 28 × 210B ÷ 1GB          ≒ 1.2 GB

③ 索引統計（TABLEINDEX 系）— 業務負荷に依存しない固定的な消費源

TABLEINDEX 容量 (GB)
  ≒ MIN(索引数, 5000) × DB数 × 24(回/日) × 保持日数 × 38B ÷ 1,073,741,824

代表例（保持期間 28 日）：
  索引  300本 × 1DB × 24 × 28 × 38B ÷ 1GB ≒ 0.009 GB   ← 低負荷/テスト環境
  索引  500本 × 3DB × 24 × 28 × 38B ÷ 1GB ≒ 0.045 GB
  索引 5000本 × 3DB × 24 × 28 × 38B ÷ 1GB ≒ 0.45 GB（上限到達）

監視 DB 数別ディスク目安（REPODB）

パターン A：標準 OLTP（同時接続 100本、ユニーク SQL 2,000文、索引 500本、保持期間 28 日）

監視 DB 数	① PACKAGE_CACHE	② sessions 系	③ 索引統計	設定・ログ (+α)	合計目安
1 DB	〜 3 GB	〜 0.1 GB	〜 0.1 GB	〜 1 GB	4 GB〜
3 DB	〜 9 GB	〜 0.3 GB	〜 0.1 GB	〜 2 GB	11 GB〜
5 DB	〜 14 GB	〜 0.5 GB	〜 0.2 GB	〜 3 GB	18 GB〜
10 DB	〜 29 GB	〜 1 GB	〜 0.5 GB	〜 5 GB	36 GB〜

パターン B：大規模 OLTP（同時接続 500本、ユニーク SQL 10,000文、索引 1,000本、保持期間 28 日）

監視 DB 数	① PACKAGE_CACHE	② sessions 系	③ 索引統計	設定・ログ (+α)	合計目安
1 DB	〜 14 GB	〜 0.6 GB	〜 0.1 GB	〜 2 GB	17 GB〜
3 DB	〜 43 GB	〜 1.8 GB	〜 0.5 GB	〜 5 GB	50 GB〜
5 DB	〜 72 GB	〜 3 GB	〜 0.9 GB	〜 8 GB	84 GB〜
10 DB	〜 143 GB	〜 6 GB	〜 1.8 GB	〜 15 GB	166 GB〜

パターン C：PACKAGE_CACHE 無効（同時接続 200本、索引 500本、保持期間 28 日）

監視 DB 数	① PACKAGE_CACHE	② sessions 系	③ 索引統計	設定・ログ (+α)	合計目安
1 DB	0 GB（無効）	〜 0.2 GB	〜 0.1 GB	〜 1 GB	1 GB〜
3 DB	0 GB（無効）	〜 0.5 GB	〜 0.1 GB	〜 2 GB	3 GB〜
5 DB	0 GB（無効）	〜 0.8 GB	〜 0.2 GB	〜 3 GB	4 GB〜
10 DB	0 GB（無効）	〜 1.5 GB	〜 0.5 GB	〜 5 GB	7 GB〜

パッケージ・キャッシュ収集を有効にする場合は保持期間の短縮で容量削減
パターン B（10DB）では 28 日保持で 166 GB になります。保持期間を 7 日に短縮するだけで 約 1/4 に削減できます。収集間隔を拡げても効果あります。

---

データプルーニングによる容量抑制

Genius Hub は収集したモニタリングデータを 自動的にプルーニング（削除） することで、REPODB の肥大化を防いでいます。

権限に注意
Genius Hub 管理者はプルーニングの閲覧・変更が可能です。データベース管理者は閲覧のみで変更できません。
（出典: IBM Docs — Genius Hub 1.1.x Pruning job / Pruning report / Pruning blackouts）

モニタリングデータのプルーニング（最重要）

REPODB の容量の大半を占める監視データの保持期間は、
モニタリング・プロファイル の データ保持期間 で制御します。
ここが サイジング上もっとも重要な設定 です。

設定場所：
管理 → モニタリング・プロファイル → プロファイルを選択して Edit → 永続性 セクション → データ保持期間（日数）

保持期間のデフォルト値（REPODB 実測）

Genius Hub の設定は REPODB の OBJECT_STORE テーブルに JSON 形式で格納されています。
実環境の keep_result_for_mseconds フィールドを読み取ると：

keep_result_for_mseconds = 2,419,200,000 ms = 2,419,200 秒 = 28 日

全メトリクス共通で 28 日が設定されていることを実測で確認しました。

データ種別	UI タブ名	REPODB テーブル	デフォルト保持期間（実測）	収集間隔（実測）
パッケージ・キャッシュ SQL 情報	パッケージ・キャッシュ	PACKAGE_CACHE	28 日	5 分
セッション情報	処理中の実行	sessions	28 日	〜11 分
トランザクション情報	処理中の実行	unitsOfWorks	28 日	〜11 分
処理中の SQL 文スナップショット	処理中の実行	INFLIGHTSTATEMENT	28 日	リアルタイム
テーブル・索引統計	モニタリング	TABLEINDEX	28 日	1 時間
テーブル・索引パフォーマンス	モニタリング	TABLEINDEX_PERFORMANCE	28 日	1 時間

デフォルト 28 日はどのテーブルにも適用されます
TABLEINDEX だけで 3 DB・28 日で約 4.5 GB 消費します。
監視 DB 数やテーブル数が多い場合、デフォルト設定のまま運用すると REPODB が急速に肥大化します。
SQL数が非常に多い環境では保持期間を 7〜14 日 に短縮することも検討してください。

保持期間とディスク消費量の関係

以下は実測値をもとにした保持期間別の容量目安です（監視 DB 3本・テーブル約 500 本/DB 想定）。

保持期間	REPODB 推奨容量	用途
7 日	〜 10 GB	直近 1 週間のトラブル調査に対応
14 日	〜 20 GB	週次レポート・週次比較が可能
28 日（デフォルト）	〜 40 GB 以上	⚠️ テーブル数が多い環境では急増
28 日（テーブル数多い場合）	〜 100 GB 以上	⚠️ テーブル 2000 本以上では危険

自動削除の仕組み

Genius Hub は データ保持期間 を超えた古いモニタリングデータを 自動削除 します。
削除キーは各テーブルの LEVEL_TAG（収集時刻を示す BIGINT 値）です。
Repository Server（Java プロセス）が定期的にスキャンし、期限切れの LEVEL_TAG に紐づくデータを DELETE で削除します。

自動削除が何らかの理由で機能しない場合は、deleteRepoData_expired.sh スクリプトで手動削除できます。
（出典: IBM Docs — Deleting expired monitor data）

---

その他のプルーニング（補足）

REPODB にはモニタリングデータ以外にも、以下の 3 種類のプルーニングがあります。
これらは容量への影響が比較的小さいため、補足情報として扱います。

種別	設定場所	成功レコードのデフォルト	失敗レコードのデフォルト
ジョブ実行履歴	管理 → ジョブ → ⚙	7 日	30 日
レポート実行履歴	管理 → レポート → ⚙	7 日	30 日
ブラックアウト履歴	管理 → ブラックアウト → ⚙	7 日	30 日

プルーニングのスキャンは毎日 00:00:00（サーバー時刻）に実行されます。
時刻を変更したい場合は以下の設定ファイルを編集してコンソールサーバーを再起動してください。

# <DGH_install_directory>/Config/dswebserver_override.properties
pruning_start_time = 02:00:00

「Disable pruning」に注意
プルーニングを無効（Disable pruning）にすると、データが無期限に蓄積されます。
特別な理由がない限り、有効な状態を維持してください。

---

CPU・メモリーの目安

メモリーの構成要素

OPM Redbook の計算式を参考にすると、Genius Hub サーバーのメモリーは以下の要素で構成されます。

メモリー計算式：

合計 (GB) = Repository Server + Console Server + REPODB BP + OS

  Repository Server 基本 :  200 MB（固定）+ 監視 DB 数 × 8 MB
  Console Server         :  512 MB（同時ユーザー ≦ 10 名）
                             768 MB（11〜30 名）/ 1,024 MB（31〜50 名）
  REPODB バッファープール  :  3 GB（監視 DB ≦ 10）
  OS 用途                :  2 GB（固定）

例）5 DB・同時ユーザー 5 名：
  (200 + 5×8) MB + 512 MB + 3 GB + 2 GB ≒ 約 6 GB
  → 余裕を持って 16 GB 推奨

監視 DB 数別サーバースペック目安

前提：同時コンソールユーザー ≦ 10 名、保持期間 14 日

監視 DB 数	CPU コア目安	メモリー目安	REPODB ディスク	推奨プロファイル
1 DB	2 コア以上 (2 GHz+)	8 GB	20 GB〜	最小構成 / PoC 向け
3 DB	4 コア以上 (2 GHz+)	16 GB	50 GB〜	標準本番構成
5 DB	4 コア以上 (2 GHz+)	16 GB	80 GB〜	標準本番構成
10 DB	8 コア以上 (2 GHz+)	32 GB	150 GB〜	大規模本番構成

テーブル数が多い DB（2,000 本以上）を含む場合は上記の 2〜3 倍を見込んでください。
また REPODB の TS4CONSOLE 表スペースのファイルシステムが満杯になると監視が停止します。定期的な容量監視を推奨します。

CPU 見積もりの参考値（OPM Redbook Table 2-6 より）

注: Redbook 記載は pSeries P5 1.9GHz プロセッサー基準です。現代の 2 GHz+ サーバー CPU では同等以上の性能が期待できます。

監視 DB 数	トランザクション率 (K/分)	同時コンソールユーザー	CPU 目安
10 DB 以下	〜 15 K/分	〜 5 名	2 コア (2 GHz+)
10 DB 以下	〜 20 K/分	〜 10 名	2 コア (2 GHz+)
20 DB 以下	〜 10 K/分	〜 10 名	2 コア (2 GHz+)

---

まとめ

本記事で紹介したサイジング目安を一覧にまとめます。

REPODB ディスク目安（3パターン別・デフォルト収集間隔・保持期間 28 日）

	パターン A（標準 OLTP）	パターン B（大規模 OLTP）	パターン C（PC 収集無効）
前提	接続 100本・SQL 2,000文	接続 500本・SQL 10,000文	接続 200本・SQL なし
1 DB	4 GB〜	17 GB〜	1 GB〜
3 DB	11 GB〜	50 GB〜	3 GB〜
10 DB	36 GB〜	166 GB〜	7 GB〜
CPU（共通）	2 コア以上	4〜8 コア以上	2 コア以上
メモリー（共通）	8〜16 GB	16〜32 GB	8 GB

ポイントの振り返り

• ① PACKAGE_CACHE が最大の変動要素：ユニーク SQL 10,000文・3DB・28日で約 43 GB。収集不要なら必ず無効化（5分ごと・194B/行）
• ② sessions は本番 OLTP の次点消費源：行長 210 バイト・収集頻度 11分。多接続環境では急増に注意
• ③ TABLEINDEX は業務負荷に依存しない固定的な消費源：行長 38 バイト・収集 1時間。低負荷環境でのみ相対的に目立つ
• 消費源の主役は環境によって変わる：本番 OLTP では ① → ②、SQL 収集無効なら ② → ③ の順
• 全メトリクスのデフォルト保持期間は 28 日（keep_result_for_mseconds = 2,419,200,000 ms を実測で確認）。7〜14 日への短縮を推奨
• TS4CONSOLE（DMS）は自動拡張されるが、OS ディスク残量の定期監視が必要
• 全テーブルに COMPRESS YES ADAPTIVE が設定されているため、実ディスク消費は計算値の 50〜70% 程度になることが多い
• Genius Hub 専用サーバーは 監視対象 DB とは別サーバーに置くことを強く推奨（リソース競合防止）
• プルーニングスキャンは深夜に実行するよう pruning_start_time を設定することを推奨

次のステップ

1. チェックリストを使って現環境の情報を収集する（特に同時接続数とユニーク SQL 文数が重要）
2. パッケージ・キャッシュ収集の要否を判断する（SQL チューニング不要なら 先に無効化）
3. 本記事の 3パターン計算式で自環境の REPODB ディスク容量を見積もる
4. Monitoring profile で データ保持期間 を 7〜14 日 に設定する
5. PoC 環境（1 DB）で実際の REPODB 成長速度を観測・調整する
6. 本番導入後は MON_GET_TABLESPACE で TS4CONSOLE の OS ディスク残量を定期的にモニタリングする

---

参考情報

• IBM Redbook SG24-7925-00: IBM Optim Performance Manager for DB2 for Linux, UNIX, and Windows (Chapter 2.4 Capacity planning)
• IBM Docs — Pruning job (Genius Hub 1.1.x)
• IBM Docs — Pruning report (Genius Hub 1.1.x)
• IBM Docs — Pruning blackouts (Genius Hub 1.1.x)
• IBM Docs — Deleting expired monitor data (Genius Hub 1.1.x)
• IBM Docs — Configuring the default monitoring profile (Genius Hub 1.1.x)

---

📖シリーズ一覧

🌱 基礎編

• 概要「Db2 Genius Hubとは」
• 【Db2 Genius Hub】Trial エディション使ってみた

🚀 導入構成編

• 【Db2 Genius Hub】インストール手順
• 【Db2 Genius Hub】ライセンス適用方法
• 【Db2 Genius Hub】導入前に知っておきたいサイジングの考え方 ～実環境から見積もってみた～
• 【Db2 Genius Hub】モニター対象DBに作成されるオブジェクト

⚙️ 運用編

• 【Db2 Genius Hub】起動・停止・稼働確認方法
• 【Db2 Genius Hub】モニタリング・ダッシュボードを使ってみた
• 【Db2 Genius Hub】Log Analysis機能を使ってみた　

🚨 トラブルシューティング編

• 【Db2 Genius Hub】ログフルエラー発生！～調査と対応はどうすれば？～
• 【Db2 Genius Hub】ロック問題を解決する

---