init parameter PROCESSES

Initialization parameter PROCESSES defines the max number of user connections that can access the database at a same time. The default value for the parameter is 300.

If the max number exceeds the parameter value, new connection will not be able to connect to the database. Grid Control will report the connection problem and the database will give error in trace file:

ORA-00020: maximum number of processes (300) exceeded

In that case, the issues can be confirmed by number of OS sessions and by database view v$process:

$ echo $ORACLE_SID
$ ps -ef | grep $ORACLE_SID | wc -l
299

SQL> select count(*) from v$process;

COUNT(*)
----------
297

To increase the value, run an alter statement. Then a database bounce is necessary.

SQL> alter system set processes=500 scope=pfile;

I read that below three parameters are related by a formula (in 10G, but might not be always). If database reports ORA-00018 error, you may also consider modifying parameter PROCESSES (or find why the number of sessions jumped).

ORA-00018: maximum number of sessions exceeded

processes=x
sessions=x*1.1+5
transactions=sessions*1.1

Oracle Client Patchset

When Oracle releases a database (RDBMS) version, it releases a corresponding client. For example, for 11.2.0.1.0 database server, aix.ppc64_11gR2_client.zip and aix.ppc32_11gR2_client.zip are client files. If you want to upgrade your client (i.e. from 11.2.0.1 to 11.2.0.3), you have to use the server patchset. Document 438049.1 says "For database and client upgrade use the same patch set. There is no separate patch set for client".

Document 207303.1 provides a matrix summarizing client and server combinations that are supported Oracle.

To install Oracle client utilities, choose "Custom" during the installation. Document 437377.1 shows how to install SQL*Loader on the 10G client:

The steps to install SQL*Loader in client in Custom Installation :

1) Start the Oracle Universal Installer (OUI) from the client source (CD)

2) Choose 'Installation Type'
==> Select the "Custom" and then continue with 'Next'

3) Choose the ORACLE_HOME, continue with 'Next'

4) In the 'Available Product Components' Screen
==> Select the "Oracle Database Utilities" and then continue with 'Next'
Note: Only components with a check mark are installed.

5) At the "Summary" screen Click "Install"

Finish the installation. This will Install SQL Loader.

You will be able to find the "sqlldr.exe" (or "sqlldr") in the directory %ORACLE_HOME%\bin in Windows and $ORACLE_HOME\bin in UNIX

Get AWR, ADDR, and ASH reports from SQL scripts

One way to identify the causes of poor performance in the database is to review AWR, ADDR, and ASH reports. They should be for a period of 60 or more minutes, covering the poor performance period.

. To generate the AWR report, execute the following script and select two snapshots:

SQL> @$ORACLE_HOME/rdbms/admin/awrrpt.sql

>> Choose the TXT format or the HTML format.

. To generate the ADDM report, execute:

SQL> @$ORACLE_HOME/rdbms/admin/addmrpt

>> Choose the TXT format or the HTML format.

. To generate the ASH report, execute:

SQL> @$ORACLE_HOME/rdbms/admin/ashrpt

>> Choose the TXT format or the HTML format.

REDO log sizing

Online redo log sizing is very important. If it is too small, the LGWR, ARCH and DBWR background processes will be busy by the frequent log switches and increase CPU usage. It it is too big, the database risks losing data during an instance crash.

In Oracle 10G, Oracle advisory utility makes recommendation on optimal redo log size. To use this feature, an initialization parameter FAST_START_MTTR_TARGET parameter must be set to a nonzero value, which specifies a target (bounded) time (in seconds) to complete the cache recovery phase of recovering. Using this parameter, Oracle database can now self-tune checkpointing to achieve good recovery times with low impact on normal throughput. DBAs no longer have to set any checkpoint-related parameters and should disable (set to 0) the following parameters:

- LOG_CHECKPOINT_TIMEOUT
- LOG_CHECKPOINT_INTERVAL
- FAST_START_IO_TARGET

View v$instance_recovery holds the MTTR (mean time to recovery ) information with following columns:

optimal_logfile_size -- the suggested size in megabytes
target_mttr -- MTTR target in effect in seconds
estimated_mttr -- the estimated MTTR if a crash happens right now

The data reported in this view may change frequently, based on the DML load on the database. DBAs can use the suggested size when the database is relatively stable to build the redo log properly.

Grid Control also gives the suggested size. The navigation is
Adminstration --> Storage --> Redo Log Group --> Actions dropdown: Sizing advice --> Go.

Oracle Database Backup and Recovery Advanced User's Guide (10gR2, B14191-01) has details on Oracle recovery process and on FAST_START_MTTR_TARGET sizing.
Note 276103.1 has more on Advisors.

EBS Configurator version

The Configurator version in 11i can be obtained using the following URL:
http://hostname:portnum/configurator/oracle.apps.cz.servlet.UiServlet?test=version

the values "hostname:portnum" can be found in "BOM:Configurator URL of UI Manager" profile option.

Reference: Note 419300.1

For EBS R12, the URL is

http://hostname:portnum/OA_HTML/configurator/UiServlet?test=version