查看: 15980|回复: 84

[原创] 求助:在Oracle10g中如何应对超级大表、海量存储75T的部署需求?

[复制链接]
论坛徽章:
1
设计板块每日发贴之星
日期:2007-11-26 01:06:25
发表于 2008-3-15 11:45 | 显示全部楼层 |阅读模式
各位好!
由于最近有一个项目,其数据库系统的信息如下:
一、数据库系统硬件配置
     【1】数据库服务器为双机,128G内存,32颗CPU,CPU为IBM Power6 4.7G或同等级别的CPU。(预计数据库服务器可能会是IBM P590或P595,或者其它厂商提供的同等类型的服务器,例如HP Superdom)
     【2】存储设备尚未确定(可能与IBM DS8000同等或者更高),但是采用的硬盘是15K转速的光纤硬盘且单盘容量小于200G,RAID0+1
     【3】存储交换网络采用4G的光纤交换机(主机的HBA也是4G)

二、数据库运行环境
     【1】数据库版本Oracle10g
     【2】数据库运模式为RAC模式
     【3】RAC通信网络带宽是2G
     【4】数据库对外提供服务的网络带宽是1000M
     【5】数据库整体存储规模在75T以上

三、实际业务情况
     【1】业务量峰值时大约每小时40000笔业务交易(不是40000个数据库transaction)
     【2】数据库总存放的三种数据最大,这三种数据分别被存放在3张表中,其中一张表的初始数据记录数在4亿条以上,另外两张表初始数据记录数都在1000万以上,但是预计在18个月(本系统设计生存周期是40个月)以后将会突破1.2个亿。

--问题:--

一、如此规模的数据库,硬件配置是否足够
     【1】CPU的主频和数量是否足够?
     【2】内存是否足够?
     【3】存储设备的性能是否足够?是否需要选择更加高性能的存储设备?
     【4】SAN网络传输能力是否足够?
     【5】数据库服务器数量是否足够(目前是2台,是否有增加到3台或者4台的必要)?

二、如此规模的数据库,如何规划数据库的部署及细节设计?
     【1】目前数据库计划运行在RAC模式,是否合理?
     【2】对于那些大数据量的表,如何设计其数据库部署属性(例如:设置分区,为每一个分区设置不同的表空间等)?
     【3】如何设置表空间属性?(例如:是否需要将这些大表的表空间指定在磁盘的中心区域)
     【4】对于数据库初始化参数,都有哪些设置建议或者基于这种情况,应该采取哪些参数优化措施,以提供数据库整体性能?
     【5】如何在操作系统层面应该采取哪方面的优化手段,以提高性能。

由于是第一次搞这样规模的数据库系统,而且数据库功力不够深厚,故想在这里和各位探讨请教一下,如果各位有好的想法或建议,请知无不言,言无不尽。

无论怎样,在此感谢各位对本帖的关注与响应,感谢所有花费时间和精力阅读、参与本帖的热心人员。

另外:帖子限制标题的字数不大于80,导致无法对标题进行清晰明确的描述,请各位见谅。

[ 本帖最后由 十一月雨 于 2008-3-18 18:52 编辑 ]
认证徽章
论坛徽章:
139
2009日食纪念
日期:2009-07-22 09:30:00ITPUB8周年纪念徽章
日期:2009-09-27 10:21:21祖国60周年纪念徽章
日期:2009-10-09 08:28:002010年世界杯参赛球队:葡萄牙
日期:2010-01-18 09:23:302010年世界杯参赛球队:意大利
日期:2010-01-21 07:30:192010年世界杯参赛球队:南非
日期:2010-01-22 09:48:242010年世界杯参赛球队:加纳
日期:2010-02-13 16:34:422010新春纪念徽章
日期:2010-03-01 11:04:572010年世界杯参赛球队:斯洛伐克
日期:2010-05-21 11:24:312010年世界杯参赛球队:塞尔维亚
日期:2010-06-30 13:43:14
发表于 2008-3-15 12:14 | 显示全部楼层
--问题:--
一、如此规模的数据库,硬件配置是否足够
     【1】CPU的主频和数量是否足够?
>>>要看业务是I/o密集型还是cpu密集型,--test。
     【2】内存是否足够?
