This document details how to install the Grid Control Agent 10.2.0.4 onto any 10g or 9i database host running on Solaris.

Assumptions & Pre-Requisites

The following assumptions and pre-requisites are assumed:-

• The NFS mount point /net/hostname/u01/app/oracle/GRID/oms10g/sysman/agent_download exists on the server you intend to install the Grid Control agent.
• A Grid Control repository has been built according the documentation listed here.
• The Agent Download directory has been configured as detailed in the Grid Control Config Guide

Useful Information

• Read the Known Issues section below.
• The install for a VCS cluster uses a staticports.ini file. This allows the port number for the agent to be defined at install time. This is required if installing more than one agent on a host, as each agent must have a different port number.
• More than one agent on a host is only needed if the host has multiple sets of Oracle binaries that failover independently of each other. If there is only one set of Oracle binaries or the binaries do not failover independent of each other, then the entries in the staticports.ini file should be hashed out using a # or the file removed altogether.
• It is possible to ignore the statictports.ini steps if only one agent is being installed or if ALL agents on the host are up and running on the host where the agent is being installed.
• When installing an agent on a VCS cluster, it is important that the agent is installed into a failover mount point.

Step-By-Step Guide

Installing the Agent on a Solaris Standalone Server

1. Log onto the server where the agent is to be installed.

2. Make sure you have the correct oraInst.loc file in place.

3. Unset the variables

• unset ORACLE_HOME
• unset ORACLE_BASE
• unset ORACLE_SID

4. Set the Agent Install and DBSNP Password variable

• export AGENT_INSTALL_PASSWORD=password
  • NB The password specified above is the current OMS registration password.
• export DBSNMP_PASSWORD=password
  • NB The password specified above is the current DBSNMP password.
• export AGENT_HOSTNAME=hostname

5. Copy the agentDownload file to the local host.

• cd /u01/app/oracle
• mkdir -p SOFTWARE/agent10g
• cd SOFTWARE/agent10g
• cp /net/hostname/u01/app/oracle/GRID/oms10g/sysman/agent_download/10.2.0.4.0/solaris/agentDownload.solaris agentDownload.solaris
• chmod 755 agentDownload.solaris
• ./agentDownload.solaris -b agent_base -m OMS_hostname -r OMS_portno
• WARNING Be careful to specify the Agent Base and NOT the Agent Install Location.
• Check the agent10g logfile located /u01/app/oracle/SOFTWARE/agent10g/agentDownload10.2.0.4.0Oui/ErrLog.log

6. Shutdown the Agent

• cd agent_home/bin
  • NB The agent home is agent_base/agent10g where agent_base is the value specified in the install step above.
• ./emctl stop agent

7. Get a UNIX administrator to run root.sh from the agent10g home driectory.

8. Start the Agent

• cd agent_home/bin
  • NB The agent home is agent_base/agent10g where agent_base is the value specified in the install step above.
• ./emctl start agent

9. Follow the Step-By-Step guide Configuring the Agent Install shown below.

Installing the Agent on a Solaris RAC Server

1. Log onto the server where the agent is to be installed.

2. Make sure you have the correct oraInst.loc file in place.

3. Unset the variables

• unset ORACLE_HOME
• unset ORACLE_BASE
• unset ORACLE_SID

4. Set the Agent Install and DBSNP Password variable

• export AGENT_INSTALL_PASSWORD=password
  • NB The password specified above is the current OMS registration password.
• export DBSNMP_PASSWORD=password
  • NB The password specified above is the current DBSNMP password.
• export AGENT_HOSTNAME=hostname

5. Copy the agentDownload file to the local host.

