数据库写入过程

?

  1. reserved state
    进入reserved state以后,sqlite可以修改数据库中的内容,不过把修改以后的内容写到pager的缓存里,大小由page cache指定。
    进入这个状态以后,pager开始初始化日志文件,用户回滚和异常恢复。(其实就是把日志中的文件内容拷贝到数据库文件中去)
    这种机制使得数据库在进行写操作时可以同时进行读操作。
    不过由于只有一个reservedexclusive锁,所以只能有一个写操作
  2. pending state
    从reserved到exclusive要经历一个pending state,即获取pending锁。
    pending是一个gateway lock。

    • 不会有事务从unlock状态到shared状态,保证了不会有新的读操作和写操作
    • 已经拥有shared锁的事务可以正常运行。写事务等待着这些事务的完成,释放锁。
  3. Exclusive state
    当其他所有的数据库链接都释放了锁之后,整个数据库就只有一个写操作的事务了。进入Exclusive状态。

    1. pager检查日志文件已经被写到了磁盘中,调用fsync()系统调用(如果这个系统调用挂了,SQlite也没办法)

      • 如果SYNCHRONOUS PRAGMA是默认的设置,会调用一次sync操作。
      • 如果SYNCHRONOUS PRAGMA是FULL,会调用两次sync操作
      • 如果SYNCHRONOUS PRAGMA是NONE,不会调用sync操作
    2. pager把已经修改完的内容写入数据库文件
    3. 清理日志文件,释放锁

锁实现的原理

?

SQLite锁的实现是基于标准的文件锁。SQlite在数据库文件上有三个锁,1个reserved byte,一个pending byte以及一个shared region。

  1. unlocked->shared
    获取pending byte的读锁。获取成功以后,在shared region随机获得一个byte的读锁,并释放pending byte的读锁。
  2. shared->reserved
    获取reserved byte的写锁即可。
  3. reserved->exclusive
    首先获取pending byte的写锁。
    一旦成功,那么由于pending byte已经被锁定,因此不会有unlocked->shared。
    接下来,会尝试获取整个shared region的写锁。
    由于shared region有一些被active的事务持有读锁,因此数据库会等待这些事务完成并释放锁。

恢复机制

使用reserved byte来决定是否需要恢复。
一般来说,日志文件和reserved lock是同步的,即同时出现和消失。
如果SQLite发现了日志文件,却没有发现reserved lock,那么可以认为发生了crash或系统掉电。
当pager首次打开数据库或从数据库文件读取到内存时,会做一个完整性检查。如果发现不一致(有日志文件却没有reserved lock),那么数据库进入恢复模式。此时的数据库日志文件叫做hot journal。
进入恢复模式以后,会直接从shared状态进入pending状态,如第一个图的灰线所示。这样子可以保证
1. 不会有新的数据库连接
2. shared状态的数据库连接不会进入恢复模式(实际上不会发生,因为第一个数据库连接会进入恢复模式,从而阻塞其他的数据库连接进入shared状态)

简单的说,一个hot journal就是一个implicit exclusive锁。如果写操作crash了,那么在其他数据库连接成功恢复数据库以前,数据库不会有其他操作。crash以后第一个操作数据库的pager会看到hot journal,并进行数据库恢复。

时间: 2024-10-11 08:35:51

数据库写入过程的相关文章

深入分析Elastic Search的写入过程

摘要 之前写过一篇ElasticSearch初识之吐槽,不知觉竟然过去了两年了.哎,时光催人老啊.最近又用到了ES,想找找过去的总结文档,居然只有一篇,搞了半年的ES,遇到那么多的问题,产出只有这么点,真是说不过去啊.只好又重新捡起ES,发现ES槽点依然很多,不兼容的更新太多了,各个版本之间的差异不小,感觉ES就是偏理论算法的人设计出来的,而不是工程学家写的.非常像公司里面,算法工程师吐槽后端应用开发算法能力弱,后端应用开发吐槽算法工程师工程能力太差.作为一个应用开发对ES差不多就是这种感觉.不

你所不知道的SQL Server数据库启动过程(用户数据库加载过程的疑难杂症)