>>>不知道,看应用是如何使用数据的。test。
     【3】存储设备的性能是否足够?是否需要选择更加高性能的存储设备?
>>>看应用的要求,如果数据只是进到数据库里就处于静止状态,那i/o就不是问题,如果有各种各样的查询,如果结果集又可能非常大,这个谁说的清?test。



     【4】SAN网络传输能力是否足够?
>>>看应用了。我们san是2G的,每天入库量1亿条,还可以。
     【5】数据库服务器数量是否足够(目前是2台,是否有增加到3台或者4台的必要)?
>>>test.
二、如此规模的数据库,如何规划数据库的部署及细节设计?
     【1】目前数据库计划运行在RAC模式,是否合理?
>>>取决于应用,感觉oltp并不适用用rac.
     【2】对于那些大数据量的表,如何设计其数据库部署属性(例如:设置分区,为每一个分区设置不同的表空间等)?
>>>无他,分区。物理上为San。
     【3】如何设置表空间属性?(例如:是否需要将这些大表的表空间指定在磁盘的中心区域)
>>>用asm就好了。
     【4】对于数据库初始化参数,都有哪些设置建议或者基于这种情况,应该采取哪些参数优化措施,以提供数据库整体性能?
>>>这个与应用密切相关。最重要的是test.
     【5】如何在操作系统层面应该采取哪方面的优化手段,以提高性能。
>>>看应用可能在那些方面造成瓶颈了。

其实楼主只是描述了一个存储规模,如果剔除性能,存储只是一个存储容量的问题。所以说,应该不是问题。
真正的问题是应用,应用对数据库都需要做哪些操作,这才是最关键的,不了解非常细节的应用的情况,所有的问题都不可能得到答复。

使用道具 举报

回复
论坛徽章:
25
ITPUB新首页上线纪念徽章
日期:2007-10-20 08:38:442010世博会纪念徽章
日期:2010-07-30 12:07:232011新春纪念徽章
日期:2011-02-18 11:43:332010广州亚运会纪念徽章:高尔夫球
日期:2011-04-11 18:22:37蜘蛛蛋
日期:2011-08-17 08:44:40ITPUB十周年纪念徽章
日期:2011-11-01 16:21:15复活蛋
日期:2011-12-15 09:06:552012新春纪念徽章
日期:2012-01-04 11:51:22ITPUB 11周年纪念徽章
日期:2012-10-09 18:06:202013年新春福章
日期:2013-02-25 14:51:24
发表于 2008-3-15 13:18 | 显示全部楼层
原帖由 alantany 于 2008-3-15 12:14 发表
--问题:--
一、如此规模的数据库,硬件配置是否足够
     【1】CPU的主频和数量是否足够?
>>>要看业务是I/o密集型还是cpu密集型,--test。
     【2】内存是否足够?
>>>不知道,看应用是如何使用数据的。test。
     【3】存储设备的性能是否足够?是否需要选择更加高性能的存储设备?
>>>看应用的要求,如果数据只是进到数据库里就处于静止状态,那i/o就不是问题,如果有各种各样的查询,如果结果集又可能非常大,这个谁说的清?test。



     【4】SAN网络传输能力是否足够?
>>>看应用了。我们san是2G的,每天入库量1亿条,还可以。
     【5】数据库服务器数量是否足够(目前是2台,是否有增加到3台或者4台的必要)?
>>>test.
二、如此规模的数据库,如何规划数据库的部署及细节设计?
     【1】目前数据库计划运行在RAC模式,是否合理?
>>>取决于应用,感觉oltp并不适用用rac.
     【2】对于那些大数据量的表,如何设计其数据库部署属性(例如:设置分区,为每一个分区设置不同的表空间等)?
>>>无他,分区。物理上为San。
     【3】如何设置表空间属性?(例如:是否需要将这些大表的表空间指定在磁盘的中心区域)
>>>用asm就好了。
     【4】对于数据库初始化参数,都有哪些设置建议或者基于这种情况,应该采取哪些参数优化措施,以提供数据库整体性能?
>>>这个与应用密切相关。最重要的是test.
     【5】如何在操作系统层面应该采取哪方面的优化手段,以提高性能。
>>>看应用可能在那些方面造成瓶颈了。

