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
|||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...
>

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 issue

Hi All,
I am a new learner of SQL2000. Recently I learned to setup log shipping.
I have Primary Server (A) and 1st Secondary Server (B) at my head office.
I also have 2nd Secondary (C) at a remote site. Server A log ship logs to
server B and C. Server C is my monitor server also. One of the log shipping
failed. Now when I try to re- establish log shipping I am getting following
error:
"Error 14261: he specified primary_server-name.primary-database-name('F')
already exist."
I don't see any thing in log shipping monitor nor under Databasse
maintenance Plans. Please guide me how to get rid of error.
Many Thanks,
Jamil
If you look in the msdb database on your sql server there are a series of
tables starting "Log Shipping" .. they should all be empty before you set up
your plan. This applies to all 3 servers, dont forget to clear the tables on
the monitor server.
"Jamil Ahsan" wrote:

> Hi All,
> I am a new learner of SQL2000. Recently I learned to setup log shipping.
> I have Primary Server (A) and 1st Secondary Server (B) at my head office.
> I also have 2nd Secondary (C) at a remote site. Server A log ship logs to
> server B and C. Server C is my monitor server also. One of the log shipping
> failed. Now when I try to re- establish log shipping I am getting following
> error:
> "Error 14261: he specified primary_server-name.primary-database-name('F')
> already exist."
> I don't see any thing in log shipping monitor nor under Databasse
> maintenance Plans. Please guide me how to get rid of error.
> Many Thanks,
> Jamil
>

log shipping initial backup restore

hi,
sql2000 enterprise edi. Planning for 15 min log shipping .
database size is around 6 gb. took the full backup and try to copy to the
secondary server over the network taking too much of time (say .5mb/sec).
meanwhile i stoped the transaction log backup . because the full backup is
not restored in the secondary server. my question is , ' can i restore log
backups after the full backup restore on secondary to make sync. ? then start
the log shipping process? or peer to peer connection needed in between
primary and secondary?
2) Another question : after the reindex process, the log file size will be
similar to dbsize. so transafering the log file over the network will take
take and log shipping may break because of copy time? how can i handle this?
thanks
Hello
I had a quick question - Did you start the file copy process for your
Complete backup through the Log Shipping Setup wizard?
Assuming that you did not, then regarding your first question :
You can actually perform the transaction log backups on your primary server
while the complete backup is copying over.
1. Once the complete backup is finished copying, start the restore of this
complete backup in NORECOVERY mode and in the meantime start copying over
the transaction log backups.
2. When the restore of the complete backup is complete, start applying the
transaction logs with NORECOVERY option.
3. At some point, stop performing transaction log backups on your primary
server and complete copying/restoring the transaction log backups on the
secondary server.
4. Once the secondary database is ready, start the Log Shipping Setup
Wizard (through the Maintenance Plan) and on the Log Shipping secondary
dialog, select Existing database option and select the NORECOVERY database
that you have created in steps earlier. Selecting this option will prevent
the Wizard from actually initiating a copy/load of the complete backup
during setup.
Regarding your second question:
Since rebuilding an index is a logged operation, there is no way for you to
get around this problem. The only way you can avoid this is by
reinitializing log shipping which is going to be more time consuming. Think
of this process as "keeping your secondary database in complete sync with
your primary". Assume for a second that as soon as you've finished
restoring the large transaction log backup (performed after the index
rebuild operation) to the secondary standby database, your primary database
goes offline. At this point since you have to bring the secondary online,
you would expect it to perform just as fast as your primary (given all
other factors including hardware etc are the same between the 2 machines).
Well if there was a way for you to avoid transferring the info related to
index rebuild to the secondary, the performance on your secondary most
likely would be very slow since there were no index updates performed on it.
Let me know if you have further questions.
Thank you for using Microsoft newsgroups.
Sincerely
Pankaj Agarwal
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
|||pankaj,
Thanks for you suggestion.
I took the full backup and copied over the network to the standby server,
before starting Logshipping process Setup. But it was very slow. For setting
up logshipping for production environment, i dont want any sync problems
like copying delay and restore log after the reindex process. I want to
know that whether i missed something.
I am thinking of adding one more NIC to my production server to connect to
the standby to improve the copy process.
"Pankaj Agarwal [MSFT]" <pankaja@.online.microsoft.com> wrote in message
news:k0XK9CVkEHA.2656@.cpmsftngxa10.phx.gbl...
> Hello
> I had a quick question - Did you start the file copy process for your
> Complete backup through the Log Shipping Setup wizard?
> Assuming that you did not, then regarding your first question :
> You can actually perform the transaction log backups on your primary
server
> while the complete backup is copying over.
> 1. Once the complete backup is finished copying, start the restore of this
> complete backup in NORECOVERY mode and in the meantime start copying over
> the transaction log backups.
> 2. When the restore of the complete backup is complete, start applying the
> transaction logs with NORECOVERY option.
> 3. At some point, stop performing transaction log backups on your primary
> server and complete copying/restoring the transaction log backups on the
> secondary server.
> 4. Once the secondary database is ready, start the Log Shipping Setup
> Wizard (through the Maintenance Plan) and on the Log Shipping secondary
> dialog, select Existing database option and select the NORECOVERY database
> that you have created in steps earlier. Selecting this option will prevent
> the Wizard from actually initiating a copy/load of the complete backup
> during setup.
> Regarding your second question:
> Since rebuilding an index is a logged operation, there is no way for you
to
> get around this problem. The only way you can avoid this is by
> reinitializing log shipping which is going to be more time consuming.
Think
> of this process as "keeping your secondary database in complete sync with
> your primary". Assume for a second that as soon as you've finished
> restoring the large transaction log backup (performed after the index
> rebuild operation) to the secondary standby database, your primary
database
> goes offline. At this point since you have to bring the secondary online,
> you would expect it to perform just as fast as your primary (given all
> other factors including hardware etc are the same between the 2 machines).
> Well if there was a way for you to avoid transferring the info related to
> index rebuild to the secondary, the performance on your secondary most
> likely would be very slow since there were no index updates performed on
it.
> Let me know if you have further questions.
> Thank you for using Microsoft newsgroups.
> Sincerely
> Pankaj Agarwal
> Microsoft Corporation
> This posting is provided AS IS with no warranties, and confers no rights.
>
|||Unfortunately there is no way to get around the large transaction log when
you are performing index rebuild. If you feel that adding another NIC will
provide better bandwidth and hence faster copy, then that may be something
to consider.
Thank you for using Microsoft newsgroups.
Sincerely
Pankaj Agarwal
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.

