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

Similar Messages

Informatica Workflow fails because of TEMP tablespace

Hi,
I am trying to do a Complete Oracle 11.5.10 load. However my execution plan fails because the SDE_ORA_Payroll_Fact fails. The error in the session log is as follows:
READER_1_1_1> RR_4035 SQL Error [
ORA-01652: unable to extend temp segment by 128 in tablespace TEMP
From the error message it is very clear that the Source Qualifier is unable to select the data from the source tables. i have increased the TEMP tablespace too however I keep getting the error. Because of this error my other mappings are also Stopped. Any solutions to this problem?

Hi,
Would you not want to use the following parameters to say load one fiscal year at a time?
Analysis Start Date
The start date used to build the day dimension and to flatten exchange rates and costs lists.
$$ANALYSIS_START, $$ANALYSIS_START_WID
Default : Jan 1, 1980
Analysis End Date
The end date used to build the day dimension and to flatten exchange rates and costs lists.
$$ANALYSIS_END, $$ANALYSIS_END_WID
Default : Dec 31, 2010
Thanks,
Chris

Tablespace temp grows too much

Hi gurus,
i´m using OBIEE 10.1.3.4 . When i´doing a select over a materialized view, the tablespace temp grows too much ( about 15GB).
The columns of the materialized view are functions.
The base tables of the Materialized View are big, thousands of MB.
Is it possible to configure the tablespace temp with OBIEE? and via SQL-PLUS?
Best Regards.
Roberto.

you can do it with Oracle Enterprise Manager, that is much easier way. If you don't have access to OEM and has privileges to alter table space. the command is something like
alter tablespace ts_sth add datafile \etc\temp.dbf' size 4M autoextend on;

Tablespace temp grows too much when using OBIEE

Hi gurus,
i´m using OBIEE 10.1.3.4 . When i´doing a select over a materialized view, the tablespace temp grows too much ( about 15GB).
The columns of the materialized view are functions.
The base tables of the Materialized View are big, thousands of MB.
Is it possible to configure the tablespace temp with OBIEE? and via SQL-PLUS?
Best Regards.
Roberto.

you can do it with Oracle Enterprise Manager, that is much easier way. If you don't have access to OEM and has privileges to alter table space. the command is something like
alter tablespace ts_sth add datafile \etc\temp.dbf' size 4M autoextend on;

Sizing of the OLAP temp tablespace!!

We are using 10gR2 OLAP along with Disco Plus OLAP to build a prototype. The metadata is built with AWM 10.2.0.1.0A.
Our test data is about 40M records, 1.7G in a flat file. After loaded to a fact table via Sql*loader, it takes about 2G for the tablespace, along with 7 dim tables. Only one cube and one measure are used. A compressed composite with 6 dims in it is associated with the cube.
However, when run the AWM maintenance steps to get a full cube aggregation. The temp tablespace for the AW shot for 30G and then generated an out of disk space error. The AW tablespace remains untouched. The maintenace cannot be finished.
Interesting to note, the data was solved in the Xpress already. When do a eif exp/imp, the result tablespace is about 5G while the eif file takes 1.3G.
Also, before doing this round data, we have sucessfully created and maintained a AW with very small set of data. The data is displayed in Disco Plus correctly.
The disk space for the temp tablespace seems surprisingly demanding. We need to get an idea how much space it really needs. Is there anybody that has some contributable experience on this issue? Please reply this post. Not sure if Oracle has formal publishing on the temp tablespace sizing issue. Believe they should have one.
Thanks,

Chris,
No upgrading was done here. The metadata and objects were defined using AWM model view manually, but matching to the definition on the Xpress side for the same object, like dim order etc. The fact data then dumped to a flat file from Xpress, transferred to the olap db server and loaded to a star schema with sql*loader. AWM mapping and maintenance features were used to build the cube.
I am saying the data was solved means the summary level data was included in the dump. So we know the size of the solved cube. My reasoning is that there should be no place for the size increase to out of control because too much new summary level data was added.
Another fact I should mention last time is all the data are in one time period. 40M is the number of tuples.
Thanks for the help.
Haiyong

Size for TEMP tablespace

I don't know if this is a "valid" question. We have users running reports on our production system. The sometimes complain about the temp space being too small (due to their queries crashing when using too much temp space).
But I also have a feeling that you can keep throwing disks at TEMP space, and that it will never be enough.
What should the size of a database's TEMP space be - is there a rule of thumb for this ?
Dirk

There are several considerations that you should take into account when you try to size your temporary tablespace:
First, how much sort does you average transaction need and how many concurrent transactions does your system need to support. This number gives you a starting point for the minimum workable size for normal operations.
Now, how big is the largest table on your system and do you wish to be able to support select * from biggest order by ? Supporting an unqualified select on your largest table may not be required.
How big is the largest index in your system? It is likely that you need to have enough temp space available to recreate this index in the event of corruption without having to take special action to allocate more space to temp on a temporary basis. But having to add space in the event of a diaster might be acceptable.
Figure out what the largest sort operation you need to be able to support is and then add enough space to handle the number of concurrent average transactions that would be expected to be on the system at the same time. This is the size you should use for your temporary tablespace.
It is better to have all the space you will need for any normal and for any maintenance operation available at all time rather than trying to find additional file space to support special maintenance tasks or diaster recovery operations.
HTH -- Mark D Powell --

Creating a Global Temporary Table on non-default TEMP tablespace.

Hello ,
I am using Oracle 11g.
I have a procedure which create global temporary tables for its functionality. As the data which is going in the global temporary table , mean the data which is going in the default TEMP tablesapce is too huge ..... billions of rows..
So what i want to do is , I want to create the global temporary table in another TEMP2 tablespace ( which is not the default one) so the load of billions of rows of data will be shifted to TEMP2. The default TEMP tablespace will not be affected and it can be used for other transactions.
Is this possible. Can i shift the global temporary table from TEMP( Default temp tablespace) to TEMP2 ( the non-default temp tablespace) ????
Please guide me with proper solutions and examples ....
Thanks in advance ..

DBA4 wrote:
Hello ,
I am using Oracle 11g.
I have a procedure which create global temporary tables for its functionality. As the data which is going in the global temporary table , mean the data which is going in the default TEMP tablesapce is too huge ..... billions of rows..
So what i want to do is , I want to create the global temporary table in another TEMP2 tablespace ( which is not the default one) so the load of billions of rows of data will be shifted to TEMP2. The default TEMP tablespace will not be affected and it can be used for other transactions.
Is this possible. Can i shift the global temporary table from TEMP( Default temp tablespace) to TEMP2 ( the non-default temp tablespace) ????
Global temporary tables are instantiated in the temporary tablespace of the schema that inserts the data - not into "the default" temporary tablespace.
Assume Schema1 creates a GTT and grants all on that table to schema2
Assume schema1 also creates a procedure (authid owner, the default) to insert data into the GTT and grants execute on the procedure to schema2
If schema2 executes: insert into schema1.gtt, the data will appear in the temporary tablespace of schema2
If schema2 executes: execute schema1.procedure, the data will appear in the temporary tablespace of schema1
So if you want to protect the "normal" temporary tablespace, you could just create a special temporary tablespace for the owner of the procedure.
Regards
Jonathan Lewis

Buffer too small for string - Crystal Report for Vs2010

Hello,
    I have recently upgrade my VS2010 project to Crystal Report for Visual Studion 2010.
    I have some reports that contains more than 512 characters in the Report Comments section.
    When I try to do a RptDoc.SaveAs(vPath, false) the following error is raised:
Buffer too small for string or missing null byte.
      at CrystalDecisions.ReportAppServer.ClientDoc.ReportClientDocumentClass.SaveAs in :line 0
      at CrystalDecisions.ReportAppServer.ReportClientDocumentWrapper.SaveAs in :line 0
      at CrystalDecisions.CrystalReports.Engine.ReportDocument.SaveAs in :line 0
    This line SaveAs was working has expected with Crystal Report 2008. Any idea on why it is not working anymore.
Thank you.
Charles

Hello Don,
    I have start a little project to retest the behavior.
   I have create a new report in Crystal Report 2008 just by clicking New, Finish and Save.
   In a new Windows Application in Vs2010 ,I have added the following Crystal Report Reference.
    CrystalDecisions.CrystalReports.Engine, Version=13.0.2000.0
   CrystalDecisions.Shared, Version=13.0.2000.0
I have then try the following code and found out the limit of ReportComment is 511 but in the Crystal Report 2008 designer and runtime the limit did not apply.
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
      Dim objRpt As New CrystalDecisions.CrystalReports.Engine.ReportDocument()
      Dim i As Integer = 0
      Try
         objRpt.Load("c:\temp\empty.rpt", CrystalDecisions.Shared.OpenReportMethod.OpenReportByTempCopy)
         Do
            i += 1
            objRpt.SummaryInfo.ReportComments = New String("X", i)
         Loop
         objRpt.SaveAs("c:\temp\dfh_save.rpt", False)
      Catch ex As Exception
         MsgBox("i: " & i)
         MsgBox(ex.Message)
      End Try
End Sub
     I am able to put has many characters if I insert the report in the Vs2010 Solution.
     If you prefer I can send you my little project.
Thank you.
Charles
<code> should be
Edited by: Don Williams on Feb 4, 2011 12:47 PM

Restored coldbackup and having trouble with TEMP tablespace

Hi, i succesfully restored from a coldbackup on solaris.(oracle 9.2)
i can log on to database using toad, query the database, but when i try to take an export or something i got the error
EXP-00056: ORACLE error 1157 encountered
ORA-01157: cannot identify/lock data file 203 - see DBWR trace file
ORA-01110: data file 203: '/sun2int1/oracle92/app/oracle/product/9.2.1/oradata/TPRS/temp03.dbf'
ORA-06512: at "SYS.DBMS_LOB", line 424
ORA-06512: at "SYS.DBMS_METADATA", line 1140
ORA-06512: at line 1
EXP-00000: Export terminated unsuccessfully
when i did the restore, i simply renamed the datafiles and redo logs.
But i didnt rename the TEMP datafile, as you can not rename it with a "alter database rename file ..." command
so thats the problem!
i planned to create a new default temp. tablespace, and simply make it default and drop the other one. but it does not work!
i tried to execute:
CREATE TEMPORARY TABLESPACE temp4 TEMPFILE '/oracleAS/TPRS/oradata/TPRS/temp4.dbf' SIZE 5M REUSE AUTOEXTEND ON NEXT 1M MAXSIZE unlimited
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;
create temporary tablespace temp01 tempfile '/oracleAS/TPRS/oradata/TPRS/temp01.dbf' size 100M;
but they all hang! i wait, but nothing happens! (and alert log does not log anything too)
and finally i tried to drop the default tablespace, and i couldnt drop it as i thought. (ORA-12906: cannot drop default temporary tablespace
So, im stuck and i beleive i have to RENAME the datafile for temporary tablespace. how can i do this?
Edited by: merope on Jun 9, 2009 11:32 AM

SQL> col file_name for a50
col status for a15
col tablespace_name for a15
col PROPERTY_VALUE for a20
select file_name,tablespace_name,bytes/1024/1024 as "SIZE_IN_MB",status,autoextensible from dba_temp_files;
SELECT PROPERTY_NAME,PROPERTY_VALUE FROM DATABASE_PROPERTIES where PROPERTY_NAME='DEFAULT_TEMP_TABLESPACE';
SQL> SQL> SQL> SQL> SQL> SQL> ERROR:
ORA-01157: cannot identify/lock data file 202 - see DBWR trace file
ORA-01110: data file 202: '/izmir1/oradbTPRS/temp1.db'
no rows selected
SQL>
PROPERTY_NAME PROPERTY_VALUE
DEFAULT_TEMP_TABLESPACE TEMP3
This is not the actual directory: /izmir1/oradbTPRS/temp1.db
it is the old location, but in the restored db, the temp1.db file is in some other directory
how can i rename this?
Edited by: merope on Jun 9, 2009 11:50 AM

Rollback segment number not shown with name " not shown " too small

Hi,
we have a table TABLE1 with a BLOB field FIELD1 on a Oracle 10g database. Today we found out that there is one record in that table that make problems. if we try to read the BLOB data from that record, Oracle shows the error:
ORA-01555: snapshot too old: rollback segment number with name "" too small
The strange thing about it, that the message shows neither the segment number nor the segment's name. Like it has lost the reference to it.
Could you help please.
Notes:
The TABLE1 and the BLOB data are really not big.
The UNDO tablespace is 2Gb big and just 1% used.
Thank you very much
Igor

Out-of-row LOB undo is maintained in the LOB segment. So the UNDO tablespace and undo retention is not associated with most LOB ORA-1555 issues. Instead the LOB column is created using either PCT_VERSION or RETENTION to manage how much space within blocks or time transpires before the LOB undo is overwritten. In environments with high updates, deletes on rows including LOBs, the chances of ORA-1555 on LOB undo is very high.
Source:http://blogs.oracle.com/db/entry/troubleshooting_ora_1555
In the above link you will get plenty of good metalink notes to understand and solve the issue.
There is no undo segment name in the error message means this error has no relation with undo tablespace/parameter/segment. This might mean that your LOB table is corrupted. Can you drop and recreate/re-populate this table and try again ?
Srini Chavali @ Another "snapshot too old: rollback segment number with name "" too small"
Regards
Girish Sharma

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.

ODT error in VS2005: Value was either too large or too small for an Int32

Using ODT's Oracle Explorer in VS2005 I connected to a 3rd party's Oracle9i database that's been around for a while. I expanded the tables node and then attempted to expand a specific table. It then displayed a popup message and never expanded the table so I could manage the columns.
The error is:
An error ocurred while expanding the node:
Value was either too large or too small for an Int32
I recreated the table, with no data, in another database (same version of oracle, different physical server) and was able to expand the table in ODT's Oracle Explorer.
I went back to the other database in Oracle Explorer and tried to expand the table and it failed with the same error message.
The only difference I can see is that the first table contains ALOT of data (gigabytes), while the other table (the duplicate I created to duplicate the error) does not have any data.
here's the definition of the table minus the actual table and field names.
FLD6 contains jpg data from a 3rd party Oracle Forms application. The jpg data is between 100K and 20MB.
CREATE TABLE myTable
FLD1 VARCHAR2(30 BYTE),
FLD2 VARCHAR2(15 BYTE),
FLD3 VARCHAR2(20 BYTE),
FLD4 VARCHAR2(20 BYTE),
FLD5 NUMBER(3),
FLD6 LONG RAW,
FLD7 VARCHAR2(80 BYTE),
FLD8 DATE,
FLD9 VARCHAR2(20 BYTE),
FLD10 VARCHAR2(20 BYTE),
FLD11 VARCHAR2(99 BYTE),
FLD12 VARCHAR2(256 BYTE)
TABLESPACE myTableSpace
PCTUSED 0
PCTFREE 10
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 2048M
MINEXTENTS 1
MAXEXTENTS 2147483645
PCTINCREASE 0
BUFFER_POOL DEFAULT
LOGGING
NOCOMPRESS
NOCACHE
NOPARALLEL
NOMONITORING;
This is just to let the developers know I ran into a problem. I've already gotten around the issue by using an alternative tool.

Hi,
You can also use the Map TestTool to test your maps. It uses the BizTalk engine to execute the map. You can select a map that is deployed to the GAC en execute it.
You can download the sample tool with the source code here:
TestTool for BizTalk 2013
http://code.msdn.microsoft.com/Execute-BizTalk-2013-maps-e8db7f9e
TestTool for BizTalk 2010
http://code.msdn.microsoft.com/Execute-a-BizTalk-map-from-26166441
Kind regards,
Tomasso Groenendijk
Blog
| Twitter
MCTS BizTalk Server 2006, 2010
If this answers your question please mark it accordingly

Dump roll back segment too small

Hii All,
From last week i am getting this dump in my production system.
Database error text........: "ORA-01555: snapshot too old: rollback segment
number 20 with name "PRS_18" too small#"
Internal call code.........: "[RSQL/FTCH/MKPF ]"
What should i do to avoid this dump.
Regards,
Viren.

HI Rana,
When you have "ora-01555: snapshot too old (rollback segment _ too small)", it usually means failure due to the lack of rollback space. The failure indicates read consistency error, as your active transaction overwrites existing, uncommitted transaction, which implies that the system change number SCN in the block is newer than the SCN at the start of the transaction. The read consistency image of new data can therefore not be created. This can happen when large transactions are being written where there is not enough tablespace for the rollback segments to expand or when the rbs has reached its "MAXEXTENTS".
Solution is to either add new roll back segment or extend the size of the existing ones.To extend the size of existing ones, increase both the values of their MINEXTENTS and OPTIMAL parameters with ALTER ROLLBACK SEGMENT statement or create additional ones.
Thanks
Prince Jose

Drop Temp tablespace hangs...

I have created a new TEMP tablespace and made it default TEMP one.
Now I want to drop TEMP3 tablespace, because it has become fulll...
when I drop it through EM, it hangs...
Once a tablespace has been dropped, the objects and data in it will no longer be available. To recover them can be a time consuming process. Oracle recommends a backup before and after dropping a tablespace.
Are you sure you want to delete Tablespace TEMP3?
Delete associated datafiles from the OS
When I checked at EM, there are locks too..
SMON has locked the system
What should I do now?

The_Rock wrote:
I have created a new TEMP tablespace and made it default TEMP one.
Now I want to drop TEMP3 tablespace, because it has become fulll...
when I drop it through EM, it hangs...
Once a tablespace has been dropped, the objects and data in it will no longer be available. To recover them can be a time consuming process. Oracle recommends a backup before and after dropping a tablespace.
Are you sure you want to delete Tablespace TEMP3?
Delete associated datafiles from the OS
When I checked at EM, there are locks too..
SMON has locked the system
What should I do now?Refer
Drop Temp Tablespace Command Hangs [ID 214371.1]
How to Drop Temporary Tablespace Having Enteries in V$SORT_USAGE [ID 285993.1]

Drop Temp Tablespace

DB 10.2.0.4
AIX 5.2
PROD
I am trying to drop temp tablespace as below command. It is running since nine hours I am not understand why it is taking too much time. FYI I have created a new temp and assigned to default temporary tablespace. Even I connected with new session and run “drop tablespace temp” it is also running since one hour. Suggest me.
DROP TABLESPACE temp INCLUDING CONTENTS AND DATAFILES;
Thanks

user11969485 wrote:
FYI Holder session is "oracle@devdb (SMON)"
Edited by: user11969485 on Jan 7, 2012 12:49 AMYes, Looks like you hitting a BUG.
Check this note Bug 3833893: SMON GETS "TT ENQUEUE" OF TEMP IF DATEFILE OF TEMP DOESN'T EXIST
It saying to drop files from mount status. Lets try :)
Keep Close the Threads, So it meaningful as those answered.
user11969485      Newbie
Handle:      user11969485
Status Level:      Newbie (10)
Registered:      Oct 27, 2009
Total Posts:      302
Total Questions:      66 (57 unresolved)
Edited by: CKPT on Jan 7, 2012 2:36 PM

TEMP Tablespace too small

Similar Messages

Maybe you are looking for