May 30, 2011 at 5:52 am
We are planning a move, our productiondb on server A is SQL2005 and our new server B has SQL2008 R2.
We are thinking and testing setting up logshipping from server A (SQL 2005) to server B (SQl 2008).
And in standby mode, because all applications need to read data already (= read only).
But we're getting problems with the restore standby:
*** Error: This backup cannot be restored using WITH STANDBY because a database upgrade is needed. Reissue the RESTORE without WITH STANDBY.
Are there workarounds for this problem?
Replication was no option (already tested).
Hope to get some help, thanks...
May 30, 2011 at 6:04 am
Nope. Standby is only an option if both servers are the same version. For logshipping up-version (which is not a supported scenario) only NORECOVERY can be used.
Why is replication not an option?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 30, 2011 at 6:08 am
Because with the initialising of the replication, we are getting database errors, bad coded procedures etc...
We've tried to setup the replication on different ways, but we are still holded by the same errors 🙁
So as I checked, there's only the option to take the production database offline... 🙁
May 30, 2011 at 6:41 am
Oddly written procedures shouldn't cause any problems with replication.... What are the errors?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 30, 2011 at 6:44 am
just out of interest how large is the database you are moving?
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
May 30, 2011 at 10:39 pm
Same version will be work for the logshipping and what are errors in replication
Why do you not come to the new version with these steps,if you want to come on SQL Server 2008
1-Full Backup and then restore on the SQL Server 2008 with norecovery
2-Down the application services(downtime start here)
3-Take Differential backup and then restore on the SQL Server 2008 with recovery option
In these steps your downtime is less, how much transaction/ minute and how much size of the database
Regards,
Syed Jahanzaib Bin Hassan
BSCS | MCTS | MCITP | OCA | OCP | OCE | SCJP | IBMCDBA
My Blog
www.aureus-salah.com
June 6, 2011 at 6:44 am
GilaMonster (5/30/2011)
Oddly written procedures shouldn't cause any problems with replication.... What are the errors?
There were missing parameter errors in the develloped sp...
Also some problems with 2 different sp (with spelling errors in the name)...
And this wasn't easy to ignore...
June 6, 2011 at 6:45 am
Perry Whittle (5/30/2011)
just out of interest how large is the database you are moving?
It's 50Gb and no downtime allowed (if possible)
June 6, 2011 at 7:00 am
Syed Jahanzaib Bin hassan (5/30/2011)
Same version will be work for the logshipping and what are errors in replicationWhy do you not come to the new version with these steps,if you want to come on SQL Server 2008
1-Full Backup and then restore on the SQL Server 2008 with norecovery
2-Down the application services(downtime start here)
3-Take Differential backup and then restore on the SQL Server 2008 with recovery option
In these steps your downtime is less, how much transaction/ minute and how much size of the database
Because the actual production database server is not ours (and SQL2008 isn't installed on that server)... 🙁
We are migrating the database to our servers (working on SQL2008)
June 6, 2011 at 7:01 am
Is it possible to get an 'updated' database next to the restoring one (same instance)?
Make snapshot of the restoring db?
June 6, 2011 at 7:08 am
An simple way to do this is to do a restore with norecovery. Even if that takes 1 day to do the move and restore it doesn't matter. The next step (optional) is to then do a diff backup and also restore that with no recovery. Then you take the tail log and the do the move.
It's going to require a few minutes downtime, but not hours or days.
June 6, 2011 at 7:13 am
Ninja's_RGR'us (6/6/2011)
An simple way to do this is to do a restore with norecovery. Even if that takes 1 day to do the move and restore it doesn't matter. The next step (optional) is to then do a diff backup and also restore that with no recovery. Then you take the tail log and the do the move.It's going to require a few minutes downtime, but not hours or days.
That's indeed the reason to start using LogShipping now.
But we want to test some applications on an 'updated' (15min difference is no problem) database on the new server.
That's why I need a 'standby' database... i've already restored the last full backup of the db to our new server (so 1 readable db and 1 rstoring log shipped db is on our server right now), but if we need to do LogShipping for 2 weeks, we cann't keep this restored db (without new updates) (if you understand what I'm trying to say 🙂
and we are searching a workaround...
June 6, 2011 at 8:06 am
It's not possible to restore the restoring db as a copy, so the actual restoring db keeps available for log shipping?
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply