この付録では、Oracle Grid Infrastructureのインストールに関するトラブルシューティング情報について説明します。
関連項目: ドキュメント・ディレクトリに含まれるOracle Database 12cリリース1 (12.1) Oracle RACのドキュメントを参照してください。
|
この付録の内容は次のとおりです。
Oracleサポートに連絡して問題を報告する必要がある場合は、サービス・リクエストを入力するときに次のガイドラインに従うことをお薦めします。
問題の明確な説明(正確なエラー・メッセージを含む)を提供します。
問題のトラブルシューティングを行うために実行した手順と、この手順の結果の説明を提供します。
影響を受けたソフトウェアの正確なバージョン(メジャー・リリースとパッチ・リリース)を提供します。
Oracleサポートが問題を再現できるように、問題が発生したときに実行した処置の段階ごとの手順を提供します。
問題の影響の評価(影響を受けた最終期限およびコストを含む)を提供します。
スクリーンショット、ログ、Remote Diagnostic Agent (RDA)出力などの関連情報を提供します。
次に、インストール中に発生する可能性のある様々なエラーの例を示します。内容は次のとおりです。
hsi0
(またはeth
)デバイスがARPプロトコルを使用するように、次のコマンドを実行して構成します。
# ifconfig hsi0 arp
su
コマンドを使用して変更している場合(root
ユーザーのコンソール・ディスプレイで低い権限のユーザーがウィンドウを開いている場合など)に起こります。echo $DISPLAY
コマンドを使用して、環境変数に正しいディスプレイ、つまり正しいホストが設定されていることを確認してください。DISPLAY変数が正しく設定されていたら、X Windowを開く権限のあるユーザーでログインしていることを確認するか、またはxhost +
コマンドを実行してすべてのユーザーにX Windowを開く許可を与えてください。
サーバー・コンソール上でroot
としてローカルでログインし、su -コマンドを使用してOracle Grid Infrastructureのインストール所有者に変更した場合は、サーバーからログアウトし、Gridのインストール所有者としてログインしなおしてください。
root.sh
を実行したとき、Oracle Grid Infrastructureのインストールが失敗しました。ローカル・ホスト・エントリがhostsファイルから欠落しているため、Oracle Grid Infrastructureは起動に失敗しました。
Oracle Grid Infrastructureのalert.logファイルには、次のように示されます。
[/oracle/app/grid/bin/orarootagent.bin(11392)]CRS-5823:Could not initialize agent framework. Details at (:CRSAGF00120:) in /oracle/app/grid/log/node01/agent/crsd/orarootagent_root/orarootagent_root.log 2010-10-04 12:46:25.857 [ohasd(2401)]CRS-2765:Resource 'ora.crsd' has failed on server 'node01'.
crsdOUT.log
ファイルを確認し、次を見つけることで、これが原因であることを検証できます。
Unable to resolve address for localhost:2016 ONS runtime exiting Fatal error: eONS: eonsapi.c: Aug 6 2009 02:53:02
xhost
が適切に構成されていない場合か、Xサーバーを起動するためにstartx
コマンドで使用したアカウントとは異なるユーザー・アカウントで実行している場合の、WindowsまたはUNIXシステムに特有のX Window表示エラーです。$ xhost fullyqualifiedRemoteHostname
次に例を示します。
$ xhost somehost.example.com
その後、次のコマンドを入力してください。workstationname
はワークステーションのホスト名またはIPアドレスです。
Bourne、BashまたはKornシェル:
$ DISPLAY=workstationname:0.0
$ export DISPLAY
X Windowアプリケーションがローカル・システムで適切に表示されるかどうかを確認するには、次のコマンドを入力します。
xclockユーティリティをインストールします。xclock
はデフォルトではSolaris 11で使用できません。xclock
は、x11/xclock
パッケージをインストールした後に、/usr/bin/xclock
にあります。
次のコマンドを入力します。
$ xclock
xclock
がモニターに表示されます。xclock
が使用できない場合、これをシステムにインストールし、テストを繰り返します。xclock
がシステムにインストールされているが、ディスプレイ上にxclock
を表示できない場合、xhost
コマンドの使用は制限される可能性があります。
VNCクライアントを使用してサーバーにアクセスしている場合は、インストールに使用しようとしているユーザーに割り当てられているビジュアルにアクセスしていることを確認します。たとえば、su
コマンドを使用して、別のユーザー・ビジュアルでインストール所有者になった場合、xhost
コマンドの使用は制限され、xhost
コマンドを使用して表示を変更することはできません。インストール所有者に割り当てられたビジュアルを使用すると、正しく表示でき、xclock
コマンドの入力によってxclockがディスプレイに表示されます。
xclockが表示されたら、xclockを閉じてインストーラを再度起動します。
/etc/vfstab
ファイル内のNFS用に構成されたオプションが間違っています。
これを確認するには、Grid_home
/log/node
number
/client
パスにあるocrconfig.log
ファイルをチェックし、次の行を検索します。
/u02/app/grid/clusterregistry, ret -1, errno 75, os err string Value too large for defined data type 2007-10-30 11:23:52.101: [ OCROSD][3085960896]utopen:6'': OCR location
/etc/vfstab
ファイル内で指定します。
rw,sync,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768,actimeo=0
注意: マウントの指定にnetdev やvers=2 を含めないでください。netdev オプションを必要とするのは、OCFSファイル・システムを対象とした場合のみであり、vers=2 を指定すると、カーネルによって強制的にNFSがマウントされます(この場合、以前のバージョン2のプロトコルが使用されます)。 |
NFSマウント情報を修正した後にNFSマウント・ポイントを再マウントし、root.sh
スクリプトを再度実行します。たとえば、マウント・ポイント/u02
の場合は次のようになります。
# umount /u02 # mount -a -t nfs # cd $GRID_HOME # sh root.sh
root
に変更されます。この変更により、他のインストールで権限エラーが発生します。また、Oracle Clusterwareソフトウェア・スタックも、Oracleベース・パスの下に配置しないでください。root.sh
コマンドを実行します root.sh
スクリプトの実行が完了する間またはその前に、示されたノードが停止したことが考えられます。root.sh
スクリプトの実行を完了させ、エラー・メッセージに示されたノードではroot
スクリプトを実行しないようにします。計画しているクラスタ・メンバー・ノードのセットのすべてまたは一部でOracle Grid Infrastructureが完了したら、OUIを起動し、エラーに示されたノードで、失敗したOracle Grid Infrastructureのインストールをアンインストールします。そのノードから失敗したインストールをアンインストール後、そのノードを手動でクラスタに追加します。
関連項目: ノードを追加する方法の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
rootupgrade.sh
の実行中に移行障害が発生します。確認するには、ログ・ファイルでエラー「utopen:12:Not enough space in the backing store」を検索してください。Grid_homeはOracle Grid Infrastructureホームのパス、hostnameはサーバーの名前です。Grid_home/log/
hostname/client/ocrconfig_
pid
.log
listener.ora
、Oracleログ・ファイルまたはアクション・スクリプトがNASデバイスまたはNFSマウントに格納されていて、ネーム・サービス・キャッシュ・デーモンnscd
がアクティブになっていない場合に発生します。/sbin/service nscd start
エラー・メッセージの解決に関するその他のヘルプの詳細は、My Oracle Supportを参照してください。たとえば、Doc ID 1367631.1のNoteには、Oracle Grid InfrastructureおよびOracle Clusterwareの最も一般的なインストールの問題の一部が含まれています。
-verbose
引数を使用してクラスタ検証ユーティリティを実行し、特定のノードに対するクラスタ検証ユーティリティ・コマンドの結果がUNKNOWN
になる場合、その原因は、検証時に問題が検出されたかどうかをクラスタ検証ユーティリティで判断できないことにあります。結果が「不明」になる場合の、考えられる原因を次に示します。
ノードが停止している。
クラスタ検証ユーティリティで必要な、オペレーティング・システムの共通コマンド・バイナリが、Oracle Grid Infrastructureホームの/bin
ディレクトリまたはOracleホーム・ディレクトリで不足している。
クラスタ検証ユーティリティを起動したユーザー・アカウントには、ノードでオペレーティング・システムの共通コマンドを実行する権限がない。
ノードで、オペレーティング・システム・パッチ、または必須パッケージが不足している。
ノードの最大プロセス数または最大オープン・ファイル数を超えているか、共有メモリー、セマフォなど、IPCセグメントに問題が発生している。
Oracle Grid Infrastructureをインストールするための要件をシステムが満たしていないことがクラスタ検証ユーティリティのレポートに示された場合は、この項の説明に従ってレポートに示されている問題を解決し、クラスタ検証ユーティリティを再実行します。
失敗したノードと示されている各ノードに対して、ユーザー構成およびSSH構成が正常に完了していることをインストール所有者のユーザー構成で確認してください。Oracle Clusterwareのインストールを実行するユーザーには、SSH接続を作成する権限が必要です。
SSHの構成は、OUIのSSH構成オプションで行うことをお薦めします。手動でSSHの構成を行う場合はインストール前に、インストールのためにSSHが構成済の場合はインストール後に、クラスタ検証ユーティリティを使用できます。
たとえば、ユーザー・アカウントoracle
のユーザー等価関係を確認するには、su - oracle
コマンドを使用し、date
コマンド引数を指定したssh
コマンドを次の構文を使用してローカル・ノードで実行し、ユーザー等価関係を手動で確認します。
$ ssh nodename date
このコマンドによって、nodename
に指定した値で指定されたリモート・ノードのタイムスタンプが出力されます。パスワードを求められた場合、SSHの構成を行う必要があります。デフォルトの場所(/usr/bin
ディレクトリ)にssh
がある場合は、ssh
を使用してユーザー等価関係を構成します。ユーザー等価関係は、rsh
を使用しても確認できます。
SSHを使用してdateコマンドを入力した際に次のメッセージが表示された場合、この問題はユーザー等価関係エラーが原因である可能性があります。
The authenticity of host 'node1 (140.87.152.153)' can't be established. RSA key fingerprint is 7z:ez:e7:f6:f4:f2:4f:8f:9z:79:85:62:20:90:92:z9. Are you sure you want to continue connecting (yes/no)?
「yes」と入力してクラスタ検証ユーティリティを実行し、ユーザー等価関係エラーが解決されたかどうか確認します。
ssh
がデフォルト(/usr/bin
)以外の場所にある場合は、クラスタ検証ユーティリティによって、ユーザー等価関係の検証に失敗したことがレポートされます。このエラーを回避するには、Grid_home
/cv/admin
ディレクトリに移動し、テキスト・エディタでcvu_config
ファイルを開き、ORACLE_SRVM_REMOTESHELL
キーを追加または更新してシステム上のssh
パスの位置を指定します。次に例を示します。
# Locations for ssh and scp commands ORACLE_SRVM_REMOTESHELL=/usr/local/bin/ssh ORACLE_SRVM_REMOTECOPY=/usr/local/bin/scp
cvu_config
ファイルを変更する場合は、次の規則に注意します。
キー・エントリはname=value構文で指定する。
キーに割り当てる各キー・エントリおよび値は適切なものを1のみ定義する。
シャープ記号(#)で始まる行はコメント行であり無視される。
name=value構文が前にない行は無視される。
パス設定の変更後、再度クラスタ検証ユーティリティを実行します。また、ssh
がデフォルト以外の場所にある場合は、リモート・シェルおよびリモート・コピー・コマンドに別の場所を指定するために引数を追加してOUIを起動する必要があります。これらの引数の使用方法の詳細を表示するには、runInstaller -help
を入力してください。
注意: ユーザーまたはOUIがssh またはrsh コマンド(ログインや起動するその他のシェル・スクリプトを含む)を実行し、それらのスクリプトによって出力が行われると、無効な引数または標準の入力に関するエラーが表示されます。これらのエラーの原因を解決する必要があります。
エラーを回避するには、 X11転送についてのメッセージが表示された場合は、第5.2.4項「リモート表示およびX11転送構成の設定」のタスクを完了し、この問題を解決します。 次のようなエラーが出力される場合もあります。 stty: standard input: Invalid argument stty: standard input: Invalid argument これらのエラーは、システム上の隠しファイル( |
/bin/ping
address
コマンドを使用して、各ノードのアドレスを確認してください。到達できないアドレスを発見した場合は、パブリックおよびプライベート・アドレスのリストを確認して、それらを正しく構成してください。他社ベンダーのクラスタウェアを使用する場合に役立つ情報については、そのベンダーのドキュメントを参照してください。パブリック・ネットワーク・インタフェースおよびプライベート・ネットワーク・インタフェースのインタフェース名は、クラスタ内の各ノードで同じである必要があります。id
コマンドを使用して、インストール所有者ユーザー(grid
やoracle
など)が正しいグループ・メンバーシップで作成されていることを確認してください。必要なグループを作成していることを確認し、影響のあるノードでユーザー・アカウントを作成または変更して、必要なグループ・メンバーシップを設定してください。
関連項目: 必要なグループの作成方法およびインストール所有者ユーザーの構成方法については、5.1項「Oracle Grid Infrastructureのグループ、ユーザーおよびパスの作成」を参照してください。 |
深刻なエラーを見つけるには、まずOracle Clusterwareのアラート・ログを見ます。エラーが発生すると、エラーの原因に関する具体的な情報がある診断ログのパス情報が含まれていることがあります。
重要なイベントが発生した場合には、インストール後に、Oracle Clusterwareがアラート・メッセージを書き込みます。たとえば、Cluster Ready Services(CRS)デーモン・プロセスからのアラート・メッセージは、起動時、中断した場合、フェイルオーバー・プロセスが失敗した場合、CRSリソースの自動再起動が失敗した場合に出力されます。
Oracle Enterprise ManagerはClusterwareのログ・ファイルを監視し、エラーが検出されると「クラスタ・ホーム」ページにアラートを書き込みます。たとえば、投票ファイルが利用できない場合はCRS-1604
エラーが発生し、「クラスタ・ホーム」ページにクリティカル・アラートが書き込まれます。「メトリックとポリシー設定」ページで、エラー検出とアラートの設定をカスタマイズできます。
Oracle Clusterwareのログ・ファイルの場所は、CRS_home
/log/
hostname
/alert
hostname
.log
です。CRS_home
はOracle Clusterwareがインストールされたディレクトリ、hostname
はローカル・ノードのホスト名です。
関連項目:
|
インストーラで「ノードの選択」ページが表示されない場合は、次のコマンド構文を使用してクラスタ・マネージャの整合性を検証します。
cluvfy comp clumgr -n node_list -verbose
前述の構文例で、node_list
変数は、クラスタ内のノードのカンマ区切りリストです。
Oracle Grid Infrastructure 11g リリース2 (11.2.0.3)以上では、CVUのhealthcheckコマンド・オプションを使用してOracle ClusterwareおよびOracle Databaseインストールをチェックし、必須要件およびベスト・プラクティス・ガイドラインへの適合性を調べたり、正しく動作していることを確認できます。
次の構文を使用してhealthcheckコマンド・オプションを実行します。
cluvfy comp healthcheck [-collect {cluster|database}] [-db db_unique_name] [-bestpractice|-mandatory] [-deviations] [-html] [-save [-savedir directory_path]
次に例を示します。
$ cd /home/grid/cvu_home/bin $ ./cluvfy comp healthcheck -collect cluster -bestpractice -deviations -html
オプションは次のとおりです。
-collect [cluster|database]
このフラグを使用して、Oracle Clusterware(クラスタ)またはOracle Database(データベース)のチェックを実行することを指定します。healthcheckオプションでcollectフラグを使用しない場合、cluvfy comp healthcheckではOracle ClusterwareとOracle Databaseの両方のチェックが実行されます。
-db
db_unique_name
このフラグを使用して、db
フラグの後に入力した一意のデータベース名に対するチェックを指定します。
CVUでは、JDBCを使用してcvusys
ユーザーとしてデータベースに接続し、様々なデータベース・パラメータが検証されます。このため、-db
フラグで指定したデータベースに対してチェックを実行する場合は、最初にそのデータベースでcvusys
ユーザーを作成し、このユーザーにCVU固有の役割であるcvusapp
を付与する必要があります。cvusapp
の役割のメンバーに、システム表に対するselect
権限を付与する必要もあります。
SQLスクリプトがCVU_home/cv/admin/cvusys.sql
に含まれており、このユーザーの作成を容易にします。このSQLスクリプトを使用して、CVUにより検証するすべてのデータベースでcvusysユーザーを作成します。
db
フラグを使用し、一意のデータベース名を指定しない場合、CVUではクラスタのすべてのOracle Databaseが検出されます。これらのデータベースでベスト・プラクティス・チェックを実行する場合は、各データベースでcvusys
ユーザーを作成し、ベスト・プラクティス・チェックを実行するのに必要なcvusapp
の役割とselect
権限をこのユーザーに付与する必要があります。
[-bestpractice | -mandatory] [-deviations
]
ベスト・プラクティス・チェックを指定するにはbestpractice
フラグを使用し、必須チェックを指定するにはmandatory
フラグを使用します。ベスト・プラクティスの推奨事項または必須要件からの差異のみを確認することを指定するには、deviations
フラグを追加します。-bestpractice
または-mandatory
のいずれかのフラグを指定できますが、両方のフラグを指定することはできません。-bestpractice
または-mandatory
のいずれも指定しない場合は、ベスト・プラクティスと必須要件の両方が表示されます。
-html
html
フラグを使用すると、詳細レポートがHTML形式で生成されます。
html
フラグを指定し、CVUで認識されるブラウザがシステムで使用可能な場合は、チェックの完了時にブラウザが起動されてレポートがブラウザに表示されます。
htmlフラグを指定しない場合、詳細レポートはテキスト・ファイルで生成されます。
-save [-savedir
dir_path
]
検証レポート(cvuchecdkreport_
timestamp
.txt
およびcvucheckreport_
timestamp
.htm
)を保存するには、save
フラグまたは-save -savedir
フラグを使用します(timestamp
は検証レポートの日時)。
save
フラグを単独で使用すると、レポートはパスCVU_home
/cv/report
に保存されます(CVU_home
はCVUバイナリの場所)。
-save -savedir
フラグを使用し、CVUレポートを保存するパスを入力すると、指定したパスにCVUレポートが保存されます。
インターコネクトに複数のネットワーク・インタフェース・カード(NIC)を使用する場合で、それらを冗長インターコネクトを使用してインストール時またはインストール後に構成していない場合は、サード・パーティのソリューションを使用して、オペレーティング・システム・レベルでインタフェースを集約する必要があります。そうしない場合、1つのNICの障害が、クラスタ・ノードの可用性に影響します。
チーミングされたNICカードを使用し、Oracle Clusterware冗長インターコネクト機能を使用する場合、それらのカードは異なるサブネット上に存在する必要があります。サード・パーティ・ベンダーの集約方法(チーミングやIPMPなど)を使用する場合は、そのベンダーの製品に対する指示に従います。
エラーが発生したら、次のシステム検証を実行してください。
スイッチに適切なケーブル(長さやタイプ)やソフトウェアが使用されていることを、ネットワーク・プロバイダに確認してください。場合によっては、負荷によって切断を起こす不具合を回避するため、またはジャンボ・フレームなどの追加機能をサポートするために、インターコネクト・スイッチのファームウェアのアップグレードや、新しいNICドライバ、オペレーティング・システム・レベルの新しいファームウェアが必要になることがあります。こうした修正を行わずに実行すると、初めのインストールは正常に見えても、後でOracle RACデータベースが不安定になることがあります。
ベンダーおよびOracleの推奨事項に従って、VLAN構成、二重化設定、自動ネゴシエーションを確認してください。
Oracle SolarisでIPネットワーク・マルチパス(IPMP)を使用してパブリック・ネットワークまたはプライベート・ネットワーク用に複数のインタフェースを集約する場合は、Oracle Grid Infrastructureのインストール時に、IPMPグループに集約したすべてのインタフェース名を、パブリック・ネットワークまたはプライベート・ネットワークに使用する必要があるインタフェースとして指定する必要があります。
Oracle Grid InfrastructureおよびOracle RACをインストールする場合は、インターコネクトに同じNICカードまたは集約されたNICカードを使用する必要があります。
集約されたNICカードを使用する場合は、それらが同じサブネット上に存在している必要があります。
エラーが発生したら、次のシステム検証を実行してください。
スイッチに適切なケーブル(長さやタイプ)やソフトウェアが使用されていることを、ネットワーク・プロバイダに確認してください。場合によっては、負荷によって切断を起こす不具合を回避するため、またはジャンボ・フレームなどの追加機能をサポートするために、インターコネクト・スイッチのファームウェアのアップグレードや、新しいNICドライバ、オペレーティング・システム・レベルの新しいファームウェアが必要になることがあります。こうした修正を行わずに実行すると、初めのインストールは正常に見えても、後でOracle RACデータベースが不安定になることがあります。
ベンダーおよびOracleの推奨事項に従って、VLAN構成、二重化設定、自動ネゴシエーションを確認してください。
このエラーは、Oracle Solaris 11の構成で発生する可能性があります。
インストール時の最終チェックでSCAN VIPアドレスまたはリスナーに関連するエラーが報告された場合、次の項目をチェックして、ネットワークが正しく構成されていることを確認します。
ファイル/etc/resolv.conf
をチェックして、内容が各ノードで同じであることを確認します。
SCANのDNSエントリが存在しており、SCANが3つの有効なIPアドレスに解決されることを確認します。コマンドnslookup
scan-name
を使用します(このコマンドにより、DNSサーバー名およびSCAN用に構成された3つのIPアドレスが戻されます)。
ping
コマンドを使用して、SCANに割り当てられたIPアドレスをテストします(IPアドレスごとにレスポンスを受信する必要があります)。
注意: クラスタ環境用にDNSが構成されていない場合は、各ノードの/etc/hosts ファイルでSCANのエントリを作成できます。ただし、/etc/hosts ファイルを使用してSCANを解決すると、クラスタ全体で使用可能なSCANは3つではなく1つのみとなります。hosts ファイルにおけるSCAN用の最初のエントリのみが使用されます。 |
パブリック・インタフェースと同じサブネットがSCAN VIPで使用されていることを確認してください。
SCAN、SCAN VIPまたはリスナーに関連するエラーのトラブルシューティングについてさらに支援が必要な場合は、My Oracle Supportを参照してください。たとえば、Doc ID 1373350.1のNoteには、SCAN VIPおよびリスナーの最も一般的な問題の一部が含まれています。
次にストレージ構成の問題を示します。
誤ってファイル・システムを削除したり、Oracle Local Registryを失うことになる別のストレージ構成の問題が発生したり、ノードが破損した場合は、次のいずれかの方法でノードをリカバリできます。
オペレーティング・システム・レベルのバックアップからノードをリストアする(推奨)。
Gridホームの/addnode/addnode.sh
を使用して、ノードを削除した後、ノードを追加する。プロファイル情報はノードにコピーされ、ノードがリストアされます。
addnode.sh
を使用するとクラスタ・ノードを削除して再度追加でき、クラスタ内の残りのノードからリストアできるようになります。GNS構成でノードを追加した場合は、グリッドのプラグ・アンド・プレイ(GPnP)と呼ばれます。GPnPではプロファイルを使用してノードが構成されるため、ノードの構成データ要件がなくなり、明示的にノードを追加したり削除する必要性がなくなります。GPnPによって、システム管理者は、テンプレートのシステム・イメージを取得するだけで、それ以上の構成を行わなくても、新しいノードでそのイメージを実行できます。GPnPにより、多くの手動操作が不要になり、エラーの発生する可能性が減るだけでなく、構成の変更をより簡単に行えるようになります。個々のノードの構成が排除されると、個々の状態をノードで保持して管理する必要がなくなるため、ノードの交換が容易になります。
GPnPにより、ノードの状態が使い捨て可能になることで、データベース・ノードのインストール、構成および管理のコストが削減されます。これによって、再生成された状態でノードを簡単に交換できるようになります。
関連項目: 手動でまたはGNSでノードを追加する方法の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
次の項では、Oracle Grid Infrastructureをアップグレードする場合に発生する可能性のあるエラーとその対処方法について説明します。
$ srvctl modify asm -count ALL
この設定によりカーディナリティが変更されるので、Flex ASMインスタンスはすべてのノードで実行されるようになります。
関連項目: 12cリリース1より前のOracle DatabaseリリースでのOracle ASMの使用可能化の詳細は、第8.3.4項「以前のOracle DatabaseリリースでのOracle ASMの使用可能化」を参照してください。 |
次の項では、スタンドアロン・サーバー(Oracle Restart)用にOracle Grid Infrastructureをダウングレードしたとき発生する可能性があるエラーと、その対処方法について説明します。
ora.asm
リソースにサーバー・パラメータ・ファイル(SPFILE)パラメータが含まれていません。Oracle Restartを12.1.0.2から12.1.0.1にダウングレードするとき、次の手順に従います。
12.1.0.2 Oracle Restartのインストール構成で、Oracle ASMリソース(ora.asm
)からSPFILE
パラメータを問い合せて、それを覚えておきます。
srvctl config asm
リリース12.1.0.2のOracle Restartを構成解除します。
Grid_home/crs/install/roothas.sh -deconfig -force
root.sh
を実行して、リリース12.1.0.1のOracle Restartをインストールします。
$ Grid_home/root.sh
リスナー・リソースを追加します。
$ Grid_home/bin/srvctl add LISTENER
Oracle ASMリソースを追加し、ステップ1で取得した12.1.0.2 Oracle Restartの構成のSPFILE
パラメータを指定します。
$ Grid_home/bin/srvctl add asm
[-spfile <spfile>] [-diskstring <asm_diskstring>])
関連項目: Oracle Restartのインストールと構成解除の詳細は、『Oracle Databaseインストレーション・ガイド』 |
Oracle Grid Infrastructureのインストールまたはアップグレード中に、次のアクションが行われます。
Oracle Universal Installer (OUI)は、システムにOracle Grid Infrastructureソフトウェアを構成するために入力を受け入れます。
orainstRoot.sh
またはroot.sh
スクリプトのいずれか、または両方を実行するよう指示されます。
手動またはルート自動化のいずれかでスクリプトを実行します。
OUIはコンフィギュレーション・アシスタントを実行します。Oracle Grid Infrastructureソフトウェアのインストールが正常に完了します。
root.sh
またはrootupgrade.sh
スクリプトを実行する前にOUIが終了した場合、または、インストールまたはアップグレードのセッションが正常に完了する前にOUIが終了した場合、Oracle Grid Infrastructureのインストールまたはアップグレードは完了していません。インストールまたはアップグレードが完了しない場合、Oracle Clusterwareは正常には機能しません。アップグレードを実行する場合、不完全なアップグレードにより、一部のノードは最新のソフトウェアにアップグレードされ、その他のノードはまったくアップグレードされないことがあります。インストールを実行する場合、不完全なインストールにより、一部のノードがクラスタに参加しないことがあります。
また、Oracle Grid Infrastructureリリース11.2.0.3以上では、インストールまたはアップグレード中に次のメッセージが表示される場合があります。
ACFS-9427: ADVM/ACFSドライバのアンロードに失敗しました。システムの再起動をお薦めします。
ACFS-9428: ADVM/ACFSドライバのロードに失敗しました。システムの再起動をお薦めします。
CLSRSC-400: インストールを続行するにはシステムの再起動が必要です。
このエラーを解決するには、サーバーを再起動し、次の項で説明する不完全なインストールまたはアップグレードを完了する手順を実行します。
アップグレードを開始したノードでOUIが終了する場合、またはrootupgrade.sh
スクリプトがすべてのノードで実行されたことを確認する前にノードが再起動された場合、アップグレードは不完全のままです。アップグレードが不完全な場合でも、コンフィギュレーション・アシスタントを実行し、中央のOracleインベントリで新しいGridホームをアクティブとマークする必要があります。影響のあるノードでは、アップグレードを手動で完了する必要があります。
この項の内容は次のとおりです。
最初のノードをアップグレードできなかった場合は、次の作業を実行します。
rootスクリプトの失敗で、メッセージCLSRSC-400
により再起動が必要であることが示される場合、最初のノード(アップグレードを開始したノード)を再起動します。それ以外の場合は、エラー出力でレポートされているエラー状況を手動で修正するか消去します。そのノードで再度rootupgrade.sh
スクリプトを実行します。
クラスタ内の他のすべてのノードでアップグレードを完了します。
レスポンス・ファイルを構成し、インストール用のパスワードを指定します。レスポンス・ファイルの作成方法の詳細は、第C.5項「レスポンス・ファイルを使用したインストール後の構成」を参照してください。
アップグレードを完了するには、Gridインストール所有者としてログインしてから、Gridhome/cfgtoollogs/configToolAllCommands
のパスにあるスクリプトconfigToolAllCommands
を実行して、作成したレスポンス・ファイルを指定します。たとえば、レスポンス・ファイルがgridinstall.rsp
の場合は次のとおりです。
[grid@node1]$ cd /u01/app/12.1.0/grid/cfgtoollogs [grid@node1]$ ./configToolAllCommands RESPONSE_FILE=gridinstall.rsp
最初のノード(アップグレードを開始したノード)以外のノードで、次の手順を実行します。
rootスクリプトの失敗で、メッセージCLSRSC-400
により再起動が必要であることが示される場合、最初のノード(アップグレードを開始したノード)を再起動します。それ以外の場合は、エラー出力でレポートされているエラー状況を手動で修正するか消去します。
ルート自動化を使用する場合、最初のノードのOUIインスタンスで「再試行」をクリックします。
ルート自動化を使用しない場合、影響のあるノードにroot
としてログインします。ディレクトリをGridホームに変更し、そのノードでrootupgrade.sh
スクリプトを実行します。次に例を示します。
[root@node6]# cd /u01/app/12.1.0/grid [root@node6]# ./rootupgrade.sh
インストールを開始したノードでOUIが終了する場合、またはorainstRoot.sh
またはroot.sh
スクリプトがすべてのノードで実行されたことを確認する前にノードが再起動された場合、インストールは不完全のままです。インストールが不完全な場合でも、コンフィギュレーション・アシスタントを実行し、中央のOracleインベントリで新しいGridホームをアクティブとマークする必要があります。影響のあるノードでは、インストールを手動で完了する必要があります。
この項の内容は次のとおりです。
ローリング・アップグレード・モードでクラスタ・ノードの強制アップグレードを試みた場合に、次のようなエラーが発生することがあります。
crsctl start rollingupgrade
コマンドを使用してローリング・アップグレードのプロセスを再試行できます。最初のノードのインストールは、クラスタ内の他のノードの前に完了している必要があります。最初のノードでの不完全なアップグレードを続行するには、次の手順を実行します。
rootスクリプトの失敗で、メッセージCLSRSC-400
により再起動が必要であることが示される場合、最初のノード(アップグレードを開始したノード)を再起動します。それ以外の場合は、エラー出力でレポートされているエラー状況を手動で修正するか消去します。
必要に応じて、最初のノードにroot
としてログインします。そのノードで再度orainstRoot.sh
スクリプトを実行します。次に例を示します。
$ sudo -s [root@node1]# cd /u01/app/oraInventory [root@node1]# ./orainstRoot.sh
最初のノードでGridホームのディレクトリに移動し、そのノードで再度root
スクリプトを実行します。次に例を示します。
[root@node1]# cd /u01/app/12.1.0/grid [root@node1]# ./root.sh
他のすべてのノードでインストールを実行します。
レスポンス・ファイルを構成し、インストール用のパスワードを指定します。レスポンス・ファイルの作成方法の詳細は、第C.5項「レスポンス・ファイルを使用したインストール後の構成」を参照してください。
インストールを完了するには、Gridインストール所有者としてログインしてから、Gridhome/cfgtoollogs/configToolAllCommands
のパスにあるスクリプトconfigToolAllCommands
を実行して、作成したレスポンス・ファイルを指定します。たとえば、レスポンス・ファイルがgridinstall.rsp
の場合は次のとおりです。
[grid@node1]$ cd /u01/app/12.1.0/grid/cfgtoollogs [grid@node1]$ ./configToolAllCommands RESPONSE_FILE=gridinstall.rsp
最初のノード(インストールを開始したノード)以外のノードで、次の手順を実行します。
rootスクリプトの失敗で、メッセージCLSRSC-400
により再起動が必要であることが示される場合、影響のあるノードを再起動します。それ以外の場合は、エラー出力でレポートされているエラー状況を手動で修正するか消去します。
ルート自動化を使用する場合、最初のノードのOUIインスタンスで「再試行」をクリックします。
ルート自動化を使用しない場合、次の手順を実行します。
影響のあるノードにroot
としてログインし、そのノードでorainstRoot.sh
スクリプトを実行します。次に例を示します。
$ sudo -s [root@node6]# cd /u01/app/oraInventory [root@node6]# ./orainstRoot.sh
ディレクトリをGridホームに変更し、影響のあるノードでroot.sh
スクリプトを実行します。次に例を示します。
[root@node6]# cd /u01/app/12.1.0/grid [root@node6]# ./root.sh
最初のノードのOUIインスタンスからインストールを続行します。