MDB Frequently Asked Questions
 Last Updated: January 21, 2010

General Concepts

Q 1: How does this relate to the CORe?

A 1: The MDB completely replaces the Common Object Repository (CORe) that was used by pre-r11 releases of Unicenter NSM.


Q 2: Is it the same as a CMDB?

A 2: No. A “CMDB” (Configuration Management Database) is a core requirement for many of the IT Infrastructure Library (ITIL) best practices. It holds information for, about and related to configuration items (CIs) and the relationships between those items. As a result, this type of data can be described as more logical than physical.  The primary purpose behind implementing a CMDB is to provide change management and historical functionality, including versioning of configuration items and historical analysis.

The CA CMDB is a product that can run either stand-alone or in conjunction with Unicenter Service Desk.  It supports both ITIL and non-ITIL implementations and includes integrations with other products such as CA Network and Systems Management, CA Asset Portfolio Management, CA Asset Management as well as 3rd party products. 

While an MDB also contains both asset and configuration item information that doesn’t make it a CMDB.  Whereas the CA CMDB is an application which provides a single source of truth about CIs and graphically depicts their relationships, the MDB provides the common operational data store for many CA products – including the CA CMDB.

Q 3: Where can I find more information about the MDB Schema?

A 3: The MDB Schema Viewer can be accessed through the following link:

The viewer provides the following information for both common and product-specific tables in the MDB:

 The MDB Schema Viewer also includes Erwin models for the following products:

 Additional models will be added in the future. 

Installation and Planning

Q 4: Where can I find information on migration? Can I stage my migration with multiple products (e.g., upgrade NSM first, then USD) and still maintain integration?

A 4: For Unicenter NSM, migration information can be found in the Migration Guide. For other products, such as Unicenter Desktop and Server Management (UDSM) or Unicenter Service Desk (USD), migration information can be found in the Implementation Guide. As with previous migrations, you have the option to upgrade in-place (on the same machines) or in parallel (on separate machines) and you also have the option to phase your migration over a period of time - provided you begin upgrading "from the top down." For example, NSM DSMs should be upgraded before Agents because a version 3.1 Agent can report to an r11 DSM, however, a version 3.1 DSM cannot manage an r11 Agent.

When you are upgrading multiple products, the order should be dictated by your administrative requirements and by the availability of the staff responsible for conducting the upgrades. There is no compelling technical reason to upgrade one product before another.


Q 5: Can I have more than one MDB? If so, how should they be distributed?

A 5: You can have multiple distributed MDBs for a single product, a single MDB shared by multiple products or a combination of the two.  The number of MDBs you need and where they should be placed is dependent on a several key factors – including which products are being deployed, the degree of integration that is required, as well as the nature of the deployment environment itself – how large, how distributed and the reliability of the network that connects it.

The “MDB Federation Page”, available from the Implementation Best Practices website includes several useful sources for further information regarding multiple MDBs.  The direct URL is:


Q 6: How can I aggregate or exchange information from multiple MDBs?

A 6: This will depend on the solution you are deploying. For example, Unicenter NSM provides a Repository Bridge function to share information across multiple repositories and includes existing integration mechanisms that work across MDBs already (e.g., Unicenter NSM to Unicenter Service Desk via an event or rule). Unicenter Service Desk includes a tool to import asset information from Unicenter NSM or Unicenter Desktop and Server Management.  Unicenter Asset Intelligence was designed from the onset to draw from multiple MDBs and consolidate data into a top level MDB. Ingres and SQL and Oracle also provide utilities that utilize XML to export and import data from one database to another, as well as other methods. Consult the product and database specific documentation for more details.


Q 7: Where should the MDB be installed in regards to my current network configuration?

A 7: That will depend on what products and which components you are deploying as well as how the administration will be handled (locally vs. centrally) and which objects you plan to manage. The communications requirements for each deployed components also need to be considered when there are firewalls. An MDB planning presentation that discusses this and other placement considerations can be found at the following URL:


Q 8: How can I secure the MDB?

A 8: Tables in the MDB are being created with the same level of security as they have had in each product’s original database. Currently all of the tables are created by a single user ID. To gain access to the tables a user must be explicitly granted access. This means that very few users have access to the tables unless explicitly permitted.

When Ingres is installed, it creates and populates the MDB. This is done by an Ingres user called MDBAdmin. MDBAdmin is not an OS user and this is by design. There must not be an OS user named MDBadmin. If you are unable to connect to the MDB database, or are unable to select the tables you would expect to be able to then please check that the Ingres user you are using has the required permissions and is set up properly. All other Ingres users accessing tables in the MDB need to have OS users with the same user id and permissions to access required tables.


SQL Based MDBs

Q 9: I'm planning to use a SQL Server-based MDB. Is the default character set relevant? What about case and access sensitivity? Should the SQL Server case and accent sensitivity match that of the MDB?

A 9: No. The MDB setup process looks at the default server collation, strips off the case and accent sensitivity tokens and appends "_CI_AS" (case insensitive, accent sensitive). For example, the MDB collation may end up as the following:


where "SQL_Latin1_General_CPI" is inherited from the default server collation and "CI_AS" is appended by the MDB setup process. This practice eliminates any issues where the server collation does not exactly match what we need.


Q 10: For SQL-based MDBs, what authentication mode should I use?

A 10: Authentication must be set to "Mixed Mode (Windows and SQL Server Authentication).” If SQL Server was installed with "Windows Authentication Mode" you will need to do the following in order to change it to mixed mode:

