Drop tablespace temp going forever

Similar Questions

• Drop tablespace Temp, in windows

  I decided to pass the tablaspace on another disk TEMP have more default disk storage space.
  I create new TEMP and as a default value.
  Then I put old Temp offline and drop it. Everything is Ok for EM.
  The problem is that can not remove the file in SO. because the file is in use.
  
  Why is being used? Are a problem with windows?
  
  Can some help me?
  
  I use Oracle 10.2.0.1 to 64 bytes and Windows 2003 Enterprise 64 bytes.

  It is provided in windows. If you restart your db, the file will go.

  Please see the following for a similar description:

  Re: tempfile not deleted at the OS level

  Published by: SKU on March 19, 2009 07:41

• change tablespace temp problem

  Hi guys,.
  
  my old temp tablespace was DMT and grown huge. So I created a new LMT one using a temporary file. I also modified the temporary tablespcae by default my database of TEMP2.
  
  Select distinct (temporary_tablespace) in dba_users
  
  TEMP2
  
  
  Now I'm trying to
  
  SQL > drop tablespace temp including contents;
  
  and it takes ages as expected. However, what I've noticed, is that this temp tablespace seems still to be used! It remains 100% free, and this one is free space is declining.
  
  is it possible for me to delete this file in the system files, and then start my nomount database and re-create the control file?
  
  Thank you

  Here my procedure I use to delete it and create a new temp

  create tablespace temporary temp2 tempfile ' / oracledata/DB/temp999.dbf' size 500M management of local measure;

  ALTER DATABASE by DEFAULT TABLESPACE TEMPORARY temp2;

  DROP TABLESPACE temp including CONTENTS AND DATA files;

  create tablespace temporary temp tempfile ' / oracleindex/DB/temp01.dbf' size, 1025M
  ' / oracleindex/DB/temp02.dbf' size 1025 M, ' / oracleindex/DB/temp03.dbf' size, 1025M
  ' / oracleindex/DB/temp04.dbf' size 1025 M, ' / oracleindex/DB/temp05.dbf' size, 1025M
  ' / oracleindex/DB/temp06.dbf' size 1025 M, ' / oracleindex/DB/temp07.dbf' size M 1025
  extent management local uniform size 1048576;

  ALTER DATABASE default TEMPORARY TABLESPACE temp;

  DROP TABLESPACE temp2 including CONTENT AND DATA files;

• Application of segment SS Enqueue and fate on 8.1.7.4 after attempting to drop the temp tablespace

  We have a case opened with the support of the Oracle, but I thought I'd throw it out there if it's ok.

  We have a 8.1.7.4 database running on HP - UX 11.11 PA-Risc and it looks like any session that wants to use a temp space is hung a SS enqueue or in some cases is waiting on a waiting "sort request of the segment.

  Saturday, we tried to move all users to a new temporary tablespace and drop the old one but the drop suspended and we control-C out of it.  We put the users to the original temp.  Note that both the old and the new temporary tablespaces are managed locally.

  Before trying to leave falling the old tablespace temp that we killed the existing sessions, including one who had worked for two weeks and has been hooked on SMON.

  Query v$ fast_start_transactions and x$ ktuxe indicate that SMON is back any large transaction.

  In addition, SMON seems to run this query always:

  SELECT file #, block #, LENGTH

  The UET $

  WHERE the ts # =: 1 AND segfile # =: 2 AND segblock # =: 3 AND ext # =: 4

  Here are the locks held by SMON for what it's worth:

  ADDR KADDR SID TY ID1 ID2 LMODE CTIME BLOCK REQUEST
  ---------------- ---------------- ---------- -- ---------- ---------- ---------- ---------- ---------- ----------
  C000000028C43CD8 C000000028C43CF8 74 16 4 0 59610 TT 8 0
  C000000028C43C68 C000000028C43C88 TS 74-666633304 8 6 0 0 59650
  C000000028C1CB38 C000000028C1CB58 8 ST 0 0 6 0 13 0

  ST, space management Transaction
  TS, temporary Segment (also TableSpace)
  TT, temporary Table

  Same database has a recovery scenario about a month or to go back due to some deleted data files.  Also, during the holidays, we had to rebuild a global index huge and increased our tablespace temp to get it, which is why we strive to reduce now create a smaller.  In addition, creating index was still holding in the tablespace existing managed dictionary so we ended up move the index to a managed locally.  Also, UET$ has about 33,000,000 lines and most of the data is in the dictionary managed tablespaces.  Dba_free_space queries typically take 30 minutes to return - that is, we know it is messed up and has been so for a long time.

  Pleasure for us.  If anyone has an idea that would be great.

  -Bobby

  Tablespace name I really used corresponded to ts #= 74 in v$ tablespace.

  We plan to rebuild the other indexes in this space in a new locally managed tablespace and then drop the tablespace existing managed dictionary.  My only question is whether corruption will drop the tablespace to fail.

  Hi Bobby,.

  I'm not sure of your current situation hope now, that's better.

  I couldn't find the time to reply back yesterday. Looking at the huge amounts of temporary segments in your tablespace (74), just made me think if you or Support of Oracle were you made aware of an event DROP_SEGMENTS which is an event of users can invoke to clear temporary segments. It deletes the temporary segments such as the SMON in the background. This event has the advantage of not having the CPU consumed by SMON.

  47400.1 Note : EVENT: DROP_SEGMENTS - forcing cleanup of TEMPORARY segments

  There is also a method to the dictionary (changes) patch (not recommended if not). You can enlist the help of Oracle Support

  The method is to identify the segment (which you already have) and update the segment_type from temporary to 999.

  388619.1 Note: last resort when SMON takes 100% of CPU

  Kind regards

  Suntrupth

