Sameer Dandage

Sameer
Dandage

Sameer Dandage is a consultant with HTC Global Services. He is an MCDBA and a SQL Server DBA with more than five years of SQL Server experience.

Articles
Preparing Disaster Scenarios
How to prepare your transactional-replication setup for a disaster.
After the Crash 1
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.
Login Security for TRQU

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.

Looking Under the Hood

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.

Queueing Up
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.
Stay in Control 1
Keep your complex software-development projects in check by building a version-control system that uses Enterprise Manager and Visual SourceSafe.

Digital Magazine Archives

Browse back issues of SQL Server Pro, from January 2007 through the last issue published in April 2014. Find the back issues here.

 

From the Blogs
Jul 28, 2015
blog

AlwaysOn Availability Groups and SQL Server Jobs, Part 29: Practical Implementation Tips

My initial goal in writing this series of posts was to outline some of the concerns surrounding Availability Groups (AGs) and SQL Server Agent Jobs – and call out how there is virtually no guidance from Microsoft on this front and then detail some of the pitfalls and options available for tackling this problem domain. I initially expected this series of posts to have between 25 and 30 posts – according to some of the early outlines I created ‘way back when’....More
Jul 6, 2015
blog

AlwaysOn Availability Groups and SQL Server Jobs, Part 28: Additional Options for Tackling Jobs Failover

Throughout this series of posts I’ve taken a somewhat pessimistic view of how SQL Server Agent jobs are managed within most organizations – meaning that most of the code and examples I’ve provided up until this point were based on assumptions about how CHANGE to jobs is managed. That pessimism, to date, has come in two forms:...More
Jul 1, 2015
blog

AlwaysOn Availability Groups and SQL Server Jobs, Part 27: Options and Concerns for More Advanced Deployments

In this series of posts I’ve called out some of the concerns related to SQL Server AlwaysOn Availability Groups and their interaction with SQL Server Agent jobs – both in the form of Batch Jobs (see post #3) and backups....More
SQL Server Pro Forums

Get answers to questions, share tips, and engage with the SQL Server community in our Forums.

Sponsored Introduction Continue on to (or wait seconds) ×