この記事の要点

DBW (DBWn / Database Writer) = Oracle のバックグラウンドプロセスで、SGA バッファキャッシュからデータファイルへ「ダーティバッファ」を書き出す役割 書き出しタイミング: チェックポイント発生時 / バッファ不足 / 3 秒タイムアウト / LRU リストでクリーン要求 複数プロセス稼働可能。パラメータ DB_WRITER_PROCESSES (デフォルト CPU コア数の 1/8、最大 100)、I/O スレーブ (DBWR_IO_SLAVES) もある 関連プロセス: LGWR (Log Writer) / CKPT (Checkpoint) / ARCH (Archiver) / SMON / PMON 確認: SELECT * FROM v$bgprocess / v$session、AWR レポートの Background Process Statistics セクション

DBW プロセスの役割

Oracle データベースの SGA (System Global Area) 内のバッファキャッシュに変更が加わると、その変更されたブロックは「ダーティバッファ」になります。DBW プロセスは、これをディスク上のデータファイル (.dbf) に書き出す非同期書き込み専用プロセスです。

これにより、ユーザセッションは I/O 待ちを避けてメモリ上で UPDATE/INSERT を完了でき、Oracle は高いスループットを実現しています。

プロセス	役割
DBWn	バッファキャッシュ → データファイル書込み
LGWR	REDO バッファ → REDO ログファイル書込み
CKPT	チェックポイント情報をデータファイルヘッダと制御ファイルに書込み
ARCH (ARCn)	REDO ログをアーカイブログにコピー
SMON	インスタンスリカバリ、領域結合
PMON	プロセス監視 / 異常終了プロセスの後処理
MMON	AWR スナップショット、メトリック収集

書き出しタイミング

DBW がディスク書込みを発動するきっかけは大きく 5 種:

契機	説明
1. チェックポイント	CKPT がチェックポイント信号 → DBW が該当ダーティバッファを書込み
2. バッファ不足	サーバプロセスが空きバッファを要求 → クリーンが追いつかない場合 DBW にライト要求
3. 3 秒タイムアウト	3 秒ごとに起動して定期的にダーティバッファを書出し
4. 表領域 OFFLINE / BACKUP モード	該当ファイルのバッファを全部フラッシュ
5. DROP / TRUNCATE	セグメント削除時に該当バッファを書出し

COMMIT 時には DBW は走らないのがポイント。COMMIT を確実にするのは LGWR (REDO ログのフラッシュ) であり、データファイル本体はあとから DBW が書きます。これをWrite-Ahead Logging (WAL) と呼びます。

DB_WRITER_PROCESSES と DBWR_IO_SLAVES

Oracle 9i 以降、DBW は複数プロセス並列稼働できます:

-- 現在の値確認
SHOW PARAMETER db_writer_processes;
SHOW PARAMETER dbwr_io_slaves;

-- 変更 (要再起動)
ALTER SYSTEM SET db_writer_processes = 8 SCOPE=SPFILE;
SHUTDOWN IMMEDIATE;
STARTUP;

-- プロセス確認
SELECT name, description FROM v$bgprocess
 WHERE name LIKE 'DBW%';
-- NAME  | DESCRIPTION
-- DBW0  | db writer process 0
-- DBW1  | db writer process 1
-- ...

パラメータ	デフォルト	用途
DB_WRITER_PROCESSES	CPU コア数 / 8 (最小 1)	並列 DBW プロセス数 (推奨)
DBWR_IO_SLAVES	0	1 つの DBW に I/O スレーブをぶら下げる旧方式

非同期 I/O (DISK_ASYNCH_IO=TRUE) が OS でサポートされていれば、DBW 1 プロセス + 非同期 I/O で十分なケースが多く、まずは DBW 並列化より非同期 I/O 有効化を確認します。

確認 SQL

-- 全バックグラウンドプロセス一覧
SELECT name, description, error
  FROM v$bgprocess
 WHERE paddr <> '00';

