ヘッダーをスキップ

Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド
11g リリース1(11.1)

E05700-03
目次
目次
索引
索引

戻る 次へ

22 Recovery Manager操作のトラブルシューティング

この章では、Recovery Managerをトラブルシューティングする方法について説明します。この章では、次の項目について説明します。

Recovery Managerのメッセージ出力の解釈

Recovery Managerは、問題のトラブルシューティングに役立つ詳細なエラー・メッセージを提供します。また、Oracle Databaseサーバーおよびサード・パーティのメディア・ベンダーは、独自の有効なデバッグ出力を生成します。この項では、発生する可能性がある様々なエラーの識別方法および解釈について説明します。

メッセージ出力タイプの識別

障害が発生したか、ハングアップしたRecovery Managerジョブのトラブルシューティングに役立つ出力は、次の表に示すとおり、様々な場所に表示または格納されます。

出力タイプ  作成元  場所  説明 

Recovery Managerメッセージ 

Recovery Manager 

ジョブの詳細情報は、V$RMAN_STATUSおよびRC_RMAN_STATUSに表示されます。現行のジョブの情報は、V$RMAN_OUTPUTに表示されます。

Recovery Managerをコマンドラインから実行すると、出力を次の場所に送ることができます。

  • 標準出力

  • コマンドラインのLOGまたはSPOOL LOGコマンドで指定したログ・ファイル

  • Recovery Manager出力をリダイレクトすることで作成したファイル(UNIXの>演算子などによる)

 

Recovery Managerジョブに関連するアクション、およびRecovery Manager、データベース・サーバー、メディア・ベンダーによって生成されたエラー・メッセージが含まれています。Recovery Managerのエラー・メッセージには、RMAN-xxxxxという接頭辞が付いています。通常のアクションの説明には接頭辞は付きません。

次のPL/SQLを実行すると、V$RMAN_STATUSからすべてのエントリを削除できることに注意してください。

SYS.DBMS_BACKUP_RESTORE.resetCfileSection(28);

このファンクションでは、すべてのジョブ関連エントリが削除されます。新しいバックアップ・ジョブがV$RMAN_BACKUP_JOB_DETAILSに表示されるまで、行は表示されません。 

alert_SID.log 

Oracle Database 

自動診断リポジトリ・ホームのalertサブディレクトリ 

エラー、初期化パラメータ設定および管理操作の時系列のログが含まれています。上書きされた制御ファイル・レコードの値が記録されます。 

Oracleトレース・ファイル 

Oracle Database 

ADRホームのtraceサブディレクトリ 

Oracleサーバー・プロセスによって生成された詳細な出力が含まれています。このファイルは、ORA-600またはORA-3113エラー・メッセージが発生したとき、Recovery Managerがチャネルを割り当てられないとき、およびデータベースがメディア管理ライブラリのロードに失敗したときに作成されます。 

sbtio.log 

サード・パーティのメディア管理ソフトウェア 

ADRホームのtraceサブディレクトリ 

メディア管理ソフトウェアによって生成されたベンダー固有の情報が含まれています。このログには、OracleサーバーまたはRecovery Managerのエラーは含まれていません。 

メディア・マネージャのログ・ファイル 

サード・パーティのメディア管理ソフトウェア 

sbtio.log以外のすべてのメディア・マネージャのログのファイル名は、メディア管理ソフトウェアによって決定されます。 

メディア管理デバイスの機能に関する情報が含まれています。 

Recovery Managerのエラー・メッセージ・スタックの識別

Recovery Managerは、エラーの発生時にそれらのエラーを通知します。回復不可能なエラーの場合、Recovery Managerは別のチャネルへのフェイルオーバーを実行して特定のジョブ手順を完了することができず、すべてのジョブ・セットの完了後にエラーの概要レポートを出力します。この機能は、遅延エラー・レポートともいいます。

