To minimize the impact on the production BMC Remedy AR System database, BMC recommends that you use a separate reporting instance of the BMC Remedy AR System database with BMC Analytics for Business Service Management.
Only the tables used by BMC Analytics for Business Service Management (BMC Analytics for BSM) must be replicated for this separate instance, and they must be in the same form as in the underlying BMC Remedy AR System database so that BMC Analytics for BSM can work seamlessly with the replicated tables. For a full list of database views that are used by BMC Analytics for BSM, see ITSM universe classes, objects, conditions, and views.
For a procedure for replicating the BMC Remedy AR System database, see your database documentation. The following diagram shows the architecture of the recommended deployment for replication.
BMC Analytics for BSM with replicated BMC Remedy AR System database
(Click the image to expand it.)
Consider the following points when implementing the product with a replicated BMC Remedy AR System Server database:
- Because the replication is done at the database level, you do not need to obtain additional licenses for BMC Remedy AR System.
- Only the tables that are required for the ITSM universe need to be replicated. See ITSM universe classes, objects, conditions, and views for the list of tables.
- Any tuning performed on the replicated database to enable better query performance is separate from any operations performed on the production database.
- The hyperlink from BMC Analytics for BSM to BMC Remedy AR System is maintained in the operational datastore as long as the time to replicate the information into the operational data store is kept to a minimum.
- Generally, some time elapses between data creation on the production server and data replication to the operational data store.
- Maintaining separate databases to support the business functions of BMC Remedy AR System and the reporting infrastructure results in a smaller performance impact to BMC Remedy AR System than using the production database for reporting.
- The reporting database should not be bound by limitations of the applications database sizing and data recommendations. The reporting database might be subject to different data retention guidelines.
- Separating the service desk and support application from the reporting services and operations minimizes the impact on your services. During an outage, if the two services are dependent on the same database and server configuration, both services are impacted.