转载

【运维专家大讲堂】云计算和大数据时代,数据库运维工程师发展方向在哪?

本次运维专家大讲堂精选2014年6月份ITPUB的采访,访谈对象是杨志洪,网名boypoo,Oracle ACE成员,现担任上海新炬网络技术有限公司的技术总监。

开场:

一直以来运维工程师的角色被蒙上了各种神秘面纱,平时他们是默默无闻的幕后工作者,很少被人关注。而一旦企业出现技术故障,大家就会立刻呼叫他们,这时候的他们又会像消防员一样迅速灭火,随时要面对应急情况,比如数据库性能优化、数据库备份与恢复、数据迁移以及故障排除等。千万不要认为运维工程师只适合做幕后的事情,他们今后的发展大有前途。今天我们邀请到的嘉宾就是从运维工程师做起,一步步高升到了技术总监的职位,我们一起来看看他的成功秘诀。

下面开始详细的访谈:

pipihappy8888(Q1):您好,非常高兴能够采访到您,作为一名Oracle ACE成员,您觉得这一路走来是否收获颇多?能否和我们网友介绍下自己?

boypoo(A1):大家好,我叫杨志洪,网名boypoo,目前担任上海新炬网络技术有限公司的技术总监。我是ITPUB的早期用户,与ITPUB一起成长,也属于最早一批ITPUB dataguru。从02年毕业到现在,一晃12年的时间过去了,这些年来上帝很眷顾我,总是会给我一些不错的机会.

大学毕业后,我就到了云南电信的下属公司,接触了IBM、HP、SUN的各式小型机、各种操作系统, 各式网络交换机,Oracle从732到Oracle 8174的各个版本…….。就在刚毕业的2年里,这些东西就唾手可得,那个时候还没有实行省集中,我们到各个地市去都是“专家”,这些机器系统都可以随便折腾,现在的同学们很难遇到这样的环境了。

在电信做了2年杂家后,我就一直专注于Oracle的专业服务,一做就是10年.从05年起我开始利用业余时间在上海给ITPUB主讲RAC、性能优化这些课程,也喜欢撰写博客来分享自己的工作经验,除了在ITPUB扎根外,还会雨露均沾,在Loveunix上撰写.不巧有一次Loveunix的博客彻底数据丢失了,我就干脆搞起了自己域名的博客,还做些公开的技术分享,推广Oracle技术的同时也结识了一大批圈子里的高手。

去年,我很荣幸被推荐成为了Oracle ACE的一员,也就是在这一年,我和老熊老耿一起翻译的《Oracle核心技术》中文版也出版了 。这些年来,我们踏踏实实地走好每一步,从做Oracle服务,学习、实践、总结到最后的分享形成了一个完整的闭环,利己利人。

今年我又跟公司申请,跟ITPUB合作,举办“新炬.ITPUB 全国巡回DBA技术沙龙”,目前已经在上海、合肥、南京、福州、成都、武汉六个城市办了六场,对200多名到场的Oracle DBA来说是一场免费的技术大餐,除了上海之外,其他城市几乎没有人办过类似的活动。讲师们因为有这么一个舞台分享做了充分的准备,来听课的朋友们都很积极提问和讨论,整个过程形成正向激励,每一份认真的经历对我来说都是满满的收获。

pipihappy8888(Q2):数据库运维人员就像消防员一样,随时要面对应急情况,比如数据库性能优化、数据库备份与恢复、数据迁移以及故障排除等,您在电信、银行、保险等大型行业有十多年的数据库运维经验,有哪些常见的Oracle数据库故障?能否结合具体的事例,和我们分享下您是如何解决数据库故障等应急情况?

boypoo(A2):因为做的是Oracle服务,所以我也习惯了每天耳边充斥着各种故障的消息.我已经从开始的好奇、担心、兴奋到奇怪,现在已经处变不惊了。Oracle有个故障代码手册的文档,不说全部的,但至少80%的故障代码我都处理过,我还在网上记录分享了大部分Oracle数据库故障的处理。