1.      Launch the SQL Server Enterprise Manager and drill down to the Server.

2.      Right click and select Properties

3.      Click the Security tab and select "SQL Server and Windows" under "Authentication"

Note: Before changing from Windows Authentication to Mixed Authentication, make sure you assign a password to "sa."

This change will not take effect until you restart the SQL Server.


Q 11: Do I need to change the dictionary order, comma settings or rounding preferences?

A 11: No. These settings are not relevant to the MDB.


Q 12: Can I install the MDB on a non-default SQL instance?

A 12:  That currently depends on the product itself.  The document available at the following URL describes the concept of installing multiple MDBs on different SQL instances or on a Cluster Resources group.


Q 13: I’m planning to install several MDB-based products – is the install order important?

A 13: In general, with one notable exception, if the MDB is to be SQL-based, the answer is “no.” The SQL MDB creation process includes built-in intelligence that performs the following checks:

The end result is an MDB that is at the current version and patch level.

The application that is being installed (e.g., Unicenter NSM, Unicenter Service Desk) should then perform the following tasks:

If you are installing multiple MDB-based applications, there are no requirements regarding which application is installed first. In fact, the rule of thumb should be to select the Install MDB option for each application. If the MDB already exists, selecting Install MDB, will:

Note that these guidelines only apply to SQL-based MDBs. If you are installing an Ingres-based MDB, selecting the “install MDB option” will, instead, drop the database and recreate it.

One important consideration is which version of the MDB is being installed by each product. MDB r1.5 installs only those database tables that are used by the product being installed. Previous version of the MDB installed ALL database tables used by ALL products that utilize the MDB - even if those products are not currently being installed. Therefore, if you install a product that uses MDB r1.5 first and then plan to share that MDB with another product that uses an earlier MDB version you will need to convert the existing MDB to be compatible with that product. Further details can be found at the following link:


The following document summarizes the role of installation order when 2 or more applications will be sharing the same SQL based MDB:

Integration and Customization Considerations

updated.gif (1425 bytes)Q 14: What modifications can I make to the MDB? Are there tools provided to do this?

A 14: It is important to understand that the MDB in and of itself, is not a solution; it is a facility that is used to support solutions.

Solution integration is something that the MDB helps to facilitate, but the MDB itself does not provide any reporting or third party integration tools per se; rather, these are provided at the product/solution level.

That said, the key to MDB integration is “CORA” - the Common Registration API.  CORA is the interface through which assets are registered and is the only source for updating the MDB tables.  CORA ensures that asset data flows consistently, thereby supporting the data and referential integrity of the MDB's master asset data model.  To understand how products register their assets in the MDB consult the “MDB, Hardware Assets and CORA” document which is available at the following URL:

The MDB, however, is not limited to CA products.  For information on using Advantage Data Transformer (ADT) to import Microsoft SMS data into the MDB, check the following link:

You can also employ the new Unicenter Desktop and Server Management (DSM) r11 Reporter to use asset data from the MDB in other applications. To download a zip file which includes both a detailed document and other supporting files demonstrating examples of how this data can be used externally, check the following link:


Fault Tolerance Considerations

Q 15: What is the recommended failover configuration? what steps can I take to ensure high availability for my critical r11 components/applications?

A 15:  The Fault Tolerance section of the Implementation Best Practices website provides a number of discussions and further links regarding fault tolerance considerations for MDB-based solutions.  To access this section directly, use the following URL:

In general, clusters are the best practice recommendations for providing HA SQL MDBs and this section provides presentations outlining cluster deployment options for Unicenter NSM, Unicenter Desktop and Server Management, Unicenter Service Desk and Unicenter Asset and Portfolio Management. 

An overview of HA considerations for shared, multi-product MDBs is provided at the following link:

High Availability for Unicenter NSM is discussed in Chapter 4 "Deployment Architecture for Systems Management" in the Systems Management Greenbook. This guide can be accessed through the following link:

High Availability for Unicenter Service Desk is discussed in Chapter 14 "Architectural Choices" in the Incident and Problem Management Greenbook (v1.1). This guide can be accessed through the following link:


Maintenance and Optimization

Q 16: The hostname for my Ingres MDB is going to change. What modifications do I need to make to the MDB itself?

A 16: There are a number of Ingres changes that will need to be done.  For a step-by-step outline of all necessary procedures, check the following link:


Q 17: What do I have to do to maintain my MDB?

A 17: Performing basic maintenance tasks and monitoring key performance indicators for your MDB can ensure that both the MDB and the products it supports are operating at optimum levels.  It can also ensure that you are better prepared to retrieve critical data in the event of a disaster recovery situation.    

Standard database maintenance guidelines still apply and, although the following “Care and Feeding…”  documents identify basic tasks and concerns specific to MDB administration, they should not be considered a replacement more detailed DBA skills


For Ingres based MDBs:


For Oracle based MDBs:


For SQL Server based MDBs:



Q 18: My Ingres-based MDB is installed on Windows and I've noticed a large number of handles being used - is this normal?

A 18: Yes. Ingres preallocates most of the resources it requires and it often uses hundreds of megabytes of virtual memory and several hundred thousand handles. The exact use of resources depends upon the number and sizes of the page caches used. For example, the default medium MDB configuration provided with r11 products uses about 1GB of virtual memory and roughly 350-500K handles. Note that this use of handles causes no problem. Also note that SQL and Oracle do not use large numbers of handles, so there is nothing wrong if you do not see this with those databases.