- By David LeBlanc
SQL Server replication has been available in most releases of the product. Over time, replication types were introduced to ensure that users could configure replication architectures that satisfied a wide range of scenarios. Using SQL Server replication technology, you can distribute data locally, to different locations, using File Transfer Protocol (FTP), over the Internet, and to mobile users. Replication can be configured to push data, pull data, and merge data across local area networks (LANs) and wide area networks (WANs).
The simplest form of replication, snapshot replication, periodically takes a snapshot of the data and distributes it to servers that are subscribed to the publication. Snapshot replication is typically used to move data at longer intervals, such as daily or nightly. While this method is effective, it is often insufficient in satisfying the high demands of users for near real-time data. If higher throughput is required, users often leverage transactional replication. Instead of distributing snapshots of data, transactional replication continuously sends data changes as they happen to the subscribers. Transactional replication is typically used in a server-to-server topology where one server is the source of the data and the other server is used as a backup copy or for reporting.
Both replication types are one-way data movements. But what if you need bidirectional movement? For example, assume you have mobile users who work offline. While they are offline, they enter information into a database residing on an instance of SQL Server running on their laptops. What happens when they return to the office and connect to the network? In this scenario, the local instance will synchronize with the company’s primary SQL Server database. Merge replication will move transactions between the publisher and subscriber since the last time synchronization occurred.
SQL Server professionals debate the use of replication as a high availability (HA) or disaster recovery (DR) technology. Could it be used for either? There is a possibility; however, replication moves only schema changes and data. To provide an effective HA or DR topology, every aspect of the instance should be included such as security, maintenance, jobs, and so on. Therefore, using replication in either case could pose potential problems in the event of hardware failure or a disaster.
SQL Server Agent
SQL Server Agent runs as a separate service on an instance of SQL Server. Each instance of SQL Server has an accompanying SQL Agent service. The primary use of SQL Server Agent is to execute scheduled tasks, such as rebuilding indexes, backing up databases, loading the data warehouse, and so on. It allows you to schedule the jobs to run at various intervals throughout the day or night.
To ensure that you are notified in the event of a job failure, SQL Server Agent allows you to configure operators and alerts. An operator is simply an individual and an email address. Once you configure an operator, you can send notifications or alerts to that person when a job succeeds, completes, or fails.
High Availability and Disaster Recovery Tools
With growing demands on server availability and uptime, it is vital that your RDBMS include several mechanisms that will ensure the consistency and availability of your data. SQL Server 2012 provides four technologies for high availability:
AlwaysOn Availability Groups In SQL Server 2012, Microsoft introduces AlwaysOn Availability Groups. An Availability Group supports failover for a set of databases and leverages the existing database mirroring technology to maintain secondary replicas of the database on local or remote instances of SQL Server. This technology differs from traditional failover clustering in two ways:
You can configure automatic failover without the use of a Storage Area Network (SAN).
You can configure one or more of the secondary replicas to support read-only operations.
Since a SAN is no longer required, you now have the ability to configure HA and DR using one technology. By leveraging the database mirroring capability to move data over distances using TCP/IP, you can have a copy of the database stored in a data center located in a different geographic area.
Failover clustering SQL Server failover cluster instances provide high availability support at the server level. Prior to building an AlwaysOn SQL Server failover instance, you must create and configure a Windows Server failover cluster.
Database mirroring A predecessor of AlwaysOn, database mirroring provides high availability at the database level. It maintains two copies of the database on instances of SQL Server running on separate servers. Typically, the servers are hosted in separate geographic locations, not only ensuring HA, but also providing DR. If you want to incorporate automatic failover, you must include a third server (witness) that will change which server is the owner of the database. Unlike with AlwaysOn, with database mirroring you cannot directly read the secondary copy of the database. You can, however, create a snapshot of the database for read-only purposes. The snapshot will have a different name, so any clients connecting to it must be aware of the name change. Please note that this feature has been deprecated and replaced by AlwaysOn; therefore, going forward, you should use AlwaysOn instead of database mirroring.
Log shipping This is another technology that provides high availability at the database level, which is ideal for very low-latency networks. The transaction log for a specific database is sent to a secondary server from the primary server and restored. Just as with AlwaysOn and database mirroring, you can configure log shipping in a way that allows the secondary database to be read.
SQL Server Integration Services
SQL Server Integration Services (SSIS) is a platform that allows you to build high-performance extraction, transformation, and loading (ETL) frameworks for data warehouses. So why is it included in here in a list of Database Engine components? In most cases SSIS is used for ETL; however, it offers a number of tasks and transformations that extend its usage well beyond ETL.
For example, if you are new to administering a SQL Server environment, SSIS provides you with the tools needed to perform several administrative tasks, including rebuilding indexes, updating statistics, and backing up databases, which make up the primary list of maintenance items that should be performed on any database. Without SSIS, as a new administrator you could spend a lot of time writing T-SQL just to get these activities running on a regular basis. But this is not the extent of the capabilities of SSIS for administrators. How often are you asked for an export of data to Microsoft Excel or to move data from one server to another? Using SSIS, you can quickly export or import data from various sources, including Excel, text files, Oracle, and DB2.
SQL Server Management Tools
SQL Server 2012 includes two graphical user interfaces that enable you to manage, monitor, maintain, and develop in a SQL Server environment. The first is SQL Server Management Studio (SSMS), which allows you to perform just about any action you can think of against an instance of SQL Server. It is an integrated environment where you can access many instances of SQL Server. It consists of a broad set of tools with a rich set of interfaces and script editors that simplify the process of developing and configuring SQL Server instances.
In addition to SSMS, SQL Server 2012 introduces SQL Server Data Tools (SSDT). SSDT is another integrated environment, but it was designed specifically for database developers. You can explore the database and database objects using the SQL Server Object Explorer. So far, some of the most talked-about features of SSDT are the ability to easily create or edit database objects and data, and run queries directly from the interface. Using the visual Table Designer, you can change table schemas for both database projects and online database instances.