Oracle ACE,《Oracle DBA工作笔记》作者 现就职于国内某互联网公司,擅长数据管理,数据迁移,性能优化,目前专注于开源技术,运维自动化和性能优化。
在前几天搭建好备库之后,因为同步文件着实花了些时间,首先配置备库能够正常接收归档,然后内核参数也基本没有设置,简单使用脚本算出一个Hugepage的值,就直接改了。当时从数据库日志中确实也没有发现hugepage启用的情况,但是因为不是很影响备库的性能,自己就没有重视。
今天在配置一个备库的时候碰到了一些问题,话说配置dg broker真没什么特别需要注意的细节了,本身已经给DBA省了很大的事儿了。 但是有时候就是会出现一些稀奇古怪的小问题。
这几天一台服务器出了硬件问题之后,这台服务器上的两个备库都殉职了,我们真是如坐针毡,毕竟没有了备库感觉就是裸奔,两个库差不多有10T,搭一套备库也是颇有波折。 当服务器到了我手里之后,首先就开始准备安装数据库软件,安装前的基本检查很快做完了,需要预先安装的依赖包我看使用yum源已经识别了,我也标示了yes,然后开始克隆安装。
今天有个同学问我一个问题,也是一个实际的案例,我简单分析了一下,发现还是有很多可以考究的地方。仅做参考。 问题是,系统里目前有一个大表,因为历史数据的沉淀,目前有60多亿的数据,不是分区表,现在得到反馈说insert的操作比较满,想优化一下,同时把部分历史数据需要做一些清理。
在上一篇中写到了 DBA和开发同事的一些代沟(一) 可以参考 http://blog.itpub.net/23718752/viewspace-1837743/ 有些朋友给我反馈了他们遇到的小故事,我后续再整理整理,看看有多少。
DBA同学在工作中不可避免和开发同学打交道,和开发的同学在交流中还是有不少的小插曲,有些想想也蛮有意思,但是有些是痛点。 我举几个例子来说明,可能比较片面,但是只是为了说明问题,达到交流的目的即可。
继前两篇分析了一个看似非常普通的报警邮件,结果在分析问题的时候八面玲珑,相关因素都给分析了一下,没想到还真是有不小的收获。 前两篇地址: http://blog.itpub.net/23718752/viewspace-1827685/ http://blog.itpub.net/23718752/viewspace-1829630/ 最后通过手工定位监控的方式终于把罪魁祸首揪了出来,为什么在备库使用ash无果,因为还是10g的库,还没有这个特性,在11g中才可以。
在第一篇中分享了关于备库报警邮件的分析,发现很多问题都是一环扣一环. 起初是通过监控主库中的v$dataguard_status发现备库中可能存在一些问题,结果逐步分析,发现是由备库的crontab触发了备库的定时read-only和online状态,(即只读和应用...
今天早上到了公司后,收到了这样一封报警邮件,发现收到备库的报警案例也比较多,着实颠覆了我对备库基本不需要关注管理的观点。后面可以把几个案例做成一个主题来说说。 报警邮件的内容如下: ZABBIX-监控系统: --------------------------...
今天在技术之外聊天生活的话题,都是发生在我们身边的事情,突然想起来了。就准备凑在一起说一说。 医患关系 110报警 中介和骗子 医患关系 这是真实发生在生活中的一幕,最近去医院的时候,在挂号的时候,走廊里听到几个人在争吵,一男一女围着一个白大褂大夫,然后边上站了几个警察。
昨天到公司之后,收到两份封报警邮件,可以看到在早晨6:30左右主库的v$dataguard_status检查时发现了一个错误。然后再2分钟后就自动恢复了。 一般这种问题很自然想到可能是网络出现了一些问题。
昨天刚到公司,开发的同事就找到我,让我帮他看看某一台mysql的库,似乎数据是不同步了。大体的意思是,A地库中的数据会同步到B地,B地的数据会同步到C地,C地就是开发最终需要访问的数据,这些业务都是独立的,但是一部分数据是需要同步的。
不管怎么样,12c出来这么久,总是因为各种各样的原因没有开始学习,现在似乎还是有些晚了。总是耳闻PDB在12c是一种全新的架构模式,在各种技术聊天也大概知道是一种可插拨的新型架构模式,但是似乎SQLServer中也有类似的架构,不管怎么样Oracle圈内还是很火,而且听说12c r2可以支持4096个pdb,这个也太大了,docker装一下试试:) 自己也在本地尝试了一下,其实中间了花了些时间,中途总是被各种事情打断,所以留下的都是一些零碎的知识片段,自己索引把环境重新删了再做几次。
之前分享过一篇关于merge语句导致的CPU使用率过高优化的案例。的http://blog.itpub.net/23718752/viewspace-1819471/ 后续的跟进没有补充,也“秀”一张图,红色的火焰是原来的系统负载,右边的部分是最近的逻辑读情况,不过惭愧的是,这个不是优化的效果,因为应用的高峰期已经处理完了,后面的sql调用频率极低,所以感觉不到任何的压力。
笔记又坚持到了600天,想想也该总结一下了。其实每天晚上10点以后才是属于我的空间和时间,可以在近2个小时的时间里琢磨该写点什么,有时候下班晚回到家之后闺女已经入睡了。
最近碰到了一个有些奇怪的问题,自己当时排查问题时间紧,没有细细琢磨,今天抽空看了下,终于发现了端倪。 首先是在早晨收到了报警邮件,报警邮件内容如下:ZABBIX-监控系统: ------------------------------------报警内容: ...
在之前写过 记一次数据同步需求的改进(一)之后,就开始着手对这个需求进行实践。 所谓实践出真知,在实际做的时候才发现可能计划的再好,做的时候还真不是那么回事。 在之前的邮件中已经确认目标库是一个统计分析库,首先拿到这个环境,先调查一番,发现了一个奇怪的现象。
今天有一个数据库有点反常,早上的时候报出了CPU使用率的警告。 警告内容如下: ZABBIX-监控系统: ------------------------------------报警内容: CPU utilization is too high -----...
Oracle对于sys用户的审计是默认的操作,所以不管你开启了什么审计策略,sys的登录等操作都会记录下来,这也是Oracle的默认配置,可能他们也没有料到有些应用可能把这个影响放大,毕竟频繁登录sys听起来是不现实的。
最近有个需求,开发的同事找到我,提出了下面的需求 由于平台业务发展需要,需要将test_account_log 和test_protect_log 表前一天的增量同步到新增的两张表上 对于这个需求看起来还是蛮简单的。
今天下午收到一条报警邮件ZABBIX-监控系统: ------------------------------------报警内容: Free disk space is less than 20% on volume /U01--------------------...
因为业务需要,有个临时的活动需要DBA来支持一些数据业务,问题来了,需要从MySQL端同步一部分数据到Oracle端,然后从Oracle端匹配查到相应的数据返回给MySQL,至于原因,也是不同的业务系统,不同的权限分配,还没法做到一个应用端去读取这些信息,而且也有安全的考虑,大体就是两部分的数据也是互相补充,但又彼此独立,是一个全集和子集的关系。
很久之前听过一个小笑话,现在搜不到了,大体的意思如下,是某个朋友问一个大学同学要另一个同学的电话号码#场景1A:你知道老王的电话号码吗?等待了5分钟B:知道A心中一丝喜悦A:那能把他的电话号码发给我吗?等待了10分钟B:好的后面省去几十字本来是个小笑话,但是联系起生活来,还是蛮有意思,有些朋友比较熟了,可以直接要,有些朋友不太熟,还得寒暄一下,有的可能就见过一面,还得报个家门,然后继续要。
每天工作中会碰到一些问题,圈内朋友也会有各种问题,解决问题总是能够带来很大的成就感,有时候感觉在做两份工作。:) 帮助别人的意义就在于别人碰到的坑,你可能也会碰到,别人遇到的坎,也可能是以后你会面临的,坑填平了,坎越过去了,对己对人都是好事,知道那些坑,自己就会绕过去尽量规范,不要去犯;有哪些坎,出了问题之后,自己也知道该怎么处理,所以说是双赢,何乐而不为。
最近偶尔会收到一封报警短信,提示内容大体如下, xxxx,trc_directory (TNS-1190),log_directory(TNS-1190),Please check log for details 对于这个问题,看似是监听出了问题,但是根据同事的反馈说监听一切正常,而且从业务部门也从来没有得到任何反馈说系统的任何问题,所以问题就搁置了下来,但是昨天再次收到这个问题, 感觉还是需要来看一下,毕竟收到报警短信了,应该是什么地方达到了阀值,还是需要关注的。
今天收到3封报警邮件,从邮件内容中的报警情况来看,还是比较反常的。需要引起关注,找到原因处理。 这个库是一个历史库,库中的数据非常庞大,几十亿数据的表还是有好几个。但是访问频率很低,一般到历史库中所做的历史数据分析查询需求还是要少很多。
今天也算忙忙碌碌,处理了不少小问题,自己也总结几个问题,本来写点MySQL和mongoDB的东西,发现还是没有准备好,再补补分享给大家。 ### 批量处理防火墙权限开通 每天都会接到不少的请求,有一部分是关于权限开通的,一般的流程就是登陆到目标机器,然后赋予相应的协议和端口,如果检查发现已经开通了权限,就不需要了。
最近有个网友咨询我一个问题,是关于undo_retention的,对于这个参数没有过多关注,只是知道需要设置undo_retention搭配使用undotablespace retention guarantee通过邮件的操作记录可以看出这个网友还是很严谨的,每一个步骤都很详细的列了出来,这位网友在测试11.2.0.1.0的环境中发现undo retention没有像期望值那样来达到预期的效果。
之前尝试了历史数据的清理,在逻辑层面清除了数据,可以参见 http://blog.itpub.net/23718752/viewspace-1814000/ 但是从物理层面来看,数据文件还是那么大,空间还是没有释放掉。
在昨天讨论了关于目前遇到的多系统交互中关于推送文件的一些基本的要求,http://blog.itpub.net/23718752/viewspace-1814410/ 虽然感觉已经提了不少的要求,基本能够做到全面的把握,但是说归说,计划归计划,实际要做的时候,问题就很具体了,有时候很可能会和自己的想法有一些出入。
最近碰到这样一个问题,类似下面的架构形式。 目前应用1是一个另外一个网段的系统,负责一块业务,而应用2是目前我所负责的数据库所在的环境里。 现在因为业务需要,需要从应用1来推送一部分数据到应用2,只在一段时间推送,一段时间过后,就不再需要推送了。
最近处理一个遗留问题,感觉手动修复真是让人抓狂,所以花了点力气写了一个半自动的脚本,总算从这个繁琐的工作中解放出来了。 问题的背景如下图所示。 存在一个很大的统计库(有容灾备库),还有一个历史统计库,历史统计库中都是相对较老的数据。
最近收到一封报警邮件,提示还是DB time突然提高,时间发生在早晨的时候,想必大过节的也不会有人这么卖力工作把数据库负载弄上去。 ############ DB time抖动 被平均 ZABBIX-监控系统: ---------------------...
数据库软件的安装根据工作需要主要有以下几种方式,使用oui是普遍的图形界面方式,还有两种是不依赖图形界面的,一种为静默安装,另外一种为克隆安装。 静默安装的时候核心就在于响应文件,在安装目录database/response下提供了几个响应文件,是oracle提供的模板。
最近从同事那儿接手了一套新环境,备库因为服务器问题已经下架,重新配了一台服务器,所以需要搭一套备库,主库已经配置好了,而且同事已经把在主库把dg broker配好了。
昨天下午开始给一个新环境搭备库,本来想一两个小时全速搞定,没想到因为密码文件的问题耽搁了,整个过程也是一波三折,希望大家能够吸取过程之中的经验和教训。 首先这个环境没有安装oracle软件,只安装了操作系统,所以搭建备库先需要安装数据库软件,然后开始从主库使用duplicate的方式同步数据文件,然后用dg broker来配置即可。
对于orabbix报出的警报,自己都是心怀敬畏,因为这些表面的现象如果深入分析没准就能有所收获,当然目的还是解决问题,不是一味追求指标。 今天收到的报警邮件如下,然后在两分钟后问题自动恢复。
今天收到一封报警邮件,内容如下: ------------------------------------ 报警内容: Free disk space is less than 15% on volume /var ------------------...
继昨天对系统进行了初步的调优后,效果还是比较显著,DB time从500%降到了100%以内,当然过程还是充满艰辛,期间也是各种工具和分析语句斟酌了再三。 今天也没有收到任何报警,所以感觉问题似乎已经彻底解决了。
awr报告中的sql明细部分基本必看的部分,尤其是SQL Order by Elapsed time这个部分,能够很清晰的看到哪些sql语句占用了较多的DB time,所占的比例。
最近偶尔会接到一条短信,提示某个备库中出现了ORA-00600的错误。对于这个问题还真不能心存侥幸,自己带着疑问查看了一下, 这是一个一主两备的库,主库和其中的一个备库没有任何的ORA-00600的错误,只有这一个备库中偶尔会出现ORA-00600的错误。
昨天收到一条报警短信,短信内容大体如下: Agent is Unreachable(REASON=javax.net.ssl.SSLPeerUnverifiedException:xxxx.com:cn=xxxxx).Host is unreachable. 看着短信内容,应该是agent罢工了。
现在系统监控的工作处于过渡期,即对于Oracle的还是保留了gridcontrol的监控和报警,同时也保留了zabbix的报警,在发生问题的时候想看看哪个能监控的更到位一些,是否稳定等等,其实这个还真不好说,监控的好与不好都在于使用的情况,标准也不一样,不过从今天这个案例来看,系统级的监控还是zabbix要灵活一些。
一般在一些容灾环境中,尤其是在11g的ADG非常普及的场景下,备库被赋予了更多的责任,很多时候在容忍一些延迟的情况下,有些应用的大量数据查询任务直接放到了备库,把它当做一个只读节点来使用,所以在有些情况下,可能备库的压力还是蛮大的。
我家宝现在长大了,越来越爱活动了,从侧面可以反映出婴儿床是早已满足不了她了,所以给她在客厅空出一大块空间,当作小游乐园。小的健身器材也有的,小玩具也有若干,不过似乎从她的反应来看,对颜色鲜艳的东西还是更感兴趣,灰色暗色的她基本都不敢兴趣。
还是继续分析报警信息的关联,下面两个看似没有直接联系的报警信息其实很有关联。 下面是主库的报警的信息,查看v$dataguard_status得到了最新的错误信息。
最近也在处理一些遗留的问题,所以对于使用orabbix的报警还是心怀敬畏之心,一方面是我们让它能够做全方位的监控,另一方面也让我发现我们还是存在不少的小问题,小问题虽小,但是放大了,就是大麻烦,甚至数据库事故。
说起数据类型转换,在开发中如此,在数据库中也是如此,之前简单对比过MySQL和Oracle的数据类型转换情况,可以参见MySQL和Oracle中的隐式转换 http://blog.itpub.net/23718752/viewspace-1787973/ 不过当时写完之后,有个读者随口问了一句为什么,为什么呢?似乎自己还是一知半解,说是规则,无规矩不成方圆,倒也无可非议,不过我觉得还是要再看看,看看还能有哪些收获,接下来的内容我就不能保证正确性了,希望大家明辨,也希望提出意见,毕竟就是希望把问题搞明白而已。
今天在微信上碰到某大师,简单聊了下。我和这位大师的关系也蛮有趣,最开始通过其他的渠道认识,还没有见过面,我向他推荐了我的一名前同事,没想到这位大洋彼岸的前同事竟然和这位大师也曾经是同事。
今天来给大家分享一下DBtime抖动的诊断案例。讲到的不足之处还希望大家多多指正,共同提高。案例会分下面几个方面来说。 首先来说问题的背景。因为使用的数据库环境多且复杂,数据库不只有Oracle,所以通过gc来统一管理所有的数据库平台定制成本较高,使用zabbix可以满足系统级监控和MySQL等的监控报警,对于Oracle的监控通过扩展的Orabbix来实现。