Recent Posts

RSS Feeds

CPU_COUNT导致的LIBRARY CACHE问题

Posted on 四月 17, 2010 by 白鳝

LIBRARY CACHE闩锁等待导致了系统数分钟的HANG住，什么原因呢？请到Oracle粉丝网阅读： http://www.oraclefans.cn/forum/showtopic.jsp?rootid=18377

Permalink     No Comments

EVENT 19549和从损坏的备份集中恢复数据文件

Posted on 九月 02, 2009 by 白鳝

EVENT 19549和从损坏的备份集中恢复数据文件

如果备份集损坏，而这个备份集又是我们唯一的备份集。这个时候我们的想法可能是能恢复多少数据就回复多少数据了。不过我们可能碰到下面的错误：

                      
RMAN-00571: =========================================================== 

                      
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== 

                      
RMAN-00571: =========================================================== 

                      
RMAN-03002: failure during compilation of command 

                      
RMAN-03013: command type: restore 

                      
RMAN-03007: retryable error occurred during execution of command: IRESTORE 

                      
RMAN-07004: unhandled exception during command execution on channel t1 

                      
RMAN-10035: exception raised in RPC: ORA-27192: skgfcls: sbtclose2 returned  

                      
error - failed to close file 

                      
ORA-19511: sbtclose2: Failed to process backup file. 

                      
ORA-19612: datafile 84 not restored due to missing or corrupt data 

                      
RMAN-10031: ORA-19624 occurred during call to DBMS_BACKUP_RESTORE. 

                      
RESTOREBACKUPPIECE 

                      
 

                      
这个时候怎么办呢？为了解决这个问题，Oracle提供了两个EVENT 19548,19549

                      
EVENT 19548:忽略备份集中的坏块，这是一个很危险的事件，建议慎重使用。因为在不设置这个事件的时候，如果RMAN恢复数据文件的时候发现备份集有坏块，就会

                      
    在坏块的位置写入一个空块。而设置了这个事件，不管怎样，都会将这个块写入数据文件，这可能导致不一致的产生。不过设置了这个事件也不一定能够跳过

                      
    坏块恢复文件，因为一个备份集往往有多个文件，如果标志哪个块属于哪个文件的数据块坏了，那么恢复数据将变得不可能

                      
 

                      
EVENT 19549：如果在恢复的时候还没有恢复到所需要的所有数据块，就碰到文件结束了，这个时候会报 ORA-19612,如果设置了这个事件就会忽略这个错误

                      
 

                      
这两个事件可以作为最后的解决方案来使用，不过使用的时候要慎重。

                      
 

                      
另外要注意的是，这两个事件必须在以下版本使用：

                      
  ORACLE 8.1.7.4：必须打了PATCH  2973616,这个补丁目前只支持SUN SPARC 64位和AIX 32位，其他平台无补丁包

                      
  ORACLE 9.2.0.4或者以后版本

                      
 

                      
使用方法：

                      
event = "19548 trace name context forever"


                      
event = "19549 trace name context forever"


                      
 

Permalink     No Comments

一个WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!的分析

Posted on 八月 25, 2009 by 白鳝

请参考：

http://www.oraclefans.cn/forum/showtopic.jsp?rootid=13816&CPages=1

Permalink     No Comments

关于10g 表分析采样的官方说明

Posted on 八月 06, 2009 by 白鳝

很多客户的数据库从9i升到10g 后都出现了性能问题，有些甚至比9i时下降超过50%。后来经过分析绝大多数都是和大量SQL使用了错误的执行计划有关。为什么10g 会出现这么严重的执行计划偏差呢？在9i的时代里，我们都自己编写分析脚本来对表和索引进行分析，在使用采样比例上，大家一般都比较保守，基本上都在20%以上。而10G提供了一个令人心动的技术就是自动分析，10g 数据库由于取消了RBO优化模式，缺省的优化器模式变为了ALL_ROWS，因此对分析数据的依赖程度更高，因此Oracle自带了一个标准的分析脚本，并且定期进行分析。不过随着这种新技术的使用，问题就出现了，oracle 的自动分析脚本往往只做很少量的采样，导致大量的表的评估信息出现严重偏差。最终很多客户选择了停止自动采集作业，改为手工分析。

