Moving from Rdb to Oracle RDBMS

This large educational institute wanted to change its Student Management System database from Oracle Rdb to Oracle RDBMS hosted on Linux in order to better facilitate integration and standardisation with other systems. As the migration was to be performed incrementally over several months with periodic refreshes of data to the target Oracle RDBMS database, tools were developed to automate various aspects of the data synchronisation and migration process, including a powerful "data pump" utility that could be used to create and update database structures such as tables and indexes in the target Oracle RDBMS database based on metadata read from the source Oracle Rdb database, and automate the transformation and transfer data from the Rdb database into Oracle RDBMS. This approach allowed data to be migrated with minimal disruption to the existing operational environment and made final cutover to the new database environment seamless. In addition to migrating the application data from Oracle Rdb to Oracle RDBMS, application code was modified in a semi-automated manner to convert embedded RDML and some of the surrounding logic into Oracle PL/SQL stored procedures.

What technical problems did that raise?

The main technical challenge for this project was automating the creation and ongoing population of the Oracle RDBMS database in a largely automated manner. In general, mapping database entities between the two database environments is relatively straightforward; however, there are numerous small subtle but often significant differences that needed to be taken into careful consideration, ranging from differences in reserved words, through to differences in date formats, use of nulls, and so on. It was also necessary to consider differences from the perspective of application code, such as differences in locking strategies, and to make appropriate changes to such code to ensure that identical results were obtained when applications were run against the new Oracle DBMS database.
In terms of keeping data suitably synchronised between the two database platforms, while it was not necessary to do this in real-time, data migration operations needed to be performed within specific time windows, and accordingly is was necessary to ensure that the operation of the data pump solution was as efficient as possible. This was achieved through careful coding and by making full advantage of highly efficient data export and import facilities provided by the respective database products wherever possible.

What are the benefits?

The primary benefit to the customer was a cost-effective solution to the database conversion that included features specifically tailored to their particular situation and requirements. The alternative would have been to utilise an off-the-shelf product to help facilitate the database migration work, however it would then have been necessary to develop additional components to address specific requirements. By developing a custom solution, it was possible to address all requirements with one simple-to-use tool, the development cost of which was only a small fraction of the overall project cost.