dpf这个特性我们只在olap环境中搭建过,一般还是要根据分配给该数据库的硬件资源来考虑的。新建系统的架构设计,硬件资源比较充裕些,设计方案也可以比较好看,(^-^),估计集成厂商和ibm原厂商也很喜欢的。734原版资料上面也有相关介绍,实际工作中也可以借鉴下分配原理,切莫照搬。上...
显示全部
dpf这个特性我们只在olap环境中搭建过,一般还是要根据分配给该数据库的硬件资源来考虑的。新建系统的架构设计,硬件资源比较充裕些,设计方案也可以比较好看,(^-^),估计集成厂商和ibm原厂商也很喜欢的。
734原版资料上面也有相关介绍,实际工作中也可以借鉴下分配原理,切莫照搬。
上次看到一个资料,主要就是bcu和bpu的思想,最基本的一个物理cpu一个分区即可,cpu:mem=1:4【内存充裕的话可以更多点】,io设计保证每10块磁盘【lun】有个1G的带宽【我们是两块4g的hba卡,基本不用太愁】,当然可以更高些,这样分区数基本就定下来了。
有条件的话,最好编目分区和数据分区区分开来,鉴于share nothing的架构理念,为各个分区设置单独的日志路径【日志存储设备最好独立于数据存储设备】。缓冲池和表空间设计方面,数据表空间在数据节点均匀分布即可,有些作业控制信息表,维表,等其他可能不需要分区表空间,做成单节点表空间即可。临时表空间基本跟着表空间的页大小和数据节点设计,建议使用文件系统并关闭表空间的文件系统缓存。
由于olap系统的数据量可是很大的,做好hsm的规划。最重要的一点就是这点了,高频访问数据【1年内更新&&特殊数据】,一般访问数据【1-3年】,较少访问的数据【3-5年】,基本5年以上的数据就要转出备份上带。各类数据划分上有点主观,各个行业特征和监管不一样,不必一概而论。
在数据库备份方案选择上,要想省事就说服你的boss做db全备吧,开循环日志。不然也可以选择开启归档日志,启用表空间备份,重要且比较小的表空间全备就行了,数据量比较大的表空间可以增备或者差备,不怎么更新的表空间【却要提供数据服务】定期全备即可。不需要提供数据服务的历史数据,说服你的boss,导出上带吧,节约空间。
说了一堆废话,前不久在p595上的一个lpar上部了个4个节点的查询库【资源够少的:4C,32G,4T】,查询速度不算很理想,4块盘并发读也只在250M/s左右,写大概是在120M/s。峰值咱就不说了,存储管理员叫好多次了。大家请评论下,是否还有提升的空间。
该p595上有6个lpar,分配到该lpar的有2个hba卡,四块存储【10000转*3,1500*1】
收起