「Recovery Managerのリターン・コードの識別」で説明するように、Recovery Managerにエラーが発生したかどうかを確認する方法の1つは、リターン・コードを調べることです。2つ目の方法は、Recovery Managerの出力内でRMAN-00569文字列を検索することです。RMAN-00569は、エラー・スタック・バナーのメッセージ番号です。すべてのRecovery Managerエラーの前に、このエラー・メッセージが表示されます。出力内にRMAN-00569メッセージが表示されない場合、エラーはありません。次に、構文エラーの例を示します。

例22-1    Recovery Manager構文エラー

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

エラー・コードの識別

通常、Recovery Managerメッセージ・スタックには次のタイプのエラー・コードが含まれています。

Recovery Managerのエラー・メッセージ番号

表22-2に、一般的なRecovery Managerエラー・メッセージのエラー範囲を示します。すべてのメッセージの詳細は、『Oracle Databaseエラー・メッセージ』を参照してください。

表22-2    Recovery Managerのエラー・メッセージの範囲 
エラー範囲  原因 

0550-0999 

コマンドライン・インタプリタ 

1000-1999 

キーワード・アナライザ 

2000-2999 

構文アナライザ 

3000-3999 

主レイヤー 

4000-4999 

サービス・レイヤー 

5000-5499 

RESTOREコマンドまたはRECOVERコマンドのコンパイル 

5500-5999 

DUPLICATEコマンドのコンパイル 

6000-6999 

通常のコンパイル 

7000-7999 

通常の実行 

8000-8999 

PL/SQLプログラム 

9000-9999 

低レベルのキーワードのアナライザ 

10000-10999 

サーバー側の実行 

11000-11999 

PL/SQLとRecovery Manager間のフェーズ間エラー 

12000-12999 

リカバリ・カタログ・パッケージ 

ORA-19511: メディア・マネージャ・エラー

メディア・マネージャ・エラーが発生した場合、ORA-19511が表示され、説明を含むエラー・メッセージがメディア・マネージャからRecovery Managerに戻されます。Recovery Managerは、メディア・マネージャから戻されたエラーを表示します。たとえば、次のようなエラーが表示されます。

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に固有なエラー・コードが表示されます。表示される値は、表22-3に示すメディア・マネージャ・メッセージ番号およびエラー・テキストに対応しています。Recovery Managerは、「ORA-19511: メディア・マネージャ・レイヤーからのエラーを受け取りました。」を再度表示し、メディア・マネージャから戻されたエラー・コードに関連する一般的なエラー・メッセージおよびSBT 1.1エラー番号を表示します。

参考として、SBT 1.1エラー・メッセージを示します。表22-3に、メディア・マネージャ・メッセージ番号および各番号に対応するエラー・テキストを示します。エラー・コード内のO/Sは、オペレーティング・システムを意味します。アスタリスクが付いているエラーは内部エラーであり、通常の操作中に一般的に表示されるものではありません。

表22-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エラー。 

Recovery Managerエラー・スタックの解釈

Sometimes Recovery Managerエラー・スタック内の役立つメッセージを特定することが困難な場合があります。次のヒントおよび推奨事項を参考にしてください。

Recovery Managerエラーの解釈の例

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つのメッセージを参照すると、表領域名を正しく入力しなかったため、リカバリ・カタログ内にuserという名前の表領域が見つからないことがわかります。

サーバー・エラーの解釈の例

表領域のリカバリを試行し、次のエラーが戻されたと想定します。

RMAN> RECOVER TABLESPACE users;

Starting recover at 29-AUG-01
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つ目のメッセージは、そのデータファイルが使用中かリカバリ中であるため、リカバリ不可能であることを示しています。その他のRecovery Managerエラーは、サーバー・エラーのためにリカバリ・セッションが取り消されたことを示しています。このデータファイルはリカバリ中ではないため、問題はデータファイルがオンラインであることであり、このファイルをオフラインにしてバックアップをリストアする必要があると判断できます。

SBT 2.0のメディア管理エラーの解釈の例

テープ・ドライブを使用したバックアップ・ジョブ中に、次の出力が戻されたと想定します。

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エラーの後に表示されるエラー・テキストはメディア・マネージャによって生成されたものであり、障害の根源を示しています。このエラーを解釈する方法は、メディア・マネージャのドキュメントを参照してください。

SBT 1.1のメディア管理エラーの解釈の例

