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