设为首页 收藏本站
查看: 1381|回复: 0

[经验分享] 01. SQL Server 如何读写数据

[复制链接]

尚未签到

发表于 2015-6-28 19:32:20 | 显示全部楼层 |阅读模式
  一. 数据读写流程简要
SQL Server作为一个关系型数据库,自然也维持了事务的ACID特性,数据库的读写冲突由事务隔离级别控制。无论有没有显示开启事务,事务都是存在的。流程图如下:
DSC0000.jpg
数据读写流程图
  0. 事务开始
(1) 所有DML语句必然是基于事务的,如果没有显式开启事务,即手动写下BEGIN TRAN,SQL Server则把每条语句作为一个事务,并自动提交事务。
  也就是说SQL SERVER 默认不开启隐式事务,这点与ORACLE正好相反,ORACLE默认开启了隐式事务,每条DML语句或者语句块,都要手动commit才会提交。
  SQL Server里如要改变这个默认行为,可以在会话里做如下设置,如果没有打开隐式事务,SQL Server会自动提交当前的DML语句,而打开后,需要手动COMMIT才会提交。



--开启隐式事务
SET IMPLICIT_TRANSACTIONS ON
--插入一条记录
CREATE TABLE TEST_TRAN(ID INT)
INSERT INTO TEST_TRAN VALUES(1)
--查看开启的事务
DBCC OPENTRAN()
  (2) 如果手动开启了一个事务(BEGIN TRAN),则和开启隐式事务(SET IMPLICIT_TRANSACTIONS ON)一样,需要手动提交事务(COMMIT);
  1. 发起DML
(1) DML通常指的是:INSERT、DELETE、UPDATE;
(2) DDL语句最终是被转化为对系统表的DML,在SQL SERVER中DDL语句也可以被回滚,比如:CREATE/ALTER/DROP/TRUNCATE,在ORACLE里是不可以的,另外SQL Server中的DCL语句:DENY,REVOKE,也可以被回滚;
  2. 数据是否在内存
(1) 在内存中使用HASH算法查找数据,如果找到数据那么记为逻辑读;
(2) 如果数据页不在内存中,则需要从磁盘上的数据文件中,读取相应的数据页到内存中,即物理读,物理读也会被记数为逻辑读,也就是说无论内存中有没有数据,逻辑读是一定有的。
  3. 修改数据
(1) 在SQL SERVER内存的数据缓冲区中将数据页修改,此时数据页称为脏页(DIRTY PAGE);
(2) 在SQL SERVER内存的日志缓冲区中记录REDO LOG,姑且称为脏日志;
  4. 事务结束
(1) 提交(COMMIT),此时将当前事务的脏日志刷新到数据库的日志文件中,并打上事务结束标记(COMMIT),脏页有可能暂未被刷新到数据文件;
事务日志结构如下(可通过log explorer等类似工具查看):
BEGIN TRAN
DML
COMMIT TRAN
  (2) 回滚(ROLLBACK),此时读REDO LOG得到反向DML操作,反向修改脏页,正向的DML+反向DML都会被记录在数据库的日志文件中,并打上事务结束标记(ROLLBACK),同样,脏页有可能暂未被刷新到数据文件;
事务日志结构如下:
BEGIN TRAN
DML
反向DML
ROLLBACK TRAN
  不难发现,SQL SERVER的日志容易成为一个瓶颈(BOTTLENECK),因为在写的同时引入了读,即引入了竞争,而ORACLE用UNDO SEGMENT很好地避免了这个问题,REDO LOG永远只是在被串行写。
  5. 刷新数据页
(1) SQL Server数据库遵循预写日志(WAL:Write-Ahead Logging)原则,因为关系型数据库是基于事务的,而日志正是事务ACID属性的保证,也是数据恢复的保证;
(2) 检查点(CHECKPOINT),检查点周期性地将脏页刷新到数据文件中,最终在日志文件打上检查点标记(CHECKPOINT),至此上面事务中修改的数据被正式写到磁盘上的数据文件中。
  二. 数据读写流程深入
试想:
(1) 日志是不是一定要在COMMIT后才写到日志文件?如果有个很长很大的事务,那么提交日志时,日志从缓冲区被写入磁盘,岂不是要等很久?
(2) 数据是不是一定要在日志提交后,发生了CHECKPOINT,才写到数据文件?如果日志一直没提交,那么数据缓冲区岂不是很拥挤?
  考虑到这2点,SQL Server还会通过Log Writer/Lazy Writer不定时的刷新日志/数据到磁盘,至于日志和数据的一致性,在启动或者数据库还原时,SQL Server会去做检查,也即是我们常说的前滚(REDO)和回滚(UNDO)。
DSC0001.jpg
数据读写体系结构图
  
0. SQL SERVER MEMORY
(1) SQL SERVER占用服务器内存的一部分,非SQL SERVER占用的内存,供操作系统及服务器上其他应用程序使用;
(2) SQL SERVER内存对象可分为两大类,图中仅标出Buffer Pool中的数据及日志缓存;
  1. 事务结束
(1) 事务结束的前提是日志缓存成功写入到日志文件中,也就是说客户端收到COMMIT/ROLLBACK语句运行成功的消息时,日志已被成功写入日志文件(数据还不定是否被写入数据文件);
(2) 不过,日志缓存并不是一定要等到事务结束时才刷新到日志文件的;
  2. LOG WRITER
(1) 当遇到长事务时,不必等到发出事务结束命令,LOG WRITER也会周期性地将脏日志刷新到日志文件,以保证用户发出COMMIT时快速响应以结束事务;
(2) 微软并没有公布SQL SERVER 除去COMMIT外,LOG WRITER将脏日志刷新到日志文件的周期,这里可以参考ORACLE的:每3秒,或者日志缓冲区1/3满;或者已经包含1M的脏日志;
  3. LAZY WRITER
(1) LAZY WRITER周期性扫描缓存(默认1s),维护自由页面(free page)列表,根据LRU算法将已刷新到磁盘的页释放;
(2) 如果是脏页,则Lazy Writer将脏页刷新到磁盘(这时事务可能还未提交),以最终将内存页释放并加入自由页面列表;
  4. CHECKPOINT
(1) CHECKPOINT同LAZY WRITER一样也会刷新脏页到数据文件中(只刷新已提交的事务数据),但不会维护内存自由页面列表;
(2) 可以设置SP_CONFIGURE ‘RECOVERY INTERVAL’选项来改变CHECKPOINT发生的频率,默认为1分钟一次。
  小结:可以发现,数据和日志被写入数据/日志文件,并不是同步的。有可能写入/提交了日志,数据没有写入磁盘;有可能写入了数据,事务未被提交;
(1) 针对有完整事务日志,数据未被写入磁盘的情况,启动/还原数据库时,SQL SERVER做前滚(REDO);
(2) 针对有数据写入数据文件,日志未完整提交的事务,启动/还原数据库时,SQL SERVER做回滚(UNDO)。
  

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-81325-1-1.html 上篇帖子: asp.net(c#)实现从sql server存取二进制图片 下篇帖子: 《Microsoft Sql server 2008 Internals》读书笔记--第六章Indexes:Internals and Management(7
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表