テープ・ドライブを使用したバックアップ・ジョブ中に、次の出力が戻されたと想定します。

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

表22-3「メディア・マネージャのエラー・メッセージの範囲」を参照すると、7005エラーが、メディア管理デバイスがビジー状態であることを示していることがわかります。メディア管理ソフトウェアが使用中か、またはそのソフトウェアに問題が発生しているため、そのソフトウェアを使用してデバイスに書き込むことができません。


注意:

sbtio.logには、Oracle Databaseではなくメディア管理ソフトウェアによって生成された情報が含まれています。そのため、それらのエラー・コードおよびメッセージを解釈するには、ご使用のメディア・ベンダーのドキュメントを参照する必要があります。sbtio.logに情報が記述されない場合、別の場所にエラー・メッセージが記述されているかどうか、またはメディア・マネージャ・エラーをsbtio.logに表示するために必要な手順があるかどうかを、ご使用のメディア・マネージャのサポートに問い合せてください。 


Recovery Managerのリターン・コードの識別

Recovery Managerにエラーが発生したかどうかを確認する方法の1つは、リターン・コードまたは終了ステータスを調べることです。Recovery Managerクライアントは、そのクライアントが起動されたシェルに、エラーが発生しなかった場合は0(ゼロ)を戻し、エラーが発生した場合は0(ゼロ)以外のエラー値を戻します。

このリターン・コードへのアクセス方法は、Recovery Managerクライアントを起動した環境によって異なります。たとえば、UNIXおよびCシェルを実行している場合、Recovery Managerが完了すると、$statusというシェル変数にリターン・コードが配置されます。終了ステータスを戻す方法は、Recovery Managerクライアントではなくホスト・オペレーティング・システムの詳細によって異なります。

Recovery ManagerのトラブルシューティングでのV$ビューの使用

LISTREPORTおよびSHOWを使用しても、Recovery Managerアクティビティで必要なすべての情報が表示されない場合は、多数のV$ビューで詳細を参照できます。

バックアップおよびリカバリ・ジョブを実行するサーバー・セッションで現在実行されている動作を確認すると有効な場合があります。表22-4に示すビューは、Recovery Managerジョブに関する情報を取得する場合に有効です。

表22-4    トラブルシューティングで有効なV$ビュー 
ビュー  説明 

V$PROCESS 

現在アクティブなプロセスを識別します。 

V$SESSION 

現在アクティブなセッションを識別します。このビューを使用して、Recovery Managerが割り当てたチャネルに対応するデータベース・サーバー・セッションを判断します。 

V$SESSION_WAIT 

セッションが待機中のイベントまたはリソースのリストを表示します。 

前述のビューを使用して、次のタスクを実行できます。

Recovery Managerとメディア・マネージャの相互作用の監視

動的パフォーマンス・イベント・ビューのイベント名を使用して、Media Management APIに対するRecovery Managerコールを監視できます。イベント名は、SBTファンクションと1対1で対応します。次に例を示します。

Backup: sbtinit
Backup: ssbtopen
Backup: ssbtread
Backup: ssbtwrite
Backup: ssbtbackup
.
.
.

SBTイベントの完全なリストを取得するには、次の問合せを使用します。

SELECT NAME 
FROM   V$EVENT_NAME 
WHERE  NAME LIKE '%sbt%';

サーバーは、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 a10
COLUMN SECONDS_IN_WAIT FORMAT 999
COLUMN STATE FORMAT a20
COLUMN CLIENT_INFO FORMAT a30

SELECT p.SPID, EVENT, SECONDS_IN_WAIT AS SEC_WAIT, 
       sw.STATE, CLIENT_INFO
FROM   V$SESSION_WAIT sw, V$SESSION s, V$PROCESS p
WHERE  sw.EVENT LIKE 's%bt%'
AND    s.SID=sw.SID
AND    s.PADDR=p.ADDR;

SQL出力を調べて、待機中のSBT機能を確認します。たとえば、次の出力には、Recovery Managerがsbtbackupファンクションが戻されるのを10分間待機していることが示されています。

