Sysaux tablespace is getting full

Hi,
can anyone help me find out why my sysaux tablespace is getting full?
Regards

Hi,
The datafiles of System ,and Sysaux tablespaces are in AUTIEXTEND ON mode by default.
To findout what object is occupying the space
SELECT OCCUPANT_NAME,OCCUPANT_DESC,SCHEMA_NAME,MOVE_PROCEDURE,SPACE_USAGE_KBYTES from V$SYSAUX_OCCUPANTS;

Similar Messages

SYSAUX tablespace is getting filled up

Hi,
Friends, my PROD SYSAUX tablespace is getting filled up continously...is this normal behaviour..
i have allocated 3.7 GB for SYSAUX, now free is 9 MB...
I can allocate new space to SYSAUX...but Can I know, why it is getting filled up like this...
SQL> select username,default_tablespace,account_status from dba_users
2 where default_tablespace='SYSAUX';
=====================================================
USERNAME DEFAULT_TABLESPACE ACCOUNT_STATUS
DBSNMP SYSAUX OPEN
SYSMAN SYSAUX OPEN
WMSYS SYSAUX EXPIRED & LOCKED
ORDSYS SYSAUX EXPIRED & LOCKED
EXFSYS SYSAUX EXPIRED & LOCKED
XDB SYSAUX EXPIRED & LOCKED
DMSYS SYSAUX EXPIRED & LOCKED
OLAPSYS SYSAUX EXPIRED & LOCKED
SI_INFORMTN_SCHEMA SYSAUX EXPIRED & LOCKED
ORDPLUGINS SYSAUX EXPIRED & LOCKED
MDSYS SYSAUX EXPIRED & LOCKED
CTXSYS SYSAUX EXPIRED & LOCKED
ANONYMOUS SYSAUX EXPIRED & LOCKED
========================================================

Check the AWR (Automatic Workload Repository) settings as outlined in this metalink note:
Space Management In Sysaux Tablespace with AWR in use
Doc ID: Note:287679.1
Werner

Tablespace PSAPSR3DB getting full again and agin

Dears,
In our PI 7.1 system,Installed on AIX tablespace PSAPSR3DB is getting full very rapidly.
10 GB space is getting full in 2 days.
As per our PI developer they are not saving any such huge data in PI, data transfer through PI is going on but I am not sure in that case does PI is storing any data.
Please suggest how can I stop this rapid increment in data of this tablespace.
Can I clean some of its data by any way or if possible how not to save data getting transfer through PI.
Regards,
Shivam Mittal

Hi Shivam,
This table references to standard tablespace for JAVA stack of SAP objects. It's possible that the clean job of Java Stack have been executed with errors. Check this job in Netweaver Administrator application ( http://servername:port/nwa ).
Have you storing synchronous messages? Maybe you have to tunning the ABAP and Java Stack.
Have you configured the archive and delete jobs in SXMB_ADM?
Best regards
Ivá

SYSAUX tablespace full

Hi,
What will happen if SYSAUX tablespace size is full and we do not increase the size?
Will the database hang or continue to run?
AFAIK if SYSTEM tablespace is full then database gets hanged.
Edited by: oratest on Feb 13, 2010 11:00 PM

If sysaux tblsp is full, the database would still remain operational except the functionality associated with AWR will not work. I would expect that the snapshots that by default gets gathered every hour cannot be stored anymore unless you increase the sysaux tablespace size.
Your database users would still be able to work normally though.

UNDO tablespace getting full

My undo tablespace is getting full because of uncommited deletes performed by jdbc thin client sessions.
How can I solve this problem permanently?
Size of undo tablespace is 5.5GB
I am facing an undo tablespace full issue
Below are the sessions which maybe causing the problem.
select s.sid,
s.serial#,
s.sql_id,
s.prev_sql_id,
s.SCHEMANAME ,
s.OSUSER ,
s.program,
USED_UBLK,USED_UREC from v$session s, v$transaction t where s.taddr=t.addr order by USED_UREC;
3909 30842 fgcp0qn1bqzx9 XLTDB5 xltwrk5 JDBC Thin Client 504 45257
5133 53593 fgcp0qn1bqzx9 XLTDB5 xltwrk5 JDBC Thin Client 07 54482
4525 35108 fgcp0qn1bqzx9 XLTDB10 xltwrk10 JDBC Thin Client 2381 192853
4428 38484 fgcp0qn1bqzx9 XLTDB1 xltwrk1 JDBC Thin Client 8682 634540
For this sql id :fgcp0qn1bqzx9 there are more than 14k executions per hour.
Below is the query for this sql id:
/* TJAPI_SubTrxTransient_deleteTrb1SubTrxTransient_0 */ DELETE FROM TRB1_SUB_TRX_TRANSIENT
Some other details
++++++++++++
Oravle version:11.1.0.7
OS:SunOS
++++++++++++

