Monday, March 12, 2012

Restore Problem

I need to copy a database FSPROD to FSSYS on a different SQL server. In
enterprise manager, I hightlighted the FSPROD and performed a complete
backup and named it FSPROD.bak. After the backup completed, I copied that
file to the server it needs to be restored on.
I didn't have a FSSYS database, but I thought SQL would do it on its own,
so when I did this:
RESTORE DATABASE FSSYS
FROM Disk='F:\FSPROD.bak'
WITH
MOVE 'TDSFSSYSdata' TO 'F:\Data\TDSFSSYS_data.mdf',
MOVE 'TDSFSSYSlog' TO 'F:\Logs\TDSFSSYS_log.ldf',
REPLACE
I got this message: Could not find database ID 65535. Database may not be
activated yet or may be in transition.
I then created a FSSYS database, and went to the Query Analyzer:
RESTORE DATABASE FSSYS
FROM Disk='F:\FSPROD.bak'
WITH
MOVE 'TDSFSSYSdata' TO 'F:\Data\TDSFSSYS_data.mdf',
MOVE 'TDSFSSYSlog' TO 'F:\Logs\TDSFSSYS_log.ldf',
REPLACE
I got this message: The backup set holds a backup of a database other than
the existing 'FSSYS' database.
I then tried created the FSPROD on the second server to use the same name,
as I figured I could ALTER the name later, but I still get: The backup set
holds a backup of a database other than the existing 'FSPROD' database.
If the DB name is the same, why isn't it letting me restore? Is it because
I used the wizard to perform the backup?
Thanks,
RockyWhat happens if you try it the first way (without the database existing)
without the REPLACE statement?
Christian Smith
"Rocky" <me@.me.co> wrote in message
news:Xns948B7C1D62EB3memeco@.207.46.248.16...
> I need to copy a database FSPROD to FSSYS on a different SQL server. In
> enterprise manager, I hightlighted the FSPROD and performed a complete
> backup and named it FSPROD.bak. After the backup completed, I copied that
> file to the server it needs to be restored on.
> I didn't have a FSSYS database, but I thought SQL would do it on its own,
> so when I did this:
> RESTORE DATABASE FSSYS
> FROM Disk='F:\FSPROD.bak'
> WITH
> MOVE 'TDSFSSYSdata' TO 'F:\Data\TDSFSSYS_data.mdf',
> MOVE 'TDSFSSYSlog' TO 'F:\Logs\TDSFSSYS_log.ldf',
> REPLACE
> I got this message: Could not find database ID 65535. Database may not be
> activated yet or may be in transition.
> I then created a FSSYS database, and went to the Query Analyzer:
> RESTORE DATABASE FSSYS
> FROM Disk='F:\FSPROD.bak'
> WITH
> MOVE 'TDSFSSYSdata' TO 'F:\Data\TDSFSSYS_data.mdf',
> MOVE 'TDSFSSYSlog' TO 'F:\Logs\TDSFSSYS_log.ldf',
> REPLACE
> I got this message: The backup set holds a backup of a database other than
> the existing 'FSSYS' database.
> I then tried created the FSPROD on the second server to use the same name,
> as I figured I could ALTER the name later, but I still get: The backup set
> holds a backup of a database other than the existing 'FSPROD' database.
> If the DB name is the same, why isn't it letting me restore? Is it
because
> I used the wizard to perform the backup?
> Thanks,
> Rocky|||I think you made it comnplicated. Let's say you already copied the backup
file to the root of drive F: on the new server. Frist you need to know the
logical file names of FSPROD.
RESTORE FILELISTONLY FROM DISK = 'F:\FSPROD.bak'
it returns logical files name of data file and log file of FSPROD. Use
them for restore command:
RESTORE DATABASE FSSYS FROM DISK = 'F:\FSPROD.bak'
WITH MOVE 'logical file name of data file of FSPROD' TO
'F:\Data\TDSFSSYS_data.mdf',
MOVE 'logical file name of log file of FSPROD' TO
'F:\Log\TDSFSSYS_log.ldf'
You don't need to create the DB first.
hth,
"Rocky" <me@.me.co> wrote in message
news:Xns948B7C1D62EB3memeco@.207.46.248.16...
> I need to copy a database FSPROD to FSSYS on a different SQL server. In
> enterprise manager, I hightlighted the FSPROD and performed a complete
> backup and named it FSPROD.bak. After the backup completed, I copied that
> file to the server it needs to be restored on.
> I didn't have a FSSYS database, but I thought SQL would do it on its own,
> so when I did this:
> RESTORE DATABASE FSSYS
> FROM Disk='F:\FSPROD.bak'
> WITH
> MOVE 'TDSFSSYSdata' TO 'F:\Data\TDSFSSYS_data.mdf',
> MOVE 'TDSFSSYSlog' TO 'F:\Logs\TDSFSSYS_log.ldf',
> REPLACE
> I got this message: Could not find database ID 65535. Database may not be
> activated yet or may be in transition.
> I then created a FSSYS database, and went to the Query Analyzer:
> RESTORE DATABASE FSSYS
> FROM Disk='F:\FSPROD.bak'
> WITH
> MOVE 'TDSFSSYSdata' TO 'F:\Data\TDSFSSYS_data.mdf',
> MOVE 'TDSFSSYSlog' TO 'F:\Logs\TDSFSSYS_log.ldf',
> REPLACE
> I got this message: The backup set holds a backup of a database other than
> the existing 'FSSYS' database.
> I then tried created the FSPROD on the second server to use the same name,
> as I figured I could ALTER the name later, but I still get: The backup set
> holds a backup of a database other than the existing 'FSPROD' database.
> If the DB name is the same, why isn't it letting me restore? Is it
because
> I used the wizard to perform the backup?
> Thanks,
> Rocky|||> What happens if you try it the first way (without the database
> existing) without the REPLACE statement?
Could not find database ID 65535. Database may not be activated yet or may
be in transition.
I'm re-building a backup from a Transact-SQL command, but it is about 50gb
so it will take awhile to copy to the other box. Hopefully it is just an
issue from the backup wizard-thing.
Later,
Rocky|||> I think you made it comnplicated. Let's say you already copied the
> backup file to the root of drive F: on the new server. Frist you need
> to know the logical file names of FSPROD.
> RESTORE FILELISTONLY FROM DISK = 'F:\FSPROD.bak'
> it returns logical files name of data file and log file of FSPROD.
> Use them for restore command:
RESTORE FILELISTONLY FROM DISK = 'F:\FSPROD.bak'
TDSFSSYSdata I:\Data\TDSFSSYS_data.mdf D
TDSFSSYSlog K:\Log\TDSFSSYS_log.ldf L
I was using those names in my move commands in the restore statement.
Later,
Rocky|||> I'm re-building a backup from a Transact-SQL command, but it is about
> 50gb so it will take awhile to copy to the other box. Hopefully it is
> just an issue from the backup wizard-thing.
Worked fine as usual from Query Analyzer.
Thanks for the help,
Rocky

No comments:

Post a Comment