Skip Headers
Oracle® Enterprise Manager Configuration Change Console Installation Guide
10g Version 10.2.0.5 for Windows or UNIX

E15311-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

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

1 Database Installation Pre-Installation Tasks

The installation of the Configuration Change Console and its components must be executed in the order documented below:

  1. Oracle database installation and configuration

  2. Configuration Change Console Server installation and configuration

  3. Configuration Change Console Agent installation

Before installing the database, read through the following preparatory tasks.

Determining Database Size

This section provides a guideline for database sizing. It does not necessarily reflect every environment.

The size of the database correlates with the number of expected changes, rather than the number of devices being monitored.The first table shows monthly change counts that might exist in some environments based on the expected change rates. A low change rate would mean that not very many changes happen on the rules sets that are configured. These can be used as a guideline when estimating how many changes you might expect to collect over a month. If your database purging configured for 90 days, these numbers must be multiplied by 3.

Table 1-1 Example Monthly Event Counts vs. Number of Agents

Number of Agents Low Change Rate (5 changes per agent per day) Nominal Change Rate (30 changes per agent per day) High Change Rate (100 changes per agent per day) Very High Change Rate (500 changes per agent per day)

100

15K

90K

300K

1.5M

250

39K

234K

780K

3.9M

500

78K

468K

1.6M

8.0M

1000

155K

930K

3.1M

15.5M

2500

388K

2.3M

7.8M

--

5000

775K

4.7M

15.5M

--

10000

1.6M

9.3M

--

--

15000

2.3M

13.8M

--

--


(Note: Cells with "--" represent extremely large environments that may require special configurations beyond what is supported with the out-of-the-box product.)

The next table shows the estimated Configuration Change Console tablespaces size versus the number of changes in the environment. The number of changes shown in the table reflects the number of changes the application can retain in its repository. If you have your data purging set to three months, then you would find the number of changes you expect in a three month period. The previous table showed some example total change counts for one month.

If you were storing events for three months, you would need to multiply the estimated change counts in the previous table by three.

Table 1-2 Minimum Tablespace Size vs. Change Counts

Total number of changes stored in repository GATEWAY Tablespace GATEWAY_LGDATA Tablespace GATEWAY_INDEX Tablespace Total Minimum Tablespace size

100K

2GB

2GB

4GB

8GB

500K

2GB

2GB

4GB

8GB

1.0M

3GB

2GB

4GB

9GB

5.0M

4GB

3GB

6GB

13GB

10.0M

6GB

4GB

8GB

18GB

20.0M

8GB

12GB

24GB

34GB

50.0M

10GB

30GB

60GB

100GB

100.0M

15GB

60GB

120GB

195GB


Note that if the tablespace is not sufficient in size, there may be data loss should the database become full. Once the database reaches its capacity you will receive an error message in your server log. You will be able to see this under the Administration > Server Reports > Server and Database Logs screen. Any new data will not be saved and users will not be able to log in to the product. To prevent data loss and user lockout, it is best to over-estimate the space needed for your database or leave a small buffer of disk space for auto-extension of the tablespace.

This table does not include other tablespaces such as TEMP and UNDO or Redo logs. You must allocate an appropriate amount of disk space for these based on your own best practices.

System Requirements

The specific operating system requirements for the database server are contingent on the required database size. All operating systems on which an Oracle database can operate are supported.

The following table lists some suggestions for various sizes of environments. These can change depending on many factors in a specific customer environment, but can be used as a rough guideline to follow.

Table 1-3 Recommended Size for Environments

Number of Agents Change Rate Database Hosts CPUs/Host Physical Memory Minimum Disk Space

100

Nominal

1

1 dual-core 3 GHz

4 GB

30 GB

1000

Nominal

1

2 dual-core 3 GHz

4 GB

40 GB

5000

Nominal

1

--

8 GB

60 GB

15,000

Nominal

1

4 dual-core 3 GHz

8 GB

150 GB

1000

Very High

1

4 dual-core 3 GHz

8 GB

150 GB


Deployment sizes are based on the sizing section in the documentation above. Total Recommended Disk Space includes the three Configuration Change Console tablespaces as well as Database software, Temp, and Undo tablespace size. Minimum recommended disk space is based on saving raw events for only 3 months and utilizing the majority of Configuration Change Console features.

Considerations For High Scale Environments

