First published on MSDN on Oct 19, 2016
This is the first post in a planned series of articles relating to SQL Server Transaction Log Backups of databases using a read-only secondary replica (ROSR). With the introduction of ROSRs in SQL Server 2012, administrators can now perform full database (copy only) backups as well as transaction log backups on one of the secondary replicas within the same Availability Group. This allows the administrator to reduce or eliminate resource contention between production activity and backups. This series of posts will address some of the aspects of transaction log backups that may not be obvious, especially as it pertains to how the log truncation LSN is maintained across all of the replicas (primary and secondary), as well as what can actually be backed up. For example, if a transaction log backup is taken on an asynchronous replica that is significantly behind the primary replica, what will actually be backed up and how will that affect the log chain? In addition, since the log backups can be taken from either the primary replica or any secondary replica, how will the log chain be maintained? Can log backups be taken on more than one database replica at the same time? This series of posts will attempt to address these and other questions and full explain how this new feature will enhance the DBAs capabilities in maintaining databases in an AlwaysOn environment.
When troubleshooting AlwaysOn Availability Groups, there are several DMVs that refer to various LSNs (log sequence numbers). In addition, backup and restore operations frequently refer to and output LSN values.
So what is an LSN? An LSN, is a sequence number that is used to maintain order and track operations within a database. An LSN can be in either decimal form or hex depending on where it is referenced. Most DMVs reference the LSN in decimal format. The decimal format of the LSN is composed of three concatenated
pieces of information. Those three pieces are (from left to right):
The hexadecimal format is simply the hexadecimal representation of each portion (VLF, Log Block number, and Log Record number) separated by colons (:). For example: 34 in decimal is 22 in Hex, 156 in decimal is 9C in hex, and 65 in decimal is 41 in hex. So the LSN represented by 34000000015600065 in decimal would appear as 22:9C:41 in hexadecimal.
In the previous section, the definition of an LSN was mention as a combination of the VLF (virtual log file), the Log Block number, and the Log Record number. What is a “Lob Block” and what is a “Log Record”? For the purposes of this article, a log block is a collection of log records that are written to disk together. A “log record” is a single atomic record of activity within the SQL engine. The relationship between “log record”, “log block”, and Virtual Log File (VLF) is as follows:
Now it is time to look at one important DMV for reviewing the current status of a database replica. How this pertains to database backups will be more clear in part two of this series, “Describe the Log Backup Process on a ROSR”. Right now, there is plenty to look at in this DMV.
The DMV, sys.dm_hadr_database_replica_states , has several columns that have “LSN” as part of their name that are helpful in troubleshooting issues dealing with AlwaysOn replication. Even though these fields have “lsn” in their name, in fact, they are not all true LSNs. Of the ones listed in the table above, only the last_redone_lsn and end_of_log_lsn are true LSNs. The others are actually Log Block IDs.
The following diagram depicts the relationship between these “LSNs” values when looking at the Primary Replica and a corresponding Secondary replica. Points “B”, “C”, and “E” point to the log blocks themselves representing the fact those values are Log Block IDs. In contrast, points “A” and “D” point to log records and represent true LSNs.
As noted in the blog, AlwaysON - HADRON Learning Series: - How does AlwaysON Process a Synchronous Commit Request , AlwaysOn does not ship individual log records, it ships log blocks. The log block is used as a container for log records so by virtue of the log block tracking the individual LSN tracking also occurs. Additionally, it is important to note that last_hardened_lsn is a “flush LSN” meaning that it represents the START of the NEXT block past the blocks already stored on stable media. In other words, an LSN value that is less than last_hardened_lsn has been saved to stable media. Any LSN greater than or equal to the last_hardened_lsn value has not been flushed.
Combining everything that has been discussed so far, we can now query sys.dm_hadr_database_replica_states and begin to analyze the information obtained.
On an instance that is acting as a primary replica,execute the following query:
SELECT ar.replica_server_name AS ServerName ,drs.synchronization_state_desc AS SyncState ,drs.last_hardened_lsn ,drs.last_redone_lsn FROM sys.dm_hadr_database_replica_states drs LEFT JOIN sys.availability_replicas ar ON drs.replica_id = ar.replica_id ORDER BY ServerNameYou should see results similar to the following:
This article has attempted to explain several foundation points that will make subsequent study of log backups on secondary replicas easier to understand. The LSN is comprised of three pieces concatenated together:
When executed on the primary, the DMV, sys.dm_hadr_database_replica_states can be used to show the status of the various secondary replicas. In addition, in order for a secondary replica to be SYNCHRONIZED it must be configured for synchronous commit, and the last_hardened_lsn must be the
same as the primary. And for a secondary replica that is configured for asynchronous commit, it will never be in a SYNCHRONIZED state even if it has the identical last_hardened_lsn value.
Finally it was demonstrated that even though the secondary replica LC2SQLAOLB2 was SYNCHRONIZED, the last_redone_lsn was one log block ID less than the last_hardened_lsn . This is because the last_hardened_lsn is not a true LSN, but rather a “Flush LSN” which by definition, points to the next log block ID following those log records that have been written to stable media.
The next post in this series will go into detail the process of taking log backups on an ROSR. It will discuss the communication process between the primary and secondary (the messages sent back and forth), the farthest point that can be backed up on a secondary, the effects of the redo queue size on log backups as well as other
factors relating to sync status.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.