log shipping initial backup restore

hi,
sql2000 enterprise edi. Planning for 15 min log shipping .
database size is around 6 gb. took the full backup and try to copy to the
secondary server over the network taking too much of time (say .5mb/sec).
meanwhile i stoped the transaction log backup . because the full backup is
not restored in the secondary server. my question is , ' can i restore log
backups after the full backup restore on secondary to make sync. ? then star
t
the log shipping process? or peer to peer connection needed in between
primary and secondary?
2) Another question : after the reindex process, the log file size will be
similar to dbsize. so transafering the log file over the network will take
take and log shipping may break because of copy time? how can i handle this
?
thanksHello
I had a quick question - Did you start the file copy process for your
Complete backup through the Log Shipping Setup wizard?
Assuming that you did not, then regarding your first question :
You can actually perform the transaction log backups on your primary server
while the complete backup is copying over.
1. Once the complete backup is finished copying, start the restore of this
complete backup in NORECOVERY mode and in the meantime start copying over
the transaction log backups.
2. When the restore of the complete backup is complete, start applying the
transaction logs with NORECOVERY option.
3. At some point, stop performing transaction log backups on your primary
server and complete copying/restoring the transaction log backups on the
secondary server.
4. Once the secondary database is ready, start the Log Shipping Setup
Wizard (through the Maintenance Plan) and on the Log Shipping secondary
dialog, select Existing database option and select the NORECOVERY database
that you have created in steps earlier. Selecting this option will prevent
the Wizard from actually initiating a copy/load of the complete backup
during setup.
Regarding your second question:
Since rebuilding an index is a logged operation, there is no way for you to
get around this problem. The only way you can avoid this is by
reinitializing log shipping which is going to be more time consuming. Think
of this process as "keeping your secondary database in complete sync with
your primary". Assume for a second that as soon as you've finished
restoring the large transaction log backup (performed after the index
rebuild operation) to the secondary standby database, your primary database
goes offline. At this point since you have to bring the secondary online,
you would expect it to perform just as fast as your primary (given all
other factors including hardware etc are the same between the 2 machines).
Well if there was a way for you to avoid transferring the info related to
index rebuild to the secondary, the performance on your secondary most
likely would be very slow since there were no index updates performed on it.
Let me know if you have further questions.
Thank you for using Microsoft newsgroups.
Sincerely
Pankaj Agarwal
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||pankaj,
Thanks for you suggestion.
I took the full backup and copied over the network to the standby server,
before starting Logshipping process Setup. But it was very slow. For setting
up logshipping for production environment, i dont want any sync problems
like copying delay and restore log after the reindex process. I want to
know that whether i missed something.
I am thinking of adding one more NIC to my production server to connect to
the standby to improve the copy process.
"Pankaj Agarwal [MSFT]" <pankaja@.online.microsoft.com> wrote in message
news:k0XK9CVkEHA.2656@.cpmsftngxa10.phx.gbl...
> Hello
> I had a quick question - Did you start the file copy process for your
> Complete backup through the Log Shipping Setup wizard?
> Assuming that you did not, then regarding your first question :
> You can actually perform the transaction log backups on your primary
server
> while the complete backup is copying over.
> 1. Once the complete backup is finished copying, start the restore of this
> complete backup in NORECOVERY mode and in the meantime start copying over
> the transaction log backups.
> 2. When the restore of the complete backup is complete, start applying the
> transaction logs with NORECOVERY option.
> 3. At some point, stop performing transaction log backups on your primary
> server and complete copying/restoring the transaction log backups on the
> secondary server.
> 4. Once the secondary database is ready, start the Log Shipping Setup
> Wizard (through the Maintenance Plan) and on the Log Shipping secondary
> dialog, select Existing database option and select the NORECOVERY database
> that you have created in steps earlier. Selecting this option will prevent
> the Wizard from actually initiating a copy/load of the complete backup
> during setup.
> Regarding your second question:
> Since rebuilding an index is a logged operation, there is no way for you
to
> get around this problem. The only way you can avoid this is by
> reinitializing log shipping which is going to be more time consuming.
Think
> of this process as "keeping your secondary database in complete sync with
> your primary". Assume for a second that as soon as you've finished
> restoring the large transaction log backup (performed after the index
> rebuild operation) to the secondary standby database, your primary
database
> goes offline. At this point since you have to bring the secondary online,
> you would expect it to perform just as fast as your primary (given all
> other factors including hardware etc are the same between the 2 machines).
> Well if there was a way for you to avoid transferring the info related to
> index rebuild to the secondary, the performance on your secondary most
> likely would be very slow since there were no index updates performed on
it.
> Let me know if you have further questions.
> Thank you for using Microsoft newsgroups.
> Sincerely
> Pankaj Agarwal
> Microsoft Corporation
> This posting is provided AS IS with no warranties, and confers no rights.
>|||Unfortunately there is no way to get around the large transaction log when
you are performing index rebuild. If you feel that adding another NIC will
provide better bandwidth and hence faster copy, then that may be something
to consider.
Thank you for using Microsoft newsgroups.
Sincerely
Pankaj Agarwal
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.

