Temporary tablespace-Problem

Hi,
How to view the temporary tablespace usage?
How to deallocate the used temporary tablespace segments/ resize temporary tablespace?
I am running a query which is consuming 4GB temporary tablespace and failing.
pga_aggregate_traget=500m;
oracle -9.2.0.1.0
OS:Windows 2003
How to solve this?
regards
Mathew

Hi,
We are using the following View and it is fetchhing 46,56,00,000 rows.
PGA=500m
While running the query temporary tablespace is growing upto 4GB and query is failling.
CREATE OR REPLACE FORCE VIEW MHUBADMIN.LOAN_PIPELINE_VIEW
(LOAN_ID, USER_ID, FIRST_NAME, LAST_NAME, BORROWER_NAME,
SSN, USERNAME, SELLERLOANNUMBER, LOANNUMBER, LOANAMOUNT,
STATUS_DESC, LOAN_TYPE, LOCK_EXPIRE_DATE, ORG_NAME, ORG_PARENT_ID,
ORG_CHILD_ID, NO_CASCADE_FLAG, PRODUCT_NAME, INT_RATE, UPDATE_DATE,
UPDATE_DATE_STR, CURRENT_DATE, LOWER_FIRST_NAME, LOWER_LAST_NAME, LOWER_SSN,
LOWER_STATUS_DESC, STATUS_ID, AMORTIZATION_TYPE, STREET1, LOCK_EXTEN_EXPIR_DATE,
RELOCK_EXPIR_DATE, LOCK_RELOCK_COUNT, UNDERWRITE_FLAG, RECENT_EXPIR_DATE, STATUS_DATE)
AS
SELECT
LOAN.loan_id,
LOAN.user_id,
PERSON.first_name,
PERSON.last_name,
PERSON.last_name||', '||PERSON.first_name AS Borrower_Name,
PERSON.ssn,
HUBUSER.username,
LOAN.sellerloannumber,
LOAN.loannumber,
LOAN.loanamount,
STATUS.status_desc,
LOAN.loan_type,
PRICE.lock_expire_date,
ORGANIZATION.org_name,
BUSINESS_RELATIONSHIP.org_parent_id,
BUSINESS_RELATIONSHIP.org_child_id,
BUSINESS_RELATIONSHIP.no_cascade_flag,
product_name,
PRICE.final_rate,
LOAN.update_date,
TO_CHAR (LOAN.update_date,
'MM/DD/YYYY HH:MI:SS AM') update_date_str,
sysdate,
LOWER (PERSON.first_name),
LOWER (PERSON.last_name),
LOWER (PERSON.ssn),
LOWER (STATUS.status_desc),
STATUS.status_id,
LOAN.amortization_type,
ADDRESS.STREET1,
PRICE.LOCK_EXTEN_EXPIR_DATE,
PRICE.RELOCK_EXPIR_DATE,
LOAN.LOCK_RELOCK_COUNT,
LOAN.UNDERWRITE_FLAG,
decode (status.STATUS_ID,
22, PRICE.LOCK_EXTEN_EXPIR_DATE,
          23, PRICE.lock_expire_date,
          13, PRICE.lock_expire_date,
          24, PRICE.RELOCK_EXPIR_DATE,
          PRICE.lock_expire_date) RECENT_EXPIR_DATE,
          LOAN_STATUS_HISTORY.STATUS_DATE
FROM
LOAN,
HUBUSER,
ORGANIZATION,
BUSINESS_RELATIONSHIP,
BORROWER,
PERSON,
STATUS,
PRICE,
product,
PROPERTY,
ADDRESS,
LOAN_STATUS_HISTORY
WHERE
ORGANIZATION.org_id = BUSINESS_RELATIONSHIP.org_child_id AND
LOAN.org_id = BUSINESS_RELATIONSHIP.org_child_id AND
LOAN.loan_id = BORROWER.loan_id AND
LOAN.registration_loan_status_id = STATUS.status_id AND
LOAN.price_id = PRICE.price_id AND
BORROWER.primaryborrower = 'T' AND
PERSON.person_id = BORROWER.person_id AND
LOAN.product_id = product.product_id AND
LOAN.PROPERTY_ID = PROPERTY.PROPERTY_ID AND
PROPERTY.ADDRESS_ID = ADDRESS.ADDRESS_ID AND
LOAN.user_id = HUBUSER.user_id (+);
Any one know how to tune this query?
regards
Mathew

