Category Archives: Oracle

乱用_allow_resetlogs_corruption参数导致悲剧

Posted on by

一个朋友11.2.0.1的数据库因为断电,出现不能正常open问题,自己尝试恢复,折腾了几天,最后让我帮忙的时候错误如下

SQL> startup
ORACLE 例程已经启动。

Total System Global Area  778387456 bytes
Fixed Size                  1374808 bytes
Variable Size             545260968 bytes
Database Buffers          226492416 bytes
Redo Buffers                5259264 bytes
数据库装载完毕。
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00604: error occurred at recursive SQL level 1
ORA-01578: ORACLE data block corrupted (file # 1, block # 225)
ORA-01110: data file 1: 'F:\APP\ADMINISTRATOR\ORADATA\YFCLOUD\SYSTEM01.DBF'
进程 ID: 5964
会话 ID: 1144 序列号: 5

从启动的日志提示看初步判断就是悲剧了,因为根据经验值在11gr2版本中,该错误就是undo$(分析trace文件进步一确定是undo$),该block出现异常,数据库在启动的时候要扫描该表，把相关的回滚段给online起来,现在他异常了,数据库肯定无法正常启动
dbv检查数据库文件

F:\>dbv file='F:\APP\ADMINISTRATOR\ORADATA\YFCLOUD\SYSTEM01.DBF'

DBVERIFY: Release 11.2.0.1.0 - Production on 星期三 5月 22 11:06:00 2013

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

DBVERIFY - 开始验证: FILE = F:\APP\ADMINISTRATOR\ORADATA\YFCLOUD\SYSTEM01.DBF
页 225 流入 - 很可能是介质损坏
Corrupt block relative dba: 0x004000e1 (file 1, block 225)
Fractured block found during dbv:
Data in bad block:
 type: 6 format: 2 rdba: 0x004000e1
 last change scn: 0x0000.00d65120 seq: 0x1 flg: 0x06
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0xb98e0601
 check value in block header: 0xb307
 computed block checksum: 0xe8ae



DBVERIFY - 验证完成

检查的页总数: 134400
处理的页总数 (数据): 98226
失败的页总数 (数据): 0
处理的页总数 (索引): 14189
失败的页总数 (索引): 0
处理的页总数 (其他): 4178
处理的总页数 (段)  : 1
失败的总页数 (段)  : 0
空的页总数: 17806
标记为损坏的总页数: 1
流入的页总数: 1
加密的总页数        : 0
最高块 SCN            : 14045769 (0.14045769)

看到这里,可以确定坏块的存在，根据上面的提示,我们发现tailchk值不正确,应该是5120+06+01,而不该是b98e0601,通过bbed查看

BBED> p kcbh
struct kcbh, 20 bytes                       @0
   ub1 type_kcbh                            @0        0x06
   ub1 frmt_kcbh                            @1        0xa2
   ub1 spare1_kcbh                          @2        0x00
   ub1 spare2_kcbh                          @3        0x00
   ub4 rdba_kcbh                            @4        0x004000e1
   ub4 bas_kcbh                             @8        0x00d65120
   ub2 wrp_kcbh                             @12       0x0000
   ub1 seq_kcbh                             @14       0x01
   ub1 flg_kcbh                             @15       0x06 (KCBHFDLC, KCBHFCKV)
   ub2 chkval_kcbh                          @16       0x5ba9
   ub2 spare3_kcbh                          @18       0x0000

BBED> p tailchk
ub4 tailchk                                 @8188     0xb98e0601

进一步证明是tailchk异常导致,分析alert日志,数据库异常断电,然后启动的时候发现如下错误

Recovery of Online Redo Log: Thread 1 Group 2 Seq 431 Reading mem 0
  Mem# 0: F:\APP\ADMINISTRATOR\ORADATA\YFCLOUD\REDO02.LOG
RECOVERY OF THREAD 1 STUCK AT BLOCK 451 OF FILE 3
Aborting crash recovery due to error 1172
Errors in file f:\app\administrator\diag\rdbms\yfcloud\yfcloud\trace\yfcloud_ora_772.trc:
ORA-01172: 线程 1 的恢复停止在块 451 (在文件 3 中)
ORA-01151: 如果需要, 请使用介质恢复以恢复块和还原备份
Errors in file f:\app\administrator\diag\rdbms\yfcloud\yfcloud\trace\yfcloud_ora_772.trc:
ORA-01172: 线程 1 的恢复停止在块 451 (在文件 3 中)
ORA-01151: 如果需要, 请使用介质恢复以恢复块和还原备份
ORA-1172 signalled during: alter database open...
Tue May 21 14:27:29 2013
ALTER DATABASE RECOVER  datafile 3  
Media Recovery Start
Serial Media Recovery started
Recovery of Online Redo Log: Thread 1 Group 2 Seq 431 Reading mem 0
  Mem# 0: F:\APP\ADMINISTRATOR\ORADATA\YFCLOUD\REDO02.LOG
Errors in file f:\app\administrator\diag\rdbms\yfcloud\yfcloud\trace\yfcloud_ora_772.trc  (incident=112164):
ORA-00600: 内部错误代码, 参数: [3020], [3], [451], [12583363], [], [], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 3, block# 451, file offset is 3694592 bytes)
ORA-10564: tablespace UNDOTBS1
ORA-01110: 数据文件 3: 'F:\APP\ADMINISTRATOR\ORADATA\YFCLOUD\UNDOTBS01.DBF'
ORA-10560: block type 'KTU UNDO BLOCK'
Media Recovery failed with error 600
ORA-283 signalled during: ALTER DATABASE RECOVER  datafile 3  ...

因为file# 3, block# 451和redo信息不一致,出现ora-600[3020]错误,而file# 3为undo文件,朋友从而设置undo_management=’manual’并设置了_allow_resetlogs_corruption=true,然后进行不完全恢复,从而出现了如下错误提示

Tue May 21 14:41:23 2013
SMON: enabling cache recovery
Corrupt block relative dba: 0x004000e1 (file 1, block 225)
Fractured block found during buffer read
Data in bad block:
 type: 6 format: 2 rdba: 0x004000e1
 last change scn: 0x0000.00d65120 seq: 0x1 flg: 0x06
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0xb98e0601
 check value in block header: 0xb307
 computed block checksum: 0xe8ae
Reading datafile 'F:\APP\ADMINISTRATOR\ORADATA\YFCLOUD\SYSTEM01.DBF'
for corruption at rdba: 0x004000e1 (file 1, block 225)
Reread (file 1, block 225) found same corrupt data
Errors in file f:\app\administrator\diag\rdbms\yfcloud\yfcloud\trace\yfcloud_ora_4892.trc  (incident=120165):
ORA-01578: ORACLE 数据块损坏 (文件号 1, 块号 225)
ORA-01110: 数据文件 1: 'F:\APP\ADMINISTRATOR\ORADATA\YFCLOUD\SYSTEM01.DBF'
Errors in file f:\app\administrator\diag\rdbms\yfcloud\yfcloud\trace\yfcloud_ora_4892.trc:
ORA-00604: 递归 SQL 级别 1 出现错误
ORA-01578: ORACLE 数据块损坏 (文件号 1, 块号 225)
ORA-01110: 数据文件 1: 'F:\APP\ADMINISTRATOR\ORADATA\YFCLOUD\SYSTEM01.DBF'
Errors in file f:\app\administrator\diag\rdbms\yfcloud\yfcloud\trace\yfcloud_ora_4892.trc:
ORA-00604: 递归 SQL 级别 1 出现错误
ORA-01578: ORACLE 数据块损坏 (文件号 1, 块号 225)
ORA-01110: 数据文件 1: 'F:\APP\ADMINISTRATOR\ORADATA\YFCLOUD\SYSTEM01.DBF'
Error 604 happened during db open, shutting down database
USER (ospid: 4892): terminating the instance due to error 604

从而的原因基本上可以从操作过程中了解到:数据库是因为file# 3 block# 451和redo不一致导致问题,而恢复的操作人员冲动的使用了_allow_resetlogs_corruption参数,从而使得数据库出现了不一致性,也就是导致file# 1 block# 225坏块的根本原因,针对这样的情况,完全没有到使用_allow_resetlogs_corruption隐含参数地步

使用bbed修改tailchk

BBED> p tailchk
ub4 tailchk                                 @8188     0xb98e0601

BBED> verify
DBVERIFY - Verification starting
FILE = system01.dbf
BLOCK = 225

Block 225 is corrupt
***
Corrupt block relative dba: 0x004000e1 (file 0, block 225)
Fractured block found during verification
Data in bad block -
 type: 6 format: 2 rdba: 0x004000e1
 last change scn: 0x0000.00d65120 seq: 0x1 flg: 0x06
 consistency value in tail: 0xb98e0601
 check value in block header: 0x5ba9, computed block checksum: 0x0
 spare1: 0x0, spare2: 0x0, spare3: 0x0
***


DBVERIFY - Verification complete

Total Blocks Examined         : 1
Total Blocks Processed (Data) : 0
Total Blocks Failing   (Data) : 0
Total Blocks Processed (Index): 0
Total Blocks Failing   (Index): 0
Total Blocks Empty            : 0
Total Blocks Marked Corrupt   : 1
Total Blocks Influx           : 2

BBED> m /x 01062051
 File: system01.dbf (0)
 Block: 226              Offsets: 8188 to 8191           Dba:0x00000000
------------------------------------------------------------------------
 01062051

 <32 bytes per line>

BBED> p tailchk
ub4 tailchk                                 @8188     0x51200601

BBED> sum apply
Check value for File 0, Block 226:
current = 0xb307, required = 0xb307

BBED> verify
DBVERIFY - Verification starting
FILE = system01.dbf
BLOCK = 225


DBVERIFY - Verification complete

Total Blocks Examined         : 1
Total Blocks Processed (Data) : 1
Total Blocks Failing   (Data) : 0
Total Blocks Processed (Index): 0
Total Blocks Failing   (Index): 0
Total Blocks Empty            : 0
Total Blocks Marked Corrupt   : 0
Total Blocks Influx           : 0

bbed修改block之后,数据库直接正常打开,完成数据库恢复任务,在这里很明显是因为错误的使用了_allow_resetlogs_corruption参数,屏蔽了redo前滚导致了相关的坏块,所以大家在数据库异常恢复的时候,需要知道各个参数的意义,而不要乱使用,很可能导致不可控结果

ksuapc : ORA-1033 foreground process starts before PMON

Posted on by

在11.2.0.1数据库中启动出现ksuapc : ORA-1033 foreground process starts before PMON错误

Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Using LOG_ARCHIVE_DEST_1 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on. 
IMODE=BR
ILAT =27
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
Using parameter settings in server-side spfile /opt/oracle/product/11.2.0/dbhome_1/dbs/spfileora11bak.ora
System parameters with non-default values:
  processes                = 150
  nls_language             = "SIMPLIFIED CHINESE"
  nls_territory            = "CHINA"
  sga_target               = 1536M
  control_files            = "/opt/oracle/oradata/ora11bak/control01.ctl"
  control_files            = "/opt/oracle/flash_recovery_area/ora11bak/control02.ctl"
  db_block_size            = 8192
  compatible               = "11.2.0.0.0"
  db_recovery_file_dest    = "/opt/oracle/flash_recovery_area"
  db_recovery_file_dest_size= 3882M
  undo_tablespace          = "UNDOTBS1"
  remote_login_passwordfile= "EXCLUSIVE"
  db_domain                = ""
  dispatchers              = "(PROTOCOL=TCP) (SERVICE=ora11bakXDB)"
  audit_file_dest          = "/opt/oracle/admin/ora11bak/adump"
  audit_trail              = "DB"
  db_name                  = "ora11bak"
  open_cursors             = 300
  pga_aggregate_target     = 1595M
  diagnostic_dest          = "/opt/oracle"
Fri May 17 05:03:15 2013
ksuapc : ORA-1033 foreground process starts before PMON
Fri May 17 05:03:15 2013
ksuapc : ORA-1033 foreground process starts before PMON
Fri May 17 05:03:16 2013
ksuapc : ORA-1033 foreground process starts before PMON
Fri May 17 05:03:16 2013
ksuapc : ORA-1033 foreground process starts before PMON
Fri May 17 05:03:16 2013
ksuapc : ORA-1033 foreground process starts before PMON
Fri May 17 05:03:16 2013
ksuapc : ORA-1033 foreground process starts before PMON
…………

该错误的原因是数据库在启动过程中有前台进程连接数据库导致,该现象是数据库bug 8991997,该bug影响版本为:11.2.0.1/11.1.0.7,在11.2.0.1.1开始修复

一次侥幸的OSD-04016 O/S-Error异常恢复

Posted on by

一台数据库因为异常断电导致硬盘IO出现O/S-Error: (OS 23) 数据错误(循环冗余检查)错误，使得datafile 6无法完成实例恢复.使用dbv检查该数据文件也出现类似错误,尝试copy该文件,也出现了类似的错误.尝试dd拷贝完整,发现dd也只能拷贝81951个block.

Tue May 14 15:32:10 2013
Completed redo scan
 16941 redo blocks read, 1106 data blocks need recovery
Tue May 14 15:32:17 2013
Errors in file d:\oracle\product\10.2.0\admin\water\bdump\water_p002_1472.trc:
ORA-01115: IO error reading block from file 6 (block # 81951)
ORA-01110: data file 6: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\WATER\YD_DATA01.DBF'
ORA-27070: async read/write failed
OSD-04016: 异步 I/O 请求排队时出错。
O/S-Error: (OS 23) 数据错误(循环冗余检查)。

因为该数据库有一天前的备份,而且他们只要求恢复其中三张核心表的数据,通过分析数据字典,确定出来相关表的block均不在block 81951之上,也就是说,如果数据库只是该block异常了,可以通过跳过该block,从而copy相关block,来实现数据库恢复,因为是一个文件的中间部分异常了,所以决定使用dd来copy文件正常部分

dd if=D:\ORACLE\PRODUCT\10.2.0\ORADATA\WATER\YD_DATA01.DBF bs=8192 count=81951 of=h:\dd\yd_data01_1.dbf
dd if=D:\ORACLE\PRODUCT\10.2.0\ORADATA\WATER\YD_DATA01.DBF bs=8192  skip=81952   of=h:\dd\yd_data01_2.dbf

dd出来文件之后,因为我们跳过了block 81952(block 0 数据库为记录),所以我们需要通过dd来构造block 81952,并且把他们合并到一起

dd if=/dev/zero of=h:\dd\yd_data01_1.dbf seek=81951 bs=8192 count=1
dd if=h:\dd\yd_data01_2.dbf seek=81952 bs=8192 of=h:\dd\yd_data01_1.dbf

然后使用dul工具抽出来客户需要的三张核心表的数据,恢复工作算完成。
针对本次恢复,如果需求是open数据库,通过设置隐含参数,bbed之类原则上也可以实现.
这次的恢复算是比较侥幸:1.客户有一天前的exp,只需要恢复三张核心表数据;2.三张表的数据恰好都不在损坏的block中;3.数据库就损坏了一个block.
如果出现不幸情况,那可能需要先硬盘恢复,然后数据库恢复,最后折腾数据.
总之再次提醒各位:数据库备份很重要,很重要.对于需求是不能丢失数据的系统备份,一定要rman的方式备份,千万别选择exp/expdp

关于ORACLE 11G密码大小写敏感猜想(USER$.SPARE4)

Posted on by

从11.1开始密码大小写敏感了，同时可以设置sec_case_sensitive_logon参数可以忽略大小写敏感。
通过朋友咨询的不设置sec_case_sensitive_logon参数让密码大小写不敏感的实验这篇文章疑惑,同时也感谢朋友让我学习到了新知识,我通过测试证明了如下结论：
1.password_versions的优先级大于sec_case_sensitive_logon
2.通过修改USER$.SPARE4为空实现了屏蔽ORACLE 11g密码大小写敏感

10g创建用户导出数据

SQL> create user ora10g identified by xifenfei;

User created.

SQL> grant connect to ora10g;

Grant succeeded.


C:\Documents and Settings\Administrator>expdp \"/ as sysdba \" DIRECTORY=exp_dp
DUMPFILE=chf.dmp schemas=ora10g

Export: Release 10.2.0.1.0 - Production on 星期三, 15 5月, 2013 22:59:45

Copyright (c) 2003, 2005, Oracle.  All rights reserved.

连接到: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
启动 "SYS"."SYS_EXPORT_SCHEMA_01":  "/******** AS SYSDBA" DIRECTORY=exp_dp DUMPF
ILE=chf.dmp schemas=ora10g
正在使用 BLOCKS 方法进行估计...
处理对象类型 SCHEMA_EXPORT/TABLE/TABLE_DATA
使用 BLOCKS 方法的总估计: 0 KB
处理对象类型 SCHEMA_EXPORT/USER
处理对象类型 SCHEMA_EXPORT/ROLE_GRANT
处理对象类型 SCHEMA_EXPORT/DEFAULT_ROLE
处理对象类型 SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
已成功加载/卸载了主表 "SYS"."SYS_EXPORT_SCHEMA_01"
******************************************************************************
SYS.SYS_EXPORT_SCHEMA_01 的转储文件集为:
  C:\CHF.DMP
作业 "SYS"."SYS_EXPORT_SCHEMA_01" 已于 23:00:19 成功完成

11g创建用户


SQL> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE    11.2.0.3.0      Production
TNS for Linux: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production

SQL> show parameter logon

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
sec_case_sensitive_logon             boolean     TRUE
SQL> create user ora11g identified by xifenfei;

User created.

SQL> grant connect to ora11g;

Grant succeeded.

SQL> conn ora11g/xifenfei
Connected.
SQL> conn ora11g/XIFENFEI
ERROR:
ORA-01017: invalid username/password; logon denied


Warning: You are no longer connected to ORACLE.

这里证明,在sec_case_sensitive_logon=true的情况下,数据库密码是大小写敏感

导入10g创建用户dmp文件

[oracle@localhost ~]$ impdp '"/ as sysdba"' directory=exp_dp dumpfile=CHF.DMP 

Import: Release 11.2.0.3.0 - Production on Wed May 15 23:07:20 2013

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Master table "SYS"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "SYS"."SYS_IMPORT_FULL_01":  "/******** AS SYSDBA" directory=exp_dp dumpfile=CHF.DMP 
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/ROLE_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Job "SYS"."SYS_IMPORT_FULL_01" successfully completed at 23:07:21

查询ora10g和ora11g用户区别

SQL> conn ora10g/xifenfei
Connected.
SQL> conn ora10g/XIFENFEI
Connected.
SQL> conn / as sysdba
Connected.
SQL>  select t.username,t.account_status,t.password_versions from dba_users t where t.username in ('ORA11G','ORA10G');

USERNAME                       ACCOUNT_STATUS                   PASSWORD
------------------------------ -------------------------------- --------
ORA11G                         OPEN                             10G 11G
ORA10G                         OPEN                             10G

SQL> select name,password,spare4 from SYS.USER$ t where name in ('ORA11G','ORA10G');

NAME                           PASSWORD                       SPARE4
------------------------------ ------------------------------ ----------------------------------------------------------------
ORA10G                         F3CF2F0CB35CB6CA
ORA11G                         559D84354181EB8E               S:BFE2625310D9382E9AEA6EE0AA2988E82C17B3EA23E3DAC23800490C2621

这里可以发现我们从低版本(10g)导入到11g中的用户登录是不区分大小写,而11g本身创建的用户是区分大小写,而他们的区别仅仅是在dba_users.password_versions中有不一样,跟踪到基表发现就是USER$.SPARE4列不一样(10g的该列为空).
猜想:password_versions的优先级大于sec_case_sensitive_logon这个参数

验证猜想
如果是password_versions的优先级大于sec_case_sensitive_logon那么，如果我修改了USER$.SPARE4,使得dba_users.password_versions变成和10g导入的库一样,是否就可以实现不区分密码大小写的问题,如果不缺乏证明：password_versions的优先级大于sec_case_sensitive_logon这个参数,反之失败.

SQL> update SYS.USER$ t set SPARE4='' where name='ORA11G';

1 row updated.

SQL> COMMIT;

Commit complete.


SQL> alter system flush shared_pool;

System altered.

SQL> conn ora11g/XIFENFEI
Connected.
SQL> conn ora11g/xifenfei
Connected.

由此得出两个结论:
1.password_versions的优先级大于sec_case_sensitive_logon
2.通过修改USER$.SPARE4为空实现了屏蔽ORACLE 11g密码大小写敏感

windows Patch list

Posted on by

32-Bit Patches :

Patch

 Patch Location Bug Fix List Notes
11.2.0.3.0 Patch 20 Target date End May 2013
11.2.0.3.0 Patch 19 Bug:16656150 Patch:16656150 Note:1114533.1 Requires 11.2.0.3.0
11.2.0.3.0 Bug:10404530 Patch:10404530 ReadMe
11.2.0.2.0 Patch 26 Target date End May 2013
11.2.0.2.0 Patch 25 Bug:16345845 Patch:16345845 Note:1114533.1 Requires 11.2.0.2.0
11.2.0.2.0 Bug:10098816 Patch:10098816 ReadMe
11.2.0.1.0 Patch 15 Bug:13329696 Patch:13329696 Note:1114533.1 Requires 11.2.0.1.0
11.1.0.7.0 Patch 53 Target date Mid July 2013
11.1.0.7.0 Patch 52 Bug:16345861 Patch:16345861 Note:560295.1

Requires 11.1.0.7.0
11.1.0.7.0 Bug:6890831 Patch:6890831 ReadMe
11.1.0.6.0 Patch 18 Bug:8970709 Patch:8970709 Note:560295.1

Requires 11.1.0.6.0
10.2.0.5.0 Patch 22 Target date Mid July 2013
10.2.0.5.0 Patch 21 Bug:16345855 Patch:16345855 Note:342443.1 Requires 10.2.0.5.0
10.2.0.5.0 Bug:8202632 Patch:8202632 ReadMe
10.2.0.4.0 Patch 50 Bug:15834695 Patch:15834695 Note:342443.1

Requires 10.2.0.4.0
10.2.0.4.0 Patch 49 Bug:13928775 Patch:13928775 Note:342443.1

Requires 10.2.0.4.0
10.2.0.4.0 Bug:6810189 Patch:6810189 ReadMe
10.2.0.3.0 Patch 31 Bug:8288852 Patch:8288852 Note:342443.1

Requires 10.2.0.3.0
10.2.0.3.0 Bug:5337014 Patch:5337014 ReadMe
10.2.0.2.0 Patch 18 Bug:7213940 Patch:7213940 Note:342443.1

Requires 10.2.0.2.0
10.2.0.2.0 Bug:4547817 Patch:4547817 ReadMe
10.2.0.1.0 Patch 9 Bug:5695784 Patch:5695784 Note:342443.1
10.1.0.5.0 Patch 45 Not planned

Requires 10.1.0.5.0 Standalone Database Home
10.1.0.5.0 Patch 44 Bug:13413002 Patch:13413002 Note:276548.1

Applicable to Standalone Database Oracle Homes.
These fixes are consumed by later OracleAS Critical Patches, seeNote:1159443.1 for further information.
10.1.0.5.0 Bug:4505133 Patch:4505133 ReadMe
9.2.0.8.0 Patch 32 Not planned
9.2.0.8.0 Patch 31 Bug:14666190 Patch:14666190 Note:211268.1

Requires 9.2.0.8.0
9.2.0.8.0 CFS RAC Bug:5388107 Patch:5388107

Cluster File System / RAC Clusterware bundle
9.2.0.8.0 Bug:4547809 Patch:4547809 ReadMe

 

64-Bit x64 Patches :

Patch

 Patch Location Bug Fix List Notes
11.2.0.3.0 Patch 20 Target date End May 2013
11.2.0.3.0 Patch 19 Bug:16656151 Patch:16656151 Note:1114533.1 Requires 11.2.0.3.0
11.2.0.3.0 Bug:10404530 Patch:10404530 ReadMe
11.2.0.2.0 Patch 26 Target date End May 2013
11.2.0.2.0 Patch 25 Bug:16345846 Patch:16345846 Note:1114533.1 Requires 11.2.0.2.0
11.2.0.2.0 Bug:10098816 Patch:10098816 ReadMe
11.2.0.1.0 Patch 16 Bug:13423278 Patch:13423278 Note:1114533.1 Requires 11.2.0.1.0. Patch 16 is only available on x64 Windows due a build issue.
11.1.0.7.0 Patch 53 Target date Mid July 2013
11.1.0.7.0 Patch 52 Bug:16345862 Patch:16345862 Note:560295.1

Requires 11.1.0.7.0
11.1.0.7.0 Bug:6890831 Patch:6890831 ReadMe
11.1.0.6.0 Patch 18 Bug:8970710 Patch:8970710 Note:560295.1

Requires 11.1.0.6.0
10.2.0.5.0 Patch 22 Target date Mid July 2013
10.2.0.5.0 Patch 21 Bug:16345857 Patch:16345857 Note:342443.1 Requires 10.2.0.5.0
10.2.0.5.0 Bug:8202632 Patch:8202632 ReadMe
10.2.0.4.0 Patch 49 Bug:13928776 Patch:13928776 Note:342443.1

Requires 10.2.0.4.0
10.2.0.4.0 Bug:6810189 Patch:6810189 ReadMe
10.2.0.3.0 Patch 31 Bug:8288854 Patch:8288854 Note:342443.1

Requires 10.2.0.3.0
10.2.0.3.0 Bug:5337014 Patch:5337014 ReadMe
10.2.0.2.0 Patch 18 Bug:7213942 Patch:7213942 Note:342443.1

Requires 10.2.0.2.0
10.2.0.2.0 Bug:4547817 Patch:4547817 ReadMe
10.2.0.1.0 Patch 9 Bug:5695786 Patch:5695786 Note:342443.1

 

64-Bit Itanium Patches :

Patch

 Patch Location Bug Fix List Notes
10.2.0.5.0 Patch 22 Target date Mid July 2013
10.2.0.5.0 Patch 21 Bug:16345856 Patch:16345856 Note:342443.1 Requires 10.2.0.5.0
10.2.0.5.0 Bug:8202632 Patch:8202632 ReadMe
10.2.0.4.0 Patch 47 Bug:12914909 Patch:12914909 Note:342443.1

Requires 10.2.0.4.0
10.2.0.4.0 Bug:6810189 Patch:6810189 ReadMe
10.2.0.3.0 Patch 32 Bug:8504486 Patch:8504486 Note:342443.1

Requires 10.2.0.3.0
10.2.0.3.0 Bug:5337014 Patch:5337014 ReadMe
10.2.0.2.0 Patch 18 Bug:7213941 Patch:7213941 Note:342443.1

Requires 10.2.0.2.0
10.2.0.2.0 Bug:4547817 Patch:4547817 ReadMe
10.2.0.1.0 Patch 9 Bug:5695785 Patch:5695785 Note:342443.1
10.1.0.5.0 Patch 45 Not planned
10.1.0.5.0 Patch 44 Bug:13413003 Patch:13413003 Note:276548.1

Applicable to Standalone Database Oracle Homes.
These fixes are consumed by later OracleAS Critical Patches, seeNote:1159443.1 for further information.
10.1.0.5.0 Bug:4505133 Patch:4505133 ReadMe
9.2.0.8.0 Patch 31 Not planned
9.2.0.8.0 Patch 30 Bug:9683645 Patch:9683645 Note:211268.1

Requires 9.2.0.8
9.2.0.8.0 CFS RAC Bug:5689499 Patch:5689499
9.2.0.8.0 Bug:4547809 Patch:4547809 ReadMe