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

众所周知，数据库的运维既是个技术活儿也是个苦差事，不仅要有广阔的知识面，强大的技术能力，主机、存储、网络、操作系统最好样样精通，而且要会写SQL、shell、最好也会Java…同时，还需要拥有超强的耐心、谨慎的态度以及强健的体魄。首先跟大家分享下我在运维过程二个案例1、我的第一个运维工具：ora2008年刚进公司转做专职DBA，发现DBA竟然比以前干程序员还苦逼，通宵施工如家常便饭，而且有大量的重复工作。当时每个dba在共享服务器上都有自己的脚本集，每当应用侧有任何异动DBA们就找到自己的脚本集文件，然后替换条件复制粘贴执行，遇到没找到的就一顿狂敲键盘输SQL。特别是在遇到大故障时，身后便会围着一群人，有各方领导，还有开发商，里外好几层。那可真是令人抓狂，因为做过几年的开发，我便想，为何不做一个shell程序，统一的入口，只要传入参数即可。于是我开发了我的第一款简单的Oracle运维工具，当时脚本集就叫ora。这个工具后来在运维团队不断被完善、扩散。至今该工具还在使用。Ora脚本集的优点：让日常监控、维护操作等标准化。减少出错机会，提高效率。让DBA从容应对故障应急。当然缺点也是明显的，正是有了这个工具，现在很多DBA们到了非驻场的服务现场就不会写SQL了。（怪我喽…）2、智能HANG分析在运维期间碰到系统常发生HANG，当数据库发生在争夺内核级别的资源时，比如Latch等，在11G之前oracle不能自动的检测并处理这种死锁。这时候需用Hanganalyze工具dump资源持有的相互关系。而这时候当二线DBA到场时已基本Hang死，或无法登陆，即使能做出dump trace也无法反映真实原因。另外分析trace定位堵塞源也要一定时间。所以分析出结果时往往应用已中断。既然hang住后要重启或终止掉所有前台发起数据库进程才能解决，何不在hang开始初期就发起自动hang分析，识别引起hang的源头，记录相关信息，终止源头。具体过程如下：1．通过等待事件识别Hang症状2．根据上一步骤判断触发搜集hanganalyze 3. 分析hang的dump信息，并确认是否存在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= number。 HM检测hang的时间间隔，默认值为30（秒）。小结后面只要碰到能重复的、具有一定规则的工程，如长事务分析、二阶段事务（DX锁）分析、自动生命周期管理、自动优化调度、巡检工具、离线巡检工具等等。如果你能把你日常需要做的工具化或自动化了，DBA还是苦差活么?那么就有更多时间研究更深层次技术。我只是一个不安分的、会写程序的、“会偷懒”的DBA。二、OraZ之路至此越来越想做一个较为完整能帮助DBA的工具，该工具将运行SQL查询视图监控数据库的性能，识别数据库存在隐患。在数据库的运维工作包括部署安装、性能优化、备份容灾、故障恢复、预防性巡检等工作，而这几个方面都存在不少重复度高、工作量大的任务，有的甚至还可以并行处理，这些都是该工具需解决目标。1、运行需求?Oraz是基于JDBC+SSH的JAVA应用，监测和分析数据库实例活动，系统要求是相当简单，只需jdbc能连接上数据库即可，该工具不会安装任何额外软件在你的服务器和终端上。2、Oraz目前能做什么有关数据库和实例的一般信息。有关数据库结构和数据存储的详细信息: 表空间，数据库文件重做日志、 归档的日志等。表空间/数据文件使用情况和可用空间内存信息: SGA/PGA 组件和大小，共享的池和缓冲区缓存统计数据。实例活动洞察-CPU消耗、 等待事件、 顶级的会话、 顶级SQL语句等。会话信息-活动会话，排在前面的会话等。顶级的 SQL 语句和有关每个语句包括语句活动、 执行统计信息、 资源消耗、 执行计划、 版本等详细的信息。Oracle 数据库全系统统计信息、 操作系统统计、 指标和时间模型。3、DBA日常运维之巡检规避系统风险运维自动化体系形成之前，我们DBA的日常例行工作在总工作量中占比较高，很消耗人力，员工疲于奔命但工作效率不高，也很容易出差错。自动化平台把我们的员工从繁琐的常规工作中解放出来，更专注于做架构优化类有创造性的工作，效率