Log shipping in SQL STD

I'm looking for some docs to instruct me how to setup log shipping in a SQL
2000 Standard environment.
Thanks
Here's one example:
http://www.sqlservercentral.com/colu...ogshipping.asp
HTH,
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"Peretz Stern" <peretzstern@.optonline.net> wrote in message
news:O58NIYWnFHA.1372@.TK2MSFTNGP10.phx.gbl...
> I'm looking for some docs to instruct me how to setup log shipping in a
> SQL 2000 Standard environment.
>
> Thanks
>

Log shipping in SQL STD

I'm looking for some docs to instruct me how to setup log shipping in a SQL
2000 Standard environment.
Thanks
Here's one example:
http://www.sqlservercentral.com/colu...ogshipping.asp
HTH,
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"Peretz Stern" <peretzstern@.optonline.net> wrote in message
news:O58NIYWnFHA.1372@.TK2MSFTNGP10.phx.gbl...
> I'm looking for some docs to instruct me how to setup log shipping in a
> SQL 2000 Standard environment.
>
> Thanks
>

Log shipping in SQL STD

I'm looking for some docs to instruct me how to setup log shipping in a SQL
2000 Standard environment.
Thanks
Here's one example:
http://www.sqlservercentral.com/colu...ogshipping.asp
HTH,
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"Peretz Stern" <peretzstern@.optonline.net> wrote in message
news:O58NIYWnFHA.1372@.TK2MSFTNGP10.phx.gbl...
> I'm looking for some docs to instruct me how to setup log shipping in a
> SQL 2000 Standard environment.
>
> Thanks
>

