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