以前在和一些Oracle的工程师讨论这个问题的时候，大家都觉得Oracle的AUTO SAMPLE是很不错的，是Oracle官方建议的，应该不会有问题，只有少量的系统需要调整，自定义采集作业脚本。今天我在整理以前的资料的时候，发现了一份METALINK的文档，发现这里的观点和我一直坚持的观点很近似。现在拿出来和大家共享。

全文参考：

http://www.oraclefans.cn/forum/showtopic.jsp?rootid=13577

Permalink     No Comments

一个安装CRS无法发现节点的问题的处理思路

Posted on 八月 04, 2009 by 白鳝

 

昨天有一个朋友安装CRS的时候无法找到节点：

$ ./cluvfy/runcluvfy.sh stage -post hwos -n node1,node2 -verbose
notice: JAVA_HOME not set in the environment.

Performing post-checks for hardware and operating system setup

Checking node reachability...

Check: Node reachability from node "node1"
  Destination Node                      Reachable?             
  ------------------------------------  ------------------------
  node1                                 no                     
  node2                                 no                     
Result: Node reachability check failed from node "node1".

碰到这个问题，首先我问他hostname是否就是Node1，node2，而且这两个地址是否正确的在/etc/hosts里定义了。他回答是这些都没错，然后我问他网卡的顺序是否正确，在HP-UX下有时候私网和公网的网卡在两台服务器上的设备名不对应，也可能会出一些莫名其妙的错误。经过确认都没问题。

检查hosts文件和services文件的属性，也都没问题，world有r的权限。看样子问题不是出在这些地方。那么下面该怎么处理呢？我建议他用tusc跟踪一下，看看能有什么发现。

很快在tusc里面我们发现了疑点：

stat("/usr/sbin/ping", 0x742ff5e4) .................................................................... = 0
access("/usr/sbin/ping", X_OK) ........................................................................ = 0
pipe() ................................................................................................ = 9 (10)
pipe() ................................................................................................ = 11 (12)
pipe() ................................................................................................ = 13 (14)
vfork() ............................................................ (returning as child ...) ......... , 2452
execve("/tmp/2437/jre/bin/HPUXChildWrapper", 0x1923d0, 0xf5230) ....................................... [entry]
                              argv[0] @ 0x192410: "/tmp/2437/jre/bin/HPUXChildWrapper"
                              argv[1] @ 0x742ff460: "9"
                              argv[2] @ 0x742ff470: "12"
                              argv[3] @ 0x742ff480: "14"
                              argv[4] @ 0xffffffffc1be1140:
                              argv[5] @ 0x742ff038: "/usr/sbin/ping"
                              argv[6] @ 0x192170: "node1"
                              argv[7] @ 0x192188: "-n"
                              argv[8] @ 0x1921a0: "1"
                              argv[9] @ 0x1921e8: "-m"
                              argv[10] @ 0x192200: "3"
                               env[0] @ 0x77ff00f2: "_=/tmp/2437/jre/bin/java"
                               env[1] @ 0x77ff010b: "MANPATH=/usr/share/man/%L:/usr/share/man:/usr/contrib/man/%L:/usr/contrib/man:/usr/local/man/%L:/usr/local/man:/opt/mx/share/man:/opt/upgrade/share/man/%L:/opt/upgrade/share/man:/opt/pd/share/man/%L:/opt/pd/share/man:/opt/pd/share/man/%L:/opt/pd/share/man:/opt/pd/share/man/%L:/opt/pd/share/man:/opt/resmon/share/man:/opt/gnome/man:/opt/openssl/man:/opt/openssl/prngd/man:/opt/wbem/share/man:/opt/hparray/share/man/%L:/opt/hparray/share/man:/opt/graphics/common/man:/usr/dt/share/man:/opt/samba/man:/opt/perl/man:/opt/ignite/share/man/%L:/opt/ignite/share/man:/opt/ssh/share/man"
                               env[2] @ 0x77ff034e: "SHLIB_PATH=/tmp/2437/jre/lib/PA_RISC2.0:/tmp/2437/jre/lib/PA_RISC2.0/server:/tmp/2437/jre/../lib/PA_RISC2.0:/tmp/2437/lib32:/tmp/2437/srvm/lib32:"
                               env[3] @ 0x77ff03e0: "PATH=/usr/bin:/usr/ccs/bin:/usr/contrib/bin:/opt/hparray/bin:/opt/nettladm/bin:/opt/upgrade/bin:/opt/fcms/bin:/opt/pd/bin:/opt/resmon/bin:/opt/gnome/bin:/usr/bin/X11:/usr/contrib/bin/X11:/opt/mozilla:/opt/wbem/bin:/opt/wbem/sbin:/opt/graphics/common/bin:/usr/sbin/diag/contrib:/opt/mx/bin:/opt/perl/bin:/opt/ssh/bin:."
                               env[4] @ 0x77ff051e: "COLUMNS=125"
                               env[5] @ 0x77ff052a: "ORACLE_BASE=/home/oracle/base"
                               env[6] @ 0x77ff0548: "EDITOR=vi"
                               env[7] @ 0x77ff0552: "LOGNAME=oracle"
                               env[8] @ 0x77ff0561: "CV_DESTLOC=/tmp"
                               env[9] @ 0x77ff0571: "ERASE=^H"
                               env[10] @ 0x77ff057a: "CV_JDKHOME=/tmp/2437/jre"
                               env[11] @ 0x77ff0593: "CRS_HOME=/home/oracle/crsHome"
                               env[12] @ 0x77ff05b1: "SHELL=/sbin/sh"
                               env[13] @ 0x77ff05c0: "HOME=/home/oracle"
                               env[14] @ 0x77ff05d2: "LD_LIBRARY_PATH=/tmp/2437/lib:"
                               env[15] @ 0x77ff05f1: "TERM=vt100"
                               env[16] @ 0x77ff05fc: "CV_HOME=/tmp/2437"
                               env[17] @ 0x77ff060e: "PWD=/home/oracle"
                               env[18] @ 0x77ff061f: "TZ=EAT-8"
                               env[19] @ 0x77ff0628: "LINES=47"
                               env[20] @ 0xffffffffc1be0fa8:
                               env[21] @ 0xffffffffc1be0fd0:

