Restore to different version of 2003 OS

Hello,
I have a client with a database and want to use a second server as warm spare.
Primary server is 2003 Std and the spare is 2003Ent.
I've heard that the OS must be the same to restore.
I can understand the SQL needs the same version 2000 and service pack level
on each server but what about the OS?
Thanks in advance
Kevin"Kevin1aB" <Kevin1aB@.discussions.microsoft.com> wrote in message
news:5B30FD35-4E84-474F-8240-E812C27E548A@.microsoft.com...
> Hello,
> I have a client with a database and want to use a second server as warm
> spare.
> Primary server is 2003 Std and the spare is 2003Ent.
> I've heard that the OS must be the same to restore.
> I can understand the SQL needs the same version 2000 and service pack
> level
> on each server but what about the OS?
>
The OS can be different.
David|||To restore a system database, the SQL build numbers must match exactly. To
restore a non-system database, the major levels must match (I.E 7.0, 8.0,
9.0 etc). The operating system does not matter as long as it is supported
for that release of SQL.
--
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Kevin1aB" <Kevin1aB@.discussions.microsoft.com> wrote in message
news:5B30FD35-4E84-474F-8240-E812C27E548A@.microsoft.com...
> Hello,
> I have a client with a database and want to use a second server as warm
> spare.
> Primary server is 2003 Std and the spare is 2003Ent.
> I've heard that the OS must be the same to restore.
> I can understand the SQL needs the same version 2000 and service pack
> level
> on each server but what about the OS?
> Thanks in advance
> Kevin|||While I agree with what the others have posted, you are going to test this
all first, right?
"Kevin1aB" wrote:
> Hello,
> I have a client with a database and want to use a second server as warm spare.
> Primary server is 2003 Std and the spare is 2003Ent.
> I've heard that the OS must be the same to restore.
> I can understand the SQL needs the same version 2000 and service pack level
> on each server but what about the OS?
> Thanks in advance
> Kevin|||Thanks to all who posted. I will test it in the next week or so.
Regards,
Kevin B
"ChrisR" wrote:
> While I agree with what the others have posted, you are going to test this
> all first, right?
> "Kevin1aB" wrote:
> > Hello,
> > I have a client with a database and want to use a second server as warm spare.
> > Primary server is 2003 Std and the spare is 2003Ent.
> > I've heard that the OS must be the same to restore.
> > I can understand the SQL needs the same version 2000 and service pack level
> > on each server but what about the OS?
> >
> > Thanks in advance
> >
> > Kevin

Restore to different version of 2003 OS

Hello,
I have a client with a database and want to use a second server as warm spare.
Primary server is 2003 Std and the spare is 2003Ent.
I've heard that the OS must be the same to restore.
I can understand the SQL needs the same version 2000 and service pack level
on each server but what about the OS?
Thanks in advance
Kevin
"Kevin1aB" <Kevin1aB@.discussions.microsoft.com> wrote in message
news:5B30FD35-4E84-474F-8240-E812C27E548A@.microsoft.com...
> Hello,
> I have a client with a database and want to use a second server as warm
> spare.
> Primary server is 2003 Std and the spare is 2003Ent.
> I've heard that the OS must be the same to restore.
> I can understand the SQL needs the same version 2000 and service pack
> level
> on each server but what about the OS?
>
The OS can be different.
David
|||To restore a system database, the SQL build numbers must match exactly. To
restore a non-system database, the major levels must match (I.E 7.0, 8.0,
9.0 etc). The operating system does not matter as long as it is supported
for that release of SQL.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Kevin1aB" <Kevin1aB@.discussions.microsoft.com> wrote in message
news:5B30FD35-4E84-474F-8240-E812C27E548A@.microsoft.com...
> Hello,
> I have a client with a database and want to use a second server as warm
> spare.
> Primary server is 2003 Std and the spare is 2003Ent.
> I've heard that the OS must be the same to restore.
> I can understand the SQL needs the same version 2000 and service pack
> level
> on each server but what about the OS?
> Thanks in advance
> Kevin
|||While I agree with what the others have posted, you are going to test this
all first, right?
"Kevin1aB" wrote:

