Oracle ACE,《Oracle DBA工作笔记》作者 现就职于国内某互联网公司,擅长数据管理,数据迁移,性能优化,目前专注于开源技术,运维自动化和性能优化。
现在的技术发展,海量服务器,批量任务,让原本精细化,几台服务器上的维护工作一下子有了指数级的提升,于是很多人就提出了自动化运维,而Python似乎也是“应运而生”,当然Python语言其实历史已经很悠久了,这是很多运维,很多开发人员来说没有逐渐渗透到这个领域而已。
今天同事有一个环境发现一条语句执行时间很长,感到非常奇怪。刚好有些时间,就抽空琢磨了下这个问题。 总体来看这个环境还是相对比较繁忙的,线程大概是200多个。 # mysqladmin pro|less|wc -l 235 带着好奇查看慢日志,马上定位到这个语句,已做了脱敏处理。
MySQL Profile对于分析执行计划的开销来说,还是有一定的帮助,至少在分析一些性能问题的时候有很多的参考依据。 我在5.6, 5.7版本中进行了测试,没发现差别,还是以5.7为例进行演示吧。
rownum在平时的使用中总是一个很自然的语法。如果说这个rownum是否有规律,可能很多人都会模棱两可。到底是还是不是呢,我们来做几个测试来说明。 这个结果也是在一个测试过程中无意发现的,没想到还蛮有意思。
在Oracle中有merge into的语法,可以达到一个语句完成同时修改,添加数据的功能,MySQL里面没有merge into的语法,却有replace into。 我们来看看replace into的使用细则。
一直以来,对于MySQL中的事务和锁的内容是浅尝辄止,没有花时间了解过,在一次看同事排查的故障中有个问题引起了我的兴趣,虽然过去了很久,但是现在简单总结一下还是有一些收获。
我有两个手机,一个华为的手机双卡双待,但存储空间严重不足,工作生活电话两用勉强够用,另外一个苹果手机,没有手机卡,只是作为我看电影所需,按照我媳妇的话,实在是太浪费了,分成两个卡多好,我想一个手机已经够累了,拿两个手机,总是得再生活工作中切换更麻烦,看电影是可选需求,这可能也算个借口吧。
鉴于上一次科技馆匆匆游览,今天再次踏上了旅途,准备带孩子好好玩一玩。 早上出发还算早,看着楼下宠物店的猫咪还在懒洋洋的睡觉。睁开眼瞥了我们一眼,继续睡。 一路直奔鸟巢,跑跑玩了一会,为了保存体力决定搭观光车过去,鸟巢来了多少次,观光车还是第一次做。
黄金周里处理了一起紧急的问题,在外面幸亏有同事帮忙协助,等我赶回家去,赶紧继续处理。 首先问题是在晚饭时间左右开始发生,但是过了没多久又恢复了,所以这个问题暂时就没有引起太多关注,但是后面发现问题开始反复,而且数据库的负载开始急剧提升,后面也开始收到了不少的报警信息,一下子问题就变得紧急起来。
在我的印象中,路边的小摊是不大卫生的,我很少去光顾,确切的说是,一年勉强有那么一次吧。今天就是这样的一个机会。 下午要解决一个看起来比较简单的问题,结果耽误了不少的时间,折腾到下班的时候,还是没有进展。
还是继续昨天的任务,今天会把剩下的工作都做完,给个交代。 昨天完成了Data Guard切换,然后Failover备库,导出了元数据信息作为TTS的准备,亮点就在于导入的部分。
在之前写的一篇博文中,自己是打算对一台数据库使用Data Guard+TTS的方式来完成数据迁移和升级的工作,整体的思路如下。 备库Failover之后,导出元数据,然后同一台服务器上的11g的数据库中导入元数据,这样就避免了传输文件的时间消耗。
在我的印象中,一直以来都会收到一封报警邮件,之前分析过,排查过,最后发现是一个遗留问题,协调开发同学,停业务维护还是有一些难度,最后不了了之了,在今天又突然想起了这件事情,觉得还是需要做点什么。
又是一个周末,很难得,陪孩子待了近2天,第一天是外出,第二天是生病陪伴,虽然说有苦有乐,但是回想起来几乎都是乐。两天没再捣鼓技术,反而得到了更多生活中的感悟。 首先是到郊外去,陪孩子在小区里转悠,看着两旁的水泥森林,让人有一种麻木的感觉。
有一天上班的时候,收到一封报警邮件。 ZABBIX-监控系统: ------------------------------------报警内容: archive_area_usage ----------------------------------...
之前写了一篇文章分析了目前存在的一个问题和改进思路。 当前的硬件环境是Solaris,Oracle 10gR2 单实例,数据量在800G左右。想迁移到另外一台服务器上。
在很多时候,我们都是需要保持业务的可持续性,尽管说DDL的过程持续时间很短,但是在线业务出现,就会阻塞DML,导致业务访问中断,事务收到影响,所以在有些场景下,高可用的需求可能比性能的需求优先级还要高一些。
DG Broker是Oracle为Data Guard维护提供的一个很不错的工具,从我的实际使用来看,早期的版本中似乎大家都还是存在一定的思维定式,认为手工维护已经足够了。
有很多事情都是如此,说小了是份内的,说大了是份外的。 昨天快下班前接到一个电话,是某厂商的技术支持打过来的,我们有一台在保的服务器idrac服务有问题,经过技术建议,固件升级都不奏效,最后厂商决定派技术工程师去机房上门维修了。
在N多年前,搭建Oracle RAC环境的时候,其中有一项非常艰巨的任务就是配置节点服务器的互信关系,每次到了这个部分的时候就有点晕,因为文件需要在两个节点间拷过来,拷过去。
今天看了下《Linux大棚命令百篇》网络和系统篇,发现了几个很不错的命令,我是看着目录然后根据自己的需要选了3个命令,没想到3个命令都让人眼前一亮,刷新了我原本的认知。 首先第一个命令还是老生常谈的ping 传统的ping就是下面的样子,这个也是我们熟悉的ping # ping 10.
今天无意中在微信群中看到了这么一个截图,让我的内心又开始躁动不安。 记得有这么一页ppt,但是忘了是在哪里的,于是乎翻遍了这两天的大多数微信聊天记录,终于找到。
最近的琐事比较多,而提问题的朋友还是不少,很多消息都没有来得及回复,各种事情一堆起来,不少问题想起来已经过了好几天了,所以还是来整理一篇技术问答为好。 首先是很多朋友问我关于半自动化搭建Data Guard的脚本,我写了几篇文章来介绍思路,自己也提了不少的改进,团队内部也沟通过了,一直迟迟没有发布出来是因为我觉得目前的实现方式可能对于我的工作能够极大提高,但是很多朋友使用的环境可能没有中控的概念,所以不是很通用,所以我想做一些改变,还有一个是里面的有些逻辑我想改改,至少简化一下。
对于Oracle的Flashback来说,在11g里面有了一个很细微的变化,可以说是一个很不错的福利,那就是开启闪回不需要重启数据库至mount状态下,归档模式下open状态就可以开启,关闭。
最近又发掘出了Data Guard的新玩法,可以通过闪回恢复switchover的主库,这种场景听起来比较特别,但是Oracle依旧支持。 我们的大体思路就是,在主库我们标记一下数据状态,然后做Switchover之后,我们truncate 某个表中的数据,也就间接模拟了一个数据库故障,这个时候需要做回退,需要把主库的数据都恢复到切换前的状态,这个听起来还是比较复杂的场景,备库还可以一如既往的跟着主库吗? 我们用图表来说明一下: 首先是一个主备库的环境: switchover是计划内的任务,就是主切备,备切主。
在搭建Data Guard的时候,我们可以直接从主库生成一个备库控制文件,或者拷贝一个备库的控制文件即可,后续的工作就交给Data Guard来自动恢复完成了,尤其是使用rman备份恢复的时候,使用recover database是一气呵成,我们无须理会其中更多的细节,当然实际上Oracle已经帮我们处理好了。
今天看到有一个网友提了一个问题,描述很简短 测试DG时,主库不能宕机,如何测试failover? 其实这个需求从业务层面来说是合理的,一个数据量很大的核心数据库,如果需要做灾难演练,就希望在备库上做一下演练工作,而这个演练其实又不想影响到目前的主库,而且又希望能够尽可能模拟真实的情况,我想这样对于运维部门来说是最具有考核力度,而对于开发业务部门来说是最受欢迎的,因为他们什么都不需要改动。
当Zabbix和Percona两者相遇,会擦出不少的开源火花来,众人拾柴火焰高,最终受益的还是大部分运维人员。 我很早就用过Percona提供的MySQL监控模板,但是却没有刨根问底,只是简单使用而已,自从定制了Orabbix之后,我还是信心满满,MySQL的数据字典相对要少很多,监控起来可能想必Oracle要少很多,不过关于Percona的这个插件,我还是带着好奇之心,内部是否有很多独门秘籍,我想好好学学那些监控项对应的SQL,好好弥补我对于MySQL监控的一些空缺,所以简单分析这个模板就排上了日程。
自从拿到了华为Mate 7的手机之后,大屏确实给我带来了很多不一样的使用体验,特色功能是双卡双待,确认让我省心不少,但是一直让我纠结的就是这手机存储空间的问题。本来存储空间是12G,到现在空间剩余总是徘徊在几百兆的样子,每次清理空间都会让我有些心疼,一来怕删错了,有点担心,二来有些东西还是得删掉,有些不忍。
作为DBA总是会有现场的救火工作,而如果尽可能早一些介入需求,设计,开发阶段,可能就会杜绝很多潜在的性能问题。很多问题都是如此,都是逐步积累,最终在某一个阶段会集中爆发出来。
时间滴答滴答滑过,又是一个100天的阶段性总结。 大体来说,这100天里发生了很多的故事,去了趟青岛,去了趟四川成都,九寨游玩,回了趟家,出了新书,做了演讲,多陪了陪女儿。
下午的时候收到这么一条报警。 ZABBIX-监控系统: ------------------------------------报警内容: Too many parallel sessions on xxxxx_xx机房_xxxxx ------------...
周末整理了一下书架,一来书架上实在是放不下东西了,四层书架,两层在闺女的触及范围之内,所以直接拿胶带封住,留下两层勉强可用。二来书架已经不是放书的地儿,生活用品已经一股脑儿堆了很多,让人想拿那本书都困难,书不是远观而不可亵玩焉的,要捧得起,放得下。
今天和大家聊聊过旧技术的问题,这个名词听起来挺怪,技术本身无罪,最后想了想,还是暂且这么标记吧。 我想起了在8年前的一天,一个很资深的前辈在聊到自己的感触的时候说,技术的更新在实际工作中总是会慢一拍或者几拍。
对于有料的技术会议,我一向很有兴趣,今天从APMCon归来,也是收获满满。因为天气的原因,我想可能到会的人数会有很大影响,从现场的情况来看还不错,会场的整体情况超出我的预期。
今天下午的时候,准备顺手写一个简单的脚本,但是发现很多事情较真起来真是寸步难行。在写脚本的过程中碰到了太多的问题,很多时候感觉像要实现的功能更通用,就得做更多的检查,更多的校验也就意味着有更多的预先条件,这些条件里面有些是规范和建议,有些是按照已有的配置情况,尽管如此,自己感觉还是缺少了太多的检查。
对于备库的使用,尤其是一主多备的环境,一直以来有一点感觉不大给力,那就是主备库的关系,总是感觉会少一点什么。 尤其是在做月度404审计的时候,总是要反复确认备库的IP。
自前些天写了一个脚本之后,今天特意测试了一下,没想到一下子发现了一个大问题。有一套一主两备的10gR2环境,一个异机备库一直在READ ONLY状态,也就意味着数据库在打开之后一直忘了恢复应用归档,然后在某一天发现时,已经延迟了好几个月。
整个一个周末似乎都是忙中有闲,闲中带忙。最近在思考一个书单,在思考能让受益的群体更大一些,已经有了一些思路,当然要付诸行动又得是很多个不眠之夜的努力了。从我整体的感觉来看,大家还是对于一些脚本类,通用类的问题更感兴趣,写技术文章之余再补几篇随笔,也是悠哉悠哉。
今天写了个脚本,虽然实现的功能不多,但是个人感觉是一个好的开始,架子出来了,后面要补充的细节加进来就逐步完善了。 这个脚本的运行效果如下: OS Version is :[ RHEL_6.
晚上在琢磨怎么把报警的处理实现自动化的功能,想来想去,发现其实很多内容都是相通,在纸上写写画画,简单理了理自己的思绪。 人嘛,有时候不逼着自己,只会更加懒惰,而一旦迈开了步子,可能就停不下来了,问题也有轻重缓急,我们来理一理。
今天在处理一个工单的时候发现了一个奇怪的现象,开发同学需要创建一个存储过程,目前的架构类似这样的形式 数据库中存在一个属主用户,表,存储过程等对象都创建在这个用户上,而另外有一些连接用户,根据业务和功能可能访问的对象权限也有所不同。
应有些网友的要求,今天还是硬着头皮把半自动化的方案给发出来了。内部测试了一下,因为我是开发者,使用者,所以都玩得转,大体的测试,从安装数据库软件到搭建Data Guard,在duplicate同步数据前,大概用了近15分钟时间。
晚上正在休息的时候,突然收到一封报警邮件。 报警内容: CPU utilization is too high ------------------------------------ 报警级别: PROBLEM ------------------------------------ 监控项目: CPU idle time:59.11 % ------------------------------------ 这个报警信息已经非常明确,CPU使用率很紧张了。
今天的技术问答是刘晨兄的一个问题,提问来自于我新书中的一个实验,刘晨兄非常认真,对我书中的很多细节都进行了测试。 看到这个错误,如果出现end-of-file这类的错误信息,基本可以断定数据库实例是宕了。
今天总算抽了些时间把半自动化的脚本完成了大半,目前还缺少两部分的脚本,一部分是安装前的检查脚本,可以做一个预检查。虽然目前来看还不是必须,但是这些是标准和规范的地方,这些条件不满足,失败的概率会加大。
关于半自动化搭建Data Guard,自己花了一些时间,总算是把这件事情继续推进了一下,还是再啰嗦一句,为什么不自动化,因为安全。主库就是主库,任何变更都要手工检查审核,自动化的工作在备库和中控端来完成。
前几天看Fenny写了一篇文章,提出了一个观点:翻新也是一种创新。我是感同身受,当然Fenny的名气如此之大,我也没有必要去附和了。 当然那篇文章看过之后,我还是继续写我的笔记,每天上下班的生活,地铁上抱着手机上翻下滑,日子看起来也过得有滋有味。
前段时间有个开发的同事向我咨询一个问题, 开发同事:Oracle会存在一个用户插入数据,已经提交了;但是另外一个用户还查询不到吗?都是同一张表 jeanron: 不会的。
之前写过一篇关于我的女儿的文章,我本来愧疚的心感到稍稍宽慰了不少,我想若干年后,可能我还真不一定能够想起自己还曾写过这些。因为这不是在单纯抒发感情,而是我觉得现在积累的东西越来越多,感觉大脑的能放下的事情有限。