この章では、Recovery Managerをトラブルシューティングする方法について説明します。この章の内容は次のとおりです。
Recovery Managerは、問題のトラブルシューティングに役立つ詳細なエラー・メッセージを提供します。また、Oracle Databaseおよびサード・パーティのメディア・ベンダーは、独自の有効なデバッグ出力を生成します。この項では、発生する可能性がある様々なエラーの識別方法および解釈について説明します。
障害が発生したか、応答しなくなったRMANジョブのトラブルシューティングに役立つ出力は、表23-1に示すとおり、様々な場所に表示または格納されます。
表23-1 メッセージ出力タイプ
出力タイプ | 作成元 | 場所 | 説明 |
---|---|---|---|
RMANメッセージ |
RMAN |
ジョブの詳細情報は、 RMANをコマンドラインから実行すると、出力を次の場所に送ることができます。
|
RMANジョブに関連するアクションと、RMAN、データベース・サーバーおよびメディア・ベンダーによって生成されたエラー・メッセージが含まれています。RMANのエラー・メッセージには、 次のPL/SQLを実行すると、 SYS.DBMS_BACKUP_RESTORE.resetCfileSection(28); このファンクションでは、すべてのジョブ関連エントリが削除されます。新しいバックアップ・ジョブが |
Oracle Database |
|
エラー、初期化パラメータ設定および管理操作の時系列のログが含まれています。上書きされた制御ファイル・レコードの値が記録されます。 |
|
Oracle Database |
ADRホームの |
Oracle Databaseプロセスによって生成された詳細な出力が含まれています。このファイルは、 |
|
サード・パーティのメディア管理ソフトウェア |
ADRホームの |
メディア管理ソフトウェアによって生成されたベンダー固有の情報が含まれています。このログには、Oracle DatabaseまたはRMANのエラーは含まれていません。 |
|
メディア・マネージャのログ・ファイル |
サード・パーティのメディア管理ソフトウェア |
|
メディア管理デバイスの機能に関する情報が含まれています |
RMANは、エラーの発生時にそれらのエラーを通知します。回復不可能なエラーの場合、つまりRMANが別のチャネルへのフェイルオーバーを実行して特定のジョブ手順を完了することができない場合、すべてのジョブ・セットの完了後にエラーの概要レポートも出力されます。この機能は、遅延エラー・レポートともいいます。
「RMANのリターン・コードの識別」で説明するように、RMANにエラーが発生したかどうかを確認する方法の1つは、リターン・コードを調べることです。2つ目の方法は、Recovery Managerの出力内でRMAN-00569
文字列を検索することです。RMAN-00569は、エラー・スタック・バナーのメッセージ番号です。すべてのRMANエラーの前に、このエラー・メッセージが表示されます。出力内にRMAN-00569
メッセージが表示されない場合、エラーはありません。例23-1に、構文エラーの例を示します。
例23-1 RMAN構文エラー
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-00558: error encountered while parsing input commands RMAN-01005: syntax error: found ")": expecting one of: "archivelog, backup, backupset, controlfilecopy, current, database, datafile, datafilecopy, (, plus, ;, tablespace" RMAN-01007: at line 1 column 18 file: standard input
通常、RMANメッセージ・スタックには次のタイプのエラー・コードが含まれています。
接頭辞がRMAN-
のエラー
接頭辞がORA-
のエラー
Additional information:
の後に表示されるエラー
関連項目: RMANおよびORAのエラー・コードの詳細は、 『Oracle Databaseエラー・メッセージ』 を参照してください。 |
表23-2に、一般的なRMANエラー・メッセージのエラー範囲を示します。すべてのメッセージの詳細は、『Oracle Databaseエラー・メッセージ』を参照してください。
表23-2 RMANのエラー・メッセージの範囲
エラー範囲 | 原因 |
---|---|
0550-0999 |
コマンドライン・インタプリタ |
1000-1999 |
キーワード・アナライザ |
2000-2999 |
構文アナライザ |
3000-3999 |
主レイヤー |
4000-4999 |
サービス・レイヤー |
5000-5499 |
|
5500-5999 |
|
6000-6999 |
通常のコンパイル |
7000-7999 |
通常の実行 |
8000-8999 |
PL/SQLプログラム |
9000-9999 |
低レベルのキーワードのアナライザ |
10000-10999 |
サーバー側の実行 |
11000-11999 |
PL/SQLとRMAN間のフェーズ間エラー |
12000-12999 |
リカバリ・カタログ・パッケージ |
メディア・マネージャ・エラーが発生した場合、ORA-19511
が通知され、説明を含むエラー・メッセージがメディア・マネージャからRMANに戻されます。RMANは、メディア・マネージャから戻されたエラーを表示します。たとえば、次のようなエラーが表示されます。
ORA-19511: Error received from media manager layer, error text: sbtpvt_open_input: file .* does not exist or cannot be accessed, errno = 2
メディア・マネージャからのメッセージには、根本的な問題を修正するために十分な情報が含まれています。十分でない場合、ご使用のメディア・マネージャのドキュメントを参照するか、またはメディア管理ベンダーのサポート担当者に詳細を問い合せてください。ORA-19511
エラーは、Oracle Databaseではなくメディア・マネージャによって生成されます。データベースは、メディア・マネージャからのメッセージを渡すのみです。原因を解決できるのは、メディア管理ベンダーのみです。
SBT 1.1対応のメディア管理レイヤーを使用している場合、その他のエラー・メッセージ・テキストが表示される場合があります。SBT 1.1対応のメディア管理レイヤーからの出力は、次のものと類似しています。
ORA-19507: failed to retrieve sequential file, handle="c-140148591-20031014-06", parms="" ORA-27007: failed to open file Additional information: 7000 Additional information: 2 ORA-19511: Error received from media manager layer, error text: SBT error = 7000, errno = 0, sbtopen: backup file not found
「Additional information」には、SBT 1.1に固有なエラー・コードが表示されます。表示される値は、表23-3に示すメディア・マネージャ・メッセージ番号およびエラー・テキストに対応しています。RMANは、「ORA-19511: メディア・マネージャ・レイヤーからのエラーを受け取りました。
」を再度表示し、メディア・マネージャから戻されたエラー・コードに関連する一般的なエラー・メッセージおよびSBT 1.1エラー番号を表示します。
参考として、SBT 1.1エラー・メッセージを示します。表23-3に、メディア・マネージャ・メッセージ番号および各番号に対応するエラー・テキストを示します。エラー・コード内のO/S
は、オペレーティング・システムを意味します。アスタリスク(*)が付いているエラーは内部エラーであり、通常の操作中に一般的に表示されるものではありません。
表23-3 メディア・マネージャのエラー・メッセージの範囲
原因 | 番号 | メッセージ |
---|---|---|
sbtopen |
7000 7001 7002* 7003 7004 7005 7006 7007 7008 7009 7010 7011 7012* |
バックアップ・ファイルが見つかりません。(読取りの場合のみ戻されます。) バックアップ・ファイルは存在します。(書込みの場合のみ戻されます。) 不正なモードが指定されました。 指定されたブロック・サイズが無効です。 デバイスがありません。 デバイスは見つかりましたがビジーです。後で再試行してください。 ボリュームが見つかりません。 ボリュームは使用中です。 I/Oエラーです。 Media Managerと接続できません。 許可されません。 システム・エラー - 例: malloc、forkのエラー 引数が無効です。 |
sbtclose |
7020* 7021* 7022 7023 7024* 7025 |
ファイル・ハンドルが無効か、ファイルをオープンできません。 フラグが無効です。 I/Oエラーです。 O/Sエラー。 引数が無効です。 Media Managerと接続できません。 |
sbtwrite |
7040* 7041 7042 7043 7044* |
ファイル・ハンドルが無効か、ファイルをオープンできません。 ボリュームの終わりに達しました。 I/Oエラーです。 O/Sエラー。 引数が無効です。 |
sbtread |
7060* 7061 7062 7063 7064 7065* |
ファイル・ハンドルが無効か、ファイルをオープンできません。 EOFに達しました。 ボリュームの終わりに達しました。 I/Oエラーです。 O/Sエラー。 引数が無効です。 |
sbtremove |
7080 7081 7082 7083 7084 7085 7086* |
バックアップ・ファイルが見つかりません。 バックアップ・ファイルは使用中です。 I/Oエラーです。 Media Managerと接続できません。 許可されません。 O/Sエラー。 引数が無効です。 |
sbtinfo |
7090 7091 7092 7093 7094 7095* |
バックアップ・ファイルが見つかりません。 I/Oエラーです。 Media Managerと接続できません。 許可されません。 O/Sエラー。 引数が無効です。 |
sbtinit |
7110* 7111 |
引数が無効です。 O/Sエラー。 |
RMANエラー・スタック内の役立つメッセージを特定することが困難な場合があります。次のヒントおよび推奨事項を参考にしてください。
メッセージは下から上に読みます。これは、RMANは下から順にメッセージを発行するためです。スタックの最後から1つか2つのエラーが、通常は最も重要です。
SBT 1.1メディア管理レイヤーを使用しており、「追加情報」
およびエラー・コード(番号)を含むSBT 1.1形式のエラー・メッセージが表示された場合、その後に続くORA-19511
メッセージの、メディア・マネージャによってRMANに戻されたエラー・メッセージのテキストを確認します。これらのメッセージには、メディア管理レイヤーでの実際の障害が示されます。
エラー・バナーの直後にあるRMAN-03002
メッセージまたはRMAN-03009
メッセージを確認します(RMAN-03009
はRMAN-03002
と同じですが、RMAN-03009にはチャネルIDが含まれます)。これらのメッセージには、正常に実行されなかったコマンドが示されます。構文エラーの場合、RMAN-00558
が生成されます。
表23-2に示すエラー範囲を参照して基本的なエラー・タイプを判断し、最も重要なメッセージについて、『Oracle Databaseエラー・メッセージ』を参照して確認します。
users
表領域のバックアップを試行し、次のメッセージが戻されたと想定します。
Starting backup at 29-AUG-02 using channel ORA_DISK_1 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of backup command at 08/29/2002 15:14:03 RMAN-20202: tablespace not found in the recovery catalog RMAN-06019: could not translate tablespace name "USESR"
RMAN-03002
エラーは、BACKUP
コマンドが正常に実行されなかったことを示しています。スタックの最後の2つのメッセージを参照すると、表領域名を正しく入力しなかったため、リカバリ・カタログ内にusesr
という名前の表領域が見つからないことがわかります。
表領域のリカバリを試行し、次のエラーが戻されたと想定します。
RMAN> RECOVER TABLESPACE users; Starting recover at 29-AUG-07 using channel ORA_DISK_1 starting media recovery media recovery failed RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 08/29/2007 15:18:43 RMAN-11003: failure during parse/execution of SQL statement: alter database recover if needed tablespace USERS ORA-00283: recovery session canceled due to errors ORA-01124: cannot recover data file 8 - file is in use or recovery ORA-01110: data file 8: '/oracle/oradata/trgt/users01.dbf'
前述の推奨事項に従って、スタックの下から読み始めます。ORA-01110
メッセージは、users01.dbf
データファイルのリカバリで問題が発生したことを示しています。下から2つ目のメッセージは、そのデータファイルが使用中かリカバリ中であるため、リカバリ不可能であることを示しています。その他のRMANエラーは、サーバー・エラーのためにリカバリ・セッションが取り消されたことを示しています。こうして、このデータファイルはリカバリ中ではないため、問題はデータファイルがオンラインであることで、このファイルをオフラインにしてバックアップをリストアする必要があると判断できます。
テープ・ドライブを使用したバックアップ・ジョブ中に、次の出力が戻されたと想定します。
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== ORA-19624: operation failed, retry possible ORA-19507: failed to retrieve sequential file, handle="/tmp/mydir", parms="" ORA-27029: skgfrtrv: sbtrestore returned error ORA-19511: Error received from media manager layer, error text: sbtpvt_open_input:file /tmp/mydir does not exist or cannot be accessed, errno=2
ORA-19511
エラーの後に表示されるエラー・テキストはメディア・マネージャによって生成されたものであり、障害の根源を示しています。このエラーを解釈する方法は、メディア・マネージャのドキュメントを参照してください。
テープ・ドライブを使用したバックアップ・ジョブ中に、次の出力が戻されたと想定します。
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03009: failure of backup command on c1 channel at 09/04/2007 13:18:19 ORA-19506: failed to create sequential file, name="07d36ecp_1_1", parms="" ORA-27007: failed to open file SVR4 Error: 2: No such file or directory Additional information: 7005 Additional information: 1 ORA-19511: Error received from media manager layer, error text: SBT error = 7005, errno = 2, sbtopen: system error
SBT 1.1メディア・マネージャによって戻される最も重要な情報は、「Additional information」行にあるエラー・コードです。
Additional information: 7005
表23-3を参照すると、7005
エラーが、メディア管理デバイスがビジー状態であることを示していることがわかります。メディア管理ソフトウェアが使用中か、またはそのソフトウェアに問題が発生しているため、そのソフトウェアを使用してデバイスに書き込むことができません。
注意: sbtio.log には、Oracle Databaseではなくメディア管理ソフトウェアによって生成された情報が含まれています。そのため、それらのエラー・コードおよびメッセージを解釈するには、ご使用のメディア・ベンダーのドキュメントを参照する必要があります。sbtio.log に情報が記述されない場合、別の場所にエラー・メッセージが記述されているかどうか、またはメディア・マネージャ・エラーをsbtio.log に表示するために必要な手順があるかどうかを、ご使用のメディア・マネージャのサポートに問い合せてください。 |
RMANにエラーが発生したかどうかを確認する方法の1つは、リターン・コードまたは終了ステータスを調べることです。RMANクライアントは、そのクライアントが起動されたシェルに、エラーが発生しなかった場合は0(ゼロ)を戻し、エラーが発生した場合は0(ゼロ)以外のエラー値を戻します。
このリターン・コードへのアクセス方法は、RMANクライアントを起動した環境によって異なります。たとえば、UNIXおよびCシェルを実行している場合、RMANが完了すると、$status
というシェル変数にリターン・コードが配置されます。終了ステータスを戻す方法は、RMANクライアントではなくホスト・オペレーティング・システムの詳細によって異なります。
LIST
、REPORT
およびSHOW
を使用しても、RMANアクティビティで必要なすべての情報が表示されない場合は、いくつかの有効なV$ビューで詳細を参照できます。
バックアップおよびリカバリ・ジョブを実行するサーバー・セッションで現在実行されている動作を確認すると有効な場合があります。表23-4に示すビューは、RMANジョブに関する情報を取得する場合に有効です。
表23-4 トラブルシューティングで有効なV$ビュー
ビュー | 説明 |
---|---|
現在アクティブなプロセスを識別します |
|
現在アクティブなセッションを識別します。このビューを使用して、RMANが割り当てたチャネルに対応するデータベース・サーバー・セッションを判断します。 |
|
セッションが待機中のイベントまたはリソースのリストを表示します |
前述のビューを使用して、次のタスクを実行できます。
動的パフォーマンス・イベント・ビューのイベント名を使用して、Media Management APIに対するRMANコールを監視できます。イベント名は、SBTファンクションと1対1で対応します。次に例を示します。
Backup: MML v1 open backup piece Backup: MML v1 read backup piece Backup: MML v1 write backup piece Backup: MML v1 query backup piece Backup: MML v1 delete backup piece Backup: MML v1 close backup piece . . .
SBTイベントの完全なリストを取得するには、次の問合せを使用します。
SELECT NAME FROM V$EVENT_NAME WHERE NAME LIKE '%MML%';
サーバーは、Media Management APIでいずれかのファンクションをコールする前に、V$SESSION_WAIT
に行を追加して、STATE
列に文字列WAITING
を含めます。V$SESSION_WAIT.SECONDS_IN_WAIT
列には、サーバーが、このコールが戻されるのを待機している秒数が表示されます。SBTファンクションがメディア・マネージャから戻されると、この行は削除されます。
SBTイベント名に対応するV$SESSION_WAIT
の行には、問題は表示されません。これは、サーバーがこれらの行を実行時に更新するためです。これらの行は、コールが実行されると表示され、戻されると削除されます。ただし、SECONDS_IN_WAIT
列の値が高い場合、メディア・マネージャが一時停止している可能性があります。
SBTイベントを監視するには、次のSQL問合せを実行します。
COLUMN EVENT FORMAT a17 COLUMN SECONDS_IN_WAIT FORMAT 999 COLUMN STATE FORMAT a15 COLUMN CLIENT_INFO FORMAT a30 SELECT p.SPID, s.EVENT, s.SECONDS_IN_WAIT AS SEC_WAIT, sw.STATE, s.CLIENT_INFO FROM V$SESSION_WAIT sw, V$SESSION s, V$PROCESS p WHERE sw.EVENT LIKE '%MML%' AND s.SID=sw.SID AND s.PADDR=p.ADDR;
SQL出力を調べて、待機中のSBT機能を確認します。たとえば、次の出力には、RMANがsbtbackup
ファンクションが戻されるのを10分間待機していることが示されています。
SPID EVENT SEC_WAIT STATE CLIENT_INFO ---- ----------------- ---------- --------------- ------------------------------ 8642 Backup: MML creat 600 WAITING rman channel=ORA_SBT_TAPE_1
注意: V$SESSION_WAIT ビューにはデータベース・イベントのみが表示され、メディア・マネージャ・イベントは表示されません。 |
関連項目: V$SESSION_WAITビューの詳細は、『Oracle Databaseリファレンス』 を参照してください。 |
どのサーバー・セッションがどのRMANチャネルに対応しているかを確認するには、V$SESSION
およびV$PROCESS
を問い合せます。V$PROCESS
のSPID
列に、オペレーティング・システムのプロセスまたはスレッドのID番号が示されます。たとえば、UNIXではSPID
列にプロセスIDが表示され、WindowsではSPID
列にスレッドIDが表示されます。この情報を取得するには、複数のRMANセッションが同時にアクティブになっているかどうかに応じて、2つの基本的な方法があります。
アクティブなRMANセッションが1つのみの場合、RMANチャネルに対応するサーバー・セッションIDを確認する最も簡単な方法は、RMANジョブの実行中、ターゲット・データベースで次の問合せを実行することです。
COLUMN CLIENT_INFO FORMAT a30 COLUMN SID FORMAT 999 COLUMN SPID FORMAT 9999 SELECT s.SID, p.SPID, s.CLIENT_INFO FROM V$PROCESS p, V$SESSION s WHERE p.ADDR = s.PADDR AND CLIENT_INFO LIKE 'rman%';
出力例を次に示します。
SID SPID CLIENT_INFO ---- ------------ ------------------------------ 14 8374 rman channel=ORA_SBT_TAPE_1
システム生成のデフォルトIDではなく、RMANのSET COMMAND ID
コマンドを使用してIDを設定する場合、'rman%'
ではなく、CLIENT_INFO
列の値を検索します。
アクティブなRMANセッションが複数の場合、V$SESSION.CLIENT_INFO
列に、各セッションのチャネルに対して同じ情報が表示される場合があります。次に例を示します。
SID SPID CLIENT_INFO ---- ------------ ------------------------------ 14 8374 rman channel=ORA_SBT_TAPE_1 9 8642 rman channel=ORA_SBT_TAPE_1
この場合、次の方法でSID
値に対応するチャネルを確認します。
この方法では、まずRMAN出力からsid
値を取得して、その値をSQL問合せで使用する必要があります。
アクティブなセッションで、RMANジョブを通常どおりに実行し、出力を確認してチャネルのsid
を取得します。たとえば、次の出力が表示される場合があります。
Starting backup at 21-AUG-01
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: sid=14 devtype=SBT_TAPE
RMANジョブの実行中に
、SQL*Plusセッションを開始して、V$SESSION
およびV$PROCESSビューを結合して問い合せます。たとえば、次のように入力します。
COLUMN CLIENT_INFO FORMAT a30 COLUMN SID FORMAT 999 COLUMN SPID FORMAT 9999 SELECT s.SID, p.SPID, s.CLIENT_INFO FROM V$PROCESS p, V$SESSION s WHERE p.ADDR = s.PADDR AND CLIENT_INFO LIKE 'rman%' /
最初の手順で取得したsid
値を使用して、どのチャネルがどのサーバー・セッションに対応しているかを確認します。
SID SPID CLIENT_INFO ---------- ------------ ------------------------------ 14 2036 rman channel=ORA_SBT_TAPE_1 12 2066 rman channel=ORA_SBT_TAPE_1
この方法では、RMANバックアップ・スクリプトでコマンドID文字列を指定します。これによって、この文字列のV$SESSION.CLIENT_INFO
を問い合せることができます。
各セッションで、チャネルの割当て後
、COMMAND
IDを別々の値に設定して、目的のオブジェクトをバックアップします。たとえば、セッション1で次のように入力します。
RUN { ALLOCATE CHANNEL c1 TYPE disk; SET COMMAND ID TO 'sess1'; BACKUP DATABASE;
}
セッション2で実行中のジョブで、コマンドIDをsess2
などの文字列に設定します。
RUN { ALLOCATE CHANNEL c1 TYPE sbt; SET COMMAND ID TO 'sess2'; BACKUP DATABASE;
}
RMANジョブの実行中に
、SQL*Plusセッションを開始して、V$SESSION
およびV$PROCESSビューを結合して問い合せます。たとえば、次のように入力します。
SELECT SID, SPID, CLIENT_INFO FROM V$PROCESS p, V$SESSION s WHERE p.ADDR = s.PADDR AND CLIENT_INFO LIKE '%id=sess%';
RMANジョブでSET
COMMAND
ID
コマンドを実行した場合、CLIENT_INFO
列は次の形式で表示されます。
id=command_id,rman channel=channel_id
出力例を次に示します。
SID SPID CLIENT_INFO ---- ------------ ------------------------------ 11 8358 id=sess1 15 8638 id=sess2 14 8374 id=sess1,rman channel=c1 9 8642 id=sess2,rman channel=c1
文字列rman channel
を含む行に、バックアップを実行中のチャネルが表示されます。残りの行には、ターゲット・データベースへの接続が表示されます。
関連項目: SET COMMANDID の構文については、 『Oracle Databaseバックアップおよびリカバリ・リファレンス』 を参照してください。V$SESSIONおよびV$PROCESSの詳細は、 『Oracle Databaseリファレンス』 を参照してください。 |
一部のプラットフォームでは、Oracleによってsbttest
という診断ツールが提供されます。このユーティリティは、Oracle Databaseサーバーとして機能し、メディア・マネージャとの通信を試行することによって、メディア管理ソフトウェアの簡単なテストを実行します。
UNIX上では、sbttest
ユーティリティは、通常$ORACLE_HOME/bin
に存在します。なんらかの理由でプラットフォームにこのユーティリティが存在しない場合、Oracleサポート・サービスからこのプログラムのCバージョンを入手してください。このバージョンのプログラムは、すべてのUNIXプラットフォームでコンパイルできます。
Solarisなどのプラットフォームでは、sbttest
を使用する際に再リンクを行う必要はありません。その他のプラットフォームでは、再リンクが必要な場合があります。
sbttest
のオンライン・ドキュメントを入手するには、コマンドラインで次のコマンドを発行します。
% sbttest
このプログラムで使用可能な引数のリストが表示されます。
Error: backup file name must be specified Usage: sbttest backup_file_name # this is the only required parameter <-dbname database_name> <-trace trace_file_name> <-remove_before> <-no_remove_after> <-read_only> <-no_regular_backup_restore> <-no_proxy_backup> <-no_proxy_restore> <-file_type n> <-copy_number n> <-media_pool n> <-os_res_size n> <-pl_res_size n> <-block_size block_size> <-block_count block_count> <-proxy_file os_file_name bk_file_name [os_res_size pl_res_size block_size block_count]> <-libname sbt_library_name>
各引数の意味も表示されます。例として、2つのオプション・パラメータの説明を次に示します。
Optional parameters: -dbname specifies the database name which will be used by SBT to identify the backup file. The default is "sbtdb" -trace specifies the name of a file where the Media Management software will write diagnostic messages.
sbttest
を使用すると、メディア・マネージャの簡単なテストを実行できます。
sbttest
によって0(ゼロ)が戻される場合、テストがエラーなしで実行されています。これは、メディア・マネージャが正しくインストールされ、データ・ストリームを受け入れ、要求に応じて同じデータを戻すことができることを意味します。sbttest
によって0以外の値が戻される場合、メディア・マネージャがインストールされていないか、正しく構成されていません。
sbttestの使用手順
コマンドラインでsbttest
と入力し、プログラムがインストール済でシステム・パスに含まれていることを確認します。
% sbttest
プログラムが操作可能の場合、オンライン・ドキュメントが表示されます。
オンライン・ドキュメントに表示された任意の引数を指定して、プログラムを実行します。たとえば、some_file.f
テスト・ファイルを作成してsbtio.log
に出力を生成するには、次のコマンドを入力します。
% sbttest some_file.f -trace sbtio.log
既存のデータファイルのバックアップをテストすることもできます。たとえば、prod
データベースのtbs_33.f
データファイルをテストするには、次のコマンドを入力します。
% sbttest tbs_33.f -dbname prod
出力を確認します。プログラムの実行中にエラーが発生した場合、障害を説明するメッセージが出力されます。たとえば、データベースがライブラリを検出できない場合、次の出力が戻されます。
libobk.so could not be loaded. Check that it is installed properly, and that LD_LIBRARY_PATH environment variable (or its equivalent on your platform) includes the directory where this file can be found. Here is some additional information on the cause of this error: ld.so.1: sbttest: fatal: libobk.so: open failed: No such file or directory
sbttest
を実行可能でも、RMANバックアップを実行できない場合があります。次のような理由が考えられます。
sbttest
を実行したユーザーがOracle Databaseプロセスの所有者ではない。
データベース・サーバーがメディア管理ライブラリにリンクされていないか、または必要に応じてメディア管理ライブラリを動的にロードできない。この場合、sbttest
は機能しますが、メディア・マネージャに対するRMANによるバックアップは失敗します。
sbttest
プログラムはシェルからすべての環境変数を渡しているが、RMANは渡していない。
推奨する方法は、RMANインタフェースで[Control]キーを押しながら[C]キー(または、ご使用のシステムのアテンション・キーの組合せ)を押すことです。この操作では、テープのマウントを待機している場合など、割当て済チャネルがメディア管理コードで一時停止していないかぎり、そのチャネルも終了します。
SQLのALTER
SYSTEM KILL SESSION
文を実行すると、RMANチャネルに対応するサーバー・セッションを終了できます。
オペレーティング・システム上のRMANチャネルに対応するサーバー・セッションを終了します。
RMANチャネル用のOracleセッションIDは、RMANログ内の、次のような書式のメッセージに示されています。
channel ch1: sid=15 devtype=SBT_TAPE
割当て済チャネルごとに、sid
およびdevtype
が表示されます。Oracle Databaseのsid
はオペレーティング・システム・プロセスIDとは異なります。セッションを終了するには、SQLのALTER
SYSTEM
KILL
SESSION
文を使用します。
ALTER SYSTEM KILL SESSION
には、シリアル番号およびRMANメッセージに出力されたsid
の2つの引数を指定できます。いずれの引数も、V$SESSION
を問い合せて取得できます。たとえば、次の文を実行します。ここで、sid_in_rman_output
はRMANメッセージから得られた番号です。
SELECT SERIAL#
FROM V$SESSION
WHERE SID=sid_in_rman_output
;
問合せによって取得したsid_in_rman_output
およびシリアル番号を代入して次の文を実行します。
ALTER SYSTEM KILL SESSION 'sid_in_rman_output
,serial#
';
メディア・マネージャ・コードでセッションが停止した場合、この文はセッションに影響を与えません。
サーバー・セッションに関連付けられたプロセスの検出および終了の方法は、オペレーティング・システムによって異なります。サーバー・セッションがどのプロセスにも関連付けられていないプラットフォームもあります。詳細は、ご使用のオペレーティング・システム固有のドキュメントを参照してください。
メディア・マネージャで応答しなくなったRMANジョブを終了する必要がある場合があります。チャネル接続がメディア・マネージャで応答しなくなった場合にRMANを終了する最も適切な方法は、メディア・マネージャ内のセッションを終了することです。この操作で問題が解決しない場合、Linuxなどの一部のプラットフォームでは、接続を行っているOracle Databaseプロセスを終了できる場合があります。(Oracleプロセスを終了すると、メディア・マネージャに問題が発生する場合があります。詳細は、ご使用のメディア・マネージャのドキュメントを参照してください。)
RMANセッションの特性は、オペレーティング・システムに応じて異なります。UNIXでは、RMANセッションには次のプロセスが関連付けられています。
RMANクライアント・プロセス自体。
ターゲット・データベースへの初期接続であるデフォルト・チャネル。
各割当て済チャネルに1つ対応付けられた、ターゲット・データベースへのターゲット接続。
リカバリ・カタログを使用する場合、リカバリ・カタログ・データベースへのカタログ接続。
DUPLICATE操作またはTSPITR操作中は、補助インスタンスへの補助接続
。
様々な割当て済チャネルに対するRMANコマンドの実行の監視に使用される、ターゲット・データベースへのポーリング接続。デフォルトでは、RMANは1つのポーリング接続を確立します。ALLOCATE
CHANNEL
コマンドまたはCONFIGURE
CHANNEL
コマンドに異なる接続文字列を使用すると、RMANは追加のポーリング接続を確立します。ポーリング接続は、ALLOCATE
CHANNEL
コマンドまたはCONFIGURE
CHANNEL
コマンドに使用した各接続文字列に1つ存在します。
RMANが応答しなくなる理由は、通常、メディア・マネージャ・コードでテープ・リソースが使用可能になるまでチャネル接続が待機するためです。カタログ接続およびデフォルト・チャネルが一時停止しているように見えるのは、RMANからの指示を待機しているためです。ポーリング接続は、RMANプロセスの制御下でRPCをポーリングする間は無限にループしているように見えます。
RMANプロセス自体を終了すると、カタログ接続、補助接続、デフォルト・チャネルおよびポーリング接続が切断されます。メディア・マネージャ・コードの実行中以外に一時停止しているターゲット接続および補助接続も切断されます。メディア管理レイヤーで、ターゲット接続または補助接続が実行されている場合、これらのプロセスを終了するには、オペレーティング・システム・レベルで手動で終了する必要があります。
すべてのメディア・マネージャがOracle Databaseプロセスの終了を検出できるわけではありません。終了を検出しないメディア・マネージャは、リソースをビジー状態のままにしたり、処理を継続する場合があります。詳細は、ご使用のメディア・マネージャのドキュメントを参照してください。
カタログ接続を切断しても、RMANプロセスは終了されません。これは、RMANは、バックアップまたはリストアの実行中にはカタログ操作を実行しないためです。デフォルト・チャネルおよびポーリング接続を削除すると、RMANプロセスはチャネルの1つが存在しなくなったことを検出し、終了処理を実行します。この場合、前述のとおり、応答しなくなったチャネルへの接続はアクティブのままです。
メディア・マネージャ・コードで応答しなくなったチャネルが終了されると、RMANプロセスはその終了を検出し、終了処理を実行します。その際、メディア管理レイヤーで実行可能なターゲット接続を除く、すべての接続を削除します。この場合にも、メディア・マネージャ・リソースに関する警告が当てはまります。
メディア・マネージャで応答しなくなったOracle Databaseプロセスを終了する手順
「RMANのトラブルシューティングでのV$ビューの使用」
で説明するように、V$SESSION
およびV$SESSION_WAITを問い合せます。たとえば、次の問合せを実行します。
COLUMN EVENT FORMAT a17 COLUMN SECONDS_IN_WAIT FORMAT 999 COLUMN STATE FORMAT a10 COLUMN CLIENT_INFO FORMAT a30 SELECT p.SPID, s.EVENT, s.SECONDS_IN_WAIT AS SEC_WAIT, sw.STATE, s.CLIENT_INFO FROM V$SESSION_WAIT sw, V$SESSION s, V$PROCESS p WHERE sw.EVENT LIKE '%MML%' AND s.SID=sw.SID AND s.PADDR=p.ADDR;
SQL出力を調べて、待機中のSBT機能を確認します。たとえば、次のような出力が表示されます。
SPID EVENT SEC_WAIT STATE CLIENT_INFO ---- ----------------- ---------- ---------- ----------------------------- 8642 Backup:MML write 600 WAITING rman channel=ORA_SBT_TAPE_1 8374 Backup:MML write 600 WAITING rman channel=ORA_SBT_TAPE_2
ご使用のプラットフォームに適切なオペレーティング・システム・レベルのツールを使用して、応答しなくなったセッションを終了します。たとえば、Linuxではkill
-9
コマンドを実行します。
% kill -9 8642 8374
一部のプラットフォームには、orakill
というコマンドライン・ユーティリティが含まれています。このユーティリティを使用すると、特定のスレッドを終了できます。コマンド・プロンプトから、次のコマンドを実行します。ここで、sid
はターゲットに対するデータベース・インスタンスで、thread_id
は手順1の問合せで取得したSPID
値です。
orakill sid thread_id
メディア・マネージャがプロセスも消去したことを確認します。消去されていないプロセスが存在する場合、次のバックアップまたはリストア操作が、以前のバックアップおよびリストア操作の問題が原因で再度フリーズする可能性があります。一部のメディア・マネージャでは、この唯一の解決策は、メディア・マネージャを停止して再起動することです。メディア・マネージャのドキュメントに必要な情報が記載されていない場合、メディア・マネージャのテクニカル・サポートに問い合せてください。
関連項目: 関連するコマンドについては、ご使用のオペレーティング・システム固有のドキュメントを参照してください。 |