Transactional replication with queued updates (TRQU) can be a useful way to replicate data if you can tolerate some latency. Sameer Dandage examines the intricacies of backing up and restoring TRQU setups.
In transactional replication with queued updates (TRQU), the Distributor needs to connect to the Publisher and Subscriber. For security, the replication agents use a special SQL Server login that SQL Server creates during the replication setup for this purpose. This login, distributor_admin, has sysadmin permissions on all SQL Server instances involved in the replication process. You can see this login in the sysxlogins table on all servers.
Maintaining multiple database servers at multiple sites in active mode and closely synchronizing copies of the data on all servers is a challenge for any DBA. But as long as you can tolerate a little latency, one good option for keeping your data current at all locations is to use SQL Server’s transactional replication with queued updates (TRQU). In the first article in this series, “Queuing Up,” December 2003, InstantDoc 40567, I showed how to set up TRQU.
If you need to maintain multiple database servers at multiple sites and synchronize all the data, SQL Server has a solution to make your job easier--SQL Server’s Transactional Replication with Queued Updates can help.
The quest for the Golden Record to achieve a single, accurate and complete version of a customer record is worth the pursuit to attain survivorship. Record matching and consolidation are only the beginning. Melissa Data takes a new approach. Learn how to apply intelligent rules based on reference data to make smarter and better decisions for data cleansing....More
On SQL Servers where Availability Groups (or Mirroring) isn’t in play, I typically recommend keeping a combination of on-box backups along with copying said backups off-box as well. Obviously, keeping databases AND backups on the SAME server is the metaphorical equivalent of putting all of your eggs in one basket – and therefore something you should avoid like the plague....More
One of the biggest strengths of AlwaysOn Availability Groups is that they allow DBAs to address both high availability and disaster recovery concerns from a single set of tooling or interfaces. But, this doesn’t mean that you won’t still need backups....More