These days Oracle is one of the leading database systems, and T24 is many financial service providers' preferred core banking engine. However, if we go back several decades, things are pretty different. Then, the mainframe dominated our banking world, storing data in DB2 database systems.
If your core banking system is still using DB2 databases and the migration to Oracle is on your plan, you should read this post.
The T24 core banking system supports relational Databases such as DB2 and Oracle. Both have pros and cons, but we see more organizations moving to the latter to remove legacy technologies, simplify operations, and utilize richer features.
Oracle Tuning
Involves the initial requirements for setting up, configuring, and troubleshooting on DB.
Indexing
Implementing indexing and promoted columns on the ORACLE database for TAFJ improves the performance of 'expensive' queries, reducing response times.
There are several flavors of indexing you should consider
Single Value Field Indexing
Single value Field using TO_NUMBER function
Multi-value field indexing
Shrink or truncate
Tables grow over time, and also, in a core banking system, proper care is a must. Some index segments can exceed several GB, negatively impacting performance and backup procedures.
Prepare a script to shrink all tables as part of your maintenance task with a size greater than 1 MB but not having any records. As a second step, focus on the COB tables and make sure that you follow Oracle best practices such as
Resize the tables: Optimize the table and LOB sizes for archived files. Keep in mind that T24 API events do not reset the current size of tables.
Create an index for a function-based null index: There are situations where we have null values on fields and use them in a select. The problem is that indexing ignores null values. It would be best to use a second column as a composite index to solve such problems.
Improve the locking behavior: The F_LOCKING table is often highlighted in the AWR report because of high buffer wait and cluster wait times. Solving these issues is difficult, and our team is happy to implement significant improvements to this locking overhead in your environment.
Based on our experience, you should follow these guidelines in every database migration project:
1.) Take a JR environment – This should be the environment before installing the new license Or XML driver.
2.) Run the CONVERT.SYSTEM.UTF8.JBASE – Include the JBASE_I18N/JBASE_CODEPAGE variables as suggested – Make sure all the formal testing with report generation etc. during COB/ONLINE are done and verify UTF8 database.
3.) Install the new jbase license in the environment provided for XML driver installation. – You may need the server restart for the new license (Oracle standard license) to take effect.
4.) Set up the oracle database/XML driver/make sure the CREATE-FILE works as expected.
5.) Proceed with running the RDBMS Conversion program to migrate the JR to the Oracle database.
You should be in touch with distribution to get the STANDARD license for driver + RDBMS Conversion license to perform this migration.
Optimizer and Timeout
Everyone planning a T24 DB2 to Oracle database migration should also review the Optimizer and client side timeout configurations because they are different for Oracle databases.
One last side note about BLOB and XML documents in T24 databases is that both have pros and cons, and the LOB segment handling requires special attention.
If your Data migration project requires some helping hands, don't hesitate to contact our T24 experts. We are also interested in learning more about your experience in the DB2 to Oracle data migration journey.
Happy Performance Engineering! Keep up the great work!