于是我让他执行一下/usr/sbin/ping node1 -n 1 -m 3
发现ping没有-m选项

# ping node1 -n 1
PING node1: 64 byte packets
64 bytes from 192.168.1.150: icmp_seq=0. time=0. ms

----node1 PING Statistics----
1 packets transmitted, 1 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 0/0/0
# ping node1 -n 1  -m 3
Usage:  ping [-oprv] [-i address] [-t ttl] host [-n count]
        ping [-oprv] [-i address] [-t ttl] host packet-size [[-n] count]

这下子就很明确了，估计是HP-UX的补丁没有打全，经过检查，发现GOLDQPK11i 没有打，打了补丁后，测试一下/usr/sbin/ping node1 -n 1 -m 3
,一切都OK了，于是再安装CRS，一切正常。

这个案例主要让大家学会如何通过TUSC去做深入的诊断，如果发现问题后胡乱的从网上去找解决方案，肯定是不行的。解决问题，思路最重要。

 

Permalink     No Comments

粉丝网2周年的感想-再谈资料共享

Posted on 六月 12, 2009 by 白鳝

办粉丝网的目的是为大家提供一个开放的平台，交流技术，交换各自手中的好的技术资料。想来粉丝网也已经足足开通了2年了，这两个目的都没有达到。

首先是交流技术，到粉丝网来的朋友往往都是为了下载资料，而并没有多少技术交流。

其次是分享资料，粉丝网上有不少资料的确不错，大家也很喜欢。不过主动把资料上传到粉丝网上的人很少。很多DBA把手头的资料看的很宝贝，藏着掖着，哪怕自己看不懂也没人愿意拿出来交流。实际上老白觉得没有必要。与其在手里放着几年也难得看上一眼，还不如把资料上传，给更多的人共享，只有大家都愿意拿出自己的资料来交流，大家才能获得更多的资料。虽然老白尽力上传资料，不过老白的收藏还是有限的，没有大家的共同互动，资料交流就是一句空话。

不管大家对老白的观点是否赞同，老白还将继续上传资料给大家共享。

Permalink     4 Comments