精华内容
下载资源
问答
  • oracle消耗资源sql查询语句记录
  • 今天要验证一个Full table scan问题的patch,需要分析一下sql执行情况,用到...Oracle sql语句资源消耗监控,最常用的系统视图有: v$sql v$sqlarea v$sqltext v$session   v$sql与v$sqlarea基本相同,记录共享


    今天要验证一个Full table scan问题的patch,需要分析一下sql执行情况,用到了v$sqlarea视图,感觉这篇文章讲得挺明白,摘抄一部分做个读书笔记。

    1       常用视图说明

    Oracle sql语句资源消耗监控,最常用的系统视图有:

    v$sql

    v$sqlarea

    v$sqltext

    v$session

     

    v$sql与v$sqlarea基本相同,记录共享sql区(share pool)中sql统计信息,如内存消耗、IO(物流磁盘读和逻辑内存读)、排序操作、哈希ID等数据。不同之处在于v$sql为每一条sql保留一个条目,而v$sqlarea中根据sql_text进行group by,统计列进行sum(),通过version_count计算子指针的个数。

             Sql_text相同的sql语句在数据库中意义可能完全不同,此时,v$sql会有这两条完全一样的sql各自的统计信息,而在v$sqlarea中sql_text相同的2个指针会合并,执行次数,DISK_READS,BUFFER_GETS等统计信息会累加,这就是v$sqlarea的聚合作用

             v$sqltext中没有统计信息,却存储着完整的sql语言及其哈希ID等。

             v$session主要用来确定会话相关信息,如通过SID和SERIAL来确定一个Session、会话拥有者用户名username、会话状态、会话由哪个客户端发起、正在执行什么sql(通过sql_address、sql_hash_value、sql_id、sql_child_number确定,再借助v$sqltext就可以知道)、锁等待相关信息(如所在表、文件、块、被锁行)等。

            

    查看视图原表:

    SELECTview_definition FROM v$fixed_view_definition WHERE view_name='GV$SQL';

    SELECTview_definition FROM v$fixed_view_definition WHERE view_name='GV$SQLAREA';

    SELECTview_definition FROM v$fixed_view_definition WHERE view_name='GV$SQLTEXT';

            视图名为v$sql但该视图的源又是GV$sql,所以直接使用GV$SQL,其他两个也如此。

     

    2       视图重要字段

    2.1      v$sqlarea

    sql_text: sql 语句的前1000个字符

    sql_fulltext: sql语句的所有字符

    sql_id:缓存在高速缓冲区中的sql父游标的唯一标识ID

    sorts: 语句执行导致的排序次数

    version_count:在缓存中以该语句为父语句的子游标总数

    executions: 包含所有子游标在内该sql语句共执行次数

    parse_calls:父游标下所有子游标解析调用次数

    disk_reads: 该语句通过所有子游标导致的读磁盘次数

    address:当前游标父句柄

    hash_value: 该语句在library cache中的hash值

    2.2      v$sqltext

    address: 当前游标父句柄

    hash_value:该游标在library cache中唯一hash值

    3       高资源消耗sql定位

    3.1      查看读硬盘多或占用内存可能多的sql

    Selectsql_text,disk_reads,buffer_gets,parsing_scheme_name,executions

    From v$sqlarea

    Order by disk_reads desc

    单纯从v$sqlarea 中无法查出每个sql消耗的内存量,但可以借助磁盘读次数间接反映可能的消耗内存较大的sql语句,然后借助执行计划(v$sql_plan)具体查看。

    3.2      查看执行次数多的sql

    Selectsql_text,executions,parsing_schema_name

    From v$sqlarea

    Order by executions desc;

    3.3      查看排序多的sql

    Select sql_text,sorts,parsing_schema_name

    From v$sqlarea

    Order by sorts desc;

     

    摘自:http://www.ecdoer.com/post/oracle-highcost-sql-locate.html

    展开全文
  • Oracle系统SQL消耗大量资源(bsa0wjtftg3uw) top sql第一条是select file# from file$ where ts#=:1 现象: 客户反馈AWR中TOPSQL第一条为系统SQL:select file# from file$ where ts#=:1。 客户的系统是比较繁忙的...
    Oracle系统SQL消耗大量资源(bsa0wjtftg3uw)
    
    top sql第一条是select file# from file$ where ts#=:1
    现象:
    客户反馈AWR中TOPSQL第一条为系统SQL:select file# from file$ where ts#=:1。
    客户的系统是比较繁忙的系统,该AWR报告取样自业务高峰期。
    WORKLOAD REPOSITORY report for
    DB Name DB Id Instance Inst num Release RAC Host
    EDI 2695423743 EDI 1 10.2.0.2.0 NO dssdb01

    Snap Id Snap Time Sessions Cursors/Session
    Begin Snap: 32286 20-May-13 07:49:14 205 65.8
    End Snap: 32287 20-May-13 08:54:47 210 72.1
    Elapsed: 65.55 (mins)
    DB Time: 1,375.64 (mins)

    Top 5 Timed Events

    Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
    PX Deq Credit: send blkd 215,620 24,567 114 29.8 Other
    CPU time 14,962 18.1
    enq: CF - contention 147,525 10,324 70 12.5 Other
    db file sequential read 1,472,843 7,988 5 9.7 User I/O
    log file sync 119,120 7,308 61 8.9 Commit

    SQL ordered by Gets

    Buffer Gets Executions Gets per Exec %Total CPU Time (s) Elapsed Time (s) SQL Id SQL Module SQL Text
    123,784,076 143,834 860.60 33.58 988.01 1023.40 bsa0wjtftg3uw select file# from file$ where ... <<<<<<<<<<<<<<<< Here!

    bsa0wjtftg3uw ==> select file# from file$ where ts#=:1
    该SQL在一个小时时间内执行了1023秒。

    分析:
    在metalink上发现有几个相关的BUG,但版本对应不上,不过根据BUG的说明信息我们可以窥得Oracle处理文件方面的一些内部机制。
    1.Bug 14309390 - High CPU usage / Mutex Contention with Recursive statement on FILE$ (Doc ID 14309390.8)
    Range: Versions >= 11.2 but BELOW 12.1
    Recursive statement SQLID bsa0wjtftg3uw 'select file# from file$ where ts#=:1'
    which is executed during tablespace operations can cause a high mutex contention / high CPU usage

    2.Bug 13520452 - Recursive statement on FILE$ causes a huge workload - superseded (Doc ID 13520452.8)
    Recursive statement 'select file# from file$ where ts#=:1' which is executed
    inside the tbsfnl() function can cause high workload.

    Rediscovery Notes:
    High workload due to 'select file# from file$ where ts#=:1'
    The select shows a FULL scan of FILE$

    3.Bug 13520452 : RECURSIVE STATEMENT ON FILE$ CAUSES A HUGE WORKLOAD

    INTERNAL PROBLEM DESCRIPTION:
    @The statement 'select file# from file$ where ts#=:1' is executed inside tbsfnl
    @ function while performing tablespace alter operations, to fetch the file info
    @rmation corresponding to the tablespace. tbsfnl is also called while adding ex
    @tent where we choose the best file to allocate space for extent, once per each
    @ extent allocation. As the number of files inside tablespace increase, executi
    @on of the above statement may impact performance.
    <===这段说明了该SQL一般在tbsfnl函数中被执行(执行alter tablespace操作时),在为段分配extent时也会执行以选择适合的文件创建extent
    @INTERNAL FIX DESCRIPTION:
    @File information per tablespace is maintained by Recovery(rcv) layer in SGA. W
    @e are fetching file list per tablespace using the cached information.
    <===在11.2.0.3,Oracle提供patch包修复这个BUG,修复之后不需要再执行SQL bsa0wjtftg3uw,而是将数据文件信息直接缓存起来,通过直接查看缓存信息获取数据文件信息,此举避免了上述系统SQL的大量执行。

    REDISCOVERY INFORMATION:
    High workload due to 'select file# from file$ where ts#=:1'


    Q:Which program generated below recursive statements and takes lots of buffer gets?
    bsa0wjtftg3uw ==> select file# from file$ where ts#=:1

    A:
    'bsa0wjtftg3uw' is an oracle internal recursive SQL, which is executed during tablespace operations.

    The statement 'select file# from file$ where ts#=:1' is executed inside tbsfnl function while performing tablespace alter operations, to fetch the file information corresponding to the tablespace. tbsfnl is also called while adding extent where we choose the best file to allocate space for extent, once per each extent allocation. As the number of files inside tablespace increase, execution of the above statement may impact performance.
    Disable autoexetend can do some help to reduce the SQL, but operation like creating table also need to query the tablespace information.
    现在我们大致了解了这条系统SQL产生的几个原因,排除了BUG因素,我们需要检查:
    1.alert日志,对应时间段是否有alter tablespace操作,例如add datafile。  <== NO
    2.查看AWR,是否存在许多insert,造成需要扩充段空间(add extent)。      <== yes
    3.检查是否有数据文件为autoextend。                                     <== no

    TOPSQL中确实有几条INSERT,并且据客户介绍这个系统是OLAP系统,在繁忙时间段有很多抽数操作,需要将其他系统的数据抽进来,插入到数据库中,
    因此比较符合第2点推测,如下:

    SQL ordered by Gets
    Buffer Gets Executions Gets per Exec %Total CPU Time (s) Elapsed Time (s) SQL Id SQL Module SQL Text
    ...
    13,996,731 109,095 128.30 3.80 586.11 1708.30 b2cfm5jm9888j GP4MSOX3DWK74QT9KQ0S2LNJLU0 INSERT INTO "/BIC/AMM00_O2900"...
    10,222,371 126,034 81.11 2.77 494.23 1396.76 fqwvuf7w3kk7d GP4NBPK14Z49C1BR3I63Q5TQY4O INSERT INTO "/BIC/B0003586000"...
    9,017,859 471 19,146.20 2.45 33.79 178.54 5xxbw9gqqugr7 CL_RSBC_FILTER_CMD============CP INSERT INTO "D010TAB" ( "MASTE...
    ...

    以上平均每条insert的逻辑读在100次以上,推测是在执行insert的时候需要为表段分配新的分区(extent),导致了SQL bsa0wjtftg3uw的执行,带来了额外的逻辑读。
    口说无凭,实验说明一切,做了个简单测试:
    1. Create a new table t2 and try insert some data. Note: there are any extents allocation occurs in the session
    ====================
    SQL> create table t2 as select * from dba_objects where 1=2;

    SQL> select count(*) from dba_extents where owner='EDISON' and segment_name='T2';

     COUNT(*)
    ----------
     1

    SQL> alter session set timed_statistics = true;

    Session altered.

    SQL> alter session set statistics_level=all;

    Session altered.

    SQL> alter session set max_dump_file_size = unlimited;

    Session altered.

    SQL> alter session set events '10046 trace name context forever, level 12';

    Session altered.

    SQL> insert into t2 select * from dba_objects;

    51268 rows created.

    SQL> insert into t2 select * from t2;

    51268 rows created.

    SQL> /

    102536 rows created.

    SQL> alter session set events '10046 trace name context off';

    Session altered.

    SQL> select count(*) from dba_extents where owner='EDISON' and segment_name='T2';  <===分配了38个extent

     COUNT(*)
    ----------
     38

    检查trc文件:

    select file# from file$ where ts#=:1                    <===执行了72次

    call count cpu elapsed disk query current rows
    ------- ------ -------- ---------- ---------- ---------- ---------- ----------
    Parse 72 0.00 0.01 0 0 0 0
    Execute 72 0.00 0.00 0 0 0 0
    Fetch 144 0.00 0.00 0 288 0 72
    ------- ------ -------- ---------- ---------- ---------- ---------- ----------
    total 288 0.00 0.01 0 288 0 72


    2. 删除所有数据,但不回收EXTENT
    ====================
    SQL> delete from t2;

    205072 rows deleted.

    SQL> commit;

    Commit complete.

    SQL> select count(*) from dba_extents where owner='EDISON' and segment_name='T2';

     COUNT(*)
    ----------
     38

    SQL> alter session set timed_statistics = true;

    Session altered.

    SQL> alter session set statistics_level=all;

    Session altered.

    SQL> alter session set max_dump_file_size = unlimited;

    Session altered.

    SQL> alter session set events '10046 trace name context forever, level 12';

    Session altered.

    SQL> insert into t2 select * from dba_objects;

    51268 rows created.

    SQL> insert into t2 select * from t2;

    51268 rows created.

    SQL> commit;

    Commit complete.

    SQL> alter session set events '10046 trace name context off';

    Session altered.

    SQL> select count(*) from dba_extents where owner='EDISON' and segment_name='T2';

     COUNT(*)
    ----------
     38

    检查trc文件,未发现有select file# from file$ where ts#=:1 执行。

    解决方法:
    1.将表的NEXT属性调大避免多次分配extent。
    ALTER TABLE T2 STORAGE(NEXT NM);
    2.手动为表分配extent
    ALTER TABLE T2 ALLOCATE EXTENT ALLOCATE EXTENT (SIZE NM);

    展开全文
  • Oracle资源消耗SQL语句定位

    千次阅读 2015-05-29 15:31:32
    Oracle SQL语句资源消耗监控最常用的系统视图有v$sql、v$sqlarea、v$sqltext和v$session。本文我们先了解这些视图的作用与区别,然后了解如何定位高资源消耗SQL语句,最后再了解一下各视图字段具体含义。 相关...


    文章目录

    Oracle SQL语句资源消耗监控最常用的系统视图有v$sql、v$sqlarea、v$sqltext和v$session。本文我们先了解这些视图的作用与区别,然后了解如何定位高资源消耗SQL语句,最后再了解一下各视图字段具体含义。

    相关系统视图功能与区别

    v$sql和v$sqlarea基本相同,记录了共享SQL区(share pool)中SQL统计信息,如内存消耗、IO(物理磁盘读和逻辑内存读)、排序操作、哈希ID等数据。不同之处在于v$sql为每一条SQL保留一个条目,而v$sqlarea中根据sql_text(需要注意,该处存储的为当前SQL指针的前1000个字符,也就是说这里记录的SQL可能是不完整的!)进行group by,统计列进行sum(),通过version_count计算子指针的个数。

    然而,文本(sql_text)相同的SQL语句在数据库中意义可能完全不同。比如数据库中存在两个用户User1和User2,这两个用户各拥有一张数据表EMP。那么当两个用户发出查询select count(*) from emp;时各自访问自己SCHEMA中的表EMP,而两者表内容不同所以其资源消耗肯定也不同。此时,在v$sql中会有这两条完全一样的SQL各自的统计信息,而在v$sqlarea中sql_text相同的2个指针会合并起来,执行次数、DISK_READS、BUFFER_GETS等统计信息都会累加(sum),version_count会显示为2,这就是v$sqlarea的聚合作用。

    v$sqltext中没有统计信息,然而却存储着完整的SQL语句及其哈希ID等。

    对于这三者,我们可以使用视图v$fixed_view_definition来查看视图的源表,如下:

    SELECT view_definition FROM v$fixed_view_definition WHERE view_name='GV$SQL';

    SELECT view_definition FROM v$fixed_view_definition WHERE view_name='GV$SQLAREA';

    SELECT view_definition FROM v$fixed_view_definition WHERE view_name='GV$SQLTEXT';

    注:视图名为V$SQL但该视图的源又是GV$SQL,所以直接使用GV$SQL,其他两个也如此。

    通过以上3条语句可以发现,V$SQL数据来源X$KGLCURSOR_CHILD,其实数据还是来源于X$KGLOB;而V$SQLAREA数据来源X$KGLCURSOR_CHILD_SQLID本质是对X$KGLCURSOR_CHILD按照sql_id等字段分组汇总后的结果;V$SQLTEXT数据来源X$KGLNA。

    v$session主要用来确定会话相关信息,如通过SID和SERIAL#来唯一确定一个session(SID可能会重复)、会话拥有者用户名USERNAME、会话状态(active:正在执行SQL语句、inactive:等待操作、killed:被杀死)、会话由哪个客户端发起(MACHINE、TERMINAL)、正在执行什么SQL(通过SQL_ADDRESS、SQL_HASH_VALUE、SQL_ID、SQL_CHILD_NUMBER确定,有这些再借助v$sqltext就能知道)、甚至上一次执行的SQL是什么(通过PREV_SQL_ADDRESS等确定)、锁等待相关信息(如所在表、文件、块、被锁行)等。

    高资源消耗SQL查找定位

    1)查看读硬盘多或占用内存可能多的SQL:

    select sql_text, disk_reads, buffer_gets, parsing_schema_name, executions

    from v$sqlarea

    order by disk_reads desc;

    说明:单纯从V$sqlarea中是无法查出每个SQL消耗的内存量的,但我们可以借助磁盘读次数间接反映可能的消耗内存量较大的SQL语句,然后再借助执行计划(如v$sql_plan视图)具体查看。

    利用系统视图v$sqlarea,其中disk_reads是磁盘读次数,也是主要字段,剩余字段均为参考字段。其中,buffer_gets是内存读次数,parsing_schema_name是首次编译者模式名(一般与user名相同),executions是语句执行次数。

    需要注意的是,v$sqlarea中sql_text可能不完整,若需要完整的则需要借助hash_value或sql_id结合v$sqltext来查看分析。

    2)查看执行次数多的SQL

    select sql_text, executions, parsing_schema_name

    from v$sqlarea

    order by executions desc;

    3)查看排序多的SQL

    select sql_text, sorts, parsing_schema_name

    from v$sqlarea

    order by sorts desc;

    该处还应涉及Library Cache命中率、内存命中率等内容,暂不总结,见转载内容“Oracle调优相关的各种命中率、使用率汇总”。

    相关视图重要字段

    v$sqlarea

    v$sql和v$sqlarea基本类似,而v$sqlarea更常用,故仅对v$sqlarea常用字段进行说明,如下(个人参考Oracle官方文档翻译的,因是最新版本,所以会跟网络上的有些出入):

    • SQL_TEXT:SQL语句的前1000个字符;
    • SQL_FULLTEXT:SQL语句的所有字符;
    • SQL_ID:缓存在高速缓冲区(library cache)中的SQL父游标的唯一标识ID(注,类似于hash_value,不过hash_value是4bytes而sql_id是8bytes,sql_id更精确后期可能会替代hash_value);
    • SHARABLE_MEM:SQL语句及其子游标占用的共享内存大小;
    • PERSISTENT_MEM:打开SQL语句的生命周期内所占用的固定内存大小(包含子游标);
    • RUNTIME_MEM:游标执行期间所占用的固定内存大小;
    • SORTS:语句执行导致的排序次数;
    • VERSION_COUNT:在缓存中以该语句为父语句的子游标总数;
    • LOADED_VERSIONS:缓存中载入了这条语句上下文堆(KGL heap 6)的子游标数;
    • OPEN_VERSIONS:父游标下打开的子游标个数;
    • USERS_OPENING:打开子游标的用户个数;
    • FETCHES:SQL语句的fetch数;
    • EXECUTIONS:包含所有子游标在内该SQL语句共执行次数;
    • USERS_EXECUTING:执行过该语句所有子游标的用户总数;
    • LOADS:语句被载入的总次数;
    • FIRST_LOAD_TIME:父游标被首次载入(编译)的时间;
    • PARSE_CALLS:父游标下所有子游标解析调用次数;
    • DISK_READS:该语句通过所有子游标导致的读磁盘次数;
    • DIRECT_WRITES:该语句通过所有子游标导致的直接写入次数;
    • BUFFER_GETS:该语句通过所有子游标导致的读缓存次数;
    • APPLICATION_WAIT_TIME:应用等待时间;
    • USER_IO_WAIT_TIME:用户I/O等待时间;
    • PLSQL_EXEC_TIME:PLSQL执行时间;
    • ROWS_PROCESSED:该SQL语句处理的总行数;
    • OPTIMIZER_COST:此查询优化给出的成本数;
    • PARSING_USER_ID:第一次解析该父语句的用户ID;
    • PARSING_SCHEMA_ID:第一次解析该语句SCHEMA的ID;
    • PARSING_SCHEMA_NAME:解析该语句的SCHEMA的NAME;
    • KEPT_VERSIONS:指出是否当前子游标被使用DBMS_SHARED_POOL包标记为常驻内存;
    • ADDRESS:当前游标父句柄(唯一指向该游标的一种地址编号);
    • HASH_VALUE:该语句在library cache中hash值;
    • PLAN_HASH_VALUE:执行计划的hash值,可依此确定两个执行计划是否相同(取代每行每字符进行比较的方式);
    • CPU_TIME:该语句解析、执行和fetch(取值)所消耗的CPU时间;
    • ELAPSED_TIME:该语句解析、执行和fetch(取值)所经过的时间;
    • LAST_ACTIVE_TIME:查询计划最后一次执行的时间;
    • LOCKED_TOTAL:所有子游标被锁的次数;

    v$sqltext

    • ADDRESS:当前游标父句柄(唯一指向该游标的一种地址编号);
    • HASH_VALUE:该游标(子游标)在library cache中唯一hash值;
    • SQL_ID:缓存游标中该SQL的一个唯一标识值;
    • COMMAND_TYPE:SQL语句类型,如select、insert、update等;
    • PIECE:排序SQL文本的碎片数;
    • SQL_TEXT:包含一个完整SQL中的某一小块SQL文本字符(要完整的SQL语句需要把这些碎片组合起来);

    v$session

    • SADDR:session地址;
    • SID:session标识值,常跟serial#联合唯一确定一个session(在杀进程时,有时SID会重用,造成误杀。而serial会增加但不会重复,sid 在同一个instance的当前session中是一个unique key,而sid ,serial#则是在整个instance生命期内的所有session中是unique key);
    • SERIAL#:会话序列号,用于在一个会话结束而另一个会话重用这该会话的SID时,唯一确定一个会话;
    • AUDSID:审计会话ID,可以通过audsid查询当前session的sid,select sid from v$session where audsid=userenv('sessionid');
    • PADDR:进程地址,关联v$process的addr字段,通过这个可以查询到进程对应的session;
    • USER#:同于dba_users中的user_id,Oracle内部进程user#为0;
    • USERNAME:会话拥有者用户名,等于dba_users中的username,Oracle内部进程的username为空;
    • COMMAND:正在执行的SQL语句类型,如1为create table、3为select等;
    • OWNERID:如果该列值为2147483644则值无效,否则值用于会话迁移、并行等;
    • TADDR:Address of transaction state object;
    • LOCKWAIT:标识当前查询是否处于锁等待状态,为空则表示无等待;
    • STATUS:标识session状态,Active正执行SQL语句,inactive等待操作,killed被标注为杀死;
    • SERVER:服务器类型,DEDICATED专用、SHARED共享等;
    • SCHEMA#:SCHEMA标识ID值,Oracle内部进程的schema#为0;
    • SCHEMANAME:SCHEMA用户名,Oracle内部进程的为sys;
    • OSUSER:客户端操作系统用户名;
    • PROCESS:客户端操作系统进程ID;
    • MACHINE:操作系统机器名;
    • TERMINAL:操作系统终端名;
    • PROGRAM:操作系统应用程序名,如EXE或sqlplus.exe;
    • TYPE:会话类型,如BACKGROUND或USER;
    • SQL_ADDRESS:和SQL_HASH_VALUE一起使用标识正在执行的SQL语句;
    • SQL_HASH_VALUE:和SQL_ADDRESS一起使用标识正在执行的SQL语句;
    • SQL_ID:正在执行的SQL语句的标识ID;
    • SQL_CHILD_NUMBER:正在执行的SQL语句的子ID;
    • FIXED_TABLE_SEQUENCE:当session完成一个user call后就会增加的一个数值,也就是说,如果session挂起,它就不会增加。因此可以根据这个字段来监控某个时间点以来的session性能情况。例如,一个小时前某个session的此字段数值为10000,而现在是20000,则表明一个小时内其user call较频繁,可以重点关注此session的performance statistics。
    • ROW_WAIT_OBJ#:被锁定行所在table的object_id,和dba_object中的object_id关联可以得到被锁定的table name;
    • ROW_WAIT_FILE#:被锁定行所在的datafile id,和v$datafile中的file#关联可以得到datafile name;
    • ROW_WAIT_BLOCK#:被锁定的块ID;
    • ROW_WAIT_ROW#:被锁定的当前行;
    • LOGON_TIME:登录时间;
    展开全文
  • 一、执行过的SQL SELECT SQL_ID, HASH_VALUE, ADDRESS, SQL_FULLTEXT,LAST_LOAD_TIME FROM V$SQL ORDER BY LAST_LOAD_TIME DESC; -----------------------------------------------------------------...

    一、执行过的SQL

    SELECT 
        SQL_ID, HASH_VALUE, ADDRESS, SQL_FULLTEXT,LAST_LOAD_TIME 
    FROM 
        V$SQL 
    ORDER BY 
        LAST_LOAD_TIME DESC;
    
    -------------------------------------------------------------------------------------------------
    
    SELECT 
        SQL_ID, HASH_VALUE, ADDRESS, B.SQL_FULLTEXT, B.FIRST_LOAD_TIME 
    FROM 
        V$SQLAREA B 
    ORDER BY 
        B.FIRST_LOAD_TIME DESC;

    二、正在执行的SQL

    SELECT 
        SSN.USERNAME, SSN.SID, SSN.SQL_ID,SAA.ADDRESS, SAA.HASH_VALUE, SAA.SQL_FULLTEXT
    FROM 
        V$SESSION SSN, V$SQLAREA SAA 
    WHERE 
        SSN.SQL_ADDRESS = SAA.ADDRESS AND SSN.SQL_HASH_VALUE = SAA.HASH_VALUE;
    

    三、读取磁盘次数最多的SQL

    SELECT * FROM (
        SELECT 
            SQL_ID,ADDRESS,HASH_VALUE,COMMAND_TYPE, PARSING_USER_ID, PARSING_SCHEMA_NAME, EXECUTIONS, SORTS, DISK_READS, BUFFER_GETS, CPU_TIME, SQL_FULLTEXT 
        FROM 
            V$SQLAREA 
        ORDER BY 
            DISK_READS DESC 
    )WHERE ROWNUM<10 ; 

    四、消耗CPU时间最多的SQL

    SELECT * FROM (
        SELECT 
            SQL_ID,ADDRESS,HASH_VALUE,COMMAND_TYPE, PARSING_USER_ID, PARSING_SCHEMA_NAME, EXECUTIONS, SORTS, DISK_READS, BUFFER_GETS, CPU_TIME, SQL_FULLTEXT 
        FROM 
            V$SQLAREA 
        ORDER BY 
            CPU_TIME DESC  
    )WHERE ROWNUM<10 ; 
    

    五、执行次数最多的SQL

    SELECT * FROM (
        SELECT 
            SQL_ID,ADDRESS,HASH_VALUE,COMMAND_TYPE, PARSING_USER_ID, PARSING_SCHEMA_NAME, EXECUTIONS, SORTS, DISK_READS, BUFFER_GETS, CPU_TIME, SQL_FULLTEXT 
        FROM 
            V$SQLAREA 
        ORDER BY 
            EXECUTIONS DESC  
    )WHERE ROWNUM<10 ;

     

     

     

     

    展开全文
  • 定位资源消耗多的sql,亲测可用
  • 1. 先通过top命令查看产用资源较多的pid号, 注意:top命令的user的oacle的,关注pid  2.查询当前耗时的会话ID,用户名,sqlID等:其中top中的pid就是v$process的spid字段值。不是v$process视图中的pid值。 ...
  • Oracle中如何查找消耗资源较大的SQL

    千次阅读 2017-02-26 18:51:38
    从V$SQLAREA中查询最占用资源的查询select b.username username,a.disk_reads reads, a.executions exec,a.disk_reads/decode(a.executions,0,1,a.executions) rds_exec_ratio, a.sql_text Statement from v$sqlarea...
  • Oracle SQL monitor

    千次阅读 2016-04-13 20:35:00
    Oracle SQL monitor  第一章 被埋没的SQL优化利器——Oracle SQL monitor DBAplus社群 | 2015-11-26 07:00 转载声明:本文为DBA+社群原创文章,转载必须连同本订阅号二维码全文转载,并注明作者...
  • oracle中找出最消耗资源sql SELECT * FROM (select PARSING_USER_ID,EXECUTIONS,SORTS,COMMAND_TYPE,DISK_READS,sql_text FROM v...
  • ORACLEsql

    千次阅读 2013-11-19 21:26:12
    自学ORACLE的笔记,希望有所帮助
  • 概述 我们知道,Oracle提供的脚本均位于下列目录下 $ORACLE_HOME/rdbms/admin 其中,
  • oracle sql语句优化

    2019-09-22 17:28:23
    如何在 Oracle数据库里写出高质量的SQL语句,如何在Oracle数据库里对有性能问题的SQL做诊断和调整,这是DBA...1、查看该SQL语句的执行计划,并结合其资源消耗情况和相关统计信息、Trace文件来分析其执行计划是否合理...
  • Oracle SQL性能优化

    2016-07-29 23:19:56
     Oracle在执行一个SQL之前,首先要分析一下语句的执行计划,然后再按执行计划去执行。分析语句的执行计划的工作是由优化器(Optimizer)来完成的。不同的情况,一条SQL可能有多种执行计划,但在某一时点,一定只有一种执行...
  • 相关说明: ps aux 命令结果的第三列即是进程的CPU使用率 命令结果的第四列即是进程的内存使用率 ...脚本间隔5秒搂取一次对应系统资源消耗SQLID 根据SQLID可以进一步查询出对应的S...
  • oracle sql调优集

    千次阅读 2015-02-11 18:06:25
    oracle sql TTS加载数据
  • 标题:oracle 中如何定位重要(消耗资源多)的SQL 作者:惜分飞©版权所有[文章允许转载,但必须以链接方式注明源地址,否则追究法律责任.] 1、查看值得怀疑的SQL select substr(to_char(s.pct,'...
  • 环境: 操作系统版本:linux redhat 6.6 数据库版本:oracle 11.2.0.4 问题描述:今天,实施同事反馈一个很奇怪的问题,就是oracle 数据库的sql merge...
  • Oracle SQL性能优化 SQL优化

    万次阅读 2017-07-31 08:47:44
    (1) 选择最有效率的表名顺序(只在基于规则的优化器(Oracle有两种优化器:RBO基于规则的优化器和CBO基于成本的优化器)中有效): ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表...
  • Oracle SQL跟踪

    千次阅读 2013-06-28 17:29:52
    很多时候,对数据库进行性能诊断可以使用SQL跟踪的方法,把一些信息记录在trace文件里以后分析。一般情况下我们可以通过初始化参数SQL_TRACE=TRUE来设置SQL跟踪。我们也可以通过设置10046事件来进行SQL跟踪,并且...
  • Oracle SQL优化 总结

    千次阅读 2012-09-25 19:53:00
    Oracle SQL优化 总结 分类: Oracle Performance My Blog Summary 2011-11-24 17:05 6216人阅读 评论(9) 收藏 举报 目录(?)[+] 一.SQL 编写注意事项 SQL 编写的具体注意事项多表关联方式 ...
  • Oracle SQL性能优化〔转〕

    千次阅读 2011-01-17 21:09:00
    Oracle SQL性能优化〔转〕
  • oracle sql性能优化

    2014-05-13 15:48:37
    SQL 编写注意事项 SQL 编写的具体注意事项多表关联方式 二 相关理论说明 Oracle 优化器CBO 和 RBO软解析和硬解析执行计划和 10046 事件事件统计信息 三索引 索引分类索引限制索引维护索引的 Clustering...
  • 查询oracle最耗资源sql语句

    千次阅读 2013-08-12 10:20:26
    查询oracle最耗资源sql语句,等等 1、查询当前系统中正在执行的sql: SELECT osuser, username, sql_text from v$session a, v$sqltext b where a.sql_address =b.address order by address, piece; 2、...
  • oracle资源消耗查看

    2019-03-11 14:05:04
    SQL消耗资源情况查询: 从V$SQLAREA中查询最占用资源的查询   select b.username username,a.disk_reads reads, a.executions exec,a.disk_reads/decode(a.executions,0,1,a.executions) rds_exec_ratio, ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 41,570
精华内容 16,628
关键字:

oraclesql消耗资源