データベースの物理設計とは？設計項目・進め方・容量見積の実務をOracle 19cで解説

システム開発

データベースの物理設計と聞いて、具体的に何を検討し、どのような根拠で設計値を決めればよいのか、迷うシステムエンジニアは少なくないのではないでしょうか。

実際のプロジェクトでは、Oracleのデフォルト設定をほぼそのまま使用し、表領域の初期容量を決めて自動拡張を有効にするだけで、データベースを構築しているケースも見受けられます。しかし、データが格納でき、システムが正常に動作することと、性能・可用性・運用性まで考慮した物理設計ができていることは別です。

物理設計で重要なのは、設定値そのものではなく、業務特性やデータ量、アクセス傾向、将来の増加量などを把握し、何を検討し、どのような根拠で判断し、どう検証するかというプロセスです。

本記事では、実際のプロジェクトで使用した物理設計書、課題管理表、容量見積Excelをもとに、データベースの物理設計で押さえるべき検討項目と、設計を進めるための具体的なアプローチを解説します。技術解説にはOracle Database 19cを使用し、容量見積や接続数の算定、性能・運用面での設計判断を実例とともに紹介します。

なお、実務事例は過去のプロジェクト資料を匿名化・再構成したものであり、掲載する設定値は案件固有のものです。個々の数値を正解として示すのではなく、自分のプロジェクトで適切な設計値にたどり着くための考え方を伝えることを目的としています。

データベースの物理設計とは？

データベースの物理設計とは、論理設計で定義されたデータを、実際のデータベース環境にどのように格納し、安定して稼働させるかを具体化する工程です。

表領域やデータファイル、メモリ、REDOログ、バックアップなどを設計し、性能・容量・可用性・運用性に関する要件を実現します。

概念設計・論理設計・物理設計の違い

データベース設計は、大きく概念設計・論理設計・物理設計の3段階に分けられます。

設計工程主な内容成果物の例
概念設計業務に必要な情報とその関連を整理する概念ER図
論理設計テーブル、カラム、主キー、外部キーなどを定義する論理ER図、テーブル定義書
物理設計DB製品の仕様や非機能要件に合わせて格納方式と稼働環境を具体化する物理設計書、パラメータ一覧、容量見積書

例えば、注文データを5年間保存するシステムを考えます。

論理設計では注文テーブルの項目やキー、テーブル間の関連を定義します。

一方、物理設計では、初期データ120万件、年間増加30万件という条件から5年後の件数を270万件と見積もり、必要な表領域容量、データファイルの拡張方法、バックアップ方針などを決めます。

つまり、論理設計が「どのようなデータを管理するか」を決める工程であるのに対し、物理設計は「そのデータをどのような構成で稼働・管理するか」を具体化する工程です。

物理設計は誰が担当するのか

物理設計は、インフラエンジニア、DBA、アプリケーション担当者が連携して進めます。

担当主な設計範囲
インフラエンジニアサーバ、OS、ストレージ、DB構成、可用性、バックアップ基盤
DBA表領域、初期化パラメータ、REDOログ、メモリ、権限、DB運用
アプリケーション担当テーブル構造、索引、パーティショニング、SQLアクセス特性
パッケージ・ミドルウェアベンダー製品固有のDB要件、専用スキーマ、必要テーブル、接続方式

担当領域の違いや連携については、以下の記事で詳しく解説しています。

システムエンジニアの種類と仕事内容｜SIerのSEはどこまで担当するのか
システムエンジニアの種類と仕事内容を、PM、アプリ、AP基盤、インフラ、ネットワーク、DBに分けて解説。大手SIerで20年以上働いた筆者の経験から、SEのキャリアの広がりや求められるスキルも紹介します。
sys-univ.com
2026.08.25

実際のプロジェクトでは、この担当範囲の境界で情報が不足することがあります。

私が携わった案件でも、ミドルウェア製品が使用するセッション管理用テーブルについて、製品ベンダーに仕様を確認してからスキーマや表領域を決定しました。また、帳票データの型がBLOBなのかCLOBなのかについて、関係者間で認識が異なっていたこともありました。

物理設計では担当者間の役割分担を明確にするとともに、必要な情報の提供元も確認する必要があります。

本記事では、インフラエンジニア・DBAの立場から行う物理設計に焦点を当て、Oracle Database 19cを例に解説します。

データベース物理設計でやること・設計項目一覧

物理設計では、ソフトウェア構成、表領域、初期化パラメータ、可用性、通信、運用、セキュリティなどを決定します。

実務で使用した物理設計書の章立ても参考にしながら、Oracle 19cで検討する設計項目と成果物、実務上の進め方を整理します。

物理設計の主要設計項目と成果物

【実務事例：物理設計書の章立てから必要項目を把握する】

実際の物理設計書は全10章で構成されていました。次の表は、その章立てを手がかりに、Oracle 19cの物理設計で確認すべき項目を整理したものです。

実際の物理設計書の章立てOracle 19cでの主な検討項目本記事での扱い
第1章 ソフトウェア構成エディション、ライセンス、RU・パッチ方針H2-3
第2章 インスタンス設計CDB/PDB、インスタンス、DBブロックサイズ、キャラクタセットH2-3
第3章 表領域設計SYSTEM等の表領域、業務表領域、データファイルH2-3・H2-4
第4章 REDOログ設計オンラインREDO、スタンバイREDO、アーカイブログH2-3・H2-5
第5章 制御ファイル設計制御ファイルの多重化・配置・復旧H2-3で要点
第6章 通信設計リスナー、サービス、接続方式H2-3で要点
第7章 初期化パラメータ設計メモリ、PROCESSES、SESSIONS、UNDOH2-3・H2-5
第8章 ユーザ設計スキーマ、ロール、プロファイル、最小権限H2-3で要点
第9章 運用設計RMAN、ログ管理、統計情報、性能監視、PDB間のリソース管理H2-3で要点
第10章 セキュリティ設計Unified Auditing、暗号化、アクセス制御H2-3で要点

