The installation of the Configuration Change Console and its components must be executed in the order documented below:
Oracle database installation and configuration
Configuration Change Console Server installation and configuration
Configuration Change Console Agent installation
Before installing the database, read through the following preparatory tasks.
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.
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.
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.
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.
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.
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:
The computer on which Oracle Database is installed must have more than 4 GB of memory.
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.
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.
The user account under which Oracle Database runs (typically the LocalSystem account), must have the Lock memory pages Windows 2000 and Windows XP privilege.
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.
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:
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.
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).