Why a parallel query use direct path read?

I think because the cache must Access pads, lock and lock on buffer block if parallel query do not reading of the direct path, parallel queries will be affected by the serialization as the latch and oracle .so lock mechanism choose direct path read to avoid what he.

that someone has a good idea?

Published by: Jeremiah on December 8, 2008 07:52

Jinyu wrote:
I think because the cache must Access pads, lock and lock on buffer block if parallel query do not reading of the direct path, parallel queries will be affected by the serialization as the latch and oracle .so lock mechanism choose direct path read to avoid what he.

Jinyu,

actually, Yes, I think that's it. The parallel query is designed to scan very much, because the load of communication between processes and maintenance/commissioning the parallel slave makes inefficient operation for small segments.

So I guess that the assumption is that the segment to analyze is probably very large, the fraction of the blocks in the buffer cache is very low compared to the blocks to scan and so the fresh reduction General read directly blocks without moving through all the questions of serialization of the buffer cache should prevail on the issue of blocks "unbuffered" and save the buffer for objects cache more benefit from development caching.

Kind regards
Randolf

Oracle related blog stuff:
http://Oracle-Randolf.blogspot.com/

SQLTools ++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676 /.
http://sourceforge.NET/projects/SQLT-pp/

Tags: Database

Similar Questions

  • Insert adds parallel sessions expect "direct path read temp".

    Hi all.

    The database is 11.2.0.3 on a linux machine.

    I published the following query, and I found that parallel query sessions were waiting for "direct path read temp.

    And SDPCSM. Table SDP_CHILD_SVC_PROFATTR_HIS does NOT index and is in nologging mode.

    Why the pq sessions expect "direct path read/write temp?
    insert /*+ append parallel (8) */ into SDPCSM.SDP_CHILD_SVC_PROFATTR_HIS
