初期化パラメータ概観

DBには起動時に読み込まれる多数のパラメータがあります。それぞれ「変更前にバックアップ・テスト」「本番反映前に静的/動的どちらかを確認」「再起動要否を必ず確認」が鉄則です。

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

メモリ関連の考え方

サーバ物理メモリ ≈ OS + DB 共有メモリ + セッション × 接続数

  • OS
  • 共有メモリ（SGA/Buffer Pool）
  • セッション（PGA × N）
  • 予備

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

OSのキャッシュやセッションを圧迫すると逆に遅くなる。物理メモリの50〜70%が目安。

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

アプリのプールが100接続、1セッションあたり10MBなら、それだけで1GB。

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

巨大ソートを避けたければPGA/work_memを増やす。ただし全セッション分の総和に注意。

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

本番環境ではOSのヒュージページを有効化し、DBの共有メモリをロック。

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

理想的な物理分離（例）

  • Disk 1: OS / DBバイナリ
  • Disk 2: データファイル（USERS, INDEX）
  • Disk 3: オンラインREDO + 制御ファイル（多重化）
  • Disk 4: アーカイブログ
  • Disk 5: 一時表領域（TEMP）+ UNDO
  • Disk 6: バックアップ出力先

配置の原則

  • REDOはシーケンシャル書き込み中心 ⇒ 専用の高速ディスクに
  • データファイルはランダムI/O中心
  • REDOとバックアップ出力は必ず分離（同時故障の防止）
  • 制御ファイルは3つ以上に多重化
  • アーカイブの空き枯渇は即サービス停止に直結
  • クラウドの場合はIOPSで設計

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

文字コード

DB作成後に変更困難。

  • UTF-8（AL32UTF8 / UTF8MB4）を強く推奨
  • 絵文字や4バイト文字を含む業務では必須
  • アプリ側クライアントのキャラセットと一致させる

タイムゾーン

DB時刻とアプリ時刻のズレ事故が多発。

  • サーバ・DBのTZを明示的に固定（例: UTC）
  • WITH TIME ZONE 型を活用
  • ログのタイムスタンプとも揃える

NLS / 通貨書式

ロケール依存の表示・数値解釈。

  • 小数点の「.」「,」の差異
  • 日付フォーマットの暗黙変換に注意
  • サーバ側書式とアプリ側書式を明示する

監査（Audit）

誰が何をしたかの記録。

  • 最低でもDDL・権限変更・接続失敗は監査
  • 監査ログは別領域・別ディスクへ
  • 改ざん防止のため書き込み専用ストレージ等を検討