管理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模式。