Database Sizing
The factors to consider when sizing and configuring the database are as follows:
-
Undo Tablespace: The Undo tablespace is utilized when running the SYNC processes, especially during the initial SYNC when potentially larger numbers of rows are pulled from the Enterprise Manager instance to Always-On Monitoring.
-
Temp Tablespace: The SYNC process will also utilize TEMP tablespace, especially when indexes are created or sorting occurs during the data movement process.
-
Always-On Monitoring Tablespace: Table data and indexes specific to Always-On Monitoring are stored in this tablespace.
-
Redo Logs: Redo logs should be large enough to minimize the number of checkpoints that occur during times when the SYNC is occurring. It is recommended to configure 3 x 1 GB REDO log files.
-
Special Oracle Parameter Settings: For Always-On Monitoring, it is desirable to maintain the parameters used in the Enterprise Manager repository, especially if the Always-On Monitoring schema is to be populated in the Enterprise Manager repository database. To ensure correctness of the Enterprise Manager parameter settings that are passed in as part of the Always-On Monitoring install, you can run the SYNC and other Always-On Monitoring functions that are part of the emsctl verbs. This is important to consider when configuring a separate database instance. As is the case with the Enterprise Manager Repository, the following parameter should be set for the Always-On Monitoring Repository to avoid unforeseen optimizer issues:
ALTER SYSTEM SET OPTIMIZER_ADAPTIVE_FEATURES=FALSE SCOPE=BOTH SID='*';
The following table represents an example of the sizing of the above components for an Always-On Monitoring schema that is being used for a large enterprise database. Note that these figures represent the sizes of the tablespaces after the initial full SYNC between Always-On Monitoring and Enterprise Manager. Also note that the Redo Log files are not included in these calculations:
Table 17-1 Always-On Monitoring Repository Tablespace Sizing
Tablespace Name Used Space (MB) Free Space (MB) Total Allocation (MB) Percentage Free (%) TEMP
0
30,720
30,720
100%
Users
6,430
44,797
51,200
87%
SYSAUX
1,385
85
1,470
6%
SYSTEM
896
4
900
0%
UNDOTBS1
84
30,636
30,720
100%
Totals
8.769
106,246
115,015
92%
For this particular configuration, the absolute minimum for disk space required was 9 GB based on the used Tablespace. To ensure room for growth with this schema, it is recommended to plan on allocating at least 120 GB of space for the Always-On Monitoring database if creating a new Oracle instance. The TEMP and UNDO tablespaces are configured to handle initial and subsequent SYNC operations ensuring there is no issue with TEMP or REDO saturation. In addition, the Always-On Monitoring tablespace is sized to ensure no interruption due to saturation of the tablespace.
In order to accurately size the Always-On Monitoring tablespace for current usage and future growth, it is important to understand the following:
-
What data from what tables is being transferred from the Enterprise Manager Repository to the Always-On Monitoring Schema.
-
Knowing the number of rows transferred for each table, what is the approximate number of Bytes per Row for the tables and indexes?
The following table shows a subset of the tables and indexes in the Always-On Monitoring schema, highlighting the number of rows, total space consumption, and the number of bytes per row:
Table 17-2 Always-On Monitoring Table and Index Space Allocation
Owner | Segment Name | Segment Type | Partition Name | Size (MB) | Number of Rows |
---|---|---|---|---|---|
Always-On Monitoring |
MGMT_TARGET_PROPERTIES |
TABLE |
Non-Partitioned |
1,472 |
15,408,952 |
Always-On Monitoring |
MGMT_TARGET_PROPERTIES_IDX_02 |
INDEX |
Non-Partitioned |
1,152 |
15,215,316 |
Always-On Monitoring |
MGMT_TARGET_PROPERTIES_PK |
INDEX |
Non-Partitioned |
856 |
15,462,104 |
Always-On Monitoring |
MGMT_TARGET_PROPERTIES_IDX_01 |
INDEX |
Non-Partitioned |
584 |
14,871,521 |
Always-On Monitoring |
EM_MANAGEABLE_ENTITIES |
TABLE |
Non-Partitioned |
496 |
1,177,065 |
Always-On Monitoring |
MGMT_TARGET_PROPERTIES_IDX_03 |
INDEX |
Non-Partitioned |
472 |
16,105,162 |
Always-On Monitoring |
EM_MANAGEABLE_ENTITIES_UK1 |
INDEX |
Non-Partitioned |
136 |
1,201,617 |
Always-On Monitoring |
EM_MANAGEABLE_ENTITIES_UK2 |
INDEX |
Non-Partitioned |
120 |
1,133,804 |
Always-On Monitoring |
EM_MANAGEABLE_ENTITIES_IDX01 |
INDEX |
Non-Partitioned |
112 |
1,184,414 |
Always-On Monitoring |
EM_MANAGEABLE_ENTITIES_IDX07 |
INDEX |
Non-Partitioned |
112 |
1,166,536 |
Always-On Monitoring |
EM_MANAGEABLE_ENTITIES_IDX03 |
INDEX |
Non-Partitioned |
96 |
1,182,817 |
Always-On Monitoring |
EM_MANAGEABLE_ENTITIES_IDX04 |
INDEX |
Non-Partitioned |
80 |
1,218,977 |
Always-On Monitoring |
EM_MANAGEABLE_ENTITIES_IDX05 |
INDEX |
Non-Partitioned |
72 |
1,104,428 |
Always-On Monitoring |
EM_MANAGEABLE_ENTITIES_IDX06 |
INDEX |
Non-Partitioned |
59 |
673,838 |
Always-On Monitoring |
EM_MANAGEABLE_ENTITIES_IDX08 |
INDEX |
Non-Partitioned |
44 |
1,215,411 |
Always-On Monitoring |
EM_MANAGEABLE_ENTITIES_PK |
INDEX |
Non-Partitioned |
41 |
1,172,101 |
Always-On Monitoring |
EM_MANAGEABLE_ENTITIES_IDX09 |
INDEX |
Non-Partitioned |
40 |
1,192,236 |
Always-On Monitoring |
EM_MANAGEABLE_ENTITIES_IDX02 |
INDEX |
Non-Partitioned |
37 |
1,178,410 |
Always-On Monitoring |
EM_VIOLATIONS |
TABLE |
Non-Partitioned |
28 |
112,106 |
Always-On Monitoring |
EM_METRIC_COLUMN_VER_PK |
INDEX |
Non-Partitioned |
17 |
611,561 |