其实楼主只是描述了一个存储规模,如果剔除性能,存储只是一个存储容量的问题。所以说,应该不是问题。
真正的问题是应用,应用对数据库都需要做哪些操作,这才是最关键的,不了解非常细节的应用的情况,所有的问题都不可能得到答复。

说得好,最好LZ再把具体应用说得详细点,以前你的配置怎样,跑得如何,量有多大,现有哪些地方有大的改变,我想坛子里或许有人跟你的情况有相似的情况,他们会提供一些宝贵的意见

使用道具 举报

回复
论坛徽章:
31
NBA常规赛纪念章
日期:2008-04-18 19:48:162011新春纪念徽章
日期:2011-02-18 11:43:36ITPUB十周年纪念徽章
日期:2011-11-01 16:21:152012新春纪念徽章
日期:2012-01-04 11:51:22
发表于 2008-3-15 13:31 | 显示全部楼层
关注!

使用道具 举报

回复
论坛徽章:
1
设计板块每日发贴之星
日期:2007-11-26 01:06:25
 楼主| 发表于 2008-3-15 14:04 | 显示全部楼层
首先感谢一楼的兄弟,给出了一个剖析问题问题的角度,下面我逐一解释或者深入描述一下:
     【1】CPU的主频和数量是否足够?
>>>要看业务是I/o密集型还是cpu密集型,--test。
       答复:从目前来看,白天以处理实时交易为主,这些交易对数据库的操作更多的是集中在查询、更新和插入。晚上系统要做大量的批量数据同步工作,包括export和import。

     【2】内存是否足够?
>>>不知道,看应用是如何使用数据的。test。
       答复:这是一个规划阶段,尚未进入实施,无法进行测试,因此在这个阶段只能根据经验和相关的案例比照分析,以给出一个初步的判断。

     【3】存储设备的性能是否足够?是否需要选择更加高性能的存储设备?
>>>看应用的要求,如果数据只是进到数据库里就处于静止状态,那i/o就不是问题,如果有各种各样的查询,如果结果集又可能非常大,这个谁说的清?test。
      答复:由于都是基于基础数据而衍生的各种交易业务,因此这些数据并不是静态的,而是处于被检索和更新的状态,可能会出现结果集较大的情况。当然,结果集有多大,并不能精确给出,毕竟系统没有完全部署呢,,所有的设计和计算都是更加业务需求、系统需求和经验值作为计算的输入值。

     【4】SAN网络传输能力是否足够?
>>>看应用了。我们san是2G的,每天入库量1亿条,还可以。
      答复:对于以处理交易为主要任务的大型系统,个人认为4G的SAN传输带宽是够了,毕竟4G/8 * 50%(网络利用率) = 250M byte /秒 的带宽是一个不小的实际传输速度。

     【5】数据库服务器数量是否足够(目前是2台,是否有增加到3台或者4台的必要)?
>>>test.
      答复:经过简单的TPC-C值计算,基本上在250万的压力,个人判断了一下,以当前服务器硬件配置,单体就可以满足需求,但是还是希望和大家在帖子里探讨一下。当然,TPC-C值实际上是并无太强的实际指导意义,毕竟实际与标准的测试情况不一样啊。

二、如此规模的数据库,如何规划数据库的部署及细节设计?
     【1】目前数据库计划运行在RAC模式,是否合理?
>>>取决于应用,感觉oltp并不适用用rac.
      答复:并没有做个DW,也没有做过大型的OLAP系统,不知道您认为RAC并不适合于OLTP场景是否有相关案例可以比照?毕竟Ora的RAC是一个并发的工作模式,感觉正好是有利于提高OLTP业务吞吐量的啊?

     【2】对于那些大数据量的表,如何设计其数据库部署属性(例如:设置分区,为每一个分区设置不同的表空间等)?
>>>无他,分区。物理上为San。
      答复:我也是这样认为,我也打算把这些超级大表进行partition,但是使用哪种Partition方式,还是个问题。您这边是否有基于经验或者理论方面的建议或者规则?

     【3】如何设置表空间属性?(例如:是否需要将这些大表的表空间指定在磁盘的中心区域)
>>>用asm就好了。
      答复:Oracle是力推asm,asm也的确方便,唯一的缺陷是Oracle数据库的ASM在大型系统中没有对应的应用案例(国内来讲)。

     【4】对于数据库初始化参数,都有哪些设置建议或者基于这种情况,应该采取哪些参数优化措施,以提供数据库整体性能?