• cd /u01/app/oracle
• mkdir -p SOFTWARE/agent10g
• cd SOFTWARE/agent10g
• cp /net/hostname/u01/app/oracle/GRID/oms10g/sysman/agent_download/10.2.0.4.0/solaris/agentDownload.solaris agentDownload.solaris
• chmod 755 agentDownload.solaris
• ./agentDownload.solaris -b agent_base -m hostname -r port_no -c node1,node2,node3 -n clustername
  • node1,node2,node3 are the nodes hosting the RAC cluster
  • clustername is the name of the RAC cluster ( to get cluster name run /bin/cemutlo -n
• WARNING Be careful to specify the Agent Base and NOT the Agent Install Location.
• Check the agent10g logfile located /u01/app/oracle/SOFTWARE/agent10g/agentDownload10.2.0.4.0Oui/ErrLog.log

6. Shutdown the Agent

• cd agent_home/bin
  • NB The agent home is agent_base/agent10g where agent_base is the value specified in the install step above.
• ./emctl stop agent

7. Get a UNIX administrator to run root.sh from the agent10g home driectory.

8. Start the Agent

• cd agent_home/bin
  • NB The agent home is agent_base/agent10g where agent_base is the value specified in the install step above.
• ./emctl start agent

9. Follow the Step-By-Step guide Configuring the Agent Install shown below.

NOTE You will have to manually install the fix_agent.ksh script on the other nodes in the cluster.

Installing the Agent on a Solaris VCS Cluster

1. Log onto the server where the agent is to be installed.

2. Unset the variables

• unset ORACLE_HOME
• unset ORACLE_BASE
• unset ORACLE_SID

2. Set the Agent Install and DBSNP Password variable

• export AGENT_INSTALL_PASSWORD=password
  • NB The password specified above is the current OMS registration password.
• export DBSNMP_PASSWORD=password
  • NB The password specified above is the current DBSNMP password.
• export AGENT_HOSTNAME=hostname

3. Copy the agentDownload file to the local host.

• cd /u01/app/oracle
• mkdir -p SOFTWARE/agent10g
• cd SOFTWARE/agent10g

4. Copy the VCS oraInst.loc file to the agent10g software directory.

• cd /u01/app/oracle/SOFTWARE/agent10g
• cp /net/hostname/u01/app/oracle/GRID/oms10g/sysman/agent_download/10.2.0.4.0/solaris/custom/VCSoraInst.loc oraInst.loc

5. Copy the staticports.ini file to the agent10g software directory.

• cd /u01/app/oracle/SOFTWARE/agent10g
• cp /net/hostname/u01/app/oracle/GRID/oms10g/sysman/agent_download/10.2.0.4.0/solaris/custom/staticports.ini staticports.ini

6. Update the staticports.ini file with a valid port number.

• vi staticports.ini
• %s/port_num/VALID_PORT_NO/g
• NB If installing multiple agents on the same server for each set of binaries, the port number must be different for each agent. If installing just one agent, then the line can be hashed out.

7. Run the agentDownload script

• cp /net/hostname/u01/app/oracle/GRID/oms10g/sysman/agent_download/10.2.0.4.0/solaris/agentDownload.solaris agentDownload.solaris
• chmod 755 agentDownload.solaris
• ./agentDownload.solaris -b agent_base -m OMS_hostname -r OMS_portno -i /u01/app/oracle/SOFTWARE/agent10g/oraInst.loc -p /u01/app/oracle/SOFTWARE/agent10g/staticports.ini
• WARNING Be careful to specify the Agent Base and NOT the Agent Install Location.
• Check the agent10 logfile located /u01/app/oracle/SOFTWARE/agent10g/agentDownload10.2.0.4.0Oui/ErrLog.log

8. Shutdown the Agent

• cd agent_home/bin
  • NB The agent home is agent_base/agent10g where agent_base is the value specified in the install step above.
• ./emctl stop agent

9. Get a UNIX administrator to run root.sh from the agent10g home driectory.

10. Start the Agent

• cd agent_home/bin
• NB The agent home is agent_base/agent10g where agent_base is the value specified in the install step above.
• ./emctl start agent

10. Follow the Step-By-Step guide Configuring the Agent Install shown below.

Configuring the Agent Install

1. Configure Proxy & Connection Settings for the new agent.

• In the Grid Control Console click on the Home tab.
• Click setup in the top right hand corner.
• Click on Patching Setup in the menu on the left hand side.
• Click on Proxy & Connection Settings
• Ensure the radio button for Manual proxy configuration is selected.
• Ensure the Host is set to proxyhostname.domain
• Ensure the port is set to portno
• In the list of Don’t proxy for hosts add the new agent hostname to the comma separated list.
• Ensure the Realm is set to local
• Ensure the Username is set to proxy username
• Enter a valid password
• Click Apply

Known Issues

Error when Trying to Configure a Database

Description

The following error messages may be reported in the emagent.trc when trying to configure a database target or after the agent install has completed.

SQL = ” OCIPing”…
LOGIN = dbsnmp/<PW>@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=hostname)(PORT=1521))(CONNECT_DATA=(SID=SIDNAME)))
2009-06-05 12:13:26,567 Thread-432 WARN vpxoci: OCI Error — ErrorCode(3113): ORA-03113: end-of-file on communication channel

In addition, in the Targets Not Configured page of the the Grid Control front end you will get errors similar to the following

Get dynamic property error,Dynamic Category property error
Compute dynamic property takes too long

Cause

This is a bug reltaing to the way the patched 10.2.0.4 agent interacts with database at version 9.2.0.7 or below.

Fix Step-By-Step

1. Log onto the database having the error and grant sysdba to the dbsnmp user.

• . oraenv
• ORACLE_SID = [SID] ? SID
• sqlplus ‘/ as sysdba’
• SQL> grant sysdba to dbsnmp

1. From the Grid Control front end reconfigured the database having the issue.

• Select the Targets tab.
• Select the Databases breadcrumb.
• Select the radio button alongside the database having the issue.
• Click Configure
• From the Configure Database Instance: Properties page set the Role field to sysdba
• Set the Monitor Username field to dbsnmp
• Ensure you have set a valid password in the Monitor Password field.
• Click Next
• Click Submit
• Click Ok

Error Messages When Starting up Grid Control Agents

Description

The following error messages may be reported when starting grid control agents.

Cause

See above.

Fix Step-By-Step

All of these messages can be ignored.

Useful Information

Manual Application of Patch Bundle 1 for Solaris 10.2.0.4 Agent.

The automatic application of patch bundle 1 for the 10.2.0.4 agent should happen automatically if the agent_download directory has been set-up correctly. However, if for any reason the application of patch bundle 1 does not work, the following guide can be used.

NB This is not required if using the amended agent_download script.

