The information in this article applies to:
Enterprise Manager for RDBMS - Version: 10.1.0.2
This problem can occur on any platform.
Symptoms:
When attempting to use DB Control to administer a 10g Database, the database shows down in the UI but it is actually started and accepting connections.
emoms.log file might contain:
OMSHandshake failed (AGENT URL = .....:1830/emd/main) (ERROR =INTERNAL_ERROR) - Io Exception: the network adapter could not establish the connection
If you attempt to start it from the DB Control UI, the following errors occur:
ORA 12500 "TNS:listener failed to start a dedicated server process"
ORA-12514 TNS:listener could not resolve SERVICE_NAME given in connect descriptor
Cause:
During the 10g Database installation, several configuration files will be populated with the default listener port of 1521. If no other listeners are running, this works as expected. However, if a pre-existing listener was already running on the node when the 10g database was installed, the 10g database will dynamically register with the 9i listener which is not supported.
When a listener is already using port 1521, several components will experience problems.
1) The 10g TNS listener will not start. If this is a Windows server, no service will be created either. This error is a result of port conflicts with preexisting software.
2) The DB Console will show the database status as "unavailable". This error is encountered because the DB Console is not able to get a valid status of the database. Even though the DB is open, dbsnmp is not able to log into the database, so EM reports an "unavailable" status.
3) Attempting to start the database through DB Console will fail with an ORA-12500 error.
Fix
1. Lets start by fixing the listener problem and then move on to fix the other two problems. The first problem is due to a port conflict with the TNS Listener.
NOTE: On Windows systems, the service is created when the listener is first started. Once the port conflict has been resolved, the listener will start (from command line) and on Windows, the new service will be created.
a) To correct this issue, select a port number that is not defined by any other listeners, and modify the 10g ORACLE_HOME/network/admin/listener.ora file and provide the new port number.
b) If your listener.ora file does not contain a SID_LIST_LISTENER entry for your new SID, one should be created. This will enable the listener to make a client connection (as sysdba) to an idle instance. If this entry does not exist, then the database will only use the automatic registration feature (the database registers with the listener when the DB starts). This means that the listener will not have any service handlers for a down database, and only local (bequeth) connections will be possible. DB Control will ALWAYS attempt client connections, and not local connections. Adding the following section will ensure the database can be started without receiving an ORA-12514 error. This error would be possible if only the automatic registration feature is used.
This is an example of what the SID_LIST_LISTENER entry will look like (the formatting of this may be incorrect, but make sure it follows a typical listener.ora file where only the SID_LIST entry is on the left margin, and everything else is indented at least one space, with no tab characters):
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = D:\oracle\product\10.1.0\Db_1)
(PROGRAM = extproc)
)
(SID_DESC =
(SID_NAME = orcl)
(ORACLE_HOME = D:\oracle\product\10.1.0\Db_1)
(GLOBAL_DBNAME=ORCL)
)
)
In this example, the SID_DESC for the PLSExtProc was already created, so only the SID_DESC entry for the ORCL SID had to be created.
c) Start the listener using the following command from your 10g ORACLE_HOME/bin directory:
lsnrctl start
(In Windows, starting a listener will also create the listener service if it does not already exist. Verify the listener service has been created and shows that it is started.)
2. To correct the problem with the DB Control showing the database as unavailable or down, you will have to modify a emoms.properties and targets.xml files to reflect the new port for the listener.
a) modify the ORACLE_HOME/hostname_sid/sysman/config/emoms.properties file, and change all of the references (usually 2) of port 1521 to the port number you specified in the listener.ora file. The two parameters that should contain the port numbers are:
oracle.sysman.eml.mntr.emdRepPort
oracle.sysman.eml.mntr.emdRepConnectDescriptor
b) modify the ORACLE_HOME/hostname_sid/sysman/emd/targets.xml file. This file will contain two entries for port 1521. Make sure both of these values are changed to the correct listener port.
3) Once these files have been updated, stop and restart the DB Control
emctl stop dbconsole
emctl start dbconsole
This will force the DB Console components to reread the configuration files, and everything should communicate on the newly defined port.
At this point, the DB Console should provide the correct status for the database.
[10g]inconsistance de statut entre OMS et SQLPlus
Envoyé par oracle
Répondre avec citation
Suppression des variables d'environnements systèmes ORACLE_HOME, ORACLE_BASE et ORACLE_SID mises par erreur dans la base de registre. Les données spécifiées dans la base de registre sous HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_10g sont suffisantes.
Partager