I guess corruption was a poor choice of wording on my behalf, my apologies. The database server is running on VMware ESX with 4 HP blades using an HP MSA storage solution. As such, I don't believe this is an actual storage corruption because I have created clones of the system and brought them up and the error still persisted. The actual error being reported is below: Errors in file /usr/lib/oracle/xe/app/oracle/admin/XE/bdump/xe_smon_3351.trc: ORA-00604: error occurred at recursive SQL level 1 ORA-08102: index key not found, obj# 576, file 1, block 4567 (2) Tue Aug 24 08:28:53 2010 WARNING: inbound connection timed out (ORA-3136) Tue Aug 24 08:33:16 2010 Errors in file /usr/lib/oracle/xe/app/oracle/admin/XE/bdump/xe_smon_3351.trc: Tue Aug 24 08:33:17 2010 Errors in file /usr/lib/oracle/xe/app/oracle/admin/XE/bdump/xe_smon_3351.trc: ORA-00604: error occurred at recursive SQL level 1 ORA-08102: index key not found, obj# 576, file 1, block 4567 (2) Tue Aug 24 08:38:18 2010 Errors in file /usr/lib/oracle/xe/app/oracle/admin/XE/bdump/xe_smon_3351.trc: Tue Aug 24 08:38:18 2010 Errors in file /usr/lib/oracle/xe/app/oracle/admin/XE/bdump/xe_smon_3351.trc: ORA-00604: error occurred at recursive SQL level 1 Thanks for all the help. On Tue, Aug 24, 2010 at 1:55 PM, Andrew Kerber <andrew.kerber@xxxxxxxxx>wrote: > I suggested new tablespace in case there is physical corruption. Moving > the index would take it off of the bad spot. > > > On Tue, Aug 24, 2010 at 12:47 PM, Bobak, Mark <Mark.Bobak@xxxxxxxxxxxx>wrote: > >> I’m not sure the new tablespace would be required either, but I’m pretty >> sure ‘online’ option is out of the question, as that’s an Enterprise Edition >> only option, if I’m not mistaken. >> >> >> >> -Mark >> >> >> >> *From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto: >> oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Uzzell, Stephan >> *Sent:* Tuesday, August 24, 2010 1:44 PM >> *To:* 'andrew.kerber@xxxxxxxxx'; jepettrey@xxxxxxxxx >> >> *Cc:* Oracle-L@xxxxxxxxxxxxx >> *Subject:* RE: Oracle XE Corruption >> >> >> >> Wouldn’t just a simple rebuild online suffice? Why move it to a new >> tablespace if it is an object owned by SYS? >> >> >> >> * >> _____________________________________________________________________________ >> * >> >> *Stephan Uzzell |** **MICROS Systems, Inc.** * >> >> >> >> Database Administrator - OPERA Global Technical Services >> >> 7031 Columbia Gateway Dr, Columbia, MD 21046 | ( 443.285.8000x2760 | >> 7443.285.6505 >> >> >> >> *From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto: >> oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Andrew Kerber >> *Sent:* Tuesday, 24 August, 2010 13:38 >> *To:* jepettrey@xxxxxxxxx >> *Cc:* Oracle-L@xxxxxxxxxxxxx >> *Subject:* Re: Oracle XE Corruption >> >> >> >> Create a new tablespace (datafile), and try this command: >> >> alter index SMON_SCN_TIME_TIM_IDX rebuild tablespace new_tablespace; >> >> On Tue, Aug 24, 2010 at 12:31 PM, Evan Pettrey <jepettrey@xxxxxxxxx> >> wrote: >> >> Hello all, >> >> >> >> I’ve just taken a job as a sys admin with a company who uses an Oracle XE >> database on one of their production machines and it is exceptionally >> important for me to limit downtime. >> >> >> >> Immediately upon taking the position I setup backups and an alerting >> system. Well yesterday I started getting an alert that their Oracle DB >> server was running out of space. After further investigation I learned that >> one of their bdump trace files was growing at a rate of nearly 1GB a day. At >> this rate, the hard drive will run out of space sometime in the next few >> days. >> >> >> >> As such, I began poking around to see why this trace log was growing so >> fast and so large. By looking through the log I was able to determine that >> the error was with Object ID 576 and has existed since at least January >> (I’ve only been here a few weeks). >> >> >> >> I checked to see what object 576 was and determined that it is: >> >> >> >> SQL> select object_name, object_type from dba_objects where object_id = >> 576; >> >> OBJECT_NAME >> ------------------------------ >> >> OBJECT_TYPE >> ------------------------------ >> >> SMON_SCN_TIME_TIM_IDX >> INDEX >> >> >> >> >> >> Since the corruption has been around since at least January, restoring the >> database from a backup really isn’t option...this object index needs to be >> rebuilt. >> >> >> >> I know I can rebuild the object by running: >> >> >> >> alter index smon_scn_time_tim_idx rebuild; >> >> >> >> However I’m not sure that this will actually resolve the issue fully and I >> can’t afford to create other problems in the process, leading to the >> database not being functional after working on it. The database apparently >> takes around 30 minutes to bring back up after it has been shutdown so I >> don’t want to have to do this more than once. >> >> >> >> I’m not a DBA and am a little lost at this point in time. A previous >> co-worker of mine suggested this would be a good place to see help since >> Oracle XE isn’t supported by Oracle and I don’t have a metalink account. If >> anybody could help me out I would greatly appreciate it. >> >> >> >> >> >> Thanks in advance. >> >> >> >> >> >> Regards, >> >> Evan >> >> >> >> >> -- >> Andrew W. Kerber >> >> 'If at first you dont succeed, dont take up skydiving.' >> > > > > -- > Andrew W. Kerber > > 'If at first you dont succeed, dont take up skydiving.' >