• cd AGENT_HOME/sysman/bin
• ./emctl stop agent
• cd /u01/app/oracle/SOFTWARE/agent10g
• mkdir Recommended
• cd Recommended
• cp /net/hostname/u01/app/oracle/GRID/oms10g/sysman/agent_download/Patches/SolarisSPARC/Recommended/Solaris_x64_GridControl_agent_download_10_2_0_2_0.zip Solaris_x64_GridControl_agent_download_10_2_0_2_0.zip
• unzip Solaris_x64_GridControl_agent_download_10_2_0_2_0.zip
• cd 8345731
• export ORACLE_HOME=AGENT_HOME
• export PERL5LIB=$ORACLE_HOME/perl/lib:$ORACLE_HOME/perl/lib/site_perl
• export EMSTATE=$ORACLE_HOME
• export PATH=$PATH:$ORACLE_HOME/OPatch
• $ORACLE_HOME/perl/bin/perl ./8345731/files/GCAgent/scripts/apply_8345731.pl
• sh ./8345731/files/GCAgent/scripts/patch8345731_nmo.sh
• opatch napply -skip_subset -skip_duplicate
• Get a UNIX administrator to run root.sh from the agent10g home driectory.

Script for Resetting the DBSNMP Password

This script below can be used to configure ther DBSNMP user and the related targets.xml entries after an agent has been installed. Alternatively, it can be performed manually by performing the following commands

NB This is not required if using the amended agent_download script.

1. Log onto the server where the new agent has been installed.
2. For each database where the agent has been installed perform the following steps.

• Unlock, unexpire and reset the DBSNMP password.
• . oraenv
• ORACLE_SID = [oracle] ?
• sqlplus ‘/ as sysdba’
• SQL> alter user dbsnmp identified by current_dbsnmp_password account unlock;

2. Configure the DBSNMP account from the Grid front end.

• In the Grid Control Console click on the Home tab.
• Click setup in the top right hand corner.
• Click on the Agents breadcrumb.
• Click on the hostname where the agent has been installed.
• Click on a database that requires configuring. This is donated by the words unconfigured written in red below the database name.
• From the database instance page, click on configure
• In the Monitor Password field enter the current DBSNMP password.
• Click on Test Connection
• If the Test Connection is successful, click on Next
• Click Submit
• Click OK
• After a period of time, the screen will refresh and the database instance page will be displayed.

#!/bin/ksh
#############################################################################
# Script : setup_dbsnmp.ksh
#
# Date : 4th December 2008
#
# Author : www.oracle-wiki.net
#
# Description : Set-up the DBSNMP user ready for Grid.
#
# Parameters : \$1 – Password for DBSNMP.
#
# History
# V1 Date 4/06/09 Name: MDT Reason:Documented
#
############################################################################
#
# Set-up Variables
#

PASSWORD=$1
export ORAENV_ASK=NO
EMAGENT=$(ps -eo comm | grep emagent)
EMDIR=$(dirname $EMAGENT)
EMCTL=$(echo $EMAGENT | sed ‘s/emagent/emctl/’)

#
#For each DB Loop Around and Configure DBSNMP
#

ps -ef | grep pmon | grep -v grep | awk -F’_’ ‘{print $3}’ | while read SID
do
export ORACLE_SID=$SID
. oraenv
sqlplus -s “/ as sysdba” <<EOF
alter user dbsnmp account unlock identified by $PASSWORD
/
exit
EOF

#
#Configure the targets.xml file.
#

TARGET=$(grep $ORACLE_SID ${EMDIR}/../sysman/emd/targets.xml | grep oracle_database | sed ‘s/.*NAME=”\(.*\)”.*$/\1/’)
$EMCTL config agent credentials ${TARGET}:oracle_database <<EOF
y
dbsnmp
y
$PASSWORD
$PASSWORD
EOF
Done

#
#End Job
#

echo “JOB COMPLETE”
exit 0

staticports.ini file

#staticports.ini Template File
#This file is a template for specifying port numbers at installation time.
#To specify a port number, uncomment the appropriate line (remove #) and
#replace “port_num” with the desired port number.
#You can then launch Oracle Universal Installer with special options to use this file.
#Please refer to Enterprise Manager Grid Control 10gR2 Installation Guide for instructions.
Enterprise Manager Central Agent Port=port_num

VCSoraInst.loc file

#Oracle Installer Location File Location
#Thu Mar 26 10:48:21 GMT 2009
inst_group=dba
inventory_loc=/u01/app/oracle/agent10g/oraInventory

A Critical Patch Update is a collection of patches for multiple security vulnerabilities. Critical Patch Update patches are usually cumulative but each advisory describes only the security fixes added since the previous Critical Patch Update advisory. Thus, prior Critical Patch Update advisories should be reviewed for information regarding earlier published security fixes. Please refer to:

Due to the threat posed by a successful attack, Oracle strongly recommends that customers apply CPU fixes as soon as possible. This Critical Patch Update contains 78 new security fixes across all product families listed below.

Affected Products and Components

Security vulnerabilities addressed by this Critical Patch Update affect the products listed in the categories below.  The product area of the patches for the listed versions is shown in the Patch Availability column corresponding to the specified Products and Versions column.   Please click on the link in the Patch Availability column below or in the Patch Availability Table to access the documentation for those patches.