这次采访我想通过一个小故障来分享自己的处理经验.春节前,一个用户通过我们的客户找到我,反应了故障的情况,一个“重要”的系统Oracle数据库坏了,启动不起来了.我通过远程登录的方式,发现所有的联机日志文件全部都放在一个目录里,奇怪的是这个目录一个文件都没有了。通过history能看到有rm 联机日志文件的命令,但是用户反馈说,这个主机操作系统有一年多没有人登录过了。要搁在10年前,我刚学会_corrupted_rollback_segments、_allow_resetlogs_corruption参数或者bbed、DUL那阵子,肯定兴奋得不得了,也不管数据丢失了,三下五除二把数据库强制拉起来 。但这么多年下来,我觉得这事没那么妖怪,就这么“解决了”的话,一方面不知道真实原因,另一方面还会导致数据丢失和不一致的后果。于是让用户把相关厂商都聚合起来,很快硬件工程师检测发现是闪存卡异常offline了,手工把它online后,消失的文件都回来了,系统好了。相当于我什么都没做,但是一样解决了一个“数据库故障”,只是好像没用到什么高深的技术而已。

对于故障,套用句歌词“三分天注定,七分是人为”来描述其实是很合适的,这个“人为”里分为两个方面,一方面是纯粹的“误操作”,手贱!另一方面是运维没有成体系,单点故障隐患随处可见。在我们的这次“新炬.ITPUB 全国巡回DBA技术沙龙”里,技术专家袁伟翔的演讲主题就是“Oracle故障诊断——黑匣子解密”,这里面包含了我们的故障诊断方法论和故障管理:故障的预警、预案,发生时的升级流程,处理过程的分工,处理完的总结,一整套的故障闭环管理。演讲材料在这里:http://pan.baidu.com/s/1ntE3CBv,在此我就不再赘述了。

pipihappy8888(Q3):随着企业的发展壮大,在线服务器的数量越来越多,软硬件故障发生的概率也变得越来越高。如果没有好的监控系统,主机发生异常,尤其对于企业的核心业务系统,将是不可承受之重。那么我们该如何选择合适的监控方案呢?常用的网络监控工具Cacti、Nagios、Zabbix有哪些优缺点?如何选择适合自己的监控工具?

boypoo(A3):其实关于这个问题,国外的同行是走在前面的。很多年前,IBM TIVOLI、HP OPENVIEW、BMC 出产的都是成型的产品了,不过可惜的是,这些产品都太厚重了,初看起来似乎包罗万象,事实上80%的功能是客户不需要的,而客户需要的另外80%的功能它们又没有。所以到目前为止,没有一款现成监控工具是用户交口称赞的。

这几年,随着互联网行业的兴起,各种开源的监控工具也诞生了,像您说的CACTI,Nagios、Zabbix等等都属于这一类的,它们都属于半成品,这就好比小姑娘的头发任你打扮。这个时候的重点不是你用什么形状什么大小的梳子,而是你知道你要的是什么发型.大的互联网公司由于自身能力非常强,运维工程师对公司的业务可以说是了如指掌,所以总能适时找到最适合自己的监控工具加以改造,成为自己最好用的监控工具。但是传统行业的运维工程师,则由于诸多因素的限制,没办法做到这点。正是因为这样,我们在4年前基于开源软件的基础上开发了我们自己的自动化运维工具(DATAYUN.AMP),不断的迭代用户需求和我们的运维经验,目前在电信运营商和大型行业客户有使用。关于产品不能太吹嘘,要试用的欢迎联系我.

pipihappy8888(Q4):在大数据时代里,随着数据量剧增,并发用户数量的增加,系统常常出现吞吐量的降低,响应时间变长等性能问题,影响数据库系统性能的常见因素有哪些?如何有效地优化Oracle数据库的性能?