> Hello,
> I have a client with a database and want to use a second server as warm spare.
> Primary server is 2003 Std and the spare is 2003Ent.
> I've heard that the OS must be the same to restore.
> I can understand the SQL needs the same version 2000 and service pack level
> on each server but what about the OS?
> Thanks in advance
> Kevin
|||Thanks to all who posted. I will test it in the next week or so.
Regards,
Kevin B
"ChrisR" wrote:
[vbcol=seagreen]
> While I agree with what the others have posted, you are going to test this
> all first, right?
> "Kevin1aB" wrote:

Restore to different version of 2003 OS

Hello,
I have a client with a database and want to use a second server as warm spar
e.
Primary server is 2003 Std and the spare is 2003Ent.
I've heard that the OS must be the same to restore.
I can understand the SQL needs the same version 2000 and service pack level
on each server but what about the OS?
Thanks in advance
Kevin"Kevin1aB" <Kevin1aB@.discussions.microsoft.com> wrote in message
news:5B30FD35-4E84-474F-8240-E812C27E548A@.microsoft.com...
> Hello,
> I have a client with a database and want to use a second server as warm
> spare.
> Primary server is 2003 Std and the spare is 2003Ent.
> I've heard that the OS must be the same to restore.
> I can understand the SQL needs the same version 2000 and service pack
> level
> on each server but what about the OS?
>
The OS can be different.
David|||To restore a system database, the SQL build numbers must match exactly. To
restore a non-system database, the major levels must match (I.E 7.0, 8.0,
9.0 etc). The operating system does not matter as long as it is supported
for that release of SQL.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Kevin1aB" <Kevin1aB@.discussions.microsoft.com> wrote in message
news:5B30FD35-4E84-474F-8240-E812C27E548A@.microsoft.com...
> Hello,
> I have a client with a database and want to use a second server as warm
> spare.
> Primary server is 2003 Std and the spare is 2003Ent.
> I've heard that the OS must be the same to restore.
> I can understand the SQL needs the same version 2000 and service pack
> level
> on each server but what about the OS?
> Thanks in advance
> Kevin|||While I agree with what the others have posted, you are going to test this
all first, right?
"Kevin1aB" wrote:

> Hello,
> I have a client with a database and want to use a second server as warm sp
are.
> Primary server is 2003 Std and the spare is 2003Ent.
> I've heard that the OS must be the same to restore.
> I can understand the SQL needs the same version 2000 and service pack leve
l
> on each server but what about the OS?
> Thanks in advance
> Kevin|||Thanks to all who posted. I will test it in the next week or so.
Regards,
Kevin B
"ChrisR" wrote:
[vbcol=seagreen]
> While I agree with what the others have posted, you are going to test this
> all first, right?
> "Kevin1aB" wrote:
>

Restore readonly filegroup sqlserver 2000

Hi,