The list of affected product releases and versions that are in Premier Support or Extended Support, under the Oracle Lifetime Support Policy is as follows:

Patch Availability Table and Risk Matrices

Products with Cumulative Patches

The Oracle Database, Oracle Fusion Middleware, Oracle Enterprise Manager Base Platform (formerly “Oracle Enterprise Manager Grid Control”), Oracle E-Business Suite Applications, JD Edwards EnterpriseOne, JD Edwards OneWorld Tools, PeopleSoft Enterprise Portal Applications, PeopleSoft Enterprise PeopleTools, Siebel Enterprise, Oracle Industry Applications and Oracle VM patches in the Critical Patch Updates are cumulative; patches for any of these products included in a Critical Patch Update will include all fixes for that product from the previous Critical Patch Updates. For more information about cumulative and non-cumulative patches, check the patch availability documents in the table below for the respective product groups.

Patch Availability Table

For each administered Oracle product, consult the documentation for patch availability information and installation instructions referenced from the following table. For an overview of the Oracle product documentation related to this Critical Patch Update, please refer to the Oracle Critical Patch Update January 2012 Documentation Map, My Oracle Support Note 1368685.1.

Operations such as upgrades, patches and DDL changes can invalidate schema objects. Provided these changes don’t cause compilation failures the objects will be revalidated by on-demand automatic recompilation, but this can take an unacceptable time to complete, especially where complex dependencies are present. For this reason it makes sense to recompile invalid objects in advance of user calls. It also allows you to identify if any changes have broken your code base. This article presents several methods for recompiling invalid schema objects.

• Identifying Invalid Objects
• The Manual Approach
• Custom Script
• DBMS_UTILITY.compile_schema
• UTL_RECOMP
• utlrp.sql and utlprp.sql

Identifying Invalid Objects

The DBA_OBJECTS view can be used to identify invalid objects using the following query.

COLUMN object_name FORMAT A30
SELECT owner,
       object_type,
       object_name,
       status
FROM   dba_objects
WHERE  status = 'INVALID'
ORDER BY owner, object_type, object_name;

With this information you can decide which of the following recompilation methods is suitable for you.

The Manual Approach

For small numbers of objects you may decide that a manual recompilation is sufficient. The following example shows the compile syntax for several object types.

ALTER PACKAGE my_package COMPILE;
ALTER PACKAGE my_package COMPILE BODY;
ALTER PROCEDURE my_procedure COMPILE;
ALTER FUNCTION my_function COMPILE;
ALTER TRIGGER my_trigger COMPILE;
ALTER VIEW my_view COMPILE;

Notice that the package body is compiled in the same way as the package specification, with the addition of the word “BODY” at the end of the command.

An alternative approach is to use the DBMS_DDL package to perform the recompilations.

EXEC DBMS_DDL.alter_compile('PACKAGE', 'MY_SCHEMA', 'MY_PACKAGE');
EXEC DBMS_DDL.alter_compile('PACKAGE BODY', 'MY_SCHEMA', 'MY_PACKAGE');
EXEC DBMS_DDL.alter_compile('PROCEDURE', 'MY_SCHEMA', 'MY_PROCEDURE');
EXEC DBMS_DDL.alter_compile('FUNCTION', 'MY_SCHEMA', 'MY_FUNCTION');
EXEC DBMS_DDL.alter_compile('TRIGGER', 'MY_SCHEMA', 'MY_TRIGGER');

This method is limited to PL/SQL objects, so it is not applicable for views.

Custom Script

In some situations you may have to compile many invalid objects in one go. One approach is to write a custom script to identify and compile the invalid objects. The following example identifies and recompiles invalid packages and package bodies.

SET SERVEROUTPUT ON SIZE 1000000
BEGIN
  FOR cur_rec IN (SELECT owner,
                         object_name,
                         object_type,
                         DECODE(object_type, 'PACKAGE', 1,
                                             'PACKAGE BODY', 2, 2) AS recompile_order
                  FROM   dba_objects
                  WHERE  object_type IN ('PACKAGE', 'PACKAGE BODY')
                  AND    status != 'VALID'
                  ORDER BY 4)
  LOOP
    BEGIN
      IF cur_rec.object_type = 'PACKAGE' THEN
        EXECUTE IMMEDIATE 'ALTER ' || cur_rec.object_type ||
            ' "' || cur_rec.owner || '"."' || cur_rec.object_name || '" COMPILE';
      ElSE
        EXECUTE IMMEDIATE 'ALTER PACKAGE "' || cur_rec.owner ||
            '"."' || cur_rec.object_name || '" COMPILE BODY';
      END IF;
    EXCEPTION
      WHEN OTHERS THEN
        DBMS_OUTPUT.put_line(cur_rec.object_type || ' : ' || cur_rec.owner ||
                             ' : ' || cur_rec.object_name);
    END;
  END LOOP;
END;
/

This approach is fine if you have a specific task in mind, but be aware that you may end up compiling some objects multiple times depending on the order they are compiled in. It is probably a better idea to use one of the methods provided by Oracle since they take the code dependencies into account.

DBMS_UTILITY.compile_schema

