Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Test of>10gr2 upgrade, platform important?

Re: Test of>10gr2 upgrade, platform important?

From: Bjrn Drr Jensen <>
Date: Mon, 16 Jan 2006 19:27:46 +0100
Message-ID: <002101c61aca$8c2811b0$6501a8c0@camelopardalis>

thank you for the examples, i fully agree. Every difference is an candidate for wasting time! One thing is to know the right thing another to explain it understandable for management ;-) /Bjoern


     This should be simple.

     The whole idea to "testing" is to ensure that the thing you are testing will actually work when you do it for real. Would you test an Oracle 9i -> Oracle 10g upgrade by migrating a database from SQL-Server 2000 to Sql-Server 2005? Of course not!

     Sure, Oracle is "platform agnostic". If we're not talking about religion, the definition of "Agnostic" (from '') is:

    One who is doubtful or noncommittal about something.

     Hmmm... "noncommittal". No wait -- I don't want open a whole new discussion here. To be honest, though, in the case of Oracle (or the Oracle DBA), the term "platform agnostic" might be better defined as:

    One who has no idea how or when a particular platform is going to make their life hell.

     It is hardly unheard of for a task or procedure (or query, or ....) to work flawlessly on most platforms, and yet blow sky-high (usually due to platform-specific bugs) on one or two. Performing a migration test for Oracle 9i to 10g on Windows would in no way satisfy me that my (proposed) upgrade procedure will actually succeed on HP-UX.

     Not only should your test environment be on the same platform as production, but it (or at least *one* of your test environments) should be as close a possible to *physically* identical to production. Providing that it is not absolutely cost-prohibitive, anyway. ('Course, I personally would argue that if you can't afford the *test* environment, you certainly can't afford the *production* environment either.) Same model. Same OS. Same patches. Same type and number of CPUs. Same amount of RAM. Same type and number of I/O controllers. Same type of storage. Same firmware. Same... well, I think you get the picture. I have seen people get burned by variances in all of these...

     Anyway, this is not something you should need to explain to your management. If "your management" doesn't "get it", then maybe you should think about "getting" new management. ;-)

     To be fair, though, I *have* had clients or managers balk at this myself. Usually, minimal "explanation" is necessary. For example, a question like:

    If you use Fibre-Channel SAN storage in production, and direct-attached SCSI in the test environment, how do you proposed to "test" upgrades to the software that manages the multi-path I/O in your SAN?

  is often all the explanation I've needed. On occasion, I've had to point out the (happily rare) need to test devices drivers, kernel patches, etc. If that fails, I can tell stories of the RDBMS (happily not Oracle) where backups worked fine on single-processor servers, but failed (silently!) on multi-processor servers. After enough of examples like this, even a "manager" will usually "get it". :-)


  Bjrn Drr Jensen wrote:
    Hi Hemant!
    Thank you for your answer! I expected an answer like this, but I'm not     having experience wiht upgrade-tasks     and without it, it's difficult to convince management about the point of     having the right platform for testing...     If you or someone else reading this can give me more links about it I'll be     happy ;-)
    Thank all of you for your help!

    As a rule, the development/test environment is generally the same platform     as prod.
    Of course, Oracle is "platform agnostic" -- you can develop your scheme,     stored procedures etc
    on a database on windows and port them to a database on AIX.     But when it comes to upgrading your database, your test upgrades should be     on
    the same platform as prod. Not only will it help you identify     platform-specific
    issues {different OS patches are pre-reqs for 9i/10g}, it will also help you     run the actual Oracle installation specific to that platform.

    You would be running the test upgrade to a different platform from prod only     if
    the test platform is your target platform for the live upgrade -- ie you     ARE planning
    a platform migration.
    At 03:29 AM Saturday, Bjrn Drr Jensen wrote:

      I suppose that it's very important to test an upgrade in an environment 
      similar to production. 
      Lets say production environment is AIX, database-size about 100Gb. 
      Can I (=is it meaningfull) to test upgrade in windows-environment when 
      production is AIX? 

    Hemant K Chitale


Received on Mon Jan 16 2006 - 12:28:10 CST

Original text of this message