ITPub博客

针对之前在生产环境中使用sql*loader的性能问题，最近一直在想使用外部表的oracle_datapump来替代它。昨天下午做了大量数据的测试，比较了这两种方案。最后发现在一定的限定条件下，从很多细节来看 oracle_datapump要更胜一筹。首先使用sql*loader对于clob,blob的数据相比普通表的处理要一些额外的工作，但是这些限制或者...

继续昨天的部分，上一篇的链接为：http://blog.itpub.net/23718752/viewspace-1217012/对这条大sql的性能瓶颈进行了分析。主要瓶颈在于一个很大的业务表，数据量在亿级。如果通过时间条件来过滤，会有5%以内的数据被过滤出来。但是没有时间相关的索引字段，所以会走全表扫描，在目前的产品线中，这个大分区表的索引时严...

SELECT   DISTINCT CA.L9_CONVERGENCE_CODE AS ATB2,                CU.CUST_SUB_TYPE AS ACCOUNT_TYPE,                CST.DESCRIPTION AS ACCOUNT_TYPE_DESC,                SS....

在sql调优中，对于sql语句的实时监控显得尤为重要，如果某条sql语句的性能比较差。可能从前端的直观感觉就是执行时间比较长。对于dba来说，可能关注的相关因素需要多一些.1）可以通过top命令来监控sql的性能情况，查看cpu使用率较高的oracle process,然后通过查看session和process得绑定得到对应的session,然后得到对应的...

SQL>  create table t1 as select object_id,object_name from dba_objects where rownum create table t2 as select * from dba_objects;  Table created.SQL> create index t2_idx on t2(object_id);Index created.SQL>  exec dbms_stats.gather_tabl...

今天在生产中发现一条sql语句消耗了大量的cpu资源。  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                     &...

上一节讨论了在数据迁移中发现数据加载的速度一下子慢了很多，和之前在测试环境相比有很大的差距。一个原因就是由于在数据加载的过程中有一些额外的session也在操作访问数据库，造成了undo的使用率急剧上升，数据库负载从某种程度上也加剧了。通过查看awr,ash报告可以发现更多的内容。测试环境的数据库负载情况Load P...

在测试环境中进行了多轮测试，使用sqlldr批量加载数据，csv文件大概有120G左右，在一致的数据量的情况下，测试环境都在一个小时左右，但是在生产环境中竟然跑了将近2个小时，性能差了一倍。而且生产环境的服务器配置还要好一些。对于这个奇怪的问题，尽管说数据第一轮数据迁移已经完成了，对于之后的数据迁移还是很好的参...

今天客户说有一个job跑的特别慢。想看看到底是不是数据库这边有什么问题了。使用top来查看，io wait奖金30%，已经算是负载比较重的了。和客户确认从什么时候发现速度开始变慢的，他们说大概是从中午以后。使用sar来看一下，确实是从iowait从:1:00开始有了大量的io 10:40:01AM     &...

接着续上次提到的sqlldr的性能问题，加载一个表数据400多万条记录，竟然用了6个多小时。最后大家争论不休的时候，我发现应该是网络的问题。http://blog.itpub.net/23718752/viewspace-1182534/今天客户IT的同事把网络做了调整，他们就想看看到底改进有多大。下面是测试的一些记录。 àoriginal logs for issue ...

最近根据业务需要加载一批数据，在生产环境中不到半个小时就完了，可是到了测试环境，竟然跑了6个多小时，另外测试环境和生产环境的数据情况都基本差不多，主机配置也基本类似。大家的注意力都集中到了sqlldr的加载性能上。等到他们找到我时，已经讨论了不少关于direct,convention加载的各种情况了，看似工作也做了不少了...

在本地的环境中测试外部表的性能，由于空间有限，不一会儿归档的空间就爆了。然后文件貌似出现了系统级的问题，刚刚rm掉的归档日志文件。隔了几秒钟再ls，就出现了。怎么删都删不掉。尝试了多次之后，无奈尝试shutdown immediate结果等了好半天还是没反应，然后采用shutdown abort后重启，库直接起不来了。报了ora错误，然...

生产中有一个sql语句，做了union-all操作，对于时间的要求是极其严格的，目前已经从2秒的改进调整到了1秒以内，在此基础上还想做进一步的调整，因为极其频繁的查询，如果一丁点的改进都会在时间上的飞跃，以下的sql语句目前时间控制在不到半秒的样子。因为表SMALL_OFFER_PARAM 是一个数据字典表，查询的字段上没有相关的索...

接着昨天的那个问题来说。有个sql语句在做了统计信息收集之后，速度有了一定的提升，从5秒的响应降低到了2秒。但是和预期还是有一定的差距，按照80条查询请求在短时间内响应。2秒*80000次/60/60=44.4小时，本来感觉可以接受的一下子就成了大问题。 Elapsed Tim...

今天凌晨，又被电话叫醒了，说是有1个sql，现在跑的很慢。问题已经挺严重了，想让我看看，能不能做点什么。首先就是和他们确认最近有什么改动，他们说这个是用了很久的sql语句了，没有任何的改动，再听他们说，之前也没有任何的问题。然后就和他们确认之前这个jobl处理大概多长时间，那个哥们说他也是最近才进的这个项目...

昨天基本休息了一天，想着生产系统升级也会多多少少碰到些问题，肯定有一些心得或者是值得学习的东西，结果昨晚到现在生产系统升级一直为一个pl/sql的问题所困扰。在测试环境中只用了十多分钟， 在生产系统上跑了快5个小时。这个经历太痛苦了，大半夜还在考虑怎么优化真是痛苦。这个也算是一个很深刻的学习经验，和大家...

在平时的工作中，可能需要导入一些数据，有些表可能比较大，对于constraint的操作可能会耗费大量的时间，今天简单做了一些相关的测试，也提出了一些相关的优化方案，对结果进行比较，看看哪种才是比较合理的方法。 首先监控redo,undo的生成量也是衡量的一个标准。本次测试就简单从redo,undo,执行时间这三个方面进行总结。...

生产发现有一个sql语句运行耗时达5000多秒。抓出来sql_id一看,sql倒不是一个很长的语句。结构也很简单。如下。select company_code, sap_company_id  from data_company_code where company_code not in       (SELECT dist inct l9_company_code          F...

今天对表的update进行了性能测试，收获不小。在linux 64位的环境中测试，数据量是按照40万左右的标准进行的测试。SQL> select count(*)from test;  COUNT(*)----------    411426数据库在archive log 模式下。没有考虑索引（没有添加索引),没有考虑执行计划优化的影响，为了保证每次执行的环境基本...

top命令在linux环境维护中很实用，虽然功能缺失不够sar那么全面。今天和大家分享一个通过top命令来抓取性能sql的案例。通过top命令抓取了如下的信息。pid是3585的进程对应的sql 之前已经确定是性能问题导致的了，所以先放过，可以看看pid是8879的这个进程，出现的不是很“稳定”。可能通过ash,awr不一定能够及时的抓...