Quaries using temp tablespace

Dear all,
Is there any script which gives the
list of quaries which heavily uses temp tablespace.Because my temp tablespace size is 32 gb , some times usage will go till 28gb , and it will reset to 0,
i need to know what quary it is running when the usage is at 28 gb.
Please help me regard this,
Regards,
Vamsi.

Check with below query.
SELECT
b.tablespace tablespace_name
, a.username username
, a.sid sid
, a.serial# serial_id
, b.contents contents
, b.segtype segtype
, b.extents extents
, b.blocks blocks
, (b.blocks * c.value) bytes
FROM
v$session a
, v$sort_usage b
, (select value from v$parameter
where name = 'db_block_size') c
WHERE
a.saddr = b.session_addr
========= output =======================
Tablespace Name Username SID Serial# Contents Segment Type Extents Blocks Bytes
TEMP SYS 128 9 TEMPORARY LOB_DATA 1 128 1,048,576
SYS 137 1 TEMPORARY DATA 1 128 1,048,576
sum 2 256 2,097,152

Similar Messages

  • Does rebuild of indexes uses temp tablespace or system tablespace?

    Does rebuild of indexes uses temp tablespace or system tablespace?
    If so why?

    If you combine the answers from Aman and Burleson, they cover most of the picture.
    When rebuilding an index, you may end up sorting a large amount of information. The sort may spill into the temporary tablespace - if you haven't configured your database and users properly, it is possible that the SYSTEM tablespace may be used for the temporary tablespace.
    As the new copy of the index is built, it has to be built in the right place (tablespace), and the space used to build it will be marked as a temporary segment as the build takes place. When the build is complete, this temporary segment will take on the name of the origrinal index, and the original index will be re-badged as a temporary segment and dropped. (Again, you might see temporary segments in the SYSTEM tablespace if the index was originally in, or was rebuilt into, the SYSTEM tablespace).
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk

  • Create index without using temp tablespace

    Hello,
    i have a great table with over 2.000.000.000 rows. Therefor i want to create an index on column1:
    CREATE INDEX "SCHEMA"."INDEX_TABLE1" ON "SCHEMA"."TABLE1" ("STR1")
    PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS NOCOMPRESS LOGGING
    STORAGE( INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
    TABLESPACE "USERS" ;
    If i execute this my temp tablespace will be used and if its full (max 20gb) the creation will be aborted.
    Where is my fault to create the index?
    With best

    bladepit wrote:
    The table description:
    CREATE TABLE "SCHEMA"."TABLE1"
    (     "STR1" VARCHAR2(20 BYTE),
         "STR2" VARCHAR2(20 BYTE),
         "VAL" NUMBER
    ) SEGMENT CREATION IMMEDIATE
    PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
    STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
    TABLESPACE "USERS" ;
    And i want to get the values like this:
    select str1,str2,val from SCHEMA.TABLE1 where str1 = 'TEST1' or str2 = 'TEST1'
    If this is the complete definition of the table, and if (str1, str2) are unique, and this really is the only way you use the table, then it looks as if your STRATEGIC move would be to rebuild the table as a hash partitioned IOT with something like 128 partitions. Since you probably can't do that in the short-term you could create a hash partitioned index on the table (assuming you have paid the partitioning licence) with enough partitions that you can create each one separately. Something like:
    SQL> create index t1_i1 on t1(n1, n2, n3) unusable global partition by hash (n1, n2) partitions 4;
    Index created.
    SQL> select index_name, partition_name from user_ind_partitions;
    INDEX_NAME           PARTITION_NAME
    T1_I1                SYS_P8713
    T1_I1                SYS_P8712
    T1_I1                SYS_P8711
    T1_I1                SYS_P8710
    4 rows selected.
    SQL> alter index t1_i1 rebuild partition sys_p8713 online;
    Index altered.
    -- repeat for each partition in turnRegards
    Jonathan Lewis

  • Temp tablespace use

    maintaining a cube via batch uses TEMP tablespace although the temp tablespace specified for the user is TEMP01. Olapsys has TEMP tablespace.
    How to force it to use TEMP01?
    Thanks.
    pxsheth.

    I don't have a good feeling for sizes of things (I'm a developer and don't typically see real-world data). Maybe someone else can give you stronger feedback. Also, you don't mention versions or anything. Sometimes that can be helpful.
    The relational world and the OLAP world are different in a number of ways. The relational world doing OLAP-type stuff (data warehousing) uses materialized views for summaries.
    Our stuff is closest in concept to that.
    Remember that in OLAP, you create cubes. The (virtual) size of the cube is the product of the lengths of the dimensions. This number can go up fast with the number of dimensions. Most data is sparse (not all dimension values are meaningful). It is important to properly define your cubes to take that into account. Rdbms tables are automatically sparse (they only contain the rows that exist). Saying a table has 67,000 rows gives a sense of size, but no clue to the dimensionality and thus the size.
    One GB of storage does not seem like a lot to me. You might get a hint at how much you need based on how far the build got. If it got most of the way, then its close. Otherwise you need a lot more. I might go up to 3-4 gig at a minimum, and consider doubling it a couple of times until you get a sense of how much you need. If you've gone back several times, and are only up to 1 gig, reconsider your size requests.
    Can some of you active users help in the sizing area?

  • TEMP tablespace increasing

    I have a problem with storage space of my default temporary table space.
    For my application, I specified the default table space as "DEFTBSPACE" with size 4000MB and temporary table space as "TEMP" with size 14486MB. Now, my usage of my temporary table space is increasing rapidly (Now, the used temp tablespace is 14485MB almost 99.99%). What could be the reason..? Is there any thing going into TEMP tablespace by mistake?.
    Please help.
    Reagrds,
    Satish.

    Can we deallocate manually the data file or a part of the datafile so that the usage space is reduced. What's the solution to reduce the usage space of this TEMP tablespace.If you bounce the db, you will get all used space.
    I heared, dropping and recreating the TEMP tablespace is the only the solution for this..??Is it true?
    Yes it is absolutely true.
    Create another temp tabelspace and set as default temp tablespace and drop the previous one. However, make sure no one is currently using that temp tablespace.
    The reason that you haven't get any result query v$sort_usge is that no one is using temp currently.
    You can also use v$tempseg_usage.
    Jaffar
    OCP DBA

  • TEMP tablespace 98%

    Hi,
    in 8.1.7 under Win 2003 (yes not supported). TEMP tablespace is used at 98%. Should we enlarge temp file or it is not necessary and Oracle manges it automatically ?
    Many thanks.

    > TEMP tablespace is used at 98%.
    Question.. what is better? A 50% used TEMP tablespace? And if you think so, why would it be "better"?
    Consider this for CPUs. Let's say you have 32 CPUs in your server. Only 2 are used at 100%. The remaining 30 CPUs are idle.
    What is good about this? Nothing much. And bad? What is especially bad is that you/your company paid loads of money for those 30 CPUs that are now sitting and doing absolutely nothing. What a waste!
    Back to temp space. Is a 50% temp space usage "better" than 98%? No.
    Temp space is a resource. A resource (CPU, space, memory, etc) is there to be used. If it is only used 50%, then the remaining 50% is a "waste". So in that respect, 98% is a LOT better than 50%. It seems that temp space has been correctly sized and that the vast majority of it, is being used.
    When is 98% (or 99% or a 100%) a problem? When there is not enough.. and more is still needed. And Oracle will inform you of that via error messages. (e.g. unable to extend temp space by x)
    This is only part of the resource utilisation puzzle of course. The other parts deal with how effectively the resources are being used. Is that 98% utilisation effective and efficient utilisation? (which needs you to look at HOW it is being used in order to determine WHY it is being used in order to answer these questions)

  • Unusual Temp Tablespace Growth

    Hi ,
    We have noticed unsual temp tablespace growth when concurrent users are accessing OLAP cube through BI Bean crosstabs.
    On an average 3 to 4 GB temp tablespace is consumed for each new user. OLAP cube has 7 dimensions and 1.2 million records and is fully precalculated.
    This causes the system to fail as a result of temp tablespace getting full.
    Can somebody please let me know what can be the root causes?.
    Thanks in advance.
    Harry

    Hi there,
    It is not unusual for OLAP queries to make significant use of temp tablespace. 3-4GB doesn't sound unreasonable to me. The actual amount used depends on factors such as the type of activity and the number of users.
    There is a brief description of how OLAP uses temp tablespace here :- http://download.oracle.com/docs/cd/B28359_01/olap.111/b28124/admin.htm#sthref442
    Note the lower than standard setting 'EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K' - if you are not already using this setting then you may find that it lowers temp space usage as the default setting is usually 1024K or even 4096K
    I hope this helps
    Stuart

  • When is temp tablespace been freed?

    Hi all
    our temp tablespace is 2GB, and it is always full(100% used)
    Could you tell me know
    1) when temp tablespace is freed?
    2) how to find out which users are using temp tablespace?
    Thanks

    1) Extents in the temp tablespace are only freed when the database is shut down. It is normal, and desirable, for your temp tablespace to show as 100% full. Allocating extents is an expensive operation. Once Oracle allocates an extent in temp, it manages them internally, re-using them as required.
    2) You can use v$sort_usage to see who is using temp tablespace. However, do not be surprised if noone is using temp even if it is 100% full.
    HTH
    John

  • Oracle 9i TEMP tablespace backup problem using RMAN!

    Oracle8/8i whole backup is ok for our backup software(using RMAN without RC database), but for Oracle 9i, I get following error messages when backing up temp tablespace.
    1. RMAN-20202: tablespace not found in the recovery catalog
    2. RMAN-06019: could not translate tablespace name "TEMP"
    I check some views of Oracle9i, and know some changes happen for temp tablespace in 9i, but how to deal with this problem. Any idea, please!

    In 9i RMAN does not restore temporary datafiles. Instead, you should create them after your restore. I believe that Oracle is going to make a change to this in the next release of 9i and have RMAN create the temporary files. You can view the temporary datafiles @ v$tempfile.
    I believe RMAN doesn't restore temporary files because they are locally managed and not in the control files. RMAN reads the controlfile of the target database to obtain info about backups, datafiles, etc.
    Hope this helps.

  • How to exclude UNDO and temp tablespace using monitoring template

    hi,
    as per MOS note id 816920.1 undo and temp tablespace is excluded from monitoring starting version 11G onwards.It says that thresholds will need to be explicitly set if undo and temp needs to be monitored
    we have grid 12C implemented now with monitoring templates which sets thresholds for all tablespaces. does it apply that thresholds to undo and temp too?? we are receiving alerts for undo and temp tablespaces and we wish to disable them. We have undo tablespaces with different names in many databases as per naming conventions for that line of business.
    How can i exclude undo and temp tablespaces from monitoring using grid 12C monitoring templates. is there a way through templates where i can set thresholds of permanent tablespaces only???

    In EM12c, go to the 'Enterprise' menu, then 'Job', then 'Library'. There should be an out-of-the-box job called "DISABLE TABLESPACE USED (%) ALERTS FOR UNDO AND TEMP TABLESPACES" that you can run against your database targets, and that job will disable database-generated alerts.
    If a previous admin has set up EM12c-generated alerts for undo and temp, then yes, a monitoring template will take care of disabling them. Either remove those alerts from the existing monitoring template and apply them to your targets, or create a new monitoring template based on one database's current settings, remove those warning/critical thresholds for your undo and temp tablespaces, and apply it to your targets.

  • Temp Tablespace Goes Berzerk using XMLGEN

    The following procedure seems to maxout my temporary tablespace (2G!!!!)
    I use this procedure to pump XML to a client given a sql statement and a few parameters.
    I am using the plxmlparser_v1_0_2 release and the XSU12_ver1_2_1 release.
    There seems to be some discussion concerning this in other threads but no soloution seems to be forth coming. Any advice?
    PS I am also having a problem with XMLGEN returning XML datasets >90k. Methinks the two issues are related.
    Regards
    James Crockart
    [email protected]
    procedure createDynamicXML(
    sql_string varchar2,
    result_name varchar2 default 'results',
    row_name varchar2 default 'row',
    error_name varchar2 default 'error_results',
    rowid_name varchar2 default null,
    rowid_col varchar2 default null,
    useLowerCase boolean default true,
    useNullAttrib boolean default false)
    is
    no_sql exception;
    --XML Variables
    xmlString CLOB := null;
    amount integer:= 255;
    position integer := 1;
    charString varchar2(255);
    begin
    if sql_string is null then
    raise no_sql;
    end if;
    --Set XML preferences
    xmlgen.resetOptions;
    xmlgen.setErrorTag(error_name);
    xmlgen.setRowsetTag(result_name);
    xmlgen.setRowTag(row_name);
    if rowid_name is not null then
    xmlgen.setRowIdAttrName(rowid_name);
    end if;
    if rowid_col is not null then
    xmlgen.setRowIdColumn(rowid_col);
    end if;
    if useLowerCase then
    xmlgen.useLowerCaseTagNames();
    end if;
    xmlgen.useNullAttributeIndicator(useNullAttrib);
    --Set mime header
    --owa_util.mime_header('text/xml');
    --Generate XML
    xmlString := xmlgen.getXML(sql_string);
    --Output XML
    dbms_lob.open(xmlString,DBMS_LOB.LOB_READONLY);
    loop
    dbms_lob.read(xmlString,amount,position,charString);
    htp.prn(charString);
    position := position + amount;
    end loop;
    dbms_lob.close(xmlString);
    dbms_lob.freetemporary(xmlString);
    exception
    when no_data_found then
    dbms_lob.close(xmlString);
    dbms_lob.freetemporary(xmlString);
    end createDynamicXML;
    null

    The user the xml sdk was installed in and its privs is:
    CREATE USER "XML" PROFILE "DEFAULT"
    DEFAULT TABLESPACE "USERS"
    TEMPORARY TABLESPACE "TEMP"
    ACCOUNT UNLOCK;
    grant connect to XML;
    grant resource to XML;
    grant javauserpriv to XML;
    grant javasyspriv to XML;
    I suppose I can give the XML user it's own temp tablespace to save the rest of the production environment from going down.
    But does not solve the problem :(
    -James
    null

  • Which temp tablespace will used during the import (impdp) ?

    Oracle version : 11.2.0.3 on Solaris
    We have created an empty schema called MLDT_FN and set its default temporary tablespace as TEMP_MLDT. We usually use SYSTEM user to do exports (expdp) and imports (impdp)
    During a schema level (or table level) import to MLDT_FN schema, which temporary tablespace will be used ?
    Will it be
    the default temporary tablespace of SYSTEM user which runs this impdp job
    or
    the default temporary tablespace of the newly created MLDT_FN schema which is being to imported to

    It will use default temp tablespace of schema.

  • Who is using all Temp Tablespace

    Hi,
    Temp TS is 80% full and I want to see, who is using this lot space ?
    It might be an uncommited, not rolled back statement, but what session is it ?
    v$sort_usage does not show any result.
    Documentation does not recommend Quota on Temp TS, since temp-objects belong to sys.
    How to limit a users comsumtion of temp TS for bad statements ?
    Thanks for any tip Lao De

    I believe it is normal for a well-used temporary tablespace to have this level of usage. Once space has been allocated in a temporary tablespace the system manages it. This behaviour should show up in the DBA_FREE_SPACE view - all the extents in that tablespace will be marked as FREE.
    If you "free up" - release - space in the temporary tablespace you are in effect asking the database to do additional space allocation the next time a sort has to be done. All you've acheived is added to the amount of latching required to process your sorts. Forget about it.
    The fact that V$SORT_USAGE is empty shows you that nobody is doing any sorts at the moment (it's a dynamic view).
    ORA-03217: invalid option for alter of TEMPORARY TABLESPACE
    This might happend becaue it's local managed ?Probably. Uniform tablespaces must have PCTINCREASE of zero (otherwise they ain't uniform).
    Cheers, APC

  • Generating xml using PL/SQL taking a lot of space in TEMP tablespace

    We wrote a stored procedure that generate xml which will be stored in a CLOB column. Environment is 9i on Windows 2003.
    The gnerated xml is about 800K. In the procedure there is one big cursor that will retrieve 200 records of 55 fields and many other small dynamic cursors that open and close here and there. The fields are pretty small. Biggest ones are like varchar2(30). The query for the big cursor does using union and need sorting.
    Can anyone explain why it takes about 15G of TEMP tablespace to accomplish this job and is there a way to avoid this?

    The version is Enterprise Edition 9.2.0.1.0.
    Below is the query.
    SELECT ROWNUM + ( SELECT NVL(MAX(WQX_ACTIVITY_GEN_ID), 0) FROM WQX_ACTIVITY ) as WQX_ACTIVITY_GEN_ID
         , A.ACTIVITYIDENTIFIER2            as ACTIVITY_IDENTIFIER
         , (SELECT MAX(O.ORGANIZATION_NAME) FROM SYS_ORGANIZATION O WHERE O.ORGANIZATION_ID = 111242)  as ORGANIZATION_NAME
         , (SELECT MAX(P.PROJECT_IDENTIFIER) FROM SYS_PROJECT P WHERE P.PROJECT_ID = 111242) as PROJECT_IDENTIFIER
         , A.ACTIVITYTYPECODE               as ACTIVITY_TYPE_CD
         , A.ActivityMediaName              as ACTIVITY_MEDIA_NAME
         , A.ActivityMediaSubDivisionName   as MEDIA_SUB_DIVISION
         , A.ActivityStartDate              as ACTIVITY_START_DATE
         , CASE WHEN A.ActivityStartTime is not NULL THEN
                     substr(A.ActivityStartTime,1,2)||':'||substr(A.ActivityStartTime,3,2)||':00'
                WHEN A.ActivityStartTime is NULL THEN ''
           END as ACTIVITY_START_TIME
    --   , substr(A.ActivityStartTime,1,2)||':'||substr(A.ActivityStartTime,3,2)||':00' as ACTIVITY_START_TIME
         , A.ACTIVITYENDDATE                as ACTIVITY_END_DATE
         , CASE WHEN A.ACTIVITYENDTIME is not NULL THEN
                     substr(A.ACTIVITYENDTIME,1,2)||':'||substr(A.ACTIVITYENDTIME,3,2)||':00'
                WHEN A.ACTIVITYENDTIME is NULL THEN ''
           END as ACTIVITY_END_TIME
    --   , substr(A.ACTIVITYENDTIME,1,2)||':'||substr(A.ACTIVITYENDTIME,3,2)||':00' as ACTIVITY_END_TIME
         , A.TIMEZONECODE1                  as TIME_ZONE_CD
         , A.ActivityRelativeDepthName      as RELATIVE_DEPTH_NAME
         , NULL                             as DEPTH_HEIGHT_MEASURE
         , NULL                             as DEPTH_HEIGHT_UNIT
         , 111242              as MONITORING_LOC_ID
         , A.ACTIVITYCOMMENTTEXT            as COMMENT_
         , A.SamplerName                    as SAMPLER_NAME
         , A.ActivityArea                   as ACTIVITY_AREA
         , A.ReportingRound                 as REPORTING_ROUND
         , A.SamplePanel                    as SAMPLEPANEL
         , A.DataIncludedinReport           as DATA_INCLUDED_IN_REPORT
         , A.FlowStatusIndicator            as FLOW_STATUS_IND
         , A.SampleChainOfCustody           as SAMPLE_COC
         , A.ActivitySeason                 as ACTIVITY_SEASON
         , A.RunoffImpact                   as RUNOFF_IMPACT
         , (111242)            as MONI_LOC_ID
         , (SELECT MAX(B.MONI_LOC_IDENTIFIER) FROM WQX_MONITORING_LOC B WHERE B.MONI_LOC_IDENTIFIER = A.MONITORINGLOCATIONIDENTIFIER) as MONI_LOC_IDENTIFIER
         , 111242                     as PROJECT_ID
         , NULL                             as BIO_ASSEMB_SAMPLED_NAME
         , NULL                             as BIO_TOXICITY_TEST_TYPE
         , A.METHODIDENTIFIER1              as SAMPLE_COLLECT_METHOD_IDENTIFI
         , A.METHODIDENTIFIERCONTEXT1       as SAMPLE_COLLECT_METHOD_CONTEXT
         , A.METHODNAME1                    as SAMPLE_COLLECT_METHOD_NAME
         , NULL                             as SAMPLE_COLLECT_QUALIFIER_TYPE
         , A.METHODDESCRIPTIONTEXT1         as SAMPLE_COLLECT_DESC
         , A.SampleCollectionEquipmentName  as SAMPLE_COLLECT_EQUIP_NAME
         , A.SAMPLECOLLECTIONEQUIPMENTTXT   as SAMPLE_COLLECT_EQUIP_DESC
         , A.METHODNAME2                    as SAMPLE_PREP_METHOD_NAME
         , A.METHODIDENTIFIER2              as SAMPLE_PREP_METHOD_IDENTIFIER
         , A.METHODIDENTIFIERCONTEXT2       as SAMPLE_PREP_METHOD_CONTEXT
         , NULL                             as SAMPLE_PREP_QUALIFIER_TYPE
         , A.METHODDESCRIPTIONTEXT1         as SAMPLE_PREP_DESC
         , A.SampleContainerTypeName        as SAMPLE_CONTAINER_TYPE
         , A.SampleContainerColorName       as SAMPLE_CONTAINER_COLOR
         , A.ChemicalPreservativeUsedName   as CHEM_PRESERVATIVE_USED
         , A.ThermalPreservativeUsedName    as THERMAL_PRESERVATIVE_USED
         , A.SAMPLETRANSPORTSTORAGEDESC     as SAMPLE_TRANS_STORAGE
         , A.AnalysisStartTime              as AnalysisStartTime
         , A.AnalysisEndTime                as AnalysisEndTime
         , A.MethodSpeciationName           as MethodSpeciationName
         , A.ResultLaboratoryCommentCode    as ResultLaboratoryCommentCode
         , A.UnidentifiedSpeciesIdentifier  as UnidentifiedSpeciesIdentifier
      FROM TMP_CHEMACTIVITYRESULTS A
    WHERE A.SUBMISSION_ID = 111242
       AND A.ACTIVITYIDENTIFIER2 NOT IN
         ( SELECT ACTIVITY_IDENTIFIER FROM WQX_ACTIVITY )
    UNION
    SELECT X.WQX_ACTIVITY_GEN_ID                                             as WQX_ACTIVITY_GEN_ID
         , A.ACTIVITYIDENTIFIER2                                             as ACTIVITY_IDENTIFIER
         , (SELECT MAX(O.ORGANIZATION_NAME) FROM SYS_ORGANIZATION O WHERE O.ORGANIZATION_ID = 111242)  as ORGANIZATION_NAME
         , (SELECT MAX(P.PROJECT_IDENTIFIER) FROM SYS_PROJECT P WHERE P.PROJECT_ID = 111242) as PROJECT_IDENTIFIER
         , NVL(A.ACTIVITYTYPECODE, (SELECT MAX(ACTYP_CD) FROM REF_ACTIVITY_TYPE WHERE TO_CHAR(ACTYP_UID) = TO_CHAR(X.ACTIVITY_TYPE_CD))) as ACTIVITY_TYPE_CD
         , NVL(A.ActivityMediaName, X.ACTIVITY_MEDIA_NAME)                   as ACTIVITY_MEDIA_NAME
         , NVL(A.ActivityMediaSubDivisionName, X.MEDIA_SUB_DIVISION)         as MEDIA_SUB_DIVISION
         , NVL(A.ActivityStartDate, TO_CHAR(X.ACTIVITY_START_DTTM, 'YYYY-MM-DD')) as ACTIVITY_START_DATE
         , CASE WHEN A.ActivityStartTime is not NULL THEN
                     substr(A.ActivityStartTime,1,2)||':'||substr(A.ActivityStartTime,3,2)||':00'
                WHEN A.ActivityStartTime is NULL THEN ''
           END as ACTIVITY_START_TIME
    --   , NVL((substr(A.ActivityStartTime,1,2)||':'||substr(A.ActivityStartTime,3,2)||':00'), TO_CHAR(X.ACTIVITY_START_DTTM, 'HH24:MI:SS')) as ACTIVITY_START_TIME
         , NVL(A.ACTIVITYENDDATE, TO_CHAR(X.ACTIVITY_END_DTTM, 'YYYY-MM-DD'))     as ACTIVITY_END_DATE
         , NVL(A.ACTIVITYENDDATE, TO_CHAR(X.ACTIVITY_END_DTTM, 'HH24:MI:SS'))     as ACTIVITY_END_TIME
         , NVL(A.TIMEZONECODE1, X.TIME_ZONE_CD)                              as TIME_ZONE_CD
         , NVL(A.ActivityRelativeDepthName, X.RELATIVE_DEPTH_NAME)           as RELATIVE_DEPTH_NAME
         , X.DEPTH_HEIGHT_MEASURE                                            as DEPTH_HEIGHT_MEASURE
         , X.DEPTH_HEIGHT_UNIT                                               as DEPTH_HEIGHT_UNIT
         , NVL(111242, X.MONITORING_LOC_ID)                     as MONITORING_LOC_ID
         , NVL(A.ACTIVITYCOMMENTTEXT, X.COMMENT_)                            as COMMENT_
         , NVL(A.SamplerName, X.SAMPLER_NAME)                                as SAMPLER_NAME
         , NVL(A.ActivityArea, X.ACTIVITY_AREA)                              as ACTIVITY_AREA
         , NVL(A.ReportingRound, X.REPORTING_ROUND)                          as REPORTING_ROUND
         , NVL(A.SamplePanel, X.SAMPLEPANEL)                                 as SAMPLEPANEL
         , NVL(A.DataIncludedinReport, X.DATA_INCLUDED_IN_REPORT)            as DATA_INCLUDED_IN_REPORT
         , NVL(A.FlowStatusIndicator, X.FLOW_STATUS_IND)                     as FLOW_STATUS_IND
         , NVL(A.SampleChainOfCustody, X.SAMPLE_COC)                         as SAMPLE_COC
         , NVL(A.ActivitySeason, X.ACTIVITY_SEASON)                          as ACTIVITY_SEASON
         , NVL(A.RunoffImpact, X.RUNOFF_IMPACT)                              as RUNOFF_IMPACT
         , (111242)                                             as MONI_LOC_ID
         , (SELECT MAX(B.MONI_LOC_IDENTIFIER) FROM WQX_MONITORING_LOC B WHERE B.MONI_LOC_IDENTIFIER = A.MONITORINGLOCATIONIDENTIFIER) as MONI_LOC_IDENTIFIER
         , 111242                                                      as PROJECT_ID
         , X.BIO_ASSEMB_SAMPLED_NAME                                         as BIO_ASSEMB_SAMPLED_NAME
         , X.BIO_TOXICITY_TEST_TYPE                                          as BIO_TOXICITY_TEST_TYPE
         , NVL(A.METHODIDENTIFIER1, X.SAMPLE_COLLECT_METHOD_IDENTIFI)        as SAMPLE_COLLECT_METHOD_IDENTIFI
         , NVL(A.METHODIDENTIFIERCONTEXT1, X.SAMPLE_COLLECT_METHOD_CONTEXT)  as SAMPLE_COLLECT_METHOD_CONTEXT
         , X.SAMPLE_COLLECT_METHOD_NAME                                      as SAMPLE_COLLECT_METHOD_NAME
         , X.SAMPLE_COLLECT_QUALIFIER_TYPE                                   as SAMPLE_COLLECT_QUALIFIER_TYPE
         , NVL(A.METHODDESCRIPTIONTEXT1, X.SAMPLE_COLLECT_DESC)              as SAMPLE_COLLECT_DESC
         , NVL(A.SampleCollectionEquipmentName, X.SAMPLE_COLLECT_EQUIP_NAME) as SAMPLE_COLLECT_EQUIP_NAME
         , NVL(A.SAMPLECOLLECTIONEQUIPMENTTXT, X.SAMPLE_COLLECT_EQUIP_DESC)  as SAMPLE_COLLECT_EQUIP_DESC
         , NVL(A.METHODNAME2, X.SAMPLE_PREP_METHOD_NAME)                     as SAMPLE_PREP_METHOD_NAME
         , NVL(A.METHODIDENTIFIER2, X.SAMPLE_PREP_METHOD_IDENTIFIER)         as SAMPLE_PREP_METHOD_IDENTIFIER
         , NVL(A.METHODIDENTIFIERCONTEXT2, X.SAMPLE_PREP_METHOD_CONTEXT)     as SAMPLE_PREP_METHOD_CONTEXT
         , X.SAMPLE_PREP_QUALIFIER_TYPE                                      as SAMPLE_PREP_QUALIFIER_TYPE
         , NVL(A.METHODDESCRIPTIONTEXT1, X.SAMPLE_PREP_DESC)                 as SAMPLE_PREP_DESC
         , NVL(A.SampleContainerTypeName, X.SAMPLE_CONTAINER_TYPE)           as SAMPLE_CONTAINER_TYPE
         , NVL(A.SampleContainerColorName, X.SAMPLE_CONTAINER_COLOR)         as SAMPLE_CONTAINER_COLOR
         , NVL(A.ChemicalPreservativeUsedName, X.CHEM_PRESERVATIVE_USED)     as CHEM_PRESERVATIVE_USED
         , NVL(A.ThermalPreservativeUsedName, X.THERMAL_PRESERVATIVE_USED)   as THERMAL_PRESERVATIVE_USED
         , NVL(A.SAMPLETRANSPORTSTORAGEDESC, X.SAMPLE_TRANS_STORAGE)         as SAMPLE_TRANS_STORAGE
         , NVL(A.AnalysisStartTime, '')                                      as AnalysisStartTime
         , NVL(A.AnalysisEndTime, '')                                        as AnalysisEndTime
         , NVL(A.MethodSpeciationName, '')                                   as MethodSpeciationName
         , NVL(A.ResultLaboratoryCommentCode, '')                            as ResultLaboratoryCommentCode
         , NVL(A.UnidentifiedSpeciesIdentifier, '')                          as UnidentifiedSpeciesIdentifier
      FROM TMP_CHEMACTIVITYRESULTS A
           JOIN WQX_ACTIVITY X ON A.ACTIVITYIDENTIFIER2 = X.ACTIVITY_IDENTIFIER
    WHERE A.SUBMISSION_ID = 111242;

  • Query using large(in GB) temp tablespace, how to tune it?

    Hi,
    Below query is using large Temp tablespace, please guide for tuning this query so that it can use minimal temp space.
    SELECT DISTINCT cust_alt.cust_acct_alt_id, cust_alt.cust_acct_alt_id_type_cd,
                    trans.legal_entity_id, trans.exchange_id,
                    trans.stamp_update_dtime, trans.book_alt_id,
                    trans_alt.trans_alt_id, trans_alt.trans_alt_vers_id,
                    trans_alt.src_sys_short_name, event.trans_event_sequence_id,
                    event.trans_event_type_cd, prod_alt.product_alt_id,
                    prod_alt.product_alt_id_type_cd, trans.buy_sell_cd,
                    trans.trade_date, item.setlmt_date, item.trans_price_amt,
                    item.price_yield_ind, item.trans_dirty_price_amt,
                    item.trans_qty, item.trans_item_type_cd,
                    event.trans_event_dtime,
                    DECODE (extnn.confirm_generation_elig_ind,
                            'Y', 'In Progress',
                            NULL, 'Not Processed',
                            'Confirm Ineligible'
                           ) confirm_status,
                    event_ref.trans_event_type_desc
               FROM ods_trans_event_type_ref event_ref,
                    ods_trans_type_ref trans_type,
                    ods_cust_acct_alt_id cust_alt,
                    ods_product_alt_id prod_alt,
                    ods_trans_item item,
                    ods_trans_alt_id trans_alt,
                    ods_trans trans,
                    ods_trans_extnn extnn,
                    ods_trans_event event
              WHERE event_ref.trans_event_type_cd = event.trans_event_type_cd
                AND trans_type.trans_type_id = trans.trans_type_id
                AND prod_alt.product_id = trans.product_id
                AND cust_alt.cust_acct_id = trans.cust_acct_id
                AND item.trans_vers_id = trans.trans_vers_id
                AND item.trans_id = trans.trans_id
                AND extnn.trans_vers_id(+) = trans.trans_vers_id
                AND extnn.trans_id(+) = trans.trans_id
                AND trans_alt.trans_link_reason_cd = 'FOID'
                AND trans_alt.trans_vers_id = trans.trans_vers_id
                AND trans_alt.trans_id = trans.trans_id
                AND trans.trans_vers_id = event.trans_vers_id
                AND trans.trans_id = event.trans_id
                AND item.trans_item_type_cd IN ('MAIN', '1', '2')
                AND cust_alt.cust_acct_alt_id != 'BOOKTOBOOK'
             order by trans_alt.trans_alt_id, event.trans_event_sequence_idThe Explain for this query is
    | Id  | Operation                                      | Name                        | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                          |                             |    79 | 23384 |  1404   (1)| 00:00:17 |
    |   1 |  HASH UNIQUE                                   |                             |    79 | 23384 |  1404   (1)| 00:00:17 |
    |*  2 |   TABLE ACCESS BY INDEX ROWID        | ODS_TRANS_ITEM       |     1 |    53 |     4   (0)| 00:00:01 |
    |   3 |    NESTED LOOPS                                |                             |    79 | 23384 |  1403   (1)| 00:00:17 |
    |   4 |     NESTED LOOPS OUTER                    |                             |    73 | 17739 |  1144   (1)| 00:00:14 |
    |   5 |      NESTED LOOPS                              |                             |    73 | 16717 |   965   (0)| 00:00:12 |
    |   6 |       NESTED LOOPS                             |                             |    73 | 15476 |   819   (0)| 00:00:10 |
    |   7 |        NESTED LOOPS                            |                             |    73 | 14089 |   673   (0)| 00:00:09 |
    |   8 |         NESTED LOOPS                           |                             |    73 | 10439 |   672   (0)| 00:00:09 |
    |   9 |          NESTED LOOPS                          |                             |    90 |  9810 |   312   (0)| 00:00:04 |
    |* 10 |           TABLE ACCESS BY INDEX ROWID| ODS_TRANS_ALT_ID            |    92 |  3680 |    52   (0)| 00:00:01 |
    |* 11 |            INDEX RANGE SCAN               | ODS_TRANS_ALT_ID_X1         |   119 |       |     5   (0)| 00:00:01 |
    |  12 |           TABLE ACCESS BY INDEX ROWID| ODS_TRANS                   |     1 |    69 |     3   (0)| 00:00:01 |
    |* 13 |            INDEX UNIQUE SCAN              | ODS_TRANS_PK                |     1 |       |     2   (0)| 00:00:01 |
    |  14 |          TABLE ACCESS BY INDEX ROWID | ODS_TRANS_EVENT             |     1 |    34 |     4   (0)| 00:00:01 |
    |* 15 |           INDEX RANGE SCAN                | ODS_TRANS_EVENT_PK          |     1 |       |     3   (0)| 00:00:01 |
    |  16 |         TABLE ACCESS BY INDEX ROWID  | ODS_TRANS_EVENT_TYPE_REF    |     1 |    50 |     1   (0)| 00:00:01 |
    |* 17 |          INDEX UNIQUE SCAN                | ODS_TRANS_EVENT_TYPE_REF_PK |     1 |       |     0   (0)| 00:00:01 |
    |  18 |        TABLE ACCESS BY INDEX ROWID   | ODS_PRODUCT_ALT_ID          |     1 |    19 |     2   (0)| 00:00:01 |
    |* 19 |         INDEX RANGE SCAN                  | ODS_PRODUCT_ALT_ID_PK       |     1 |       |     1   (0)| 00:00:01 |
    |* 20 |       TABLE ACCESS BY INDEX ROWID    | ODS_CUST_ACCT_ALT_ID        |     1 |    17 |     2   (0)| 00:00:01 |
    |* 21 |        INDEX RANGE SCAN                   | ODS_CUST_ACCT_ALT_ID_PK     |     1 |       |     1   (0)| 00:00:01 |
    |  22 |      TABLE ACCESS BY INDEX ROWID     | ODS_TRANS_EXTNN             |     1 |    14 |     3   (0)| 00:00:01 |
    |* 23 |       INDEX UNIQUE SCAN                   | SYS_C0026927                |     1 |       |     2   (0)| 00:00:01 |
    |* 24 |     INDEX RANGE SCAN                      | ODS_TRANS_ITEM_PK           |     1 |       |     3   (0)| 00:00:01 |
    --------------------------------------------------------------------------------------------------------------------Cant avoid the order by and distinct clauses. Cant avoid Outer joins. Indexes are used properly.

    Just to add on to Mark's excellent points--
    1) The Oracle optimizer is estimating that your query is only going to return 79 rows. If it is using a great deal of TEMP space, that estimate would seem to be wildly incorrect which implies that you have a problem with your statistics.
    2) Are you certain that you need the DISTINCT? Lots of people either throw DISTINCT clauses into their queries "just in case" or throw in a distinct when they are unexpectedly getting duplicate rows because they are missing a join condition. If that's the case here, removing the DISTINCT and figuring out which join condition is missing (if applicable) would cause much less TEMP space to be used.
    Justin

Maybe you are looking for