alert日志中的一条ora警告信息的分析(59天)

今天照例检查数据库alert日志,发现一个错误。但是也没在意,想可能有大的操作导致的,马上会释放空间的,但是转眼一想,这是生产库,而且现在时早上,泰国的运营商还不算忙时,需要重视这个问题,看有没有什么潜在的问题,

从alert日志里面看到的

Fri Jul 12 09:08:23 ICT 2013
ORA-1652: unable to extend temp segment by 128 in tablespace                 TEMP

查询temp_usage,发现目前使用的只有goldengate的10多个session,占用的自用很少,查询现在的temp usage已经恢复正常了。

SQL> select TABLESPACE_NAME,TOTAL_BLOCKS,USED_BLOCKS,FREE_BLOCKS from v$sort_segment;
TABLESPACE_NAME                 TOTAL_BLOCKS USED_BLOCKS FREE_BLOCKS
------------------------------- ------------ ----------- -----------
TEMP                                 1023872        7936     1015936

导出awr报告,数据库整体负载很小。top sql里面看到的sql貌似都加了Hint,是被优化过的。

(awr报告时1小时一生成,可能有很多信息都不准确)

没办法,最后查ASH,精确到那一分钟,得到了以下的信息,

Service

Module

% Activity

Action

% Action

XXXX01

TOAD 9.6.1.1

83.08

UNNAMED

83.08

JDBC Thin Client

13.85

UNNAMED

13.85

并且发现下面的sql耗费了大量的资源,

Top SQL Statements

SQL ID

Planhash

% Activity

Event

% Event

SQL Text

7v8g1ffh5mwz7

3702571469

83.08

CPU + Wait for CPU

83.08

SELECT /*+ leading (ar1_charge...

d8x0ns0xjbrp9

1042878405

9.23

CPU + Wait for CPU

9.23

SELECT MT.SHORT_DESC, MO.ENTIT...

2979km1x69s3g

3257149028

1.54

CPU + Wait for CPU

1.54

SELECT AR_BALANCE FROM AR1_ACC..

猛一看,这个sql应用了大量的hint,细细一看,是一个很有问题的sql

关联了好几个大表,但是没有关联。

SQL details:

SQL Id

SQL Text

7v8g1ffh5mwz7

SELECT /*+ leading (xxxxx1 xxxx2 xxx3) use_nl (xxxxx1 xxxx2 xxx3) index (xxxxx1 xxxx2 _ix) index (xxxx2 xxxx2 _pk) */ xxxxx1 .CHARGE_ID, xxxxx2.debit_id, xxxx2.invoice_id, xxxx1.partition_id, xxxx1.period_key, ROW_NUMBER () OVER (ORDER BY xxxx2.DEBIT_ID DESC) RN FROMxxxx1, xxxx2, xxx3 WHERE xxxx1.ACCOUNT_ID = 10000027

最后马上和team里面确认了下,是有一个人执行的。

然后为了阻止隐患,为邮件给关联的team,对于sql的优化问题一点那个要优化转发到dba team。

看似一个很小的问题,可能包含着错误的操作。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2014-05-01

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏数据分析

SQL Server 性能优化之——T-SQL 临时表、表变量、UNION

这次看一下临时表,表变量和Union命令方面是否可以被优化呢? 一、临时表和表变量 很多数据库开发者使用临时表和表变量将代码分解成小块代码来简化复杂的逻辑。但是...

3664
来自专栏杨建荣的学习笔记

使用dbms_parallel_execute来完成DML的并行(r3笔记第1天)

在工作中使用并行可以极大的提高工作效率。可以Object,session.hint级别引入并行。可以使大量的数据处理更加高效。 比如现在有一个表 t 有10...

2786
来自专栏杨建荣的学习笔记

关于segment的一个小问题

今天统计数据的时候,发现一个奇怪的小问题,通过segment去判断一个表的大小,然后查表的count,有一个表明明在,但是从segment里面去查的时候查不出来...

3378
来自专栏携程技术中心

干货 | 一个MySQL 5.7 分区表性能下降的案例分析

作者简介 姜宇祥,2012年加入携程,10年数据库核心代码开发经验,相关开发涉及达梦,MySQL数据库。现致力于携程MySQL的底层研发,为特殊问题定位和处理提...

3937
来自专栏chenssy

MySQL事务隔离级别和Spring事务关系介绍

接下来一次来验证每个隔离级别的特性,首先我们先建一张表,我们建立账户表account用来测试我们的事务隔离级别:

784
来自专栏Jerry的SAP技术分享

编程面试题:编写一个会造成数据库死锁的应用

相信对于"开发一个会产生死锁的Java应用”这类需求,大家都能顺利完成。但是如果题目要求得更具体一些,要求这个死锁发生在数据库层面,应该怎样完成呢?

781
来自专栏乐沙弥的世界

dbms_stats 导入导出表统计信息

      在SQL tuning的过程中,不正确的或者过时的统计信息导致使用不正确的执行计划被采用的情况比比皆是。 当然对于这个情形,我们可以通过收集最新的统...

452
来自专栏沃趣科技

应用示例荟萃 | performance_schema全方位介绍(上)

经过前面6个篇幅的学习,相信大家对什么是performance_schema,已经初步形成了一个整体认识,但我想很多同行看完之前的文章之后可能还是一脸懵逼,今天...

1743
来自专栏杨建荣的学习笔记

MYSQL索引条件下推的简单测试

自MySQL 5.6开始,在索引方面有了一些改进,比如索引条件下推(Index condition pushdown,ICP),严格来说属于优化器层面的改进。 ...

2775
来自专栏大内老A

T-SQL Enhancement in SQL Server 2005[上篇]

较之前一版本,SQL Server 2005可以说是作出了根本性的革新。对于一般的编程人员来说,最具吸引力的一大特性就是实现了对CLR的寄宿,使我们可以使用任意...

1735

扫码关注云+社区