OS・ストレージやHugePages、ASMなどは、設計書の章立てとは別に、基盤設計側との責任分界を決めて確認します。表は設計項目の把握に使い、実際の成果物の構成はプロジェクトごとに合意します。

最初にエディション・ライセンスとCDB/PDBの設計単位を確定し、後続の表領域やメモリ設計の制約条件を整理します。

物理設計の主な成果物

成果物主な内容
データベース詳細設計書（物理設計書）DB構成、表領域、REDO、通信、運用等の設計方針
環境定義書環境ごとの設定値、サーバ・ソフトウェア構成等
初期化パラメータ一覧パラメータ値、設定理由、適用範囲
容量見積書テーブル、索引、LOB、表領域等の容量
設計課題管理表未確定事項、対応方針、担当、期限
設計進捗管理表設計・レビュー・完了の状況

成果物の名称や分け方はプロジェクトによって異なり、初期化パラメータ一覧などを環境定義書に含める場合もあります。

【実務事例：成果物とフォーマットの合意】

実際の課題管理表では、設計作業の初期に、設計書のフォーマットについて確認を行っていました。

その後、成果物を「データベース詳細設計書」と「環境定義書」の2つとする方針で合意しています。

さらに設計途中で、統一テンプレートが提供され次第、差し替える方針が決まりました。

この経験から、物理設計では内容の検討に入る前に、成果物の名称、記載範囲、使用するテンプレート、レビュー方法を関係者と合意することが重要だと考えています。

物理設計の進め方と依存関係

物理設計の実務では、最初に必要な情報がすべて揃うとは限りません。

実案件の課題管理表にも、システム特性、テーブル定義、データ件数、同時接続数、LOB容量、バッチ処理量などの情報を関係者へ依頼した記録が多数残っています。

設計項目と必要情報の依存関係

必要な入力情報影響する設計項目本記事の解説
システム特性・アクセス傾向DBブロックサイズ、性能設計H2-3
テーブル定義・件数・増加率表領域、データファイル容量H2-4
LOBの型・件数・平均サイズLOB格納方式、容量見積H2-4
同時接続数・接続プールPROCESSES、SESSIONSH2-3・H2-5
トランザクション量・バッチ処理量UNDO、REDO、アーカイブH2-3・H2-5
運用フロー・ログ保持期間バックアップ、ログ管理H2-3で要点

【実務事例：設計FIXの延期】

実案件の課題管理表では、1月中旬から課題が起票されていました。

物理設計書のFIXは当初2月末を予定していましたが、容量見積に必要なデータを2月中に提供できないことが判明し、3月末へ延期されています。

一方、データが揃うまで設計を止めたわけではありません。未確定の情報には暫定値を置いて設計を進め、資料の受領後に見直しました。具体的な方法は後述の容量見積の章で解説します。

物理設計を進める6つのステップ

⓪ 成果物とフォーマットを合意する

設計書、環境定義書、容量見積書などの成果物、記載範囲、テンプレートを関係者と合意します。

① 必要な情報を確認し、不足分を課題として起票する

非機能要件、論理設計書、テーブル定義、業務処理量などを確認し、不足する情報は提供元と期限を明確にして管理します。

② 基本構成を決める

Oracleのエディションとライセンス、CDB/PDB構成、可用性構成、OS・ストレージ方式などを決定します。

③ 未確定事項を管理しながら詳細設計を進める

表領域、容量、REDOログ、メモリ、初期化パラメータなどを設計し、未確定事項には暫定値と根拠を記録します。

④ 設計レビューを実施し、課題を解決する

関係者から提供された情報やレビュー結果を設計書に反映し、未解決課題の影響範囲と確定条件を明らかにします。

⑤ 構築・試験で設計を検証する

構築時に設定値を確認し、移行リハーサルや性能試験で容量、接続数、REDO生成量などを検証します。

次章では、これらの設計項目について、Oracle Database 19cを例に具体的な判断とその根拠を解説します。

Oracle 19cの物理設計で具体的に決めること

Oracle Database 19cを例に、物理設計で決定する主要な項目と、その判断基準を解説します。単なる設定項目の紹介ではなく、実際の設計判断を具体例とともに示します。

最初に決めるソフトウェア構成とライセンス

物理設計では、まずOracleのエディションと利用できる機能を確認します。

Oracle 19cのStandard Edition 2（SE2）ではRACとData Guardを利用できません。また、Enterprise Edition（EE）でも追加ライセンスが必要な機能があります。

機能Oracle 19cでの主な利用条件
RACEE＋RACオプション
Data GuardEEで利用可能
Active Data GuardEE＋Active Data Guardオプション
PartitioningEE＋Partitioningオプション
TDEEE＋Advanced Securityオプション
AWR・ASHDiagnostics Packの利用権が必要
STATSPACKDiagnostics Packなしで利用可能

※実際の利用条件は、契約、導入形態、クラウドサービスなどによって異なります。

【設計判断例：Data Guardによる待機系の参照利用】

障害対策としてData Guardを採用し、待機系を帳票検索にも利用したい場合を考えます。

フィジカル・スタンバイを読み取り専用で開くだけなら基本Data Guardでも可能ですが、REDOの適用を継続しながら参照処理を実行するには、Active Data Guardオプションが必要です。

また、Diagnostics Packを契約しない場合は、CONTROL_MANAGEMENT_PACK_ACCESSをNONEに設定して、有償の診断・チューニング機能を誤使用しないようにします。性能監視にはSTATSPACKなどを採用します。

このように、技術的に実現できる構成と、契約上利用できる構成は区別しなければなりません。

Oracle 19cでは、採用するRelease Update（RU）やパッチ適用方針も物理設計時に決定します。

