Parrallel query and physical reads

Hi I have ran a query in uing OPQ degree 12 several time, but in subsiquent runs, im still seeing physical reads, should the data not be cached after the first run..
ie, run 4 is shown below:
Statistics
         33  recursive calls                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          
          0  db block gets                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            
       4866  consistent gets                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          
       3146  physical reads                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           
          0  redo size                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    7373850  bytes sent via SQL*Net to client                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         
     293742  bytes received via SQL*Net from client                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   
      26668  SQL*Net roundtrips to/from client                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        
          2  sorts (memory)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           
          0  sorts (disk)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             
     400002  rows processed  

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1027523970333
parallel query may use direct io, it may not use direct io.
parallel query may use the buffer cache, it may bypass it.
And in the next followup.
Tom, in what conditions parallel query would entirely bypass buffer cache? Thanks.
Followup June 15, 2005 - 10am Central time zone:
when it does direct IO to read the blocks.
"

Similar Messages

  • High user input output (I/O) and physical reads

    Hi guys
    Recently we have noticed that our database performance degraded significantly. as we looked around in grid control we noticed that the user IO and Physical reads are really high which cause the database to be laggy.
    at first we thought it was memory problem, so we added 2gb to sga. we have set sga to be automatic and it's been like this for the past 2 years.
    how do i trouble shoot this problem. i haven't found any troubleshooting guide for it yet.
    please instruct me on how to solve it
    database: 10.2.0.4 sparc
    regards
    Sina

    Top 5 Timed events
    db file sequential read          23,582          679          29          46.3     User I/O
    CPU time                                        626                    42.7     
    db file scattered read     3,089     70     23     4.8     User I/O
    db file parallel write     3,478     28     8     1.9     System I/O
    log file parallel write     4,201     24     6     1.7     System I/O
    SGA Memory Summary
    SGA regions     Begin Size (Bytes)     End Size (Bytes) (if different)
    Database Buffers     2,768,240,640     2,835,349,504
    Fixed Size     2,050,240     
    Redo Buffers     14,721,024     
    Variable Size     3,657,439,040     3,590,330,176
    Process Memory Summary
         Category     Alloc (MB)     Used (MB)     Avg Alloc (MB)     Std Dev Alloc (MB)     Max Alloc (MB)     Hist Max Alloc (MB)     Num Proc     Num Alloc
    B     Other     569.22     0     2.62     3.14     22     24     217     217
         Freeable     101.63     0.00     0.77     0.45     3          132     132
         SQL     91.51     45.35     0.44     0.76     4     78     209     192
         PL/SQL     12.50     5.57     0.06     0.07     0     4     217     217
         JAVA     5.40     5.38     1.08     0.09     1     2     5     5
    E     Other     603.20          3.03     3.62     22     24     199     199
         SQL     115.21     64.78     0.60     1.67     21     78     191     182
         Freeable     112.31     0.00     0.83     0.43     3          135     135
         PL/SQL     13.89     5.94     0.07     0.12     1     4     199     199
         JAVA     8.93     8.89     1.12     0.23     2     2     
    for some reason i can't paste a table into this post but if you want i can email you above tables

  • Difference between "Physical Read Total IO Requests Per Sec" and "Physical Read IO Requests Per Sec"

    What is the difference between "Physical Read Total IO Requests Per Sec" and "Physical Read IO Requests Per Sec" metrics in dba_hist_sysmetric_summary?

    From docs (Reference, Statistics Descriptions)   :
    physical read IO requests : Number of read requests for application activity (mainly buffer cache and direct load operation) which read one or more database blocks per request. This is a subset of "physical read total IO requests" statistic.
    physical read total IO requests : Number of read requests which read one or more database blocks for all instance activity including application, backup and recovery, and other utilities.

  • Consistent gets and physical reads

    Hi all,
    I am tuning a DM SQL query, by comparing execution plans with STAR TRANSFORMATION enabled or disabled. I got the following results:
    STAR TRANSFORMATION ON
    74889 consistent gets
    254365 physical reads
    STAR TRANSFORMATION OFF
    1945892 consistent gets
    168028 physical reads
    I thought a physical read would be counted as a logical read as well, because the data block would be read from disk (1 physical IO), placed in the buffer cache and then read from there (1 more logical IO or consistent get).
    So, one physical IO does not cause a logical IO?
    Thanks!
    Edited by: user10634835 on 12-Jul-2011 08:40

    But shouldn't consistent gets be >= physical reads (Since, as per my understanding, 1 PIO causes at least 1 LIO)? In this case it is not.
    74889 consistent gets
    254365 physical readsJust clarifying for my knowledge.
    regards

  • What is the diff b/w logical query and physical query?

    Thanks In advance

    In OBIEE terms the logical query is how you query the BI Server, the Presentation services sends logical SQL to the BI Server, you can also write your own using JDBC , pull from BI Server using ODI etc.
    The BI Server engine takes this logical query and writes (a number of) phyiscal querie(s) to satisfy the logical request, depeninding on how your BMM and Physical layer is setup. There are a number of rules the BI Server evaluates before deciding the most appropriate Physical query to generate, rules include Physical Joins, Aggregate tales / Hierarchy levels and so on.
    Hope this helps,
    Good luck with interview :-)
    Alastair

  • 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.

  • Physical reads and autotrace

    Hii all
    In http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:880343948514 tom gives an example table
    has a 320 block and the query "select * from table"
    autotrace output shows physical reads=46 the statics physical reads= number of block read from disk but table has 320 block how this could be ?
    Best regards..

    As Oracle has a buffer cache, Oracle will place blocks in buffer cache as soon as it needs it.
    When it needs those records subsequently, there will be a consistent get only.
    Logical I/O is predictable. Physical I/O depends on the size of the cache.
    There will never be a 1 on 1 relationship between size of a table and physical reads or you must disable the buffer cache.
    Clarifications about Asktom articles are also best asked at Asktom.
    Sybrand Bakker
    Senior Oracle DBA
    Experts: those who did read documentation.

  • Understanding Statistics io and Logical reads - is logical reads information correct

    Hi,
    This question arises during a performance test - on SQL Server 2012 with SP2.
    In the following example, table has only column and that is of data type INT.
    When inserted 592 records of data type INT it is doing only 1 logical read but as soon another record is inserted SP is reporting 2 logical reads. Why?
    In the code, i have highlighted difference between 
    statistics io - logical reads and sys.dm_exec_procedure_stats.total_logical_reads
    to understand the difference between these 2 information.
    set nocount on
    GO
    create table dbo.test_storage_and_logical_reads
    employee_number int --primary key
    GO
    go
    CREATE procedure dbo.test_sp_logical_reads
    as
    begin
    select
    employee_number
    from dbo.test_storage_and_logical_reads
    order by employee_number desc
    end
    go
    insert into dbo.test_storage_and_logical_reads
    (employee_number)
    VALUES (1)
    GO 592
    EXEC sp_spaceused 'dbo.test_storage_and_logical_reads'
    --set statistics io on
    --GO
    exec dbo.test_sp_logical_reads
    GO
    ----Table 'test_storage_and_logical_reads'. Scan count 1, logical reads 1, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    ---- But sys.dm_exec_procedure_stats.total_logical_reads is reporting 3 instead.
    truncate table dbo.test_storage_and_logical_reads
    GO
    insert into dbo.test_storage_and_logical_reads
    (employee_number)
    VALUES (1)
    GO 593
    EXEC sp_spaceused 'dbo.test_storage_and_logical_reads'
    exec dbo.test_sp_logical_reads
    GO
    ----Table 'test_storage_and_logical_reads'. Scan count 1, logical reads 2, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    ---- But sys.dm_exec_procedure_stats.total_logical_reads is reporting 4 instead.
    --drop procedure dbo.test_sp_logical_reads
    --drop table dbo.test_storage_and_logical_reads
    GO
    NB: I do understand the logical and physical reads. Thanks.
    For quick review of new features, try virtual labs: http://msdn.microsoft.com/en-us/aa570323

    Hi.
    I still need to test the scenario but if you read definition of this DMV it says 'Returns aggregate performance statistics for cached stored procedures' so I guess, I am not sure 3 can be due to this aggregated output given by this DMV. Will test it
    on SS 2012 SP2 will get back to you.
    Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it.
    My TechNet Wiki Articles
    Hi Shanky / Sean Gallardy
    i think Sean Gallardy created the "test_sp_logical_reads" table in master DB, i have that same issue when i accidentiatly created the table "test_sp_logical_reads" in master, but when i create the same table in USER DB like "sample1"
    it only allocate 1 page for 592,
    hi Asam,
    Let me narrow down the your question, if my understanding is correct ...
    <<When you have the free space in a page of a Heap, why SQL Server is assigning New page for a New Record>>
    Answer is in PFS bytes
    The answer is that PFS bytes are not fully reset until the page is reallocated. On deallocation, the only bit in the PFS byte that's changed is the allocation status bit - this makes it very easy to rollback a deallocation
    --Before inserting the 593 record plese execute the below query
    --Note Replace "database1" with your DBName
    DBCC TRACEON (3604);
    DBCC IND ('database1', 'test_storage_and_logical_reads', 1);
    --Result
    PageFID PagePID IAMFID IAMPID ObjectID IndexID PartitionNumber PartitionID iam_chain_type PageType IndexLevel NextPageFID NextPagePID PrevPageFID PrevPagePID
    1 2770 NULL NULL 517576882 0 1 72057594039828480 In-row data 10 NULL 0 0 0 0
    1 2769 1 2770 517576882 0 1 72057594039828480 In-row data 1 0 0 0 0 0
    --your intrested in the second record(page)
    DBCC PAGE ('database1', 1, 2769,3) WITH TABLERESULTS;
    --you can find 38th row as
    --PFS (1:1) = 0x64 MIXED_EXT ALLOCATED 100_PCT_FULL
    --which means your page is full
    --you can try inserting 300 rows it will show you PFS (1:1) = 0x61 MIXED_EXT ALLOCATED 50_PCT_FULL
    please refer in the below link
    http://blogs.msdn.com/b/sqlserverstorageengine/archive/2006/07/08/under-the-covers-gam-sgam-and-pfs-pages.aspx
    http://aboutsqlserver.com/2013/12/17/sql-server-storage-engine-heap-tables/
    "This page has a PFS byte value of 0x04 - how can it be full when its not allocated?"
    The answer is that PFS bytes are not fully reset until the page is reallocated. On deallocation, the only bit in the PFS byte that's changed is the allocation status bit - this makes it very easy to rollback a deallocation.
    Here's an example. Using a database with a simple table with one row.
    A DBCC PAGE of the IAM page includes:
    PFS (1:1) = 0x70 IAM_PG MIXED_EXT ALLOCATED 0_PCT_FULL
    If I run the following:
    BEGIN
    TRANSACTION
    DROP
    TABLE T1
    GO
    And then do the DBCC PAGE again, the output now includes:
    PFS (1:1) = 0x30 IAM_PG MIXED_EXT 0_PCT_FULL
    And if I rollback then transaction, the DBCC PAGE output reverts to:
    PFS (1:1) = 0x70 IAM_PG MIXED_EXT ALLOCATED 0_PCT_FULL
    Thanks
    Saravana Kumar C

  • Logical read Vs Physical Reads

    Hi,
    I want to know How should we balance the logical reads and physical reads on database.
    I generaly assume logical reads is always better but what if too many session accessing the same
    objects it will cause latch contention.
    If it is physical read then it will take more time to read from disk than reading from SGA.
    If I look at statspack report I check the
    Logical reads: 59,846.54 840.03
    Physical reads: 1,095.91 15.38
    Is there any standards for logical reads on database. If there is latch contentions can we go for the
    decreasing the SGA to avoid the contentions so that there will balance between the physical reads
    and logical reads.

    amitbansode wrote:
    I want to know How should we balance the logical reads and physical reads on database.There is no balance as it implies some kind of "+perfect ratio+" for logical I/O vs. physical I/O.
    A high percentage of physical I/O can be perfectly acceptable and normal and correct for a specific database (e.g. think of a system collecting telemetry data where 90% or more of all I/O is writing new telemetry into the database and the remaining 10% is querying the data, with old data being aged out from the database using partition drops which is negligible I/O).
    A high percentage of logical I/O can be indicative of a serious application design problem - where 80GB of database data is read and read again and again and again.. resulting in over a TB of logical I/O. (actually saw this in production database some years ago)
    So there is no balance (e.g. not true that physical I/O = BAD and logical I/O = GOOD). No perfect cache hit ratio figure that tells you that the database is doing the right amounts of logical and physical I/O.
    And I want to emphasise what Mark said - tuning requires you to identify the performance problem first, before trying to solve it.
    It is very dangerous to take one metric, like the I/O cache hit ratio, and attempt to tune that. It alone is meaningless. Just like memory utilisation alone is useless and CPU utilisation alone is useless. It does not by any means point to an actual performance problem. E.g. 100% CPU utilisation can mean hardware has insufficient horses, instead of performance issues related with application design, database setting or kernel configuration.
    I often repeat the following mantra here on OTN - a fundamental concept IMO for software engineering:
    A solution is only as good as the problem definition.
    Identify the problem first - correctly and comprehensively. And then solve it.

  • How to reduce physical reads - very interesting issue

    HI,
    Every week i generate a statspack report which will give me top20 buffer gets queries and top 20 physical reads query.When i start reducing physical reads by placing the heavy accessed table in buffer i will get the same query in top 20 higher buffer gets list in the next week.If i want to reduce buffer gets i have to remove the heavy accessed table from buffer which will cause higer physical reads.How can i solve this problem.I am trying to tune query as much as possible.
    Your help is appreciated..
    Thanks and Regards
    Anand

    I think that you are labouring under a misapprehension. Buffer gets and physical reads are basically the same thing. In order to satisfy your query, Oracle needsto read X number of blocks to find all of the data. Admittedly, it is generally faster to read those blocks from memory (buffer gets) than from disk (physical reads), but the blocks have to be read (this is called logical I/O). The only way to reduce I/O is to re-write the query to be more efficient. This may or may not be possible.
    As Kamal said, if the query is fast enough, then you are done. If it is too slow, then you need to look at ways of reducing I/O. It is unlikely that any database parameters will have a significant impact on the I/O. You need to look at the statisitics on the table and the actual sql statement.
    John

  • Logical and Physical Delete

    Hi Everyone,
    I am a newbie to Oracle.
    What is Logical Delete and What is Physical Delete ?
    Help is appreciated.
    Thanks in advance,
    KR

    Hi,
    I think you are asking about Logical read and physical read.
    Logical read - Data accessed from memory.
    Physical read - Data accessed directly from disk.
    Regards
    Jafar

  • Logical reads VS physical reads

    hello all,
    What is the difference between logical reads and physical read ??? I do get the part of logical read (from buffer) and physical read(from disk). And also do know physical reads are bad, but is it true in oracle world..logical reads are bad ??? if so why ??? Could you please explain which on to look for. As i am going thru AWR report and i see segemts by logical/physical read.

    The first and foremost difference is that physcial reads are done from the hard disk. And this is always going tobe slwoer than the memory. That's why its said that the physcial ios must be removed. Logical ios are good as they are done from the memory.The theory that logical are also not good is because the logical ios require the access given by latches. So with lots of the gets for the latches put them in to contention and latch contention would make the access to the logical io slower.So its better to do this in less IO even they are logical too.
    Lots of logical IOs probably mean that you are accessing unnecessary data which may be not required.
    HTH
    Aman....

  • Question on physical reads

    Is RMAN I/Os accounted in physical reads stat?
    I mean, do the blocks read from disk by RMAN to backup the database get accounted in physical reads statistic?
    One of our databases has a value for physical read total IO requests higher than physical reads so I guess the physical reads missing are RMAN's.
    Thanks in advance

    Statistics have not the same unit so you cannot compare them directly:
    >
    physical read total IO requests
    Number of read requests which read one or more database blocks for all instance activity including application, backup and recovery, and other utilities. The difference between this value and "physical read total multi block requests" gives the total number of single block read requests.
    >
    and
    >
    physical reads     
    Total number of data blocks read from disk. This value can be greater than the value of "physical reads direct" plus "physical reads cache" as reads into process private buffers also included in this statistic.
    >
    You should compare physical read total IO requests with:
    >
    physical read IO requests
    Number of read requests for application activity (mainly buffer cache and direct load operation) which read one or more database blocks per request. This is a subset of "physical read total IO requests" statistic.
    >
    Edited by: P. Forstmann on 9 avr. 2013 12:57

  • Understanding Physical Reads

    Hello everyone,
    I'm trying to understand about physical reads statistics.
    we have a few statistics related to this.
    They are physical reads, physical reads cache, physical reads cache prefetch, physical reads direct, physical reads direct (lob), physical reads direct temporary tablespace, and physical reads prefetch warmup.
    From all those statistics, I thought that physical reads should be like the total of the rest of the other statistics.
    However, when I looked at the actual AWR report I collected from a production database here, it seems physical reads value is only similar to the value of physical reads cache + physical reads direct.
    I wonder about the rest of the statistics related to this physical reads, I thought that physical reads statistics is like the grand total of all those physical reads, however that doesn't seems to be the case. How do I interpret these statistcs?
    Appreciate if you can explain how these statistics can be used when understanding a database performance.
    Thank you,
    Adhika

    Hello everyone,
    I'm trying to understand about physical reads statistics.
    we have a few statistics related to this.
    They are physical reads, physical reads cache, physical reads cache prefetch, physical reads direct, physical reads direct (lob), physical reads direct temporary tablespace, and physical reads prefetch warmup.
    From all those statistics, I thought that physical reads should be like the total of the rest of the other statistics.
    However, when I looked at the actual AWR report I collected from a production database here, it seems physical reads value is only similar to the value of physical reads cache + physical reads direct.
    I wonder about the rest of the statistics related to this physical reads, I thought that physical reads statistics is like the grand total of all those physical reads, however that doesn't seems to be the case. How do I interpret these statistcs?
    Appreciate if you can explain how these statistics can be used when understanding a database performance.
    Thank you,
    Adhika

  • Query tuning-how to reduce physical reads-help me

    1* select * from masterbillingInvoiceview Where SiteIID =300964 and InvoiceID like '%' order by Invoice asc
    SQL> /
    33 rows selected.
    Elapsed: 00:00:00.34
    Execution Plan
    Plan hash value: 352896138
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 16 | 6304 | 341 (3)| 00:00:05 |
    | 1 | SORT ORDER BY | | 16 | 6304 | 341 (3)| 00:00:05 |
    | 2 | TABLE ACCESS BY INDEX ROWID | ADDRESS | 1 | 48 | 2 (0)| 00:00:01
    | 3 | NESTED LOOPS | | 16 | 6304 | 340 (3)| 00:00:05 |
    | 4 | NESTED LOOPS | | 16 | 5536 | 316 (3)| 00:00:04 |
    |* 5 | HASH JOIN OUTER | | 16 | 5168 | 308 (3)| 00:00:04 |
    |* 6 | HASH JOIN | | 16 | 4992 | 302 (3)| 00:00:04 |
    |* 7 | HASH JOIN | | 16 | 4752 | 298 (3)| 00:00:04 |
    | 8 | NESTED LOOPS | | 17 | 4828 | 44 (0)| 00:00:01 |
    | 9 | NESTED LOOPS | | 17 | 3451 | 35 (0)| 00:00:01 |
    | 10 | NESTED LOOPS OUTER | | 1 | 91 | 2 (0)| 00:00:01 |
    | 11 | TABLE ACCESS BY INDEX ROWID| SITEMASTER | 1 | 74 | 1 (0)| 00:00:01 |
    |* 12 | INDEX UNIQUE SCAN | PK_SITEMASTER | 1 | | 1 (0)| 00:00:01 |
    | 13 | TABLE ACCESS BY INDEX ROWID| INVGROUPS | 1735 | 29495 | 1 (0)| 00:00:01 |
    |* 14 | INDEX UNIQUE SCAN | PK_INVGROUPS | 1 | | 1 (0)| 00:00:01 |
    |* 15 | TABLE ACCESS BY INDEX ROWID | INVOICEHEAD | 17 | 1904 | 33 (0)| 00:00:01 |
    |* 16 | INDEX RANGE SCAN | IDX_INVOICEHEADSITEIID | 271 | | 1 (0)| 00:00:01 |
    | 17 | TABLE ACCESS BY INDEX ROWID | CUSTOMER | 1 | 81 | 1 (0)| 00:00:01 |
    |* 18 | INDEX UNIQUE SCAN | PK_CUSTOMER | 1 | | 1 (0)| 00:00:01 |
    | 19 | VIEW | | 35844 | 455K| 254 (3)| 00:00:04 |
    | 20 | HASH GROUP BY | | 35844 | 455K| 254 (3)| 00:00:04 |
    | 21 | TABLE ACCESS FULL | CONTACT | 56100 | 712K| 250 (1)| 00:00:03 |
    | 22 | VIEW | index$_join$_009 | 7 | 105 | 3 (0)| 00:00:01 |
    |* 23 | HASH JOIN | | | | | |
    | 24 | INDEX FAST FULL SCAN | IDX_PAYMENTTERMSID | 7 | 105 | 1 (0)| 00:00:01
    | 25 | INDEX FAST FULL SCAN | PK_PAYMENTTERMS | 7 | 105 | 1 (0)| 00:00:01
    | 26 | VIEW | index$_join$_011 | 1428 | 15708 | 6 (0)| 00:00:01 |
    |* 27 | HASH JOIN | | | | | |
    | 28 | INDEX FAST FULL SCAN | PK_EMPLOYEE | 1428 | 15708 | 3 (0)| 00:00:01 |
    | 29 | INDEX FAST FULL SCAN | IDX_EMPLOYEEEMPLOYEEID | 1428 | 15708 | 3 (0)| 00:00:01
    | 30 | TABLE ACCESS BY INDEX ROWID | CONTACT | 1 | 23 | 1 (0)| 00:00:
    |* 31 | INDEX UNIQUE SCAN | PK_CONTACT | 1 | | 1 (0)| 00:00:01 |
    |* 32 | INDEX RANGE SCAN | PK_ADDRESS | 1 | | 1 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    5 - access("A"."CREATEDBY"="J"."EMPIID"(+))
    6 - access("A"."TERMSIID"="H"."PAYMENTTERMSIID")
    7 - access("D"."CUSTOMERIID"="F"."CUSTOMERIID")
    12 - access("B"."SITEIID"=300964)
    14 - access("B"."PARENTIID"="I"."GROUPIID"(+))
    15 - filter("A"."TYPE"=4 AND "A"."INVOICEID" LIKE '%')
    16 - access("A"."SITEIID"=300964)
    18 - access("A"."BILLINGCUSTOMERIID"="D"."CUSTOMERIID")
    23 - access(ROWID=ROWID)
    27 - access(ROWID=ROWID)
    31 - access("F"."CONTACTIID"="G"."CONTACTIID")
    32 - access("E"."ADDRESSIID"=NVL("D"."BILLINGADDRESSIID","D"."ADDRESSIID"))
    Statistics
    107 recursive calls
    0 db block gets
    2819 consistent gets
    0 physical reads
    0 redo size
    6586 bytes sent via SQL*Net to client
    356 bytes received via SQL*Net from client
    4 SQL*Net roundtrips to/from client
    1 sorts (memory)
    0 sorts (disk)
    33 rows processed
    SQL> ed
    Wrote file afiedt.buf
    1* select * from masterbillingInvoiceview Where SiteIID =300964 and InvoiceID like '%%%' order by Invoice asc
    SQL> /
    33 rows selected.
    Elapsed: 00:06:15.23
    Execution Plan
    Plan hash value: 1828716447
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 2 | 964 | 295 (3)| 00:00:04 |
    |* 1 | FILTER | | | | | |
    | 2 | SORT GROUP BY | | 2 | 964 | 295 (3)| 00:00:04 |
    | 3 | MERGE JOIN CARTESIAN | | 72315 | 33M| 291 (1)| 00:00:04 |
    | 4 | TABLE ACCESS BY INDEX ROWID | ADDRESS | 1 | 52 | 2 (0)| 00:00:01 |
    | 5 | NESTED LOOPS | | 1 | 447 | 41 (0)| 00:00:01 |
    | 6 | NESTED LOOPS | | 1 | 395 | 40 (0)| 00:00:01 |
    | 7 | NESTED LOOPS | | 1 | 382 | 38 (0)| 00:00:01 |
    | 8 | NESTED LOOPS OUTER | | 1 | 289 | 37 (0)| 00:00:01 |
    | 9 | NESTED LOOPS | | 1 | 266 | 36 (0)| 00:00:01 |
    | 10 | NESTED LOOPS | | 1 | 239 | 35 (0)| 00:00:01 |
    | 11 | NESTED LOOPS OUTER | | 1 | 115 | 2 (0)| 00:00:01 |
    | 12 | TABLE ACCESS BY INDEX ROWID| SITEMASTER | 1 | 86 | 1 (0)| 00:00:01 |
    |* 13 | INDEX UNIQUE SCAN | PK_SITEMASTER | 1 | | 1 (0)| 00:00:01 |
    | 14 | TABLE ACCESS BY INDEX ROWID| INVGROUPS | 1735 | 50315 | 1 (0)| 00:00:01 |
    |* 15 | INDEX UNIQUE SCAN | PK_INVGROUPS | 1 | | 1 (0)| 00:00:01 |
    |* 16 | TABLE ACCESS BY INDEX ROWID | INVOICEHEAD | 1 | 124 | 33 (0)| 00:00:01 |
    |* 17 | INDEX RANGE SCAN | IDX_INVOICEHEADSITEIID | 271 | | 1 (0)| 00:00:01 |
    | 18 | TABLE ACCESS BY INDEX ROWID | PAYMENTTERMS | 1 | 27 | 1 (0)| 00:00:01 |
    |* 19 | INDEX UNIQUE SCAN | PK_PAYMENTTERMS | 1 | | 1 (0)| 00:00:01 |
    | 20 | TABLE ACCESS BY INDEX ROWID | EMPLOYEE | 1 | 23 | 1 (0)| 00:00:01 |
    |* 21 | INDEX UNIQUE SCAN | PK_EMPLOYEE | 1 | | 1 (0)| 00:00:01 |
    | 22 | TABLE ACCESS BY INDEX ROWID | CUSTOMER | 1 | 93 | 1 (0)| 00:00:01 |
    |* 23 | INDEX UNIQUE SCAN | PK_CUSTOMER | 1 | | 1 (0)| 00:00:01 |
    | 24 | TABLE ACCESS BY INDEX ROWID | CONTACT | 1 | 13 | 2 (0)| 00:00:01 |
    |* 25 | INDEX RANGE SCAN | IDX_CONTACTCUSTOMERIID | 2 | | 1 (0)| 00:00:01 |
    |* 26 | INDEX RANGE SCAN | PK_ADDRESS | 1 | | 1 (0)| 00:00:01 |
    | 27 | BUFFER SORT | | 56100 | 1917K| 294 (3)| 00:00:04 |
    | 28 | TABLE ACCESS FULL | CONTACT | 56100 | 1917K| 250 (1)| 00:00:03 |
    Predicate Information (identified by operation id):
    1 - filter("G"."CONTACTIID"=MAX("CONTACTIID"))
    13 - access("B"."SITEIID"=300964)
    15 - access("B"."PARENTIID"="I"."GROUPIID"(+))
    16 - filter("A"."TYPE"=4 AND "A"."INVOICEID" LIKE '%%%')
    17 - access("A"."SITEIID"=300964)
    19 - access("A"."TERMSIID"="H"."PAYMENTTERMSIID")
    21 - access("A"."CREATEDBY"="J"."EMPIID"(+))
    23 - access("A"."BILLINGCUSTOMERIID"="D"."CUSTOMERIID")
    25 - access("D"."CUSTOMERIID"="CUSTOMERIID")
    filter("CUSTOMERIID" IS NOT NULL)
    26 - access("E"."ADDRESSIID"=NVL("D"."BILLINGADDRESSIID","D"."ADDRESSIID"))
    Statistics
    1952 recursive calls
    78 db block gets
    4649 consistent gets
    236151 physical reads
    0 redo size
    6586 bytes sent via SQL*Net to client
    356 bytes received via SQL*Net from client
    4 SQL*Net roundtrips to/from client
    1 sorts (memory)
    1 sorts (disk)
    33 rows processed
    this is the execution plan of my one query with a small difference, bt there is large diffference in physical reads..
    can anyone help me out of this
    thanks
    aju

    Hi,
    Can you please format your explain plan using
    { code } --without space
    Explain plan
    { code } -- without any space
    What is your DB version?
    There are differences in access and filter criteria...
    -- FRIST QUERY
    5 - access("A"."CREATEDBY"="J"."EMPIID"(+))
    6 - access("A"."TERMSIID"="H"."PAYMENTTERMSIID")
    7 - access("D"."CUSTOMERIID"="F"."CUSTOMERIID")
    12 - access("B"."SITEIID"=300964)
    14 - access("B"."PARENTIID"="I"."GROUPIID"(+))
    15 - filter("A"."TYPE"=4 AND "A"."INVOICEID" LIKE '%')
    16 - access("A"."SITEIID"=300964)
    18 - access("A"."BILLINGCUSTOMERIID"="D"."CUSTOMERIID")
    23 - access(ROWID=ROWID)
    27 - access(ROWID=ROWID)
    31 - access("F"."CONTACTIID"="G"."CONTACTIID")
    32 - access("E"."ADDRESSIID"=NVL("D"."BILLINGADDRESSIID","D"."ADDRESSIID"))
    ------SECOND QUERY
    1 - filter("G"."CONTACTIID"=MAX("CONTACTIID"))
    13 - access("B"."SITEIID"=300964)
    15 - access("B"."PARENTIID"="I"."GROUPIID"(+))
    16 - filter("A"."TYPE"=4 AND "A"."INVOICEID" LIKE '%%%')
    17 - access("A"."SITEIID"=300964)
    19 - access("A"."TERMSIID"="H"."PAYMENTTERMSIID")
    21 - access("A"."CREATEDBY"="J"."EMPIID"(+))
    23 - access("A"."BILLINGCUSTOMERIID"="D"."CUSTOMERIID")
    25 - access("D"."CUSTOMERIID"="CUSTOMERIID")
    filter("CUSTOMERIID" IS NOT NULL)
    26 - access("E"."ADDRESSIID"=NVL("D"."BILLINGADDRESSIID","D"."ADDRESSIID"))-Avinash

