SQLServer 隔离级别的简单学习

SQLServer 隔离级别的简单学习

---

背景

上周北京一个项目出现了卡顿的现象。
周末开发测试加紧制作测试发布了补丁，但是并没有好转。
上周四时跟研发訾总简单沟通过， 怀疑是隔离级别有关系。但是不敢确认。
因为现场是SQLServer数据库。前期出现过一些问题。
同部门的杨老师也一直问我要不要SQLServer修改默认的隔离级别。
研发戴老师找MicroSoft开Case使用dbcc等工具进行了研判。
我这边在群里一直看大家的反馈， 不太想直接反馈自己的建议。担心出现误导。

周一下午再次出现问题后，没有忍住，在群里咨询了隔离级别的问题。
事业部性能负责人肖总给出问题计划进行隔离级别的切换。
我这里想简单总结与复盘一下这次事故。也是对自己的之前一直比较不太关注的一个总结。

---

修改隔离级别的语法

这里直接复制公司的文档：
这里希望增加一点的事，建议有条件的项目进行一次数据库的重启，释放部分连接
并且进行一次数据库的全库备份操作，避免出现数据丢失和异常。

对于MSSQL数据库默认是不启用快照隔离的，一旦事务没有及时提交会影响其他进程的读操作，
造成数据库阻塞。

--查询数据库状态
select name,user_access,user_access_desc,
   snapshot_isolation_state,snapshot_isolation_state_desc,
   is_read_committed_snapshot_on
from sys.databases
GO

--如果对应的 snapshot_isolation_state_desc =OFF ，需要使用以下命令启用
---sa登录启用指定数据库的快照隔离将 [dbName]  替换为具体的cwbase001 数据库

ALTER DATABASE [dbName] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
ALTER DATABASE [dbName] SET ALLOW_SNAPSHOT_ISOLATION ON
GO
ALTER DATABASE [dbName] SET READ_COMMITTED_SNAPSHOT ON
GO
ALTER DATABASE [dbName] SET MULTI_USER
GO

---

关于此快照级别的理解-这一段的理解不一定对

Oracle和SQLSERVER的默认隔离级别都是 Read Commited
但是两者有一个区别。
Oracle数据库是通过undo段，对每一个事务提交之前做一个记录信息。
Oracle的DML并不会阻塞select， 他可以根据事务的时间，自动从undo段中截取合适的数据版本
所以理论上Oracle第一次查询和第二次查询的结果可能不一致，会出现不可可重复读的问题。 

SQLSERVER 默认情况下是不开机快照隔离的，DML语句的提交之前可能会阻塞其他事务的查询语句。
因为很多查询语句是下一步处理的必备条件，阻塞到了查询语句，就会导致后面的操作无法有效进行
出现比较严重的性能问题。 

SQLSERVER打开快照隔离， 在SQLSERVER2019之前的版本，会在tempDB里面创建类似于Oracle undo表空间
的效果。能够实现在tempdb 中读取未提交事务之前的行版本信息。
通过这种方式来避免LCK_M_U

---

关于缺点

Oracle的undo和SQLServer的tempdb都是数据库核心的关键存储。
理论上应该尽量少去使用，避免出现性能瓶颈。
必须开启的情况下。可能会导致出现大量的读写，导致性能下降。
理论上tempdb和undo 以及 redo 应该都存储于硬件性能良好的存储上面。
提高数据库的性能。 

太多的使用和频繁的读写可能会导致TPS下降，以及数据库的损坏，需要重点注意。

---

关于提高性能

更低的水位线, 更好的数据分布.
实现数据分区. 避免热数据,热数据块.
提高并发度, 提高数据库数据文件的IO性能.
提高数据库的并发能力, 使用core base 的序列号,尽可能多的发挥硬件的性能
增加redo,buffer池大小. redo tempdb masterdb 尽量分开存储.

---

关于扩展思路

十年前曾经看过阿里的Oracle的DBA的一个文章。
讲述一个系统每天早上登陆时总是特别卡顿。
原因在于。这个系统的登陆日志信息表示是按日期进行分表的。
每当刚上班时新创建的表刚开始使用，因为他的表数据比较少，所以占用的区块或者是block比较少。
oracle的insert的并发是基于区块来的， insert的并发度可能不会大于数据库已有的区块数
因为不允许同时修改同一个区块， 可能会导致数据错乱。 

