This discussion is archived
11 Replies Latest reply: Oct 29, 2012 2:40 AM by BillyVerreynne RSS

RAC Upgrade

SaikatBanerjee Newbie
Currently Being Moderated
Hi,

Currently our production is running on 10.2.0.1 RAC. I need to upgrade to it to 10.2.0.5 RAC. Do I test my application on 10.2.0.5 RAC ??? Or testing application on 10.2.0.5 stand-alone is enough??

Need your valuable suggestion

Regards,
Saikat
  • 1. Re: RAC Upgrade
    Sunny kichloo Expert
    Currently Being Moderated
    test my application on 10.2.0.5 RAC 
    Yes
  • 2. Re: RAC Upgrade
    Catalin Trifu Newbie
    Currently Being Moderated
    Always test on the same hardware/software platforms as you will use in production.
  • 3. Re: RAC Upgrade
    BillyVerreynne Oracle ACE
    Currently Being Moderated
    Saikat Banerjee wrote:

    Currently our production is running on 10.2.0.1 RAC. I need to upgrade to it to 10.2.0.5 RAC. Do I test my application on 10.2.0.5 RAC ??? Or testing application on 10.2.0.5 stand-alone is enough??
    Why do you expect your application not to work on 10.2.0.5? Does it rely or use on undocumented features? Or undocumented spfile settings?

    The upgrade is to a newer patchset. Not a new version. A patchset introduces bug fixes. Not the brand new features and behaviour that a new version may introduce.

    If your app works on 10.2.0.1, there are no reason why it should not work as well on 10.2.0.5 - unless you have some funky code using undocumented stuff. Or you are one-in-a-million that have your code now running into a new bug that 10.2.0.5 introduces due to something like only partially patching an existing bug. (and if you are one, then play the lotto)
  • 4. Re: RAC Upgrade
    SaikatBanerjee Newbie
    Currently Being Moderated
    Hi,

    Thanks for your reply.

    So, I understood from your reply that 99.99% (thanks you mentioned the exceptions where it may not work) cases the app will work for 10.2.0.5 RAC since its a same release..i.e, 10gR2. If we would migrate the DB to 11g or new release then we should have tested it on RAC setup. Am I correct?
    Regards,
    Saikat
  • 5. Re: RAC Upgrade
    Sunny kichloo Expert
    Currently Being Moderated
    Yes test it on RAC Setup

    And if your issue is resolved,you can close this thread as it save time of users looking for open thread
  • 6. Re: RAC Upgrade
    BillyVerreynne Oracle ACE
    Currently Being Moderated
    Saikat Banerjee wrote:

    So, I understood from your reply that 99.99% (thanks you mentioned the exceptions where it may not work) cases the app will work for 10.2.0.5 RAC since its a same release..i.e, 10gR2.
    I have a major PL/SQL application originally written for 10.1.x RAC, that ran without problems on 10.2.x RAC, and is currently running on 11.2.0.1 RAC.

    PL/SQL and SQL code are very unlikely to suddenly fail due a patchset upgrade.
    If we would migrate the DB to 11g or new release then we should have tested it on RAC setup. Am I correct?
    Ideally, yes. But then is the test environment identical to production in order to perform a valid test? Same h/w, same storage, same operating system, same data, same configurations, same everything, except for a newer db version?

    In my experience, this is never the case. Test and development environments never match production - so you cannot say with 100% confidence that the testing the application on development/test platforms mean not a single error or problem on production.

    There is no such thing as a risk free upgrade. Despite what some (especially management types) would like to think and demand.

    The issue is to identify what the risks are. What functionality is used? How complex is this? How well is it instrumented? Etc.

    Once these have been identified, one needs to decide how to mitigate and manage these risks.

    For a standard PL/SQL application (average complexity using common features), I would not be overly concerned to upgrade the database after minimal testing. For a complex PL/SQL application using web services, hooks into JMS via AQ, relies on X/Open distributed transactions using Oracle XA, and so on - this complexity increases the risk and the need for more extensive testing.
  • 7. Re: RAC Upgrade
    user817012 Newbie
    Currently Being Moderated
    You must always try to have a real test.
    If the circumstances are not allowed you to make such tests it's will be a risk. And it depends on you if you can accept this risk or not.
    If you have a small internet shop probably it's ok going to production without testing at all. If your bussiness is 24x7 and the business' losses can be huge it's not appropriated.
    Even you test a new system in similar way it will decrease your risks.
  • 8. Re: RAC Upgrade
    SaikatBanerjee Newbie
    Currently Being Moderated
    Hi,

    Thanks a lot for your answer.


    Since,the nature of application, what kind of features the application is using..it is complex application as you mentioned or only simple pl/sql codes are used is known by the application team...isn't it their(application team's) responsibility to perform the testing??...or the DBA has to take the responsibility of pre-upgrade testing?


    I want to be safe from our(DBA) side since if the application underperforms in production or some of the functionalities do not work..the management can blame DBA team for unsuccessful upgradation. So, what's your suggestion to avoid such blames on DBA team?


    Regards,
    Saikat
  • 9. Re: RAC Upgrade
    BillyVerreynne Oracle ACE
    Currently Being Moderated
    Saikat Banerjee wrote:

    Since,the nature of application, what kind of features the application is using..it is complex application as you mentioned or only simple pl/sql codes are used is known by the application team...isn't it their(application team's) responsibility to perform the testing??...or the DBA has to take the responsibility of pre-upgrade testing?
    Application team is responsible for testing the application on a new version - not the DBA. The DBA is there to assist the application team during this exercise.
    I want to be safe from our(DBA) side since if the application underperforms in production or some of the functionalities do not work..the management can blame DBA team for unsuccessful upgradation. So, what's your suggestion to avoid such blames on DBA team?
    GIGO. Garbage In. Garbage Out.

    You need to convey that principle to management. The DBA and the database do not determine performance and scalability.

    The application and developers do. If the developers do not design the application with performance and scalability as part of the primary goals of that application, the DBA can not make that application go fast and the database can not scale the application. A crappy application will still be just that, even on an Exadata Database Machine.

    If and when there are performance problems, diagnose it, and report it - putting the ball in the developer's court. Make sure that management clearly understand that the problem is with the application and not with the database.
  • 10. Re: RAC Upgrade
    JohnWatson Guru
    Currently Being Moderated
    Billy  Verreynne  wrote:
    You need to convey that principle to management. The DBA and the database do not determine performance and scalability.

    The application and developers do. If the developers do not design the application with performance and scalability as part of the primary goals of that application, the DBA can not make that application go fast and the database can not scale the application. A crappy application will still be just that, even on an Exadata Database Machine.

    If and when there are performance problems, diagnose it, and report it - putting the ball in the developer's court. Make sure that management clearly understand that the problem is with the application and not with the database.
    I have to disagree with this (the first time I have ever disagreed with anyting BV has written!) a not-untypical situation would be that if you take a 100 critical SQLs, after upgrade 90 of them run the same; 9 run better than before; and for 1, performance is disastrous. Why? Because the optimizer, with all the new features in your new release, is changing plans and getting one of them wrong. So you have to identify and test the critical SQLs, and if any have regressed, tune them. Standard upgrade procedure.
    But you might be lucky: there may be no regression.
  • 11. Re: RAC Upgrade
    BillyVerreynne Oracle ACE
    Currently Being Moderated
    John, I agree with your disagreement. :-)

    Simply that IMO this is something that the developers need to manage and test - not the DBA.

    Also, if the application has been properly instrumented, the developers will have a very good idea which of the 100 SQLs are now performing poorly. And will be in a far better position to diagnose the problem, and then (if need be) approach the DBA for assistance. The DBA is not solely responsible for the performance or execution plan of application SQL.

    And while I agree with your description of potential SQL performance issues, keep in mind that the OP referred to a pacthset upgrade - not a major version upgrade. Each upgrade (should) involves a risk assessment - and the scenario you describe is in my experience a higher risk version change than a lower risk patchset change. Significant changes in CBO behaviour in a pacthset upgrade is unlikely.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points