ALTER INDEX with parallel and Nologging

I want to move some indexes to a different tablespace. For this I use the SQL below:

XYZ ALTER INDEX REBUILD TABLESPACE TS_INDX01 NOLOGGING PARALLEL 8;

I use NOLOGGING and PARALLEL thinking it will speed up the process of movement. But now I'm confused because I think that this will change the index property, as in, when we create an index specify us certain parallels and logging properties.

So I want to understand:

1. the SQL above to change the properties of the index?

2. How can I check the existing nologging and parallel properties of an index?

SQL> create table temp (no integer, name varchar2(100));

Table created.

SQL> create index temp_idx on temp(no);

Index created.

SQL> select degree, logging from user_indexes where index_name = 'TEMP_IDX';

DEGREE                                   LOG
---------------------------------------- ---
1                                        YES

SQL> drop index temp_idx;

Index dropped.

SQL> create index temp_idx on temp(no) nologging parallel 5;

Index created.

SQL> select degree, logging from user_indexes where index_name = 'TEMP_IDX';

DEGREE                                   LOG
---------------------------------------- ---
5                                        NO

SQL> alter index temp_idx parallel 1 logging
  2  ;

Index altered.

SQL> select degree, logging from user_indexes where index_name = 'TEMP_IDX';

DEGREE                                   LOG
---------------------------------------- ---
1                                        YES

Tags: Database

