実録！ 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フォーラム全記事インデックス

TechTargetジャパン

Database Expert フォーラム新着記事

データ分析に必要な「道具」を揃える （2013/5/23）
　データ分析の準備・加工に優れた道具とは？データ分析する際のスタンダードになっている環境をセットアップ！
PostgreSQLエンタープライズ利用の指針が続々公開 （2013/5/21）
　堅牢性やスケーラビリティの面からエンタープライズ用途でも採用されることの多いPostgreSQL。運用のノウハウを公開する動きをウォッチ
僕たちが分散KVSでファイルシステムを実装した理由 （2013/5/14）
　KVSの仕組みをそのままファイルシステムに使ったら？ okuyamaの開発者たちがファイルシステムを実装してみた
DB界隈で聞こえてきた2つの新しいメッセージ （2013/5/10）
　今回はデータプラットフォームについて、直近で製品発表のあった2社のトレンドをウォッチ。いずれも新しいメッセージを示すものだ