使用_px_trace跟踪分析并行执行的情况
并行在系统资源充足的情况下，可以极大的加快操作的速度，在数据仓库环境中应用较多。而在OLTP环境中，由于并发较大，开启并行可能瞬间导致资源耗尽，所以一般只有在业务低估期间执行一些诸如创建索引等维护操作时才会考虑开启并行，并且在执行完成后去掉对象的并行度，否则可能后果很严重。
由于并行涉及到多个进程间分配协调任务，往往比较容易出现各种各样的问题，而且从数据字典中比较难以定位到具体的原因。Oracle提供了一些event来trace并行过程，如10384,10390,10399等等，但是这些event往往无法trace整个的并行过程，有时候需要设置多个event才能trace到我们需要的内容。而_px_trace则提供了一个统一的trace入口，并且有些信息还是event无法trace到的。
语法如下：
- Verbosity表示trace信息的详细程度，取值为high,medium,low
- area表示trace的区域，取值scheduling,execution,granul,messaging,buffer,compilation,all,none
- time表示是否在trace中包含时间信息
会话已更改。
SQL> select count(*) from test;
COUNT(*)
----------
11846
SQL> alter session set "_px_trace"="none";
会话已更改。
生成的trace文件比较多，qc和slave进程都会生成相应的trace文件。具体的trace信息分析我这里就不写了，有兴趣的可以参考Metalink(Note:444164.1)
Oracle11g ASMCMD新命令
Oracle10g的ASMCMD命令，提供了通过命令行方式管理ASM的接口，但是功能非常有限，比如无法在asm和os之间直接复制文件，就是一件很让人头痛的事情，只能通过rman或者dbms_file_transfer实现。
Oracle11g的ASMCMD终于加上了一个比较实用的cp命令，不但可以在ASM和OS之间复制文件，也可以在不同的ASM Instance和Diskgroup之间复制文件，这就非常的方便了。
source +dgtest/test/datafile/USERS.264.646186565
target users.dbf
copying file(s)...
file, E:\ORACLE\PRODUCT\11.1.0\DB_1\DATABASE\USERS.DBF, copy committed.
Feedsky数据异常
因为要查一篇文章，打开blog一看，被Feedsky显示的订阅数吓了一跳
估计再过十年，到这个订阅数还是有那么0.0001%的希望的，假如那个时候我还在写这个blog的话，哈哈。跑到Feedsy一看，果然发布了维护通知
因数据量过大，需要对系统进行升级维护，预计从今天下午6点钟开始，共需要耗时12小时，在此期间，Feed更新不会受到影响，用户后台的统计数据会暂时停止更新，请见谅。
只是这个通知是昨天的，到现在12个小时早过去了吧。看来维护的时候把数据给搞乱了，随便刷新了几下，订阅数在几个5位数字间跳来跳去，居然还是随机的。这个现象比较奇怪，要是订阅数算不出来，那么取旧的值就可以了，要么就显示为0，反正显示0大家已经见怪不怪了；要是算错了，那么也应该是个固定的值。这么变来变去的就有意思了，估计数据库的问题不大，还是前台应用的可能性比较高一点。
管理后台已经无法进入了，还有订阅数异常保护机制啊，不知道正常情况下有谁能碰到这个告警的^_^
Oracle一个典型行列转换的几种实现方法
假如有如下表，其中各个i值对应的行数是不定的
I A D
---------- ---------- -------------------
1 b 2008-03-27 10:55:42
1 a 2008-03-27 10:55:46
1 d 2008-03-27 10:55:30
2 z 2008-03-27 10:55:55
2 t 2008-03-27 10:55:59
要获得如下结果，注意字符串需要按照D列的时间排序：
2 z,t
这是一个比较典型的行列转换，有好几种实现方法
