Upgrade experiences

I’m planning for an Oracle upgrade, 9i to 11gR2. Cross-platform – Sun Solaris to Linux. Different Endian.

It’s just under 1TB so not big these days.

Downtime shouldn’t be too much of an issue. It’s not like it needs to be done in an hour or anything demanding like that. As long as it can be done within a day.

Within the client, there’s no official build for 11g on Solaris, so I think that might rule out solutions like an in situ upgrade to 11g on Solaris followed immediately by the move & conversion to Linux.

Imp/Exp seems to be the recommended approach given all of the above.

There are lots of resources out there to help with an upgrade.

So, no shortage of advice and guidance.

But I’m also interested in hearing some real world experiences.

So, if you’ve been through something similar, please let me know.

Tell me how you did it and how it went.

5 Responses to Upgrade experiences

  1. Hi Dom,

    I’ve done a cross-platform upgrade from 9i to 10.1 using transportable tablespaces. I think it was one of the first done that way and, even with 10.1, it went pretty well. It should work fine with 11 as the target. The possible show-stopper is we had to migrate the source 9i database to 10.1 on the old platform before we could use cross-platform transportable tablespaces, but we found doing the migration to 10.1 was not an issue. There was an intention that the transportable tablespace feature would work across patch version so you might not have to go all the way to the latest 11gr2 version on the original system?

    Depending on how your database is implemented you can potentially do a lot of pre-work before the actual move. We had most of the database as read-only tablespaces (something like 20TB) and just less than a TB read-write.

    Create your 10.1 {sorry, 11.2} target database.

    You copy over all of the read-only datafiles over a few days or weeks. We moved from Tru64 to Linux and even though they use the same endian-ness and thus should not have needed converting, we had to convert them using RMAN. It takes a lot less time than the copy, so you lose almost no time doing the convert (you set off other copies whilst converting the already-moved files).

    We also moved from non-ASM to ASM, so we actually copied the files over, rman converted them into ASM and them rman converted them to the correct endian-ness. That might not be an issue on 11.

    On the day of the move you shut down the original DB and copy over/convert the read-write datafiles. Of course, you do not copy over the system and sysaux tablespaces or the temp files.

    You then EXPORT the tablespace metadata and IMPORT it on the target. Start up the database, hold your breath and breath a deep sigh of relief when it all fires up.

    We did a lot of testing (and resolving of issues due to it being 10.1) but the actual move was smooth and we had no oddities afterwards. The database continues to work without issue and grow for several years afterwards.

    If you have any IOTs you might have issues with the original 9-x migration, check out metalink for the bugs

  2. dombrooks says:

    Thanks Martin, that’s interesting. Exactly the sort of thing I was after.

    I don’t normally get involved in upgrades etc, dealing as I normally do with performance, application development, etc.

    In fact, now that I think of it, the last production system upgrade I did was probably to 7.3.4. back in something like 98.

    However, with this one, it looks like I’ll be seconded to the DBA team to sort out the upgrade itself. I’ll do anything to get an application off 9i and up to something recent 🙂 … (there’s not much to blog about when you find yourself back on 9i).

    Sounds like planning is the key to making the actual upgrade as easy and simple as possible on the day.
    Planning, testing, testing and then more testing.

  3. Marko says:

    Thanks Martin for sharing real world experience.
    We are also planing migration 9i->11gR2 from Solaris to Linux.
    I’ve made simple test (9i->10g) using cross platform migration and blogged about that – http://tinyurl.com/325b9xs

    As you said Dom – the key is planning and testing 🙂

    I wish you luck with your migration and I hope you will blog a little more about your RW experiences on that subject.

    Best Regards,
    Marko

    • dombrooks says:

      Hi Marko,

      Just read your article – nice.

      What you describe pretty much matches my initial thoughts – doing a same platform upgrade first then a convert.

      Cheers,
      Dominic

  4. Pingback: Log Buffer #199, A Carnival of the Vanities for DBAs | The Pythian Blog

Leave a comment