那些在魔兽世界的日子

第九城市今天宣布:在中国大陆地区由第九城市所运营的《魔兽世界》,将于2009年6月7日凌晨0时起终止服务.感谢大家对第九城市四年来努力专心运营 《魔兽世界》的支持和宽容!

从2005年4月份某天开始,进入了这个叫作《魔兽世界》的游戏,经历过赞叹、疯狂、沉迷、疲劳、厌倦、回归、游荡、休闲各种不一而足的状态,断断续续地走到今天,回首算来,居然已经过了4年多。

曾经如此着迷于在这个世界中团队合作的氛围,沉浸于每次齐心协力闯过难关时无以言表的快乐与兴奋,可是随着朋友们的慢慢离去,它几乎已经蜕变为我的机器中一个单机游戏。只是每次用小号奔跑在贫瘠之地的月夜原野中,耳边那悠扬而又忧伤的音乐像流水一样潺潺而过,心中那份柔情总是会被不经意地触碰到。

我仍然怀念在魔兽世界中最初的那段日子,清晰地记得40个人历经艰难推到熔火之心第一个BOSS时的激动,我还保留着那些珍贵的截图,可惜,只能用物是人非来形容了。

在这张图上的朋友们现在还有几个仍然游荡在魔兽世界中?(很可惜,我只拖出了4个小组的名单,加上我自己这个小组才25人)

今天是九城魔兽世界的最后一天,谨以此文送给那些跟我一起在这个世界里挥霍了青春的朋友们。新的世界在等待吗?

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

Updated@2013-01-30
对于运行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%,在AIX6.1中该值已经默认为3%)
较低的minperm%值用以保证lru_file_repage参数作用不至于无法体现。通常minperm%值应该低于numperm%值(通过vmstat -v可以获得),如果当前的minperm%=5%满足需求那么可以不用修改。
strict_maxperm=0(这是默认值,表示这不是一个hard limit)
strict_maxclient=1(这是默认值,表示这是一个hard limit)
lru_file_repage = 0
当该参数设置为0的时候,VMM将会优先尝试从文件内存页中进行偷页操作,而不影响到计算内存页。在AIX6.1中该值已经默认为0。

更详细地看一下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

然而如果数据库服务器中文件系统使用较多(比如数据文件存储在文件系统中,或者有大量的RMAN备份归档日志,或者有大量磁盘文件复制转移等操作),那么强烈建议设置maxperm%=maxclient%=(低值,20%或者10%),这是为了保障有安全的物理内存空闲,而不至于给文件内存页占据,因为如果maxclient%设置为90,那么意味着文件内存页可以占据更多的内存(也就是意味完全空闲的内存更低),虽然根据lru_file_repage=0的算法,偷页操作会从文件内存页中进行,但是这部分缓存的释放是需要时间的,也会需要大量IO和换页操作,当某个时间点,数据库服务器上突然出现大量需要消耗内存的操作,就可能导致大量的换页,从而消耗大量系统资源,影响数据库性能,并可能进一步导致数据库服务器的不稳定。这在很多客户系统中已经遇到这样的案例。

因此对于这样的系统,我们建议VMM参数设置如下。

minperm%=3
maxperm%=20
maxclient%=20
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%=20;
vmo -p -o maxclient%=20;
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;