Oracle ACE,《Oracle DBA工作笔记》作者 现就职于国内某互联网公司,擅长数据管理,数据迁移,性能优化,目前专注于开源技术,运维自动化和性能优化。
通过v$sql_monitor能够实时采集可能存在的sql性能问题,但是每次问题发生的时候采取采取措施就有点“晚”了,我们需要防患于未然,把一些潜在问题提前发现,并加以解决。
生产环境有一条sql语句执行比较频繁,占用了大量的cpu资源。原本执行需要花费11秒。在一次排查中引起了我的注意,决定看看cpu消耗到底在哪儿? sql语句是比较简单的,通过查询SUBSCRIBER_FA_V是一个视图。
在生产环境通过sql monitor监控到有一条sql执行效率很差。执行了大约5个小时,得到的sql monitor报告如下:Global Information: EXECUTING Instance ID ...
oracle的sql monitor是一个很有用的工具集。但是通过sql命令和反复去调用dbms_tune来传入参数等等操作感觉挺费事的。 可以通过如下的脚本来定位sql monitor中的性能sql,发现一些潜在的性能问题。
并行特性在数据库里对于性能的提升很有帮助,尤其是大批量的数据处理。今天对于并行的性能情况进行了简单的图表分析。 为了能够比较合理的比较数据,对数据库里的2张大表进行了比对分析。
使用sql*loader是大型项目中数据迁移的利器。如果是外部系统,其他数据库到oracle的数据迁移,使用文本式文件是最兼容的方式。 sqlldr的加载效率是很高的,同时在oracle 10g以后推出的oracle_loader效率也不容小视。
针对之前在生产环境中使用sql*loader的性能问题,最近一直在想使用外部表的oracle_datapump来替代它。 昨天下午做了大量数据的测试,比较了这两种方案。
今天需要在测试环境中做一些性能测试,为了不影响原有的数据,准备创建一个临时的schema。但是创建的时候报了如下的错误。 SQL> create user mig_perf identified by mig_perf; create user mig_pe...
对于clob的数据,很多场合中都使用xml的格式,但是对于数据的查取和处理总是感觉力不从心。在条件允许的情况下,如果能够巧妙的使用xmltype来做数据处理,无意中是对于clob的一个处理利器。
继续昨天的部分,上一篇的链接为: http://blog.itpub.net/23718752/viewspace-1217012/ 对这条大sql的性能瓶颈进行了分析。
在生产环境中有一条sql语句的性能极差,在早晨非高峰时段运行抽取数据,平均要花费40分钟,有时候竟然要跑10个多小时。sql语句比较长,需要点耐心往下看。我对表的数据量都做了简单的说明。
在sql调优中,对于sql语句的实时监控显得尤为重要,如果某条sql语句的性能比较差。可能从前端的直观感觉就是执行时间比较长。 对于dba来说,可能关注的相关因素需要多一些. 1)可以通过top命令来监控sql的性能情况,查看cpu使用率较高的oracle process,然后通过查看session和process得绑定得到对应的session,然后得到对应的sql语句。
今天看了老熊关于sql_profile的讲解,受益匪浅,自己在本机也做了一通,感觉好记性不如烂笔头还是得多总结总测试才能真正理解。准备的数据如下,创建两个表,一个大,一个小,然后做表分析 SQL> create table t1 as select objec...
目前做数据迁移,有8套不同的环境,为了保护环境,每个环境中的表,视图等开发都不能修改,只能通过连接用户去查询。 每个环境中可能含有表,索引,序列,存储过程,函数等,所以一个一个写是不现实的,写了下面的动态脚本来自动生成相应的权限,然后创建对应的同义词。
现在有一个需求,需要开放一些"特殊“的权限给开发组。 具体的背景是这样的: 有三个数据库用户,tabowner, tabconn, tab_temp三个用户 tableowner是owner用户,里面存放着表,索引,序列,存储过程等。
今天早上收到邮件,说有一个很紧急的问题,是关于sequence的。 错误日志里面还有ORA的错误 ----- ... 7 more Caused by: java.sql.SQLException: ORA-08004: sequence TRX_1SQ.NEXTVAL exceeds MAXVALUE and cannot be instantiated 猛一看就是sequence的值越界了。
现在有一个需求,输入一串数,输入的数个数还不固定,需要得到最小的那个数和对应的下标 如果说传入的数的个数固定,直接用for循环来得到最值 其实也不难。使用编程语言java,c等都可以实现。
在oracle的数据类型中,long类型算是一个比较另类的典型,早就不建议使用了,但是在数据字典里还是能看到long 类型的影子。 如果在一些工作中碰到long type就让人感觉long 类型像是被封杀了,会碰到不少的问题。
在工作中有时候碰到一些分区表,业务数据量很大,可能几百G,上T的规模,而且做数据的导入导出的时候,会感觉到exp/expdp的时候生成的dump文件太大了,做导入的时候也是很重的负担。
并行在平时工作中可能不是很注意,因为有时候即使设定了parallel 相关的hint,感觉性能也好不到哪去。这是我以前的感觉。 今天通过一个案例来分享一下通过parallel来使数据加载的速度达到极速提升。
上一节讨论了在数据迁移中发现数据加载的速度一下子慢了很多,和之前在测试环境相比有很大的差距。一个原因就是由于在数据加载的过程中有一些额外的session也在操作访问数据库,造成了undo的使用率急剧上升,数据库负载从某种程度上也加剧了。
在平时的工作中,desc这个命令可谓短小精悍,可以很方便的查看表结构和not null的情况。 今天在生产环境中碰到一个有些奇怪的desc问题。 首先是数据迁移组说有一个表的constraint丢了。
datapump是从oracle 10g推出的新的数据导入导出工具,可以说是exp/imp的加强版,主要的亮点在于服务端,结合了direct+parallel,而且从datapump的结构上来说也和exp/imp有很大的差别。
在测试环境中进行了多轮测试,使用sqlldr批量加载数据,csv文件大概有120G左右,在一致的数据量的情况下,测试环境都在一个小时左右,但是在生产环境中竟然跑了将近2个小时,性能差了一倍。
在测试环境中做了3轮数据迁移的演练,最终到了生产环境中,还是出现了不少问题,经过大半夜的奋战,终于是数据都迁移成功了。1)共享存储的配置问题 共享存储使用NFS来共享存储,但是在实际操作中发现配置出了问题,原因是因为两台服务器上的用户不同在,目标机器上没有任何写权限。
在生产环境中,做数据迁移需要考虑很多的可能性和场景,尽量排除可能发生的问题。我自己总结了下,大体有如下需要注意的地方。1)充分的测试,评估时间,总结经验,提升性能 在生产中进行数据的大批量迁移时,充分的测试时必须的。
最近做数据批量加载的时候,是通过pl/sql嵌在shell脚本里执行的。 脚本运行后生成的日志类似如下的格式 Get Dump file for APP_TMP.
昨晚对测试环境进行了升级,同步了部分生产的数据。整个过程比较顺利,但是在最后一步启用foreign key constraint的时候报了错误。 ora-02298:cannot validate(xxxx.xxxx_fk) -parent keys not found 很明显是一部分数据没有同步到,有一部分数据丢失了。
在升级的过程中,可能需要准备一些额外的脚本,比如说做数据迁移的时候为了考虑性能,需要做如下的额外工作: 1.将部分表置为nologging 2.将部分index置为nologging 3.将部分foreign key constraint置为disable 4.将部分trigger 置为disable 在完成数据升级后,再置为logging,enable状态。
在平时的工作中,有时候需要insert一批数据,这些数据可能是临时表,外部表,普通表,子查询等形式,类似下面的格式 insert into xxxx (select xxxxx from xxx where xxxxx); 如果其中有冗余数据的时候,整个Insert会自动rollback,一条数据也插不进去,错误类似下面的形式。
今天客户说有一个job跑的特别慢。想看看到底是不是数据库这边有什么问题了。 使用top来查看,io wait将近30%,已经算是负载比较重的了。 和客户确认从什么时候发现速度开始变慢的,他们说大概是从中午以后。
今天查看数据库的负载,发现cpu消耗异常的高。里面有不少dw的进程.但是查看impdp的进程却不存在。 查看datapump的进程情况,发现大量的job,但是状态都是not running.
今天碰到一个sql语句简化的问题,虽然也不复杂,但是也值得从中学习一些东西 SELECT MOD(((SELECT TO_NUMBER(TO_CHAR(LOGICAL_DATE, 'YYYY')) FROM SMALL_TAB ...
今天在做imp和impdp的性能测试时,发现如果表中存在lob字段,加载真是慢的厉害,每秒钟大概1000条的样子,按照这种速度,基本上不用干活了。 比如5千万条记录,50000000/1000/60/60=13.89小时,时间是无法接受的。
接着续上次提到的sqlldr的性能问题,加载一个表数据400多万条记录,竟然用了6个多小时。最后大家争论不休的时候,我发现应该是网络的问题。http://blog.itpub.net/23718752/viewspace-1182534/ 今天客户IT的同事把网络做了调整,他们就想看看到底改进有多大。
在数据库维护中,可能对于一个陌生的schema,需要了解它的一些情况,可以使用如下的脚本来很快得到一个报告,里面包含了详尽的信息。 用户占用的空间,权限,角色和基本配置信息。
在平时的工作中,需要了解服务器的硬件配置信息,对于cpu的信息查询,在Linux,unix中可能会有一些不同。 对于hp-ux来说,有现成的命令machinfo可以直接得到cpu的一些明细信息。
按照计划在周二开始了数据迁移,本来之前也做了不少的准备工作。但是还是在迁移的过程中出现了一些问题。简单做一个总结。 1.constraint导致的数据reject在数据加载的时候,报了如下的错误。
最近根据业务需要加载一批数据,在生产环境中不到半个小时就完了,可是到了测试环境,竟然跑了6个多小时,另外测试环境和生产环境的数据情况都基本差不多,主机配置也基本类似。
对于数据迁移来说,无论准备工作准备的多么充分,在测试和正式生产环境中,心里还是会对冲突的数据有一些疑虑,心里感觉没底,因为生产的数据也是在不断变化的,要迁移的数据也在做相应的改动,在这样的环境中,其实数据抽取的工作还是顾虑比较少的,只要侧重考虑性能的提升,而在于数据加载的过程中,如果出现主键冲突的字段,不仅会严重拖慢加载的速度,关键对于这些数据的处理,让开发和dba都很头疼,开发需要dba来提供详尽的信息,dba则需要多个team之间进行协调。
在并行生成了大量的dump文件后,可以在目标环境上对数据进行加载,这个加载的过程时间极短,都基本可以在毫秒级完成。 由于在外部表的加载过程中需要知道表结构的定义,所以可以通过如下的脚本得到表定义的基本语句,输出和desc类似。
在10g开始的新特性中,外部表是一个不容忽视的好工具。对于大型项目中海量数据使用sqlloader是一种全新的方式,不过很明显,sqlloader的可扩展性更强,但是基于oracle平台的数据迁移来说,外部表的性能也不错。
在本地的环境中测试外部表的性能,由于空间有限,不一会儿归档的空间就爆了。然后文件貌似出现了系统级的问题,刚刚rm掉的归档日志文件。隔了几秒钟再ls,就出现了。
关于Insert的问题,可能在一些场景中会有完全不同的期望和结果,在日常工作使用的库中,需要表在Logging模式,必要时需要一些索引 但在数据迁移中,可能为了提高速度,索引就需要考虑重建了。
创建index的时候,报了如下的错误。让人有些摸不着头脑。 create unique index t_pk on t(object_id,object_name) nologging ...
在本地的测试库中,本来空间就不足,结果创建了一个表有600多万条记录,想创建一个index. 物理段有340多M. 临时段大小有100M,结果想创建一个索引,总是报临时表空间不足的错误。
在数据库遇到性能问题的时候,可能从io,cpu等角度能够下手找到性能瓶颈,日志的切换也是影响性能的一个因素,如果日志切换台频繁,等待时间就会在日志相关的事件上,从数据库的角度来说,肯定是io的瓶颈。
生产中有一个sql语句,做了union-all操作,对于时间的要求是极其严格的,目前已经从2秒的改进调整到了1秒以内,在此基础上还想做进一步的调整,因为极其频繁的查询,如果一丁点的改进都会在时间上的飞跃,以下的sql语句目前时间控制在不到半秒的样子。
接着昨天的那个问题来说。有个sql语句在做了统计信息收集之后,速度有了一定的提升,从5秒的响应降低到了2秒。但是和预期还是有一定 的差距,按照80条查询请求在短时间内响应。
今天凌晨,又被电话叫醒了,说是有1个sql,现在跑的很慢。问题已经挺严重了,想让我看看,能不能做点什么。 首先就是和他们确认最近有什么改动,他们说这个是用了很久的sql语句了,没有任何的改动,再听他们说,之前也没有任何的问题。