Temp tablespace 99%full

What are the suggestion for temp tablespace, if its 99%full, should we keep adding space in it or it will use existing space?
TABLESPACE TOTAL_MB USED_MB FREE_MB PCT_USED GRAPH (X=5%)
TEMP 17,500.00 17,444.00 56.00 99.68 [XXXXXXXXXXXXXXXXXXX-]

Hi,
>>What are the suggestion for temp tablespace, if its 99%full, should we keep adding space in it or it will use existing space?
I think that you don't need worry about, unless you're receiving some ORA- error about out of space in TEMP tablespace. You can see below an SQL output from a database used here in my company for development and tests purposes. The database is up uninterruptedly by 7 months and the space size for the TEMP tablespace have been configured to use 900 MB.
LEGATTI@ORACLE10> SELECT tablespace_name, SUM(bytes_used), SUM(bytes_free)
2 FROM   V$temp_space_header
3 GROUP BY tablespace_name;
TABLESPACE_NAME                SUM(BYTES_USED) SUM(BYTES_FREE)
TEMP                                 943718400               0Cheers
Legatti

Similar Messages

TEMP tablespace getting full while inserting a CLOB in Trigger

We have a Oracle 10g (10.2.0.4.0) DB on a Solaris 9 box which also runs our J2EE web-service application on Weblogic 8sp6 server.
We get around 220K web-service requests from upstream callers daily to insert data in the main table, say TABLE1, which has daily partitions on a date column. This table has around 21 columns out of which 1 is a CLOB column.
Now this table has an AFTER INSERT trigger which calls a package procedure to insert the same record into another table, say TABLE2.
From Java application insert statement in executed in below format using a weblogic jdbc connection pool :
INSERT INTO TABLE1(COLUMN1, COLUMN2, ........., CLOB_COLUMN,........, COLUMN21) VALUES (:1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12, :13, :14, :15, :16, :17, :18, :19, :20);
Clob object is prepared in application using ojdbc14.jar.
We are observing a strange issue here. The TEMP tablespace utilization keeps on growing as more and more inserts are executed by application and after ~125K inserts the TEMP tablespace gets full and we start getting ORA-01652 error.
On further analysis we could see that there are only 7-10 session being maintained but as more and more inserts happen TEMP tablespace utilization goes on increasing for each of these sessions.
When we tried with inserting just few records and then watching the session details in v$session_wait then we could see that it is in INACTIVE state and waiting for the event ‘SQL*Net message from client’. This does not seem correct as the session has successfully inserted the data and committed the transaction and we can see the data in the tables as well.
The confusing thing here is when we modify the trigger to pass blank string('' ) instead of the CLOB column to TABLE2 then this issue does not occur. All 200K records are inserted properly and TEMP tablespace utilization also keep always below 1%.
Can you please help us in solving this issue. Is this related to any oracle issue?
Inside the package we have tried using DBMS_COPY statement to copy the CLOB column after insert but still same result.
Code for reference:
Trigger:
=====================================
CREATE OR REPLACE TRIGGER trg
AFTER INSERT OR UPDATE
ON TABLE1
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
IF (:NEW.date_col > SYSDATE - 2)
THEN
IF (:NEW.cat IN (1001, 1002))
THEN
pkg.process_change
     (:NEW.COLUMN1,
          :NEW.COLUMN2,
          :NEW.CLOB_COLUMN,
FLAG
END IF;
END IF;
END;
=====================================
Package:
=====================================
procedure PKG.Process_change(
p_COLUMN1 number,
p_COLUMN2 varchar2,
p_CLOB_COLUMN clob,
flag boolean
) is
v_watermark pls_integer;
v_type varchar2(1);
begin
if (flag) then
v_type := 'U';
else
v_type := 'I';
end if;
select t_seq.nextval into v_watermark from dual;
insert into TABLE2(
COLUMN1 number,
COLUMN2 varchar2,
CLOB_COLUMN clob,
watermark,
dml_type
)values (
p_COLUMN1 number,
p_COLUMN2 varchar2,
p_CLOB_COLUMN clob,
v_watermark,
v_dml_type
end;
=====================================

My first thought on reading your post is that not only are you using a database version that is now so old it is in extended support and even then not even the most recent patchset for it.
The first thing I would do is move to 11gR2 and if you can't do that at least get to 10.2.0.5 and apply CLOB relevant patches as well.
Same goes for your operating system. Solaris 9 is ancient: So move to 10 which has vastly improved memory management.
To help you further it would be really valuable to know the table layout. For example is this a heap table or an IOT? Is it partitioned? Is this RAC? What size are the CLOBs? Are they stored in-line? Chunk size? etc.
This page should start you down the right road:
http://docs.oracle.com/cd/B19306_01/appdev.102/b14249/adlob_tables.htm#sthref204
But I am also wondering why you would use a trigger to, as you say, "insert the same record into another table." This description is a poster child for "bad design."

Temp tablespace 98% full

Hy
My temp tablespace (1 GB) is 98% full.
A.)How can I find out which user uses at a certain point of time in percent the tablespace.
B.)Does a full temp tablespace lead to performance problems reduces the "reply velocity" of a database
lutz
null

Lutz,
a) By using the following query you can determine who are all the users who have created their objects in TEMP tablespace..
SQL> SELECT OWNER, SEGMENT_NAME, SEGMENT_TYPE
from dba_segments
where tablespace_name like 'TEMP';
Once u get the names of the objects u can move to the tablespace u want.
b). According to me YES. Try to restart the database after moving the objects if any.. and this should give some space to u.
There is a bug in 8.1.6 related to the use of TEMP tablespace while using the sort operations.. Check it if u r using 8.1.6
Hope this helps,
Shiva
null

Temp tablespace full at startup

Hi,
my temp tablespace appears full at database startup. I know it is full because the collecting statistics process can not be executed since temp tablespace can not grow (autoextend off). I had to add another temp datafile to get the statistics but first one continues full after each restart.
Is this any signal of malfunction?
Thanks for all.
Greetings.

