数据守护中的一些常用术语

1.数据库（database）
       一个文件集合（包括数据文件，临时文件，重做日志文件，控制文件），保存在物理磁盘或文件中。
2.数据库实例（instance）
        一组操作系统进程（一个多线程的进程）以及一些内存。通过数据库实例可以操作数据库，一般情况下访问修改数据库都是通过数据库实例来完成的。
3.主库
        Primary模式，提供完整数据库服务的实例，一般是用来支撑应用系统的生产库
4.备库
        Standby模式，提供只读数据库服务的实例，一般用于容灾，备份，查询等制度功能。
5.Redo日志
        Redo日志记录物理数据页内容变动情况。Insert/delete/update 等 DML 操作、Create Table等 DDL操作，最终都会转化为对物理数据页的修改，这些修改都会 反映到 Redo日志中。
        分类：
        物理RREC
               物理RREC记录的是数据页的变化情况，内容包括：操作类型、修改数据页地址、页内偏移、数据页上的修改内容，如果是变长类型的 Redo记录，在 RREC记录头 之后还会有一个两字节的长度信息。
        逻辑RREC。
              逻辑RREC记录的是一些数据库逻辑操作步骤，主要包括：事务启动、事务提交、事务回滚、字典封锁、事务封锁、B树封锁、字典淘汰等。逻辑RREC记录是专门为数据守护增加的记录类型，用来解决备库重演Redo日志与用户访问备库之间的并发冲突，以及主库执行DDL后导致的主备数据库字典缓存不一致问题。

6.Redo日志包
        Redo日志包（RLOG_PKG）是 DM数据库批量保存物理事务产生的 Redo日志的数据单元，以物理事务PTX 为单位保存日志，一个日志包内可连续保存一个或多个PTX。DM 数据守护系统中，主库以RLOG_PKG为最小单位发送 Redo日志到备库。
7.包序号
       每个RLOG_PKG都有对应的序号属性，称之为包序号（PKG SEQNO），日志包生成时按照序号连续递增。
       分类：
       本地包序号（LSEQ）：
               节点内唯一、连续递增的值，用于校验联机日志连续性
       全局包序号（GSEQ）：
              由数据守护集群的主备库共同维护，具有全局唯一、连续、递增的特性，用于校验归档日志的连续性。
       DM数据库全局包序号：
                CUR_SEQ：是系统已经分配的最大全局包序号。
                FILE_SEQ：是已经写入联机Redo日志文件的最大全局包序号。
                APPLY_SEQ：是备库重演全局包序号，表示备库已经重演完成的最大全局包序号。
        DM数据守护全局包序号：
               CSEQ：全局已分配包序号，标识系统已经分配的最大GSEQ值。
               FSEQ：全局文件包序号，标识已写入联机日志文件的最大GSEQ值。
               ASEQ：全局重演包序号，标识备库已经重演的最大GSEQ值。
               SSEQ：全局备库包序号，标识备库明确可重演的最大GSEQ值。
               KSEQ：全局保留包序号，表示备库已经收到、未明确是否可以重演的最大GSEQ值。在读写分离集群中SSEQ == KSEQ。
8.Redo日志传输
        主备库之间的Redo日志传输，一日志包RLOG_PKG为单位，主库通过MAL系统发送Redo日志到备库。
9.Redo日志重演
        备库收到主库发送的Redo日志后，在物理数据页上重新修改数据的过程。重演过程中，备库会生成自身的Redo日志写入联机日志中。
10.联机Redo日志文件
        DM数据库默认包含两个联机 Redo日志文件（如DAMENG01.log、DAMENG02.log），系统内部分别称为0号文件、1号文件。RLOG_PKG顺序写入联机Redo日志文件中， 当一个日志文件写满后，自动切换到 另一个文件。
11.守护进程
        数据守护系统的核心工具，监控数据库实例的运行状态和主备数据同步情况，在出现故障时启动各种处理方案。会接收与发送数据库实例，其他守护进程，监视器的消息。
        守护进程必须和被守护的数据库实例部署在同一台机器上。
12.监视器
       用来监控守护系统内守护进程，数据库实例信息，执行用户输入命令，监控实例故障，实现自动切换等。
        一般配置在数据库实例和守护进程以外的机器上。