The COMPILE_SCHEMA procedure in the DBMS_UTILITY package compiles all procedures, functions, packages, and triggers in the specified schema. The example below shows how it is called from SQL*Plus.

EXEC DBMS_UTILITY.compile_schema(schema => 'SCOTT');

UTL_RECOMP

The UTL_RECOMP package contains two procedures used to recompile invalid objects. As the names suggest, the RECOMP_SERIAL procedure recompiles all the invalid objects one at a time, while the RECOMP_PARALLEL procedure performs the same task in parallel using the specified number of threads. Their definitions are listed below.

 PROCEDURE RECOMP_SERIAL(
   schema   IN   VARCHAR2    DEFAULT NULL,
   flags    IN   PLS_INTEGER DEFAULT 0);

PROCEDURE RECOMP_PARALLEL(
   threads  IN   PLS_INTEGER DEFAULT NULL,
   schema   IN   VARCHAR2    DEFAULT NULL,
   flags    IN   PLS_INTEGER DEFAULT 0);

The usage notes for the parameters are listed below.

• schema – The schema whose invalid objects are to be recompiled. If NULL all invalid objects in the database are recompiled.
• threads – The number of threads used in a parallel operation. If NULL the value of the “job_queue_processes” parameter is used. Matching the number of available CPUs is generally a good starting point for this value.
• flags – Used for internal diagnostics and testing only.

The following examples show how these procedures are used.

-- Schema level.
EXEC UTL_RECOMP.recomp_serial('SCOTT');
EXEC UTL_RECOMP.recomp_parallel(4, 'SCOTT');

-- Database level.
EXEC UTL_RECOMP.recomp_serial();
EXEC UTL_RECOMP.recomp_parallel(4);

-- Using job_queue_processes value.
EXEC UTL_RECOMP.recomp_parallel();
EXEC UTL_RECOMP.recomp_parallel(NULL, 'SCOTT');

There are a number of restrictions associated with the use of this package including:

• Parallel execution is perfomed using the job queue. All existing jobs are marked as disabled until the operation is complete.
• The package must be run from SQL*Plus as the SYS user, or another user with SYSDBA.
• The package expects the STANDARD, DBMS_STANDARD, DBMS_JOB and DBMS_RANDOM to be present and valid.
• Runnig DDL operations at the same time as this package may result in deadlocks.

utlrp.sql and utlprp.sql

The utlrp.sql and utlprp.sql scripts are provided by Oracle to recompile all invalid objects in the database. They are typically run after major database changes such as upgrades or patches. They are located in the $ORACLE_HOME/rdbms/admin directory and provide a wrapper on the UTL_RECOMP package. The utlrp.sql script simply calls the utlprp.sql script with a command line parameter of “0″. The utlprp.sql accepts a single integer parameter that indicates the level of parallelism as follows.

• 0 – The level of parallelism is derived based on the CPU_COUNT parameter.
• 1 – The recompilation is run serially, one object at a time.
• N – The recompilation is run in parallel with “N” number of threads.

Both scripts must be run as the SYS user, or another user with SYSDBA, to work correctly.

Nothing is carved in stone, but these are the sort of rules I follow:

• Entities & Tables
• Aliasing
• Attributes & Columns
• Keys & Their Columns
• Indexes
• Triggers
• Other Objects
• PL/SQL Variables
• File Extensions

Entities & Tables

All entity names should be singular and may have spaces. These are replaced with ‘_’ by Oracle Designer during table creation.

APPLICATION
APPLICATION FUNCTION
APPLICATION FUNCTION ROLE

All table names should be plural. If the table name contains serveral words, only the last one should be plural.

APPLICATIONS
APPLICATION_FUNCTIONS
APPLICATION_FUNCTION_ROLES

Aliasing

All entities and tables should be defined a unique alias that is used as part of the foreign key definitions. The alias should be an abbreviation of the name.

APPLICATIONS = APPL (4)
APPLICATION_FUNCTIONS = APFU (2:2)
APPLICATON_FUNCTION_ROLES = APFR (2:1:1)
APPLICATION_FUNCTION_ROLE_BANANAS = AFRB (1:1:1:1)
APPLICATION_FUNCTION_ROLE_BANANA_APPLES = (Do what you like!)

The bracketed numbers indicate the number of letters used from each word in the name.

Oracle has a 30 character restriction on object names, so table aliases are useful to reduce the length of object names.

Attributes & Columns

Attributes and columns should not be prefixed with a table alias. For the most part this is unnecessary and often very messy.

Keys & Their Columns

Primary Keys are named after the table or its alias with the suffix of ‘_PK’.

Table      : APPLICATIONS
Primary Key: APPLICATIONS_PK
             or
             APPL_PK

Unique Keys are named after the table or its alias with the suffix of ‘_UK’. If more than one unique key is present you may need to add further information to make the key name unique.

Table      : APPLICATIONS
Unique Key : APPLICATIONS_UK
             or
             APPL_UK

Foreign Keys are usually named using the two table aliases, from and to, with the suffix of ‘_FK’:

Relationship: APPLICATION_FUNCTIONS -> APPLCIATIONS
Foreign Key : APFU_APPL_FK

The foreign key column on the dependant table may be named using the full table name or the alias, along with the column name.