SPID EVENT             SEC_WAIT   STATE                CLIENT_INFO
---- ----------------- ---------- -------------------- ------------------------------
8642 Backup: sbtbackup 600        WAITING              rman channel=ORA_SBT_TAPE_1


注意:

V$SESSION_WAITビューにはデータベース・イベントのみが表示され、メディア・マネージャ・イベントは表示されません。 


参照:

V$SESSION_WAITの詳細は、『Oracle Databaseリファレンス』を参照してください。 

サーバー・セッションとRecovery Managerチャネルの関連付け

どのサーバー・セッションがどのRecovery Managerチャネルに対応しているかを確認するには、V$SESSIONおよびV$PROCESSを問い合せます。V$PROCESSSPID列に、オペレーティング・システムのプロセスまたはスレッドのID番号が示されます。たとえば、UNIXではSPID列にプロセスIDが表示され、WindowsではSPID列にスレッドIDが表示されます。この情報を取得するには、複数のRecovery Managerセッションが同時にアクティブになっているかどうかに応じて、2つの基本的な方法があります。

アクティブなRecovery Managerセッションが1つの場合のサーバー・セッションとチャネルの一致

アクティブなRecovery Managerセッションが1つのみの場合、Recovery Managerチャネルに対応するサーバー・セッションIDを確認する最も簡単な方法は、Recovery Managerジョブの実行中、ターゲット・データベースで次の問合せを実行することです。

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ではなく、Recovery ManagerのSET COMMAND IDコマンドを使用してIDを設定する場合、'rman%'ではなく、CLIENT_INFO列の値を検索します。

Recovery Managerセッションが複数の場合のサーバー・セッションとチャネルの一致

アクティブなRecovery Managerセッションが複数の場合、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値に対応するチャネルを確認します。

Recovery Manager出力からのチャネルIDの取得

この方法では、まずRecovery Manager出力からsid値を取得して、その値をSQL問合せで使用する必要があります。

バックアップ中にプロセスをチャネルに関連付ける手順
  1. いずれかのアクティブなセッションで、Recovery Managerジョブを通常どおりに実行し、出力を確認してチャネルのsidを取得します。たとえば、次の出力が表示される場合があります。

    Starting backup at 21-AUG-01
    allocated channel: ORA_SBT_TAPE_1
    channel ORA_SBT_TAPE_1: sid=14 devtype=SBT_TAPE
    
    
  2. Recovery Managerジョブの実行中に、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
    
SET COMMAND IDを使用したサーバー・セッションとチャネルの関連付け

この方法では、Recovery Managerバックアップ・スクリプトでコマンドID文字列を指定します。これによって、この文字列のV$SESSION.CLIENT_INFOを問い合せることができます。

バックアップ中にプロセスをチャネルに関連付ける手順
  1. 各セッションで、チャネルの割当て後、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;
    }
    
    
  2. Recovery Managerジョブの実行中に、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%';
    
    

    Recovery Managerジョブで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 COMMAND ID構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。V$SESSIONおよびV$PROCESSの詳細は、『Oracle Databaseリファレンス』を参照してください。 

Media Management APIのテスト

一部のプラットフォームでは、Oracleによってsbttestという診断ツールが提供されます。このユーティリティは、Oracle Databaseサーバーと同様にメディア・マネージャとの通信を試行して、メディア管理ソフトウェアの簡単なテストを実行します。

sbttestユーティリティの入手

UNIX上では、sbttestユーティリティは、通常$ORACLE_HOME/binに存在します。なんらかの理由でプラットフォームにこのユーティリティが存在しない場合、Oracleサポート・サービスからこのプログラムのCバージョンを入手してください。このバージョンのsbttestプログラムは、すべてのUNIXプラットフォームでコンパイルできます。

Solarisなどのプラットフォームでは、sbttestを使用する際に再リンクを行う必要はありません。その他のプラットフォームでは、再リンクが必要な場合があります。

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を使用すると、メディア・マネージャの簡単なテストを実行できます。

