以下文档摘自metalink doc : 188134.1
Subject: Tracing the Database Configuration Assistant (DBCA)
Doc ID: 188134.1 Type: BULLETIN
Modified Date: 09-OCT-2008 Status: PUBLISHED
Purpose
——-
The Purpose of this document is to assist in debugging DBCA problems.
Scope & Application
——————-
This document is for DBAs and support analysts to troubleshoot DBCA issues.
Tracing the Database Configuration Assistant (DBCA)
—————————————————
To provide verbose output for DBCA, tracing can be enabled to provide additional
output. To turn on tracing from 9i to 10g:
1. Do a copy of the original dbca file in $ORACLE_HOME/bin. For example:
cp $ORACLE_HOME/bin/dbca $ORACLE_HOME/bin/dbca.ori
2. vi the dbca file in the $ORACLE_HOME/bin directory.
3. At the end of the file, look for the following line:
# Run DBCA
$JRE_DIR/bin/jre -DORACLE_HOME=$OH -DJDBC_PROTOCOL=thin -mx64m -classpath
$CLASSPATH oracle.sysman.assistants.dbca.Dbca $ARGUMENTS
4. Add the following just before the -classpath in the ‘$JRE_DIR’ line:
-DTRACING.ENABLED=true -DTRACING.LEVEL=2
5. At the end of the dbca file, the string should now look like this:
# Run DBCA
$JRE_DIR/bin/jre -DORACLE_HOME=$OH -DJDBC_PROTOCOL=thin -mx64m
-DTRACING.ENABLED=true -DTRACING.LEVEL=2 -classpath $CLASSPATH
oracle.sysman.assistants.dbca.Dbca $ARGUMENTS
The -DTRACING.LEVEL was missing a space after the 2 so that it looks
like 2-classpath.
6. To trace run:
[opcbsol1]/u01/home/usupport> dbca > dbca.out &
The output will be written to the dbca.out file.
In 10.2 you can add the -DDEBUG flag so that you get the debug information
given to you interactively
“C:\oracle\product\10.2.0\racdb\jdk\jre\BIN\JAVA” -DDEBUG -DORACLE_HOME=”%OH%” –
DJDBC_PROTOCOL=thin -mx128m oracle.sysman.assistants.dbca.Dbca %*
BUT in 10.2 you should already have the trace information written automatically
to the following location
$ORACLE_HOME/cfgtoollogs/dbca/trace.log
In 11g, the location of trace.log has changed to:
$ORACLE_BASE/cfgtoollogs/dbca/<DBNAME>/trace.log
.
DBCA APPEARS TO HANG AFTER CLICKING FINISH BUTTON
Applies to:
Oracle Database Configuration Assistant – Version: 10.2.0.1 to 10.2.0.4
Information in this document applies to any platform.
Symptoms
Trying to create a database using the DBCA
After configuring all options successfully, clicking finish does nothing.
There is no progress, and no errors are returned
Looking at the dbca trace.log does not show any errors, just the following:
[AWT-EventQueue-0] [11:20:29:828] [DBCAWizard.onFinish:1139] m_bFinishClicked: true
[AWT-EventQueue-0] [11:20:30:2] [DBCAWizard.onFinish:1139] m_bFinishClicked: true
[AWT-EventQueue-0] [11:20:35:126] [SQLEngine.done:1958] Done called
In 10.2 trace information should be written automatically to the following location
$ORACLE_HOME/cfgtoollogs/dbca/trace.log
In 11g, the location of trace.log has changed to:
$ORACLE_BASE/cfgtoollogs/dbca//trace.log
Cause
In most cases, it appears that an X client is being used to run the dbca, like Xming.
Solution
To use Xming, you have to install the complete font package.
Optionally, run dbca locally from the console, using a different X client or using VNC.
Reflections X and Exceed are also known to work.
DBCA Tips and Pitfalls in a Windows RAC 9i Environment
Tips And Pitfalls Using DBCA in a Windows RAC 9i Environment:
===========================================================
Under normal circumstances, if the Database Configuration Assistant (DBCA) is
invoked via the Oracle Universal Installer (OUI) and/or independently
following successful install, then none of the following documented steps
should be necessary.
However, in environments where DBCA should happen to fail, here are some tips
and troubleshooting actions that may be followed to get DBCA to perform the
desired database creation.
It should be noted that manual creation of a database – even in a clustered
environment – is still a very valid option for creating your database and
should be considered against debugging DBCA as a way of meeting a stringent
deadline. In which case Note.137288.1 Manual Database Creation in
Oracle9i (Single Instance and RAC) details the process to be followed.
Topics Covered in this Article:
===============================
1. Run the Global Services Daemon (GSD) in the foreground
2. Trace DBCA during database creation
3. Cleaning up after a failed DBCA create cluster database attempt
4. DBCA will fail if Oracle Net is not configured properly
5. spfile.ora does not point to a logical partition
6. What is happening when DBCA seems to hang around 95-100%
7. Miscellaneous configuration which may prevent DBCA from succeeding
+ Sample Configuration Files
**********************************************************************
1. Run the Global Services Daemon (GSD) in the Foreground
———————————————————
The DBCA requires that the GSD be run in the foreground on each cluster
node in order to function properly.
1. Start the GSD on ALL cluster nodes in the foreground before invoking the
DBCA.
If the GSD is already running:
– Stop the GSD using commandline: gsdctl stop
OR
– Use the control panel services applet
THEN run ‘gsd.bat’ from the command line and leave this window open,
undisturbed (gsd.bat is found in $ORACLE_HOME\bin)
Repeat on all nodes.
The output on each node will display the name of the node where the gsd.bat
was first invoked and it will repeat that name over and over in a ping-like
fashion.
Do not close the window from which you invoke gsd.bat until the DBCA is
completely finished and you have exited the DBCA properly.
Example output of gsd.bat command (assuming gsd.bat has been invoked from
NODE1 first):
Example, from NODE1:
E:\>gsd.bat
“E:\Program Files\Oracle\jre\1.1.8\bin\jre” -DTRACING.ENABLED=false
-DTRACING.LEVEL=2 -classpath
(etc…)
NODE1READY
)VNODE1
Example, from NODE2:
E:\>gsd.bat
“E:\Program Files\Oracle\jre\1.1.8\bin\jre” -DTRACING.ENABLED=false
-DTRACING.LEVEL=2 -classpath
(etc…)
NODE2READY
)VNODE1
2. Trace DBCA During Database Creation
—————————————
Generating a DBCA trace file, in the event the DBCA should fail, will save
time on senseless guessing as to what caused the failure.
To generate a trace file for the DBCA it is necessary to edit the dbca.bat
file. The dbca.bat file can be found in $ORACLE_HOME\bin and can be edited
with a tool such as notepad. Remember to make a copy of the original dbca.bat
before making any changes to this file.
Note: This information is specific to Windows. If you are seeking
instructions for tracing the DBCA on UNIX, please see
Note.188134.1 Tracing the Database Configuration Assistant
(DBCA).
1. Use an editing tool such as Notepad or PFE to edit. Tracing information
should be added to line 40 of the dbca.bat.
Line 40 should now appear as follows:
“E:\Program Files\Oracle\jre\1.1.8\BIN\JRE” -DTRACING.ENABLED=true
-DTRACING.LEVEL=2 -DORACLE_HOME=”%OH%” …
2. To indicate where the trace file should be created, invoke DBCA from the
command line using the following syntax:
E:\> e:\oracle\ora920\bin\dbca.bat > e:\dbcatrace.txt
When DBCA is run, the file ‘dbcatrace.txt’ will be generated in the directory
indicated (in this case, e:\).
3. Cleaning up after a failed DBCA create cluster database attempt
——————————————————————-
As with standalone databases, the DBCA will read the registry first to
determine if a particular instance name is already in use. If the SID is
known either in the registry or in the SRVM repository then the DBCA will
not allow you to reuse that particular SID name on the second create
database attempt.
1. Use the ORADIM utility at the command line to remove the OracleServiceSID
from the Windows registry. Issue this command on each node, remembering
to edit the SID name for each node)
The oradim utility is found in the $ORACLE_HOME\bin directory.
Example:
Assume failed DBCA cluster database attempt where SID prefix =
‘RACNT’
From Node1:
oradim -delete -sid ‘RACNT1’
From Node2:
oradim -delete -sid ‘RACNT2’
2. Cleaning up the srvm repository: If this is the first cluster database
to be added to the cluster, the srvm repository may be reinitialized.
This should only be performed if this is the only cluster database known
to the SRVM repository. This step will be necessary if the DBCA create
database attempt has failed and you wish to use the same SID when
attempting DBCA create database a second time.
A. The GSD must first be stopped on all cluster nodes. Use gsdctl stop
or stop the OracleGSDService from the control panel services applet.
B. To reinitialize the repository, issue the command:
srvconfig -init -f
When DBCA is invoked again, it will no longer report the presence of database
RACNT and it will allow this name to be used again.
Note: It is also possible to trace GSD – see Note.178683.1 Tracing GSD,
SRVCTL, GSDCTL, and SRVCONFIG for details.
4. DBCA will fail if Oracle Net is not configured properly
————————————————————
One of the tasks the DBCA will perform will be to configure your spfile and/or
init.ora file parameters for this cluster database. Some parameters – such as
‘LOCAL_LISTENER’ will require that the proper net configuration is in place in
order to allow the database to open. This is the reason that an improper net
configuration could cause the DBCA to fail.
As explained in Note.188555.1 ORA-119, ORA-132, and ORA-1078 When Using DBCA
to Create a RAC Database, one of the requirements for the DBCA to run properly
is that the Net Configuration Assistant (NETCA) must first have been run
successfully.
Therefore it is strongly advised that you do not manually edit the listener.ora
and tnsnames.ora file information, but rather you leave the necessary
configuration steps to the NETCA.
In the event that these files have been edited manually since installation time,
below are some troubleshooting tips that may help to get the DBCA to create the
desired database.
Net requirements before invoking the DBCA in a RAC environment are explained
here in three categories:
A. listener.ora configuration
B. tnsnames.ora configuration
C. init.ora configuration
A. LISTENER.ORA
Listener.ora is usually configured at installation time when the OUI
invokes the Net Configuration Assistant (NETCA). At this time, a
very simple listener.ora file is generated and stored in
$ORACLE_HOME\network\admin.
If for any reason the NETCA is not run successfully at installation
time, it is necessary for the DBCA that this tool be run independently
thereafter.
When using DBCA to create your cluster database it is absolutely
unnecessary – AND ILL ADVISED – to manually edit the listener.ora file.
See Sample Configuration Files ‘A1’ here below for example listener.ora
files before and after DBCA is run.
B. TNSNAMES.ORA
Although not clearly documented, in order to run the DBCA successfully
in your RAC environment, proper configuration of the tnsnames.ora file
is critical.
As with the listener.ora information it would be ill advised to edit
the tnsnames.ora file manually as this may cause the database not to
open and the DBCA to fail!
The best way to begin is with the most simple tnsnames.ora information
possible and to allow DBCA to put in the information it will need to
create the instances, etc.
See Sample Configuration Files ‘B1′ here below for example tnsnames.ora
files before and after DBCA is run.
C. INIT.ORA (net configuration)
The DBCA will configure the SPFILE to contain the following parameters
that correspond directly to the necessary parameters in the tnsnames.ora
file:
RACNT1.local_listener=’LISTENER_RACNT1′
RACNT2.local_listener=’LISTENER_RACNT2′
*.remote_listener=’LISTENERS_RACNT’
Note: Each of these init.ora entry values must correspond to a
tnsnames.ora configured service entry.
5. spfile.ora does not point to a logical partition
————————————————————-
While running Database Configuration Assistant (DBCA) to create a database
with datafiles to be stored on Oracle Cluster File System (OCFS) in an
Oracle 9i Real Application Clusters environment on Windows the following
message is encountered:
c:\oracle\ora92\database\spfileRACNT.ora does not point to a logical partition.
The correct way to invoke DBCA in a RAC on Windows environment to create a
database that will have its datafile storage on an OCFS partition is as
documented in:
Note:178882.1 : Step-By-Step Install of RAC with OCFS on Windows 2000
invoke DBCA from the command line as instructed by Note:178882.1 :
Step-By-Step Install of RAC with OCFS on Windows 2000
dbca -datafileDestination O:\oradata
If you don’t issue this command exactly, you will get the error as described
above.
A. Possible cause #1:
==================
Failure to capitalize the drive letter …
dbca -datafileDestination o:\oradata
instead of:
dbca -datafileDestination O:\oradata
B. Possible cause #2:
==================
Failure to include backslash,
dbca -datafileDestination O:oradata
instead of:
dbca -datafileDestination O:\oradata
Be sure to use the following syntax to invoke DBCA in a RAC on Windows
environment to create a database that will have its datafile storage on an
OCFS partition EXACTLY as documented:
dbca -datafileDestination O:\oradata
6. What is happening when DBCA seems to hang around 95-100%
———————————————————–
Do not panic. What appears to be a ‘hang’ may actually be a ‘pause’.
It is not uncommon if the DBCA seems to ‘pause’ at 95-100% completion. At the
end of the DBCA create cluster database process additional instances are
created on the remote nodes and additional log threads are assigned to these
instances.
When the DBCA reaches 100% completion, the Password Management screen should
appear. Make certain that the password management screen is not just simply
‘hiding’ behind the DBCA applet. The DBCA window with status 100% will not go
away until the Password Management screen has been exited.
Other possible causes of probable DBCA hangs are covered in
Note.213416.1 RAC Troubleshooting Windows NT/2000 Service Hangs
7. Miscellaneous configuration that may prevent DBCA from succeeding
——————————————————————–
1. Note.223554.1 Automatic Startup of the Intelligent Agent Fails in RAC
Environment.
2. Be sure that your OracleGSDService is configured to run under a user
account that is a member of the ORA_DBA group. By default, the
OracleGSDService is configured to run under the Local System account
this change must be made manually. Please see the Windows Administrator
guide for more information.
3. There are srvm and dbca updates packaged wintin the CFS bundle for
Windows. If you are using these executables from the CD installation,
please obtain the CFS bundle from Oracle Tech Net whether you plan to
use RAW or OCFS datafiles:
Oracle Real Application Clusters, Cluster File System for Windows NT/2000
http://otn.oracle.com/software/products/oracle9i/htdocs/winsoft.html
4. Do not delete all control files in the Storage screen of DBCA. If you
want to change the File Name or Directory from the default, simply edit
the names that are given. Removing all control files listed will have
the result that you will be unable to add any new control file names on
this screen. If you have done so, then when attempting to proceed to
the next window of the DBCA you will not be allowed since at least two
controlfiles must be specified in order to have DBCA create a database
for you.
5. The DBCA template may indicate that the datfafiles will be created
with AUTOEXTEND = true. However, if the datafiles will be created on
raw devices, this will not be the case. After database creation, it
will be necessary to alter the datafiles to trun on AUTOEXTEND if this
is desired.
To check the AUTOEXTENSIBLE status of the datafiles in the database,
perform the following query:
SQL> select file_name, autoextensible from dba_data_files;
To set the AUTOEXTEND flag to ‘ON’ for particular or all datafiles,
the following command must be issued:
SQL> alter database datafile ‘\\.\TOOLS01.DBF’ autoextend on
maxsize 80M;
Note: Setting datafiles stored on raw devices to AUTOEXTEND in a Windows
environment is not recommended.
********************************************************************************
If you have chosen not to create a database during the Oracle Universal Installer
installation of your RDBMS / RAC option, then you must invoke NETCA and create
listeners for your cluster nodes before invoking DBCA to create your RAC
database.
Simply invoke NETCA, choose cluster configuration, choose all cluster nodenames
from the list, ‘Add Listener’ and leave the default name of LISTENER.
Assuming node names =
racnode1
racnode2
Database name =
racdb
Your LISTENER.ORA file should look like this one BEFORE and AFTER
running DBCA in this environment:
*****
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = racnode1)(PORT = 1521))
)
)
)
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = C:\oracle\ora92)
(PROGRAM = extproc)
)
(SID_DESC =
(ORACLE_HOME = C:\oracle\ora92)
(SID_NAME = racdb1)
)
)
Once the listeners have been created, you can run DBCA which will create your database
as well as update your SRVM repository with information regarding this database
AND update your tnsnames.ora files and initialization parameter files as
follows:
*****
*****
*****
TNSNAMES.ORA file:
*****
# TNSNAMES.ORA Network Configuration File: C:\oracle\ora92\network\admin\tnsnames.ora
# Generated by Oracle configuration tools.
racdb =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST =racnode1)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = racnode2)(PORT = 1521))
(LOAD_BALANCE = yes)
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = racdb)
)
)
LISTENER_racdb2 =
(ADDRESS = (PROTOCOL = TCP)(HOST = racnode2)(PORT = 1521))
LISTENER_racdb1 =
(ADDRESS = (PROTOCOL = TCP)(HOST = racnode1)(PORT = 1521))
racdb1_STARTUP =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = racnode1)(PORT = 1521))
(CONNECT_DATA =
(SID = racdb1)
)
)
racdb2 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = racnode2)(PORT = 1521))
(CONNECT_DATA =
(SERVICE_NAME = racdb)
(INSTANCE_NAME = racdb2)
)
)
racdb1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = racnode1)(PORT = 1521))
(CONNECT_DATA =
(SERVICE_NAME = racdb)
(INSTANCE_NAME = racdb1)
)
)
INST1_HTTP =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = racnode1)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = SHARED)
(SERVICE_NAME = MODOSE)
(PRESENTATION = http://HRService)
)
)
racdb2_STARTUP =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = racnode2)(PORT = 1521))
(CONNECT_DATA =
(SID = racdb2)
)
)
LISTENERS_racdb =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = racnode1)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = racnode2)(PORT = 1521))
)
*****
*****
*****
Initializiation parameters were:
RACDB1.LOCAL_LISTENER=LISTENER_racdb1
RACDB2.LOCAL_LISTENER=LISTENER_racdb2
*.REMOTE_LISTENER=LISTENERS_racdb
*****
*****
*****
Subsequent runnings of DBCA to create additional Real Application Clusters
databases require no manual intervention for the NET files.
Simply run DBCA to create the additional databases and your tnsnames.ora
file as well as your initializiation parameter file will be updated as
appropriate.
PRKS-1011 And CRS-0210 creating an ASM based RAC database using DBCA
Applies to:
Oracle Server – Enterprise Edition – Version: 10.1.0.2 and later [Release: 10.1 and later ]
IBM AIX on POWER Systems (64-bit)
IBM AIX Based Systems (64-bit)
new install of Oracle 10g RAC.
Symptoms
dbca is failing with the following errors while creating a RAC database using ASM :
For node 1:
PRKS-1011 – Failed to check status of ASM instance “+ASM1” on node “oraclust1”,
[CRS-0210: Could not find resource ora.oraclust1.ASM1.asm.]
For node 2:
PRKS-1011 – Failed to check status of ASM instance “+ASM2” on node “oraclust2”,
[CRS-0210: Could not find resource ora.oraclust2.ASM2.asm.]
After turning on dbca tracing ( -DTRACING.ENABLED=true -DTRACING.LEVEL=2)
the dbca trace shows the following erros when it tries to register the ASM instance with CRS:
Thread-36] [19:14:48:332] [RuntimeExec.runCommand:71] Calling Runtime.exec() with the command
[Thread-36] [19:14:48:332] [RuntimeExec.runCommand:73]
/oracle/app/oracle/OraHome_1/bin/crs_register
[Thread-36] [19:14:48:332] [RuntimeExec.runCommand:73] ora.oraclust1.ASM1.asm
[Thread-76] [19:14:48:385] [StreamReader.run:61] In StreamReader.run
[Thread-36] [19:14:48:386] [RuntimeExec.runCommand:127] runCommand: Waiting for the process
[Thread-75] [19:14:48:386] [StreamReader.run:61] In StreamReader.run
[Thread-75] [19:14:52:373] [StreamReader.run:65] OUTPUT>2004-07-30 19:14:52.337: ALERT
[READMESSAGE:1] Receive message header caa_clsrecv ret 11
[Thread-75] [19:14:52:376] [StreamReader.run:65] OUTPUT>2004-07-30 19:14:52.375: ALERT
[REQUEST_REPLY_:1] Error reading response IOException : Didn’t receive header part of message
[Thread-75] [19:14:52:376] [StreamReader.run:65] OUTPUT>(File: caa_Message.cpp, line: 695)
[Thread-76] [19:14:52:377] [StreamReader.run:65] ERROR>CRS-0184: Cannot communicate with the CRS daemon.
[Thread-76] [19:14:52:386] [StreamReader.run:65] ERROR>
[Thread-36] [19:14:52:404] [RuntimeExec.runCommand:129] runCommand: process returns 184
[Thread-36] [19:14:52:405] [RuntimeExec.runCommand:143] RunTimeExec: output>
[Thread-36] [19:14:52:405] [RuntimeExec.runCommand:146] 2004-07-30 19:14:52.337: ALERT
[READMESSAGE:1] Receive message header caa_clsrecv ret 11
[Thread-36] [19:14:52:405] [RuntimeExec.runCommand:146] 2004-07-30 19:14:52.375: ALERT
[REQUEST_REPLY_:1] Error reading response IOException : Didn’t receive header part of message
[Thread-36] [19:14:52:405] [RuntimeExec.runCommand:146] (File: caa_Message.cpp, line: 695)
[Thread-36] [19:14:52:406] [RuntimeExec.runCommand:151] RunTimeExec: error>
[Thread-36] [19:14:52:406] [RuntimeExec.runCommand:154] CRS-0184: Cannot communicate with the
CRS daemon.
[Thread-36] [19:14:52:406] [RuntimeExec.runCommand:154]
Cause
These messages indicate that the CRS daemon crashed while registering the resource.
The default ulimits on AIX – even for the root user – are set to:
time(seconds) unlimited
file(blocks) 2097151
data(kbytes) 131072
stack(kbytes) 32768
memory(kbytes) 32768
coredump(blocks) 2097151
nofiles(descriptors) 2000
These limits (data, stack or memory) appear to be too low (for the CRS daemon to successfully register the ASM instances.
Please note that the CRS daemon does start with these ulimits but will fail later.
Solution
After setting the ulimits to unlimited on the root account, dbca could successfully register the ASM instances with CRS:
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 2097152
memory(kbytes) unlimited
coredump(blocks) 2097151
nofiles(descriptors) unlimited
This needs to done on all nodes of the cluster. The CRS daemon needs to be restarted (e.g. via reboot).
On AIX the default ulimits and ulimits for individual users are set in /etc/security/limits. Add an entry for the root user using the following values* (these values should be set for root and Oracle as per Bug:7330414):
root:
fsize = -1
core = 2097151
cpu = -1
data = 524288
rss = 524288
stack = 524288
stack_hard = 524288
nofiles = 2000
Verify the current settings – after logging out and back in as root – with
# ulimit -a
For more information see the AIX man page for ‘ulimit’.