• Drop tablespace temporal

  Hi all
  
  I work with a RAC 11.2.0.1. I need resize the temp tablespace. To do this, I created a new tablespace temp with the right size and I have set up as storage space for the default database. Then I try to drop the old temp tablespace but when I run the sentence of drop, it never ends.
  
  I look and I see a few idle sessions use the old temp tablespace.
  
  How can I make it? Any ideas?
  
  Best regards
  dbajug

  What kind of error do you get? Old sessions still use tablespace old_temp. You can find this out using session $ v. There are 2 ways 1) wait while users end their operation that uses the old_temp tablespace (in order to...) 2) kill all the session using old_temp. And try again

• Question of Tablespace Temp datafile.

  Hi Oracle gurus,
  
  the problem occurred when my file temp01.dbf to increase the size of certain MBs to 30 GB! (Within weeks)
  without doing RnD on advice, datafile temp01.dbf has been deleted! ,
  now a text file has been created, I renamed it with the same name 'temp01.dbf '!
  
  now my tasks fail with the error:
  
  1157: 64000: java.sql.SQLException: ORA-01157: cannot identify/lock data file 201 - see DBWR trace file
  ORA-01110: data file 201: ' C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TEMP01. DBF'
  
  I tried to add a data file over to the storage space according to the steps below:
  1. connect to sqlplus DBA (user sys)
  2. stop; -Removed database and Oracle Instance will stop.
  3. start; -Oracle instance started.
  4 run this query
  alter tablespace temp add datafile
  ' C:\oracle\product\10.2.0\oradata\orcl\TEMP02. DBF' SIZE 32 M;
  
  but still the error points to Temp01.
  
  The funny part, I wrote here that I don't get the name of the data file anywhere in the comic book.
  
  I've run this query below
  
  SELECT FILE_NAME IN DBA_DATA_FILES;
  
  and there is no name of data file with "Temp01" or "Temp02".
  
  I get the name 'TEMP' Tablespace when performing "SELECT TABLESPACE_NAME FROM DBA_TABLESPACES";
  
  to add more of what the above
  
  I tried to delete the file with the name 'TEMP01. DBF. "
  by running
  
  alter tablespace temp drop datafile
  ' C:\oracle\product\10.2.0\oradata\orcl\TEMP01. DBF';
  
  I get the following error:
  ORA-03219: Tablespace 'TEMP' is managed by dictionary, offline or temporary
  
  This storage space (TEMP) is temporary (Default) and his allocation_type is uniform
  
  
  I'm looking for
  
  1 remove the Temp01 data file and rename the temp02 with her.
  2 allow the name of auto extension datafile renamed as well as default data temp file features.
  
  I'm at the point of no return?..... .i am new to this level of work... I tried to solve the problem by taking the forumns References... somwhr but still missing...
  
  Need help to solve this problem.

  Hello

  4 run this query
  alter tablespace temp add datafile
  ' C:\oracle\product\10.2.0\oradata\orcl\TEMP02. DBF' SIZE 32 M;

  but still the error points to Temp01.

  the query should be as below

  ALTER TABLESPACE
  Add TEMPFILE '' SIZE M;
  example:
  ALTER TABLESPACE temp_new
  Add TEMPFILE ' / u02/oradata/tempnew02.dbf' SIZE 200 M;

  >

  The part funny, I noted here that I don't get the name of the file of data anywhere in the DB.

  I've run this query below

  SELECT FILE_NAME IN DBA_DATA_FILES;

  and there is no name of data file with "Temp01" or "Temp02".

  We are unable to display a temporary file in dba_data_files... It's funny...

  Use tempfile $ v and v$ temp_space_header to view a temporary file...

  to make offline / online
  ALTER DATABASE TEMPFILE '' offline / online;

  MAKE USE OF THE TEMPORARY TABLESPACE DEFAULT

  ALTER TABLESPACE TEMPORARY for executives from the DATABASE default;

  the use of thiese views

  SELECT *.
  FROM database_properties
  Property_name WHERE = 'DEFAULT_TEMP_TABLESPACE ';

  SELECT file_name, nom_tablespace
  FROM dba_temp_files;

  Kind regards
  Deepak