sbttestによって0(ゼロ)が戻される場合、テストがエラーなしで実行されています。これは、メディア・マネージャが正しくインストールされ、データ・ストリームを受け入れ、要求に応じて同じデータを戻すことができることを意味します。sbttestによって0以外の値が戻される場合、メディア・マネージャがインストールされていないか、正しく構成されていません。

sbttestの使用手順
  1. コマンドラインでsbttestと入力し、プログラムがインストール済でシステム・パスに含まれていることを確認します。

    % sbttest
    
    

    プログラムが操作可能の場合、オンライン・ドキュメントが表示されます。

  2. オンライン・ドキュメントに表示された任意の引数を指定して、プログラムを実行します。たとえば、some_file.fテスト・ファイルを作成してsbtio.logに出力を生成するには、次のコマンドを入力します。

    % sbttest some_file.f -trace sbtio.log
    
    

    既存のデータファイルのバックアップをテストすることもできます。たとえば、prodデータベースのtbs_33.fデータファイルをテストするには、次のコマンドを入力します。

    % sbttest tbs_33.f -dbname prod
    
    
  3. 出力を確認します。プログラムの実行中にエラーが発生した場合、障害を説明するメッセージが出力されます。たとえば、データベースがライブラリを検出できない場合、次の出力が戻されます。

    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を実行可能でも、Recovery Managerバックアップを実行できない場合があります。次のような理由が考えられます。

Recovery Managerコマンドの終了

実行中のRecovery Managerコマンドは、次の複数の方法で終了できます。

ALTER SYSTEM KILL SESSIONによるセッションの終了

Recovery Managerチャネル用のOracleセッションIDは、Recovery Managerログ内の、次のような書式のメッセージに示されています。

channel ch1: sid=15 devtype=SBT_TAPE

割当て済チャネルごとに、sidおよびdevtypeが表示されます。Oracleのsidはオペレーティング・システム・プロセスIDとは異なることに注意してください。セッションを強制終了するには、SQLのALTER SYSTEM KILL SESSION文を使用します。

ALTER SYSTEM KILL SESSIONには、シリアル番号およびRecovery Managerメッセージに出力されたsidの2つの引数を指定できます。いずれの引数も、V$SESSIONを問い合せて取得できます。たとえば、次の文を実行します。ここで、sid_in_rman_outputはRecovery Managerメッセージから得られた番号です。

SELECT SERIAL# 
FROM   V$SESSION 
WHERE  SID=sid_in_rman_output;

問合せによって取得したsid_in_rman_outputおよびシリアル番号を代入して次の文を実行します。

ALTER SYSTEM KILL SESSION 'sid_in_rman_output,serial#';

メディア・マネージャ・コードでセッションがハングアップしている場合は、この文を実行してもハングアップ状態は解消しません。

オペレーティング・システム・レベルでのセッションの終了

サーバー・セッションに関連付けられたプロセスの検出および強制終了の方法は、オペレーティング・システムによって異なります。サーバー・セッションがどのプロセスにも関連付けられていないプラットフォームもあります。詳細は、ご使用のオペレーティング・システム固有のドキュメントを参照してください。

メディア・マネージャでハングアップしたRecovery Managerセッションの終了

メディア・マネージャでハングアップしたRecovery Managerジョブを強制終了する必要がある場合があります。チャネル接続がメディア・マネージャでハングアップした場合にRecovery Managerを終了する最も適切な方法は、メディア・マネージャ内のセッションを強制終了することです。この操作で問題が解決しない場合、UNIXなどの一部のプラットフォームでは、接続を行っているOracleプロセスを強制終了できる場合があります。(Oracleプロセスを強制終了すると、メディア・マネージャに問題が発生する場合があることに注意してください。詳細は、ご使用のメディア・マネージャのドキュメントを参照してください。)

Recovery Managerセッションの構成要素

Recovery Managerセッションの特性は、オペレーティング・システムに応じて異なります。UNIXでは、Recovery Managerセッションには次のプロセスが関連付けられています。

ジョブのハングアップ中のプロセス動作

