Oracle ACE,《Oracle DBA工作笔记》作者 现就职于国内某互联网公司,擅长数据管理,数据迁移,性能优化,目前专注于开源技术,运维自动化和性能优化。
最近使用zabbix监控之后,都会在凌晨收到1台数据库服务器的报警短信,报警的内容为: No data received from Orabbix 这个错误其实就是orabbix通过jdbc已经接受不到数据库实例的信息了,但是隔了10来分钟之后,又会收到问题恢复的短信。
主键和Null看似没有多大的关系,因为一般的主键设置都是not null,但是把两者结合起来,会有很多意想不到的情况,说是意想不到是因为结果不在预期范围,但是如果明白了基本的原理,整个过程又在情理之中。
今天早上收到一条报警短信,提示是dg的接收出了问题,从v$dataguard_status得到的最新记录如下:2015-09-18 07:13:36.0 Fetch Archive LogErrorFAL[server, ARC1]: Error 270 cr...
最近处理一个问题的时候,先是收到DB time升高的报警,然后查看DB time的情况发现,已经有近1000%的负载了。 带着好奇心想看看到底是什么样的一个语句导致如此的情况。
今天收到一条报警短信,提示dg似乎出了点问题。信息的来源是从v$dataguard_status里面扫描得到的最新错误。 2015-09-15 22:06:19.
在上周五的时候,本来一个例行巡检,想扩充一些表空间,结果弄巧成拙,因为一个drop datafile的操作直接导致了一主两备的两个备库MRP直接抛出了ORA-600错误。
今天碰到了一个dataguard在10gR2的bug,不管怎么样确实是在特定的时间做了特定的操作结果碰到了特定的问题。 这个问题是在10gR2的版本10.2.0.4.0的一个库中出现的,在做巡检的时候发现表空间使用率已经很高了,就准备加一些数据文件把这个问题给修复了,按理说这也是一个常规操作,没有什么可圈圈点点的地方。
今天在部署一个脚本的时候,碰到了一个奇怪的问题,脚本运行过程中报了一个ora错误 ORA-01756: quoted string not properly terminated 看这个错误似乎是哪里的标点符号出了问题,没有正确结束,本来这个问题看起来很明显,很可能是格式的问题,但是奇怪的是插入中文,有的语句可以,有的就不可以。
在使用Orabbix监控Oracle的时候,本身和zaabix agent最大的不同便是使用Orabbix不需要对每个数据库实例都安装单独的agent,而是一个Orabbix实例可以对应多个数据库实例,Orabbix是基于JDBC的方式来实现的,基于此,配置的工作就尤为重要了。
前几天开发的同事反馈一个问题,说前台系统报出了ORA错误,希望我们能看看是什么原因。 java.sql.SQLException: ORA-01427: single-row subquery returns more than one row 我一看到这个错误的第一反应就是应该是sql语句的问题,然后开发同事反馈这个程序已经用了蛮长时间了,现在突然报出了错误。
接着上次分享的关于数据库无法登录的原因http://blog.itpub.net/23718752/viewspace-1791089/ 其实最终还是因为在短期内生成了大量的redo,造成了频繁的日志切换,导致归档占用了大量的空间,最后无法登录,从这个层面来说,我们可以做一些工作来尽可能长时间的保留近期的归档,但是我们还可以换一个思路,那就是看看到底是什么操作生成了大量的redo,能不能试着减少redo的生成量。
昨天接到了同事的一个电话,说有一个数据库无法访问了,希望能够让我来看看,赶紧连过去,发现错误还是一个看似很简单的ora错误。 $ sqlplus / as sysdba Copyright (c) 1982, 2011, Oracle.
虽然很少追美剧,但是有些美剧确实拍得很经典,让人不禁感慨万千,《迷失》是一部让人看了感觉看懂了,似乎又没明白的电视剧,而《绝命毒师》是一部看似疯狂但又在情理之中的电视剧,很多年前,带着紧俏的剧情,一直看到了第5季,最后的悬念久久没有公布,结果在去年终于有了一个剧情的落幕。
在前两篇的基础上,对于一个环境中存在的奇怪并行进程问题进行了初步的分析。 初步排除了是通过scheduler的job运行导致的,一方面因为运行的时间会有延迟,甚至有很大的差别。
前几天的并行问题自己分析了下,也算有了一些进展,但是目前还没有找到让人信服的理由,有些读者也比较关心这个问题,所以第二篇中会把自己的分析过程写出来,第三篇中应该会对这个问题做一个了结。
今天在处理一个问题的时候,需要根据其他部门提供的sql语句对一个表中的数据进行了筛查。 语句类似下面的形式 > SELECT MAX_LEVEL,LOGOUT_TIME,CURRENT_DATE AS NOWTIME,cn_master FROM t_tes...
使用sqlplus的时候如果命令敲错之后,可能很多情况下需要重新再敲一遍,也可以用一些快捷方式,但是如果想查看之前执行的sql语句,list选项就无能为力了,它只能够列出上一条执行的sql语句。
在使用orabbix进行监控的时候,得益于使用 实时DB time监控的选项,对于几分钟内的性能抖动也能够狠容易的记录下来,而且会把这个监控的结果基本真实反应出来,不会随着两个快照的间隔被平均,这样性能问题的分析和排查如虎添翼,我直接通过性能抖动的情况就能够快速定位在哪个时间段内可能存在问题,然后借助ASH就可以得到一个更具有针对性的报告,可以精确到1分钟甚至秒级。
关于ORA问题的分析和解决其实是一个很好的学习思路,抓住一个每一个ORA错误,然后进一步分析一些原因,总结,总会有不一样的收获,还是那句话,任何问题背后都是有原因的。
今天接到开发一个同事的电话,说前端系统那边反馈有一个查询很慢,初步怀疑是有一些并发或者锁之类的问题导致的。 接到问题之后,自己还是带着一些的紧迫感来处理的。 首先查看资源使用情况,使用top来检查,结果发现CPU使用率也不高,都在90%以上的idle 查看数据库的DB time情况,发现数据库的负载其实不高,但是还是有所提高,需要进一步关注。
在之前的博文中分享过通过结合python来发送图形报表邮件的例子。http://blog.itpub.net/23718752/viewspace-1776784/ 当然我们还是需要实现,意味着那些碰到的硬骨头都需要啃下来,大体的思路如下,每个步骤都有一些难点。
在使用rac的时候,有几个很闪亮的使用特性,一个就是load balance,这块毋庸置疑,确实做了很大的改进,从10g版本开始的多个vip地址的load balance,到11g版本中的进一步load balance改进 scan-ip,确实做了很大的简化。
说到问题,真是层出不穷,自己搭建了也不少的rac的环境的,但是在本地试验的时候总是会碰到一些问题,昨晚铲掉旧环境,搭建了两遍rac环境,终于在凌晨搭建好了环境,配置好EM,看了下效果,还不错,然后就把虚拟机设为suspend状态,早上打开虚拟机发现两个节点都自动停掉了,再次重启就启动不了了。
在我们查看awr报告的时候总是会有一个关键指标需要注意,那就是DB time,这个指标一般都是通过awr报告来看到的。 比如我们得到的awr报告头部显示的下面的信息,我们就清楚的知道DB time是1502.06 mins,相对于Elapsed time来说,将近有20倍的压力。
在使用监控系统报警的时候,如果显示的报警信息为纯粹的文本,会枯燥很多,而且看起来很不清晰。 比如我们要监控表空间的使用情况,输出列有表空间名,状态,区管理方式,总共的空间,使用的空间,剩余的空间等。
在数据库的运维工作中,如果有一种运筹帷幄的感觉,那么其中一种方式就是看报表,比如喝着咖啡缓缓打开电脑,几十台,上百台的机器的负载明细都在眼底。如果某个地方出现了异常或者明显的抖动,在报表中也能够很清晰的显示出来。
在之前的博客中分享过 简单定制Orabbix监控项 http://blog.itpub.net/23718752/viewspace-1769773/ 定制的功能在Orabbix中实现非常灵活而且轻巧,还是能够感受到一种开源风的清爽。
今天通过微信群和qq帮助一个网友分析了一个rac节点性能的问题,征得这位朋友的同学,和大家分享一下。 最开始这位朋友是在微信群中留言,说有一个rac的问题,现在已经严重影响在线业务了,希望我能够帮忙看看,有什么好的建议没,这对我来说着实是一个提高自己,分析问题的好机会,因为在地铁上,自己就简单确认了下环境,然后让他提供一些基本的错误日志或者报告。
如果是从10g转战11g rac就会发现很多不同之处,其中一个比较大的改变就是在11g中有了一个新特性scan,其实这是一个简称,完整的名称为:SCAN(Single Client Access Name),但是单纯根据简称理解为scan似乎也能说得通。
在很多时候我们都需要做一些对比测试,比如我们的机器换了一个平台,比如机器做了较大的硬件升级和改造,或者引入了第三方的软件服务等等,很多时候就需要做一个基准测试,想根据测试结果然后对比做了一些变更之后,性能是提升了还是下降了,或者提升了,提升幅度有多少,这个单纯来估算一个值既不科学也不准确。
从oracle中ASM的发展来看,到今天的普及使用,应该可以算做一种文化,因为这体现的不仅是ASM技术在实际工作中的成功普及,而且从某种程度来说,都代表了一个新生事物的发展历程,无论是java的发展还是各种开源项目的普及,都有着相似的痕迹。
对于Orabbix监控Oracle来说,它是提供了一个相对轻量级的客户端来综合监控多个数据库实例。从这一点来看,它的角色有点类似于工作中使用的SQLDeveloper或者toad这类的工具。
Orabbix是在zabbix的基础上提供的一套插件,能够提供对Oracle的监控功能真是术业有专攻,在Oracle层面zabbix希望也能够走得更远,所以对于Oracle的支持还是比较开放的,而对于Orabbix和zabbix server,zabbix agent的关联关系,可以使用下面的图形来表示,能够说明大体的意思。
在IT行业始终在进行着开源和商业的竞争而且双方火力都不差,开源的受众更多是中小企业,免费开源而且用户基数庞大,商业的用户都是一些大中型企业,求稳求成熟的服务。 今天来浅谈一下zabbix和Grid control,限于自己的认识有限,所以先开个题,zabbix也在熟悉和使用中,后续继续补全和更正。
数据库的巡检是DBA工作中的一部分,有时候我们还是希望能够在巡检的基础上发现一些潜在的问题,把尽可能多的问题解决在初始阶段。 今天来给大家举一个数据库巡检和性能分析的例子。
在之前做一个测试演示的时候,使用的是11gR2的库,在说rman的备份配置的时候有一个功能时控制文件的自动备份, CONFIGURE CONTROLFILE AUTOBACKUP ON/OFF; 然后自己简单介绍了下,说controlfile autobackup功能还是蛮实用的,一般还是建议开启。
今天在巡检系统的时候,发现alert日志中有两种类型的ora错误。 Errors in file /U01/app/oracle/diag/rdbms/XX/XX/trace/xxdb_j002_20401.
自己最近也在琢磨如何搭建出一个完善有效的运维平台,当然这个工作不是一朝一夕就能完成,前行的道路上肯定会有各种各样的困难和牵绊,但是自己还是能够学以致用,把一些重复性,繁琐性的工作都能解放出来,能够更加关注于更高的一个层级来看待整个系统。
在平时的工作中,如果接手的环境多了之后,每天去尝试连接服务器,都是例行的步骤,时间长了之后就会感觉这些工作都是繁琐重复的工作,其实我们可以尝试让工作更简化,更高效一些。
今天在梳理服务器的信息的时候,发现有一台服务器没有设置crontab作业,一般的服务器中可能会需要一些定时的任务来触发一些备份,清理等等工作。 因为这是一台备库机器,上面有11gR2的备库,所以首要工作就是查看是否在正常应用日志。
在很多的时候,随着工作的持续开展,可能会接手更多的服务器资源,这个时候我们手里就不但是一两台服务器那么简单,可能几十个,上百个,甚至上千个,这个时候服务器信息的维护就变得额外重要,抛开业务线的规划,对于DBA来说,掌握服务器的信息,做到知根知底,才能在问题发生的时候合理处理问题。
rman在数据的备份恢复中还是发挥了重大的作用,把冷备,热备这种手工备份方式做了集成化的管理,可以基于这个工具集完成相对复杂额备份恢复工作。 当然了rman相对于传统的手工备份,提供了更多的改进, 比如压缩备份,我们手工测试的场景中,一个1.5G的小库,如果数据文件的使用率不到300M,那么生成的dump就在近300M,如果开启压缩备份的方式,生成的备份集差不多会在80M左右,改进的幅度还是很大的。
有一个很常规的问题大量出现在笔试面试中,就是delete,truncate和drop的区别,当然这个问题我们也可以升华一下,通过这个简单的问题其实可以关联到Oracle的一些特性。
在工作环境中有一台gc的服务器,已经好几年没有动过了,上面安装着gc的服务和数据库,也就说gc里面的HttpServer,数据库,webcache都在这台服务器上。
在数据库环境中,一主一备是比较传统的使用方式,在灾难发生的时候,可以灵活的切换主备角色,依然可以保持服务的可访问性。但是一些核心系统来说还是会有更多的过滤,一主一备似乎还是不够稳妥,如果主备出现问题,如果有另外一个备库还是有可选的余地,这种情况不是不可能发生,正是因为核心业务的需要还是需要保证数据的安全。
11g的dataguard相比于10g来说,最优越的特性应该算就是active dataguard了,这一点改进在很大意义上促使用户需要把数据库从10g升级到11g,读写分离在这个时候得到了升华,而且在后台会根据需要进行数据的同步,相比于使用10g,想读数据的时候把数据库启动到read only 阶段,但这个时候不接受日志同步数据,如果需要同步数据还需要把数据库再启动到mount阶段,感觉还是比较繁琐的。
在工作之余,也给大家推荐几部日本电影,可能一说起日本电影,都会不由得和情色联系起来,可能我要推荐的电影要让你失望了。不过不妨在自己闲暇之余看一看,还是很有收获的。
今天在一台备库机器上准备搭建active data guard ,在主库上做配置的时候,发现主库的反应有些慢,主要的感觉就是敲命令的时候似乎都有些停顿。 带着疑问查看了下数据库的负载情况,发现连进来的用户很少,数据库负载也很低,归档每天切换不到20次 但是使用top命令查看的时候还是能够看到kswapd1的身影,这个进程是一个性能出现问题的标志,因为在之前的一个项目中因为配置hugepage出现问题,结果导致系统出现了严重的swap现象,当时的top 进程就是kswapd这样的进程。
说到不完全恢复,一般有三种场景,基于时间点的不完全恢复,基于scn的不完全恢复,基于cancel的不完全恢复。 三种情况都是不完全恢复采用的方式,而不完全恢复都是在完全恢复的过程中出现了这样那样的错误,数不胜数,基本就是归档,redo损坏丢失,控制文件丢失,备份的问题,手工失误等等。
在数据的备份恢复中,基本都在使用rman来做了,但是从数据库的内部原理来说,对于介质恢复,其实还是做两件事,restore和recover. restore是一个类似物理文件的复制,而recover则在数据库后台根据scn做相关的数据恢复。