CDB/PDB構成と設計単位

Oracle 19cでは、CDB（Container Database）とPDB（Pluggable Database）によるマルチテナント構成を基本として設計します。

19cでは非CDB構成も利用できますが非推奨であり、21c以降ではサポートされません。将来のアップグレードを考慮すれば、CDB/PDB構成が基本的な選択となります。

【設計判断例：PDB数とライセンス】

Oracle 19cでは、SE2・EEともにMultitenantオプションを追加契約せず、1つのCDBにユーザー作成PDBを最大3個まで配置できます。

例えば、3つの業務データベースを統合する場合、ライセンス上は1つのCDBに3つのPDBを構成できます。

一方、4つ以上を統合する場合には、Multitenantオプションの利用条件などを確認する必要があります。

ただし、3個まで配置できるからといって、必ず統合するべきではありません。業務ごとの可用性、負荷特性、リソース競合、運用体制を踏まえて決定します。

OS・インスタンス・CDB・PDBの設計境界

設計単位主な設計項目
OS・Grid InfrastructureHugePages、カーネルパラメータ、ASM、リスナー
インスタンスSGA、PGA、PROCESSES
CDB全体標準ブロックサイズ、CDBのキャラクタセット、オンラインREDO、制御ファイル、ARCHIVELOG、Data Guard、Flashback Database
PDBごとSYSTEM、SYSAUX、TEMP、業務表領域、ローカルUNDOモードでのUNDO、アプリ用サービス、ローカルユーザ・ロール
複数階層初期化パラメータ、監査、バックアップ・リカバリ、リソース管理

PDB内で変更できる初期化パラメータは限定されています。次のSQLで変更可能なパラメータを確認できます。

SELECT name, ispdb_modifiable
FROM v$parameter
WHERE ispdb_modifiable = 'TRUE'
ORDER BY name;

RAC構成では、1つのCDBを複数のインスタンスで稼働させます。そのため、SGAなどの資源はインスタンス単位で管理する必要があります。

データベース作成時に決める重要項目

DBブロックサイズとキャラクタセットは、作成後の変更が容易ではないため、慎重に決定します。

【実務事例：8KBと16KBをどう選ぶか】

Oracle 19cでは一般的な8KBを基準に検討します。実際に担当した案件では、標準ブロックサイズに16KBを採用しました。判断材料として記録されていたのは次の3点です。

  • DSS系のシステム特性
  • 行連鎖の発生を抑える
  • テーブルフルスキャン時のI/Oコストを低減する

16KBを採用するかどうかは、これらをそのまま結論にせず、対象システムの行長とI/O・更新特性から判断します。

① フルスキャンのI/O

OracleのDB_FILE_MULTIBLOCK_READ_COUNTは、シーケンシャルスキャンで1回のI/Oに読み込む最大ブロック数を指定します。

19cの既定値はプラットフォームに応じて決まり、多くの環境で最大約1MBの効率的な読み込みに対応するよう自動設定されます。

そのため、8KBから16KBに変更しても、マルチブロック読み込みの総バイト数が単純に2倍になるわけではありません。

フルスキャンが多いという理由だけでは、16KBを採用する十分な根拠にはなりません。

② 行連鎖

レコード長が大きい場合には、大きなブロックを採用することで、行連鎖の発生を抑えられる可能性があります。

一方、平均行長が十分小さければ、16KBを採用する理由としては弱くなります。

移行元のOracleが存在する場合は、DBA_TABLES.AVG_ROW_LENなどを確認し、実データの特性を把握します。

③ 更新処理とブロック競合

ブロックサイズを大きくすると、1ブロックに格納できる行数も増えます。

更新が集中するOLTP系処理では、アクセスが同じブロックに集中する可能性があるため、ブロック競合やバッファキャッシュ効率への影響も評価する必要があります。

したがって、19cでは8KBを基準とし、16KBを採用する場合は代表的なSQLによる性能検証と、実際の行長・アクセス特性を根拠に決定します。

キャラクタセットの選択

Oracle 19cでは、CDBのキャラクタセットとしてAL32UTF8を基本に検討します。

AL32UTF8のCDBには、条件を満たせば異なるキャラクタセットのPDBを収容できます。ただし、文字コード互換性やLOBアクセスの制約は確認が必要です。

CLOBの内部表現と容量への影響については、次章の容量見積で詳しく説明します。

表領域とストレージの設計

Oracle 19cでは、SYSTEM、SYSAUX、TEMPなどの表領域がCDBルートと各PDBに存在します。ローカルUNDOモードではPDBごとにUNDO表領域を管理します。

通常のローカル管理表領域では、ASSMによる空き領域管理とAUTOALLOCATEによるエクステント自動割り当てを基本とします。

エクステントサイズを明示的に管理する要件があればUNIFORMも選択できますが、既定の方式から変更する理由を設計書に残します。

【実務事例：表領域を大・小に分けた見積】

実際の案件では、テーブルサイズや定義レコード長をもとに、表領域を大・小に分けて見積もっていました。

区分実務事例のExcel見積
大区分約68,646MB
小区分約24,785MB
合計約93,431MB

この案件では大きなテーブルと小さなテーブルで固定エクステントのサイズを変えていました。ただし、表領域の分類と固定エクステントの採用は別の判断です。

Oracle 19cではAUTOALLOCATEを基本とし、固定サイズのUNIFORMを指定する場合は、その必要性を個別に検証します。

表領域を分けるかどうかも、単に大きさで決めるのではなく、保存期間、容量監視、バックアップ、リカバリ、移行などの運用要件で判断します。

【設計判断例：240GBの表領域をどう構成するか】

実務事例の容量見積では、テーブル格納表領域を240GBとしています（内訳と見積条件は次章で説明します）。これはファイル構成の考え方を示すための入力値です。