ok. I think all is understood.
DBMS_STATS.GATHER_SCHEMA_STATS probably needed more disk than 1.5 GB (my old temp tablespace), so the result was
ERROR en línea 1:
ORA-01652: no se ha podido ampliar el segmento temporal con 128 en el
tablespace TEMP
ORA-06512: en "SYS.DBMS_STATS", línea 9136
ORA-06512: en "SYS.DBMS_STATS", línea 9616
ORA-06512: en "SYS.DBMS_STATS", línea 9800
ORA-06512: en "SYS.DBMS_STATS", línea 9854
ORA-06512: en "SYS.DBMS_STATS", línea 9831
ORA-06512: en línea 1
Then adding new datafile (1.5 GB more) process could finish. Database continues growing, process always had finished not yesterday: the day of needing full temp tablespace came.
Tell me if I am wrong.
Thanks a lot.

Smon not clearing my temp tablespace

hi guys,
even after I shutdown and restart my instance, my temp tablespace is showing as having 27.5 out of 30G used. why is this happening?
thanks

Hi OracleGuy777,
It is "normal" that temp tablespaces appear full, as the segments are not de-allocated. To know how much space is being used by active queries and to know if your are about to run out of temp tablespace use v$sort_usage and v$sort_segment.
E.g.:
These were for 8i/9i - should be OK in 10:
select TABLESPACE_NAME,TOTAL_BLOCKS,USED_BLOCKS,
FREE_BLOCKS, round((used_blocks/total_blocks), 2) "PERC_USED"
from v$sort_segment;Or:
SELECT A.tablespace_name tablespace, D.mb_total,
SUM (A.used_blocks * D.block_size) / 1024 / 1024 mb_used,
D.mb_total - SUM (A.used_blocks * D.block_size) / 1024 / 1024 mb_free
FROM v$sort_segment A,
(SELECT B.name, C.block_size, SUM (C.bytes) / 1024 / 1024 mb_total
FROM v$tablespace B, v$tempfile C
WHERE B.ts#= C.ts#
GROUP BY B.name, C.block_size) D
WHERE A.tablespace_name = D.name
GROUP by A.tablespace_name, D.mb_total;or for user details:
SELECT a.sid, a.username, a.osuser, a.program, a.tablespace_name,
a.bytes "BYTES_USED", round(a.blocks / b.total_blocks,3) "PERC_USED"
from (select sor.tablespace_name, ses.sid, ses.username,
ses.osuser, ses.program, sor.blocks, sor.bytes
from (select /*+ optimizer rule */ u.tablespace "TABLESPACE_NAME", u.session_addr,
sum(u.blocks) blocks, sum(u.blocks) * &blksize bytes
FROM v$sort_usage u GROUP BY u.session_addr, u.tablespace) sor,
(select /*+ optimizer rule */ saddr, sid, username, osuser, program from v$session) ses
where ses.saddr=sor.session_addr) a, (select tablespace_name, sum(decode(maxblocks,0,blocks,maxblocks)) "TOTAL_BLOCKS"
from dba_temp_files group by tablespace_name) b
where a.tablespace_name=b.tablespace_name order by a.bytesCheers,
Francisco Munoz Alvarez
http://www.oraclenz.com

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

Full temp tablespace

hi all,
i faced a problem regarding full temp tablespace, i added a tempfile as an immediate measure ,but the problem was with a query
i identified it
the query is
SELECT DISTINCT rt.po_unit_price item_price,
pl.unit_meas_lookup_code uom_code,
TO_NUMBER (porh.segment1) req_number,
msi.segment1 item_code, pl.item_description,
ph.po_header_id, TO_NUMBER (ph.segment1) po_number,
TRUNC (ph.creation_date) po_date, pv.vendor_name supplier,
pll.need_by_date, pl.quantity qty_ordered,
rt.quantity quantity_received,
(rt.quantity * rt.po_unit_price) pl_amount,
ph.currency_code, isd.ige_number ge_no,
isd.ige_date ge_date, rsh.receipt_num,
TRUNC (rt.transaction_date) receipt_date,
isd.lr_number gr_no, isd.transporter_name transporter,
(SELECT SUM (j.tax_amount)
FROM ja_in_receipt_tax_lines j
WHERE j.shipment_header_id =
rsl.shipment_header_id
AND j.shipment_line_id = rsl.shipment_line_id
AND j.tax_name LIKE 'PO%Freight%') freight,
pvs.vat_reg_no, pvs.cst_reg_no,
pvs.service_tax_regno st_reg_no,
pvs.excise_duty_reg_no excise_reg_no,
pvs.st_reg_no lst_reg_no, ai.invoice_num, ai.invoice_date,
ai.invoice_amount invoice_amount, ai.invoice_currency_code,
TRUNC (ai.terms_date + atl.due_days) date_of_payment,
TRUNC (aca.check_date) payment_date, aca.check_number,
aca.bank_account_name mode_of_payment,
TRUNC (aip.accounting_date) gl_date
FROM po_headers_all ph,
po_lines_all pl,
po_line_locations_all pll,
po_distributions_all pod,
po_req_distributions_all pord,
po_requisition_lines_all porl,
po_requisition_headers_all porh,
mtl_system_items msi,
po_vendors pv,
ja_in_po_vendor_sites pvs,
rcv_transactions rt,
rcv_shipment_headers rsh,
rcv_shipment_lines rsl,
ja_in_receipt_tax_lines jirtl,
ja_in_tax_codes jitc,
ap_invoice_distributions_all aid,
ap_invoices_all ai,
ap_terms_tl att,
ap_terms_lines atl,
ap_invoice_payments_all aip,
ap_checks_all aca,
kpm_ige_security_details isd,
kpm_ige_purchase_orders ipo
WHERE ph.po_header_id = pl.po_header_id
AND ph.po_header_id = pod.po_header_id
AND pl.po_line_id = pod.po_line_id
AND pl.po_line_id = pll.po_line_id
AND pl.item_id = msi.inventory_item_id
AND pod.req_distribution_id = pord.distribution_id(+)
AND pord.requisition_line_id = porl.requisition_line_id(+)
AND porl.requisition_header_id = porh.requisition_header_id(+)
AND msi.organization_id = 136
AND
pv.vendor_id = pvs.vendor_id
AND ph.vendor_id = pv.vendor_id
AND ph.vendor_site_id = pvs.vendor_site_id
AND rt.po_header_id = pl.po_header_id
AND rt.po_line_id = pl.po_line_id
AND rt.transaction_type = 'RECEIVE'
AND isd.ige_header_id = ipo.ige_header_id
AND ipo.po_header_id = ph.po_header_id
AND rsh.shipment_header_id = rsl.shipment_header_id
AND rt.shipment_header_id = rsl.shipment_header_id
AND rt.shipment_line_id = rsl.shipment_line_id
AND rsl.shipment_header_id = jirtl.shipment_header_id
AND rsl.shipment_line_id = jirtl.shipment_line_id
AND jirtl.tax_id = jitc.tax_id
AND aid.po_distribution_id = pod.po_distribution_id
AND aid.rcv_transaction_id = rt.transaction_id
AND aid.invoice_id = ai.invoice_id
AND ai.invoice_type_lookup_code = 'STANDARD'
AND ai.terms_id = att.term_id
AND att.term_id = atl.term_id
AND aip.invoice_id(+) = ai.invoice_id
AND aip.check_id = aca.check_id(+);
i am unable to identify the main cause, i know some tables are large , but how do i optimize it
I CAN SEND THE EXPLAIN PLAN ON EMAIL AS IT WONT GET DISPALYED HERE PROPERLY
database is 10g and OS is HP UX 11.11
the query runs perfectly on 9i
Edited by: user7864753 on Dec 4, 2009 2:55 PM

