Log Shipping Concern

My department is thinking of implementing Log Shipping for a database. We
have a concern that, due to the nature of replication via log files, some
transactions may not execute properly on the secondary server and when this
occurs we will have essentially non-matching databases. Is this concern a
real issue and if so, how are such issues resolved?
Right now our situation allows us to dump and restore the database at any
time and take it offline if we have to. This dump and restore availability
ensures that we have two exact copies of the database with identical
footprints. Basically our concern is that we want to be assured an equal
concurrecy with log shipping.
Can anybody provide any insight?
Thanks,
Jeff
PS. I was not sure which group to post this in (I posted the same message
in this and in .Replication). Which group do Log Shipping questions belong
in?Log Shipping works but can be a pain in the neck.
the biggest problem we ran into was the occurence of "Non-Logged" Operations
in production.
this breaks log shipping quicker than you can blink.
Cheers,
Greg Jackson
Portland, OR|||Log shipping is mainly used for maintaining standby
Servers.
If you want to do logshipping for just only one database
in a server, make sure you are taking a right decision.
Compare the pros & cons of Replication and Log Shipping
and see whether log shipping is your right choice over
Replication. If you are more concerned about data
concurrency, check whether Replication solves your purpose.
Once log shipping has been implemented, it is relatively
easy to maintain. If Logshipping is implemented properly,
usually there wont be much issues.Its very robust.
I have encountered only the issues which is explained in
the articles below.
http://www.microsoft.com/technet/treeview/default.asp?
url=/technet/prodtechnol/sql/reskit/sql2000/part4/c1361.asp
This link may help you get better idea of Log shipping.
This is a webcast.
http://support.microsoft.com/default.aspx?kbid=821786
The issue you have mentioned about the non-matching
databases, I have not come across in my vast experience in
Logshipping or Replication. I think that,if the databases
on publisher and subscriber are in sync with every aspects
(contraints,data..), then this will not occur.
If I have understand correctly, then Replication is the
best and suits your purpose.
Hope this gives you some idea to start with.
SQLVarad (MCDBA-1999,MCSE-1999)
>--Original Message--
>My department is thinking of implementing Log Shipping
for a database. We
>have a concern that, due to the nature of replication via
log files, some
>transactions may not execute properly on the secondary
server and when this
>occurs we will have essentially non-matching databases.
Is this concern a
>real issue and if so, how are such issues resolved?
>Right now our situation allows us to dump and restore the
database at any
>time and take it offline if we have to. This dump and
restore availability
>ensures that we have two exact copies of the database
with identical
>footprints. Basically our concern is that we want to be
assured an equal
>concurrecy with log shipping.
>Can anybody provide any insight?
>Thanks,
>Jeff
>PS. I was not sure which group to post this in (I posted
the same message
>in this and in .Replication). Which group do Log
Shipping questions belong
>in?
>
>.
>|||>the biggest problem we ran into was the occurence of "Non-
Logged" Operations
>in production.
>this breaks log shipping quicker than you can blink.
If you are in a production environment, you shouldn't be
doing non-logged operations. And under SQL 2K, this
really for the most part isn't possible. You use Full or
Bulk-Logged, and log shipping works. Simple prevents you
from making tran log backups at all.
The non-logged issue was more of a problem in SQL 7 and
earlier.