Parallel execution and temporary tablespaces

I have a large long running (1 hour) data warehouse query in a materialized view.
If I parallelize it using the parallel hint then I run out of temporary tablespace.
I've tried creating a bunch of temporary tablespaces and putting them into a temp tablespace group but it still runs out of space. Parallel execution seems to use up way more temp tablespace than sequential execution.
I know it is a very general question, but what are the tips for parallelizing a long running query with respect to temporary tablespace management?
I've tried searching on the interwebs but I don't find anything that addresses this particular issue.

And here is the parallel explain plan:
PLAN_TABLE_OUTPUT
Plan hash value: 1293981491
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 81M| 17G| | 19232 (2)| 00:00:01 | | | |
| 1 | TABLE ACCESS BY INDEX ROWID | MART$SC_SCORES | 1 | 13 | | 3 (0)| 00:00:01 | | | |
|* 2 | INDEX UNIQUE SCAN | SSCS_SDCC_FK_I | 1 | | | 2 (0)| 00:00:01 | | | |
| 3 | PX COORDINATOR | | | | | | | | | |
| 4 | PX SEND QC (RANDOM) | :TQ10017 | 81M| 17G| | 19232 (2)| 00:00:01 | Q1,17 | P->S | QC (RAND) |
|* 5 | HASH JOIN RIGHT OUTER BUFFERED | | 81M| 17G| | 19232 (2)| 00:00:01 | Q1,17 | PCWP | |
| 6 | PX RECEIVE | | 41925 | 491K| | 2 (0)| 00:00:01 | Q1,17 | PCWP | |
| 7 | PX SEND BROADCAST | :TQ10014 | 41925 | 491K| | 2 (0)| 00:00:01 | Q1,14 | P->P | BROADCAST |
| 8 | PX BLOCK ITERATOR | | 41925 | 491K| | 2 (0)| 00:00:01 | Q1,14 | PCWC | |
| 9 | INDEX FAST FULL SCAN | I_DWH_ZIP_ZIPCODE_EIDIID | 41925 | 491K| | 2 (0)| 00:00:01 | Q1,14 | PCWP | |
|* 10 | HASH JOIN | | 81M| 16G| | 19218 (2)| 00:00:01 | Q1,17 | PCWP | |
| 11 | JOIN FILTER CREATE | :BF0000 | 6414K| 159M| | 806 (2)| 00:00:01 | Q1,17 | PCWP | |
| 12 | PX RECEIVE | | 6414K| 159M| | 806 (2)| 00:00:01 | Q1,17 | PCWP | |
| 13 | PX SEND HASH | :TQ10015 | 6414K| 159M| | 806 (2)| 00:00:01 | Q1,15 | P->P | HASH |
| 14 | PX BLOCK ITERATOR | | 6414K| 159M| | 806 (2)| 00:00:01 | Q1,15 | PCWC | |
|* 15 | INDEX FAST FULL SCAN | I_DWH_ADDRESS_COMB_ZIP | 6414K| 159M| | 806 (2)| 00:00:01 | Q1,15 | PCWP | |
| 16 | PX RECEIVE | | 80M| 14G| | 18397 (2)| 00:00:01 | Q1,17 | PCWP | |
| 17 | PX SEND HASH | :TQ10016 | 80M| 14G| | 18397 (2)| 00:00:01 | Q1,16 | P->P | HASH |
| 18 | JOIN FILTER USE | :BF0000 | 80M| 14G| | 18397 (2)| 00:00:01 | Q1,16 | PCWP | |
|* 19 | HASH JOIN RIGHT OUTER BUFFERED | | 80M| 14G| | 18397 (2)| 00:00:01 | Q1,16 | PCWP | |
| 20 | PX RECEIVE | | 42M| 409M| | 827 (2)| 00:00:01 | Q1,16 | PCWP | |
| 21 | PX SEND HASH | :TQ10012 | 42M| 409M| | 827 (2)| 00:00:01 | Q1,12 | P->P | HASH |
| 22 | PX BLOCK ITERATOR | | 42M| 409M| | 827 (2)| 00:00:01 | Q1,12 | PCWC | |
| 23 | MAT_VIEW ACCESS FULL | MBI$CMN_ACTION_COST | 42M| 409M| | 827 (2)| 00:00:01 | Q1,12 | PCWP | |
| 24 | PX RECEIVE | | 80M| 14G| | 17549 (1)| 00:00:01 | Q1,16 | PCWP | |
| 25 | PX SEND HASH | :TQ10013 | 80M| 14G| | 17549 (1)| 00:00:01 | Q1,13 | P->P | HASH |
|* 26 | HASH JOIN BUFFERED | | 80M| 14G| | 17549 (1)| 00:00:01 | Q1,13 | PCWP | |
| 27 | PX RECEIVE | | 6312K| 794M| | 7519 (1)| 00:00:01 | Q1,13 | PCWP | |
| 28 | PX SEND HASH | :TQ10010 | 6312K| 794M| | 7519 (1)| 00:00:01 | Q1,10 | P->P | HASH |
|* 29 | HASH JOIN RIGHT OUTER BUFFERED | | 6312K| 794M| | 7519 (1)| 00:00:01 | Q1,10 | PCWP | |
| 30 | VIEW | | 4443K| 80M| | 2125 (2)| 00:00:01 | Q1,10 | PCWP | |
| 31 | HASH GROUP BY | | 4443K| 33M| 158M| 2125 (2)| 00:00:01 | Q1,10 | PCWP | |
| 32 | PX RECEIVE | | 10M| 78M| | 950 (1)| 00:00:01 | Q1,10 | PCWP | |
| 33 | PX SEND HASH | :TQ10007 | 10M| 78M| | 950 (1)| 00:00:01 | Q1,07 | P->P | HASH |
| 34 | PX BLOCK ITERATOR | | 10M| 78M| | 950 (1)| 00:00:01 | Q1,07 | PCWC | |
| 35 | TABLE ACCESS FULL | DWH$PHONE | 10M| 78M| | 950 (1)| 00:00:01 | Q1,07 | PCWP | |
|* 36 | HASH JOIN | | 6312K| 680M| | 5392 (1)| 00:00:01 | Q1,10 | PCWP | |
| 37 | PX RECEIVE | | 6329K| 36M| | 130 (2)| 00:00:01 | Q1,10 | PCWP | |
| 38 | PX SEND HASH | :TQ10008 | 6329K| 36M| | 130 (2)| 00:00:01 | Q1,08 | P->P | HASH |
| 39 | PX BLOCK ITERATOR | | 6329K| 36M| | 130 (2)| 00:00:01 | Q1,08 | PCWC | |
| 40 | INDEX FAST FULL SCAN | PK_DWH_DEBTOR | 6329K| 36M| | 130 (2)| 00:00:01 | Q1,08 | PCWP | |
| 41 | PX RECEIVE | | 6312K| 644M| | 5259 (1)| 00:00:01 | Q1,10 | PCWP | |
| 42 | PX SEND HASH | :TQ10009 | 6312K| 644M| | 5259 (1)| 00:00:01 | Q1,09 | P->P | HASH |
|* 43 | HASH JOIN RIGHT OUTER BUFFERED| | 6312K| 644M| | 5259 (1)| 00:00:01 | Q1,09 | PCWP | |
| 44 | PX RECEIVE | | 3689K| 31M| | 4271 (1)| 00:00:01 | Q1,09 | PCWP | |
| 45 | PX SEND HASH | :TQ10005 | 3689K| 31M| | 4271 (1)| 00:00:01 | Q1,05 | P->P | HASH |
| 46 | VIEW | | 3689K| 31M| | 4271 (1)| 00:00:01 | Q1,05 | PCWP | |
| 47 | HASH GROUP BY | | 3689K| 56M| 84M| 4271 (1)| 00:00:01 | Q1,05 | PCWP | |
| 48 | PX RECEIVE | | 3689K| 56M| | 3653 (1)| 00:00:01 | Q1,05 | PCWP | |
| 49 | PX SEND HASH | :TQ10003 | 3689K| 56M| | 3653 (1)| 00:00:01 | Q1,03 | P->P | HASH |
|* 50 | HASH JOIN | | 3689K| 56M| | 3653 (1)| 00:00:01 | Q1,03 | PCWP | |
| 51 | BUFFER SORT | | | | | | | Q1,03 | PCWC | |
| 52 | PX RECEIVE | | 3 | 21 | | 1 (0)| 00:00:01 | Q1,03 | PCWP | |
| 53 | PX SEND BROADCAST | :TQ10000 | 3 | 21 | | 1 (0)| 00:00:01 | | S->P | BROADCAST |
| 54 | INLIST ITERATOR | | | | | | | | | |
|* 55 | INDEX RANGE SCAN | I_DWH_PAYMENT_TYPE_EIDIID | 3 | 21 | | 1 (0)| 00:00:01 | | | |
| 56 | PX BLOCK ITERATOR | | 28M| 242M| | 3648 (1)| 00:00:01 | Q1,03 | PCWC | |
|* 57 | TABLE ACCESS FULL | DWH$PAYMENT | 28M| 242M| | 3648 (1)| 00:00:01 | Q1,03 | PCWP | |
| 58 | PX RECEIVE | | 6312K| 589M| | 986 (2)| 00:00:01 | Q1,09 | PCWP | |
| 59 | PX SEND HASH | :TQ10006 | 6312K| 589M| | 986 (2)| 00:00:01 | Q1,06 | P->P | HASH |
|* 60 | HASH JOIN | | 6312K| 589M| | 986 (2)| 00:00:01 | Q1,06 | PCWP | |
| 61 | PX RECEIVE | | 2937 | 172K| | 5 (20)| 00:00:01 | Q1,06 | PCWP | |
| 62 | PX SEND BROADCAST | :TQ10004 | 2937 | 172K| | 5 (20)| 00:00:01 | Q1,04 | P->P | BROADCAST |
|* 63 | HASH JOIN BUFFERED | | 2937 | 172K| | 5 (20)| 00:00:01 | Q1,04 | PCWP | |
| 64 | PX RECEIVE | | 220 | 1540 | | 2 (0)| 00:00:01 | Q1,04 | PCWP | |
| 65 | PX SEND HASH | :TQ10001 | 220 | 1540 | | 2 (0)| 00:00:01 | Q1,01 | P->P | HASH |
| 66 | PX BLOCK ITERATOR | | 220 | 1540 | | 2 (0)| 00:00:01 | Q1,01 | PCWC | |
| 67 | TABLE ACCESS FULL | DWH$MANDATOR | 220 | 1540 | | 2 (0)| 00:00:01 | Q1,01 | PCWP | |
| 68 | PX RECEIVE | | 2937 | 152K| | 2 (0)| 00:00:01 | Q1,04 | PCWP | |
| 69 | PX SEND HASH | :TQ10002 | 2937 | 152K| | 2 (0)| 00:00:01 | Q1,02 | P->P | HASH |
| 70 | PX BLOCK ITERATOR | | 2937 | 152K| | 2 (0)| 00:00:01 | Q1,02 | PCWC | |
| 71 | TABLE ACCESS FULL | DWH$PACKAGE | 2937 | 152K| | 2 (0)| 00:00:01 | Q1,02 | PCWP | |
| 72 | PX BLOCK ITERATOR | | 6312K| 228M| | 980 (1)| 00:00:01 | Q1,06 | PCWC | |
| 73 | TABLE ACCESS FULL | DWH$CASE | 6312K| 228M| | 980 (1)| 00:00:01 | Q1,06 | PCWP | |
| 74 | PX RECEIVE | | 78M| 4199M| | 10016 (1)| 00:00:01 | Q1,13 | PCWP | |
| 75 | PX SEND HASH | :TQ10011 | 78M| 4199M| | 10016 (1)| 00:00:01 | Q1,11 | P->P | HASH |
| 76 | PX BLOCK ITERATOR | | 78M| 4199M| | 10016 (1)| 00:00:01 | Q1,11 | PCWC | |
|* 77 | TABLE ACCESS FULL | DWH$ACTION | 78M| 4199M| | 10016 (1)| 00:00:01 | Q1,11 | PCWP | |
------------------------------------------------------------------------------------------------------------------------------------------------------------------