>
database is 10g and OS is HP UX 11.11
the query runs perfectly on 9iDid you compare 9i and 10g plan ?
What changed ?
Was the DB migrated ? How ?
Were statistics recalculated ?
>
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 1 | 547 | 1224 (4)|
| 1 | SORT AGGREGATE | | 1 | 31 | |
|* 2 | TABLE ACCESS BY INDEX ROWID | JA_IN_RECEIPT_TAX_LINES | 1 | 31 | 4 (0)|
|* 3 | INDEX RANGE SCAN | JA_IN_RECEIPT_TAX_LINES_N2 | 4 | | 3 (0)|
| 4 | HASH UNIQUE | | 1 | 547 | 1224 (4)|
| 5 | NESTED LOOPS | | 1 | 547 | 1223 (4)|
| 6 | NESTED LOOPS | | 1 | 543 | 1223 (4)|
| 7 | NESTED LOOPS | | 1 | 527 | 1220 (4)|
| 8 | NESTED LOOPS | | 1 | 491 | 1219 (4)|
| 9 | NESTED LOOPS | | 1 | 473 | 1216 (4)|
| 10 | NESTED LOOPS | | 1 | 465 | 1214 (4)|
| 11 | NESTED LOOPS | | 1 | 460 | 1213 (4)|
| 12 | NESTED LOOPS | | 1 | 400 | 1211 (4)|
| 13 | NESTED LOOPS | | 1 | 388 | 1204 (4)|
| 14 | NESTED LOOPS | | 1 | 376 | 1203 (4)|
| 15 | NESTED LOOPS | | 1 | 364 | 1202 (4)|
| 16 | NESTED LOOPS | | 1 | 351 | 1200 (4)|
| 17 | NESTED LOOPS | | 1 | 297 | 1192 (4)|
| 18 | NESTED LOOPS | | 1 | 274 | 1190 (4)|
| 19 | NESTED LOOPS | | 5 | 1050 | 1185 (4)|
| 20 | NESTED LOOPS | | 5 | 985 | 1180 (4)|
| 21 | NESTED LOOPS | | 5 | 935 | 1175 (4)|
| 22 | NESTED LOOPS | | 5 | 885 | 1170 (4)|
|* 23 | HASH JOIN | | 6 | 954 | 1158 (4)|
|* 24 | HASH JOIN | | 6 | 684 | 1029 (4)|
|* 25 | HASH JOIN | | 29 | 3045 | 898 (4)|
|* 26 | HASH JOIN | | 7077 | 483K| 90 (6)|
| 27 | VIEW | index$_join$_010 | 4217 | 123K| 57 (4)|
|* 28 | HASH JOIN | | | | |
| 29 | INDEX FAST FULL SCAN | PO_VENDORS_U1 | 4217 | 123K| 19 (0)|
| 30 | INDEX FAST FULL SCAN | PO_VENDORS_U2 | 4217 | 123K| 37 (3)|
| 31 | TABLE ACCESS FULL | JA_IN_PO_VENDOR_SITES | 7077 | 276K| 32 (7)|
| 32 | TABLE ACCESS FULL | PO_HEADERS_ALL | 52500 | 1794K| 805 (4)|
PLAN_TABLE_OUTPUT
|* 33 | TABLE ACCESS FULL | KPM_IGE_PURCHASE_ORDERS | 10824 | 97416 | 130 (3)|
| 34 | TABLE ACCESS FULL | KPM_IGE_SECURITY_DETAILS | 14910 | 655K| 128 (4)|
|* 35 | TABLE ACCESS BY INDEX ROWID| PO_DISTRIBUTIONS_ALL | 1 | 18 | 3 (0)|
|* 36 | INDEX RANGE SCAN | PO_DISTRIBUTIONS_N3 | 4 | | 1 (0)|
| 37 | TABLE ACCESS BY INDEX ROWID | PO_REQ_DISTRIBUTIONS_ALL | 1 | 10 | 1 (0)|
|* 38 | INDEX UNIQUE SCAN | PO_REQ_DISTRIBUTIONS_U1 | 1 | | 0 (0)|
| 39 | TABLE ACCESS BY INDEX ROWID | PO_REQUISITION_LINES_ALL | 1 | 10 | 1 (0)|
|* 40 | INDEX UNIQUE SCAN | PO_REQUISITION_LINES_U1 | 1 | | 0 (0)|
| 41 | TABLE ACCESS BY INDEX ROWID | PO_REQUISITION_HEADERS_ALL | 1 | 13 | 1 (0)|
|* 42 | INDEX UNIQUE SCAN | PO_REQUISITION_HEADERS_U1 | 1 | | 0 (0)|
|* 43 | TABLE ACCESS BY INDEX ROWID | PO_LINES_ALL | 1 | 64 | 1 (0)|
|* 44 | INDEX UNIQUE SCAN | PO_LINES_U1 | 1 | | 0 (0)|
| 45 | TABLE ACCESS BY INDEX ROWID | MTL_SYSTEM_ITEMS_B | 1 | 23 | 2 (0)|
|* 46 | INDEX UNIQUE SCAN | MTL_SYSTEM_ITEMS_B_U1 | 1 | | 1 (0)|
|* 47 | TABLE ACCESS BY INDEX ROWID | RCV_TRANSACTIONS | 1 | 54 | 8 (0)|
|* 48 | INDEX RANGE SCAN | RCV_TRANSACTIONS_N5 | 7 | | 2 (0)|
| 49 | TABLE ACCESS BY INDEX ROWID | PO_LINE_LOCATIONS_ALL | 1 | 13 | 2 (0)|
|* 50 | INDEX RANGE SCAN | PO_LINE_LOCATIONS_N1 | 2 | | 1 (0)|
|* 51 | TABLE ACCESS BY INDEX ROWID | RCV_SHIPMENT_LINES | 1 | 12 | 1 (0)|
|* 52 | INDEX UNIQUE SCAN | RCV_SHIPMENT_LINES_U1 | 1 | | 0 (0)|
| 53 | TABLE ACCESS BY INDEX ROWID | RCV_SHIPMENT_HEADERS | 1 | 12 | 1 (0)|
|* 54 | INDEX UNIQUE SCAN | RCV_SHIPMENT_HEADERS_U1 | 1 | | 0 (0)|
|* 55 | TABLE ACCESS BY INDEX ROWID | AP_INVOICE_DISTRIBUTIONS_ALL | 1 | 12 | 7 (0)|
|* 56 | INDEX RANGE SCAN | AP_INVOICE_DISTRIBUTIONS_N17 | 7 | | 2 (0)|
|* 57 | TABLE ACCESS BY INDEX ROWID | AP_INVOICES_ALL | 1 | 60 | 2 (0)|
|* 58 | INDEX UNIQUE SCAN | AP_INVOICES_U1 | 1 | | 1 (0)|
|* 59 | INDEX RANGE SCAN | AP_TERMS_TL_U1 | 1 | 5 | 1 (0)|
| 60 | TABLE ACCESS BY INDEX ROWID | AP_TERMS_LINES | 2 | 16 | 2 (0)|
|* 61 | INDEX RANGE SCAN | AP_TERMS_LINES_U1 | 2 | | 1 (0)|
| 62 | TABLE ACCESS BY INDEX ROWID | AP_INVOICE_PAYMENTS_ALL | 1 | 18 | 3 (0)|
|* 63 | INDEX RANGE SCAN | AP_INVOICE_PAYMENTS_N1 | 1 | | 2 (0)|
| 64 | TABLE ACCESS BY INDEX ROWID | AP_CHECKS_ALL | 1 | 36 | 1 (0)|
|* 65 | INDEX UNIQUE SCAN | AP_CHECKS_U1 | 1 | | 0 (0)|
| 66 | TABLE ACCESS BY INDEX ROWID | JA_IN_RECEIPT_TAX_LINES | 1 | 16 | 3 (0)|
|* 67 | INDEX RANGE SCAN | JA_IN_RECEIPT_TAX_LINES_N2 | 4 | | 2 (0)|
|* 68 | INDEX UNIQUE SCAN | JA_IN_TAX_CODES_U1 | 1 | 4 | 0 (0)|
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
2 - filter("J"."TAX_NAME" LIKE 'PO%Freight%')
3 - access("J"."SHIPMENT_HEADER_ID"=:B1 AND "J"."SHIPMENT_LINE_ID"=:B2)
23 - access("ISD"."IGE_HEADER_ID"="IPO"."IGE_HEADER_ID")
24 - access("IPO"."PO_HEADER_ID"="PH"."PO_HEADER_ID")
25 - access("PH"."VENDOR_ID"="PV"."VENDOR_ID" AND "PH"."VENDOR_SITE_ID"="PVS"."VENDOR_SITE_ID")
26 - access("PV"."VENDOR_ID"="PVS"."VENDOR_ID")
28 - access(ROWID=ROWID)
33 - filter("IPO"."PO_HEADER_ID" IS NOT NULL)
35 - filter("POD"."REQ_DISTRIBUTION_ID" IS NOT NULL)
36 - access("PH"."PO_HEADER_ID"="POD"."PO_HEADER_ID")
38 - access("POD"."REQ_DISTRIBUTION_ID"="PORD"."DISTRIBUTION_ID")
40 - access("PORD"."REQUISITION_LINE_ID"="PORL"."REQUISITION_LINE_ID")
42 - access("PORL"."REQUISITION_HEADER_ID"="PORH"."REQUISITION_HEADER_ID")
43 - filter("PH"."PO_HEADER_ID"="PL"."PO_HEADER_ID")
44 - access("PL"."PO_LINE_ID"="POD"."PO_LINE_ID")
46 - access("PL"."ITEM_ID"="MSI"."INVENTORY_ITEM_ID" AND "MSI"."ORGANIZATION_ID"=136)
47 - filter("RT"."TRANSACTION_TYPE"='RECEIVE' AND "RT"."PO_HEADER_ID"="PL"."PO_HEADER_ID")
48 - access("RT"."PO_LINE_ID"="PL"."PO_LINE_ID")
50 - access("PL"."PO_LINE_ID"="PLL"."PO_LINE_ID")
51 - filter("RT"."SHIPMENT_HEADER_ID"="RSL"."SHIPMENT_HEADER_ID")
52 - access("RT"."SHIPMENT_LINE_ID"="RSL"."SHIPMENT_LINE_ID")
54 - access("RSH"."SHIPMENT_HEADER_ID"="RSL"."SHIPMENT_HEADER_ID")
55 - filter("AID"."PO_DISTRIBUTION_ID" IS NOT NULL AND
"AID"."PO_DISTRIBUTION_ID"="POD"."PO_DISTRIBUTION_ID")
56 - access("AID"."RCV_TRANSACTION_ID"="RT"."TRANSACTION_ID")
filter("AID"."RCV_TRANSACTION_ID" IS NOT NULL)
57 - filter("AI"."INVOICE_TYPE_LOOKUP_CODE"='STANDARD')
58 - access("AID"."INVOICE_ID"="AI"."INVOICE_ID")
59 - access("AI"."TERMS_ID"="ATT"."TERM_ID")
61 - access("ATT"."TERM_ID"="ATL"."TERM_ID")
63 - access("AIP"."INVOICE_ID"="AI"."INVOICE_ID")
65 - access("AIP"."CHECK_ID"="ACA"."CHECK_ID")
67 - access("RSL"."SHIPMENT_HEADER_ID"="JIRTL"."SHIPMENT_HEADER_ID" AND
PLAN_TABLE_OUTPUT
"RSL"."SHIPMENT_LINE_ID"="JIRTL"."SHIPMENT_LINE_ID")
68 - access("JIRTL"."TAX_ID"="JITC"."TAX_ID")
Note
- 'PLAN_TABLE' is old version
117 rows selected.