Perhaps an interesting link:
http://oracledisect.blogspot.com/2008/05/who-is-using-your-undo-space.html
Perhaps you can use Oracle Resource Manager, create a resource plan and switch sessions to a different consumer group once they reach a certain treshold.
http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/dbrm004.htm
Btw are these distributed transactions?
DBA commit other session's transaction?
Edited by: Markus Waldorf on Sep 9, 2010 7:57 PM

TEMP tablespace getting full while inserting a CLOB in Trigger

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

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

SYSAUX tablespace full and snapshots not deleted

hi all,
I am on 10g linux.
1) my sysaux tablespace is full and i realize there are many awr snapshots lying around.
so i went to my OEM console -> Automatic Workload Repository and this are basically my settings
Snapshot Retention (days) 7
Snapshot Interval (minutes) 60
Collection Level TYPICAL
Next Snapshot Capture Time Sep 25, 2012 8:27:41 AM
However, when i check the amount of snapshots
->
Manage Snapshots and Preserved Snapshot Sets
Snapshots 247
Preserved Snapshot Sets 0
Latest Snapshot Time Sep 25, 2012 7:27:41 AM
Earliest Snapshot Time Jun 27, 2012 10:20:16 PM
q1) i have got 247 snapshots dated as early as Jun 27 but i am only retaining 7 days of snapshots ?
7 * 24 (1 hour snapshot frequency) != 247
there is no snapshot baseline also.
q2) why my latest snapshot time is dated way back to sept 25 ? is it because my sysaux is full for a longtime thus no more snapshot can be taken ? but i thought the retention of 7 days will remove obsolete snapshots ?
Please advise.
Regards,
Noob

Hi,
there are some problem in delete AWR stats.
For example, if the delete takes more 5 minute it's interrupted.
Look which component grows using awrinfo.sql under $ORACLE_HOME/rdbms/admin
You may execute the delete procedure manually than move and rebuild the tables.

Sysaux Tablespace full 95 Percentage...

Hi,
I Have a tablespace call sysaux around 2GB.
The total tablespace is used around 1.9 GB and only 100 MB is free.
The 77 % of 1.9 GB is used to store AWR reports.
There are aound 4000 Awr report store in this table space...
I deleted around 3500 awr reports using drop_sanpshot.range option..
After droping this snapshot, still the status for Sysaux tablespaces used is around 1.9 GB.
system is not re-claiming the free disk space ...
What i can do to free up used sapce since, I have very less disk space on the disk itself ...
SSM

>>
system is not re-claiming the free disk space ...
Fortunately, Oracle won't reduce the filesize, even if you drop objects inside tablespace.
If you want reclaim space, you need to find your own solution. In your case, exp, recreate database, and import is a way.
Nicolas.

UNDOTBS1 and SYSAUX Tablespace Filename Mismatch in Oracle 11g XE

Hi,
We have installed Oracle 11g XE 32 bit on Windows and found that Tablespace name and filenames are mismatched for UNDOTBS1, SYSAUX.
If you run following query:
SELECT TABLESPACE_NAME, FILE_NAME FROM DBA_DATA_FILES; You will get below output:
TABLESPACE_NAME                    FILE_NAME
============================================================================
USERS                C:\ORACLE\ORACLE11GXE\APP\ORACLE\ORADATA\XE\USERS.DBF
UNDOTBS1           C:\ORACLE\ORACLE11GXE\APP\ORACLE\ORADATA\XE\SYSAUX.DBF
SYSAUX                C:\ORACLE\ORACLE11GXE\APP\ORACLE\ORADATA\XE\UNDOTBS1.DBF
SYSTEM                C:\ORACLE\ORACLE11GXE\APP\ORACLE\ORADATA\XE\SYSTEM.DBFNotice the difference between UNDOTBS1 and SYSAUX.
UNDOTBS1 tablespace has filename SYSAUX.DBF while
SYSAUX tablespace has filename UNDOTBS1.DBF
Is this a bug or just a wrong name mapping?
Will this affects the internal behavior of tablespace as well for undo tablespace and APEX Installation?
Regards,
Sohil Bhavsar.

