Efficient Data Lifecycle Management in Temenos T24

DLM involves the process of maintaining the historical data in T24. The part of historical data is kept in Live DB, and the older data is moved to Read Only database (R/O DB). It involves data separation and data retention process.

Data Separation

It involves moving the historical data from the Live database to the new Read-Only database.

Initial separation is carried out in a staging area, which leaves the performance of the live database unaffected. The Read-Only database is created and populated from the restored live copy. The ‘Live copy’ schema is purged upon completion, leaving the Read-Only schema.

Once the Read-Only database is populated:

• The copied data is purged from the actual Live database.

• The Read-Only database is moved to the live server to be synchronized.

Temenos Changes	·    Add DL Product ·    Add Copy and Purge Services and script generation programs for R/O DB. ·    VOC, T24 updates to enable redirections and enquiries for R/O DB.
DB Changes	·      Temenos Live DB change: Link with RO DB and view copy and purge services. ·      RO DB change: Depending on the type of DB, the same or different schema is decided for Live and RO DB. ·     RO Tables: Read-only tables are partitioned by month. Monthly tablespaces are pre-created for the length of the data retention period - 60 tablespaces are needed for the typical retention period of 5 years. ·  Other Changes in Archive tables, copy and purge services
Operational Changes	·    Add the Read-Only database to the Live database server(s) ·    Add the Read-Only database to backups ·    Add the Read-Only database to monitoring Systems ·    Add the Read-Only database to the planned maintenance schedule ·    Adjust the scheduling window ·    Update database definition
Recovery Procedure Change	·    Recovery procedure should be the same for Live and RO DB backup. ·    During the recovery of the Read-Only database, you may be able to restore the tablespaces of the most recent data first and bring the Temenos Core Banking suite back online, while the others are still being restored.

Copy and Purge Services

In the DLM system, the copy (DL.COPY.PROCESS) and purge (DL.PURGE.PROCESS) processes are integrated with the existing Temenos Core Banking archiving service (ARC.GENERIC). The Temenos Core Banking Copy and Purge Services maintain the movement of data between the Live and Read-Only databases within given retention periods.

Process Flow:

Service	Description
ARC.GENERIC service	The Temenos Core Banking ARC.GENERIC service generates the KEYLIST information, a list of record keys that are moved for each Temenos Core Banking module.
RO.COPY service	The RO.COPY service processes the list of record keys from RO.COPY.KEYLIST table and copies these records from the Live database to the Read-Only database.
RO.PURGE service	The RO.PURGE service processes the list of record keys from RO.PURGE.KEYLIST table and deletes these records from the Live database.

Temenos Changes	·  Two new Temenos Core Banking suite services, the RO.COPY service and RO.PURGE services have been added, in addition to the ARC.GENERIC service.
DB Changes	·  Copy, Purge, and Error keylist tables and views have been added to the Live database. ·  The DLM database package has been implemented for both the Live and Read-Only databases. ·  DLM Copy functions have been added to the Read-Only database. ·  DLM Purge functions have been added to the Live database.
Operational Changes	·  Add the RO.COPY and RO.PURGE services to scheduling and monitoring systems ·  Monitor three additional tables RO.COPY.KEY.LIST, RO.PURGE.KEY.LISTand RO.ERROR.KEY.LIST ·  Monitor RO.ERROR.KEY.LIST constantly for record movement errors and purge failures
Recovery Procedure Change	·  The failure of one or all of the RO.COPY, RO.PURGE or ARC.GENERIC services will not affect the Temenos Core Banking suite from running normally. You can operate the system as usual, while you investigate the failures. Once corrected, you can re-schedule the services accordingly.

Lifecycle Management

The Read-Only database contains historical data in monthly partitioned read-only tables for a specified retention period. The retention period is typically five years but will vary from client to client depending upon legal and local requirements. Once the data has passed this retention period, it can be aged out into archive tables, in new tablespaces. The archive tablespaces are partitioned by year, and the physical data can be stored on standard, less expensive storage media as the data will be rarely, or never accessed.

Performance Improvements

·      Reduce Live DB size

·      Improving Live DB performance

· Application-specific date range partition and data maintenance

·      Better Response time if Archive data is indexed

Keep up the great work! Happy Performance Engineering! #TemenosT24 #DataLifecycleManagement #CoreBanking