Similar Messages

  • Parallel Execution and Partitioning ?

    Hi,
    Can anybody explain me -- "How to implement Parallel execution and Partitioning in Data Warehouse?" on a single server.
    Any examples related to implement Parallel Execution helps me a lot.
    Thanks in Advance,
    -Vency

    Hi Vency,
    Try posting this in the following forum:
    General Database Discussions
    Thanks, Mark

  • DEFAULT TABLESPACE and TEMPORARY TABLESPACE for eBusiness Suite database

    Hi:
    What is the
    DEFAULT TABLESPACE and TEMPORARY TABLESPACE
    for eBusiness Suite database.
    I want to create a new schema on the eBusiness Suite database.
    Please help

    DEFAULT TABLESPACE and TEMPORARY TABLESPACE
    for eBusiness Suite database.
    I want to create a new schema on the eBusiness Suite database.Create a new tablespace and temporary tablespace for your custom schema (you may use the existing temporary tablespace).
    Integrating Custom Applications with Oracle Applications Release 11i [ID 176852.1]
    Step By Step Guide to Creating a Custom Application in Applications 11i [ID 216589.1]
    Thanks,
    Hussein

  • Move undo and temporary tablespace to new path

    Hi All,
    I want to move my undo and temporary tablespace to new path because of space issue. I am using Oracle 10g release 2 and working on production server can't take shutdown without prior permission.
    Please tell me the steps to do so...
    thanks
    Api

    About create/change/drop
    UNDO:
    SQL>show parameter undo
    NAME TYPE VALUE
    undo_management string AUTO
    undo_retention integer 900
    undo_tablespace string UNDOTBS1
    SQL> CREATE UNDO TABLESPACE undotbs2 DATAFILE '+DATA_NEWPATH' SIZE 100M AUTOEXTEND ON;
    http://www.oracle-base.com/articles/9i/AutomaticUndoManagement.php
    SQL> alter system set undo_tablespace=undotbs2;
    *** after that can drop UNDOTBS1
    TEMP:
    SQL> CREATE TEMPORARY TABLESPACE TEMP TEMPFILE '+DATA_NEWPATH' SIZE 500M AUTOEXTEND ON NEXT 100M MAXSIZE unlimited EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;
    http://www.idevelopment.info/data/Oracle/DBA_tips/Tablespaces/TBS_3.shtml
    SQL> ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp2;
    *** after that can drop old temp tablespace -> DROP TABLESPACE temp INCLUDING CONTENTS AND DATAFILES

  • Parallel Execution and disk affinity on MPP

    Hello,
    In Chapter 25 Using Parallel Execution
    Oracle® Database Data Warehousing Guide
    10g Release 2 (10.2)
    Part Number B14223-02
    There is a very short quote "Additionally, Oracle Database considers the disk affinity of the granules on MPP systems to take advantage of the physical proximity between parallel execution servers and disks."
    I understand the benefits but :
    - I'm wondering what it really means ?
    - How it can work ?
    - How to demonstrate, show this phenomenon ?
    Best Regards,
    Gregory

    Hi Vency,
    Try posting this in the following forum:
    General Database Discussions
    Thanks, Mark

  • Undo Tablespace and Temporary Tablespace - autoextend ?

    - In general, should I allow the Undo Tablespace to grow (autoextend)?
    - In general, should I allow the Temporary Tablespace to grow (autoextend)?

    The size of undo tablespace should always keeps in mind otherwiase you eill get ORA-1555 or out of space errors.
    This paper is to help DBA’s in calculating the size of UNDO tablespace by using a simple formula.
    It is tough to know about the number of transactions and subsequently number of rows changed per second.
    So I suggest having a “big undo tablespace” to start with and based on load, after doing some calculations and resize your UNDO tablespace.
    In my case one of the applications was going to production (live), and I had no idea that how many transactions will happen against this database. All what I was told that there will be optimum (transactional) activity on this database.
    So I started with UNDO tablespace with size of 3GB and datafiles with autoextend “on” .
    Note:
    In production, you must be very careful in using this (autoextend on) as the space may grow to inifinity very fast. So my advice is either dont use this option, or use with "maxsize" or continuously monitor space (which is tough).
    I month later, I noticed the activity from V$undostat.
    Here is the step by step approach:
    Step 1: Longest running query.
    SQL> select max(maxquerylen) from v$undostat;
    MAX(MAXQUERYLEN)
    1793
    This gives you ideal value for UNDO_RETENTION. To be on the safer size you should add few more seconds to get the right value. So in my case, the size of undo retention should be say 2000 secs.
    Step 2: Size of UNDO tablespace.
    Size of UNDO needed = UNDO_RETENTION x [UNDO block Generation per sec x DB_BLOCK_SIZE] + Overhead(30xDB_BLOCK_SIZE)
    Out of these we know UNDO_RETENTION and DB_BLOCK_SIZE
    All we need is to find out “UNDO Blocks per second”
    Which can be easily fetched from v$undostat
    SQL> SELECT (SUM(undoblks))/ SUM ((end_time - begin_time) * 24*60*60) "UPS"
    2 FROM v$undostat;
    UPS
    8.11985583
    V$undostat stores data for every 10 mins and begin/end times are start/end time of those intervals. We multiplied it with 24*60*60 because the difference between two dates will be in days and to get to seconds, we need it to multiply with 24hrs*60mins*60secs
    So now we have all the values needed.
    Undo size needed = [8.12 x 2000 x 8192] + [30 x 8192] = 133283840 bytes = 127.11 MB

  • Alter user default tablespace and temporary tablespace

    Hi guru,
    target : to ensure that users don't have the SYSTEM tablespace as their TEMPORARY or DEFAULT tablespace
    scenario :
    user default tablespace temporary tablespace
    xxyym system system
    Question: How to alter user ?
    tq

    In a scenario, let's say you want to make USERS the default tablespace for existing users and TEMP the default temporary tablespace, you can also create the alter statements as below into one script based on the output and run it.
    select 'ALTER USER '||username||' DEFAULT TABLESPACE USERS;'  FROM DBA_USERS WHERE DEFAULT_TABLESPACE IN('SYSTEM')
    and username not in('SYS','SYSTEM');
    select 'ALTER USER '||username||' TEMPORARY TABLESPACE TEMP;'  FROM DBA_USERS WHERE TEMPORARY_TABLESPACE IN('SYSTEM');As magnus mentioned, don't forget to do this(if USERS and TEMP is what you want to go with) :
    ALTER DATABASE DEFAULT TABLESPACE USERS;
    ALTER DATABASE DEFAULT TEMPORARY TABLESPACE TEMP;

  • Creating a primary key with the parallel option and the tablespace option

    I know I can create a unique index with these options and then make the primary key with the "using index" clause. anyway to do this and skip the create unique index and just create the primary key ?

    SQL> ALTER TABLE t
      2  ADD CONSTRAINT pk_t
      3  PRIMARY KEY (testcol)
      4  USING INDEX
      5  TABLESPACE example
      6  PARALLEL (DEGREE 2);
    PARALLEL (DEGREE 2)
    ERROR at line 6:
    ORA-03001: unimplemented featureYou can name the tablespace but you must do an alter index thereafter.

  • Best settings for sort_area_size and temporary tablespace??

    Hi, I'm trying to tune a data extract from a database which extracts records created by selects which concatenate various fields to form a record less than 100 characters long. The records are then loaded into a reporting cube.
    When it is run there are 8 instances of the extract package running which write to a separate file. When the procedures are finished Unix sorts them and merges them together.
    In terms of volume I am returning approx 280,000 records per day going back 4 years, with each instance of the procedure given a different date range.
    Currently the average procedure takes 4 hours to complete, but the sort and merge takes a further 6 hours.
    I would like to let Oracle do the sort, as even tough Oracle and unix sort the records slightly differently, this shouldn't impact the load to the reporting cube too much.
    What should I set the sort_area_size to, it currently stands at 1Mb,
    shared pool size is 200Mb.
    Any advice is welcome!!

    What should I set the sort_area_size to, it currently stands at 1Mb <<How would we know, you provide absolutely no information on user load and how much free memory your server has available. And are the sessions in question connected using dedicated sessions or shared server connections?
    Based on 280K 100 byte rows per day X 4 years the sort is going to disk. I would make sure my temp tablespace was stripped accross as many disk units as possible. And you should probably verify that you have at least 22G of sort available within the database. ( I figured at 200 days of data per year not 365 so if you have data for 7 days a week the temp estimate has to go up)
    HTH -- Mark D Powell --

  • Setting the default default tablespace and default temporary tablespace

    Is there a way to set the default default tablespace and default temporary tablespace database wide? I want to assign default and temporary tablespaces other than SYSTEM to all new users without having to explicitly define the tablespace names.

    Hi,
    Well, I assume that OP is using 10g, but exactly what you said, in Oracle 9i, it became possible to specify the default temporary tablespace in the database. In Oracle 10g, it allows all users to set up the default permanent tablespace to set the permanent tablespace used by default. Before Oracle 10g, if the default permanent tablespace is not set up when creating the user, SYSTEM tablespace will be set up as the default permanent tablespace by default.
    Cheers

  • 10G: TEMPORARY TABLESPACES GROUP

    제품 : ORACLE SERVER
    작성날짜 : 2004-05-25
    10G: TEMPORARY TABLESPACES GROUP
    ==================================
    PURPOSE
    이 문서에서는 10g New Feature 인 Temporary tablespace 의 group 에 대해 알아 보도록 한다.
    Explanation
    10g 에서는 temporary tablespaces 에 대해 group 을 지정하여 생성할 수 있고
    consumer group 을 지정하여 resource manager 와 함께 적용하여 사용이 가능하다.
    다음은 Temporary tablespace group 지정을 위한 기본적이 사항이다.
    1. 하나의 temporary tablespace group 은 적어도 하나의 tablespace 가 존재해야 하고
    maximum number tablespace 에 대한 limit 은 정해져 있지 않다.
    2. Ttemporary tablespace 와 group name 을 동일하게 지정할 수 없다.
    3. Temporary tablespace group 은
         1) 한 group 에서 다른 group 으로 move 가 가능하고
         2) Group 내에서 삭제 될 수 있으며
         3) 추가적으로 add 가 가능하다.
    4. Temporary tablespace group 사용으로 인해
         1) Sort 결과를 유지하여 space 낭비를 막을 수 있고
         2) 동시에 여러개의 session connect 시에도 서로 다른 temporary tablespaces 를 사용함으로써
         temporary tablespaces 의 사용을 분산 시킬 수 있다.
         3) Parallel operation 시에도 multiple temporary tablespaces 사용이 가능하다.
    Example
    1. GROUP1 을 지정하고 GROUP1 에 속하는 temporary tablespace LMTEMP 1 를 생성한다.
    이 때 GROUP 1 을 따로 생성할 필요 없고 temporary tablespace 생성시에 지정하도록 한다.
    SQL> create temporary tablespace LMTEMP 1
    tempfile 'D:\ORACLE10\ORCL\temp1_01.dbf' size 50M
    tablespace group GROUP1;
    SQL> select * from dba_tablespace_groups;
    GROUP_NAME TABLESPACE_NAME
    GROUP1 LMTEMP1
    2. LMTEMP2 를 GROUP1 에 새로 추가한다.
    SQL> create temporary tablespace lmtemp2
    tempfile 'D:\ORACLE10\ORCL\temp1_02.dbf' size 2M
    tablespace group group1;
    Tablespace created.
    SQL> select * from dba_tablespace_groups;
    GROUP_NAME TABLESPACE_NAME
    GROUP1 LMTEMP1
    GROUP1 LMTEMP2
    3. 기존에 존재하는 LMTEMP1 를 GROUP2 로 move 한다.
    SQL> alter tablespace LMTEMP1 tablespace group GROUP2 ;
    Tablespace altered.
    SQL> select * from dba_tablespace_groups;
    GROUP_NAME TABLESPACE_NAME
    GROUP2 LMTEMP1
    GROUP1 LMTEMP2
    4. LMTEMP1 이 속해 있던 GROUP2 에서 LMTEMP1 를 제외 시키고 다시 포함시킬 수 있다.
    SQL> alter tablespace LMTEMP1 tablespace group '';
    Tablespace altered.
    SQL> select * from dba_tablespace_groups;
    GROUP_NAME TABLESPACE_NAME
    GROUP1 LMTEMP2
    SQL> select tablespace_name from dba_tablespaces where contents='TEMPORARY';
    TABLESPACE_NAME
    TEMP
    LMTEMP1
    LMTEMP2
    SQL> alter tablespace LMTEMP1 tablespace group GROUP1;
    Tablespace altered.
    5. Temporary tablespace 와 group name 을 동일하게 지정할 경우 ORA-10918 에러가 발생한다.
    즉, temporary tablespace 와 group name 을 동일하게 지정이 불가능하다.
    SQL> create temporary tablespace lmtemp5
    tempfile 'D:\ORACLE10\ORCL\temp1_05.dbf' size 50M
    tablespace group lmtemp5;
    create temporary tablespace lmtemp5
    ERROR at line 1:
    ORA-10918: TABLESPACE GROUP name cannot be the same as tablespace name
    6. 존재하던 모든 temporary tablespaces 를 drop 하게 되면 group 은 자동으로 remove 된다.
    SQL> create temporary tablespace LMTEMP3
    tempfile 'D:\ORACLE10\ORCL\temp1_03.dbf' size 2M
    tablespace group GROUP2;
    Tablespace created.
    SQL> create temporary tablespace LMTEMP4
    tempfile 'D:\ORACLE10\ORCL\temp1_04.dbf' size 2M
    tablespace group GROUP2;
    Tablespace created.
    SQL> select * from dba_tablespace_groups;
    GROUP_NAME TABLESPACE_NAME
    GROUP1 LMTEMP1
    GROUP1 LMTEMP2
    GROUP2 LMTEMP3
    GROUP2 LMTEMP4
    SQL> drop tablespace lmtemp3 including contents and datafiles;
    Tablespace dropped.
    SQL> drop tablespace lmtemp4 including contents and datafiles;
    Tablespace dropped.
    SQL> select * from dba_tablespace_groups;
    GROUP_NAME TABLESPACE_NAME
    GROUP1 LMTEMP1
    GROUP1 LMTEMP2
    7. Group 에 user 사용이 가능하도록 지정할 수 있다.
    SQL> alter user scott temporary tablespace GROUP1;
    User altered.
    8. Temporary tablespace group 을 database level 의 default temporary tablespace 로도 지정할 수 있다.
    SQL> alter database <db_name> default temporary tablespace GROUP1;
    Database altered.
    만약, temporary tablespaces 가 default database temporary tablespace group 에 속해 있는경우
    drop 시 ORA-10921 에러가 발생하게 된다. 즉, default temporary tablespace group 에 속해 있는 경우
    drop 할 수 없다.
    SQL> drop tablespace LMTEMP2 including contents and datafiles;
    drop tablespace lmtemp2 including contents and datafiles
    ERROR at line 1:
    ORA-10921: Cannot drop tablespace belonging to default temporary tablespace
    group
    Reference Documents
    <NOTE. 245645.1>

    Hi,
    Take a look in
    1 - DBA_TEMP_FILES :http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96536/ch2398.htm
    2 - V$TEMPFILE: http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96536/ch3225.htm
    Cheers,
    Marcello M.

  • Parallel executions on AIX

    Hi,
    9.2 AIX5.3
    Since I enabled parallel executions, and table monitoring there are performance issues while database (warehouse) is loaded (sqlldr) .
    The LRUD root process gets active and maxes up the CPU to extend that performance is trashed.
    The process is active even after all db activities are gone.
    Is there something that could be done from db side to tune-accommodate the AIX behavior?
    The only solution so far is to disable the parallel executions that I'm reluctant to do.
    Thx,

    Greg Rahn wrote:
    If LRUD is consuming lots of CPU and there is also a high paging rate, it would seem to point to an issue with the VMM file cache. Are you using direct I/O? Not doing so, while using PQ would cause the VMM file cache to be flooded with I/O requests from all the PQ slaves thus resulting in a high CPU usage for LRUD. Direct I/O allows I/O to bypass the VMM and eliminates LRUD from having to do any work at all - it bypasses this code path. This is a necessity while using PQ (as well as a recommendation in the Oracle docs).
    Greg,
    I was going to say "concurrent I/O" rather than "direct I/O" - but either way it looks like there's a load of memory being used for the filesystem cache when bypassing the cache and letting Oracle use the memory seems to be the obvious bet.
    Nemohm
    Could you supply a little more precise about your comments:
    The LRUD root process gets active and maxes up the CPU to extend that performance is trashed.
    The process is active even after all db activities are gone.When you say "after all db activities are gone" - do you mean just the heavy duty loader activity is complete, or has all activity from all other users stopped as well; and is this only during and directly after a loader session, or does it happen at other times when parallel queries are going on; and how long does it take before the LRU daemon calms down ? How many CPUs do you have, by the way ?
    As Greg points out - parallel execution can result in a very heavy demand for I/O requests that bypass Oracle's own cache - this means that data that could have been thrashed through Oracle's cache when you run serially is suddenly thrashed through the filesystem cache (if hasn't been bypassed). Moreover, parallel execution often does things that put a heaavy load on the PGA memory - which could cause lots of (OS) memory pages to be reclaimed from the filesystem cache so that they can be used by Oracle processes in their PGA heaps.
    In general: if you've got memory set it up so that Oracle can use it effectively - leaving it for the filesystem cache can help in some cases, but avoiding the filesystem cache is often the better bet.
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk
    "Science is more than a body of knowledge; it is a way of thinking" Carl Sagan

  • Rapid and Huge growth of of used space of temporary tablespace

    Hi,
    Have a query (select) that run quick (no more than 10 seconds).
    As soon I insert the data into a temporary table or even on physical table, the temporary table used space starts to growth very fast. The used space is totally used and the query crash since e reach the limit (65GB), or even more if I add more table files to temporary tablespace!
    The problem also happen only if the period (dates) is one year (2013). If the period is the first trimestre of 2013 (same amount of data), the problem does not happen!!
    I also confirm that on another instance ( a test one), even with less resources this ORACLE behavior do not happen. I confirm differente execution plan queries, between the two instances .
    What I really do not understant is the behavior of the ORACLE with the huge and rapid growth!!!
    Any one experiment such a similiar situation?
    Thanks in advance,Rui
    Plan
    INSERT STATEMENT ALL_ROWSCost: 15.776 Bytes: 269 Cardinality: 1
    28 LOAD TABLE CONVENTIONAL MIDIALOG_OLAP.MED_INVCOMP_FACTTMP_BEFGROUPBY
    27 FILTER
    26 NESTED LOOPS
    24 NESTED LOOPS Cost: 15.776 Bytes: 269 Cardinality: 1
    22 NESTED LOOPS Cost: 15.775 Bytes: 255 Cardinality: 1
    19 NESTED LOOPS Cost: 15.774 Bytes: 205 Cardinality: 1
    17 NESTED LOOPS Cost: 15.773 Bytes: 197 Cardinality: 1
    14 NESTED LOOPS Cost: 15.770 Bytes: 180 Cardinality: 1
    11 NESTED LOOPS Cost: 15.767 Bytes: 108 Cardinality: 1
    9 HASH JOIN Cost: 15.757 Bytes: 8.346.500 Cardinality: 83.465
    7 HASH JOIN Cost: 13.407 Bytes: 6.345.012 Cardinality: 83.487
    5 HASH JOIN Cost: 11.163 Bytes: 5.010.550 Cardinality: 100.211
    3 HASH JOIN Cost: 5.642 Bytes: 801.288 Cardinality: 22.258
    1 INDEX RANGE SCAN INDEX MIDIALOG.IX_INSCOMP_DTCEIDICIDLCPECIDOP Cost: 120 Bytes: 489.676 Cardinality: 22.258
    2 INDEX FAST FULL SCAN INDEX (UNIQUE) MIDIALOG.IX_LINHACOMPRADA_IDLCIDOPSEQ Cost: 5.463 Bytes: 123.975.530 Cardinality: 8.855.395
    4 INDEX FAST FULL SCAN INDEX (UNIQUE) MIDIALOG.IX_LINHACOMPRADA_IDLCIDOPSEQ Cost: 5.463 Bytes: 123.975.530 Cardinality: 8.855.395
    6 TABLE ACCESS FULL TABLE MIDIALOG.ITEM_AV Cost: 1.569 Bytes: 6.963.736 Cardinality: 267.836
    8 TABLE ACCESS FULL TABLE MIDIALOG.ITEM_AV Cost: 1.572 Bytes: 7.713.672 Cardinality: 321.403
    10 INDEX UNIQUE SCAN INDEX (UNIQUE) MIDIALOG.IX_BOFINALBO_IDBOIDFINALBO Cost: 0 Bytes: 8 Cardinality: 1
    13 TABLE ACCESS BY INDEX ROWID TABLE MIDIALOG.INSERCAO_COMPRADA Cost: 3 Bytes: 72 Cardinality: 1
    12 INDEX RANGE SCAN INDEX (UNIQUE) MIDIALOG.IX_INSCOMPRADA_IDLCDATAPECAINS Cost: 2 Cardinality: 1
    16 TABLE ACCESS BY INDEX ROWID TABLE MIDIALOG.INSERCAO_ITEMFACTURA Cost: 3 Bytes: 17 Cardinality: 1
    15 INDEX RANGE SCAN INDEX MIDIALOG.IX_INSITFACT_INSCOMPRADA Cost: 2 Cardinality: 1
    18 INDEX RANGE SCAN INDEX (UNIQUE) MIDIALOG.UQ_ITEMFACTURA_IDITF_IDFACT Cost: 1 Bytes: 8 Cardinality: 1
    21 TABLE ACCESS BY INDEX ROWID TABLE MIDIALOG.FATURA Cost: 1 Bytes: 50 Cardinality: 1
    20 INDEX UNIQUE SCAN INDEX (UNIQUE) MIDIALOG.PK_FATURA Cost: 0 Cardinality: 1
    23 INDEX UNIQUE SCAN INDEX (UNIQUE) MIDIALOG.PK_TIPO_ESTADO Cost: 0 Cardinality: 1
    25 TABLE ACCESS BY INDEX ROWID TABLE MIDIALOG.TIPO_ESTADO Cost: 1 Bytes: 14 Cardinality: 1
    Edited by: rr**** on 19/Fev/2013 15:25

    I run the select with sucess, no more that 1 minute from on year of data. Few temporary used space used.
    As soon I plug the insert (global temporary table, also experiment with physical table) the used space of temporary table space start to grow crazy!!
    insert into midialog_olap.med_invcomp_facttmp_befgroupby
    select fac.numefatura,
    fac.codpessoa,
    fac.dtemiss,
    tef.nome as estado_factura,
    opsorig.demid,
    opsorig.anoplano,
    opsorig.numplano,
    opsorig.numplanilha,
    ops.nome as ordem_publicidade,
    ops.external_number as numero_externo,
    ops.estado,
    lic.seq,
    inc.data,
    inc.peca,
    fac.id_versao_plano,
    fac.ano_proforma || '.' || fac.numrf as num_proforma,
    iif.tipo_facturacao,
    opsorig.codveiculo as id_veiculo,
    opsorig.codfm as id_fornecedor_media,
    icorig.chkestado as id_estado_checking,
    0 as percentagem_comissao_agencia,
    0 as valor_pbv,
    0 as valor_stxtv,
    0 as valor_ptv,
    0 as valor_odbv,
    0 as valor_pbbv,
    0 as valor_dnv,
    0 as valor_pbnv,
    0 as valor_stxv,
    0 as valor_pbtv,
    0 as valor_dav,
    0 as valor_plv,
    0 as valor_odlv,
    0 as valor_pllv,
    0 as valor_ca,
    0 as valor_trv,
    0 as valor_txv,
    0 as valor_base_facturacao,
    decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
    decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
    inc.total_pb_compra * fac.percentagem_facturada / 100))
    as valor_pbc,
    decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
    decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
    inc.total_stxt_compra * fac.percentagem_facturada / 100))
    as valor_stxtc,
    decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
    decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
    inc.total_pt_compra * fac.percentagem_facturada / 100))
    as valor_ptc,
    decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
    decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
    inc.total_odb_compra * fac.percentagem_facturada / 100))
    as valor_odbc,
    decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
    decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
    inc.total_pbb_compra * fac.percentagem_facturada / 100))
    as valor_pbbc,
    decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
    decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
    inc.total_dn_compra * fac.percentagem_facturada / 100))
    as valor_dnc,
    decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
    decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
    inc.total_pbn_compra * fac.percentagem_facturada / 100))
    as valor_pbnc,
    decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
    decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
    inc.total_stx_compra * fac.percentagem_facturada / 100))
    as valor_stxc,
    decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
    decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
    inc.total_pbt_compra * fac.percentagem_facturada / 100))
    as valor_pbtc,
    decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
    decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
    inc.total_da_compra * fac.percentagem_facturada / 100))
    as valor_dac,
    decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
    decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
    inc.total_pl_compra * fac.percentagem_facturada / 100))
    as valor_plc,
    decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
    decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
    inc.total_odl_compra * fac.percentagem_facturada / 100))
    as valor_odlc,
    decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
    decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
    inc.total_pll_compra * fac.percentagem_facturada / 100))
    as valor_pllc,
    decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
    decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
    inc.total_transcricoes * fac.percentagem_facturada / 100))
    as valor_trc,
    decode(ops.estado, :WKFOPR_BOOKINGORDER_CANCELED, 0,
    decode(iif.tipo_facturacao, :BILLING_TYPE_ONLYCOMISSION, 0,
    inc.total_tx_compra * fac.percentagem_facturada / 100))
    as valor_txc,
    --nvl((select cfm.total_comprado
    -- from fin_custos_facturados_media cfm
    -- where cfm.id_factura = fac.id_factura and
    - -- cfm.id_op = ops.id_op
    -- ), 0) / opsorig.number_of_bought_insertions as custos_associados,
    0 as custos_associados,
    fac.iss as percentagem_iva,
    fac.percentagem_facturada,
    fac.currency_exchange as taxa_cambio,
    iif.associated_code as insertions_associated_code
    from fatura fac, item_fatura itf, insercao_itemfactura iif,
    insercao_comprada icorig, linha_comprada lcorig, item_av opsorig,
    med_bookingorder_finalbo opfin,
    insercao_comprada inc,
    linha_comprada lic, item_av ops,
    --veiculo vei,
    tipo_estado tef
    where fac.id_factura = itf.id_factura and
    itf.id_itemfactura = iif.id_itemfactura and
    iif.id_ic = icorig.id_ic and
    icorig.id_lc = lcorig.id_lc and
    lcorig.id_op = opsorig.id_op and
    opsorig.id_op = opfin.id_booking_order and
    opsorig.number_of_bought_insertions > 0 and
    opfin.id_final_booking_order = ops.id_op and
    -- ops.id_op = (
    -- select max(ops.id_op)
    -- from item_av ops
    -- start with ops.id_op = opsorig.id_op
    -- connect by prior ops.id_opsubstituicao = ops.id_op) and
    ops.id_op = lic.id_op and
    lic.seq = lcorig.seq and
    lic.id_op = inc.id_op and
    lic.id_lc = inc.id_lc and
    inc.data = icorig.data and
    inc.peca = icorig.peca and
    --opsorig.codveiculo = vei.codveiculo and
    fac.estado = tef.estado and
    fac.estado != 305 and
    ops.estado != 223 and
    iif.tipo_facturacao != 'SO_CA' and
    icorig.data between :dtBeginDate and :dtEndDate and
    (fac.codagenciafat = :iIdAgency or :iIdAgency is null);

  • Temporary tablespace and alert log

    If a temporary tablespace is actually filled and users get error when they are running some query, will it be updated in the alert log?
    Thanks

    It is ora-01652, and will be written to alert,
    Thanks

  • Temporary Tablespace Sizing and SNOTE 164925

    Hi All,
    I am facing a dilemma when I look into the temporary tablespace setting.
    I have gone thru the SNOTE 164925, for the sizing parameters of PSAPTEMP.
    There is a calculation on the note for selecting initial extent next extent etc.....
    My PSAPTEMP is locally managed and having default initial extent value of 1 MB but as per the calculation given on SNOTE 164925 solution section.
    But the point is in the How Can I check the specified value section on the same note it says....
    "As of Oracle 8i, SAP recommends using the assignment of locally managed
    temporary tablespaces (see Notes 659946 and 662900). This means that when
    problems with a 'dictionary managed' temporary tablespace occur, you should
    change to a 'locally managed' temporary tablespace instead of optimizing
    the settings of the 'dictionary managed' temporary tablespace."
    Now my question is whther I should still go with the default value or with the new values as per the formula given in the same note.
    I am using Oracle 10g behind SAPR3 4.6D
    Regards,
    Soumen

    Hello Soumen,
    to be honest - i don't really understand your question / problem.
    Just use locally managed temporary tablespace and set an uniform size.
    The values initial, next and pctincrease doesn't matter in this case. Set the uniform size to 1 - 5 MB.
    As you told us you are using oracle 10g .. just check the documenation:
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_7003.htm#CJAIDDDB
    Specify LOCAL if you want the tablespace to be locally managed. Locally managed tablespaces have some part of the tablespace set aside for a bitmap. This is the default for permanent tablespaces. Temporary tablespaces are always automatically created with locally managed extents.
    AUTOALLOCATE specifies that the tablespace is system managed. Users cannot specify an extent size. You cannot specify AUTOALLOCATE for a temporary tablespace.
    UNIFORM specifies that the tablespace is managed with uniform extents of SIZE bytes.The default SIZE is 1 megabyte. All extents of temporary tablespaces are of uniform size, so this keyword is optional for a temporary tablespace. However, you must specify UNIFORM in order to specify SIZE. You cannot specify UNIFORM for an undo tablespace.
    Restriction on Dictionary-managed Tablespaces
    You cannot specify DICTIONARY if the SYSTEM tablespace of the database is locally managed or if you have specified the temporary_tablespace_clause.
    Regards
    Stefan

Maybe you are looking for