Archive for May, 2009
How to resolve ORA-14117: partition resides in offlined tablespace
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. 删除临时表。
DROP TABLE TEMP;
3. 当所有的表分区都已经置换出来以后,就可以删除表空间了。
Tuning VMM kernel parameter in AIX for Oracle
对于运行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%,IBM甚至建议将该值设置为3%)
较低的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.
因此,对于作为Oracle数据库服务器的IBM AIX 5.3之后版本,VMM参数建议值如下。
minperm%=3 maxperm%=90 maxclient%=90 lru_file_repage=0 strict_maxperm=0 strict_maxclient=1 page_steal_method=1
修改VMM参数的命令如下。
#!/usr/bin/ksh vmo -p -o minperm%=3; vmo -p -o maxperm%=90; vmo -p -o maxclient%=90; vmo -p -o lru_file_repage=0; vmo -p -o strict maxperm=0; vmo -p -o strict maxclient=1; vmo -r -o page_steal_method=1;
How to recover data with DUL after datafile offline
系统情况如下:
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到表中。
此步操作在处理位于offline表空间中的表分区时碰到了ORA-14117错误,详细参看How to resolve ORA-14117: partition resides in offlined tablespace文章。
![Chanel [K]](http://www.dbform.com/wp-content/chanelk.png)