11g リリース1（11.1）
E05700-03
 目次 |
 索引 |
| Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド 11g リリース1（11.1） E05700-03 |
|
この章では、Recovery Managerをトラブルシューティングする方法について説明します。この章では、次の項目について説明します。
Recovery Managerは、問題のトラブルシューティングに役立つ詳細なエラー・メッセージを提供します。また、Oracle Databaseサーバーおよびサード・パーティのメディア・ベンダーは、独自の有効なデバッグ出力を生成します。この項では、発生する可能性がある様々なエラーの識別方法および解釈について説明します。
障害が発生したか、ハングアップしたRecovery Managerジョブのトラブルシューティングに役立つ出力は、次の表に示すとおり、様々な場所に表示または格納されます。
| 出力タイプ | 作成元 | 場所 | 説明 |
|---|---|---|---|
|
Recovery Managerメッセージ |
Recovery Manager |
ジョブの詳細情報は、 Recovery Managerをコマンドラインから実行すると、出力を次の場所に送ることができます。 |
Recovery Managerジョブに関連するアクション、およびRecovery Manager、データベース・サーバー、メディア・ベンダーによって生成されたエラー・メッセージが含まれています。Recovery Managerのエラー・メッセージには、
次のPL/SQLを実行すると、 SYS.DBMS_BACKUP_RESTORE.resetCfileSection(28);
このファンクションでは、すべてのジョブ関連エントリが削除されます。新しいバックアップ・ジョブが |
|
|
Oracle Database |
自動診断リポジトリ・ホームの |
エラー、初期化パラメータ設定および管理操作の時系列のログが含まれています。上書きされた制御ファイル・レコードの値が記録されます。 |
|
Oracleトレース・ファイル |
Oracle Database |
ADRホームの |
Oracleサーバー・プロセスによって生成された詳細な出力が含まれています。このファイルは、 |
|
|
サード・パーティのメディア管理ソフトウェア |
ADRホームの |
メディア管理ソフトウェアによって生成されたベンダー固有の情報が含まれています。このログには、OracleサーバーまたはRecovery Managerのエラーは含まれていません。 |
|
メディア・マネージャのログ・ファイル |
サード・パーティのメディア管理ソフトウェア |
|
メディア管理デバイスの機能に関する情報が含まれています。 |
Recovery Managerは、エラーの発生時にそれらのエラーを通知します。回復不可能なエラーの場合、Recovery Managerは別のチャネルへのフェイルオーバーを実行して特定のジョブ手順を完了することができず、すべてのジョブ・セットの完了後にエラーの概要レポートを出力します。この機能は、遅延エラー・レポートともいいます。
「Recovery Managerのリターン・コードの識別」で説明するように、Recovery Managerにエラーが発生したかどうかを確認する方法の1つは、リターン・コードを調べることです。2つ目の方法は、Recovery Managerの出力内でRMAN-00569文字列を検索することです。RMAN-00569は、エラー・スタック・バナーのメッセージ番号です。すべてのRecovery Managerエラーの前に、このエラー・メッセージが表示されます。出力内にRMAN-00569メッセージが表示されない場合、エラーはありません。次に、構文エラーの例を示します。
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メッセージ・スタックには次のタイプのエラー・コードが含まれています。
表22-2に、一般的なRecovery Managerエラー・メッセージのエラー範囲を示します。すべてのメッセージの詳細は、『Oracle Databaseエラー・メッセージ』を参照してください。
メディア・マネージャ・エラーが発生した場合、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は、オペレーティング・システムを意味します。アスタリスクが付いているエラーは内部エラーであり、通常の操作中に一般的に表示されるものではありません。
Sometimes Recovery Managerエラー・スタック内の役立つメッセージを特定することが困難な場合があります。次のヒントおよび推奨事項を参考にしてください。
「Additional Information:」およびエラー・コード（番号）を含むSBT 1.1形式のエラー・メッセージが表示された場合、その後に続くORA-19511メッセージの、メディア・マネージャによってRecovery Managerに戻されたエラー・メッセージのテキストを確認します。これらのメッセージには、メディア管理レイヤーでの実際の障害が示されます。
RMAN-03002メッセージまたはRMAN-03009メッセージを確認します（RMAN-03009はRMAN-03002と同じですが、RMAN-03009にはチャネルIDが含まれます）。これらのメッセージには、正常に実行されなかったコマンドが示されます。構文エラーの場合、RMAN-00558が生成されます。
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エラーは、サーバー・エラーのためにリカバリ・セッションが取り消されたことを示しています。このデータファイルはリカバリ中ではないため、問題はデータファイルがオンラインであることであり、このファイルをオフラインにしてバックアップをリストアする必要があると判断できます。
テープ・ドライブを使用したバックアップ・ジョブ中に、次の出力が戻されたと想定します。
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
表22-3「メディア・マネージャのエラー・メッセージの範囲」を参照すると、7005エラーが、メディア管理デバイスがビジー状態であることを示していることがわかります。メディア管理ソフトウェアが使用中か、またはそのソフトウェアに問題が発生しているため、そのソフトウェアを使用してデバイスに書き込むことができません。
Recovery Managerにエラーが発生したかどうかを確認する方法の1つは、リターン・コードまたは終了ステータスを調べることです。Recovery Managerクライアントは、そのクライアントが起動されたシェルに、エラーが発生しなかった場合は0（ゼロ）を戻し、エラーが発生した場合は0（ゼロ）以外のエラー値を戻します。
このリターン・コードへのアクセス方法は、Recovery Managerクライアントを起動した環境によって異なります。たとえば、UNIXおよびCシェルを実行している場合、Recovery Managerが完了すると、$statusというシェル変数にリターン・コードが配置されます。終了ステータスを戻す方法は、Recovery Managerクライアントではなくホスト・オペレーティング・システムの詳細によって異なります。
LIST、REPORTおよびSHOWを使用しても、Recovery Managerアクティビティで必要なすべての情報が表示されない場合は、多数のV$ビューで詳細を参照できます。
バックアップおよびリカバリ・ジョブを実行するサーバー・セッションで現在実行されている動作を確認すると有効な場合があります。表22-4に示すビューは、Recovery Managerジョブに関する情報を取得する場合に有効です。
| ビュー | 説明 |
|---|---|
|
|
現在アクティブなプロセスを識別します。 |
|
|
現在アクティブなセッションを識別します。このビューを使用して、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
どのサーバー・セッションがどのRecovery Managerチャネルに対応しているかを確認するには、V$SESSIONおよびV$PROCESSを問い合せます。V$PROCESSのSPID列に、オペレーティング・システムのプロセスまたはスレッドのID番号が示されます。たとえば、UNIXではSPID列にプロセスIDが表示され、WindowsではSPID列にスレッドIDが表示されます。この情報を取得するには、複数のRecovery Managerセッションが同時にアクティブになっているかどうかに応じて、2つの基本的な方法があります。
アクティブな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セッションが複数の場合、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出力からsid値を取得して、その値をSQL問合せで使用する必要があります。
sidを取得します。たとえば、次の出力が表示される場合があります。
Starting backup at 21-AUG-01allocated channel: ORA_SBT_TAPE_1channel ORA_SBT_TAPE_1: sid=14 devtype=SBT_TAPE
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
この方法では、Recovery Managerバックアップ・スクリプトでコマンド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;}
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を含む行に、バックアップを実行中のチャネルが表示されます。残りの行には、ターゲット・データベースへの接続が表示されます。
一部のプラットフォームでは、Oracleによってsbttestという診断ツールが提供されます。このユーティリティは、Oracle Databaseサーバーと同様にメディア・マネージャとの通信を試行して、メディア管理ソフトウェアの簡単なテストを実行します。
UNIX上では、sbttestユーティリティは、通常$ORACLE_HOME/binに存在します。なんらかの理由でプラットフォームにこのユーティリティが存在しない場合、Oracleサポート・サービスからこのプログラムのCバージョンを入手してください。このバージョンのsbttestプログラムは、すべての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
プログラムが操作可能の場合、オンライン・ドキュメントが表示されます。
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を実行可能でも、Recovery Managerバックアップを実行できない場合があります。次のような理由が考えられます。
sbttestを実行したユーザーがOracleプロセスの所有者ではない。
sbttestは機能しますが、メディア・マネージャに対するRecovery Managerによるバックアップは失敗します。
sbttestプログラムはシェルからすべての環境変数を渡しているが、Recovery Managerは渡していない。
実行中のRecovery Managerコマンドは、次の複数の方法で終了できます。
ALTER SYSTEM KILL SESSION文を実行すると、Recovery Managerチャネルに対応するサーバー・セッションを強制終了できます。
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を終了する最も適切な方法は、メディア・マネージャ内のセッションを強制終了することです。この操作で問題が解決しない場合、UNIXなどの一部のプラットフォームでは、接続を行っているOracleプロセスを強制終了できる場合があります。（Oracleプロセスを強制終了すると、メディア・マネージャに問題が発生する場合があることに注意してください。詳細は、ご使用のメディア・マネージャのドキュメントを参照してください。）
Recovery Managerセッションの特性は、オペレーティング・システムに応じて異なります。UNIXでは、Recovery Managerセッションには次のプロセスが関連付けられています。
DUPLICATE操作またはTSPITR操作中は、補助インスタンスへの補助接続。
ALLOCATE CHANNELコマンドまたはCONFIGURE CHANNELコマンドに異なる接続文字列を使用すると、Recovery Managerは追加のポーリング接続を確立します。ポーリング接続は、ALLOCATE CHANNELコマンドまたはCONFIGURE CHANNELコマンドに使用した各接続文字列に1つ存在します。
Recovery Managerがハングアップする理由は、通常、チャネル接続の1つが、メディア・マネージャ・コードでテープ・リソースが使用可能になるまで待機するためです。カタログ接続およびデフォルト・チャネルがハングアップしているように見えるのは、Recovery Managerからの指示を待機しているためです。ポーリング接続は、Recovery Managerプロセスの制御下でRPCをポーリングする間は無限にループしているように見えます。
Recovery Managerプロセス自体を強制終了すると、カタログ接続、補助接続、デフォルト・チャネルおよびポーリング接続が切断されます。メディア・マネージャ・コードでハングアップしていないターゲット接続および補助接続も切断されます。メディア管理レイヤーで実行しているターゲット接続か補助接続のいずれかは切断されません。これらのプロセスを終了するには、オペレーティング・システム・レベルで手動で強制終了する必要があります。
すべてのメディア・マネージャがOracleプロセスの終了を検出できるわけではありません。終了を検出しないメディア・マネージャは、リソースをビジー状態のままにしたり、処理を継続する場合があります。詳細は、ご使用のメディア・マネージャのドキュメントを参照してください。
カタログ接続を切断しても、Recovery Managerプロセスは終了されません。これは、Recovery Managerは、バックアップまたはリストアの実行中にはカタログ操作を実行しないためです。デフォルト・チャネルおよびポーリング接続を削除すると、Recovery Managerプロセスはチャネルの1つが終了したことを検出し、終了処理を実行します。この場合、前述のとおり、ハングアップしたチャネルへの接続はアクティブのままです。
メディア・マネージャ・コードでハングアップしたチャネルが強制終了されると、Recovery Managerプロセスはその終了を検出し、終了処理を実行します。その際、メディア管理レイヤーで実行可能なターゲット接続を除く、すべての接続を削除します。この場合にも、メディア・マネージャ・リソースに関する警告が当てはまります。
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
kill -9コマンドを実行します。
% kill -9 8642 8374
一部のプラットフォームには、orakillというコマンドライン・ユーティリティが含まれています。このユーティリティを使用すると、特定のスレッドを強制終了できます。コマンド・プロンプトから、次のコマンドを実行します。ここで、sidはターゲットに対するデータベース・インスタンスで、thread_idは手順1の問合せで取得したSPID値です。
orakill sid thread_id
|
 Copyright © 2003, 2008, Oracle Corporation. All Rights Reserved. |
|