When setting up a database for a high change rate environment, there are several factors that must be taken into account. Use the following recommendations regarding the database the Configuration Change Console uses for its repository.

Fast Disk, Filesystem I/O for REDO Logs

The disk on which the REDO logs are located should be as fast as possible and should be dedicated for REDO logs only. If your database uses a RAID disk structure, the REDO logs should be located on disks using RAID1. A RAID5 disk layout is too slow for the REDO logs. In addition, you can alternate REDO logs onto different disks to minimize the effect of the archiver on the log writer.

If the disk on which the REDO logs is on is too slow, or if the filesystem I/O to the REDO log files is too slow, the database will see transaction timeouts due to high I/O waits on the logs.

Log Writer Write Performance and I/O Subsystem Settings

Whenever possible, the database should make use of the best/optimal performance settings supported for Oracle DB performance in the available I/O subsystem in the environment. For example, the Oracle database can make use of Direct I/O bypassing Vendor/OS buffer cache in writes to redo log as well as data files. In addition the Oracle database can also make use of Asynchronous I/O. By default, Oracle DB initialization parameter disk_asynch_io is set to true (useful for ASM/raw devices usage). The parameter filesystemio_options should also be checked to ensure the proper value is used for your environment. For Operating System and File Systems where Direct I/O as well as Async I/O is supported, the database should be configured to make use of it.

VLM Configuration for Windows 32-Bit

The Oracle DB process in Windows can only make use of extra RAM available through PAE/AWE above the 4GB limit for data segments (buffer cache) only. All other process address space components need to fit within the theoretical 1.7 or 2.7GB limit (in case of /3GB ).

Also the AWE_WINDOW_MEMORY setting must be set in the registry as mentioned here and it must be greater than or equal to 1GB default limit.

The requirements for taking advantage of this support are:

  1. The computer on which Oracle Database is installed must have more than 4 GB of memory.

  2. The operating system must be configured to take advantage of Physical Address Extensions (PAE) by adding the /PAE switch in boot.ini. See Microsoft Knowledge Base article Q268363 for instructions on modifying boot.ini to enable PAE.

  3. It is advisable to enable 4GT support by adding the /3GB parameter in boot.ini. See Microsoft Knowledge Base article Q171793 for additional requirements and instructions on modifying boot.ini to enable 4GT.

  4. The user account under which Oracle Database runs (typically the LocalSystem account), must have the Lock memory pages Windows 2000 and Windows XP privilege.

  5. USE_INDIRECT_DATA_BUFFERS=TRUE must be present in the initialization parameter file for the database instance that will use VLM support. If this parameter is not set, then Oracle Database 10g Release 1 (10.1) or later behaves in exactly the same way as previous releases. Initialization parameters DB_BLOCK_BUFFERS and DB_BLOCK_SIZE must be set to values you have chosen for Oracle Database.

  6. The total number of bytes of database buffers (that is, DB_BLOCK_BUFFERS multiplied by DB_BLOCK_SIZE) is no longer limited to 3 GB.

    Dynamic SGA and multiple block size are not supported with VLM. When VLM is enabled, the following new buffer cache parameters are not supported:

    DB_CACHE_SIZE
    DB_2K_CACHE_SIZE
    DB_4K_CACHE_SIZE
    DB_8K_CACHE_SIZE
    DB_16K_CACHE_SIZE
    DB_32K_CACHE_SIZE
  7. Registry parameter AWE_WINDOW_MEMORY must be created and set in the appropriate key for your Oracle home. This parameter is specified in bytes and has a default value of 1 GB. AWE_WINDOW_MEMORY tells Oracle Database how much of its 3 GB address space to reserve for mapping in database buffers. This memory comes from the 3 GB virtual address space in Oracle Database, so its value must be less than 3 GB. Setting this parameter to a large value has the effect of using more of the address space for buffers and using less AWE memory for buffers. However, since accessing AWE buffers is somewhat slower than accessing virtual address space buffers, Oracle recommends that you tune these parameters to be as large as possible without adversely limiting database operations.

    In general, the higher AWE_WINDOW_MEMORY is set, the fewer connections and memory allocations will be possible for Oracle Database. The lower AWE_WINDOW_MEMORY is set, the lower the performance.

  8. Once this parameter is set, Oracle Database can be started and will function exactly the same as before except that more database buffers are available to the instance. In addition, disk I/O may be reduced because more Oracle Database data blocks can be cached in the System Global Area (SGA).