Database Research & Development

  • Home
  • NoSQL
    • NoSQL
    • Cassandra
  • Databases
    • Database Theory
    • Database Designing
    • SQL Server Coding Standards
    • SQL Server
    • PostgreSQL
    • MySQL
    • Greenplum
    • Linux
  • Interviews
    • SQL Server Interviews
    • MySQL Interviews
    • SQL Puzzles
  • DBA Scripts
    • SQL Server DBA Scripts
    • PostgreSQL DBA Scripts
    • MySQL DBA Scripts
    • Greenplum DBA Scripts
  • Home
  • Blog Archives !
  • (: Laugh@dbrnd :)
  • Contact Me !
sqlserverinterviews
Home 2017 January SQL Server: Important Discussion about the Latches

SQL Server: Important Discussion about the Latches

This article is half-done without your Comment! *** Please share your thoughts via Comment ***

In the previous series of the articles, I have shared details about the locking and deadlocking of the SQL Server.

In this post, I am going share similar details, but this is going to be a very important discussion about the SQL Server Latches.

What is Latche in the SQL Server?

Previously SQL Server Professionals are facing problem like Lost Updates in which two transactions are unaware about the each other and last transaction overwrites the transaction updated by the first transaction.
Now SQL Server has power of row-level locking in which Latching is playing the main role.

Latches are lightweight internal structures which ensure the physical data integrity. It is performing like the thread synchronization.

When we are reading a particular data page, internally that data page is moved from disk to memory buffer pool area and it creates a require structures for its execution like memory allocation, page modification details, remark about the dirty page and others.

During this process, it will create one or more Latches to prevent corruption by the other threads.
If multiple threads are going to update data into the same page, Latches creates an exclusive lock for all rows.
A data page can only be latched while it is in memory.

Once the data page is modified in memory and written back to the disk, the Latches will be released and other threads will be able to access that data page and memory structure again.

The latching can also be used with Read-Ahead in which reading operation moves data page from disk to memory and Latches prevents further modification on that data page.

The important note is:
SQL DBA doesn’t have any control on Latches because internally SQL Server controls the utilization of the Latches.
But DBA can monitor the different wait types related to Latches and can take the steps for performance optimization.

Three different types of Latches:

IO Latches: It makes sure that all I/O operations are done and should not be executed multiple times while reading and writing same data page into a disk and buffer pool.

Buffer Latches:
It protects the pages into the buffer pool from the concurrent running threads.

Non-Buffer Latches: It protects the shared data structures of the buffer pool.

The different between Locks and Latches:

Locks ensure that same record cannot be modified by two different connections and Latches ensure that record resides in a proper data page for further reading and writing operation.

Locks provide a consistency of logical transaction and Latches provide a consistency of the memory area.

The DBA can control and manage database locks by applying different Isolation Levels and for Latches, DBA doesn’t have any control because it’s managed by the SQL Server.

Jan 6, 2017Anvesh Patel
PostgreSQL: Rebuild all Indexes using REINDEXDB utility and REINDEX commandSQL Server: Get the Latches Usage and Information (sys.dm_db_index_operational_stats)
Anvesh Patel
Anvesh Patel

Database Engineer

January 6, 2017 SQL ServerAnvesh Patel, buffer pool, database, database research and development, dbrnd, Latches, Locks, SQL Query, SQL Server, SQL Server Administrator, SQL Server Monitoring, SQL Server Performance Tunning, SQL Server Tips and Tricks, TSQL
About Me!

I'm Anvesh Patel, a Database Engineer certified by Oracle and IBM. I'm working as a Database Architect, Database Optimizer, Database Administrator, Database Developer. Providing the best articles and solutions for different problems in the best manner through my blogs is my passion. I have more than six years of experience with various RDBMS products like MSSQL Server, PostgreSQL, MySQL, Greenplum and currently learning and doing research on BIGData and NoSQL technology. -- Hyderabad, India.

About DBRND !

dbrnd

This is a personal blog (www.dbrnd.com).

Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated.

Feel free to challenge me, disagree with me, or tell me I’m completely nuts in the comments section of each blog entry, but I reserve the right to delete any comment for any reason whatsoever (abusive, profane, rude, or anonymous comments) - so keep it polite.

The content of this website is protected by copyright. No portion of this website may be copied or replicated in any form without the written consent of the website owner.

Recent Comments !
  • Anvesh Patel { Sure will do... } – May 27, 12:43 PM
  • Anvesh Patel { Great... } – May 27, 12:41 PM
  • Anvesh Patel { Great... } – May 27, 12:39 PM
  • Anvesh Patel { Great... } – May 27, 12:36 PM
  • Anvesh Patel { Great... } – May 27, 12:28 PM
  • Anvesh Patel { Great... } – May 27, 12:27 PM
  • Anvesh Patel { Great... } – May 27, 12:16 PM
  • Older »
Follow Me !
  • facebook
  • linkedin
  • twitter
  • youtube
  • google
  • flickr
© 2015 – 2019 All rights reserved. Database Research & Development (dbrnd.com)
Posting....