RE: HELP URGENT CORRUPTED DATA
- From: "Freeman, Donald" <dofreeman@xxxxxxxxxxx>
- To: <paulastankus@xxxxxxxxx>, "Alex Gorbachev" <gorbyx@xxxxxxxxx>
- Date: Fri, 19 May 2006 15:41:16 -0400
Paula, can you tell us exactly what error you are getting? How do you know
that copy one and copy two are different? If we knew exactly how it was
failing we might be able to provide more informed advice.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Paula Stankus
Sent: Friday, May 19, 2006 3:07 PM
To: Alex Gorbachev
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: HELP URGENT CORRUPTED DATA
Alex,
Add to that that the system I have inherited had nologging and was not
properly synchronizing their backups to nologging and wallah! The problem is
eye-balling the data we come up with no differences.
My question is: if there are hidden characters in data elements (so
there are differences but we don't see them) - will a MINUS find them?
:)
Alex Gorbachev <gorbyx@xxxxxxxxx> wrote:
If you restore your database to a point in time in the past than
transactional integrity is preserved. However, your application
should
be done in such a ways that business transaction is done as
database
transaction. This was the change is atomic. If your business
transaction is done so that you have 10 commits for one business
transaction than you might have got restored to the middle of
this
business transaction. Such inconsistencies shoule be than
handled by
application otherwise it's a design flaw. Often these might be
bastches that are commiting work every so many records. For
example,
your purge batch might have purged half of your tables and
introduced
inconsistency.
Also you didn't really say what exactly wrong with it and how
you see
the problem from application point of view - some query returns
wrong
result? Or it's just users see "something" wrong and you can't
identify what's that. If the latter, than I would suggest to
narrow
down the area.
Regarding point A - it's possible that index can be corrupted
and you
are correct in the way to detect it. Fix is to rebuild the
index. Btw,
PiT recovery should not cause index corruption becasue it's
updated as
part of the transaction and PiT recovery doesn't leave
non-commited
transactions on the half way.
Point B - I am not sure about your question. Do you mean string
comparison?
Good luck!
2006/5/19, Paula Stankus :
>
> Guys,
>
> We recovered a database, did a dbverify - everything looked
good, exports
> are working fine. However, we recovered to an earlier point
(few hours
> earlier) and on the "earlier" database we have no errors in a
specific
> function of the application in the "later" one we have
errors. We have been
> beating our hands against the brick wall doing comparisons of
the data - the
> comparisons - table by table, column by column look okay. We
have been
> working on this issue round-the-clock for days.
>
> Questions:
>
> A-Can an index be somehow causing this problem and can we use
validate
> structure or something to be sure of the validity of the
index? - analyze
> table validate structure...cascade...
>
> B-Can there be missing characters (characters we cannot
visually see)
> causing the problem and can a "MINUS" find it if there is? :)
>
> Thanks,
>
> Paula
>
>
> ________________________________
> New Yahoo! Messenger with Voice. Call regular phones from
your PC and save
> big.
>
>
--
Best regards,
Alex Gorbachev
http://oracloid.blogspot.com
_____
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great
rates starting at 1¢/min.
<http://us.rd.yahoo.com/mail_us/taglines/postman7/*http://us.rd.yahoo.com/evt=39666/*http://messenger.yahoo.com>
Other related posts:
