本番投入後にパラメータを変更するには影響範囲の確認やメンテナンスウィンドウの調整が必要になり、想像以上に手間がかかります。最初の投入時点で決めておくべき設定項目を、経験に基づいて絞り込みました。

初期化パラメータ概観

主要初期化パラメータ一覧図

図1: Oracleの主要初期化パラメータとカテゴリ

DBには起動時に読み込まれる多数のパラメータがあります。それぞれ「変更前にバックアップ・テスト」「本番反映前に静的/動的どちらかを確認」「再起動要否を必ず確認」が鉄則です。パラメータには動的パラメータ（DB再起動なしで変更可）と静的パラメータ（再起動が必要）の2種類があります。本番環境での変更は必ず動作確認後にメンテナンス時間帯に実施してください。

パラメータ名は製品により異なる。「メモリ」「I/O」「ログ」「セッション数」の観点で押さえると応用が利く。

メモリ関連の考え方

データベースサーバのメモリは複数の用途で使われます。サイジングの基本式は次の通りです。

物理メモリ = OS使用分 + DB共有メモリ（SGA/Buffer Pool）+ セッション分（PGA × 最大接続数）+ 予備（10〜20%）

共有メモリは大きいほど良い……ではない

OSのキャッシュやセッションを圧迫すると逆に遅くなる。物理メモリの50〜70%を共有メモリの目安にする。残りをOS・セッション・予備に割り当てる。クラウド環境では後からインスタンスタイプを変更しやすいため、まず適切なサイズで運用してモニタリングしながら調整する方が現実的だ。

接続数 × 1セッション当りメモリ

アプリのプールが100接続、1セッションあたり10MBなら、それだけで1GBのメモリが必要だ。接続プールのサイズは「必要最小限」に設定することが重要で、無制限にプールを広げると本番でOOMが発生するリスクがある。アプリサーバが複数台ある場合は「台数 × プールサイズ」の合算で考える。

ソートメモリ（work_mem等）を意識

巨大ソートを避けたければPGA/work_memを増やす。ただし全セッション分の総和に注意する。PostgreSQLでは work_mem は1クエリあたりの割り当てであり、複数のソート操作が同時に走ると work_mem × 同時接続数 × 操作数 のメモリを消費する可能性がある。

ヒュージページ / メモリロック

本番環境ではOSのヒュージページを有効化し、DBの共有メモリをロックする。これによりOSのページングによるDB性能の不安定化を防ぐことができる。Linuxでは vm.hugetlb_shm_group でOracleの共有メモリをヒュージページに配置できる。

ファイル配置とI/O設計

理想的な物理分離（例）

ディスク 配置するもの 理由
Disk 1OS / DBバイナリデータと分離することで障害の影響範囲を限定
Disk 2データファイル（USERS, INDEX）最もI/Oが多い。高速ストレージ（SSD/NVMe）推奨
Disk 3オンラインREDO + 制御ファイル（多重化）書き込み専用・シーケンシャルアクセス。高速ディスク必須
Disk 4アーカイブログ容量が大きく必要。枯渇するとサービス停止になるため定期監視が必須
Disk 5一時表領域（TEMP）+ UNDOソート処理が多い場合は高速ディスクを割り当てる
Disk 6バックアップ出力先REDOと同一ディスクにすると障害時に両方失うリスク。必ず分離する

クラウド環境（AWS/GCP/Azure）では物理ディスクの分離は不要だが、IOPSとスループットの設計が必要になる。例えばAWS EBSでは io2 Block Express や gp3 のIOPS・スループット設定をI/O負荷に合わせて構成する。

文字コード・タイムゾーン・監査

文字コード

文字コードはDB作成後に変更が困難なため、作成前に必ず確定させる重要な設定です。

  • UTF-8（AL32UTF8 / UTF8MB4）を強く推奨する。多言語・絵文字・4バイト文字を扱う業務では必須。
  • アプリ側クライアントのキャラセットと一致させる。不一致の場合、文字化けや「?」への変換が発生する。
  • 既存データを移行する場合はデータの文字コード変換テストを必ず行う。

タイムゾーン

DB時刻とアプリ時刻のズレ事故は頻繁に発生します。特にDBサーバとアプリサーバが異なるタイムゾーンに設定されている環境では深刻な問題になります。

  • サーバ・DBのTZをUTCに統一することを強く推奨する。表示はアプリ側でローカルタイムに変換する。
  • TIMESTAMP WITH TIME ZONE 型を活用することでタイムゾーン情報をDBに保持できる。
  • ログのタイムスタンプも同じTZで統一する。異なるTZのログを時系列で比較すると障害調査が困難になる。

監査（Audit）

誰が何をしたかの記録は、セキュリティ事故の際の調査・証跡保全・コンプライアンス対応に必須です。監査設定を後から入れようとしても「事故が起きる前のログがない」という状況になります。

  • 最低でもDDL（テーブル作成・削除）・権限変更・接続失敗は監査対象にする。
  • 監査ログは別領域・別ディスクへ出力する。本番DBと同じ領域に出力すると、不正アクセスで監査ログも改ざんされるリスクがある。
  • 監査ログの保持期間をポリシーで定義し、定期的なアーカイブ・削除の仕組みを構築する。

DB設定でよくある失敗パターン

失敗パターン何が起きるか対処
共有メモリを物理RAMの90%以上に設定する OSのページキャッシュやセッションメモリが圧迫されてスワップが発生しDB全体が遅くなる 共有メモリは物理RAMの50〜70%を目安にし、残りをOS・セッション・予備に割り当てる
文字コードをUTF-8以外（Shift-JISなど）で作成する 4バイト文字（絵文字・一部漢字）が格納できず、後からの変更は全データ移行を伴う大工事になる 新規作成時はUTF-8（AL32UTF8 / UTF8MB4）を選択する
本番・開発・テスト環境でタイムゾーンが異なる 環境間でタイムスタンプがずれ、時刻比較クエリの結果が一致しないバグが発生する 全環境のサーバーとDBのタイムゾーンをUTCに統一し、表示変換はアプリ側で行う
パラメータ変更を再起動要否確認なしに本番適用する 静的パラメータを動的変更しようとしてエラーが出るか、次回再起動まで変更が反映されない 変更前にパラメータのISSYSが STATIC/DYNAMIC を確認し、変更手順書を作成してから適用する