• Restored coldbackup and trouble with tablespace TEMP

  Hi, I've successfully restored from a coldbackup on solaris. (oracle 9.2)
  I can connect to databases using toad, query the database, but when I try to take an export or something I got the error
  
  EXP-00056: ORACLE error 1157
  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 completed unsuccessfully
  
  
  When I did the restore, I simply rename the data files and redo logs.
  But I was not rename the TEMP data file, as you can rename it with a command 'alter database rename file... ". »
  That's the problem!
  
  I plan to create a new default temp. tablespace and simply do it by default and a drop. but it does not work!
  
  I tried to run:
  
  CREATE a TABLESPACE TEMPORARY TMP4 TEMPFILE ' / oracleAS/TPRS/oradata/TPRS/temp4.dbf' SIZE 5 M REUSE AUTOEXTEND ON NEXT 1 M MAXSIZE unlimited
  EXTENT MANAGEMENT UNIFORM LOCAL 1 M SIZE;
  
  create tablespace temp01 temporary tempfile ' / oracleAS/TPRS/oradata/TPRS/temp01.dbf' size 100M;
  
  but they all hang! I wait, but nothing happens! (and the alert log will not connect anything too)
  
  Finally, I tried to drop the default tablespace and I couldn't let it go as I thought. (ORA-12906: cannot remove the temporary tablespace default)
  )
  
  So, im stuck and I think I should RENAME the data file for the temporary tablespace. How can I do this?
  
  Published by: merope on June 9, 2009 11:32

  I just found this link:
  http://dbaforums.org/Oracle/lofiversion/index.php?t4552.html
  which is something talk no problem of tablespace temp cold backup restore. In the end, it's say that the OP got solution due to the existence of a DDL trigger or something like that.

  HTH
  Girish Sharma

• tablespace Temp problem

  I want to run this commnad all in one, I create PL/SQL, but I give the error and save the txt file and run of I also give me error when I complie and statements into a toad, it compiles successfully, please tell me how to create a procedure or block anoymous. because I wanted to create a task that runs automatically please help my in this regard, please tell me can we shrink in the temporary tablespace
  
  CREATE TABLESPACE TEMPORARY TEMP_new1
  
  RE-USE of 50 M SIZE TEMPFILE 'TEMP_new1 '.
  
  AUTOEXTEND ON NEXT 32 M MAXSIZE unlimited
  
  EXTENT MANAGEMENT UNIFORM LOCAL 32 M SIZE;
  
  
  
  ALTER DATABASE default TEMPORARY TABLESPACE TEMP_new1;
  
  
  DROP TABLESPACE TEMP_ABC INCLUDING CONTENT AND DATA FILES;
  
  
  CREATE THE TEMPORARY TEMP TABLESPACE
  
  TEMPFILE 'TEMP01.dbf' SIZE 50 M REUSE
  
  AUTOEXTEND ON NEXT 32 M MAXSIZE unlimited
  
  EXTENT MANAGEMENT UNIFORM LOCAL 32 M SIZE;
  
  ALTER TABLESPACE TEMPP add TEMPFILE 'temp02' SIZE 50 M
  AUTOEXTEND ON NEXT 32 M MAXSIZE UNLIMITED;
  
  ALTER TABLESPACE TEMPP add TEMPFILE 'temp03' SIZE 50 M
  
  AUTOEXTEND ON NEXT 32 M MAXSIZE UNLIMITED;
  
  ALTER TABLESPACE TEMPP add TEMPFILE 'temp04' SIZE 50 M
  
  AUTOEXTEND ON NEXT 32 M MAXSIZE UNLIMITED;
  
  ALTER TABLESPACE TEMPP add TEMPFILE 'temp05"SIZE 50 M
  
  AUTOEXTEND ON NEXT 32 M MAXSIZE UNLIMITED;
  
  ALTER DATABASE DEFAULT TEMPORARY TEMP TABLESPACE;
  
  DROP TABLESPACE TEMP_new1 including CONTENT AND DATA files;

  sql_stmt: = "ALTER DATABASE default TEMPORARY TABLESPACE TEMP1"

  you need to end the statement with '; '.

