社内SEの徒然なる日記

OracleでORA-00257 アーカイブ・エラーです。解除されるまで内部接続のみにしてください。に対応してみた

■ 障害発生

夜間処理が異常終了して緊急出動するはめになった(障害と障害と徹夜)のですが、その時に発生したエラーがこれです。

ORA-00257: アーカイブ・エラーです。解除されるまで内部接続のみにしてください。


はは、何言ってるか分からねぇ。

■ ORA-00257

オラクルのエラーメッセージを調べると、こんな感じでした。

状況 アーカイブ・エラーです。解除されるまで内部接続のみにしてください。  
原因 ARCH プロセスがREDO ログをアーカイブしようとして、エラーを受け取りました。
  問題がすぐに解決されない場合、データベースはトランザクションの実行を停止します。
  アーカイブ先のデバイスで、REDO ログ・ファイルを格納する領域が不足している
  可能性があります。
処置 アーカイバ・トレース・ファイルを確認して、問題の詳細な説明を調べてください。
  また、初期化パラメータARCHIVE_LOG_DEST に指定されたデバイスが、アーカイブ
  に対して適切に設定されていることを検証してください。


どうやら、アーカイブログの保存先で何かあったようです。ディスク、パンクしたかな?

■ ディスク容量の確認

アーカイブログの出力先は知っているの、ディスク容量を確認してみます。ちなみに、OSはUnix(Solaris)です。

telnetで接続して、df -hk を実行。
df -hk
ファイルシステム サイズ 使用済み 使用可能 容量 マウント先
/dev/******/oraback 158G 156G 225M 100% /oraback
/dev/******/oracc 49G 17G 32G 35% /oracc


空き容量が225MBしかない。REDOログは、確か600MBにしてたはずなので、やはりこれが原因ですね。

しかし、アーカイブログの削除は毎日実行している処理(バックアップ)に組み込んでいるので、そんなに溜まらない筈なんですが、どういうことかね?

■ 接続できない!

アーカイブログを削除するためにOracleに接続しようとしたのですが、上手く行きません。
> sqlplus user01/user01pass@****

SQL*Plus: Release 11.2.0.2.0 Production on 木 1月 10 13:00:00 2015

Copyright (c) 1982, 2010, Oracle. All rights reserved.

ERROR:
ORA-00257: アーカイブ・エラーです。解除されるまで内部接続のみにしてください。


※ DBサーバ(Solaris)にtelnetで接続して、そこからSQL*Plusを起動しています。


Object Browserからも試してみたのですが、やはりダメです。
Oracleアーカイブログ (1)

Oracleアーカイブログ (2)

■ sysdba

調べたところ、内部接続のみってどういうことかは分からないのですが、sysdbaで接続しないとダメということは分かりました。それならそうと、エラーメッセージに書いて欲しいものです。

sysdbaってことは、ユーザーはsysを使わないとダメですかね。

