実録！ DBA1.0 vs. DBA2.0 障害対応対決

Oracle管理者のための「時間術」

 

　
初音玲
2009/3/6

Round1：障害対応対決

　Oracle Database 11g Release 1を使って、コマンドとスクリプトを駆使したDBA 1.0とEnterprise Manager Database Controlを駆使したDBA 2.0では、障害発生時の対応はどのように違うか比較してみよう。

DBA 1.0の障害対応：達人クラスで作業時間5分

　「データベースにつながらなくなった」

と連絡を受けた場合、DBA 1.0はリモートデスクトップ、telnet、ssh、サーバ端末などを使って、サーバ上からSQL*Plusに接続してデータベースインスタンスの状態を確認する。

●手順1　状況の確認 
[oracle@ora11g ~]$ sqlplus / as sysdba　//（1)SYSDBA権限で接続

SQL*Plus: Release 11.1.0.5.0 - Production on 火 1月 27 22:19:55 2009

Copyright (C) 1982, 2007, Oracle.  All rights reserved.



Oracle Database 11g Release 11.1.0.6.0 - Production
に接続されました。
SQL> SELECT status FROM v$instance;　//（2）インスタンスの状態を確認

STATUS
---------------------------------------
MOUNTED　　//（3）マウントはされているがOPENになっていない

SQL> ALTER DATABASE OPEN;　//（4）OPENを実行してみる
ALTER DATABASE OPEN
*
行1でエラーが発生しました。:
ORA-01157: データファイル4を識別/ロックできません - 
DBWRトレースファイルを参照してください ORA-01110:
データファイル4: '/u01/app/oracle/oradata/orcl/users01.dbf'

　Oracle Databaseが動いている機器にインストールされたSQL*Plusに接続したら、SYSDBA権限を持ったSYSユーザーとして接続する。ローカル接続なのでIDやパスワードは指定せず「/」だけで接続可能だ。

　V$INSTANCE表を確認するとデータベースはマウント状態にありオープン状態にはなっていないので、ALTER DATABASE OPENコマンドでデータベースをオープンして使用可能になるように操作したが、データファイル4がないというエラーになった。

　どうやらこのファイルが原因のようなのでOracle Databaseのファイルを格納してあるフォルダを確認したところ、users01.dbfファイルが存在しないことが分かった。

　そこで、次のようなリカバリ策を試すことにした。

●手順2　リカバリ 
SQL> shutdown immediate　//immediateモードでシャットダウン
ORA-01109: データベースがオープンされていません。


データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました
SQL> startup open recover //リカバリモードでオープンしてみる
ORACLEインスタンスが起動しました。

Total System Global Area   347340800 bytes
Fixed Size                   1299848 bytes
Variable Size              314575480 bytes
Database Buffers            25165824 bytes
Redo Buffers                 6299648 bytes
データベースがマウントされました。
ORA-01157: データファイル4を識別/ロックできません - 
DBWRトレースファイルを参照してください ORA-01110:
データファイル4: '/u01/app/oracle/oradata/orcl/users01.dbf'



SQL> exit
Oracle Database 11g Release 11.1.0.6.0 - Productionとの接続が切断されました。

　Immediateモードでデータベースをシャットダウンしてからリカバリモードでのオープンを試みたが、マウントまでしか行われず、オープンできないままだ。

　そこで、RMAN（Recovery Manager）を使って対応する。

●手順3　RMANの実行 
[oracle@ora11g ~]$ rman target / as nocatalog　//RMANから接続

Recovery Manager : Release 11.1.0.6.0 - Production on 火 1月 27 22:21:17 2009

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

ターゲット・データベース: ORCL(DBID=1195388079、未オープン)に接続されました
リカバリ・カタログのかわりにターゲット・データベース制御ファイルを使用しています

RMAN> restore datafile 4;　//データファイル4をリストア

restoreが開始されました(開始時間: 09-01-27)
チャネル: ORA_DISK_1: SID=152 デバイス・タイプ=DISK
 :
 :
 :
restoreが完了しました(完了時間: 09-01-27)

RMAN> recover datafile 4;  //データファイル4をリカバー

recoverが開始されました(開始時間: 09-01-27)
チャネルORA_DISK_1の使用
 :
 :
 :
recoverが完了しました(完了時間: 09-01-27)

RMAN> quit


Recovery Managerが完了しました。

　ローカルをターゲットとしてRMANでOracleインスタンスに接続したら、データファイル4に対してrestoreとrecoverを実施する。

●手順4　データベースのオープン 
[oracle@ora11g ~]$ sqlplus / as sysdba　//sysdbaとして接続

SQL*Plus: Release 11.1.0.5.0 - Production on 火 1月 27 22:24:25 2009

Copyright (C) 1982, 2007, Oracle.  All rights reserved.



Oracle Database 11g Release 11.1.0.6.0 - Production
に接続されました。
SQL> ALTER DATABASE OPEN;　//OPENを実施

データベースが変更されました。

SQL>

　データベースのオープンが正常に完了して「データベースが変更されました。」と表示されるのを待つ。

　作業時間の実測結果は、22時19分47秒〜24分54秒までの5分くらいになった。あらかじめRMANで使用するコマンドを調べておくなどの事前準備があったので、RMANのノウハウがかなりあるデータベース管理者の作業時間だと見なせるかもしれない。

前のページへ 2/4 次のページへ

Index
Oracle管理者のための「時間術」

Page 1
・かつてOracleメンテナンス担当は三重苦だった!?
　9iまでの「職人芸」とそれ以降
・Round0：障害対応対決〜両者のスペック
　DBA 1.0のシステム構成
　DBA 2.0のシステム構成
→ Page 2
・Round1：障害対応対決
　DBA 1.0の障害対応：達人クラスで作業時間5分

Page 3
　DBA 2.0の障害対応：誰がやっても4分以内！

Page 4
・Round2：ボトルネック調査対決
　DBA 1.0の対応：「もう1回発生したら分かるかも」
　DBA 2.0の対応：問題のクエリを即、究明
・最後に：少ない作業コストで状態把握を
Databaseフォーラム全記事インデックス


Database Expert フォーラム 新着記事
＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

注目のテーマ

Database Expert 記事ランキング

本日月間
＠IT