Re: Oracle XE Corruption
- From: Evan Pettrey <jepettrey@xxxxxxxxx>
- To: Andrew Kerber <andrew.kerber@xxxxxxxxx>
- Date: Tue, 24 Aug 2010 14:02:06 -0400
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.'
>
Other related posts:
