dbunload问题的修复

　2006-04-01 23:08:37　来源：WEB开发网　　　

核心提示： One type of database corruption that is reported to Technical Support is typically associated with Assertion Error 50213, "Page number on page does not ma

One type of database corruption that is reported to Technical Support is typically associated with Assertion Error 50213, "Page number on page does not match page requested". When running on an ASA 6 or 7, the assertion will likely be 200601, "Page for requested record not a table page or record not present on page." Most frequently, however, said database was created on version 5.x and became corrupted before upgrading the software. Occasionally other assertions are reported, depending on the operation that first fails.

Our Product Quality department has stated that they would prefer to receive all databases in-house that become corrupted on version of the software that is currently being developed (as of this writing, SSA 5.5.05, ASA 6.0.4, ASA 7.0.1) in order to investigate the causes and frequency of database corruption. In some cases, however, the procedure described below can be more expedient. Furthermore, if the you are running on software that is no longer being updated (typically the maintenance level currently being sold plus one level earlier), the usefulness of such information is limited.

In all cases of database corruption, the preferred resolution is to find a valid backup, and apply all of the log files since the time of the backup.

This type of corruption is particularly bothersome, however, because it only manifests itself when a particular database page is accessed. If the data on that page is rarely used, the corruption may well exist on many or all of the backups the customer has on hand.

It may be possible to recover the database with the following procedure, although it is likely that some data will be lost. It is up to the customer to determine the validity and completeness of the data in the recovered database.

You will want to use the dbunload command; therefore it is prudent to note the following dbunload switches:

(at the command prompt type: dbunload /? )

Usage: dbunload [switches] <directory> [table-name-list]

Switches (use specified lower-case letter, as shown):

NOTE: <directory> must be specified as a path meaningful to
the engine (or server) unless an external unload is used.

Adaptive Server Anywhere 6 and 7 include additional switches, notably -an and -ac, which can be used to roll the entire recovery process into a single command line. However, when using these switches, if the reload fails, the whole recovery process needs to be started from scratch. For this reason, we will use a manual, three-step process that leaves data and command files even in the event of a partial failure.

Create a working directory (eg c:\working) and an unload directory (eg c:\unload). Placing these directories off the root will save wear and tear on the fingers. Copy the database and log files to the working directory. Open a command prompt in the working directory. Run the following command line. (In this example we are using the asademo.db which comes with ASA6)

dbunload -c "uid=dba;pwd=sql;dbf=c:\working\asademo.db" -u c:\unload

The output will resemble:

In a technical support case, we would see an assertion error message in the above example at this point. Assume table "customer" gave an Assertion Error.

Type the following:

dbunload -c "uid=dba;pwd=sql;dbf=c:\working\asademo.db" -u c:\unload -e dba.customer

The output will resemble:

This will either complete successfully or yield another corrupt table. Rerun the process with a comma-separated list of tables to exclude until the unload completes successfully.

We will now have a series of *.DAT files with the data we need, and a file called reload.sql with the schema for the database, except for the corrupt tables. We need a complete schema for the database. Type the following in order to create RELOAD1.SQL:

dbunload" -c "uid=dba;pwd=sql;dbf=c:\working\asademo.db" -n -r RELOAD1.SQL

With your favourite text editor (i.e. notepad) open RELOAD.SQL and RELOAD1.SQL and search for RELOAD DATA. Copy the entire contents of this section from reload.sql to the same section of RELOAD1.SQL.

This section will contain LOAD TABLE paragraphs. I.e:

The details will vary slightly depending on the version of the engine doing the unload. Duplicate one of these paragraphs, once for each table that has been corrupted. Replace the table name ("DBA"."CONTACT") with the name of the corrupted table ("DBA"."CUSTOMER"). Replace the DAT file with a unique filename in the same directory ('c:\\unload\\customer.dat')

Save the RELOAD1.SQL file.

We now need to salvage good data from the corrupted table. Start the database on a standalone engine and connect with Interactive SQL. Select and output data from the table with the following syntax:

SELECT * FROM customer ORDER BY cust_id ASC >># c:\unload\customer.dat

This will output as much data as possible from that table to customer.dat, until the engine asserts. for convenience, order by the Prima(最完善的虚拟主机管理系统)ry key.

Restart the engine, reconnect with Interactive SQL, and reverse the sort order:

SELECT * FROM customer ORDER BY cust_id DESC >># c:\unload\customer.dat

The doubled > signs will cause the new output to be concatenated to the first set. The engine will assert again. Try to verify how much data has been lost, by comparing the number of rows written to the number expected, or by opening customer.dat and comparing the Prima(最完善的虚拟主机管理系统)ry key value of the last row in the first pass, to the PK value in the last row of the second pass. Some data loss is inevitable, but if a significant number of rows are missing, you may need to continue the process with syntax like:

SELECT * FROM customer where cust_id between 1600 and 20000 ORDER BY cust_id ASC >># c:\unload\customer.dat

This can become tedious, if multiple rows are corrupted, and these are widely separated. Fortunately, these rows are frequently grouped together on the Prima(最完善的虚拟主机管理系统)ry key. If not, you might try sorting by a different column that has an index on it, or dropping all indexes on this table before trying to salvage the data.

When you have salvaged as much data as you can, you need to create a new database from Sybase Central or using the dbinit command. Be sure you match the collation sequence, blank padding setting, case sensitivity and page size of the original.

Start the new database on a standalone engine/personal server with lots of cache, and connect to the new database with Interactive SQL and type:

READ C:\WORKING\RELOAD1.SQL

This should read all of the schema and data you have been able to salvage from the original database. The only other problem you are likely to encounter is when foreign key relationships are applied. If child records exist where there is no parent, the foreign key relationships will not be established. You will need to either delete the child records or replace/dummy up the parent records before this will work.

If your new database was created with a name different from the original, rename the file with DOS/Explorer and run dblog to rename the log file:

DBLOG -t asademo.log asademo.db

It will be up to you the customer to verify that the data is complete and accurate.

It is strongly recommended that you upgrade your software to version 5.5.05 or later, as this type of corruption was much more common in earlier versions of the software.

1 2 下一页