ITPub博客

在生产环境中哟一条sql语句，查看执行计划来看，效果还是可以接受的。sql语句类似下面的样子，可以看到里面还使用了比较纠结的外连接。从执行计划来说，默认是走nested loop join，数据的查取中会走索引，从oracle的分析来说这样的效果要好一些。  SELECT /*+ leading(cyc_cust,cyc_pay) */   CUST....

一般来说一条sql语句执行个4秒钟是可以接受的，没有什么问题，但是如果应该执行1秒，却执行了4秒，问题就挺大的了。今天查看数据库负载，发现在中午12:00 到1点之间，数据库的负载急剧增加，负载达到了百倍。Snap IdSnap TimeSessionsCursors/Session...

最近这一周以来，生产环境像是得了重病的病人一样，小问题没有修好，大问题不断。IO的等待极为严重。数据库的负载达到了几十倍，上百倍。weblogic和tuxedo在很大程度上都受到了影响，导致业务响应极为缓慢。在排查了中间件部门，数据库，存储，网络，操作系统等各个层面，也发现了存储的一些小问题，问题比较大的就是数...

目前在生产环境中有一个sql语句执行时间长达7分钟，而且执行频率极高。其中PROC_INST中有将近6千万的数据。其中STEP_INST是一个物化视图，里面还有5千多条数据。可以看到这个语句已经有了一些调优的痕迹，可以从里面的子查询和hint能够看出一些信息。SELECT PROC_INST.OBJID, PROC_INST.CREATION_TIME  FROM PROC_...

现在生产环境中目前有一个很大的中继表，作为多个流程的数据流动所用，数据量很大。里面有clob字段，加上庞大的数据量，表就显得很臃肿了。目前在做大批量的数据处理的时候发现了一些问题，事物数在不断增加的情况下，数据的处理速度也在不断的降低。最后出现了一些资源的问题。在抓取了awr和同事的分析之后，产品部门...

今天在生产环境中查看alert日志，发现了如下的一段错误。这个错误确实没有太多需要解释的。很明显就是因为session leak的经典问题。ORA-00020: maximum number of processes 5000 exceededORA-20 errors will not be written to the alert log for the next minute. Please look at trace files to see all ...

在数据迁移完成之后，开始了例行的后期数据库维护，早上一来就发现了一个sql执行时间很长了。达到了37279秒。最后在改进调优之后执行速度在1分钟以内。这个速度是毫无疑问的性能问题，但是是否是因为数据迁移直接导致的呢，通过简单的脚本分析，得出了如下的图表。显示了同样的sql语句在7月份至今的执行情况，还真是奇怪...

生产环境中有大量的sql语句在运行，尽管有awr,ash做数据的收集统计，但是dba的调优工作大多数情况都是在问题已经发生后做排查的，有些sql语句可能执行的时间有1,2分钟左右，但是sql语句本身有潜在的性能问题，通过awr是定位不到的，ash尽管能够查到，但是我们在未知的情况下怎么知道问题发生的精确时间点，通过sql monito...

在很多应用中如果数据量少有规模，都会有大量的分区表存在，使用比较多的是range partition.一般的range partition都一时间为键值，或者根据业务绑定的关键id值。虽然已经做了一些大数据量的数据迁移，但是不管是按照分区抽取，还是根据数据条数抽取，发现有一个表比较奇怪，一个100G左右的分区表，80%以上的数据都分布在...

在生产系统中，会发现一些潜在的sql问题，为了能够及时和准确的定位，我们可以借助sql_monitor来做性能sql的查找。可以在后台启用一个job不定时的去查找。毕竟大半夜的我们去监控也是有难度的，我们希望一切都能很自然的处理，结果我在一个指定的目录下每隔10分钟去查找一次性能sql，如果当天已经有生成报告就不重新生成...

在平时的工作中，数据库所处的文件系统是vxfs的话，可以考虑启用veritas的odm特性。ODM(Oracle Dsk Manager)是在oracle 9i之后开放出来管理数据文件，可以提高oracle数据库的输入输出数据吞吐量。Veritas提供了ODM的扩展，可以在VxFS文件系统的基础上，为oracle提供更高的读写速率和更简便的管理，其在VxFS文件系统上的...

昨晚在做测试环境数据迁移的时候，遇到了io的问题，本来预计2，3个小时完成的数据导入工作最后竟然耗了7个多小时。在数据的导入中，使用了10个并行的session，每个session都启用的并行度为8,在表级，索引级都做了nologging设置，在insert的时候使用了append模式，结果本来数据的导入还是比较顺利的，突然在8点左右开始就一...

今天在做数据迁移的时候，碰到了一个严重的问题，数据加载完全hang住了，最后无奈回退了。 系统使用的vxfs文件系统，在生产升级前一个月的时候，做过一次小规模的数据迁移，当时查看awr,ash，最后根据addm的推荐得出加载速度比较慢主要是由于异步IO导致的，而且当时生产库确实没有启用异步io, filesystemio_option的...

生产系统中有一条sql语句，目前执行的时间有点长了,SELECT COUNT(1)  FROM (         SELECT /*+ leading (payment_temp_table payment PAYMENT_DETAILS account memo) use_nl (payment_temp_table ar1_payment PAYMENT_DETAILS account memo) index (payment payment_pk) index (P...

今天在生产环境中发现一条sql语句尽管走了主键索引，但是查询还是很慢。sql语句类似下面的形式：SELECT /*+ index (bl1_cyc_payer_pop BL1_CYC_PAYER_POP_PK) */ T_TAX.BA_NO, T_TAX.TOTAL_TAX_AMT, T_TAX.TAX_RELATION, T_TAX_ITEM.TAX_ITEM_SEQ_NO, T_TAX_ITEM.TAX_SEQ_NO, T_TAX_...

生产中有一条sql语句消耗了大量的cpu资源，执行时间在18秒左右，Session:PRODBUSER (1560:61133)SQL ID:1hg2wcuapy3y3SQL Exec...

通过v$sql_monitor能够实时采集可能存在的sql性能问题，但是每次问题发生的时候采取采取措施就有点“晚”了，我们需要防患于未然，把一些潜在问题提前发现，并加以解决。如果有些sql执行很频繁，我们需要得到一个执行的报告，但是因为sql执行很频繁，每次都生成一个报告就显得有些过于消耗资源了。现在想达到的目标就是...

生产环境有一条sql语句执行比较频繁，占用了大量的cpu资源。在一次排查中引起了我的注意，决定看看cpu消耗到底在哪儿？sql语句是比较简单的，通过查询SUBSCRIBER_FA_V是一个视图。在视图中关联了几个和业务核心表。SELECT TO_CHAR(SUBSCRIBER_NO) SUBSCRIBER_ID,       SUB_STATUS,    ...

全表扫描 vs 索引

并行特性在数据库里对于性能的提升很有帮助，尤其是大批量的数据处理。今天对于并行的性能情况进行了简单的图表分析。为了能够比较合理的比较数据，对数据库里的2张大表进行了比对分析。测试的场景有以下两个。1.并行生成dump文件，比如一个大表有100G，使用并行，并行度为50 ，那么很可能会生成50个dump文件，每个dump...