还记得2007年时候遭遇过一次由于cursor_sharing = similar导致的系统问题，大量游标无法共享，产生巨大的version count，最终让整个系统崩溃。
在这个案例中我提到有4个条件导致了问题的发生：
1. cursor_sharing = similar
2. 收集了列上的histogram
3. SQL中使用到了此列作为条件，并且条件是“等于”
4. 这个SQL是没有绑定变量的
在最近Optimizer Development Group的Why do I have hundreds of child cursors when cursor_sharing set to similar in 10g文章中又再次提到这个现象。
This is in fact the expected behavior when
1. CURSOR_SHARING is set to similar
2. Bind peeking is in use
3. And a histogram is present on the column used in the where clause predicate of query
在Oracle10g中这是正常的现象，如果在某列上收集了histograms信息，那么就等于告诉CBO这一列上的数据是不平衡的，如果都使用同一个执行计划那么就可能产生问题，因此对于每一个distinct值，CBO都会产生一个child cursor，这一点无法避免。当然，由于这是child cursor，因此比cursor_sharing = exact时候产生的parent cursor还是要节省内存空间，至少SQL语句本身不需要重复存储了。
在Oracle10g中解决方法是：
1. 去掉这列上的histograms统计信息，或者
2. 将CURSOR_SHARING = FORCE
虽然源于对Oracle Database的热爱，我们无条件接受了10g中的这个方式，并且不认为这是bug，但是实际上心里一定暗暗骂过，傻啊，我收集了histogram你就要每个值产生1个cursor吗？自己再分析一下不行吗？都是一样的执行计划何必要用不同的cursor空间呢？
我想Oracle自己也一定意识到了这点，于是在Oracle11g中这一切有了变化，Oracle推出了称为Adaptive Cursor Sharing（自适应游标共享）的游标共享机制，可以阅读这几篇相关文章。
Optimizer Development Group：Adaptive Cursor Sharing
Optimizer Development Group：Update on Adaptive Cursor Sharing
Arup Nanda：Adaptive Cursors and SQL Plan Management
Tim Hall：Adaptive Cursor Sharing in Oracle Database 11g Release 1
什么是Adaptive Cursor Sharing就不重复叙述了，上面的几篇文章说的非常清楚，那么ACS机制对于之前在10g中碰到的child cursor过多的情况有何种改善呢？
简单地说，在Oracle11g中我们可以保留cursor_sharing=similar并且也保留列上的histograms统计信息，ACS机制将不会对每一个distinct值都产生一个child cursor，而是对每一个不同的执行计划产生一个child cursor，这大大减少了子游标的数量。这种处理方式无疑是合理的，只有在执行计划确实需要不相同的时候才产生额外的child cursor，当然，在bind peeking之后，CBO是否确实能够选择一个最优的执行计划那另当别论，是另外的话题。
注意，实际上产生的child cursor数量仍然是会大于execution plan数量的，也就是加入对于一个绑定变量的SQL一共有2种执行计划，那么child cursor数量会大于2，因为CBO始终在监控SQL的执行效率，如果认为变量的某一个真实值跟其它值的分布情况有很大的不同，那么CBO就会让这个SQL再做一次hard parse，这样就会产生出来一个新的child cursor，即使最终这个cursor的执行计划还是跟之前的相同。但是我们不用担心这些多余的cursor，因为这些cursor被标志为无法共享（可以通过v$sql.is_shareable字段得知），在需要的时候将会被age out出去。
kamus Oracle RDBMS Oracle11g
SQL> DROP tablespace SUMM_DATA07;
DROP tablespace SUMM_DATA07
*
ERROR at line 1:
ORA-14404: partitioned TABLE contains partitions IN a different tablespace appears.
SQL> ALTER TABLE CCDAWORK.S_ACCT_FIX DROP partition P6;
ALTER TABLE CCDAWORK.S_ACCT_FIX DROP partition P6
*
ERROR at line 1:
ORA-14117: partition resides IN offlined tablespace这样就处于了一个很尴尬的境地，面对着一个无法online的表空间，既不能将这个表空间drop了重建，也不能将这个表空间中包含的表分区删除掉。
解决方法是：通过exchange partition的方法，将位于offline表空间中的表分区置换到一个普通表中，这是数据字典的操作，不会检查表空间是否处于online状态，然后再将普通表删除，之后就可以将表空间删除了。
1. 将离线表空间中的所有表分区都选择出来，对于subpartition也同理操作。
SELECT owner,segment_name, partition_name,segment_type
FROM dba_segments
WHERE segment_type='TABLE PARTITION' AND
tablespace_name IN(list of the offlined tablespces IN upper case)
ORDER BY segment_name;
2. 对于所有的表分区循环执行2.1到2.3的步骤。
2.1. 创建一个临时表，表结构同分区表一样，OWNER.SEGMENT_NAME都是从第一步的SQL中获得的。
CREATE TABLE TEMP AS SELECT * FROM OWNER.SEGMENT_NAME
WHERE 1=2;
2.2. 置换表分区。
ALTER TABLE OWNER.SEGMENT_NAME
exchange partition PARTITION_NAME WITH TABLE TEMP;
2.3. 删除临时表。
3. 当所有的表分区都已经置换出来以后，就可以删除表空间了。
kamus Oracle RDBMS tips
对于运行Oracle数据库的AIX操作系统VMM（Virtual Memory Management）层面的系统内核参数如何进行调整，这是一个很古老的话题。这篇文章力图解释一些概念，同时与时俱进地提出一些设置的建议。
通常对VMM系统内核调优的目的，在于最大限度的保护计算内存页（computational memory）不被page-out到paging space中，因为对于计算内存页（特定于Oracle数据库来说就比如是SGA和PGA）来说被page-out出去的内存页总在之后的某一时刻又会被重新page-in，通常这样会对系统性能产生负面影响。另外对于像Oracle数据库这样拥有自己的数据缓存机制（data buffer cache）的数据库应用来说，保护计算内存页更显得格外重要。
在IBM AIX 5.3 ML1之前，对于作为Oracle Database Server用途并且使用裸设备作为Datafile存储的的AIX操作系统内核参数调优的经验通常如下：
maxperm%=maxclient%=(通常是一个很低的值，小于20或者30)
设置较小maxperm%值的原因在于，如果文件内存页在内存中的比例高过该参数值，那么VMM换页算法将只从文件内存页中进行偷页。将maxperm%值降低就意味着有更大的机会让VMM只从文件内存页中偷页。
minperm%=5（通常是一个比maxperm%更低的值）
lru_file_repage = 1（这是默认值）
比如以下的VMM参数设置就符合该种调优方式。
root@hostname:/> vmo -a |grep "maxclient%"
maxclient% = 15
root@hostname:/> vmo -a |grep "maxperm%"
maxperm% = 15
root@hostname:/> vmo -a |grep "minperm%"
minperm% = 10
root@hostname:/> vmo -a |grep "lru_file_repage"
lru_file_repage = 1但是实际上在AIX 5.3 引入了lru_file_repage参数之后，对于操作系统VMM层的内核参数调整方法已经发生了改变。现在的VMM参数调优建议应该如下。
maxperm%=maxclient%=(较高值，通常为90%)
因为较高的maxperm%值能够防止不必要的lrud进程运行，lrud进程是系统核心进程负责在需要的时候偷取内存页（stealing memory）。如果可以，maxperm%应该大于numclient%值（通过vmstat -v可以获得）。
minperm%=(较低值，对于超过64G物理内存的服务器来说通常为20%)
较低的minperm%值用以保证lru_file_repage参数作用不至于无法体现。通常minperm%值应该低于numperm%值（通过vmstat -v可以获得），如果当前的minperm%=5%满足需求那么可以不用修改。
strict_maxperm=0（这是默认值）
strict_maxclient=1（这是默认值）
lru_file_repage = 0
当该参数设置为0的时候，VMM将会优先尝试从文件内存页中进行偷页操作，而不影响到计算内存页。
更详细地看一下lru_file_repage参数是如何影响VMM偷页算法的。
由于空闲页低于了minfree参数值，或者其它的一些触发机制（比如说client page数量超过了maxclient%并且strict_maxclient=1）导致lrud进程要开始偷页操作，此时如果lru_file_repage =1（这是默认值）那么lrud进程将会根据多种内核参数和系统当前状况进行判断，可能是只从文件内存页中偷页也可能是不管内存段的类型从整个内存中进行偷页，这就可能导致计算内存页被page-out出去，而如果lru_file_repage =0，那么只要文件内存页（file memory）占内存的比值（numperm）高于minperm并且VMM确实能够从文件内存页中偷取到足够的内存以满足需求，那么就只会做文件内存页的page-out。因此，保护了Oracle数据库SGA在内存中的稳定性。
另外可以调整的参数包括：
page_steal_method = 1（应该为默认值）
参看如下解释：
The VMM maintains a logical list of free page frames that it uses to accommodate page faults. In most environments, the VMM must occasionally add to the free list by reassigning some page frames owned by running processes. The virtual-memory pages whose page frames are to be reassigned are selected by the VMM’s page-replacement algorithm. The VMM thresholds determine the number of frames reassigned.
By default in AIX 6.1, and optionally in AIX 5.3 the LRU algorithm can either use lists or the page frame table. Prior to AIX 5.3, the page frame table method was the only method available. The list-based algorithm provides a list of pages to scan for each type of segment.
You can disable the list-based LRU feature and enable the original physical-address-based scanning with the page_steal_method parameter of the vmo command. The default value for the page_steal_method parameter is 1, which means that the list-based LRU feature is enabled and lists are used to scan pages. If the page_steal_method parameter is set to 0, the physical-address-based scanning is used. The value for the page_steal_method parameter takes effect after a bosboot and reboot.
kamus Operating System, Oracle RDBMS AIX
系统情况如下：
1. Oracle版本是10.2.0.3，操作系统是HP-UX PA RISC 64
2. 数据文件存储在裸设备上
3. 需要恢复的表是分区表
4. 在调整存储硬件的时候没有关闭数据库，由于某些不可预知的故障导致某些用户表空间的数据文件write error，然后自动offline了
5. 数据库确实是归档模式，但是有一个每小时删除一次归档的crontab，删除了重新online数据文件需要的所有归档
6. 保留了之前建表时的create脚本
恢复过程如下：
1. DUL使用的init.dul内容：
CONTROL_FILE = control.dul
DB_BLOCK_SIZE = 16384
2. DUL使用的control.dul文件内容
0 1 /somepath/rsystem_01_8g blocks 524161
22 128 /somepath/r_data07_01_32g blocks 2096641
22 134 /somepath/r_data07_02_32g blocks 2096641
22 141 /somepath/r_data07_03_32g blocks 2096641
22 147 /somepath/r_data07_04_32g blocks 2096641
22 153 /somepath/r_data07_05_32g blocks 2096641
22 159 /somepath/r_data07_06_32g blocks 2096641
22 165 /somepath/r_data07_07_32g blocks 2096641
22 171 /somepath/r_data07_08_32g blocks 2096641
22 177 /somepath/r_data07_09_32g blocks 2096641
22 183 /somepath/r_data07_10_32g blocks 2096641
在HP-UX PA RISC中，虽然数据文件是存储在裸设备中的，但是仍然不需要设置需要跳过的字节，跟AIX中DUL相比较，缺少了第4位的4096。
3. 登录DUL
DUL> bootstrap;
DUL> unload table user_name.table_name;
由于system表空间正常，数据字典都存在，因此unload table的过程很简单，并且对于分区表（复合分区表）DUL也是完全胜任的，只需要指定table name，就会自动unload出该表的所有分区以及子分区的数据。
这次DUL大概花了4个小时，unload出120G左右的数据。数据库字符集为ZHS16GBK，字段内容包含中文内容，DUL可以unload出正确的字符。
4. 重新创建表结构，将DUL卸载出的数据再sqlldr到表中。
kamus Oracle RDBMS dul