随着时间的流逝，这个表越来越大区块越来越多，就能够支撑更多的并发。性能就会变好。

感觉这个问题和SQLSERVER的隔离级别问题是相似的。
虽然理论上在不同区块上面应该不会互相锁掉，但是在某些极端情况下依旧存在风险。
数据库调优的核心就是查看等待时间， 查看CBO， 查看事务的处理。
通过耗时较长的操作的定位发现问题原因进行优化。

---

跟微软聊完之后获取的信息

1. 跟语言没关系, java和.net都一样.
2. 开启快照隔离会导致tempdb增大,需要进行监控.增加预警.
3. 建议将tempdb和业务数据库进行隔离. 避免在同一个存储设备上面. 避免性能互相影响.
4. tempdb和redo一样大部分是顺序写, 但是需要注意数据的大小和未提交事务对性能的影响.

---

一些资料

Oracle中的隔离级别及实现机制:
　　在Oracle中，没有Read Uncommitted及Repeatable Read隔离级别，这样在Oracle中不允许一
个会话读取其他事务未提交的数据修改结果，从而避免了由于事务回滚发生的读取错误。Oracle中的
Read Committed和Serializable级别，其含义与SQL Server类似，但是实现方式却大不一样。

　　在Oracle中，存在所谓的回滚段(Oracle9i之前版本)或撤销段(Oracle9i版本)，Oracle在修改
数据记录时，会把这些记录被修改之前的结果存入回滚段或撤销段中，就是因为这种机制，Oracle对
于事务隔离级别的实现与SQL Server截然不同。在Oracle中，读取操作不会阻碍更新操作，更新操作
也不会阻碍读取操作，这样在Oracle中的各种隔离级别下，读取操作都不会等待更新事务结束，更新
操作也不会因为另一个事务中的读取操作而发生等待，这也是Oracle事务处理的一个优势所在。

　　Oracle缺省的设置是Read Committed隔离级别(也称为语句级别的隔离)，在这种隔离级别下，
如果一个事务正在对某个表进行DML操作，而这时另外一个会话对这个表的记录进行读取操作，则
Oracle会去读取回滚段或撤销段中存放的更新之前的记录，而不会象SQL Server一样等待更新事务的
结束。

　　在Serializable隔离级别(也称为事务级别的隔离)，事务中的读取操作只能读取这个事务开始之
前已经提交的数据结果。如果在读取时，其他事务正在对记录进行修改，则Oracle就会在回滚段或撤
销段中去寻找对应的原来未经更改的记录(而且是在读取操作所在的事务开始之前存放于回滚段或撤销
段的记录)，这时读取操作也不会因为相应记录被更新而等待。

---

一些资料2

SQLSERVER的隔离级别以及实现机制：
    Read Committed

　　这是SQL Server的缺省隔离级别，设置为这种隔离级别的事务只能读取其他事务已经提交的更新
结果，否则，发生等待，但是其他会话可以修改这个事务中被读取的记录，而不必等待事务结束，显
然，在这种隔离级别下，一个事务中的两个相同的读取操作，其结果可能不同。

　　Read Repeatable

　　在一个事务中，如果在两次相同条件的读取操作之间没有添加记录的操作，也没有其他更新操作导
致在这个查询条件下记录数增多，则两次读取结果相同。换句话说，就是在一个事务中第一次读取的记
录保证不会在这个事务期间发生改变。SQL Server是通过在整个事务期间给读取的记录加锁实现这种
隔离级别的，这样，在这个事务结束前，其他会话不能修改事务中读取的记录，而只能等待事务结束，
但是SQL Server不会阻碍其他会话向表中添加记录，也不阻碍其他会话修改其他记录。

　　Serializable

　　在一个事务中，读取操作的结果是在这个事务开始之前其他事务就已经提交的记录，SQL Server
通过在整个事务期间给表加锁实现这种隔离级别。在这种隔离级别下，对这个表的所有DML操作都是不
允许的，即要等待事务结束，这样就保证了在一个事务中的两次读取操作的结果肯定是相同的。