| Previous | Table of Contents | Next |
The Enterprise Manager Repository is simply a collection of tables used to store information about an organization’s database environment and tasks that the DBA wants to perform. If you monitor your databases for an event, schedule a job, or group several databases into a group—all this is stored in the Repository.
There are a few things to keep in mind as you plan for your Repository. First, you should build a Repository for each administrator, unless all your administrators will be sharing one central console. Second, you should not create multiple repositories owned by the same Oracle user ID, even though they are stored in separate databases. If you don’t follow these rules, the messages passing between the console and the Intelligent Agents could, and most likely will, be misrouted.
You can create the Repository in any database to which the console will have access. First, create a tablespace to hold the Repository data. Next, create a Repository owner with DBA privileges and make the user’s default tablespace the one you just created. Listing 21.1 shows a tablespace and user being created for this purpose using SQL Worksheet.
Listing 21.1. Creating the Repository tablespace and owner.
SQLWKS> create tablespace oem_data
2> datafile ‘C:\ORANT\DATABASE\oemdata.ora’ size 30M
3> default storage (initial 48K next 256K)
4>
Statement processed.
SQLWKS> create user oemown identified by oemown
2> default tablespace oem_data
3> temporary tablespace temp
4> quota unlimited on oem_data
5>
Statement processed.
SQLWKS> grant dba to oemown
2>
Statement processed.
After you create the tablespace and Repository owner ID, building the Repository is a simple matter. In fact, there are several ways you can build your Repository. Probably the easiest is to let Enterprise Manager step you through the process the first time you sign on.
Select the Enterprise Manager icon from the Oracle Enterprise Manager program group. Enter the ID, password, and connect string for the Repository owner when the sign-on screen appears. Because the Repository tables do not exist yet, Enterprise Manager asks whether you would like to build a new Repository. Click the OK button and OEM will display the steps it is following as it builds the Repository.
If you have any problems with the automatic build of the Repository described previously, you can use the Repository Manager, also located in the Oracle Enterprise Manager program group. The Repository Manager enables you to create, drop, or validate the Repository for any OEM component.
For those of you who love the command line, you can still manually build the Repository from a DOS prompt. See the appendixes in the Oracle Enterprise Manager Configuration Guide for a description of the vobsh utility.
If you are configuring an Intelligent Agent to run on a UNIX server, it is much easier than it used to be as long as the server’s SQL*Net (or Net8) configuration files are present and are formatted correctly. In earlier releases you had to run some scripts to create a database user ID for the Agent in each of your databases. You then had to edit an snmp.ora file and key in the appropriate information for each of the databases and listeners you intended to monitor.
Tip:
If you are having trouble getting the service discovery feature of the Intelligent Agent to work, try generating a new set of SQL*NET configuration files (*.ora) using Oracle Network Manager. This produces some nicely formatted files, and the Agent sometimes has better luck using these files to create its own configuration files.
The more recent releases of Oracle and the Intelligent Agent have simplified this process. The Agent user ID, dbsnmp, is created in the database when you run the scripts to build your catalog. After the Intelligent Agent is installed, start the Agent by typing lsnrctl dbsnmp_start. On some platforms, you will receive a message that an SNMP master agent could not be found. You can ignore this message and just press the Enter key.
The first time the Intelligent Agent is started, it will check for the existence of its configuration files, and because they are not there yet, the Agent will gather the information it needs to create them. First, the Agent will read /etc/oratab to obtain the names of the SIDs and the Oracle home for each SID. Next, it will read the listener.ora file to see which listeners are servicing the various SIDs. If a GLOBAL_DBNAME parameter exists in listener.ora, the Agent assumes Oracle Names is being used to resolve service names, and the global name is used in the Agent’s configuration files. If there is no GLOBAL_DBNAME entry, tnsnames.ora is read to determine the service name of each SID. If no entry exists in tnsnames.ora, the Agent uses <sid>_<hostname> for the service name.
After it has collected this information, the Agent creates its configuration files, snmp_ro.ora, snmp_rw.ora, and services.ora in $ORACLE_HOME/network/admin. As you might have guessed, the ro and rw stand for read-only and read/write. You can add additional parameters to the snmp_rw.ora file, if you want to specify a new password for the dbsnmp database ID, for example. You should never edit snmp_ro.ora. As you add new services, the Agent will take care of updating this file each time you start and stop the Agent. See the “Sample Net8 Configuration Files” section at the end of this chapter for working examples of *.ora files.
Tip:
Some documentation might lead you to believe that OEM versions 1.4 and higher will work with the Intelligent Agent delivered with the 7.3.2 release of Oracle. This is not true. If you have servers running 7.3.2 or earlier, save yourself a tremendous amount of time by installing a 7.3.3 or newer Agent in order to use OEM 1.4 or OEM 1.5.
| Previous | Table of Contents | Next |