Error: ORA-03297 ... related to this mismatch of UNDOTBS1 with SYSAUXActually its related to trying to resize a file smaller than the existing extents in use, so yes, restores aren't the only place that could cause confusion from the "incorrect" datafile names.
Fixing it could be done in one pass if you don't mind adjusting filenames so they don't clash, i.e. shut down your database instance and move the files at the OS, startup mount and rename the files in the database.
Don't use the services applet, the instance has to be shutdown with sqlplus, leave the database service running. If you try to open the database with OS files renamed but not corrected in the instance, the database won't open if there are troubles with the undo datafile.
sqlplus /nolog
conn /as sysdba;
... connected ...
col name format a60
col tsname format a10
set lines 120
select t.name tsname, d.name, d.BYTES / 1024 / 1024 mb from v$tablespace t, v$datafile d where t.ts# = d.ts#;
system .../system.dbf <n>
shutdown immediate;
... database closed ...
exit
cd <datafile directory>
move sysaux.dbf undotbs01.dbf
move UNDOTBS1.DBF sysaux.dbf
# or use file explore GUI after shutdown
sqlplus /nolog
conn /as sysdba;
... connected to idle instance ...
startup mount;
... SGA, instance size info ...
alter database rename file 'C:\...<full path>\SYSAUX.DBF' to 'C:\...<full path>\UNDOTBS01.DBF';
alter database rename file 'C:\...<full path>\UNDOTBS1.DBF' to 'C:\...<full path>\SYSAUX.DBF';
select t.name tsname, d.name, d.BYTES / 1024 / 1024 mb from v$tablespace t, v$datafile d where t.ts# = d.ts#;
... make sure you get what was asked for ...
TSNAME     NAME                                                       MB
SYSTEM     C:\ORACLEXE\APP\ORACLE\ORADATA\XE\SYSTEM.DBF              360
SYSAUX     C:\ORACLEXE\APP\ORACLE\ORADATA\XE\SYSAUX.DBF              660
UNDOTBS1   C:\ORACLEXE\APP\ORACLE\ORADATA\XE\UNDOTBS01.DBF            25
USERS      C:\ORACLEXE\APP\ORACLE\ORADATA\XE\USERS.DBF               100
alter database open;
... database altered ...

System tablespace is 99% full

hello all,
I created a new Oracle 11gR2 11.2.0.3.
i am checking the Oracle Enterprise manager, i saw the my system tablespace size is 700 M and it is 99% full.
Do i have to re size system tablespace datafile?
does that affect my database, do i have to restart it ?
99% full of system table space will affect my database performance?
How can I specify the best size of my system tablespace?
Regards,

