Question Prorest Failed With 1147 And 1103

[BigSlick]

Hi all,

OE10.2BSP05 64 bit, Windows 64bit.

Hopefully just a quick one. Just got the below error message. there's quite a few entries around with error 1147, mainly surrounding disk space but nothing i can find with error 1103. Has anyone ever experienced this?
Our process takes a backup on one server, transfers it to another and restores. Maybe something went wrong with the transfer, but thought i'd ask.

[2015/09/27@14:27:09.299+0100] P-5620       T-2600  I          : (614)   A previous prorest E:\db\angelo failed. 
[2015/09/27@14:27:09.313+0100] P-5620       T-2600  I          : (451)   Prorest session begin for restorer on batch. 
[2015/09/27@14:27:10.454+0100] P-5620       T-2600  I          : (1368)  Full restore started. 
[2015/09/27@14:27:10.455+0100] P-5620       T-2600  I          : (12854) Restoring database from F:\db\angelo.db. 
[2015/09/27@16:24:54.986+0100] P-5620       T-2600  I          : (1147)  CRC check error reading backup block 3275318 
[2015/09/27@16:24:54.990+0100] P-5620       T-2600  I          : (1103)  Next block in sequence should be 3275319 but got 0 instead. 
[2015/09/27@16:24:54.990+0100] P-5620       T-2600  I          : (1618)  Restore failed. 
[2015/09/27@16:24:54.991+0100] P-5620       T-2600  I          : (8564)  !!! ERROR - Database restore utility FAILED !!! 
[2015/09/27@05:02:08.804+0100] P-5620       T-2600  I          : (334)   Prorest session end.

thanks

 

[Cringer]

I've seen that before but can't remember the details.
"A previous prorest E:\db\angelo failed."
What happens if you restore the database in a new location (make sure you have an st file in place of course)?

 

[TheMadDBA]

Something is horribly wrong with the backup file. CRC errors mean it couldn't decode the block properly.

Make sure the file was copied correctly and not while it was still being written. Depending on how you are copying the file there are methods to make sure it happens correctly.

 

[RealHeavyDude]

You backup file is corrupted. There is no indication as to the why as the prorest utility only encounters the corruption. Usually corruption of backup files comes from moving/copying them while they are still written or media failure. We had some problems with writing backup files to file systems residing on a paricular miserably SAN. Until we were able to have those file systems moved to a more reliable SAN we had to work around the issue with having probkup writing the database blocks redundant to the backup file ( which obviously makes the backup files larger ... ). There is a -red parameter to probkup that you might check.

This is also one reason as to why you should test your disaster recovery strategy on a regular basis to avoid winding up with corrupt backup files when you need them most.

Heavy Regards, RealHeavyDude.

 

[BigSlick]

Thanks for the feedback guys!

The backups are performed online and copied to another server, i guess it tried to take the copy before the probkup command had finished then?

I'll look at the -red command too.

This is part of our DR plan!

 

[TheMadDBA]

No way for us to tell what the root issue is... but you could try copying the file again and see if the issue goes away. Also look into the scripts.

 

[BigSlick]

A bit more info on this;

the backup file finished at 00:30:

[2015/11/16@00:30:14.017+0000] P-43188      T-2696  I BACKUP339: (1364)  Full backup successfully completed.

and the transfer of the backup file happened at 01:00

That, to me, indicates that it cannot be writing to the backup file whilst it is transferring.

I'd like to copy the file again but its 1.4TB in size and would kill the network

 

[Cringer]

Have a look at the -vs option for backups. It's an old parameter that was used if your physical backup device was smaller than your actual backup to span the backup over multiple tapes/disks. We make use of that feature to split our backups into chunks. It's a pain in some ways, but it does make things like this easier to track down, and you can check timestamps on the chunks easily to see what's what. If you see what I mean.

 

[BigSlick]

Thanks Cringer. I know what you mean.

I'm just running a prorest -vp against the backup file now to see if that brings anything back.

Do you happen to know about the -red command, i've found that its set at 0 by default and 1 would duplicat the backup block for block, are there others settings? TIA

 

[Cringer]

No idea about the -red command or any others. I've only been doing DBA stuff for a couple of years so the less known settings I do know about are the ones we make use of.

 

[BigSlick]

Ah no worries. I've just read a few documents and they've cleared it up slightly:

-red 5
Creates one error-correction block for every five blocks that are backed up.

 

[RealHeavyDude]

Exactly. -red 1 means every block is backed up twice.

Heavy Regards, RealHeavyDude.