TEMP tablespace is always full in Enterprise Manager

The TEMP tablespace is always (99.99%) full in Enterprise Manager console. How can I release it and check it?

Yes, Kamal did give the answer. owever, it still remains confusing to most people.
The temp tablespace, like all tablespaces, is used to hold SEGMENTS. There are several kinds of temporary segments, including sort segments and segments for global temporary tables.
WHen a segment is allocated, it takes time to find the blocks that are free and to format those blocks.
Oracle's performance measure to counter the cost of finding and formatting free blocks is to leave the segment allocated at that kind of block. When a session terminates, any temprary segments it holds will be released to the free pool of 'that type of temprary segment', and another session can then (as you say) reuse the space.
Still, this is frustrating for the new DBA who has not read the concepts manual and not searched the forum on 'v$sort' or 'temporary tablespace usage'.
http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14220/logical.htm#sthref399

Should I increase TEMP tablespace size here ?

Version: 10.2.0.4
Platform : RHEL 5.8
Currently we are running a batch job in a schema. The default temporary tablespace for that schema is TEMP.
But I see that the tablespace is full.
SQL> select file_name, bytes/1024/1024/1024 gb from dba_temp_files where tablespace_name = 'TEMP';
FILE_NAME                                                                 GB
/prd/fdms/oradata_db18/fdmsc1sdb/oradata/ts_temp/temp01.dbf               10
SQL> SELECT     TABLESPACE_NAME, FILE_ID,
        BYTES_USED/1024/1024,
        bytes_free/1024/1024
