Skip to content

Oracle 数据库补丁发布时间表

当前数据库发布时间表

除非特别声明这里都是服务器版本。服务器版本总是包含一个原生相同字长的客户端(比如 64 位)。如果平台支持,那么它还会包含一个 32 位或 64 位的客户端。

点击标题上的版本号即可跳转到补丁集下载页面。

 

Platform 12.1.0.2 12.1.0.12 11.2.0.410 11.2.0.3 11.2.0.2 11.2.0.12 11.1.0.71 10.2.0.53 10.2.0.44 10.1.0.5
Linux x86 无计划 无计划 2013年8月28日 2011年9月23日 2010年9月13日 2009年9月1日 2008年9月18日 2010年4月30日 2008年2月22日 2006年1月30日
Linux x86-64 2014年2季度 2013年6月25日 2013年8月27日 2011年9月23日 2010年9月13日 2009年9月1日 2008年9月18日 2010年4月30日 2008年3月17日 2006年2月24日
Oracle Solaris SPARC (64-bit) 2014年2季度 2013年6月25日 2013年8月29日 2011年10月1日 2010年9月24日 2009年11月6日 2008年10月6日 2010年5月19日 2008年4月30日 2006年2月5日
Oracle Solaris x86-64 (64-bit) 2014年2季度 2013年6月25日 2013年8月29日 2011年10月1日 2010年9月24日 2009年11月25日 无计划 2010年5月19日 2008年11月13日 无计划
Microsoft Windows x64 (64-bit) 2014年2季度 2013年7月9日 2013年10月25日 2011年11月11日 2010年12月15日 2010年4月2日 2008年11月13日 2013年7月27日 2008年5月16日 无计划
HP-UX Itanium9 2014年2季度 2014年1月9日 2013年10月10日 2011年10月29日 2010年10月19日 2009年12月22日 2008年10月6日 2010年6月3日 2008年4月30日 2006年6月7日
HP-UX PA-RISC (64-bit)
See footnote 8 below
平台不再支持 8 平台不再支持 8 2014年1月2日 2012年2月16日 2011年3月15日 2010年5月20日 2008年11月11日 2010年12月15日 2008年6月2日 2006年2月5日
IBM AIX on POWER Systems 2014年2季度 2014年1月9日 2013年10月10日 2011年10月29日 2010年10月19日 2009年12月12日 2008年10月6日 2010年6月3日 2008年5月15日 2006年2月5日
IBM Linux on System z 2014年2季度 2014年1月9日 2014年1月9日 2011年12月1日 2011年3月30日 无计划 无计划 2011年1月3日 2008年12月16日 2006年8月26日
Microsoft Windows (32-bit) 无计划 无计划 2013年10月25日 2011年11月11日 2010年12月15日 2010年4月5日 2008年10月10日 2010年7月19日 2008年3月17日 2006年2月13日
Instant Client Releases
Apple Mac OS X (Intel)  已计划  无计划 2014年4月20日
只提供 Instant Client下载>
2013年1月31日
只提供 Instant Client
无计划 无计划 无计划 日期未定 2010年4月10日
只提供 Single Instance
无计划
IBM Linux on POWER 已计划
Older Releases

Apple Mac OS X (PowerPC)
平台不再支持
2007年1月8日
HP OpenVMS Alpha
平台不再支持
2012年10月31日 2008年12月15日 2008年2月15日
HP OpenVMS Itanium
平台不再支持 (详见 Doc ID 1307745.1)
2012年10月31日 2008年12月15日 无计划
HP Tru64 UNIX
平台不再支持
2011年4月21日 2008年2月20日 2006年10月18日
IBM Linux on POWER
平台不再支持 (详见 Doc ID 1310584.1)
2011年3月17日 2009年1月9日 无计划
IBM z/OS on System z
平台不再支持 (详见 Doc ID 461234.1)
2012年10月26日 无计划 2006年3月6日
Linux Itanium9
平台不再支持(详见 Doc ID 1130325.1)
2011年3月17日 2008年9月24日 2006年4月30日
Microsoft Windows Itanium (64-bit) 9
平台不再支持 (详见 Doc ID 1307745.1)
2011年5月12日 2009年2月2日 2006年1月30日
Oracle Solaris x86 (32-bit)
平台不再支持
2008年11月14日
这个平台的最终版
2006年6月18日
Platform 12.1.0.12 11.2.0.410 11.2.0.3 11.2.0.2 11.2.0.12 11.1.0.71 10.2.0.53 10.2.0.44 10.1.0.5

