Tag Archives: ODA

ODA之测试体验

Posted on 2012/09/02 by yangtingkun

测试了将近一周的ODA，关于ODA的技术文章也写了几篇，简单总结一下使用ODA的一点心得。 以前接触的一体机并不多，EXADATA虽然有过几次接触，但是与这次可以全方位的测试ODA相比就完全不值得一提了。 总的来说ODA给我的最大感触就是简便：把ODA插上电源和网线之后，唯一需要的配置就是通过ILOM配置一下ODA的网络，只需要把安装程序上传到服务器，通过ODA提供的命令进行解压，然后就是一键式安装。整个安装过程在一个小时左右。加上配置网络和上传软件的时间，整个RAC环境的部署也不会超过半天。而一般情况下，安装一套RAC，即使是熟手也没有十足把握在一天之内搞定，毕竟网络配置、存储设置、系统包的缺失甚至是BUG都可能会导致RAC环境的总体安装时间延迟，而ODA则完全避免了上面的问题。 此外无论是一键式卸载还是一键式升级，都已经将DBA烦琐的工作简化到了极致，在加上ILOM实现的无人值守功能，更是将ODA的简单、方便的特点发挥的淋漓尽致。 ODA的性能虽然不可能像EXADATA那样把执行效率以数量级的方式提高，但是无论是ORION还是SWINGBENCH的测试来看，ODA对于大部分中小型应用应该是足够支撑的。 说了半天的优点，最后说一下ODA的不足之处。首先不灵活性不够，虽然安装配置的简化和配置的灵活性存在一定的冲突，但是这并不妨碍ODA给高级DBA多一些定制的空间。其他的方面到还可以接受，就是ODA的ASM的3重镜像配置这一点是最让人头痛的。对于ODA来说，几乎没有可能改变这一点。除非是不使用ODA的一键式安装，而安全自己安装CLUSTER和RAC，而如此一来，ODA提供的简便性又荡然无存了。此外ODA另外一个致命的缺点，扩展性不足。虽然ODA目前支持外接存储，但是默认的安装配置是不支持将RAC部署到外部存储上的。当然通过将存储添加到ASM磁盘组中应该也可以实现ODA使用外部存储的功能，但是这是ODA策略所不允许的。除了磁盘空间外，CPU、内存资源也都是无法扩展的，更重要的是，ODA没有办法扩展第三个节点，也就是说ODA所能承载的最大压力是固定的。随着业务量的增长和历史数据的增加，ODA没有能力通过添加硬件资源来进行扩展。 因此，个人认为无法扩展是ODA的致命伤，但不是Oracle，因为根据Oracle的定义，总数据量小于3T的使用ODA，而大于3T的则应该使用EXADATA。那么根据这个观点，利用ODA作为EXADATA的热身产品，熟悉一下Oracle的一体机也是一个靠谱的选择。

Posted in ORACLE | Tagged , , , , , , | Leave a comment

ODA性能概述

Posted on 2012/08/31 by yangtingkun

前一段时间对ODA进行了大概一周的测试，简单描述一下性能相关的测试结果。 Oracle的一体机是将软件和硬件结合在一起打包进行出售，那么硬件如何配置势必做过大量的测试之后才确定下来，ODA显然也是精心调测后给出的配置方案。 首先看一下ODA的硬件配置： 包含两个等同配置的节点： 2CPU，6核处理器，每个节点12核处理器； 每个节点96G内存； 每个节点配置2块500G 7200转的SATA硬盘，用来存放操作系统和数据库软件； 共享磁盘部分： 总共20块600G 15000转的SAS硬盘，底层不进行RAID，完全由ASM实现3重镜像，冗余后可用容量4T； 4块73G SAS SSD固态硬盘，用来存储REDO，同样使用ASM实现3重镜像； 网络部分： 提供了两个节点间内部通信的1G网络连接； 对外提供服务的1G网络连接端口； 对外提供服务的10G网络连接端口。 无论是CPU、内存、磁盘数量和容量还是网络连接数量都是配置平衡的，这使得ODA在处理绝大部分工作时都不会碰到明显的性能瓶颈。 经过测试，ODA磁盘的ORION测试结果为： 20块SAS盘只读方式： SIMPLE方式： IOPS=5910 MBPS=1604.98 ADVANCE方式：-run advanced -testname oda_big -size_small 8 -size_large 1024 -type rand -simulate concat -write 0 -duration 10 … Continue reading →

Posted in ORACLE | Tagged , , , , , , , | Leave a comment

ODA中的ILOM组件

