gbase8s数据库的逻辑日志、物理日志和两种特殊情形的学习

(一) 日志的介绍

1. 日志的类别

数据库日志主要是分为记录日志、逻辑日志和物理日志。

• 记录日志：记录日志包括了数据库的报错日志、连接日志、sql执行等信息，这些日志不存储在dbspace上，而是保存在操作系统的文件内
• 逻辑日志和物理日志：当需要对数据进行更新和更改时，需要将数据从磁盘读取到buffer中，再对buffer中的数据进行更新，而更新时，会将更新前的读取到buffer中的页数据进行保存到物理日志buffer中，而将更新的操作步骤记录到逻辑日志的缓冲区内，此时物理日志缓冲区和逻辑日志缓冲区共同构成了数据变化前后的状态（每两个checkpoint之间，每个页面只需保存到物理buffer中一次）

• • 物理日志：数据更新前的镜像页
  • 逻辑日志：在镜像页基础上的操作语句

(二) 逻辑日志

1. 逻辑日志的存储位置和控制参数

• 针对gbase8s数据库的逻辑日志：逻辑日志的位置在初始化时会默认创建在rootdbs系统数据空间上，后续可以手动创建逻辑日志空间，进行逻辑日志切换，将逻辑日志移动到独立的逻辑日志上
• 逻辑日志初始化后的信息有逻辑日志数目、逻辑日志文件大小、逻辑日志的页大小和逻辑日志缓冲区大小四个参数共同控制了逻辑日志，本次将这些参数分成初始化时和后续手动两种类别

• • 初始化时：

• • • 逻辑日志初始化数目：由参数LOGFILES进行指定，在数据库初始化的时候生效，逻辑日志文件最少有3个，可通过onstat -l进行查看
    • 逻辑日志大小：最初初始化的逻辑日志大小，由LOGSIZE进行指定，如果不更改，初始化后的日志文件大小则会按照此参数进行设置，且进行新增逻辑日志时，如果不指定大小，则会默认按照此参数进行设置
    • 逻辑日志页大小：最初的页大小由于逻辑日志是初始化在rootdbs上的，所以页大小和系统页大小一致，后续可以通过onspace新建大页的逻辑日志数据空间，但是建议默认为2KB的页大小
    • 逻辑日志缓冲区大小：逻辑日志缓冲区大小通过LOG_BUFF进行指定

• • 后续手动创建数据空间时：

• • • 逻辑日志的数目：逻辑日志手动创建时，没有数量限制，只要有数据空间即可
    • 逻辑日志的大小：可以手动指定大小，建议每个逻辑日志最大1G即可
    • 逻辑日志页大小：创建数据空间的时候可指定，建议默认为系统数据空间的2KB大小
    • 逻辑日志缓冲区大小：根据参数LOG_BUFF控制

2. 逻辑日志文件和逻辑日志数据空间的说明

• 逻辑日志数据空间：和其他数据空间一样，是一个熟文件，是我们规定的逻辑日志可以占用的磁盘空间大小
• 逻辑日志文件：逻辑日志文件是对逻辑日志数据空间的一个使用，必须先创建逻辑日志数据空间，在已有的数据空间中分配出来一部分大小形成一个逻辑日志文件，

• • 即创建出来2G的数据空间，可以分配20个100M的数据文件或者10个200M的数据文件

3. 逻辑日志的注意事项

• 逻辑日志增加时需要dbspace中有足够的空间
• 增加逻辑日志时需要dbspace中必须有连续的空间，即如果在rootdbs中，剩余空间200M，但是空间不连续，则增加100M逻辑日志文件失败
• 系统备份时，不能增加逻辑日志
• 不能通过参数文件增加逻辑日志文件
• 旧版本需要静态模式下增加逻辑日志文件，新版本可以在在线模式下增加逻辑日志

4. 逻辑日志的使用

• 逻辑日志是实例级别进行使用，多个库共用的，库与库之间会共用同一个实例
• 逻辑日志文件的数量：最少3个，最多32676个
• 逻辑日志是循环且顺序使用的，当逻辑日志被使用过且被备份过后（有备份标识），可以再次使用或者删除
• 当所有的逻辑日志被使用完毕，所有数据库操作都会被hang住，可以动态增加逻辑日志
• 逻辑日志主要用来记录事务细节，其除了用来事务回滚、系统故障恢复时使用，还用来在高可用复制技术中使用
• 逻辑日志在备份中的作用：当进行事务处理时，数据库需要日志来记录数据最后一次备份后的变化，以便使用逻辑日志在最后一次备份的基础上进行还原恢复数据库

5. 逻辑日志记录的详细内容

逻辑日志记录的东西

• DDL语句（create、drop、alter）
• 索引项信息增加和删除
• 记录行增加和删除
• blobpagemap结构
• checkpoint记录
• space的分配和管理（chunks、extents、logicat logs）

