An internal consistency error occurred.
-
RESTORE DATABASE DoD FROM DISK='\\whse\Drive_I\MyTeam\BACKUP\DoD_1_of_5.BAK',
DISK='\\whse\Drive_I\MyTeam\BACKUP\DoD_2_of_5.BAK',
DISK='\\whse\Drive_I\MyTeam\BACKUP\DoD_3_of_5.BAK',
DISK='\\whse\Drive_I\MyTeam\BACKUP\DoD_4_of_5.BAK',
DISK='\\whse\Drive_I\MyTeamL\BACKUP\DoD_5_of_5.BAK'
WITH REPLACE
Results: Server: Msg 3270, Level 16, State 1, Line 1
An internal consistency error occurred. Contact Technical Support for assistance. Server: Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.
Any idea what might be wrong. I backed up from System1 and am trying to restore to System2 which was created from system1 (Detach, Copy, Attach)
-
Did you perform a RAID backup to multiple files?
If so, then you might need to call PSS.
-
The backup looked just like the restore but the other command. The drive I backed up to is a network drive shared by many machines. I'm backuping up on one machine and restoring to another with the same configuration. The only difference is the mappings (Drive letters are the same).
What is PSS
Thanks, DBA by Default
-
> What is PSS
Microsoft Product Support Services. See here for details.
SQL BAK Explorer - read SQL Server backup file details without SQL Server.
Supports backup files created with SQL Server 2005 up to SQL Server 2017. -
I'd do the backup and restore one more time before calling PSS. If it doesn't work:
1. Run a hardware diagnostic on your server.
2. Contact the hardware vendor.
Assuming your hardware is under warranty, they are the ones that need to be troubleshooting this, including getting the MS support engineers involved if need be.
Derrick Leggett
Mean Old DBA
When life gives you a lemon, fire the DBA. -
If the database is not in the same folder path on system2 or you have changed the name of the database (its logical name), you will need to use the MOVE option on the restore.
Regards
Peter
-
My hardware people are saying it is a SQLServer problem.
What hardware diagnostics might I be able to run?
-
Does the server you are restoring onto have access to the shared drive?
In Query Analyser run the following command:
exec master..xp_cmdshell 'dir "\\whse\Drive_I\MyTeam\BACKUP\*.*"'
Otherwise, check the SQL server log to see if there is a more informative message.
Also, when you did the backup did you make sure that the backup files didn't already exist. In which case it will have appended the new backup onto the old one, in each file.
Regards
Peter
-
Can I use *.BAk instead of *.* if other than backups are on the drive?
What does the command do?
There was no previous backup but is there a parameter I can put on the BACKUP command to overlay?
-
I ran with *.BAK and it worked fine. The output didn't tell me much though. Was I supposed to expect something significant?
Output: Volume, Serian Number, Directory, NULL, Files, Size Files, Size Dir, and NULL>
Will the Parameter INIT be OK for overlay so I don't get issues there?
Thanks!
-
All the command does is execute the DOS 'dir *.*' to list the files on the directory. If any files appear it means the account (windows userID) SQL server is running under has security access to view the directory on the share. It doesn't necessarily mean that it also has the right to read the contents of the files. If you want to check you can read the backup files replace the 'DOS dir \\.....\*.*' command with 'TYPE \\.....\filename.bak', where filename.bak is the file you want to view. Even though you may not understand the contents of the file when it it displayed, if the file is displayed then you don't have a security problem.
Yes you can put *.bak to just list the backup files.
You should be able to use BACKUP ... WITH INIT, SKIP (initialise file and skip any checks) to overwrite an existing bakup file. But I have never tested it.
Regards
Peter
-
I didn't see your last message before I posted my previous one. The dir command should have listed all your backup files. If it didn't you could just have a security access problem. You may need to get SQL server to startup using a domain account rather than the local system account. You can change the start up account in Enterprise Manager:
Right click on the server name, select properties and go to the security tab. Change the startup account and password and then stop/start SQL server.
Hope this helps
Peter
-
I can see everything ... no access issues. Just the original consistency issues.
Any idea what hardware diagnostic programs I can run on the Application or data servers/drives?
-
No idea about the hardware diagnostics to run. Speak to your server support guys. They have probably already checked the disk. To rule out hardware issues just backup to a different shared drive, if you have one. Or backup to a local disk, zip up the backups and copy them to the server2 local disk (may take some time) - this will rule out network issues, which could be because of lost packets if you are routing the traffic to the shared drive down a slow link.
Hopefully you haven't changed the database compatibility levels or recovery modes for the database after it was attached to server2, or this could cause your problems. Also, it would help if both servers are on the same version and service pack as the backup/restore functions could have changed.
-
I've already backup to a different shared drive. I can't zip it .. I would need to break it up into almost 100 disk files for it to be small enough to zip up (4 Gig Limit). All on the same version and service pack.
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply