或许是个误会

用就用了,不标明原始出处和作者也罢了,但是还自己随便删删减减,实在不太厚道。 我的原文发表在eygle的blog上: 关于oracle的版权信息-一些你可能不知道的,一些可以看出Oracle野心的… vongates引用了我才知道,不关vongates的事儿: ORACLE不能进行双机热备 恩,其实我也没什么生气的,发个牢骚而已。 Update@2006-12-18 我更希望这是一个误会,转载尽量说明出处吧,以此共勉。

Failure Groups in ASM

Oracle Database 10g中出现的ASM(Automatic Storage Management,自动存储管理)技术提供了一种镜像冗余的方法,用以保护可能出现的磁盘故障而导致的数据丢失。要知道,以前也许我们需要RAID来达到这样的目的,但是现在Oracle数据库本身就提供给你这样的选项了,Oracle的意思是,把所有的鸡蛋都放到Oracle这个篮子里面吧,我们是Unbreakable的。 ASM提供了3种冗余方法。 external redundancy表示Oracle不帮你管理镜像,功能由外部存储系统实现,比如通过RAID技术。 normal redundancy(默认方式)表示Oracle提供2路镜像来保护数据。 high redundancy表示Oracle提供3路镜像来保护数据。 先预告一下,有时间再写吧,相信我,有内部资料的(本文用词很多来自某些metalink internal资料的翻译,因为inernal所以就不做link了),呵呵。 什么是 ASM failure group? Oracle通过failure group来提供数据的高可用性。ASM使用的镜像算法并不是镜像整个disk,而是作extent级的镜像。所以很明显如果为各个failure group使用不同容量的disk是不明智的,因为这样在Oracle分配下一个extent的时候可能就会出现问题。在normal redundancy模式下,ASM环境中每分配一个extent都会有一个primary copy和一个second copy,ASM的算法保证了second copy和primary copy一定是在不同的failure group中,这就是failure group的意义。通过这个算法,ASM保证了即使一个failure group中的所有disk都损坏了,数据也是毫发无伤的。 Oracle在分配extent的时候,所有failure group中的这个将拥有相同数据的extent称为一个extent set,当Oracle将数据写入文件的时候,primary copy可能在任何一个failure group中,而second copy则在另外的failure group中,当Oracle读取数据的时候,除非是primary copy不可用,否则将优先从primary copy中读取数据,通过这种写入无序,读取有序的算法,Oracle保证了数据读取尽量分布在多个disk中。 因为公用一个硬件模块的磁盘很可能会同时损坏或者失效,所以通常我们在设计failure group时,应该把一个大的盘阵中在一个tray中的磁盘放在一个failure group中,这样我们就可以拿走一个tray,失效这个failure group,然后换上新的tray和磁盘,这跟RAID的思想是一样的。 ASM的冗余方式一经设定就无法更改,如果我们想把normal redundancy改为high redundancy就只能是创建一个新的failure group,然后把旧failure group中的文件通过RMAN或者DBMS_FILE_TRANSFER的方法移动到新failure group中去。 如果在ASM环境中没有创建failure groups情况会怎样? 即使没有显式指定,failure groups也是始终会创建的。在这种情况下,每个disk都属于一个failure group,在创建磁盘组的时候,failure group也会默认创建,名称就是disk的名字。 应该创建多少failure…

Data Pump Import速度问题

平台:HP安腾2 操作系统:Redhat Enterprise Linux 4 数据库版本:Oracle 10.2.0.2 架构:6节点RAC 问题现象: 用数据泵方法导出一个表的两个分区数据很快,而导入却很慢 数据: 用数据泵导出,速度为29万条/秒(37MB/秒) 用数据泵导入,速度为300条/秒(39KB/秒) 解决过程: 开始没有看到环境,个人猜测也许是6节点的RAC在数据导入的时候同步Buffer Cache导致速度变慢,也许将涉及到Oracle本身的bug,所以建议用户可以先在单节点的同样环境中作一次测试,但是客户暂时没有单节点的环境。 于是在同样的6节点RAC环境中再作一个Data Pump导入,期间检查V$SESSION_WAIT,多次执行,发现确实有gc相关的等待事件,但是并不明显,然后查看V$ACTIVE_SESSION_HISTORY,用下面的SQL: select sum(time_waited), event from v$active_session_history where session_id = 501 group by event order by 1 desc; 此时问题很明显的暴露出来了,大量的时间耗费在log file switch completion和log file switch (checkpoint incomplete)这两个事件上,于是查看数据库的redo logfile大小,发现只有50M。 由于客户的数据库运行在非归档模式上,所以直接将redo文件加大到1G,再次测试,速度超乎想像。客户很爽,我也很爽。 结论: 1。在没有V$ACTIVE_SESSION_HISTORY的10g以前版本中,不要奢望能通过频繁查询V$SESSION_WAIT来定位问题。 2。Oracle的bug虽然不少,但是也没有想象中那么多。