APPLICATION_FUNCTIONS.APPLICATION_ID -> APPLICATIONS.ID
or
APPLICATION_FUNCTIONS.APPL_ID -> APPLICATIONS.ID

I prefer the full table name, but the the 30 character limit forces the use of the alias at times.

Indexes

Indexes are created implicitly to support PKs and UKs. These indexes have the same name as the constraint.

As a rule of thumb, all foreign key columns should be indexed. Indexes to support foreign keys should be named using the foreign key name with the suffix ‘_I’.

Foreign Key    : APFU_APPL_FK
Suporting Index: APFU_APPL_FK_I

Other indexes should be created with meaningful names, usually incorporating the table alias and the column name(s) where possible, along with the suffix ‘_I’.

Triggers

Trigger names should be made up of the table name, an acronym representing the triggering action and the suffix “_TRG”.

Table : APPLICATIONS

Action: BEFORE INSERT STATEMENT-LEVEL
Name  : APPLICATION_BIS_TRG

Action: AFTER INSERT AND UPDATE ROW-LEVEL
Name  : APPLICATION_AIUR_TRG

Other Objects

Other database objects have a suffix that identifies their object type.

Check Constraints : <name>_CHK
Sequences         : <name>_SEQ
Views             : <name>_V
Materialized Views: <name>_MV
Types             : <name>_T
Directories       : <name>_DIR
External Tables   : <name>_EXT
PL/SQL Packages   : <name>_API
PL/SQL Procedures : <name>_PRC
PL/SQL Functions  : <name>_FUN

PL/SQL Variables

PL/SQL variables are prefixed with a single letter, if possible, to indiate their type or usage.

Package Global Variables: g_variable_name
Local Variables         : l_variable_name
Types                   : t_type_name
Cursors                 : c_cursor_name
Exceptions              : e_exception_name
Input Parameters        : i_parameter_name
Outut Parameters        : o_parameter_name
In/Out Parameters       : io_parameter_name

Sometimes I flip back to using a generic “p_” prefix for parameters, regardless of their IN/OUT usage. Old habits dies hard.

File Extensions

File extensions include:

.pks – Package specification.
.pkb – Package body.
.sql – Everything else.

The LAG and LEAD analytic functions were introduced in 8.1.6 to give access to multiple rows within a table, without the need for a self-join.

• Introduction
• LAG
• LEAD

Introduction

Both LAG and LEAD functions have the same usage, as shown below.

LAG  (value_expression [,offset] [,default]) OVER ([query_partition_clause] order_by_clause)
LEAD (value_expression [,offset] [,default]) OVER ([query_partition_clause] order_by_clause)

• value_expression – Can be a column or a built-in function, except for other analytic functions.
• offset – The number of rows preceeding/following the current row, from which the data is to be retrieved. The default value is 1.
• default – The value returned if the offset is outside the scope of the window. The default value is NULL.

Looking at the EMP table, we query the data in salary (SAL) order.

SELECT empno,
       ename,
       job,
       sal
FROM   emp
ORDER BY sal;

     EMPNO ENAME      JOB              SAL
---------- ---------- --------- ----------
      7369 SMITH      CLERK            800
      7900 JAMES      CLERK            950
      7876 ADAMS      CLERK           1100
      7521 WARD       SALESMAN        1250
      7654 MARTIN     SALESMAN        1250
      7934 MILLER     CLERK           1300
      7844 TURNER     SALESMAN        1500
      7499 ALLEN      SALESMAN        1600
      7782 CLARK      MANAGER         2450
      7698 BLAKE      MANAGER         2850
      7566 JONES      MANAGER         2975
      7788 SCOTT      ANALYST         3000
      7902 FORD       ANALYST         3000
      7839 KING       PRESIDENT       5000

SQL>

LAG

The LAG function is used to access data from a previous row. The following query returns the salary from the previous row to calculate the difference between the salary of the current row and that of the previous row. Notice that the ORDER BY of the LAG function is used to order the data by salary.

SELECT empno,
       ename,
       job,
       sal,
       LAG(sal, 1, 0) OVER (ORDER BY sal) AS sal_prev,
       sal - LAG(sal, 1, 0) OVER (ORDER BY sal) AS sal_diff
FROM   emp;

     EMPNO ENAME      JOB              SAL   SAL_PREV   SAL_DIFF
---------- ---------- --------- ---------- ---------- ----------
      7369 SMITH      CLERK            800          0        800
      7900 JAMES      CLERK            950        800        150
      7876 ADAMS      CLERK           1100        950        150
      7521 WARD       SALESMAN        1250       1100        150
      7654 MARTIN     SALESMAN        1250       1250          0
      7934 MILLER     CLERK           1300       1250         50
      7844 TURNER     SALESMAN        1500       1300        200
      7499 ALLEN      SALESMAN        1600       1500        100
      7782 CLARK      MANAGER         2450       1600        850
      7698 BLAKE      MANAGER         2850       2450        400
      7566 JONES      MANAGER         2975       2850        125
      7788 SCOTT      ANALYST         3000       2975         25
      7902 FORD       ANALYST         3000       3000          0
      7839 KING       PRESIDENT       5000       3000       2000

SQL>

LEAD

The LEAD function is used to return data from the next row. The following query returns the salary from the next row to calulate the difference between the salary of the current row and the following row.