Posted on 2012/08/28 by yangtingkun

在ODA中，引入了ILOM固件，使得ODA的方便性和可管理性进一步增强。 Oracle ILOM是Oracle Integrated Lights Out Manager的缩写，最早在EXADATA上引入，随着ODA的诞生，这个功能也引入到了ODA上面。 这个组件提供对外的网络访问接口，可以通过图形化的工具实现两个主机的管理。包括开机、部署节点操作系统、设置网络、关机等一系列的命令。这个组件只要主机的电源接电后自动启用，因此开机、安装系统等一系列以往需要现场人员配合的工作可以很方便的远端完成。如果系统异常DOWN机没有启动后，也不再需要现场有人去专门按POWER进行重启了，显然这个功能使得ODA的方便性和易维护性进一步的提升。

Posted in ORACLE | Tagged , , | Leave a comment

ODA的高可用冗余

Posted on 2012/08/27 by yangtingkun

ODA作为一个一体机，在很多硬件和软件上进行了冗余，避免单点故障对系统的可用性造成影响。 ODA的硬件包括2个Sun Fire X 4370M2，通过RAC或RAC ONE NODE架构实现服务器的冗余； 每个服务器上包含两个冗余热切换的风扇，任何一个风扇异常不会导致系统故障； 服务器包含两组电源，任意一个电源损坏或任意一个电源无法供电都不会对系统造成影响； 每个服务器上集成了10个网络接口，其中两个网络接口用来绑定冗余进行内部连接(PRIVATE IP)，两个网络接口绑定用来提供外部客户端访问（PUBLIC IP），两个10G网络接口绑定对外提供网络访问；另外4个接口绑定为两个网络接口提供访问； 两个服务器上按照了20块600G硬盘和4块73G SSD固体硬盘。这两部分磁盘通过ASM的三种镜像进行保护； 共享磁盘和服务器之间存在2个缓冲芯片，每个芯片单独连接到每个服务器上，从而避免单点问题。 可以看到，通过硬件上对所有的组件进行冗余，避免了单点问题；利用RAC和ASM的特性对服务器和磁盘进行保护，从而彻底避免了单点故障对于系统可用性的影响。 对于ODA的硬件和软件冗余进行了简单的测试： 无论是PRIVATE IP和PUBLIC IP都使用两个网卡进行了绑定，手工关闭任意一个网卡，都不会影响RAC环境的正常运行； 将其中一个电源的插头拔下，ODA运行正常； 由于ASM部署了3重镜像，因此通过DD命令将任意两块盘清0，并没有造成数据库的崩溃，只是从ASM中看到，这两块盘的状态异常。通过简单的ASM磁盘组操作，将这两块盘删除并重新添加到磁盘组中，磁盘组的状态恢复正常。在磁盘的选择上，有一块盘是包含VOTING仲裁盘，整个过程ODA正常运行。 简单总结一下，ODA通过硬件和软件实现了冗余和高可用性，避免了任何一个环境上的单点故障，系统可用性很高。

Posted in ORACLE | Tagged , , , , , , | Leave a comment

ODA环境同一服务器中资源划分（二）

Posted on 2012/08/24 by yangtingkun