• Precisely how to find freespace in tablespace Temp

  DB version: 11.2.0.4

  Platform: Oracle Linux 6.4

  It seems that finding the space left in the temporary tablespace is not simple.

  Question1.

  These are the descriptions of column to see DBA_TEMP_FREE_SPACE

  ALLOCATED_SPACE: Total allocated space, in bytes, including the currently allocated space

  and used and the space that is currently allocated and available for reuse

  Free_space: Total free space available in bytes, including the space which is currently assigned and available for

  reuse and the space that is currently not allocated

  http://docs.Oracle.com/CD/E11882_01/server.112/e40402/statviews_5062.htm#REFRN23627

  I'm not native English, but aren't the words in red above for the column ALLOCATED_SPACE a wrong repetition?

  Question2. In 10g, when you see zero space left in the Temp tablespace, allows us to add more space to the tablespace TEMP immediately to prevent ORA-1652: unable to extend temp segment . 11 g, is there an architectural change by what TEMP segments are recycled internally (like UNDO segments) so that we don't have to worry much when we see the 0 space in tablespace temp?

  Question3. For the same database, the results of two queries are listed below. The news of freespace vary between QueryA and QueryB.

  Which is the correct output; QueryA or QueryB?

  -QueryA using dba_temp_free_space

  Select nom_tablespace,

  totalGB tablespace_size/1024/1024/1024,

  AllocSpaceGB ALLOCATED_SPACE/1024/1024/1024,

  free_space/1024/1024/1024 FreeSpaceGB

  of dba_temp_free_space;

  NOM_TABLESPACE TOTALGB ALLOCSPACEGB FREESPACEGB

  ------------------------------ ---------- ------------ -----------

  TEMP 125.99707 125.748047 69.9150391

  -QueryB using v$ sort_segment

  SELECT A.tablespace_name, D.gb_total, tablespace

  SUM (A.used_blocks * D.block_size)/1024/1024/1024 gb_used,)

  D.gb_total - SUM (A.used_blocks * D.block_size)/1024/1024/1024 gb_free)

  V $ sort_segment A.

  (

  SELECT B.name, C.block_size, SUM (C.bytes)/1024/1024/1024 gb_total

  V $ tablespace B, v$ tempfile C

  WHERE B.ts # = C.ts #.

  B.name GROUP, C.block_size

  ) D

  WHERE

  D.name = A.tablespace_name

  GROUP A.tablespace_name, D.gb_total;

  TABLESPACE GB_TOTAL GB_USED GB_FREE

  ------------------------------- ---------- ---------- ----------

  TEMP 125.99707 22.6992188 103.297852

  So, this could mean that oracle will be reuse TEMP segments internally and Temp space needs to be increased if

  you see errors ORA-1652 in the alerts log. Right?

  
  

  I rarely answer even in this case.  It is usually a transient problem with enriched work.  Only when it becomes quite persistent to impact business operations should I address it.  When I receive an event, the first thing we do is to go to the guy in charge of the related enterprise application and ask if his phone rings.  If this isn't the case, I don't worry about this. And even if it causes a business problem, the solution may be to increase the size of the TS but to identify a particularly evil-wise query.  The last time that I had to deal with this error was due to a broad and complex query generating a large intermediate result set.  The solution should not continue to increase the TEMP TS (which turned out be "whack-a-mole") but to create a materialized view to reduce the amount of data that had to be picked up and joined running.

