| Oracle® Enterprise Manager Cloud Control Extensibility Programmer's Reference 12c Release 2 (12.1.0.2) Part Number E25161-06 |
|
|
PDF · Mobi · ePub |
| Oracle® Enterprise Manager Cloud Control Extensibility Programmer's Reference 12c Release 2 (12.1.0.2) Part Number E25161-06 |
|
|
PDF · Mobi · ePub |
This chapter provides information about defining configuration collection tables and integrating them into the Enterprise Configuration Management framework.
This chapter contains the following sections:
As a plug-in developer, you are responsible for the following steps with respect to incorporating configuration-related functions into Enterprise Configuration Management for each snapshot type:
Define an Enterprise Configuration Management-specific metadata file that defines collection tables to match configuration collection metrics established as part of the target type definition.
For more information, see Section 6.3.1, "Defining Configuration Collection Tables".
Name the snapshot type (the name must match the CollectionItem name specified on the Management Agent side) for a given target type.
For more information, see Section 6.3.2, "Overview of Configuration Management Snapshot Metadata Elements".
Register the metadata with Enterprise Configuration Management during plug-in deployment. This creates tables for snapshot data, subject to any constraints imposed by the Enterprise Configuration Management framework. It also registers the data tables in Enterprise Configuration Management metadata tables.
For more information, see Section 6.3.4, "Registering Metadata With the Configuration Management Framework".
Integrate with the standard Management Agent's collection mechanisms. Both CollectionItem and corresponding metrics must be defined at the Management Agent.
For more information, see Section 6.3.7, "Modifications to Standard Collection Metrics and RAW Metrics".
Verify that the defined configuration collection data is returned to the Management Repository by the Management Agent.
For more information, see Section 6.3.8, "Testing the Configuration Collection Data" and Section 6.3.9, "Troubleshooting".
The metadata for configuration collection is defined in three metadata files packaged with the plug-in:
The configuration metadata file
This file defines the tables in the Management Repository that will store collected configuration data. In addition, the EDK includes an example of a configuration metadata file:
\samples\plugins\HostSample\stage\oms\metadata\snapshotlive\demo_hostsample_ecmdef.xml
For more information, see Section 6.3.1, "Defining Configuration Collection Tables".
Each configuration data item is collected as a metric that is defined with other metrics in the target type metadata file. In addition, the EDK includes an example of a target type metadata file:
\samples\plugins\HostSample\stage\oms\metadata\targetType\demo_hostsample.xml
For more information, see Section 3.3, "Creating the Target Type Metadata File".
The default collection metadata file
The frequency at which configuration data is collected for each metric is defined in the default collection metadata file. Metric Alert event conditions for each metric and the messages to display for such alerts are also defined in this file. In addition, the EDK includes an example of a default collection metadata file:
\samples\plugins\HostSample\stage\oms\metadata\default_collection\demo_hostsample.xml
For more information, see Section 3.5, "Creating the Default Collection File".
This section describes how to create configuration snapshot tables in terms of an Oracle home example. Assume that an Oracle home target type definition is added to the Enterprise Manager framework. After the target instance is added to the framework from the Cloud Control UI, an Oracle Management Agent can monitor any instance of that target type.
With the help of Enterprise Configuration Management, you can define data for your configuration data and define metrics to collect the data at the Management Agent.
Each Enterprise Configuration Management metric defined in the target type metadata file corresponds to a table defined by the configuration metadata XML file. For information about target type metadata files, see Chapter 3, "Creating Target Metadata Files".
Tables can have parent-child relationships similar to foreign key constraints in the database. For every parent table row, there are n numbers of child table rows, and every child table row has exactly one parent table row. In effect, Enterprise Configuration Management allows trees of tables, where each table has at most one parent table. A configuration can consist of a set of these trees where no table is repeated.
From a database perspective, a table must include all key columns of its ancestor tables. (Internally, each Enterprise Configuration Management table includes an ECM_SNAPSHOT_ID column of type RAW(16) to identify the snapshot to which a given row belongs.)
Metadata for the collection tables must specify at a minimum:
Table names, column names, column types, and hierarchical relationships between tables.
Key columns, that is columns that uniquely identify a row in a table. You must specify keys correctly. Enterprise Manager UI, comparison, and history use key columns extensively.
UI display names that will in the Enterprise Manager generic UI.
Figure 6-1 shows the Oracle Home Entity Relationship Diagram (ERD) of the configuration tables.
The configuration metadata XML file begins with the METADATA tag. The METADATA tag establishes the relationship between the target type and the snapshot type, defines the UI display name, and has at least one table specification.
<METADATAS>
<METADATA SNAP_TYPE="oracle_home_config" TARGET_TYPE="oracle_home" VER="1"
COMPARE_IGNORE="N" COMPARE_UI_IGNORE="N" HISTORY_IGNORE="N"
HISTORY_UI_IGNORE="N" UI_IGNORE="N">
<METADATA_UI_NAME>Oracle Home Configuration</METADATA_UI_NAME>
CONFIGURATION COLLECTION TABLE DEFINITIONS
</METADATA>
<METADATAS>
The configuration collection table definitions are encapsulated within the METADATA tag.
For more information about the elements of the configuration metadata XML, see Section 6.3.2, "Overview of Configuration Management Snapshot Metadata Elements". For information about the XML Schema Definitions (XSD) that governs the configuration XML files, see the Extensibility Development Kit (EDK) specifications.
The EM_ECM_OH_HOME_INFO table stores properties related to an Oracle software installation. The metadata for this table is as follows:
<TABLE NAME="EM_ECM_OH_HOME_INFO" SINGLE_ROW="Y"> <UI_NAME>Home Info</UI_NAME> <COLUMN NAME="HOME_LOCATION" TYPE="STRING" TYPE_FORMAT="1024">Install Location</COLUMN> <COLUMN NAME="OUI_HOME_NAME" TYPE="STRING" TYPE_FORMAT="256" >OUI Home Name</COLUMN> <COLUMN NAME="OUI_HOME_GUID" TYPE="STRING" TYPE_FORMAT="32" >OUI Home GUID</COLUMN> <COLUMN NAME="HOME_TYPE" TYPE="STRING" TYPE_FORMAT="1" >Home Type</COLUMN> <COLUMN NAME="HOME_POINTER" TYPE="STRING" TYPE_FORMAT="1024">Home Pointer</COLUMN> <COLUMN NAME="IS_CLONABLE" TYPE="NUMBER" TYPE_FORMAT="1" >Is Clonable</COLUMN> <COLUMN NAME="IS_CRS" TYPE="NUMBER" TYPE_FORMAT="1" >Is CRS</COLUMN> <COLUMN NAME="ARU_ID" TYPE="NUMBER" TYPE_FORMAT="10" >ARU ID of the Oracle Home</COLUMN> <COLUMN NAME="HOME_SIZE" TYPE="NUMBER" TYPE_FORMAT="10" >Size of Oracle Home (KB)</COLUMN> </TABLE>
The corresponding database table is as follows:
| COLUMN_NAME | DATA_TYPE | COLUMN_WIDTH | KEY |
|---|---|---|---|
| ECM_SNAPSHOT_ID | RAW | 16 | PK |
| HOME_LOCATION | VARCHAR2 | 1024 | |
| OUI_HOME_NAME | VARCHAR2 | 256 | |
| OUI_HOME_GUID | VARCHAR2 | 32 | |
| HOME_TYPE | VARCHAR2 | 1 | |
| HOME_POINTER | VARCHAR2 | 1024 | |
| IS_CLONABLE | NUMBER | 1 | |
| IS_CRS | NUMBER | 1 | |
| ARU_ID | NUMBER | 10 | |
| HOME_SIZE (in KB) | NUMBER | 10 |
For this table, the Primary Key consists of ECM_SNAPSHOT_ID. The SINGLE_ROW=”Y” attribute from the metadata example indicates that each snapshot will have at most a single row in this table and therefore you do not have to mark any other columns in the table as key.
The EM_ECM_OH_DEP_HOMES table stores the locations of the Oracle home directories that a given Oracle Home depends on. This data is used to form depends_on_home associations between Oracle Homes. The metadata for this table is as follows:
<TABLE NAME="EM_ECM_OH_DEP_HOMES"> <UI_NAME>Dependee Oracle Homes</UI_NAME> <COLUMN NAME="DEP_HOME_LOCATION" TYPE="STRING" TYPE_FORMAT="1024" IS_KEY="Y">Dependee Home Location</COLUMN> </TABLE>
The corresponding database table is as follows:
| COLUMN_NAME | DATA_TYPE | COLUMN_WIDTH | KEY |
|---|---|---|---|
| ECM_SNAPSHOT_ID | RAW | 16 | PK |
| DEP_HOME_LOCATION | VARCHAR2 | 1024 | PK |
The primary key for this table consists of ECM_SNAPSHOT_ID and DEP_HOME_LOCATION.
The EM_ECM_OH_CRS_NODES table stores all the nodes on which a CRS Oracle Home is installed. The metadata for this table is as follows:
<TABLE NAME="EM_ECM_OH_CRS_NODES"> <UI_NAME>CRS Nodes</UI_NAME> <COLUMN NAME="NODE" TYPE="STRING" TYPE_FORMAT="256" IS_KEY="Y">Node</COLUMN> </TABLE>
The corresponding database table is as follows:
| COLUMN_NAME | DATA_TYPE | COLUMN_WIDTH | KEY |
|---|---|---|---|
| ECM_SNAPSHOT_ID | RAW | 16 | PK |
| NODE | VARCHAR2 | 256 | PK |
The primary key for this table consists of ECM_SNAPSHOT_ID and NODE.
The EM_ECM_OH_CLONE_PROPS table stores the clone properties related to an Oracle software installation. The metadata for this table is as follows:
<TABLE NAME="EM_ECM_OH_CLONE_PROPS"> <UI_NAME>Oracle Home Clone Properties</UI_NAME> <COLUMN NAME="PROPERTY_NAME" TYPE="STRING" TYPE_FORMAT="64" IS_KEY="Y">Property Name</COLUMN> <COLUMN NAME="PROPERTY_VALUE" TYPE="STRING" TYPE_FORMAT="1024" >Property Value</COLUMN> </TABLE>
The corresponding database table is as follows:
| COLUMN_NAME | DATA_TYPE | COLUMN_WIDTH | KEY |
|---|---|---|---|
| ECM_SNAPSHOT_ID | RAW | 16 | PK |
| PROPERTY_NAME | VARCHAR2 | 64 | PK |
| PROPERTY_VALUE | NUMBER | 1024 |
The primary key for this table consists of ECM_SNAPSHOT_ID and PROPERTY_NAME.
The EM_ECM_OH_COMPONENT table stores information about Oracle software components (OUI and WebLogic). The metadata for this table is as follows:
<TABLE NAME="EM_ECM_OH_COMPONENT"> <UI_NAME>Components installed in Oracle Home</UI_NAME> <COLUMN NAME="COMPONENT_NAME" TYPE="STRING" TYPE_FORMAT="128" IS_KEY="Y">Component Name</COLUMN> <COLUMN NAME="COMPONENT_VERSION" TYPE="STRING" TYPE_FORMAT="64" IS_KEY="Y">Base Version of Component</COLUMN> <COLUMN NAME="CURRENT_VERSION" TYPE="STRING" TYPE_FORMAT="64" >Current Version of the Component</COLUMN> <COLUMN NAME="INSTALL_TIME" TYPE="TIMESTAMP" >Install Time</COLUMN> <COLUMN NAME="IS_TOP_LEVEL" TYPE="NUMBER" TYPE_FORMAT="1" >Is it a top level Component</COLUMN> <COLUMN NAME="EXTERNAL_NAME" TYPE="STRING" TYPE_FORMAT="128" >External name</COLUMN> <COLUMN NAME="DESCRIPTION" TYPE="STRING" TYPE_FORMAT="1024" >Description</COLUMN> <COLUMN NAME="LANGUAGES" TYPE="STRING" TYPE_FORMAT="1024" >Languages</COLUMN> <COLUMN NAME="INSTALLED_LOCATION" TYPE="STRING" TYPE_FORMAT="1024" >Installed Location</COLUMN> <COLUMN NAME="INSTALLER_VERSION" TYPE="STRING" TYPE_FORMAT="64" >Installer Version</COLUMN> <COLUMN NAME="MIN_DEINSTALLER_VERSION" TYPE="STRING" TYPE_FORMAT="64" >Minimum Deinstaller Version</COLUMN>
Note:
This metadata has no closing TABLE tag because it is a parent table to the next two tables (EM_ECM_OH_COMP_INST_TYPE Table and EM_ECM_OH_COMP_DEP_RULE Table).The corresponding database table is as follows:
| COLUMN_NAME | DATA_TYPE | COLUMN_WIDTH | KEY |
|---|---|---|---|
| ECM_SNAPSHOT_ID | RAW | 16 | PK |
| COMPONENT_NAME | VARCHAR2 | 128 | PK |
| COMPONENT_VERSION | VARCHAR2 | 64 | PK |
| CURRENT_VERSION | VARCHAR2 | 64 | |
| INSTALL_TIME | DATE | - | |
| IS_TOP_LEVEL | NUMBER | 1 | |
| EXTERNAL_NAME | VARCHAR2 | 128 | |
| DESCRIPTION | VARCHAR2 | 1024 | |
| LANGUAGES | VARCHAR2 | 1024 | |
| INSTALLED_LOCATION | VARCHAR2 | 1024 | |
| INSTALLER_VERSION | VARCHAR2 | 64 | |
| MIN_DEINSTALLER_VERSION | VARCHAR2 | 64 |
The primary key for this table consists of ECM_SNAPSHOT_ID, COMPONENT_NAME, and COMPONENT_VERSION
The EM_ECM_OH_COMP_INST_TYPE table stores the installation type of Oracle software components (Oracle Universal Installer (OUI) only). This a child table of EM_ECM_OH_COMPONENT Table. The metadata for this table is as follows:
<TABLE NAME="EM_ECM_OH_COMP_INST_TYPE"> <UI_NAME>Install Types of Components</UI_NAME> <COLUMN NAME="NAME_ID" TYPE="STRING" TYPE_FORMAT="128" IS_KEY="Y">Install Type Name ID</COLUMN> <COLUMN NAME="INSTALL_TYPE_NAME" TYPE="STRING" TYPE_FORMAT="128" >Install Type Name</COLUMN> <COLUMN NAME="DESC_ID" TYPE="STRING" TYPE_FORMAT="128" >Install Type Desc ID</COLUMN> </TABLE>
The corresponding database table is as follows:
| COLUMN_NAME | DATA_TYPE | COLUMN_WIDTH | KEY |
|---|---|---|---|
| ECM_SNAPSHOT_ID | RAW | 16 | PK |
| COMPONENT_NAME | VARCHAR2 | 128 | PK |
| COMPONENT_VERSION | VARCHAR2 | 64 | PK |
| NAME_ID | VARCHAR2 | 128 | PK |
| INSTALL_TYPE_NAME | VARCHAR2 | 128 | |
| DESC_ID | VARCHAR2 | 128 |
For this table, the primary key consists of ECM_SNAPSHOT_ID, COMPONENT_NAME, COMPONENT_VERSION, and NAME_ID.
The ECM_SNAPSHOT_ID, COMPONENT_NAME, COMPONENT_VERSION foreign keys must reference EM_ECM_OH_COMPONENT (ECM_SNAPSHOT_ID, COMPONENT_NAME, COMPONENT_VERSION)
The EM_ECM_OH_COMP_DEP_RULE table stores dependency relationships between Oracle software components (OUI and WebLogic). This a child table of the EM_ECM_OH_COMPONENT Table. The metadata for this table is as follows:
<TABLE NAME="EM_ECM_OH_COMP_DEP_RULE">
<UI_NAME>Component Dependencies</UI_NAME>
<COLUMN NAME="DEPENDEE_NAME" TYPE="STRING" TYPE_FORMAT="128" IS_KEY="Y">Dependee Component Name</COLUMN>
<COLUMN NAME="DEPENDEE_VERSION" TYPE="STRING" TYPE_FORMAT="64" IS_KEY="Y">Dependee Component Version</COLUMN>
<COLUMN NAME="DEPENDEE_HOME_GUID" TYPE="STRING" TYPE_FORMAT="32" >Dependee Component Home Guid</COLUMN>
</TABLE>
</TABLE>
Note:
The outdented closing TABLE tag is for the EM_ECM_OH_COMPONENT parent tableThe corresponding database table is as follows:
| COLUMN_NAME | DATA_TYPE | COLUMN_WIDTH | KEY |
|---|---|---|---|
| ECM_SNAPSHOT_ID | RAW | 16 | PK |
| COMPONENT_NAME | VARCHAR2 | 128 | PK |
| COMPONENT_VERSION | VARCHAR2 | 64 | PK |
| DEPENDEE_NAME | VARCHAR2 | 128 | PK |
| DEPENDEE_VERSION | VARCHAR2 | 64 | PK |
| DEPENDEE_HOME_GUID | VARCHAR2 | 32 |
For this table, the primary key consists of ECM_SNAPSHOT_ID, COMPONENT_NAME, COMPONENT_VERSION, DEPENDEE_NAME, and DEPENDEE_VERSION.
The ECM_SNAPSHOT_ID, COMPONENT_NAME, COMPONENT_VERSION foreign keys must reference EM_ECM_OH_COMPONENT (ECM_SNAPSHOT_ID, COMPONENT_NAME, COMPONENT_VERSION)
Note the following when you are creating the configuration metadata XML file:
Each table definition must specify its name and at least one column specification:
<TABLE NAME="..." ...>
Optional UI name
Column definitions
Optional Indexes definitions
Optional Child Tables
</TABLE>
Table 6-2 provides the attributes of the TABLE element.
Table names must be specific to a given snapshot type and cannot be shared by multiple snapshot types.
You can use name_IGNORE flags at the metadata, table, or column level to disregard certain comparison, history, and UI functionality. Inheritance flows from metadata to tables, parent tables to child tables, and from all tables to their columns. You can override these flags at any lower level.
Each column definition must specify its name and type at least:
Table 6-2 provides the attributes of the COLUMN element.
Columns can be of type STRING, NUMBER, TIMESTAMP, or RAW. TYPE_FORMAT is optional; its meaning derives from the value of type. For a string, it is the maximum string length. For a number, it is precision and scale, as for an Oracle database (for example, TYPE_FORMAT=”4, 9”).
Specify parent child relationships between tables by nesting the TABLE tags.
Table and view names cannot exceed 25 characters.
Table and column order is significant. The UI display replicates the order. Import and export operations preserve the order. Delete operations (on table data) occur in inverse order. Child rows are removed before parent rows.
COLUMN tags contain the UI display name of the column.
Tables require key columns that uniquely identify rows in the table. The key columns of all ancestor tables are automatically assumed to be inherited by the child tables and are not repeated in the child table specification.
Note:
A table does not require a key (beyond that of ancestor table keys, if any) if it has at only one row for each parent row, or each snapshot in the case of a top-level table. Tables without a key must specify the SINGLE_ROW=”Y” attribute, which is set to “N” by defaultOptional indexes are useful when a table is used in derived associations, compliance rules, reports or other queries where performance is important in accessing table rows based on columns other than ECM_SNAPSHOT_ID.
An optional index definitions element <INDEXES> should specify at least one <INDEX> element, and each <INDEX> element should specify name and columns.
<INDEXES>
<INDEXNAME="..."COLUMNS="..."/>
<INDEXNAME="..."COLUMNS="..."/>
...
</INDEXES>
Table 6-1 provides a list of the attributes of the INDEX element.
Table 6-1 INDEX Element Attributes
| Attribute | Description |
|---|---|
|
NAME |
NAME attribute is required. Its value should be unique among all index names. It is recommended to be the same as table name followed by _IDX1, _IDX2, etc. |
|
COLUMNS |
COLUMNS attribute is required. Its value should be comma-separated list of column names. Note: The predefined ECM_METADATA_ID column is always added as the last column for each index. |
For information about the key elements of the configuration metadata, see Section 6.3.2, "Overview of Configuration Management Snapshot Metadata Elements".
Table 6-2 describes the key elements that define configuration management.
Table 6-2 Key Elements of a Configuration Metadata XML File
| Element | Description |
|---|---|
|
The root element that established the relationship between the target type and snapshot type. It also defines the snapshot UI display name. It includes the following attributes:
|
|
|
Specifies the table name and at least one column. It includes the following attributes:
|
|
|
|
Each column definition must a
|
Example 6-4 provides an example of a configuration metadata XML file for an oracle_home target.
Example 6-4 Example of a Configuration Metadata XML File
<METADATAS>
<METADATA SNAP_TYPE="oracle_home_config_test" TARGET_TYPE="oracle_home"
VER="1" COMPARE_IGNORE="N" COMPARE_UI_IGNORE="N" HISTORY_IGNORE="N"
HISTORY_UI_IGNORE="N" UI_IGNORE="N" DROP_EXISTING_DATA="Y">
<METADATA_UI_NAME>Oracle Home Configuration Test</METADATA_UI_NAME>
<TABLE NAME="EM_ECM_OH_HOME_INFO" SINGLE_ROW="Y">
<UI_NAME>Home Info</UI_NAME>
<COLUMN NAME="HOME_LOCATION" TYPE="STRING" TYPE_FORMAT="1024">Install Location</COLUMN>
<COLUMN NAME="OUI_HOME_NAME" TYPE="STRING" TYPE_FORMAT="256" >OUI Home Name</COLUMN>
<COLUMN NAME="OUI_HOME_GUID" TYPE="STRING" TYPE_FORMAT="32" >OUI Home GUID</COLUMN>
<COLUMN NAME="HOME_TYPE" TYPE="STRING" TYPE_FORMAT="1" >Home Type</COLUMN>
<COLUMN NAME="HOME_POINTER" TYPE="STRING" TYPE_FORMAT="1024">Home Pointer</COLUMN>
<COLUMN NAME="IS_CLONABLE" TYPE="NUMBER" TYPE_FORMAT="1" >Is Clonable</COLUMN>
<COLUMN NAME="IS_CRS" TYPE="NUMBER" TYPE_FORMAT="1" >Is CRS</COLUMN>
<COLUMN NAME="ARU_ID" TYPE="NUMBER" TYPE_FORMAT="10" >ARU ID of the Oracle Home</COLUMN>
<COLUMN NAME="OUI_PLATFORM_ID" TYPE="NUMBER" TYPE_FORMAT="10" >OUI Platform ID of Host</COLUMN>
<COLUMN NAME="HOME_SIZE" TYPE="NUMBER" TYPE_FORMAT="10" >Size of Oracle Home (KB)</COLUMN>
<COLUMN NAME="ORACLE_BASE" TYPE="STRING" TYPE_FORMAT="1024">Oracle Base (for OUI Homes only)</COLUMN>
<COLUMN NAME="OH_OWNER_ID" TYPE="NUMBER" TYPE_FORMAT="32" >Oracle Home Onwner Id</COLUMN>
<COLUMN NAME="OH_OWNER" TYPE="STRING" TYPE_FORMAT="64" >Oracle Home Owner</COLUMN>
<COLUMN NAME="OH_GROUP_ID" TYPE="NUMBER" TYPE_FORMAT="32" >Oracle Home Group Id</COLUMN>
<COLUMN NAME="OH_GROUP" TYPE="STRING" TYPE_FORMAT="64" >Oracle Home Group</COLUMN>
<COLUMN NAME="OH_OWNER_GROUPS_ID" TYPE="STRING" TYPE_FORMAT="1024">semi colon Separated list of Group Ids OracleHomeOwner belongs to</COLUMN>
<COLUMN NAME="OH_OWNER_GROUPS" TYPE="STRING" TYPE_FORMAT="1024">semi colon Separated list of Groups Oracle Home Owner belongs to</COLUMN>
</TABLE>
<TABLE NAME="EM_ECM_OH_DEP_HOMES">
<UI_NAME>Dependee Oracle Homes</UI_NAME>
<COLUMN NAME="DEP_HOME_LOCATION" TYPE="STRING" TYPE_FORMAT="1024" IS_KEY="Y">Dependee Home Location</COLUMN>
</TABLE>
<TABLE NAME="EM_ECM_OH_CRS_NODES">
<UI_NAME>CRS Nodes</UI_NAME>
<COLUMN NAME="NODE" TYPE="STRING" TYPE_FORMAT="256" IS_KEY="Y">Node</COLUMN>
</TABLE>
<TABLE NAME="EM_ECM_OH_CLONE_PROPS">
<UI_NAME>Oracle Home Clone Properties</UI_NAME>
<COLUMN NAME="PROPERTY_NAME" TYPE="STRING" TYPE_FORMAT="64" IS_KEY="Y">Property Name</COLUMN>
<COLUMN NAME="PROPERTY_VALUE" TYPE="STRING" TYPE_FORMAT="1024" >Property Value</COLUMN>
</TABLE>
<TABLE NAME="EM_ECM_OH_COMPONENT">
<UI_NAME>Components installed in Oracle Home</UI_NAME>
<COLUMN NAME="COMPONENT_NAME" TYPE="STRING" TYPE_FORMAT="128" IS_KEY="Y">Component Name</COLUMN>
<COLUMN NAME="COMPONENT_VERSION" TYPE="STRING" TYPE_FORMAT="64" IS_KEY="Y">Base Version of Component</COLUMN>
<COLUMN NAME="CURRENT_VERSION" TYPE="STRING" TYPE_FORMAT="64" >Current Version of the Component</COLUMN>
<COLUMN NAME="INSTALL_TIME" TYPE="TIMESTAMP" >Installe Time</COLUMN>
<COLUMN NAME="IS_TOP_LEVEL" TYPE="NUMBER" TYPE_FORMAT="1" >Is it a top level Component</COLUMN>
<COLUMN NAME="EXTERNAL_NAME" TYPE="STRING" TYPE_FORMAT="128" >Externale name</COLUMN>
<COLUMN NAME="DESCRIPTION" TYPE="STRING" TYPE_FORMAT="1024" >Description</COLUMN>
<COLUMN NAME="LANGUAGES" TYPE="STRING" TYPE_FORMAT="1024" >Languages</COLUMN>
<COLUMN NAME="INSTALLED_LOCATION" TYPE="STRING" TYPE_FORMAT="1024" >Installed Location</COLUMN>
<COLUMN NAME="INSTALLER_VERSION" TYPE="STRING" TYPE_FORMAT="64" >Installer Version</COLUMN>
<COLUMN NAME="MIN_DEINSTALLER_VERSION" TYPE="STRING" TYPE_FORMAT="64" >Minimum Deinstaller Version</COLUMN>
</TABLE>
<TABLE NAME="EM_ECM_OH_COMP_INST_TYPE">
<UI_NAME>Install Types of Components</UI_NAME>
<COLUMN NAME="NAME_ID" TYPE="STRING" TYPE_FORMAT="128" IS_KEY="Y">Install Type Name ID</COLUMN>
<COLUMN NAME="INSTALL_TYPE_NAME" TYPE="STRING" TYPE_FORMAT="128" >Install Type Name</COLUMN>
<COLUMN NAME="DESC_ID" TYPE="STRING" TYPE_FORMAT="128" >Install Type Desc ID</COLUMN>
</TABLE>
<TABLE NAME="EM_ECM_OH_COMP_DEP_RULE">
<UI_NAME>Component Dependencies</UI_NAME>
<COLUMN NAME="DEPENDEE_NAME" TYPE="STRING" TYPE_FORMAT="128" IS_KEY="Y">Dependee Component Name</COLUMN>
<COLUMN NAME="DEPENDEE_VERSION" TYPE="STRING" TYPE_FORMAT="64" IS_KEY="Y">Dependee Component Version</COLUMN>
<COLUMN NAME="DEPENDEE_HOME_GUID" TYPE="STRING" TYPE_FORMAT="32" >Dependee Component Home Guid</COLUMN>
</TABLE>
<TABLE NAME="EM_ECM_OH_PATCHSET">
<UI_NAME>Patchsets installed in Oracle Home</UI_NAME>
<COLUMN NAME="PATCHSET_NAME" TYPE="STRING" TYPE_FORMAT="128" IS_KEY="Y">Patchset Name</COLUMN>
<COLUMN NAME="PATCHSET_VERSION" TYPE="STRING" TYPE_FORMAT="64" IS_KEY="Y">Patchset Version</COLUMN>
<COLUMN NAME="INSTALL_TIME" TYPE="TIMESTAMP" >Install Time</COLUMN>
<COLUMN NAME="EXTERNAL_NAME" TYPE="STRING" TYPE_FORMAT="128" >Externale name</COLUMN>
<COLUMN NAME="DESCRIPTION" TYPE="STRING" TYPE_FORMAT="1024" >Description</COLUMN>
<COLUMN NAME="INV_LOCATION" TYPE="STRING" TYPE_FORMAT="1024" >Inventory Location</COLUMN>
<COLUMN NAME="INSTALLER_VERSION" TYPE="STRING" TYPE_FORMAT="64" >Installer Version</COLUMN>
<COLUMN NAME="MIN_DEINSTALLER_VERSION" TYPE="STRING" TYPE_FORMAT="64" >Minimum Deinstaller Version</COLUMN>
</TABLE>
<TABLE NAME="EM_ECM_OH_VERSION_PATCH">
<UI_NAME>Versioned Patches installed in Oracle Home</UI_NAME>
<COLUMN NAME="VPATCH_NAME" TYPE="STRING" TYPE_FORMAT="128" IS_KEY="Y">Versioned Patch Name</COLUMN>
<COLUMN NAME="VPATCH_VERSION" TYPE="STRING" TYPE_FORMAT="64" IS_KEY="Y">Versioned Patch Version</COLUMN>
<COLUMN NAME="BASE_COMP_VERSION" TYPE="STRING" TYPE_FORMAT="64" >Base Component Version</COLUMN>
<COLUMN NAME="PATCHSET_NAME" TYPE="STRING" TYPE_FORMAT="128" >Patchset Name</COLUMN>
<COLUMN NAME="PATCHSET_VERSION" TYPE="STRING" TYPE_FORMAT="64" >Patchset Version</COLUMN>
<COLUMN NAME="INSTALL_TIME" TYPE="TIMESTAMP" >Install Time</COLUMN>
<COLUMN NAME="EXTERNAL_NAME" TYPE="STRING" TYPE_FORMAT="128" >Externale name</COLUMN>
<COLUMN NAME="DESCRIPTION" TYPE="STRING" TYPE_FORMAT="1024" >Description</COLUMN>
<COLUMN NAME="LANGUAGES" TYPE="STRING" TYPE_FORMAT="1024" >Languages</COLUMN>
<COLUMN NAME="INSTALLED_LOCATION" TYPE="STRING" TYPE_FORMAT="1024" >Installed Location</COLUMN>
<COLUMN NAME="INSTALLER_VERSION" TYPE="STRING" TYPE_FORMAT="64" >Installer Version</COLUMN>
<COLUMN NAME="MIN_DEINSTALLER_VERSION" TYPE="STRING" TYPE_FORMAT="64" >Minimum Deinstaller Version</COLUMN>
</TABLE>
<TABLE NAME="EM_ECM_OH_PATCH">
<UI_NAME>Patches installed in Oracle Home</UI_NAME>
<COLUMN NAME="PATCH_ID" TYPE="STRING" TYPE_FORMAT="128" IS_KEY="Y">Patch ID</COLUMN>
<COLUMN NAME="PATCH_UPI" TYPE="STRING" TYPE_FORMAT="256" IS_KEY="Y">Patch UPI</COLUMN>
<COLUMN NAME="PATCH_LANG" TYPE="STRING" TYPE_FORMAT="8" IS_KEY="Y">Patch Language</COLUMN>
<COLUMN NAME="INSTALL_TIME" TYPE="TIMESTAMP" >Install Time</COLUMN>
<COLUMN NAME="IS_ROLLBACKABLE" TYPE="NUMBER" TYPE_FORMAT="1" >Can the Patch be rolled back</COLUMN>
<COLUMN NAME="IS_PSU" TYPE="NUMBER" TYPE_FORMAT="1" >Is it a PSU</COLUMN>
<COLUMN NAME="PROFILE" TYPE="STRING" TYPE_FORMAT="1024" >Profile</COLUMN>
<COLUMN NAME="DESCRIPTION" TYPE="STRING" TYPE_FORMAT="1024" >Description</COLUMN>
<COLUMN NAME="XML_INV_LOCATION" TYPE="STRING" TYPE_FORMAT="1024" >XML Inventory Location</COLUMN>
<COLUMN NAME="INSTALLER_VERSION" TYPE="STRING" TYPE_FORMAT="64" >Installer Version</COLUMN>
</TABLE>
<TABLE NAME="EM_ECM_OH_PATCHED_COMP">
<UI_NAME>Components affected by Patch</UI_NAME>
<COLUMN NAME="COMPONENT_NAME" TYPE="STRING" TYPE_FORMAT="128" IS_KEY="Y">Affected Component Name</COLUMN>
<COLUMN NAME="COMPONENT_VERSION" TYPE="STRING" TYPE_FORMAT="64" IS_KEY="Y">Affected Component Version</COLUMN>
<COLUMN NAME="FROM_VERSION" TYPE="STRING" TYPE_FORMAT="64" >Component Version before applying PSU</COLUMN>
<COLUMN NAME="TO_VERSION" TYPE="STRING" TYPE_FORMAT="64" >Component Version after applying PSU</COLUMN>
</TABLE>
</METADATA>
</METADATAS>
When you have completed your configuration metadata XML file, save the file in the following directory in your plug-in staging directory:
oms/metadata/snapshotlive
After you save the configuration metadata file in the plug-in staging directory, it is available for automatic registration during plug-in deployment.
For information about the plug-in staging directory or plug-in deployment, see Chapter 13, "Validating, Packaging, and Deploying the Plug-in".
During plug-in deployment, the configuration metadata XML file is registered with the Enterprise Configuration Management framework automatically and the necessary schema objects are created.
Note:
Ensure the configuration metadata XML file is in the correct directory, see Section 6.3.3, "Packaging Configuration Metadata".If you want to register the configuration metadata XML file with the Enterprise Configuration Management framework without having to deploy the plug-in, then use the Metadata Registration Service (MRS).
For information about MRS and its usage, see Section 13.7, "Updating Deployed Metadata Files Using the Metadata Registration Service (MRS)".
To register the configuration metadata XML file with the Enterprise Configuration Management framework, enter the following command, where PLUGIN_ID is the ID of the plug-in to which the snapshot metadata target types belong:
Note:
You must import the plug-in into the Management Repository before running this command.For information about importing plug-ins, see Chapter 13, "Validating, Packaging, and Deploying the Plug-in".
emctl register oms metadata -sysman_pwd SYSMAN_PASSWORD -pluginId PLUGIN_ID -service LiveSnapshotRegistration -file CONFIG_METADATA_XML_FILE
Note: LiveSnapshotRegistration is the service that creates or updates the schema objects and registers the metadata.
Use the generate_ecm_resources utility to generate some additional files if required.
To run the utility:
$ORACLE_HOME/../../empdk/bin/generate_ecm_resources config_metadata.xml destination_dir
The generate_ecm_resources utility generates the following additional files:
config_metadata_metric.xml and config_metadata_collection.xml
Note:
The generated files are located in the destination_dir directory and their file names use the name of the Configuration Metadata XML file (config_metadata.xml) as a prefix (in lowercase).These files can be used as starting templates for Agent-side integration. For more information on Agent-side integration, see Section 6.3.7, "Modifications to Standard Collection Metrics and RAW Metrics".
config_metadata_xml_file.dlf
This is a file for translations of snapshot type name, table, and column names. Place the generated DLF file and its translated versions in the following directory:
plugin_stage/oms/rsc/ecm
*.sql
Ignore all generated *.sql files
Note:
You must increment your integer metadata version whenever you release a new version of metadata to your customers.The version must be incremented in the Configuration Metadata XML file (VER attribute) and the corresponding Management Agent collection file.
For more information about the VER attribute, see Table 6-2, "Key Elements of a Configuration Metadata XML File".
When you are upgrading existing snapshot metadata, only the following changes are supported:
New tables
New non-key columns (these must appear after previous existing columns)
Increasing length of STRING type columns
Values of UI_IGNORE, COMPARE_IGNORE, COMPARE_UI_IGNORE, HISTORY_IGNORE, HISTORY_UI_IGNORE and UI_NAME attributes
New list of indexes (replaces any previous indexes)
Note:
No columns formats except STRING can be altered
The length of the STRING columns only can be increased
New table cannot be added as a parent for an existing table
Tables or columns cannot be removed from the existing snapshot metadata
Take the following metadata example:
Example 6-5 Original Metadata Definition
<METADATAS xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<METADATA VER=”1”
SNAP_TYPE="sn_dbconfig"
TARGET_TYPE="sn_oracle_database"
UI_IGNORE="Y"
HISTORY_IGNORE="N"
COMPARE_IGNORE="Y"
COLLECTION_GROUP="COL_GRP_0">
<METADATA_UI_NAME>Database Configuration</METADATA_UI_NAME>
<TABLE NAME="TABLESPACES" DATA_SOURCE="R">
<UI_NAME>Tablespaces</UI_NAME>
<COLUMN NAME="TABLESPACE_NAME" TYPE="STRING" TYPE_FORMAT="30"
IS_KEY="Y">Tablespace Name</COLUMN>
<COLUMN NAME="SIZE" TYPE="NUMBER">Size</COLUMN>
<COLUMN NAME="STATUS" TYPE="STRING" TYPE_FORMAT="10">Status</COLUMN>
<TABLE NAME="DATAFILES">
<UI_NAME>Datafiles</UI_NAME>
<COLUMN NAME="FILE_NAME" TYPE="STRING" TYPE_FORMAT="1024"
IS_KEY="Y">File Name</COLUMN>
<COLUMN NAME="FILE_SIZE" TYPE="NUMBER" HISTORY_IGNORE="Y">Size</COLUMN>
<COLUMN NAME="STATUS" TYPE="STRING" TYPE_FORMAT="9">Status</COLUMN>
</TABLE>
</TABLE>
</METADATA>
</METADATAS>
Example 6-6 provides an example of an upgrade to the metadata definition described in Example 6-5. The changes are highlighted in bold text.
Example 6-6 Upgraded Metadata Definition
<METADATAS xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <METADATA VER=”2” SNAP_TYPE="sn_dbconfig" TARGET_TYPE="sn_oracle_database" UI_IGNORE="Y" HISTORY_IGNORE="N" COMPARE_IGNORE="Y" COLLECTION_GROUP="COL_GRP_0"> <METADATA_UI_NAME>Database Configuration</METADATA_UI_NAME> <TABLE NAME="TABLESPACES" DATA_SOURCE="R"> <UI_NAME>Tablespaces</UI_NAME> <COLUMN NAME="TABLESPACE_NAME" TYPE="STRING" TYPE_FORMAT="30" IS_KEY="Y">Tablespace Name</COLUMN> <COLUMN NAME="SIZE" TYPE="NUMBER">Size</COLUMN> <COLUMN NAME="STATUS" TYPE="STRING" TYPE_FORMAT="10">Status</COLUMN> <TABLE NAME="DATAFILES"> <UI_NAME>Datafiles</UI_NAME> <COLUMN NAME="FILE_NAME" TYPE="STRING" TYPE_FORMAT="1024" IS_KEY="Y">File Name</COLUMN> <COLUMN NAME="FILE_SIZE" TYPE="NUMBER" HISTORY_IGNORE="Y">Size</COLUMN> <COLUMN NAME="STATUS" TYPE="STRING" TYPE_FORMAT="10">Status</COLUMN> <COLUMN NAME="DESC" TYPE="STRING" TYPE_FORMAT="128">Status</COLUMN> </TABLE> </TABLE> <TABLE NAME="TABLESPACES_1" DATA_SOURCE="R" > <UI_NAME>Tablespaces_1</UI_NAME> <COLUMN NAME="TABLESPACE_NAME" TYPE="STRING" TYPE_FORMAT="30" IS_KEY="Y">Tablespace Name</COLUMN> <COLUMN NAME="SIZE" TYPE="NUMBER">Size</COLUMN> <COLUMN NAME="STATUS" TYPE="STRING" TYPE_FORMAT="10">Status</COLUMN> <COLUMN NAME="NOTES" TYPE="STRING" TYPE_FORMAT="128">Status</COLUMN> <TABLE NAME="DATAFILES_1"> <UI_NAME>Datafiles_1</UI_NAME> <COLUMN NAME="FILE_NAME" TYPE="STRING" TYPE_FORMAT="1024" IS_KEY="Y">File Name</COLUMN> <COLUMN NAME="FILE_SIZE" TYPE="NUMBER" HISTORY_IGNORE="Y">Size</COLUMN> <COLUMN NAME="STATUS" TYPE="STRING" TYPE_FORMAT="10">Status</COLUMN> </TABLE> </TABLE> </METADATA> </METADATAS>
Alternative Option for Upgrading Configuration Data
There is another option provided for upgrade behavior. You can specify the DROP_EXISTING_DATA attribute in METADATA element of the Configuration Metadata XML file. "N" is the default value. When the attribute is set "N", the default upgrade behavior as described previously takes place.
If you set the DROP_EXISTING_DATA attribute to "Y", then the existing snapshot metadata is deleted (if present) as well as all the corresponding data, such as saved snapshots, comparison results, and history, and then the new snapshot metadata is registered.
If the new metadata is the same as an existing metadata and the "DROP_EXISTING_DATA" attribute is not specified or specified as "N", then no changes to the existing metadata are administered.
Note:
If you must have non-backward compatibly changes in your configuration metadata, then the only way to do this is to set the DROP_EXISTING_DATA attribute to "Y", thus losing any previous collected data with an older version of the snapshot type.Note:
If you set the DROP_EXISTING_DATA attribute to "Y" in the past, and you want to use the upgrade feature for backward compatible changes (that is, without dropping customer data), make sure you set the DROP_EXISTING_DATA attribute to "N" or do not specify the attribute in the new version of your metadata.Enterprise Configuration Management data is collected by regular metrics, collections and Management Agent mechanisms. This data is collected though regular RAW metrics with the following modifications:
Add a CONFIG=”TRUE” attribute to all Metric and CollectionItem tags that collect configuration snapshot information.
Ensure that the CollectionItem NAME attribute is the same as the snapshot type name (for example, oracle_home_config).
Note:
Do not include ECM_SNAPSHOT_ID as a column in any RAW metric table descriptorWhen ancestor key columns are included in child tables, you can populate a hierarchical set of tables one at a time, without having to express the hierarchical relationships during the collection. You should list parent tables before corresponding child tables in the Collection Item.
After integrating the configuration collection tables into the ECM framework, you can test the configuration collection by completing the following steps:
Restart the Management Agent.
AGENT_HOME/agent/bin/emctl stop agent AGENT_HOME/agent/bin/emctl start agent
In the preceding command, AGENT_HOME represents the Management Agent home directory.
From Enterprise Manager Cloud Control, select Targets, then select the required target.
Right-click the target and select Configuration, then select Last Collected to view the most recent data collection.
Check that the required collected data is visible.
If you are having problems with your configuration collections, do the following:
Check that your snapshot type is registered in the MGMT_ECM_SNAPSHOT_METADATA table:
select * from mgmt_ecm_snapshot_metadata where target_type = your_target_type and snapshot_type = your_snapshot_type;
You should see two rows. If not, check if there are any errors during registration in the regular log files for MRS in the following directory.
$ORACLE_HOME/cfgtoollogs/pluginca
Make sure that MRS does not produce any errors when it registers the Configuration XML metadata or register the Configuration XML metadata manually and ensure that no errors result. For more information, see Section 6.3.4, "Registering Metadata With the Configuration Management Framework".
Define the corresponding metrics to verify that collections begin and data accumulates. If the collections are not happening, then check the following:
Make sure that your collection item name is the same as snapshot type and CONFIG="TRUE" is specified for both the collection item and all its metrics.
For more information, see Section 6.3.7, "Modifications to Standard Collection Metrics and RAW Metrics".
Make sure your metrics are defined as RAW metrics and table descriptor corresponds to your ECM tables.
Check if the collection arrives to the Management Repository but is not updated as "current".
In the MGMT_ECM_GEN_SNAPSHOT table, check the is_current status for your target and snapshot type. If there are no rows, then the collection did not progress. The IS_CURRENT flag should be set to Y to indicate the latest snapshot of data. Rows with other IS_CURRENT values are possible for internal purposes. For example, if there are no rows with the Y value, then IS_CURRENT values of T and D would indicate a snapshot started loading but did not finish.
At Oracle Management Service and the Management Repository, check the MGMT_SYSTEM_ERROR_LOG table and the emoms_pbs.trc file for the snapshot type. Also check the MGMT_METRIC_ERRORS table as follows:
select * from mgmt_metric_errors where target_guid = 'your_target_guid' and coll_name = 'your_snapshot_type';
At the Management Agent, check the gcagent.log file and other files in agent log directory for the same string.
If you still have problems, turn on the Management Agent backup file feature:
Open the emd.properties file.
Add the following line to the file:
backupUploadedFiles=true
Restart the Management Agent.
AGENT_HOME/agent/bin/emctl stop agent AGENT_HOME/agent/bin/emctl start agent
In the preceding command, AGENT_HOME represents the Management Agent home directory.
Search for your snapshot type in the following directory to ensure that the Management Agent is sending data to the OMS:
agentStateDir/sysman/emd/upload/upload/succbkup/
A potential issue can arise relating to the configuration difference feature. If the configuration did not load but the Management Agent interprets that the configuration did load, (and if the configuration does not change), then the Management Agent sends short files indicating that nothing changed and the loader will continue to disregard the files.
To clear or eliminate this potential issue, clear the Management Agent log as follows:
emctl clearstate agent -incrementalconfig targetName,targetType
For example:
emctl clearstate agent -incrementalconfig myOracleHomeTargetName,oracle_home
Then, to initiate the collection, run the following command:
emctl control agent runCollection targetName:targetType snapshot_type
For example:
emctl control agent runCollection myOracleHomeTargetName:oracle_home oracle_home_config
From the Cloud Control console, test the history and comparison features to see how the results look or if any flags should be tweaked.
From Enterprise Manager Cloud Control, select Targets, then select the required target.
Right-click the target and select Configuration, then select History to view the configuration history or select Compare to test the comparison feature.
Note:
For more information about these pages, see the Cloud Control online help.
|
 Copyright © 2011, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|