10g リリース3（10.2.0.3.0）
E05063-01
 目次 |
 索引 |
| Oracle Enterprise Manager Grid Controlインストレーションおよび基本構成 10g リリース3（10.2.0.3.0） E05063-01 |
|
この付録では、Enterprise Managerのインストールまたはアップグレード時に発生する可能性のある一般的な問題の解決方法とシナリオを説明します。
この項では、インストール時に最も一般的に発生する問題とその解決方法を示します。
Grid Controlをインストールするシステム上で実行している、/tmp/ディレクトリをクリーンアップする日次のcronジョブが存在する場合、インストールが異常終了して失敗する可能性があります。その場合、installActions.errファイルにjava.lang.UnsatisfiedLinkError: no nio in java.library.pathのエラーが記録されます。
この対処方法として、TMPおよびTEMP環境変数をデフォルトの/tmp以外のディレクトリに設定し、./runInstallerを実行します。
Microsoft Windows環境では、PERL5LIB環境変数がすでに存在する場合、この変数はEnterprise Manager Grid Controlインストールによって強制的に上書きされます。その結果、このホスト上の他のアプリケーションは、管理サービスのインストール中にインストールされる新しいバージョンのPerlの使用を余儀なくされます。
この問題を回避するには、管理サービスのインストールを開始する前に既存のPerl変数の名前をPERL5LIB_TMPに変更します。PERL5LIB_TMP変数は、後で（インストールの完了後に）PERL5LIBに変更できます。
管理エージェントのインストールに失敗した場合、emctl statusログを調べ、インストールの失敗の理由を診断します。このログを参照するには、次のコマンドを実行します。
<AGENT_HOME>/bin/emctl status agent
サンプルのログ・ファイルを次に示します。いくつかの一般的な問題を太字で示しています。
Oracle Enterprise Manager 10g Release 10.2.0.0.0. Copyright (c) 1996, 2005 Oracle Corporation. All rights reserved. --------------------------------------------------------------- Agent Version : 10.2.0.2.0OMS Version : 10.2.0.2.0Protocol Version : 10.2.0.2.0 Agent Home : /scratch/OracleHomes2/agent10g Agent binaries : /scratch/OracleHomes2/agent10g Agent Process ID : 9985 Parent Process ID : 29893Agent URL : https://foo.abc.com:1831/emd/main/Repository URL : https://foo.abc.com:1159/em/uploadStarted at : 2005-09-25 21:31:00 Started by user : pjohn Last Reload : 2005-09-25 21:31:00
Last successful upload : (none)Last attempted upload : (none) Total Megabytes of XML files uploaded so far : 0.00 Number of XML files pending upload : 2434 Size of XML files pending upload(MB) : 21.31 Available disk space on upload filesystem : 17.78% Last attempted heartbeat to OMS : 2005-09-26 02:40:40 Last successful heartbeat to OMS : unknown ---------------------------------------------------------------Agent is Running and Ready
エージェントの配置を使用したエージェントのインストール中、インストールが突然失敗し、「失敗」ページが表示されます。「再試行」をクリックすると、前提条件チェック・フェーズでインストールが再度失敗し、ディレクトリが空でないことを伝えるエラーが表示されます。
これは、SSH接続がリモート・ホスト上で切断されているにもかかわらず、Oracle Universal Installer（OUI）がまだ実行中であることが原因と考えられます。
この問題を解決するには、リモート・ホスト上で、OUIがまだ実行中であるかどうかを確認します。これを確認するには、次のコマンドを実行します。
ps -aef | grep -i ora
OUIがまだ実行中の場合は、OUIプロセスが完了するまで待ってからSSHデーモンを再起動します。その後、「再試行」をクリックして、インストールを実行します。
インストール・プロセス中にSSH接続が切断されたためにOracle RAC 10gリリース2（10.2）クラスタ上でのエージェントの配置に失敗する場合があります。
これは、sshd_configファイルのLoginGraceTime値が0（ゼロ）である場合に発生する可能性があります。値をゼロにすると、SSH認証の時間が無期限になります。
この問題を解決するには、/etc/ssh/sshd_configファイルのLoginGraceTime値をゼロより高い値に変更します。デフォルト値は120秒です。これは、ログインに失敗した場合に、ここで指定した時間が経過した後サーバーとの接続が切断されることを意味します。
この問題を解決するには、/etc/ssh/sshd_configファイルのLoginGraceTime値をゼロより高い値に変更します。値が0（ゼロ）に設定されている場合、認証の時間制限がなくなります。
SSHユーザー等価の検証の失敗の最も一般的な理由には、次のものがあります。
/etc/sshd/sshd_configファイルのサーバー設定で、ユーザー$USERのsshが許可されていない。
-sharedオプションを渡していないか、または、このオプションを非共有リモート・ユーザーに渡した可能性がある。
サーバー設定を確認し、次のスクリプトを再実行してSSHユーザー等価を設定します。
次に、サンプルのsshd_configファイル（サーバー側の構成ファイル）とその変数のすべてを示します。
#$OpenBSD: sshd_config,v 1.59 2002/09/25 11:17:16 markus Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default values where # possible, but leave them commented out. Uncommented options change a # default value. #Port 22 #Protocol 2,1 #ListenAddress 0.0.0.0 #ListenAddress :: # HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key # Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 3600 #ServerKeyBits 768 # Logging #obsoletes QuietMode #SyslogFacility AUTH SyslogFacility AUTHPRIV #LogLevel INFO # Authentication: #LoginGraceTime 120 #PermitRootLogin yes #StrictModes yes #RSAAuthentication yes #PubkeyAuthentication yes #AuthorizedKeysFile.ssh/authorized_keys # rhosts authentication should not be used #RhostsAuthentication no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication #IgnoreUserKnownHosts no # To disable tunneled clear text passwords, change to no here! #PasswordAuthentication yes #PermitEmptyPasswords no # Change to no to disable s/key passwords #ChallengeResponseAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #AFSTokenPassing no # Kerberos TGT Passing only works with the AFS kaserver #KerberosTgtPassing no # Set this to 'yes' to enable PAM keyboard-interactive authentication # Warning: enabling this may bypass the setting of 'PasswordAuthentication' #PAMAuthenticationViaKbdInt no #X11Forwarding no X11Forwarding yes #X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes #KeepAlive yes #UseLogin no #UsePrivilegeSeparation yes #PermitUserEnvironment no #Compression yes #MaxStartups 10 # no default banner path #Banner /some/path #VerifyReverseMapping no #ShowPatchLevel no # override default of no subsystems Subsystemsftp/usr/libexec/openssh/sftp-server
SSHユーザー等価スクリプトは、実行時に次のコマンドを実行して、終了時に設定を自動的に検証するように構築されています。
ssh -l <user> <remotemachine> 'date'
検証時には、SSH設定が正常でないことを示す無効なポート・エラーが発生する可能性があります。
これは、ssh.exe（sshUserSetupNT.shスクリプト）がcygwinホーム・ディレクトリから起動されていない場合に発生する可能性があります。
この問題を解決するには、ローカルOMSマシン上のsshUserSetupNT.shスクリプトをcygwin（BASH）シェル内からのみ実行します。この場所以外から実行すると、このスクリプトは失敗します。
Cygwinが複数インストールされているために、起動するssh.exeを探す必要がある場合は、次のコマンドを実行します。
C:¥Cygwin¥bin¥which ssh
このコマンドを例として実行すると、次のような結果が返されます。
¥cygdrive¥c¥WINDOWS¥ssh
これは、PATH環境変数においてC:¥Cygwin¥binより前にC:¥windowsがあるため、Cygwinのssh.exeファイルが起動されないことを示しています。
この問題を解決するには、このssh.exeの名前を次のように変更します。
-C:¥cygwin>move c:¥WINDOWS¥ssh.exe c:¥WINDOWS¥ssh.exe1 1 file(s) moved.
この後で、C:¥Cygwin which sshコマンドを再実行します。
この結果は、¥usr¥bin¥sshのようになります。
これにより、ssh.exeファイルが正しい場所（つまり、C:¥Cygwin¥binフォルダ）から起動されることが確認されます。
Cygwinバージョン5.2でsshConnectivity.shスクリプトを実行すると、スクリプトが失敗し、次のエラーが発生する可能性があります。
"JAVA.LANG.NOCLASSDEFFOUNDERROR"
この問題を回避するには、CygwinスタイルのパスのOracleホームが次のように定義されていることを確認します。
ORACLE_HOME="c:/oraclehomes/oms10g/oracle"
現在インストールされているCygwinのバージョンを確認するには、Cygwinウィンドウでunameコマンドを実行します。
SSHデーモンの設定時に、コマンドcygrunsrvが見つからないというエラーが発生することがあります。この問題は、次のいずれかの理由により発生する可能性があります。
sshdサービスを作成してから、この新しいsshdサービスをcygwinディレクトリから起動します。
SSHDサービスを作成するには、次のコマンドを実行する必要があります。
ssh-host-config
このコマンドの実行時に実行されるCygwinスクリプトにより、複数の質問に回答するよう求められます。次の質問に対してyesを指定します。
ローカル・ユーザーsshdを作成するかどうかを問う質問に対してはnoを指定します。
Cygwinの値を指定するよう求められた場合は、ntsec（CYGWIN="binmode tty ntsec"）と入力します。
これで、SSHDサービスが作成されるため、次のコマンドを実行してこのサービスを起動できます。
cygrunsrv -start sshd
SSHDサービスを再起動してもエラーが解決されない場合、Cygwinを再インストールする必要があります。この手順は、次のとおりです。
regeditを使用して「Cygnus Solutions」の下位にあるキーおよびサブキーを削除します。
C:¥cygwin）と、すべてのCygwinアイコンを削除します。
.sshディレクトリを削除します。
Cygwinのインストール方法の詳細は、C.1.2.3項「Microsoft WindowsでのSSHサーバー（SSHD）の設定」を参照してください。
cygrunsrv -start sshd
SSH設定を終了すると、次の検証コマンドが自動的に実行されます。
ssh -l <user> <remotemachine> 'date'
このコマンドによって、「ソケットからの読取りに失敗しました。接続はピアによってリセットされました。」というエラーが返された場合は、SSHが正しく設定されていないことを示します。この問題を解決するには、ユーザー等価を設定しようとしたリモート・マシンに移動し、次の手順を実行します。
cygrunsrv -stop sshd）。
etcディレクトリに移動します（cd /etc）。
chown <SYSTEM> ssh*）。
chmod 644 /etc/ssh* chmod 755 /var/empty chmod 644 /var/log/sshd.log
ssh -l <user> <remote machine> 'date'）。これにより、日付が正しく表示され、SSH設定が成功したことが示されます。
/usr/bin/sshdまたはcygrunsrv -start sshdを実行して、SSHDサービスを起動します。
ssh -l <user> <remote machine> 'date'）。これにより、日付が正しく表示され、SSH設定が成功したことが示されます。
SSHDを構成すると、SSHDサービスがローカル・アカウントに対してデフォルトで作成されます。ドメイン・ユーザーとしてログインしても、このアカウントがSSHDサービスによって認識されず、使用し始めることができません。
この問題を解決するには、SSHDサービスのLog On As値をLocalSystemからドメイン・ユーザーに変更する必要があります。これを行うには、次の手順を実行します。
domain¥userの形式。例: FOO-US¥pjohn）。
chmod 644 /etc/ssh* chmod 755 /var/empty chmod 644 /var/log/sshd.log
/usr/sbin/sshd
TZ環境変数がリモート・ホストのSSHデーモンで設定されていない場合、タイムゾーン前提条件チェック（timezone_check）は失敗します。
この問題を解決するには、リモート・ホストのSSHデーモンでTZ環境変数を設定する必要があります。詳細は、C.1.2.5項「リモート・ホスト上のタイムゾーン変数の設定」を参照してください。
または、次の操作を実行します。
-z <timezone> For example, -z PST8PDT
s_timeZone=<timezone> For example, s_timezone=PST8PDT
OMSバージョンがログ・ファイルに表示されない場合、インストールされたエージェントが、ロックされたセキュアな管理サービス（OMS）に登録されていないことを意味します。
これを確認するには、次のコマンドを実行します。
emctl status oms emctl status agent
この問題を解決するには、次のコマンドを実行して管理エージェントを手動で保護する必要があります。
<AGENT_HOME>/bin/emctl secure agent -reg_passwd <password>
エージェントのインストールに成功した場合、エージェントとリポジトリのURLのプロトコルは同じになります。つまり、両方のURLが、httpsプロトコル（両方とも保護されていることを示す）で始まることになります。
エージェントのURLのプロトコルが、httpsではなくhttpとして表示される場合、このエージェントは保護されていないことを意味します。
この問題を解決するには、次のコマンドを実行してエージェントを手動で保護する必要があります。
<AGENT_HOME>/bin/emctl secure agent -reg_passwd <password>
ログで、このパラメータに対するタイムスタンプが存在しない（NULLと表示）場合、エージェントがいずれのデータのアップロードもできないことを意味します。
この問題を解決するには、次のコマンドを実行してデータを手動でアップロードしてから、ログを再確認します。
<AGENT_HOME>/bin emctl upload
エージェントの準備ができていず、動作していない場合、emctl statusログには、著作権情報のみが表示されます。サンプル・ログに表示されているいずれのパラメータも表示されません。
この問題は、次の理由により発生する可能性があります。
<AGENT_HOME>/bin emctl secure agent -reg_passwd <password>
<AGENT_HOME>/bin emctl start agent
sysman/config/emd.propertiesファイルを調べます。また、emd.propertiesファイルで次の値が正しく設定されていることを確認する必要もあります。
この項では、構成時に最も一般的に発生する問題とその解決方法を示します。
インストール中、いずれかのコンフィギュレーション・アシスタントの実行に失敗した場合は、コンフィギュレーション・アシスタントをスタンドアロン・モードで実行するよう選択できます。
|
注意 各構成ツールの個別のログ・ファイルは、次のディレクトリ内にあります。 ORACLE_HOME/cfgtoollogs/cfgfw
このディレクトリには、個々の構成ログに加えて 作成されるインストール・ログおよびその場所の詳細は、付録A「Enterprise Managerのトラブルシューティング」を参照してください。 また、3.4項「コマンドラインからのrunConfigツールの実行」も参照して、runConfigツールの使用方法を理解してください。このツールは、次の説明に従ってコンフィギュレーション・アシスタントを実行するために使用します。 |
インストール・プロセス中、このコンフィギュレーション・アシスタントは、管理サービスのコンフィギュレーション・アシスタントが起動される前に実行されます。
このコンフィギュレーション・アシスタントは、Enterprise Manager 10gリリース2のインストールに必要な個別パッチを適用します。
このコンフィギュレーション・アシスタントをスタンドアロン・モードで実行するには、管理サービスのOracleホームから次のコマンドを実行する必要があります。
<OMS_HOME>/perl/bin/perl <OMS_HOME>/install/oneoffs/applyOneoffs.pl
データベース・コンフィギュレーション・アシスタントを実行するには、次のようにrunConfig.shを起動する必要があります。
<DB_Home>/oui/bin/runConfig.sh ORACLE_HOME=<DB_HOME> ACTION=Configure MODE=Perform
Microsoft Windowsの場合、前述のコマンドのrunConfig.shをrunConfig.batに読み替えます。
OMSコンフィギュレーション・アシスタントを実行するには、次のようにrunConfig.shを起動する必要があります。
<OMS_Home>/oui/bin/runConfig.sh ORACLE_HOME=<OMS_HOME> ACTION=Configure MODE=Perform
Microsoft Windowsの場合、前述のコマンドのrunConfig.shをrunConfig.batに読み替えます。
エージェント・コンフィギュレーション・アシスタントを実行するには、次のようにrunConfig.shを起動する必要があります。
<Agent_Home>/oui/bin/runConfig.sh ORACLE_HOME=<AGENT_HOME> ACTION=Configure MODE=Perform
Microsoft Windowsの場合、前述のコマンドのrunConfig.shをrunConfig.batに読み替えます。
|
注意
前述のコマンドは、 Agent_Home/bin/agentca -f
Oracle RACで Agent_Home/bin/agentca -f -c "node1,node2,node3,...." 詳細は、7.5項「エージェントの再構成および再検出」を参照してください。 |
ルール・マネージャのみを配置する場合は、次のコマンドを実行します。
/scratch/OracleHomes/oms10g/jdk/bin/java -Xmx512M -DemLocOverride=/scratch/OracleHomes/oms10g -classpath /scratch/OracleHomes/oms10g/dcm/lib/dcm.jar:/scratch/OracleHomes/oms10g/jlib/e mConfigInstall.jar:/scratch/OracleHomes/oms10g/lib/classes12.zip:/scratch/Orac leHomes/oms10g/lib/dms.jar:/scratch/OracleHomes/oms10g/j2ee/home/oc4j.jar:/scr atch/OracleHomes/oms10g/lib/xschema.jar:/scratch/OracleHomes/oms10g/lib/xmlpar serv2.jar:/scratch/OracleHomes/oms10g/opmn/lib/ons.jar:/scratch/OracleHomes/om s10g/dcm/lib/oc4j_deploy_tools.jar oracle.j2ee.tools.deploy.Oc4jDeploy -oraclehome /scratch/OracleHomes/oms10g -verbose -inifile /scratch/OracleHomes/oms10g/j2ee/deploy.master -redeploy
Microsoft Windowsの場合、前述のコマンドのrunConfig.shをrunConfig.batに読み替えます。
ルール・マネージャの配置の失敗のため、Enterprise Managerの配置に失敗する場合があります。
この問題を解決するには、次の手順に従い、Enterprise Managerを再配置する必要があります。
OH/j2ee/deploy.masterをOH/j2ee/deploy.master.bakに移動します。
OH/bin/EMDeployスクリプトを実行します。
OH/j2ee/deploy.masterをリストアします。つまり、mv OH/j2ee/deploy.master.bak OH/j2ee/deploy.masterを実行します。
Oracle管理サービスの構成は、次の理由から失敗することがあります。
cfgfwログには次のエラーが表示されます。
Redeploying application 'EMAgentPush' to OC4J instance 'OC4J_EMPROV'. FAILED! ERROR: Caught exception while deploying 'EMAgentPush' to 'OC4J_EMPROV':java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
このエラーは、/etc/hostsファイル内のIpv6エントリによるものです。root.shの実行を求められた場合または構成が失敗した場合は、次のようにします。
<OMS Home>/sysman/install/EMDeployTool.pmで、deployEmEar ()で実行されるコマンドに"-Djava.net.preferIPv4Stack=true"を指定します。
<OMS Home>/opmn/conf/opmn.xmlで、すべてのOC4Jプロセスのjavaオプションに"-Djava.net.preferIPv4Stack=true"を指定します。
cfgfwログには次のエラーが表示されます。
Failed to initialize JDBC Connection
これは、NetCA実行時にリスナーが起動していないと発生します。また、installActionsログには次のエラーが表示されます。
Listener start failed. Listener may already be running.
このエラーを修正するには、次の行を<DB Home>/network/admin/listener.oraに追加します。
SUBSCRIBE_FOR_NODE_DOWN_EVENT_<listener_name>=OFF
次に、リスナーを再起動します。
既存のデータベースを使用してEnterprise Managerをインストールしている際に、Oracle管理サービス構成がリポジトリの削除中にハングします。これは、データベースに接続しているアクティブなSYSMANセッションによるものです。
この問題を解決するには、既存のEnterprise Managerセッション（Grid ControlとDatabase Controlの両方）または他のSQLPLUS SYSMANセッションを停止します。
この問題は、リリース10.2.0.1.0の追加のOracle Management Serverインストールでのみ発生します。
この問題を解決するには、<OMS_ORACLE_HOME>/sysman/configディレクトリにあるemoms.propertiesで、値をスワップしてConsoleServerNameの余分なアンダースコアを削除します。
Enterprise Manager 10gリリース2のアップグレードは移動アップグレードです。つまり、Enterprise Manager 10gリリース2のOracleホームは、以前のホームとは別になります。コピー・フェーズ（バイナリのコピー）中にアップグレード・プロセスを中断した場合は、以前の10gリリース1インストールに無事に戻ります。
このアップグレード・プロセスでは、新しいOMSホームおよびデータベース・ホームが作成されます。アップグレード・アシスタントは、データファイルおよびSYSMANスキーマをアップグレードした後、新しいOracleホームを作成します。
この項では、エージェントのアップグレード時に発生する可能性がある問題を示します。
エージェントをリリース10.1.0.nからリリース10.2.0.2にアップグレードするとき、アップグレードされるエージェントに構成されたタイムゾーンが以前に構成された元のエージェントのものと異なる場合に、アップグレード後にエージェントが起動しない可能性があります。
この問題は、タイムゾーンを変更することで解決できます。これを行うには、アップグレードされたエージェントのホームで次のコマンドを実行します。
emctl resetTZ agent
このコマンドは、エージェント側のタイムゾーンを訂正し、値を訂正するリポジトリに対して実行する追加のコマンドを指定します。
Windows NTのRACエージェントのアップグレードを行う場合、AgentOnlyのshiphomeインストーラによるインストール完了後、エージェントのアップグレードを完了させるために<Upgrade AOH>/oui/bin/upgradeユーティリティをRAC内の各ノードに対して実行する必要があります。
この項では、Enterprise Managerのリカバリの実行手順について説明します。
エージェントのリカバリを実行するには、次の手順に従います。
<New_AgentHome>/binにディレクトリを変更する必要があります。
./upgrade_recoverスクリプトを実行します。
スキーマがアップグレードされた、またはアップグレードが不完全な場合、OMSアップグレードを実行する前のバックアップにデータベースを手動でリストアする必要があります。
リポジトリのアップグレードのステータスは、<New_OMSHome>/sysman/log/emrepmgr.log.<proc_id>にあるログ・ファイルで判別できます。このログ・ファイルの最後の行にアップグレードのステータスが表示されます。アップグレードがエラーなしで完了した場合は、「リポジトリのアップグレードに成功しました。」と表示されます。そうでない場合は、「リポジトリのアップグレードにエラーがあります。」と表示されます。
OMSのリカバリを実行するには、次の手順に従います。
|
注意 データベースのリストアを試行する前に、アップグレード・ウィザードを終了する必要があります。また、実行中のOMSプロセスがないことも確認する必要があります。Enterprise Managerプロセスの停止の詳細は、11.2.1項「アップグレード前のEnterprise Managerの停止」を参照してください。 |
<New_OMSHome>/binにディレクトリを変更します。
./upgrade_recoverスクリプトを実行します。
以前のOMSを起動してそのまま使用します。インストールされた新しいOMSのホームのバイナリを削除する場合は、インストーラの製品の削除機能を使用します。
リポジトリ作成の失敗のため、管理サービス構成のプラグインが失敗した場合、Oracle Universal Installerから構成ツールを再実行すると、リポジトリが削除され、再作成されます。ただし、リポジトリを手動で削除する場合は、次の手順を完了します。
<OMSHOME>/bin/opmnctl stopall）、管理サービス（<OMS_HOME>/bin/emctl stop oms）およびエージェント（<AGENT_HOME>/bin/emctl stop agent）を停止します。
OMS_OracleHomeに設定します。
OMS_Home/sysman/admin/emdrep/RepManager <hostname> <port> <SID> -action drop -output_file <log_file>を実行します。
OMS_OracleHomeに設定します。
OMS_Home/sysman/admin/emdrep/RepManager <hostname> <port> <SID> -action create -output_file <log_file>を実行します。
既存のデータベースを使用してEnterprise Managerをインストールする際に、リポジトリの作成に失敗します。
データベースのパスワード検証リソース名のプロファイルの値が「デフォルト」以外である場合、この問題が発生する可能性があります。この問題を解決するには、次の操作を実行します。
監視エージェントはアップグレードせずに管理サービスのみを10gリリース2にアップグレードする場合、次の収集エラーが発生する場合があります。
この問題を解決するには、管理サービスとともに監視エージェントを10gリリース2にアップグレードします。
次の理由で、管理サービスのアップグレード・プロセスが中断された場合、問題が発生する可能性があります。
（<New_OracleHome>/cfgtoollogs/cfgfw/oracle.sysman.top.oms_#date.logにある）インストール・ダイアログ・ボックスおよび構成フレームワーク・ログ・ファイルに、Oracle Application Serverアップグレード・アシスタントが失敗した理由を示すSEVEREメッセージのリストが表示されます。
特定のファイルに対して、権限が拒否されたというメッセージが表示されている場合は、インストーラを実行したユーザーが、特定のOracle Application Server構成を実行するために適切な権限を持たない可能性があることを意味します。
この問題を解決するには、これらのファイルを含むOracle Application Server構成をコメント・アウトし、アップグレードを再試行します。アップグレードが完了した後で、構成を再度適用できます。
EMDeployが失敗する最も一般的な理由には次のものがあります。
Enterprise Managerを停止するには、次のコマンドを実行します。
<Oracle_Home>/opmn/bin/opmnctl stopall <Oracle_Home>/bin/emctl stop em
詳細は、11.2.1項「アップグレード前のEnterprise Managerの停止」を参照してください。
<Oracle_Home>/Apache/<component>構成ファイルで、ハード・リンクのみが参照され、シンボリック・リンクがないことを確認する必要があります。詳細は、11.2.2項「シンボリック・リンクのチェック」を参照してください。
これらの問題を解決した後、手動再配置の手順を実行し、アップグレード・ウィザードで「再試行」をクリックします。
リポジトリ・スキーマの構成の失敗の最も一般的な理由は、リスナーに接続できないことです。リポジトリ・スキーマのアップグレードの失敗の理由は、構成フレームワークのログ・ファイル（<New_OracleHome>/cfgtoollogs/cfgfw/oracle.sysman.top.oms_#date.log）に示されます。
この問題を解決するには、OMSに接続しているリスナーが有効で、動作しているかどうかを確認する必要があります。
また、「新規データベースを使用したEnterprise Manager 10g Grid Control」インストール・タイプを使用してOMSをインストールした場合は、参照されているシンボリック・リンクが存在しないことを確認します。リスナーの接続を確立した後、アップグレード・ウィザードで「再試行」をクリックします。
Enterprise Manager Grid Controlターゲット（データベースなど）を個別に（Oracle Universal Installerを使用せずに通常のアップグレード・メカニズムを使用して）アップグレードした場合、監視エージェントは、このアップグレード・ターゲットを検出できない可能性があります。
これは、アップグレード・ターゲットのOracleホームの値に、既存のものと異なる値を指定した場合に発生します。
この問題を解決するには、アップグレードされたOracleホーム情報の構成の詳細を更新するように監視エージェントのtargets.xmlファイルを手動で構成するか、または、Enterprise Managerコンソールにログインし、適切なターゲットを選択して、アップグレードされたターゲットのパラメータを反映するように構成パラメータを変更する必要があります。
10gリリース1の管理サービスとそれに関連する（監視）エージェントが同時にアップグレードされる場合、エージェントのアップグレードでCSAコレクタ・ターゲットが検出されません。
このターゲットを検出するには、再検出オプションを使用して、エージェントのコンフィギュレーション・アシスタント（agentcaスクリプト）を実行する必要があります。
詳細は、7.5.1項「スタンドアロン・エージェント上のターゲットの再検出および再構成」を参照してください。
この問題を解決するには、次のコマンドを実行します。
<New OMS Home>/bin/emctl set password welcome1 <New Password>
この問題を解決するには、次のようにします。
allroot.sh実行を求められた場合は、古いリスナーを停止します。Oracle管理サービスのアップグレードは失敗します。
この項では、Enterprise Managerのインストールおよび構成で発生する可能性があるネットワーク問題を示します。
これは、インストールはハングして、OUI-25031エラーまたはOUI-10104エラーがログ・ファイルに出力される原因となります。
/etc/hostsファイルのエントリは、次の形式である必要があります。
IP_Address Canonical_Hostname Aliases
たとえば、次のように指定します。
11.22.33.441 abc.xyz.com abc1 xyz2
/etc/hostsファイルを作成する際は、次のルールに従います。
前方参照は、ホスト名からIPアドレスを調べます。逆引き参照は、IPアドレスからホスト名を調べます。前方参照と逆引き参照の結果は同じです。通常、ホスト名および別名の大/小文字が異なると、結果は異なります。
リリース10.2.0.1のEnterprise Managerインストールの場合、ホスト名に大文字が含まれると、エージェントの保護は失敗します。
Enterprise Managerまたは関連コンポーネントをマルチホーム（マルチIP）マシン、つまり複数のIPアドレスを持つマシンにインストールするとき、ORACLE_HOSTNAME環境変数が設定されている場合、ホスト名はこの変数から導出されます。設定されていない場合は、/etc/hostsの最初の名前がインストール用と判断されます。
この問題を解決するには、Oracle管理サービスと、エージェントをインストール必要があるターゲット・ホストはping可能である必要があります。
Enterprise Managerまたは関連コンポーネントをDHCPホストにインストールする場合、ループバック・アダプタをインストールしてローカルIPアドレスをそのコンピュータに割り当てる必要があります。
次の条件が満たされていることを確認してください。
/etc/hostsファイルに、次のエントリが含まれている必要があります。
<lopback IP Address><hostname.domainname> <hostname>
たとえば、次のように指定します。
127.0.0.1 localhost.localdomain localhost
/etc/hostsに指定されたIPアドレスが正しいことを確認します。正しくないと、ポートの割当てが失敗します。
この項では、Enterprise Managerのインストールおよび構成で発生する可能性がある一般エラーを示します。
次のEnterprise Manager収集エラー・メッセージが、サイレントまたはagentdownloadインストール・メカニズムによってインストールされたエージェントから表示される場合があります。
snmhsutl.c:executable nmhs should have root suid enabled.
この問題を解決するには、必要なルートのインストール操作を（UNIXプラットフォームの場合のみroot.shスクリプトを使用して）実行します。解決が反映されるには最大24時間かかります。
エージェントがインストールされていない場合、新しいターゲットをグリッド環境に追加できません。
Grid Controlコンソールからエージェントをインストールするには次の操作を実行します。
特定のGrid Controlターゲットを削除した後、同じターゲットをGrid Controlコンソールから削除しようとすると、次のようなメッセージの例外が発生する場合があります。
java.sql.SQLException: ORA-20242: Target <target name> is monitoring other targets. It cannot be deleted.
この問題を解決するには、Grid Contolターゲットを削除した後、15秒以上待ってから、「ホスト」ページを使用して、Grid Controlコンソールからのターゲットの削除を試みてください。15秒は、削除情報が管理リポジトリに伝播するために必要となる時間です。
この付録で問題が解決されない場合は、次に示すその他の参考資料を参照してください。
（http://metalink.oracle.com）
問題の解決方法が見つからない場合は、サービス・リクエストを登録してください。
|
 Copyright © 2003, 2007 Oracle Corporation. All Rights Reserved. |
|