Good designed ITSM Applications are reliable, modular, flexible and easy to maintain. All database tables are well indexed and the performance is acceptable from a user perspective. Okay, stop dreaming…..

An ITSM Application is likely a living elephant. With increasing of data records like  Incidents, Problems, Infrastructure Change and all the associated CI’s the good elephant turns to a bad mammoth. One option to increase the performance back to acceptable values is to archive the transaction data.

Scope

The Remedy out-of-the-box works as designed but doesn’t fullfill the archiving requirements of ITSM installations.

In general, a “living” Remedy ITSM environment requires an archiving solution to improve performance and overall usability. The Archiving solution should deliver a company/module level configuration that can be driven by customer requirements.

Best practise should be a Hybrid solution design; combining a Remedy configuration layer that will drive database stored procedures to physically move/delete data from the Incident Management, Problem Investigation, Known Error, Change Management, Service Request Management, Task Management, Work Order Management and bespoken applications ‘live’ tables to ‘archive’ tables.

Permissions

Archive data should be accessible via the same multi-tenanted permission model as for the Remedy application data. Data can be archived based on company and ITSM module/application. The archived ITSM data will be accessible via the current ITSM permission model.

The end user will determine which ITSM permission groups will have access to the archived data for each ITSM application, e.g. ‘Incident Master’ will have access to archived incident data.

Synchronisation

The ‘live’ tables and ‘archive’ tables need to be kept in sync in relation to field additions/changes. Field changes like increasing the field length can cause the database structure to change. This will cause issues for the archiving process. An API program will be executed before the archive process and will keep the tables in sync. Any structure changes will report to the log form.

The initial phase the archiving PL/SQL script will check the database repository to ensure that the table structures are identical. If fields are missing or have different data-type/length the PL/SQL will report an error and terminate without archiving any data.

Archiving

The archive stored procedure design methodology will encompass a parameter driven solution. These parameters can be configured in the Remedy Archive Configuration forms and passed when executing the stored procedure.

The stored procedure will be written in the Oracle PL/SQL program language. Any other SQL program language like Windows/SQL Server can be used as well. The PL/SQL stored procedure will deliver the following functionality.

• Database schema consistency validation of ‘live’ and ‘archive’ tables
• Gathering of transactional records, e.g. HPD:Help Desk for incident based on the company/module archive policy and business rule(s)
• Using the transactional record (primary key) to copy the associations based on the configured association SQL into the archive tables
• Delete the association data and transactional data records from the ‘live’ tables
• Capture transactional record counts, database errors etc by company/module and log this information into a separate table. This data will be available via a Remedy view form

The archiving of data in the ARSystem database will include associated status history (H table) data and attachments (B table).

The described solution is proven and works as designed.

Thanks to Dan Knight for his fantastic cooperation and contribution in this project.

Check it out

N-Tuition Australia web presentation