Issue with SYSAUX tablespace.

Without backup and any old archivelog(more then last five days),IN RAC environment we are trying to recover one of datafile of our SYSAUX tablespace which is in RECOVER state.
sysaux tablespace having two datafile,while making online to second datafile it's asking for last month archivelogs which we dont have And while making online to SYSAUX tablespace it's giving error that one of your database datafile recquire recovery.
ORA-00279: change 195638767 generated at 08/10/2009 14:17:27 needed for thread 1 while recovering by auto
recover datafile 42;
ORA-15173: entry '1_15271_682264878.dbf' does not exist in directory 'csdprod'

Jaroslaw Bicz wrote:
Hi
I'm having some issue with SYSAUX tablespace. it have 36GB Allocated Size but only 2GB used. Is there a way to reuse free space. it is oracle 10.2.0.4 on red hat.
Regards
JarekOracle doesn't recommend to use SYSAUX tablespace to store user data on it

Similar Messages

  • Restore Database to non-ASM Storage - Issue with Bigfile Tablespace

    I have been testing a restore of my prod database that uses ASM (and oracle managed files) for storage to a different server and non-ASM storage. Oracle version is 10g EE. My database has one bigfile tablespace and it's datafile is about 250GB. The restore fails and it has something to do with the bigfile tablespace.
    Here is the rman restore script:
    run
    set newname for datafile 1 to '/ora01/db/ehr/system01.dbf';
    set newname for datafile 2 to '/ora01/db/ehr/undotbs01.dbf';
    set newname for datafile 3 to '/ora01/db/ehr/sysaux01.dbf';
    set newname for datafile 4 to '/ora01/db/ehr/undotbs02.dbf';
    set newname for datafile 5 to '/ora01/db/ehr/users01.dbf';
    set newname for datafile 6 to '/ora01/db/ehr/apolloaud01.dbf';
    set newname for datafile 7 to '/ora01/db/ehr/apollohist01.dbf';
    set newname for datafile 8 to '/ora01/db/ehr/apolloidx01.dbf';
    set newname for datafile 9 to '/ora01/db/ehr/apollotab01.dbf';
    set newname for datafile 10 to '/ora01/db/ehr/apollotab02.dbf';
    set newname for datafile 11 to '/ora02/db/ehr/apollolob01.dbf';
    set newname for datafile 12 to '/ora01/db/ehr/apollofdb01.dbf';
    set newname for datafile 13 to '/ora01/db/ehr/apolloidx02.dbf';
    set newname for datafile 14 to '/ora01/db/ehr/apolloidx03.dbf';
    set newname for datafile 15 to '/ora01/db/ehr/apolloaud02.dbf';
    set newname for datafile 16 to '/ora01/db/ehr/apollotab03.dbf';
    set until sequence 60298 thread 2;
    restore database;
    switch datafile all;
    recover database;
    Datafile 11 is the datafile in the bigfile tablespace. Here are the weird things about the restore:
    1. The restore output shows this:
    creating datafile fno=11 name=/ora02/db/ehr/apollolob01.dbf
    channel ORA_DISK_1: starting datafile backupset restore
    channel ORA_DISK_1: specifying datafile(s) to restore from backup set
    restoring datafile 00001 to /ora01/db/ehr/system01.dbf
    restoring datafile 00002 to /ora01/db/ehr/undotbs01.dbf
    restoring datafile 00003 to /ora01/db/ehr/sysaux01.dbf
    restoring datafile 00004 to /ora01/db/ehr/undotbs02.dbf
    restoring datafile 00005 to /ora01/db/ehr/users01.dbf
    restoring datafile 00006 to /ora01/db/ehr/apolloaud01.dbf
    restoring datafile 00007 to /ora01/db/ehr/apollohist01.dbf
    restoring datafile 00008 to /ora01/db/ehr/apolloidx01.dbf
    restoring datafile 00009 to /ora01/db/ehr/apollotab01.dbf
    restoring datafile 00010 to /ora01/db/ehr/apollotab02.dbf
    restoring datafile 00012 to /ora01/db/ehr/apollofdb01.dbf
    restoring datafile 00013 to /ora01/db/ehr/apolloidx02.dbf
    restoring datafile 00014 to /ora01/db/ehr/apolloidx03.dbf
    restoring datafile 00015 to /ora01/db/ehr/apolloaud02.dbf
    restoring datafile 00016 to /ora01/db/ehr/apollotab03.dbf
    Why at the beginning is it "creating" datafile 11? Then it doesnt even say it is "restoring" that datafile. Only restoring datafiles 1,2,3,4,5,6,7,8,9,10,12,13,14,15, and 16.
    When it creates datafile 11 it is only 26GB, that is much smaller than it should be according to v$datafile view on source prod database. Also even though it says it is creating datafile 11 as /ora02/db/ehr/apollolob01.dbf it actually creates it as an oracle managed file at /ora02/db/ehr/EHR/datafile/o1_mf_apollolo_6crxyqs2_.dbf
    After the datafiles are restored the "switch datafile all" command fails:
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of switch command at 10/18/2010 13:58:37
    ORA-19625: error identifying file /ora02/db/ehr/apollolob01.dbf
    ORA-27037: unable to obtain file status
    Linux-x86_64 Error: 2: No such file or directory
    Additional information: 3
    So my question is how do I get this database restored to non-ASM (and non omf)?

    So I tried using a different scn with my "set until scn #####" then the restore created 2 datafiles. The datafile for apollolob and apollotab02.dbf. So I think I have narrowed the problem to be that I am not using the correct scn number so RMAN can successfully restore those datafiles and recreates them instead. How do I find the correct scn to use to do a successful restore of the entire database? I have seen different methods on the web, but cant figure it out. Ive used "select archivelog_change#-1 from v$database;" and I also did "list backup of archivelog all" and used the latest sequence number. How can I find the correct scn to use so the entire database will restore?
    Here is the output of "list backup":
    List of Backup Sets
    ===================
    BS Key Size Device Type Elapsed Time Completion Time
    19724 41.12M DISK 00:00:10 14-OCT-10
    BP Key: 65840 Status: AVAILABLE Compressed: YES Tag: TAG20101014T210022
    Piece Name: /mnt/migrate/rman/EHR_dbid3632734257_set113195_piece1_copy1_20101014
    List of Archived Logs in backup set 19724
    Thrd Seq Low SCN Low Time Next SCN Next Time
    1 50439 3230234843 14-OCT-10 3230268282 14-OCT-10
    1 50440 3230268282 14-OCT-10 3230286806 14-OCT-10
    2 60280 3230234852 14-OCT-10 3230251419 14-OCT-10
    2 60281 3230251419 14-OCT-10 3230268263 14-OCT-10
    2 60282 3230268263 14-OCT-10 3230286809 14-OCT-10
    BS Key Type LV Size Device Type Elapsed Time Completion Time
    19725 Full 126.40G DISK 09:11:51 15-OCT-10
    List of Datafiles in backup set 19725
    File LV Type Ckp SCN Ckp Time Name
    1 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/system.625.609259453
    2 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/undotbs1.620.609259461
    3 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/sysaux.768.609259463
    4 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/undotbs2.632.609259467
    5 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/users.257.609259471
    6 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apolloaud.316.619537285
    7 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apollohist.629.619538155
    8 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apolloidx.312.619538169
    9 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apollotab.276.619538487
    10 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apollotab.576.619539331
    11 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apollolob.570.619539593
    12 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apollofdb.750.645974339
    13 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apolloidx.429.651171265
    14 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apolloidx.705.688680793
    15 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apolloaud.747.699632315
    16 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apollotab.330.715622123
    Backup Set Copy #1 of backup set 19725
    Device Type Elapsed Time Completion Time Compressed Tag
    DISK 09:11:51 20-OCT-10 YES TAG20101014T210039
    List of Backup Pieces for backup set 19725 Copy #1
    BP Key Pc# Status Piece Name
    65851 1 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece1_copy1_20101014
    65862 2 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece2_copy1_20101014
    65873 3 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece3_copy1_20101014
    65884 4 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece4_copy1_20101014
    65895 5 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece5_copy1_20101014
    65901 6 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece6_copy1_20101014
    65902 7 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece7_copy1_20101014
    65903 8 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece8_copy1_20101014
    65904 9 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece9_copy1_20101014
    65841 10 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece10_copy1_20101014
    65842 11 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece11_copy1_20101014
    65843 12 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece12_copy1_20101014
    65844 13 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece13_copy1_20101014
    65845 14 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece14_copy1_20101014
    65846 15 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece15_copy1_20101014
    65847 16 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece16_copy1_20101014
    65848 17 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece17_copy1_20101014
    65849 18 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece18_copy1_20101014
    65850 19 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece19_copy1_20101014
    65852 20 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece20_copy1_20101014
    65853 21 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece21_copy1_20101014
    65854 22 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece22_copy1_20101015
    65855 23 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece23_copy1_20101015
    65856 24 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece24_copy1_20101015
    65857 25 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece25_copy1_20101015
    65858 26 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece26_copy1_20101015
    65859 27 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece27_copy1_20101015
    65860 28 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece28_copy1_20101015
    65861 29 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece29_copy1_20101015
    65863 30 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece30_copy1_20101015
    65864 31 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece31_copy1_20101015
    65865 32 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece32_copy1_20101015
    65866 33 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece33_copy1_20101015
    65867 34 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece34_copy1_20101015
    65868 35 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece35_copy1_20101015
    65869 36 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece36_copy1_20101015
    65870 37 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece37_copy1_20101015
    65871 38 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece38_copy1_20101015
    65872 39 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece39_copy1_20101015
    65874 40 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece40_copy1_20101015
    65875 41 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece41_copy1_20101015
    65876 42 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece42_copy1_20101015
    65877 43 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece43_copy1_20101015
    65878 44 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece44_copy1_20101015
    65879 45 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece45_copy1_20101015
    65880 46 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece46_copy1_20101015
    65881 47 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece47_copy1_20101015
    65882 48 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece48_copy1_20101015
    65883 49 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece49_copy1_20101015
    65885 50 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece50_copy1_20101015
    65886 51 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece51_copy1_20101015
    65887 52 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece52_copy1_20101015
    65888 53 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece53_copy1_20101015
    65889 54 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece54_copy1_20101015
    65890 55 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece55_copy1_20101015
    65891 56 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece56_copy1_20101015
    65892 57 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece57_copy1_20101015
    65893 58 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece58_copy1_20101015
    65894 59 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece59_copy1_20101015
    65896 60 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece60_copy1_20101015
    65897 61 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece61_copy1_20101015
    65898 62 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece62_copy1_20101015
    65899 63 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece63_copy1_20101015
    65900 64 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece64_copy1_20101015
    BS Key Size Device Type Elapsed Time Completion Time
    19726 228.10M DISK 00:00:49 15-OCT-10
    BP Key: 65905 Status: AVAILABLE Compressed: YES Tag: TAG20101015T061242
    Piece Name: /mnt/migrate/rman/EHR_dbid3632734257_set113197_piece1_copy1_20101015
    List of Archived Logs in backup set 19726
    Thrd Seq Low SCN Low Time Next SCN Next Time
    1 50441 3230286806 14-OCT-10 3230331993 14-OCT-10
    1 50442 3230331993 14-OCT-10 3230401945 14-OCT-10
    1 50443 3230401945 14-OCT-10 3230469794 15-OCT-10
    1 50444 3230469794 15-OCT-10 3230555010 15-OCT-10
    1 50445 3230555010 15-OCT-10 3230618396 15-OCT-10
    1 50446 3230618396 15-OCT-10 3230695020 15-OCT-10
    2 60283 3230286809 14-OCT-10 3230304858 14-OCT-10
    2 60284 3230304858 14-OCT-10 3230330891 14-OCT-10
    2 60285 3230330891 14-OCT-10 3230354275 14-OCT-10
    2 60286 3230354275 14-OCT-10 3230366292 14-OCT-10
    2 60287 3230366292 14-OCT-10 3230399805 14-OCT-10
    2 60288 3230399805 14-OCT-10 3230423577 14-OCT-10
    2 60289 3230423577 14-OCT-10 3230446176 15-OCT-10
    2 60290 3230446176 15-OCT-10 3230469756 15-OCT-10
    2 60291 3230469756 15-OCT-10 3230496786 15-OCT-10
    2 60292 3230496786 15-OCT-10 3230524710 15-OCT-10
    2 60293 3230524710 15-OCT-10 3230554981 15-OCT-10
    2 60294 3230554981 15-OCT-10 3230583802 15-OCT-10
    2 60295 3230583802 15-OCT-10 3230610465 15-OCT-10
    2 60296 3230610465 15-OCT-10 3230617887 15-OCT-10
    2 60297 3230617887 15-OCT-10 3230673207 15-OCT-10
    2 60298 3230673207 15-OCT-10 3230695022 15-OCT-10

  • Reduce sysaux tablespace file

    Hi.
    Could anybody suggest the ways to reduce size of sysaux tablespace file.
    Thanks in advance.
    Andrii.

    Pl post details of OS and database versions. See also these MOS Docs
    Suggestions if your SYSAUX Tablespace grows rapidly or too large          [Document 1292724.1]
    General Guidelines for SYSAUX Space Issues          [Document 552880.1]
    SYSAUX Grows Because Optimizer Stats History is Not Purged          [Document 1055547.1]
    Space issue in Sysaux tablespace due to Unexpected AWR size          [Document 1218413.1]
    Space Management In Sysaux Tablespace with AWR in Use          [Document 287679.1]
    SYSAUX Tablespace Grows Heavily Due To AWR          [Document 852028.1]
    HTH
    Srini

  • Sysaux tablespace issue-missing sysux datafile

    hi,
    I ve upgraded an database for 9i to 10g. The upgrade was sucessfull and the Db was in normal usage. Due to some functionality testing the database was restored to a state from the backup taken after upgrade. But while restoring the database i forgot to include the path of the datafile of sysaux tablespace in the control file re-creation script.
    I didnt notice this issue for long time until i realised the mistake made by me.
    I found in the alert logs which showed errors such as
    ORA-01157: cannot identify/lock data file 124 - see DBWR trace file
    ORA-01110: data file 124: '/oracle/ora/dbs/MISSING00141'
    ORA-27037: unable to obtain file status
    since the path of the sysaux tablespace was not referred in the script i thought of referring it now and i issued the following command
    alter tablespace sysaux add datafile '<path>/sysaux01.dbf' reuse;
    i issued this as the datafile was already present and i thought of jus reusing it again.
    But what had happened is this datafile had been added as an additional datafile for the sysaux tablespace,which means the sysaux is still referring '/oracle/ora/dbs/MISSING00141' as one of the datafile.
    but one important thing is that there isnt any such datafile ie '/oracle/ora/dbs/MISSING00141' when i checked inside the dbs folder.
    The path is getting referred as part of the sysaux tablespace but its physical location is not found.
    So i did took this datafile offlinedrop issuing
    alter database datafile '/oracle/ora/dbs/MISSING00141' ofline drop
    but the problem i m facing now is the AWR is not opening up and it throw error stating first datafile of sysaux tablespace '/oracle/ora/dbs/MISSING00141' not found.
    ORA-00376: file 124 cannot be read at this time
    ORA-01110: data file 141: '/oracle/ora/dbs/MISSING00141'
    ORA-06512: at line 21.
    any solution for solving the problem would be appreciated
    thanks,
    ahmed

    Hi, I've got exactly the same problem up to the point where I try to offline drop the MISSING0009 datafile.
    The command says it completed OK but the phantom datafile does not go and still reports that it's there in dba_data_files, althoguh the online_status is RECOVER, the status is ONLINE.
    I'm not sure how to get rid of the entry if the offline drop command doesnt work. I've tried recreating the control file and deleting the entry for this datafile too but somehow it returned after that too!
    I''m also not sure what to do when I do get rid of it - since I cant recover the old sysaux01.dbf datafile since it's not consistent with the database since there has been a week inbetween and we're not running archivelogging.
    I would assume that all the stuff usually put in the SYSAUX tablespace is therefore lost, but I dont think we use anything that normally puts stuff in there, I've only noticed this since I was trying to install em.
    Do I have to rebuild the database from scratch? Or any ideas on how I can recover the situation? Can I do something like startup upgrade and re-run the upgrade scripts which will put their stuff back into sysaux....?
    Many thanks for ideas
    Rob

  • Sysaux tablespace issue

    hi,
    I ve upgraded an database for 9i to 10g. The upgrade was sucessfull and the Db was in normal usage. Due to some functionality testing the database was restored to a state from the backup taken after upgrade. But while restoring the database i forgot to include the path of the datafile of sysaux tablespace in the control file re-creation script.
    I didnt notice this issue for long time until i realised the mistake made by me.
    I found in the alert logs which showed errors such as
    ORA-01157: cannot identify/lock data file 124 - see DBWR trace file
    ORA-01110: data file 124: '/oracle/ora/dbs/MISSING00141'
    ORA-27037: unable to obtain file status
    since the path of the sysaux tablespace was not referred in the script i thought of referring it now and i issued the following command
    alter tablespace sysaux add datafile '<path>/sysaux01.dbf' reuse;
    i issed this as the datafile was already present and i thought of jus reuing it again.
    But what had happened is this datafile had been added as an additional datafile for the sysaux tablespace,which means the sysaux is still referring '/oracle/ora/dbs/MISSING00141' as one of the datafile.
    but one important thing is that there isnt any such datafile ie '/oracle/ora/dbs/MISSING00141' when i checked inside the dbs folder.
    The path is getting referred as part of the sysaux tablespace but its physical location is not found.
    So i did took this datafile offlinedrop issuing
    alter database datafile '/oracle/ora/dbs/MISSING00141' ofline drop
    but the problem i m facing now is the AWR is not opening up and it throw error stating first datafile of sysaux tablespace '/oracle/ora/dbs/MISSING00141' not found.
    ORA-00376: file 124 cannot be read at this time
    ORA-01110: data file 141: '/oracle/ora/dbs/MISSING00141'
    ORA-06512: at line 21.
    any solution for solving the problem would be appreciated
    thanks,
    ahmed

    i m able to start up the database normally....there isnt any errors while starting the DB.These errors are encountered in alert log file and user trace files.As as result AWR is not opening.

  • Need clarification on issue with tablespaces

    Hi All,
    I needed clarification on this issue with tablespaces.I am following a guideline which says "Presently,The general rule of thumb is to concentrate on tablespaces that are 90% or greater used and have less than 2 GB of free space"
    My Scenario:-Now i have tablesace which is 97.23 % and the free space is 10 gb.Please advise me that whats the best next step I can take in this respect?
    I am very new to this and just following the guideline,so can you all please explain me some details about this.
    Thanks

    Well, the guideline says "*and* have less than 2 GB of free space"
    Since that tablespace as 10GB of free space, the guideline says that you do not need to concentrate on it. Eh ?
    I would be careful with guidelines that are hard-coded in this manner. You need to know the context in which the guideline was set.
    Assuming that your database/application doesn't grow suddenly by 1GB or larger (or create temporary segments / objects of 1GB or larger), the "2 GB of free space" might make sense. Then, again, it depends on the extent allocation type. What size are extents getting allocated.
    You should check with your organisation's senior DBAs on what happens if you don't concentrate on a tablespace because it is outside the guidelines !

  • Clarification on issue with tablespaces

    Hi All,
    I needed clarification on this issue with tablespaces.I am following a guideline which says _"Presently,The general rule of thumb is to concentrate on tablespaces that are 90% or greater used and have less than 2 GB of free space"_
    My Scenario:-Now i have tablesace which is 97.23 % and the free space is 10 gb.Please advise me that whats the best next step I can take in this respect?
    I am very new to this and just following the guideline,so can you all please explain me some details about this.
    Thanks

    What's the rate of growth? Is 10GB going to last you a day? A week? A month?
    Cheers, APC
    blog: http://radiofreetooting.blogspot.com

  • Logical corruption found in the sysaux tablespace

    Dear All:
    We lately see the logical corruption error when running dbverify command which shows the block corruption. It is always on the the sysaux tablespace. The database is 11g and platform is Linux.
    we get the error like:error backing up file 2 block xxxx: logical corruption and this comes to alert.log out of the automated maintenance job like sqltunning advisor running during maintenance window.
    Now As far as I know,we can't drop or rename the sysaux tablespace. there is a startup migrate option to drop the SYSAUX but it does not work due to the presence of domain indexes. you may run the rman block media recovery but it ends with not fixing since rman backups are more of physical than maintain the logical integrity.
    Any help, advise, suggestion will be highly appreciated.

    If you let this corruption there then you are likely to face a big issue that will compromise database availability sooner or later. The sysaux is a critical tablespace, so you must proceed with caution.
    Make sure you have a valid backup and don't do any thing unless you are sure about what you are doing and you have a fall back procedure.
    if you still have a valid backup then you can use rman to perform a db block level recovery, this will help you in fixing the block. Otherwise try to restore and recover the sysaux. In case you cannot fix the block by refreshing the sysaux tablespace then I suggest you to create a new database and use aTransportable Tablespace technique to migrate all tablespaces from your current database to the new one and get rid of this database.
    ~ Madrid
    http://hrivera99.blogspot.com

  • ORA-01578: ORACLE data block corrupted on tables in sysaux tablespace

    Dear Experts,
    From the alert log file we noticed data block corruptions on one of our datafiles. After further investigation, we realized that the corruptions were on 3 of the AWR related tables in the SYSAUX tablespace:
    1. WRH$_LIBRARYCACHE
    2. WRH$_TEMPSTATXS
    3. WRI$_ALERT_OUTSTANDING
    The bad news is that we may not have a valid rman backup to do the recovery due to the retention policy - RECOVERY WINDOW OF 2 DAYS. Since this is a development database with limited monitoring, we did not discover the corruption until 6 days later. The issue happened about 6 days ago (about Christmas time).
    So, what are our recovery options? Can someone advice? We are thinking about drop and recreate the 3 affected v$WR* tables, but not quite sure about the impact to the system if we drop and recreate the 3 objects. Did someone experience this type of recovery. If you did, what are your approaches?
    We are running oracle 10.2.0.3 version.
    I greatly appreciate your input and suggestion. Thanks!!!

    as long as you have a backup of ur database before christmas, you can use the " MAXDAYS " cmd to get ur backup working so long as you have not used delete obsolote....had a same sistuation....where i had a backup and trying to restore it ...kept saying no valid backup...after going thru some stuff...found the MAXDAYS cmd to use my backup...here is an example ...
    $ rman target /
    Recovery Manager: Release 10.2.0.2.0 - Production on Sun Apr 6 09:05:44 2008
    Copyright (c) 1982, 2005, Oracle. All rights reserved.
    connected to target database (not started)
    RMAN> SET DBID=1528894801
    executing command: SET DBID
    RMAN> startup force nomount;
    startup failed: ORA-01078: failure in processing system parameters
    LRM-00109: could not open parameter file '/u01/app/oracle/product/10.2.0/db_1/dbs/initsameera.ora'
    starting Oracle instance without parameter file for retrival of spfile
    Oracle instance started
    Total System Global Area 159383552 bytes
    Fixed Size 1259672 bytes
    Variable Size 58722152 bytes
    Database Buffers 92274688 bytes
    Redo Buffers 7127040 bytes
    RMAN> set controlfile autobackup format for device type disk to '/u99/backup/sameera/control_spfile_%F';
    executing command: SET CONTROLFILE AUTOBACKUP FORMAT
    using target database control file instead of recovery catalog
    RMAN> run
    2> {
    3> allocate channel p1 type disk;
    4> restore spfile to pfile '/u01/app/oracle/product/10.2.0/db_1/dbs/initsameera.ora' from autobackup;
    5> shutdown abort;
    6> }
    allocated channel: p1
    channel p1: sid=36 devtype=DISK
    Starting restore at 06-APR-08
    channel p1: looking for autobackup on day: 20080406
    channel p1: looking for autobackup on day: 20080405
    channel p1: looking for autobackup on day: 20080404
    channel p1: looking for autobackup on day: 20080403
    channel p1: looking for autobackup on day: 20080402
    channel p1: looking for autobackup on day: 20080401
    channel p1: looking for autobackup on day: 20080331
    channel p1: no autobackup in 7 days found
    released channel: p1
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of restore command at 04/06/2008 09:09:09
    RMAN-06172: no autobackup found or specified handle is not a valid copy or piece
    Solution:
    RMAN> shutdown abort;
    RMAN> EXIT;
    $ ps -ef |grep pmon
    oracle 2891 2856 0 09:05 pts/1 00:00:00 grep pmon
    oracle 7448 1 0 Apr05 ? 00:00:00 ora_pmon_primary
    $export ORACLE_SID=sameera
    $ rman target /
    Recovery Manager: Release 10.2.0.2.0 - Production on Sun Apr 6 09:05:44 2008
    Copyright (c) 1982, 2005, Oracle. All rights reserved.
    connected to target database (not started)
    RMAN> SET DBID=1528894801
    executing command: SET DBID
    RMAN> startup force nomount;
    startup failed: ORA-01078: failure in processing system parameters
    LRM-00109: could not open parameter file '/u01/app/oracle/product/10.2.0/db_1/db s/initsameera.ora'
    starting Oracle instance without parameter file for retrival of spfile
    Oracle instance started
    Total System Global Area 159383552 bytes
    Fixed Size 1259672 bytes
    Variable Size 58722152 bytes
    Database Buffers 92274688 bytes
    Redo Buffers 7127040 bytes
    RMAN> set controlfile autobackup format for device type disk to '/u99/backup/sameera/control_spfile_%F';
    executing command: SET CONTROLFILE AUTOBACKUP FORMAT
    using target database control file instead of recovery catalog
    RMAN> run
    2> {
    3> allocate channel p1 type disk;
    4> restore spfile to pfile '/u01/app/oracle/product/10.2.0/db_1/dbs/initsameera.ora' from autobackup maxdays 15;
    5> shutdown abort;
    6> }
    released channel: ORA_DISK_1
    allocated channel: p1
    channel p1: sid=36 devtype=DISK
    Starting restore at 06-APR-08
    channel p1: looking for autobackup on day: 20080406
    channel p1: looking for autobackup on day: 20080405
    channel p1: looking for autobackup on day: 20080404
    channel p1: looking for autobackup on day: 20080403
    channel p1: looking for autobackup on day: 20080402
    channel p1: looking for autobackup on day: 20080401
    channel p1: looking for autobackup on day: 20080331
    channel p1: looking for autobackup on day: 20080330
    channel p1: looking for autobackup on day: 20080329
    channel p1: looking for autobackup on day: 20080328
    channel p1: looking for autobackup on day: 20080327
    channel p1: looking for autobackup on day: 20080326
    channel p1: looking for autobackup on day: 20080325
    channel p1: looking for autobackup on day: 20080324
    channel p1: looking for autobackup on day: 20080323
    channel p1: autobackup found: /u99/backup/sameera/control_spfile_c-1528894801-20080323-00
    channel p1: SPFILE restore from autobackup complete
    Finished restore at 06-APR-08
    Oracle instance shut down
    Check to make sure if initsameera.ora exists in $ORACLE_HOME/dbs location.
    $ cd $ORACLE_HOME/dbs
    $ ls -ltr
    total 7052
    -rw-r----- 1 oracle oinstall 2560 Apr 5 13:21 spfileprimary.ora
    -rw-r----- 1 oracle oinstall 7061504 Apr 5 13:23 snapcf_primary.f
    -rw-rw---- 1 oracle oinstall 1544 Apr 5 18:42 hc_sameera.dat
    -rw-r--r-- 1 oracle oinstall 1087 Apr 6 09:12 initsameera.ora
    $ pwd
    /u01/app/oracle/product/10.2.0/db_1/dbs
    $

  • Sysaux tablespace corrupted.

    Hi,
    Sysaux tablepace corrupted. when recover sysaux tablespace it is asking archfiles. but archfiles is expired. how to overcome from this issue? can we recreate sysaux tablespace
    Thanks

    Krishna Agnihotri wrote:
    Hi user2017273
    Kindly explain what do you mean of sysaux tablespace corruption, How you have identified this issue.
    there are two type of corruption > Physical and Logical
    are you able to identified the corruption is in which segment or is this in any free segment. if this is in free segment then you need not to worry. and if corruption is in any segment then what is the segment type > Table, Index or LOB....
    kindly give your finding with above plan, so that i can help to recover/recreate your sysaux tablespace.
    Krishna,
    I am not sure that for a tablespace, there is anything like a logical corruption. That said, whether its a logical or physical corruption, since its a tablespace which is meant for the db's internal tables and since the OP doesn't have any archive logs to recover it and he is on a patched system, its better than he should work with OSS. Because without archivelogs, any kind of corruption recovery would be impossible and logical corruption is not something that I have seen a lot. So going to support would be the best thing to do to avoid further complexities IMO.
    Aman....

  • Performance Issues with Debugging even in Display Mode

    Hi not certain if this would sit in Security, ABAP or Basis, but lets start here as it is security related.
    S_DEVELOP with any activity on DEBUG on a production system is a concern, but what are the performance related issues when a super user has to go into debug in display only on a production system because of a really complex issue?
    I've heard in the past of a scenario where system performance was impacted, and we have notes around the allocation of S_DEVELOP display DEBUG access to this point. (I've summarised these below)
    The risk with debug is associated with the length of time that the actual debugging process is being performed.
    u2022     Work processes are dedicated solely to the users for the duration of the debug. If these are being performed for a long time, these can cause issues with not enough work processes being available.
    u2022     It can cause DB2 locks. If the debug session last awhile, DB2 locks are not released. This impacts the availability of tablespaces, thus, affecting various transactions running across the system.
    Even with these concerns, security will often get asked for debug display access.
    As security is about risk identification, assessment and then controlled access what do other organisations do?
    Options (not exhaustive) are "No Debug ever" or "Debug display only via a fire fight or super user on a time limited basis".
    We are currently in the "debug display only via fire fight" camp, but would like to canvas opinion on this.
    As one of the concepts of security is Availability of data (and to an extent ensuring the systems are up and running) do the performance risks push the security function to the "No Debug Ever" stance.

    If you need to debug in production, then 9 times out of 10 you need to do root-cause analysis: The developer is the problem.
    Writing sloppy code and not testing properly should not be an excuse for debugging in production.
    But of course, there are exceptions even when you do try to keep them to a minimum.
    To add to Jurjen's comments, also note that the debugger only has a limited capability of doing a rollback. So you can quite easily and unintentionally create inconsistencies in the system - also in display mode - which is an integrity problem, and typically more critical than availability problems or even potential confidentiality concerns.
    Cheers,
    Julius
    Edited by: Julius Bussche on May 15, 2009 10:50 AM

  • Issue with back end validation in jsf 2.0

    I am upgrading my apps to jsf2.0 and I came across something that I hope you have already solved.
    In jsf 1.1 action methods returned a string. If that string was NOT mapped as a navigation in faces-config.xml, then it just rerendered the active page. this made doing back end validation easy because I could add messages to the faces context and when the active page rerendered the validation messages would get displayed and no one was the wiser than it was done on the back end instead of on the front end.
    In jsf 2.0 I get null pointers if I return a string that is NOT mapped as a navigation. So I changed the code to return a string that is mapped as a navigation for that page when there is a validation error. but that is treating it like a new request and not a rerender so the validation messages I added to the faces context are not there when the page renders.
    if i test submit a form that has only front end validation then it works fine and the validation messages are correctly shown.
    any suggestions?

    In 11.2.0.3 you are unlikely to see the various truncate/drop issues relating to large numbers of small extents - unless you use dictionary managed tablespaces.
    There are a couple of possible threats with small extents and highly concurrent inserts with ASSM that might be a temporary problem when the object size is small. There may still be some issues with large uncommitted inserts or deletes making other session's work very hard to identify free blocks until the large transaction has committed - these things can be hard to test.
    There may still be a couple of inefficiencies with parallel query and small extents, although parallel CTAS did have a (possibly temporary) hack to allocate immediate large extents to work around some of the silly details.
    Really you need to think through your requirements and them model them on your system - some of the anomalies have changed several times over the last three years.
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    Now on Twitter: @jloracle

  • Issue with Generate Create Script in new ODT 11.1.0.5.10 beta

    So I'm trying to determine if there's an issue with the Generate Create Script option in the new ODT 11.1.0.5.10 beta (when you right click on a table in Server Explorer).
    The SQL create script that it generates lacks the slash between lines. For example I generated the create script for my User table and this is what was generated:
    CREATE TABLE "DEV"."SYSTEM_USER_TB" ("RID" NUMBER(10,0),"USER_NAME" VARCHAR2(256 CHAR),"APPLICATION_RID" NUMBER(10,0),"FIRST_NAME" VARCHAR2(256 CHAR),"LAST_NAME" VARCHAR2(256 CHAR),"PW" VARCHAR2(128 CHAR),"PW_FORMAT" NUMBER,"PW_SALT" VARCHAR2(128 CHAR),"LAST_ACTIVITY_DT" DATE,"EXPIRATION_DT" DATE,"EMAIL" VARCHAR2(256 CHAR),"PW_QUESTION" VARCHAR2(256 CHAR),"PW_ANSWER" VARCHAR2(256 CHAR),"APPROVED_FLG" NUMBER(1,0),"LOCKED_OUT_FLG" NUMBER(1,0),"LAST_LOGIN_DT" DATE,"LAST_PW_CHANGED_DT" DATE,"LAST_LOCKOUT_DT" DATE,"FAILED_PW_ATTEMPT_CNT" NUMBER(6,0),"FAILED_PW_ATTEMPT_WINSTART" DATE,"FAILED_PW_ANSW_ATTEMPT_CNT" NUMBER(8,0),"FAILED_PW_ANSW_ATTEMPT_WINSTRT" DATE,"CREATED_BY_RID" NUMBER(10,0),"CREATED_DT" DATE,"MODIFIED_BY_RID" NUMBER(10,0),"MODIFIED_DT" DATE) TABLESPACE "USERS" PCTFREE 10 INITRANS 1 MAXTRANS 255 STORAGE ( INITIAL 131072 MAXEXTENTS 2147483645 MINEXTENTS 1 )
    CREATE UNIQUE INDEX "DEV"."XPKSTAFF" ON "DEV"."SYSTEM_USER_TB" ("RID" ) TABLESPACE "USERS"
    ALTER TABLE "DEV"."SYSTEM_USER_TB" ADD ( CONSTRAINT "SYS_C0033033" PRIMARY KEY ("RID") USING INDEX "DEV"."XPKSTAFF" ENABLE VALIDATE )
    ALTER TABLE "DEV"."SYSTEM_USER_TB" ADD ( CONSTRAINT "SYS_C0033032" CHECK ("RID" IS NOT NULL) ENABLE VALIDATE )
    CREATE TRIGGER "DEV"."SYSTEM_USER_TRG1"
    BEFORE
    INSERT
    ON "DEV"."SYSTEM_USER_TB"
    FOR EACH ROW
    begin
         select SYSTEM_USER_SEQ.nextval into :new.RID from dual;
    end;
    In my new Oracle Database Project, if I right click on the script and select "Run" or "Run On", the script fails saying:
    Connected.
    CREATE UNIQUE INDEX "DEV"."XPKSTAFF" ON "DEV"."SYSTEM_USER_TB" ("RID" ) TABLESPACE "USERS"
    ERROR at line 2:
    ORA-00922: missing or invalid option
    If I then add, a slash between lines, the script runs successfully and creates the table/trigger and whatever else just fine. For example, I changed the above generated code to look as follows:
    CREATE TABLE "DEV"."SYSTEM_USER_TB" ("RID" NUMBER(10,0),"USER_NAME" VARCHAR2(256 CHAR),"APPLICATION_RID" NUMBER(10,0),"FIRST_NAME" VARCHAR2(256 CHAR),"LAST_NAME" VARCHAR2(256 CHAR),"PW" VARCHAR2(128 CHAR),"PW_FORMAT" NUMBER,"PW_SALT" VARCHAR2(128 CHAR),"LAST_ACTIVITY_DT" DATE,"EXPIRATION_DT" DATE,"EMAIL" VARCHAR2(256 CHAR),"PW_QUESTION" VARCHAR2(256 CHAR),"PW_ANSWER" VARCHAR2(256 CHAR),"APPROVED_FLG" NUMBER(1,0),"LOCKED_OUT_FLG" NUMBER(1,0),"LAST_LOGIN_DT" DATE,"LAST_PW_CHANGED_DT" DATE,"LAST_LOCKOUT_DT" DATE,"FAILED_PW_ATTEMPT_CNT" NUMBER(6,0),"FAILED_PW_ATTEMPT_WINSTART" DATE,"FAILED_PW_ANSW_ATTEMPT_CNT" NUMBER(8,0),"FAILED_PW_ANSW_ATTEMPT_WINSTRT" DATE,"CREATED_BY_RID" NUMBER(10,0),"CREATED_DT" DATE,"MODIFIED_BY_RID" NUMBER(10,0),"MODIFIED_DT" DATE) TABLESPACE "USERS" PCTFREE 10 INITRANS 1 MAXTRANS 255 STORAGE ( INITIAL 131072 MAXEXTENTS 2147483645 MINEXTENTS 1 )
    CREATE UNIQUE INDEX "DEV"."XPKSTAFF" ON "DEV"."SYSTEM_USER_TB" ("RID" ) TABLESPACE "USERS"
    ALTER TABLE "DEV"."SYSTEM_USER_TB" ADD ( CONSTRAINT "SYS_C0033033" PRIMARY KEY ("RID") USING INDEX "DEV"."XPKSTAFF" ENABLE VALIDATE )
    ALTER TABLE "DEV"."SYSTEM_USER_TB" ADD ( CONSTRAINT "SYS_C0033032" CHECK ("RID" IS NOT NULL) ENABLE VALIDATE )
    CREATE TRIGGER "DEV"."SYSTEM_USER_TRG1"
    BEFORE
    INSERT
    ON "DEV"."SYSTEM_USER_TB"
    FOR EACH ROW
    begin
         select SYSTEM_USER_SEQ.nextval into :new.RID from dual;
    end;
    So, does anyone know if this is a bug? Could I be missing an option to add in the slashes to the generated code? Is there an option to not require the slashes? Could there be another way to execute these scripts?
    Seriously, I think I'm having deja vu from the last release of the Dev Tools: Generate Create Script creates scripts that won't run: ORA-00922: missing..
    ...except this time the documentation says I should be able to use the "Run" and "Run On" commands in the Oracle Database Project (see page 8): http://www.oracle.com/technology/tech/dotnet/pdf/ODT11_whatsnew.pdf
    null

    There are 2 issues in the generated script :
    1. Missing semicolons at the end of the create stmts
    2. Missing slashes
    Both of these fixes will be available in the ODT 11.1 release.

  • System and sysaux tablespace

    hi,
    can anyone tell me whata system and sysaux tablespace contains, and how to manage them.

    The system tablespace
    The system tablespace is always available when a database is open (it cannot be taken offline).
    The system tablespace stores the data dictionary (or their base tables, respectively).
    The sysaux tablespace
    The sysaux tablespace is new with Oracle 10g. It is used to store database components that were stored in the system tablespace in prior releases of the database.
    Also, the tablespaces that were needed for RMAN's recovery catalog, for Ultra Search, for Data Mining, for XDP and for OLAP are going to sysaux with 10g.
    Additionally, it is the place where automatic workload repository stores its information.
    The SYSAUX tablespace was installed as an auxiliary tablespace to the SYSTEM tablespace when you created your database. Some database components that formerly created and used separate tablespaces now occupy the SYSAUX tablespace.
    If the SYSAUX tablespace becomes unavailable, core database functionality will remain operational. The database features that use the SYSAUX tablespace could fail, or function with limited capability.
    refer the links:
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/tspaces.htm#i1011659

  • Row locking issue with version enabled tables

    I've been testing the effect of locking in version enabled tables in order to assess workspace manager restrictions when updating records in different workspaces and I have encountered a locking problem where I can't seem to update different records of the same table in different sessions if these same records have been previously updated & committed in another workspace.
    I'm running the tests on 11.2.0.3.  I have ROW_LEVEL_LOCKING set to ON.
    Here's a simple test case (I have many other test cases which fail as well but understanding why this one causes a locking problem will help me understand the results from my other test cases):
    --Change tablespace names as required
    create table t1 (id varchar2(36) not null, name varchar2(50) not null) tablespace XXX;
    alter table t1 add constraint t1_pk primary key (id) using index tablespace XXX;
    exec dbms_wm.gotoworkspace('LIVE');
    insert into t1 values ('1', 'name1');
    insert into t1 values ('2', 'name2');
    insert into t1 values ('3', 'name3');
    commit;
    exec dbms_wm.enableversioning('t1');
    exec dbms_wm.gotoworkspace('LIVE');
    exec dbms_wm.createworkspace('TESTWSM1');
    exec dbms_wm.gotoworkspace('TESTWSM1');
    --update 2 records in a non-LIVE workspace in preparation for updating in different workspaces later
    update t1 set name = name||'changed' where id in ('1', '2');
    commit;
    quit;
    --Now in a separate session (called session 1 for this example) run the following without committing the changes:
    exec dbms_wm.gotoworkspace('LIVE');
    update t1 set name = 'changed' where id = '1';
    --Now in another session (session 2) update a different record from the same table.  The below update will hang waiting on the transaction in session 1 to complete (via commit/rollback):
    exec dbms_wm.gotoworkspace('LIVE');
    update t1 set name = 'changed' where id = '2';
    I'm surprised records of different ids can't be updated in different sessions i.e. why does session 1 lock the update of record 2 which is not being updated anywhere else.  I've tried this using different non-LIVE workspaces with similar results.  I've tried changing table properties e.g. initrans with and still get a lock.  The changes to table properties are successfully propagated to the _LT tables but not all the related workspace manager tables created for table T1 above.  I'm not sure if this is the issue.
    Note an example of the background workspace manager query that may create the lock is something like:
    UPDATE TESTWSM.T1_LT SET LTLOCK = WMSYS.LT_CTX_PKG.CHECKNGETLOCK(:B6 , LTLOCK, NEXTVER, :B3 , 0,'UPDATE', VERSION, DELSTATUS, :B5 ), NEXTVER = WMSYS.LT_CTX_PKG.GETNEXTVER(NEXTVER,:B4 ,VERSION,:B3 ,:B2 ,683) WHERE ROWID = :B1
    Any help with this will be appreciated.  Thanks in advance.

    Hi Ben,
    Thanks for your quick response.
    I've tested your suggestion and it does work with 2 workspaces but the same problem is enountered when additional workspaces are created. 
    It seems if multiple workspaces are used in a multi user environment, locks will be inevitable which will degrade performance especially if a long transaction is used. 
    Deadlocks can also be encountered where eventually one of the sessions is rolled back by the database. 
    Is there a way of avoiding this e.g. by controlling the creation of workspaces and table updates?
    I've updated my test case below to demonstrate the extra workspace locking issue.
    --change tablespace name as required
    create table t1 (id varchar2(36) not null, name varchar2(50) not null) tablespace XXX;
    alter table t1 add constraint t1_pk primary key (id) using index tablespace XXX;
    exec dbms_wm.gotoworkspace('LIVE');
    insert into t1 values ('1', 'name1');
    insert into t1 values ('2', 'name2');
    insert into t1 values ('3', 'name3');
    commit;
    exec dbms_wm.enableversioning('t1');
    exec dbms_wm.gotoworkspace('LIVE');
    exec dbms_wm.createworkspace('TESTWSM1');
    exec dbms_wm.gotoworkspace('TESTWSM1');
    update t1 set name = name||'changed' where id in ('1', '2');
    commit;
    Session 1:
    exec dbms_wm.gotoworkspace('LIVE');
    update t1 set name = 'changed' where id = '1';
    session 2:
    exec dbms_wm.gotoworkspace('LIVE');
    update t1 set name = 'changed' where id = '2';
    --end of original test case, start of additional workspace locking issue:
    Session 1:
    rollback;
    Session 2:
    rollback;
    --update record in both workspaces
    exec dbms_wm.gotoworkspace('LIVE');
    update t1 set name = 'changed' where id = '3';
    commit;
    exec dbms_wm.gotoworkspace('TESTWSM1');
    update t1 set name = 'changed' where id = '3';
    commit;
    Session 1:
    exec dbms_wm.gotoworkspace('LIVE');
    update t1 set name = 'changed' where id = '1';
    session 2:
    exec dbms_wm.gotoworkspace('LIVE');
    update t1 set name = 'changed' where id = '2';
    Session 1:
    rollback;
    Session 2:
    rollback;
    exec dbms_wm.gotoworkspace('LIVE');
    exec dbms_wm.createworkspace('TESTWSM2');
    exec dbms_wm.gotoworkspace('TESTWSM2');
    update t1 set name = name||'changed2' where id in ('1', '2');
    commit;
    Session 1:
    exec dbms_wm.gotoworkspace('LIVE');
    update t1 set name = 'changed' where id = '1';
    --this now gets locked out by session 1
    session 2:
    exec dbms_wm.gotoworkspace('LIVE');
    update t1 set name = 'changed' where id = '2';
    Session 1:
    rollback;
    Session 2:
    rollback;
    --update record 3 in TESTWSM2
    exec dbms_wm.gotoworkspace('TESTWSM2');
    update t1 set name = 'changed' where id = '3';
    commit;
    Session 1:
    exec dbms_wm.gotoworkspace('LIVE');
    update t1 set name = 'changed' where id = '1';
    --this is still locked out by session 1
    session 2:
    exec dbms_wm.gotoworkspace('LIVE');
    update t1 set name = 'changed' where id = '2';
    Session 1:
    rollback;
    Session 2:
    rollback;
    --try updating LIVE
    exec dbms_wm.gotoworkspace('LIVE');
    update t1 set name = 'changed' where id = '3';
    commit;
    Session 1:
    exec dbms_wm.gotoworkspace('LIVE');
    update t1 set name = 'changed' where id = '1';
    --this is still locked out by session 1
    session 2:
    exec dbms_wm.gotoworkspace('LIVE');
    update t1 set name = 'changed' where id = '2';
    Session 1:
    rollback;
    Session 2:
    rollback;
    --try updating TESTWSM1 workspace too - so all have been updated since TESTWSM2 was created
    exec dbms_wm.gotoworkspace('TESTWSM1');
    update t1 set name = 'changed' where id = '3';
    commit;
    Session 1:
    exec dbms_wm.gotoworkspace('LIVE');
    update t1 set name = 'changed' where id = '1';
    --this is still locked out by session 1
    session 2:
    exec dbms_wm.gotoworkspace('LIVE');
    update t1 set name = 'changed' where id = '2';
    Session 1:
    rollback;
    Session 2:
    rollback;
    --try updating every workspace afresh
    exec dbms_wm.gotoworkspace('LIVE');
    update t1 set name = 'changedA' where id = '3';
    commit;
    exec dbms_wm.gotoworkspace('TESTWSM1');
    update t1 set name = 'changedB' where id = '3';
    commit;
    exec dbms_wm.gotoworkspace('TESTWSM2');
    update t1 set name = 'changedC' where id = '3';
    commit;
    Session 1:
    exec dbms_wm.gotoworkspace('LIVE');
    update t1 set name = 'changed' where id = '1';
    --this is still locked out by session 1
    session 2:
    exec dbms_wm.gotoworkspace('LIVE');
    update t1 set name = 'changed' where id = '2';
    Session 1:
    rollback;
    Session 2:
    rollback;

