我打算不再做一个普通的DBA-





首页 产品与服务 解决方案 客户案例 技术支持 合作发展 关于美创 用户退出 合作商登录 用户登录 申请试用

行业解决方案政府解决方案金融解决方案医疗解决方案教育解决方案能源解决方案物流交通解决方案

售后服务文档中心年度培训

渠道政策申请成为合作伙伴渠道专区

公司动态行业资讯安全研究

热门阅读

美创科技打造县域医疗灾备新标杆｜神木市医院 HIS 系统数据库分钟级切换演练实录

2025-07-02

百万罚单警示！DCAS助力金融机构筑牢数据安全防线，实现监管合规

2025-06-20

2025中国互联网产业年会丨《中国互联网产业绿色算力发展倡议》正式发布

2025-02-07

美创用户专访 | 精细化管理：医疗行业数据分类分级的策略与实践

2025-01-10

容灾演练双月报｜美创助力某特大型通信基础设施央企顺利完成多个核心系统异地容灾演练

2025-01-10

连续两年｜美创数据库审计市场份额 TOP5 !

2025-07-23

美创科技建设项目被评为中国信通院医疗领域“磐安”优秀案例

2025-07-18

解读 | 美创深度参编GB/T 20988-2025《网络安全技术信息系统灾难恢复规范》

2025-07-18

权威发布 | 美创数据安全一体化平台DSC市场份额排名前五，领跑专精厂商

2025-07-15

美创专家出席上海市《卫生健康数据分类分级要求》地方标准宣贯会

2025-07-11

我打算不再做一个普通的DBA

发布时间：2017-10-13 阅读次数： 472 次

作为一个有点辈分的DBA，我的日常是

“救火”于危难之中

24小时待命，客户“十万火急”电话分分钟彪过来

定期还要人工现场巡检

自从有了运维云，

我立下“不再做一个普通的DBA”的志愿

我的工作日常变了样儿

比如，某一天早上

手机上收到一条来自运维云的告警短信：某客户M库2节点的内存使用率已经超过90%，1节点也在不断上升中，马上也要达到90%了。

赶紧坐下来打开监控系统，查看M库2个节点的内存使用率监控趋势图，如下：

（图1：1节点的内存使用状况）

（图2：2节点的内存使用状况）

从上面的图形上能够明显的看到，从26日之后，2个节点的内存使用率节节上升。按这个趋势，2节点的内存，用不了几天就会爆掉了。

于是乎，凭借我的超敏感嗅觉，开始逐一原因排查。

原因排查

从数据库的dba_hist_process_mem_summary中查看内存的使用，取问题发生的前一天（25日，snap_id为51946）到今天为止，每天早上8点到9点这个时间段内的内存使用情况:

（图3：1节点的数据库内存使用分布）

（图4：2节点的数据库内存使用分布）

从图3和4中也可以看到，2个节点上，自26日之后，每个类型的内存使用，都在随着process的不断增加而上涨。

对于这个内存问题，第一反应是25日晚上的一次应用系统升级引起的。如果是应用服务的增加，应该是上涨之后稳定下来，而不是持续上升，因此，最可能的原因是某个新上的程序有bug，在持续地新建会话，而不释放老会话。

再次打开运维云监控，查看2个节点上的会话信息：

（图5：1节点会话数趋势图）

（图6：2节点会话数趋势图）

从图5，6中可以看到，2个节点上的会话数都在不断的上涨中，尤其是2节点，从3500左右涨到6000左右，按趋势来看，没有停止的趋势。这也证实了前面的推论，只需找出哪个程序出问题即可。

会话上涨了2500左右，应该能在gv$session里面能查到比较直接的结果。可以使用以下语句查看：

从查询结果中，确实能够找到一个连接数异常高的进程，2个节点上都有连接，2节点尤其高。

再从连接过来的客户端服务器上，查这个serv_SyncVpnMe的程序。

果然，这个程序的启动时间正好是26日凌晨，也就是系统升级那天。到这里，算是揪出了“罪魁祸首”。

发现问题，如何解决，也是DBA的职责所在。

故障解决

找到相关开发人员说明排查结果，协商后停掉该问题程序，数据库的session很快就降了下来，2个节点的内存都立即降到了正常水平。

再次从监控系统中查看会话情况，结果如下：

（图7：2节点异常程序停掉后的会话趋势图）

（图8：2节点异常程序停掉后的内存趋势图）

以一个实际案例，回顾了我的日常。其实，这种问题是我们平常运维中经常会遇到的故障问题之一。

作为一个勤于思考的DBA，我做了进一步推敲：

以往

运维人员手握大量数据库，面对层出不穷的数据库问题，时间和精力难免会分散，不可能时时兼顾每一套数据库，察觉每一个潜在隐患。在没有监控的情况下，按照以往的运维模式，可能得等到数据库连接占满，或者是系统资源耗尽之时，数据库无法提供服务了，运维人员直到接到客户的投诉电话才会意识到出故障了。而往往在这个时候，即便迅速、顺利地处理了故障，仍然已经影响到用户体验，属于严重滞后了。

现在

而实时的监控所有在运系统的运行状况，及时发现问题隐患并产生告警，通过邮件、短信等方式第一时间通知到一线运维人员，运维人员收到信息后及时处理，可以有效避免问题进一步扩大化，是新时期运维的必要手段。

MC运维云，应运而生。美创提倡主动运维服务，7*24 自动巡检，实时监控数据库状态，第一时间发出告警。MC运维工程师利用运维云监控，提早发现隐患问题，在问题扩大化之前及时主动的解决问题，保障客户数据库的稳定运行。

不会打广告的DBA不是好写手，冷不丁的打了一个小广告。哈哈。

上一条：勒索软件调查报告 | 2016年到2017年，勒索软件市场增长了2502%
下一条：@所有人数据库性能优化实践指南看这里