Insert operation takes looooooooooong time

One of our ETL procedures does an Insert operation on a table with the records selected from a couple of tables across DB link.
While the SELECT query takes about 6 seconds to retrieve nearly 42,00,000 records, the insert of those records to a table takes about 45 minutes.
Infact I've altered the table to NOLOGGING mode and the /*+ append */ comment(for Insert) is in place to reduce the redo logs.The destination table has no index and no constraints as well..
Is there any other way that I can adapt to reduce the time of insert operation?
Thanks,
Bhagat

>While the SELECT query takes about 6 seconds to retrieve nearly 42,00,000 records
Is this in TOAD? If so, TOAD actually returns rows in sections and may not be returning the full set. You would have to actually scroll to the bottom of the grid and wait for the data to finish loading. Caution, if you did not select the option to execute queries in threads in TOAD you will not have the cancel query ability.
>the insert of those records to a table takes about 45 minutes
Have you performed a CREATE TABLE AS using the query. This will give you a good benchmark for performance during a direct-path load. You can then look at the USER_SEGMENTS.BYTES column for that table after a load and, with your timings, check the data transfer rate with your network support.

Similar Messages

  • Oracle coherence first read/write operation take more time

    I'm currently testing with oracle coherence Java and C++ version and from both versions for writing to any local or distributed or near cache first read/write operation take more time compared to next consecutive read/write operation. Is this because of boost operations happening inside actual HashMap or serialization or memory mapped implementation. What are the techniques which we can use to improve the performance with this first read/write operation?
    Currently I'm doing a single read/write operation after fetching the NamedCache Instance. Please let me know whether there's any other boosting coherence cache techniques available.

    In which case, why bother using Coherence? You're not really gaining anything, are you?
    What I'm trying to explain is that you're probably not going to get that "micro-second" level performance on a fully configured Coherence cluster, running across multiple machines, going via proxies for c++ clients. Coherence is designed to be a scalable, fault-tolerant, distributed caching/processing system. It's not really designed for real-time, guaranteed, nano-second/micro-second level processing. There are much better product stacks out there for that type of processing if that is your ultimate goal, IMHO.
    As you say, just writing to a small, local Map (or array, List, Set, etc.) in a local JVM is always going to be very fast - literally as fast as the processor running in the machine. But that's not really the focus of a product like Coherence. It isn't trying to "out gun" what you can achieve on one machine doing simple processing; Coherence is designed for scalability rather than outright performance. Of course, the use of local caches (including Coherence's near caching or replicated caching), can get you back some of the performance you've "lost" in a distributed system, but it's all relative.
    If you wander over to a few of the CUG presentations and attend a few CUG meetings, one of the first things the support guys will tell you is "benchmark on a proper cluster" and not "on a localised development machine". Why? Because the difference in scalability and performance will be huge. I'm not really trying to deter you from Coherence, but I don't think it's going to meet you requirements when fully configured in a cluster of "1 Micro seconds for 100000 data collection" on a continuous basis.
    Just my two cents.
    Cheers,
    Steve
    NB. I don't work for Oracle, so maybe they have a different opinion. :)

  • Insert query takes long time

    Hi,
    I have written a procedure that does the following :
    1- Creates a temp table
    2- INSERT /*+ append */ INTO <temp table>
    (Select ......,
    (select sum(amt)
    from tbl1 b
    where b.col1=a.col2 and b.col3=a.col3 and (b.col4=a.col4 OR b.col5=a.col5) ...
    grp by col1,col2,col3),
    from tbl1 a
    where a.col1=.................
    3- Query to delete the duplicate rows from the temp table....
    4- Populate summarized data from TEMP TABLE to tbl1
    5- drops the temp table.
    Now this procedure takes around 2-3 mins for 2lakh records on local db, but when executed on production db takes 4 hours, when called from the application.
    When the log was reviewed it took 4 hours just to insert the data into TEMP TABLE.
    (*Note: this problem occurs only after executing the procedure for continuously 1 week or so. When the bea server is restarted and the application is run, it works fine. but after few days again the performance detiorates.
    What could be the reason for this weird problem?!!! Please give me some tips, which can help me to figure out the problem.
    Thanks
    Shruts.

    **I have renamed the cols and table.
    CREATE OR REPLACE PROCEDURE PROC_TEST(p_1 IN number,p_2 IN number,p_3 IN varchar2)
    is
    vsql varchar2(5000);
    Error_Message varchar2(200);
    vcalc varchar2(150);
    v_rec_present number;
    begin
         SELECT nvl(count(*),0) into v_rec_present
         FROM USER_TABLES
         WHERE upper(TABLE_NAME)=upper('TMP_TEST');
         if v_rec_present>0 then
         EXECUTE IMMEDIATE 'DROP table TMP_TEST';
         end if;
         EXECUTE IMMEDIATE 'CREATE TABLE TMP_TEST as select * from TBL1 where 1=2';
         vsql:= 'select distinct NULL as col1,a.scol2,a.ncol3,a.scol4, a.ncol5,a.scol6,a.dcol7,a.dcol8,null as dcol9,a.scol10,';
         vsql:=vsql||' nvl((select sum(t.amount) as TOTAL_AMT ';
         vsql:=vsql||' from TBL1 t';
         vsql:=vsql||' where t.ncol3='||p_1;
         vsql:=vsql||' and t.ncol3=a.ncol3';
         vsql:=vsql||' and t.scol4=a.scol4 and t.scol10=a.scol10 ';
         vsql:=vsql||' and (t.ncol5=a.ncol5 OR t.scol6=a.scol6)';
         vsql:=vsql||' and t.ncol11=a.ncol11      and t.ccol12=a.ccol12';
         vsql:=vsql||' and t.dcol7=a.dcol7 and t.dcol8=a.dcol8';     
         vsql:=vsql||' group by t.ncol3,t.scol4,';
         vsql:=vsql||' t.dcol7,t.dcol8, t.scol10,t.ncol11, t.ccol12),0) as amount,';
         vsql:=vsql||' a.ccol12,a.ncol11,';
         vsql:=vsql||' a.ncol13, null as ncol14, null as scol15, null as dcol16, null as scol17, null as scol18,';
         vsql:=vsql||' a.scol19, a.ccol20,a.sUser, sysdate as date_ins, a.site_ins,null as description';
         vsql:=vsql||' from TBL1 a';
         vsql:=vsql||' where a.ncol3='||p_1;
         if p_2=1 then
         vcalc:=' SYSDATE ';
         else
              vcalc:='to_date((to_char(to_date('''||p_3||''',''dd-mon-yyyy hh:mi:ss am''),''mm/dd/yyyy'') ) ,''mm/dd/yyyy'')' ;
         end if;
         vsql:=vsql||' and (case when a.ccol20=''TC'' and a.ccol12=''R''';
         vsql:=vsql||' then (case when '||p_2||'=0 and to_date(to_char(a.dcol9,''mm/dd/yyyy''),''mm/dd/yyyy'')='||vcalc;
         vsql:=vsql||' then ''TRUE'' ELSE ''FALSE'' END)';
         vsql:=vsql||' else ''TRUE'' END)=''TRUE''';
         /* if accrual flag=0 and calcenddt<>NULL then */
         if p_2=0 and p_3 is not NULL then
              vsql:=vsql||' and (a.dcol9 is null oR     (to_char(a.dcol9,''YYYY'')<=to_char(sysdate,''YYYY'') and';
              vsql:=vsql||' to_date(to_char(a.dcol9,''mm/dd/yyyy hh24:mi:ss''),''mm/dd/yyyy hh24:mi:ss'')<=to_date((to_char(to_date('''||p_3||''',''dd-mon-yyyy hh:mi:ss am''),''mm/dd/yyyy'') || ''23:59:59'') ,''mm/dd/yyyy hh24:mi:ss'')))';
         elsif p_2=1 then
              vsql:=vsql||' and (a.dcol9 is null oR     ((to_char(a.dcol9,''YYYY'')<=to_char(sysdate,''YYYY'') or';
              vsql:=vsql||' to_char(a.dcol9,''YYYY'')>to_char(sysdate,''YYYY''))))';
    end if;
    vsql:= 'INSERT /*+ append */ INTO TMP_TEST '|| vsql;
    EXECUTE IMMEDIATE vsql;
    EXECUTE IMMEDIATE 'truncate table TBL1';
    EXECUTE IMMEDIATE 'INSERT INTO TBL1 SELECT * FROM TMP_TEST';
    EXECUTE IMMEDIATE 'DROP table TMP_TEST';
    vsql:='DELETE from TBL1 a';
    vsql:=vsql||' where a.ncol3='||p_1;
    vsql:=vsql||' and ROWID<>(select min(ROWID)';
    vsql:=vsql||' from TBL1 b';
    vsql:=vsql||' where (a.scol6=b.scol6 OR a.ncol5=b.ncol5)';
    vsql:=vsql||' AND b.ncol3='||p_1;
    vsql:=vsql||' and a.ncol3=b.ncol3 and a.scol4=b.scol4 and a.scol10=b.scol10';
    vsql:=vsql||' and a.dcol7=b.dcol7';
    vsql:=vsql||' and a.dcol8=b.dcol8';
    vsql:=vsql||' and a.ccol12=b.ccol12 and a.ncol11=b.ncol11';
    vsql:=vsql||' group by a.scol4,a.dcol7,a.dcol8,a.scol10,a.ccol12,a.ccol20)';
    EXECUTE IMMEDIATE vsql;
    EXCEPTION
         WHEN OTHERS THEN
              Error_Message := 'Error in executing SP "PROC_TEST" '|| chr(10) ||'Error Code is ' || SQLCODE || Chr(10) || 'Error Message is ' || SQLERRM;
              dbms_output.put_line ('ERROR:-'||Error_message);
              raise;
    end;
    ******************************************************************************************

  • Clear operation takes long time and gets interrupted in ThreadGate.doWait

    Hi,
    We are running Coherence 3.5.3 cluster with 16 storage enabled nodes and 24 storage disabled nodes. We have about hundred of partitioned caches with NearCaches (invalidation strategy = PRESENT, size limit for different caches 60-200K) and backup count = 1. For each cache we have a notion of cache A and cache B. Every day either A or B is active and is used by business logic while the other one is inactive, not used and empty. Daily we load fresh data to inactive caches, mark them as active (switch business logic to work with fresh data from those caches), and clear all yesterday's data in those caches which are not used today.
    So at the end of data load we execute NamedCache.clear() operation for each inactive cache from storage disabled node. From time to time, 1-2 times a week, the clear operation fails on one of 2 our biggest caches (one has 1.2M entries and another one has 350K entries). We did some investigations and found that NamedCache.clear operation fires many events within Coherence cluster to clear NearCaches so that operation is quite expensive. In some other simular posts there were suggestions to not use NamedCache.clear, but rather use NamedCache.destroy, however that doesn't work for us in current timelines. So we implemented simple retry logic that retries NamedCache.clear() operation up to 4 times with increasing delay between the attempts (1min, 2 min, 4 min).
    However that didn't help. 3 out of those attempts failed with the same error on one storage enabled node and 1 out of those 4 attempts failed on another storage enabled node. In all cases a Coherence worker thread that is executing ClearRequest on storage enabled node got interrupted by Guardian after it reached its timeout while it was waiting on lock object at ThreadGate.doWait. Please see below:
    Log from the node that calls NamedCache.clear()
    Portable(com.tangosol.util.WrapperException): (Wrapped: Failed request execution for ProductDistributedCache service on Member(Id=26, Timestamp=2012-09-04 13:37:43.922, Address=32.83.113.116:10000, MachineId=3149, Location=machine:mac305,process:2
    7091,member:mac305.instance1, Role=storage) (Wrapped: ThreadGate{State=GATE_CLOSING, ActiveCount=3, CloseCount=0, ClosingT
    hread= Thread[ProductDistributedCacheWorker:1,5,ProductDistributedCache]}) null) null
    Caused by:
    Portable(java.lang.InterruptedException) ( << comment: this came form storage enabled node >> )
    at java.lang.Object.wait(Native Method)
    at com.tangosol.util.ThreadGate.doWait(ThreadGate.java:489)
    at com.tangosol.util.ThreadGate.close(ThreadGate.java:239)
    at com.tangosol.util.SegmentedConcurrentMap.lock(SegmentedConcurrentMap.java:180)
    at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.DistributedCache.onClearRequest(DistributedCache.CDB:27)
    at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.DistributedCache$ClearRequest.run(DistributedCache.CDB:1)
    at com.tangosol.coherence.component.util.DaemonPool$WrapperTask.run(DaemonPool.CDB:1)
    at com.tangosol.coherence.component.util.DaemonPool$WrapperTask.run(DaemonPool.CDB:32)
    at com.tangosol.coherence.component.util.DaemonPool$Daemon.onNotify(DaemonPool.CDB:63)
    at com.tangosol.coherence.component.util.Daemon.run(Daemon.CDB:42)
    at java.lang.Thread.run(Thread.java:619)
    Log from the that storage enabled node which threw an exception
    Sat Sep 08 04:38:37 EDT 2012|**ERROR**| com.tangosol.coherence.component.util.logOutput.Log4j | 2012-09-08 04:38:37.720/31330
    1.617 Oracle Coherence EE 3.5.3/465 <Error> (thread=DistributedCache:ProductDistributedCache, member=26): Attempting recovery
    (due to soft timeout) of Guard{Daemon=ProductDistributedCacheWorker:1} |Client Details{sdpGrid:,ClientName:  ClientInstanceN
    ame: ,ClientThreadName:  }| Logger@9259509 3.5.3/465
    Sat Sep 08 04:38:37 EDT 2012|**WARN**| com.tangosol.coherence.component.util.logOutput.Log4j | 2012-09-08 04:38:37.720/313301
    .617 Oracle Coherence EE 3.5.3/465 <Warning> (thread=Recovery Thread, member=26): A worker thread has been executing task: Message "ClearRequest"
    FromMember=Member(Id=38, Timestamp=2012-09-07 10:12:27.402, Address=32.83.113.120:10000, MachineId=40810, Location=machine:
    mac313,process:22837,member:mac313.instance1, Role=maintenance)
    FromMessageId=5278229
    Internal=false
    MessagePartCount=1
    PendingCount=0
    MessageType=1
    ToPollId=0
    Poll=null
    Packets
    [000]=Directed{PacketType=0x0DDF00D5, ToId=26, FromId=38, Direction=Incoming, ReceivedMillis=04:36:49.718, ToMemberSet=nu
    ll, ServiceId=6, MessageType=1, FromMessageId=5278229, ToMessageId=337177, MessagePartCount=1, MessagePartIndex=0, NackInProg
    ress=false, ResendScheduled=none, Timeout=none, PendingResendSkips=0, DeliveryState=unsent, Body=0x000D551F0085B8DF9FAECE8001
    0101010204084080C001C1F80000000000000010000000000000000000000000000000000000000000000000, Body.length=57}
    Service=DistributedCache{Name=ProductDistributedCache, State=(SERVICE_STARTED), LocalStorage=enabled, PartitionCount=257, B
    ackupCount=1, AssignedPartitions=16, BackupPartitions=16}
    ToMemberSet=MemberSet(Size=1, BitSetCount=2
    Member(Id=26, Timestamp=2012-09-04 13:37:43.922, Address=32.83.113.116:10000, MachineId=3149, Location=machine:mac305,process:27091,member:mac305.instance1, Role=storage)
    NotifySent=false
    } for 108002ms and appears to be stuck; attempting to interrupt: ProductDistributedCacheWorker:1 |Client Details{sdpGrid:,C
    lientName: ClientInstanceName: ,ClientThreadName: }| Logger@9259509 3.5.3/465
    I am looking for your help. Please let me know if you see what is the reason for the issue and how to address it.
    Thank you

    Today we had that issue again and I have gathered some more information.
    Everything was the same as I described in the previous posts in this thread: first attempt to clear a cache failed and next 3 retries also failed. All 4 times 2 storage enabled nodes had that "... A worker thread has been executing task: Message "ClearRequest" ..." error message and got interrupted by Guardian.
    However after that I had some time to do further experiments. Our App has cache management UI that allows to clear any cache. So I started repeatedly taking thread dumps on those 2 storage enabled nodes which failed to clear the cache and executed cache clear operation form that UI. One of storage enabled nodes successfully cleared its part, but the other still failed. It failed with completely same error.
    So, I have a thread dump which I took while cache clear operation was in progress. It shows that a thread which is processing that ClearRequest is stuck waiting in ThreadGate.close method:
    at java.lang.Object.wait(Native Method)
    at com.tangosol.util.ThreadGate.doWait(ThreadGate.java:489)
    at com.tangosol.util.ThreadGate.close(ThreadGate.java:239)
    at com.tangosol.util.SegmentedConcurrentMap.lock(SegmentedConcurrentMap.java:180)
    at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.DistributedCache.onClearRequest(DistributedCache.CDB:27)
    at
    All subsequents attempts to clear cache from cache management UI failed until we restarted that storage enabled node.
    It looks like some thread left ThreadGate in a locked state, and any further attempts to apply a lock as part of ClearRequest message fail. May be it is known issue of Coherence 3.5.3?
    Thanks

  • Inserting data takes long time

    Hi,
    when I am insterting data in my application it's took very long time. can anybody tell me where is the problem why it's taking very long time.
    Thanks in advance

    What kind of replication r u using?
    if it is streams then below metalink docs will help u.
    goodluck
    Subject:      Streams Performance Recommendations
         Doc ID:      Note:335516.1
    REFERENCES
    Note 298877.1 10g Streams Recommended Configuration
    Note 259609.1 Script to Prevent Excessive Spill of Message From
    the Streams Buffer Queue To Disk
    Note 273674.1 Streams Configuration Report and Health Check Script
    Note 290605.1 Oracle Streams STRMMON Monitoring Utility
    Note 238455.1 Streams Supported and Unsupported Datatyp

  • INSERT INTO TABLE using SELECT takes long time

    Hello Friends,
    --- Oracle version 10.2.0.4.0
    --- I am trying to insert around 2.5 lakhs records in a table using INSERT ..SELECT. The insert takes long time and seems to be hung.
    --- When i try to SELECT the query fetches the rows in 10 seconds.
    --- Any clue why it is taking so much time

    vishalrs wrote:
    Hello Friends,hello
    >
    >
    --- Oracle version 10.2.0.4.0
    alright
    --- I am trying to insert around 2.5 lakhs records in a table using INSERT ..SELECT. The insert takes long time and seems to be hung.
    I don't know how a lakh is, but it sounds like a lot...
    --- When i try to SELECT the query fetches the rows in 10 seconds.
    how did you test this? and did you fetch the last record, or just the first couple of hundred.
    --- Any clue why it is taking so much timeWithout seeing anything, it's impossible to tell the reason.
    Search the forum for "When your query takes too long"

  • JDBC Insert takes more time

    Hi,
    We are using BPM to insert a JDBC table.  The send step takes 5 mins to insert 10k records.  We have used similar design in other processes but does not take much time,.
    What would be the issue?  
    Regards
    Krish

    Krish,
    We are using BPM to insert a JDBC table.  The send step takes 5 mins to insert 10k records.
    I think that indexing has not been done. Verify that. if not, do the indexing which will reduce the processing time significantly.
    Regards,
    Neetesh

  • Delete DML statment takes more time than Update or Insert.

    i want to know whether a delete statement takes more time than an update or insert DML command. Please help in solving the doubt.
    Regards.

    i do not get good answers sometimes, so, i ask again.I think Alex answer to your post was quite complete. If you missed some information, continue the same post, instead of opening a new thread with the same subject and content.
    You should be satistied with the answers you get, I also answered your question about global indexes, and I do think my answer was very complete. You may ask more if you want, but stop multiposting please. It is quite annoying.
    Ok, have a nice day

  • Insert query takes too much time

    I have two select clauses as follows:
    "select * from employee" This returns me 6000 rows.
    & I have next clause as
    "select * from employee where userid in(1,2,3,....,3000)"
    This returns me 3000 rows.
    Now i have to insert the result of above queries into same extended list view of Visual Basic. But the insert for first query takes 11 seconds while second takes 34 sec. We have evaluated this that this time is for insert query & not for select query.
    I want to know that even if the Ist query returns 6000 rows it takes lesser time than the second which is
    inserting 3000 rows.
    We are using Oracle 8.1.7
    Thanks in advance

    The first query can do a straight dump of the table. The second select has to compare every userid to a hardcoded list of 3000 numbers. This will take quite a bit longer. Try rewriting it to
    select * from employee where userid between 1 and 3000
    It will run much faster then the other query.

  • Procedure takes long time to execute...

    Hi all
    i wrote the proxcedure but it takes long time to execute.
    The INterdata table contains 300 records.
    Here is the procedure:
    create or replace procedure inter_filter
    is
         /*v_sessionid interdata.sessionid%type;
         v_clientip interdata.clientip%type;
         v_userid interdata.userid%type;
         v_logindate interdata%type;
         v_createddate interdata%type;
         v_sourceurl interdata%type;
         v_destinationurl interdata%type;*/
         v_sessionid filter.sessionid%type;
         v_filterid filter.filterid%type;
         cursor c1 is
         select sessionid,clientip,browsertype,userid,logindate,createddate,sourceurl,destinationurl
         from interdata;
         cursor c2 is
         select sessionid,filterid
         from filter;
    begin
         open c2;
         loop
              fetch c2 into v_sessionid,v_filterid;
              for i in c1 loop
                   if i.sessionid = v_sessionid then
                        insert into filterdetail(filterdetailid,filterid,sourceurl,destinationurl,createddate)
                        values (filterdetail_seq.nextval,v_filterid,i.sourceurl,i.destinationurl,i.createddate);
                   else
                        insert into filter (filterid,sessionid,clientip,browsertype,userid,logindate,createddate)
                        values (filter_seq.nextval,i.sessionid,i.clientip,i.browsertype,i.userid,i.logindate,i.createddate);
                        insert into filterdetail(filterdetailid,filterid,sourceurl,destinationurl,createddate)
                        values (filterdetail_seq.nextval,filter_seq.currval,i.sourceurl,i.destinationurl,i.createddate);
                   end if;
              end loop;
         end loop;
         commit;
    end
    Please Help!
    Prathamesh

    i wrote the proxcedure but it takes long time to execute.Please define "long time". How long does it take? What are you expecting it to take?
    The INterdata table contains 300 records.But how many records are there in the FILTER table? As this is the one you are driving off this is going to determine the length of time it takes to complete. Also, this solution inserts every row in the INTERDATA table for each row in the FILTER table - in other words, if the FILTER table has twenty rows to start with you are going to end up with 6000 rows in FILTERDETAIL. No wonder it takes a long time. Is that want you want?
    Also of course, you are using PL/SQL cursors when you ought to be using set operations. Did you try the solution I posted in Re: Confusion in this  scenario>>>>>>> on this topic?
    Cheers, APC

  • Which of these takes less time?

    Which of these takes less time?
    INSERT INTO TABLE_1 AS SELECT * FROM TABLE_2;
    CREATE TABLE TABLE_1 SELECT * FROM TABLE_2;
    Thanks,
    Bhagat

    here's what the documentation says about a table created with the NOLOGGING clause:
    "Specify NOLOGGING if you do not want these operations to be logged.
    For a nonpartitioned object, the value specified for this clause is the actual physical attribute of the segment associated with the object."
    I read that to mean that segment information is not logged. I don't see where it says that inserts are not logged.
    And my testing on versions 9, 10.1 and 10.2 have shown that normal inserts to a table created with nologging mode will generate the same amount of redo as inserts to a table created with logging mode.
    Using APPEND will drastically reduce the amount of redo generated. Here's some of my findings showing the amount of redo (in bytes) generated for different methods:
    v10.2.0.3.0
    table structure:
    t( a number, b number)
    insert 50,000 rows per test
    created regular table, did NOT enable parallel dml
    insert append parallel :  141808 redo
    insert parallel        :  142032 redo
    insert append          :    1156 redo
    insert                 :  754120 redo
    regular table, alter session enable parallel dml:
    insert append parallel :  141180
    insert parallel        :  141876
    insert append          :   16156
    insert                 :  748552
    create table with nologging option, did NOT enable parallel dml:
    insert append          :   16000
    insert                 :  748616let the debate begin (again)

  • MVIEW refresh takes long time

    Materialized view takes long time to refresh but when i tried select & insert into table it's very fast.
    i executed SQL and it takes ust 1min ( total rows is 447 )
    but while i refresh the MVIEW it takes 1.5 hrs ( total rows is 447 )
    MVIEW configration :-
    CREATE MATERIALIZED VIEW EVAL.EVALSEARCH_PRV_LWC
    TABLESPACE EVAL_T_S_01
    NOCACHE
    NOLOGGING
    NOCOMPRESS
    NOPARALLEL
    BUILD DEFERRED
    REFRESH FORCE ON DEMAND
    WITH PRIMARY KEY
    Not sure why so much diffrence

    infant_raj wrote:
    Materialized view takes long time to refresh but when i tried select & insert into table it's very fast.
    i executed SQL and it takes ust 1min ( total rows is 447 )
    but while i refresh the MVIEW it takes 1.5 hrs ( total rows is 447 )A SELECT does a consistent read.
    A MV refresh does that and also writes database data.
    These are not the same thing and cannot be directly compared.
    So instead of pointing at the SELECT execution time and asking why the MV refresh is not as fast, look instead WHAT the refresh is doing and HOW it is doing that.
    Is the execution plan sane? What events are the top ones for the MV refresh? What are the wait states that contributes most to the processing time of the refresh?
    You cannot use the SELECT statement's execution time as a direct comparison metric. The work done by the refresh is more than the work done by the SELECT. You need to determine exactly what work is done by the refresh and whether that work is done in a reasonable time, and how other sessions are impacting the refresh (it could very well be blocked by another session).

  • What causes BUFFER GETS and PHYSICAL READS in INSERT operation to be high?

    Hi All,
    Am performing a huge number of INSERTs to a newly installed Oracle XE 10.2.0.1.0 on Windows. There is no SELECT statement running, but just INSERTs one after the other of 550,000 in count. When I monitor the SESSION I/O from Home > Administration > Database Monitor > Sessions, I see the following stats:
    BUFFER GETS = 1,550,560
    CONSISTENT GETS = 512,036
    PHYSICAL READS = 3,834
    BLOCK CHANGES = 1,034,232
    The presence of 2 stats confuses. Though the operation is just INSERT in database for this session, why should there be BUFFER GETS of this magnitude and why should there by PHYSICAL READS. Aren't these parameters for read operations? The BLOCK CHANGES value is clear as there are huge writes and the writes change these many blocks. Can any kind soul explain me what causes there parameters to show high value?
    The total columns in the display table are as follows (from the link mentioned above)
    1. Status
    2. SID
    3. Database Users
    4. Command
    5. Time
    6. Block Gets
    7. Consistent Gets
    8. Physical Reads
    9. Block Changes
    10. Consistent Changes
    What does CONSISTENT GETS and CONSISTENT CHANGES mean in a typical INSERT operation? And does someone know which all tables are involved in getting these values?
    Thank,
    ...

    Flake wrote:
    Hans, gracias.
    The table just have 2 columns, both of which are varchar2 (500). No constraints, no indexes, neither foreign key references are in place. The total size of RAM in system is 1GB, and yes, there are other GUI's going on like Firefox browser, notepad and command terminals.
    But, what does these other applications have to do with Oracle BUFFER GETS, PHYSICAL READS etc.? Awaiting your reply.Total RAM is 1GB. If you let XE decide how much RAM is to be allocated to buffers, on startup that needs to be shared with any/all other applications. Let's say that leaves us with, say 400M for the SGA + PGA.
    PGA is used for internal stuff, such as sorting, which is also used in determing the layout of secondary facets such as indexes and uniqueness. Total PGA usage varies in size based on the number of connections and required operations.
    And then there's the SGA. That needs to cover the space requirement for the data dictionary, any/all stored procedures and SQL statements being run, user security and so on. As well as the buffer blocks which represent the tablespace of the database. Since it is rare that the entire tablespace will fit into memory, stuff needs to be swapped in and out.
    So - put too much space pressure on the poor operating system before starting the database, and the SGA may be squeezed. Put that space pressure on the system and you may enbd up with swapping or paging.
    This is one of the reasons Oracle professionals will argue for dedicated machines to handle Oracle software.

  • Why update query takes  long time ?

    Hello everyone;
    My update query takes long time.  In  emp  ( self testing) just  having 2 records.
    when i issue update query , it takes long time;
    SQL> select  *  from  emp;
      EID  ENAME     EQUAL     ESALARY     ECITY    EPERK       ECONTACT_NO
          2   rose              mca                  22000   calacutta                   9999999999
          1   sona             msc                  17280    pune                          9999999999
    Elapsed: 00:00:00.05
    SQL> update emp set esalary=12000 where eid='1';
    update emp set esalary=12000 where eid='1'
    * ERROR at line 1:
    ORA-01013: user requested cancel of current operation
    Elapsed: 00:01:11.72
    SQL> update emp set esalary=15000;
    update emp set esalary=15000
      * ERROR at line 1:
    ORA-01013: user requested cancel of current operation
    Elapsed: 00:02:22.27

    Hi  BCV;
    Thanks for your reply but it doesn't provide output,  please  see   this.
    SQL> update emp set esalary=15000;
    ........... Lock already occured.
    >> trying to trace  >>
    SQL> select HOLDING_SESSION from dba_blockers;
    HOLDING_SESSION
                144
    SQL> select sid , username, event from v$session where username='HR';
    SID USERNAME     EVENT
       144   HR    SQL*Net message from client
       151   HR    enq: TX - row lock contention
       159   HR    SQL*Net message from client
    >> It  does n 't  provide  clear output about  transaction lock >>
    SQL> SELECT username, v$lock.SID, TRUNC (id1 / POWER (2, 16)) rbs,
      2  BITAND (id1, TO_NUMBER ('ffff', 'xxxx')) + 0 slot, id2 seq, lmode,
      3  request
      4  FROM v$lock, v$session
      5  WHERE v$lock.TYPE = 'TX'
      6  AND v$lock.SID = v$session.SID
      7  AND v$session.username = USER;
      no rows selected
    SQL> select MACHINE from v$session where sid = :sid;
    SP2-0552: Bind variable "SID" not declared.

  • Query Takes more Time when i execute from the Instant client.

    Hi,
    Currently in our Env we have some Queries takes more time when we run from the Instant Client.
    System Details
    OS=Solaris 10 x86 64bit
    Oracle 10.2.0.4
    Client Side
    $ sqlplus trd_trd_ro/trd_trd_ro@prdba001/TRADE1
    SQL*Plus: Release 10.2.0.2.0 - Production on Mon Aug 9 16:26:25 2010
    Copyright (c) 1982, 2005, Oracle.  All Rights Reserved.
    Connected to:
    Oracle Database 10g Release 10.2.0.4.0 - Production
    SQL> set timing on
    SQL> select mod(lastinstmessagesequence, 1000000000) LastInstIDSeqNo from tibex_msgseqbyuseralias where useralias='2221';
    no rows selected
    Elapsed: 00:01:54.19
    SQL> Disconnected from Oracle Database 10g Release 10.2.0.4.0 - ProductionSame Query running on Server Side
    ^C130-oracle@prdba001 txt: sql
    Database: trd_trd_owner/trd_trd_owner@prdba001/TRADE1
    SQL*Plus: Release 10.2.0.4.0 - Production on Mon Aug 9 17:15:18 2010
    Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.
    Connected to:
    Oracle Database 10g Release 10.2.0.4.0 - Production
    trd_trd_owner@TRADE1>  set timing on
    trd_trd_owner@TRADE1> select mod(lastinstmessagesequence, 1000000000) LastInstIDSeqNo from tibex_msgseqbyuseralias where useralias='2221';
    no rows selected
    Elapsed: 00:00:00.12
    trd_trd_owner@TRADE1> exitKindly help me what could be the Issues.

    Hi Charles,
    Thanks for your Quick response.I pulled the info.
    sys@TRADE1> SELECT  * FROM  TABLE(DBMS_XPLAN.DISPLAY_CURSOR('bpxr7axhxaqvy',NULL,'ALLSTATS LAST'));
    PLAN_TABLE_OUTPUT
    SQL_ID  bpxr7axhxaqvy, child number 0
    select /*+ GATHER_PLAN_STATISTICS */ mod(lastinstmessagesequence, :"SYS_B_0") LastInstIDSeqNo from
    tibex_msgseqbyuseralias where useralias=:"SYS_B_1"
    Plan hash value: 1955857846
    | Id  | Operation                       | Name                  | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
    |   1 |  SORT GROUP BY NOSORT           |                       |      1 |     21 |      0 |00:00:00.06 |    6121 |
    |   2 |   VIEW                          |                       |      1 |     21 |      0 |00:00:00.06 |    6121 |
    |   3 |    UNION-ALL                    |                       |      1 |        |      0 |00:00:00.06 |    6121 |
    |   4 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.05 |    3073 |
    |*  5 |      TABLE ACCESS FULL          | TIBEX_QUOTE           |      1 |  30080 |      0 |00:00:00.05 |    3073 |
    |   6 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |
    |   7 |      TABLE ACCESS BY INDEX ROWID| TIBEX_ORDER           |      1 |    971 |      0 |00:00:00.01 |       3 |
    |*  8 |       INDEX RANGE SCAN          | TIBEX_ORDER_IDX_OLT   |      1 |    971 |      0 |00:00:00.01 |       3 |
    |   9 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |
    |* 10 |      TABLE ACCESS FULL          | TIBEX_TSTRADE         |      1 |      1 |      0 |00:00:00.01 |       3 |
    |  11 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |
    |* 12 |      TABLE ACCESS FULL          | TIBEX_IOIREQUEST      |      1 |      1 |      0 |00:00:00.01 |       3 |
    |  13 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |     126 |
    |* 14 |      TABLE ACCESS FULL          | TIBEX_BESTEXREL       |      1 |      1 |      0 |00:00:00.01 |     126 |
    |  15 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |    2862 |
    |* 16 |      INDEX FAST FULL SCAN       | SYS_C0058325          |      1 |    339 |      0 |00:00:00.01 |    2862 |
    |  17 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |      31 |
    |* 18 |      TABLE ACCESS FULL          | TIBEX_EDPPULLORDERS   |      1 |      1 |      0 |00:00:00.01 |      31 |
    |  19 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 20 |      INDEX RANGE SCAN           | SYS_C0058803          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  21 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 22 |      INDEX RANGE SCAN           | SYS_C0057785          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  23 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 24 |      INDEX RANGE SCAN           | SYS_C0057827          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  25 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |
    |* 26 |      TABLE ACCESS FULL          | TIBEX_DELETEADMIN     |      1 |      1 |      0 |00:00:00.01 |       3 |
    |  27 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 28 |      INDEX RANGE SCAN           | SYS_C0058148          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  29 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 30 |      INDEX RANGE SCAN           | SYS_C0058264          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  31 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 32 |      INDEX RANGE SCAN           | SYS_C0058516          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  33 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 34 |      INDEX RANGE SCAN           | SYS_C0058561          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  35 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 36 |      INDEX RANGE SCAN           | SYS_C0058783          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  37 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 38 |      INDEX RANGE SCAN           | SYS_C0058977          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  39 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 40 |      INDEX RANGE SCAN           | SYS_C0058859          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  41 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 42 |      INDEX RANGE SCAN           | SYS_C0059197          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  43 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |
    |* 44 |      TABLE ACCESS FULL          | TIBEX_CANCELTRDADMIN  |      1 |      1 |      0 |00:00:00.01 |       3 |
    |  45 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |
    |* 46 |      TABLE ACCESS FULL          | TIBEX_BULKCANCELADMIN |      1 |      1 |      0 |00:00:00.01 |       3 |
    Predicate Information (identified by operation id):
    PLAN_TABLE_OUTPUT
       5 - filter("LASTINSTUSERALIAS"=:SYS_B_1)
       8 - access("LASTINSTUSERALIAS"=:SYS_B_1)
      10 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
      12 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
      14 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
      16 - filter("USERALIAS"=:SYS_B_1)
      18 - filter("USERALIAS"=:SYS_B_1)
      20 - access("USERALIAS"=:SYS_B_1)
      22 - access("USERALIAS"=:SYS_B_1)
      24 - access("USERALIAS"=:SYS_B_1)
      26 - filter(("USERALIAS" IS NOT NULL AND "USERALIAS"=:SYS_B_1))
      28 - access("USERALIAS"=:SYS_B_1)
      30 - access("USERALIAS"=:SYS_B_1)
      32 - access("USERALIAS"=:SYS_B_1)
      34 - access("USERALIAS"=:SYS_B_1)
      36 - access("USERALIAS"=:SYS_B_1)
      38 - access("USERALIAS"=:SYS_B_1)
      40 - access("USERALIAS"=:SYS_B_1)
      42 - access("USERALIAS"=:SYS_B_1)
      44 - filter("USERALIAS"=:SYS_B_1)
      46 - filter("USERALIAS"=:SYS_B_1)
    SQL_ID  bpxr7axhxaqvy, child number 1
    select /*+ GATHER_PLAN_STATISTICS */ mod(lastinstmessagesequence, :"SYS_B_0") LastInstIDSeqNo from
    tibex_msgseqbyuseralias where useralias=:"SYS_B_1"
    Plan hash value: 1955857846
    Plan hash value: 1955857846
    | Id  | Operation                       | Name                  | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
    |   1 |  SORT GROUP BY NOSORT           |                       |      1 |     21 |      0 |00:00:00.12 |    8545 |
    |   2 |   VIEW                          |                       |      1 |     21 |      0 |00:00:00.12 |    8545 |
    |   3 |    UNION-ALL                    |                       |      1 |        |      0 |00:00:00.12 |    8545 |
    |   4 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.10 |    5496 |
    |*  5 |      TABLE ACCESS FULL          | TIBEX_QUOTE           |      1 |  21056 |      0 |00:00:00.10 |    5496 |
    |   6 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       4 |
    |   7 |      TABLE ACCESS BY INDEX ROWID| TIBEX_ORDER           |      1 |    660 |      0 |00:00:00.01 |       4 |
    |*  8 |       INDEX RANGE SCAN          | TIBEX_ORDER_IDX_OLT   |      1 |    660 |      0 |00:00:00.01 |       4 |
    |   9 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |
    |* 10 |      TABLE ACCESS FULL          | TIBEX_TSTRADE         |      1 |      1 |      0 |00:00:00.01 |       3 |
    |  11 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |
    |* 12 |      TABLE ACCESS FULL          | TIBEX_IOIREQUEST      |      1 |      1 |      0 |00:00:00.01 |       3 |
    |  13 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |     126 |
    |* 14 |      TABLE ACCESS FULL          | TIBEX_BESTEXREL       |      1 |      1 |      0 |00:00:00.01 |     126 |
    |  15 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.02 |    2862 |
    |* 16 |      INDEX FAST FULL SCAN       | SYS_C0058325          |      1 |    339 |      0 |00:00:00.02 |    2862 |
    |  17 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |      31 |
    |* 18 |      TABLE ACCESS FULL          | TIBEX_EDPPULLORDERS   |      1 |      1 |      0 |00:00:00.01 |      31 |
    |  19 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 20 |      INDEX RANGE SCAN           | SYS_C0058803          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  21 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 22 |      INDEX RANGE SCAN           | SYS_C0057785          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  23 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 24 |      INDEX RANGE SCAN           | SYS_C0057827          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  25 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |
    |* 26 |      TABLE ACCESS FULL          | TIBEX_DELETEADMIN     |      1 |      1 |      0 |00:00:00.01 |       3 |
    |  27 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 28 |      INDEX RANGE SCAN           | SYS_C0058148          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  29 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    PLAN_TABLE_OUTPUT
    |* 30 |      INDEX RANGE SCAN           | SYS_C0058264          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  31 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 32 |      INDEX RANGE SCAN           | SYS_C0058516          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  33 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 34 |      INDEX RANGE SCAN           | SYS_C0058561          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  35 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 36 |      INDEX RANGE SCAN           | SYS_C0058783          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  37 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 38 |      INDEX RANGE SCAN           | SYS_C0058977          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  39 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 40 |      INDEX RANGE SCAN           | SYS_C0058859          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  41 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 42 |      INDEX RANGE SCAN           | SYS_C0059197          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  43 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |
    |* 44 |      TABLE ACCESS FULL          | TIBEX_CANCELTRDADMIN  |      1 |      1 |      0 |00:00:00.01 |       3 |
    |  45 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |
    |* 46 |      TABLE ACCESS FULL          | TIBEX_BULKCANCELADMIN |      1 |      1 |      0 |00:00:00.01 |       3 |
    Predicate Information (identified by operation id):
       5 - filter("LASTINSTUSERALIAS"=:SYS_B_1)
       8 - access("LASTINSTUSERALIAS"=:SYS_B_1)
      10 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
      12 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
      14 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
      16 - filter("USERALIAS"=:SYS_B_1)
      18 - filter("USERALIAS"=:SYS_B_1)
      20 - access("USERALIAS"=:SYS_B_1)
      22 - access("USERALIAS"=:SYS_B_1)
      24 - access("USERALIAS"=:SYS_B_1)
      26 - filter(("USERALIAS" IS NOT NULL AND "USERALIAS"=:SYS_B_1))
      28 - access("USERALIAS"=:SYS_B_1)
      30 - access("USERALIAS"=:SYS_B_1)
      32 - access("USERALIAS"=:SYS_B_1)
      34 - access("USERALIAS"=:SYS_B_1)
      36 - access("USERALIAS"=:SYS_B_1)
      38 - access("USERALIAS"=:SYS_B_1)
      40 - access("USERALIAS"=:SYS_B_1)
      42 - access("USERALIAS"=:SYS_B_1)
      44 - filter("USERALIAS"=:SYS_B_1)
      46 - filter("USERALIAS"=:SYS_B_1)
    SQL_ID  bpxr7axhxaqvy, child number 2
    select /*+ GATHER_PLAN_STATISTICS */ mod(lastinstmessagesequence, :"SYS_B_0") LastInstIDSeqNo from
    tibex_msgseqbyuseralias where useralias=:"SYS_B_1"
    Plan hash value: 1955857846
    | Id  | Operation                       | Name                  | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |
    |   1 |  SORT GROUP BY NOSORT           |                       |      1 |     21 |      1 |00:00:00.13 |    8476 |      3 |
    |   2 |   VIEW                          |                       |      1 |     21 |      1 |00:00:00.13 |    8476 |      3 |
    |   3 |    UNION-ALL                    |                       |      1 |        |      1 |00:00:00.13 |    8476 |      3 |
    |   4 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.10 |    5283 |      0 |
    |*  5 |      TABLE ACCESS FULL          | TIBEX_QUOTE           |      1 |  21056 |      0 |00:00:00.10 |    5283 |      0 |
    |   6 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      1 |00:00:00.01 |     148 |      3 |
    |   7 |      TABLE ACCESS BY INDEX ROWID| TIBEX_ORDER           |      1 |    660 |    150 |00:00:00.01 |     148 |      3 |
    PLAN_TABLE_OUTPUT
    |*  8 |       INDEX RANGE SCAN          | TIBEX_ORDER_IDX_OLT   |      1 |    660 |    150 |00:00:00.01 |       5 |      0 |
    |   9 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |      0 |
    |* 10 |      TABLE ACCESS FULL          | TIBEX_TSTRADE         |      1 |      1 |      0 |00:00:00.01 |       3 |      0 |
    |  11 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |      0 |
    |* 12 |      TABLE ACCESS FULL          | TIBEX_IOIREQUEST      |      1 |      1 |      0 |00:00:00.01 |       3 |      0 |
    |  13 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |     126 |      0 |
    |* 14 |      TABLE ACCESS FULL          | TIBEX_BESTEXREL       |      1 |      1 |      0 |00:00:00.01 |     126 |      0 |
    |  15 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.02 |    2862 |      0 |
    |* 16 |      INDEX FAST FULL SCAN       | SYS_C0058325          |      1 |    339 |      0 |00:00:00.02 |    2862 |      0 |
    |  17 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |      31 |      0 |
    |* 18 |      TABLE ACCESS FULL          | TIBEX_EDPPULLORDERS   |      1 |      1 |      0 |00:00:00.01 |      31 |      0 |
    |  19 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |* 20 |      INDEX RANGE SCAN           | SYS_C0058803          |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |  21 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |* 22 |      INDEX RANGE SCAN           | SYS_C0057785          |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |  23 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |* 24 |      INDEX RANGE SCAN           | SYS_C0057827          |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |  25 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |      0 |
    |* 26 |      TABLE ACCESS FULL          | TIBEX_DELETEADMIN     |      1 |      1 |      0 |00:00:00.01 |       3 |      0 |
    |  27 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |* 28 |      INDEX RANGE SCAN           | SYS_C0058148          |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |  29 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |* 30 |      INDEX RANGE SCAN           | SYS_C0058264          |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |  31 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |* 32 |      INDEX RANGE SCAN           | SYS_C0058516          |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |  33 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |* 34 |      INDEX RANGE SCAN           | SYS_C0058561          |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |  35 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |* 36 |      INDEX RANGE SCAN           | SYS_C0058783          |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |  37 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |* 38 |      INDEX RANGE SCAN           | SYS_C0058977          |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |  39 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |* 40 |      INDEX RANGE SCAN           | SYS_C0058859          |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |  41 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |* 42 |      INDEX RANGE SCAN           | SYS_C0059197          |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |  43 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |      0 |
    |* 44 |      TABLE ACCESS FULL          | TIBEX_CANCELTRDADMIN  |      1 |      1 |      0 |00:00:00.01 |       3 |      0 |
    |  45 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |      0 |
    |* 46 |      TABLE ACCESS FULL          | TIBEX_BULKCANCELADMIN |      1 |      1 |      0 |00:00:00.01 |       3 |      0 |
    Predicate Information (identified by operation id):
       5 - filter("LASTINSTUSERALIAS"=:SYS_B_1)
       8 - access("LASTINSTUSERALIAS"=:SYS_B_1)
      10 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
      12 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
      14 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
      16 - filter("USERALIAS"=:SYS_B_1)
      18 - filter("USERALIAS"=:SYS_B_1)
      20 - access("USERALIAS"=:SYS_B_1)
      22 - access("USERALIAS"=:SYS_B_1)
      24 - access("USERALIAS"=:SYS_B_1)
      26 - filter(("USERALIAS" IS NOT NULL AND "USERALIAS"=:SYS_B_1))
      28 - access("USERALIAS"=:SYS_B_1)
      30 - access("USERALIAS"=:SYS_B_1)
      32 - access("USERALIAS"=:SYS_B_1)
      34 - access("USERALIAS"=:SYS_B_1)
      36 - access("USERALIAS"=:SYS_B_1)
      38 - access("USERALIAS"=:SYS_B_1)
    PLAN_TABLE_OUTPUT
      40 - access("USERALIAS"=:SYS_B_1)
      42 - access("USERALIAS"=:SYS_B_1)
      44 - filter("USERALIAS"=:SYS_B_1)
      46 - filter("USERALIAS"=:SYS_B_1)
    249 rows selected.

Maybe you are looking for