网站开发话术,合同管理软件系统,网站中用特殊字体,网站建设实现用户登录开头还是介绍一下群#xff0c;如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,SQL Server#xff0c;Redis #xff0c;Oracle ,Oceanbase 等有问题#xff0c;有需求都可以加群群内有各大数据库行业大咖#xff0c;CTO#xff0c;可以解决你的问题。加群请加微信号 l… 开头还是介绍一下群如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,SQL ServerRedis Oracle ,Oceanbase 等有问题有需求都可以加群群内有各大数据库行业大咖CTO可以解决你的问题。加群请加微信号 liuaustin3 共1250人左右 1 2 3 4新人会进入3群 3群准备关闭自由申请 每天感悟 好像现代人不焦虑就不正常为了孩子为了身体为了工作为了钱财为了每天安全的食品焦虑是每天的必修课焦虑中饱含希望一切都按照自己的想法运转自己仿佛是宇宙的中心为什么就不能按我心意如意如意麻烦醒醒你脚离地了。 SQL SERVER 好久没有写了偶然有人问SQL SERVER 的UNDO REDO 怎么实现的因为这些人不曾听说SQL SERVER 有 autovacuum ,vacuum 也不曾听说 SQL SERVER 有UNDO 表空间REDO 日志到底SQL Server是怎么实现传统数据库中需要的前滚翻和后滚翻我们今天看看到底SQL SERVER 和那个数据库有近亲关系。 首选需要确认的SQL SERVER 的确没有和ORACLE 以及MYSQL 同流合污走了UNDO 表空间的这条路也没有和PostgreSQL 一样将UNDO 深藏在每个自己的表内他走的是完全依靠日志的的这条路。 在SQL SERVER 中饱含了数据文件MDF NDF以及SQL SERVER 最硬核的日志LDF 文件而 LDF 文件承载了SQL SERVER 的 REDO ,UNDO 的两个数据库核心功能的实现。 首先我们需要确认一个前提无论那种数据库的WAL write ahead log 都是顺序的有时间性和顺序性在确认这点后我们就可以很少的解释SQL SERVER 到底怎么单纯通过日志就可以完成那些数据库通过日志无法完成的 UNDO 。 这里需要说明SQL SERVER LDF 文件本身是被切成多个VLF 块的而这些块有正在被使用的也有还未激活的整体的日志VLF 是循环使用每个VLF 中会写事务的日志每个日志占用512bytes 到 60KB 不同大小的来记录每个事务的工作。 这里会对不同的日志块进行标记那些那些事务是活跃的而那些是已经提交的。当一个VLF 写满后就开启下一个VLF 来继续写日志所以SQL SERVER 的日志是一个非常复杂的结构。 那么SQL SERVER 回滚需要做的就是将ACTIVE 的事务日志block进行反向翻译然后执行就可以得到事务的回滚。下图中事务1 事务2都是并行运行的当事务1发生问题进行回滚举例 事务1中为 insert into table 而产生回滚则会产生反向语句 delete from table where XXXX. 所以通过一个逆向的操作将正向的操作抵消掉。同时每个事务自身也有自己的序号LDF 日志中通过 VLF 分块然后每个事务占用VLF 中的 512 bytes 或 60KB 来记录事务而其中会标记 1 事务的commit 还是uncommit 2 事务中的log block 顺序号 3 事务中 log block 中的事务详细执行的每一步的顺序 4 数据中操作修改的字段的值 所以SQL SERVER LDF 日志文件中如果回滚将从原有的日志中获取倒序的执行顺序执行的值等信息产生逆向操作后直接执行日志即可数据库的操作可以随时进行rollback。这里与其他的数据库 ORACLE ,MySQL , PostgreSQL 的实现方式均不同UNDO 的整体操作都在日志中完成。 这里小结一下SQL SERVER 日志中饱含的信息 1 每个事务的是否活跃的信息标志 2 每个事务的序号 3 每个事务内部的序号 4 事务终止标志 5 回滚标志位 -- 反向事务日志 6 CheckPoint 标记位 通过这个SQL SERVER 事务的了解也就明白如果有一个长事务不进行commit 则SQL SERVER 的LDF 文件会疯狂的进行扩展无法进行回收。 同时回滚的事务较多的情况下尤其大事务则会导致回滚较慢以及LDF文件加大的问题。 通过学习也了解了三种UNDO实现的方式 SQL SERVER 是将冗余的回滚段放到了日志POSTGRESQL是将回滚的数据放到了原表ORACLE MYSQL则是单独设置了回滚段4种数据库3种实现的UNDO的方式也体现了每种数据库设计者的一些数据库设计的思路。 REDO 的实现在SQL SERVER 也更加的简单还是通过LDF 日志文件来实现在最后一次CHECKPOINT点前说明数据已经刷新到数据页面则这些日志数据无需回滚而在最后一次CHECKPOINT点标志位后的日志则说明需要进行前滚。 单这里会出现一个问题便是和POSTGRESQL 一样被DISS的 REDO 大量事务过慢的问题这里POLARDB FOR POSTGRESQL 在代码中将这部分变为了多线程的前滚模式SQL SERVER 解决这个问题开始并行REDO是在2012以后得版本当然有一些BUG不够应该FIXED 了SQL SERVER在 2019版本中又启用了ADR 新的功能。 ADR -- accelerated database recovery 其中这个新的功能中饱含了新的组件 1 PVS persistent version store -- 存储事务中修改行前一个版本的行信息2 logical revert 通过逻辑分析在事务回滚时组织好如何读取前一个版本的信息3 sLog 这个组件的信息是在内存中比如一些还为写入PVS 的行信息4 cleaner 清理PVS 中过期的行的信息 当启用ADR会在数据行中产生一个14个字节的指针当行被修改后指针指向行之前的行版本启用了ADR 后之前SQL SERVER 大事务日志无法截断和快速收缩的问题得到了解决但是会产生一个新得问题和POSTGRESQL 一样数据文件将变得大。 ALTER DATABASE [ADR] SET ACCELERATED_DATABASE_RECOVERY OFF; 这里微软官方文档明确指出如果你的应用是高频的UPDATE和 DELETE的操作数据库表则不建议开启ADR功能。 所以SQL SERVER ADR的功能和 POSTGRESQL的某些设计是不是近亲你心里应该有一个答案当然好消息是对于大事务的UNDO回滚将比以往有更快的速度。 小结在数据库的设计中UNDO REDO 的实现的方式在不同的数据库有不同的设计的方式各种数据库都在尽力的解决自身设计的缺陷并和其他数据库取长补短回到题目SQL SERVER 在有了ADR 后和POSTGRESQL是不是有近亲关系这可能还需要更深入的研究但是在LINUX 系统中各种数据库互相“拳打脚踢”的局面不同Windows server服务器的市场中SQL Server 是隔岸观火唯我独尊的状态。 最终数据库的WAR 背后的投资者还是微软和甲骨文敌人的敌人就是朋友被演绎的淋漓尽致。 参考文字 https://techcommunity.microsoft.com/t5/sql-server-blog/sql-server-2016-2017-availability-group-secondary-replica-redo/ba-p/385905