SELECT empno,
       ename,
       job,
       sal,
       LEAD(sal, 1, 0) OVER (ORDER BY sal) AS sal_next,
       LEAD(sal, 1, 0) OVER (ORDER BY sal) - sal AS sal_diff
FROM   emp;

     EMPNO ENAME      JOB              SAL   SAL_NEXT   SAL_DIFF
---------- ---------- --------- ---------- ---------- ----------
      7369 SMITH      CLERK            800        950        150
      7900 JAMES      CLERK            950       1100        150
      7876 ADAMS      CLERK           1100       1250        150
      7521 WARD       SALESMAN        1250       1250          0
      7654 MARTIN     SALESMAN        1250       1300         50
      7934 MILLER     CLERK           1300       1500        200
      7844 TURNER     SALESMAN        1500       1600        100
      7499 ALLEN      SALESMAN        1600       2450        850
      7782 CLARK      MANAGER         2450       2850        400
      7698 BLAKE      MANAGER         2850       2975        125
      7566 JONES      MANAGER         2975       3000         25
      7788 SCOTT      ANALYST         3000       3000          0
      7902 FORD       ANALYST         3000       5000       2000
      7839 KING       PRESIDENT       5000          0      -5000

SQL>

1.1 General Objects / Tables / Columns

1.2 Invalids / Compiling

1 .3 Bugs and Patching

1.4 Other Objects

1.5 Helpful SQL Syntax

1.5.1 Rowid:
Working with Rowids: rowidtochar(rowid) and chartorowid(‘AAABUeAAQAAACsjAAg’)

1.5.2 Date Columns
a. Converting dates to show date with time: to_char(<date> ‘DD-MON-YYYY HH24:MI:SS’)
For example: select to_char(sysdate, ‘DD-MON-YYYY HH24:MI:SS’) from dual;
b. Comparing date columns — Sometimes handy to skip the time portion when searching for dates. You can use the trunc command to strip the time off. This resets the time to midnight.
For example: select to_char(trunc(sysdate), ‘DD-MON-YYYY HH24:MI:SS’) from dual;

2. Foundation (FND/ATG/AOL)

2.1 SQL related to Oracle Application Messages

2.2. Review Oracle Application Programs

a. Looking for trace files

b. Another for programs and managers:

c. Concurrent program statuses

d. Submitted Concurrent Programs

e. Ensure trace is disabled
The best way is to check via the forms System Administrator > Concurrent > Programs > Define. This is just a quick update to change trace enabled to no.

2.3. Users and Responsibilities

a. Basic user check

b. Active users

c. Users with a responsibility
There is also a similar concurrent program “Users of a Responsibility”.

d. Values of a profile option
It is sometimes hard to know where a profile option is set. A user might have a profile option set, an application, responsibility, and these might result in unexpected results. The following prompts for the profile name that a user sees. You could also query for the internal profile code instead by using the column a.profile_option_name instead.

2.4 Set Context / Initialize

Sometimes you want to run queries that reference profile options. To do this, you should first initialize the context of the current session to the user, responsibility and application being used. You can also set the context of the current inventory organization for queries that reference the organization context.

a. Set context

b. Set organization

3. Manufacturing

3.1 Manufacturing General

3.2. Setup

3.2.1. Inventory

a. Transaction types

b. Transaction sources:

3.3. Transactions

3.3.1. Inventory Transactions

a. Stuck interface transactions (Group By)

b. Stuck pending transactions (Group By)

c. Stuck move order transactions (Group By)

d. Uncosted transactions (Group By)

e. Dump information about transaction tables

When using RAC or ASM under Oracle 10g Release 2 or above, the Oracle Clusterware automatically starts and stops the Oracle database instances, so the following procedures are not necessary. For all other cases, you can use the methods described below.

• The “su” Command
• The “rsh” Command
• Known Issues

The “su” Command

The following represents the Oracle recommended method for automating database startup and shutdown of Oracle 9i instances.

Once the instance is created, edit the “/etc/oratab” file setting the restart flag for each instance to ‘Y’.

TSH1:/u01/app/oracle/product/9.2.0:Y

Next, create a file called “/etc/init.d/dbora” as the root user, containing the following.

#!/bin/sh
# chkconfig: 345 99 10
# description: Oracle auto start-stop script.
#
# Set ORA_HOME to be equivalent to the $ORACLE_HOME
# from which you wish to execute dbstart and dbshut;
#
# Set ORA_OWNER to the user id of the owner of the
# Oracle database in ORA_HOME.

ORA_HOME=/u01/app/oracle/product/9.2.0
ORA_OWNER=oracle

if [ ! -f $ORA_HOME/bin/dbstart ]
then
    echo "Oracle startup: cannot start"
    exit
fi

case "$1" in
    'start')
        # Start the Oracle databases:
        # The following command assumes that the oracle login
        # will not prompt the user for any values
        su - $ORA_OWNER -c "$ORA_HOME/bin/lsnrctl start"
        su - $ORA_OWNER -c $ORA_HOME/bin/dbstart
        touch /var/lock/subsys/dbora
        ;;
    'stop')
        # Stop the Oracle databases:
        # The following command assumes that the oracle login
        # will not prompt the user for any values
        su - $ORA_OWNER -c $ORA_HOME/bin/dbshut
        su - $ORA_OWNER -c "$ORA_HOME/bin/lsnrctl stop"
        rm -f /var/lock/subsys/dbora
        ;;
