技术开发 频道

管理Oracle RAC中的存储

    管理Oracle RAC中的存储(2)

    1、ASM和RAC的SRVCTL

    通过SRVCTL可以完成如下的ASM管理操作:

    *  ADD操作向一个运行的CRS中添加关于ASM Instance的oracle cluster registry(OCR)信息。此操作也同时执行的相应的ENABLE

    例:$ srvctl add asm -n clusnode1 -i +ASM1 -o /ora/ora10

    note:这里的-o参数指明的是Instance的ORACLE_HOME,-i指明的是Instance的name

    *  ENABLE操作使运行在CRS中的ASM Instance可以自动的startup或是restart
    *  DISABLE操作阻止了CRS对相应的ASM Instance不必要的自动重启restart

    例:$ srvctl disable asm -n clusnode1 -i +ASM1

    *  START操作start一个CRS-enabled的ASM Instance。SRVCTL使用的是SYSDBA连接来执行此操作

    例:$ srvctl start asm -n clusnode1 -i +ASM1 -o open

    *  STOP操作stop一个ASM Instance,可选的shutdown方式有normal、transactional、immediate和abort

    例:$ srvctl stop asm -n clusnode1 -i +ASM1 -o immediate

    *  CONFIG选项显示了OCR中存储的特定ASM Instance的配置信息。
    *  STATUS选项可以获得ASM Instance的当前状态
    *  REMOVE选项将删除一个ASM Instance的配置信息,以及它相关联的Instance。在remove一个ASM Instance前,必须先stop并disable它

    note:在使用DBCA创建ASM Instance时,会自动执行ASM Instance的ADD和ENABLE操作。

    2、向ASM的迁移

    1)overview

    当需要将已存在的Database转移为ASM的,只能用RMAN工具。因为存储在disk group上的每个file都是物理延伸到该group上的所有disks上的,而RMAN命令可以使non-ASM files被重新分配到ASM的disk group上。

    尽管不是必须的,但多数情况下会将目标数据库迁移ASM时分配到两个disk groups上:一个存储所有的Database files,另一个用于存储flash recovery area的文件。

    可行的迁移方法可分为冷、热两种。冷迁移适用于无需关心停机时间长短的情况。如果希望尽量缩短服务停止时间,可选用热迁移。但,是不可能做的完全的在线迁移的。

    此外,迁移方法的选择还要看可用的磁盘空间能力。最简单的方法是有足够的磁盘空间,同时在file system和ASM存储两份Database。然而,即使是无法在系统中添加disks的情况,也是可以将Database向ASM做迁移的。

    2)使用额外空间做ASM的迁移

    具体步骤:

    ① 创建ASM Instance
    ② 创建data和recovery area disk groups
    ③ 设置Database file和back up OMF参数
    ④ 创建一个Database的副本到ASM上,并转换控制文件和data file到ASM
    ⑤ 重建闪回Database logs、临时文件,并改变追踪文件到ASM中
    ⑥ 可选择的将以前的backups迁移到ASM中
    ⑦ drop并re-create online redo log groups到ASM中

    如果Database相对较小,上述方法的停止服务时间是最少的。服务的停止时间是在第四步道第六步。只有flashback logs的重构是需要offline的。

    当然这里已经假设Database已经使用了闪回区,并且有足够的磁盘空间。

    下面上个例子,这里假设已经完成了ASM Instance的创建以及用于存放data file的DATA disk group和存放recovery file的RECOV disk group的创建和加载。并假设使用的是SPFILE。

    例子从③开始:

    ③使用sql*plus设置OMF参数

    ALTER DATBASE DISALBE BLOCK CHANGE TRACKING;
    ALTER SYSTEM SET db_create_file_dest=’+DATA’ SCOPE=SPFILE;
    ALTER SYSTEM SET db_recovery_file_dest=’+RECOV’ SCOPE=SPFILE;
    ALTER SYSTEM SET control_files=” SCOPE=SPFILE;
    SHUTDOWN IMMEDIATE;

    注:可以在open的任何一个Database Instance上执行上述命令,但需要立即关闭所有Instances。上述脚本中关闭了block change tracking机制,同时改变每个Instance的OMF参数使其指向新的disk groups。同时设置了新的CONTROL_FILES,确保OMF控制文件被创建到ASM中。

    ④当Database被关闭后,可以用RMAN执行下面的脚本:

    CONNECT TARGET
    STARTUP NOMOUNT;
    RESTORE CONTROLFILE FROM ‘filename_of_old_control_file’;
    ALTER DATABASE MOUNT;
    BACKUP AS COPY DATABASE FORMAT ‘+DATA’;
    SWITCH DATABASE TO COPY;
    RECOVER DATABASE;

    注:此脚本创建了两个多路复用的OMF控制文件,存储在DATA和RECOV中。filename_of_old_control_file 指明了至今仍在使用的一个控制文件名,当然,它也可是通过ALTER DATABASE BACKUP CONTROLFILE TO 得来的。随后使用新的控制文件加载Database,备份已经存在的文件系统的Database到DATA中作为镜像副本。之后将控制文件的指针切换到ASM Database的镜像副本中。

    ⑤在sql*plus中做flashback logs的迁移,改变tracking file和临时文件

    ALTER DATABASE FLASHBACK OFF;
    ALTER DATABASE FLASHBACK ON;
    ALTER DATABASE OPEN;
    ALTER TABLESPACE temp ADD TEMPFILE;
    ALTER DATABASE TEMPFILE ‘filename_of_old_tempfile’ DROP;
    ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;

    注:首先通过关闭再打开flashback loggi ng,在RECOV上重建了flashback logs。此外因为RMAN不会对临时表空间进行备份,所以需要对所有已经存在的临时表空间进程重建,只需对每个临时表空间添加至少一个tempfile,并删除以前在文件系统中的旧临时文件。最后一句将在DATA中重建change-tracking 文件。

    ⑥使用RMAN迁移已经存在的backups(这是可选的操作,但是推荐使用)

    CONNECT TARGET
    BACKUP AS COPY ARCHIVELOG ALL DELETE INPUT;
    BACKUP DEVICE TYPE DISK BACKUPSET ALL DELETE INPUT;
    BACKUP AS COPY DATAFILECOPY ALL DELETE INPUT;

    首先是移动所有的当前尚未被备份的归档日志文件,随后移动所有的当前的备份集。最后,移动所有的数据文件副本。

    ⑦使用sql*plus迁移online redo log files

    DECLARE

    cursor logfile_cur is select l.thread#, l.group#, l.bytes from v$log l;
    type numTab_t is table of number index by binary_integer;
    grouplist numTab_t; threadlist numTab_t; byteslist numTab_t;

    BEGIN

    open logfile_cur;
    fetch logfile_cur bulk collect into threadlist, grouplist, byteslist;
    close logfile_cur;
    for i in 1 .. threadlist.count loop
    migrateorl(threadlist(i), grouplist(i), byteslist(i) );
    end loop;
    END;

    注意,这里的migrateorl存储过程具体如下:

    CREATE PROCEDURE migrateorl(thread# number, group# number, bytes number) is
    stmt varchar2(1024):=’alter database add logfile thread’|| thread#||’ size ‘||bytes;
    asalc varchar2(1024):=’alter system archive log current’;
    BEGIN
    execute immediate stmt;
    stmt := ‘alter database drop logfile group ‘||group#;
    for i in 1 .. 5 loop
    begin
    execute immediate stmt;
    exit;
    exception
    when others then execute immediate asalc;
    end;
    end loop;
    END;

    具体存储过程的解释我就不罗嗦了,应该都看得懂的。

    3)表空间的迁移

    依然假设假设已经完成了ASM Instance的创建以及用于存放data file的DATA disk group创建和加载。具体过程如下:

    ①用RMAN 连接到target Database
    ②将target tablespace设置为OFFLINE或READ ONLY
    ③拷贝表空间到ASM 的disk group上
    ④切换控制文件的指针到ASM的副本上
    ⑤将target tablespace设置为ONLINE或READ WRITE

    具体在RMAN上执行的脚本如下:

    CONNECT TARGET
    SQL “ALTER TABLESPACE tbsname OFFLINE”;
    BACKUP AS COPY TABLESPACE tbsname FORMAT ‘+DGROUP1′;
    SWITCH TABLESPACE tbsname TO COPY;
    SQL “ALTER TABLESPACE tbsname ONLINE”;

    4)SPFILE向ASM的迁移

    可以将SPFILEs存储在ASM disk group中。具体迁移过程如下:

    ①通过已经存在的SPFILE创建一个PFILE到file system中。

    CREATE PFILE=’initORCL.ora’ FROM SPFILE;

    ②添加一个意味深长的directory

    ALTER DISKGROUP dgroup1 ADD DIRECTORY ‘+DGROUP1/ORCL/SPFILE’;

    ③在新的Directory中创建新的SPFILE文件

    CREATE SPFILE=’+DGROUP1/ORCL/SPFILE/spfileORCL.ora’ FROM PFILE=’initORCL.ora’;

    ④创建一个新的PFILE,只有SPFILE参数指向新的SPFILE文件。此PFILE文件将用于Instance的startup。

    spfile=+DGROUP1/ORCL/SPFILE/spfileORCL.ora

    3、ASM disk 元数据的需求

    必须添加额外的disk 空间用于存放ASM的元数据。可以使用下面的公式计算对于空disk group来说需要的额外的disk 空间,单位是MB。

    *  对于normal和high redundancy需要:

    15 + (2 * #_disks) + ( 126 * #_ASM_insts)

    *  对于external redundancy

    5 + (2 * #_disks) + (42 * #_ASM_insts)

    根据上面的公式,假设有4个节点的RAC,使用三个disks的high-redundancy disk group,需要额外的disk space为525MB(15+2*3+126*4)。

    当文件被创建,会有额外的元数据开支:

    *  对于high redundancy,大于20MB的file要增加3MB的元数据存储,并且该file每多增加42GB,会多占用3MB空间
    *  对于normal redundancy,大于30MB的file要增加3MB的元数据存储,并且该file每多增加64GB,会多占用3MB空间
    *  对于external redundancy,大于60MB的file要增加1MB的元数据存储,并且该file每多增加128GB,会多占用1MB空间

    4、ASM和可传输(transportable)表空间

    可以将存储在机器上的一个ASM disk group中的data file复制到另一台机器上的ASM disk group中,具体通过DBMS_FILE_TRANSFER包在一个Database Instance上的执行。该操作可以被直接执行而无需隐藏data file。

    但,如果要将传统的file system中的data file传输到其他机器上的ASM disk group中时,则需要通过典型的传输表空间过程锁住目标Database的data file,再使用RMAN迁移被加锁的表空间到ASM中。

    具体的过程其他文章中补充吧,这里先跳过了。

    5、ASM和存储阵列

    使用ASM并不意味这抛弃过去的存储方式,用新的东西取代它。

    虽然ASM 提供镜像的功能,但如果可以将这些任务交给外部的存储阵列(支持镜像或是raid 5等技术),将是非常好的实践。ASM可以被设置为使用external redundancy机制来保护数据。

    server-level的striping可以用于补充storage-level striping的性能。这种技术被称作double striping。因为server-level striping穿过storage level的后端,提供了一个均匀分布的I/O。并且通过可用的channel,动态多路径提供了动态分配。

    对recovery area使用ASM提供了更有特色的file system。它提供了自动的文件命名、分布和data file的自动扩涨。与recovery area相互结合,将不会有比ASM更好的cluster file system用于oracle Database files。

    6、ASM 的可扩展性

    ASM增加了下面的限制:

    *  一个存储系统中最多有63个disk groups
    *  一个存储系统,最多有10000个ASM disks
    *  每个ASM disk的最大存储量不可超过4 petabyte
    *  每个存储系统最大存储量不超过40 exabyte
    *  每个disk group最多可存放1百万个files
    *  每个file最大可存放2.4 terabyte的数据

    7、redo log files和RAC

    对于RAC,每个Instance向自己的online redo log files集合写入data,被一个Instance写入的redo 被称作一个thread redo,或一个thread。因此,每个Instance使用的redo log file group是与由初始化参数THREAD的设定一致的thread number决定的。如果THREAD参数设置为非0值,则给Instance在下次start时将使用该thread。推荐为每个Instance设置不同的THREAD参数值。

    可以通过ALTER DATABASE ADD LOGFILE THREAD语句将一个thread number与一个redo log file group相关联。通过ALTER DATABASE ENABLE THREAD语句启用一个thread number。在启用某个thread之前,它必须至少有两个redo log file groups。

    默认情况下,一个Database创建的同时会启用一个公共的thread。启用一个公共的thread,可以使用下面的语句:ALTER DATABASE ENABLE PUBLIC THREAD。该thread可以被所有THREAD参数设置为0的Instance所获得。

    所以,当添加Instance到Database中时,需要创建新并启用新的thread。

    NOTE:THREAD参数可设置的最大值要受到CREATE DATABASE时MAXINSTANCES参数的值的限制。

    8、RAC和自动Undo 管理

    oracle Database可以自动管理在分配给该Instance的特定undo tablespace中的undo segments。在正常环境中,只有被分配的Instance可以修改该undo tablespace的内容。而所有的Instances可以读取所有的undo blocks从而达到一致读的目的。同时,在事务恢复时,任何Instance可以更新任何undo tablespace,只要该undo tablespace当前没有被其他Instance用于写入undo或是做事务恢复。

    你通过指明RAC Database中的不同Instance的UNDO_TABLESPACE参数(在SPFILE或是各自的PFILEs)来分配undo tablespaces。如果没有设置UNDO_TABLESPACE参数,则每个Instance使用第一个可用的undo tablespace。如果没有可用的tablespace,则会使用SYSTEM回滚段。

    可以通过执行ALTER SYSTEM SET UNDO_TABLESPACE 语句动态的切换分配undo tablespace,其中用SID子句指明相应的Instance。可以在任何Instance中执行此句。在图中的例子里当分配新的undo tablespace时,将被挂起使用直到最后一个transaction被提交。挂起的offline tablespace将对于其他Instances是不可用的,直到其上的所有transaction被提交。

    note:在RAC中,不可同时使用自动undo 管理(AUM)和手工undo管理。高度推荐使用AUM模式。


 

0
相关文章