select /*+ parallel (SDP_CHILD_SVC_PROFATTR_HIS_E, 8) */ * from SDPCSM.SDP_CHILD_SVC_PROFATTR_HIS_E@tb_link;
    Thanks in advance.
    Best regards.

    Please check this blog:
    http://www.Confio.com/blog/Oracle-wait-event-explained-direct-path-read-temp

  • Is it reasonable to require a Full table Scan (Direct path read) on a large Table

    Hello

    I have an Oracle 11.2.0.3 on a Sun Solaris 10 sparc with SGA 25 GB machine

    One of my made SQL an analysis of indexes on the table to 45 GB where the size of the index is 14FR and the thourghput for the sequential read is 2MBPS.

    so now (Index) 14 000 Mo, 14 GB / 2 MB = dry 7000 = 2 hours to scan the index.

    Flow of the direct path read is 500 Mbps for an another SQL and reads assimilate them all live.

    and because of this flow, a read (FTS) of direct path on the table of 7 GB out in 12-13 seconds. So in my case, it probably takes 100 seconds to scan the entire table. It is a monthly report and does not often.

    Should I try to use a trick to force sql to do a full scan and exploit the possibilities of direct reading and is done in a few minutes? Assuming it to do a FTS (direct play)

    Of course, it will be tested and verified, but the question is, is this a sensible apprioach? is - anyone has experience by forcing it?

    Any suggestions would be helpful... I'll test this on a different machine tomorrow.

    Best regards

    Maran

    82million lines and a grouping of 18million factor?  And really 17million from lines to recover?  However, your result set after the hash join is 3500 lines, although the optimizer expects 16 lines.

    I would say that the statistics are not representative or not in use for this SQL.  Certainly, the index does not match query predicates.

    The fact that the index is also using the virtual columns only adds to confusion.

    Hemant K Collette

  • Direct path read event

    Hi all

    We use 10.2.0.3 on sparc solaris 10 64 bit OS.

    I wondered about two events in my environment that will take a long time. Yes, we do a lot of grouping, sorting and hash joins that temp on spill data.

    For the most part, all time will "lead the read temp path. I took route and seen it's just 1 block reading all time (p3) vs other reads like scattered or direct path write 32 blocks read/write.
      direct path read temp                      241389        4.19       2511.08
  direct path write                               2        0.00          0.00
    So, is there a reason why the direct path read temp to read than a single block at the time? Can we define something that can read multiple blocks in an extraction

    Nico wrote:
    Thank you Greg for more information.

    Have you found any workaround to 10.2.0.3

    It is not a work around. The changes in the fixed a bug how temp blocks are read for positional kinds. It should all but remove the one-piece temp readings. Much more effective with this fix. I saw about 2 x increase in performance in many cases actual test using this hotfix.

    You can try and see if Oracle Support will backport of 10.2.0.3, but I recommend you do 10.2.0.4 anyway due to the considerable number of bug fixes. It won't take long and 10.2.0.5 comes out as well.

    --
    Kind regards
    Greg Rahn
    http://structureddata.org

  • With regard to 'Direct Path read' expected

    As we know, the direct path read waits is a new feature of Oracle 11 g. Oracle Documents or other objects, when it's the full table scan, direct path reading took place. But why it happened?  I don't know clearly.

    Here is the description of the Oracle Document:

    http://docs.Oracle.com/CD/E18283_01/server.112/e17110/waitevents003.htm#sthref3849

    During operations of Direct Reading of data asynchronously access path in the database files. At some point, the session must ensure that all the asynchronous i/o in circulation have been realized on the drive. This can also happen if during a direct reading without more slots is available for storing exceptional load requests (a charge application might consist of several e/s).


    Question:

    1 during operations of Direct data asynchronously reading path in database files.  > > this statement means what? What of "asynchronous reading '?

    2 describe above description for me in details.

    3. who can clearly explain "why read direct path wait to happen ' for me?


    Thanks in advance.

    Lonion


    Lonion wrote:

    Question:

    1. to path operations Direct playback of data asynchronously in the database files.  > This statement means what? What of "asynchronous reading '?

    2 describe above description for me in details.

    3. who can clearly explain "why read direct path wait to happen ' for me?

    If you want to get very technical, Frits Hoogland wrote a lot about the implementation:

    http://fritshoogland.WordPress.com/2013/05/09/direct-path-read-and-fast-full-index-scans/

    http://fritshoogland.WordPress.com/2013/01/04/Oracle-11-2-and-the-direct-path-read-event/

    http://fritshoogland.WordPress.com/2012/12/27/Oracle-11-2-0-1-and-the-KFK-async-disk-IO-wait-event/

    http://www.UKOUG.org/what-we-offer/library/about-Multiblock-reads/about-Multiblock-reads.PDF

    Concerning

    Jonathan Lewis

  • Wait events "direct path write" and "direct path read".

    Hello

    We have a query that takes more than 2 minutes. It's a 9.2.0.7 database. We took the request trace/tkprof and identified there so manay 'direct entry path' and 'direct path read' wait for events in the trace file.

    WAITING #3: nam = "Write" direct path ela = 5 201 p1 = p2 = p3 70710 = 15
    WAITING #3: nam = "direct path read" ela = 170 201 p1 = p2 = 71719 p3 = 15

    In the light of the foregoing, "p1 = 201" is a the file_id, but we could not find any data file, the temporary file, the control file with this id # 201.
    Can you please let us know what "p1 = 201" here, how to identify the file that is causing the problem.

    Thank you
    Sravan

    Whatever it is:

    show parameter db_files

    back? I think, is that it returns 200.

    Read the file live and direct file writing events are reads and writes of tablespace TEMP. Wait events, folder # is reported as db_files + id of a temporary file. So, 201 means temp #1 file.

    Now, as to your real performance issue.

    Without seeing the SQL and the corresponding implementation plan, it is impossible to be sure. However, the most frequent causes of temporary entries are the operations of sorting and group by operations.

    If you decide to display your plan and SQL execution, please be sure to make it readable by formatting it. Information on how to do this can be found here.

    Hope that helps,

    -Mark

    Published by: mbobak on May 1st, 2011 01:50

  • SPARQL query using varying paths

    Hello

    I have a chart in Oracle I like to do query using Jena 2.6.4 and OracleJenaAdaptor 11.2.0.3

    IND:123: ind:124 hasA
    IND:124: ind:125 Hilmi
    IND:125: hasC ind:126
    IND:123: coward ind:127

    Is there a way to build a sparql query to return all the ind: without 'hard-conding"the full property name? Something in these lines (note that this query doesn't really work).

    Select *.
    where {ind:123 (: has *) +? x}

    Thank you.

    Hello

    If you have created a virtual model before, then will do the following. Note that I am assuming that the virtual model is created based on two 'my_asset', 'my_model' models and modules OWLPRIME.

    Piece attached attachment = Attachment.createInstance (new String() {"my_model"},
    (New String() {"OWLPRIME"}, InferenceMaintenanceMode.UPDATE_WHEN_COMMIT, QueryOptions.ALLOW_QUERY_INVALID_AND_DUP).

    Chart GraphOracleSem = new GraphOracleSem (oracle, "my_asset", room attached, true);
    graph.performInference ();

    Thank you

    Zhe

  • DB file sequential read and read of the direct path

    Hello

    Could someone please clear my doubts about 'db file sequential read' and ' path direct reading. And help me understand the tkprof report correctly.
    Please suggest if my understanding for scenario below is correct.

    We have a 11.2.0.1 ' cluster 2 node rac version + asm' production and environment of his test environment that is a stand-alone database.
    The query performs well in production compared to the test database.
    The table is to have 254 + columns (264) with many lobs coulumns however LOB is not currently selected in the query.
    I read in metalink this 254 table + column a intra-line-chaining, causing "db file sequential read" full table Scan.

    Here are some details on the table which is similar to the prod and test, block size is 8 k:
    TABLE                             UNUSED BLOCKS     TOTAL BLOCKS  HIGH WATER MARK
------------------------------  ---------------  ---------------  ---------------
PROBSUMMARYM1                               0          17408          17407
    What I understand less tkprof in production environment for a given session is:
    1 - the request resulted in disk 19378 readings and 145164 consistent readings.
    2 19378 disc bed, 2425 reads disc has given rise to the wait event 'db file sequential read'.
    This statement is correct this disc remaining readings were "db file sequential reads" but real quick so didn't wait event tied to it?
    3 - 183 'direct path read' there also. Is it because of the order by clause of the query?

    SQL ID: 72tvt5h4402c9
Plan Hash: 1127048874
select "NUMBER" num 
from
 smprd.probsummarym1 where flag ='f' and affected_item = 'PAUSRWVP39486' 
  order by num asc


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      0.53       4.88      19378     145164          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3      0.53       4.88      19378     145164          0           0

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: SYS

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  SORT ORDER BY (cr=145164 pr=19378 pw=0 time=0 us cost=4411 size=24 card=2)
      0   TABLE ACCESS FULL PROBSUMMARYM1 (cr=145164 pr=19378 pw=0 time=0 us cost=4410 size=24 card=2)


Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                       1        0.00          0.00
  ges message buffer allocation                   3        0.00          0.00
  enq: KO - fast object checkpoint                2        0.00          0.00
  reliable message                                1        0.00          0.00
  KJC: Wait for msg sends to complete             1        0.00          0.00
  Disk file operations I/O                        1        0.00          0.00
  kfk: async disk IO                            274        0.00          0.00
  direct path read                              183        0.01          0.72
  db file sequential read                      2425        0.05          3.71
  SQL*Net message from client                     1        2.45          2.45
    The same query when ran in no no rac - asm test stand alone database has given below tkprof.
    Does this mean that:
    1-here too, reads happen through "db file sequential read", but they were so fast that has failed to the wait event?
    2. "direct path read," it's because of the order clause in the query. "
    SQL ID: 72tvt5h4402c9
Plan Hash: 1127048874
select "NUMBER" num 
from
 smprd.probsummarym1 where flag ='f' and affected_item = 'PAUSRWVP39486' 
  order by num asc


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.06          0          0          0           0
Fetch        1      0.10       0.11      17154      17298          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3      0.10       0.18      17154      17298          0           0

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: SYS

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  SORT ORDER BY (cr=17298 pr=17154 pw=0 time=0 us cost=4694 size=12 card=1)
      0   TABLE ACCESS FULL PROBSUMMARYM1 (cr=17298 pr=17154 pw=0 time=0 us cost=4693 size=12 card=1)


Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                       1        0.00          0.00
  Disk file operations I/O                        1        0.00          0.00
  db file sequential read                         3        0.00          0.00
  direct path read                              149        0.00          0.03
  SQL*Net message from client                     1        2.29          2.29
    For trace files in the database Production and Test, I see that 'direct path read' is against the same data file that's stored table.
    Then how come 'this direct path read' because of the order by clause of the query and would have been in sort field size or pga?
    Or this direct path read extracts real PGA disk data, and "db file sequential read" do not extract data?
    I know, it's 'direct path read' is wait event when data are asked in PGA drive or what kind segment or temp tablespace is used.

    Here is the example of trace file in the Production database:
    *** 2013-01-04 13:49:15.109
WAIT #1: nam='SQL*Net message from client' ela= 11258483 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1357278555109496
CLOSE #1:c=0,e=9,dep=0,type=1,tim=1357278555109622
=====================
PARSING IN CURSOR #1 len=113 dep=0 uid=0 oct=3 lid=0 tim=1357278555109766 hv=138414473 ad='cfc02ab8' sqlid='72tvt5h4402c9'
select "NUMBER" num from smprd.probsummarym1 where flag ='f' and affected_item = 'PAUSRWVP39486' order by num asc
END OF STMT
PARSE #1:c=0,e=98,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=1127048874,tim=1357278555109765
EXEC #1:c=0,e=135,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=1127048874,tim=1357278555109994
WAIT #1: nam='SQL*Net message to client' ela= 2 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1357278555110053
WAIT #1: nam='ges message buffer allocation' ela= 3 pool=0 request=1 allocated=0 obj#=-1 tim=1357278555111630
WAIT #1: nam='enq: KO - fast object checkpoint' ela= 370 name|mode=1263468550 2=65610 0=1 obj#=-1 tim=1357278555112098
WAIT #1: nam='reliable message' ela= 1509 channel context=3691837552 channel handle=3724365720 broadcast message=3692890960 obj#=-1 tim=1357278555113975
WAIT #1: nam='ges message buffer allocation' ela= 2 pool=0 request=1 allocated=0 obj#=-1 tim=1357278555114051
WAIT #1: nam='enq: KO - fast object checkpoint' ela= 364 name|mode=1263468550 2=65610 0=1 obj#=-1 tim=1357278555114464
WAIT #1: nam='KJC: Wait for msg sends to complete' ela= 9 msg=3686348728 dest|rcvr=65536 mtype=8 obj#=-1 tim=1357278555114516
WAIT #1: nam='ges message buffer allocation' ela= 2 pool=0 request=1 allocated=0 obj#=-1 tim=1357278555114680
WAIT #1: nam='Disk file operations I/O' ela= 562 FileOperation=2 fileno=6 filetype=2 obj#=85520 tim=1357278555115710
WAIT #1: nam='kfk: async disk IO' ela= 5 count=1 intr=0 timeout=4294967295 obj#=85520 tim=1357278555117332

*** 2013-01-04 13:49:15.123
WAIT #1: nam='direct path read' ela= 6243 file number=6 first dba=11051 block cnt=5 obj#=85520 tim=1357278555123628
WAIT #1: nam='db file sequential read' ela= 195 file#=6 block#=156863 blocks=1 obj#=85520 tim=1357278555123968
WAIT #1: nam='db file sequential read' ela= 149 file#=6 block#=156804 blocks=1 obj#=85520 tim=1357278555124216
WAIT #1: nam='db file sequential read' ela= 155 file#=6 block#=156816 blocks=1 obj#=85520 tim=1357278555124430
WAIT #1: nam='db file sequential read' ela= 4826 file#=6 block#=156816 blocks=1 obj#=85520 tim=1357278555129317
WAIT #1: nam='db file sequential read' ela= 987 file#=6 block#=156888 blocks=1 obj#=85520 tim=1357278555130427
WAIT #1: nam='db file sequential read' ela= 3891 file#=6 block#=156888 blocks=1 obj#=85520 tim=1357278555134394
WAIT #1: nam='db file sequential read' ela= 155 file#=6 block#=156912 blocks=1 obj#=85520 tim=1357278555134645
WAIT #1: nam='db file sequential read' ela= 145 file#=6 block#=156920 blocks=1 obj#=85520 tim=1357278555134866
WAIT #1: nam='db file sequential read' ela= 234 file#=6 block#=156898 blocks=1 obj#=85520 tim=1357278555135332
WAIT #1: nam='db file sequential read' ela= 204 file#=6 block#=156907 blocks=1 obj#=85520 tim=1357278555135666
WAIT #1: nam='kfk: async disk IO' ela= 4 count=1 intr=0 timeout=4294967295 obj#=85520 tim=1357278555135850
WAIT #1: nam='direct path read' ela= 6894 file number=6 first dba=72073 block cnt=15 obj#=85520 tim=1357278555142774
WAIT #1: nam='db file sequential read' ela= 4642 file#=6 block#=156840 blocks=1 obj#=85520 tim=1357278555147574
WAIT #1: nam='db file sequential read' ela= 162 file#=6 block#=156853 blocks=1 obj#=85520 tim=1357278555147859
WAIT #1: nam='db file sequential read' ela= 6469 file#=6 block#=156806 blocks=1 obj#=85520 tim=1357278555154407
WAIT #1: nam='db file sequential read' ela= 182 file#=6 block#=156826 blocks=1 obj#=85520 tim=1357278555154660
WAIT #1: nam='db file sequential read' ela= 147 file#=6 block#=156830 blocks=1 obj#=85520 tim=1357278555154873
WAIT #1: nam='db file sequential read' ela= 145 file#=6 block#=156878 blocks=1 obj#=85520 tim=135727855515
    Here are the trace file for the test database:
    *** 2013-01-04 13:46:11.354
WAIT #1: nam='SQL*Net message from client' ela= 10384792 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1357278371354075
CLOSE #1:c=0,e=3,dep=0,type=3,tim=1357278371354152
=====================
PARSING IN CURSOR #1 len=113 dep=0 uid=0 oct=3 lid=0 tim=1357278371363427 hv=138414473 ad='c7bd8d00' sqlid='72tvt5h4402c9'
select "NUMBER" num from smprd.probsummarym1 where flag ='f' and affected_item = 'PAUSRWVP39486' order by num asc
END OF STMT
PARSE #1:c=0,e=9251,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=1127048874,tim=1357278371363426
EXEC #1:c=0,e=63178,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=1127048874,tim=1357278371426691
WAIT #1: nam='SQL*Net message to client' ela= 2 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1357278371426766
WAIT #1: nam='Disk file operations I/O' ela= 1133 FileOperation=2 fileno=55 filetype=2 obj#=93574 tim=1357278371428069
WAIT #1: nam='db file sequential read' ela= 51 file#=55 block#=460234 blocks=1 obj#=93574 tim=1357278371428158
WAIT #1: nam='direct path read' ela= 31 file number=55 first dba=460235 block cnt=5 obj#=93574 tim=1357278371428956
WAIT #1: nam='direct path read' ela= 47 file number=55 first dba=136288 block cnt=8 obj#=93574 tim=1357278371429099
WAIT #1: nam='direct path read' ela= 80 file number=55 first dba=136297 block cnt=15 obj#=93574 tim=1357278371438529
WAIT #1: nam='direct path read' ela= 62 file number=55 first dba=136849 block cnt=15 obj#=93574 tim=1357278371438653
WAIT #1: nam='direct path read' ela= 17 file number=55 first dba=136881 block cnt=7 obj#=93574 tim=1357278371438750
WAIT #1: nam='direct path read' ela= 35 file number=55 first dba=136896 block cnt=8 obj#=93574 tim=1357278371438855
WAIT #1: nam='direct path read' ela= 22 file number=55 first dba=136913 block cnt=7 obj#=93574 tim=1357278371438936
WAIT #1: nam='direct path read' ela= 19 file number=55 first dba=137120 block cnt=8 obj#=93574 tim=1357278371439029
WAIT #1: nam='direct path read' ela= 36 file number=55 first dba=137145 block cnt=7 obj#=93574 tim=1357278371439114
WAIT #1: nam='direct path read' ela= 18 file number=55 first dba=137192 block cnt=8 obj#=93574 tim=1357278371439193
WAIT #1: nam='direct path read' ela= 16 file number=55 first dba=137201 block cnt=7 obj#=93574 tim=1357278371439252
WAIT #1: nam='direct path read' ela= 17 file number=55 first dba=137600 block cnt=8 obj#=93574 tim=1357278371439313
WAIT #1: nam='direct path read' ela= 15 file number=55 first dba=137625 block cnt=7 obj#=93574 tim=1357278371439369
WAIT #1: nam='direct path read' ela= 22 file number=55 first dba=137640 block cnt=8 obj#=93574 tim=1357278371439435
WAIT #1: nam='direct path read' ela= 702 file number=55 first dba=801026 block cnt=126 obj#=93574 tim=1357278371440188
WAIT #1: nam='direct path read' ela= 1511 file number=55 first dba=801154 block cnt=126 obj#=93574 tim=1357278371441763
WAIT #1: nam='direct path read' ela= 263 file number=55 first dba=801282 block cnt=126 obj#=93574 tim=1357278371442547
WAIT #1: nam='direct path read' ela= 259 file number=55 first dba=801410 block cnt=126 obj#=93574 tim=1357278371443315
WAIT #1: nam='direct path read' ela= 294 file number=55 first dba=801538 block cnt=126 obj#=93574 tim=1357278371444099
WAIT #1: nam='direct path read' ela= 247 file number=55 first dba=801666 block cnt=126 obj#=93574 tim=1357278371444843
WAIT #1: nam='direct path read' ela= 266 file number=55 first dba=801794 block cnt=126 obj#=93574 tim=1357278371445619
    Thanks & Rgds,
    Vijay

    911786 wrote:

    Direct path readings can be done on the series tablescans in your version of Oracle, but if you have chained rows in the table and then Oracle can read read read the beginning of the line in the path directly, but must make a single block in the cache (the db file sequential read) to get the next part of the line.

    It is possible that your production system has a lot of chained rows, while your test system is not. As corroboration (though not convincing) indicator of what you might notice that if you take (reads disc - db file sequential reads) - who might get you close to all the blocks direct read - the numbers are very similar.

    I'm not 100% convinced that it's the answer for the difference in behavior, but worth a visit. If you can force and indexed access path in the table, do something like "select / * + index (use {pk}) * / max table (last_column_in_table)" and check the number of "table fetch continued lines" could be close to the number of db file sequential reads you. (There are other options for the counting of the chained rows that could be faster).

    Concerning
    Jonathan Lewis

  • Direct path SQLLDR allows duplicates in the primary key

    I would use sqlldr path direct to charge millions of records in the table but direct way allows duplicates on the primary key constraints.

    inserts of duplicates
    sqlldr control deploy_ctl/deploy_ctl@dba01mdm = direct ctl_test.ctl = true
    primary key is enabled

    I do not understand the behavior that's why the primary key is always enabled--(logiquement il doit avoir désactivé que doublons insérés)

    Inserts no duplicates
    sqlldr control = ctl_test.ctl deploy_ctl/deploy_ctl@dba01mdm
    primary key is enabled

    Please can I know if there is any work around to use direct path with constraints of primary school in place.

    The only solution is to not use direct load, if your dataset contains records in duplicate, of the documentation:

    /*
    A record that violates a UNIQUE constraint is not rejected (the file is not available in the memory when the constraint violation is detected).
    */

  • Insert / * + Append * / and direct-path INSERT

    Hi guys

    Insert / * + Append * / hint cause Oracle 10 G using direct-path INSERT?
    and so insert / * + Append * / suspicion causes an Oracle of using direct-path INSERT, insert / * + Append * / is subject to the same restrictions as direct-path, such as "the target table cannot have any triggers or referential integrity constraints defined on it.»



    Thank you

    How it would be difficult for you to look for the answer in the documentation and do not abuse this forum asking questions doc and flaming posters colleagues?

    ------------
    Sybrand Bakker
    Senior Oracle DBA

  • The DIRECT path load... Please advice!

    I want to load the table called staging.

    There are approximately 72 million data should be loaded. And the table has a UNIQUE index

    (reg_no, rel_no, hip_member_id, ind), the control file that I use in my script is less than

    Control file:

    options (silent=feedback, errors=999999)
load data
append
into table STAGING
WHEN status!='30' AND status!='31' AND status!='32' AND status!='33' AND status!='34' AND status!='40' AND status!='41' AND status!='42' AND status!='43'

(        
reg_no              position (01:13)      char,          
rel_no               position (290:298)    char "decode(ascii(:rel_no), 0,NULL,OPS_ARW.ALTID_CERT_CONVERSION(:rel_no,'A'))",              
HIP_MEMBER_ID              position (14:24)      char,              
PLAN_TYPE           position (25:42)      char,              
START_DATE            position (43:50)      char,              
status          position (51:54)      char,             
status_DATE       position (55:62)      char,                   
TAX_ID                 position (63:71)      char,                  
CHECK_NO               position (72:83)      char  "decode(:check_no,'99999999','00000000',nvl(:check_no,'00000000'))",              
CHECK_DATE             position (84:91)      char  "nvl(:check_date,'00000000')",               
AMT_PAID               position (92:104)     DECIMAL EXTERNAL,                  
AMT_BILLED             position (105:117)    DECIMAL EXTERNAL,                
DATE_SETTLED           position (118:125)    char "nvl(:date_settled,'00000000')",                  
PAYEE                  position (126:126)    char,                  
PREVIOUS_reg_no       position (127:139)    char,                            
PAY_TO_ID               position (149:163)    char,                 
ACCOUNT_NO              position (164:183)    char,              
PAYEE_ADDRESS           position (184:283)    char,             
DIAGNOSIS_CODE           position (284:289)    char,
pst_id          position (290:303)    char,
ALT_ID               position (290:298)    char,
MEM_LASTNAME          position (304:318)    char,
MEM_FIRSTNAME          position (319:333)    char,
MEM_DOB               position (334:341)    char,
ind           constant 'E'          
)
    My question is can I use load path DIRECT to this charge? SE direct path load works with a table with a unique index?
    If I use DIRCT how can I fit it into the script

    Thank you

    Hena

    Can I use direct path load if the table has a unique index on it?

    Yes, you can:

    SQL> create table t (a int)
/
Table created.

SQL> create unique index t_idx on t(a) compute statistics
/
Index created.

SQL> explain plan for insert /*+ append */ into t select empno from emp
/
Explain complete.

SQL> select * from table(dbms_xplan.display)
/
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------------------------------------
Plan hash value: 2133360128                                                                                                  

---------------------------------------------------------------------------
| Id  | Operation        | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | INSERT STATEMENT |        |    14 |    56 |     1   (0)| 00:00:01 |
|   1 |  LOAD AS SELECT  | T      |       |       |            |          |
|   2 |   INDEX FULL SCAN| PK_EMP |    14 |    56 |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------                                                  

9 rows selected.

    Note the LOAD AS SELECT step, which indicates a path direct insert.

  • Why doesn't a parallel query in parallel?

    Hello

    I hope someone can help me.

    I tested (several times and different ways) to see if the parallel server will work and help on my queries.

    My version is 11.2 on Solaris 10.

    I have a table with more 100,000 records and set autotrace and calendar on for testing purposes.

    I confirmed PARALLEL_MIN_SERVERS = 30 and PARALLEL_MAX_SERVERS = 160 and PARRALLEL_SERVERS_PER_CPU = 2.
    (my server has 4 CPU)

    I tested the full table running scan (select * from table) and time taken about 13:30 minutes.

    Then, I changed the table and set 4 Parallels.
    Run the test again and he ran more slowly (about 16 minutes).

    Then I ran select / * + parallel (manual) * / and it was always about 14 minutes.

    Then I ran select / * + parallel 4 * / and it took about 14:30 minutes.

    Then I reset the degree of parallel to the table to 1.
    Then, ran select / * + parallel 4 * / and it took a little less than 13:30 minutes.

    So, it seems that it does not use any parallel query. Why not?
    SQL> sho parameter cpu

NAME                                 TYPE                             VALUE
------------------------------------ -------------------------------- ---------
cpu_count                            integer                          4
parallel_threads_per_cpu             integer                          2
resource_manager_cpu_allocation      integer                          4

SQL> sho parameter parallel

NAME                                 TYPE                             VALUE
------------------------------------ -------------------------------- ---------
fast_start_parallel_rollback         string                           LOW
parallel_adaptive_multi_user         boolean                          TRUE
parallel_automatic_tuning            boolean                          FALSE
parallel_degree_limit                string                           CPU
parallel_degree_policy               string                           MANUAL
parallel_execution_message_size      integer                          16384
parallel_force_local                 boolean                          FALSE
parallel_instance_group              string
parallel_io_cap_enabled              boolean                          FALSE
parallel_max_servers                 integer                          160
parallel_min_percent                 integer                          0
parallel_min_servers                 integer                          30
parallel_min_time_threshold          string                           AUTO
parallel_server                      boolean                          FALSE
parallel_server_instances            integer                          1
parallel_servers_target              integer                          64
parallel_threads_per_cpu             integer                          2
recovery_parallelism                 integer                          0

SQL> sho parameter servers

NAME                                 TYPE                             VALUE
------------------------------------ -------------------------------- ---------
max_shared_servers                   integer
parallel_max_servers                 integer                          160
parallel_min_servers                 integer                          30
parallel_servers_target              integer                          64
shared_servers                       integer                          1

    PX COORDINATOR stage is something that you will see that when the plan uses parallel queries that are steps PX SEND QC (RANDOM) and PX BLOCK ITERATOR. You will also see that data in the column of PQ Distrib if parallel query is used. And the reference to the column of the IN-OUT backwards-> operations S indicates a transition between the parallel operations to the series (i.e. several parallel slaves, aggregated by one master series).

    Justin

  • query error - 410 in reading R & S fsp30 Analyzer using agilent usb-gpib?

    Dear users of or,.

    I'm new to Labview. I use labview 8.6.1 to retrieve data from the fsp30 Analyzer R & S helps Agilent gpib 82357 B usb. When I use the trace reading VI provided by R & S, I had problem of query - 410 error code and only get a table of 3 data elements. Could help me solve the problem take I can true data table?

    Thanks in advance!

    Jstin

    It is a specific error of the instrument and should be explained in the manual.

    If you need additional assistance, provide an explanation of the error and the code you are running. Someone with experience with the instrument may be able to see something.

  • Please help with parallel query

    Hi all

    I am "playing" with a parallel query and try to see if it could improve some more long running queries, but can't do the database that you want to use a parallel execution plan, no matter what I do! I hope someone can point me in the right direction!

    ORACLE Version is 11.2.0.2
    OS Win 2008 R2 server
    UC = 32
    64 GB OF RAM
    AMM enabled, memory_target = M 50560
    SQL > show the parallel parameter

    VALUE OF TYPE NAME
    ------------------------------------ ----------- --------------
    fast_start_parallel_rollback string LOW
    parallel_adaptive_multi_user Boolean TRUE
    parallel_automatic_tuning boolean FALSE
    parallel_degree_limit string CPU
    parallel_degree_policy string AUTO
    parallel_execution_message_size integer 16384
    parallel_force_local boolean FALSE
    parallel_instance_group string
    parallel_io_cap_enabled boolean FALSE
    PARALLEL_MAX_SERVERS integer 985
    parallel_min_percent integer 0

    VALUE OF TYPE NAME
    ------------------------------------ ----------- --------------
    parallel_min_servers integer 16
    parallel_min_time_threshold channel 5
    parallel_server boolean FALSE
    parallel_server_instances integer 1
    parallel_servers_target integer 512
    parallel_threads_per_cpu integer 2
    recovery_parallelism integer 0
    I also ran the calibration of IO which resultet
    Max e/s per second 21569
    Max Mo / second 989
    I collected statistics of the system, the 1 hour time. the results are:
    Select pname, sys.aux_stats pval1 $;
    STATUS
    DSTART
    DSTOP
    FLAGS 0
    CPUSPEEDNW 915
    IOSEEKTIM 10
    IOTFRSPEED 4096
    SREADTIM 0.589
    MREADTIM 0.841
    CPUSPEED 1355
    MBRC 11
    MAXTHR 679936
    SLAVETHR
    I changed all my tables and indexes using 'ALTER TABLE xxx PARALLEL' then when I query the dba_tables, the DEGREE is DEFAULT for all objects invoked in my queries.

    what I've learned so far, I put all the necessary parameters.
    From my understanding, all queries who believe more than 5 seconds, should be tried to run in parallel (parallel_min_time_threshold = 5). But not a single query is doing at least this forced manually with a / * + PARALLEL * / tip! It drives me crazy. Choose manually a degree of 16 for example allows to speed up some queries from 15 minutes to 1 minute, but why ORACLE does not by itself?
    Given that it is a Siebel application, that we are talking about, there is no possibility of adding tips for SQL.

    example:

    This query took 29 seconds to complete, but was executed in SERIES
    SQL_ID, atzj0dmhshb23, number of children 0
    -------------------------------------
    SELECT T7. CONFLICT_ID, T7. LAST_UPD, T7. CREATED,
    T7. LAST_UPD_BY, T7. CREATED_BY, T7. MODIFICATION_NUM,
    T7. ROW_ID, T9. MAIN_PH_NUM, T9.NAME, T9. REGION,
    T9. X_SUB_REGION, T20. ATTRIB_44, T20. ATTRIB_26,
    T20. ATTRIB_45, T20. ATTRIB_27, T20. ATTRIB_03,
    T33. SUPPRESS_MAIL_FLG, T33. EMAIL_ADDR, T33. MID_NAME,
    T33. PR_DEPT_OU_ID, T33. LAST_NAME, T33. SEX_MF,
    T33. PR_PER_ADDR_ID, T33. PR_POSTN_ID, T30. PR_ADDR_ID,
    T33. HOME_PH_NUM, T33. OWNER_PER_ID, T33. WORK_PH_NUM,
    T33. FAX_PH_NUM, T33. FST_NAME, T20. ATTRIB_07,
    T3. INTEGRATION_ID, T33. PR_PER_PAY_PRFL_ID, T33. PRIV_FLG,
    T33. PR_MKT_SEG_ID, T33. PR_REP_SYS_FLG,
    T33. PR_REP_MANL_FLG, T33. PR_REP_DNRM_FLG, T33. PR_OPTY_ID,
    T33. PR_GRP_OU_ID, T33. EMP_FLG, T8. OWN_INST_ID,
    T8. INTEGRATION_ID, T33. PERSON_UID, T7. NAM

    Hash value of plan: 35208051

    ---------------------------------------------------------------------------------------------------------------------------------
    | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
    ---------------------------------------------------------------------------------------------------------------------------------
    | 0 | SELECT STATEMENT | 34 (100) |
    | 1. NESTED EXTERNAL LOOPS | 10. 42440 | 34 (0) | 00:00:01 |
    | 2. NESTED EXTERNAL LOOPS | 10. 42300 | 33 (0) | 00:00:01 |
    | 3. NESTED EXTERNAL LOOPS | 10. 42160 | 32 (0) | 00:00:01 |
    | 4. NESTED EXTERNAL LOOPS | 10. 42020 | 31 (0) | 00:00:01 |
    | 5. NESTED LOOPS | 10. 41880 | 30 (0) | 00:00:01 |
    | 6. NESTED EXTERNAL LOOPS | 11. 45947 | 29 (0) | 00:00:01 |

    | 7. NESTED LOOPS | 11. 45716 | 28 (0) | 00:00:01 |
    | 8. NESTED EXTERNAL LOOPS | 11. 45364 | 27 (0) | 00:00:01 |
    | 9. NESTED EXTERNAL LOOPS | 11. 45243 | 26 (0) | 00:00:01 |
    | 10. NESTED EXTERNAL LOOPS | 11. 45122 | 25 (0) | 00:00:01 |
    | 11. NESTED EXTERNAL LOOPS | 11. 43648 | 24 (0) | 00:00:01 |
    | 12. NESTED EXTERNAL LOOPS | 11. 37070 | 23 (0) | 00:00:01 |
    | 13. NESTED EXTERNAL LOOPS | 11. 34661 | 22 (0) | 00:00:01 |
    | 14. NESTED EXTERNAL LOOPS | 11. 34430 | 21 (0) | 00:00:01 |
    | 15. NESTED EXTERNAL LOOPS | 11. 33891 | 20 (0) | 00:00:01 |
    | 16. NESTED EXTERNAL LOOPS | 11. 33253 | 19 (0) | 00:00:01 |
    | 17. NESTED EXTERNAL LOOPS | 11. 32362 | 18 (0) | 00:00:01 |
    | 18. NESTED EXTERNAL LOOPS | 11. 31999 | 17 (0) | 00:00:01 |
    | 19. NESTED EXTERNAL LOOPS | 11. 29337 | 16 (0) | 00:00:01 |
    | 20. NESTED EXTERNAL LOOPS | 11. 28556 | 15 (0) | 00:00:01 |
    | 21. NESTED EXTERNAL LOOPS | 11. 28061 | 14 (0) | 00:00:01 |
    | 22. NESTED EXTERNAL LOOPS | 11. 26400 | 13 (0) | 00:00:01 |
    | 23. NESTED EXTERNAL LOOPS | 11. 26169 | 12 (0) | 00:00:01 |
    | 24. NESTED EXTERNAL LOOPS | 11. 25465 | 10 (0) | 00:00:01 |
    | 25. NESTED EXTERNAL LOOPS | 11. 21131. 9 (0) | 00:00:01 |
    | 26. NESTED EXTERNAL LOOPS | 11. 18326. 8 (0) | 00:00:01 |
    | 27. NESTED LOOPS | 11. 13651 | 7 (0) | 00:00:01 |
    | 28. NESTED EXTERNAL LOOPS | 11. 12452. 6 (0). 00:00:01 |
    | 29. NESTED EXTERNAL LOOPS | 11. 10978. 5 (0) | 00:00:01 |
    | 30. NESTED LOOPS | 11. 9504. 4 (0) | 00:00:01 |
    | 31. NESTED EXTERNAL LOOPS | 4. 360 | 3 (0) | 00:00:01 |
    | 32. NESTED LOOPS | 4. 228. 2 (0) | 00:00:01 |
    | * 33 | INDEX UNIQUE SCAN | S_PARTY_P1 | 1. 11. 1 (0) | 00:00:01 |
    | 34. TABLE ACCESS BY INDEX ROWID | S_CONTACT_BU | 4. 184. 1 (0) | 00:00:01 |
    | * 35 | INDEX RANGE SCAN | S_CONTACT_BU_M1 | 4 | | 1 (0) | 00:00:01 |
    | 36. TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1. 33. 1 (0) | 00:00:01 |
    | * 37 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | 1 (0) | 00:00:01 |
    | * 38 | TABLE ACCESS BY INDEX ROWID | S_CONTACT. 3. 2322 | 1 (0) | 00:00:01 |
    | * 39 | INDEX UNIQUE SCAN | S_CONTACT_P1 | 1 | | 1 (0) | 00:00:01 |
    | 40. TABLE ACCESS BY INDEX ROWID | S_MED_SPEC | 1. 134. 1 (0) | 00:00:01 |
    | * 41. INDEX UNIQUE SCAN | S_MED_SPEC_P1 | 1 | | 1 (0) | 00:00:01 |
    | 42. TABLE ACCESS BY INDEX ROWID | S_PRI_LST | 1. 134. 1 (0) | 00:00:01 |
    | * 43. INDEX UNIQUE SCAN | S_PRI_LST_P1 | 1 | | 1 (0) | 00:00:01 |
    | * 44 | TABLE ACCESS BY INDEX ROWID | S_PARTY | 1. 109. 1 (0) | 00:00:01 |
    | * 45 | INDEX UNIQUE SCAN | S_PARTY_P1 | 1 | | 1 (0) | 00:00:01 |
    | 46. TABLE ACCESS BY INDEX ROWID | S_CONTACT_SS | 1. 425. 1 (0) | 00:00:01 |
    | * 47 | INDEX RANGE SCAN | S_CONTACT_SS_U1 | 1 | | 1 (0) | 00:00:01 |
    | 48. TABLE ACCESS BY INDEX ROWID | S_CONTACT_LOYX | 1. 255. 1 (0) | 00:00:01 |
    | * 49 | INDEX RANGE SCAN | S_CONTACT_LOYX_U1 | 1 | | 1 (0) | 00:00:01 |
    | * 50 | INDEX RANGE SCAN | S_DQ_CON_KEY_U1 | 1. 394. 1 (0) | 00:00:01 |
    | * 51 | TABLE ACCESS FULL | S_CASE | 1. 64. 0 (0) |
    | 52. TABLE ACCESS BY INDEX ROWID | S_POSTN | 1. 21. 1 (0) | 00:00:01 |
    | * 53 | INDEX UNIQUE SCAN | S_POSTN_U2 | 1 | | 1 (0) | 00:00:01 |
    | 54. TABLE ACCESS BY INDEX ROWID | S_EMP_PER | 1. 151. 1 (0) | 00:00:01 |
    | * 55 | INDEX UNIQUE SCAN | S_EMP_PER_U1 | 1 | | 1 (0) | 00:00:01 |
    | 56. TABLE ACCESS BY INDEX ROWID | S_POSTN_CON | 1. 45. 1 (0) | 00:00:01 |
    | * 57 | INDEX RANGE SCAN | S_POSTN_CON_M3 | 4 | | 1 (0) | 00:00:01 |
    | 58. TABLE ACCESS BY INDEX ROWID | S_ORG_EXT_FNX | 1. 71. 1 (0) | 00:00:01 |
    | * 59 | INDEX RANGE SCAN | S_ORG_EXT_FNX_U1 | 1 | | 1 (0) | 00:00:01 |
    | 60. TABLE ACCESS BY INDEX ROWID | S_ORG_EXT_X | 1. 242. 1 (0) | 00:00:01 |
    | * 61. INDEX RANGE SCAN | S_ORG_EXT_X_U1 | 1 | | 1 (0) | 00:00:01 |
    | 62. TABLE ACCESS BY INDEX ROWID | S_CON_ADDR | 1. 33. 1 (0) | 00:00:01 |
    | * 63. INDEX RANGE SCAN | S_CON_ADDR_M51 | 1 | | 1 (0) | 00:00:01 |
    | 64. TABLE ACCESS BY INDEX ROWID | S_ADDR_PER | 1. 51 M | 1 (0) | 00:00:01 |
    | * 65 | INDEX UNIQUE SCAN | S_ADDR_PER_P1 | 1 | | 1 (0) | 00:00:01 |
    | 66. TABLE ACCESS BY INDEX ROWID | S_ADDR_PER | 1. 58. 1 (0) | 00:00:01 |
    | * 67. INDEX UNIQUE SCAN | S_ADDR_PER_P1 | 1 | | 1 (0) | 00:00:01 |
    | 68. TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1. 49. 1 (0) | 00:00:01 |
    | * 69 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | 1 (0) | 00:00:01 |
    | 70. TABLE ACCESS BY INDEX ROWID | S_POSTN | 1. 21. 1 (0) | 00:00:01 |
    | * 71 | INDEX UNIQUE SCAN | S_POSTN_U2 | 1 | | 1 (0) | 00:00:01 |
    | 72. TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1. 219. 1 (0) | 00:00:01 |
    | * 73 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | 1 (0) | 00:00:01 |
    | 74. TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1. 598. 1 (0) | 00:00:01 |
    | * 75 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | 1 (0) | 00:00:01 |
    | 76. TABLE ACCESS BY INDEX ROWID | S_CONTACT_X | 1. 134. 1 (0) | 00:00:01 |
    | * 77 | INDEX RANGE SCAN | S_CONTACT_X_U1 | 1 | | 1 (0) | 00:00:01 |
    | * 78 | INDEX UNIQUE SCAN | S_PARTY_P1 | 1. 11. 1 (0) | 00:00:01 |
    | * 79 | INDEX UNIQUE SCAN | S_PARTY_P1 | 1. 11. 1 (0) | 00:00:01 |
    | 50 M | TABLE ACCESS BY INDEX ROWID | S_POSTN_CON | 1. 32. 1 (0) | 00:00:01 |
    | * 81 | INDEX RANGE SCAN | S_POSTN_CON_M3 | 1 | | 1 (0) | 00:00:01 |
    | 82. TABLE ACCESS BY INDEX ROWID | S_POSTN | 1. 21. 1 (0) | 00:00:01 |
    | * 83 | INDEX UNIQUE SCAN | S_POSTN_U2 | 1 | | 1 (0) | 00:00:01 |
    | * 84 | INDEX UNIQUE SCAN | S_PARTY_P1 | 1. 11. 1 (0) | 00:00:01 |
    | 85. TABLE ACCESS BY INDEX ROWID | S_USER | 1. 14. 1 (0) | 00:00:01 |
    | * 86 | INDEX UNIQUE SCAN | S_USER_U2 | 1 | | 1 (0) | 00:00:01 |
    | 87. TABLE ACCESS BY INDEX ROWID | S_USER | 1. 14. 1 (0) | 00:00:01 |
    | * 88. INDEX UNIQUE SCAN | S_USER_U2 | 1 | | 1 (0) | 00:00:01 |
    | 89. TABLE ACCESS BY INDEX ROWID | S_USER | 1. 14. 1 (0) | 00:00:01 |
    | * 90 | INDEX UNIQUE SCAN | S_USER_U2 | 1 | | 1 (0) | 00:00:01 |
    | 91. TABLE ACCESS BY INDEX ROWID | S_USER | 1. 14. 1 (0) | 00:00:01 |
    | * 92 | INDEX UNIQUE SCAN | S_USER_U2 | 1 | | 1 (0) | 00:00:01 |
    ---------------------------------------------------------------------------------------------------------------------------------

    Information of predicates (identified by the operation identity card):
    ---------------------------------------------------

    33 - access("T15".") ROW_ID "(=:2)"
    35 - access("T1".") BU_ID "(=:2)"
    37 - access("T2".") PAR_ROW_ID "(=:2)"
    38 - filter ((NLS_UPPER ("LAST_NAME", '= "GENERIC_BASELETTER" nls_sort') AS
    NLS_UPPER(:3,'nls_sort=''GENERIC_BASELETTER''') AND 'T33 '. "PRIV_FLG"(='N')) "
    39 - access("T33".") ROW_ID '= 'T1'.' CONTACT_ID')
    41 - access("T33".") MED_SPEC_ID '= 'T5'.' ROW_ID")
    43 - access("T33".") CURR_PRI_LST_ID "="T18"." ROW_ID")
    44 - filter("T7".") PARTY_TYPE_CD' <>'Suspect')
    45 - access("T7".") ROW_ID "= 'T33'." PAR_ROW_ID')
    47 - access("T7".") ROW_ID "="T8"." PAR_ROW_ID')
    49 - access("T7".") ROW_ID "="T12"." PAR_ROW_ID')
    50 - access("T7".") ROW_ID "="T19"." CONTACT_ID')
    51 - filter("T7".") ROW_ID "= 'T25'." PR_SUBJECT_ID')
    53 - access("T33".") PR_POSTN_ID "="T21"." PAR_ROW_ID')
    55 - access("T7".") ROW_ID "="T23"." PAR_ROW_ID')
    57 - access("T30".") POSTN_ID ' =: 1 AND "T7".» ROW_ID "= 'T30'." CON_ID')
    59 - access("T33".") PR_DEPT_OU_ID '= 'T22'.' PAR_ROW_ID')
    61 - access("T33".") PR_DEPT_OU_ID "="T14"." PAR_ROW_ID')
    63 - access("T33".") PR_OU_ADDR_ID '= 'T11'.' ADDR_PER_ID' AND 'T33 '. "PR_DEPT_OU_ID"= "T11". ("' ACCNT_ID")
    65 - access("T33".") PR_PER_ADDR_ID "="T32"." ROW_ID")
    67 - access("T33".") PR_OU_ADDR_ID "="T17"." ROW_ID")
    69 - access("T33".") PR_DEPT_OU_ID '= 'T3'.' PAR_ROW_ID')
    71 - access("T3".") PR_POSTN_ID '= 'T31'.' PAR_ROW_ID')
    73 - access("T33".") PR_DEPT_OU_ID "="T9"." PAR_ROW_ID')
    75 - access("T33".") PR_DEPT_OU_ID '= 'T13'.' PAR_ROW_ID')
    77 - access("T7".") ROW_ID "="T20"." PAR_ROW_ID')
    78 - access("T33".") PR_DEPT_OU_ID '= 'T4'.' ROW_ID")
    79 - access("T33".") PR_SYNC_USER_ID '= 'T16'.' ROW_ID")
    81 - access("T33".") PR_POSTN_ID '= 'T29'.' POSTN_ID' AND 'T33 '. "ROW_ID"= 'T29'. ("' CON_ID")
    83 - access("T29".") POSTN_ID "="T6"." PAR_ROW_ID')
    84 - access("T29".") POSTN_ID "= 'T27'." ROW_ID")
    86 - access("T6".") PR_EMP_ID "="T26"." PAR_ROW_ID')
    88 - access("T21".") PR_EMP_ID '= 'T28'.' PAR_ROW_ID')
    90 - access("T31".") PR_EMP_ID '= 'T24'.' PAR_ROW_ID')
    92 - access("T33".") PR_SYNC_USER_ID '= 'T10'.' PAR_ROW_ID')

    Note
    -----
    -dynamic sample used for this survey (level = 5)
    -Automatic DOP: calculated degree of parallelism is 1 because of the parallel threshold
    -Profile SQL SYS_SQLPROF_013b617a8f0b005f used for this statement
    Looks like ORACLE considers all my questions with '1 second' which is the parallel threshold (5 seconds) and so works in series? Or am I completely wrong?


    (continued)

    Edited by: Penky 5 December 2012 09:37

    Penky wrote:
    Randolf,

    db_file_multiblock_read_count find not at all as far as I know, so it translates the default of 128 to 11 g. I read somewhere that it's not recommended to set it manually 10 or 11 and following.

    Thank you for the values. Which is recommended, fix, but still a lot together sites of value to something by default. I don't know yet where this MB_IO_COUNT = 8 comes, however.

    Furthermore, if you do want to play with the DOP Auto, you could just stick to the old manual DOP. If you set your PARALLEL_DEGREE_POLICY MANUAL, but have the objects marked as PARALLEL, you should get a PARALLEL query, it has provided is no less available to the optimizer serial plan.

    The default DOP is very susceptible to high (64 per node with your given configuration), you can set the PARALLEL degree to something lower.

    You could also play with ALTER SESSION FORCE PARALLEL QUERY PARALLEL x if you want / can limit this to specific sessions, then you have even to mark objects as PARALLEL, such that it could have side effects to other processes that you do not want to run in parallel.

    Randolf

  • Redo generation for Direct path Inserts

    Hello, I'm trying to understand some test results confused I see this morning on the generation of redo direct path for the pads. Based on my understanding of Tom to ask several discussions directly inserts path on a set of data to force the record should generate much less remake a traditional insert because the insertion of the direct route does not generate as much cancel which in turn should generate less do on cancellation.

    https://asktom.Oracle.com/pls/asktom/f?p=100:11:0:P11_QUESTION_ID:5280714813869

    Of course, always connect the actual inserted rows but I expected to the remake was less because less cancel has been generated. Instead the roll forward is actually bigger and I don't know why.

    Here's a test case to prove my example.

    set autotrace traceonly;
create table test_redo as select * from all_tables where 1=0;
insert into test_redo select * from all_tables;
rollback;
insert /*+ append */ into test_redo select * from all_tables;
rollback;


    Stats without Append Hint

Statistics
----------------------------------------------------------
        387  recursive calls
       1275  db block gets
      19604  consistent gets
          9  physical reads
    2409204  redo size
        501  bytes sent via SQL*Net to client
        897  bytes received via SQL*Net from client
          4  SQL*Net roundtrips to/from client
          4  sorts (memory)
          0  sorts (disk)
       9031  rows processed

Stats with Append Hint

Statistics
----------------------------------------------------------
         59  recursive calls
        162  db block gets
      18675  consistent gets
          0  physical reads
    2596904  redo size
        490  bytes sent via SQL*Net to client
        911  bytes received via SQL*Net from client
          4  SQL*Net roundtrips to/from client
          2  sorts (memory)
          0  sorts (disk)
       9031  rows processed

    Any ideas on what I'm missing?

    Thank you

    The / * + append * / copies all blocks Oracle in roll forward, with a little extra for recording etc. headers.

    The standard insert creates change descriptions which save odd odd little bits of space and adds little bits of information links (as well as some redo to describe a very small amount to cancel)...

    The difference between the two has always been pretty low (assuming that you are running in archivelog mode, or force logging) on a right append.  It is possible that curious little details of efficiencies in future versions of the average of the Oracle that the standard Insert wins a place a bit more efficient - it used to be the other way around in earlier versions.

    Concerning

    Jonathan Lewis

Maybe you are looking for