If your business has an SQL Server environment functioning as a system of record, you may find that you need to make data available outside of it.
As you consider your path forward, it’s helpful to have a full understanding of the process to make that happen. Accordingly, in this article, we’ll outline some of the major considerations to account for when doing SQL Server data replication.
The good news is that data replication from SQL Server is typically straightforward, especially when done using StarQuest Data Replication software.
Ready to learn how to approach it? Let’s dig in.
First, let’s define our basic term: What do we mean when we say data replication?
As we’ve written before, data replication is a process by which data is made available outside of the systems that are used to produce or maintain it. The use cases are broad; data replication might be used to power business intelligence, or disaster recovery solutions, or to provide a sandbox for testing applications.
Data replication tends to involve frequency (meaning that updates are performed to keep data current) and distribution (meaning that data is replicated from a source database to a destination database). It’s useful whenever data needs to be accessed outside of production systems.
With data replication defined, let’s discuss our platform of interest: Microsoft’s SQL Server.
SQL Server is a relational database management system (RDBMS) that was originally released by Microsoft in 1988 to compete with database products from IBM and Oracle. Unsurprisingly, given its maker, SQL Server supports ANSI SQL, but comes with a proprietary language known as Transact-SQL (or T-SQL for short).
SQL Server has come a long way from its origins. It’s now compatible with Linux and can handle JSON data. Still, despite its advances, newer database management system players have tried to label it a legacy system. In reality, today’s SQL Server is still an industry standard, but it has frequently become a system of record, with organizations looking to replicate data from SQL Server to other environments (whereas, in the past, replication was often done to SQL Server).
It’s still one of the most widely recognized and commonly used database environments on the planet.
With the role of SQL Server clarified, let’s dig into key considerations for replicating SQL Server data to another database management system.
SQL Server doesn’t provide direct log access.
One of the most notable things to keep in mind is that SQL Server provides no direct access to their log. Instead, the environment is designed to provide a queryable version of the log information, which is available in two different modes. One is based on row versioning, and one is based on change data capture.
In both cases, the data reflected and made available is not actually the log. So, in replication, solutions can be somewhat limited by what is exposed in these two mechanisms for delivering change data.
SQL Server is easy to work with.
On the plus side, SQL Server is very easy to work with and very easy to understand, thanks to straightforward design by Microsoft. While there are limitations, they are known limitations, and it’s very easy to determine what the possibilities for replication are and to enact them.
SQL Server does not incur an additional cost for transactional replication.
Another tally on the plus side: SQL Server has the built-in ability to implement transactional replication (meaning it’s not an additional cost item). Both change tracking and change data capture allow for relatively easy data replication setup.
SQL Server is not as scalable as Oracle and DB2.
As a source of information, SQL Server is not quite as scalable as the other database products (like Oracle and IBM’s Db2). It’s hard to point to a SQL Server database that’s doing some of the massive data management that Oracle and Db2 have been tasked with. That’s because SQL Server has grown from a technology that was originally intended for personal computers, whereas other products were designed for largescale environments.
So, with all of this said, how should you actually go about replicating SQL Server data?
At StarQuest, we recommend transactional replication using change data capture. While SQL Server logs aren’t directly accessible, this method is straightforward, reliable, and effective, especially when enacted via a solution like StarQuest Data Replication software (SQDR).
SQDR creates an intermediate repository of data from SQL Server that doesn’t impact the environment’s resources and that can be kept up to date in near-real-time. It’s easily compatible with all of the major DBMS products on the market, which means that you can send your data to the environment of your choice.
If you’re ready to move ahead with SQL Server data replication, we’d love to hear from you. We’ve helped leading brands like Mazda, BlueCross Blue Shield, and US Foods to seamlessly replicate data. And our customer service team is regarded as some of the best in the business, with clients calling us “The best vendor support I have ever encountered.”
Get in touch with us to discuss your data replication needs. We can set you up with a no-charge trial of our software from SQL Server to the DBMS of your choice, and help you take the first step toward a solution that will meet your data replication requirements.