这篇文章给大家分享的是有关甲骨文数据库部分迁至闪存存储的示例分析的内容。小编觉得挺实用的,因此分享给大家做个参考,一起跟随小编过来看看吧。
<强>环境:甲骨文11.2.0.4 RAC节点(2)强>
说明:假设新增闪存挂载点是/flash(使用了第三方的集群文件系统),如果是使用甲骨文的ASM,则本文提及的所有/flash目录都可以认定是新的闪存磁盘组是+ flash。
<强> 1实施需求强>
为提高数据库IO性能,采购了全闪存阵列存储,但由于前期预算有限,只能将部分数据迁移到闪存存储上(当然,如果条件允许,还是强烈建议将数据库整体全部迁移到闪存)。经评估,最终确认将业务高峰时刻,IO压力最大的表空间整体迁移到闪存存储上,此外,将数据库的重做和撤销迁移到闪存存储上。
注:本文方案实际是我对某生产环境的真实需求而编写,由于该场景具有普适性,故脱敏后发表。
<强> 2确认迁移表空间信息强>
主要根据业务高峰(以历史DBTime为主要参考指标),从对应的心田报告中的表空间IO统计部分筛选出IO压力最大的表空间,比如我这里确定数据库需要迁移到闪存的表空间是TBS_D_JINGYU。
<强>具体依据:强>
。抽查平日数据库的心田报告,根据表空间IO统计部分,TOP1就是TBS_D_JINGYU,而且比其他表空间高一个数量级。
b。抽查业务高峰时段数据库的心田报告,根据表空间IO统计部分,TOP1多数情况也是TBS_D_JINGYU,但由于业务高峰期很多表空间都比较忙,不如平日明显,但综合考虑,还是选择TBS_D_JINGYU表空间。
TBS_D_JINGYU表空间大小:当前大小是2160克,预估数据量按30%的增长率,至少需要空间为2810 g .
<强> 3确认重做信息强>
将所有重做日志文件迁移到闪存。
很多年前,在甲骨文界就一直流传一个说法:不建议将重做放在SSD上,就连Oracle官方文档都有对应的说法,所以直到现在还有很多人不敢将重做放在SSD上。而实际上,这个观点早已经过时,目前的企业级闪存卡经实际测试,是完全可以用来存放重做的。
确认重做信息,我这里是2节点RAC,重做相关信息是:一共有两个线程,每个线程有7组日志,每个日志大小为2 g。总大小28 g.group组号是31-37,41-47。
<强> 4确认撤销信息强>
确认撤销信息:
TABLESPACE_NAME ,,,,,,, FREE_SPACE USED_SPACE TABLESPACE_SIZE USED_PERCENT - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -,- - - - - - - - - - -,- - - - - - - - - - -,- - - - - - - - - - - - -安康;- - - - - - - - - - - - UNDOTBS1 ,,,,,,,,,,, 176.668823, 4.33117676,,,,,,, 181, 2.39291534 UNDOTBS2 ,,,,,,,,,,, 47.9354248, .064575195 ,,,,,, 48,。134531657
可以看的到,UNDOTBS1大小181克,UNDOTBS2大小48 g。总大小229克。
<强> 5表空间迁移到闪存强>
<强> 5.1确认闪存空间符合最小需求强>
假设闪存挂载目录是/flash;按表空间30%预留增长空间计算,对应闪存挂载目录空间最小值:
数据库迁移至闪存的空间最小需求:表空间+重做+撤销=2810克+ 28 g + 229 g=3067克
注:如果数据表空间和对应索引表空间是分开规划的,那么强烈建议将这个IO最高的数据表空间对应的索引表空间也一起迁移,这样总空间需求量就还要加上对应索引表空间的需求。
<强> 5.2表空间迁移到闪存强>
使是用备份拷贝tablesapce来实现表空间TBS_D_JINGYU的迁移工作:
RMAN>, backup as copy tablespace TBS_D_JINGYU format & # 39;/flash/oradata/jydb5 & # 39;; 完成,alter tablespace  TBS_D_JINGYU 离线; RMAN>, switch tablespace  TBS_D_JINGYU 用复制; RMAN>, recover tablespace  TBS_D_JINGYU; 完成,alter tablespace  TBS_D_JINGYU 网络;
<强> 6重做迁移到闪存强>
新增重做日志文件,删除历史重做。
重做迁移到闪存的操作命令:
——新增redo 日志文件 alter database  add logfile  THREAD 1, group 11, & # 39;/flash/oradata/jydb5 redo11.log& # 39;, SIZE 2147483648; alter database  add logfile  THREAD 1, group 12, & # 39;/flash/oradata/jydb5 redo12.log& # 39;, SIZE 2147483648; alter database  add logfile  THREAD 1, group 13, & # 39;/flash/oradata/jydb5 redo13.log& # 39;, SIZE 2147483648; alter database  add logfile  THREAD 1, group 14, & # 39;/flash/oradata/jydb5 redo14.log& # 39;, SIZE 2147483648; alter database  add logfile  THREAD 1, group 15, & # 39;/flash/oradata/jydb5 redo15.log& # 39;, SIZE 2147483648; alter database  add logfile  THREAD 1, group 16, & # 39;/flash/oradata/jydb5 redo16.log& # 39;, SIZE 2147483648; alter database  add logfile  THREAD 1, group 17, & # 39;/flash/oradata/jydb5 redo17.log& # 39;, SIZE 2147483648; alter database  add logfile  THREAD 2, group 21, & # 39;/flash/oradata/jydb5 redo21.log& # 39;, SIZE 2147483648; alter database  add logfile  THREAD 2, group 22, & # 39;/flash/oradata/jydb5 redo22.log& # 39;, SIZE 2147483648; alter database  add logfile  THREAD 2, group 23, & # 39;/flash/oradata/jydb5 redo23.log& # 39;, SIZE 2147483648; alter database  add logfile  THREAD 2, group 24, & # 39;/flash/oradata/jydb5 redo24.log& # 39;, SIZE 2147483648; alter database  add logfile  THREAD 2, group 25, & # 39;/flash/oradata/jydb5 redo25.log& # 39;, SIZE 2147483648; alter database  add logfile  THREAD 2, group 26, & # 39;/flash/oradata/jydb5 redo26.log& # 39;, SIZE 2147483648; alter database  add logfile  THREAD 2, group 27, & # 39;/flash/oradata/jydb5 redo27.log& # 39;, SIZE 2147483648; null null null null null null null null null null null null null null null null null null null null null null null null null null null null甲骨文数据库部分迁至闪存存储的示例分析