ademo.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:
LOAD TABLE "DBA"."CONTACT" FROM 'c:\\unload\\430.dat' FORMAT 'ASCII' QUOTES ON ESCAPES ON STRIP OFF CHECK CONSTRAINTS OFF go
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')
LOAD TABLE "DBA"."CUSTOMER" FROM 'c:\\unload\\customer.dat' FORMAT 'ASCII' QUOTES ON ESCAPES ON STRIP OFF CHECK CONSTRAINTS OFF go
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 primary 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 primary 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 primary 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] 没有相关教程
|