SQL Server Latch Vs Locks

SQL Server Latch VS Lock

Latch
Latches are very lightweight, short-term synchronization objects protecting actions that need not be locked for the life of a transaction. They are primarily used to protect a row when read for a connection.

Lock
Locks in SQL Server protects the tables or data pages currently used by active transactions by locking them. Locking is a concurrency control mechanism: it ensures the consistency of data across transactions. It is needed in a multi-user environment, since several users may be working with the same data at the same time.

Why do we need Latches/Locks for Database?
Latches were first introduced in SQL Server 7.0, when Microsoft first introduced row-level locking. For row-level locking it was very important to introduce a concept like latching, because otherwise it would give rise to phenomena like Lost Updates in memory.

A page in SQL Server is 8KB and can store multiple rows. To increase concurrency and performance, buffer latches are held only for the duration of the physical operation on the page, unlike locks which are held for the duration of the logical transaction. Latches are internal to the SQL engine and are used to provide memory consistency, whereas locks are used by SQL Server to provide logical transactional consistency.

When the relational engine is processing a query, each time a row is needed from a base table or index, the relational engine uses the OLE DB API to request that the storage engine return the row. While the storage engine is actively transferring the row to the relational engine, the storage engine must ensure that no other task modifies either the contents of the row or certain page structures such as the page offset table entry locating the row being read. The storage engine does this by acquiring a latch, transferring the row in memory to the relational engine, and then releasing the latch.

SQL Server Performance Monitor has a Latches object that indicates how many times latches could not be granted immediately and the amount of time threads spent waiting for latches to be granted.

Latches are often confused with locks, as their purposes are similar but not the same. A latch can be defined as an object that ensures data integrity on other objects in SQL Server memory, particularly pages. They are a logical construct that ensures controlled access to a resource and isolationism when required for pages in use. In contrast to locks, latches are an internal SQL Server mechanism that isn't exposed outside the SQLOS.

While locks protect data during transactions, another process, latching, controls access to physical pages. Latches are very lightweight, short-term synchronization objects protecting actions that do not need to be locked for the life of a transaction. When the engine scans a page, it latches the page, reads the row, gives it back to the relational engine, and then unlatches the page again so another process can reach the same data. Through a process called lazy latching, the storage engine optimizes access to the data pages by releasing latches only when a page is also requested by another ongoing process. If no ongoing process requests the same data page, a single latch remains valid for the entire operation on that page.

Latching
SQL Server uses latches to provide data synchronization. A latch is a user-mode reader-writer lock implemented by SQL Server. Each data page in memory has a buffer (BUF) tracking structure. The BUF structure contains status information (Dirty, On LRU, In I/O) as well as a latch structure.

Locking maintains the appropriate lock activity; latching controls physical access. For example, it is possible for a lock to be held on a page that is not in memory. The latch is only appropriate when the data page is in memory (associated with a BUF).

The following list describes the different types of latches:

• I/O latches:
I/O Latches are used by SQL Server when outstanding I/O operations against pages in the Buffer Pool are done – when you read and write from/to your storage subsystem. For these I/O latches SQL Server reports a wait type that starts with PAGEIOLATCH_.
You can see the waiting times introduced with these types of latches in the DMV sys.dm_os_wait_stats.

• Non-buffer (Non-BUF) latch:
The non-buffer latches provide synchronization services to in-memory data structures or provide re-entrance protection for concurrency-sensitive code lines. These latches can be used for a variety of things, but they are not used to synchronize access to buffer pages.
- SQL Server also reports these latches in the DMV sys.dm_os_wait_stats with wait types starting with LATCH_.

• Buffer (BUF) latch:
The buffer latches are used to synchronize access to BUF structures and their associated database pages. The typical buffer latching occurs during operations that require serialization on a buffer page, (during a page split or during the allocation of a new page, for example). These latches are not held for the duration of a transaction.
- SQL Server also reports the waits introduced by these latches with wait types starting with PAGELATCH_*. These wait types are again reported to you through the DMV sys.dm_os_wait_stats.

SQL Server Cluster Network Name Resource ‘SQL Network Name’ Failed Issue

Issue
Today will discuss about the issue that I’ve encountered during performing an installation of a SQL Server failover cluster is “The cluster resource ‘SQL Server (MSSQLSERVER)’ could not be brought online due to an error bringing the dependency resource ‘SQL Network Name (MSSQL2012)’ online.” Upon checking the cluster events in the Failover Cluster Manager, you will find the below error.

Cluster network name resource 'SQL Network Name (MSSQL2012)' 
failed to create its associated computer object in domain 'ENTERPRISE.ORG' for the following reason: 
Resource online.
The associated error code is: -1073741790
Please work with your domain administrator to ensure that:
- The cluster identity 'WIN2012$' can create computer objects. 
By default, all computer objects are created in the 'Computers' container; consult the domain 
administrator if this location has been changed.
- The quota for computer objects has not been reached.
- If there is an existing computer object, 
verify the Cluster Identity ' WIN2012$' has 'Full Control' permission to that computer object 
using the Active Directory Users and Computers tool.

Lets first understand, what is Cluster Name Object (CNO)?
In a Windows Server Failover Cluster, a cluster name object (CNO) is an Active Directory (AD) account for a failover cluster.

A CNO is automatically created during cluster Setup. When the administrator creates a failover cluster and configures clustered services or applications, the "Create Cluster Wizard" creates all the Active Directory computer accounts the failover cluster requires and gives each account specific permissions. The wizard also creates a computer account for the failover cluster itself; this account is called the cluster name object.

The CNO is important because other accounts are created through it. If the CNO is deleted or permissions for the account are changed, other computer accounts required by the cluster can't be created until the CNO and correct permissions are restored.

Beginning with Windows Server 2012, both the Create Cluster Wizard and the PowerShell cmdlet New-Cluster allow administrators to decide which organizational unit (OU) should contain the CNO.

There are basically two solution of this problem:

1. One resolution is a preventative action that can be done prior to beginning the installation of the SQL Server Failover Cluster, and
2. Second resolution is after the issue experienced during installation to be able to continue.
Both resolutions require access and permissions to AD.

Resolution
1. The resolution that will prevent this issue on future installations is to “pre-stage” the VCO.

- Log in as a user with permissions to create computer objects in the domain.
- Under Active Directory Users and Computers, create a “New Computer” object within the desired AD Container for the VCO (this will be your SQL Server Network Name).
- Once the object has been created, you can then add the CNO (this will be your WSFC Name) to the security of the VCO with “Full Control” over the VCO.

2. To achieve the resolution that will be reactive for your current errors, you need to grant the proper permissions to the CNO.

- Log in as a user with administrative permissions in the domain.
- Under Active Directory Users and Computers, grant the CNO (this will be your WSFC Name) “Create Computer Objects” permissions.

After doing this, you can retry your previously failed installation, and it should be successful. To verify if this issue was corrected, you can navigate within the SQL Server (MSSQLSERVER) Cluster group and attempt to bring the Server Name resource online.
If the resource is able to be brought online successfully and thats it!!