Chapter3.pdf
免费下载
O
O
r
r
a
a
c
c
l
l
e
e
D
D
B
B
A
A
2
2
Chapter 3：电商运营商 DBA 工作手记
题记：本来没有打算写一份这样的东西，但是，Eygle 多次向我约稿，也一直告诉
我说，写一点吧，写出来在运营商那里做运维的经验和教训，对其他人也是非常
宝贵的参考。想想也是，对很多 DBA 来说，三年的驻场运维，确实是很难得的机
会，于是，就写成了这一篇，算是给 eygle 交差吧。
作者简介
分享不停歇，2017，云和恩墨伴你同行
数据驱动，成就未来，云和恩墨，成就所托。
书名书名书名书名书名书名书名书名书名书名书名书名书名书名
·2·
一、 运营商数据库特点
一提到运营商的数据库，我相信很多人第一时间想到的，就是大。我认为这个大包括两
个方面的概念，一个是数据量大，电信运营商的数据，可以说，在国内同等级别的单位，例如
地市级别，或者是省的级别，其数据量远远大于银行，证卷，电力，交通以及其他政府机关的
数据库；另外一个大，就是系统压力大，主要表现在数据库的连接数的多（Active 的链接也非
常之多），并且 SQL 的执行频度也是非常的高。
就我三年全省集中运营商核心 BOSS 系统的运维经验来看，其核心 OLTP 系统的数据量，
在 TB 级别是很正常，而其计费系统的数据量，就直接达到几十 TB 的级别；而其系统压力大，
就更明显，一套 RAC 系统，一个节点的连接数在 5000 以上是非常正常的，每天每个节点执
行上亿条 SQL。
运营商数据库另外一个显著的特点，就是对于系统的高可用性要求非常之高，高到什么
程度呢？可以这么说，交通，税务，等等系统，半夜 3 点暂停个 1 小时，根本不算个什么事；
而对于运营商系统则完全不同。我还记得我刚开始维护运营商的数据库的时候，收到的第一个
需要我进行分析的问题，是一个 CALLCENTER 的系统，这个系统每天的凌晨 4 点，会发生 5
分钟左右的 hang，导致 CALLCENTER 在这个时候业务处理终止，因此就跨部门请求资源分
析，就为了这 5 分钟，我们安排了值班人员，在凌晨 3：30 起床，盯着系统，看看系统到底发
生了什么，记录所有的系统状况，并分析这个问题（这个案例会在后续部分描述）。要知道，
对于运营商来说，CALLCENTER 并不是其最为核心的业务系统，在系统分级的概念上，
CALLCENTER 并不能占据最为关键的核心系统的地位，由此可见运营商对高可用性要求之一
斑。
当然，运营商对系统高可用的要求是有其业务原因的，并非有意为难运维工程师或者
ORACLE 厂商。按照内部的一般准则，运营商级别的系统，停机一小时，其损失大致相当于
人民币 72 万，由此也可以知道，运营商级别的系统，为很么需要如此高的高可用要求。
正是基于如此之环境，对于运维工程师来说，必然带来巨大的工作压力，当然，这种压
力，和工地上搬砖头干苦力是完全不一样的，这种压力更多的来自于心理压力。在运维运营商
的系统之前，我是一个睡眠很好的人，每天晚上挨着床，我就睡着了；维护运营商的系统以后，
我发展到晚上将手机短信调整为震动，就震动一下，然后手机放到被子上，这种情况下，我都
能被惊醒。在值班的日子里，如果晚上没收到电话，早上醒来第一感觉，是不是漏接了电话，
是不是睡的太沉，是不是监控系统发生了问题，可以说，已经神经质了。
在值班的时候，我们的要求，是你不管干什么都要带上手机，而且，只要是有电话，必
须在最多三次内接电话，否则，一个是电话会自动升级到你的主管那里，另外一个，如果由于
你没接电话，引起了故障，那么这次故障就算你的了。在运气最不好的一个晚上，我每隔 30
分钟左右接一个电话，那感觉，刚要睡，就有电话，一个晚上在半睡半醒之间折腾，当然，也
有运气好的时候，一个晚上没电话，那就早上醒来的时候担心了。时间长了以后，你的睡眠就
被摧毁了，到现在，已经离开运营商的数据库 2 个多月了，似乎睡眠还没有恢复过来（工作时
似乎运气好的时候比运气差的时候要少很多）。不论在任何时候，作为一个运营商的运维 DBA，
接到告警后的第一反应，是终止任何事情，启动处理流程。
of 23
免费下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
评论