FROM V$TEMP_SPACE_HEADER where tablespace_name = 'TEMP' 2    3    4 ;
TABLESPACE_NAME                             FILE_ID BYTES_USED/1024/1024 BYTES_FREE/1024/1024
TEMP                                              1                10240
So, far the application users have not complained and I didn't see any 'unable to extend' error in the alert log yet, but the above scenario is dangerous. Right? I mean SQL statements with sorting can error out. Right ? Unlike UNDO, with temp tablespace, temp segments cannot be reused. Right ?

Hello,
As said previously, the Sort Segments can be reused, the Views V$SORT_SEGMENT and V$TEMPSEG_USAGE are relevant to monitore the usage of the Temporary Tablespace.
You'll find in the Note below a way to control over time the Temporary Tablespace:
How Can Temporary Segment Usage Be Monitored Over Time? [ID 364417.1]
More over, you may also check for any ORA-01652 in the Alert Log.
But don't worry to much to get a Full Temporary Tablespace, here "Full" doesn't mean "unreusable".
Hope this help.
Best Regards,
Jean-Valentin Lubiez

To shrink the size of TEMP tablespace

Dear all,
There is a databse with RAC, now in OEM the size of TEMP tablespace has been reached at 99.9%. now we want to shrink the size of TEMP tablespace.
how to we do that???????
plz help me...........

Temporary tablespaces usually show they are full, however this space is not actually in use. It is rather allocated. Oracle has evaluated the best way to obtain the most of performance, and he said it is better to allocate once than allocate-deallocate-reallocate extents, so temporary space is not 'released'.
If you want to feel psychologically more confortable with lower allocated space, you can drop your tablespace (create an interim default temporary tablespace first) and recreate it.
You can also rebuild temporary datafiles:
alter tablespace temp add tempfile 'C:\ORACLE\ORACLEXE\ORADATA\XE\TEMP01.dbf' size 32m;
SQL> select name from v$tempfile;
NAME
C:\ORACLE\ORACLEXE\ORADATA\XE\TEMP.DBF
C:\ORACLE\ORACLEXE\ORADATA\XE\TEMP01.DBF
SQL> alter database tempfile 'C:\ORACLE\ORACLEXE\ORADATA\XE\TEMP01.DBF' drop including datafiles;
Database altered.

