数据库的运维分享一切从简.docx

1、数据库的运维分享一切从简众所周知，数据库的运维既是个技术活儿也是个苦差事，不仅要有广阔的知识面，强大的技术能力，主机、存储、网络、操作系统最好样样精通，而且要会写SQL、shell、最好也会Java同时，还需要拥有超强的耐心、谨慎的态度以及强健的体魄。首先跟大家分享下我在运维过程二个案例1、我的第一个运维工具：ora2008年刚进公司转做专职DBA，发现DBA竟然比以前干程序员还苦逼，通宵施工如家常便饭，而且有大量的重复工作。当时每个dba在共享服务器上都有自己的脚本集，每当应用侧有任何异动DBA们就找到自己的脚本集文件，然后替换条件复制粘贴执行，遇到没找到的就一顿狂敲键盘输SQL。特别是在遇

2、到大故障时，身后便会围着一群人，有各方领导，还有开发商，里外好几层。那可真是令人抓狂，因为做过几年的开发，我便想，为何不做一个shell程序，统一的入口，只要传入参数即可。于是我开发了我的第一款简单的Oracle运维工具，当时脚本集就叫ora。这个工具后来在运维团队不断被完善、扩散。至今该工具还在使用。Ora脚本集的优点： 让日常监控、维护操作等标准化。 减少出错机会，提高效率。 让DBA从容应对故障应急。当然缺点也是明显的，正是有了这个工具，现在很多DBA们到了非驻场的服务现场就不会写SQL了。（怪我喽）2、智能HANG分析在运维期间碰到系统常发生HANG，当数据库发生在争夺内核级别的资源时

3、，比如Latch等，在11G之前oracle不能自动的检测并处理这种死锁。这时候需用Hanganalyze工具dump资源持有的相互关系。而这时候当二线DBA到场时已基本Hang死，或无法登陆，即使能做出dumptrace也无法反映真实原因。另外分析trace定位堵塞源也要一定时间。所以分析出结果时往往应用已中断。既然hang住后要重启或终止掉所有前台发起数据库进程才能解决，何不在hang开始初期就发起自动hang分析，识别引起hang的源头，记录相关信息，终止源头。具体过程如下：1通过等待事件识别Hang症状2根据上一步骤判断触发搜集hanganalyze 3. 分析hang的dump信息，

4、并确认是否存在hang。4. 识别hang的源头记录相关信息并解决hang问题。这是我编写的第二个程序（由于该程序已申请了专利，代码在此就不分享了）。注：在Oracle 11g 11.2.0.2版本发布后，在其新特性中才出现了hang 管理器(Hang Manager)，HM配置参数（开启后会根据配置终止实例或进程，请谨慎使用）：_hang_resolution=TRUE 或者 FALSE。这个参数用于控制HM是否解决hang。_hang_resolution_scope=OFF,PORCESS或者 INSTANCE。这个参数用于控制HM解决问题的范围。_hang_detection= 。 H

5、M检测hang的时间间隔，默认值为30（秒）。小结后面只要碰到能重复的、具有一定规则的工程，如长事务分析、二阶段事务（DX锁）分析、自动生命周期管理、自动优化调度、巡检工具、离线巡检工具等等。如果你能把你日常需要做的工具化或自动化了，DBA还是苦差活么?那么就有更多时间研究更深层次技术。我只是一个不安分的、会写程序的、“会偷懒”的DBA。二、OraZ之路至此越来越想做一个较为完整能帮助DBA的工具，该工具将运行SQL查询视图监控数据库的性能，识别数据库存在隐患。在数据库的运维工作包括部署安装、性能优化、备份容灾、故障恢复、预防性巡检等工作，而这几个方面都存在不少重复度高、工作量大的任务，有的甚

6、至还可以并行处理，这些都是该工具需解决目标。1、运行需求?Oraz是基于JDBC+SSH的JAVA应用，监测和分析数据库实例活动，系统要求是相当简单，只需jdbc能连接上数据库即可，该工具不会安装任何额外软件在你的服务器和终端上。2、Oraz目前能做什么 有关数据库和实例的一般信息。 有关数据库结构和数据存储的详细信息: 表空间，数据库文件重做日志、 归档的日志等。表空间/数据文件使用情况和可用空间 内存信息: SGA/PGA 组件和大小，共享的池和缓冲区缓存统计数据。 实例活动洞察-CPU消耗、 等待事件、 顶级的会话、 顶级SQL语句等。 会话信息-活动会话，排在前面的会话等。 顶级的 S

7、QL 语句和有关每个语句包括语句活动、 执行统计信息、 资源消耗、 执行计划、 版本等详细的信息。 Oracle 数据库全系统统计信息、 操作系统统计、 指标和时间模型。3、DBA日常运维之巡检规避系统风险运维自动化体系形成之前，我们DBA的日常例行工作在总工作量中占比较高，很消耗人力，员工疲于奔命但工作效率不高，也很容易出差错。自动化平台把我们的员工从繁琐的常规工作中解放出来，更专注于做架构优化类有创造性的工作，效率也有了进一步的改善.每日检查是工程师上班的第一件事，通过脚本来进行，脚本输出仅提示异常部分，检查内容例如：数据库检查内容：数据库/系统是否处于归档模式数据文件是否有offline

8、或处于备份状态文件系统使用情况（90%为告警阀值）alert_SID.log文件是否有错误或告警备份是否正常表空间使用情况（90%为告警阀值）数据库/系统对象的存储参数设置检查是否有失效的索引检查是否有无效的对象检查有无运行失败的JOB检查回滚段使用情况数据库/系统用户情况等，编写对应查询SQL，再通过JDBC访问远程服务器获取该值进行判断，如分析指定用户下是否存在失效主键：SELECT owner, constraint_name, table_name, statusFROM all_constraintsWHERE owner = &OWNER AND status = DISABLED

