Oracle ACE,《Oracle DBA工作笔记》作者 现就职于国内某互联网公司,擅长数据管理,数据迁移,性能优化,目前专注于开源技术,运维自动化和性能优化。
今天快下班的时候,有个开发的同事问我一个问题,说他在客户端执行一条sql语句,里面包含子查询,如果单独执行子查询,会报"invalid identifier"的错误,但是整个sql语句一致性就没有错误,而且数据的结果还是正确的,碰到这种问题,想必都是信心满满,越是奇怪越想探个究竟。
生产系统中总是可能碰到各种各样的sql问题,其中大部分问题都和执行计划有关,执行计划出现问题有很多原因导致,比如统计信息过旧,比如数据的分布极不均匀等等都会导致执行计划出现很大的偏差。
有时候当你碰到一些问题一筹莫展的时候,如果能够看到某个帖子的问题和你碰到的刚好一致,那种欣喜的感觉真是难以形容。 但是有些问题尽管发生的错误一致,处理的方式却不同,举一个例子。
生产环境中有一条sql语句通过sql_monitor看到执行的时间实在是太惊人了,竟然达到了13个小时,而且还没有执行完。 Session APPC (20015:7013) SQL I...
在生产环境中有一些sql语句出现问题,大多是一些很紧急的问题,可能有些sql语句出现了执行计划的问题,通过hint能够做很大的改进,但是如果想让变更尽快生效,可以使用sql_profile来实现。
今天在检查生产库的问题的时候,收到开发的邮件,他们在运行一个job的时候报出了ora的错误,想让我们来看一下是什么原因。 ora错误是01652的错误,单纯来看是由于临时表空间不足造成的。
今天到公司以后,照例查看了数据库的负载情况,发现有一些异常。11点开始到12点的时候,数据库的负载格外的高。按照平时的经验,这个时间段内不会有太多的高峰业务在运行,为了简单验证,自己抓取了近几天的数据库负载情况。
数据库的性能调优,需要基于操作系统的性能指标,如果操作系统级发生了一些状况,那么会潜移默化的影响到数据库层面。而数据库中对应的进程和操作系统级也有一定的映射关系,在专有服务器模式下大体如此。
MySQL和Oracle虽然在架构上有很大的不同,但是如果从某些方面比较起来,它们有些方面也是相通的。 毕竟学习的主线是MySQL,所以会从MySQL的角度来对比Oracle的一些功能。
今天在对生产系统做监控的时候,发现一个process的cpu消耗很高,抓取了对应的session和执行的sql语句。 发现是一个简单的update语句,这样一条如果CPU消耗较大,很可能是由于全表扫描的。
昨天在做生产监控的时候发现有个库的表空间不够了,就发邮件给客户的dba去处理,但是得到的反馈是尝试添加的时候发现已经超过了数据文件的最大数限制。这个错误毫无疑问就是"ORA-00059: Maximum Number Of db_files Exceeded" 一看到这个问题,一下子感觉就头大了。
CPU可能对于我们来说是熟悉又陌生的,每天的工作基本都离不开CPU,CPU的消耗是系统负载的一个重要指标,每天都会不定时的来看看CPU的使用情况,但是对于它了解甚少。
在之前讨论过 关于oracle中session跟踪的总结,可以参见链接 http://blog.itpub.net/23718752/viewspace-1150568/ 基本的session跟踪方法都做了讨论,但是在实际应用中场景可能要复杂一些,比如我们可以对指定的session开诊断事件,如果session中运行的某个环节出现问题,可以根据诊断事件得到比较明细的递归sql来逐步查看排除,知道问题的根源。
近期客户希望提高业务处理能力,在现有的环境中加入几台weblogic服务器,所以需要增加一下连接数的配置,但是同时他们想对现有系统的设置一些变更,最后发送了一个清单给我们。
今天开发的同事问我一个问题,说有一个sql语句,在weblogic的日志中执行没有结果,但是手动拷贝数据到客户端执行,却能够查到。这种奇怪的问题一下子就能引起我的好奇心,从我知道的原因来看啊,可能是存在不可见字符造成的。
关于exp/imp,是很常用的数据导出导入工具,在10g开始推出的数据泵datapump相当于是exp/imp的补充和升级版本。在后续章节再做一个总结。 exp/imp的使用相对比较简单,通常用做在不同的数据库或者环境之间转移数据,即使数据库位于不同的平台,也可以通过统一的接口来做数据的导入导出工作。
今天突然发现vi虽然用了些日子了,但是常用的一些命令之外,还是有些命令比较生疏,简单总结了一下,然后自己在vi里面编辑了一把,效果还不错。 对于大家比较熟悉且常用的命令就没有再列举。
如果在前几年SSH火热的时候,提起Gavin King,那是如雷贯耳,现在虽然从事数据库管理的部分要多一些,感觉开发都快淡出了自己的能力范围了。但是看到Hibernate的故事还是让人热血沸腾。
在比较经典的表联结方法中,nested loop join和hash join是比较常用的,对于sort-merge join来说,可能略微有些陌生。 在数据库中有一个隐含参数,默认是开启的。
最近同事问我一个问题,是关于一个update语句的问题,需求有点特别,结果在使用update语句尝试了各种方法后,仍然是不依不饶的报出ORA-01779的错误。今天专门花时间分析了一下这个问题,还是有些收获。
今天有个同事问我一个问题,他说运行shell脚本的时候抛出了ORA 错误,但是对于错误的原因没有思路,想让我帮他看看。 我查看了下,脚本的结构比较清晰。 脚本是有一个shell脚本,一个sql文件组成,shell脚本作为基本的流程控制,sql文件中是pl/sql脚本。
前几天在做巡检的时候发现有个库的负载在某一个时间段内极高,高达100倍。一个10分钟的awr报告,得到的db time 却有1000分钟。 Snap Id Snap Time ...
前些天在看一本shell脚本攻略的时候,里面有一个章节是通过curl命令来访问gmail邮箱,我在本地反复尝试,看来还是google服务在大陆受限的原因,一直都不通。
昨天开发的同事找到我说,生产有个job处理数据的速度很慢,想让我帮忙看看是怎么回事,最近碰到这种问题相对比较多了,但是问题的原因也是五花八门。我还是大体找他们了解了下情况,说有一个Job是处理文件传输的,但是从目前的运行情况来看,处理速度很慢,基本没什么进展,我向他们确认这几天是否有数据变更的操作,他们说没有。
今天现场的开发同事反馈有一个job处理数据的速度很慢,从半夜2点开始运行,结果到了早上8点还没有运行完,最后无奈kill掉了进程。等我刚到公司,他们想让我查查倒底是什么原因导致的执行速度很慢。
昨天开发的一个同事找到我,说写了一条sql语句,但是执行了半个小时还没有执行完,想让我帮忙看看是怎么回事。 他大体上给我讲了下逻辑,表bl1_rc_rates是千万级数据量的表,autsu_subscriber 是个临时表,里面只有三百多条数据,bl1_activity_history 表的数据量略小,是百万级的。
在平时的调优工作中,在11g中的新特性sql monitor可以极大的简化性能监控的工作,对于执行时间超过5秒的sql语句都会记入v$sql_monitor中。 但是如果某个sql语句还没有执行,或者执行时间已经是几天前了,等发现性能问题进行调优的话就会比较困难,采用dbms_advisor.quick_tune是一个不错的选择。
awr报告对于dba而言是工作中重要的一部分内容,有些时候感觉跟去医院看病的化验单一样,各种指标和参数。有些高了,有些低了都是需要注意的内容。之前打印了一份awr报告,竟然有将近40页的样子,但是阅读awr报告也只能按照一定的思路来看,如果通读,那确实是云里雾里。
上周在升级的时候,客户反馈某个job报了下面的错误,想让我们查看一下是不是数据库这边有什么问题。 报错的内容如下。Caused by: java.sql.SQLRecoverableException: No more data to read from socket at oracle.
在系统环境中存在大量的文件时,统计磁盘空间的工作变得尤为重要。 首先是传统的文件统计,通常使用-s选项,但是只能得到一个概要的信息,如果想定位哪些文件消耗的空间较大还是比较麻烦的。
sequence在平时的工作中是一个默默无闻的角色。可能创建好之后很少会去修改它,它就在默默地自增长。直到一些特殊的原因导致sequence出现问题,比如提供了一个脚本,需要使用insert语句修复一些问题, 修复的语句类似insert into test values(100,xxxxxx,xxxx); 正确的写法应该是insert into test values(test_seq.nextval,xxxxxx,xxxx); 但是测试的时候也没有发现问题,就这样部署到生产中就出现问题了。
今天同事问我一个问题,他说问题的逻辑很清晰,但是感觉无从开始。问题的逻辑大体是这样的。 有一个表,存在着大量的数据,比如account_id为1代表account的编号,可以把这个account做暂停操作,相当于把账户冻结,然后在一定的时候后做恢复操作,相当于把账户解冻。
数组在各种编程语言中都是很重要的数据结构实现,在oracle中也有自己的一席之地。自己简单做了几个实验,发现很多东西还是眼高手低,真实去做的时候,里面还是有不少的细节的。
今天无意中看了下ORACLE_HOME/bin下面的东西,发现里面还是存在不少的东西。除了常用的sqlplus,tnsping,rman,exp/expdp,imp/impdp,sqlldr等命令外还是不少的命令可能平时不使用,但是一旦有需要还是很不错的工具集。
在平时上网的时候,发现有些图片不错,想保存到本地,一个一个的保存确实够费劲的,如果把整个网页都保存了,有些又是自己不需要的,就算下载下来了,还得从上百个网页元素中去筛选,哪些是css文件,哪些是js文件。
今天开发的一个同事找到我,说碰到一个比较奇怪的问题,有两个等价的查询类似下面的形式。 select *from test where account_id=xxxxxx order by creation_dateselect *from test where account_id=xxxxxx and entity_id=xxxxx order by creation_date 两个查询都会返回4条结果,但是第一个查询和第二个查询的结果排序结果不一致。
平时在工作学习中如果可以录屏的话,那么在以后能够再看真是很难得的学习资料。有些远程的操作都是命令行,如果使用录屏软件,可能占用的空间极大。其实Linux中可以通过命令行来实现屏幕录制和屏幕回放。
今天在翻看以前的笔记时,发现自己在很早之前写过一个java程序,能够解析日志中的sql语句。 当时使用的环境是weblogic,日志目录下总是有几十上百个日志文件,有时候排查问题的时候只需要找到对应的DML语句即可。
说起行列转换,大家是既熟悉又陌生,在oracle 10g版本之前如果要做行列转换,都基本得使用decode来完成,在11g中情况有了改观,可以直接使用pivot特性来完成。
虽然忙活了一年,但是今天审视自己在年初定的学习计划,自己也是好多作业没有完成。有些要求是简单了解,书都没找到,有些要求是熟悉,也都忘了看了。 2015年重拾2014年未完成的学习计划,也让自己在得瑟的时候明白自己其实好多都不会。
今天查看数据库负载没有发现问题,但是当我使用top命令的时候,发现有一个进程占用了大量的cpu资源而且已经执行很长时间了。这一下子引起了我的注意。 PID USER PR NI VIRT RES SHR S %CPU %MEM TI...
今天在中午的时候,收到客户的邮件,说数据库访问有问题了,赶紧连到生产环境查看。 结果在尝试登录的时候报了listener的错误,感觉像是listener停了一样。
在工作中,dump文件对于dba而言是再平常不过的文件了。 不过在导入dump文件的时候还是有很多的细节可以注意,可以避免一些不必要的问题。 exp/imp是比较经典的数据导出导入工具,不过自expdp/impdp推出以来,exp/imp还是受到了不少的冷落,在新的版本中,支持力度都集中在了expdp/impdp上面。
在平时的工作环境中,总会有一些表会存在依赖关系,比如我们有三张表customer,用户表subscriber,账户表account 其中客户可以有多个用户或者账户,subscriber表和account表中就存在外键customer_id指向了customer表。
在之前的章节中见到讨论过oracle中的半连接 http://blog.itpub.net/23718752/viewspace-1334483/ 与半连接相对应的是反连接,简而言之半连接就是查询条件中的in,exists,反连接就是not in, not exists这种类型的连接。
地铁票价在这周六开始就要上涨了,这几天做地铁明显感觉人比平常多了很多。大家也都在默默的等待这一刻的到来,尽管很不情愿,但是终究会来。 到时候肯定吐槽的人一抓一大把,毕竟一天上班4块的时代就要终结,一下子变成十几块,票价涨了,生活成本都在上涨,其它都没有变化,生活着实不容易啊。
在探究awr第一篇中介绍了awr的一些基本操作 http://blog.itpub.net/23718752/viewspace-1123134/ 在这一篇中,我们来分析几个awr报告来探究一下awr的一些信息,其实在报告中有很多的信息是可以互相印证的。
在之前写了一个shell脚本,能够得到一个基于时间点的数据库负载报告。 使用shell脚本查看数据库负载情况 http://blog.itpub.net/23718752/viewspace-1168027/ 在生产环境中快照的生成频率可能10分钟或者半个小时就会生成,频率要快些,使用原先的脚本执行起来会有一定的延时。
在之前写过两片关于sql语句分析足彩的。都从不同的角度提供了一些思路,之前是基于500场比赛的数据分析,为了数据分析的更加有说服性,我抽取了7000多场比赛的数据来作为分析的基础。
在平时的工作中,可能会碰到一种很奇怪的问题,本来在生产环境中有些sql语句执行没有问题,一个很普通的查询预期走了索引扫面,但是拷贝数据到其它环境之后,就发现却走了全表扫描。