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 monitor的使用(一) (r2第30天)

在sql调优中,对于sql语句的实时监控显得尤为重要,如果某条sql语句的性能比较差。可能从前端的直观感觉就是执行时间比较长。 对于dba来说,可能关注的相关因...

2685
来自专栏wOw的Android小站

[设计模式]之七:命令模式

将请求封装成一个对象,从而使你可用不同的请求对客户进行参数化;对请求排队或者请求日志,以及支持可撤销的操作。

482
来自专栏拭心的安卓进阶之路

Android 进阶12:进程通信之 Socket (顺便回顾 TCP UDP)

不要害怕困难,这是你进步的机会! 前面几篇文章我们介绍了 AIDL 、Binder、Messenger 以及 ContentProvider 实现进程通信的方式...

2117
来自专栏恰同学骚年

.NET Core微服务之基于MassTransit实现数据最终一致性(Part 2)

  在上一篇中,我们了解了MassTransit这个开源组件的基本用法,这一篇我们结合一个小案例来了解在ASP.NET Core中如何借助MassTransit...

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

一条执行4秒的sql语句导致的系统问题(r3笔记第10天)

一般来说一条sql语句执行个4秒钟是可以接受的,没有什么问题,但是如果应该执行1秒,却执行了4秒,问题就挺大的了。 今天查看数据库负载,发现在中午12:00 ...

3478
来自专栏数据和云

极限优化:从75到2000,由技能到性能提升岂止80倍

崔华,网名 dbsnake Oracle ACE Director,ACOUG 核心专家 编辑手记:感谢崔华授权我们独家转载其精品文章,也欢迎大家向“Oracl...

2395
来自专栏大内老A

WCF后续之旅(1): WCF是如何通过Binding进行通信的

《我的WCF之旅》系列自开篇以来,得到了园子里很多朋友的厚爱,并荣登了博客园2007年度系列博文Top 10。由于工作原因,沉寂了几个月,今天开始WCF新的旅程...

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

生产环境sql语句调优实战第七篇(r2笔记99天)

在数据迁移完成之后,开始了例行的后期数据库维护,早上一来就发现了一个sql执行时间很长了。达到了37279秒。最后在改进调优之后执行速度在1分钟以内。 这个速度...

3278
来自专栏乐沙弥的世界

Heap size 80869K exceeds notification threshold (51200K)

      前阵子的alert日志获得了所需堆尺寸的大小超出指定阙值的提示,即Heap size 80869K exceeds notification thr...

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

undo retention的思考(一)

最近有个网友咨询我一个问题,是关于undo_retention的,对于这个参数没有过多关注,只是知道需要设置undo_retention搭配使用undotabl...

3105

扫描关注云+社区