boypoo(A4):性能问题从大的方面来说就是吞吐量和响应时间的问题,大多数是由于IO过“慢”导致的。为减轻这个问题的影响,网络方面出现了infiniband交换机,存储方面出现了SSD盘、闪存卡,它们相对比较贵。对现在动辄几十TB,上PB并且还在继续暴增的数据库来说,用起来也没那么容易。对于核心业务数据库来说,通常会建设BCV快照、容灾环境、应急环境、测试环境、开发环境、数据交换中心、备份等“冗余”,成本也非常高。因此,做好数据生命周期管理是优化Oracle数据库性能必须要做,而且收效甚好的一种解决方案。其次,另一个方面的性能问题是锁争用导致的问题,其中包括一些常见原因,比如大表没有分区、分区建选择不合适、没有建索引、没有建合适的索引、SQL代码没有重用、使用或者没有使用绑定变量等等都是这类问题的源头.要解决这个问题,我们需要提早介入产品的开发,在模型设计、代码测试、版本上线前就参与和纠正。

我们的客户相对来说都比较“大型”,动辄上百几百套Oracle数据库,怎样有效优化这些数据库确实是个难题。简单的也可以分为两类,一类是短暂紧急的问题,你不快速搞定它,可能影响面就会迅速扩大,这类难题需要我们迅速判断,到底是新上线的业务导致,还是执行计划变化导致的.通过核心SQL进行管理,这类性能问题非常容易解决。另一类问题相对来讲较为复杂,随着客户业务的增多,新功能越来越复杂,压力也就更明显了.,我们需要从长计议,做好核心系统的容量管理、数据生命周期管理及版本管理,这一类的优化往往需要多个部门达成共识后才能做,但是一旦得到有效执行,效果非常好。至于作为项目型的专题优化,可以参考“新炬.ITPUB 全国巡回DBA技术沙龙”中的其中一个演讲,技术专家杨修国分享的《运营商核心系统优化案例解析》里从方法论、优化工具到案例都做了比较详细的解析。

pipihappy8888(Q5):通常情况下,数据存储在内存缓冲区和磁盘中,访问内存的速度远远快于访问磁盘的速度,因此我们会将频繁访问的数据放入内存中。而各大厂商也纷纷在内存数据库上崭露头角,各种内存新技术层出不穷,您觉得未来内存数据库会和传统数据库共舞,还是会大幅度地冲击传统数据库?

boypoo(A5):为了解决磁盘访问慢的问题,大内存和大闪存基本上是新的硬件选型标准,希望将尽可能多的数据装载到内存或闪存中。相对于盘大的数据量来说,内存还不是足够大。在OLTP型的数据库中,近年来比较火的内存数据库是Timesten,每个数据库通常限额在100G以内,而传统的Oracle数据库可能是几十TB,内存数据库只是作为传统数据库的一个补充而已。而在OLAP方面,SAP有HANA,Oracle 12C也推出了in-memory option,谁胜谁负也还很难定论。这方面我没有太过关注,个人觉得,内存数据库会推动传统数据库进化得更加完美。

pipihappy8888(Q6):对广大的数据库运维工程师而言,十年前和十年后的变化很大,尤其是在云计算与大数据时代,面临着海量数据的高并发带来的各种压力,该如何面对呢?

boypoo(A6):在去年的Oracle技术嘉年华上Jonathan Lewis接受采访时说“如果你想在5年后成为Oracle DBA,你要么就是为很大的公司工作,他们自己为了保护数据的隐密性,而把数据留在自己这里。要么就是为很大的机器工作,500台机器上运行着上百个数据库。小公司里的多数DBA,就不会存在了。”

十年之前,OCP都很少,十年之后的今天,几乎要满大街都是Oracle OCM了。再过十年呢?也许Oracle都不是主流了。但是,围绕着数据的ACID应该是不会的。也就是说,我们做数据库的运维工程师,要更加去学习基础的、核心的东西,关心数据库版本演进过程中新特性的变化,这些变化一方面是基于产品自身的改进,一方面是基于海量数据的需求。时代一直在变,不变的是我们追求新知识新技能的心态。

正文到此结束
Loading...