13.数据库模式
        DM支持三种模式
       Normal模式：
               提供正常的数据库服务，操作没有限制，只生成本地归档。
        Primary模式：
               提供正常的数据库服务，操作有极少限制。限制包括：不支持修改表空间文件名，不支持修改arch_ini参数。
              正常生成本地归档，支持实时归档（Realtime），及时归档(Timely),异步归档（Async）
               对所有除临时表空间以外的所有数据库对象的修改操作都强制生成Redo日志
        Standby模式
               可以执行数据库备份，查询等只读数据库操作。正常生成本地归档，发送异步归档Redo日志。
               实时归档，即时归档均强制失效。时间触发器，事件触发器等都失效。
14.数据库状态
        Startup状态
               系统刚启动时设置为Startup状态
        After Redo状态
               系统启动过程中练级日志重做完成后，回滚活动事务前设置为After Redo状态。
               非Standby模式的实例在执行alter database open操作前，将系统设置为After Redo状态
        Open状态
               数据库处于正常提供服务的状态，但不能进行归档配置等操作。
        Mount状态
               数据库在Mount状态下，不能修改数据，不能访问表、视图等数据库对象。
              可以进行数据库的配置，可以执行查询数据库系统视图等一些只读操作。
               系统从Open状态切换为Mount状态时，会强制回滚所有活动事物，但不会强制清理（Purge）已提交事物，不会强制断开用户连接，也不会强制Buffer中的脏页刷 盘。
        Suspend状态
              可以访问数据库对象，甚至可以修改数据（限当前会话未断开），但限制Redo日志刷盘，一旦执行commit等触发Redo日志刷盘的操作时，当前操作将被挂起。
               从Open到Suspend的状态切换，不会回滚活动的事务，切换完状态，所有事务继续执行。
       Shhutdown状态
               实例正常退出时设置为Shhutdown状态。

15.物理事物
       物理事务（Physical Transaction，简称ptx）是数据库内部一系列修改物理数据页操作的集合，与数据库管理系统中事务（Transaction）概念相对应，具有原 子性、有序性、无法撤销等特性。
16.LSN
       LSN(Log Sequence Number)是由系统自动维护的Biginit类型数值，是具有自动递增，全局唯一特性，每一个LSN值代表着DM系统内部产生的一个物理事务。
       DM数据库LSN分类：
              CUR_LSN:系统已经分配的最大LSN。
              FILE_LSN：已经写入联机Redo日志文件的最大LSN值。
               FLUSH_LSN:已经发起日志刷盘请求，但还没有真正写入联机Redo日志文件的最大LSN值。
              CKPT_LSN：检查点LSN所有LSN<=CKPT_LSN的物理事务修改的数据页，都已经从Buffer缓冲区写入磁盘。
              APPLY_lsn：备库重演LSN，表示备库已经重演完成的最大LSN。
       DN数据守护LSN分类：
              CLSN：与CUR_LSN保持一致，数据库已经分配的最大LSN值。
               FLSN：与FILE_LSN保持一致，已写入联机日志文件的LSN值。
               ALSN：与APPLY_LSN保持一致，备库已经重演完成的最大LSN值。
               SLSN：是Standby LSN的缩写，表示备库明确可重演的最大LSN值。
               KLSN：是Keep LSN的缩写，表示备库已经收到、但未明确是否可以重演的RLOG_PKG的最大LSN值。在读写分离集群中 KLSN == SLSN。
17.KEEP_PKG
        主库的RLOG_PKG日志通过实时归档机制发送到备库后，备库将最新收到的RLOG_PKG保存在内存中，不马上启动重演，这个RLOG_PKG我们称之为KEEP_PKG。即时备库 没有 KEEP_PKG。
