数据库的运维分享一切从简.docx
《数据库的运维分享一切从简.docx》由会员分享,可在线阅读,更多相关《数据库的运维分享一切从简.docx(14页珍藏版)》请在冰豆网上搜索。
数据库的运维分享一切从简
众所周知,数据库的运维既是个技术活儿也是个苦差事,不仅要有广阔的知识面,强大的技术能力,主机、存储、网络、操作系统最好样样精通,而且要会写SQL、shell、最好也会Java…同时,还需要拥有超强的耐心、谨慎的态度以及强健的体魄。
首先跟大家分享下我在运维过程二个案例
1、我的第一个运维工具:
ora
2008年刚进公司转做专职DBA,发现DBA竟然比以前干程序员还苦逼,通宵施工如家常便饭,而且有大量的重复工作。
当时每个dba在共享服务器上都有自己的脚本集,每当应用侧有任何异动DBA们就找到自己的脚本集文件,然后替换条件复制粘贴执行,遇到没找到的就一顿狂敲键盘输SQL。
特别是在遇到大故障时,身后便会围着一群人,有各方领导,还有开发商,里外好几层。
那可真是令人抓狂,因为做过几年的开发,我便想,为何不做一个shell程序,统一的入口,只要传入参数即可。
于是我开发了我的第一款简单的Oracle运维工具,当时脚本集就叫ora。
这个工具后来在运维团队不断被完善、扩散。
至今该工具还在使用。
Ora脚本集的优点:
●让日常监控、维护操作等标准化。
●减少出错机会,提高效率。
●让DBA从容应对故障应急。
当然缺点也是明显的,正是有了这个工具,现在很多DBA们到了非驻场的服务现场就不会写SQL了。
(怪我喽…)
2、智能HANG分析
在运维期间碰到系统常发生HANG,当数据库发生在争夺内核级别的资源时,比如Latch等,在11G之前oracle不能自动的检测并处理这种死锁。
这时候需用Hanganalyze工具dump资源持有的相互关系。
而这时候当二线DBA到场时已基本Hang死,或无法登陆,即使能做出dumptrace也无法反映真实原因。
另外分析trace定位堵塞源也要一定时间。
所以分析出结果时往往应用已中断。
既然hang住后要重启或终止掉所有前台发起数据库进程才能解决,何不在hang开始初期就发起自动hang分析,识别引起hang的源头,记录相关信息,终止源头。
具体过程如下:
1.通过等待事件识别Hang症状
2.根据上一步骤判断触发搜集hanganalyze
3.分析hang的dump信息,并确认是否存在hang。
4.识别hang的源头记录相关信息并解决hang问题。
这是我编写的第二个程序(由于该程序已申请了专利,代码在此就不分享了)。
注:
在Oracle11g11.2.0.2版本发布后,在其新特性中才出现了hang管理器(HangManager),
HM配置参数(开启后会根据配置终止实例或进程,请谨慎使用):
_hang_resolution=TRUE或者FALSE。
这个参数用于控制HM是否解决hang。
_hang_resolution_scope=OFF,PORCESS或者INSTANCE。
这个参数用于控制HM解决问题的范围。
_hang_detection=。
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的日常例行工作在总工作量中占比较高,很消耗人力,员工疲于奔命但工作效率不高,也很容易出差错。
自动化平台把我们的员工从繁琐的常规工作中解放出来,更专注于做架构优化类有创造性的工作,效率也有了进一步的改善.
每日检查是工程师上班的第一件事,通过脚本来进行,脚本输出仅提示异常部分,检查内容例如:
数据库检查内容:
数据库/系统是否处于归档模式
数据文件是否有offline或处于备份状态
文件系统使用情况(90%为告警阀值)
alert_SID.log文件是否有错误或告警
备份是否正常
表空间使用情况(90%为告警阀值)
数据库/系统对象的存储参数设置
检查是否有失效的索引
检查是否有无效的对象
检查有无运行失败的JOB
检查回滚段使用情况
数据库/系统用户情况
等,编写对应查询SQL,再通过JDBC访问远程服务器获取该值进行判断,如分析指定用户下是否存在失效主键:
SELECTowner,constraint_name,table_name,status
FROMall_constraints
WHEREowner='&OWNER'ANDstatus='DISABLED'ANDconstraint_type='P';
建立一系列巡检规则,实现如360式的一键体检方式:
上图列出体检结果,黄色需dba关注的,为不匹配预定检查项的,点击对应图标,可以看到具体体检结果。
通过该体检功能可快速检测数据库问题;目前该巡检暂不支持自定义,如需可以考虑建立可分享的自定义巡检项,这视大家的反馈情况而定。
4、实例活动洞察
实例活动洞察分析功能当前已同步发布更新,在很多情况下,当数据库发生性能问题的时候,我们是来不及收集足够的诊断信息,或者收到告警,甚至问题发生的时候DBA根本不在场。
这给我们诊断问题带来很大的困难。
那么在这种情况下,我们是否能在事后收集一些信息来分析问题的原因呢
首先我们看看Oracle重器oem,而TopActivity功能是使用最为频繁的功能点:
对于分析指定时段内的顶级消耗、会话等一目了然。
上图中负载均以AverageActiveSessions(AAS)平均活动会话进行计算。
每一个会话执行过程如下:
而每一个语句在执行过程又可以分解为不同活动时间:
CPU执行中、等待IO或其它资源中,即可分为CPU、IO、Wait
当有多个会话连接到库,并活动时:
通过时间片段来看同一时刻有多少会话处于活动状态,而该值为AAS值,以相同方法以sql语句维度统计该时刻活动,则找出顶级活动SQL,同样可以计算顶级活动program、user、会话等待。
。
由于DBTime=某一时段时间总和,故顶级活动SQL即为TOPSQL,所以
AAS=DBTime/elapsedtime(历时),之所以该指标叫做黄金指标,通过AAS指标可以衡量一个系统的繁忙程度,这里有个CPU时间片概念,每一个CPU时间由操作系统分成CPU时间片,然后CPU时间片轮询模式分配给线程或进程(视操作新系统而定),在最小单位CPU片段内整个系统允许的最大允许数为cpu个数,故通过比较AAS值与CPU之间可以衡量数据库繁忙度,与CPU数量关联分析:
●AAS/CPU_Count~=0非常空闲
●AAS/CPU_Count<=0.5没堵塞
●AAS/CPU_Count<1部分进程已达100%,应用开始出现缓慢
●AAS/CPU_Count>或>>1出现性能问题或堵死、HANG状态
AAS在Oracle中OEM、ASH中的应用:
OEM中:
ASH:
从Oracle数据库10g开始增加V$ACTIVE_SESSION_HISTORY视图,通过它可以容易地得知当前Instance的活动状态,主要是各个时刻系统都在等待哪些事件,通过对这些等待事件和相应等待次数的统计,就可以清晰地了解系统的历史工作负载特征和压力情况。
此视图提供了大量宝贵的信息,而且不需要繁重的跟踪活动
ASH数据采集有mmon进程与mmnl进程负责:
快照由MMON和MMNL后台进程自动地每隔固定时间采样一次。
MMON进程负责:
∙当某个测量值(metrics)超过了预设的限定值(thresholdvalue)后提交警告
∙创建新的 MMON 隶属进程(MMONslaveprocess)来进行快照(snapshot)
∙捕获最近修改过的 SQL 对象的统计信息
MMNL进程负责执行轻量级的且频率较高的后台任务,如捕获会话历史信息,测量值计算等。
AWR的采样工作由MMON进程每个1小时执行一次,ASH信息同样会被采样写出到AWR负载库中。
ASHbuffer根据被设计为保留1小时的信息,但很多时候这个内存是不够的,当ASHbuffer写满后,另外一个后台进程MMNL将会主动将ASH信息写出。
ASHbuffer大小
-按照公式SizeofASHCircularBuffer=Max[Min[#CPUs*2MB,5%ofSharedPoolSize,30MB],1MB]计算,默认1M左右,该参数可以同隐含参数进行调整:
"_ash_size"隐含参数控制ashbuffer的大小
ASH对应视图关系为:
通过按分钟从v$active_session_history视图采集数据,展示如下:
从上图可看到选择时段内TOPSQL为“cvn54b7yz0s8u”,占该时段内的19.5%,主要在等待IO资源。
三、OraZ后续计划开发或扩展功能
∙表空间增加读写走势分析、碎片率分析
∙计划作业执行详细信息和当前正在运行的作业。
∙闪回去/快速恢复区使用情况和备份信息。
∙深度体检
∙进程跟踪(10046、10053)以及trace分析
∙自动化优化分析等
∙Alert日志查询图形化展示
深度体检功能预告
对于数据库、中间件设计,在系统上线前,针对应用系统的主要业务场景,应用要求,对数据库、中间件软硬件配置,系统参数,数据存储进行优化设计,包括但不限于如下内容:
Ø数据库适用应用特点的最佳实践配置
Ø性能及稳定性满足设计需求
Ø系统与数据库特性及设置的最佳匹配
Ø数据库版本对已知BUG的修复
●花5-10分钟发现系统存在的风险
●直接提供来自MOS推荐的专业解决方案
如果你所在部门有如运维自动化、标准化、可视化、一体化(集中化)这些需求建设,可以与邹老师联系,他们有AMP(自动化运维平台)和APM(应用性能管理),即使是已部署了IxM的Txxxx软件的企业依然会再使用他们的产品。
邹德裕
新炬网络首席专家,DBA+社群联合发起人,OraZ产品作者,轻维软件产品架构师。
十年以上运维管理经验,OracleOCM,精通Oracle9i、10g和11g数据库技术和Linux/Unix技术;对数据库系统架构具有深刻的理解,并在数据库诊断、故障排除、优化、架构设计等方面具有丰富的经验。