I have a database running on sqlserver 2000. This database (let's call it TestDatabase) has 2 filegroups called 'PRIMARY' and 'SECONDARY', and is bulk-logged. The 'SECONDARY' filegroup is set to readonly since no data gets changed there by the applications, it is read-only data. Sometimes this read-only data needs an update, so I need to update the data in the 'SECONDARY' filegroup by running some long data-operations. These data-operations are executed and checked on a another database (which is a backup of TestDatabase) called TestDatabaseDemo. When everything is correct in TestDatabaseDemo we can copy all objects from the 'SECONDARY'-filegroup of TestDatabaseDemo to the 'SECONDARY'-filegroup of TestDatabase using DTS. This takes a long time and I want to try if I could speed up things by using the following strategy:

Take a full backup of TestDatabase

Restore full backup as TestDatabaseDemo

Run long-running data-operations on TestDatabaseDemo

Take a backup of TestDatabaseDemo

Restore only the 'SECONDARY'-filegroup from TestDatabaseDemo to TestDatabase, and keeping the 'PRIMARY' filegroup from TestDatabase as it was at that moment.

Suppose we arrived at step 5, I am executing the following commands:

Code Snippet

--make full backup of TestDatabase
backup database TestDatabase to DISK='G:\temp\testdatabase.bak' with init
--make full backup of TestDatabaseDemo
backup database TestDatabaseDemo to DISK='G:\temp\testdatabasedemo.bak' with init

backup log TestDatabase to DISK='g:\temp\testdatabase.log'

--restore secondary filegroup from TestDatabasedemo-backup

restore database TestDatabase FILEGROUP='SECONDARY' FROM DISK='G:\temp\testdatabasedemo.bak'
with move 'TestDatabase_Data_Secondary' to 'G:\temp\TestDatabase_Data_secondary.ndf', NORECOVERY

--restore primary filegroup from Testdatabase-backup
restore database TestDatabase FILEGROUP='PRIMARY' FROM DISK='G:\temp\testdatabase.bak'
with move 'TestDatabase_Data' to 'G:\temp\TestDatabase_Data.mdf', NORECOVERY
--restore log and try to get db onlin

restore log TestDatabase FROM DISK='g:\temp\testdatabase.log' with recovery

I get the following error:

The log in this backup set terminates at LSN 6000000021500001, which is too early to apply to the database. A more recent log backup that includes LSN 6000000022400003 can be restored.

When trying to execute "RESTORE DATABASE TestDatabase WITH RECOVERY; " as last statement

I get error:

The database cannot be recovered because the files have been restored to inconsistent points in time.

How i can restore the read-only filegroup correctly?

Hi Stijn,

Simple answer is that you can't do that. The SECONDARY filegroup is now at a different (more recent) point in time than the rest of the TestDatabase - exactly like the final error message says. What you're essentially trying to do is mix-n-match filegroups from different databases.

Thanks

|||

Hi Paul,

Thanks for the answer! I was thinking the mix-n-match would work, because that filegroup is readonly for the database, so applying the transaction log would be good enough for the other (read-write) filegroup, since there couldn't be any inserts/updates/deletes on the secondary filegroup. Which technique is used on very large databases to update a read-only filegroup? Using dts to copy objects from a test-database to the production database? Or is there a more efficient way?

Restore readonly filegroup sqlserver 2000

Hi,

I have a database running on sqlserver 2000. This database (let's call it TestDatabase) has 2 filegroups called 'PRIMARY' and 'SECONDARY', and is bulk-logged. The 'SECONDARY' filegroup is set to readonly since no data gets changed there by the applications, it is read-only data. Sometimes this read-only data needs an update, so I need to update the data in the 'SECONDARY' filegroup by running some long data-operations. These data-operations are executed and checked on a another database (which is a backup of TestDatabase) called TestDatabaseDemo. When everything is correct in TestDatabaseDemo we can copy all objects from the 'SECONDARY'-filegroup of TestDatabaseDemo to the 'SECONDARY'-filegroup of TestDatabase using DTS. This takes a long time and I want to try if I could speed up things by using the following strategy:

Take a full backup of TestDatabase

Restore full backup as TestDatabaseDemo

Run long-running data-operations on TestDatabaseDemo

Take a backup of TestDatabaseDemo

Restore only the 'SECONDARY'-filegroup from TestDatabaseDemo to TestDatabase, and keeping the 'PRIMARY' filegroup from TestDatabase as it was at that moment.

Suppose we arrived at step 5, I am executing the following commands:

Code Snippet

--make full backup of TestDatabase
backup database TestDatabase to DISK='G:\temp\testdatabase.bak' with init
--make full backup of TestDatabaseDemo
backup database TestDatabaseDemo to DISK='G:\temp\testdatabasedemo.bak' with init

backup log TestDatabase to DISK='g:\temp\testdatabase.log'

--restore secondary filegroup from TestDatabasedemo-backup

restore database TestDatabase FILEGROUP='SECONDARY' FROM DISK='G:\temp\testdatabasedemo.bak'
with move 'TestDatabase_Data_Secondary' to 'G:\temp\TestDatabase_Data_secondary.ndf', NORECOVERY

--restore primary filegroup from Testdatabase-backup
restore database TestDatabase FILEGROUP='PRIMARY' FROM DISK='G:\temp\testdatabase.bak'
with move 'TestDatabase_Data' to 'G:\temp\TestDatabase_Data.mdf', NORECOVERY
--restore log and try to get db onlin

restore log TestDatabase FROM DISK='g:\temp\testdatabase.log' with recovery

I get the following error:

The log in this backup set terminates at LSN 6000000021500001, which is too early to apply to the database. A more recent log backup that includes LSN 6000000022400003 can be restored.

When trying to execute "RESTORE DATABASE TestDatabase WITH RECOVERY; " as last statement

I get error:

The database cannot be recovered because the files have been restored to inconsistent points in time.

How i can restore the read-only filegroup correctly?

Hi Stijn,

Simple answer is that you can't do that. The SECONDARY filegroup is now at a different (more recent) point in time than the rest of the TestDatabase - exactly like the final error message says. What you're essentially trying to do is mix-n-match filegroups from different databases.

Thanks

|||

Hi Paul,

Thanks for the answer! I was thinking the mix-n-match would work, because that filegroup is readonly for the database, so applying the transaction log would be good enough for the other (read-write) filegroup, since there couldn't be any inserts/updates/deletes on the secondary filegroup. Which technique is used on very large databases to update a read-only filegroup? Using dts to copy objects from a test-database to the production database? Or is there a more efficient way?

Restore Previous Backup on Logshipping Primary

Quick Question: If I want to restore an earlier database backup (rollback)
my log shipping primary - how do I ensure that I get my secondaries in sync?
Just re-create the maintenance plan? The database in question is very large,
and I'd like to be able to just do a point-in-time restore on the primary,
etc, without messing up my transaction log lineage.
Does anyone have any scripts handy?
TIA
J Roberts
Norfolk ITJohn
Backup Log file before restore full database
Disable Log Shipping
Restore the database and apply all log file/s with option at point of
time. Then enable Log Shipping and restore full and then log file backpus on
the secondary server
Actually I have not used maintenance paln fo doing Log Shipping , as I
always create scripts (stored proceduers etc..)
"John Roberts" <JohnRoberts@.discussions.microsoft.com> wrote in message
news:094ACA2D-1C92-47DE-B63C-7E7A4087FE7B@.microsoft.com...
> Quick Question: If I want to restore an earlier database backup
> (rollback)
> my log shipping primary - how do I ensure that I get my secondaries in
> sync?
> Just re-create the maintenance plan? The database in question is very
> large,
> and I'd like to be able to just do a point-in-time restore on the primary,
> etc, without messing up my transaction log lineage.
> Does anyone have any scripts handy?
> TIA
> J Roberts
> Norfolk IT|||That's what I thought. You'd think that MS would have considered rollbacks
in their implementation... Oh well. T-SQL it is. I think I'm going to use
SQL-DMO (vb.net) for this...
Thanks for your reply.
John
"Uri Dimant" wrote:
> John
> Backup Log file before restore full database
> Disable Log Shipping
> Restore the database and apply all log file/s with option at point of
> time. Then enable Log Shipping and restore full and then log file backpus on
> the secondary server
> Actually I have not used maintenance paln fo doing Log Shipping , as I
> always create scripts (stored proceduers etc..)
>
>
> "John Roberts" <JohnRoberts@.discussions.microsoft.com> wrote in message
> news:094ACA2D-1C92-47DE-B63C-7E7A4087FE7B@.microsoft.com...
> > Quick Question: If I want to restore an earlier database backup
> > (rollback)
> > my log shipping primary - how do I ensure that I get my secondaries in
> > sync?
> > Just re-create the maintenance plan? The database in question is very
> > large,
> > and I'd like to be able to just do a point-in-time restore on the primary,
> > etc, without messing up my transaction log lineage.
> >
> > Does anyone have any scripts handy?
> >
> > TIA
> >
> > J Roberts
> > Norfolk IT
>
>