ITPub博客

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

Why does my system swaps the data instead of freeing cache and buffer memory?[@more@]The kernel uses heuristics to guess which pages of memory are likely to be needed in the near future, and tries to keep those pages in memory, regardless of whether they belong to processes or kernel caches. It is normal for the kernel to swap out process memory even when there is plenty of cache memory that could be easily freed. The kernel heuristics can be tuned by changing the vm.swappiness parameter of

工作上有用到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 上进行创建。

The CPU’s Translation Lookaside Buffer (TLB) is a small cache used for storing virtual-tophysical mapping information. By using the TLB, a translation can be performed without referencing the in-memory page table entry that maps the virtual address. However, to keeptranslations as fast as possible, the TLB is usually small. It is not uncommon for large memory applications to exceed the mapping capacity of the TLB.[@more@]在2.6的kernel里对这个值 的评价是这样的：This memory management feature is

之前遇到的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调优又要开始了，不过，现在终

做一个恢复测试，又碰上了，插个小别针记录下。[@more@]比如，如果需预期目的是要从/Test1 (逻辑link) ---> /u01/data/test1 (实体目录)这样的模式这样写就好了：ln -s /u01/data/test1 /Test1注意，这里的/Test1目录是不需要事先建立好的，link后会自动建立，另外就是顺序啦，记得ln -s语法顺序是前实体目录，后逻辑link就好。

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@]