ITPub博客

8.0.5是不支持case语句的[@more@]今天碰到这么个案例,只能够用decode替换。

工作上有用到Listener加密的这个需求，试了试，留下个简单的记录，觉得在单实例数据库中还较方便的。在RAC中由于用到srvctl 管理，在srvctl start ...　命令时会去检查Listener的status(这个动作就等同于是执行了lsnrctl status命令来查询Listener状态)，所以这个时候会不通过(这是我目前在RAC环境加密Listener测试到挺麻烦的一个issue)，有时间再查一查。[@more@]rac-test2</oracle/9208>$lsnrctl <<< 此时是没有设置密码前的操作，可以正常作业(如status/start/stop/reload等操作)LSNRCTL for Linux: Ver

今天才知道ctas可以通过dblink抓取远程的blob,以前都是exp/imp来做的，MARK一下。几篇文章供参考：http://www.itpub.net/486546.htmlhttp://yangtingkun.itpub.net/post/468/67592http://yangtingkun.itpub.net/post/468/22850[@more@]

前些日子有需要用到procedure加密的需求，查了下文档，记录之。[@more@]1、将标准的procedure保存为.sql格式存放在db server上(ex: /u01/temp/dbatest.sql)。2、以oracle用户登录db server，执行$ wrap iname=/u01/temp/dbatest.sql oname=dbatest02.plb ，会在同目录里生成加过密的dbatest02.plb文件。3、以dba用户登录目标db，执行SQL>@dbatest02.plb 即可创建目标procedure。测试过从低版本oracle生成加密文件可以在高版本oracle上执行创建procedure ，可以直接copy *.plb文件到目标db server 上进行创建。

之前遇到的buffer busy waits的问题在所做的一些变动后，情况下降许多，但问题依然存在。[@more@]因为我们的环境中遇到的buffer busy waits为data block类型，识别码为220，让人直接想到的就是，高并发的DML是导致这个环境buffer busy waits的主因。(额外附注一下：当块被读到sga后，若有session想读取或者修改它，必先获取cache buffers chains锁存器以遍历该缓冲区链而找到所必需的缓冲区头，然后，根据session所请求的类别来以共享模式或者独占模式来pin住该缓冲区头，然后才可以进行读取或者修改,pin住后然后释放cache buffer chains锁

这是一套生产环境的3节点RAC环境，RHEL3+9208,突出等待事件为buffer busy wait及cluster wait。[@more@]top,vmstat,free过后发现系统较为空闲状态，抓statspack：Cache Sizes (end)~~~~~~~~~~~~~~~~~Buffer Cache: 1,312M Std Block Size: 16KShared Pool Size: 448M Log Buffer: 1,024KLoad Profile~~~~~~~~~~~~ Per Second Per Transaction--------------- ---------------Redo size: 103,989.15 5,199.31Logical reads: 4,307.61 215.37Block changes: 670.76 33.54Physical reads: 6.72 0.34Physical writes: 14.18 0.71User calls: 3

在一次恢复过程中,restore过后，在open时遇到报错：ORA-01152: file 1 was not restored from a sufficiently old backup ORA-01110: data file 1: '/../../raw12'[@more@]造成这种报错的大部分原因是因为controlfile里所记录的scn与datafile里的scn不一致。比如从备份里restore出的controlfile上的scn < datafile上所记录的scn，因此理论上二种思路：1、以old controlfile为准的，datafile上的scn是新的，这样存在着数据的不一致，要继续恢复下去，将datafile上的scn也要restore到与controlfile一致的情况，但这样会丢失datafile上的数

以前一直有些迷惑，一直以为v$open_cursor里查询出来就是当前open的cursor，google收藏了一些讨论得比较深入的帖，比如说这里：http://www.oracle.com.cn/viewthread.php?tid=17870 。[@more@]今天看到Natalka Roshak写的一篇关于open_cursors及session_cached_cursors的文章，顿时一目了然，参见：http://www.orafaq.com/node/758，摘录部分精彩内容如下：SESSION_CACHED_CURSORS sets the number of cached closed cursors each session can have. You can set SESSION_CACHED_CURSORS to higher than OPEN_CURSORS, lower than OPEN_CU

今天发现RAC下某节点没有设置定期移走listener.log的脚本，log文件达到800M，记得以前有listener.log超过2G就写不进去的案例，需要定期移走，如何转移走当前记录？[@more@]可以这样：1、先cp一份当前listener.log$cp ./listener.log /other/path/listener_bak20080708.log2、echo 一个空值到当前listener.log$ echo ''> ./ listener.log 或者用/dev/null。记录一下，免得某天头脑发昏来个rm或者mv之类的操作。当然，做好crontab当然是好习惯咯。

发现一台正式环境io偏高，抓了个statspack，命中率什么的都较为理想，突出事件是enqueue，遂直接找Enqueue activity部分查看，确定为CF类型：[@more@]Eq Requests Succ Gets Failed Gets Waits Time (ms) Time (s) -- ------------ ------------ ----------- ----------- ------------- ------------ CF 7,900 7,866 34 991 298.22 296再check视图v$enqueue_stat：SQL> select * from v$enqueue_stat where cum_wait_time>0 order by inst_id,cum_wait_time;以现CF类型的enqueue最近发生得很频繁：1 CF 12894072 1895049 12879213 1

alert log抛出一堆ora-600，查看udump下的一个trace文件，有发现 Probe:read_pipe: receive failed, status 3　类似的错误，从后边的dump文件(一般而言此时这个文件应该是超乎意料地大)看出是某位ap工程师debug时被hang住但忘了关闭debug所导致的： cause: These are the return codes from the RDBMS package Dbms_Pipe. FIX: SELECT SID FROM V$ACCESS WHERE object='DBMS_PIPE'; 找到session，kill.[@more@]

以前写过些php，今天偶尔发现现在的php cms真的好多哦，比如Joomla .[@more@]以前写过些php，今天偶尔发现现在的php cms真的好多哦，比如Joomla . www.joomla.cn 另外，用了快2年的toad今天才会用auto trace，很简单的一步，在editor窗口选中"Auto trace"选项就好了。 一个生产库里出现latch free，检查发现latch类型为cache buffers chains ，查owi，先是否定了是热点块导致的原因，继而检查，有可能是逻辑读较大的sql频繁执行所导致。（ps:每一个逻辑读都会引起一个latch get和一个cpu的使用的），sql调优又要开始了，不过，现在终

http://download.oracle.com/docs/cd/B10501_01/server.920/a96540/queries4a.htm#2053937这张图，很容易让人联想到现在的X销模式。START WITH specifies the root row(s) of the hierarchy.CONNECT BY specifies the relationship between parent rows and child rows of the hierarchy. [@more@]