逻辑日志不记录的

• sql语句-select语句
• 不记临时日志表（with no log）数据修改
• blobspace blobs
• 记录所在的数据页、物理记录page
• no-logging数据库DML语句不产生逻辑日志，但是DDL语句会有逻辑日志

6. 逻辑日志的特殊机制-释放机制

释放机制的介绍：

• 由于逻辑日志是循环使用的，所以何时释放日志的时间点（何时认为一个日志文件不再被需要使用时），是重要的时间点
• 如果事务回滚或者数据库快速恢复时需要一个逻辑日志的文件内容，那个这个逻辑日志是不能被释放的，或者说这个日志是激活或者是使用状态

释放的机制：

• 假设上述三个日志文件是当前正在使用的最后三个文件，从上图可以看出Log1中的checkpoint是Log1,Log2,Log3这三个逻辑日志文件中的最后一个checkpoint，所以认为Log1,Log2,Log3这三个日志文件中checkpoint后的内容都没有被刷新到磁盘，所以log1和log2、log3都被认为是正在使用的日志文件，不能释放
• 当新的检查点写入时，两次检查点之间没有激活的事务且日志已经被备份过，快速恢复也不需要这些日志，则新检查点之前的日志都可以被释放
• 由于大对象的更新是不需要写入到buffer缓冲区内的，如果逻辑日志内包括大对象的操作，逻辑日志被释放，则也将会释放掉旧的blobpages

• • 特殊说明：blobpages这种大字段类型做更新时，不会讲更新的变化写入到逻辑日志内，而是在blobdbs中，保留旧的大字段数据，将新的大字段数据写进去，会存在一段时间新旧两个数据同时存在的情况，而在某个时间点会释放掉旧的大字段数据

7. 更改数据库的日志模式

• gbase8s数据库中，数据库共有四种日志模式：

• • 不记录日志
  • unbuffered log不带缓冲区的记录日志
  • buffered log带缓冲区的记录日志
  • log：记录日志分为两种，普通的记录日志和ansi格式的日志记录

• 可以通过ondblog进行修改日志模式（大多数人喜欢使用ontape修改日志模式），如果一个数据库是不记日志格式，出现故障后，无法恢复

--对应sysmaster:sysdatabases的is_buff_log字段
--修改为带buf和不带buf的记录日志格式
ondblog buf test
ondblog unbuf test
--修改数据库不记录日志
ondblog nolog test
--进行0级备份后即可修改为ansi模式，但是无法再修改为不记录日志模式
ontape -s
--修改数据库为ansi兼容模式
ondblog ansi test
--解锁数据库
ondblog cancel test

（关于ondblog可以进行相关测试）

8. onlog用于逻辑日志的检查

onlog工具可用于检查逻辑日志文件的内容，可以读磁盘或者备份的数据，会打印一个报表，主要用于分析

log输出中的头部信息，大多数记录会有额外的列提供额外的信息

addr     len  type     xid      id link
10f018   44   CKPOINT  1        56 0        0
         2c000000 38004200 10000000 00000000 ,...8.B. ........
         00000000 00000000 01000000 00000000 ........ ........
         2c828501 00000000 00000000          ,....... ....
110018   44   HA       1        0  10f018   CKPTEND  6519
         2c000000 00000200 16000000 06000000 ,....... ........
         00000000 00000000 01000000 18f01000 ........ ........
         3b828501 00000000 77190000          ;....... w...