まず、Solarisから。
> sqlplus sys/******@**** as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on 金 1月 10 13:10:00 2015

Copyright (c) 1982, 2010, Oracle. All rights reserved.



Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning option
に接続されました。


続いて、Object Browser。
Oracleアーカイブログ (3)

Oracleアーカイブログ (4)

こっちも大丈夫ですね。

■ RMAN

アーカイブログをOSのファイルシステムから直接削除すると色々と面倒になるので、RMANでの削除を試みます。

oracleユーザーで接続(下記ではrootでログインしてからoracleに切り替えてます)して、コマンドを実行してみます。
# su - oracle
Oracle Corporation SunOS 5.10 Generic Patch January 2005
> rman target /

Recovery Manager: Release 11.2.0.2.0 - Production on 木 1月 10 13:30:00 2015

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

ターゲット・データベース: **** (データベースID=2454092121)に接続されました

RMAN> delete archivelog until time 'sysdate - 7';

リカバリ・カタログのかわりにターゲット・データベース制御ファイルを使用しています
チャネル: ORA_DISK_1が割り当てられました
チャネルORA_DISK_1: SID=549 デバイス・タイプ=DISK
指定がリポジトリ内のどのアーカイブ・ログとも一致しません


システム日付から7日前までのアーカイブログを削除しようとしましたが、モノが無いようです。

そこで、アーカイブログの保存場所を見てみた(FFFTPで確認)のですが、タイムスタンプが全て当日になっています。やはり、日々のアーカイブログの削除処理は機能しているようですね。

■ ダンプファイル

アーカイブログの出力先なのですが、アーカイブログ以外にバックアップファイル(データポンプ・エクスポートのダンプファイル)も保存しています。アーカイブログを削除するより、このダンプファイルを何とかした方がよさそうです。

FFFTPで接続しているので、そこからダンプファイルを削除して十分な容量を確保します。

ここでアーカイブログの出力先を見ると、一呼吸おいてからアーカイブログが3個ほど出力されました。これで大丈夫そうです。

■ 時間指定で削除

これで終わっても良かったのですが、やはりアーカイブログも少し削除します。必要はないんですが、自力でアーカイブログを消したことが無かったので興味がありまして。

日付指定だとダメだったので、今度は時間まで指定します。2015/1/10の10時以前のアーカイブログを削除します。
# su - oracle
Oracle Corporation SunOS 5.10 Generic Patch January 2005
> rman target /

Recovery Manager: Release 11.2.0.2.0 - Production on 木 1月 10 13:30:00 2015

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

ターゲット・データベース: **** (データベースID=2454092121)に接続されました

RMAN> delete archivelog until time=
"TO_DATE('2015-01-10 10:00:00','YYYY-MM-DD HH24:MI:SS')";

チャネル: ORA_DISK_1がリリースされました
チャネル: ORA_DISK_1が割り当てられました
チャネルORA_DISK_1: SID=135 デバイス・タイプ=DISK
データベースdb_unique_name ****のアーカイブ・ログ・コピーのリスト
=====================================================================

Key Thrd Seq S Low時間
------- ---- ------- - --------
3800 1 3798 A 15-01-13
名前: /oraback/****/archive/log_1_3798_763766463.arc

3801 1 3799 A 15-01-14
名前: /oraback/****/archive/log_1_3799_763766463.arc



このオブジェクトを削除しますか(YESまたはNOを入力してください)。 yes
アーカイブ・ログを削除しました
アーカイブ・ログ・ファイル名=/oraback/****/archive/log_1_3798_76376
6463.arc レコードID=3800 スタンプ=868967519
アーカイブ・ログを削除しました
アーカイブ・ログ・ファイル名=/oraback/****/archive/log_1_3799_76376
6463.arc レコードID=3801 スタンプ=868993647

2オブジェクトを削除しました


今度は、上手く削除できました。

■ 余談

ここからは実際にやっていないので確証はないのですが、RMANを使わずにOS側からアーカイブログを削除しても、Oracleはディスクに空きが出来たと思ってくれないらしいです。

その場合は、RMANを起動して整合性チェックコマンドを実行するそうです。
RMAN> CROSSCHECK ARCHIVELOG ALL;


何でも、不整合があった場合は「アーカイブ・ログの検証に失敗しました」とか表示されるらしいです。

CROSSCHECKコマンドでOracle(というか、RMANかな)は不要なアーカイブログを確認するらしいのです。続けて、アーカイブログを削除するコマンドを実行します。
RMAN> DELETE EXPRRED ARCHIVELOG ALL


これで、OKだそうです。

ちなみに、「list archivelog all」ってコマンドを実行すると、RMANが認識しているアーカイブログの状態が表示されるらしいです。上のコマンドの前後で実行しておいた方が良いかも知れないですね。

■ 後書き

今回の障害の原因は、ダンプファイルの肥大が原因ではあるのですが、バックアップを取得しない訳にもいかないので、困ってしまいます。とりあえず、取得したバックアップを別の場所に退避してから削除するようにしたので、再発はしないと思いますが。

いや、しかし今回は辛かったです。前に書いた通り、日中にも障害対応(子会社との合併に伴うシステム移行 No18 時を超えて)があってクタクタだったのに、まさか続けて障害が起きるとは思ってませんでした。

それに、夜間処理の開始時間を前倒し()していたせいで、私が起きている時間帯に異常終了するようになったので、徹夜で対応しなければならなくなりました。前までは、問題があってもの2〜3時間は寝れたからなぁ。

・・・30を過ぎたあたりから、徹夜が辛いです。

投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end —

スポンサードリンク

PageTop

コメント


管理者にだけ表示を許可する