Backup 67242 of 67238 - File is shorter than expected

[RADical_Systems]

I am hoping for some pearls of wisdom here. First of all this is V10, (10.0.1.3831), of SQL Anywhere and we may try updating to V16 but in the first instance we have an oddity which is causing a little concern.

A customer is backup up their db and using dbvalid to validate it. As of 4 days ago they started to receive errors "Assertion failed: 2011" File is shorter than expected. The database runs fine overall and we have done a full unload and reload as well as full validation within Sybase Central, (makes us a little less concerned).

dbbackup in the batch file is indicating is backs up more pages than it believes are in the db, (67242 of 67238), and when the validation occurs we get the assertion:

Clearly something not right somewhere but as it allowed a full unload and reload we feel much more confident in the actual database.

Any advice on what might be wrong and/or whether we have a misplaced trust in the fact we were able to fully rebuild the db with our unload/reload?

[Breck_Carter]

Here's a WAG...

Check for bad RAM... since every single computer operation depends on the reliability of RAM storage, a bit of bad RAM can mimic any failure, any symptom.

In your case, if the first failure (assertion 201129) was really caused by bad file data, you would expect to see another failure (rebuild error) caused by the same bad file data... but you are not, which may be evidence that the underlying cause is bad RAM.

The danger is extreme... good file data that is passed through bad RAM can BECOME bad file data. In other words, bad RAM can permanently corrupt file data... so immediately stop using that computer until the RAM is checked.

[RADical_Systems]

Thanks Breck. Will test it on another machine and see what we get. Hopefully that will help to identify this as an issue.

[johnsmirnios]

I think the apparent backing up of more pages than are in the database is possibly an indication that the database grew during the backup (ie 67238 was the number of pages when backup started).

Certainly, the assertion failure shouldn't be happening: it likely actually means the backup didn't copy enough pages. Without the commandline, it's hard to tell what kind of backup is being done (see the '-k' switch here: http://dcx.sap.com/index.html#sqla170/en/html/813ad3a96ce21014a0e0b9eab1406546.html*loio813ad3a96ce2... Even with the commandline, it's possible that the backup type may not be discernible (ie. -k auto). It's possible that by choosing a different backup method such as '-k nocopy', you could work around the issue but that method is definitely slower than the other methods. Try -k recover too...

Version 17 can read version 10 files directly. Given that version 10 is ancient (even version 16 is now out of support), you could try downloading a trial/development copy of version 17 and see if the bug has been fixed.

[Breck_Carter]

> version 10 is ancient

[RADical_Systems]

Thank you John. Will test with the -k switch and see what we get. We'll also try a newer version of SQL Anywhere.

If no luck with these, (or Breck's thoughts), I will post the command line we have - I would do it now but it is a colleague and I just don't have it to hand.