Restore sql server database

I did one complete backup, and two transaction log backups.
The first of log backups is corrupt.
So I have to make a restore with the complete backup and only the
second log backup.
Is it possible?
Thanks.Hi,
if any of u r log backup is corrupt u cant restore subsequential log back
files.
Amol Lembhe
"giminera@.libero.it" wrote:
> I did one complete backup, and two transaction log backups.
> The first of log backups is corrupt.
> So I have to make a restore with the complete backup and only the
> second log backup.
> Is it possible?
> Thanks.
>

Restore sql server database

I did one complete backup, and two transaction log backups.
The first of log backups is corrupt.
So I have to make a restore with the complete backup and only the
second log backup.
Is it possible?
Thanks.Hi,
if any of u r log backup is corrupt u cant restore subsequential log back
files.
Amol Lembhe
"giminera@.libero.it" wrote:

> I did one complete backup, and two transaction log backups.
> The first of log backups is corrupt.
> So I have to make a restore with the complete backup and only the
> second log backup.
> Is it possible?
> Thanks.
>

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

Restore needs too much space

I'm trying to restore a database from a complete backup (70MB)
and on restore it says that the restore needs 713MB of free space to
continue
Why? and is there a way to get around this?
I assume the transaction log is the suspect...
The size of the backup file is usually unrelated to the actual size of the
files that make up the database. It is more aligned with the amount of data
in the files. You really don't have a choice but to find enough disk space
to restore the database to. You can use the
RESTORE HEADERONLY
RESTORE FILELISTONLY
commands to see what is on the backup device.
Andrew J. Kelly SQL MVP
"Ben" <test@.test.com> wrote in message
news:OzMXO6IZFHA.220@.TK2MSFTNGP10.phx.gbl...
> I'm trying to restore a database from a complete backup (70MB)
> and on restore it says that the restore needs 713MB of free space to
> continue
> Why? and is there a way to get around this?
> I assume the transaction log is the suspect...
>
|||When you restore a backup, the transaction log file is expanded to the
size it had when the backup was made, but it remains empty (the actual
log records are not stored in the backup, only the size of the
transaction log).
Razvan
|||And if the data file where, say, 2 GB, but only contained 1.5 GB of data,
you would still need the 2 GB in order for the store to create the original
2 GB data file and then restore the 1.5 GB into.
Sincerely,
Anthony Thomas

"Razvan Socol" <rsocol@.gmail.com> wrote in message
news:1117432747.852108.163660@.z14g2000cwz.googlegr oups.com...
When you restore a backup, the transaction log file is expanded to the
size it had when the backup was made, but it remains empty (the actual
log records are not stored in the backup, only the size of the
transaction log).
Razvan

Restore needs too much space

I'm trying to restore a database from a complete backup (70MB)
and on restore it says that the restore needs 713MB of free space to
continue
Why? and is there a way to get around this?
I assume the transaction log is the suspect...The size of the backup file is usually unrelated to the actual size of the
files that make up the database. It is more aligned with the amount of data
in the files. You really don't have a choice but to find enough disk space
to restore the database to. You can use the
RESTORE HEADERONLY
RESTORE FILELISTONLY
commands to see what is on the backup device.
--
Andrew J. Kelly SQL MVP
"Ben" <test@.test.com> wrote in message
news:OzMXO6IZFHA.220@.TK2MSFTNGP10.phx.gbl...
> I'm trying to restore a database from a complete backup (70MB)
> and on restore it says that the restore needs 713MB of free space to
> continue
> Why? and is there a way to get around this?
> I assume the transaction log is the suspect...
>|||When you restore a backup, the transaction log file is expanded to the
size it had when the backup was made, but it remains empty (the actual
log records are not stored in the backup, only the size of the
transaction log).
Razvan|||And if the data file where, say, 2 GB, but only contained 1.5 GB of data,
you would still need the 2 GB in order for the store to create the original
2 GB data file and then restore the 1.5 GB into.
Sincerely,
Anthony Thomas
"Razvan Socol" <rsocol@.gmail.com> wrote in message
news:1117432747.852108.163660@.z14g2000cwz.googlegroups.com...
When you restore a backup, the transaction log file is expanded to the
size it had when the backup was made, but it remains empty (the actual
log records are not stored in the backup, only the size of the
transaction log).
Razvan

Restore needs too much space

I'm trying to restore a database from a complete backup (70MB)
and on restore it says that the restore needs 713MB of free space to
continue
Why? and is there a way to get around this?
I assume the transaction log is the suspect...The size of the backup file is usually unrelated to the actual size of the
files that make up the database. It is more aligned with the amount of data
in the files. You really don't have a choice but to find enough disk space
to restore the database to. You can use the
RESTORE HEADERONLY
RESTORE FILELISTONLY
commands to see what is on the backup device.
--
Andrew J. Kelly SQL MVP
"Ben" <test@.test.com> wrote in message
news:OzMXO6IZFHA.220@.TK2MSFTNGP10.phx.gbl...
> I'm trying to restore a database from a complete backup (70MB)
> and on restore it says that the restore needs 713MB of free space to
> continue
> Why? and is there a way to get around this?
> I assume the transaction log is the suspect...
>|||When you restore a backup, the transaction log file is expanded to the
size it had when the backup was made, but it remains empty (the actual
log records are not stored in the backup, only the size of the
transaction log).
Razvan|||And if the data file where, say, 2 GB, but only contained 1.5 GB of data,
you would still need the 2 GB in order for the store to create the original
2 GB data file and then restore the 1.5 GB into.
Sincerely,
Anthony Thomas
"Razvan Socol" <rsocol@.gmail.com> wrote in message
news:1117432747.852108.163660@.z14g2000cwz.googlegroups.com...
When you restore a backup, the transaction log file is expanded to the
size it had when the backup was made, but it remains empty (the actual
log records are not stored in the backup, only the size of the
transaction log).
Razvan