Subject | Re: Database Validation |
---|---|
Author | Adam |
Post date | 2006-04-05T00:19:37Z |
> When I run a full validation on a particular database, I get theI note that you have resolved the issue. Basically some data is
> following results:
>
>
>
> Summary of validation errors
>
>
>
> Number of index page errors : 52
>
> Number of database page errors : 33
>
>
>
>
>
> I have tried running, Check, Mend, etc, but the results remain the same.
>
> Apart from one of the programs bulk update functions not running through
> which is why I tried this), the database appears to be fine.
>
>
>
> Is this anything to worry about?
>
corrupt. It sounds to me like the data resides in some area that only
your bulk update functions go near, perhaps some historical record.
Basically, mend puts a marker next to the corrupt record version so it
does not get backed up. Providing the corruption is minor, the
backup-restore will then ignore that record version and you are fine.
(as indeed happenned in this case).
In some cases, the backup fails. You can then try to skip garbage
collection during backup using the -g switch. If that is ok, then you
can just restore, otherwise you need to change your mind to datapump mode.
You will find that the backup failed in some table. Open up iSQL and
run something like
select *
from suspecttable
order by id
Note the id where the thing falls to pieces, lets say 50. Reconnect
and change the query to:
select *
from suspecttable
where id <= 49 and id >= 51
order by id
If it was just id 50 that went south, then you can save everything
else apart from that record.
Create an identical table to suspecttable, called tmpsuspecttable, and
run the following query.
insert into tmpsuspecttable (.....)
(select ....
from suspecttable
where id <= 49 and id >= 51
);
This will copy all the good records to the tmp table.
Now find a datapump utility (I use the one from clevercomponents) and
link up the source and destination tables. You will need to map the
tmp table in the source to the normal table in the destination.
Once data pumping is complete, you will need to fix up any
dependencies that were relying on that corrupt record manually.
Perform a backup-restore cycle on the new database for piece of mind.
Should you be concerned, well yes corruption should never happen. It
is normally due to hardware failure. Certainly if the machine is a
repeat offender, you need to get the database on another machine and
do some investigation.
Adam