>>>这个与应用密切相关。最重要的是test.
      答复:的确是,毕竟这些参数最终的值需要在系统部署完毕后,作完压力测试后进行反复调整和验证的。

     【5】如何在操作系统层面应该采取哪方面的优化手段,以提高性能。
>>>看应用可能在那些方面造成瓶颈了。
       答复:其实这个问题并不是说要讨论出一个精确的优化措施,而是想借助所有人的实际经验和理论知识,得出一些儿应该注意的事项或者需要重点观察的点,包括对于主要OS内核参数的关注点和可能的优化点。

二楼的兄弟希望了解“以前的配置怎样,跑得如何,量有多大,现有哪些地方有大的改变,”相关情况,其实是这样的:这个系统是新建的,以前是一个区域性系统,即每个独立的业务区域有自己的系统,现在是将全国进行了大集中,所有的区域系统全部取消,全部集中到一个系统中,支撑全部区域的业务。因此并没有历史情况可以参考,很痛苦。

[ 本帖最后由 十一月雨 于 2008-3-18 19:48 编辑 ]

使用道具 举报

回复
论坛徽章:
122
现任管理团队成员
日期:2011-05-07 01:45:08
发表于 2008-3-15 14:21 | 显示全部楼层
二、如此规模的数据库,如何规划数据库的部署及细节设计?
     【1】目前数据库计划运行在RAC模式,是否合理?
>>>取决于应用,感觉oltp并不适用用rac.
      答复:并没有做个DW,也没有做过大型的OLAP系统,不知道您认为RAC并不适合于OLTP场景是否有相关案例可以比照?毕竟Ora的RAC是一个并发的工作模式,感觉正好是有利于提高OLTP业务吞吐量的啊?


我们的生产环境就是一个oltp类型,听过oracle人说,不能使用rac,因为再高并发环境中会造成锁等待~

使用道具 举报

回复
论坛徽章:
1
设计板块每日发贴之星
日期:2007-11-26 01:06:25
 楼主| 发表于 2008-3-15 14:35 | 显示全部楼层
我们的生产环境就是一个oltp类型,听过oracle人说,不能使用rac,因为再高并发环境中会造成锁等待~

-----这个解释有道理,我也听一个哥们说过,以前他们用Oracle9i的RAC,最后说由于并发中容易造成锁,于是最后经过4年的运行后,在一次扩容中换成HA了。

使用道具 举报

回复
论坛徽章:
1
设计板块每日发贴之星
日期:2007-11-26 01:06:25
 楼主| 发表于 2008-3-16 13:41 | 显示全部楼层
真心和大家探讨,不指望从这里获得精确的解决,就是和大家探讨一下,扩展一下思路,尽可能的地把问题考虑全面了。

使用道具 举报

回复
linjia828 该用户已被删除
发表于 2008-3-16 17:02 | 显示全部楼层
关注中...没动过这么大的库

使用道具 举报

回复
论坛徽章:
63
19周年集字徽章-19
日期:2020-09-23 02:43:002012新春纪念徽章
日期:2012-02-13 15:12:092012新春纪念徽章
日期:2012-01-04 11:49:54ITPUB十周年纪念徽章
日期:2011-11-01 16:20:28现任管理团队成员
日期:2011-05-07 01:45:082011新春纪念徽章
日期:2011-02-18 11:42:472011新春纪念徽章
日期:2011-01-25 15:42:562011新春纪念徽章
日期:2011-01-25 15:42:332011新春纪念徽章
日期:2011-01-25 15:42:152011新春纪念徽章
日期:2011-01-25 15:41:50
发表于 2008-3-16 19:54 | 显示全部楼层
原帖由 十一月雨 于 2008-3-15 14:04 发表
首先感谢一楼的兄弟,给出了一个剖析问题问题的角度,下面我逐一解释或者深入描述一下:
     【1】CPU的主频和数量是否足够?
>>>要看业务是I/o密集型还是cpu密集型,--test。
       答复:从目前来看,白天以处理实时交易为主,这些交易对数据库的操作更多的是集中在查询、更新和插入。晚上系统要做大量的批量数据同步工作,包括export和import。

     【2】内存是否足够?