简单描述如何实现在同一台服务器上不同的应用之间进行资源划分。 这里介绍资源管理器的方式。 无论是Exadata还是ODA，服务器的配置都越来越强大。因此都存在着把多个应用集中到一起的需求。 对于Exadata而言，一般来说部署的应用数据量大，并发应用高，很少会有多个应用同时部署在一个数据库服务器上的需求，反而经常是需要RAC中的多个节点同时支持某个应用，因此对于Exadata来说，应用资源划分的解决方案是SERVER POOL。 而ODA则和Exadata不同，由于ODA受扩展性，磁盘容量以及配置的限制，因此把多个应用集成到ODA上，那么这些应用多半都是小应用，考虑到ODA只有两个节点组成的RAC，因此对于ODA来说，如何在同一个服务器上给各个应用划分资源，而尽量减少应用之间的相互干扰就是十分有意义的事情了。 除了利用操作系统上的解决方案外，Oracle提供了两种方式的解决方案。一个是通过把多个应用分布到多个数据库中，通过限制每个数据库可以使用的CPU数量实现，即INSTANCE STAGE；另一个是把所有的应用集中到一个数据库，通过数据库的资源管理器实现资源的划分。 如果要使用资源管理器来分配资源，那么需要将所有的应用集中到同一个数据库中，然后根据用户、访问方式以及主机名的不同来设定不同的资源组，并将CPU资源按照一定的比例分配给不同的资源组。 在ODA上使用SWINGBENCH进行压力测试，选择100G的订单环境进行测试，当并发达到6000左右时，ODA两个服务器的CPU基本跑满，前端SWINGBENCH开始出现连接超时的情况，说明当前这种压力已经是服务器所能支持的最大值了。 此时，如果数据库中存在其他的应用，那么这些应用势必会受到压力测试的影响，应用访问的效率必然严重下降。 下面看一个简单的例子，数据库中存在两个用户分布对应两个不同的应用，可以通过下面的方法来给不同的应用分配CPU时间片资源： SQL> BEGIN 2 DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA(); 3 DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA(); 4 DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(CONSUMER_GROUP => ‘SOE_GROUP’,COMMENT => ‘soe first group’); 5 DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(CONSUMER_GROUP => ‘S2_GROUP’, COMMENT => ‘soe2 group’); 6 DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(ATTRIBUTE => DBMS_RESOURCE_MANAGER.ORACLE_USER, VALUE => … Continue reading →

Posted in ORACLE | Tagged , , , , , | Leave a comment

ODA环境同一服务器中资源划分（一）

Posted on 2012/08/23 by yangtingkun

简单描述如何实现在同一台服务器上不同的应用之间进行资源划分。 这里介绍INSTANCE STAGE的方式。 无论是Exadata还是ODA，服务器的配置都越来越强大。因此都存在着把多个应用集中到一起的需求。 对于Exadata而言，一般来说部署的应用数据量大，并发应用高，很少会有多个应用同时部署在一个数据库服务器上的需求，反而经常是需要RAC中的多个节点同时支持某个应用，因此对于Exadata来说，应用资源划分的解决方案是SERVER POOL。 而ODA则和Exadata不同，由于ODA受扩展性，磁盘容量以及配置的限制，因此把多个应用集成到ODA上，那么这些应用多半都是小应用，考虑到ODA只有两个节点组成的RAC，因此对于ODA来说，如何在同一个服务器上给各个应用划分资源，而尽量减少应用之间的相互干扰就是十分有意义的事情了。 除了利用操作系统上的解决方案外，Oracle提供了两种方式的解决方案。一个是通过把多个应用分布到多个数据库中，通过限制每个数据库可以使用的CPU数量实现，即INSTANCE STAGE；另一个是把所有的应用集中到一个数据库，通过数据库的资源管理器实现资源的划分。 对于INSTANCE STAGE其实很简单，就是通过设置初始化参数CPU_COUNT来限制每个数据库可以使用的CPU数量。当然并不是只要设置了CPU_COUNT就可以生效，这个参数生效的一个前提似乎启用了资源管理器。 虽然INSTANCE STAGE也要用资源管理器，但是资源如何划分并不是通过资源管理器中的设置实现的，使用资源管理区是需要Oracle启用资源划分的功能，从而使得CPU_COUNT参数发挥作用。无论是修改CPU_COUNT初始化参数还是开启资源管理区，都是可以动态生效的。 在ODA上使用SWINGBENCH进行压力测试，选择100G的订单环境进行测试，当并发达到6000左右时，ODA两个服务器的CPU基本跑满，前端SWINGBENCH开始出现连接超时的情况，说明当前这种压力已经是服务器所能支持的最大值了。 此时，如果服务器上存在另一数据库，那么连接这个数据库的应用势必会受到压力测试数据库和应用的影响，应用访问的效率必然严重下降。 而如果部署了INSTANCE STAGE，则可以最大程度上避免这个问题。比如在进行压力测试的数据库上设置： SQL> SHOW parameter cpu_count NAME TYPE VALUE ———————————— ———– —————————— cpu_count INTEGER 24 SQL> ALTER system SET cpu_count=8 scope=BOTH; System altered. SQL> SHOW … Continue reading →

Posted in ORACLE | Tagged , , , | Leave a comment

ODA一键式升级

Posted on 2012/08/21 by yangtingkun

ODA另外一个值得称道的方便之处，就是一键式升级。 数据库的升级本身就是比较麻烦的事情，不谈跨大版本的升级，仅仅是PSR的升级也包括很多的步骤，即使是一个PSU的升级，同样也不是一个简单的工作。如果是RAC环境，那么恭喜你，工作量DOUBLE都不止。 那么对于ODA而言，除了RAC架构之外，还有自身的ILON以及管理工具要维护，因此整个环境的升级一定是一个非常烦琐的工作。而ODA的最大目标就是简化工作，因此整个ODA硬件及软件环境这个非常烦琐的操作被简化为几个命令完成。 当前的ODA管理工具oak版本为2.2.0.0.0，包含的数据库版本为11.2.0.3.2，下面的测试将oak升级到2.3.0.0.0，而数据库的版本相应的升级到11.2.0.3.3。 首先需要从MOS上下载补丁文件：p13982331_23000_Linux-x86-64.zip，这个文件打包了所有ODA升级需要的文件。 上传到/tmp目录后，通过unpack选项进行解压： [root@odaenmo1 ~]# cd /opt/oracle/oak/bin [root@odaenmo1 bin]# ./oakcli unpack –package /tmp/p13982331_23000_Linux-x86-64.zip Unpacking takes a while, pls wait…. Successfully unpacked the files TO repository.[root@odaenmo1 ~]# cd /opt/oracle/oak/bin [root@odaenmo1 bin]# ./oakcli unpack –package /tmp/p13982331_23000_Linux-x86-64.zip Unpacking takes a … Continue reading →

Posted in ORACLE | Tagged , , , , , , , , , , | Leave a comment

ODA一键式清除

Posted on 2012/08/10 by yangtingkun

测试了一下ODA的一键式清除，果然是“破坏”比建设更容易，整个操作比本来已经非常简单的ODA安装还要简化得多。 很多DBA都有RAC的安装经验，但是真正进行过RAC环境清除的恐怕并不是很多。虽然Oracle提供了脚本来删除节点或清除RAC环境，但是真正做起来还是有些烦琐的，而且如果不小心，很容易造成部分信息没有彻底清除，从而给RAC的再次安装留下隐患。 而ODA提供的一键式清除功能极大的简化了RAC环境清除的过程，全程只需要执行一个命令，在任意一个节点上执行： # cd /opt/oracle/oak/onecmd # ./cleanupDeploy.pl Please enter the root password FOR performing cleanup: Re-enter root password: About TO clear up OAK deployment,public network connectivity will be lost,root password will be SET TO DEFAULT AND BOTH nodes will … Continue reading →

Posted in ORACLE | Tagged , , , , , | Leave a comment

ODA一键式安装

Posted on 2012/08/09 by yangtingkun

今天测试了一下ODA的一键式安装，果然是方便快捷。 一般而言，即使一个有一定基础的熟手，RAC的搭建过程也要一天的时间，这还是安装过程没有碰到太多问题的情况下，而ODA将整个RAC搭建过程简化到了极致，只要一个对于RAC环境IP地址分配有一定了解的DBA，就可以在2个小时之内把ODA中整个RAC环境包括ASM和数据库完全建立起来。 使用ROOT登录节点，确认图形化工具配置正确，进入/opt/oracle/oak/bin目录执行安装命令： [root@oak1 ~]# cd /opt/oracle/oak/bin [root@oak1 bin]# ./oakcli deploy[root@oak1 ~]# cd /opt/oracle/oak/bin [root@oak1 bin]# ./oakcli deploy 执行这个简单的命令后，会弹出一个窗口，用来输入设置RAC的IP等信息。整个安装过程如果选择复杂的客户定制方式，也只有12个页面，其中第一个是Welcome，最后一个是Complete，也就是说是个步骤就可以完成所有的输入。 第一个有意义的页面是Configuration Type，这里如果输入Typical的话，设置过程会更加简单，但是可定制化太差，建议还是选择Custom方式。这里还可以载入或保存整个安装配置文件，默认的安装配置文件名称是onecommand.params； 随后是System Information，这里输入系统名称、时区、配置数据库的类型以及ROOT用户的密码。其中数据库的类型包括RAC、RAC One Node和单实例企业版； 随后是比较关键的网络配置部分，首先是Generic Network部分，以前ODA必须要求配置DNS服务器，在最新版中ODA增加了一个选项，可以不使用DNS，如果环境中没有DNS服务器，那么这里记得选择No ODA Server available； 接着配置Public Network：主要是输入两个节点的PUBLIC IP、VIP和SCAN IP的名称以及地址，此外还需要输入NETMASK、GATEWAY和INTERFACE。这里还配置ILOM的地址信息，ILOM是ODA设置在两台服务器之外的系统，用来在节点环境清除后，重新安装服务器的操作系统重新设置IP地址等。 在Other Network部分可以直接跳过。 在Database Information部分输入数据库名称、数据库类型、语言、字符集、BLOCKSIZE等设置，其中数据库类型只是选择数据量是Small、Normal、Large和Very Large等几个选项。 ASR … Continue reading →

Posted in ORACLE | Tagged , , | Leave a comment