A proprietary operational system shared a single Oracle database instance with the company's implementation of Oracle Financial's. The database instance required a unusually large team of highly skilled Oracle DBA's with numerous database engine customizations to support the client's applications at existing transaction levels. After upgrading the main processor and real memory available in an effort to scale the operation, the customer realized no increase in performance.

After a careful analysis, it was determined that the single database instance was unable to effectively manage enough memory to scale beyond the current transaction levels. A migration plan was developed to split the proprietary operational components from the customer's Oracle Financial components, resulting in two separate database instances running on separate processors. Cross-communications between the two instances was maintained through the use of very high-speed dedicated links between systems and implementation of a limited number of transactions utilizing views which spanned the two instances. The implementation of the migration occurred during a weekend, scheduled maintenance window and resulted in zero unscheduled downtime for the client. All scalibility targets were achieved and performance issues previous seen have not been experienced since infrastructure was re-implemented. No application code was altered in the restructuring of the underlying database layer. Both of the new Oracle database instances were returned to default installation configurations and the DBA workload returned to conventional levels for installations of similar size.