Oracle 19cの8KBブロック環境で240GBを構成する場合、SMALLFILEとBIGFILEの2つの選択肢があります。

比較項目SMALLFILEBIGFILE
ファイル数複数1つ
8KB時の1ファイル上限約32GB約32TB
240GBの構成例30GB×8ファイル240GB×1ファイル
主な考慮点ファイル数と管理大容量ファイルのバックアップ・復旧

SMALLFILEの場合、240GBなら最低8ファイル必要です。運用方針に応じて10ファイル程度に分ける構成も考えられます。

一方、BIGFILEなら1ファイルで構成できます。

ただし、BIGFILEでは大きなデータファイルをどのようにバックアップ・復旧するかが重要になります。

RMANではSECTION SIZEを指定したマルチセクション・バックアップを利用でき、1つの大きなデータファイルを複数セクションに分け、並列にバックアップできます。

例えば、CDBルートに接続したRMANからPDB1のAPP_DATA表領域をバックアップする場合は、次のように指定します。

BACKUP
  SECTION SIZE 8G
  TABLESPACE PDB1:APP_DATA;

※バックアップの並列度は、RMANのチャネル設定などにも依存します。PDBに直接接続する場合は、そのPDB内の表領域名を指定します。

このように、必要容量だけでなく、バックアップ時間、リカバリ方式、ASMやOMFの利用方針を踏まえてファイル構成を決定します。

REDOログ・アーカイブログ・可用性の設計

REDOログの設計では、サイズ、グループ数、多重化、アーカイブ方式を決めます。

【設計判断例：REDOログサイズの決定】

例えば、ピーク時のREDO生成量が毎分20MBで、ログスイッチ間隔の目安を30分とした場合、

20MB×30分＝600MB

となります。

この値をREDOログサイズの初期検討値とし、実際の負荷や運用要件に応じて調整します。

REDO生成量はどのように把握するか

移行元のOracleが存在する場合は、AWRまたはSTATSPACKのredo sizeなどを確認します。

また、V$LOG_HISTORYからログスイッチの頻度を確認できます。ログサイズと組み合わせることで、概算の生成量を推定できますが、ピーク時の厳密なREDO生成量を求めるには、統計情報や実測による確認が必要です。

さらに、V$INSTANCE_RECOVERYのOPTIMAL_LOGFILE_SIZE列も参考になります。

SELECT
  optimal_logfile_size,
  target_mttr,
  estimated_mttr
FROM v$instance_recovery;

OPTIMAL_LOGFILE_SIZEは、FAST_START_MTTR_TARGETなどの設定に基づくREDOログサイズの目安です。FAST_START_MTTR_TARGETを有効に設定している場合に算出され、設定条件によってはNULLとなるため、その場合はREDO生成量やログスイッチ頻度から判断します。

REDOログのグループ数はどう決めるか

REDOログは、ログスイッチによって次のグループへ切り替わります。

ロググループを再利用するまでに、必要なチェックポイント処理やアーカイブが完了していなければ、更新処理が待たされる可能性があります。

したがって、グループ数は単に最小構成にするのではなく、ピーク時のログスイッチ間隔とアーカイブ・チェックポイント処理の時間を踏まえて決定します。

特に大量バッチが存在するシステムでは、ピーク時にロググループが不足しないか検証する必要があります。

なお、Oracle 19cのクラッシュリカバリ時間は、主にFAST_START_MTTR_TARGETなどによって制御します。REDOログサイズだけで復旧時間が決まるわけではありません。

アーカイブの生成間隔を制御する必要があれば、ARCHIVE_LAG_TARGETも検討します。

Data Guardを利用する場合

Data GuardではMaximum AvailabilityやMaximum Performanceなどの保護モードを、データ損失の許容範囲と性能・可用性要件に応じて選択します。

スタンバイREDOログは、各REDOスレッドに対してオンラインREDOと同じサイズを基本とし、オンラインREDOより1グループ多く用意します。

例えば、オンラインREDOが3グループであれば、スタンバイREDOは4グループとします。

Data Guardにおける大量バッチのREDO転送・適用性能の課題については、後述の実案件の章で説明します。

メモリ・初期化パラメータの設計

Oracleのメモリ設計では、SGA・PGAに加えて、プロセス数とセッション数を検討します。

LinuxでHugePagesを利用する場合は、AMM（MEMORY_TARGET）と併用できないため、ASMMなどを採用します。

【設計判断例：PROCESSESの初期見積】

例えば、次の構成を想定します。

接続・プロセスの要素想定数
APサーバ4台×接続プール最大50200
バッチ用30
管理・保守用20
Oracleバックグラウンドプロセス等50
合計300

この場合、PROCESSES=300を初期検討値とできます。

ただし、これは説明用の仮定であり、PDB数、有効機能、並列実行、バックグラウンドプロセスの数によって必要値が変わります。

検証環境ではV$PROCESSなどを利用して実際のプロセス数を確認し、余裕を含めて見直します。

また、APサーバのローリング再起動時には、古い接続プールと新しい接続プールが一時的に併存する可能性があります。このような通常運用以外のピークも考慮する必要があります。

SESSIONSはPROCESSESから派生する

Oracle 19cでは、SESSIONSの既定値は原則として次の式から算出されます。

SESSIONS＝1.5×PROCESSES＋22

例えばPROCESSES=300なら、計算上の既定値は472です。

ただし、PROCESSESとSESSIONSは同一の設定ではありません。PDB単位のセッション制限も含め、アプリケーションの接続方式に合わせて設計します。

実際の案件で、端末数・同時アクセス数とDB接続数をどう区別したかは、後述の課題事例で説明します。

その他の物理設計項目

基盤・運用関連の設計

