Migrating NewDB/IMCE databases to new shores

[Former Member]

Prelude

Let me start with some wild fantasy: We have the year 2012. No the Mayans were all wrong, it is not the end of the world. To the contrary, we have just entered a new era. SAP has released NewDB V 2.0 where all these fancy, awe inspiring new features of NewDB have been implemented and they really work! The database rocks, all SAP customers migrate their SAP systems to NewDB 2.0, the optimists have won the argument. Flabbergasted IBM pre-sales reps join with humble Oracle pre-sales reps in applying for SAP's job offerings. Everything turns out as Vishal predicted, or even better. What now?

NewDB, the new kid in RDBMS town

There were lots of announcements stressing especially the really impressive performance of SAP's NewDB / IMCE, but unfortunately there is very little technical information available and no roadmap. Collecting the information snippets available one gets this picture about NewDB:

• standard SQL compliant
• general purpose database
• very few tuning necessary, all table columns are indexed "out-of-the box"
• NewDB is not like MaxDB a "small" database but should be really "state-of-the-art"
• ...

Others have elaborated much better on the possible features. The important point is NewDB should be a full-fledged RDBMS like Oracle or DB2, and less like a MaxDB which has only relatively few distinct features. NewDB has to grow up really fast.

What is still left to do?

While I can only speculate about the actual technical features which NewDB will offer, even if the wild speculation from the opening would come true, there are still some facts which will remain untouched:

1. SAP systems tend to be deeply interwinded with their hosts. This poses a major problem for SaaS offerings (SAP as a service) or virtualizing SAP instances.
2. On average, it might be that a SAP system breaks off to new shores every three years (e.g. due to boxswaps, data center moves, change of outsourcing contract, mergers&acquisitions, ...)

So even if you are happy with the shiny NewDB, there will still be many migrations happening in the SAP world. If SAP is creating a new state-of-the-art RDBMS, then what features might be in for migrating NewDB instances?

A view over the fence: Oracle

With Oracle RDBMS, there are many advanced features available to simplify the life of the DBA. Especially when using Oracle 11g one can neatly migrate a database instance to another host:

1. clone the database via RMAN "clone database"
2. keep this cloned database in sync with your productive instance via Data Guard
3. migrate a whole (non-SAP) database instance via Oracle Streams
4. migrate a whole (SAP) database instance via Triple-O

The biggest advantage of such procedures is that most of the work can be done online and in advance, thereby reducing the required downtime for system migrations. A downtime of 2 hours, independent of the database size, is realistic.

Keep the fingers crossed for NewDB

I really hope that there will be some similar feature available for migrating NewDB instances. I do! Why is this important?

• downtimes are increasingly difficult to arrange
• mission critical systems are very restricted on downtime windows
• migrations happen typically at weekends, so migrations are expensive
• creating standby databases and keeping them in sync would allow migrations via WAN connections

The wish-list for NewDB might be already quite long, so why not adding one more item to it?

Summary

Of course, it is very easy to predict how a NewDB 1.0 can be migrated. You have either the option of using R3load, or you can shutdown your NewDB 1.0 instance, copy the files to another host and start the instance over there. However, I hope I could make the point why in NewDB 2.0 (or 3.0) there is a valid requirement for cloning database instances. This cannot be called true virtualization, but it would be a major requirement for optimizing your landscapes. (Whoo whoo, anyone from SAP ACC reading this?)