Increasin the temp tablespace

Hello All,
I am using Oracle 11g R2 i want to increase the temp tablespace size. can i use the below command? can i increase while the database is open and some queries are running and use the temp table space?
ALTER DATABASE TEMPFILE '....../datafile/name_datafile.tmp' RESIZE 100M
Regards,

Hello,
I am using Oracle 11g R2 i want to increase the temp tablespace size. can i use the below command? can i increase while the database is open and some queries are running and use the temp table space?Why do you intend to extend the Temporary Tablespace ? Do you have any ORA-01652 error ?
If not, may be it's not necessary to extend it. Even if it seems to be full Free Extents are reused.
ALTER DATABASE TEMPFILE '....../datafile/name_datafile.tmp' RESIZE 100MYes you can use this statement, but be aware that the Size specified (here 100 Mo) is the target size not the supplemental size.
Hope this help.
Best regards,
Jean-Valentin

Temp tablespace issue

Hi,
We are facing continuous problem of slow performance in some applications...i found that temp tablespace is becoming full frequently...so after that reports are getting delayed..is there any permanent fix for this problem..
We have recreated the temp tablespace...
Regards,
Joshua

Hi,
pls find the details...
VERSION:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
some info abt temp tablespace:
TABLESPACE_NAME BYTES_COALESCED EXTENTS_COALESCED PERCENT_EXTENTS_COALESCED BLOCKS_COALESCED PERCENT_BLOCKS_COALESCED
TEMP_SCHEMA_USR 50724864 2 100 6192 100
is that means coalescing would solve the problem ?...
We have some limitation that we cant control the users since they are very critical in operation...
Is Adding datafile will solve the problem(bcoz b4 sometime i added one file....no improvement)...

ORA-01652 in TEMP Tablespace

Hi,
We have the following errors:
RMAN> crosscheck archivelog all;
starting full resync of recovery catalog
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of crosscheck command at 01/07/2009 14:26:10
RMAN-03014: implicit resync of recovery catalog failed
RMAN-03009: failure of full resync command on default channel at 01/07/2009 14:26:10
ORA-01652: unable to extend temp segment by in tablespace
RMAN>
We have tried to increase the size of the TEMP tablespace, but this operation keeps using up the entire temp tablespace. It's the temp tablespace in the target database that is filling up.
We cannot keep increasing the size of the TEMP ts to fill the disk.
We have also tried to create a new repository but this had the same outcome.
I reckon there is something in the database tables, as one of our backups used the target control file as its repository. Should I remove the entries from these tables in the target tablespace to make the repository think there is no re-synching to be done?
Regards,
Tim.

If you are sure that it is on the target DB what you can do is enable a trace for the event to see what triggers this error
it doesnt have to be on temporary table because there are temp segments on normal tables used for index creation type operations as well so you need to find the problem before assuming it is temp tablespace error
alter system set events '1652 trace name errorstack level 1';
to turn off
alter system set events '1652 trace name context off';
If you cant find anything from trace then you can send the trace output here maybe somebody can catch something.
Coskan Gundogar
http://coskan.wordpress.com
Edited by: coskan on Mar 30, 2009 4:28 PM

System tablespace 92% full

Oracle 9.2.0.1
Linux 7.3
I am on a test machine.
The system tablespace is 92%full.Is it an appropriate value?
What should be the size of the system tablespace?
I checked in DBA_USERS,all users have users tablespace ,few system users have system tablespace as there default tablespace.There is a separate temp tablespace for temporary segments.

few system users have system tablespace as there default tablespacei think the OP mentioned users are the one that are created during the creation of database
Once the user has been assigned a tablesapce ..whatever he creates after that by default will be created under the default tablesapce unless it is redirected to use a different tbs provided he has the privilge on that

TEMP Tablespace too small

Hi all,
We have an Oracle 10.2.0.4 Reporting database, of which every night al lot of data is refreshed from production databases.
For this refresh this database uses complex Materialized View definitions.
We recently keep running out of TEMP tablespace during the refresh of these MV's. The TEMP tablespace has lately been increased several times ( in total from 15Gb to 25Gb the last months).
The largets MV is just 3Gb's big. Especially the one that ran out of TEMP tablespace last night is only 1Gb big.
The error message:
ORA-12008: error in materialized view refresh path
ORA-12801: error signaled in parallel query server P002
ORA-01652: unable to extend temp segment by 64 in tablespace TEMP
Can anyone tell me what could cause this behaviour ??
Some specs:
Oracle 10.2.0.4
Platform: AIX 5.3 TL06
sga_target = 3504M
parallel_max_servers=8
temp_tablespace_size=25600Mb
Thanks in advance

