追根溯源32bit&64bit

在做维护的时候经常要确认oracle是32位还是64位的，如果仅仅要求知道目前的版本是多少位的，直接运行file oracle或者desc x$ksmmem查看KSMMMVAL的type即可，但是如果当前版本是从低版本升级上来的，用上述方法可以知道当前版本的位数，但是却无法得知是由什么版本升级上来的，而在做一些upgrade的时候碰到一些奇怪的bug,就会很被动

前些日子做9208到10.2.0.3的upgrade,碰到一个bug，折腾了许久，也没搞定，还好，目前这个bug终于显现了他的庐山真面目

: ORA-600 [22635] and ORA-600 [KOKEIIX1] Reported While Upgrading Or Patching Databases To 10.2.0.3

Description

This alert covers an issue that occurs while upgrading Oracle8i (8.1.x) , Oracle9i (9.0.x) and Oracle10gR1 (10.1.0.x) databases to Oracle10gR2 Patchset 2 (10.2.0.3). The issue also occurs while patching Oracle10gR2 (10.2.0.1 or 10.2.0.2) databases to Oracle10gR2 Patchset 2 (10.2.0.3). 

If the database was created as a 32-bit database (even though it might currently be 64-bit) and is now being upgraded to 10.2.0.3 64-bit, the following type of errors will be reported during the upgrade or while patching the database:

ALTER TYPE SYS.AnyData REPLACE
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kokeiix1], [600], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [22635], [], [], [], [], [], [], []

ALTER TYPE SYS.AnyDataSet REPLACE
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kokeiix1], [600], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [22635], [], [], [], [], [], [],[]

DECLARE
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [22635], [], [], [], [], [], [], []
ORA-06512: at "SYS.UPGRADE_SYSTEM_TYPES_FROM_920", line 1
ORA-06512: at line 11
ORA-01403: no data found

The same errors can occur when upgrading/patching a database that was created as a 64-bit database to 10.2.0.3 32-bit, but this is less common.

Here are some examples of databases that will be affected by this issue:

• Created as 8.0.6.x 32-bit, upgraded to 8.1.7.x 32-bit, upgraded to 9.2.0.x 32-bit, upgraded to 10.2.0.3 64-bit
• Created as 8.1.7.x 32-bit, upgraded to 9.2.0.x 64-bit, upgraded to 10.2.0.1 64-bit, patched to 10.2.0.3 64-bit
• Created as 8.1.7.x 32-bit, upgraded to 9.2.0.x 32-bit, upgraded to 10.2.0.3 64-bit
• Created as 9.2.0.x 64-bit, upgraded to 10.2.0.x 32-bit, patched to 10.2.0.3 32-bit
• Created as 9.2.0.x 64-bit, upgraded to 10.2.0.3 32-bit

Databases that were created as 32-bit and are being upgraded/patched to 10.2.0.3 32-bit will not be affected.

Similarly, databases that were created as 64-bit and are being upgraded/patched to 10.2.0.3 64-bit will not be affected.

Here are some examples of databases that will not be affected by this issue:

• Created as 8.1.7.x 32-bit, upgraded to 9.2.0.x 64-bit, upgraded to 10.2.0.3 32-bit
• Created as 9.2.0.x 64-bit, upgraded to 10.2.0.1 32-bit, upgraded to 10.2.0.3 64-bit

Likelihood of Occurrence

You will hit this issue if:

• the database was created as 32-bit and is now being upgraded/patched to 10.2.0.3 64-bit
• the database was created as 64-bit and is now being upgraded/patched to 10.2.0.3 32-bit

You will not hit this issue if:

• the database was created as 32-bit and is now being upgraded/patched to 10.2.0.3 32-bit
• the database was created as 64-bit and is now being upgraded/patched to 10.2.0.3 64-bit

To identify whether a database was created as 32-bit or 64-bit, execute the following SQL statement:

SQL> select metadata from sys.kopm$ ;

If the output references the string 'B023' then it indicates that the database was created as 32-bit

If the output references the string 'B047' then it indicates that the database was created as 64-bit

NOTE: The second character is the digit zero, not an upper-case letter 'o'

 

下面我们就来看看我自己的系统

$ cd $ORACLE_HOME/bin

$ file oracle

oracle:         ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped（目前版本是64位）

$ sqlplus "/as sysdba"

 

SQL*Plus: Release 9.2.0.8.0 - Production on Sat Mar 22 11:46:20 2008

 

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.

 

 

Connected to:

Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production

With the Partitioning, OLAP and Oracle Data Mining options

JServer Release 9.2.0.8.0 - Production

 

SQL> desc x$ksmmem;

 Name                                      Null?    Type

 ----------------------------------------- -------- ----------------------------

 ADDR                                               RAW(8)

 INDX                                               NUMBER

 INST_ID                                           NUMBER

 KSMMMVAL                                       RAW(8)（RAW(8)再次证明了是64bit,如果是RAW(4)则为32bit）

下面我们来揭穿他的老底

SQL> select metadata from sys.kopm$ ;

 

METADATA

--------------------------------------------------------------------------------

0000006001240F050B0C030C0C0504050D0609070805050505050F05050505050A05050505050405

0607080823472323081123081141B0230083035407D0130000000000000000000000000000000000

0000000000000000000000000000000000000000

 

SQL>

果然是B023，证明他的前身是32bit,而非64bit

询问客户得知他开始安装的是32bit的9206，后来升级到64bit的9208，于是在升级到64bit 10203的时候出现了这个bug

还好，目前oracle已经给出了这个bug的patch

下面我们来看看这个bug的解决方案

Development have released and for 10.2.0.3 on the following platforms:

• Solaris Operating System (SPARC 64-bit)
• AIX5L Based Systems (64-bit)
• Linux x86-64 (AMD64/EM64T)
• Linux Itanium (IA64)
• HP-UX PA-RISC (64-bit)
• HP-UX Itanium (IA64) 

For the Microsoft Windows 2003 (AMD64/EM64T) platform, the fix is available in 10.2.0.3 patch 5 () or higher.

For the Microsoft Windows 2003 Itanium platform, the fix is available in 10.2.0.3 patch 5 () or higher.

These patches are included in the 10.2.0.4 patchset, which is now available on some platforms.

 

Remen
2008.3.22