Info2softは、ウェブサイトでより快適で適切な閲覧体験を提供するためにCookieを使用しています。 プライバシーポリシー
Loading...
By:
Oracleリドログはデータベースに対するすべての変更履歴を記録します。ユーザーがINSERT、UPDATE、DELETEを実行した際、Oracleは変更内容を直接ディスクに書き込まず、まずログに記録した後、リドログファイルへ書き出します。
インスタンスがクラッシュした場合、次回起動時にOracleは記録されたログ変更を再実行し、コミット済みのトランザクションをすべて復旧します。これはACID準拠における持続性の基盤となる機構です。
Oracleは2種類のリドログを管理します。
詳細に入る前に、本ガイドで頻出する4つの用語を解説します。
リドログファイルは事前に確保された固定サイズのディスクファイルです。データファイルと異なり循環利用される仕組みで、最後のグループが満杯になると最初のグループへ戻って上書きします。ただし、対象グループのアーカイブ完了、かつ変更内容がデータファイルにチェックポイント反映された後に限り上書きが実行されます。
Oracleはリドログファイルを「グループ」と「メンバー」の2階層構造で管理します。グループは1つ以上の同一メンバーファイルで構成される論理単位で、ログライタープロセス（LGWR）は現在のグループ内のすべてのメンバーに同一のリドエントリを同時書き込みします。
多重化（マルチプレキシング）とは同一グループの複数メンバーを別々の物理ディスクに配置する構成を指します。一方のディスク障害でメンバーファイルが破損しても、グループ内に読み取り可能なメンバーが1つでも残っていればOracleは稼働を継続できます。多重化を実施していない場合、単一のリドログファイル損失だけでデータベース全体が停止する恐れがあります。
V$LOGビューを照会すると、各グループは4種類のステータスのいずれかを表示します。
| ステータス | 意味 |
|---|---|
| CURRENT | LGWRが現在書き込み中のグループ |
| ACTIVE | ログスイッチは発生済みだが、変更内容がデータファイルに完全にチェックポイント反映されていない状態。インスタンス復旧に必要なログ |
| INACTIVE | 変更内容のチェックポイント反映完了。このグループは再利用可能 |
| UNUSED | 新規追加されたばかりで一度も書き込みが行われていないグループ |
グループ、メンバー、ファイルサイズ、現在のステータスを確認するクエリは以下の通りです。
SELECT
a.GROUP#,
a.STATUS,
b.MEMBER,
a.BYTES/1024/1024 AS SIZE_MB
FROM V$LOG a
JOIN V$LOGFILE b ON a.GROUP# = b.GROUP#
ORDER BY a.GROUP#;
新規グループ追加（多重化のため2つのメンバーを別ディスクに配置）：
ALTER DATABASE ADD LOGFILE GROUP 4
('/u01/app/oracle/oradata/REDO/log4a.rdo',
'/u02/app/oracle/oradata/REDO/log4b.rdo') SIZE 512M;
既存グループへメンバー追加：
ALTER DATABASE ADD LOGFILE MEMBER
'/u02/app/oracle/oradata/REDO/log1b.rdo' TO GROUP 1;
グループ削除：
ALTER DATABASE DROP LOGFILE GROUP 4;CURRENTまたはACTIVEステータスのグループは絶対に削除しないでください。現在のグループを削除したい場合は事前にALTER SYSTEM SWITCH LOGFILEを実行し、ステータスがINACTIVEに変わるのを待ってから削除します。リドログの配置先を決定する際は「パフォーマンス」と「冗長性」の2点を最優先に考慮します。
Oracle Managed Files（OMF）を使用している場合、DB_CREATE_ONLINE_LOG_DEST_nパラメータに基づきOracleがファイル名と配置先を自動管理します。いずれの配置方法でも共通の鉄則が存在します。同一グループのメンバーを同じ物理ディスクに配置してはならないという点です。同一ボリュームに両方のメンバーを置くと、ディスク障害発生時に多重化による保護効果が失われます。必ずメンバーを別マウントポイント、ストレージコントローラー、またはASMディスクグループに分散配置してください。
V$LOGFILEビューを照会することで各メンバーの保存先、ファイルシステムかASMかを確認できます。
SELECT
GROUP#,
TYPE,
MEMBER
FROM V$LOGFILE
ORDER BY GROUP#;
高速ストレージへログを移行する、または配置不備を修正する際に本手順を使用します。以下のリネーム方式は全Oracleバージョンで対応可能です。
1. データベースを正常シャットダウンし、すべてのリドデータをディスクにフラッシュします。
SHUTDOWN IMMEDIATE;2. OSレベルでファイルを新規配置先へコピーします（Linuxはcp、Windowsはcopyコマンド）。Oracle側でファイル移動は実施できないため、この手順は手動で実行する必要があります。
3. データベースをマウント状態で起動します。
STARTUP MOUNT;4. 制御ファイル内のパスを新しい配置先に更新します。
ALTER DATABASE RENAME FILE '/old_disk/log1a.rdo' TO '/new_disk/log1a.rdo';
ALTER DATABASE RENAME FILE '/old_disk/log1b.rdo' TO '/new_disk/log1b.rdo';5. データベースをオープンする前に、パスが正しく更新されたか確認します。
SELECT GROUP#, TYPE, MEMBER FROM V$LOGFILE ORDER BY GROUP#;6. データベースをオープンします。
ALTER DATABASE OPEN;ログサイズとスイッチ頻度は密接に連携しています。リドログの容量によって、次のグループへ切り替えるまでに記録可能な変更データ量が決まります。ログスイッチが発生するたびにチェックポイントが起動し、データライタープロセス（DBWn）がメモリ上の変更データをディスクへ書き出します。
ログサイズが小さすぎるとスイッチが頻発し、定常的なチェックポイント処理によりI/Oボトルネックが発生し、待機イベントに「log file switch (checkpoint incomplete)」が頻出する特徴があります。
負荷ピーク時の目標は15～30分に1回のログスイッチです。これより頻繁にスイッチが発生する場合はログサイズが不足している明確な兆候となります。
V$LOG_HISTORYビューを照会し、過去7日間の1時間ごとのスイッチ回数を確認できます。
SELECT
TRUNC(FIRST_TIME, 'HH') AS HOUR,
COUNT(*) AS SWITCHES
FROM V$LOG_HISTORY
WHERE FIRST_TIME > SYSDATE - 7
GROUP BY TRUNC(FIRST_TIME, 'HH')
ORDER BY 1;
スイッチ回数が多い時間帯が負荷ピークとなり、ログサイズ設計の基準となります。
設計の基準となる計算式は以下の通りです。
ピーク時リド生成速度(MB/分) × 30分 ＝ 適正ログサイズ
標準的なOLTP業務の場合、500MB～1GBを基準値とします。バッチ処理や日次締め処理が多いデータベースは、平時平均ではなくピーク負荷に合わせてサイズを設定してください。平均負荷に合わせると、パフォーマンスが最も重要なタイミングでデータベースが停滞する恐れがあります。
実例：200MBのログを使用していたデータベースは夜間バッチ実行時に1時間あたり456回のログスイッチが発生していました。ログサイズを22GBに拡張後、AWR上位待機イベントから「log file switch (checkpoint incomplete)」が完全に消滅し、バッチ処理時間が40%短縮されました。
既存のログファイルのサイズを直接変更することはできません。手順は「大容量の新規グループ追加→ログスイッチを実行→旧グループ削除」となります。
1. 目標サイズの新規グループを追加します。
ALTER DATABASE ADD LOGFILE GROUP 4 ('/u01/app/oracle/oradata/redo04.log') SIZE 2G;
ALTER DATABASE ADD LOGFILE GROUP 5 ('/u01/app/oracle/oradata/redo05.log') SIZE 2G;
ALTER DATABASE ADD LOGFILE GROUP 6 ('/u01/app/oracle/oradata/redo06.log') SIZE 2G;2. 強制的にログスイッチを実行し、Oracleが新規グループへ切り替わるようにします。
ALTER SYSTEM SWITCH LOGFILE;3. 旧グループのステータスがINACTIVEになったら削除します。
ALTER DATABASE DROP LOGFILE GROUP 1;4. 残りの旧グループに対して手順3を繰り返し実行します。
ALTER SYSTEM SWITCH LOGFILEを複数回実行する必要がある場合があります。グループを削除する前に必ずV$LOGビューでステータスがINACTIVEであることを確認してください。OracleデータベースはNOARCHIVELOGまたはARCHIVELOGの2つのモードのいずれかで稼働します。
NOARCHIVELOGモードでは、書き込み完了したリドログはそのまま上書きされます。最後のフルバックアップ時点までしか復旧できず、それ以降のデータは失われます。
ARCHIVELOGモードでは、リドログを再利用する前に恒久的な複製ファイルを保存します。古いバックアップにアーカイブログを適用することで障害発生直前までデータを復旧可能となるため、本番データベースではARCHIVELOGモードは必須の設定です。
インスタンスがクラッシュし再起動する際、Oracleは自動的に2段階の復旧処理を実行します。
人手による操作は不要で、この処理が完了した後にデータベースがオープンします。
現在のアーカイブ状況を確認するコマンド：
ARCHIVE LOG LIST;
出力結果に「No Archive Mode」と表示される場合は、以下の手順でARCHIVELOGモードを有効化します。
1. データベースをシャットダウンします。
SHUTDOWN IMMEDIATE;2. データベースをマウント状態で起動します。
STARTUP MOUNT;3. ARCHIVELOGモードを有効化します。
ALTER DATABASE ARCHIVELOG;4. データベースをオープンします。
ALTER DATABASE OPEN;| 症状 | 考えられる原因 | 解決策 |
|---|---|---|
| 1～2分ごとにログスイッチが発生 | ログファイルのサイズが小さすぎる | グループ追加・削除方式でログサイズを拡張 |
| log file sync 待機イベントが多発 | ログ用ディスクのI/Oボトルネック | SSDまたはNVMeなど高速ストレージへログを移行 |
| log file switch (checkpoint incomplete) が発生 | ロググループの数が不足 | DBWnがチェックポイント処理を完了する時間を確保するため、グループを追加 |
| アーカイブ先の容量枯渇によりデータベースが停止 | アーカイブ領域の監視不足 | ストレージ容量拡張、アーカイブファイルの移設、またはRMANによる古いアーカイブ削除 |
リドログはOracleの最初の防衛線です。インスタンスが予期せず停止した際、クラッシュリカバリを自動実行し、コミット済みトランザクションの損失を防止します。
しかしリドログには限界があります。誤ったデータ削除、永久的なディスク障害、チェックポイントを経てデータファイルに反映済みの破損からの復旧には対応できません。また、複数データベースのバックアップポリシーを一箇所で統合管理する機能も備えていません。
こうしたケースには専用のバックアップソリューションが必要です。i2Backupは、リドログのカバーできない領域を補完するために開発されたエンタープライズ向けバックアップ基盤です。
完全なデータ保護スタック
高可用性またはリアルタイムレプリケーションを必要とするOracle環境向けに、Info2softは相補的な2製品を提供しています。
i2Backupと組み合わせることで、インスタンスレベルのクラッシュリカバリから異種環境間の災害復旧まで、あらゆるデータ保護ニーズに対応します。
ボタンをクリックするとInfo2softの災害復旧ソリューションの無料トライアルを申し込めます。
Oracleリドログはデータ永続性の基盤です。すべてのコミット済み変更を記録し、自動クラッシュリカバリを有効にし、適切なサイズと設定によりパフォーマンスボトルネックなしでデータベースを稼働させ続けます。
本ガイドの要点は以下の通りです。
とはいえ、リドログはバックアップ戦略にはなりません。インスタンスクラッシュからは保護できても、誤削除、ハードウェア障害、複数DB横断の復旧管理には対応できません。これらの課題に対しては、Info2softのi2Backupといった専用ソリューションが補完します。常時Oracleバックアップ、任意時点リカバリ、環境全体の集中管理機能を備えています。
