Re: data corruption

From: Maxim Demenko <mdemenko_at_gmail.com>
Date: Tue, 21 Jul 2009 10:16:31 +0200
Message-ID: <4A65795F.1080301_at_gmail.com>



helter skelter schrieb:
> Hi, I've got some strange situation:
>
> desc table_1;
> trans_id number
> load_time timestamp(6) nullable
>
>
> select trans_id, load_time
> from table_1
> where trans_id in (133,167,199);
>
> trans_id load_time
> 133
> 167
> 199
>
> select trans_id, load_time
> from table_1
> where trans_id in (133,167,199);
> and load_time is null
>
> trans_id load_time
> 133
>
> ...something wrong, so I tried:
>
> select trans_id, to_char(load_time)
> from table_1
> where trans_id in (133,167,199);
>
> trans_id load_time
> 133
> 167 77/08/07 08:51:00,000000
> 199 77/07/17 12:51:00,000000
>
> Additionally:
>
> select trans_id, to_char(load_time,'DD-MM-YYYY')
> from table_1
> where trans_id in (133,167,199);
>
> ORA-01877: string is too long for internal buffer
>
> But:
> select trans_id, to_char(load_time,'DD-MM')
> from table_1
> where trans_id in (133,167,199);
>
> trans_id load_time
> 133
> 167 07-08
> 199 17-07
>
> Can somebody tell me what is going on ? :)
>
> I've checked tablespace with rman 'valiadte backup check logical
> tablespace ...' and there is no block corruption in
> v$database_block_corruption, no other errors in alert_log
>
> oracle 10.2.0.4, rhel5
>
>
> thanks

There are some hits on metalink if you search for "ORA-01877 timestamp" You can try to find, what is really stored in your table ( like select trans_id,dump(load_time) from table_1 where trans_id in (133,167,199)), but you'll probably get only more certainity that you have corrupted data, so the best bet would be what the error message suggests:

01877, 00000, "string is too long for internal buffer" // *Cause: This is an internal error.
// *Action: Please contact Oracle Worldwide Support.

Best regards

Maxim

-- 
Why make things difficult, when it is possible to make them cryptic
and totally illogical, with just a little bit more effort?

Aksel Peter J?rgensen
Received on Tue Jul 21 2009 - 03:16:31 CDT

Original text of this message