This month's Tip is a start of a new series on the APM database. This article gives an overview of some parts of the APM database administration lifecycle.
The APM database is a superset of the 4.x CEM database containing data both for APM CE and Introscope. This includes:
- APM CE overall configuration settings. Most of these can be configured through the APM CE MOM-TESS GUI interface.
- APM CE transaction definitions and related settings (such as defect thresholds, SLAs).
- APM CE statistics settings and values (such as retention).
- And new to 9.x, application triage map data
The database schema is not publically available but one can see the tables and fields used in the APM database by examining the various database scripts found under the <EM_HOME>/install directory such as the createtables, createapmtables, createappmaptables. Other installations scripts set the table constraints and sequences.
Note that only one APM database can be active in a cluster at a time and currently only custom APM database failover mechanisms are used.
This is a very important task to get correct. So take the time that you need to investigate and plan for the APM database deployment. CA Technologies resources are available to assist as needed.
When deploying a database, there are several decisions to make:
1) Choosing the Database vendor. The APM database may be installed on either Postgres or Oracle. (There is a tech note that explains some of the requirements that you may consider in making this decision. Also, there are many articles publicly available on this topic to help in the decision process.) Both products will do the job so select what makes sense for your environment.
2) Architecture and Sizing
Getting this step right is important for a stable environment. Failure to do so may mean
- Database being too busy to be available to perform operations because being undersized or not on dedicated box.
- Database operations stopping for running out of table space. (In more recent APM releases, there is a configurable warning for Oracle when this is about to happen.)
- Database operations not completing because the database is running out of memory.
Some of the things to determine are the following:
- Where on the network to place the APM database in relation to the EMs and TIMs. Placing it in another database center than the EMs could contribute to performance problems due to network latency and other factors.
- Size of the database. You want to be able meet your present and future needs. (Such as if you need to monitor thirty additional applications tomorrow. Use the APM Performance and Sizing guide on factors to consider for sizing.
- Hardware requirements to make sure the memory and other hardware provided are adequate for present and future needs.
- Look into the connection pool (c3po) settings to see if they need to be changed for the number of planned database connections.
3) How many databases?
- is there a need for multiple databases for different environments, failover, testing etc.? How many are needed?
4) Dedicated or Non-dedicated server?
- Unless it is a small test environment, a dedicated server is a good investment from a performance standpoint. Otherwise you may have some of the issues mentioned earlier.
5) Is Database needed at all?
- If this is an Introscope only installation and not using appmap, then a database may not be needed at all. However, your logs may then be filled with all sorts of database errors and EM startup/shutdown may be slower.
The install guide goes into the details on this area. Some of these include:
- Database pre-requirements (Not meeting these can impact successful database performance.)
- Order (Install database then EM or the reverse? Typically most sites do the former)
- Account used -- root or not-root. (But not sudo.)
- Parameters to enter during database installation (such as database name and port, account name and password, database password)
It also lists any post-installation steps that are needed to be completed.
One important step many administrators often forget is to look at the install log and schematools.log to see if the database installation is successful. Since the database installation is running a series of SQL scripts, it is possible that a line in an individual script was not successful. This can only be found by reading the entire APM database log (Unlike the install log, there is no summary at the end to see if was successful or not.) In some cases, the database may need to be installed again
In the coming months we will take on APM database upgrades and migrations, administration, and optimization.
Questions for Discussion:
1) What are the lessons that you have learned and best practices followed for APM database planning, architecture, and deploying?
2) What would you like to see changed in APM database installations?
3) What other database topics would you like to be covered in Tuesday Tips?