Log shipping over a T1, best pratices

I successfully implemented log shipping but am questioning the xcopy function over a point to point T1. Would it be better to use FTP? The database file is currently 6 gigs in size and takes awhile to copy over. We are doing this with SQL Server 2000 sta
ndard, so we don't get the extra features that Enterprise Edition would give us, whatever they may be. Any suggestions are appreciated.
Thanks,
Denny
ftp is considered to be unsecure. Its performance is much the same as an
xcopy.
"Denny" <anonymous@.discussions.microsoft.com> wrote in message
news:6E15A90F-AB52-4268-B379-B7FE73EA5EED@.microsoft.com...
> I successfully implemented log shipping but am questioning the xcopy
function over a point to point T1. Would it be better to use FTP? The
database file is currently 6 gigs in size and takes awhile to copy over. We
are doing this with SQL Server 2000 standard, so we don't get the extra
features that Enterprise Edition would give us, whatever they may be. Any
suggestions are appreciated.
> Thanks,
> Denny

log shipping and replication

Ive got my publishers and distributors on the same server say Server A . We
have implemented log shipping as Disaster Recovery solution.
Ive got my published databases log shipped to Server B.
My questions are : Do I need to log ship the distribution database as well ?
How can I recover from this scenario should Server A fail ?
I have read Books Online on Replication and Log shipping.. We cannot
implement the " sync with backup " option because of the increased latency.
It also talks about the semi-synchronous mode. I havent really followed it
for the fact that the distribution database is on the same server as the
publisher and currently we are not log shipping that.
Can someone guide me here on how to recover based upon my settings ? Using
SQL 2000
Thanks
Hassan,
In my experience when replication databases are restored onto another server
than the original, restoration is only partially successful using
KEEP_REPLICATION, and on failover it was not possible to rename the server
then start synchronizing - I found it easiest to recreate the publications
from scratch. However if you restore to Server A itself (or another "Server
A") then it should be ok.
The "sync with backup" option is to ensure that transactions don't get into
the distribution database before the publication database is backed up,
otherwise the distribution database backup could be ahead of the publication
backup. You can achieve the same effect by making sure that the restore of
the publication database and logs is older than the restore of the
distribution database - then you have essentially performed a synchronous
mode backup. In your case you will need a distribution backup, as regular as
possible.
To see the order of restores if Server A goes down, have a look in BOL at
"replication, backup and restore operations".
hth,
Paul Ibison

Log shipping and DTS packages update

Hello,
I just implemented log shipping on SQL Server 2000 Developer edition
and I need to keep all modifications to DTS packages on Primery Server
to be replicated on Standby Server. Could you please give me a hint how
to do that?
Thanks,
GBGB wrote:

> DTS packages
From microsoft:
"Copying DTS Packages
DTS packages can be stored in the msdb database or in the file system.
If you have DTS packages that run on the primary server on which your
production database relies, you must manually copy these DTS packages
to each standby server. You cannot simply back up the msdb database and
restore it to a standby server. Doing so overwrites all jobs, alerts,
operators, and DTS packages in the msdb database on the standby server.
You can open DTS packages saved to the msdb database on the primary
server and save them to each standby server. Simply copy DTS packages
saved to the file system on the primary server to a folder on each
standby server. Complete this task before users connect to a standby
server that is promoted to become the new primary server.
Use the following procedure to copy DTS packages that the production
database needs to each standby server.
To copy DTS packages
1.
For each DTS package stored in the file system on the primary server,
copy the DTS package to each standby server using Windows Explorer.
When copying DTS packages to each standby server, use the same drive
and path that the primary server uses. Doing so eliminates potential
path problems.
2.
For each DTS package stored in the msdb database on the primary server,
use SQL Server Enterprise Manager to open the DTS package, and then
save it to the msdb database on each standby server.
Note: To ensure DTS packages execute properly on a subscriber, use an
alias or the dynamic properties task. For more information, see
"Redirecting Client Network Traffic to a Promoted Secondary Server" in
Planning Guide Chapter 5, "Minimizing Downtime by Using Redundant
Components.""
This article might be handy:
http://www.dbazine.com/sql/sql-articles/larsen8
HTH,
Stijn Verrept.