[SQL Server] memory cache data is written to disk (a) of the Rings

Few solid practical behavior inside the SQL Server Database Engine, the recent discovery of a customer's performance bottlenecks may Transaction log of I / O, while the other one customer save manufacturers are importing remote replication (DR site) solutions (not intended for the use AlwaysOn to off-site), due to the protection of disk resources, we need to ensure consistency mdf on the disk, ndf and ldf's.

To note Buffer Flush To Disk reading experience and SQL2012 / 2014 / SQL2016 related to ancient and new new features.


Maintain the integrity of ACID (Atomicity) and persistent (Durability)

In order to maintain the important mission of relational database ACID, SQL Server uses a transaction record (Transaction log) to achieve integrity A tomicity and persistence ( D urability), here briefly explain the integrity of the A tomicity and persistence ( D urability):

  • Integrity A tomicity: transaction must be completed execution, or else all is not executed. 
  • Persistent ( D urability): After the transaction is complete, and its role will never exist in the system.

In order to have a fast I / O performance, update the database data, SQL Server will first update the data files and log files in Buffer Pool (also known as Buffer cache), that is, the memory cache area, and in order to ensure the integrity and long-lasting sex, Commit a transaction is completed, it isBuffer Pool will be written in Log Flush to Disk as confirmation, Which is the Write-Ahead log (WAL) , make sure to save disk log correctly (this is similar to synchronized approval of AlwaysOn).

Because the data page (Data Page) is still on the Buffer Pool, at this time if the server where the SQL Server memory exception occurs, as long as the Transaction log disk file (.ldf) correct, DataBase Engine can still use the Transaction Log will complete ReDo and UnDo Disk mdf on / ndf fileRecover or restore correct

* If the direct synchronization mdf, ndf and ldf offsite room (DR Site), may run into log (ldf) are new, but the data file (mdf ndf) or old situation.


Log point in time is written to the disk from the Buffer Pool

Transaction Log understand the previous article to be written to disk which is a point in timeCommit the transaction Ending pose, Finishing a few points of time writing to disk:

  • Transaction commit
  • log Buffer reach capacity of 60K
  • checkpoint checkpoint

Here we briefly tested before and after the transaction commit, DataBase Engine activity on the disk.

1. Create a test database, test data and test data table

CREATE DATABASE [FlushDiskDb]
 CONTAINMENT = NONE
 ON  PRIMARY 
( NAME = N'FlushDiskDb', FILENAME = N'C:tempdbFlushDiskDb.mdf' , SIZE = 5120KB , FILEGROWTH = 1024KB )
 LOG ON 
( NAME = N'FlushDiskDb_log', FILENAME = N'C:tempdbFlushDiskDb_log.ldf' , SIZE = 2048KB , FILEGROWTH = 10%)
GO

USE [master]
GO
ALTER DATABASE [FlushDiskDb] SET RECOVERY FULL WITH NO_WAIT
GO

create table t1 
(
   c1 int identity,
   c2 varchar(30)
)

insert t1 VALUES('Stanley')
insert t1 VALUES('Taiwan')

2. Open the process monitor

3. Set Filter condition

Ctrl+ L Hotkey option out of Filer

Filter setting conditions: Path> Contaons> database file path

4. Create a transaction, and then Do not Commit

use FlushDiskDb

BEGIN tran tran_one 
 update t1 
    set c2 = 'France'
 where c1 = 2 

Sure enough, the process monitor 5. In: empty!

6. However, if the transaction at this time in the final surface down commit

process monitor appeared written .ldf disk activity ! And not only mdf ldf Oh disk activity.

write-ahead log (WAL),先保证log写入磁盘来确保ACID的AD!


从Buffer Pool写入数据分页到磁盘的时间点

前面的简单练习可以理解到Log写入磁盘的时间点,也许聪明的工程师一定很快想进一步知道,数据分页写入磁盘的时间点? 从Technet的文章很快找到答案:

  • checkpoint:检查点发生
  • Lazy writer:懒惰写入器工作了(因为很懒惰,触发的机会相较checkpoint少很多)
  • Eager writing: 热切的写入器被选择,然后大量载入事务发生了(nonlogged操作的一种,这边暂时不讨论)

简单把Data Page和log buffer一起划图来表示磁盘写入流程:


检查点(CheckPoint)触发时机

这边我们先study最常发生的CheckPoint,中文是检查点,CheckPoint会将目前内存中已修改的页面 (中途分页或称Dirty Page)和事务记录资讯从内存缓存(Buffer Cache)中写入磁盘上。

Database Engine 支持几种类型的检查点:

  • 自动:SQL DataBase Engine决定,可在执行个体层级设定(recovery interval)
  • 间接:SQL Server 2012中的新功能,在数据库层级设定固定周期的检查点时间(TARGET_RECOVERY_TIME)
  • 手动: 人为的方式执行checkpoint命令
  • 系统内部: 执行数据库备份、快照、停止 SQL Server (MSSQLSERVER) 服务、SQL Server 容错移转丛集执行个体 (FCI) 离线、使用 ALTER DATABASE 加入或移除数据库文件..

我们来试试刚刚的案例,新增查询窗口,手动输入checkpoint命令!

Process monitor多了写入.mdf的磁盘活动


Checkpoint vs Lazy writer

Checkpoint和Lazy writer很类似,但Checkpoint的设计出发点是为了缩短数据库的复原时间,但Lazy writer则是为了解决内存压力,两种执行后都会将Buffer Cache的数据分页写入磁盘,但只有Lazy Writer会释放出资源。

如果也希望checkpoint释放资源,举例来说,我们需要手动再执行DBCC DROPCLEANBUFFERS命令:

CHECKPOINT;
GO
DBCC DROPCLEANBUFFERS;
GO


查询目前Buffer Pool中的数据表

我们可以透过sys.dm_os_buffer_descriptors 这个dm查询到!


USE FlushDiskDb
SELECT
	DB_NAME(buf.database_id) AS DbName
	,o.name
	,buf.* 
FROM sys.dm_os_buffer_descriptors buf
LEFT JOIN sys.allocation_units AS au WITH (NOLOCK)
	ON buf.allocation_unit_id = au.allocation_unit_id
LEFT JOIN sys.partitions AS pt WITH (NOLOCK)
	ON au.container_id = pt.hobt_id
LEFT JOIN sys.objects AS o WITH (NOLOCK)
	ON pt.object_id = o.object_id
LEFT JOIN sys.indexes AS idx WITH (NOLOCK)
	ON o.object_id = idx.object_id
		AND pt.index_id = idx.index_id
WHERE DB_NAME(buf.database_id) = db_name()
  and o.type_desc = 'USER_TABLE'

ORDER by name 

 

执行结果:

1.Checkpoint执行前: Dirty Page

2.Checkpoint执行后

3.DBCC DROPCLEANBUFFERS执行后:

今天先大致理解Buffer Pool写入磁盘的架构及时间点,周末继续笔记未完成的SQL2012/2014/2016新古和全新功能。


参考:

Writing Pages

https://technet.microsoft.com/en-us/library/aa337560(v=sql.105).aspx

数据库检查点 (SQL Server)

https://msdn.microsoft.com/zh-tw/library/ms189573(v=sql.120).aspx

原文:大专栏  [SQL Server]内存缓存数据写入磁盘(一)首部曲


Guess you like

Origin www.cnblogs.com/chinatrump/p/11505624.html
Recommended