Maybe you are looking for

  • [SOLVED] Having Issues with the Nouveau Driver and ACPI

    Hello, Trying to set up an old laptop I have with Arch and I'm having issues getting X up and running. My graphics chip is: 01:00.0 VGA compatable controller: nVidia Corporation NV11 [GeForce2 Go] (rev b2) I've installed xf86-video-nouveau and get th

  • A note on Setup Manager - Application Change Management Pack

    Hi All, This is Mugunthan, Development manager for iSetup and Setup Manager. I am happy to begin my note with the launch of Application Change Management Pack 3.1. For those who are not aware of Application Change Management Pack, it is a new product

  • UTC Time Zone Impact to Sales & Distribution

    We've decided to set out time zone for UTC within the system, while the individual users will set their time zones accordingly.  However, we feel this may lead to some issues with the 6-7 hr time zone difference as most of the users are in Eastern Ti

  • Issue in Transport Request of ChaRM

    I have created a Transport Request made import'd to Q-Sys, Now i need to Make some changes I've set the status to IN-dev & made changes & saved ,also released the transport request, still no changes found, Plz suggest me a remedy?

  • CUSTOM.pll missing after applying patch 6167056

    HI ALL, i have applied patch 6167056 successfully, to carry on the post install step to Copy the CUSTOM.pll to $AU_TOP/resource and re-generate the CUSTOM.plx i cannot find the CUSTOM.pll at 6167056/backup/resource bash-3.00$ pwd /XXXX/XXXX/6167056/b