求助：在Oracle10g中如何应对超级大表、海量存储75T的部署需求？

十一月雨

各位好！
由于最近有一个项目，其数据库系统的信息如下：
一、数据库系统硬件配置
     【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 编辑 ]

alantany

－－问题：－－
一、如此规模的数据库，硬件配置是否足够
     【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】如何在操作系统层面应该采取哪方面的优化手段，以提高性能。
>>>看应用可能在那些方面造成瓶颈了。

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

microsoft_fly

原帖由 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再把具体应用说得详细点，以前你的配置怎样，跑得如何，量有多大，现有哪些地方有大的改变，我想坛子里或许有人跟你的情况有相似的情况，他们会提供一些宝贵的意见

robincao

关注！

十一月雨

首先感谢一楼的兄弟，给出了一个剖析问题问题的角度，下面我逐一解释或者深入描述一下：
     【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 编辑 ]

zergduan

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

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

十一月雨

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

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

十一月雨

真心和大家探讨，不指望从这里获得精确的解决，就是和大家探讨一下，扩展一下思路，尽可能的地把问题考虑全面了。

关注中...没动过这么大的库

cc59

原帖由 十一月雨 于 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系统．
出了问题会让你很麻烦的．甚至数据都可能很难救出来．
深刻体会，当然．你需要更多的测试，　也许你的应用会适合．．．