110044   40   SYNC     1        0  110018
         28000000 00000000 16000000 00000000 (....... ........
         00000000 00000000 01000000 18001100 ........ ........
         3b828501 00000000                   ;.......

额外列

• 1002ca：tblspace id，对应systables的partnum
• 10c：rowid，16进制
• 82：槽长度

TYPE为checkpoint的额外列

• link后面第一列为0：此时激活的事务数目为0

(三) 物理日志

1. 物理日志的位置和参数介绍

• 针对gbase8s数据库的物理日志：物理日志的位置在初始化时会默认创建在rootdbs系统数据空间上，后续可以手动创建物理日志空间，进行物理日志迁移，将物理日志移动到独立的物理日志上
• 物理日志初始化后的信息有物理日志文件大小和物理日志缓冲区大小两个参数控制了物理日志，本次将这些参数分成初始化时和后续手动两种类别

• • 物理日志数目：物理日志没有此参数，只有物理日志数据空间
  • 物理日志文件大小：初始化时物理日志大小由参数PHYSFILE决定，初始化后可通过onspace进行新建，通过onparams进行迁移
  • 物理日志页大小：物理日志文件大小只能和系统页大小、rootdbs一致，不能手动指定页大小
  • 物理日志缓冲区：初始化时通过参数PHYSFBUFF进行指定，物理日志缓冲区最少有2个

2. 物理日志的使用

• 物理日志是服务器中连续的一组页面
• 物理日志主要是主要目的是为了做快速恢复时使用
• 对dbspace做在线备份时，会用到物理日志
• 当需要备份逻辑日志时，需要有一个物理备份存在

3. 物理日志的创建

--简单说明一下，/路径要求755权限，文件需要660权限
onspaces -c -P 物理日志数据空间 -p /路径/已有的文件名 -o 0 -s 大小(KB为单位)
--使用-P创建的物理日志文件，应该默认会自动迁移，也可以手动迁移
onparams -p -d 物理日志数据空间 -s 大小

(四) 日志的特殊场景-长事务

1. 长事务的介绍

• 如果一个事务同时存在多个日志文件中，跨过了多个日志文件达到某个阈值还没有提交，我们称其为长事务
• 如果长事务达到某个阈值时想要继续执行，那么必须在此时提供更多的逻辑日志文件，提供日志文件的方式有两种

• • 设置了逻辑日志增加模式，当逻辑日志使用将近完毕时，会自动增减新的逻辑日志文件，增加新的逻辑日志文件，要求数据空间中有剩余的未使用空间，如果事务过大，将会使用完所有的数据空间
  • 释放旧的逻辑日志数据空间，但是逻辑日志空间的释放，要求逻辑日志文件上没有正在执行的事务，所以形成了死循环，此时将会触发事务回滚（事务回滚要求此事务的所有日志都在日志文件中）

• 长事务的危害：下列进行分析

2. 针对长事务的两个阈值长事务高水位线LTXHWM和长事务独占水位线LTXEHWM

• LTXHWM：

• • 是长事务的高水位线，参数查看onstat -c |grep -i ltxhwm，默认是70%
  • 当一个事务达到此水平线时，这个事务将会被标记为长事务，而一个事务当被标记为长事务时，就会触发回滚操作

• LTXEHWM：

• • 事务的回滚也是需要写逻辑日志的，而且日志回滚时，同时也会存在其他事务需要写逻辑日志
  • 为了防止事务回滚的时候，还没有回滚完成，逻辑日志被使用完毕，此时设置了第二个水位线，独占水位线，如果长事务没有回滚完毕，日志的使用个数百分比达到了独占水位线，就会触发独占水位线的机制
  • 当写日志的量达到此水位线时，除了允许回滚的线索和正在写commit记录的线索允许访问逻辑日志，其他所有的事务都会被挂起（hang住），直到长事务回滚结束，其他事务才可以继续执行，访问逻辑日志

• LTXHWM和LTXEHWM：

• • 可以在配置文件中修改，默认值是70和80
  • 其代表的是逻辑日志文件个数的百分比，不是总空间的百分比
  • 只有逻辑日志切换时才会检查百分比
  • 由于长事务回滚需要很多的空间，建议将LTXHWM和LTXEHWM设置为40和50

3. 事务的查看

• 长事务的回滚时间可以通过onstat -x获得，这将有利于判断数据库在多久之后可以恢复在线的模式
• onstat -x会显示当前激活的事务和其起始的log number

4. 逻辑日志新增

5. 逻辑日志文件自动新增

• DYNAMIC_LOGS：自动增加逻辑日志参数

• • 0不申请会触发一个警告开始回滚
  • 1：事务会挂起，允许用户自己进行增加逻辑日志

• • • onparams：-i指定在当前逻辑日志后面新增逻辑日志，不指定-i，默认增加在最后

• • 2：默认和建议设置，会自动申请逻辑日志文件，并发出告警， 要求当前逻辑日志文件所在dbspace有空间

(五) 逻辑日志的特殊场景-blobspace logging和sbspace logging

1. blobspace

• blobspace blobpages不会再内存中缓存，他们在插入或更新时会立即写入磁盘，在物理日志中不会保留更新的前映像
• 每个对blob free map页面的修改都会记录在逻辑日志和物理日志中，由于blob free map中记录了blobspace中blobpages的状态，这使得blob数据的恢复成为可能
• 单个blobpages和修改他的事务会被一起备份
• 大对象被修改时，会申请新的blobpages，旧的数据不会被覆盖，直到修改事务相对应的日志文件被释放后，这些旧的blobpages才能被重用

• • 事务回滚或者快速恢复时仍然需要那些旧的blobpage，数据库通过哪些逻辑日志文件被释放判断哪些旧的数据不再被需要

2. sbspace

• 智能大对象要写日志确保日志比大对象大，即是大对象不记日志，元数据也总是记日志的
• 当创建sbspace时带了log选项，逻辑日志就会包括智能大对象的操作步骤
• 大对象的日志记录中包含用户数据和元数据
• 大对象被修改后，逻辑日志中仅包含被修改后的数据