>>>不知道,看应用是如何使用数据的。test。
       答复:这是一个规划阶段,尚未进入实施,无法进行测试,因此在这个阶段只能根据经验和相关的案例比照分析,以给出一个初步的判断。

     【3】存储设备的性能是否足够?是否需要选择更加高性能的存储设备?
>>>看应用的要求,如果数据只是进到数据库里就处于静止状态,那i/o就不是问题,如果有各种各样的查询,如果结果集又可能非常大,这个谁说的清?test。
      答复:由于都是基于基础数据而衍生的各种交易业务,因此这些数据并不是静态的,而是处于被检索和更新的状态,可能会出现结果集较大的情况。当然,结果集有多大,并不能精确给出,毕竟系统没有deploy,没有go life,,所有的设计和计算都是更加业务需求、系统需求和经验值作为计算的输入值。

     【4】SAN网络传输能力是否足够?
>>>看应用了。我们san是2G的,每天入库量1亿条,还可以。
      答复:对于以处理交易为主要任务的大型系统,个人认为4G的SAN传输带宽是够了,毕竟4G/8 * 50%(网络利用率) = 250M byte /秒 的带宽是一个不小的实际传输速度。

     【5】数据库服务器数量是否足够(目前是2台,是否有增加到3台或者4台的必要)?
>>>test.
      答复:经过简单的TPC-C值计算,基本上在200万的压力,个人判断了一下,以当前服务器硬件配置,单体就可以满足需求,但是还是希望和大家在帖子里探讨一下。当然,TPC-C值实际上是并无太强的实际指导意义,毕竟实际与标准的测试情况不一样啊。

二、如此规模的数据库,如何规划数据库的部署及细节设计?
     【1】目前数据库计划运行在RAC模式,是否合理?
>>>取决于应用,感觉oltp并不适用用rac.
      答复:并没有做个DW,也没有做过大型的OLAP系统,不知道您认为RAC并不适合于OLTP场景是否有相关案例可以比照?毕竟Ora的RAC是一个并发的工作模式,感觉正好是有利于提高OLTP业务吞吐量的啊?

     【2】对于那些大数据量的表,如何设计其数据库部署属性(例如:设置分区,为每一个分区设置不同的表空间等)?
>>>无他,分区。物理上为San。
      答复:我也是这样认为,我也打算把这些超级大表进行partition,但是使用哪种Partition方式,还是个问题。您这边是否有基于经验或者理论方面的建议或者规则?

     【3】如何设置表空间属性?(例如:是否需要将这些大表的表空间指定在磁盘的中心区域)
>>>用asm就好了。
      答复:Oracle是力推asm,asm也的确方便,唯一的缺陷是Oracle数据库的ASM在大型系统中没有对应的应用案例(国内来讲)。

     【4】对于数据库初始化参数,都有哪些设置建议或者基于这种情况,应该采取哪些参数优化措施,以提供数据库整体性能?
>>>这个与应用密切相关。最重要的是test.
      答复:的确是,毕竟这些参数最终的值需要在系统部署完毕后,作完压力测试后进行反复调整和验证的。

     【5】如何在操作系统层面应该采取哪方面的优化手段,以提高性能。
>>>看应用可能在那些方面造成瓶颈了。
       答复:其实这个问题并不是说要讨论出一个精确的优化措施,而是想借助所有人的实际经验和理论知识,得出一些儿应该注意的事项或者需要重点观察的点,包括对于主要OS内核参数的关注点和可能的优化点。

二楼的兄弟希望了解“以前的配置怎样,跑得如何,量有多大,现有哪些地方有大的改变,”相关情况,其实是这样的:这个系统是新建的,以前是一个区域性系统,即每个独立的业务区域有自己的系统,现在是将全国进行了大集中,所有的区域系统全部取消,全部集中到一个系统中,支撑全部区域的业务。因此并没有历史情况可以参考,很痛苦。


我没看别的,
首先你的系统应该是oltp的高并发系统了.
说实话,我不认为asm很适合你这样的oltp系统.
出了问题会让你很麻烦的.甚至数据都可能很难救出来.
深刻体会,当然.你需要更多的测试, 也许你的应用会适合...

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 
京ICP备09055130号-4  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表