18.归档
        归档是实现数据守护系统的重要技术手段，根据功能与实现方式的不同，DM数据库的归档可以分为5类：本地归档、远程归档、实时归档、即时归档和异步归档。
        本地归档：
               Redo日志本地归档（Local），就是将 Redo日志写入到本地归档日志文件的过程。
               保数据守护系统中所有节点的归档日志文件内容是完全一致的。
               本地归档日志文件不能被覆盖
        远程归档：
               归档日志发送到远程实例保存的归档方式，我们称为远程归档
        实时归档：
               实时归档（Realtime）将主库产生的Redo日志写入联机日志文件前通过MAL系统传递到备库。实时归档只在主库生效，一个主库可以配置 1~8个实时备库。
       执行流程：
               1.主库在Redo日志（RLOG_PKG）写入联机日志文件前，将Redo日志发送到备库
               2.备库收到Redo日志（RLOG_PKG）后标记为KEEP_PKG，将原KEEP_PKG加入日志重演任务系统，并马上响应主库，不需要等待Redo日志重演结束后再响 应主库。
               3.主库收到备库的响应消息，确认备库已经收到Redo日志后，再将Redo日志写入联机日志文件中。
        分类：
               事务一致模式
               主库事务提交触发 Redo日志刷盘和即时归档，备库收到主库发送的Redo日志，并重演完成后再响应主库。
        高性能模式
               与实时归档一样，备库收到主库发送的Redo日志后，马上响应主库，再启动日志重演。
               区别仅在于配置为实时归档时，dmarch.ini中的ARCH_WAIT_APPLY配置项默认值为0，即采用高性能模式。
        即时归档：
               即时归档（Timely）在主库将Redo日志写入联机日志文件后，通过MAL系统将Redo日志发送到备库。
        分类：
              事务一致模式
               主库事务提交触发 Redo日志刷盘和即时归档，备库收到主库发送的Redo日志，并重演完成后再响应主库。
               高性能模式
               与实时归档一样，备库收到主库发送的Redo日志后，马上响应主库，再启动日志重演。
       异步归档
              由主、备库上配置的定时器触发，根据异步备库的KEEP LSN信息，扫描本地归档目录获取Redo日志，并通过MAL系统将Redo日志发送到异步备库。

19.归档文件
       备库归档机制调整后，备库归档日志文件写入的并不是自己重演生成的Redo日志，而是直接将主库产生的 Redo日志写入到本地归档日志文件中。
       为了区分生成Redo日志和写入Redo日志的库，归档日志文件头增加了几个MAGIC字段：
       PMNT_MAGIC：永久魔数，用来唯一标识数据库，初始化数据库时生成并保持不变（DDL_CLONE还原库除外），数据守护集群中所有主备库的 PMNT_MAGIC是相 同的。
        DB_MAGIC：数据库魔数，数据库初始化时生成，数据库还原后重新生成新的DB_MAGIC，数据守护集群中所有主备库的 DB_MAGIC 是不同的。
        归档日志文件使用DB_MAGIC标识写入 Redo日志的库。
        SRC_DB_MAGIC：源库魔数，产生 Redo 日志数据库的 DB_MAGIC 值；主库归档日志文件中SRC_DB_MAGIC与 DB_MAGIC相同；备库归档日志文件中 SRC_DB_MAGIC与主库的 DB_MAGCI值相同。
20.归档状态
       本地归档、实时归档和即时归档均包含两种状态：Valid和 Invalid。
        异步归档只有一种归档状态：Valid。
       Valid：归档有效，正常执行各种数据库归档操作。
        Invalid：归档无效，主数据库不发送联机 Redo日志到备数据库。
21.OGUID
       数据守护唯一标识码。
       数据库的OGUID在MOUNT状态下有系统函数SP_SET_OGUIID设置，守护进程和监视器的OGUID值在配置文件中设定
        同一守护进程组中的所有数据库、守护进程和监视器，都必须配置相同的 OGUID值
       取值范围为 0~2147483647。
22.守护进程组
       配置了相同 OGUID的两个或多个守护进程，构成一个守护进程组。
23.组分裂
       同一守护进程组中，不同数据库实例的数据出现不一致，并且无法通过重演Redo日志重新同步数据的情况，我们称为组分裂。
       产生原因：
               1. 即时归档中，主库在将 Redo日志写入本地联机 Redo日志文件之后，发送 Redo日志到备库之前出现故障，导致主备库数据不一致，为了继续提供服务，执行 备库强制接管。此时，当故障主库重启后，就会引发组分裂。
               2. 故障备库重新完成数据同步之前，主库硬件故障，并且长时间无法恢复；在用户接受丢失部分数据情况下，为了尽快恢复数据库服务，执行备库强制接管，将备库切换为主库。此时，如果故障主库重启，也会造成组分裂。
       恢复方法：
               检测到组分裂后，守护进程会修改控制文件为分裂状态，被分裂出去的数据库需要通过备份还原等技术手段重新恢复。
24.脑裂
       脑裂是同一个守护进程组中同时出现两个或者多个活动主库，并且这些主库都接收用户请求，提供完整数据库服务。
       产生的主要原因：
        1.网络不稳定
        2.错误的人工干预。