They are COMPLETE refreshes.
Statement of the view:
SELECT /*+ NO_USE_HASH_AGGREGATION */
mon.mon_description AS mon_mon_descr, mon.mon_code AS mon_mon_code,
mon.yer_code AS mon_yer_code, cus.iet_descr AS cus_iet_descr,
prd.igp_nr AS prd_igp_nr, prd.igp_descr_german AS prd_igp_descr_ger,
prd.igp_descr_dutch AS prd_igp_descr_dut,
prd.igp_descr_english AS prd_igp_descr_eng,
prd.igp_descr_czech AS prd_igp_descr_ces,
prd.igp_descr_russian AS prd_igp_descr_rus, prd.pgp_nr AS prd_pgp_nr,
prd.pgp_descr_german AS prd_pgp_descr_ger,
prd.pgp_descr_dutch AS prd_pgp_descr_dut,
prd.pgp_descr_english AS prd_pgp_descr_eng,
prd.pgp_descr_czech AS prd_pgp_descr_ces,
prd.pgp_descr_russian AS prd_pgp_descr_rus, prd.dvs_nr AS prd_dvs_nr,
prd.dvs_descr_german AS prd_dvs_descr_ger,
prd.dvs_descr_dutch AS prd_dvs_descr_dut,
prd.dvs_descr_english AS prd_dvs_descr_eng,
prd.dvs_descr_czech AS prd_dvs_descr_ces,
prd.dvs_descr_russian AS prd_dvs_descr_rus,
cus.pce_descr AS cus_pce_descr, cus.smk_descr AS cus_smk_descr,
cus.org_descr AS cus_org_descr, cus.dpm_descr AS cus_dpm_descr,
cus.cmp_descr AS cus_cmp_descr, cus.cgp_descr AS cus_cgp_descr,
cus.cus_nr AS cus_cus_nr, cus.cus_descr AS cus_cus_descr,
cus.cus_billto_nr AS cus_billto_nr,
SUM (fin.invoice_discount_eur) AS invoice_discount_eur,
SUM (fin.invoice_discount_gbp) AS invoice_discount_gbp,
SUM (fin.invoice_line_discount_eur) AS invoice_line_discount_eur,
SUM (fin.invoice_line_discount_gbp) AS invoice_line_discount_gbp,
SUM (fin.turnover_cr_eur) AS turnover_cr_eur,
SUM (fin.turnover_cr_gbp) AS turnover_cr_gbp,
SUM (fin.turnover_deb_eur) AS turnover_deb_eur,
SUM (fin.turnover_deb_gbp) AS turnover_deb_gbp,
SUM (fin.turnover_eur) AS turnover_eur,
SUM (fin.turnover_gbp) AS turnover_gbp,
SUM (fin.count_credit_slips) AS count_credit_slips,
cus.srp_nr AS cus_srp_nr, cus.srp_descr AS cus_srp_descr,
COUNT (*) AS total_records,
COUNT (fin.count_credit_slips) AS num_count_credit_slips,
cus.cus_branch AS cus_branch_nr, cus.cus_district AS cus_district_nr,
SUM (fin.profit_eur) AS profit_eur,
SUM (fin.profit_gbp) AS profit_gbp,
SUM (fin.cost_price_eur) AS costs_eur,
SUM (fin.cost_price_gbp) AS costs_gbp,
SUM (fin.invoice_discount_chf) AS invoice_discount_chf,
SUM (fin.invoice_line_discount_chf) AS invoice_line_discount_chf,
SUM (fin.turnover_cr_chf) AS turnover_cr_chf,
SUM (fin.turnover_deb_chf) AS turnover_deb_chf,
SUM (fin.turnover_chf) AS turnover_chf,
SUM (fin.profit_chf) AS profit_chf,
SUM (fin.cost_price_chf) AS costs_chf,
SUM (fin.invoice_discount_czk) AS invoice_discount_czk,
SUM (fin.invoice_line_discount_czk) AS invoice_line_discount_czk,
SUM (fin.turnover_cr_czk) AS turnover_cr_czk,
SUM (fin.turnover_deb_czk) AS turnover_deb_czk,
SUM (fin.turnover_czk) AS turnover_czk,
SUM (fin.profit_czk) AS profit_czk,
SUM (fin.cost_price_czk) AS costs_czk,
SUM (fin.invoice_discount_rub) AS invoice_discount_rub,
SUM (fin.invoice_line_discount_rub) AS invoice_line_discount_rub,
SUM (fin.turnover_cr_rub) AS turnover_cr_rub,
SUM (fin.turnover_deb_rub) AS turnover_deb_rub,
SUM (fin.turnover_rub) AS turnover_rub,
SUM (fin.profit_rub) AS profit_rub,
SUM (fin.cost_price_rub) AS costs_rub,
COUNT (fin.invoice_discount_eur) AS cnt_invoice_discount_eur,
COUNT (fin.invoice_discount_gbp) AS cnt_invoice_discount_gbp,
COUNT
(fin.invoice_line_discount_eur)
AS cnt_invoice_line_discount_eur,
COUNT
(fin.invoice_line_discount_gbp)
AS cnt_invoice_line_discount_gbp,
COUNT (fin.turnover_cr_eur) AS cnt_turnover_cr_eur,
COUNT (fin.turnover_cr_gbp) AS cnt_turnover_cr_gbp,
COUNT (fin.turnover_deb_eur) AS cnt_turnover_deb_eur,
COUNT (fin.turnover_deb_gbp) AS cnt_turnover_deb_gbp,
COUNT (fin.turnover_eur) AS cnt_turnover_eur,
COUNT (fin.turnover_gbp) AS cnt_turnover_gbp,
COUNT (fin.profit_eur) AS cnt_profit_eur,
COUNT (fin.profit_gbp) AS cnt_profit_gbp,
COUNT (fin.cost_price_eur) AS cnt_costs_eur,
COUNT (fin.cost_price_gbp) AS cnt_costs_gbp,
COUNT (fin.invoice_discount_chf) AS cnt_invoice_discount_chf,
COUNT
(fin.invoice_line_discount_chf)
AS cnt_invoice_line_discount_chf,
COUNT (fin.turnover_cr_chf) AS cnt_turnover_cr_chf,
COUNT (fin.turnover_deb_chf) AS cnt_turnover_deb_chf,
COUNT (fin.turnover_chf) AS cnt_turnover_chf,
COUNT (fin.profit_chf) AS cnt_profit_chf,
COUNT (fin.cost_price_chf) AS cnt_costs_chf,
COUNT (fin.invoice_discount_czk) AS cnt_invoice_discount_czk,
COUNT
(fin.invoice_line_discount_czk)
AS cnt_invoice_line_discount_czk,
COUNT (fin.turnover_cr_czk) AS cnt_turnover_cr_czk,
COUNT (fin.turnover_deb_czk) AS cnt_turnover_deb_czk,
COUNT (fin.turnover_czk) AS cnt_turnover_czk,
COUNT (fin.profit_czk) AS cnt_profit_czk,
COUNT (fin.cost_price_czk) AS cnt_costs_czk,
COUNT (fin.invoice_discount_rub) AS cnt_invoice_discount_rub,
COUNT
(fin.invoice_line_discount_rub)
AS cnt_invoice_line_discount_rub,
COUNT (fin.turnover_cr_rub) AS cnt_turnover_cr_rub,
COUNT (fin.turnover_deb_rub) AS cnt_turnover_deb_rub,
COUNT (fin.turnover_rub) AS cnt_turnover_rub,
COUNT (fin.profit_rub) AS cnt_profit_rub,
COUNT (fin.cost_price_rub) AS cnt_costs_rub
FROM /* dwh_internal_external_dim iet */
dwh_customers_dim cus /* department */
, dwh_products_dim prd /* itemgroup */
, dwh_months_dim mon
, dwh_financial_fct fin
WHERE fin.mon_code = mon.mon_code
AND fin.prd_id = prd.prd_id
AND fin.cus_cus_id = cus.cus_id
GROUP BY mon.mon_description,
mon.mon_code,
mon.yer_code,
cus.iet_descr,
prd.igp_nr,
prd.igp_descr_german,
prd.igp_descr_dutch,
prd.igp_descr_english,
prd.igp_descr_czech,
prd.igp_descr_russian,
prd.pgp_nr,
prd.pgp_descr_german,
prd.pgp_descr_dutch,
prd.pgp_descr_english,
prd.pgp_descr_czech,
prd.pgp_descr_russian,
prd.dvs_nr,
prd.dvs_descr_german,
prd.dvs_descr_dutch,
prd.dvs_descr_english,
prd.dvs_descr_czech,
prd.dvs_descr_russian,
cus.pce_descr,
cus.smk_descr,
cus.org_descr,
cus.dpm_descr,
cus.cmp_descr,
cus.cgp_descr,
cus.cus_nr,
cus.cus_descr,
cus.cus_billto_nr,
cus.srp_nr,
cus.srp_descr,
cus.cus_branch,
cus.cus_district;
Explain plan:
Plan
SELECT STATEMENT CHOOSE Cost: 278,496 Bytes: 13,752,541,260 Cardinality: 18,864,940
25 PX COORDINATOR
24 PX SEND QC (RANDOM) PARALLEL_TO_SERIAL SYS.:TQ10005 :Q1005 Cost: 278,496 Bytes: 13,752,541,260 Cardinality: 18,864,940
23 SORT GROUP BY PARALLEL_COMBINED_WITH_PARENT :Q1005 Cost: 278,496 Bytes: 13,752,541,260 Cardinality: 18,864,940
22 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1005 Cost: 278,496 Bytes: 13,752,541,260 Cardinality: 18,864,940
21 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10004 :Q1004 Cost: 278,496 Bytes: 13,752,541,260 Cardinality: 18,864,940
     20 SORT GROUP BY PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 278,496 Bytes: 13,752,541,260 Cardinality: 18,864,940
     19 HASH JOIN PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 26,390 Bytes: 13,752,541,260 Cardinality: 18,864,940
     4 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 55 Bytes: 11,394,614 Cardinality: 70,774
     3 PX SEND BROADCAST PARALLEL_TO_PARALLEL SYS.:TQ10000 :Q1000 Cost: 55 Bytes: 11,394,614 Cardinality: 70,774
     2 PX BLOCK ITERATOR PARALLEL_COMBINED_WITH_CHILD :Q1000 Cost: 55 Bytes: 11,394,614 Cardinality: 70,774
     1 TABLE ACCESS FULL TABLE PARALLEL_COMBINED_WITH_PARENT MIS_RUN.DWH_CUSTOMERS_DIM :Q1000 Cost: 55 Bytes: 11,394,614 Cardinality: 70,774
     18 HASH JOIN PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 26,300 Bytes: 10,715,285,920 Cardinality: 18,864,940
     8 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 2 Bytes: 2,052 Cardinality: 108
     7 PX SEND BROADCAST PARALLEL_TO_PARALLEL SYS.:TQ10001 :Q1001 Cost: 2 Bytes: 2,052 Cardinality: 108
     6 PX BLOCK ITERATOR PARALLEL_COMBINED_WITH_CHILD :Q1001 Cost: 2 Bytes: 2,052 Cardinality: 108
          5 TABLE ACCESS FULL TABLE PARALLEL_COMBINED_WITH_PARENT MIS_RUN.DWH_MONTHS_DIM :Q1001 Cost: 2 Bytes: 2,052 Cardinality: 108
     17 HASH JOIN PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 26,264 Bytes: 10,356,852,060 Cardinality: 18,864,940
     12 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 305 Bytes: 178,954,440 Cardinality: 426,082
     11 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10002 :Q1002 Cost: 305 Bytes: 178,954,440 Cardinality: 426,082
          10 PX BLOCK ITERATOR PARALLEL_COMBINED_WITH_CHILD :Q1002 Cost: 305 Bytes: 178,954,440 Cardinality: 426,082
          9 TABLE ACCESS FULL TABLE PARALLEL_COMBINED_WITH_PARENT MIS_RUN.DWH_PRODUCTS_DIM :Q1002 Cost: 305 Bytes: 178,954,440 Cardinality: 426,082
     16 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 11,396 Bytes: 2,433,577,260 Cardinality: 18,864,940
     15 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10003 :Q1003 Cost: 11,396 Bytes: 2,433,577,260 Cardinality: 18,864,940
     14 PX BLOCK ITERATOR PARALLEL_COMBINED_WITH_CHILD :Q1003 Cost: 11,396 Bytes: 2,433,577,260 Cardinality: 18,864,940
          13 TABLE ACCESS FULL TABLE PARALLEL_COMBINED_WITH_PARENT MIS_RUN.DWH_FINANCIAL_FCT :Q1003 Cost: 11,396 Bytes: 2,433,577,260 Cardinality: 18,864,940
Thanks again

Temp tablespace 99%full

Similar Messages

Maybe you are looking for