2006/12/07

weird...

this showed up in one of our 10gr2 alert logs:

Tue Dec 5 10:00:58 2006
Thread 1 advanced to log sequence 1411
Current log# 5 seq# 1411 mem# 0: /u209/oradata/ZOT/ZOT_redo05.log
Tue Dec 5 10:21:56 2006
Some indexes or index [sub]partitions of table SYS.WRH$_SEG_STAT have been marked unusable
Tue Dec 5 10:30:37 2006
Thread 1 advanced to log sequence 1412
Current log# 1 seq# 1412 mem# 0: /u209/oradata/ZOT/ZOT_redo01.log


how about an error code, mr Oracle? perhaps we should read the alert log in its entirety now? instead of "grepping", like everyone has done for longer than I can remember?

of course, a little bit of investigation showed this:

ZOT->
select * from dba_part_indexes
2 where table_name = 'WRH$_SEG_STAT';
Press return to continue...

OWNER INDEX_NAME
------------------------------ ------------------------------
TABLE_NAME PARTITI SUBPART PARTITION_COUNT
------------------------------ ------- ------- ---------------
(etcetc, snipped for brevity)
SYS WRH$_SEG_STAT_PK
WRH$_SEG_STAT RANGE NONE 2
0 2 0 LOCAL
PREFIXED SYSAUX 10 2
255 DEFAULT
DEFAULT
DEFAULT
DEFAULT
DEFAULT 0 0
NONE DEFAULT
****
1 row selected.


and

ZOT->select index_name,partition_name,high_value,status,tablespace_name
2 from dba_ind_partitions
3 where index_name = 'WRH$_SEG_STAT_PK';
Press return to continue...

INDEX_NAME PARTITION_NAME
------------------------------ ------------------------------
HIGH_VALUE
--------------------------------------------------------------------------------
STATUS TABLESPACE_NAME
-------- ------------------------------
WRH$_SEG_STAT_PK WRH$_SEG_STAT_MXDB_MXSN
MAXVALUE, MAXVALUE
USABLE SYSAUX

WRH$_SEG_STAT_PK WRH$_SEG_ST_3930333368_0
3930333368, MAXVALUE
USABLE SYSAUX


2 rows selected.


so: which one exactly was marked as "unusable"?

beats me. ain't AWR peachy? I like this kind of automation, though. yes, it simply prunes partitions older than a week and this message is part of that process.

makes sense: anything to reduce my workload is welcome. just wish someone at Oracle had the vision to write messages in the alert log that can be "grepped" for...

while I'm here and following on from my very rude interjection - my apologies - after Joel's reply, I must mention these:

bugs 3406157, 5237272, 5458753

I won't mention what they are, it'd be breaking our support agreement with Oracle. anyone with proper and authorized Metalick access can check what this is about.

scary eh? I've seen this happen in 9.2.0.6 in Linux. could never pinpoint it to any known bug. by luck I stumbled upon this and from there I got the bugs above.

that is a violation of the most basic rules of safety in any database!

unbreakable, mr Oracle? Why bother? it's BROKEN already!

quite frankly: although this is supposedly fixed in 10.2.0.3, it's just completely unacceptable that it isn't in ALL PRIOR VERSIONS all the way down to 9ir1!

perhaps it's time for mr Oracle to stop pandering to the "technology de jour" and other moronic flights of fancy and concentrate their R&D on fixing bugs in what is after all their flagship product?

if I have to pay a premium price for this sort of crap, then I simply won't.
or should we start learning Postgres?

0 Comments:

Post a Comment

Links to this post:

Create a Link

<< Home