Similar Questions

  • ALTER index rebuild (parallel nologing) vs (parallel nologging)

    The below statements have difference the behavior of oracle or it is just the other way to use the syntax:

    SQL > create index test_idx on test (owner, table_name, nom_tablespace);

    The index is created.


    What is the best way to use?

    SQL > alter index test_idx reconstruction nologging parallel 16;

    The index is modified.

    SQL > alter index rebuild nologging test_idx parallel (16 degrees);

    The index is modified.

    SQL > alter index rebuild nologging test_idx parallel (measure 16);

    The index is modified.


    and

    SQL > alter index test_idx connection parallel 1.

    The index is modified.


    SQL > alter index test_idx parallel 1 operating forest;

    The index is modified.


    All I'm trying to understand y - no difference in the statements of reconstruction? I have

    If you read the link below, I'm sure you cela and the rest doubts will never be around you...!
    http://download.Oracle.com/docs/CD/B19306_01/server.102/b14200/statements_1008.htm

    Logging and parallel clauses are optional, and there is no effect on the order of the optional clauses.

    Concerning
    Girish Sharma

  • Try to install EQ7 on iMac with Parallels and Windows 7

    Have iMac with Parallels and Windows 7. Try to install EQ7 (windows only program). Get the message "Error reading setup initialization file." How can I install this program?

    See the developers website for compatibility with Windows 7 and if there are updates, corrections or difficulties that might ensure compatibility.

    Windows 7 Compatibility Center

    Check if your application software or hardware is on the list

    http://www.Microsoft.com/Windows/compatibility/Windows-7/en-us/default.aspx

    Software:

    http://www.Microsoft.com/Windows/compatibility/Windows-7/en-us/default.aspx?type=software

    You can also try to run the program in compatibility mode

    You can find more information on compatibility modes in the articles below:

    http://Windows.Microsoft.com/en-us/Windows7/what-is-program-compatibility

    http://Windows.Microsoft.com/en-us/Windows7/make-older-programs-run-in-this-version-of-Windows

    http://Windows.Microsoft.com/en-us/Windows7/Program-Compatibility-Assistant-frequently-asked-question

  • ALTER Index Rebuild online

    My database is out 10 gr 2. Sometimes, I pass command ALTER INDEX < index name > REBUILD online on the indexes that are 500 MB in size. It takes about ten minutes to run the command. The database alert log shows no activity for the first six minutes, and DML is allowed on the associated table. At about minute seven journal alerts shows the first of a series of five online redo logs switches. They are each 100 MB.

    During the time that online redo logs, DML execution sessions cannot fill. When the new version of the index was created again online records switching station, the original copy of the index disappears, the ALTER INDEX command ends, and blocking for DML ceases.

    I read that the DML statements are not affected by executing ALTER INDEX REBUILD online, but experience shows that the blocking of the above sessions. Can someone explain to me what is happening in the different stages of the index rebuild? Is there something I can do to eliminate the blocking of the DML statements during the period when redo online record switch?

    Thank you
    Bill

    Bill,

    A useful reference for you:
    http://jonathanlewis.WordPress.com/2009/06/05/online-rebuild/

    Another very useful reference - of many articles:
    http://richardfoote.WordPress.com/category/index-rebuild/

    For what reason you rebuild the index?

    Charles Hooper
    Co-author of "Expert Oracle practices: Oracle Database Administration of the Oak Table.
    http://hoopercharles.WordPress.com/
    IT Manager/Oracle DBA
    K & M-making Machine, Inc.

  • Diff bet rebuilding indexes with NOLOGGING and UNRECOVERABLE

    Hello

    What would you please tell me what is the difference beterrn rebuilding of indexes with NOLOGGING and UNRECOVERABLE.

    Thank you

    Meaning remains the same. UNRECOVERABLE has been deprecated (it is there only for backward compatibility) and he was replaced by NOLOGGING.

    Kind regards
    S.K.

  • ALTER INDEX REBUILD and large waste area

    Hello world.

    Concerns the RDBMS EE 10.2.0.2 on a box with 16CPUs. Non-standard initialization parameters:

    db_16k_cache_size = 3G
    pga_aggregate_target = 3G
    SGA_MAX_SIZE = 12G
    SGA_TARGET = 5G
    workarea_size_policy = AUTO

    I have a large table partitioned on a monthly basis with a local couple of bitmap index on this subject. Table and index are stored in different areas of storage. The index tablespace is

    EXTENT MANAGEMENT UNIFORM LOCAL 1 M SIZE
    16K BLOCKSIZE
    SEGMENT SPACE MANAGEMENT AUTO

    Nightly batch processing allows a few partitions index unusable then inserts/adds one part of the data and rebuilds the index with

    ALTER INDEX... REBUILD PARTITION... NOLOGGING PARALLEL

    When you are finished, query on DBA_IND_PARTITIONS shows that, for all the index, partition value SCOPES is much greater than the value of used BYTES, for example one of the partitions has 106 DEGREES (1 MB each so he made 106 MB space) while only 15 MB for the BYTES.

    I understand that during the reconstruction of the parallel process slave create segments in the tablespace of the index of destination so that spend a lot more space than this segment takes finally. But it also means that the space is not released. (Deallocation/shrinkage will not help). Same thing can be demonstrated by the queries on DBA_SEGMENTS and DBA_FREE_SPACE. Because of this behavior, I have huge waste of space in the tablespace to index.

    Can someone help, please?
    Przemek

    Allocate space for parallel process slave is documented in the book 'Data warehousing database Oracle 10 g 2', chapter 25 "run in parallel to assistance.

    user2038804 wrote:
    Concerns the RDBMS EE 10.2.0.2 on a box with 16CPUs. Non-standard initialization parameters:

    When you are finished, query on DBA_IND_PARTITIONS shows that, for all the index, partition value SCOPES is much greater than the value of used BYTES, for example one of the partitions has 106 DEGREES (1 MB each so he made 106 MB space) while only 15 MB for the BYTES.

    Przemek,

    I can confirm that there is a bug in 10.2.0.2 leading to inconsistent information related to size in DBA_SEGMENTS / DBA_EXTENTS after an index rebuild in parallel to a big clue, maybe a bug 4771672 in 10.2.0.3. If I remember correctly the information of MEASUREMENT is correct and the information provided in DBA_SEGMENTS is misleading.

    The Metalink note suggests to use DBMS_SPACE_ADMIN Procedure TABLESPACE_FIX_SEGMENT_EXTBLKS to correct erroneous information in the dictionary, but I don't know if it was the one we used when encountering the problem.

    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/

  • Question about parallel hint and 'alter table enable parallel DML'

    Hi all

    I have a DML as follows:

    Insert / * + append * / into table1
    Select *.
    of COMPLEX_VIEW;

    Here complex_view contains a very complicated SQL, in which there is some heavy tables joins, subqueries, and aggregations.

    Question 1:

    Let's assume that the underlying tables have no attribute "parallel." Where should I add "parallel index" to force it to be run in parallel and can get better performance?

    Some members think that what follows is good.

    Insert / * + append * / into table1
    Select / * + parallel (a 4) * / *.
    of COMPLEX_VIEW;

    But I think that indicators must be put in the defintion of the complex view where they should be and do not put advice to the main insert DML, like this:

    Insert / * + append * / into table1
    Select *.
    of COMPLEX_VIEW; -I added the indicators in the COMPLEX_VIEW.

    What is your opinion?

    Quesion2:
    Without ' alter session enable parallel DML ", I can see the parallel session in v$ px_session thus." And the execution time has been shortened. This proves without this statement, the DML is also run in parallel.

    So, what is the effect of this statement?

    Best regards
    Leon

    I prefer the suspicion out of the COMPLEX_VIEW. This way, only this application forces the suspicion. If you put the indicator in the COMPLEX_VIEW, any other query on COMPLEX_VIEW (or Assembly of COMPLEX_VIEW to another view or a table) would also "encode" indicator in its execution. You don't then isolation parallel query to only where it is needed.

    If you put the parallel indicator in SELECT it (or view), the query is parallelized. This does not necessarily mean that the INSERT is parallelized. What you see v$ px_session are only slaves to PQ to SELECT.
    You must ALTER SESSION ACTIVATE PARALLEL DML and add the PARALLEL indicator in the INSERT.

    Hemant K Collette

  • Create indexes with NOLOGGING option

    Hello

    Can you please provide solution on the following scenario?

    If I create indexes with NOLOGGING Tablespace that is created with the LOGGING option, option can you please let me know what are the effects on the database?

    If I create indexes using NOLOGGING on Tables that are created with the LOGGING option, can you please let me know that it is to increase performance during the creation / rebuild indexes?

    Thank you

    Published by: user12088323 on December 28, 2010 12:45

    Published by: user12088323 on December 28, 2010 12:47

    user12088323 wrote:
    The database is in log mode archive. I would like to create indexes with NOLOGGING option on the tables to increase performance. The tables are created with the LOGGING option. Can you please let me know it's to create a bad effect on the database? If so, please explain.

    Thank you

    Published by: user12088323 on December 28, 2010 16:37

    NOLOGGING will cease to produce data AGAIN... for which you want to execute the instructions.
    Nothing wrong... it is created by ORACLE ;-)

    read this and cross with your process. You can do it with nologging option.

    http://www.Oracle.com/technetwork/database/RDB/0804-NOLOGGING-option-130004.PDF

    hope you understood

  • NOLOGGING with DEC and RMAN incremental backup

    DB Version: 10.2.0.4
    OS : AIX
    
    We use RMAN for our backup scheduled via cron.
    Retention Policy : REDUNDANCY 1
    Type             : Incremental 
    On the 31 of every month in most of our patterns, we recreate a lot of tables using DEC.

    Due to the size, the CREATE TABLE instructions take a while. Because we run on the Standard edition, we cannot use the PARALLELISM.
    NOLOGGING is the only option to improve performance. But we are concerned the roll forward not being generated for these tables and the potential loss of data in case of crash.

    Currently we take a Level0 backup every Wednesday and Sunday night and LEVEL1 backup on the rest of the days.

    I know that all will be saved on Level0. But what happens if 31 falls on a day which occurs the only backup of level 1. We will be safe only until the next Level0 arrives.

    No work around for this?

    HI T.Boyd,

    NOLOGGING is the only option to improve performance.

    So no recovery will be generated but the blocks in the data files will change.

    But what happens if 31 falls on a day which occurs the only backup of level 1.

    Only blocks changed since the last level 0 (or level 1 if you use differential differential) will be saved which includes blocks modified by the ETG.

    No work around for this?

    No need for a work around. You can check at any time whether a certain activity nologging will compromise a restoration with < report="" unrecoverable;=""> .
    Kind regards
    Tycho

  • rebuild indexes with NOLOGGING

    I like to read

    http://richardfoote.files.WordPress.com/2007/12/index-internals-rebuilding-the-truth.PDF

    and he says

    'Reconstructions of Index generate massive amounts of acetate to redo.

    which is a point just, but because we can do it with NOLOGGING, why would you ever rebuild an index with a RECORD? I mean, we can always rebuild using the table, even if our database crashed. So we should always do with NOLOGGING, and point Richard becomes rather redundant, isn't?

    I mean, Richard knows a lot more than me and I am in no way challenge his authority, I just don't see why we worry index generating a lot of when we can easily put out of service.

    Thank you

    Among other things, think about what happens if you have a recovery site after a disaster and you are using DataGuard to maintain the previous day. This will require that all elementary operations are recorded and thus eliminate your ability to make reconstructions NOLOGGING indices on the main machine.

    Justin

  • Have Windows 7 running on Parallels Desktop with a Mac. Get "setup.exe is not a valid Win32 application" when trying to download a program with Windows Explorer. I can download from these sites with Vista and XP with other computers.

    Have Windows 7 running on Parallels Desktop with a Mac. Get "setup.exe is not a valid Win32 application" when trying to download a program with Windows Explorer. I can download from these sites with Vista and XP with other computers. Now, I can't download the programs that are supposed to solve the problem! including FoxFire

    Try to download from this site:

  • My website looks fine in other browsers, but on firefox it arrives as an index with the title first and on the second line it says go to the content. This can be corrected?

    When I look at my site it loads as an index with the heading on the top line and then a link saying "go to content" and then corresponds to the navigation in the chips. I downloaded the latest version of firefox and this did not improve the situation. The site looks very well in other browsers.

    Make sure that you do not block the CSS files on this page.

    Reload Web pages, and ignore the cache.

    • Hold SHIFT and click reload.
    • Press 'Ctrl + F5' or 'Ctrl + Shift + R' (Windows, Linux)
    • Press 'Cmd + Shift + R' (MAC)

    Start Firefox in Firefox to solve the issues in Safe Mode to check if one of the extensions of the origin of the problem (switch to the DEFAULT theme: Firefox (Tools) > Add-ons > appearance/themes).

  • Receiving a message to activate Windows 7 online. Tried this and it will not activate. Windows 7 on your MAC with Parallels.

    Activating Windows 7

    I BOUGHT WINDOWS 7 WITH PARALLELS DESKTOP 5.  IT IS INSTALLED AND WORKING FINE EXCEPT THAT I GET A MESSAGE TO ACTIVATE ONLINE.  I TRIED TO DO AND IT WON'T LET ME ACTIVATE.  I CHECKED THE KEY TO PRODUCT AT LEAST 10 TIMES AND IT IS CORRECT.  I'M DOING SOMETHING WRONG?

    Case of failure of the online activation:

    Call Microsoft use the manual phone Activation

    Note: If you always install Windows page enter your product key, do not enter your key and uncheck the "Automatically activate when online" then click OK/next to complete the installation.

    If you have trouble activating Windows 7 you can call Microsoft to activate it by following the steps below.

    1. with the operation of Windows, click Start, then in the search box type: slui.exe 4

    2. press enter on your keyboard

    3. Select your country.

    4. Select the telephone activation option, dial the given number and hold for a person pick up.

    For more details:

    http://www.SevenForums.com/tutorials/18715-activate-Windows-7-phone.html

    If you are still unable to activate:

    (1) download and run the Microsoft Genuine Diagnostics tool:

    http://go.Microsoft.com/fwlink/?LinkId=52012

    (2) then copy and paste your analysis results.

    Questions about installing Windows 7?
    FAQ - Frequently Asked Questions from Installation Windows 7 & responses

  • 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

  • With parallel option swap partition

    Hi all

    I do a swap with parallel option partition, but his giving is not not an option valid.

    ALTER TABLE table_1
    P_name SWAP PARTITION
    WITH TABLE table_2
    WITHOUT VALIDATION
    PARALLEL (level 12);

    ERROR on line 5:
    ORA-14094: invalid ALTER TABLE EXCHANGE PARTITION option

    Please advice.

    Thank you and best regards,
    Rakesh

    Published by: user12003321 on March 5, 2010 17:43

    This means that we cannot run with parallel option swap partition when we do not include the index of update?

    FIX!

    cannot use PARALLEL with EXCHANGE

Maybe you are looking for