Hi,
Log shipping from sql 2k to sql2005. How do I do it?
I have sql2005 reporting server need to be synched with sql2000 prod db for
reporting.
How do I make the dbs synched?
Thanks,
You cannot use built-in log shipping across SQL 2000 and SQL 2005 (both EM
and SSMS should error out). You should get a message stating the restore
failing abruptly and suggesting you to upgrade.
However, you can write your own scripts to backup, copy and restore across
different versions. Then you'll have to create your own tables to track the
files that are copied and use the entries in those tables to keep the
process in sync. Search google for sample scripts on custom log shipping--
you should be able to come up with your own wih minor changes.
Anith
|||Thanks for the reply, I did use my own log shipping. I still get the error;
Msg 3180, Level 16, State 1, Line 1
This backup cannot be restored using WITH STANDBY because a database upgrade
is needed. Reissue the RESTORE without WITH STANDBY.
Msg 3013, Level 16, State 1, Line 1
RESTORE LOG is terminating abnormally.
"Anith Sen" <anith@.bizdatasolutions.com> wrote in message
news:udOam56fIHA.2268@.TK2MSFTNGP02.phx.gbl...
> You cannot use built-in log shipping across SQL 2000 and SQL 2005 (both EM
> and SSMS should error out). You should get a message stating the restore
> failing abruptly and suggesting you to upgrade.
> However, you can write your own scripts to backup, copy and restore across
> different versions. Then you'll have to create your own tables to track
> the files that are copied and use the entries in those tables to keep the
> process in sync. Search google for sample scripts on custom log shipping--
> you should be able to come up with your own wih minor changes.
> --
> Anith
>
|||This is one problem with the destination database in the 90 compatibility
level. Here is a response from Kevin Farlee, a SQL Mgr at MS:
"Unfortunately, although you can maintain log shipping from SQL 2000 to a
SQL 2005 instance as long as the target database is never recovered and
converted to 90 format, you cannot have the target database in standby mode.
Putting a database in standby mode implies that you are recovering the
database and writing the uncommitted changes out to the standby file. The
last stage of recovery when a 80-format database is on a SQL 2005 instance
is to upgrade the format to 90. It just doesn't logically make sense to
have a 90-format database with a standby file of 80-format changes.
As soon as the database recovers, it will be in 90 (SQL 2005) format. A
database in 90 format cannot have 80 format logs applied to it because as
Paul points out, the physical format is different."
Anith
|||Ok. It can't do it.
Is there any ideas or suggestions on how i get the report data
source(databases) and create repports in sql2005 reporting server and data
source are sql 2k?
Thanks
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:F7D3473D-16AB-4C05-9DFA-1117A2C0E667@.microsoft.com...
> ... so in other words, separate your HA requirements (fail over) from your
> scaling requirements (reports); it is not uncommon that they require
> separate techniques.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://sqlblog.com/blogs/tibor_karaszi
>
> "Anith Sen" <anith@.bizdatasolutions.com> wrote in message
> news:uQajj97fIHA.4760@.TK2MSFTNGP06.phx.gbl...
>
Showing posts with label sql2005. Show all posts
Showing posts with label sql2005. Show all posts
Monday, March 26, 2012
Friday, March 23, 2012
log shipping question
Hi,
Log shipping from sql 2k to sql2005. How do I do it?
I have sql2005 reporting server need to be synched with sql2000 prod db for
reporting.
How do I make the dbs synched?
Thanks,You cannot use built-in log shipping across SQL 2000 and SQL 2005 (both EM
and SSMS should error out). You should get a message stating the restore
failing abruptly and suggesting you to upgrade.
However, you can write your own scripts to backup, copy and restore across
different versions. Then you'll have to create your own tables to track the
files that are copied and use the entries in those tables to keep the
process in sync. Search google for sample scripts on custom log shipping--
you should be able to come up with your own wih minor changes.
--
Anith|||Thanks for the reply, I did use my own log shipping. I still get the error;
Msg 3180, Level 16, State 1, Line 1
This backup cannot be restored using WITH STANDBY because a database upgrade
is needed. Reissue the RESTORE without WITH STANDBY.
Msg 3013, Level 16, State 1, Line 1
RESTORE LOG is terminating abnormally.
"Anith Sen" <anith@.bizdatasolutions.com> wrote in message
news:udOam56fIHA.2268@.TK2MSFTNGP02.phx.gbl...
> You cannot use built-in log shipping across SQL 2000 and SQL 2005 (both EM
> and SSMS should error out). You should get a message stating the restore
> failing abruptly and suggesting you to upgrade.
> However, you can write your own scripts to backup, copy and restore across
> different versions. Then you'll have to create your own tables to track
> the files that are copied and use the entries in those tables to keep the
> process in sync. Search google for sample scripts on custom log shipping--
> you should be able to come up with your own wih minor changes.
> --
> Anith
>|||This is one problem with the destination database in the 90 compatibility
level. Here is a response from Kevin Farlee, a SQL Mgr at MS:
"Unfortunately, although you can maintain log shipping from SQL 2000 to a
SQL 2005 instance as long as the target database is never recovered and
converted to 90 format, you cannot have the target database in standby mode.
Putting a database in standby mode implies that you are recovering the
database and writing the uncommitted changes out to the standby file. The
last stage of recovery when a 80-format database is on a SQL 2005 instance
is to upgrade the format to 90. It just doesn't logically make sense to
have a 90-format database with a standby file of 80-format changes.
As soon as the database recovers, it will be in 90 (SQL 2005) format. A
database in 90 format cannot have 80 format logs applied to it because as
Paul points out, the physical format is different."
--
Anith|||... so in other words, separate your HA requirements (fail over) from your scaling requirements
(reports); it is not uncommon that they require separate techniques.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Anith Sen" <anith@.bizdatasolutions.com> wrote in message
news:uQajj97fIHA.4760@.TK2MSFTNGP06.phx.gbl...
> This is one problem with the destination database in the 90 compatibility level. Here is a
> response from Kevin Farlee, a SQL Mgr at MS:
> "Unfortunately, although you can maintain log shipping from SQL 2000 to a SQL 2005 instance as
> long as the target database is never recovered and converted to 90 format, you cannot have the
> target database in standby mode.
> Putting a database in standby mode implies that you are recovering the database and writing the
> uncommitted changes out to the standby file. The last stage of recovery when a 80-format database
> is on a SQL 2005 instance is to upgrade the format to 90. It just doesn't logically make sense to
> have a 90-format database with a standby file of 80-format changes.
> As soon as the database recovers, it will be in 90 (SQL 2005) format. A database in 90 format
> cannot have 80 format logs applied to it because as Paul points out, the physical format is
> different."
> --
> Anith
>|||Ok. It can't do it.
Is there any ideas or suggestions on how i get the report data
source(databases) and create repports in sql2005 reporting server and data
source are sql 2k?
Thanks
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:F7D3473D-16AB-4C05-9DFA-1117A2C0E667@.microsoft.com...
> ... so in other words, separate your HA requirements (fail over) from your
> scaling requirements (reports); it is not uncommon that they require
> separate techniques.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://sqlblog.com/blogs/tibor_karaszi
>
> "Anith Sen" <anith@.bizdatasolutions.com> wrote in message
> news:uQajj97fIHA.4760@.TK2MSFTNGP06.phx.gbl...
>> This is one problem with the destination database in the 90 compatibility
>> level. Here is a response from Kevin Farlee, a SQL Mgr at MS:
>> "Unfortunately, although you can maintain log shipping from SQL 2000 to a
>> SQL 2005 instance as long as the target database is never recovered and
>> converted to 90 format, you cannot have the target database in standby
>> mode.
>> Putting a database in standby mode implies that you are recovering the
>> database and writing the uncommitted changes out to the standby file.
>> The last stage of recovery when a 80-format database is on a SQL 2005
>> instance is to upgrade the format to 90. It just doesn't logically make
>> sense to have a 90-format database with a standby file of 80-format
>> changes.
>> As soon as the database recovers, it will be in 90 (SQL 2005) format. A
>> database in 90 format cannot have 80 format logs applied to it because as
>> Paul points out, the physical format is different."
>> --
>> Anith
>|||Why not just connect your 20905 reporting services report to your 2000 database? If that is not
possible for some reason, then I'd investigate replication from 2000 to 2005.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Mecn" <mecn@.yahoo.com> wrote in message news:OA5JM38fIHA.2448@.TK2MSFTNGP03.phx.gbl...
> Ok. It can't do it.
> Is there any ideas or suggestions on how i get the report data source(databases) and create
> repports in sql2005 reporting server and data source are sql 2k?
>
> Thanks
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in message
> news:F7D3473D-16AB-4C05-9DFA-1117A2C0E667@.microsoft.com...
>> ... so in other words, separate your HA requirements (fail over) from your scaling requirements
>> (reports); it is not uncommon that they require separate techniques.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://sqlblog.com/blogs/tibor_karaszi
>>
>> "Anith Sen" <anith@.bizdatasolutions.com> wrote in message
>> news:uQajj97fIHA.4760@.TK2MSFTNGP06.phx.gbl...
>> This is one problem with the destination database in the 90 compatibility level. Here is a
>> response from Kevin Farlee, a SQL Mgr at MS:
>> "Unfortunately, although you can maintain log shipping from SQL 2000 to a SQL 2005 instance as
>> long as the target database is never recovered and converted to 90 format, you cannot have the
>> target database in standby mode.
>> Putting a database in standby mode implies that you are recovering the database and writing the
>> uncommitted changes out to the standby file. The last stage of recovery when a 80-format
>> database is on a SQL 2005 instance is to upgrade the format to 90. It just doesn't logically
>> make sense to have a 90-format database with a standby file of 80-format changes.
>> As soon as the database recovers, it will be in 90 (SQL 2005) format. A database in 90 format
>> cannot have 80 format logs applied to it because as Paul points out, the physical format is
>> different."
>> --
>> Anith
>>
>sql
Log shipping from sql 2k to sql2005. How do I do it?
I have sql2005 reporting server need to be synched with sql2000 prod db for
reporting.
How do I make the dbs synched?
Thanks,You cannot use built-in log shipping across SQL 2000 and SQL 2005 (both EM
and SSMS should error out). You should get a message stating the restore
failing abruptly and suggesting you to upgrade.
However, you can write your own scripts to backup, copy and restore across
different versions. Then you'll have to create your own tables to track the
files that are copied and use the entries in those tables to keep the
process in sync. Search google for sample scripts on custom log shipping--
you should be able to come up with your own wih minor changes.
--
Anith|||Thanks for the reply, I did use my own log shipping. I still get the error;
Msg 3180, Level 16, State 1, Line 1
This backup cannot be restored using WITH STANDBY because a database upgrade
is needed. Reissue the RESTORE without WITH STANDBY.
Msg 3013, Level 16, State 1, Line 1
RESTORE LOG is terminating abnormally.
"Anith Sen" <anith@.bizdatasolutions.com> wrote in message
news:udOam56fIHA.2268@.TK2MSFTNGP02.phx.gbl...
> You cannot use built-in log shipping across SQL 2000 and SQL 2005 (both EM
> and SSMS should error out). You should get a message stating the restore
> failing abruptly and suggesting you to upgrade.
> However, you can write your own scripts to backup, copy and restore across
> different versions. Then you'll have to create your own tables to track
> the files that are copied and use the entries in those tables to keep the
> process in sync. Search google for sample scripts on custom log shipping--
> you should be able to come up with your own wih minor changes.
> --
> Anith
>|||This is one problem with the destination database in the 90 compatibility
level. Here is a response from Kevin Farlee, a SQL Mgr at MS:
"Unfortunately, although you can maintain log shipping from SQL 2000 to a
SQL 2005 instance as long as the target database is never recovered and
converted to 90 format, you cannot have the target database in standby mode.
Putting a database in standby mode implies that you are recovering the
database and writing the uncommitted changes out to the standby file. The
last stage of recovery when a 80-format database is on a SQL 2005 instance
is to upgrade the format to 90. It just doesn't logically make sense to
have a 90-format database with a standby file of 80-format changes.
As soon as the database recovers, it will be in 90 (SQL 2005) format. A
database in 90 format cannot have 80 format logs applied to it because as
Paul points out, the physical format is different."
--
Anith|||... so in other words, separate your HA requirements (fail over) from your scaling requirements
(reports); it is not uncommon that they require separate techniques.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Anith Sen" <anith@.bizdatasolutions.com> wrote in message
news:uQajj97fIHA.4760@.TK2MSFTNGP06.phx.gbl...
> This is one problem with the destination database in the 90 compatibility level. Here is a
> response from Kevin Farlee, a SQL Mgr at MS:
> "Unfortunately, although you can maintain log shipping from SQL 2000 to a SQL 2005 instance as
> long as the target database is never recovered and converted to 90 format, you cannot have the
> target database in standby mode.
> Putting a database in standby mode implies that you are recovering the database and writing the
> uncommitted changes out to the standby file. The last stage of recovery when a 80-format database
> is on a SQL 2005 instance is to upgrade the format to 90. It just doesn't logically make sense to
> have a 90-format database with a standby file of 80-format changes.
> As soon as the database recovers, it will be in 90 (SQL 2005) format. A database in 90 format
> cannot have 80 format logs applied to it because as Paul points out, the physical format is
> different."
> --
> Anith
>|||Ok. It can't do it.
Is there any ideas or suggestions on how i get the report data
source(databases) and create repports in sql2005 reporting server and data
source are sql 2k?
Thanks
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:F7D3473D-16AB-4C05-9DFA-1117A2C0E667@.microsoft.com...
> ... so in other words, separate your HA requirements (fail over) from your
> scaling requirements (reports); it is not uncommon that they require
> separate techniques.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://sqlblog.com/blogs/tibor_karaszi
>
> "Anith Sen" <anith@.bizdatasolutions.com> wrote in message
> news:uQajj97fIHA.4760@.TK2MSFTNGP06.phx.gbl...
>> This is one problem with the destination database in the 90 compatibility
>> level. Here is a response from Kevin Farlee, a SQL Mgr at MS:
>> "Unfortunately, although you can maintain log shipping from SQL 2000 to a
>> SQL 2005 instance as long as the target database is never recovered and
>> converted to 90 format, you cannot have the target database in standby
>> mode.
>> Putting a database in standby mode implies that you are recovering the
>> database and writing the uncommitted changes out to the standby file.
>> The last stage of recovery when a 80-format database is on a SQL 2005
>> instance is to upgrade the format to 90. It just doesn't logically make
>> sense to have a 90-format database with a standby file of 80-format
>> changes.
>> As soon as the database recovers, it will be in 90 (SQL 2005) format. A
>> database in 90 format cannot have 80 format logs applied to it because as
>> Paul points out, the physical format is different."
>> --
>> Anith
>|||Why not just connect your 20905 reporting services report to your 2000 database? If that is not
possible for some reason, then I'd investigate replication from 2000 to 2005.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Mecn" <mecn@.yahoo.com> wrote in message news:OA5JM38fIHA.2448@.TK2MSFTNGP03.phx.gbl...
> Ok. It can't do it.
> Is there any ideas or suggestions on how i get the report data source(databases) and create
> repports in sql2005 reporting server and data source are sql 2k?
>
> Thanks
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in message
> news:F7D3473D-16AB-4C05-9DFA-1117A2C0E667@.microsoft.com...
>> ... so in other words, separate your HA requirements (fail over) from your scaling requirements
>> (reports); it is not uncommon that they require separate techniques.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://sqlblog.com/blogs/tibor_karaszi
>>
>> "Anith Sen" <anith@.bizdatasolutions.com> wrote in message
>> news:uQajj97fIHA.4760@.TK2MSFTNGP06.phx.gbl...
>> This is one problem with the destination database in the 90 compatibility level. Here is a
>> response from Kevin Farlee, a SQL Mgr at MS:
>> "Unfortunately, although you can maintain log shipping from SQL 2000 to a SQL 2005 instance as
>> long as the target database is never recovered and converted to 90 format, you cannot have the
>> target database in standby mode.
>> Putting a database in standby mode implies that you are recovering the database and writing the
>> uncommitted changes out to the standby file. The last stage of recovery when a 80-format
>> database is on a SQL 2005 instance is to upgrade the format to 90. It just doesn't logically
>> make sense to have a 90-format database with a standby file of 80-format changes.
>> As soon as the database recovers, it will be in 90 (SQL 2005) format. A database in 90 format
>> cannot have 80 format logs applied to it because as Paul points out, the physical format is
>> different."
>> --
>> Anith
>>
>sql
Monday, February 20, 2012
Log Shipping - SQL2000 and SQL2005
We currently have Log Shipping setup between some of our SQL Server 2000
systems. We are looking at upgrading SQL Server 2000 to SQL Server 2005.
Is it possible to have our Primary and Secondary servers to be SQL Server
2005 with a Log Shipping Monitor still running SQL Server 2000? Or, do we
need to upgrade our Log Shipping Monitor to run SQL Server 2005 as well?
Thanks,
JodyI haven't tested the scenario, but I believe that the log shipping monitor
on SQL 2000 will not work with SQL 2005. Under 2000, sqlmaint.exe took care
of automating the log shipping configuration and such - under 2005, there
are separate log shipping stored procedures used.
If someone has other info, please share.
BTW, I'll be testing this scenario in the next couple of weeks, but I fear
that I'll just be confirming what I said.
"Jody Gelowitz" <jgelowitz_nospam@.blah.leevalley.com> wrote in message
news:OBL9pUkjGHA.3848@.TK2MSFTNGP04.phx.gbl...
> We currently have Log Shipping setup between some of our SQL Server 2000
> systems. We are looking at upgrading SQL Server 2000 to SQL Server 2005.
> Is it possible to have our Primary and Secondary servers to be SQL Server
> 2005 with a Log Shipping Monitor still running SQL Server 2000? Or, do we
> need to upgrade our Log Shipping Monitor to run SQL Server 2005 as well?
> Thanks,
> Jody
>
systems. We are looking at upgrading SQL Server 2000 to SQL Server 2005.
Is it possible to have our Primary and Secondary servers to be SQL Server
2005 with a Log Shipping Monitor still running SQL Server 2000? Or, do we
need to upgrade our Log Shipping Monitor to run SQL Server 2005 as well?
Thanks,
JodyI haven't tested the scenario, but I believe that the log shipping monitor
on SQL 2000 will not work with SQL 2005. Under 2000, sqlmaint.exe took care
of automating the log shipping configuration and such - under 2005, there
are separate log shipping stored procedures used.
If someone has other info, please share.
BTW, I'll be testing this scenario in the next couple of weeks, but I fear
that I'll just be confirming what I said.
"Jody Gelowitz" <jgelowitz_nospam@.blah.leevalley.com> wrote in message
news:OBL9pUkjGHA.3848@.TK2MSFTNGP04.phx.gbl...
> We currently have Log Shipping setup between some of our SQL Server 2000
> systems. We are looking at upgrading SQL Server 2000 to SQL Server 2005.
> Is it possible to have our Primary and Secondary servers to be SQL Server
> 2005 with a Log Shipping Monitor still running SQL Server 2000? Or, do we
> need to upgrade our Log Shipping Monitor to run SQL Server 2005 as well?
> Thanks,
> Jody
>
Log Shipping - SQL2000 and SQL2005
We currently have Log Shipping setup between some of our SQL Server 2000
systems. We are looking at upgrading SQL Server 2000 to SQL Server 2005.
Is it possible to have our Primary and Secondary servers to be SQL Server
2005 with a Log Shipping Monitor still running SQL Server 2000? Or, do we
need to upgrade our Log Shipping Monitor to run SQL Server 2005 as well?
Thanks,
JodyI haven't tested the scenario, but I believe that the log shipping monitor
on SQL 2000 will not work with SQL 2005. Under 2000, sqlmaint.exe took care
of automating the log shipping configuration and such - under 2005, there
are separate log shipping stored procedures used.
If someone has other info, please share.
BTW, I'll be testing this scenario in the next couple of weeks, but I fear
that I'll just be confirming what I said.
"Jody Gelowitz" <jgelowitz_nospam@.blah.leevalley.com> wrote in message
news:OBL9pUkjGHA.3848@.TK2MSFTNGP04.phx.gbl...
> We currently have Log Shipping setup between some of our SQL Server 2000
> systems. We are looking at upgrading SQL Server 2000 to SQL Server 2005.
> Is it possible to have our Primary and Secondary servers to be SQL Server
> 2005 with a Log Shipping Monitor still running SQL Server 2000? Or, do we
> need to upgrade our Log Shipping Monitor to run SQL Server 2005 as well?
> Thanks,
> Jody
>
systems. We are looking at upgrading SQL Server 2000 to SQL Server 2005.
Is it possible to have our Primary and Secondary servers to be SQL Server
2005 with a Log Shipping Monitor still running SQL Server 2000? Or, do we
need to upgrade our Log Shipping Monitor to run SQL Server 2005 as well?
Thanks,
JodyI haven't tested the scenario, but I believe that the log shipping monitor
on SQL 2000 will not work with SQL 2005. Under 2000, sqlmaint.exe took care
of automating the log shipping configuration and such - under 2005, there
are separate log shipping stored procedures used.
If someone has other info, please share.
BTW, I'll be testing this scenario in the next couple of weeks, but I fear
that I'll just be confirming what I said.
"Jody Gelowitz" <jgelowitz_nospam@.blah.leevalley.com> wrote in message
news:OBL9pUkjGHA.3848@.TK2MSFTNGP04.phx.gbl...
> We currently have Log Shipping setup between some of our SQL Server 2000
> systems. We are looking at upgrading SQL Server 2000 to SQL Server 2005.
> Is it possible to have our Primary and Secondary servers to be SQL Server
> 2005 with a Log Shipping Monitor still running SQL Server 2000? Or, do we
> need to upgrade our Log Shipping Monitor to run SQL Server 2005 as well?
> Thanks,
> Jody
>
Subscribe to:
Posts (Atom)