esac

Use the chmod command to set the privileges to 750.

chmod 750 /etc/init.d/dbora

Associate the dbora service with the appropriate run levels and set it to auto-start using the following command.

chkconfig --add dbora

The relevant instances should now startup/shutdown automatically at system startup/shutdown.

This method can still be used under Oracle 10g and 11g, provided the “ORA_HOME” variable is amended to use the correct path and this is added to the end of the dbstart and dbshut lines. The lines to start and stop the listener can be removed under Oracle 10g release 2, as the dbstart command includes an automatic start of the listener.

#!/bin/sh
# chkconfig: 345 99 10
# description: Oracle auto start-stop script.
#
# Set ORA_HOME to be equivalent to the $ORACLE_HOME
# from which you wish to execute dbstart and dbshut;
#
# Set ORA_OWNER to the user id of the owner of the
# Oracle database in ORA_HOME.

ORA_HOME=/u01/app/oracle/product/10.2.0/db_1
#ORA_HOME=/u01/app/oracle/product/11.1.0/db_1
#ORA_HOME=/u01/app/oracle/product/11.2.0/db_1
ORA_OWNER=oracle

if [ ! -f $ORA_HOME/bin/dbstart ]
then
    echo "Oracle startup: cannot start"
    exit
fi

case "$1" in
    'start')
        # Start the Oracle databases:
        # The following command assumes that the oracle login
        # will not prompt the user for any values
        su - $ORA_OWNER -c "$ORA_HOME/bin/dbstart $ORA_HOME"
        touch /var/lock/subsys/dbora
        ;;
    'stop')
        # Stop the Oracle databases:
        # The following command assumes that the oracle login
        # will not prompt the user for any values
        su - $ORA_OWNER -c "$ORA_HOME/bin/dbshut $ORA_HOME"
        rm -f /var/lock/subsys/dbora
        ;;
esac

The “rsh” Command

With Oracle 10g, Oracle switched from recommending the “su” command to the “rsh” command. In Oracle 10g release 2, the dbstart command includes an automatic start of the listener, so there are some differences between the two versions, but the following represents the preferred method for Oracle 10g.

Once the instance is created, edit the “/etc/oratab” file setting the restart flag for each instance to ‘Y’.

TSH1:/u01/app/oracle/product/9.2.0:Y

Next, create a file called “/etc/init.d/dbora” as the root user, containing the following.

#!/bin/sh
# chkconfig: 345 99 10
# description: Oracle auto start-stop script.
#
# Change the value of ORACLE_HOME to specify the correct Oracle home
# directory for your installation.

ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1
#
# Change the value of ORACLE to the login name of the
# oracle owner at your site.
#
ORACLE=oracle

PATH=${PATH}:$ORACLE_HOME/bin
HOST=`hostname`
PLATFORM=`uname`
export ORACLE_HOME PATH
#
if [ ! "$2" = "ORA_DB" ] ; then
   if [ "$PLATFORM" = "HP-UX" ] ; then
      remsh $HOST -l $ORACLE -n "$0 $1 ORA_DB"
      exit
   else
      rsh $HOST -l $ORACLE  $0 $1 ORA_DB
      exit
   fi
fi
#
case $1 in
'start')
        $ORACLE_HOME/bin/dbstart $ORACLE_HOME
        touch /var/lock/subsys/dbora
        ;;
'stop')
        $ORACLE_HOME/bin/dbshut $ORACLE_HOME
        rm -f /var/lock/subsys/dbora
        ;;
*)
        echo "usage: $0 {start|stop}"
        exit
        ;;
esac
#
exit

Use the chmod command to set the privileges to 750.

chmod 750 /etc/init.d/dbora

Associate the dbora service with the appropriate run levels and set it to auto-start using the following command.

chkconfig --add dbora

The relevant instances should now startup/shutdown automatically at system startup/shutdown.

This method relies on the presence of an RSH server, which requires additional packages and configuration.

# Install the rhs and rsh-server packages from the OS CD/DVD.
rpm -Uvh --force rsh-*

# Enable rsh and rlogin.
chkconfig rsh on
chkconfig rlogin on
service xinetd reload

This can be quite problematic when attempting to use this method under later Linux distributions, where rsh is deprecated. As a result, I prefer to use the “su” command method.

This method can also be used for 11g databases that are not using ASM or RAC.

Known Issues

When using Oracle 10g Release 2, calling dbstart might result in the following error message.

Failed to auto-start Oracle Net Listener using /ade/vikrkuma_new/oracle/bin/tnslsnr

This is due to a hard coded path in the dbstart script. You should not see this error if you pass the “$ORACLE_HOME” as a parameter to dbstart and dbshut. To correct this, edit the “$ORACLE_HOME/bin/dbstart” script and replace the following line (approximately line 78).

ORACLE_HOME_LISTNER=/ade/vikrkuma_new/oracle

With this.

ORACLE_HOME_LISTNER=$ORACLE_HOME

The dbstart script should now start the listener as expected.