制御ファイルのスイッチオーバの失敗

$ORACLE_HOME ディレクトリが回復されない場合、データベース制御ファイルが正しくセットアップされていない可能性があります。自動スイッチオーバの場合は、データベースの作成中に制御ファイルを共有デバイス上に設定する必要があります。制御ファイルを別々のサーバに置く場合は、変更が必要になったときに両方のサーバを手動でアップデートする必要があります。

出力の打ち切り

Oracle の一部のバージョンでは、show parameters control_files を sqldba モードで実行するときに、出力が打ち切られることがあります。使用している Oracle のバージョンがそのような動作をする場合は、以下の点を確認してください。

  • controlfile パラメータ。パラメータが、$Oracle_HOME/dbs/init#SID.ora ファイルにあることを確認します。
  • controlfile デバイス。controlfile デバイスが、新規行ではなく、継続行で指定され、各デバイスがコンマで区切られていることを確認します。

Oracle 関連のデバイスが正しく設定されていない場合は、LifeKeeper Application 管理の下で利用可能なファイルシステムアプリケーションを使用して、手動で設定できます。

共有ドライブ上に配置された Flash Recovery Destination

構成のセクションでも記載されているように、Flash Recovery destination が、共有ドライブ上に配置されていることが重要です。Flash Recovery Area がどこに配置されているかを確認する場合は、SYSDBA として以下のクエリーを発行してください。

SQL> SELECT substr(Name,1,30) Name, 
  (SPACE_LIMIT/1024/1024/1024) Space_Limit_GB,
       SPACE_USED/1024/1024/1024 Space_Used_GB,
       SPACE_RECLAIMABLE, NUMBER_OF_FILES
FROM V$RECOVERY_FILE_DEST;
 
NAME               SPACE_LIMIT_GB SPACE_USED_GB SPACE_RECLAIMABLE
------------------ -------------- ------------- -----------------
NUMBER_OF_FILES
---------------
/U01/flash_recovery_area    3.76171875    .156448364           0
              4

下記は、このタスクを完了させるために、 $ORACLE_HOME/dbs/spfile<sid> に変更を行う場合の例です。

SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='/oracledb/oracle/flash_recovery_area' scope=both; 
System altered.
SQL> show parameter DB_RECOVERY_FILE_DEST;
NAME                        TYPE        VALUE
----------------------------------------------------------------------
db_recovery_file_dest       string      /oracledb/oracle/flash_recovery_area
db_recovery_file_dest_size  big integer 2G
SQL> commit;

データベースに接続できない場合のフェイルオーバの回避

リソースのヘルスチェックの実行時に、Oracle ARK は実行中のデータベースプロセスをチェックし、データベースへの接続を試行します。最大許容接続に達したことで生じるヘルスチェック障害を回避するには、 /etc/default/LifeKeeper で以下を設定します。

LK_ORA_NICE=1

注記: LK_ORA_NICE を設定することで、非稼働データベースによって生じる他のタイプの接続エラーをマスクできます。この設定を使用する場合は、注意してください。

oratab の非伝統的な場所

デフォルトでは、Oracle ARKoratab ファイルをまず /etc で検索した後、 /var/opt/oracle でこのファイルを検索します。このいずれかのデフォルトの場所に oratab ファイルがない場合は、ORACLE_ORATABLOC/etc/default/LifeKeeperoratab. が含まれるディレクトリに設定する必要があります。

サポートされていない NFS バージョン 4

Oracle Recovery Kit は共有データベースストレージで NFSv3 をサポートしています。現時点では、NFSv4 のファイルロックメカニズムにより NFSv4 はサポートされていません。

ローカルストレージでの Oracle バイナリのインストール後の Oracle データベース階層の作成

各 LifeKeeper クラスタノードのローカルストレージに Oracle バイナリ ($ORACLE_BASE) をインストールした場合、LifeKeeper GUI で Oracle データベース階層の作成時に以下のようなメッセージが表示されます。

BEGIN create of <SID> on server <server1(サーバ server1 でSID の作成を開始)>
Creating resource instance <SID> on server <server1(サーバ server1 でリソースインスタンス SID を作成)>
Setting resource state for <SID> on server <server1> to "ISP".(サーバ server1 で SID のリソース状態を「ISP」に設定)

ORACLE_HOME「/opt/oracle/app/oracle/product/11.2.0/dbhome_1」が共有ファイルシステムにありません。ORACLE_HOME ディレクトリおよび関連ファイルがすべてのサーバで同じであるか確認してください。詳細については、LifeKeeper Oracle Recovery Kit のドキュメントを参照してください。
Creating dependent file system resource "/u00" on <server1>.(server1 で依存ファイルシステムリソース「/u00」を作成)
Creating dependency between Oracle database "SID (SID)" and the dependent resource "/u00" on <server1>.(server1 で Oracle データベース「SID(SID)」と依存リソース「/u00」間の依存関係を作成)
Creating dependency between Oracle database "SID (SID)" and the listener resource "LSNR.LISTENER" on <server1>.(server1 で Oracle データベース「SID(SID)とリスナーリソース「LSNR.LISTENER」間の依存関係を作成)
Performing in-service of new Oracle resource tag=< SID > on <server1>.(server1 で新しい Oracle リソースタグ=SID の In Service を実行)
END successful create of <SID> on server <server1(サーバ server1 で SID の作成が正常終了)>