分類主な設計内容
通信リスナー、サービス名、接続方式
ユーザ・権限スキーマ、ロール、最小権限
セキュリティUnified Auditing、暗号化、アクセス制御
バックアップRMAN、保持期間、復旧方式
統計情報収集方法、実行タイミング
性能監視AWR、STATSPACK、監視項目
リソース管理PDB間のCPU・セッション等の制御

Oracle 19cではUnified Auditingの混合モードが既定の構成です。新規設計では、従来型監査への依存を避け、純粋なUnified Auditingへの移行も検討します。

アプリケーション寄りの物理設計

索引、パーティショニング、非正規化なども広義の物理設計に含まれます。

これらはDBAとアプリケーション担当者が連携して設計します。

また、Amazon RDS for OracleなどのマネージドDBでは、OS、ストレージ、ファイル管理などについて、オンプレミスとは設計できる範囲が異なります。利用するサービスに応じて、設計対象と責任分界点を整理する必要があります。

テーブルサイズ・表領域容量の見積方法と実務ノウハウ

データベースの物理設計で特に難しいのが、容量見積です。物理設計の段階ではテーブル定義やデータ件数が確定していないことも多く、そのような状況でもストレージ容量を決めなければなりません。

ここでは、実際の大規模システムで使用した容量見積Excelと課題管理表をもとに、Oracle Database 19cでも活用できる見積の進め方を解説します。

容量見積に必要な情報と基本的な計算方法

テーブル容量の見積では、次の情報を確認します。

項目確認内容
テーブル定義列、データ型、定義長
平均レコード長1行に格納される平均データ量
初期件数稼働開始時の件数
年間増加件数1年間に増加する件数
保存期間データの保持年数
索引・LOBテーブル本体以外に必要な容量
拡張余裕将来増加と見積誤差への備え

基本的な計算式は以下のとおりです。

将来件数＝初期件数＋年間増加件数×見積年数

テーブルデータ量＝将来件数×平均レコード長

冒頭で例に挙げた注文テーブル（初期件数120万件、年間増加30万件、見積期間5年で、5年後に270万件）に、平均レコード長420バイトを当てはめると、次のようになります。

420バイト×270万件＝1,134,000,000バイト

したがって、データ本体の概算は約1.1GBです。

ただし、Oracleの実際の格納容量には、ブロック管理領域、PCTFREE、エクステント割り当てなどの影響があります。

定義レコード長と平均レコード長は区別する

実案件では、エンティティ定義書から取得した定義上のレコード長を使って概算していました。

この方法は実データがなくても計算できますが、VARCHAR2などの可変長項目では、定義上の最大長が実際の平均長より大きくなる場合があります。

移行元のOracle Databaseが利用できる場合は、DBA_TABLES.NUM_ROWSとAVG_ROW_LENを参照すると、実態に近い見積が可能です。AVG_ROW_LENには行オーバーヘッドも含まれます。

ただし、統計情報が古ければ信頼性が低下します。また、行外LOBのデータ本体は平均行長だけでは評価できないため、別途容量を見積もる必要があります。

必要な情報が揃わないときの暫定見積

実務では、すべてのテーブルの件数や増加量が確定してから物理設計を開始できるとは限りません。

私が担当したプロジェクトでも、物理設計時点では全テーブルの定義と件数が揃っていませんでした。

課題管理表には、業務側に全テーブルの定義と件数一覧を求めた記録が残っています。その中で、必要な資料が不足していても、既存資料から設計を進めるという方針が示されました。

実際には以前に提供されていたエンティティ定義書を利用して見積を開始し、その後に件数や増加率の情報を取得して修正を進めました。定義書の項目長に未記入が見つかり、資料を再確認した経緯もあります。

【実務事例：105テーブルを暫定見積】

実案件の容量見積Excelでは、件数が把握できるテーブルは5年後の推定件数から容量を計算し、初期件数が不明なテーブルには暫定容量を設定しました。

項目事例の見積
暫定扱いのテーブル数105
1テーブルの暫定容量100MB
暫定容量合計10,500MB
Excel上の集計容量約93,431MB
暫定容量の割合約11.2％

※元資料のMB表記を使用。100MBは実際の案件固有の暫定値であり、Oracle 19cの推奨値ではありません。

全体の約11％を暫定値が占めていました。

仮に、この105テーブルの実際の平均容量が300MBだった場合、必要容量は31,500MBとなります。

当初見積10,500MBとの差は21,000MBです。

つまり、未確定部分の見積条件によって、ストレージ容量が大きく変わる可能性があります。

そのため、暫定値については少なくとも以下を記録しておきます。

管理項目記載例
未確定事項初期データ件数
暫定容量100MB
設定根拠類似テーブルの規模、暫定的な仮定
リスク実容量が想定を上回る可能性
確認担当業務設計担当
見直し条件移行対象件数の確定時

重要なのは、情報不足を理由に設計を止めるのではなく、合理的な前提を置いて設計を進め、後から検証・修正できるようにしておくことです。

暫定値は正解ではありません。未確定であることを明示し、関係者と合意して使用する必要があります。

索引・LOBの容量見積

テーブル本体の容量を計算しただけでは、データベース全体の容量は決まりません。

索引容量は、定義が確定していなければ暫定見積する

物理設計段階では、性能チューニングによって索引が追加される可能性があります。

実案件では、索引容量を次のように見積もっていました。

（240GB－80GB）×25％＝40GB

240GBはテーブル格納表領域全体、80GBはLOBを含むテーブルの見積容量です。

この計算では、LOBを除いた160GBを基準に25％を掛けています。

なお、160GBには非LOBテーブルのデータ量120GBに加え、表領域設計上の余裕40GBも含まれるため、索引の見積にも実質的に余裕を見込んでいます。

この25％は案件固有の暫定係数であり、Oracle 19cの標準的な割合ではありません。