Recovery Managerがハングアップする理由は、通常、チャネル接続の1つが、メディア・マネージャ・コードでテープ・リソースが使用可能になるまで待機するためです。カタログ接続およびデフォルト・チャネルがハングアップしているように見えるのは、Recovery Managerからの指示を待機しているためです。ポーリング接続は、Recovery Managerプロセスの制御下でRPCをポーリングする間は無限にループしているように見えます。

Recovery Managerプロセス自体を強制終了すると、カタログ接続、補助接続、デフォルト・チャネルおよびポーリング接続が切断されます。メディア・マネージャ・コードでハングアップしていないターゲット接続および補助接続も切断されます。メディア管理レイヤーで実行しているターゲット接続か補助接続のいずれかは切断されません。これらのプロセスを終了するには、オペレーティング・システム・レベルで手動で強制終了する必要があります。

すべてのメディア・マネージャがOracleプロセスの終了を検出できるわけではありません。終了を検出しないメディア・マネージャは、リソースをビジー状態のままにしたり、処理を継続する場合があります。詳細は、ご使用のメディア・マネージャのドキュメントを参照してください。

カタログ接続を切断しても、Recovery Managerプロセスは終了されません。これは、Recovery Managerは、バックアップまたはリストアの実行中にはカタログ操作を実行しないためです。デフォルト・チャネルおよびポーリング接続を削除すると、Recovery Managerプロセスはチャネルの1つが終了したことを検出し、終了処理を実行します。この場合、前述のとおり、ハングアップしたチャネルへの接続はアクティブのままです。

Recovery Managerセッションの終了の基本手順

メディア・マネージャ・コードでハングアップしたチャネルが強制終了されると、Recovery Managerプロセスはその終了を検出し、終了処理を実行します。その際、メディア管理レイヤーで実行可能なターゲット接続を除く、すべての接続を削除します。この場合にも、メディア・マネージャ・リソースに関する警告が当てはまります。

メディア・マネージャでハングアップしたOracleプロセスの終了手順
  1. 「Recovery ManagerのトラブルシューティングでのV$ビューの使用」で説明するように、V$SESSIONおよびV$SESSION_WAITを問い合せます。たとえば、次の問合せを実行します。

    COLUMN EVENT FORMAT a10
    COLUMN SECONDS_IN_WAIT FORMAT 999
    COLUMN STATE FORMAT a20
    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 'sbt%'
    AND    s.SID=sw.SID
    AND    s.PADDR=p.ADDR;
    
    

    SQL出力を調べて、待機中のSBT機能を確認します。たとえば、次のような出力が表示されます。

    SPID EVENT        SEC_WAIT STATE                CLIENT_INFO
    ---- ---------- ---------- -------------------- -------------
    8642 sbtwrite2         600 WAITING              rman channel=ORA_SBT_TAPE_1
    8374 sbtwrite2         600 WAITING              rman channel=ORA_SBT_TAPE_2
    
    
  2. ご使用のプラットフォームに適切なオペレーティング・システム・レベルのツールを使用して、ハングアップしたセッションを強制終了します。たとえば、Linuxではkill -9コマンドを実行します。

    % kill -9 8642 8374
    
    

    一部のプラットフォームには、orakillというコマンドライン・ユーティリティが含まれています。このユーティリティを使用すると、特定のスレッドを強制終了できます。コマンド・プロンプトから、次のコマンドを実行します。ここで、sidはターゲットに対するデータベース・インスタンスで、thread_idは手順1の問合せで取得したSPID値です。

    orakill sid thread_id
    
    
  3. メディア・マネージャがプロセスも消去したことを確認します。消去されていないプロセスが存在する場合、次のバックアップ処理またはリストア処理で、以前のハングアップが原因で再度ハングアップする可能性があります。一部のメディア・マネージャでは、この唯一の解決策は、メディア・マネージャを停止して再起動することです。メディア・マネージャのドキュメントに必要な情報が記載されていない場合、メディア・マネージャのテクニカル・サポートに問い合せてください。

    参照:

    関連するコマンドの詳細は、ご使用のオペレーティング・システム固有のドキュメントを参照してください。 


戻る 次へ
Oracle
Copyright © 2003, 2008, Oracle Corporation.

All Rights Reserved.
目次
目次
索引
索引