また、LifeKeeper ログにも似たような警告が示されます。この警告が不要で、階層を拡張して作業を続行した後、データベースリソースを別のノードで In Service にしようとした場合、[LifeKeeper GUI] ダイアログに以下のようなメッセージが表示されます。

Put resource "OST" in-service(リソース「OST」を In Service にする)
BEGIN restore of "OST" on server "cae-qa-v39"(サーバ「cae-qa-v39」で「OST」のリストアを開始)
Begin the "start [ start.normal ]" of the database "OST" on "cae-qa-v39".(「cae-qa-v39」でデータベース「OST」の「start[start.normal]」を開始)
The "start [ start.normal ]" attempt of the database "OST" appears to have failed on "cae-qa-v39".(「cae-qa-v39」でデータベース「OST」の「start [start.normal]」試行が失敗したようです)
ORA-01078: failure in processing system parameters(ORA-01078: システムパラメータの処理障害)
LRM-00109: could not open parameter file ‘/opt/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/initOST.ora’(LRM-00109: パラメータファイル「/opt/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/initOST.ora」を開くことができませんでした)
Begin the "start [ start.force ]" of the database "OST" on "cae-qa-v39".(「cae-qa-v39」でデータベース「OST」の「start[start.force]」を開始)
The "start [ start.force ]" attempt of the database "OST" appears to have failed on "cae-qa-v39".(「cae-qa-v39」でデータベース「OST」の「start [start.force]」試行が失敗したようです)
select ‘alter database datafile ‘||file#||’ end backup;’ from v\$backup where status = ‘ACTIVE’(ステータス=「ACTIVE」の v\$backup から「alter database datafile ‘||file#||’ end backup;」を選択してください)

また、ダイアログボックスに以下のようなメッセージが表示されることもあります。

Put resource "OST" in-service(リソース「OST」を In Service にする)
BEGIN restore of "OST" on server "cae-qa-v39"(サーバ「cae-qa-v39」で「OST」のリストアを開始)
Begin the "start [ start.normal ]" of the database "OST" on "cae-qa-v39".(「cae-qa-v39」でデータベース「OST」の「start[start.normal]」を開始)
122528 Initial inspection of "COMMAND" failed, verifying failure or success of received output.」(122528 「COMMAND」の初期点検が失敗し、受信出力の成否を検証できませんでした)
Logon failed with "" for "OST" on "cae-qa-v39".(「cae-qa-v39」の「OST」で「」でログオンが失敗しました)Please check username/password and privileges.(ユーザ名 / パスワードおよび権限をチェックしてください)
The "start [ start.normal ]" attempt of the database "OST" appears to have failed on "cae-qa-v39".(「cae-qa-v39」でデータベース「OST」の「start [start.normal]」試行が失敗したようです)
ERROR:(エラー: )

ORA-01031: insufficient privileges(ORA-01031: 不十分な権限)

Enter password:(パスワードを入力してください: )

ERROR:(エラー: )

ORA-01005: null password given; logon denied(ORA-01005: null パスワードが返されました。ログオンが拒否されます)

この問題を解決するには、 $ORACLE_BASE/admin をデータベースインスタンスが作成されたプライマリシステムからバックアップシステム(階層が拡張された場所)の $ORACLE_BASE/admin にコピーしてください。また、このディレクトリの所有権を Oracle ユーザ名および Oracle グループ(通常 oracle:oinstall)に変更してください。

また、すべての *{$ORACLE_SID}*(この例では OST)ファイルをプライマリファイルの $ORACLE_BASE/product/11.2.0/dbhome_1/dbsからバックアップシステムの ORACLE_BASE/product/11.2.0/dbhome_1/dbs にコピーしてください。

例えば、これらはプライマリシステムからバックアップへコピーされたファイルであり、ORACLE SIDOST であるとします。

-rw-r——- 1 oracle oinstall 1544 2012-05-09 11:02 hc_OST.dat
-rw-r——- 1 oracle oinstall 24 2012-01-31 10:22 lkOST
-rw-r——- 1 oracle oinstall 1536 2012-03-05 09:02 orapwOST
-rw-r——- 1 oracle oinstall 2560 2012-05-09 10:58
spfileOST.ora

SID が ORA01 のもう 1 つの例では、以下のファイルがコピーされます。

-rw-r——- 1 oracle oinstall 1536 2010-09-08 18:25 orapwORA01
-rw-r——- 1 oracle oinstall 24 2010-09-08 18:25 lkORA01
-rw-r——- 1 oracle oinstall 2560 2010-09-08 18:30 spfileORA01.ora
-rw-r——- 1 oracle oinstall 1544 2010-09-08 18:30
hc_ORA01.dat

およびディレクトリ

peshm_ORA01_0/:

フェイルオーバ後も Oracle リスナーがプライマリサーバ上で稼動したままになる

ネットワーク障害に起因した Oracle アプリケーションのフェイルオーバ後に、プライマリサーバ上でリスナー・プロセスが稼動し続けることがあります。

フィードバック

お役に立ちましたか?

はい いいえ
お役に立ちましたか
理由をお聞かせください
フィードバックありがとうございました

このトピックへフィードバック

送信