Reconfiguration started (old inc 0, new inc 16) Synchronization timeout interval: 900 sec List of nodes: 0 1
*** 2007-05-19 15:28:08.141
Global Resource Directory frozen node 0
release 10 2 0 2 node 1
release 10 2 0 2
number of mastership buckets = 128 domain attach called for domid 0
* kjbdomalc: domain 0 invalid = TRUE * kjbdomatt: first attach for domain 0 asby init, 0/0/x1
asby returns, 0/0/x1/false
* Domain maps before reconfiguration: * DOMAIN 0 (valid 0): 0 * End of domain mappings
* Domain maps after recomputation: * DOMAIN 0 (valid 0): 0 1 * End of domain mappings Dead inst
Join inst 0 1 Exist inst
Active Sendback Threshold = 50 %
Communication channels reestablished
sent syncr inc 16 lvl 1 to 0 (16,5/0/0) sent synca inc 16 lvl 1 (16,5/0/0) received all domreplay (16.6) sent master 1 (16.6)
sent syncr inc 16 lvl 2 to 0 (16,7/0/0) sent synca inc 16 lvl 2 (16,7/0/0)
Master broadcasted resource hash value bitmaps * kjfcrfg: domain 0 valid, valid_ver = 16 Non-local Process blocks cleaned out Set master node info
sent syncr inc 16 lvl 3 to 0 (16,13/0/0) sent synca inc 16 lvl 3 (16,13/0/0) Submitted all remote-enqueue requests
kjfcrfg: Number of mesgs sent to node 1 = 0 sent syncr inc 16 lvl 4 to 0 (16,15/0/0) sent synca inc 16 lvl 4 (16,15/0/0) Dwn-cvts replayed, VALBLKs dubious
sent syncr inc 16 lvl 5 to 0 (16,18/0/0) sent synca inc 16 lvl 5 (16,18/0/0) All grantable enqueues granted
sent syncr inc 16 lvl 6 to 0 (16,20/0/0) sent synca inc 16 lvl 6 (16,20/0/0) *** 2007-05-19 15:28:09.638
Submitted all GCS cache requests
sent syncr inc 16 lvl 7 to 0 (16,22/0/0) sent synca inc 16 lvl 7 (16,22/0/0) Post SMON to start 1st pass IR Fix write in gcs resources
sent syncr inc 16 lvl 8 to 0 (16,24/0/0) sent synca inc 16 lvl 8 (16,24/0/0) *** 2007-05-19 15:28:12.962 Reconfiguration complete * domain 0 valid?: 1
*** 2007-05-19 15:28:18.377
kjxgrtmc2: mounting member 0 thread 1 Begin DRM(32)
sent syncr inc 16 lvl 9 to 0 (16,0/31/0) sent synca inc 16 lvl 9 (16,0/31/0) ...
sent syncr inc 16 lvl 39 to 0 (16,0/36/0) sent synca inc 16 lvl 39 (16,0/36/0) *** 2007-05-19 15:28:28.459
sent syncr inc 16 lvl 40 to 0 (16,0/38/0) sent synca inc 16 lvl 40 (16,0/38/0) End DRM(32)
9.7 日志文件太小引起的切换过于频繁
假设现有三个日志组，每个组内有一个成员，每个成员的大小为512MB，现在想把此三个日志组的成员大小都改为1G。
? 创建2个新的日志组
alter database add logfile group 4 ('/oracle/oradata/redo04_1.log') size 1024M;
alter database add logfile group 5 ('/oracle/oradata/redo05_1.log') size 1024M;
? 切换当前日志到新的日志组
alter system switch logfile;
alter system switch logfile;
? 删除旧的日志组
alter database drop logfile group 1; alter database drop logfile group 2; alter database drop logfile group 3;
? 操作系统下删除原日志组1、2、3中的文件
? 重建日志组1、2、3
alter database add logfile group 1 ('/oracle/oradata/redo01_1.log') size 1024M;
alter database add logfile group 2 ('/oracle/oradata/redo02_1.log') size 1024M;
alter database add logfile group 3 ('/oracle/oradata/redo03_1.log') size 1024M;
? 切换日志组
alter system switch logfile; alter system switch logfile; alter system switch logfile;
? 删除中间过渡用的日志组4、5
alter database drop logfile group 4; alter database drop logfile group 5;
? 到操作系统下删除原日志组4、5中的文件
? 备份当前的最新的控制文件
SQL> connect internal
SQL> alter database backup controlfile to trace resetlogs
9.8 Oracle连接中断问题
? 环境:
10201，AIX53(据ORACLE称，在任何操作系统版本都有此问题)
? 现象：
监听器启动后，隔一段时间（长短不定），就会出现无法连接： 若是用10201版本的SQLPLUS，则会出现 NO LISTENER。 若是用9207 版本的SQLPLUS，则会出现：没反应，HANG住。
? 原因：
10201 版本上的一个BUG：4518443。其会自动创建一个子监听器，当出现此情况时，监听器将会挂起。
检查是否真因为此BUG造成此现象：
$ ps -ef | grep tnslsnr ora10g 8909 1 0 Sep 15 ? 902:44 /u05/10GHOME/DBHOME/bin/tnslsnr sales -inherit
ora10g 22685 8909 0 14:19:23 ? 0:00 /u05/10GHOME/DBHOME/bin/tnslsnr sales -inherit
正常情况只有一个监听器，而此BUG则会出现两个监听器。
? 解决方法：
打补丁4518443 或者在listener.ora 文件里加入：
SUBSCRIBE_FOR_NODE_DOWN_EVENT_
9.9 查询委托返回记录不对
? 环境:
10g，任何平台
? 现象：
查询语句结果集返回不全，只返回一条或其中几条。
? 原因：
未知，怀疑为Oracle Bug
? 解决方法：
收集相关表的统计信息，如：
SQL> Analyze table hs_secu.entrust compute statistics;
如问题仍然存在，使用下面语句： SQL> Analyze table hs_secu.entrust compute statistics for all indexes;
? 其它
这个问题已经多次出现，与很多Oracle 售前人员交流过，没有定论。目前怀疑与下面这个Bug相关。具体内容参见metalink：Wrong Results Possible on 10.2 When New \GROUP BY\（Doc ID: Note:387958.1） ? Cause
Bug 4604970 Wrong Results With 'Hash Group By 'Aggregation Enabled
Any query that displays \The \? Solution
Patch 4604970 can be downloaded from Metalink for most platforms . Problem is resolved in latest Patchset release 10.2.0.3.
Workaround:
Increase the memory used by hash group by Or
Disable the use of hash group by
eg: set optimizer_features_enable to \or
set \
9.10 Linux + Oracle 10g RAC的平台上，发生节点重启故障
? 环境:
? 服务器硬件平台：
- HP DL580 G4 4CPU（双核） 16G内存 - IBM 3950 4CPU（双核） 16G内存 ? 操作系统平台：
- Redhat Linux AS 4 Update 4 64bit
? 数据库系统：
- Oracle 10g R2(10.2.0.1) RAC (有2节点的，4节点的)
? 现象：
其中某一结点操作系统重启。经典场景：前一日清算到资金清算汇总时rac节点2自动重启，次日9:10 rac节点1死机，冷启动后恢复正常。 ? ALERT.LOG日志 Mon Jun 11 16:54:38 2007