索引定義が確定した後は、キー長、索引本数、データ件数などをもとに再見積します。既存テーブルであれば、DBMS_SPACE.CREATE_INDEX_COSTを利用する方法もあります。ただし、対象テーブルの統計情報が適切に収集されていることが前提です。

LOB容量は文字コードと格納方式に注意する

実案件では、帳票データを格納するCLOBの容量見積で問題が発生しました。

当初の見積には、以下の2つの問題がありました。

  • 見積に使用した帳票枚数が、実際にLOBへ格納されるデータ件数を正しく表していなかった。
  • すべてのLOBが行外格納されるという前提で計算していた。

このため、LOB容量の再見積が必要になりました。

Oracle 19cでCLOB容量を見積もる場合は、文字コードによる内部表現の違いも考慮します。

例えば、AL32UTF8環境では、CLOBの可変長文字データはUCS2互換の内部形式で格納されます。

基本多言語面の文字を例にすると、次の違いがあります。

文字の種類UTF-8UCS2互換の内部表現
ASCII文字「A」1バイト2バイト
ひらがな「あ」3バイト2バイト
漢字「漢」3バイト2バイト

つまり、ASCII中心の帳票では元のUTF-8データより大きく、日本語中心では小さくなる場合があります。

ただし、補助文字、管理領域、LOB格納方式などの影響があるため、この比率をそのまま最終容量に使用してはいけません。

行内格納と行外格納の違い

Oracle 19cでは、ENABLE STORAGE IN ROWが有効な場合、管理情報を含めておおむね4,000バイト以下のLOBを行内に格納できます。

1文字が内部的に2バイトとなる文字を中心に考えれば、おおむね2,000文字弱が目安になります。ただし、これは厳密な文字数上限ではありません。

4,000バイトを超えるLOBは行外格納となり、別途LOBセグメントの容量を考慮する必要があります。

また、BasicFilesでは小さなLOBの行外格納に最低1チャンクが必要となる場合がありますが、SecureFilesでは格納方式が異なります。

Oracle 19cではSecureFilesを基本に検討し、圧縮・重複排除・暗号化を利用する場合は、Advanced CompressionやAdvanced Securityのライセンス条件も確認します。

LOBの容量は単純な「件数×元ファイルサイズ」では求められません。実際のデータ形式と格納特性を確認したうえで見積もる必要があります。

表領域・ストレージ容量への積み上げ

テーブル・索引・LOBの容量を見積もった後は、表領域およびストレージ全体の必要容量を決めます。

【実務事例：テーブル格納表領域の設計】

最終物理設計書には、次の容量が記録されています。

見積項目容量
LOBを含まないテーブル120GB
LOBを含むテーブル80GB
合計200GB
設計上の余裕40GB
テーブル格納表領域240GB
索引表領域40GB
合計280GB

なお、前述のExcel約93,431MBは、見積ツール上の大・小区分の集計値です。

最終物理設計書では、非LOBテーブルを約200テーブル×平均600MBとして120GBに見積もり、さらに帳票データなどのLOBを含むテーブルに80GBを計上しています。

両者は同じ条件で算出した値ではなく、Excel集計から最終値へ至ったすべての再計算過程も確認できないため、93GBと200GBを直接比較することはできません。

実務では、このように見積条件や対象範囲が変わることがあるため、見積値だけでなく、算出時点・対象範囲・前提条件を一緒に管理することが重要です。

データファイルのサイズと拡張方針を決める

Oracle 19cでは、必要容量を踏まえて次の項目を設計します。

  • 初期データファイルサイズ
  • AUTOEXTENDの使用有無
  • NEXTによる拡張増分
  • MAXSIZEによる上限

AUTOEXTENDを有効にしていても、ストレージの空き容量が不足すれば拡張できません。

そのため、データファイルの上限と物理ストレージの空き容量を合わせて管理します。

ストレージの冗長化も考慮する

ASMでNORMAL REDUNDANCYを採用する場合、通常のデータファイルは2重化されます。

例えば280GBの論理容量を同じASMディスクグループに配置すると、ミラーリングを含めて、概算560GB相当の物理容量が必要です。

さらに、ASMの管理領域や障害時の再ミラーリングに必要な余裕も考慮します。ストレージ装置側で冗長化する場合は、その方式に応じて計算します。

その他の領域も忘れずに見積もる

領域主な見積根拠
TEMP・UNDOソート・更新負荷、UNDO保持要件
REDOログ更新量、ログ切り替え、可用性構成
アーカイブログ・FRAREDO生成量、保持期間、バックアップ方式
バックアップ領域データ容量、保存世代、バックアップ方式

特にアーカイブログは、テーブルの総容量ではなく更新処理量の影響を大きく受けます。

設計時には容量監視の方針も決めます。DBA_TABLESPACE_USAGE_METRICSなどを利用し、使用率だけでなく、自動拡張可能量、ストレージの空き容量、増加速度も監視します。

概算→補正→実測で容量見積の精度を上げる

容量見積は一度で完成するものではありません。実務では、次の3段階で精度を高めます。

段階方法目的
① 概算Excelによる件数・レコード長からの算出必要容量の全体像を把握
② 補正DBMS_SPACE.CREATE_TABLE_COSTOracleの格納特性を考慮
③ 実測移行リハーサル・性能試験実際の使用容量と比較

第1段階：概算

前述のように、基本設計・詳細設計の初期段階では、わかっている件数とレコード長から概算し、未確定部分は暫定値で補います。

第2段階：Oracleの標準機能で補正

Oracle 19cではDBMS_SPACE.CREATE_TABLE_COSTを利用して、平均行サイズと想定件数からテーブル容量を推定できます。

例えば、平均行サイズ420バイト、270万件の場合は次のように指定します。

SET SERVEROUTPUT ON
DECLARE
  v_used_bytes  NUMBER;
  v_alloc_bytes NUMBER;
