The forum will experience an outage sometime between February 10 at 7:00pm EST and February 12 at 11:59 EST for installation of security updates. The actual time and duration of the outage are unknown but attempts will be made to minimize the downtime. We apologize for any inconvenience.

A customer received an assertion error 200505 checksum failure on page xxx on a server version 12.0.1.3152.

The database is an approximately 300 GB remote database using SQL Remote replication, there was no full database backup.

I successfully unloaded the database using dbunload without ordering the data and therefore can recover the database using the unload, reload and reset of the offsets as explained in the documentation. However the unload and reload will take approximately 48 hours and I don't want to be down for that long.

My idea was to do the unload, reload, and offset thing and then apply the transaction logs from the online version of the corrupt database however SQL Anywhere is smarter than I and wouldn't apply the files saying they belong to a different database. By the way it would be nice if you had an option that would allow this.

I believe I can translate and apply the log files on a daily basis and then reset the offset to the ending offset of the last translated log file, (please verify). However I would rather fix the problem associated with the bad checksum since I assume the successful unload indicates the error is in an index page.

I determined which table is associated with the page with the bad checksum. Is my best approach to reorganize this table or drop the primary and foreign kay as well as any other indexes and rebuild them.

Thanks in advance

Jim Diaz

asked 22 Jun '15, 16:07

J%20Diaz's gravatar image

J Diaz
830243044
accept rate: 14%

Is it possible to test whether a newer v12.0.1 engine will also assert in that situation?

I'm suggesting this as there are some fixes for assertions, cf. that one:

    ================(Build #4247  - Engineering Case #781332)================

    In very rare cases, the server would have crashed with assertion 200509, 
    indicating that a checksum failure of critical sectors of page 0 had failed. 
    This was specific to page 0 of the transaction log, and has now been fixed.

Note: I do not claim at all that this is anyhow related to the problem you are facing!

(23 Jun '15, 07:39) Volker Barth

Unfortunately we are stuck with 3152 at this facility since upgrading requires a good deal of time and paperwork.

(24 Jun '15, 12:52) J Diaz

I reorganized the table, but still receive and error when I perform a "VALIDATE CHECKSUM" the weird thing is the validation completes past the failed checksum page through to 100% then an ISQL Error dialog pops up saying

"Could not execute statement. Run time SQL error -- Checksum validation failed for database file "xyz" SQLCODE=-300, ODBC 3 State="HY000" Line 1, column 1"

Why wouldn't the Validate Checksum report an error as it was validating each page? I'm starting to think there is nothing wrong with this database.

OK Next I will try a validation of each table to see if the error is discovered.

(24 Jun '15, 13:00) J Diaz
Be the first one to answer this question!
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×31
×6

question asked: 22 Jun '15, 16:07

question was seen: 1,043 times

last updated: 24 Jun '15, 13:00