Oracle 11gR2 for Linux正式发布
呵呵，一大早的很多人已经在谈论这个话题了，Oracle11.2.0.1已经正式发布，并且linux版本已经可以从OTN下载。从2007年上海Oracle Open World上开始了解到不少Oracle11g的新特性开始，到现在已经过去整整两年。一般来说，Oracle新版本的第一个版本，很少有人会用在生产系统中，R2版本才是真正值得期待的Oracle11g，或许很快就能看到有人在讨论生产系统中的Oracle11g了。
OTN上的下载地址（一共两个disk，2.1GB，又是个大家伙）：
Oracle11g R2 for linux x86
Oracle11g R2 for linux x86_64
Oracle11gR2文档可以从这里下载，也可以到这里在线看。相比软件，文档的提供应该更加让人激动，接下来可以花点时间来看看了。除了之前已近广为流传的新特性，Oracle11.2.0.1还包含了一个反安装工具Oracle De-install Utility (11.2.0.1.0)，嗯，不错。
正在争取今年旧金山的Oracle Open World的机会，希望10月份可以去感受一下Oracle11gR2带来的震撼。
ora-600内部错误的类型
ora-600是Oracle对于一些内部错误的一个统一的错误号（类似的还有ora-7445）。要判断ora-600错误具体的类型，一般要根据其第一个参数来区分。一个ora-600的例子如下：
ORA-00600: internal error code, arguments: [15700], [3], [0x1DDE1AAB0], [], [], [], [], []
其中15700代表这个错误的具体类型，这是和并行查询相关的一个内部错误，后面的几个参数则是该错误的一些具体参数，不同类型的错误，参数的意义也不尽相同。
ora-600一共有两大类，一类的错误类型以数字标识，另外一类则以字符串标识。数字表示不同的内核层，而字符串则是具体的函数或者模块名。在Metalink的Doc ID: 175982.1 中，oracle列举了这两类错误的详细信息，转录在这里以供需要是查询：
[继续阅读全文]
DataGuard环境慎用alter tablespace drop datafile
Oracle10g开始提供alter tablespace drop datafile的特性，允许删除没有数据的空文件。本来这是一个还有那么点用的功能，可是，慎用，有bug。
ALTER TABLESPACE ... DROP DATAFILE ... produces bad redo which typically does not then drop the datafile either during recovery or at a standby. This can lead to subsequent errors such as ORA-600 [3689] of subsequent redo tries to add new datafile.
如果在data guard环境中，可能你在主库这么一执行，备库就挂了，报ora-600
ORA-00600: internal error code, arguments: [3689], [28], [], [], [], [], [], []
这个bug 5623467，从10.2.0.1一直影响到10.2.0.4，好在10.2.0.4后出了一个 Data Guard Physical Recommended Patch Bundle #1(Doc ID: 7936993.8)，总算是修复了这个问题，已经升级或者准备升级到10.2.0.4的朋友，一定要主机打上这个patch bundle，Oracle总是在一些你不注意的地方留个坑，一不小心就让你灰头土脸。
Workaround Avoid the use of the ALTER TABLESPACE .. DROP DATAFILE .. command on the primary.
10.2.0.4 Data Guard Physical Recommended Patch Bundle #1主要修复的bug如下：
Bug:3934160 Intermittent OERI[ksfdgfnm1]
Bug:5126719 LGWR may terminate the instance due to ORA-16164
Bug:5404871 Local first not used archiving closed thread at higher protection mode
Bug:5476236 RFS logminer client inoperative after physical standby switchover to primary
Bug:5623467 Corrupt redo from ALTER TABLESPACE DROP DATAFILE
Bug:6024730 V$BACKUP . STATUS shows “UNKNOWN ERROR”
Bug:6070225 Terminal recovery encounters ORA-308 when RMAN is active
Bug:6074620 LGWR unconditionally writes to trace file
Bug:6345573 OERI [krsmseqa.2] during terminal recovery
Bug:6469211 Slow startup with many log files on ASM
Bug:6490140 LGWR may crash the instance
Bug:6711853 V$ARCHIVE_DEST does not show new ‘binding’ on the physical standby
Bug:6840740 Switchover to physical standby allowed even if there are no physical standbys
Bug:6874522 V$DATAGUARD_STATS . VALUE may be NULL in logical standby
Bug:6882739 Controlfile enqueue contention from DataGuard
Bug:6919819 Flashback database may not correctly flashback some data blocks
Bug:6941717 Logical standby considered synchronous during dictionary load
Bug:6954829 OERI[kcramr_8] during media recovery
Bug:6955744 Archive log is not automatically registered when second CDC is built
Bug:6976005 CF enqueue held for longer than needed with flashback enabled
Bug:6980597 Heartbeat redo is not generated for single instance primary with RTA logical
Bug:7013124 30 second delay for 2nd pass instance recovery
Bug:7044551 ALTER TABLESPACE BACKUP CONTROLFILE TO TRACE can be slow
Bug:7136489 Unwanted trace lines “FAIL: tkrsf_al_read: Invalid archive log file contents”
Bug:7140204 OERI[ktupdb_0] undo block corruption on readable standby
Bug:7159505 Standby MRP stuck when no recovery area space left
Bug:7197445 Standby Recovery session cancelled due to ORA-600 [3020]
Bug:7257461 ORA-16146 during block media recovery on a primary with no standby destination
Bug:7257770 OERI:krffReserveCFEntry_1 / flashback disabled in RAC
Bug:7276960 Intermittent ORA-16014 errors in Streams environment
Bug:7432601 Hang holding FAL queue latch
Bug:7460818 Flashback logs are not balanced between redo threads
Bug:7494333 MRP may request wrong (too old) log
Bug:7568556 Slow standby recovery
Bug:7593835 Write failure when “selecting” new SRL is not handle properly
Bug:7643632 High log file sync in Data Guard maximum availability (sync) mode
Bug:8230457 Physical standby media recovery gets OERI[krr_media_12]
Bug:8283650 A dump can occur under krsmchksl with trace enabled
Bug:8287155 Final gap error (ORA-16416) reported during switchover to standby
Bug:8304589 Terminal recovery may hang
In Memory Undo与logical standby database
最近碰到了一个bug，导致逻辑备库重建，相当的郁闷。我们一个系统，包含一个主库，一个物理备库，一个逻辑备库。系统不久前刚从9i升级到10.2.0.4。5.30号因为系统维护，将原主库和物理备库做了一次switchover，切换没有什么问题，做了很多次了。这是逻辑备库突然报出了ora-600错误：
ORA-00600: internal error code, arguments: [2730], [331], [1], [13], [293130], [293130], [], []
ok，不用紧张，这个错误没啥问题。因为主库从9i升级到10g之后，为了保留降级的可能，compatible参数还是保留设置为9.2.0.0.0了，而这次切换，顺便把compatible改成了10.2.0.0.0，所以出现主备库的参数不一致了，就会报该错误。修改该参数即可。
但是，问题出来了：
ORA-00600: internal error code, arguments: [krvxbpx20], [1], [293141], [91], [96], [], [], []
Metalink上一查(Doc ID:761661.1)，麻烦来了:
The ORA-00600: [KRVXBPX20] indicates that logical standby builder detects IMU (In Memory Undo) in the redo streams. Logical standby does not support IMU and enabling supplemental logging disables the IMU.
In customer’s case, supplemental logging is enabled in the original primary database, but it is not enabled in the original physical standby database. Prior to 11.2 (which has not been released yet at the time of writing), supplemental logging DDLs are not propagated to the physical standby database. Thus they had a situation where the primary has supplemental logging set, but the physical standby did not.
晕死，逻辑备库不支持IMU(In Memory Undo,10g新特性)，所以要使用逻辑备库，必须在主库禁用IMU，否则将导致逻辑备库损坏，并只能重建。那为什么原来主库升级到10g之后，逻辑备库是正常的，而执行switchover切换到物理备库，才碰到问题呢？
我们的升级，是在主库执行升级脚，然后备库使用新版本的oracle软件直接应用主库传过来的日志的方式来完成整个系统的升级的。因为逻辑备库是在主库升级到10g后配置的，在执行exec dbms_logstdby.build生产数据字典信息的时候自动配置了supplement logging，而开启supplement logging将自动禁用IMU，所以未切换前逻辑备库是正常的。而问题在于，主库设置supplement logging的语句，并不会在物理备库上自动应用，这样实际上物理备库还是原来9i默认的未开启supplement logging的状态，这样一切换过来，问题就发生了。
如果你也在使用10g的逻辑保备库，要避免该问题，则可以：
1.直接在主库和物理备库都设置_in_memory_undo=false
2.在主库和物理备库检查supplement logging的状态
select supplemental_log_data_min as supp_log, supplemental_log_data_pk as supp_pk, supplemental_log_data_ui as supp_ui from v$database; SUPP_LOG SUPP_PK SUPP_UI ---------- ---------- ---------- NO NO NO
只要上述结果中，任意一列值为NO，则需要执行（物理备库可以mount状态或者open readonly状态执行）：
alter database add supplemental log data (primary key, unique index) columns;