-- DBW に関連するメトリック
SELECT * FROM v$sysstat
 WHERE name LIKE '%physical writes%';
-- physical writes                   : 物理書込み総数
-- physical writes direct            : ダイレクトパス書込み
-- physical writes non checkpoint    : 非チェックポイント書込み
-- physical writes from cache        : バッファキャッシュ経由

-- DBW セッション情報
SELECT s.sid, s.serial#, s.program, s.event, s.wait_class
  FROM v$session s, v$process p
 WHERE s.paddr = p.addr
   AND p.program LIKE '%DBW%';

-- DBW の書込み待ちイベント
SELECT event, total_waits, time_waited
  FROM v$system_event
 WHERE event IN ('db file parallel write',
                 'log file parallel write',
                 'free buffer waits');

AWR レポートで活動を見る

-- AWR スナップショット取得
EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();

-- レポート生成
@?/rdbms/admin/awrrpt.sql
-- → snap_id を 2 つ指定 → HTML/TEXT を選択

-- 注目セクション:
--   Top 5 Timed Events    : db file parallel write が上位なら DBW がボトルネック
--   Background Process Statistics : DBW 別の書込み量
--   IO Profile            : Total Mbytes/Read/Write
--   Wait Event Histogram  : free buffer waits の分布

パフォーマンスチューニングのポイント

症状	原因	対処
free buffer waits 多発	DBW が間に合わずバッファクリーンが追いつかない	DBW プロセス増 / 高速ストレージ / I/O スレーブ
db file parallel write 長時間	ディスク I/O が遅い	ストレージ点検、RAID 設定見直し
checkpoint completed 待ち多い	チェックポイントが遅い	FAST_START_MTTR_TARGET 調整
log file sync も同時に長い	I/O 系統全体がボトルネック	REDO ログを別ディスク / SSD 化
DBW プロセスの CPU 100%	暗号化や圧縮で CPU バウンド	DBW 並列化、CPU 増強

DBW と LGWR の協調 (WAL プロトコル)

Oracle は「対応する REDO レコードが REDO ログに書かれた後でないと、DBW はデータブロックを書いてはならない」という制約を守ります (Write-Ahead Logging)。

1. ユーザが UPDATE 実行
   → メモリ上のバッファとREDO バッファに変更が書かれる

2. ユーザが COMMIT
   → LGWR が REDO バッファをディスクにフラッシュ
   → 制御がユーザに戻る (COMMIT 完了)

3. 後で... DBW が好きなタイミングでデータファイルを更新
   → ただし、必ず該当 REDO がディスクに書かれた "後" にしか書かない
   → これにより、インスタンスクラッシュしても REDO から復元できる

クラッシュリカバリ:
   SMON が REDO を再生 → 未完了 COMMIT は ROLLBACK、完了 COMMIT は再適用

Oracle RAC での DBW

RAC (Real Application Clusters) では、各ノードに DBW が独立して動きます。書込み先のデータファイルは共有ストレージ(ASM / OCFS / NFS)。Cache Fusion によりノード間でブロックを直接交換し、ディスク経由を最小化します。

FAQ

Q: DBW が落ちるとどうなる？
A: バックグラウンドプロセスの異常終了はインスタンス全体のクラッシュを引き起こします。PMON が検知し ALERT ログに ORA-00474 等を記録、Oracle が自動再起動を試みます。

Q: DBW を高速化するには SSD だけで十分？
A: NVMe SSD で I/O は速くなりますが、Direct I/O / 非同期 I/O が有効化されていないと活かしきれません。FILESYSTEMIO_OPTIONS=SETALL や ASM 化が効果的です。

Q: COMMIT 時に DBW を動かしたい
A: 動かせません。COMMIT は LGWR の REDO 書込みで完了する設計です。データファイルへの書込みは性能のため遅延されます。

Q: ダーティバッファをいま強制的に書き出したい
A: ALTER SYSTEM CHECKPOINT; で全 DBW が起動しダーティバッファを全て書き出します。バックアップ前等で使用。