That does seem to be the size system tablespace you get with a new db. After a couple of years, mine is still that size, though it appears something has come and gone, but I don't really care.
Recent versions separate out various things into the sysaux tablespace. You do have to watch out that it doesn't start growing. dbconsole has an interesting tablespace map (and there are command lines ways also) to see what segments are in tablespaces. Don't worry too much about any apparent "fragmentation" (and I use that word loosely, and probably shouldn't) you see in the mapping of segments, but it is useful to be aware [url http://docs.oracle.com/cd/B28359_01/server.111/b28310/create004.htm#i1011308]what is in sysaux and why it might start growing. Autoextend is perfectly fine for these tablespaces.
Edit: Auditing is special, and may cause the system tablespace to grow under certain circumstances.
Edited by: jgarry on Apr 11, 2012 3:27 PM

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

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.

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

DBIF_REPO_SQL_ERROR after SGEN: Tablespace is possibly full

Dear SAP gurus,
This is an a SAP ERP60 EHP3 system with Oracle we are in the process of patching it. First, We have download all sw components patches (EHP3 SPS6) we patched java stack and then the sw components -SAP_ABA and SAP_BASIS from SP17 to SP22.
We ran SGEN for SAP_ABA and SAP_BASIS and it is when the issues start coming out.
"2.043 generation error(s): Tablespace is possibly full (with load tables)"
Then we tried to access any SAP Transaction related to ORacle:
"DBIF_REPO_SQL_ERROR".
From work process logs:
C Wed Feb 15 11:02:26 2012
C OCIStmtExecute() failed with -1=OCI_ERROR
C SQL error 600:
C *** ERROR => Error 600 in stmt_execute() from oci_execute_stmt(),
orpc=119
[dbsloci.c 12981]
C *** ERROR => ORA-600 occurred when executing SQL stmt (parse error
offset=0)
[dbsloci.c 12983]
C
sc_p=0x5901b30,no=182,idc_p=0x5917a88,con=0,astyle='font-family:courier'
ct=1,slen=67,smax=256,#vars=
2,stmt=0x5dcaa30,table=D010INC
C INSERT INTO "D010INC" ( "MASTER" , "INCLUDE" ) VALUES ( :A0 , :A1 );
C
sc_p=0x5901b30,no=182,idc_p=0x5917a88,con=0,astyle='font-family:courier'
ct=1,slen=67,smax=256,#vars=
2,stmt=0x5dcaa30,table=D010INC
C Dumping DBSL stmt. cache:
C prep=0,lit=0,nsql=0,lobret=0,xop=1,dbcnt=119,upsh=
(nil),stmtp=0x5bcc0f8,rtc=0
C IN :
cols=2,rmax=387,xcnt=232,rpc=0,rowi=232,rtot=232,upto=4294967295,rsize=16
0,vmax=32,bound=1,iobuf_p=0x5a2a7b0,vda_p=0x5db8470
C lobs=0,lmax=0,lpcnt=0,larr=(nil),lcurr_p=(nil),rret=0
C INSERT INTO "D010INC" ( "MASTER" , "INCLUDE" ) VALUES ( :A0 , :A1 );
B ***LOG BYL=> DBQ action required because of database error
[dbsh#3 @ 1104] [dbsh 1104 ]
B SQL code: 600, SQL text: ORA-00600: internal error code, arguments:
[4553], [2], [0], [], [], [], [], []
B ***LOG BY4=> sql error 600 performing CLC on table D010INC
[dbrepo#5 @ 6034] [dbrepo 6034 ]
B ***LOG BY0=> ORA-00600: internal error code, arguments: [4553], [2],
[0], [], [], [], [], [] [dbrepo#5 @ 6034] [dbrepo 6034 ]
B DBREPO: new rc return for insert_inc_difference
A TH VERBOSE LEVEL FULL
We tried to extend the tablespace PSAPSR700 (which is related to table
D010INC) but we are still getting dumps like "DBIF_REPO_SQL_ERROR".
Can you please guide us how to proceed?This query is very urgent since we
prefer that our developers do not work until we resolve the issue.
Thanks in advance, Marc

Thanks for your reply Venky,
RMAN> connect target /
connected to target database: SHD (DBID=1683093070)
using target database control file instead of recovery catalog
RMAN> backup check logical validate (datafile 2);
Starting backup at 16-FEB-12
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=193 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 02/16/2012 12:22:36
ORA-19602: cannot backup or copy active file in NOARCHIVELOG mode
alert_SID.log
Thu Feb 16 09:43:42 2012
Errors in file /oracle/SHD/saptrace/usertrace/shd_ora_3380.trc:
ORA-00600: internal error code, arguments: [4553], [2], [0], [], [], [], [], []
Thu Feb 16 09:43:47 2012
Doing block recovery for file 2 block 3455
Block recovery from logseq 19230, block 22155 to scn 1338742588
Thu Feb 16 09:43:47 2012
Recovery of Online Redo Log: Thread 1 Group 2 Seq 19230 Reading mem 0
Mem# 0: /oracle/SHD/origlogB/log_g12m1.dbf
Mem# 1: /oracle/SHD/mirrlogB/log_g12m2.dbf
Block recovery completed at rba 19230.22329.16, scn 0.1338742589
Doing block recovery for file 2 block 297161
Block recovery from logseq 19230, block 12545 to scn 1338742588
Thu Feb 16 09:43:47 2012
Recovery of Online Redo Log: Thread 1 Group 2 Seq 19230 Reading mem 0
Mem# 0: /oracle/SHD/origlogB/log_g12m1.dbf
Mem# 1: /oracle/SHD/mirrlogB/log_g12m2.dbf
Block recovery completed at rba 19230.22329.16, scn 0.1338742589
Doing block recovery for file 35 block 352889
Block recovery from logseq 19230, block 22155 to scn 1338742590
Thu Feb 16 09:43:48 2012
Recovery of Online Redo Log: Thread 1 Group 2 Seq 19230 Reading mem 0
Mem# 0: /oracle/SHD/origlogB/log_g12m1.dbf
Mem# 1: /oracle/SHD/mirrlogB/log_g12m2.dbf
Block recovery stopped at EOT rba 19230.22329.16
Block recovery completed at rba 19230.22329.16, scn 0.1338742589
Thu Feb 16 09:43:49 2012
Errors in file /oracle/SHD/saptrace/usertrace/shd_ora_30410.trc:
ORA-00600: internal error code, arguments: [4553], [2], [0], [], [], [], [], []
Thu Feb 16 09:43:54 2012
dev_server0
Wed Feb 15 10:55:06 2012
A GENER request remote generation: CL_SRT_WSP_HELPER_METHODS=====CP.
A
A Wed Feb 15 10:55:19 2012
A GENER request remote generation: RSDSOSCCM.
A
A Wed Feb 15 10:55:23 2012
A GENER starting inline generation: RSDSOSCCM (reason: compile error during remote generation).
C
C Wed Feb 15 10:55:26 2012
C     OCIStmtExecute() failed with -1=OCI_ERROR
C     SQL error 600:
C *** ERROR => Error 600 in stmt_execute() from oci_execute_stmt(), orpc=9
[dbsloci.c    12981]
C *** ERROR => ORA-600 occurred when executing SQL stmt (parse error offset=0)
[dbsloci.c    12983]
C sc_p=0x58fd3f0,no=62,idc_p=0x5916100,con=0,act=1,slen=67,smax=256,#vars=2,stmt=0x5cecfb0,table=D010INC
C INSERT INTO "D010INC" ( "MASTER" , "INCLUDE" ) VALUES ( :A0 , :A1 );
C sc_p=0x58fd3f0,no=62,idc_p=0x5916100,con=0,act=1,slen=67,smax=256,#vars=2,stmt=0x5cecfb0,table=D010INC
C Dumping DBSL stmt. cache:
C prep=0,lit=0,nsql=0,lobret=0,xop=1,dbcnt=9,upsh=(nil),stmtp=0x5cedc58,rtc=0
C IN : cols=2,rmax=387,xcnt=9,rpc=0,rowi=9,rtot=9,upto=4294967295,rsize=160,vmax=32,bound=1,iobuf_p=0x5da5400,vda_p=0x5cee310
C       lobs=0,lmax=0,lpcnt=0,larr=(nil),lcurr_p=(nil),rret=0
C INSERT INTO "D010INC" ( "MASTER" , "INCLUDE" ) VALUES ( :A0 , :A1 );
B ***LOG BYL=> DBQ action required because of database error            [dbsh#3 @ 1104] [dbsh    1104 ]
B SQL code: 600, SQL text: ORA-00600: internal error code, arguments: [4553], [2], [0], [], [], [], [], []
B ***LOG BY4=> sql error 600    performing CLC on table D010INC    [dbrepo#5 @ 6034] [dbrepo 6034 ]
B ***LOG BY0=> ORA-00600: internal error code, arguments: [4553], [2], [0], [], [], [], [], [] [dbrepo#5 @ 6034] [dbrepo 6034 ]
B DBREPO: new rc return for insert_inc_difference
A TH VERBOSE LEVEL FULL
A ** RABAX: level LEV_RX_PXA_RELEASE_MTX entered.
A ** RABAX: level LEV_RX_PXA_RELEASE_MTX completed.
A ** RABAX: level LEV_RX_COVERAGE_ANALYSER entered.
A ** RABAX: level LEV_RX_COVERAGE_ANALYSER completed.
A ** RABAX: level LEV_RX_SAVE_SHMLOCKS entered.
A ** RABAX: level LEV_RX_SAVE_SHMLOCKS completed.
A ** RABAX: level LEV_RX_RESET_SHMLOCKS entered.
Regards, Marc

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 is getting full

Similar Messages

Maybe you are looking for