Info2softは、ウェブサイトでより快適で適切な閲覧体験を提供するためにCookieを使用しています。 プライバシーポリシー
Loading...
By:
Oracleにおいて、ALTER SYSTEM ARCHIVE LOGコマンドはアーカイブログ処理を手動制御するために使用します。オプションに応じて、現行REDOログのアーカイブ強制、滞留したREDOログの一括アーカイブ、アーカイブプロセスの制御などを実行可能です。
自動アーカイブを有効化している場合でも、バックアップ実行前、リカバリ作業後、アーカイブログのギャップ解消時などに管理者が手動でログをアーカイブする必要が生じることがあります。
ALTER SYSTEM ARCHIVE LOG CURRENTまたはALTER SYSTEM ARCHIVE LOG ALLを使用する前提として、データベースがARCHIVELOGモードで起動している必要があり、実行ユーザーにはSYSDBAまたはSYSOPER権限が必須です。
現在のアーカイブモードは下記コマンドで確認できます：SELECT LOG_MODE FROM V$DATABASE; または ARCHIVE LOG LIST;
コマンド概要
OracleのALTER SYSTEM ARCHIVE LOGには複数オプションが存在しますが、実務で頻出するのはCURRENT、ALL、STOPの3種類です。
各コマンドの動作と利用シナリオを下表にまとめます：
| コマンド | 同期実行 | ログスイッチ発生 | RAC適用範囲 | 推奨利用場面 |
|---|---|---|---|---|
ARCHIVE LOG CURRENT |
Y | Y | 全ノード | RMANバックアップスクリプト |
ARCHIVE LOG ALL |
Y | N | 全スレッド | ログギャップ解消 / リカバリ後処理 |
ARCHIVE LOG STOP |
– | – | – | 非推奨：廃止予定コマンド |
ALTER SYSTEM ARCHIVE LOG CURRENTはバックアップ業務の標準コマンドです。実行するとアクティブなREDOログの強制スイッチを行い、アーカイブ処理完了後にセッション制御が戻ります。
本コマンドは同期実行となり、Oracleがアーカイブファイルをディスクに完全書き込むまで次の処理に進まない仕様です。この特徴により、バックアップスクリプト内で安定して使用でき、REDOデータが確実にアーカイブされた状態で後続処理を実行できます。
スタンドアロン環境での基本構文は以下の通りです：
ALTER SYSTEM ARCHIVE LOG CURRENT;
RAC（Real Application Clusters）環境の場合、1インスタンスから本コマンドを実行すると、全稼働ノードの全REDOスレッドに対しログスイッチとアーカイブが実行されます。特定のインスタンスのみを対象にする場合はTHREADパラメータを使用します。
-- スレッド2のREDOログを強制アーカイブ
ALTER SYSTEM ARCHIVE LOG CURRENT THREAD 2;
バックアップスクリプトで誤ってALTER SYSTEM SWITCH LOGFILEを使用するケースが多発します。こちらもログスイッチは発生しますが非同期処理のため、ARCnプロセスがアーカイブファイルの書き込みを完了する前にセッション制御が即時戻ります。
この状態でRMAN処理を続行すると、対象アーカイブファイルが未作成のためRMAN-06054やORA-00279といったエラーが発生します。古いスクリプトでは回避策としてSLEEP 60による待機処理を挿入していますが、安定性に欠けます。ALTER SYSTEM ARCHIVE LOG CURRENTはアーカイブ完了まで待機するためこの問題を根本的に解消します。
Oracle公式ドキュメントではホットバックアップ実行時に本コマンドを2回実行することを推奨しています。バックアップ開始前と完了後にそれぞれ実行することで、バックアップ実行期間中に生成されたすべてのREDOデータがリカバリ用セットに含まれる保証が得られます。
ALTER SYSTEM ARCHIVE LOG ALLは書き込み完了済みだが未アーカイブのREDOロググループを一括でアーカイブします。ARCHIVE LOG CURRENTと異なりアクティブログの強制スイッチは行わず、閉鎖済みのログのみ全有効スレッド分走査してアーカイブ処理を実行します。
自動アーカイブ処理の遅延や一時的な停止が発生し、ログが滞留した際に適切な対処手段となります。
最大の差異はログスイッチの有無です。ARCHIVE LOG CURRENTは即時に新しいREDOログへ切り替えるのに対し、ARCHIVE LOG ALLは既にクローズされた古いログのみ処理します。アクティブなREDOログの使用量が50%程度の状態でも本コマンドは影響を与えません。
実務で主に3つのシナリオで活用されます。
全ログが正常にアーカイブ済みの状態で本コマンドを実行すると下記メッセージが返却されます。
ORA-00271: no logs need archiving
こちらはエラーではなく正常ステータス通知です。出力された場合、バックグラウンドのアーカイバーが正常稼働し滞留ログが存在しないことを意味します。
複数のREDOログを一括アーカイブする処理は短期間だがI/Oサブシステムに高負荷をかけます。可能な限り業務負荷の低い時間帯に実行し、業務トランザクションとディスク帯域を奪い合わないよう調整してください。
ALTER SYSTEM ARCHIVE LOG STOPは旧世代のレガシーコマンドで、最新のデータベース運用では使用すべきではありません。Oracle9i以前ではARCHIVE LOG STARTと組み合わせARCnバックグラウンドプロセスを手動制御するために活用されていました。Oracle10gより廃止予定となり、新しいバージョンでは文法上実行可能ですが重大なリスクを伴うため禁止推奨です。
本コマンドを実行するとOracleはアーカイバープロセスを停止し、REDOデータのアーカイブ先への書き出しを中断します。一方、データベースはトランザクションの記録をオンラインREDOログに継続して書き込み続けます。
全REDOロググループが満杯になった時点で、新規変更点を書き込む場所が存在しなくなります。DBはARCHIVELOGモードのままアーカイブ処理が停止しているため全業務を無期限に一時停止します。復旧手段はアーカイブを再開するかインスタンスをシャットダウンする以外に存在しません。
DBAがやむを得ず使用する極限の緊急時が1つだけ存在します。アーカイバープロセスが完全にハングアップしシステムレベルでI/Oロックが発生した場合、ARCHIVE LOG STOPでプロセスを強制終了します。実行後は即時SHUTDOWN ABORTを実行し、更なる不安定化を防止する必要があります。
アーカイブ機能を無効化したい場合はSTOPコマンドを使用せず、データベースのログモードを直接変更する安全な手順を実施します。
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE NOARCHIVELOG;
ALTER DATABASE OPEN;
上記手順は制御ファイルに設定を反映し、バックグラウンドのアーカイバープロセスを安全に停止させ、予期せぬDBハングのリスクを回避します。
適切に運用されている環境でも、アーカイブ処理が起因となるDB停止エラーが発生する場合があります。各エラーコードの意味を把握することで速やかに障害を復旧し通常運用に戻せます。
ORA-00257：アーカイバーエラー – 空き容量確保までSYSDBA以外は接続不可
最も頻出するアーカイブ関連エラーです。Flash Recovery Area(FRA)を代表とするアーカイブ先ディスクの容量が枯渇した際に発生します。新規REDOデータの保存先がなくなるため、管理者以外のDB接続を一時遮断し障害拡大を抑止する仕様です。
調査・復旧手順は以下の通りです。
V$RECOVERY_FILE_DESTビューから領域使用状況を確認DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-1';db_recovery_file_dest_sizeパラメータを拡張するか、セカンダリアーカイブ先を追加設定ORA-00271：アーカイブが必要なログなし
ALTER SYSTEM ARCHIVE LOG ALL実行時、全完了REDOログが既にアーカイブ済みの場合に出力されます。対応作業は不要で、アーカイバーが正常稼働し滞留ログがないことを示します。
ORA-16038：ログシーケンスのアーカイブに失敗
アーカイブ先へのI/O障害または設定不備によりファイル書き込みが失敗するエラーです。主な原因は下記3点です。
LOG_ARCHIVE_DEST_nに不正なパスが設定されているRMAN-06054 / ORA-00279
RMANバックアップスクリプト内でALTER SYSTEM SWITCH LOGFILEを使用すると頻発します。非同期処理のためアーカイブ完了前にRMANがログのバックアップを試行することが原因です。前述の同期処理コマンドALTER SYSTEM ARCHIVE LOG CURRENTに置き換えることで完全に解消できます。
アーカイブログを手動管理することでDBのリカバリ性は維持できますが、人的リスクが常に伴います。アーカイブ先の容量オーバーはORA-00257を引き起こしユーザー接続を遮断し、ログギャップの放置はData Guardスタンバイとの不整合を生みます。またバックアップ時間帯にアーカイブ処理が停止するとRMANジョブが予期せず失敗する恐れがあります。これらは本番Oracle環境で頻発する課題です。
専用バックアップソリューションを導入することで運用負荷を大幅に削減可能です。i2Backupは人的操作を最小限に抑えOracle環境を保護するために開発されたエンタープライズ向けバックアッププラットフォームです。
定時バックアップではなく常時データ保護が必要な環境にはi2CDPが最適で、バイト単位でデータ変更をリアルタイムレプリケートしRPOを限りなくゼロに抑えます。Oracleインスタンス間の高可用性・自動フェイルオーバーが必要な場合はi2Availabilityがサブ秒単位の切り替えに対応し、プライマリ環境障害時でも業務を継続します。
これらのソリューションを組み合わせることで、日常的なアーカイブログ管理からサイト間災害リカバリまでOracleデータ保護の全要件をカバーできます。下記ボタンより上記製品の60日間無料トライアルを申し込めます。
本ガイドで解説した3種類のアーカイブログコマンドはそれぞれ役割が明確に分かれており、誤ったタイミングで使用すると重大な影響が発生します。ARCHIVE LOG CURRENTはアーカイブ完了まで待機する安定仕様のためバックアップスクリプトに最適、ARCHIVE LOG ALLはログ滞留時の一括処理用、ARCHIVE LOG STOPはほぼ全ての状況で使用を避けるべきで、最新Oracle環境では予期せぬDB停止を引き起こす危険なコマンドです。
日常運用ではORA-00257、ORA-16038などの頻出エラーの知識と組み合わせることで、ユーザー業務に影響を与える前に障害を速やかに復旧可能です。
一方、手動によるアーカイブログ管理には限界が存在します。本番Oracle環境を運用する場合はInfo2softのi2Backupのような専用ソリューションでバックアップスケジュール、保存ルール、ログ取得処理を自動化することで人的ミスのリスクを低減し、担当者の手作業に依存せず安定的にリカバリ目標を維持できます。