• ORA-1652: unable to extend segment temp of 128 in tablespace TEMP

  Hi all

  We receive ora 1652 error because since a few days, I increased the temporary table space for nearly 20 GB, but it still keeps to launch error

  Following errors written to the alert log file. Please check

  **********************************************************************

  Date: 26/12/13 Thursday 22:44:01

  **********************************************************************

  ORA-1652: unable to extend segment temp of 128 in tablespace TEMP

  ORA-1652: unable to extend segment temp of 128 in tablespace TEMP

  ORA-1652: unable to extend segment temp of 128 in tablespace TEMP

  ORA-1652: unable to extend segment temp of 128 in tablespace TEMP

  ORA-1652: unable to extend segment temp of 128 in tablespace TEMP

  ORA-1652: unable to extend segment temp of 128 in tablespace TEMP

  ORA-1652: unable to extend segment temp of 128 in tablespace TEMP

  After some research, I found that query below is causing such huge operation & the invasion of the temporary space

  Select distinct s.serialnr, s.shipdate, s.cpc, s.country, s.description, s.soldt

  oparty, s.shiptoparty, s.ean_code, registration_crm_serial_n s.shipserialnr

  Join s Pascale registration_crm_serial_number s2 left s.serialnr = s2.shipseria

  NRL where (s2.serialnr =: 1 or s.serialnr =: 2) and s.shipserialnr is null

  I have only 10 GB of space left on my mount point and may not increase any more space for the temporary table space.

  version of database-10 g

  one question und an additional comment:

  1. is the separate necessary? This is the reason for sorting - and when I see a distinct, I always start to think if it is useful...

  2. an outer join with:

  left outer join t2 t1 (t1.col1 = t2.col1) where t2.col2 = 'something '.

  is therefore more an outer join for the t2.col2 condition = 'something' deletes all attachments outside your result NULL values

• Drop tablespace and recreate a new!

  Hi all

  Of my database (oracle 10g, aix server) has a tablespace called tools for xample. its size is nearly 16g, but current use is about 170 MB only. So I want to resize the size of tablespace to 2G

  So what I've done, taken separately export tools tablespace and backup full export. so in my hand, I, tablespace backup tools (export file) and backup of the entire database (taken using new utility exp)

  Now, I tried to drop the tablespace tools and got this error

  SQL > DROP TABLESPACE TOOLS including CONTENTS AND DATA files;

  DROP TABLESPACE TOOLS INCLUDING CONTENTS AND DATA FILES

  *

  ERROR on line 1:

  ORA-29857: domain indexes and/or secondary objects exist in the tablespace.

  so I planned too, instead of dropping the tablespace, I thought the deletion of objects in storage space and resize and import using the backup of what I have.

  When I interrogate the tablespace, I had 4 object. indexes, tables, lobindex and lobsegment.

  I wrote the script to delete the index and dint tables.but run again.

  How delete/move, lobindex, and lobsegment, so that I can resize the tools tablespace?

  someone has experienced this problem? or any other method is over come this problem?

  Please provide detailed step if you did.

  Kind regards

  Pradeep. V

  1. create a new tablespace with the expected size

  2. move the original SCT to the second object

  ALTER table move

  change the index rebuild

  ALTER table move lob () store (tablespace )

  The lobindex will follow by itself.

  3. be sure that the original tablespace is now empty

  4. remove the original tablespace

  5 rename the new tablespace as former

  alter tablespace and rename

  Nicolas.

• Drop tablespace and flashback: ORA-01245: offline file 7 will be lost if RESETLOGS is done

  Hello
  
  1. create tablespace TS1
  2. create restore RP1 point;
  3 drop tablespace TS1 (datafile ' / c:/ts1.dbf ') including files
  4 restore database to RP1
  5 alter database open resetlogs failed with this error:
  ERROR on line 1:
  ORA-01245: offline file 7 will be lost if RESETLOGS is done
  ORA-01110: data file 7: ' / c:/ts1.dbf '
  
  Can you help me please to solve this problem and to understand why it happened.
  
  

  Hello

  If you check the log of alerts you will get message similar to

  Remove the #7 file recovery:'/db/dbs/UNNAMED00007 ' of controlfile.

  Now you have 2 possible

  1. If you have backup of the tablespace TS1, then you can restore and recover

  If you do not need this tablespace then you drop that datafile offline 7. Open the database in resetlogs mode and drop the tablespace TS1

  Thank you

