This chapter identifies postinstallation configuration tasks you must complete after installation. The following topics are covered in this chapter:
If you have performed any of the following silent installations, you must run the allroot.sh
script to complete the installation:
Enterprise Manager Using New Database
If you have selected this installation option, you must execute the allroot.sh
script from the database Oracle home (db10g
). For example:
/scratch/OracleHomes/db10g/allroot.sh
Enterprise Manager Using Existing Database
If you have selected this installation option, execute the allroot.sh
script from the Management Service Oracle home (oms10g
). For example:
/scratch/OracleHomes/oms10g/allroot.sh
Additional Management Service
If you have selected this installation option, execute the allroot.sh
script from the Management Service Oracle home (oms10g
). For example:
/scratch/OracleHomes/oms10g/allroot.sh
Execute the root.sh
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 allroot.sh
or root.sh (depending on the installation type selected) before completing your installation.
On the Management Service machine, run the root.sh
script as the root
user from the $ORACLE_HOME
directory.
Note:
For a cluster installation, you must run theroot.sh
script on each host of the cluster on which you installed a Management Agent.You may want to check the following settings for your Management Repository database to make sure they are set correctly.
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.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.
Oracle recommends that you do not put the Management Repository database in QUIESCE
mode. Check your Resource Plan for INTERNAL_QUIESCE
.
Navigate to the Database Home page of your Management Repository.
On the Administration property screen, under Resource Manager, click Resource Plans.
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.
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:
Go to http://metalink.oracle.com
and navigate to the Patches and Updates screen.
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.
Specify emgrid
and click Search. The search results display all the patch or patch sets that match the parameters you have specified.
Select the appropriate patch or patch set and download it to the Management Service Oracle home location.
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.
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.
You can perform the following configuration activities, if required:
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:
On the Enterprise Manager Grid Control Home page, click Setup.
On the Setup screen, click Patching Setup.
Specify your OracleMetaLink user name and password in the fields provided.
The URL (http://updates.oracle.com
) 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:
http://metalink.oracle.com
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.
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 environmentIf Enterprise Manager is using a proxy server for external access, the following properties must be properly set in the <OMS_HOME>/sysman/config/emoms.properties
file:
proxyHost=www-fooproxy.here.com proxyPort=80 dontProxyFor=here.com
See Also:
Oracle Enterprise Manager Advanced Configuration for more information on configuring the Management Service properties fileYou can also specify domain names that cover all hosts with those domains. For example:
dontProxyFor=us.mycompany.com, uk.mycompany.com
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.
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.
Note:
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:
Unlock the DBSNMP User Account (if necessary).
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 |
---|---|
-n |
Specify the cluster name (CLUSTER_NAME). |
-c |
Specify a comma-separated cluster node list. |
-t |
Do not start the agent after reconfiguration or target rediscovery. |
-d |
Rediscover targets. |
-f |
Reconfigure agents. |
-i |
Specify the |
-h |
Get information on all the available options. |
Note:
You must specify either the-f
or -d
option when executing this script. Using one of these two options is mandatory.Caution:
Do not use theagentca -f
option to reconfigure any upgraded agent (standalone and RAC).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 ]
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 ]
Note:
The-c
option must comprise all the nodes (including the local machine) to update the inventory.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.
Note:
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]
Note:
The-c
option must comprise all the nodes (including the local machine) to update the inventory.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]
Note:
The-c
option must comprise all the nodes (including the local machine) to update the inventory.Caution:
You run this script on only one node at a time.