Discussion:
Dump corrupts the DB
(too old to reply)
Joerg Gempe
2006-09-05 08:14:59 UTC
Permalink
Hi,

I've a strange problem where loading a dump corrupts my DB on:
Adaptive Server Enterprise/12.5.3/EBF 13339 ESD#7/P/x86_64/Enterprise
Linux/ase1253/1951/64-bit/OPT/Fri Mar 24 00:39:11 2006

I check the original DB storedb6 with dbcc checkstorage and no error is
reported.
Now I dumped the storedb6 (to a local disk) and load the dump into a
different DB (storedbold). And now the dbcc checkstorage(storedbold)
reports problems. Please see the attachment for more details.

The data devices are located on a NetApp filer (nfs) and the log devices
are located on a local raid.

Anyone ever seen this? And is there any chance to get a valid backup of
the database?

Any help is highly appreciated

Thx Joerg
Bret Halford
2006-09-05 15:19:26 UTC
Permalink
What fault conditions is checkstorage reporting?

-bret
Post by Joerg Gempe
Hi,
Adaptive Server Enterprise/12.5.3/EBF 13339 ESD#7/P/x86_64/Enterprise
Linux/ase1253/1951/64-bit/OPT/Fri Mar 24 00:39:11 2006
I check the original DB storedb6 with dbcc checkstorage and no error is
reported.
Now I dumped the storedb6 (to a local disk) and load the dump into a
different DB (storedbold). And now the dbcc checkstorage(storedbold)
reports problems. Please see the attachment for more details.
The data devices are located on a NetApp filer (nfs) and the log devices
are located on a local raid.
Anyone ever seen this? And is there any chance to get a valid backup of
the database?
Any help is highly appreciated
Thx Joerg
------------------------------------------------------------------------
1> dbcc traceon (3604)
2> .
DBCC execution completed. If DBCC printed error messages, contact a user with System Administrator (SA) role.
1> dbcc checkstorage(storedb6)
2> .
Checking storedb6: Logical pagesize is 4096 bytes
Storage checks for 'storedb6' are complete. DBCC is now recording the results in the dbccdb database.
DBCC CHECKSTORAGE for database 'storedb6' sequence 2 completed at Sep 4 2006 1:34PM. 0 faults and 0 suspect conditions were located. 0 checks were aborted. You should investigate the recorded faults, and plan a course of action that will correct them.
1> dump database storedb6 to "/opt/eproot/Shared/Patches/storedb6.dmp"
2> .
Backup Server session id is: 62. Use this value when executing the 'sp_volchanged' system stored procedure after fulfilling any volume change request from the Backup Server.
Backup Server: 4.41.1.1: Creating new disk file /opt/eproot/Shared/Patches/storedb6.dmp.
Backup Server: 6.28.1.1: Dumpfile name 'toredb6062470BEEF' section number 1 mounted on disk file '/opt/eproot/Shared/Patches/storedb6.dmp'
...
Backup Server: 4.58.1.1: Database storedb6: 814044 kilobytes DUMPed.
Backup Server: 3.43.1.1: Dump phase number 1 completed.
Backup Server: 3.43.1.1: Dump phase number 2 completed.
Backup Server: 3.43.1.1: Dump phase number 3 completed.
Backup Server: 4.58.1.1: Database storedb6: 814372 kilobytes DUMPed.
Backup Server: 3.42.1.1: DUMP is complete (database storedb6).
1> load database storedbold from "/opt/eproot/Shared/Patches/storedb6.dmp"
2> .
Backup Server session id is: 113. Use this value when executing the 'sp_volchanged' system stored procedure after fulfilling any volume change request from the Backup Server.
Backup Server: 6.28.1.1: Dumpfile name 'toredb6062470BEEF' section number 1 mounted on disk file '/opt/eproot/Shared/Patches/storedb6.dmp'
...
Backup Server: 4.58.1.1: Database storedbold: 4096168 kilobytes LOADed.
Backup Server: 3.42.1.1: LOAD is complete (database storedbold).
Started estimating recovery log boundaries for database 'storedbold'.
Database 'storedbold', checkpoint=(539113, 16), first=(539113, 16), last=(539114, 38).
Completed estimating recovery log boundaries for database 'storedbold'.
Started ANALYSIS pass for database 'storedbold'.
Completed ANALYSIS pass for database 'storedbold'.
Started REDO pass for database 'storedbold'. The total number of log records to process is 67.
Redo pass of recovery has processed 10 committed and 0 aborted transactions.
Completed REDO pass for database 'storedbold'.
Use the ONLINE DATABASE command to bring this database online; SQL Server will not bring it online automatically.
1> dbcc checkstorage(storedbold)
2> .
Checking storedbold: Logical pagesize is 4096 bytes
Too many errors have been detected on table 'localizedtextattribute' index 'tlocalizedtextattribute'. Checking for that object will be discontinued. (The CHECKSTORAGE operation stops when more than 25 % of the checks are abandoned.)
Too many errors have been detected on table 'ebayauction' index 'tebayauction'. Checking for that object will be discontinued. (The CHECKSTORAGE operation stops when more than 25 % of the checks are abandoned.)
Storage checks for 'storedbold' are complete. DBCC is now recording the results in the dbccdb database.
DBCC CHECKSTORAGE for database 'storedbold' sequence 5 completed at Sep 4 2006 1:46PM. 8 faults and 296 suspect conditions were located. 13 checks were aborted. You should investigate the recorded faults, and plan a course of action that will correct them.
Suspect conditions are to be treated as faults if the same suspect condition persists in subsequent CHECKSTORAGE operations, or if they are also detected by other DBCC functions.
1> online database storedbold
2> .
Started estimating recovery log boundaries for database 'storedbold'.
Database 'storedbold', checkpoint=(539113, 16), first=(244813674985, 16), last=(539114, 38).
Completed estimating recovery log boundaries for database 'storedbold'.
Started ANALYSIS pass for database 'storedbold'.
Completed ANALYSIS pass for database 'storedbold'.
Recovery of database 'storedbold' will undo incomplete nested top actions.
Database 'storedbold' is now online.
1> dbcc checkstorage(storedbold)
2> .
Checking storedbold: Logical pagesize is 4096 bytes
Too many errors have been detected on table 'localizedtextattribute' index 'tlocalizedtextattribute'. Checking for that object will be discontinued. (The CHECKSTORAGE operation stops when more than 25 % of the checks are abandoned.)
Too many errors have been detected on table 'localizedtextattribute' index 'tlocalizedtextattribute'. Checking for that object will be discontinued. (The CHECKSTORAGE operation stops when more than 25 % of the checks are abandoned.)
Too many errors have been detected on table 'ebayauction' index 'tebayauction'. Checking for that object will be discontinued. (The CHECKSTORAGE operation stops when more than 25 % of the checks are abandoned.)
Storage checks for 'storedbold' are complete. DBCC is now recording the results in the dbccdb database.
DBCC CHECKSTORAGE for database 'storedbold' sequence 6 completed at Sep 4 2006 1:48PM. 8 faults and 299 suspect conditions were located. 13 checks were aborted. You should investigate the recorded faults, and plan a course of action that will correct them.
Suspect conditions are to be treated as faults if the same suspect condition persists in subsequent CHECKSTORAGE operations, or if they are also detected by other DBCC functions.
1> dbcc checkverify(storedbold)
2> .
Verifying faults for 'storedbold'.
DBCC CHECKVERIFY for database 'storedbold' sequence 6 completed at Sep 4 2006 1:48PM. 281 suspect conditions considered, 234 identified as faults, 47 identified as harmless, and 0 could not be checked. 0 objects could not be checked.
1>
Joerg Gempe
2006-09-06 08:00:51 UTC
Permalink
Post by Bret Halford
What fault conditions is checkstorage reporting?
-bret
Hello,

We now figured out that it's not the dump which corrupts the DB but the
dbcc checkstorage didn't recognize the corruption of the original DB.
But unfortunately we already have the problem in the original DB which
report 605 and 692 errors.
Therefore we need to rescue the data from the corrupted table via BCP
and/or select into.
Is there any documentation how to rescue data from a corrupted table?
Can I somehow mark the affected page as "unused" or so?


NB: I will also open a new thread in ase.general group. Thx.

Joerg

Loading...