Oracle ACE,《Oracle DBA工作笔记》作者 现就职于国内某互联网公司,擅长数据管理,数据迁移,性能优化,目前专注于开源技术,运维自动化和性能优化。
一直以来搭建Data Guard是一件看起来还蛮有含量的工作,因为这其中涉及的工作比较琐碎,比较细,况且手工搭建起来都会碰到各种各样的问题,如果中途碰到一点儿小问题,那可能需要花点时间来排查,如果想要脚本自动化,那简直寸步难行。
最近处理了一个需求,比较紧急,映射到数据库层面是需要更新17万id的值,听起来是不少,根据数据架构进行了分析,发现目前是做了分库分表的方式,所以这17万的id在这些分库中都可能存在,而跨部门的数据交付中,也没有做分库的区分,所以拿到的id是一个笼统的概念,即哪个id对应哪个分库没有事先过滤甄别,这个工作就自然而然的下落到了DBA头上。
今天碰到一个有些奇怪的问题,有一套环境,在主从复制的时候有一些问题。 大体的流程设计如下: 三个节点位于三个不同的区域,因为节点1和节点3之间的网络存在问题,所以走了节点2来中转,由此可见延迟是难免的,但是延迟不能太大。
最近为了统计一些服务器的监听使用情况,于是写了一个简单的脚本,在中控中执行,脚本逻辑很简单,也没有什么亮点。 脚本内容如下: #check $1 is IP base_dir=`pwd` ssh $1 "ps -ef|grep smon|grep -v gre...
今天北京社群举办了第三次线下沙龙,作为其中的一员还是颇有感触。 当然社群不是一两个人撑起来的,今天全国的另外四个城市大连,长沙,福州,成都也都同时举办了沙龙活动,遥相呼应。
在网上突然翻到几年前和美国一个Oracle大师的邮件交流,再次读来依旧感觉受益匪浅,这位大师很热心,为了保护隐私,只说他是oaktable的会员,是一位很有经验而且谦逊的一个人。
最近处理了好几起关于merge导致的问题,其实看到merge语句内心也还是蛮纠结的,这一次还是碰到了问题,简直无语了。 先交代下问题的背景。有一套OLTP环境和OLAP环境需要同步一部分数据,都是在每天的半夜开始,OLAP的库的一个表数据会根据增量的逻辑从OLTP库中同步,有两种方式,一种是OLAP从OLTP中去抓取,另外一种是OLTP推送给OLAP。
今天北京暴雨,雨下得非常猛烈。我在早上经历了一番洗礼之后,在朋友圈感慨到:生活如此多娇,带着雨伞出门被大雨浇了半身,在地铁上,裤子湿了又干,下地铁,裤子干了又湿,到公司,还摔了一跤。
最近有一个同事问我一个问题,说他运行一个SQL语句抛出了ORA-00600的错误,想让我帮忙分析一下,这种问题听了确实有兴趣,了解了问题的大体情况之后,发现这个问题还是值得分析分析的,因为只是客户端调用抛出异常,没有给服务器端带来什么致命的影响,这样的问题还是很耐人寻味的。
前几天的时候帮助一个网友看了他遇到的一个问题,在问题处理中也让我有不少的感悟。 最开始的时候这位网友的问题是一个10gR2的单实例数据库,监听无法正常关闭和启动,他在尝试了杀进程之后,重新启动还是会一直卡在那里。
今天快下班的时候有一个同事问我一个存储过程的权限是否做过修改。我简单看了下发现这个存储过程已经是很久以前创建的了,一直没有做过修改,所以就反馈给他了。但是他过了一会问我说,他通过数据字典查看,没有找到这个存储过程,想让我帮忙看看是不是因为权限的原因,因为他们调用这个存储过程有一些问题。
虽说实践了不少的数据迁移项目,但是从我的感触来说,一些很细小的差别就会造成整个数据迁移方案的大不同。数据是系统的核心命脉,所以对于DBA来说,保证数据的一致性和准确性是一个最基本的要求。
之前写了一篇文章分析了Datapump迁移数据的一些准备总结,反响还不错。最近碰到一个场景,根据评估还是使用Datapump比较好。主要的原因如下: 1.原来的环境在Solaris下,硬件资源老旧,需要迁移到Linux下,跨平台迁移使用逻辑迁移优先 2.原来的环境使用10gR2,现在需要顺带迁移到11gR2,充分解决备库“不中用”的情况 3.迁移的数据量不算大,在几百G以内,可以充分利用带宽和I/O吞吐量来达到预期的时间窗口。
最近有不少的朋友问我一些技术问题,有些因为时间紧张没能及时回复,可能等我想起来的时候他已经不需要了,这种情况下着实让我感到有一丝歉意。我也有过很多次的问答经历,也是不停的刷刷手机屏幕看看有没有回复,一旦有了回复,就像吃了蜜一样甜,说实话还是蛮讨厌现在的自己,很多事情似乎都不是我预想的那样,我也不是很喜欢应酬,我还是那个屌丝的我。
最近填了些快递单,也填出了一些感悟,很多地址看起来很陌生,到了接收快件的快递员手里,我相信也是陌生的,但是到了派送快件的快递员手里,就变得更加具体了。比如说我写地址的时候总是会偷懒写北京大兴区彩虹新城xxxx,其实完整的地址应该是北京市大兴区黄村镇彩虹新城xxxx,但是我几乎所有的物流单都这么写,竟然也写习惯了,基本上没有接到过快递员的电话问我具体的地址,物流系统真是庞大,复杂,远远超出我的想象,里面牵扯有太多的学问和门道。
最近几天有几件趣事,还是值得说道说道。一件是苦中有乐的事情,一件是技术问答的真实“段子” 关于新书 首先是关于我的新书,因为有不少的朋友捧场,刚开始的几天还是很忙碌的,很多事情都要独立完成,远远比我预想的要复杂多了。
对于之前碰到的一个数据库负载急剧提升的问题,做了应急处理之后,我们需要再冷静下来,来看看是哪些地方出现了问题,还需要哪些改进。 首先第一个问题就是为什么会突然负载提高,如果感觉,应该是业务层面出现了一些变化吧。
今天处理了一起紧急问题,回过头来看还是有不少需要注意的地方。 首先是收到了报警,有一台DB服务器的负载有一些高,但是会快就恢复了。所以自己也没有在意,但是过了大概40多分钟,又接到一封报警邮件,而且随着报警频繁,感觉真是出了问题,在中控机器上使用ssh连接竟然都抛出了异常。
今天看到一个同事发了一封邮件,是关于分区的,他说目前某个表的分区需要添加,为了保险起见,让我先添加三年的。这里折射出几个问题。 1.如果没有这位开发同学提醒,我还真不知道哪个表的分区数据会有问题 2.添加三年的分区,这个对于DBA来说是一个体力活,哪怕写脚本也是,本身维护起来就比较纠结。
今天接到一个MySQL工单,是执行几条SQL语句。我一看就感觉这语句比较有意思。 语句大体是这样的: update app_code_value set channel_id=null where task_id=378 and channel_id=''; update app_code_value set channel_id=null where task_id=379 and channel_id=''; 因为对Oracle熟悉一些,所以总是喜欢用Oracle的思维来看很多问题,大多数的情况下是相通的,但是还是有一些差别之处。
回家的路总是漫长而又曲折,从四川那边回家近30个小时,从家里会北京又是一整天的时间,整个9天假,路上花了一半的时间,这次的旅行算是匆忙,旅途距离跨度大,很大的一部分原因都是因为想带着孩子,孩子还小,大人也累,孩子也累,不过总体来说还是其乐融融,现在的小孩子见多识广,比我们高不知道多少倍,我到上大学了才摸到手机,现在孩子比我提前至少20多年,哈哈。
在茫茫的夜色中,我从长途火车上下来,终于到了多年不回的家乡,想想已经多年没有回家了,每次过年都是在北京,每次都是匆匆而过,当然这次也是。因为需要尽快回家,而且当时天色已晚,所以我们选择了打车回去。
最近一直在旅途中,也领略了不少沿途的风景,对于我个人还是很有感触的,一来是需要赶紧学驾照了,开个车出去自驾游还是很惬意的。二来是生活中其实还是有很多不一样的体验,比如旅行,比如吃喝玩乐,在工作之外这些才是我们的生活吧。
关于运维平台的建设,元数据一直是一个很重要的环节,之前在听了ITIL方面的一些讲解之后,发现其实早已经是体系之中的,想必是很多公司很多人还没有重视起来而已。 而要说运维平台和元数据,其实我也一直比较纠结,因为我不是专业的,只是在工作中越来越意识到它的重要性,很多时候不是口上说说,提提而已,而要落到实处,更不能图形式。
今天和有些同学讨论了学习和工作中关于oracle的一些小问题,也让我在回答中梳理了自己的思路。 首先是操作系统的选择,目前来看,大家的态度其实还是不够认真,工作中很多环境使用的是Linux64位,所以我也是推荐使用redhat6,如果选择...
今天下班在地铁上,我拖着疲惫的身子行走在地铁换乘的通道里,突然接到一个电话,是出版社的荆老师打过来的。简单寒暄之后,他带着一种喜悦,如释重负的告诉我,到今天为止,稿子所有的流程都走完了,可以正式下厂印刷了。
今天抽空整理,发现近期问我数据恢复,灾备的问题还比较多,我简单整理了一下。 问题1: 能请教一个问题么?我们用was链接的oracle数据库,是不是不建议在was上设置statementcachesize的参数?我们目前设置的是200,发现数据库中那个sessio...
前几天,一个开发的同学让我帮忙做一个大查询,给了我一个数据列表,里面的ID有几万个,提供了一个SQL语句,看这情况还得我自己来解析生成相关的SQL了。 假设ID列表为: T100 T200 T300 SQL语句为: select peak_transaction_id,cash ,req_time ,back_time from peak_new.peak_detail where peak_transaction_id=?; 对我来说拼成动态SQL也是分分钟,但是这种方式不推荐,还是推荐使用数据的结果集方式来匹配。
又是一年父亲节,在我的印象中,似乎也没有主动给老爸过过一次生日,实在羞愧,如果细想,老爸的生日是什么时候啊,好像老是看身份证,但是一直没有记住。今天这个节日真是一个好的机会,我们中午也借着这个机会去外面的馆子改善了一下。
如果你去看其他DBA的操作的时候,如果要判断他们水平的高低,我想就是通过一些操作的差别来看了,而水平高低就体现于此。细节决定成败,越是看起来简单的操作越是要严谨,一丝不苟。
对于生活,用文字表达是一种非常好的方式,作为技术人,我决定使用一个脚本来映射技术生活中的一些小故事,也是在今天突然想到的。 对的,你没有看错,就是下面这个命令。但凡接触过Linux系统,这个命令还是很熟悉的,不熟悉也没有关系,就是查看服务器的磁盘空间。
其实对于Datapump迁移而言,如果参与过XTTS,OGG,Veritas SF,外部表增量等迁移方式的话,会发现Datapump还是很简单清晰的,一个优点就是操作简单清晰,想必于imp而言性能要好。
其实对于Failover和Switchover是大家处理灾难时很头疼的一个环节,也是最关键的处理过程。 假设你半夜正在睡觉,被报警电话惊醒,得知某个服务器产生了故障宕机,在这种情况下,我们大体会有下面的处理流程: 1)检查原来的节点是否可用,需要查看ILO和存储,...
创建数据库,主要有手工建库,DBCA建库,OMF建库。手工建库会重新初始化数据字典,过程相对比较耗时,但是完全定制化;OMF建库的场景比较特别,一般都是糅合在ASM中使用;DBCA图形化建库使用场景受限较大,其实DBCA还有另外一种快捷的方式就是DBCA静默建库,整个过程分分钟即可搞定。
带着满满的期待,今天终于完成了Gdevops峰会北京站的活动,从会场走来,感触良多,索性在回家之后马上打开电脑来记录一下自己的所见所闻。 其实从开始准备要筹划这么一个峰会,自己感觉是有些突然,最初我的想法是做做几场沙龙,提高提高人气,发现峰会是一种大胆的尝试和挑战,所以说社群要做大做强,确实需要一个掌舵者和领航员,而在这个想法筹备的过程中,社群也在不断的壮大,从最开始的雄心勃勃到目前的落地举办,这个过程中着实大家都付出了很多的心血。
今天早上看了魔兽,下午玩了几把魔兽争霸,晚上玩了几把,然后看了两场月神moon的精彩视频,看人家咋就那么淡定,各路兵种齐上阵,瞬间秒杀英雄是并行,同时执行多个任务是并发,这么强的组织和策划,还真是学不会。
魔兽上映了,带给80后的是更多的期待,感觉很多人一下子在这个时候找到了一丝回忆,可以为之疯狂。看微信,微博里的情况,魔兽算是刷屏了,这种感觉就如同《美人鱼》带给我们的感觉一 样,很多都戏称欠星爷的一张电影票,想必真是如此,这种时日可遇不可求,以后什么时候会有,可能吧。
在Oracle运维中,有一个很基础的工作就是安装数据库软件,而这个工作一般少则需要花费个把小时,多则半天。 如果我们有大批量的服务器安装任务,那么这种时候你肯定会希望从这种重复性劳动中解放出来,人工操作还是会有或多或少的差错,而且耗时。
最近有一些朋友也在问我关于公众号写文章的事情,以前也有很多人。有些朋友也开设了自己的公众号,很多人坚持了一段时间就放弃了。不过一般对于他们的问答我都是比较热心的,我希望能够有更多的人参与进来,至于盈利模式,如果那么想,可能你会发现似乎不是想象的那样,至少对于我是如此。
前些天收集了一个非技术的读书清单,受益匪浅,从中也学习了不少未知领域的解读。如果我在图书馆看到这么一本陌生的书,可能会去看看简介或者花一些时间去简单了解,但是显然我不会像朋友推荐的书一般重视,征集书单的缘由在于公司之前的一个活动,可以帮大家订购一本自己喜爱的...
在Data Guard环境中,主备库基本都是使用归档来传递数据的变化。如果主备的归档传输中断,同时主库的归档被删除或者损坏,这种情况下备库是没法开始继续接收归档,应用新的数据变更了。
昨天中午的时候,接到开发同学的电话,说有一个在线数据迁移,碰到了一些问题,希望我能够帮忙看看是哪里的原因。 从电话里的反馈得知,他们在做业务数迁移,会把数据库1中的数据迁移到数据库2中,当然会根据逻辑要求迁移大部分的数据。
又到了年度的儿童节,其实儿童节大人小孩都挺忙,有娃的带着娃忙着过节,没娃的保持一颗童心,听到一句挺有意思的话,愿生活这台滚筒洗衣机,永远都洗不掉你的孩子气。 今年这个节日,看着娃也大了,刚好公司有这么一个年度的活动,所以就和媳妇带着娃来到公司,上班时间来陪娃玩还是别有一番滋味。
最近在处理服务器机房迁移的事宜,很多事情其实看起来简单,但是实现的时候总会有一些不如意的地方,很可能你考虑的是一个看起来非常稳定完美的迁移,但是实现中总会有这样那样的限制最后不得不采用一种混合式或者看起来有些别扭的方式来实现。
在主备库环境中,如果出现数据文件级的一些不一致,后期修复会很麻烦,所以这种情况可以提前规避,减少后期的隐患,我定制了一个数据库监控选项,即数据文件状态的检查。 最近几天,在半夜的时候,我总会收到这么一则报警信息,最开始没有留意,看报警信息是在备库中。
人性中总会有一些善恶,姑且认为有些恶不是恶意而为吧。当然写出来自己也会痛快一些,也是作为指示明鉴。 我在周末的时候,就不让父母给我煮粥了,一来不想让他们麻烦,二来喝粥也有些腻了,所以我会赶早场去吃牛肉面,当然在北京能吃到几家正宗牛肉面的馆子实在太少了,楼下的算勉强一家。
最近对一个统计库做了计划内的容灾切换,即主备切换。操作的过程其实还是蛮顺利的。但是灾难切换中如果出现在问题,那就是灾难中的灾难了。 按照计划对配置信息做了同步,然后使用DG Broker做了SwitchOver操作。
昨天在朋友圈发起了一个小小的请求,希望朋友们推荐一些自己喜欢的书,非技术类的。很快收到了不少的回复,我简单整理了一下,看到了很多陌生的书名,对我也是好事,在平时闲暇的时候还是能够读点书,其实我们大部分是有知识没文化的人 对于书单,整理如下,当然这个书名看起来很简单,对陌生的人来说还是有很多的未知问题,比如属于哪种类型,评价怎么样,什么时候出版的,一本多少钱,作者是谁等等。
工作中碰到问题当然是见怪不怪了,而处理这些问题也是我们的价值所在。 今天处理了几个看起来比较有意思的小问题,当然究其原因,要不是不规范,要不就是基本功不够扎实。问题1:奇怪的ORA-00600报错,常规的原因 对于ORA-00600的错误,其实自己也碰到过很多次了,绝大多数的情况下,这个错误还是能够反映出来一些不规范的现象。
最近收到了几个朋友的提问,我简单总结了一下。问题1: 首先是有个朋友问到,单引号,双引号在有些场合通用,有些场合会提示错误。 我做了一个简单的测试,当然只是一个相对片面的解读,能够说明问题即可。