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

今天我们邀请到的嘉 宾就是从运维工程师做起，一步步高升到了技术总监的职位，我们一起来看看他的成功秘诀。

大家好，我叫杨志洪，目前担任上海新炬网络技术有限公司的技术总监。我是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来说是一场免费的技术大餐，除了上海之外，其他城市几乎没有人办过类似的活动。讲师们因为有这么一个舞台分享做了充分的准备，来听课的朋友们都很积极提问和讨论，整个过程形成正向激励,每一份认真的经历对我来说都是满满的收获。

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

因为做的是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，在此我就不再赘述了。

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

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

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

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

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

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

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

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

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

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

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