Legend:

Sched TBA = 日期未定

DD-MMM-YYYY: 在 My Oracle Support/MetaLink 上显示的补丁集可以下载的日期。

1H or 2H CYyyyy: 日历年上半年(6个月)或下半年中的某个日期。比如 1H CY2009 的意思是日历年2009上半年的某个时间。

Qn CYyyyy: 日历年第 n 个季度(3个月)中的某个日期. 比如 Q2 CY 2009 的意思是日历年2009年第2季度,也就是4月到6月间的某个时间。

Unsupported platform – 以后不会再对这个平台发布新的数据库版本。

Patching for previous release ends: 看下面的解释.

生活以及Oracle

总的来讲,我不善于写这种技术和生活交涉的文字。
工作这些年,以技术融入社会,在oracle 数据库这条路越走越远,经常会迷惑自己会想要什么?经常有人在身边说某某在某行发了,在最初的几年确实是怦然心动。技术在最初的几年是无法很明显的改善生活的,这个我已经深有体会,我也想过做其它方面的事情,但是并没有鼓足勇气去放弃自己喜欢的工作。
从实际上讲我并不是一个好工程师,因为我不喜欢钻牛角尖,我喜欢一种感觉,推动以及完成一个项目的成就感,把技术实际的应用施展开来,这种感觉很棒!你会发现没有什么能比把自己的专业知识给予用户解决方案解客户燃眉之急的那种感觉,这可能正是你在这个行业苦苦追寻的,当然我现在发现这是我在追求的。今年早些时候老姚和我聊到这个话题,他的定义就是类销售方向,我的理解就是技术型专家走上了工程师与销售的角色混合之路。

我很想把我的所学每天按部就班整理出来放到blog,人的精力是有限的可是。
我很想把事情做好,却没有足够做完美一件事情的时间,最近理解得很深刻,做事的人不是简单的4个字。且行且稳,路还要远,就想勒夫当年还是一个德乙的球员,如今却是德国国家队教练一样,任重道远,看得远那是应该的,做好眼前事一步步走出踏实的印子那更是必须的。

Fatal NI connect error 12170.

11g中的12170事件.
其实遭遇这个错误不是第一回,我因为应用在半夜的批处理数据交互中出现某个环节进程连接丢失的情况在复查日志时候发现这个错误,因为是半夜2点,当时备份在执行,而且监听日志已经1g了,所以进程估计在io和cpu压力下响应时间超过了阀值就断开了,这个时候也报了12170.具体的12170解释参考了下官方的说法,下面描述一翻:

报错信息如下:

VERSION INFORMATION:
TNS for Linux: Version 11.2.0.1.0 - Production
Oracle Bequeath NT Protocol Adapter for Linux: Version 11.2.0.1.0 - Production
TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.1.0 - Production
Time: 11-MAY-2011 22:23:40
Tracing not turned on.
Tns error struct:
Tns main err code: 12535

TNS-12535: TNS:operation timed out
ns secondary err code: 12560
nt main err code: 505

TNS-00505: Operation timed out
nt secondary err code: 110
nt OS err code: 0
Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.131.29.167)(PORT=1827))

官方解释以及处理办法如下:

1.version
Oracle Net Services - Version: 11.1.0.6 to 11.2.0.2 - Release: 11.1 to 11.2
Oracle Server - Enterprise Edition - Version: 11.1.0.6 to 11.2.0.2   [Release: 11.1 to 11.2]
Information in this document applies to any platform.

2.cause
These time out related messages are mostly informational in nature.  The messages indicate the specified client connection (identified by the 'Client address:' details) has experienced a time out.  The 'nt secondary err code' identifies the underlying network transport, such as (TCP/IP) timeout limits after a client has abnormally terminated the database connection.
 The 'nt secondary err code' translates to underlying network transport timeouts for the following Operating Systems:
 For the Solaris system: nt secondary err code: 145:

 #define ETIMEDOUT 145 /* Connection timed out */

 For the Linux operating system: nt secondary err code: 110
