Skip Headers
Oracle® Enterprise Manager Grid Control Installation and Basic Configuration
10g Release 2 (10.2)

Part Number B16228-05
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Feedback page
Contact Us

Go to previous page
Go to next page
PDF · Mobi · ePub

7 Postinstallation Configuration Tasks

This chapter identifies postinstallation configuration tasks you must complete after installation. The following topics are covered in this chapter:

Running to Complete the Installation Process (UNIX Only)

If you have performed any of the following silent installations, you must run the script to complete the installation:

Execute the script from the agent Oracle home if you have performed a silent installation of only the Management Agent.

This script finishes the postinstallation steps for the Management Agent, Management Service, and Management Repository database. If you used interactive mode to install Enterprise Manager, you are prompted to run or (depending on the installation type selected) before completing your installation.

On the Management Service machine, run the script as the root user from the $ORACLE_HOME directory.


For a cluster installation, you must run the script on each host of the cluster on which you installed a Management Agent.

Checking Database Settings

You may want to check the following settings for your Management Repository database to make sure they are set correctly.

UNDO Tablespace and Temporary Tablespace

Oracle recommends that the Management Repository database have the Tablespace and the Temporary Tablespace set to UNDO and AUTOEXTEND ON, respectively.

See Also:

Managing the UNDO Tablespace chapter of the Oracle Database Administrator's Guide for more information.

Archive Logging

Oracle recommends that the Management Repository database have archive logging turned on for any environment where continuity of data is important. Regular backups are also recommended.

Ensure the Database is Not in QUIESCE Mode

Oracle recommends that you do not put the Management Repository database in QUIESCE mode. Check your Resource Plan for INTERNAL_QUIESCE.

  1. Navigate to the Database Home page of your Management Repository.

  2. On the Administration property screen, under Resource Manager, click Resource Plans.

  3. Make sure INTERNAL_QUIESCE has not been selected.

In QUIESCE mode, only DBA transactions are processed; all other transactions are suspended. Putting the Management Repository database in the QUIESCE mode suspends Enterprise Manager transactions.

Accessing the OracleMetaLink Web Site

You can search OracleMetaLink for Oracle software patches and patchsets, and download these patches or patch sets to an appropriate location in the Management Service Oracle home of Enterprise Manager.

To locate the required patches or patch sets in MetaLink:

  1. Go to and navigate to the Patches and Updates screen.

  2. Here, you can either perform a simple search with limited parameters, or click Advanced Search to perform a more granular (detailed) search. On this screen, you can search for updates based on the patch type (patches or patch sets), product name, platform, patch number, and so on.

  3. Specify emgrid and click Search. The search results display all the patch or patch sets that match the parameters you have specified.

  4. Select the appropriate patch or patch set and download it to the Management Service Oracle home location.

Accessing Management Packs

Oracle offers a number of management packs for Oracle Database and Oracle Application Server. For example, management packs available with the Oracle Enterprise Manager 10g Release 2 include: Database Change Management Pack, Database Configuration Pack, Database Diagnostics Pack, and Database Tuning Pack. Oracle Application Server supports the following packs: Application Server Configuration Pack and Application Server Diagnostics Pack.Each pack has several premium features bundled as part of that pack. The licensable targets (also called parent targets) that are granted access to the packs propagate that access to their dependent targets. For example, all packs that are granted to a database propagate to the host on which the database resides.

For example, if databases D1, D2, and D3 reside on host H1, and the user has access to the Database Tuning pack for database D1, then not only is the D1 database granted access to the Database Tuning pack, but the host H1 is granted access to this pack as well.

You can manage, that is grant and revoke, access to packs for various databases and application servers in your Enterprise Manager repository by using the Management Pack Access option available from the Setup screen. This Management Pack Access function is available only for super administrators.

Impact of Management Packs on Targets

Whether a target has access to a pack or not has a very significant impact on the user experience. The corresponding links related to the target, which need the pack, are enabled or disabled accordingly.To know what packs a screen needs, as well as the links in that screen, click Show Management Pack Information in the screen footer.When the access to a pack is removed from a target, all corresponding links that need this pack are disabled.

Identifying the Features that Can Be Accessed in Enterprise Manager

When one or more packs on a target monitored by Enterprise Manager are not licensed, access to premium functions for that target is disabled.For example, the Blackout button located on a Target home page (which you can use to move the target to the blackout state), is enabled only when either the Oracle Database Diagnostics Pack or the Oracle Application Server Diagnostics Pack is licensed for that target. To determine the packs used by the current screen and to know what packs need to be licensed for any link on that screen to be enabled, click Show Management Pack Information in the footer of the Enterprise Manager Home page. Enterprise Manager displays this information for all pages you navigate to during that session.

For more information on working with Management Packs, refer to the Enterprise Manager online Help.

Optional Configurations

You can perform the following configuration activities, if required:

Specifying the OracleMetaLink Credentials

