对于Oracle运维中的那些事儿，我的最终目的：不是比谁更惨，而是能够从中吸取经验和教训。
从我的理解来看，我会从下面的几个方面来进行说明DBA运维中的一些事儿。
每个部分都是非常关键的，缺一不可，而且每一部分都有很多的东西可以细化，我会逐一展开来说。
首先来说说环境篇。
DBA的角色及分工
对于DBA的分工，以前的公司对于DBA角色划分粒度还是很细的。
大体是按照核心和客户化定制层来划分的，核心层主要负责产品化，客户化层面主要负责定制。属于不同的产品线但又彼此紧密关联。
Physical DBA更多负责环境部署，搭建和数据恢复，补丁升级等，对于系统，存储网络等更为拿手。
Performance DBA一般都是从各个产品线逐渐衍生出来的高手，对于产品理解很深，当然工作重点是在性能调优上。一般都是产品级的优化，全球所有项目都会通用。
Dev DBA也有一个团队，负责运维产品的开发，其实内部的很多自动化的工具都是他们做出来的，当然开发功底要求也很了得。
Delivery DBA主要负责数据交付，一般的UT,UAT,PROD的数据交付，有的时候涉及的环境成百套，对于这些数据的交付管理非常重要，补丁管理，数据变更的基线管理，数据的同步，复制，业务环境搭建都会涉及。
Application DBA 主要和业务相关，一般和开发的联系较为紧密，一线的数据支持，对于系统的架构，业务情况要很熟悉。
最后是site DBA，所有产品，业务的事情都要考虑，最终的方案和实施落地。
然后来说说行业环境，以我为例，我也是从传统行业到了互联网行业，当然也需要作出一些改变。
从角色上是从乙方到甲方，很多的事情都需要考虑，对于技术方案和硬件选型，不仅仅是纯技术上的考量，需要更多的因素。这是一个全面的过程。
当然和传统行业来比，传统行业更为保守，稳定压倒一切。
以之前的电信客户为例，测试情况极为苛刻，UAT测试做了差不多一年。
对于产品和数据库的版本搭配，公司也有严格的认证制度，哪个产品适用的数据库子版本（比如11.2.0.2.x）都有要求，因为这些是实实在在做足了测试。
很多客户对于RAC的使用也是保守的active/passive方式，当然自11g的ADG之后，也在默默的开始替换BCV的方式。
从数据库的角度来看，为了保守，很多特性都会禁用。
禁用直方图
产品化极为彻底，很少有创建索引优化sql的场景
禁用回收站
禁用skip scan
……
监控篇中和大家说说一下几个方面。一个是监控工具。
一般的选择都会是商业或者开源，或者两者兼有。
两者没有严格的优劣之分，这是一种平衡和理性的选择过程。
Gc,em12c本身原生支持Oracle,还可以扩展支持其它的数据库，系统层面也做得不错。管理功能非常强大。
而在开源领域，zabbix负责系统级，搭配插件orabbix监控数据库实例，其实也不错。
再说说监控盲点，对于下面的语句：
select ‘Oracle is alive’ from dual; 如果监控实例是否open，是否合理？
其实dual表比较特殊，在nomount,mount,open阶段都可以访问。严格来说是不太合理的。
11g中备库的v$flash_recovery_area_usage的自动归档删除策略
11g备库在mount阶段，比较浪费。
1、Asm使用空间的监控
硬件监控
当然还有很多，就不展开了。我想多说说硬件监控的重要性。
这是一个故障类型的占比图。
可以看到硬件故障出现的概率还是非常大的。其实在很多的故障中都是一个很头疼的问题，对于硬件故障来说，主板故障，内存故障又占有很高的比例。
这是故障影响累计时长的占比图：
这里有几个地方需要说明一下。
可以看到硬件故障遥遥领先，这个4500分钟是一个累计的值，不是一次故障的影响时间，比如有1000台机器，一台机器影响1分钟，1000台就是1000分钟。
这是积累了好几年的一个数值，所以会把这个影响放大。
2、硬件故障的反思
监控维度要全
监控粒度要细
不能等待问题降临，要直面迎击
100多台服务器，硬件巡检12台有磁盘坏块
没有条件，不能坐以待毙，要敢于DIY
DB time抖动的分析，后面会讲到
做历史问题，遗留问题的终结者
我举一个例子来说明一下监控的重要性，可能对于备库的监控也是个盲点。
这是一台备库的CPU使用情况，蓝色的部分表示使用情况，在平时负载是很高的。
当然深入分析之后，发现有一些查询只在备库上运行，在做大量的全表扫描，分析之后发现问题其实完全可以避免，创建一个相应的索引即可修复。
修复后的情况如下，可以看到CPU使用率几乎触底。
3、运维管理
运维管理的内容很多，我说说日常维护和一些细节问题。
（1）日常维护
使用空格的技巧：这是学到的一种专业态度，对于不熟悉，不确定的环境，黑屏时先敲一下空格，敲了回车很可能会有致命问题。
空格的惨案：这个惨案也是听来的，如果使用下面的命令 ifconfig –a6 vs ifconfig –a 6 就因为一个空格就会造成网络地址瞬间修改，如果是rac,节点瞬间就会倒下。
简单至极的维护案例：system表空间满，如果发现表空间满的情况，不要急于添加数据文件，倒底是应用不规范存放数据到了system表空间还是审计日志占用了大量空间，可以参考MOS得到一些专业指导，在有些版本直接清理审计日志可能会有死锁。
（2）不可忽略的细节
既然说到这么细了，我再多提几个。
外部表使用exp会有奇怪的问题，还是要用expdp来做。
安装数据库软件时silent模式下的参数在10g和11g中竟然有一个细小的差别。
responsefile,responseFile你看出来了吗？
合理利用新特性
使用sql_monitor，竟然发现一条运行14天的sql语句，当然其它方式也可以做到。
少踩一些坑
drop datafile导致的备库bug，在10.2.0.4以前，主库如果drop datafile，备库的MRP会直接挂掉，这是一个bug,官方解决方案是重建备库，当然我比较任性，其实也可以手工修复。
灵活变通，省事省力
5T数据和1M数据的灵活切换。这个我拿一个小案例来说明，生产环境需要紧急复现一个问题，这个工作通过测试生产环境来完成，但是测试生产环境已经数据有5T，而从生产环境抽取的客户数据只有1M。
直接导入1M的数据，很可能因为逐渐冲突而导入失败。这个时候就可以使用闪回数据库来实现。可以做到5T和1M数据的灵活切换。
说到优化。
不定时的性能炸弹sqlprofile：sqlprofile是一个临时方案。有一个sqlprofile调优的语句在一年后发生了严重的性能问题，原因就在于里面的数据情况发生了很大变化，导致原油的执行计划资源消耗太大。
临时提交的变更4个小时的pl/sql和1分钟的sql：之前有同事在升级前紧急提交一个pl/sql脚本是作为数据插入，但是测试不够充分，结果在生产执行了近4个小时，当然问题期间，我们进行了优化，其实改造成一条sql语句，insert xxxx select xxxx from xx where 一分钟就可以搞定。
sqlldr加载性能问题的分析：有一个sqlldr加载的性能问题诊断，在各方掐架的情况下，我默默使用scp传送一个文件，证明了其实是网络问题。
优化部分我举一个案例：数据库无法登录的诊断。
某一天收到报警说数据库无法登录,报错信息如下：
报错的原因看起来是audit的问题，其实sysdba登录会自动写audit，当然audit区域空间占用很小。
但是问题时间段的归档频率可以说明问题，横轴是每个小时的切换频率，纵轴是日期：
可以看到归档切换很频繁，想必应用做了调整，但是我还是看了看awr报告分析了一下。发现top1的sql语句是一个update，当然看性能也没有什么大的问题。
语句如下：
下面的报告对比可以说明问题的原因，rows per Exec有很大的差别，其实这个表只有1万条的数据。
所以很容易看出来，这是冗余数据的问题导致了大量的归档。
稍后做了对比测试：
运行3分钟，日志切换14次（存在冗余数据）
运行7分钟，日志切换0次（删除冗余数据）
开发和业务对于数据库运维非常重要，可能这个部分大家都会轻视。
定制awr,ash,addm——
这些工具其实可以简单定制，会极大提高工作效率。
熟练掌握开发技能——
数据库连接满的原因分析：之前分析的一个数据库连接满的问题，还是在查看开发源代码后发现jdbc没有正确释放连接导致，当然还是比较隐蔽的一个小问题。
熟练掌握业务——
通过业务优化sql：通过业务来优化sql其实还是非常中肯的一种方式，改进幅度最大，把技术需求转化为业务需求。
我来举一个分区规则，业务和技术的脱钩的例子，可能看起来比较绕，大家耐心看一下。
之前做数据迁移的时候，有一个分区表特别慢，最后发现分区元数据如下：
所以说分区规则可能存在问题。发现分区规则是多键值的情况。
我们来看看分区规则的元数据情况，似乎和业务需求和吻合的。
那么实际的数据存放情况呢。以p120_c10分区为例。可以看到数据有些乱。
多键值分区需要格外注意，点到为止。
对DBA更高的要求，更高的挑战
开发技能
数据架构
一专多能
新技术前沿
全栈DBA
展望
自动化运维
精细化运维
这个部分看起来比较虚，但是都是我们目前在做的。比如说精细化运维，一个目前的简单的zabbix改进就是db time的监控。其实通过这个可以发现很多的潜在问题。
调优之后的情况如下。
所以大家一起努力，办法总比困难多。有很多人觉得平淡，其实可以再努力一下，坚持一下。借用知乎的一句话。平淡其实是很奢侈的，那意味着有许多爱你的人在为你付出。在DBA+社群，在这里，就是我们可爱的DBA们。
作者介绍 杨建荣
【DBA+社群】联合发起人。
Oracle ACE-A、YEP成员，现就职于搜狐畅游，拥有6年以上的数据库开发和运维经验，曾任amdocs DBA，负责亚太电信运营商的数据业务支持，擅长电信数据业务，数据库迁移和性能调优。
拥有Oracle 10g OCP，OCM，MySQL OCP认证，对shell，ava有一定的功底,曾在2015年数据库大会进行关于数据迁移和升级的主题分享，现在每天仍在孜孜不倦的进行技术分享，每天通过微信，技术博客共享，已连续坚持700多天。
本文来自云栖社区合作伙伴"DBAplus"，原文发布时间：2016-04-01