ETIMEDOUT 110 Connection timed out

For the HP-UX system: nt secondary err code: 238:

ETIMEDOUT 238 /* Connection timed out */

For Windows based platforms: nt secondary err code: 60 (which translates to Winsock Error: 10060)
Description:  A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

The reason the messages are written to the alert log is related to the use of the new 11g Automatic Diagnostic Repository (ADR) feature being enabled by default.

3、Solution
To revert to Oracle Net Server tracing/logging, set following parameter in the server's sqlnet.ora :

DIAG_ADR_ENABLED = OFF

Also, to back out the ADR diag for the Listener component, set following parameter in the server's listener.ora:

DIAG_ADR_ENABLED_ = OFF

   - Where the  would be replaced with the actual name of the configured listener(s) in the listener.ora configuration file.  For example, if the listener name is 'LISTENER', the parameter would read:

DIAG_ADR_ENABLED_LISTENER = OFF

-Reload or restart the TNS Listener for the parameter change to take effect.

谈谈adjust_scn的计算方法

遭遇2662错误时候(关于2662的介绍参考我以前写的2262的介绍),经验丰富的dba首先考虑到的就是设置adjust_scn的方式来打开数据库,但是有个问题就是如何计算djust_scn level的合适的值?这方面的资料目前也比较少,关于这个方面的技术内容可以参考MT id:[​3​0​6​8​1​.​1​],但是升级后的OTN没这个文章了…所以这里最后面会贴出这个文章.

一:Adjust_scn算法规则

这个报错参数的含义在metalink中如此描述的:
Arg [a] Current SCN WRAP
Arg [b] Current SCN BASE
Arg dependent SCN WRAP
为了存储更大的SCN值,当SCN BASE到足够大并开始重置的时候,SCN WRAP将加1。

Arg [d] dependent SCN BASE
Arg [e] Where present this is the DBA where the dependent SCN came from.
也就是Arg [d] 的值是从哪个block中找到的,通常是一个datablock address。

通过这几个参数根据一定的规则可以计算出我们需要的level。计算规则如下:
1.Arg *4得出一个数值,假设为V_Wrap
2.如果Arg [d]=0,则V_Wrap值为需要的level
Arg [d] < 1073741824,V_Wrap+1为需要的level Arg [d] < 2147483648,V_Wrap+2为需要的level Arg [d] < 3221225472,V_Wrap+3为需要的level 二.计算案例 举个例子来计算: ORA-00600: internal error code, arguments: [2662], [0], [378942], [7777], [22222222], [111089032], [], [] 在这上面的报错根据算法计算如下: 1.Arg c *4 = 7777 * 4 = 31108 2.Arg [d] = 22222222 < 1073741824 所以这里adjust_scn=31108+1=31109 因此在这个例子中我们应该执行>
alter session set events ‘IMMEDIATE trace name ADJUST_SCN level 31109‘;

三.MOS文档信息

接下来提上相关的mos 文档资料:

DocID: Note:30681.1
Subject: EVENT: ADJUST_SCN - Quick Reference
Type: REFERENCE
Status: PUBLISHED
Content Type:TEXT/PLAIN
CreationDate: 20-OCT-1997
LastRevision Date: 04-AUG-2000
Language: USAENG

ADJUST_SCNEvent
~~~~~~~~~~~~~~~~
***WARNING ***
This event should only ever be used underthe guidance
of an experienced Oracle analyst.
If an SCN is ahead of the current databaseSCN, this indicates
some form of database corruption. Thedatabase should be rebuilt
after bumping the SCN.
****************

The ADJUST_SCN event is useful in somerecovery situations where the
current SCN needs to be incremented by alarge value to ensure it
isahead of the highest SCN in the database. This is typically
required if either:
a. An ORA-600 [2662] error is signalledagainst database blocks
or
b. ORA-1555 errors keep occuring afterforcing the database open
or ORA-604 / ORA-1555 errors occurduring database open.
(Note: If startup reports ORA-704& ORA-1555 errors together
then the ADJUST_SCN eventcannot be used to bump the
SCN as the error is occuringduring bootstrap.
Repeated startup/shutdown attemptsmay help if the SCN
mismatch is small)
or
c. If a database has been forced openused _ALLOW_RESETLOGS_CORRUPTION
(See<Parameter:Allow_Resetlogs_Corruption> )

