Oracle ACE,《Oracle DBA工作笔记》作者 现就职于国内某互联网公司,擅长数据管理,数据迁移,性能优化,目前专注于开源技术,运维自动化和性能优化。
最近碰到了一个oracle bug,但是我感觉还是有些运气的成分,虽然错误日志和bug描述吻合,版本也完全对应,现在有几个问题在我脑海中翻腾,就是这个问题是不是一个特例,是不是一些额外的原因导致的,于是我翻出了日志重新来看。
开发同学前几天给我提了一个数据查询的需求,大体是查询某个表的数据,然后把查询结果以csv的形式提供给他们,一般来说这种定制查询,开发的同学都会提供好语句,DBA同学只需要简单执行即可。
今天对之前描述的问题一条insert语句导致的性能问题分析(一) 进行了进一步的补充。 有一条insert语句的主要性能瓶颈在于insert子句中的查询语句,查询中的主要资源消耗在于对两个表进行了多次关联 语句主要的结构如下: insert into xxxxx...
今天早上开发找我看一个问题,说他们通过程序连接去查一个表的数据的时候,只查到了8条记录,这个情况着实比较反常,因为从业务上的数据情况来说,不可能只有8条。 但是开发没有太多的权限做线上环境的数据检查,就让我帮忙看一下。
这篇文章的动力来自于一个朋友的提问,他问我备库的密码文件直接重建可以吗,我说最好还是复制,如果重建可能会有一些潜在的问题,当然这个所谓潜在问题也是自己给自己打的马虎眼,到底哪里有问题,脑海里搜索了一番似乎没有找到什么有效的信息,但是隐隐之中感觉搭建dataguard好...
已经好几年没有玩过拳皇了,今天从我哥那里拷贝来了街霸的虚拟机,玩了一会,竟然不由得想到了拳皇,这个曾经让我们如痴如醉的游戏。 在自己玩的所有版本里面,个人最喜欢认为最经典的还属97版的拳皇。
最近看了一个问题,看问题的表现着实比较奇怪,困扰了我好一会儿。 问题的背景是帮助开发的同学解决一个数据库问题,最后问题解决之后,我想做一个操作系统级的检查,帮他们看看还有什么需要注意的地方。
最近处理的小问题很多,我就拿出来几个,简单和大家说一说。我就分为三个方面,硬件问题,Oracle表空间迁移,MySQL断电恢复 首先是硬件问题。 如果看到下面的系统日志,就会发现早在2014年就出现了一些警告和问题,随后看似已经修复了部分,但是实际情况是这台服务器的电源已经坏了一个,另外一个已经快扛不住了。
目前线上有一套环境是10gR2的,采用了一主两备的架构。在其中一个备库上每天凌晨会开放一个窗口运行一些批量的查询,目前使用dg broker会在指定的时间把备库置为read-only,查询完毕之后修改为online状态。
今天处理了一个比较有意思的案例,说是有意思,因为涉及多个部门,但是哪个部门似乎都不愿意接。最后还是用了一些巧力,化干戈为玉帛。 问题的背景是这样的,业务部门需要做一个大查询,他们目前只拿到了部分账号的一个id字段的值,需要匹配得到一个类似手机号的字段值,开发部门提供了对应的sql语句,会关联两张表来匹配得到对的数据,然后反馈到DBA这里的时候就是最终的sql语句了,DBA查询得到数据,然后反馈给业务部门。
最近帮助开发的同学处理了一个简单的问题,想通过这个问题来反思一下。 在一天下午的时候,开发的同事突然找到我说,有一个开发的数据库貌似有些表空间的问题,尽管这个数据库是划分在他们名下,但是对于数据库的操作他们还是没底,想让我帮忙看看,当然对于这类问题,我都脑海里闪现一两分钟搞定问题的成就感了。
就在我提交文章的一瞬间,网络断了,然后我写了一个小时的文章就彻底失去了恢复的可能性。没有办法只能继续重来。 周日的阳光懒懒的晒在窗台上,今天注定是个慵懒的一天。 今天着实比较悠闲,从来没有这种感觉,可能是以前的生活节奏的缘故吧,总是绷着一根筋,很多时候都在想着一些技术问题该怎么搞。
之前写了第一篇Oracle 12c PDB浅析 http://blog.itpub.net/23718752/viewspace-1823792/? 在上次的基础上继续来学习学习。
我聊聊最近我的一些想法和感悟,想了一圈,发现还是选了这么个题目。当然这也只是一个开始,都是自己的真实想法。 有时候觉得我们有些矛盾,干着高科技的活,但是有时候还用着一些老土落后的思维方式,想想也还是蛮有意思。
很多时候,大家工作中都会有一种被动的思维,那就是能不动就不动,从求稳的角度来看无可厚非,但是从风险的角度来说,还是有待商榷的。如果存在风险,还保持原样很可能就是一个不定时炸弹。
今天开发的同事找到我,让我帮他们补一部分数据,因为有一个表的数据已经快一个月没有增量数据了,这个需求听起来有些奇怪是不? 问题的背景是在统计库中存在一个表,供部分应用做统计分析,每天会根据时间生成一条记录,这条记录汇总的数据会作为统计分析所用。
偶尔会停下来思考,也会总结一下,但是现在发现很多事情都在计划之外,计划之中的很多事情貌似都没有达标,如果按照一板一钉的要求,目前的情况是严重不达标啊。 每天感觉都还挺忙,看似比较简单的一个小问题就能折腾好一会儿。
在前几天也花了一点时间测试了一下关于备库数据文件的迁移,这部分的工作看起来还是比较常规的,当然方法也很多。但是在实际工作中就更不能掉以轻心,所有的操作都要有理有据。都要经过一些严格的测试,如果测试不当,很可能在后期就会出现一些看似奇怪的问题,造成一些不必要的麻烦和影响。
地心引力之前在电影院看过,但是再次看后,还是感触颇多,但是又感觉说不出来那种压抑。 影片就是在这种深邃中的神秘中开始的。 故事的大体情节是美国宇航员Matt Kowalsky和宇航员Ryan Stone出舱修复哈勃望远镜,因为俄罗斯自毁其秘密通信卫星,导致爆炸的碎片不断撞击太空的其他卫星和设施并产生了连锁反应。
关于移动数据库文件,之前写了一篇博文,http://blog.itpub.net/23718752/viewspace-1127910/ 但是在备库中还是有一些的差别。
因为最近需要做一个测试,就顺手搭建了一套简单的dg环境。不过碰到了一些小问题。 数据库环境是11gR2,备库是开在open状态,配置了dg broker,一切都很快完成了。
前几天碰到一个CPU负载较高的问题。从系统层面来看,情况不是很严重,但是从应用的角度来说,已经感觉到很慢了。因为前端的调用频率还是比较高。所以会把这个问题放大。 使用top -c查看了基本的服务器信息。
笔记写了不少,有时候有的朋友问我几个关键字,我就会从脑海里进行搜索,凡是写过的,搜索一下总能找到,帮助了别人,提高了自己,何乐而不为。 但是笔记写了很多,如果不加以改进,那么进步还是很小的,尤其比较怕的就是如果写出了问题的解决方案,但是这个解决方案是非主流的方式,可能有一些潜在风险的,如果误导了读者,那就是罪过了。
线上有一台服务器上,里面有一个mysql数据库服务,其实库也很小,就几个G,一直以来是保留了多天的备份集,但是因为业务的关系,这个库其实只有一些基本的数据查询,但奇怪的是没有从库,一直以来是每天都会备份,保留了近一周的备份集,这种情况也倒相安无事。
对于服务器的一些信息,如果数据量大了之后总是感觉力不从心,需要了解,但是感觉得到的这些信息不够清晰明了。 比如我们得到一台服务器,需要知道最基本的硬件配置,内存情况,磁盘空间情况,哪些磁盘空间问题需要关注,哪些磁盘空间问题可以忽略,swap的使用情况如何,服务器的操作系统版本,内核版本,上面运行有几个实例,是否启用了ASM,甚至服务器运行了多少天呢,这些信息看起来非常琐碎,也可以通过脚本得到,但是一直以来感觉都是比较笼统模糊。
最近看到一个报警,是显示某一个oracle的备库进程数达到了2000多个。ZABBIX-监控系统: ------------------------------------报警内容: Too many OS processes on ora_xxx@10.
继第一篇,第二篇介绍了关于元数据的一些想法,最近做了一些改进。 对于一部分的元数据抽取大体有下面的两种方式。假设数据源已经做了很大的努力,终于统一起来了。我们现在要通过ssh的方式从源端抽取出数据来。
今天在做节后的一个基本检查的时候,发现一个不太起眼的报警,报警内容为大体为: MySQL 每秒慢查询次数超过 个on xxxx 查看zabbix的监控数据,发现每秒竟然有10个左右的慢查询,按照这个量,这个数据库得存在多大的问题啊。
之前分享过一篇元数据管理的文章 http://blog.itpub.net/23718752/viewspace-1960938/ 如果服务器不多,或者人也不多,基本都是按照下面的方式来管理。
之前使用微信网页版,发现有些手机上以前的消息或者图文链接,如果想在电脑上再看看,这个时候只能再次发送一次消息或者链接,那么问题来了,自己给自己发送不了消息,发给谁呢。
今天留意到一封报警邮件。内容如下: ZABBIX-监控系统: ------------------------------------ 报警内容: CPU utilization is too high ---------------------------...
之前总结过一篇 通过错误的sql来测试推理sql的解析过程 http://blog.itpub.net/23718752/viewspace-1848816/ 也算是以毒攻毒,当然也分析出来一些有意思的内容来,让原本看起来枯燥的内容有了更多的实践意义。
突然之间我不由得想起几个场景,这些都是身边朋友说起的几个真实的小故事。当然我想表达的很多东西都在故事之外。虚脱的地铁换乘和漫长的公交路 我的一个朋友刚来北京的时候,也是背水一战来北京,希望找到一个自己的位子,然后他说自己当时连地铁都没有坐过,就稀里糊涂背着行李买了票,过了安检,然后在去往西直门的地铁上有一条长长的隧道,他说自己当时已经虚脱了,所以格外记得这种脆弱的感觉。
今天收到一条不太起眼的报警邮件,大体内容是某个表空间的空间有些紧张了。大体内容如下:Tablesapce: CMBI_SNZG_DATA: 92.2% [Warning!] 根据这个信息,很明显是需要添加数据文件了,但是同时还有一个警告就是磁盘空间也告警了,那么这个看起来简单的问题得好好琢磨琢磨了,其实是几件事,一件是做一些数据清理,释放部分表空间,甚至可以通过释放数据文件的空间来进一步释放磁盘空间,第二件是给表空间告警的表空间添加数据文件。
最近收到报警,某一个服务器的swap空间有些紧张,查看这台服务器上有两个备库数据库实例,当然负载还是很低的。但是目前来看,内存已经所剩无几,所以自然而然会用到swap,而且swap也看起来紧张了,从设计的角度来看,这种方式还是有很大的隐患,一旦需要切换,这台服务器还是很有可能出现oom-killer的情况,也就意味着宕机。
今天在计划外观看了《三打白骨精》,个人感觉还不错,我觉得还是值得推荐,而且看完之后还是有了不少的感触,大过节的,就不分析ORA-错误了,来聊聊电影和人生。 从我觉得总体的感觉来说,片子的制作质量还是不错的。
最近在无疑中查看一个数据库的日志的时候,发现里面有这么一段内容。 Sat Feb 06 10:07:25 2016 Deleted Oracle managed file +ARCH/testdb2/archivelog/2016_01_13/thread_1_seq_4566.
最近处理了一起看似比较奇怪的dataguard归档路径问题。 问题的背景是这样的。 有一套一主两备的环境,备库1和主库在同一个机房,可以尝试在failover的时候切换备库IP为主库IP。
在Oracle里面对于数据清理,如果是非分区表,目前我经常的处理思路是下面三个。 第一种是中规中矩,做好备份,然后开始清理,当然这种情况只是说明数据清理的部分,不考虑高水位线的影响。
在数据库中对于修改用户名,在11g以前一直有一种攻略,那就是修改数据字典基表user$,这种方式的优点就是简单粗暴,当然缺点就是后果不可控。至于有什么更多的风险,其实还是未知。
我们假设一个场景,当你接触到一个新的环境,我们需要了解这个数据库是否为RAC,是否有备库。 如果有备库,那么问题来了,如果想去验证备库的状态是否有效,是否及时应用了数据变更。
快过春节了,对于巡检工作真是非常重要的一环,也是考验巡检的力度的一种方式,及早发现问题,及时解决,就会避免很多“到时候再说”的问题。 当然公司层面也有一些巡检要求,我自己也总结了一下,发现还是需要写一部分,然后不断完善。
容灾的半自动化的部分,自己写了下面的脚本,也算是一个基本实现,因为时间仓促,还是存在一些不足,稍后完善 整个切换的步骤分为三部分,第一部分是备份当前备库的配置文件,第二部分是使用dg broker决定是failover还是switchover 第三部分是切换之后开始替换参数文件。
最近也在对容灾的切换做一些改进。 目前碰到的问题有 1.灾难切换后备库的内核参数设置不到位,导致切换后又潜在的性能问题 2.灾难切换后在同机房,网络相关的情况下,需要切换备库的IP为主库,但是跨机房,跨IDC可能不行,可以修改IP的情况下,对应用基本是透明,但是如果修改IP就需要应用修改配置。
目前遇到了一个问题,目前的是一主两备的环境,但是主库,备库中的存储空间都不足。而且硬件环境相对要老旧一些。想扩容难,系统版本老旧想升级也难。 数据库是基于10gR2,有异地灾备。
这几天看到《硅谷之谜》的时候,心里会有咯噔一下的感觉,原来这种看起来不太关心的领域之中竟然有这么多的传奇故事,当然书没有看完,也是泛泛而读,突然对里面很多公司的名字由来很感兴趣,那就简单来扒一扒。
当然重启服务发现CSSD服务是Online,但是ASM是无法启动。 [grid@testbi admin]$ crs_stat -t Name Type Target Stat...
最近碰到了一个关于ASM无法启动的案例,当然这个案例比较长,准备分两篇来写。 问题的背景如下: 目前存在一套standalone的环境,采用了ASM作为存储管理,业务属于实时统计,在某一天下班的时候开发的同事突然联系我说,数据库感觉有些问题,因为部分应用开始报错了,然后他们问我在这段时间做过什么操作没有,从我的印象来看下午4点只对部分分区做了例行维护,其它什么都没调整。
一年一度的年会如期举办,回到家里已经十一点多了,回家之后立马打开电脑还是补一补今天的作业。 对于互联网公司的年会一直耳闻,今天领教了,和传统公司的玩法真不一样。
之前也强调过元数据的重要性,而且强调过备库需要考虑的很多方面,如果考虑不周到,其实我们的备库还没有做好切换的准备,而且最近也连连处理了多起问题,发现灾备中还是有很多的思考的东西,所谓实践出真知,这些地方不注意,只能保证数据不丢失,对于业务连接,应用响应和影响范围来说都是不可估量的。