• Drop tablespace problem

  We had several tablespaces which must be "purged" from the database.  These storage spaces contains tables which were divided.  We have abandoned all partitions in the range of dates for a few years, with a value of data no longer needed to free up space.  All partitions are now moved after we had to disable some referential forced and now we tried to drop one of the tablespaces...

  SYS > drop tablespace DATA_200812 including content and data files of cascade constraints;

  ORA-14407: partitioned table contains the subparts in a different tablespace

  NOTE: Do not care about the table space (s) and think that all the data has actually disappeared...

  SYS > select nom_segment, segment_type, bytes/1024/1024 "MB" IN dba_segments WHERE

  2 SEGMENT_TYPE = 'TABLE_PARTITION' and nom_tablespace = 'DATA_200812 ';

  no selected line

  But how can do us to 'clean up' all of these "empty" tablespaces so that they do not appear in our OEM?

  We are pretty sure having abandoned these old partitions releases plenty of space, even if not giving him not to return to the operating system, which was our initial objective, maybe just forget all the cleaning as it is seems just "metadata" now in any case...

  Anyone have any suggestions?

  >

  Query should be replaced by

  >

  No - as I said above OP must REMOVE SEGMENT_TYPE of the query altogether.

  The tablespace cannot be deleted if there are used segments. There is no point at all limiting the types.

• Tablespace Temp created primary not replicated to standby mode

  Hello
  
  I configured Oracle 9i data guard recently, while doing, that I was forced to restructure primary db since maxlog files was 5, so I used backup controlfile to trace and changed the maxlogfiles to 6 and then transported the remaining steps. While I was using the trace file and restructuring of the Db, I did not notice that I missed to add the temporary file and moving it in standby mode. Yest.Day once get a team request error, that I created a new tablespace temp and logs switch made, however this tablespace temp tempfile was not copied to the standby server. Does this cause anything serious or can I do now to copy it in standby? Only the manual copy with primary db shutdown or any other means?

  standby
  SQL > SELECT NAME FROM V$ TEMPFILE;

  no selected line

  Use the commands below

  SQL > alter tablespace add tempfile ' D:\ORACLE\ORADATA\CTSOC\TEMPNEW01. DBF' size 31457280;

  If you take controlfile trace (or) metadata, you can see command DDL that too.
  Thank you.

• UNDOTABLESPACE and TABLESPACE TEMP in cold or hot backup database

  Hello
  
  I have a BACKUP, including logs generated after the backup archive. What is the use of the UNDOTABLESPACE and TABLESPACE TEMP datafile data file backup? When it is used?
  
  
  Kind regards
  
  007

  >
  I have the archives which have all entries are committed in it. Undoinformation is necessary for the restoration and recovery of the database? Can u explain more clearly?
  >

  The archives are as congested entries of redo logs. And the redo logs contain all changes to the database. Information cancellation will be there in the segments of cancellation that there can be some uncommitted transactions active in the segments of cancellation. Cancellation information is necessary to put the database in a consistent state. It is one of very important storage similar to the control file and system tablespace to bring a database

  Edited: Imagine a scenario. You make a backup hot at 07:00. And there are a lot of transactions happening before and during hot backup. For ex, I run a massive update to a table. This will cause the recovery to write logs of recovery that will be eventually written to logs archived. Now, you finish the backup mode. But I have not validated or cancelled my transaction. Say to the reasoning, I roll back the transaction.

  Now, you restore the backup. Do you think that my transaction will be in inconsistent state? Redo logs and archiveed newspapers had my transaction changes/redo entries. If you are not using undo in recovery segments, what will happen to my operation that I rolled back? Without cancel, half of my transaction (even if they were not truly committed) will be sitting in the database. This is where undo tablespace helps us in rolling back the transaction during your recovery. Remember, the cancellation information "peuvent" not all in recovery if you do not a complete database recovery. But Oracle should know that. If you need to undo tablespace in your backup set.

  I hope it's clear now

  Published by: VenkatB on Sep 15, 2011 10:17