前言 本篇主要是上一篇文章的补充篇,上一篇我们介绍了SQL Server服务启动过程所遇到的一些问题和解决方法,可点击查看,我们此篇主要介绍的是SQL Server启动过程中关于用户数据库加载的流程,并且根据加载过程中所遇到的一系列问题提供解决方案. 其实SQL Server作为微软的一款优秀RDBMS,它启动的过程中,本身所带的那些系统库发生问题的情况相对还是很少的,我们在平常使用中,出问题的大部分集中于我们自己建立的用户数据库. 而且,相对于侧重面而言,其实我们更关注的是我们自己建立的用户数

C# 文件与二进制互转数据库写入读出

//这个方法是浏览文件对象 private void button1_Click(object sender, EventArgs e) { //用户打开文件浏览 using (OpenFileDialog dialog = new OpenFileDialog()) { //只能单选一个文件 dialog.Multiselect = false; //选择一个文件 if (dialog.ShowDialog() == DialogResult.OK) { try { //把选择的文件路径给tx

5. 用自己的语言描述一下程序连接数据库的过程。

在ASP.NET数据库连接中,通过Web.config,你可为使用 ﹤appSettings﹥ 标记,在这个标记中,你可用 ﹤add ... /﹥ 标记定义0到多个设置.本文中我们主要讨论了如何使用web.config来配置一个web应用程序中的数据库连接. web.config文件是标准的xml文件,我们可以使用它来为一台机器下的每一个web应用程序或某个应用程序或一个目录下的asp.net页面来进行设置,当然,它也可以为一个单独的web页面进行设置. 一.通过ODBC DSN建立连接 运用O

用自己的语言描述一下程序连接数据库的过程?

1.Access数据库的DSN-less连接方法:set adocon=Server.Createobject("adodb.connection")adoconn.Open"Driver={Microsoft Access Driver(*.mdb)};DBQ="& _Server.MapPath("数据库所在路径")  2.Access OLE DB连接方法:set adocon=Server.Createobject("a

用自己的语言描述一下程序连接数据库的过程。

一.通过ODBC DSN建立连接 运用ODBC数据源,首先必须在控制面板的ODBC中设置数据源,然后再编写脚本和数据库源建立连接. 1.创建 ODBC DSN     通过在 Windows 的"开始"菜单打开"控制面板",您可以创建基于 DSN 的文件.双击"ODBC"图标,然后选择"系统 DSN"属性页,单击"添加",选择数据库驱动程序,然后单击"下一步".按照后面的指示配置适用于您

MySQL数据库恢复过程

MySQL数据库恢复过程 某客户更新数据的时候,误删了数据库的内容,因为数据库做了主从,但是没有做备份(备份很重要啊!)幸好开启了bin-log.之后只好把整个日志的记录拿回来本地进行恢复.之后自己也做了一个简单的测试,对数据进行恢复,具体如下: binlog是什么? binlog日志用于记录所有更新且提交了数据或者已经潜在更新提交了数据(例如,没有匹配任何行的一个DELETE)的所有语句.语句以"事件"的形式保存,它描述数据更改 1.新建一个表 CREATE TABLE `lynn`

sql学习笔记(18)-----------数据库创建过程

手动创建数据库的步骤: 第一步:决定数据库实例的SID 数据库实例的SID用来将当前实例和以后可能创建的实例进行区分 % setenv ORACLE_SID mynewdb 第二步:建立数据库管理员认证方法 第三步:创建初始化參数文件 实例(由内存结构SAG和后台进程组成)启动过程中要读取初始化參数文件.得到初始化參数文件的一个好办法是改动一个已有的初始化參数文件.为了简化操作,将初始化參数文件放在Oracle默认的位置上.这种话.当数据库启动时,就没有必要再指定pfile參数了.由于Oracl

你所不知道的SQL Server数据库启动过程,以及启动不起来的各种问题的分析及解决技巧(转)

目前SQL Server数据库作为微软一款优秀的RDBMS,其本身启动的时候是很少出问题的,我们在平时用的时候,很少关注起启动过程,或者很少了解其底层运行过程,大部分的过程只关注其内部的表.存储过程.视图.函数等一系列应用方式,而当有一天它运行的正常的时候突然启动不起来了,这时候就束手无策了,能做的或许只能是重装.配置.还原等,但这一个过程其实是一个非常耗时的过程,尤其当我们面对是庞大的生产库的时候,可能在这火烧眉毛的时刻,是不允许你再重搭建一套环境的. 所以作为一个合格的数据库使用者,我们要了