Mirroring a vendor's SQL Server database to a reporting database with minimal configuration changes to the source

We host on our servers a vendor application's SQL Server database that we'd like to copy/mirror/replicate to a reporting location on a regular basis开发者_C百科. Full restores of nightly backups aren't working, full backups are too large to transfer over the network and restore in a timely manner.

I am aware of Replication and Log Shipping, but it appears that those options require the "source" database to do the work and be configured in some way to allow for this to happen. We'd like to make as few changes as possible to our production database since it is "controlled" by a 3rd-party vendor's application and any changes we make causes support issues for them (understandably so).

So .. this must be a common scenario but searching yielded no results. Is there a clean, simple way to mirror a very large, active SQL Server 2005 database to a reporting location incrementally on a regular basis (say, nightly) while making no (or minimal) changes to the source database?

---

I have done this in the past with Log Shipping. The only thing you need to do to the source database to enable this is to set the recovery model to "Full", and then configure it with a schedule of Complete and Transaction Log backups. A more detailed outline:

• Configure the source database with recovery model set to Full.
• Create the "first" complete backup
• Create the target database by restoring the complete backup, leaving it in Standby* mode
• Set up a schedule of transaction log backups. Frequency totally depends upon your circumstances, but by and large you don't want the t-log backup files to be too big.
• Configure log shipping between the two database

*Standby Mode allows read-only access to the database. Note that you cannot apply subsequent restores to a standby database if there are any connections open to it.

Timing is the hard part here. Presumably you want to update the database once per day at, say, Midnight YST (that's "Your Standard Time"), which means that: - At that time, ensure that there are no open connections to the target database (i.e. kill any you find, and make sure your users know you'll be doing that!) - Apply the day's accumulated restores at that time

I did this a few years back, and I don't think these precise requirements were supported by the built-in log shipping utilities (that, or they were overly complex). Whatever, it wasn't all that hard to "roll your own"; simply keep track of the last t-log applied, write a "Shoot Zem All" connection-killing routine, and pull and apply any subsequent ones found in the backup folder.