Sql_id in gv$sort_usage vs gv$session

I've caught a strange(?) situation here.
select sql_id from gv$sort_usage where session_addr='000000046A1932F0'; -- gives me 5bqt08ckavskx
where as
select sql_id from gv$session where saddr='000000046A1932F0'; -- gives me 1rztpy7a92vpn
Because of this, I am not able to find the correct query which is consuming lots of temp segments. Well, actually, I am catching up those queries when things are apparent but I am now caught in a situation where two queries are somewhat similar and getting me confused. Why gv$sort_usage and gv$session are giving me different queries and which query is the one that is actually taking the huge temp segments?
Any help is appreciated.
Thanks
gtcol

You might find useful information in DBA_TEMP_FILES :
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:374218170986#76977305391283 (warning: long thread ;) ,but many alternatives)
http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/tspaces.htm#sthref1323
Also dbms_xplan can be used to show you the estimated temp space needed by a query, using column temp_space from the plan_table:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm#g30946

Similar Messages

  • Log file sync waits with null sql_ids

    10.2.0.3
    I am querying V$ACTIVE_SESSION_HISTORY to drill into log file sync waits.
    select sql_id,sum(time_waited)
    from v$active_session_history
    where sample_time > sysdate - 1/24
    group by sql_id
    order by 2 desc
    All of my top sessions for this have null sql_ids. I did some google searches and these are the answers that I found have null sql_ids. There are some other sessions where the sql_id is not null, but they are not anywhere near the top.
    1. could be running pl/sql. yeah ok. but I would need to run 'dml' and issue a commit for this event to fire).
    2. no sql is running. does this mean the insert finished and then I am waiting on the 'commit' part?
    I want to track these sqls down so I can track them back to the application. I want to get the developers to limit their commit frequency and use batch (array based) DML. How do I track this down?
    Also, is there anyway to figure out how often different users are committing? I want to track back to the worst offenders. Could be some parts of the application are commit periodically and others are  not, but log file sync's could slow down everyone.

    You are either bored or suffer from Compulsive Tuning Disorder.
    It can be a challenge to solve  a problem that only exists between your ears
    post results from SQL below
    SELECT sql_id,
           SUM(time_waited) / 1000000
    FROM   v$active_session_history
    WHERE  sample_time > SYSDATE - 1 / 24
           AND time_waited > 0
    GROUP  BY sql_id
    ORDER  BY 2 DESC

  • A lot of messages "direct path write temp" and "direct path read temp"

    Hello, all
    Please, understand me, what is going on in my system (DB: Oracle database 11.2.0.3, OS: Windows 2008 R2).
    In AWR report (1 hour) I see next:
    Foreground Wait Events
                                                                 Avg               
                                            %Time Total Wait    wait    Waits   % DB
    Event                             Waits -outs   Time (s)    (ms)     /txn   time
    direct path write temp          132,627     0      1,056       8      0.8   21.7
    direct path read temp           308,969     0        565       2      2.0   11.6
    log file sync                    19,228     0        241      13      0.1    5.0
    direct path write                17,698     0        135       8      0.1    2.8
    db file sequential read          21,149     0         94       4      0.1    1.9
    SQL*Net message from dblin           59     0          5      86      0.0     .1
    Segments by Direct Physical Reads         DB/Inst: SGRE/sgre  Snaps: 1039-1040
    -> Total Direct Physical Reads:         392,273
    -> Captured Segments account for   94.7% of Total
               Tablespace                      Subobject  Obj.        Direct       
    Owner         Name    Object Name            Name     Type         Reads  %Total
    ** MISSING TEMP       ** TRANSIENT: 437734 MISSING ** UNDEF       38,290    9.76
    DBSNMP     TEMP       MGMT_TEMPT_SQL                  TABLE       38,242    9.75
    ** MISSING TEMP       ** TRANSIENT: 438784 MISSING ** UNDEF       37,790    9.63
    ** MISSING TEMP       ** TRANSIENT: 437312 MISSING ** UNDEF       37,661    9.60
    ** MISSING TEMP       ** TRANSIENT: 439257 MISSING ** UNDEF       37,477    9.55Some selects:
    SELECT   S.sid,
             T.blocks * TBS.block_size / 1024 / 1024 mb_used, T.tablespace, T.SEGTYPE
    FROM     v$sort_usage T, v$session S, v$sqlarea Q, dba_tablespaces TBS
    WHERE    T.session_addr = S.saddr
    AND      T.sqladdr = Q.address (+)
    AND      T.tablespace = TBS.tablespace_name
    AND      S.sid = 732
    ORDER BY S.username, S.sid;
    SID     MB_USED     TABLESPACE     SEGTYPE
    732     2          TEMP          LOB_DATA
    732     1          TEMP          INDEX
    732     1          TEMP          DATA
    732     1          TEMP          INDEX
    732     1          TEMP          DATA
    732     1          TEMP          INDEX
    732     1          TEMP          DATA
    732     1          TEMP          INDEX
    732     1          TEMP          INDEX
    732     1          TEMP          DATA
    732     1          TEMP          INDEX
    732     1          TEMP          INDEX
    732     1          TEMP          DATA
    732     1          TEMP          INDEX
    732     1          TEMP          INDEX
    732     1          TEMP          DATA
    732     1          TEMP          INDEX
    732     1          TEMP          INDEX
    732     1          TEMP          DATA
    732     1          TEMP          INDEX
    732     1          TEMP          INDEX
    732     1          TEMP          DATA
    732     1          TEMP          INDEX
    732     1          TEMP          INDEX
    732     1          TEMP          DATA
    732     1          TEMP          INDEX
    732     1          TEMP          INDEX
    732     1          TEMP          DATA
    732     1          TEMP          INDEX
    732     1          TEMP          LOB_INDEX
    select st.sid, sn.name, st.VALUE
    from V$statname sn, v$sesstat st
    where st.STATISTIC# = sn.STATISTIC#
    and (sn.name like 'sorts%')
    and st.sid in (select sid from v$session_wait where event like '%direct path write temp%')
    order by st.sid
    SID     NAME          VALUE
    732     sorts (memory)     591408
    732     sorts (rows)     102126
    732     sorts (disk)     0Why I do not see any disk sorts? If TEMP is used for no sort operations, then for which operations?
    How I can see that? How can I decrease direct path write temp without tuning SQL?
    Additional information:
    PGA_AGGREGATE_TARGET is set to big value - 6GB (3GB enough due to advisory recommendation)
    Please, help.
    Regards, user12103911.

    user12103911 wrote:
    SELECT optimal_count, round(optimal_count*100/total, 2) optimal_perc,
    onepass_count, round(onepass_count*100/total, 2) onepass_perc,
    multipass_count, round(multipass_count*100/total, 2) multipass_perc
    FROM
    (SELECT decode(sum(total_executions), 0, 1, sum(total_executions)) total,
    sum(OPTIMAL_EXECUTIONS) optimal_count,
    sum(ONEPASS_EXECUTIONS) onepass_count,
    sum(MULTIPASSES_EXECUTIONS) multipass_count
    FROM   v$sql_workarea_histogram); 
    OPTIMAL_COUNT OPTIMAL_PERC  ONEPASS_COUNT ONEPASS_PERC  MULTIPASS_COUNT MULTIPASS_PERC
    13150685      100           0             0             0               0No n-pass executions.That's a pretty convincing display - given that your AWR manages to NAME an object that is in the TEMP tablespace, an obvious point to follow up is global temporary tables. If you have any declared as "on commit preserve" (duration = 'SYS$SESSION') then you could have code which does "insert /*+ append */ into gtt", and if you then query this in parallel (or - since you're on 11.2.0.3 - the data volume is large enough) Oracle could choose to do direct path writes to load the GTT and direct path reads to read it back.
    Regards
    Jonathan Lewis

  • Refresh Materialized views

    Hi,
    While I was refresh the materialized view I found below error.
    SQL> exec dbms_mview.refresh(MV1','C');
    BEGIN dbms_mview.refresh('MV1','C'); END;
    ERROR at line 1:
    ORA-12008: error in materialized view refresh path
    ORA-01652: unable to extend temp segment by 1280 in tablespace TEMP
    ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2251
    ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2457
    ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2426
    ORA-06512: at line 1
    I increased 3 gb, again got the smw error
    and the 11gb TEMP tablespace size was full.
    So please advise How to resolve this issue?
    Thank,
    Praveen

    Hello,
    You should check your Temporary Tablespace so as to be sure of which statement is consumming so much
    space. The following query may help you:
    SELECT S.sid || ',' || S.serial# sid_serial, S.username, Q.hash_value, Q.sql_text,
    T.blocks * TBS.block_size / 1024 / 1024 "Mo used", T.tablespace
    FROM v$sort_usage T, v$session S, v$sqlarea Q, dba_tablespaces TBS
    WHERE T.session_addr = S.saddr
    AND T.sqladdr = Q.address
    AND T.tablespace = TBS.tablespace_name
    ORDER BY S.sid;On the other hand, is this refresh worked before or is it a new MV to refresh ?
    Which option did you use to create this MV ?
    Best regards,
    Jean-Valentin

  • High invalidations in v$sqlarea for 1 query tag with "SQL Analyze"

    Hi All,
    Hopefully post to the right forum, if not please do let me know. Thanks
    I have one pre-production issue still don't have any clue how to move forward.
    This is 2 RAC nodes in linux platform with Oracle 11.2.0.2
    In the begininng this environment having a lot of performance issue, as huge "cursor: pin S wait on X", "latch: shared pool"
    and "library cache:Mutex X" causing very bad performance in this environment. After oracle support suggest to disable few hidden paramter
    and adjust some parameter, then it help to stablized the environment (according to oracle, the initial issue was caused by high version count).
    But we still can find minimal "latch:shared pool" and "library cache:Mutex X" on top 5 wait event list on hourly AWR report.
    This time oracle was saying it might caused by high reload and high invalidatiosn in sqlarea (not sure how true it is), luckily the event
    did not caused the performance issue at this moment, but we're asking support how can we get rid of the "mutex/latch" event.
    They give me one query to check the invalidations in v$sqlarea, and they suspect the high validation is causing by application.
      select *
      from v$sqlarea
      order by invalidations DESC;
      Weird thing is, there have one SQL tag with "SQL Analyze" always causing high invalidations. But we're not able to get more detail (base on SQL_ID)
    in v$sql or v$session table. This SQL insert into v$sqlarea and remove within 1 or 2 seconds, hard to get more information.
    And the statement is exactly the same, but don't know why SQL Analyze always checking on it.
    This SQL is triggering by SYS user, and it is inserting into MLOG$ table (one of the application materialized log file)
      insert into "test"."MLOG$_test1" select * from "test"."MLOG$_test1"
      The v$sqlarea information as below, sometime the invalidations can hit more than 10,000
      SQL_ID              SQL_TEXT                                                                                        LOADS  INVALIDATIONS
      0m6dhq90rg82x /* SQL Analyze(632,0) */ insert into "test"."MLOG$_test" select * from "test"."MLOG$_test  7981    7981
      {code}
      Anyone have any idea how can i move forward for this issue? As Oracle is asking me to use SQLTXPLAIN get the detail?
      Please share with me if you have any idea. Thanks in advance.
      Regards,
      Klng                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

    Hi Dom,
    We have checked there have no SQL Tuning enable for this SQL_ID. Below is the optimizer parameter in this environment, the hidden parameter was changed which suggest by oracle support.
    NAME                                 TYPE        VALUE
    _optimizer_adaptive_cursor_sharing   boolean     FALSE
    _optimizer_extended_cursor_sharing_r string      NONE
    el
    object_cache_optimal_size            integer     102400
    optimizer_capture_sql_plan_baselines boolean     FALSE
    optimizer_dynamic_sampling           integer     2
    optimizer_features_enable            string      11.2.0.2
    optimizer_index_caching              integer     90
    optimizer_index_cost_adj             integer     10
    optimizer_mode                       string      ALL_ROWS
    optimizer_secure_view_merging        boolean     TRUE
    optimizer_use_invisible_indexes      boolean     FALSE
    optimizer_use_pending_statistics     boolean     FALSE
    optimizer_use_sql_plan_baselines     boolean     TRUE
    plsql_optimize_level                 integer     2
    SQL> select * from dba_sql_plan_baselines;
    no rows selected
    SQL>yeah we did run the ash, but the high invalidation did not caputre in the report. Actually this SQL tag with sql analyze it gone from v$sqlarea very fast (only 1 or 2 seconds only).
    Thanks.
    Regards,
    Klng

  • ORA-01652: unable to extend temp segment by 128 in tablespace TEMP

    Hi,
    I am getting the following error while executing an insert query.
    ORA-01652: unable to extend temp segment by 128 in tablespace TEMP.
    I have tried increasing the TEMP tbsp size it got resolved temporarily but occurred again after few days.
    When the problem occured, following query shows all insert queries in TEMP tablespace and one of them consumes about 5GB and others are about 24MB.
    SELECT S.sid || ',' || S.serial# sid_serial, S.username,
    T.blocks * TBS.block_size / 1024 / 1024 mb_used, T.tablespace,
    T.sqladdr address, Q.hash_value, Q.sql_text
    FROM v$sort_usage T, v$session S, v$sqlarea Q, dba_tablespaces TBS
    WHERE T.session_addr = S.saddr
    AND T.sqladdr = Q.address (+)
    AND T.tablespace = TBS.tablespace_name
    ORDER BY S.sid;
    The insert query is :
    INSERT INTO SEOSDATA (ENTRYID,DOMAINNAME,USERNAME,EVENTTYPE,LOGNAME,TIMSTAMP,SOURCE,COMPUTERNAME,EVENTID,EVENTCATEGORY,SEARCHSTRINGS,MSGTEXT) VALUES (ENTRYID_SEQ.NEXTVAL,:1,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11)
    It is not expected that an insert query consumes such a huge memory.
    Can someone help me in figuring out what the problem is.
    What might have gone wrong? Seems like sorting is used, why an insert query uses sorting?
    Regards
    Ishu

    Hi,
    Insert statement should not use TEMP tablespace. Please check with following query which user and session id is using TEMP tablespace.
    SELECT b.tablespace, b.segfile#, b.segblk#, b.blocks, a.sid, a.serial#,
    a.username, a.osuser, a.status
    FROM v$session a,v$sort_usage b
    WHERE a.saddr = b.session_addr
    ORDER BY b.tablespace, b.segfile#, b.segblk#, b.blocks;
    Dilipkumar Patel.

  • Unknown SQL eating CPU time and library cache locks

    Hello everyone,
    we are seeing a lot of activity when opening new connections to the database from PHP web server and the time is being spent on a SQL which in Enterprise manager is reported as UNKNOWN and selecting the GV$SQL view for this sql_id yields nothing, the SQL is not there. We do not have any logon triggers.
    I was wondering, if I know this SQL_ID (it's "c5brdpybgqss6"), can I see what it actually does? Can I trace it somehow?
    Our environment is:
    Oracle Database 11g Release 11.1.0.7.0 - 64bit Production
    With the Real Application Clusters option
    Two RAC instances, running RedHat ES 5 64bit
    Clients are PHP, using oci8, using Instant Client 11.1.0.7
    Thanks for any ideas how to further analyze this,
    Michal.

    Unfortunately no, it is NULL (see below). I tried metalink, but I don't know what to search for. I'll probably have to file a ticket with the support.
    select username, sid, serial#, status, sql_id, prev_sql_id, event, seconds_in_wait
    from gv$session
    where sql_id='c5brdpybgqss6'
    order by username, sid, serial#;
    USERNAME SID SERIAL# STATUS SQL_ID PREV_SQL_ID EVENT SECONDS_IN_WAIT
    IMWC2 945 64434 ACTIVE c5brdpybgqss6 latch: shared pool 5
    IMWC2 1020 38821 ACTIVE c5brdpybgqss6 library cache lock 2
    973 7519 ACTIVE c5brdpybgqss6 class slave wait 0
    992 20 ACTIVE c5brdpybgqss6 EMON slave idle wait 3
    1004 5 ACTIVE c5brdpybgqss6 EMON slave idle wait 5
    1006 1195 ACTIVE c5brdpybgqss6 EMON slave idle wait 3
    1014 2635 ACTIVE c5brdpybgqss6 EMON slave idle wait 3
    1020 2755 ACTIVE c5brdpybgqss6 EMON slave idle wait 3
    1026 3967 ACTIVE c5brdpybgqss6 EMON slave idle wait 2
    1027 3039 ACTIVE c5brdpybgqss6 EMON slave idle wait 2
    1042 805 ACTIVE c5brdpybgqss6 EMON slave idle wait 3
    1044 481 ACTIVE c5brdpybgqss6 EMON slave idle wait 3
    1046 300 ACTIVE c5brdpybgqss6 EMON slave idle wait 1
    1053 2 ACTIVE c5brdpybgqss6 Streams AQ: waiting for time management or cleanup tasks 209637
    1055 8 ACTIVE c5brdpybgqss6 Streams AQ: emn coordinator idle wait 4
    1056 10 ACTIVE c5brdpybgqss6 Streams AQ: emn coordinator idle wait 0
    1059 6 ACTIVE c5brdpybgqss6 Streams AQ: waiting for time management or cleanup tasks 0

  • Capturing the SQL that caused the sort-extents breach in TEMP

    We occasionally get ad-hoc queries in our production database
    which cause "ORA-1630: max # extents reached in temp segment for tablespace TEMP" alert-log entries.
    (The user is chewing 750Mb of sort-space).
    No user is "owning-up" to these queries, so I wish to track them down myself.
    I originally created a system-trigger as follows:-
    begin
    if (is_servererror (1630))
    then
    insert sort_breach
    select iv.sid,
    iv.serial#,
    iv.username,
    iv.osuser,
    iv.extents,
    sq.sql_text
    from
    (select
    ss.sid,
    ss.serial#,
    ss.username,
    ss.osuser,
    su.extents,
    su.sqladdr
    from v$sort_usage su,
    v$session ss
    where ss.serial# = su.session_num) iv,
    v$sqlarea sq
    where iv.sqladdr = sq.address;
    end if;
    end;
    However, this has proved ineffective, because v$sort_usage is EMPTY by the time the trigger is fired (duoh..)(it may also be that I need to use v$session.prev_sql_addr, not v$session.sql_address - please comment !).
    As there are generally upwards of 250 concurrent users, I suspect that I am condemned to the following in order to narrow down my search:-
    begin
    if (is_servererror (1630))
    then
    insert into cfm.sort_breach (SID, SERIAL#, USERNAME, OSUSER, SQL_TEXT, sorts)
    select ss.sid,
    ss.serial#,
    ss.username,
    ss.osuser,
    sq.sql_text,
    sq.sorts
    from
    v$session ss,
    v$sqlarea sq
    where ss.sql_address = sq.address
    and sq.sorts > 0
    and ss.status = 'ACTIVE'
    end if;
    end;
    Question(1) : By the time the trigger is fired, is my sorting session actually ACTIVE ?
    Question(2) : Have any of you come up with a better route to this particular grail ?
    Regards.

    Have you discounted the possiblility that the DBA is responsible? For instance, creating unique indexes generates sorts; so adding a primary key to a large table or inserting millions of rows into a table without dropping the primary key could blow the temp tablespace.
    Anyway, why don't you use something like the following query to establish which users are generating excessive disk sorts. That will give you a much smaller pool of suspects to investigate in greater depth.
    cheers, APC
    This comes from Gurry & Corrigan (I think), anyway I half-inched it from somewhere: it's very useful.
    select u.username
    , u.sid
    , sum(decode(n.name, 'sorts (memory)', s.value, 0)) memory_sorts
    , sum(decode(n.name, 'sorts (disk)', s.value, 0)) disk_sorts
    , (round(1 - (sum(decode(n.name, 'sorts (disk)', decode(s.value,0,1,s.value), 0
    (sum(decode(n.name, 'sorts (memory)', decode(s.value,0,1,s.value), 0
    )+sum(decode(n.name, 'sorts (disk)', decode(s.value,0,1,s.value), 0
    ,6)
    ) dmsr
    from v$statname n, v$sesstat s, v$session u
    where u.type = 'USER'
    and lower(n.name) in ( 'sorts (disk)', 'sorts (memory)' )
    and s.sid = u.sid
    and n.statistic# = s.statistic#
    and nvl(s.value,0) > 0
    group by u.username, u.sid
    order by 5 desc

  • ORA-03217: invalid option for alter of TEMPORARY TABLESPACE

    Hi all
    I have a database with 300 Users approximantely.
    Suddenly I was reported about slowly connection and looked to my database. And I saw that Temporary tablespace with name MUVTEMP is 0% used and in it there is no .dbf file
    Then I do ls on my data files directory and saw there MUVTEMP01.dbf!
    But it's not using it. Then I want to add another .dbf file. It created this file physically but not joined it to my temporary tablespace.
    Then I did it with Oracle EM, clicked on "Show SQL" and there was written
    ALTER TABLESPACE "MUVTEMP"
    ADD
    DATAFILE '/home/oracle/OraHome1/oradata/linux/test.dbf' SIZE
    5M
    I run it from EM it gave this error
    ORA-03217: invalid option for alter of TEMPORARY TABLESPACE
    Then I run this SQL in sqlplus
    ALTER TABLESPACE "MUVTEMP"
    ADD
    TEMPFILE '/home/oracle/OraHome1/oradata/linux/test.dbf' SIZE
    5M
    it created file physically, but I can't see this file as temporary tablespace's file. It's not using....
    Where is my mistake???
    Thanks...

    Hi,
    try this query:
    select s.sid || ',' || s.serial# sid, s.username, u.tablespace, substr(a.sql_text, 1, (instr(a.sql_text, ' ')-1)) sql_text,
      round(((u.blocks*p.value)/1024/1024),2) size_mb
    from v$sort_usage u, v$session s, v$sqlarea a, v$parameter p
    where s.saddr = u.session_addr
      and a.address (+) = s.sql_address
      and a.hash_value (+) = s.sql_hash_value
      and p.name = 'db_block_size'
    group by s.sid || ',' || s.serial#, s.username, substr(a.sql_text, 1, (instr(a.sql_text, ' ')-1)), u.tablespace, round(((u.blocks*p.value)/1024/1024),2);

  • How to find which query ORA-1652: unable to extend temp segment by 128 in

    How can i find which query caused the below error,the query is not running currently
    ORACLE ERRORS IN ALERTS LOG dnb2stg3 - lnx300 on Thu Jun 17 12:10:01 EDT 2010
    1 ORA-1652: unable to extend temp segment by 128 in tablespace TEMP_SCHED
    SQL> select inst_id, tablespace_name, total_blocks, used_blocks, free_blocks from gv$sort_segment;
    INST_ID TABLESPACE_NAME TOTAL_BLOCKS USED_BLOCKS FREE_BLOCKS
    1 TEMP 638336 0 638336
    4 TEMP 565760 0 565760
    4 TEMP_SCHED 16776704 0 16776704
    3 TEMP 484864 0 484864
    3 TEMP_SCHED 0 0 0
    2 TEMP 455808 0 455808
    6 rows selected.
    SQL> SQL> SELECT S.sid || ',' || S.serial# sid_serial, S.username,
    2 T.blocks * TBS.block_size / 1024 / 1024 mb_used, T.tablespace,
    3 T.sqladdr address, Q.hash_value, Q.sql_text
    FROM v$sort_usage T, gv$session S, gv$sqlarea Q, dba_tablespaces TBS
    4 5 WHERE T.session_addr = S.saddr
    6 AND T.sqladdr = Q.address (+)
    7 AND T.tablespace = TBS.tablespace_name
    8 ORDER BY S.sid;
    no rows selected

    Hello,
    You may try to catch the SQL with a Servererror Trigger.
    This link will give you an interesting example:
    http://oratips-ddf.blogspot.com/2008/09/to-err-is-human.html
    Hope this help.
    Best regards,
    Jean-Valentin

  • Query on  V$STREAMS_APPLY_COORDINATOR used large temp space

    Hi
    My database recently experience ORA-1652 error consistently on temp tablespace. I found out the query to cause this was an OEM query SELECT APPLY_NAME,TOTAL_RECEIVED,TOTAL_ASSIGNED,TOTAL_APPLIED FROM V$STREAMS_APPLY_COORDINATOR, which uses over than 800M temp space frequently. I am not sure why is this, I can query the same select statement in sqlplus, it returns immeidatly. Can anyone help to teach me on this? Thanks.
    The query to find the user for temp tablespace is.
    SELECT S.sid || ',' || S.serial# sid_serial, S.username, Q.hash_value, Q.sql_text,
    T.blocks * TBS.block_size / 1024 / 1024 mb_used, T.tablespace
    FROM v\$sort_usage T, v\$session S, v\$sqlarea Q, dba_tablespaces TBS
    WHERE T.session_addr = S.saddr
    AND T.sqladdr = Q.address
    AND T.tablespace = TBS.tablespace_name
    ORDER BY mb_used)
    where mb_used >=800;
    I got
    SID_SERIAL USERNAME HASH_VALUE SQL_TEXT MB_USED TABLESPACE
    1626,1 DBSNMP 3741683138 /* OracleOEM */ SELECT APPLY_NAME,TOTAL_RECEIVED,TOTAL_ASSIGNED,TOTAL_APPLIED FROM V$STREAMS_APPLY_COORDINATOR 880 TEMP1

    Hi
    My database recently experience ORA-1652 error consistently on temp tablespace. I found out the query to cause this was an OEM query SELECT APPLY_NAME,TOTAL_RECEIVED,TOTAL_ASSIGNED,TOTAL_APPLIED FROM V$STREAMS_APPLY_COORDINATOR, which uses over than 800M temp space frequently. I am not sure why is this, I can query the same select statement in sqlplus, it returns immeidatly. Can anyone help to teach me on this? Thanks.
    The query to find the user for temp tablespace is.
    SELECT S.sid || ',' || S.serial# sid_serial, S.username, Q.hash_value, Q.sql_text,
    T.blocks * TBS.block_size / 1024 / 1024 mb_used, T.tablespace
    FROM v\$sort_usage T, v\$session S, v\$sqlarea Q, dba_tablespaces TBS
    WHERE T.session_addr = S.saddr
    AND T.sqladdr = Q.address
    AND T.tablespace = TBS.tablespace_name
    ORDER BY mb_used)
    where mb_used >=800;
    I got
    SID_SERIAL USERNAME HASH_VALUE SQL_TEXT MB_USED TABLESPACE
    1626,1 DBSNMP 3741683138 /* OracleOEM */ SELECT APPLY_NAME,TOTAL_RECEIVED,TOTAL_ASSIGNED,TOTAL_APPLIED FROM V$STREAMS_APPLY_COORDINATOR 880 TEMP1

  • DBA_FREE_SPACE is showing empty (nothing is being shown)

    Good Morning,
    I get the ORA-01652 error. I go to view DBA_FREE_SPACE and it shows:
    ~
    ~
    ~
    ~
    ~
    ~
    ~
    ~
    "DBA_FREE_SPACE" [New File]
    I need to extend my temp segment by 128 in the tablespace. But, I would like to view it first. Has anyone had this issue before?
    Thank You

    Error: ORA-01652: unable to extend temp segment by string in tablespace string
    Cause: Failed to allocate an extent for temporary segment in tablespace.
    Action: Use ALTER TABLESPACE ADD DATAFILE statement to add one or more files to the tablespace indicated
    what query is creating this issue?In first place, you have to know what query is the problem before add more space in temp tablespace, to see it execute:
    SELECT S.sid || ',' || S.serial# sid_serial, S.username, S.osuser, P.spid, S.module,
    S.program, SUM (T.blocks) * TBS.block_size / 1024 / 1024 mb_used, T.tablespace,
    COUNT(*) sort_ops,T.segtype
    FROM v$sort_usage T, v$session S, dba_tablespaces TBS, v$process P
    WHERE T.session_addr = S.saddr
    AND S.paddr = P.addr
    AND T.tablespace = TBS.tablespace_name
    GROUP BY S.sid, S.serial#, S.username, S.osuser, P.spid, S.module,
    S.program, TBS.block_size, T.tablespace,T.segtype
    ORDER BY mb_used,sid_serial;
    HTH
    Edited by: Fran on 12-abr-2012 5:42

  • Temp tablespace usage...

    hi,,
    how to check the usage of temp tablespace?
    thanks,
    bicho

    Temp used:
    SELECT A.tablespace_name tablespace, D.mb_total,
    SUM (A.used_blocks * D.block_size) / 1024 / 1024 mb_used,
    D.mb_total - SUM (A.used_blocks * D.block_size) / 1024 / 1024 mb_free
    FROM v$sort_segment A,
    SELECT B.name, C.block_size, SUM (C.bytes) / 1024 / 1024 mb_total
    FROM v$tablespace B, v$tempfile C
    WHERE B.ts#= C.ts#
    GROUP BY B.name, C.block_size
    ) D
    WHERE A.tablespace_name = D.name
    GROUP by A.tablespace_name, D.mb_total;
    Temp usage per session:
    SELECT S.sid || ‘,’ || S.serial# sid_serial, S.username, S.osuser, P.spid, S.module,
    P.program, SUM (T.blocks) * TBS.block_size / 1024 / 1024 mb_used, T.tablespace,
    COUNT(*) statements
    FROM v$sort_usage T, v$session S, dba_tablespaces TBS, v$process P
    WHERE T.session_addr = S.saddr
    AND S.paddr = P.addr
    AND T.tablespace = TBS.tablespace_name
    GROUP BY S.sid, S.serial#, S.username, S.osuser, P.spid, S.module,
    P.program, TBS.block_size, T.tablespace
    ORDER BY sid_serial;
    Thanks

  • V$SORT_USAGEとV$SQLとV$SESSIONの連結SQLで.重複したデータを出力させないようにする方法

    下記SQL文でV$SORT_USAGEとV$SQLとV$SESSIONをJOINした結果を表示させようと思いますが、
    SESSION_ADDRが重複して出力されてしまいます。
    重複を排除したSQL文を出力させる方法をわかる方いましたら、教えてください。
    ※本来は、SELECTするカラムはもっと多いですが、ここでは省力しています。
    SELECT
         SORT.SESSION_ADDR
    FROM
         V$SESSION SES,
         V$SORT_USAGE SORT,
         V$SQL SQL
    WHERE
         SES.SADDR=SORT.SESSION_ADDR AND
         SES.SQL_ID=SQL.SQL_ID AND
         SES.SQL_CHILD_NUMBER = SQL.CHILD_NUMBER AND
         SES.SQL_ADDRESS=SQL.ADDRESS AND
         SORT.SQLADDR=SQL.ADDRESS AND
         SORT.SQLHASH=SQL.HASH_VALUE
    ORDER BY
         BLOCKS;
    SESSION_ADDR
    00000003FF79A788
    00000003FF79A788
    00000003FF79BCF0
    00000003FC7C9258
    00000003FF79BCF0
    00000003FC7C9258
    6 rows selected.
    【備考】
    ・表示するカラムにV$SORT_USAGE.SQL_FULLTEXT（CLOB)も含めたい為、distinct句で
    重複を排除する事ができません。
    ・DBはOracle10gです。

    すみません。上記は自己解決しました。
    ※SEGMENT_TYPE別にSQL文が出力されるのですね

  • Sql_id of active session not in v$sql

    Hi all,
    How do you explain this?
    There is one active session in v$session with a sql_id. But when I query v$sql using that sql_id I got nothing back. Is this because the sql_id was pushed out of shared memory or some other reason? The connection is shared session.
    Our db is 10.2.0.3 and server is MS window 2003 server.
    Thanks,
    Shirley

    Hi,
    Can you check what is the wait event of that session? Also can you tell me how you decided its active?
    select sql_id, prev_sql_id, last_call_et, status, program, event, sid from v$session where sid = <sid>Regards
    Anurag

Maybe you are looking for