BEGIN
  DBMS_SPACE.CREATE_TABLE_COST(
    tablespace_name => 'APP_DATA',
    avg_row_size    => 420,
    row_count       => 2700000,
    pct_free        => 10,
    used_bytes      => v_used_bytes,
    alloc_bytes     => v_alloc_bytes
  );
  DBMS_OUTPUT.PUT_LINE(
    'USED_BYTES=' || v_used_bytes
  );
  DBMS_OUTPUT.PUT_LINE(
    'ALLOC_BYTES=' || v_alloc_bytes
  );
END;
/

※ APP_DATAは説明用の表領域名です。実際には対象PDB内の表領域を指定します。

Oracle公式マニュアルでは、以下のように説明されています。

  • USED_BYTES：データが使用する容量。ブロック管理情報やPCTFREEなどのオーバーヘッドを含む。
  • ALLOC_BYTES：表領域のエクステント割り当て特性を考慮した容量。

ただし、索引や行外LOBの容量まで自動的に求まるわけではありません。

このSQLはOracle 19c実機での確認用です。実行環境で得た値とExcelの概算値を比較し、必要に応じて見積モデルを補正します。

第3段階：移行リハーサル・性能試験で実測

実際のデータを投入した後は、DBA_SEGMENTSでテーブル・索引・LOBの割当容量を確認します。

PDB内に接続してDBA_SEGMENTSを確認する方法のほか、CDBルートからCDB_SEGMENTSをCON_ID付きで確認する方法もあります。

さらに、DBMS_SPACE.SPACE_USAGEによるセグメント内の空き領域、性能試験時のUNDO・TEMP使用量、REDO生成量などを確認します。

DBA_SEGMENTS.BYTESは割当済み容量であり、純粋な業務データ量ではありません。そのため、見積と比較する際には、何を測定した容量なのかを揃える必要があります。

こうして概算から実測までの差異を確認し、その理由を設計書に反映すれば、今回の容量設計だけでなく、次のプロジェクトでも活用できるノウハウとして蓄積できます。

物理設計で実際に発生した課題と解決方法

物理設計では、教科書どおりの手順だけでは設計値を決められないことがあります。

ここでは実際の課題管理表と物理設計書をもとに、同時接続数、Data Guard、設計変更の3つの事例を紹介します。各数値は設定値の推奨例ではなく、入力情報をどのように解釈して判断したかを示す材料です。

端末数・同時アクセス数からPROCESSESを決めてはいけない

PROCESSESの設計では、利用端末数、同時アクセス数、DBへの最大接続数を区別する必要があります。

【実務事例：400台・250接続・30同時アクセス】

実案件の課題管理表には、次の回答が記録されていました。

項目回答値主に関係する設計
総端末数400台システムの利用規模
同時接続可能台数250台アプリケーション接続数
同時アクセス台数30台同時実行負荷、CPU・PGA等

250台が同時接続可能でも、実際に処理を実行する台数が30台程度なら、接続数とアクティブな処理量を分けて考える必要があります。

さらに、DBには利用者向けシステム以外からも接続が発生します。

実際の物理設計書では、接続元ごとの上限を次のように積み上げていました。

接続元最大想定接続数
Webアプリケーション基盤・業務利用者向け250
Webアプリケーション基盤・別系統50
C#アプリケーション40
バッチサーバ20
運用管理10
合計370

250はDB全体の最大接続数ではなく、一つの接続元の上限でした。

これに、案件の環境で確認したバックグラウンドプロセス約40と、Data Guard関連の想定10を加えています。

370＋40＋10＝420

最終的には約19％の余裕を見込み、PROCESSES=500を採用しました。

また、SESSIONSは既定の計算式から772としました。

1.5×500＋22＝772

Oracle 19cでもこの算出式を利用できます。ただし、CDB/PDB構成や有効機能でバックグラウンドプロセス数が変わるため、事例の50を固定値とせず、対象環境のV$PROCESSなどで実数を確認します。

重要なのは、最大接続数と同時実行負荷は別の設計指標であることです。

Data Guardと夜間バッチのREDOをどう設計するか

Data Guardでは、スタンバイの用途によって設計が変わります。

障害時の切替先として利用するのか、日常的な参照処理に利用するのかによって、適切な構成を選択します。

【実務事例：参照用DBにロジカル・スタンバイを採用】

実際の案件では、本番DBとは別に、利用者がSQLによる参照処理を行うDBを用意していました。

この参照用DBにはData Guardのロジカル・スタンバイを採用しました。Oracle 19cで同様の要件を設計する際には、後述する他の参照用DB構成とも比較して選択します。

ロジカル・スタンバイでは、DBをオープンしたままSQL Applyによって変更を反映できます。

ただし、フィジカル・スタンバイのREDO Applyとは異なり、REDOから論理的な変更を再構成し、SQLを実行して反映します。

そのため、大量の更新を伴うバッチでは、REDOを受信する速度だけでなく、SQL Applyの処理性能が同期完了時間を左右します。

また、更新対象の行を効率的に特定できるよう、主キーや一意キーの有無も重要です。適切なキーがない表では、更新や削除の適用時にフルスキャンが発生し、性能が低下する可能性があります。

ロジカル・スタンバイでは、更新行を識別するためのサプリメンタル・ロギングも必要となり、REDO生成量に影響します。

加えて、すべてのデータ型や表構成をSQL Applyで扱えるわけではありません。対象外の表はDBA_LOGSTDBY_UNSUPPORTEDなどで確認できます。

夜間バッチ終了時点までの反映をSCNで確認する

この案件では、参照用DBへの反映を日次で実施していました。

物理設計書に記載された手順は、次のとおりです。

  1. 夜間バッチ終了後、プライマリでログスイッチする。
  2. アーカイブログの最終SCNを取得する。
  3. スタンバイ側でREDO適用を開始する。
  4. 適用済みSCNが目標SCNに到達したことを確認する。
  5. REDO適用を停止する。

