精华内容
下载资源
问答
  • 数据库原理 具有检查点的恢复技术

    千次阅读 2020-03-12 17:09:00
    1、为什么需要检查点? 搜索整个日志文件需要耗费的...3、检查点记录的内容有哪些? 建立检查点时刻,所有正在执行的事务清单 这些事务最近一个日志记录的地址 4、重新开始文件的内容有哪些? 记录各个检查点...

    1、为什么需要检查点?

    • 搜索整个日志文件需要耗费的时间很多
    • 重做处理,重新执行,耗费了大量的时间

    2、解决方案是什么?

    • 在日志文件中增加检查点(check point)记录
    • 增加重新开始文件
    • 恢复子系统在登录日志文件期间动态的维护日志

    3、检查点记录的内容有哪些?

    • 建立检查点时刻,所有正在执行的事务清单
    • 这些事务最近一个日志记录的地址

    4、重新开始文件的内容有哪些?

    记录各个检查点记录在日志文件中的地址

    5、动态维护日志文件的方法有哪些?

    7、利用检查点的恢复策略?

    8、恢复步骤

    从重新开始文件中找到最后一个检查点记录在日志文件中的地址,由该地址在日志文件中找到检查点记录

    由该检查点记录得到该检查点建立时刻所有正在执行的任务清单ACTIVE-LIST

    建立两个事务队列 UndoList和RedoList刚开始两个队列均为空

    把ACTIVE-List暂时放入UndoList,然后将其中提交了的事务放入RedoList

    先对UndoList执行Undo操作,接着对RedoList执行Redo操作

     

     

    展开全文
  • 10.5恢复策略 10.5.1事务故障的恢复 ...对该事务的刚更新操作执行逆操作,即将日志记录中更新前的值写入数据库          插入操作:“更新前的值”为空,则相当于做删除操作          删

    关注公众号凡花花的小窝,收获更多的考研计算机专业编程相关的资料
    10.5恢复策略
    10.5.1事务故障的恢复
    事务故障:事务在运行到正常终止点前被终止
    恢复方法
        由恢复子系统利用日志文件撤销UNDO此事务已经对数据库进行的修改
         事务故障的恢复由系统自动完成,对用户是透明的,不需要用户干预
    事务故障的恢复步骤
        1.反向扫描文件日志(即从最后向前扫描日志文件),查找该事务的更新操作
        2.对该事务的刚更新操作执行逆操作,即将日志记录中更新前的值写入数据库
             插入操作:“更新前的值”为空,则相当于做删除操作
             删除操作:“更新后的值”为空,则相当于做插入操作
             如果是修改操作,则相当于用修改前的值代替修改后的值
    3.继续反向扫描日志文件,查找该事务的其他更新操作,并作同样的处理
    4.如此处理下去了,知道读到此事务的开始标记,事务故障恢复就完成了

    10.6.2系统故障的恢复
    系统故障造成的数据库不一致的状态的原因:
        未完成事务对数据库的更新可能已经写入数据库
        已经提交的事务对数据库的更新可能还留在缓冲区没有来得及写入数据库中
    恢复方法
        1.UNDO故障发生的时候没有完成的事务
        2.REDO已经完成的事务
    系统故障的恢复由系统在重新启动的时候自动完成,不需要用户的干预
    1.正向扫描日志文件(即从头扫描日志文件)
         重做(REDO)队列,在故障发生前已经提交的事务
             这些事务既有BEGIN TRANSACTION 记录,也有COMMIT记录
             撤销(UNDO)队列:故障发生的时候尚没有完成的事务
         这些事务只有BEGIN TRANACTION记录,没有相应的COMMIT记录
    2. 对撤销(Undo)队列事务进行撤销(UNDO)处理
         反向扫描日志文件,对每个UNDO事务的更新操作执行逆操作
         即将日志记录中“更新前的值”写入数据库
    3. 对重做(Redo)队列事务进行重做(REDO)处理
         正向扫描日志文件,对每个REDO事务重新执行登记的操作
         即将日志记录中“更新后的值”写入数据库
    10.5.3介质故障的恢复
         1.重装数据库
         2.重做已经完成的事务
    恢复步骤

    1. 装入最新的后备数据库副本(离故障发生时刻最近的转储副本) ,使数据库恢复到最近一次转储时的一致性状态。
      对于静态转储的数据库副本,装入后数据库即处于一致性状态
      对于动态转储的数据库副本,还须同时装入转储时刻的日志文件副本,利用与恢复系统故障的方法(即REDO+UNDO),才能将数据库恢复到一致性状态。
    2. 装入有关的日志文件副本(转储结束时刻的日志文件副本) ,重做已完成的事务。
      首先扫描日志文件,找出故障发生时已提交的事务的标识,将其记入重做队列。
      然后正向扫描日志文件,对重做队列中的所有事务进行重做处理。即将日志记录中“更新后的值”写入数据库。
      介质故障的恢复需要DBA介入
      DBA的工作
           重装最近转储的数据库副本和有关的各日志文件副本
           执行系统提供的恢复命令
      具体的恢复操作仍由DBMS完成
      小结
      事务故障的恢复
           UNDO
      系统故障的恢复
           UNDO+REDO
      介质故障的恢复
           重装后援副本+redo

    10.6具有检查点的恢复技术
         1.问题提出
         2.检查点技术
         3.利用检查点的恢复策略
    1.问题突出
    两个问题
         搜索整个日志将要耗费大量的时间
         重做处理:重新执行,浪费了大量的时间
    解决方案
    具有检查点(checkpoint)的恢复技术
         在日志文件中增加检查点记录(checkpoint)
         增加重新开始的文件
         恢复子系统在登录日志文件期间动态的维护日志
    2.检查点技术
    检查点记录内容
         建立检查点时刻所有正在执行的事务清单
         这些事务最近一个日志记录的地址
    重新开始文件的内容
         记录各个检查点记录在日志文件中的地址
    在这里插入图片描述

    动态维护日志文件的方法
    周期性地执行如下操作:建立检查点,保存数据库状态。
    具体步骤是:
        1.将当前日志缓冲区中的所有日志记录写入磁盘的日志文件上
        2.在日志文件中写入一个检查点记录
        3.将当前数据缓冲区的所有数据记录写入磁盘的数据库中
        4.把检查点记录在日志文件中的地址写入一个重新开始文件

    建立检查点
    恢复子系统可以定期或不定期地建立检查点,保存数据库状态
    定期
        按照预定的一个时间间隔,如每隔一小时建立一个检查点
    不定期
        按照某种规则,如日志文件已写满一半建立一个检查点
    三、利用检查点的恢复策略
    使用检查点方法可以改善恢复效率
    当事务T在一个检查点之前提交
    T对数据库所做的修改已写入数据库
    写入时间是在这个检查点建立之前或在这个检查点建立之时
    在进行恢复处理时,没有必要对事务T执行REDO操作
    系统出现故障时,恢复子系统将根据事务的不同状态采取不同的恢复策略
    在这里插入图片描述
    T1:在检查点之前提交
    T2:在检查点之前开始执行,在检查点之后故障点之前提交
    T3:在检查点之前开始执行,在故障点时还未完成
    T4:在检查点之后开始执行,在故障点之前提交
    T5:在检查点之后开始执行,在故障点时还未完成
    恢复策略:
    T3和T5在故障发生时还未完成,所以予以撤销
    T2和T4在检查点之后才提交,它们对数据库所做的修改在故障发生时可能还在缓冲区中,尚未写入数据库,所以要REDO
    T1在检查点之前已提交,所以不必执行REDO操作

    利用检查点的恢复步骤

        1.从重新开始文件中找到最后一个检查点记录在日志文件中的地址,由该地址在日志文件中找到最后一个检查点记录
    2.由该检查点记录得到检查点建立时刻所有正在执行的事务清单ACTIVE-LIST
        建立两个事务队列
             UNDO-LIST
             REDO-LIST
        把ACTIVE-LIST暂时放入UNDO-LIST队列,REDO队列暂为空。
         3.从检查点开始正向扫描日志文件,直到日志文件结束
    如有新开始的事务Ti,把Ti暂时放入UNDO-LIST队列
    如有提交的事务Tj,把Tj从UNDO-LIST队列移到REDO-LIST队列
         4.对UNDO-LIST中的每个事务执行UNDO操作
              对REDO-LIST中的每个事务执行REDO操作
    小结
    具有检查点的恢复技术
              为什么要引入检查点
              如何建立检查点
              利用检查点的恢复策略
    第十九讲 数据库镜像
    10.7数据库镜像
    介质故障是对系统影响最为严重的一种故障,严重影响了数据库的可用性
         介质故障恢复比较费时
         为了预防介质故障,数据库管理员必须周期性的转储数据库
    提高数据库可用性的解决方案
    数据库镜像(Mirror)
         数据库管理系统自动的把整个数据库或者其中的关键数据复制到另外一个磁盘上
        数据库管理系统自动保证镜像数据与主数据的一致性,每当主数据库更新的时候,数据库管理系统自动的把更新后的数据复制过去
    在这里插入图片描述
    数据库镜像的用途
    出现介质故障时
         可由镜像磁盘继续提供使用
         同 时DBMS自动利用镜像磁盘数据进行数据库的恢复
         不需要关闭系统和重装数据库副本(如下图所示)
    在这里插入图片描述
    没有出现故障的时候
         可以用于并发操作
         一个用户对数据加排他锁修改数据,其他用户可以读镜像数据库上的数据,而不必等待该用户释放锁
    在这里插入图片描述
         频繁的赋值数据自然会降低系统运行效率
         在实际应用中用户往往只是选择对关键数据和日志文件镜像,而不是对整个数据库进行镜像
    小结
    什么时数据库镜像
    出现介质故障的时候,数据库镜像如何保证数据
    的可用性,并恢复数据库
    没有出现介质故障的时候,数据库镜像如何提高系统并发度
    10.8 小结
    如果数据库只包含成功事务提交的结果,就说数据库处于一致性状态。保证数据一致性是对数据库的最基本的要求。
    事务是数据库的逻辑工作单位
    DBMS保证系统中一切事务的原子性、一致性、隔离性和持续性

    DBMS必须对事务故障、系统故障和介质故障进行恢复
    恢复中最经常使用的技术:数据库转储和登记日志文件
    恢复的基本原理:利用存储在后备副本、日志文件和数据库镜像中的冗余数据来重建数据库
    常用恢复技术
    事务故障的恢复
    UNDO
    系统故障的恢复
    UNDO + REDO
    介质故障的恢复
    重装备份并恢复到一致性状态 + REDO

    提高恢复效率的技术
    检查点技术
    可以提高系统故障的恢复效率
    可以在一定程度上提高利用动态转储备份进行介质故障恢复的效率
    镜像技术
    镜像技术可以改善介质故障的恢复效率

    在这里插入图片描述

    展开全文
  • 最近在alter日志发现 Checkpoint not complete 信息 产生此问题的原因具体分析: ... 系统发生检查点将出发DBWR进程将缓冲区的脏数据块写入到数据文件,同时更新数据文件的SCN号,记录联机重做日...

    最近在alter日志中发现 Checkpoint not complete 信息
    产生此问题的原因具体分析:
    首先说一下checkpoint 是什么?
    chkpoint是一个数据库的内部机制,它存在有两个目的:

    1. 保证数据的一致性
        系统发生检查点将出发DBWR进程将缓冲区中的脏数据块写入到数据文件,同时更新数据文件中的SCN号,记录联机重做日志文件中LRBA(low redo block address)的位置到控制文件中,当在写入过程中,突然实例崩溃,脏数据块没有完全写入到数据文件中。当实例启动的时候,会检查控制文件中的 终止SCN号,(四种SCN)这时候发现是空的(数据库正常运行的时候是无穷大或者保持为空),就认为数据库没有正常关闭,需要实例恢复,于是SMON进程根据控制文件中的SCN号,到重做日志文件中取出重做条目重现实例崩溃的那个状态。

    2. 数据库实例崩溃后的实例恢复
        当实例恢复的时候,到底从重做日志文件的什么位置开始恢复呢?检查点checkpoint就是记录了一个SCN号,当实例回复的时候从最近的这个检查点做恢复,不必全部恢复重做日志的内容,减少了恢复时间。

       日志切换会触发检查点,当检查点触发后会引起DBWR进程将脏数据块写入数据文件,这个时候写入数据文件的脏数据块已经都写入了联机重做日志中,是安全的,当日志缓冲区的日志写满需要切换日志文件的时候,由于下一个日志文件对应的脏数据块没有完全写入到数据文件中,所以不能被覆盖,于是就发生了Checkpoint not complete。

       这时候可能是磁盘的原因导致DBWR写磁盘很慢,或者DBWR进程效率不高,以至于在发生日志切换的时候没有课覆盖的日志文件。这时候可以添加DBWR进程的数,或者添加日志文件组,来解决这个问题。


    遂添加一个日志组:
    用sysdba登录 
    alter database add logfile gropu 4 ‘$ORACLE_HOME/oradata/SID/redo04.log’ size 100M;
    切换日志文件
    alter system switch logfile;
    查看当前的日志文件是否在使用
    select * from v$log
     



         本文转自andylhz 51CTO博客,原文链接:http://blog.51cto.com/andylhz2009/461220,如需转载请自行联系原作者


    展开全文
  • MYSQL数据库日志

    2020-08-29 11:11:20
    二、什么是binlog 三、binlog的三种模式 5. 日志原理 事务的原语操作 延迟的数据库修改redo 立即的数据库修改undo + redo 缓冲区管理 日志缓冲 数据库缓冲 操作系统在缓冲区管理的作用 检查点 静态检查点...

     

    目录

    1.日志介绍

    2. 日志作用

    3. 日志分类

    Mysql数据库日志

    4 .日志讲解

    一、innodb引擎中的redo/undo log是什么

    二、什么是binlog

    三、binlog的三种模式

    5. 日志原理

    事务的原语操作

    延迟的数据库修改redo

    立即的数据库修改undo + redo

    缓冲区管理

    日志缓冲

    数据库缓冲

    操作系统在缓冲区管理的作用

    检查点

    静态检查点

    动态检查点

    对比

    6 日志应用


    1.日志介绍

    数据库都具有事务日志,用于记录所有事务以及每个事务对数据库所做的修改。事务日志是数据库的重要组件,如果系统出现故障,则可能需要使用事务日志将数据库恢复到一致状态。删除或移动事务日志以前,必须完全了解此操作带来的后果。
    事务日志支持以下操作:

        恢复个别的事务。
        在 SQL Server 启动时恢复所有未完成的事务。
        将还原的数据库、文件、文件组或页前滚至故障点。
        支持事务复制
        支持备份服务器解决方案。

    那时有两个痛点:1,某个用户电脑忽然断电,数据写入不完整,导致大家都不能用了;2、多个用户对同一条记录进行写操作,或读与写不致,或ID增量重号。

    现在的数据库系统(Oracel、DB2、MS sql、Mysql等)都支持多用户,所有的数据库系统(包括Exchange),都是把数据先写到日志中,等某个时机(比如:确认commit)后再写到数据库记录中,日志是数据库最重要的数据之一,理解日志是相当重要的。为什么要用日志呢?就是要解决Foxfro多用户的痛点一啊。
    日志一般分成Undo与Redo:Undo一般用于事务的取消与回滚,记录的是数据被修改前的值,Redo一般用于恢复已确认但未写入数据库的数据,记录的是数据修改后的值,例如:数据库忽然断电重启,数据库启动时一般要做一致性检查,会把已写到Redo的数据但未写入数据库的数据重做一遍。

    数据库系统如何来确认哪些数据需要redo或undo呢?那就需要一个检查点(checkpoint),在系统中一般有一个表或一个控制文件来记录检查点,日志是按顺序一直写下去的,检查点设置后,只需要比对检查点之后的数据就可以了。

    2. 日志作用

    修改数据库时候,客户端发送一个update命令,数据库服务器收到update请求,数据库引擎首先会把表里面的数据先按照8页一个盘区的方式读到缓存里面,读入缓冲区后,就要在硬盘的日志文件中记录数据修改的操作过程以及原始参数,然后根据客户端的要求修改缓冲区中的数据,最后检查点程序向数据库中写入已经提交的事务(一次或者多次数据的修改,也就是批处理数据的修改,这样减少写盘的次数,提高效率)。如果内存里面的数据经过了修改,但是没有写入磁盘,也就是没有和磁盘里面的数据同步,这就是脏数据了。

    当你的数据在内存当中但是还没有写入硬盘的数据库中的时候,突然断电了,假如这时候有个银行帐户的转帐,如果发生这种事情的话,银行系统一般如何处理这种情况呢?以前是通过填写单子的方式来保证避免这种问题,现在都是通过日志来保证的,因为先是写入日志,然后才在内存中修改数据,日志中有个叫做检查点的东西,这个checkpoint后面的数据为脏数据块,证明没有写入硬盘,下一次启动系统后,会检查日志中的脏数据块记录,然后把他们再重新作一遍。

    Oracle中用的是还原模式,不是归档模式,如果执行delete from删除的话,如果是完全还原模式的话,删除的所有数据都必须记录日志,sqlserver中全表的删除是不写日志的,这是简单的还原模式,无法还原了。

    3. 日志分类

    数据库日志主要分为普通日志、重点日志两种类型

    Mysql数据库日志

    MySql日志类型 解析说明
    错误日志(error log) 当数据库启动、运行、停止时产生该日志
    普通查询日志(general query log) 客户端连接数据库执行语句时产生该日志
    二进制日志(binary log) 当数据库内容发生改变时产生该日志,也被用来实现主从复制功能
    中继日志(relay log) 从库上收到主库的数据更新时产生该日志
    慢查询日志(show query log) SQL语句在数据库查询超过指定时间时产生该日志
    DDL日志(metadata log) 执行DDL语句操作元数据时产生该日志

    4 .日志讲解

    一、innodb引擎中的redo/undo log是什么

    • redo
      介绍redo 日志是什么时,需要先回顾一下操作数据库数据的逻辑,一般是这样:首先,从数据库文件中找到记录,文件一般是按照一种特定的格式存放,比如页,然后加载整页数据到内存,在内存中进行数据的操作(脏页)然后将脏页同步回文件,一般不会立即将脏页刷回到磁盘,这样会产生大量的随机IO操作,性能低下,如果不立即刷回磁盘,那么当服务器挂掉后,存放在内存中的数据会丢失,造成数据的不一致性,也就无从持久化。为了解决这一矛盾,引入了redo日志。

    • undo
      undo日志是取消操作,用于事务回滚,将数据恢复到修改之前的状态,InnoDB的多版本并发控制(MVCC)就是基于undo来实现的 (原子性)

    小结:redo与undo是MySQL存储引擎级别的日志,俗称事务日志,与事务的实现息息相关

    二、什么是binlog

    数据库的任何变化(创建表,更新数据库,对行数据进行增删改),都以二进制文件的方式记录在主库的Binary Log(即binlog)日志文件中,(对于select操作则不会被记录到binlog里,因为它并没有修改数据库的数据),binlog是在事务最终commit前写入的,在MySQL主从复制中就是依靠binlog来实现。

    三、binlog的三种模式

    • row:
      基于行的模式,记录的是行的变化,很安全。但是binlog会比其他两种模式大很多,在一些大表中清除大量数据时在binlog中会生成很多条语句,可能导致从库延迟变大。
    • statement:
      基于SQL语句的模式,某些语句和函数如UUID, LOAD DATA INFILE等在复制过程可能导致数据不一致甚至出错。
    • mixed:
      混合模式,根据语句来选用是statement还是row模式。

    5. 日志原理

    事务的原语操作

    在事务系统的运行当中,有三个地址空间供元素存储:

    • 磁盘空间
    • 缓冲区
    • 事务的局部地址空间。

    一个简单的读、修改X元素操作的流程如:事务到缓冲中读取元素X,如果命中,则读取事务局部地址空间并返回,如果未命中,则先将相关页从磁盘读入缓冲区。事务在它的局部地址空间中修改元素X,然后写入缓冲区,再从缓冲区写入磁盘。当然缓冲区的数据也可能不是立即拷贝入磁盘的,这取决于具体的缓冲区管理策略。
    为了便于描述,我们描述了4个操作原语:

    • INPUT(X):将包含数据库元素X的磁盘块拷贝到内存缓冲区
    • READ(X,t):将数据库元素X拷贝到事务的局部变量t。更准确地说,如果包含数据库元素X的块不在内存缓冲区中,则首先执行INPUT(X)。接着将X的值赋给局部变量t。
    • WRITE(X,t):将局部变量t的值拷贝到内存缓冲区中的数据库元素X。更准确地说,如果包含数据库元素X的块不在内存缓冲区中,则首先执行INPUT(X)。将着将t的值拷贝到缓冲区中的X。
    • OUTPUT(X):将包含X的缓冲区拷贝到回磁盘。

    日志记录

    • <Ti start>
    • <Ti, Xj, V1, V2>
    • <Ti commit>
    • <Ti abort>

    日志必须放在稳定存储器上(99.999%不会丢失)

    延迟的数据库修改redo

    • 日志仅需记录数据项的新值

    • 所有日志(包含commit)写到稳定缓存器后,再执行真正的更新write操作缩短日志记录的时间

    • 恢复时redo同时包含 <Ti start><Ti commit> 的事务

    立即的数据库修改undo + redo

    • 允许在事务仍处于活跃时,就输出到数据库

    • 日志需记录数据项的原始值与新值

    • Ti执行任何write操作前,先写日志

    • 与数据项B相关的日志写到稳定缓存器后,才执行output(B)操作

    • 恢复时同时采用redo与undo机制
      1.redo同时包含 <Ti start><Ti commit> 的事务(可能已提交事务尚未执行output操作
      2.undo只包含 <Ti start> 的事务

    缓冲区管理

    日志缓冲

    遵循先写日志规则。
    日志只允许以附加的方式写入数据。日志块最初在主存中创建,像数据块一样也由缓冲区管理,在确当的时刻,日志块会从缓冲区写入到磁盘。
    

    数据库缓冲

    虚拟内存换页的时候,会(由操作系统)输出块B1,在B1输出前,应当先输出与块B1相关的日志记录到稳定存储器
    

    操作系统在缓冲区管理的作用

    方法一:数据库保留部分主存为缓冲区,对其管理,而不是让操作系统管理(然而几乎所有操作系统都完全控制主存区)
    方法二:在操作系统的虚拟内存中实现缓冲区,会导致输出两次,一是在操作系统换页时,一是在数据库系统进行
    

    检查点

    静态检查点

    1. 停止接受新的事务
    2. 等待所有当前的活动事务提交或终止,并且在日志文件中写COMMIT或ABORT记录。
    3. 将日志刷新到磁盘
    4. 写入日志记录<CKRT>,并再次刷新记录。
    5. 重新开始接受新事务。
      当恢复时,扫描到<CKRT>日志时,就不需要继续扫描日志记录了。

    动态检查点

    静态检查点的缺点在与,可能需要很长时间等待活跃事务的完成,在用户系统看来似乎是静止了。非静态检查克服了该缺点,在做检查点时允许新事务进入。步骤如下:
    1) 写入日志记录<START CKPT(T1,……,Tk)>.其中T1,……,Tk为活跃事务。
    2) 等待T1,……,Tk每一个事务提交或终止,但允许其它事务开始。
    3) 当T1,……,Tk都已完成时,写入日志记录<END CKPT>并刷新日志。

    当系统发生故障时,从日志尾部开始扫描日志。根据扫描过程中先遇到<END CKPT>记录还是<START CKPT(T1,……,Tk)>记录,有两种情况。

    1) 如果先遇到<END CKPT>记录。所有未完成的事务在<START CKPT(T1,……,Tk)>记录后开始,只要扫描到<START CKPT(T1,……,Tk)>就不需要继续扫描了。<START CKPT(T1,……,Tk)>前的记录是可以截断的。

    2) 如果先遇到<START CKPT(T1,……,Tk)>,那么崩溃发生在检查点过程中。未完成事务只可能是到达<START CKPT(T1,……,Tk)>前遇到的那些,以及T1,……,Tk在崩溃前未完成的那些。因此只要继续扫描到未完成事务中最早的那个事务的开始就行了。
    一个通常的规律是,一旦<END CKPT>记录到了磁盘,我们就可以将上一个<START CKPT>记录前的日志删除了。

    对比

    都是先output日志再output数据库元素
    undo:每write一条日志,write一次数据项更新,日志记录旧值,
    redo:write完所有日志,再延迟更新write数据项,日志记录新值

    6 日志应用

    一:事务系统

      1.事务的工作模型

      事务必须满足原子性,所封装的操作或者全做或者全不做。

      事务管理系统需要做两件事,1)让日志系统产生日志,2)保证多个事务并发执行,满足ACID特性。

        事务管理管理器控制查询处理器的执行、控制日志系统以及缓冲区。日志在缓冲区生成,日志管理器在一定的时候控制缓冲区的刷盘操作。当系统崩溃的时候,恢复管理器就被激活,检查日志并在必要时利用日志恢复数据。

      2.事务的原语操作

      在事务系统的运行当中,有三个地址空间供元素存储:1)磁盘空间、2)缓冲区、3)事务的局部地址空间。

      一个简单的读、修改X元素操作的流程如:事务到缓冲中读取元素X,如果命中,则读取事务局部地址空间并返回,如果未命中,则先将相关页从磁盘读入缓冲区。事务在它的局部地址空间中修改元素X,然后写入缓冲区,再从缓冲区写入磁盘。当然缓冲区的数据也可能不是立即拷贝入磁盘的,这取决于具体的缓冲区管理策略。

      为了便于描述,我们描述了五个操作原语:

      1) INPUT(X):将包含数据库元素X的磁盘块拷贝到内存缓冲区

      2) READ(X,t):将数据库元素X拷贝到事务的局部变量t。更准确地说,如果包含数据库元素X的块不在内存缓冲区中,则首先执行INPUT(X)。接着将X的值赋给局部变量t。

      3) WRITE(X,t):将局部变量t的值拷贝到内存缓冲区中的数据库元素X。更准确地说,如果包含数据库元素X的块不在内存缓冲区中,则首先执行INPUT(X)。将着将t的值拷贝到缓冲区中的X。

      4) OUTPUT(X):将包含X的缓冲区拷贝到回磁盘。

    3.应用

      假设银行系统数据库中有两个元素,元素A(表示用户1的余额,值为1000,单位:RMB)与元素B(表示用户2的余额,值为500,单位:RMB)。这时候用户1需要向用户2转帐50元。相应的过程为:

      A := A – 50;

      B := B + 50;

      执行之前,两个用户的总余额为1500(1000+500),两个操作执行成功之后总余额还是1500(950+550)。处于一致性状态。

      如果只有前一条执行成功,那总额只为1450(950+50)。处于不一致状态。

      为了避免这种不一致状态,我们需要将这两个操作封装成一个事务T。

      我们将这两个操作分解为原语操作。如下:

      READ(A,t); t := t-50; WRITE(A,t);

      READ(B,t); t := t+50; WRITE(B,t);

      OUTPUT(A); OUTPUT(B) //这两个OUTPUT原语操作由缓冲区管理器发出。

      表1给出了这8个原语操作的执行步骤,给出了每一步中A和B的内存值、磁盘拷贝的值以及事务T地址空间中局部变量t的值

    表1: 一个事务的步骤及其对内存和磁盘的影响

     

     

    步骤

     

    动作

     

    t

     

    内存A

     

    内存B

     

    磁盘A

     

    磁盘B

     

    1

     

    READ(A,t)

     

    1000

     

    1000

     

     

     

    1000

     

    500

     

    2

     

    t := t-50

     

    950

     

    1000

     

     

     

    1000

     

    500

     

    3

     

    WRITE(A,t)

     

    950

     

    950

     

     

     

    1000

     

    500

     

    4

     

    READ(B,t)

     

    500

     

    950

     

    500

     

    1000

     

    500

     

    5

     

    t := t+50

     

    550

     

    950

     

    500

     

    1000

     

    500

     

    6

     

    WRITE(B,t)

     

    550

     

    950

     

    550

     

    1000

     

    500

     

    7

     

    OUTPUT(A)

     

    550

     

    950

     

    550

     

    950

     

    500

     

    8

     

    OUTPUT(B)

     

    550

     

    950

     

    550

     

    950

     

    550

     

      在表1中不难发现,只要所有的这些步骤都执行成功,数据库的一致性就能得到保持。如果在执行OUTPUT(A)前系统发生了故障,那么磁盘上存储的数据库不会受到任何影响,就好象事务T从来没有发生过一样。但是如果故障在OUTPUT(A)后而在OUTPUT(B)前发生,那么数据就会处于不一致状态(从表中可以看出,磁盘中A为950,B为500)。我们不能防止这种情况的发生,但可以安排当这些情况发生时对问题进行修复-----或者A为1000、B为为500,或者A为950,B为550。

      二:undo日志

      1.概述

      日志是日志记录的一个序列。在多事务的数据库系统中,每个事务有若干个操作步骤。每个日志记录记载有关某个事务已做的某些情况。几个事务的行为可以是“交错的”,因此可能是一个事务的某个步骤被执行,并且其效果被记录到日志中,接着执行另外一个事务的某个步骤并记入日志,接着可能接着做第一事务的下一个步骤,也可能执行另外一个事务的某个步骤。依次类推。事务的交错执行使日志更复杂,因为仅在事务结束后记载事务的全过程是不够的。

     如果系统崩溃,恢复管理器就被激活,检查日志以重建数据库的一致性状态。恢复时,有些事务的工作将会重做,它们写到数据库的新值会重写一次。而另外一些事务的工作将被撤消,数据库被恢复,将仿佛这些事务从来没执行过一样。

      Undo日志是日志类型的一种,这类日志仅仅进行第二类修复。对于要被撤消的事务,因为不能肯定它对数据库的修改是否已经写到磁盘中,所以对于该事务的所有更新都将被撤消,数据库恢复到事务发生以前的状态。

      2.日志记录

      日志只允许以附加的方式写入数据。日志块最初在主存中创建,像数据块一样也由缓冲区管理,在确当的时刻,日志块会从缓冲区写入到磁盘。

      关于undo记录形式有四种:

      1) : 这一记录表示事务T开始

      2) : 事务T已经完成。

      3) : 事务T不能成功执行。

      4) : 事务T改变了数据库元素X的值,元素X原来的值为v。

      3.undo日志规则

      要想让undo日志能使我们从系统故障中恢复,事务必须遵循两条规则。

      规则1)如果事务T改变了数据库元素X,那么形如的日志记录必须在X的新值写到磁盘前写到磁盘

      规则 2)如果事务提交,则其COMMIT日志记录必须在事务改变的所有数据库元素已写到磁盘后再写到磁盘,但应尽快。

      简单概括,undo日志系统顺序如下:

      1) 指明所改变数据库元素的日志记录

      2) 改变的数据库元素自身

      3) COMMIT日志记录。

      4.应用

      对于前面所举的例子(A转帐50元给B帐号),如果使用了undo日志系统,则相关的工作流程如表2如下。

    表2:undo日志系统的工作原理

     

    步骤

     

    动作

     

    t

     

    内存A

     

    内存B

     

    磁盘A

     

    磁盘B

     

    undo日志

     

    1

     

     

     

     

     

     

     

     

     

     

     

     

     

    <START T>

     

    2

     

    READ(A,t)

     

    1000

     

    1000

     

     

     

    1000

     

    500

     

     

     

    3

     

    t := t-50

     

    950

     

    1000

     

     

     

    1000

     

    500

     

     

     

    4

     

    WRITE(A,t)

     

    950

     

    950

     

     

     

    1000

     

    500

     

    <T, A, 1000>

     

    5

     

    READ(B,t)

     

    500

     

    950

     

    500

     

    1000

     

    500

     

     

     

    6

     

    t := t+50

     

    550

     

    950

     

    500

     

    1000

     

    500

     

     

     

    7

     

    WRITE(B,t)

     

    550

     

    950

     

    550

     

    1000

     

    500

     

    <T, B, 500>

     

    8

     

    FLUSH LOG

     

     

     

     

     

     

     

     

     

     

     

     

     

    9

     

    OUTPUT(A)

     

    550

     

    950

     

    550

     

    950

     

    500

     

     

     

    10

     

    OUTPUT(B)

     

    550

     

    950

     

    550

     

    950

     

    550

     

     

     

    11

     

     

     

     

     

     

     

     

     

     

     

     

     

    <COMMIT T>

     

    12

     

    FLUSH LOG

     

     

     

     

     

     

     

     

     

     

     

     

     在表2,我们可以看到FLUSH LOG这个命令。该命令的用于强制将还没有刷盘日志记录写到磁盘上。对于步骤8执行之前,三个undo记录(,,)是存储在缓冲区中的(这样描述是为将问题简单化),执行步骤8之后,三条undo记录便写入了磁盘日志文件。在步骤12再次执行FLUSH LOG命令时,只将未刷盘的日志记录写入磁盘。

      步骤9、10,在前面已经描述过,是将数据库元素的修改从缓冲区写入到磁盘文件,因为WRITE操作仅仅是将修改反应到缓冲区中(这样描述也是为了将问题简单化)。 

     关注步骤8,执行完步骤8之后,将满足undo的规则1(如果事务T改变了数据库元素X,那么形如的日志记录必须在X的新值写到磁盘前写到磁盘)。在我们真正将数据库元素A与B的修改反应到磁盘前,我们已经将它们对应的与写入到磁盘日志文件。

      关注步骤11与步骤12,执行它们将满足undo的规则2(如果事务提交,则其COMMIT日志记录必须在事务改变的所有数据库元素已写到磁盘后再写到磁盘,但应尽快)。我们已经将数据库元素A与B的修改反应到磁盘上,接着可以写入来表示事务T的成功执行,但是该日志记录还在缓冲区中,所以我们在步骤12执行FLUSH LOG进行日志刷盘。

      5.使用undo日志进行数据库的恢复

      现在假设系统故障发生了。有可能给定事务的某些数据库更新已经写到磁盘上,而同一事务的另外一些更新尚未到达磁盘。如果这样,事务的执行就不是原子的,数据库状态就可能不一致。这时候,我们就有必要使用日志将数据库恢复到一致的状态。

      比如,在表2中,如果故障发生在步骤9之后、步骤10之前。数据库的状态就是不一致的。

      恢复管理的第一个任务就是将事务划分为已经提交事务和未提交事务。如果在日志中,根据undo的规则2,事务T所做的全部改变在此之前已经写到磁盘上,因此当故障发生时,该事务T不可能导致数据库的不一致状态。

      然而,假设在日志中,只有记录,而没有与之相匹配的记录。那么就有可能在崩溃前,事务的某些修改已经反应到磁盘上,而另外一些修改可能未发生或者还在缓冲区中。这种情况下,T是一个未完成的事务,因为必须被撤消。也就是说,T所做的任何修改都必须恢复为原来的值。Undo的规则1使该想法可以成为可能,因为在修改数据刷盘之前,日志文件中已经保存了修改数据的原先值。对于,只需要将X的值恢复为v就行了(我们不必检查数据库中X现有值是否为v)。

      日志中可能有一些未提交的事务,并且甚至可能有一些未提交的事务修改了X,所以恢复时采用从日志文件尾向前扫描。在扫描过程中记住所有有或记录的事务T。同时在随后的扫描中,如果它看见,则:

      1) 如果T的COMMIT记录已被扫描到,则什么也不做。

      2) 否则,将数据库中元素X的值改为v。在做完这些操作后,为以前未中止且未完成的每个事务T写入一个日志记录,然后刷新日志。

      对于表2,作如下分析:

      1)崩溃在第12步后发生。因为日志记录已经写入日志文件。当恢复时,不需要处理T事务。

      2)崩溃发生在11步和12步之间。日志中记录了三条记录:、以及。当恢复管理进行向后扫描时,首先遇到记录,于是它将B在磁盘上的值存为500。接着它遇到记录,于是它将A在磁盘上的值存为1000。最后记录被写到日志中且日志被刷新。

      3)崩溃发生在第8步和第11步之间。情况2一样。

      4)崩溃发生在第8步之前。日志系统中只有一条记录:。记录被写到日志中且日志被刷新。(实际上,在实际系统中,可能其他的事务执行FLUSH LOG操作,而将事务T的日志记录写入磁盘中,如果是这样的话,日志中可能已经写入和,对于这种情况,执行情况2的恢复就行。实际上这些细节不影响undo的恢复效用,为了简单起见,忽视这些情况)。

      6.静态检查点

      正如我们所看到的那样,恢复时需要检查整个日志。当采用undo类型的日志时,一旦日志记录被写入日志文件,事务T的日志记录就可以忽视了。但是此时事务T却不能截断日志,因为事务是交替执行的,如果这时将日志截断,可能丢失活动着的事务的日志记录。

    解决该问题的方法是周期性地对日志做检查点。步骤如下:

      1)停止接受新的事务

      2)等待所有当前的活动事务提交或终止,并且在日志文件中写COMMIT或ABORT记录。

      3)将日志刷新到磁盘

      4)写入日志记录,并再次刷新记录。

      5)重新开始接受新事务。

      当恢复事,扫描到日志时,就不需要继续扫描日志记录了。

      例如:假设日志开始时是这样的:

     

    <START T1>

     

    <T1, A, 5>

     

    <START T2>

     

    <T2, B, 10>

      这时候,我们做一个检查点。等待事务T1和事务T2都完成,才在日志文件中写记录。检查点做完后,可以接受新的事务,这里为事务T3,T3执行了一些操作,此时系统崩溃了。日志文件的内容如下:

     

    <START T1>

     

    <T1, A, 5>

     

    <START T2>

     

    <T2, B, 10>

     

    <T2, C, 15>

     

    <T1, D, 20>

     

    <COMMIT T1>

     

    <COMMIT T2>

     

    <CKPT>

     

    <START T3>

     

    <T3, E, 25>

     

    <T3, F, 30>

      恢复时,从文件尾部开始扫描,因为T3是未完成事务,则将磁盘上F的值存为前值30、磁盘上E的值存为前值25。当扫描到日志记录时,我们知道没有必要检查以前的日志记录了,并且数据库状态的恢复已经完成。

      7.非静态检查点

      静态检查点的缺点在与,可能需要很长时间等待活跃事务的完成,在用户系统看来似乎是静止了。非静态检查克服了该缺点,在做检查点时允许新事务进入。步骤如下:

      1) 写入日志记录.其中T1,……,Tk为活跃事务。

      2) 等待T1,……,Tk每一个事务提交或终止,但允许其它事务开始。

      3) 当T1,……,Tk都已完成时,写入日志记录并刷新日志。

      当系统发生故障时,从日志尾部开始扫描日志。根据扫描过程中先遇到记录还是记录,有两种情况。

      1) 如果先遇到记录。所有未完成的事务在记录后开始,只要扫描到。就不需要继续扫描了。前的记录是可以截断的。

    2) 如果先遇到,那么崩溃发生在检查点过程中。未完成事务只可能是到达前遇到的那些,以及T1,……,Tk在崩溃前未完成的那些。因此只要继续扫描到未完成事务中最早的那个事务的开始就行了。

      一个通常的规律是,一旦记录到了磁盘,我们就可以将上一个记录前的日志删除了。

      例如:假设日志开始时是这样的:

     

    <START T1>

     

    <T1, A, 5>

     

    <START T2>

     

    <T2, B, 10>

      现在我们决定做一非静态检查点。因为事务T1和T2是活动的,我们写入记录。在等待T1和T2完成时,事务T3开始了。

      执行到崩溃时,日志记录可能如下(对应恢复的第一种情况):

     

    <START T1>

     

    <T1, A, 5>

     

    <START T2>

     

    <T2, B, 10>

     

    <START CKPT(T1,T2)>

     

    <T2, C, 15>

     

    <START T3>

     

    <T1, D, 20>

     

    <COMMIT T1>

     

    <T3, E, 25>

     

    <COMMIT T2>

     

    <END CKPT>

     

    <T3, F, 30>

      对于这种情况,恢复时,从尾部开始检查日志。T3是未完成的事务,将磁盘上的F值恢复为值30。发现记录,知道所有未完成的事务从前一个START CKPT开始。继续扫描,将磁盘上E的值恢复为25。继续扫描,发现没有其它已开始但尚未提交的事务。恢复完成。

      当然,崩溃时的日志记录可能是另外一种格式,如下: 

     

    <START T1>

     

    <T1,  A, 5>

     

    <START T2>

     

    <T2, B, 10>

     

    <START CKPT(T1,T2)>

     

    <T2, C, 15>

     

    <START T3>

     

    <T1, D, 20>

     

    <COMMIT T1>

     

    <T3, E, 25>

      对于这种情况,崩溃发生在检查点过程中。向后扫描,确定T3然后又确定T2是未完成事务,并撤消它们所做的修改。当到达时,我们知道其它可能未完成的事务只有T1了,但是T1的记录已经发现。我们也发现了。所以我们只要继续扫描到记录,并在此过程中将磁盘B的值恢复成10。

    三:redo记录

      1.概述

      Undo是恢复的一种策略,但是不是唯一的策略。

      Undo日志的一个潜在的问题是:在所有修改数据没有写到磁盘前,不允许提交该事务。有时,让修改的数据页暂时缓冲在主存中,是可以节省磁盘IO的;只要在崩溃的时候有日志用来恢复。

      2.redo日志的规则

      Redo日志用新值表示数据元素的更新,而undo日志使用的是旧值。Redo日志的表示:事务T为数据库元素X写入新值v。

      Redo日志系统的规则只有一条:

      规则1:在修改磁盘上任何数据库元素X之前,要保证所有与X这一修改相关的日志记录,包括更新记录以及记录,都必须出现在磁盘上。

      Redo日志顺序如下:

      1) 指出被修改元素的日志记录

      2) COMMIT日志记录

      3) 改变的数据元素自身。

      3.应用

      对于前面所举的例子(A转帐50元给B帐号),如果使用了undo日志系统,则相关的工作流程如表3如下。

    表3:redo日志系统的工作原理

     

     

    步骤

     

    动作

     

    t

     

    内存A

     

    内存B

     

    磁盘A

     

    磁盘B

     

    undo日志

     

    1

     

     

     

     

     

     

     

     

     

     

     

     

     

    <START T>

     

    2

     

    READ(A,t)

     

    1000

     

    1000

     

     

     

    1000

     

    500

     

     

     

    3

     

    t := t-50

     

    950

     

    1000

     

     

     

    1000

     

    500

     

     

     

    4

     

    WRITE(A,t)

     

    950

     

    950

     

     

     

    1000

     

    500

     

    <T, A, 950>

     

    5

     

    READ(B,t)

     

    500

     

    950

     

    500

     

    1000

     

    500

     

     

     

    6

     

    t := t+50

     

    550

     

    950

     

    500

     

    1000

     

    500

     

     

     

    7

     

    WRITE(B,t)

     

    550

     

    950

     

    550

     

    1000

     

    500

     

    <T, B, 550>

     

    8

     

     

     

     

     

     

     

     

     

     

     

     

     

    <COMMIT T>

     

    9

     

    FLUSH LOG

     

     

     

     

     

     

     

     

     

     

     

     

     

    10

     

    OUTPUT(A)

     

    550

     

    950

     

    550

     

    950

     

    500

     

     

     

    11

     

    OUTPUT(B)

     

    550

     

    950

     

    550

     

    950

     

    550

     

     

      与记录的是新值。只有所有相关的日志记录被刷盘(步骤9),才允许将A与B的新值写到磁盘。步骤10与11在日志刷盘之后立即将数据修改写到磁盘,而实际中为了提高IO命中率,刷盘的时间可能会晚些。

     4.使用redo日志的恢复

      对于redo日志,根据规则1,我们可以知道如果日志没有,则事务T的修改所做的所有的更新都没反映到磁盘上,就像事务T从来没有发生过一样。

      如果发现记录记录,却不敢保证所有的数据库修改已经反映到磁盘上,这和undo日志是相反的。我们必须将事务T重做一次。

      使用redo日志恢复,过程如下:

      1) 确定提交事务

      2) 从首部开始扫描日志,对遇到的每一记录:

      (a):如果T是未提交的事务,则什么也不做。

      (b):如果T是提交的任务,则为磁盘上数据库元素写入值v

      3)对于每一个未完成的事务T,在日志中写入一个记录并刷新日志。

      例如,对于表3

      1) 如果故障发生在第9步以后,记录已被刷新到磁盘。恢复时,遇到记录,为磁盘上的A写入值950。遇到记录,为磁盘上的B写入值550。

      2) 如果故障发生在第9步之前,如果已经到达磁盘,则恢复过程同情况1。如果未到达磁盘,T被做为未完成事务,磁盘上的A和B不作任何修改,最后将一条写入日志并刷盘。

     

    展开全文
  • 1 什么是检查点 数据修改操作 都是在 内存的数据页进行修改,每次修改后并没有立即把这些页面写入磁盘,而是等到一定时期,数据库引擎对数据库发起 检查点命令,这时,该命令就会创建一个已知的正常点,把当前...
  • 数据库系统实现

    2013-05-12 13:09:11
    本书斯坦福大学计算机科学专业数据库系列课程第二门课的教科书。书数据库系统实现原理进行了深入阐述,并具体讨论了数据库管理系统的三个主要成分—存储管理器、查询处理器和事务管理器的实现技术。书还对...
  • ■质量检查规则(宗地与界址线、界址的边界相互重合、水井和地下 水源地等 连通性规则(河道轴线应具备连通性 ■复杂关系类(宗地与房屋的依存关系 空间要素与非空间要素间关系 空间要素挂接属性表(房屋与房屋所属人...
  • 3.1.4 系统日志检查点和模糊检查点 43 3.1.5 事务回滚 44 3.2 基于延迟更新的恢复技术 45 3.2.1 单用户环境下使用延迟更新的恢复 46 3.2.2 多用户环境下并发执行的延迟更新 46 3.2.3 不...
  • 4.4.2. 用C或其他语言定义出数据库记录(D记录)和检查点记录(K记录)的数据结构。 28 4.5. 设数据项x,y存放在S1场地,u,v存放在S2场地,有分布式事务T1和T2,T1在S1场地的操作为R1(x)W1(x)R1(y)W1(y),T2在S1场地的...
  • 1、什么是兼容性测试?兼容性测试侧重哪些方面? 答:①兼容性测试时指检查软件在不同的软/硬件平台上是否可以正常的运行,即软件的可移植性。兼容性测试的类型细分为不同平台的兼容、网络兼容、数据库兼容、数据...
  • 要知道任何时刻数据库都可能会有一些object invalid的,你的一些操作也会增加invalid objects,定期检查这些invalid objects的数量,然后定期用utlrp去重新编译,utlrp.squ在ORACLE HOME的rdbms/admin下,需要用...
  • 一、什么是联机重做日志文件联机重做日志文件的主要用于数据库的备份和恢复,它记录了数据的所有变化情况,提供了数据的恢复机制(Oracle在对数据进行操作时,会先写入联机重做日志),它被组织成组,至少有两组日志...
  • 分布式数据库试题及答案.doc

    热门讨论 2010-12-29 16:46:29
    4.4.2. 用C或其他语言定义出数据库记录(D记录)和检查点记录(K记录)的数据结构。 28 4.5. 设数据项x,y存放在S1场地,u,v存放在S2场地,有分布式事务T1和T2,T1在S1场地的操作为R1(x)W1(x)R1(y)W1(y),T2在S1场地的...
  • 内容主要集中在大多数企业常见的问题之上,如安装和升级到oracle database 11g数据库软件、创建数据库、导出和导入数据、数据库的备份与恢复、性能调优,等等。  本书还提供了dba完成本职工作必备的基本的uniix...
  • 后台进程和恢复:检查点(CKPT) 14-11 后台进程和恢复:重做日志文件和LogWriter 14-12 后台进程和恢复:归档程序(ARCn) 14-13 实例恢复14-14 实例恢复的阶段14-15 优化实例恢复14-16 使用MTTR 指导14-17 介质故障14-...
  • 3.4.2 Oracle数据库中的存储层次体系 87 3.4.3 字典管理和本地管理的表空间 90 3.5 临时文件 92 3.6 控制文件 94 3.7 重做日志文件 94 3.7.1 在线重做日志 95 3.7.2 归档重做日志 97 3.8 密码文件 99 3.9 ...
  • 8.4 检查点与RBA 374 8.5 数据库的运行模式 376 8.6 逻辑备份与恢复 381 8.6.1 使用EXP进行逻辑备份 381 8.6.2 使用IMP进行逻辑恢复 386 8.6.3 使用数据泵(EXPDP/IMPDP) 389 8.7 物理备份与恢复 395 ...
  • 6.5.5 备用数据库中的块更改跟踪支持 248 第7章 Data Pump 249 7.1 API增强 249 7.2 压缩增强 250 7.3 加密 253 7.3.1 指定加密 254 7.3.2 选择加密方式 254 7.4 重用转储文件 256 7.5 重映射数据 257 7.6...
  • chk文件是检查点文件,记录数据库备份到哪个点了,就是把LOG写入数据库,写到第几个LOG文件了。说到这不得不提一下EXCHANGE数据库的工作原理。客户端对EXCHANGE的操作,首先先记录到LOG文件里,因为LOG文件的写入...
  • 3.4.2 Oracle数据库中的存储层次体系 87 3.4.3 字典管理和本地管理的表空间 91 3.5 临时文件 93 3.6 控制文件 95 3.7 重做日志文件 95 3.7.1 在线重做日志 96 3.7.2 归档重做日志 98 3.8 密码文件 100 3.9 ...
  • 今天在做一个小项目时,遇到了form表单提交到数据库中的中文乱码情况。经过打断排查原因,发现 在执行存数据库操作之前就已经乱码了。经过一番检查,发现了问题所在,特此记录下。form在前端以post方式提交设置 ...
  • 他的数据库的存放路径:c:\windows\NTDSNTDS.DIT:数据库文件EDB.LOG :事务日志文件EDB.CHK :事务日志的检查点记录硬盘上的ad和内存的AD在内容上的差异。一般用来AD的初始化或还原; RES.lo...
  • 已经得到了所需的全部锁。...SCN 还用于保证数据库中的读一致性和检查点。可以把SCN看作一个钟摆,每次有人COMMIT时,SCN都会增1.  LGWR将所有余下的缓存重做日志条目写到磁盘,并把SCN记录到在线
  • 财务软件

    2018-11-12 15:45:30
    只要你具备电脑操作基本知识,只要你知道什么叫借方与贷方,你就能使用智财务软件。 4、不需要记帐等多余的操作,输入凭证就能看到帐簿与报表的结果。许多财务软件,它们在设计之初就完全按照手工做帐那一套工序...
  • 软件工程知识

    2012-12-02 21:34:25
    软件定义软件项目的早期阶段,主要由软件系统分析人员和用户合作,针对有待开发的软件系统进行分析、规划和规格描述,确定软件是什么,为今后的软件开发做准备。这个时期往往需要分阶段地进行以下几项工作。 1....
  • 3.6 simple_list_item_1是什么 21 3.7 ImageView的属性 22 3.8 CheckBox属性及相关代码 23 3.9 RadioGroup属性及相关代码 25 3.10 ToggleButton 26 3.11 Spinnner 28 3.12 DatePicker 29 3.13 TimePicker 30 4.1...
  • oracle checkpoint

    2014-03-02 23:10:46
    Oracle检查点检查点是一个事件,一些动作而SCN则oracle数据库里的时钟,吗?SCN,CHECKPOINT,REDO ENTRY,COMMIT这四者的关系到底是什么?当你commit的时候,oracle会产生两个动作:1:把REDO LOG BUFFER的...

空空如也

空空如也

1 2 3 4 5 ... 10
收藏数 183
精华内容 73
关键字:

数据库中什么是检查点记录