The ADJUST_SCN event acts as describedbelow.

**NOTE: You can check that the ADJUST_SCNevent has fired as it
should write a message to the alert log inthe form
"Debugging event used to advance scn to %s".
If this message is NOT present in the alert log the event
has probably not fired.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If the database will NOT open:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Take a backup.
You can use event 10015 to trigger anADJUST_SCN on database open:

startup mount;

alter session set events '10015 tracename adjust_scn level 1';

(NB: You can only use IMMEDIATE here onan OPEN database. If the
database is only mounted use the 10015 trigger to adjust SCN,
otherwise you get ORA 600 [2251], [65535], [4294967295] )

alter database open;

If you get an ORA 600:2256 shutdown, usea higher level and reopen.

Do *NOT* set this event in init.ora or theinstance will crash as soon
as SMON or PMON try to do any clean up.Always use it with the
"alter session" command.

~~~~~~~~~~~~~~~~~~~~~~~~~~
If the database *IS* OPEN:
~~~~~~~~~~~~~~~~~~~~~~~~~~
You can increase the SCN thus:

alter session set events 'IMMEDIATEtrace name ADJUST_SCN level 1';

LEVEL:Level 1 is usually sufficient - it raises the SCN to 1 billion
(1024*1024*1024)
Level 2 raises it to 2 billion etc...

If you try to raise the SCN to a level LESS THAN or EQUAL to its
current setting you will get <OERI:2256> - See below.
Ie: The event steps the SCN to known levels. You cannot use
the same level twice.

Calculating a Level from 600 errors:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To get a LEVEL for ADJUST_SCN:

a) Determine the TARGET scn:
ora-600 [2662] See <OERI:2662> Use TARGET >= blocks SCN
ora-600 [2256] See<OERI:2256> Use TARGET >=Current SCN

b)Multiply the TARGET wrap number by 4. This will give you the level
to use in the adjust_scn to get the correct wrap number.
c) Next, add the following value to thelevel to get the desired base
value as well :

Add to Level Base
~~~~~~~~~~~~ ~~~~~~~~~~~~
0 0
1 1073741824
2 2147483648
3 3221225472

-------------------------------------------------------------------------------------------------------
数据库群: 66809572 欢迎从事it行业的朋友加入。2000人超级大群。

关于光纤链路的排障

碰到过不少因为光纤链路的问题导致oracle rac集群故障,所以把一些这方面的排障思路方向汇一下,任何做过这方面排障的工程师都清楚这是一个比较繁冗的过程,因此知道从什么地方入手寻找故障非常重要。这里给出了一些最常见的光纤故障以及产生这些故障的可能因素,这些信息将有助于用户对网络故障进行有根据的猜测。
    
1.光纤断裂通常是由于外力物理挤压或过度弯折;
2.传输功率不足;
3.光纤铺设距离过长可能造成信号丢失;
4.连接器受损可能造成信号丢失;
5.光纤接头和连接器(connectors)故障可能造成信号丢失;
6.使用过多的光纤接头和连接器可能造成信号丢失;
7.光纤配线盘(patch panel)或熔接盘(splice tra)连接处故障。
8.通常而言,如果连接完全不通,那么很可能是光纤断裂。但如果连接时断时续,可能有以下原因:
9.结合处制作水平低劣或结合次数过多造成光纤衰减严重;
10.由于灰尘、指纹、擦伤、湿度等因素损伤了连接器;
11.传输功率过低;
12.在配线间连接器错误。

一般在碰到集群相关心跳出问题时候,在诊断光纤方面,应该尽量了解客户现场的案发时候的情形,比如是否动过光纤线?热拔插过否?有没有更换或者挪动等,也尽量去把每一方面涉及到的处理摸清技术手段搞清楚,以便在排障时候提升效率