ここでいうSCNは、夜間バッチ終了時点までの更新が反映されたかを確認する基準です。

単にREDOが届いたことではなく、目標SCNまでSQL Applyが完了したことを確認する運用でした。

FORCE LOGGINGと大量バッチの問題

実案件の夜間バッチでは、中間ファイルを作成し、JavaプログラムまたはSQL*Loaderを使ってDBへデータを格納していました。

ダイレクト・パス・インサートなどの大量投入処理では、NOLOGGINGによってREDO生成量を抑制できる場合があります。

しかし、必要なREDOが生成されないと、スタンバイ側で投入データを正しく再現できない可能性があります。

このため、この案件ではData Guardとの整合性を考慮し、FORCE LOGGINGを有効にしました。

一方、FORCE LOGGINGやサプリメンタル・ロギングにより、REDO量、アーカイブログ容量、転送負荷が増える可能性があります。

【実務事例：1日約100万件を基準にREDO量を算出】

課題管理表では、年次の大量処理として、1日約100万件を想定していました。

REDO量は、現行システムで同等の処理を実行した際のアラートログをもとに算出し、アーカイブログの保存期間は1週間としました。

アラートログのログスイッチ情報を利用した見積は概算ですが、実績に基づく設計値を得るための方法です。

Oracle 19cでは、利用権のあるAWRやSTATSPACKのredo size、実際のバッチ試験などを組み合わせて検証します。

【実務事例：ネットワーク転送負荷の判断】

REDO転送については、業務用と運用用のネットワークが分離されていないことが懸念事項となりました。

この案件では「問題ないレベルと思われる」という定性的な判断で課題を完了しましたが、REDO転送量と回線帯域を比較した定量的な根拠は記録されていません。

19cで同様のシステムを設計するなら、次の項目を確認します。

確認項目設計上の目的
ピーク時のREDO生成速度必要な転送帯域の算出
実効ネットワーク帯域他業務との競合を含めた余裕の確認
REDO転送遅延スタンバイへの到達時間の確認
SQL Applyの処理速度日次同期の所要時間の確認

特に、大量バッチ後のSQL Applyの所要時間は実測し、同期の完了時刻に間に合うかを確認します。

なお、19cで参照用DBを構成する場合は、ロジカル・スタンバイに加え、フィジカル・スタンバイとActive Data Guard、GoldenGateなどの論理レプリケーションも比較対象となります。要件、ライセンス、対応データ型、同期方式を踏まえて選択します（前述のライセンスの設計判断例を参照）。

設計の前提条件が変わったときの対応

物理設計では、設定値や構成が後から変更されることがあります。

重要なのは、変更後の値だけでなく、変更理由と検証すべき事項を残すことです。

【実務事例：UNDOを20GBから10GBへ変更】

課題管理表には、UNDO表領域を20GBから10GBへ変更した記録があります。

理由は、システム全体の容量を考慮したためです。

管理項目内容
変更前UNDO表領域20GB
変更後UNDO表領域10GB
事例の変更理由全体の容量を考慮
確認すべきリスクUNDO不足、長時間SQLへの影響
19cでの検証方法V$UNDOSTAT等による使用量の確認

この事例は、個別の表領域に求められる容量だけでなく、ストレージ全体の制約も設計値に影響することを示しています。

19cではV$UNDOSTATなどを確認し、必要なUNDO保持期間を満たせるか検証します。

必要資料は設計開始の条件ではなく、検証の材料とする

実案件の課題管理表では、テーブル定義やデータ件数に関する資料について、設計済みの容量が十分かどうかを確認するために必要であり、資料がなくても設計を進められる、という考え方が示されていました。

つまり、資料が揃うまで設計を止めるのではなく、暫定的な前提を置いて設計し、資料の受領後にその妥当性を検証するという進め方です。

LOBの再見積では格納方式や運用方針も見直す

LOB容量を再見積した際には、専用表領域を設けず、テーブルと同じ表領域へ格納する方向も検討されました。

また、帳票データのパージ方針は、容量を再見積した後に判断することになっていました。

このように、前提条件が変われば、単なる設定値だけでなく、表領域構成や保存・削除方式まで見直す必要があります。

課題管理表は、未確定事項を管理するだけでなく、設計判断の根拠と変更の経緯を残すための成果物として活用します。

まとめ｜データベースの物理設計で重要なこと

データベースの物理設計は、表領域や初期化パラメータの設定値を埋める作業ではありません。性能・容量・可用性・運用性の要件を踏まえ、根拠を持って設計判断を積み重ねる工程です。

本記事では、Oracle Database 19cを例に、主な設計項目、容量見積の方法、実際のプロジェクトで発生した課題を紹介しました。

Oracle 19cでは、エディションとライセンス、CDB/PDBの設計単位を最初に確認し、その制約を踏まえて表領域やメモリなどを設計します。

実務で特に重要なのは、必要な情報がすべて揃っていなくても、設計を止めないことです。

テーブル件数や接続数が未確定であれば、暫定値とその前提条件を課題管理表に記録し、設計を進めます。そして資料が提供された段階で、見積や設定値の妥当性を検証します。

また、別案件の設計値をそのまま流用しないことも重要です。

例えば、別案件の設計書に16KBのDBブロックサイズや固定エクステントが記載されていても、その値を流用せず、平均行長、アクセス特性、運用要件を確認します。フルスキャンの多さだけでは大きなブロックを選ぶ十分な根拠にはならず、代表的なSQLでの検証が必要です。

物理設計の品質を左右するのは、設定値そのものだけではありません。なぜその値を選んだのか、どの情報を根拠にしたのかを説明できることが、構築・試験・運用まで通用する設計につながります。

参考資料｜Oracle Database 19c公式マニュアル

関連記事

 

コメント

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