Enterprise Manager uses OracleMetaLink credentials to search for and download MetaLink patches. If you did not specify your OracleMetaLink credentials during installation, you can do the following:

  1. On the Enterprise Manager Grid Control Home page, click Setup.

  2. On the Setup screen, click Patching Setup.

  3. Specify your OracleMetaLink user name and password in the fields provided.

The URL ( to access the OracleMetaLink Web site appears in the Patch Search URL field on this screen.

Access OracleMetaLink directly by going to the following Web site:

From this screen, Oracle licensees can register for an account or log in with an existing account. Once logged in, you can search for and download patches.

Setting Up Proxy Configuration for the Management Service

If your firewall prevents you from accessing Web sites without the use of an HTTP proxy, then you must set the proxy settings for Enterprise Manager to access OracleMetaLink.

See Also:

Oracle Enterprise Manager Advanced Configuration for information on configuring Enterprise Manager components, such as Management Agents and Beacons, for use in a firewall environment

If Enterprise Manager is using a proxy server for external access, the following properties must be properly set in the <OMS_HOME>/sysman/config/ file:

See Also:

Oracle Enterprise Manager Advanced Configuration for more information on configuring the Management Service properties file

You can also specify domain names that cover all hosts with those domains. For example:,

If the proxy properties are set incorrectly or not set at all, and you try to search for a patch, you receive an error message indicating that Enterprise Manager cannot access the OracleMetaLink Web site.

Configuring Database and ASM Targets for Monitoring

When you first view the Database Home page for an Oracle Database 10g target, the Database Home page may display no monitoring data and the status of the database may indicate that there is a metric collection error. This is because the DBSNMP password has not been configured, or has been locked due to unsuccessful login attempts.

Similarly, the first time you display the home page for an Automatic Storage Management (ASM) target, the status of the ASM instance may be unknown or unavailable, and the home page may indicate that the Management Agent is unavailable (down). Again, this is because you need to supply the ASM SYS password.


You may first need to unlock the DBSNMP user account before setting the monitoring credentials. If the account is not locked, skip Chapter10, "Unlock the DBSNMP User Account" in the next chapter and proceed to Chapter10, "Set Monitoring Credentials" for instructions.

To fix this problem for an Oracle Database target, do the following from the Grid Control console:

  1. Unlock the DBSNMP User Account (if necessary).

  2. Set Monitoring Credentials.

Agent Reconfiguration and Rediscovery

The Agent Configuration Assistant (agentca) script is used to reconfigure the agent and rediscover the targets on the machine. This script is useful when you want to rediscover a newly added target on the machine or to convert a standalone agent to a Oracle RAC Agent.

You can make use of the following options in the agentca script.

Table 7-1 Agent Configuration Assistant Script Options

Option Description


Specify the cluster name (CLUSTER_NAME).


Specify a comma-separated cluster node list.


Do not start the agent after reconfiguration or target rediscovery.


Rediscover targets.


Reconfigure agents.


Specify the oraInst.loc (oracle inventory location). This is required when the Oracle home does not exist in the central inventory.


Get information on all the available options.


You must specify either the -f or -d option when executing this script. Using one of these two options is mandatory.


Do not use the agentca -f option to reconfigure any upgraded agent (standalone and RAC).

Rediscover and Reconfigure Targets on Standalone Agents

An agent automatically discovers all targets that are installed before the agent installation. Typically, rediscovering of targets is performed when you have installed new targets after an agent installation.

To rediscover new targets, execute agentca. The usage is as follows:

<Agent_Home>/bin/agentca -d [ -t -i oraInstloc ]

Reconfiguring a Standalone Agent to an Oracle RAC Agent

Reconfiguration of a standalone agent occurs when you want to configure this agent (with standalone configurations) as a Oracle RAC agent.

To reconfigure a standalone agent as a Oracle RAC agent, you must execute the agentca script with the following options:

<Agent_Home>/bin/agentca -f -c "node1,node2…." [-t -i oraInstloc -n CLUSTER_NAME ]


The -c option must comprise all the nodes (including the local machine) to update the inventory.

Reconfiguring an Existing RAC Agent

If you have added new nodes to an existing Oracle RAC, you can invoke the agentca script to automatically reconfigure the existing Oracle RAC agent. The agentca script updates the central inventory to add the new nodes information, and also discovers the new targets (if any).

When this script is executed, it takes a back-up of the EMSTATE directory on the local machine and creates a new EMSTATE directory.


You must run this script on only one node at a time.

To reconfigure an existing Oracle RAC agent, execute agentca as follows:

prompt> <Agent_Home>/bin/agentca -f  -c "node1,node2,node3....." [-t -i oraInst.loc -n CLUSTER_NAME] 


The -c option must comprise all the nodes (including the local machine) to update the inventory.

Rediscovering Targets on a Oracle RAC Agent

You can rediscover the new targets that have been installed on Oracle RAC nodes by running the agent configuration assistant with the following options.

prompt> <Agent_Home>/bin/agentca -d  -c "node1,node2,node3....." [-t -i oraInst.loc -n CLUSTER_NAME] 


The -c option must comprise all the nodes (including the local machine) to update the inventory.


You run this script on only one node at a time.