9、 AND constraint_type = P;建立一系列巡检规则，实现如360式的一键体检方式：上图列出体检结果，黄色需dba关注的，为不匹配预定检查项的，点击对应图标，可以看到具体体检结果。通过该体检功能可快速检测数据库问题；目前该巡检暂不支持自定义，如需可以考虑建立可分享的自定义巡检项，这视大家的反馈情况而定。4、实例活动洞察实例活动洞察分析功能当前已同步发布更新，在很多情况下，当数据库发生性能问题的时候，我们是来不及收集足够的诊断信息，或者收到告警，甚至问题发生的时候DBA根本不在场。这给我们诊断问题带来很大的困难。那么在这种情况下，我们是否能在事后收集一些信息来分析问题的原因呢首先

10、我们看看Oracle重器oem，而Top Activity功能是使用最为频繁的功能点：对于分析指定时段内的顶级消耗、会话等一目了然。上图中负载均以Average Active Sessions（AAS）平均活动会话进行计算。每一个会话执行过程如下：而每一个语句在执行过程又可以分解为不同活动时间:CPU执行中、等待IO或其它资源中，即可分为CPU、IO、Wait当有多个会话连接到库，并活动时：通过时间片段来看同一时刻有多少会话处于活动状态，而该值为AAS值，以相同方法以sql语句维度统计该时刻活动，则找出顶级活动SQL，同样可以计算顶级活动program、user、会话等待。由于DBTime=某

11、一时段时间总和，故顶级活动SQL即为TOPSQL，所以AAS=DB Time / elapsed time (历时)，之所以该指标叫做黄金指标，通过AAS指标可以衡量一个系统的繁忙程度，这里有个CPU时间片概念，每一个CPU时间由操作系统分成CPU时间片，然后CPU时间片轮询模式分配给线程或进程（视操作新系统而定），在最小单位CPU片段内整个系统允许的最大允许数为cpu个数，故通过比较AAS值与CPU之间可以衡量数据库繁忙度，与CPU数量关联分析： AAS/CPU_Count= 0 非常空闲 AAS/CPU_Count=0.5没堵塞 AAS /CPU_Count或 1 出现性能问题或堵死、HA

12、NG状态AAS在Oracle中OEM、ASH中的应用：OEM中：ASH：从Oracle 数据库 10g开始增加V$ACTIVE_SESSION_HISTORY视图，通过它可以容易地得知当前Instance的活动状态，主要是各个时刻系统都在等待哪些事件，通过对这些等待事件和相应等待次数的统计，就可以清晰地了解系统的历史工作负载特征和压力情况。此视图提供了大量宝贵的信息，而且不需要繁重的跟踪活动ASH数据采集有mmon进程与mmnl进程负责：快照由MMON和MMNL后台进程自动地每隔固定时间采样一次。MMON进程负责： 当某个测量值（metrics）超过了预设的限定值（threshold valu

13、e）后提交警告 创建新的MMON隶属进程（MMON slave process）来进行快照（snapshot） 捕获最近修改过的SQL对象的统计信息MMNL进程负责执行轻量级的且频率较高的后台任务，如捕获会话历史信息，测量值计算等。AWR的采样工作由MMON进程每个1小时执行一次，ASH信息同样会被采样写出到AWR负载库中。ASH buffer根据被设计为保留1小时的信息，但很多时候这个内存是不够的，当ASH buffer写满后，另外一个后台进程MMNL将会主动将ASH信息写出。ASH buffer大小-按照公式Size of ASH Circular Buffer = Max Min #CP

14、Us * 2 MB, 5% of Shared Pool Size, 30MB , 1MB 计算，默认1M左右，该参数可以同隐含参数进行调整：_ash_size隐含参数控制ash buffer的大小ASH对应视图关系为：通过按分钟从v$active_session_history视图采集数据，展示如下：从上图可看到选择时段内TOPSQL为“cvn54b7yz0s8u”，占该时段内的19.5%，主要在等待IO资源。三、OraZ后续计划开发或扩展功能 表空间增加读写走势分析、碎片率分析 计划作业执行详细信息和当前正在运行的作业。 闪回去/快速恢复区使用情况和备份信息。 深度体检 进程跟踪（1004

15、6、10053）以及trace分析 自动化优化分析等 Alert日志查询图形化展示深度体检功能预告对于数据库、中间件设计，在系统上线前，针对应用系统的主要业务场景，应用要求，对数据库、中间件软硬件配置，系统参数，数据存储进行优化设计，包括但不限于如下内容： 数据库适用应用特点的最佳实践配置 性能及稳定性满足设计需求 系统与数据库特性及设置的最佳匹配 数据库版本对已知BUG的修复 花5-10分钟发现系统存在的风险 直接提供来自MOS推荐的专业解决方案如果你所在部门有如运维自动化、标准化、可视化、一体化（集中化）这些需求建设，可以与邹老师联系，他们有AMP（自动化运维平台）和APM（应用性能管理），即使是已部署了IxM的Txxxx软件的企业依然会再使用他们的产品。邹德裕新炬网络首席专家，DBA+社群联合发起人，OraZ产品作者，轻维软件产品架构师。十年以上运维管理经验，Oracle OCM，精通Oracle9i、10g和11g数据库技术和Linux/Unix技术；对数据库系统架构具有深刻的理解，并在数据库诊断、故障排除、优化、架构设计等方面具有丰富的经验。