Skip to Content

Migrating NewDB/IMCE databases to new shores

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?)

7 Comments
You must be Logged on to comment or reply to a post.
  • Hi Mark,

    You’re asking the right questions here. And I’m sure that we (SAP) will follow up on these… as soon as the first HANA customer actually *requests* such features.

    I really cannot say that there weren’t many highly experienced and talented colleagues (with combined hundreds of years experience in DBMS development and operations) involved in HANA development. But what is true – from my maybe not so high level point of view – is that development for HANA is done very closely to match what the customers request.

    So, let’s hope they ask for the right things 😉 , shall we?

    best regards,

    Lars

    • Hi Lars,

      I am quite sure that customers will start asking for features to speed up migrating HANA instances in 2015. Typically the hardware lifecycle is around three years, so with the first BW on HANA instances being installed now, the first refresh cycle will start in three years. However, once customers ask, they want the solution right now. Therefore I thought why not writing a blog on that topic. This is of course no urgent issue, I just thought maybe it could be considered in HANA architecture and put on the wish list.

      My enhancement request at Oracle (classified as severity 2 – Very desirable feature) is now already three years old and still nothing happened. So I hope I will have more luck with HANA.

      Please keep on blogging about the HANA backtrace (if I manage to find them on the new SCN I’ll surely read them …)

      Mark

      • Hi Mark,

        new blog posts are all “in the pipeline” – but sometimes it’s just difficult to find the time to sit down and write them acutally… anyhow  – I’m looking forward to get something out in the next two weeks again…

        And sure, you’re right about the feature requests. I had my own experiences with Oracle (and other DBMS) on this. For HANA on the other side I’ve to say (without beeing super-optimistic here) that I’m impressed how much was achieved in the short time of development and how promptly bug reports and feature requests are usually answered. Thefore I tend to say: your – and our – hopes for having more luck with HANA do have a good chance not to be disappointed.

        Lars