Pau Lo
asked on
oracle support lifecycle
do oracle have a similar concept of support lifecycles for all their core RDBMS releases? i.e. 9i, 10g, 11g etc. By support I am specifically interested in patching, i.e. functional or security bugs? Is there anywhere you can see reamining support (in terms of dates) for all major releases?
Also are oracle security patches cumulative, specifically security patches? I.e. if you find an oracle 11g has never been patched since it was installed, is it a case of installing 1 cumulative patchset, or will you likely have to install dozens of security patches?
Also are oracle security patches cumulative, specifically security patches? I.e. if you find an oracle 11g has never been patched since it was installed, is it a case of installing 1 cumulative patchset, or will you likely have to install dozens of security patches?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
does that link essentially say 10g is no longer supported/being patched then? So staying on 10g is a risk in itself?
yup, 10g is no longer supported since last year July.
no more patches available for download
no more patches available for download
>>do patchsets ever include a collection of the one off patches?
That is pretty much what a patchset is.
>>does that link essentially say 10g is no longer supported/being patched then?
Correct.
>>So staying on 10g is a risk in itself?
Depends. Just because you can no longer ask Support questions and bugs are no longer fixed, does that mean it is a 'risk'?
It is all about perspective and risk/reward. You can probably run 10g databases for the next 10 years without a problem in most instances. In some, 10g will fail immediately with some unknown bug/issue.
For 'most' bugs I stumble across I can find a work-around for them since it takes Oracle weeks and sometimes months/years to fix a bug.
I found a bug once in 10g that 'cannot be fixed'. Over the weeks/months working with Support I was told the developer was looking at the line of code that caused it but could not 'fix' it. The bug magically disappeared in the 11g rewrite.
That is pretty much what a patchset is.
>>does that link essentially say 10g is no longer supported/being patched then?
Correct.
>>So staying on 10g is a risk in itself?
Depends. Just because you can no longer ask Support questions and bugs are no longer fixed, does that mean it is a 'risk'?
It is all about perspective and risk/reward. You can probably run 10g databases for the next 10 years without a problem in most instances. In some, 10g will fail immediately with some unknown bug/issue.
For 'most' bugs I stumble across I can find a work-around for them since it takes Oracle weeks and sometimes months/years to fix a bug.
I found a bug once in 10g that 'cannot be fixed'. Over the weeks/months working with Support I was told the developer was looking at the line of code that caused it but could not 'fix' it. The bug magically disappeared in the 11g rewrite.
lol, I found a bug in 11.2.0.3 g
> they only want to fix it in 12c
hesitated 2 seconds to fix it in 11.2.0.4 and then said no to that
> they only want to fix it in 12c
hesitated 2 seconds to fix it in 11.2.0.4 and then said no to that
ASKER
I think the risk in some cases is if a hacker found a vulnerability in 10g, and even if oracle knew about it, they wouldnt release a patch as the software is no longer supported, therefore if that exploit got into the public domain, any would be hacker could then target oracle 10g databases knowing they will be exploitable as a patch has never been published from oracle..
ASKER
are patch sets similar to service packs in ms software?
As a general rule how many patch sets are released per version of oracle rdbms? and how many one off patches are released in between each patch set?
As a general rule how many patch sets are released per version of oracle rdbms? and how many one off patches are released in between each patch set?
>>I think the risk in some cases is if a hacker found a vulnerability in 10g
That's a risk even with current releases: How long between the time the vulnerability is found and the time a patch is released and applied?
To also mitigate that risk: It is likely only vulnerable to inside threats. I hope your database isn't close to your front-end firewalls! So even a known issue should not be easily exploited.
I have this debate with our internal Security folks all the time:
Oracle isn't Windows. You do NOT patch it just because a new patchset or critical patch is released.
See my comment above: One patch can break others...
Oracle is good about introducing new bugs in patches to fix other ones.
Unless you have a pretty extensive test plan, don't patch Oracle just because you 'can'.
I get my security folks to leave me alone about patching when I tell them this:
I will apply any patch you all direct me to apply. However, my work day ends at 4:30PM. If the patch breaks something I will start working to fix it when I get back in at 8:00AM.
In other words: You make my database 'break', I'm not working overtime or 24/7 to fix it...
To date: I patch on my own schedule and ONLY after I have personally tested and approved the patch.
That's a risk even with current releases: How long between the time the vulnerability is found and the time a patch is released and applied?
To also mitigate that risk: It is likely only vulnerable to inside threats. I hope your database isn't close to your front-end firewalls! So even a known issue should not be easily exploited.
I have this debate with our internal Security folks all the time:
Oracle isn't Windows. You do NOT patch it just because a new patchset or critical patch is released.
See my comment above: One patch can break others...
Oracle is good about introducing new bugs in patches to fix other ones.
Unless you have a pretty extensive test plan, don't patch Oracle just because you 'can'.
I get my security folks to leave me alone about patching when I tell them this:
I will apply any patch you all direct me to apply. However, my work day ends at 4:30PM. If the patch breaks something I will start working to fix it when I get back in at 8:00AM.
In other words: You make my database 'break', I'm not working overtime or 24/7 to fix it...
To date: I patch on my own schedule and ONLY after I have personally tested and approved the patch.
hacker ...
first thing is getting in your network layer
that should also be patched
win2003 goes out of support next year ... :)
first thing is getting in your network layer
that should also be patched
win2003 goes out of support next year ... :)
lol > I patch on my own schedule
and when the business grants you some "down" time
and when the business grants you some "down" time
>>are patch sets similar to service packs in ms software?
The 'can' be. At times a patchset is just that, a set of patches. Some times, as mentioned above, it is pretty much a complete software install and database upgrade/migration.
These days, it seems to be more of the latter: Full download, full install.
>>As a general rule how many patch sets are released per version of oracle rdbms?
I think they are trying to go to a quarterly system but don't quote me on that.
They are moving from patchsets whenever and CRITICAL quarterly releases to a 'let's just do it all on a schedule'.
>>and how many one off patches are released in between each patch set?
Really no way to know this. It 'depends'.
The 'can' be. At times a patchset is just that, a set of patches. Some times, as mentioned above, it is pretty much a complete software install and database upgrade/migration.
These days, it seems to be more of the latter: Full download, full install.
>>As a general rule how many patch sets are released per version of oracle rdbms?
I think they are trying to go to a quarterly system but don't quote me on that.
They are moving from patchsets whenever and CRITICAL quarterly releases to a 'let's just do it all on a schedule'.
>>and how many one off patches are released in between each patch set?
Really no way to know this. It 'depends'.
>>and when the business grants you some "down" time
I am luckier than most there! I can schedule it pretty much any time with very minimal notice.
I am luckier than most there! I can schedule it pretty much any time with very minimal notice.
there is an upgrade guide which covers almost all the aspects
here is a link to the contents:
http://docs.oracle.com/cd/E11882_01/server.112/e17222/toc.htm
patching is just a portion of that ... :)
here is a link to the contents:
http://docs.oracle.com/cd/E11882_01/server.112/e17222/toc.htm
patching is just a portion of that ... :)
I am luckier than most there!
> Enjoy that will it lasts ...
my next one: 4 am
so the next team would have plenty of time for testing ... bleh
> Enjoy that will it lasts ...
my next one: 4 am
so the next team would have plenty of time for testing ... bleh
ASKER
>That's a risk even with current releases: How long between the time the vulnerability is found and the time a patch is released and applied?
agree... however, at some point they will release a patch, whereas on 10g they never would..
agree... however, at some point they will release a patch, whereas on 10g they never would..
ASKER
one more to wrap up, is there any way to query a build number? and from their determine if the latest patchsets are missing or not?sometimes there is a specific format used in the build number i.e.
version-sp-patch
other software only release bundles as opposed to one-offs so its much easier to keep tabs on.
version-sp-patch
other software only release bundles as opposed to one-offs so its much easier to keep tabs on.
> whereas on 10g they never would...
money can do something about that, and a lot of convincing
it's usually cheaper to upgrade
money can do something about that, and a lot of convincing
it's usually cheaper to upgrade
as slightwv has already said ... it's not really a must to be on the latest patch release
even in companies following sox
for sox, all parties need to agree to apply the patch
that means that all parties need to be informed when there is a patch first,
understand and agree it's necessary to apply it
> if they don't agree it's necessary to apply, then you're still sox compliant
however odd that may be
even in companies following sox
for sox, all parties need to agree to apply the patch
that means that all parties need to be informed when there is a patch first,
understand and agree it's necessary to apply it
> if they don't agree it's necessary to apply, then you're still sox compliant
however odd that may be
>> and from their determine if the latest patchsets are missing or not?
Only 'major' patches/patchsets change version numbers. To be honest, I have yet to figure out the reasoning. For what is 'supposed' to be a minor release can be a full install.
For patches applited with the OPatch utility the utility will report on what has been applied:
opatch lsinventory
Howver, some minor patches just involve file copies to specific folders. A DLL here, a .??? there... I don't know how you figure out if those have been applied with any type of reporting.
Only 'major' patches/patchsets change version numbers. To be honest, I have yet to figure out the reasoning. For what is 'supposed' to be a minor release can be a full install.
For patches applited with the OPatch utility the utility will report on what has been applied:
opatch lsinventory
Howver, some minor patches just involve file copies to specific folders. A DLL here, a .??? there... I don't know how you figure out if those have been applied with any type of reporting.
ASKER
thanks again
is there anything else "risk wise" associated with not keeping up to date with oracle patches, aside from functionality bugs and security bugs?
is there anything else "risk wise" associated with not keeping up to date with oracle patches, aside from functionality bugs and security bugs?
Is lack of new features and possible better performance a 'risk'?
Remember: A minor number say 11.2.0.1 and 11.2.0.2 (just picked them out of the air) can really be a 'major' release with a LOT of new functionality and have major pieces of code rewritten.
Remember: A minor number say 11.2.0.1 and 11.2.0.2 (just picked them out of the air) can really be a 'major' release with a LOT of new functionality and have major pieces of code rewritten.
ASKER