Hello everybody!
We are using Oracle standard edition 10.2.0.2 on Solaris x86-64 platform, and I'm trying to estimate reasonability of movement to 10.2.0.4.
A disadvantage I see is according to 10.2.0.2 "Availability and Known Issues" amount of "issues introduced" is about 10, but in 10.2.0.4 there are 63 "issues introduced", according to similar document. I suspect that some of bugs can be eliminated by applying 10.2.0.4.3 patchset, but I'm not sure that all of them will be eliminated.
A benefit of 10.2.0.4 (and especially 10.2.0.4.3) is presence of all necessary critical patches (up to Jan2010).
Can you provide me any suggestions in this situation? And do you know does the game is worth the candle?
I have recently upgraded all the databases in one of my clients' shop from 10.2.0.3 to 10.2.0.4 because I need to apply DST v13 patch and DST v13 released for 10.2.0.4.
If you have no reason or bugs you don't need to upgrade just to move to the higher version.
Thanks,
Vijay Tummala
Try hard to get what you like OR you will be forced to like what you get.
I have recently upgraded all the databases in one of my clients' shop from 10.2.0.3 to 10.2.0.4 because I need to apply DST v13 patch and DST v13 released for 10.2.0.4.
If you have no reason or bugs you don't need to upgrade just to move to the higher version.
Thanks,
Thank you for your response, vnktummala! In my everyday life I also use a rule - "There is no necessity to repair thing that wasn't broken"
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.
I would like to add that even if you did your testing optimally, there is always the case of hitting "Bugs", that's why it's really recommended to have the latest patchset applied so that you can get a fix from Oracle.
Imagine if you are running on 10.2.0.2 and all of a sudden you hit a bug that was not even discovered uptill 10.2.0.4, what would be easier then?
1. To start testing applying 10.2.0.4 which could take some time if you are going to do some proper testing (with all the downtime involved) and then create a SR with Oracle to investigate the bug and create a fix.
OR
2. Create a SR with Oracle to investigate the bug and create a fix since you are already running the latest patchset.
I would like to add that even if you did your testing optimally, there is always the case of hitting "Bugs", that's why it's really recommended to have the latest patchset applied so that you can get a fix from Oracle.
Imagine if you are running on 10.2.0.2 and all of a sudden you hit a bug that was not even discovered uptill 10.2.0.4, what would be easier then?
1. To start testing applying 10.2.0.4 which could take some time if you are going to do some proper testing (with all the downtime involved) and then create a SR with Oracle to investigate the bug and create a fix.
OR
2. Create a SR with Oracle to investigate the bug and create a fix since you are already running the latest patchset.
Regards,
Hany.
Hi Hany!
Thank you very much for an excellent example of why patchset applying is preferable. A really good example indeed.
I'm really sorry in being the one breaking this news but... that's the definition of bad testing.
yes, but anyone can miss or forget about something during testing - even Oracle Corporation (otherwise why should they produce such huge amount of patches and pathchsets after new release becomes available? )
yes, but anyone can miss or forget about something during testing - even Oracle Corporation (otherwise why should they produce such huge amount of patches and pathchsets after new release becomes available? )
Oh, I totally agree.
Let me share two theories about bugs - these two were coined by a couple of old friends of mine.
Theory #1 --Oracle sells bugs, rdbms software is just the packaging.
Theory #2 --Oracle developers work hard to produce as many bugs as possible so to ensure job security.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.
Reply With Quote
Originally Posted by davey23uk
)
Bookmarks