<kbd id='woaibaidu'></kbd><address id='woaibaidu'><style id='woaibaidu'></style></address><button id='woaibaidu'></button>

          当前位置:主页 > 数据库 > 数据库其它 >
            你的Oracle数据库还要运行在VMware上?
            2018-04-16 10:28 发布 次浏览

          因为Oracle做得实在比其他数据库要好,几乎所有平台上几乎都可以运行,就跟再蹩脚的SQL几乎都可以运行一样。因此越来越多的程序员加入了搞坏数据库的行列,越来越多系统集成的人照着“极客”们的实验文档把Oracle数据库安装到Oracle官方不支持的平台上。

          那么,在VMware上运行的生产Oracle数据库,迁移的目标在哪里呢?

          那么,有多少人在生产上用VMware呢,在DBAplus社群的一个微信群做了个小调查。

          最后,我们在这里做个小调查:

          但是,这就是Oracle。你买Oracle高级服务时,如果你注意过服务条款,就会发现Oracle售后是不承诺解决问题的,Oracle是不解决跟Oracle相关的非Oracle问题的。所以你在MOS上提SR,很可能它要你提供相关日志文件,问题指向网络或者主机或者非Oracle后,它就是要你关闭问题请求了。甭管咱乐意不乐意,就是这么个情况。但是好的Oracle服务工程师,还是会尽心尽责帮你解决问题,条款是条款,人是人,这是另一个问题。

          MVP专栏

          我们讲IT基础架构,跟CAP理论类似,也是在高效、稳定、安全三条核心要求中做平衡。要安全,效率可能就没那么高,IT投入可能也就要多一些。前期架构不多考虑考虑,在运维阶段再调整往往就很难,甚至无能为力了。

          上云后,需要考虑资源隔离的问题:

          Oracle这招其实挺讨厌的。不认证你就事先让人家不可以装上去,人家都跑了好多年,出了问题却说没有认证的平台,所以不给予支持(虽然没有认证的文档发布了好多年,但很少有人上MOS去专门搜索验证,何况很多人没有MOS权限呢)。这搁谁都挺不舒服的吧?

          幸运的是,这些系统可能已经运行了3年甚至5年或者更多时间,一直“很稳定”,没出现过问题。

          你的Oracle数据库还要运行在VMware上?

          另一方面,就是几乎所有的“平台”上,只要能安装上相应的操作系统,就能安装上Oracle数据库。操作系统从早年的Tru64、SCO Unix、RedHat、Suse、AIX、Solaris、HPUX到后面centos等各种Linux的变种、平台从VMware到Openstack到Docker……甚至一度还有“极客”专门尝新,去官方未认可上的平台上玩Oracle。

          DBA,在我眼中一个只会说no的职业。建表:不行,不规范。加字段:不行,英语拼写语义不明。多表查询:不行,去优化SQL。存储图片:不行,去存硬盘。等等等,数不胜数的no。有时候在想,DBA是上帝派来消灭我们的吗?时光如梭,随着我们项目的逐渐扩展,我去,又有bug,怎么数据库就不宕呢。如今不得不佩服敌人的狡诈与严格。

          内存资源隔离。控制好数据库的SGA和PGA即可。

          IO资源隔离。这方面没有太好的方法,需要在上云分配的时候做好监控,并给予分配。

          回到VMware的问题,会涉及很多底层分析,可能要后台GCS实验室甚至是研发介入,所以售后往往无能为力。记得前些年,一个HPUX+Oracle RAC+ Storage Foundation+EMC存储的环境,接近10TB的核心生产库,主库发生大量的坏块,底层同步的备库也发现一些坏块。四个原厂,国内国外一线二线三线投入了几十个人,在专门的问题故障室搞了一个月,最后才揪出真凶。

          显然,用的人还是有的。

          CPU资源隔离。Oracle从11g开始推出的新功能,实例囚笼(Instance Caging)用于解决该问题。由两个可以在线修改的初始化参数cpu_count和resource_manager_plan启用。

          一般来说,在VMware上运行的单个数据库应该都不太大,大部分应该在500GB以内(调查结果可能会出乎意料哦),也就是我们通常说的小库。对于这类数据库,单独运行在一个物理机上,确实是有些浪费。那么建议建设私有云数据库,将这些小库统统装进去。嗯,热门点的词语叫DBaaS,一个标准化的、可弹性扩展的、基于网络访问的共享数据库服务。

          你的Oracle数据库还要运行在VMware上?

          不幸的是,最近有用户开始遇到点问题,数据库“坏块”。虽然问题解决了,但是Oracle不支持进一步的故障分析。原因是VMware上运行Oracle数据库,Oracle官方是不支持的。

          当然,有些系统可能不适合上云,那就是应该分配单独的物理机,甚至是物理机集群来运行。

          精选专题(官网:dbaplus.cn)

          Oracle推出了PDB的概念,而且已经发布了相对稳定的12cR2,基本可以放心大胆去使用了(当然,正式上线前需要做好相关业务的功能和性能测试验证)。

          丨丨丨

          Oracle是一个伟大的数据库产品,普适性极好,一方面是几乎多烂的程序员写的烂SQL在上面都能运行,而且在业务规模不是很大的时候几乎没有什么性能问题,这样也就造成了DBA和开发同学的代沟。记得之前社群策划的一期专题中,一位开发同学很风趣地写道:

          当初为什么会在生产上使用VMware来运行Oracle数据库,可能已经不可考证。一种常见的说法是,因为是虚拟机,所以克隆起来非常方便(特别是单机的情况),都不需要每次新安装。还有一种是,觉得现在的PC Server的性能非常好,很多数据库运行在单一的PC Server上感觉浪费,用VMware分割成多个Guest OS,然后再运行数据库,有效利用资源,降低IT投入总成本。

          近期热文

          你的Oracle数据库还要运行在VMware上?