Choosing the Right Database Migration Strategy: Real-World Lessons and Pitfalls

1. Storage Replication

Storage replication is a convenient method for cross‑storage database migration, especially when multiple databases coexist in one environment. The storage vendor handles most of the work, leaving the DBA to run rman validate to check for physical or logical block errors. A ten‑year‑old case migrated a core Oracle 9i HA database to 10g RAC, moving from IBM 8000 series to HDS high‑end storage using the vendor’s heterogeneous storage virtualization; the final cut‑over took just over an hour.

While some DBAs conflate volume copying with storage replication, they differ: volume copying relies on volume‑manager software (e.g., VERITAS LVM) and works across heterogeneous platforms, whereas storage replication requires native support from the storage system. Most modern high‑end arrays support heterogeneous virtualization, but if not, a rented virtualization appliance can be used at a cost of a few thousand to tens of thousands of yuan.

Another example involved moving a database from an HP mini‑computer to an IBM mini‑computer, swapping HP storage for EMC. Using VERITAS volume replication, a bug in Oracle 10g caused UNDO tablespace conversion to fail, forcing a manual workaround that extended the migration beyond the planned window, illustrating that even simple methods can encounter unexpected issues.

2. Logical Replication

Logical replication is often chosen when the downtime window is tight. In the early 2000s, an operator migrated billing and accounting systems from Oracle 8i to 10g using Oracle GoldenGate (OGG). OGG’s performance and stability were limited, leading to missed table updates; the team fell back to dblink CTAS for the final migration, completing within the allotted window.

Logical export/import is considered safe but not infallible. A bank migrated its core system from HDS storage to Huawei 18K while upgrading from Oracle 10g to 11g, allocating an 8‑hour window for the database. After exporting data from the old storage and mounting the volume on the new server, an engineer mistakenly mounted the disk as read‑only, causing impdp to fail after five hours. The team continued, discovering that most data had already been imported; they postponed a full re‑statistics of tables, which later proved necessary for performance.

Post‑migration performance testing revealed a 40 ms increase in core transaction latency, exceeding the developer’s 120 ms limit. Investigation showed outdated statistics on several tables; after gathering fresh statistics, latency dropped to ~90 ms, meeting the requirement. This case highlights that even the simplest migration can surface hidden performance issues.

3. ASM Disk‑Group Add/Remove

Adding new disks to an ASM disk group and gradually removing old disks, using ASM’s REBALANCE feature, offers another migration path. REBALANCE can be lengthy for large data sets under heavy load, potentially causing I/O contention and overall performance degradation. DBA monitoring is essential, and priority may need to be lowered during spikes. A bank that adopted this method reported stable migrations for many systems, though they avoided it for the most critical transaction environments.

In summary, many migration techniques exist, each with trade‑offs. Successful migrations require stepping outside the traditional DBA mindset, thorough preparation of every step, and selecting the method that best fits the specific system environment and team expertise.