Similar Messages

  • Problem with Temporary Tablespace in 8i

    Hello friends,
    I have the 8.1.7.4 version, with a 18GB Temporary Tablespace.
    An external process (from Datawarehouse tool) is making a query over a 10.000.000 records.
    It appeared the error:
    SQL error 1652 occurred when accessing table XXX
    It's supposed it occurs due to temporary tablespace is full
    DWH tool makes different "big" queries.. but.. are the enough to grow up to 18GB???
    Any idea?
    [It's not possible to change sort_area_size or any other parameter in init.ora]
    Apart form this: Which would be the best way to clean this temporary tablespace?
    Thanks

    Jose, I think you are right and the problem is that Oracle was unable to obtain additional temp tablespace extents for the query since you mention the problem occurred on a query.
    The question is was the lack of free temp due to the combination of tasks running at the time or is the plan for the query in question the issue?
    If you resubmit the query does the 01652 error re-occur. If it does then I suggest grabbing a copy of the contents of v$sort_usage and resubmitting the query. Monitor the sort usage every 30 seconds, minute, or several minutes depending on how long the query runs before returning the error. This will give you an idea of how much temp space the query wants and maybe why (see following).
    Also get the explain plan and see where temp is being used. One query may use multiple allocations of temp space at a time such as one chunk to support hash joins, one to support aggregation, and one to support order by so the total sort space necessary may be a lot more than you would think just based on the result set size.
    In the case where the query in question is using too much temp you have to ask if the plan is the issue or if you really need more temp. When the plan is not efficient then converting to using nested loops over hash joins might be one way to eliminate excess temp space usage.
    HTH -- Mark D Powell --

  • Problem shrinking a temporary tablespace

    I have a temporary tablespace in 10.1.0.3 I need to shrink. I need to shrink the database.
    1. I change all users that user that temporary tablespace to a new temporary tablespace
    2. Tried to shrink it but got
    ERROR at line 1:
    ORA-03297: file contains used data beyond requested RESIZE value
    I take this to mean there are open transactions using this temporary tablespace? How do I find who currently is using this temporary tablespace? do i need to kill those sessions?

    Hi,
    There may be one issue, if there are transactions open and the old temp tbsp is currently used (for sorting, etc), you will not be able to drop it without crashing the sessions. It will be nice if you check which user sessions are using the old temp and either gracefully abort the session (by asking them) or wait until they are done. Otherwise you may create the new temp and make it default (tablespace as well as user's temp tablespace name) so that no new user session will connect to the old temp and you can monitor it to stop its usage.
    Thanks

  • Problem on temporary tablespace

    Hi all,
    I created the temporary tablespace with following command;
    create temporary tablespace rbitemp
    tempfile 'E:\ORACLE\ORADATA\RBI\RBItemp.tmp' size 100m
    autoextend on next 1m maxsize 2000m;
    while running the query i received the error
    ORA-01652: unable to extend temp segment by 256 in tablespace RBITEMP
    Then I add tempfile , now still I receiving the same error.
    Thanks in advance.

    Hi,
    This tablespace is only for rbi user.
    query is :
    select distinct trim(wrk.bd_alcd) as ALCD, wrk.bd_typecd as TypeCD, wrk.bd_forcd as FORCD, wrk.bd_curcd as CURCD,
    wrk.bd_councd as COUNCD, wrk.bd_sectcd as SECCD,
    wrk.bd_matcd as MATCD, wrk.bd_c_u_cd as C_U_CD, wrk.bd_s_u_cd as S_U_CD,
    0 as Org_FCBal,0 as ORG_Bal,case when wrk.bd_type='O' then wrk.bd_fc_bal else 0 end as Main_FCBal,
    case when wrk.bd_type='O' then (wrk.bd_fc_bal * nvl(exchg.cer_exchangerate, 1)) else 0 end as main_Bal,
    wrk.bd_rs_int,wrk.bd_rs_bal,wrk.bd_fc_int,wrk.bd_fc_bal,
    ' ' as TrackChangs
    from ibs_work_bankdata wrk inner join ibs_org_bankdata org ON org.bd_yrqtr = wrk.bd_yrqtr and org.bd_bkcode=wrk.bd_bkcode and org.bd_forcd = wrk.bd_forcd
    and wrk.BD_YRQTR=20044 and wrk.BD_BKCODE ='000'
    and wrk.BD_ALCD = '51' and wrk.BD_FORCD ='IN' and wrk.BD_TYPECD = '11'
    left join ibs_currencymaster curmst on curmst.cur_code = wrk.bd_curcd
    left join ibs_currencyexchangerate exchg on exchg.cer_currencyid = curmst.cur_id
    and exchg.cer_yearqtr = 20051 and exchg.CER_ACTIVE=1 union select distinct trim(wrk.bd_alcd) as ALCD, wrk.bd_typecd as TypeCD, wrk.bd_forcd as FORCD, wrk.bd_curcd as CURCD,
    wrk.bd_councd as COUNCD, wrk.bd_sectcd as SECCD,
    wrk.bd_matcd as MATCD, ' ' as C_U_CD, ' ' as S_U_CD,
    0 as Org_FCBal,0 as ORG_Bal,case when wrk.bd_type='O' then wrk.bd_fc_bal else 0 end as Main_FCBal,
    case when wrk.bd_type='O' then (wrk.bd_fc_bal * nvl(exchg.cer_exchangerate, 1)) else 0 end as main_Bal,
    wrk.bd_rs_int,wrk.bd_rs_bal,wrk.bd_fc_int,wrk.bd_fc_bal,
    ' ' as TrackChangs
    from ibs_work_bankdata wrk inner join ibs_org_bankdata org ON org.bd_yrqtr = wrk.bd_yrqtr and org.bd_bkcode=wrk.bd_bkcode and org.bd_forcd = wrk.bd_forcd
    and wrk.BD_YRQTR=20044 and wrk.BD_BKCODE ='000'
    and wrk.BD_ALCD = '51' and wrk.BD_FORCD ='IN' and wrk.BD_TYPECD = '11' and wrk.bd_rs_bal>0
    left join ibs_currencymaster curmst on curmst.cur_code = wrk.bd_curcd
    left join ibs_currencyexchangerate exchg on exchg.cer_currencyid = curmst.cur_id
    and exchg.cer_yearqtr = 20051 and exchg.CER_ACTIVE=1 order by main_FCBal
    explain plan is:
    ****************SELECT STATEMENT, GOAL = CHOOSE               Cost=51     Cardinality=2     Bytes=314
    SORT UNIQUE               Cost=52     Cardinality=2     Bytes=314
    UNION-ALL                         
    TABLE ACCESS BY INDEX ROWID     Object owner=RBI     Object name=IBS_ORG_BANKDATA     Cost=2     Cardinality=204     Bytes=2856
    NESTED LOOPS               Cost=26     Cardinality=1     Bytes=157
    NESTED LOOPS OUTER               Cost=24     Cardinality=1     Bytes=143
    NESTED LOOPS OUTER               Cost=23     Cardinality=1     Bytes=93
    TABLE ACCESS BY INDEX ROWID     Object owner=RBI     Object name=IBS_WORK_BANKDATA     Cost=22     Cardinality=1     Bytes=52
    INDEX SKIP SCAN     Object owner=RBI     Object name=IBS_WORK_BANKDATA_IDX     Cost=7     Cardinality=1     
    TABLE ACCESS FULL     Object owner=RBI     Object name=IBS_CURRENCYMASTER     Cost=1     Cardinality=178     Bytes=7298
    TABLE ACCESS FULL     Object owner=RBI     Object name=IBS_CURRENCYEXCHANGERATE     Cost=1     Cardinality=19     Bytes=950
    INDEX RANGE SCAN     Object owner=RBI     Object name=IBS_ORG_BANKDATA_IDX     Cost=1     Cardinality=204     
    TABLE ACCESS BY INDEX ROWID     Object owner=RBI     Object name=IBS_ORG_BANKDATA     Cost=2     Cardinality=204     Bytes=2856
    NESTED LOOPS               Cost=26     Cardinality=1     Bytes=157
    NESTED LOOPS OUTER               Cost=24     Cardinality=1     Bytes=143
    NESTED LOOPS OUTER               Cost=23     Cardinality=1     Bytes=93
    TABLE ACCESS BY INDEX ROWID     Object owner=RBI     Object name=IBS_WORK_BANKDATA     Cost=22     Cardinality=1     Bytes=52
    INDEX SKIP SCAN     Object owner=RBI     Object name=IBS_WORK_BANKDATA_IDX     Cost=7     Cardinality=1     
    TABLE ACCESS FULL     Object owner=RBI     Object name=IBS_CURRENCYMASTER     Cost=1     Cardinality=178     Bytes=7298
    TABLE ACCESS FULL     Object owner=RBI     Object name=IBS_CURRENCYEXCHANGERATE     Cost=1     Cardinality=19     Bytes=950
    INDEX RANGE SCAN     Object owner=RBI     Object name=IBS_ORG_BANKDATA_IDX     Cost=1     Cardinality=204     
    please help.

  • 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);

  • Clear the temporary tablespace

    Dear All,
    I've created a database in 10G (10.2.0). But currently running with a space problem in temporary tablespace. My database in 365X24 hrs. in such situation how to clear the temporary tablespace by keeping the database open for future operation.

    Granting privileges to a role is not necessary either ETC however everybody grants privs. to a role and roles are granted to users. When you do not do that way, you will get confused.
    What i ment with necessary is this. I tried to describe it but you don't want to understand i guess.
    I am not feel offended but Paul M. is an Oracle ACE member and he can reply to me. He asked me the question and i answered.
    As you can see it from above, i posted that it's not necessary. What i want to say is an useful fact.

  • Temporary tablespace resizing in physical standby

    Hi all,
    We have a oracle 9.2.0.6 on Sun soalris.IN Our standby db we are facing one problem is related to temporary tablespaces.
    ORA-1652: unable to extend temp segment by 128 in tablespace TEMPso how to resize the datafile we are already having a two dafiles realted to temp tablespaces
    Edited by: user00726 on Jun 2, 2009 10:25 PM

    Hi Kamran and Anand,
    Both the command s are working
    ALTER DATABASE ADD TEMPFILE 'tempfile_name.dbf' SIZE 5GByesterday only i have added one of the datafile on the same standby database
    Wed Jun  3 01:33:53 2009
    ORA-1652: unable to extend temp segment by 128 in tablespace                 TEM
    P
    Wed Jun  3 01:33:54 2009
    ORA-1652: unable to extend temp segment by 128 in tablespace                 TEM
    P
    Wed Jun  3 11:23:15 2009
    ALTER DATABASE TEMPFILE '/bkp/oradata1/temp02.dbf' resize 4024 M
    Wed Jun  3 11:24:00 2009
    Completed: ALTER DATABASE TEMPFILE '/bkp/oradata1/temp02.dbf'
    Wed Jun  3 12:53:26 2009
    ORA-1652: unable to extend temp segment by 128 in tablespace                 TEM
    P
    Wed Jun  3 12:53:26 2009
    ORA-1652: unable to extend temp segment by 128 in tablespace                 TEMand
    today also i have resized the temp files
    ALTER DATABASE TEMPFILE 'tempfile_name.dbf' RESIZE 5GB

  • Temporary tablespace groups - all available temp files not used

    We have a temporary tablespace group TEMP_GROUP made of the following pre-existing temp files. I have placed the size in MB in brackets. Names have been changed to protect our privacy. NLS is spanish
    SQL> select * from dba_tablespace_groups;
    TEMP_GROUP TEMP1 --(1024)     
    TEMP_GROUP TEMP2 --(2000)
    TEMP_GROUP TEMP3 --(8048)
    This tablespace group is the default temp tablespace of this database, and is the default temp tablespace of sys in the example that follows
    connect sys/password
    alter INDEX schema1.idx1 rebuild
    ERROR en línea 1:
    ORA-01652: no se ha podido ampliar el segmento temporal con 128 en el tablespace TEMP1
    -- this coinicdes with the TEMP1 showing 100% used
    NOTE that the message refers to the tempfile TEMP1 and not the TEMP_GROUP, which has 11GB of space available
    The size of the index is small enough to be handled by this TEMP_GROUP, although quite large to be handled by TEMP1 on its own.
    SQL> SELECT sum(bytes)/1048576 Megs, segment_name
    2 FROM dba_extents
    3 WHERE segment_name = 'IDX1'
    4 GROUP BY segment_name
    5 /
    MEGS SEGMENT_NAME
    840 IDX1
    What appears to be happening is that when the rebuild index has used all the space available in TEMP1 tempfile, it does not go on to use the space available in the other two tempfiles that make up the TEMP_GROUP. This seems to be contrary to the very idea of having set up a TEMP_GROUP.
    This suposition is born out by the repitition of the operation using the owner of the index, whose default temp file is not TEMP_GROUP as a whole, but the component tempfile TEMP_3 which has 8048MB available
    connect schema1/password
    SQL> alter INDEX schema1.idx1 rebuild
    Índice modificado.
    -- This time the index does get rebuilt, pesumably because there is space available in TEMP_3 to carry out the rebuild.
    My questions are
    1. ¿Why does the original operation fail out when it has reached the limit of tempfile TEMP1 instead of using the further space availbel within TEMP_GROUP? ¿Isn´t the point of temporary tablespace groups the explicit avoidance of this type of issue?
    2. Depending on the answer to #1, and asuming that the behaviour is normal (ie, that a rebuild index should not be expected to take place using more than one temp file), does anyone have any idea ¿what dicatates the order of usage of the component temp files in a group?. ¿Is it alphabetical order of tempfile name?, ¿file create time? or ¿something else?
    3. As I mentioned the group was created out of existing tempfiles, rather than creating some temp file specifically to form the group. ¿Could this fact explain the inability of the operation to move onto the next temp file, once the first is exhausted. There is nothing in the documentation to suggest that there should be any difference in behaviour between a temp group created with new temp files, or the inclusion of existing temp files when creating a temp group.
    As you can see, we have worked round this problem, but it is an issue of importance given that it may affect other operations that leverage this temp file group. Any information or pointers to documented instances of similar occurances would be greatly appreciated. Thank you.
    Edited by: user602617 on 06-may-2009 0:57

    Half solved. This thread seems to suggest that there should be n expectation that a sort operation will begin to use the n+1 member of a temp tablespace group once it has exhausted member n.
    TEMP Tablespace Groups
    But this does not answer my secondary question as to how to determine which temp tablespace member is used first. I guess the solution would be to drop the the group and recreate it with three adequatly sized temp tablespaces.

  • Oci_execute() [function.oci-execute]:ORA-25153:Temporary Tablespace isEmpty

    hi all,
    One of the user told us that they are facing problem while developing membership online fee payment, when theay are trying to access member table in oracle server. It works fine for single or fewer records,but when we try to fetch all records for the purpose of membership/date of birth site it generates some oracle error:
    Warning: oci_execute() [function.oci-execute]: ORA-25153: Temporary Tablespace is Empty in /usr/local/apache/htdocs/memberdbupdateoracle.php on line 41
    Warning: oci_fetch_array() [function.oci-fetch-array]: ORA-24374: define not done before fetch or execute and fetch in /usr/local/apache/htdocs/memberdbupdateoracle.php on line 49Db version is oracle 9.2.0.6
    pls suggest me...

    My suggestion is you look up the error message in the online docs, and add the tempfile to the temporary tablespace as indicated.
    My suggestion is also you read the Forums Etiquette post, and stop bothering this forum with questions for which you can find the answer yourself without effort.
    This forum is not about having someone else do your work for free.
    Sybrand Bakker
    Senior Oracle DBA

  • Cleaning up temporary tablespace

    Hi,
    I am facing a problem where temporary tablespace of the production database has grown to 23GB.The instance cannot be bounced and there is very little space left for the rest of the database.I want to free up the excess space.I know I can do it by creating a new temp tablespace,assigning it as default and dropping the old one.But I want to know how I can resize the existing temp tablespace.when I try the following command:
    alter database datafile '/d02/oradata/<SID>/temp01.dbf' resize 1G;
    it gives the following error:
    file contains used data beyond requested RESIZE value.
    How can I get around the above problem.there is no session using TEMP tablespace.Plz suggest a solution as I really want to know how this can be done.

    First of all, You can't resize the temp tablespace datafiles size as once the temp tbs allocate extents, after the operation finishes, oracle won't deallocate them as it keep them for future requirements and usage.
    What you can do in your case, as you cant bounce the db, create another temp tablespace and assign it as default temp tbs and drop the old one.
    Also, dont keep its datafiles for auto extend and if you see any error message in alter log file like 'unable to extend temp tablespace' then increase the size. If you feel your queries may fail due to this, you can also use resumable option and investigate why does it requred 20+G for temp?
    SJH
    OCP DBA

  • ORA-03212 temporary tablespace

    Hi all,
    we run a single instance database on file system (no ASM).
    The database has benn running fine for several weeks now. 2 days ago however the following error came up:
    "*** MODULE NAME:(DBMS_SCHEDULER) 2012-09-02 06:00:03.470
    *** ACTION NAME:(MGMT_CONFIG_JOB_1) 2012-09-02 06:00:03.470
    ERROR: kfnUseConn - failure to make a connection
    ORA-03212: Temporary Segment cannot be created in locally-managed tablespace".
    I changed the user's (oracle_ocm) temp tablespace to "TEMPORARY LOCAL". which should avoid that error in future.
    My question:
    What is the appropriate temporary tablespace for system users?
    We run quite a lot of databases that were created with version 7.x and migrated up to version 10 or 11. They all used to have PERMANENT tablespaces as temp tbs for the users 'SYS, SYSTEM, DIP, APPQOSSYS, CSMIG' which did not make any problems up to now.
    Should I change default temporary tbs to TBLSPC_TEMP for all users including those mentioned above?
    FJH

    Please post output of below commands :
    1. select tablespace_name from dba_data_files where tablespace_name like '%TEMP%';
    If you gets any name here, it means your temp tablespace is not really a temp one, its a permanent one whose name is temp, because if you have created temp tablespace with the TEMPFILE keyword, then only its a really temp tablespace. DBA_DATA_FILES do not shows the datafiles which have been created with TEMPFILE keyword.
    2.set long 999999;
    SELECT DBMS_METADATA.GET_DDL('TABLESPACE','TEMP') FROM DUAL;
    In above output if you don't see TEMPFILE keyword then ORA-03212 is correct and as documented.
    Now, if you want your TEMPORARY tablespace to be Locally Managed then you should use the TEMPFILE clause and NOT DATAFILE while creating the TEMPORARY TABLESPACE.
    create temporary tablespace temp tempfile
    '/u10/oradata/cprpt/temp01.dbf' size 250M reuse,
    '/u10/oradata/cprpt/temp02.dbf' size 250M reuse,
    '/u10/oradata/cprpt/temp03.dbf' size 250M reuse,
    '/u10/oradata/cprpt/temp04.dbf' size 250M reuse
    extent management local uniform size 3M;
    http://www.dbasupport.com/forums/showthread.php?t=31317
    Regards
    Girish Sharma

  • Temporary tablespace questions

    I have an Oracle 9.2.0.1.0 database running on a Windows 2000 server. I'm encountering several problems with its temporary tablespace. Here is how the temporary tablespace is created:
    create database testdb
    datafile 'd:\oradb\testdb\datafiles\testdbsys1.dbf'
    size 200M AUTOEXTEND ON NEXT 10M
    default temporary tablespace temporary
    tempfile 'd:\oradb\testdb\datafiles\tmp1.dbf'
    size 16400K reuse autoextend on next 16400K
    undo tablespace undotbs
    datafile 'd:\oradb\testdb\datafiles\testdbrbs1.dbf'
    size 100M reuse autoextend on next 10M maxsize unlimited;
    Questions:
    1- Despite the fact that the temporary tablespace datafile is specified "autoextend on", it autoextends up to 4 Gb then it fails. The exact error is ORA-0652: unable to extend temp segment by 64 in tablespace TEMPORARY. If I manually extend it beyond 4 Gb, everything works fine. Is this a bug or is it something I do wrong ? If so, what should I do to correct this ?
    2- I can't figure out what statement of my application makes the temporary tablespace grow so big. I looked at all the trace files in UDUMP and I noticed it's always the same statement that is logged when the "autoextend" error occurs. But when I run the statement on its own in SQLPlus, nothing special happens to the temporary tablespace. What is the best way to track what statement uses what resources of the temporary tablespace ?
    3- I don't know if this is what happens, but it looks like space isn't reused in the temporary tablespace. Is this possible ? If so, how can I tell Oracle to reuse it ?
    Thanks.

    1-You can try to modify the maxsize for datafaile to UNLIMITED. I am not sure it shall work, but it's worth a try
    2-Probably it's a statement that uses an order by on a large result set
    3-You can try to force the wakeup of SMON process that would free the unused extents of temporary tablespace.
    Try http://www.ixora.com.au/tips/admin/stray_temp.htm
    There is also a script to force the wakeup of smon

  • Temporary tablespace Full error 10g RAC.

    Hi All,
    Can any one help me in below problem.
    After migrating one of database from single node to two node RAC database. we are facing temporary tablespace full problem. The database previously have 2 GB of temporary tablespace but after moving to RAC enviornment it is filling 32 GB of space and still generate error.
    Thanks & Regards
    Shailendra Wanjari

    FIND OUT WHO IS USING THAT TEMP.. I USE WHEN I SEE TEMP IS BEING EATEN UP...
    column tablespace format a12
    column username format a12
    break on username nodup skip 1
    select se.username
    ,se.sid
    ,su.extents
    ,su.blocks * to_number(rtrim(p.value)) as Space
    ,tablespace
    ,segtype
    from v$sort_usage su
    ,v$parameter p
    ,v$session se
    where p.name = 'db_block_size'
    and su.session_addr = se.saddr
    order by se.username, se.sid
    /

  • How to view what is using up the temporary tablespace

    Hi all
    I am running into a problem - my temporary tablespace is being completely used up.
    How would i find out what is using up this? Technically it has enough space to function properly but now we are getting 0 bytes free.
    thanks!

    There is nothing wrong if a temporary tablespace appears as full. It is very normal. I
    For more information about temporary tablespace usage query V$SORT_USAGE and V$SORT_SEGMENT .
    For more information go to this link
    http://asktom.oracle.com/pls/ask/f?p=4950:8:14327914180898764224::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:374218170986

  • 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