Log shipping in SQL STD

I'm looking for some docs to instruct me how to setup log shipping in a SQL
2000 Standard environment.
ThanksHere's one example:
http://www.sqlservercentral.com/col...logshipping.asp
--
HTH,
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"Peretz Stern" <peretzstern@.optonline.net> wrote in message
news:O58NIYWnFHA.1372@.TK2MSFTNGP10.phx.gbl...
> I'm looking for some docs to instruct me how to setup log shipping in a
> SQL 2000 Standard environment.
>
> Thanks
>

Log shipping error - database in use

I am using MS builtin log-shipping functionality in
SQL2000.
My log shipping maintenance plan has a secondary load
state of 'standby' mode. And I have selected
the 'terminate users in database' option - however,
occasionally my log-shipping job is failing with '3101 -
database in use' error.
However, I thought that by selecting 'terminate users in
database' option - this should never happen ?
Has anyone seen anything similar before ?'terminate users in database' will not work always and
does not guarantee anything, a terminated process may drop
into a rollback mode and then it could take a long time to
finally get disappeared.
>--Original Message--
>I am using MS builtin log-shipping functionality in
>SQL2000.
>My log shipping maintenance plan has a secondary load
>state of 'standby' mode. And I have selected
>the 'terminate users in database' option - however,
>occasionally my log-shipping job is failing with '3101 -
>database in use' error.
>However, I thought that by selecting 'terminate users in
>database' option - this should never happen ?
>Has anyone seen anything similar before ?
>.
>

Log Shipping "best-practices" question

hello,
I have a SQL2000 server with circa 20 databases. I am setting up Log
Shipping for these DBs. These DBs are not very active so I want to replicate
every 2 hours. I can schedule all three steps separately:
- backing up the log on the source server
- copying the log-backup from the source server to the destination server
- restoring the backup at the destination server
My question is: should these steps happen the same time for all the DBs or
should I distribute them over a larger time period. For instance I can do all
20 DBs at 2pm, (then 4pm, then 6pm etc), or I can do the first at 2:00pm, the
second at 2:05pm, the third on at 2:10pm etc, (and then 4:00, 4:05, 4:10 etc)
so I don't put too much load on the server.
Is there a "best-practice" related to this? How about copying the logs and
restoring them?
thanks
christos
If these databases are large you should stagger the dumps and copies to
prevent network saturation. If they are small this shouldn't be a problem.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Christos Kritikos" <ChristosKritikos@.discussions.microsoft.com> wrote in
message news:FFBC1E97-0E92-43BF-943A-6971664FFE94@.microsoft.com...
> hello,
> I have a SQL2000 server with circa 20 databases. I am setting up Log
> Shipping for these DBs. These DBs are not very active so I want to
replicate
> every 2 hours. I can schedule all three steps separately:
> - backing up the log on the source server
> - copying the log-backup from the source server to the destination server
> - restoring the backup at the destination server
> My question is: should these steps happen the same time for all the DBs or
> should I distribute them over a larger time period. For instance I can do
all
> 20 DBs at 2pm, (then 4pm, then 6pm etc), or I can do the first at 2:00pm,
the
> second at 2:05pm, the third on at 2:10pm etc, (and then 4:00, 4:05, 4:10
etc)
> so I don't put too much load on the server.
> Is there a "best-practice" related to this? How about copying the logs and
> restoring them?
> thanks
> christos
>
>

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
>

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
>