Saikat Banerjee wrote: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?
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??
Saikat Banerjee wrote: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 18.104.22.168 RAC.
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?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?
Saikat Banerjee wrote: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.
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?GIGO. Garbage In. Garbage Out.
Billy Verreynne wrote: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.
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.