Maybe you are looking for

  • Calling report from a  form(Oracle team urgent)

    Hi all, I am using the following code to call a report from form PROCEDURE Run_Report (cMode varchar2) IS pl_id ParamList; BEGIN pl_id := Get_Parameter_List('OPEN'); IF NOT Id_Null(pl_id) THEN Destroy_Parameter_List( pl_id ); END IF; pl_id := Create_

  • Error while deploying the BMP Bean

    Hi Here Iam trying to deploy the Account(BMP)Bean in to WebAS and the following error is getting while deplying. Jun 28, 2005 6:18:42 PM /userOut/deploy (com.sap.ide.eclipse.sdm.threading.DeployThreadManager) [Thread[Deploy Thread,5,main]] INFO: [027

  • Making 2 iPads into 1

    I have 2 iPads and want to combine all the data onto one.  I have synced it but the data from pages etc didn't come over.  Can you advise me...Please!!

  • View of JMX console without starting standalone server

    Hi All, I want to view the JMX console without starting the standalone version of OC4j in Oracle 10g 10.1.2 AS. It is fine once i start the standalone version of OC4j using the java -jar oc4j.jar I can view the jmx console using URL http://localhost:

  • [Solved]Downgrade Firefox to 3.5.7. Getting a 'Couldn't load XPCOM'.

    Hi! I need to downgrade Firefox to 3.5.x from 3.6.2 in order to try to get Vmware console plugin to work. There is an issue with Firefox 3.6 and the Vmware console plugin. http://communities.vmware.com/thread/252218 I have downgraded Firefox to 3.5.7