Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2000 Forums
 SQL Server Administration (2000)
 database restore

Author  Topic 

AskSQLTeam
Ask SQLTeam Question

0 Posts

Posted - 2005-09-21 : 22:44:14
Sam writes "I'm trying to restore a database on a test system from a backup made on a production system. I'm using the restore feature in Enterprise Manager, but have also tried using Query Analyzer - same results.
At the end of the restore I get the following message:
"The media family on device __ is incorrectly formed. SQL cannot process this media family. Verify database is terminating abnormally."
It appears the Data & Log files have been built.
The database is unusable because it shows that it is still loading. I deleted the it & tried attaching it but that didn't work either.
I first suspected the data got corrupted when I zipped it before ftping it to the test system, so I ftped the backup without zipping it - same results.
I also suspected the systems could have different versions of SQL, but both are version 8.00.2039.
The backup job does verify the backup, so the data should be good, unless there is possibly a hard disk problem?
I'm lost & don't know where to turn. Any assistance will be appreciated."

derrickleggett
Pointy Haired Yak DBA

4184 Posts

Posted - 2005-09-21 : 22:55:46
Read this article from Books Online:

quote:

How to set up, maintain, and bring online a standby server (Transact-SQL)
Setting up a standby server generally involves creating a database backup and periodic transaction log backups at the primary server, and then applying those backups, in sequence, to the standby server. The standby server is left in a read-only state between restores. When the standby server needs to be made available for use, any outstanding transaction log backups, including the backup of the active transaction log, from the primary server, are applied to the standby server and the database is recovered.

To create backups on the primary server

Execute the BACKUP DATABASE statement to create the database backup.


Execute the BACKUP LOG statement to create a transaction log backup.


Repeat Step 2 for each transaction log you want to create over time.
To set up and maintain the standby server

Execute the RESTORE DATABASE statement using the STANDBY clause to restore the database backup created in Step 1 on the primary server. Specify the name of the undo file that contains the contents of data pages before uncommitted transactions affecting those pages were rolled back.


Execute the RESTORE LOG statement using the STANDBY clause to apply each transaction log created in Step 2 on the primary server.


Repeat Step 2 for each transaction log created on the primary server.
To bring the standby server online (primary server failed)

Execute the BACKUP LOG statement using the NO_TRUNCATE clause to back up the currently active transaction log. This is the last transaction log backup that will be applied to the standby server when the standby server is brought online. For more information, see How to create a backup of the currently active transaction log.


Execute the RESTORE LOG statement using the STANDBY clause to apply all transaction log backups, including the active transaction log backup created in Step 1, that have not yet been applied to the standby server.


Execute the RESTORE DATABASE WITH RECOVERY statement to recover the database and bring up the standby server.
Examples
This example sets up the MyNwind database on a standby server. The database can be used in read-only mode between restore operations.

-- Restore the initial database backup on the standby server.
USE master
GO
RESTORE DATABASE MyNwind
FROM MyNwind_1
WITH STANDBY = 'c:\undo.ldf'
GO
-- Apply the first transaction log backup.
RESTORE LOG MyNwind
FROM MyNwind_log1
WITH STANDBY = 'c:\undo.ldf'
GO
-- Apply the next transaction log backup.
RESTORE LOG MyNwind
FROM MyNwind_log2
WITH STANDBY = 'c:\undo.ldf'
GO
-- Repeat for each transaction log backup created on the
-- primary server.
--
-- Time elapses.. .. ..
--
-- The primary server has failed. Back up the
-- active transaction log on the primary server.
BACKUP LOG MyNwind
TO MyNwind_log3
WITH NO_TRUNCATE
GO
-- Apply the final (active) transaction log backup
-- to the standby server. All preceding transaction
-- log backups must have been already applied.
RESTORE LOG MyNwind
FROM MyNwind_log3
WITH STANDBY = 'c:\undo.ldf'
GO
-- Recover the database on the standby server,
-- making it available for normal operations.
RESTORE DATABASE MyNwind
WITH RECOVERY




Pay attention to the last part.

MeanOldDBA
derrickleggett@hotmail.com

When life gives you a lemon, fire the DBA.
Go to Top of Page

Kristen
Test

22859 Posts

Posted - 2005-09-22 : 01:37:03
Hi Sam, Welcome to SQL Team!

Your FTP isn't using 7-bit mode is it? If so it will have mucked up the files that you uploaded.

Kristen
Go to Top of Page

BigSam
Starting Member

30 Posts

Posted - 2005-09-22 : 08:24:34
No I'm not using 7-bit mode.
I'll try the recommendations listed in the article, but they look very similar to the steps I tried in Query Analyzer.
Last night I got to thinking the problem may be in the verify process. I'm going to research tuning off the verify for the restore & run a checkdb afterwards. If anyone has experience with turning off/on the database verify I'd appreciate that, too.

Sam
Go to Top of Page

Kristen
Test

22859 Posts

Posted - 2005-09-22 : 08:44:51
Try verifying on both the original and target machines - to prove not "damaged in transit"

RESTORE VERIFYONLY FROM DISK = 'X:\mssql\backup\MyBackupDevice.bak'

I would expect something like 'The backup is valid'

Also might be worth checking that the backup doesn't contain multiple appended backups by using RESTORE HEADERONLY

Kristen
Go to Top of Page

BigSam
Starting Member

30 Posts

Posted - 2005-09-22 : 10:08:35
The backup file was not correctly formed. I ran another backup (same job) & the file it created is correctly formed.

I checked the maintenance plan & verify is turned-on.

I looked at the history of the backup job & noticed that it did not have any history of the job running on 9/18, yet there is a backup file for that date. Strange - something else to investigate.

Thanks for your assistance.

Sam
Go to Top of Page

Kristen
Test

22859 Posts

Posted - 2005-09-22 : 10:29:11
It probably aborted before completion, and thus didn't add a row to the history table.

Anything [worrying!] in SQL Log or Event Log for that time?

Kristen
Go to Top of Page

BigSam
Starting Member

30 Posts

Posted - 2005-09-22 : 12:03:54
I haven't seen anything in SQL Log, but I'm trying to reconcile Event log problems with SQL. I'm using Lumiget to narrow down the SQL logging.
Go to Top of Page

BigSam
Starting Member

30 Posts

Posted - 2005-09-22 : 14:03:28
The SQL errors began when the full backup crashed. Some records in the database were corrupted - fortunately I was able to repair the database & import replacement records. LUCKY.
I suspect the real issue is related to a faulty RAID installation/repair. A week before the backup failure a RAID controller was replace. The person replacing the card did not check the status of the mirrored drives, which appear to need resyncronizing. Onward we go.
Go to Top of Page
   

- Advertisement -