简介围绕Cache数据库管理和维护的专题培训课件主要面向数据库管理员、运维人员及Caché初学者系统讲解InterSystems Caché的安装配置、日志机制、备份恢复、镜像服务与日常管理维护要点也适用于金融、医疗等行业中对高可用和并发读写要求较高的数据密集型业务场景。资源为一个PPT演示文稿压缩包大小2.65MB幻灯片围绕Caché核心概念、管理工具、缓存机制、终端调试等模块展开并配有安装流程与操作演示方便学员对照学习和实践。目前已有88人学习下载。通过这份培训课件读者可以全面了解Caché的启动停止、SQL Manager、Control Panel、Configuration Manager等常用管理工具理解Journal日志与Shadow镜像的配置思路并掌握使用Studio编写MAC/CLS程序、利用Terminal执行备份恢复、通过Explorer管理Global等实践技能为后续独立完成Caché数据库部署、监控调优和故障处理打下扎实基础。1. 把 Caché 数据库管理和维护当成“存储引擎管理”比当成“SQL 管理”更靠谱多数人第一次接手 Caché 数据库管理和维护时第一反应是打开 ODBC 驱动按关系数据库的习惯把表结构导出来再考虑备份和调优。这个思路错得并不明显却会在恢复时害你。Caché 的表、对象视图和索引都只是访问层底层真正落盘的是 globals——一种无 schema 的多维数组。你在 SQL 里看到的一行数据存储上可能是^Sample.PersonD(ID)这样的节点索引走的是另一棵 global。于是很多传统数据库优化手段在 Caché 上要么无效要么会放大写放大。这篇不是课件复述而是按运维交接的路径把存储、备份、日志、监控和自动化串起来让你能在生产环境直接对着终端操作。2. 管理 Caché 数据库前先建立 global、buffer、journal 三个坐标系2.1 global 是 Caché 的最终存储形态Caché 的持久化核心是 globals也就是全局多维数组。一个 global 的名字以^开头例如^Demo(Person,1,Name)。你执行的每条 SQL、每次对象保存最终都会被运行时转换为对 globals 的读写。默认映射规则里定义一个持久类Sample.Person系统通常会生成^Sample.PersonD放数据、^Sample.PersonI放索引这不是魔法而是 Caché 的存储约定。所以做数据库管理和维护时第一件要养成的习惯是不看表空间大小看 global 大小。下面的命令在 Caché 终端里打开全局大小分析工具;; 切换到管理命名空间 ZN %SYS ;; 启动 global 大小分析 D ^%GSIZE^%GSIZE是个老牌巡检工具进入后能按命名空间扫描所有 globals列出记录数、节点数和空间占用。常用场景是先全量扫一遍再把增长最快的几个 global 和业务表对账比如订单表对应的^Order.OrderD是不是和业务峰值吻合。参数方面扫描级别可以选“仅统计上级节点”还是“统计到叶节点”生产环境建议先跑后者虽然慢一点但可以一次性定位到深层子节点。下面这张对照表是 Caché 数据库管理和维护里最容易绕晕的映射关系业务概念存储层形态维护动作类Sample.Person数据 global^Sample.PersonD索引 global^Sample.PersonI用^%GSIZE巡检这两个 global 的大小SQL 表字段global 的节点路径确认表字段改动是否涉及旧节点读取类定义与例程存放在%SYS命名空间的代码数据库备份时永远不要漏掉%SYS临时计算数据临时 global如^CacheTemp重启后消失不能作为业务数据对待这里的易错点是很多人只盯一个 global^Sample.PersonD忽略了多个索引 global。重建索引时索引 global 会被大规模重写如果数据库分配空间不足会在日志里出现 “TEMP” 文件增长异常。^%GSIZE的意义就是帮你提前看到哪个索引节点过度膨胀。2.2 buffer pool 和共享内存的边界要找清楚Caché 的共享内存由几个区域组成常被运维混为一谈global buffer 池管理数据缓存routine buffer 池管理编译后的代码缓存gmheap 提供锁表等共享结构。一个常见故障是 gmheap 满了现象不是慢而是进程直接报 lock table full。很多维护手册会建议你先调大全局缓存但对小内存配置的机器gmheap 不足会更早暴露。查看共享内存运行情况最直接的是系统监控工具ZN %SYS D ^SYSMON进入^SYSMON后主界面会显示进程数、系统状态和缓存使用情况。InterSystems 体系里$SYS命名下可以继续查内存细分项。对 dba 来说最重要的判断是“空闲缓冲池太小”是否频繁出现。如果空闲缓冲池常小于 5%说明 global buffer 配置偏小需要去管理门户的 memory 配置里调整而不是盲目加操作系统内存。2.3 journal 是恢复生命线不是可选项Caché 的 journal 负责记录每一次写操作和 WIJWrite Image Journal配合保证崩溃后的一致性。WIJ 是数据库恢复的起点journal 则是从备份点将系统带到崩溃点的手段。理解这件事你才会明白为什么备份完成后要立刻切换 journal而不是让它从上线一直写到天荒地老。开启和维护 journal 的通用命令是;; 在 %SYS 命名空间执行 journal 管理工具 D ^JRNUTIL这个工具提供切换当前日志、删除旧日志、查看日志文件列表等能力。生产维护里标准动作是在每日备份成功后切换 journal然后清除超过保留期限的日志文件。这里有一个别忽略的点journal 和 WIJ 默认可能在同一个目录如果文件系统空间被日志写满最严重的不是业务中断而是崩溃恢复时缺少可用日志导致恢复窗口拉长。3. Caché 数据库管理和维护的主流程备份、恢复与日志处理3.1 在线备份用 ^BACKUP 而不是导出 SQLCaché 的在线备份采用数据库级快照方式备份过程中不需要停业务。和传统数据库的dump不同它不会把数据导出成 INSERT 语句而是把 database 文件复制出来同时记录备份开始时的 journal 位置。这样恢复时才能做一致性回放。最常见的操作方式是进入终端执行;; 打开实例终端切换 %SYS ZN %SYS ;; 调出备份工具 DO ^BACKUP备份工具会让你选择备份哪些库、备份目录和是否为外部备份做冻结处理。外部备份时^BACKUP会先冻结所有数据库写操作完成后再解冻。这里有一个关键参数journal 切换最好每次备份完成后自动切换 journal。也就是说每次完成的物理备份配合备份后的新 journal 文件才能构成一条可完整恢复的时间链。军团式意义上不要把备份文件只放一份^BACKUP的备份目录和 journal 目录最好在不同磁盘。一个容易忽略的动作是备份完成后验证%SYS库。%SYS里包含用户、权限、命名空间映射和代码库信息很多运维只勾选业务库结果整体恢复后业务库接入报权限错。正确做法是把所有库包括%SYS、USER和代码库全部纳入备份集。建议物业的备份策略表格维护项频率保留时间说明全量备份每日一次7~14 天使用^BACKUP在线方式journal 切换备份后与备份对齐防止日志无限增长备份文件校验每周一次记录校验结果抽查最近备份能否被^BACKUP识别恢复演练每季度一次保留演练报告在测试实例上从头恢复3.2 恢复顺序先还原备份再回放 journal恢复的正确顺序很机械化但顺序错了会前功尽弃。先启动^BACKUP选择 restore 功能把备份的数据库文件还原到目标目录。还原完成后如果备份点的日志与当前目标之间存在多次 journal 切换就要用^JRNUTIL逐个应用 journal。这也是为什么每次备份后必须切换日志——可以清晰定位每一条恢复链的起点。ZN %SYS ;; 还原备份文件 DO ^BACKUP ;; 回放 journal 日志 DO ^JRNUTIL^JRNUTIL里选择“apply journal”会让指定目录中的日志文件按顺序作用到目标库。一个现实坑是生产环境经常同时存在主节点和异步镜像节点日志文件路径在两端不一致。恢复时如果直接指定生产端路径会导致找不到文件。我会在恢复文档中导出journal文件名清单而不是仅写目录。恢复之后要做三件事第一在%SYS中检查数据库状态和挂载状态确认没有只读标记第二做完整性检查最轻量的是打开管理门户对应 database 页面第三检查 journal 是否回放到了最新位置可以通过日志文件末条记录的时间戳对比确认。3.3 日志管理别让 journal 撑爆磁盘很多 Caché 数据库管理和维护事故不是突发故障而是 journal 长期不清理导致磁盘被写满。journal 文件默认有一定的数量阈值但要养成主动看它的习惯。D ^JRNUTIL进入后选择日志文件浏览可以按日期排序识别出大文件和过期文件。清理时需要先确认该日志文件已经被完整包含在已有的备份链中否则删除等于切断恢复路径。清理之后建议做一次 journal 目录大小统计根本目标是让 journal 目录控制在数据卷大小的 10% 以内超出时优先考虑提升备份频率而不是简单扩容。4. 用系统监控和参数判断 Caché 数据库运行是否健康4.1 监控工具怎么组合使用Caché 自带的终端监控工具各有侧重常见的组合方式如下工具用途何时使用^SYSMON系统整体状态、进程、内存日常巡检尤其早高峰前^%GSIZEglobal 大小与分布每周抽查增长过快的库^LOCKTAB锁表信息SQL 慢查询或事务卡住时^PERFMON性能采样按时间段汇总性能基线对比、容量规划在执行监控命令前先掌握一个前提Caché 的锁往往不是表级锁而是对象或行级锁锁名里通常带 global 节点路径。所以你在 SQL 层看到一个“lock table full”错误很快能映射到具体 global。;; 查看锁表 D ^LOCKTAB^LOCKTAB会输出持有锁的进程、锁的类型和对应 global 节点。比如看到一个进程长期持有^Sample.PersonD的排他锁你就能确定它在执行批量更新或索引重建而不是简单的查询卡住。4.2 缓存命中率与 buffer 参数调整Caché 数据库管理和维护里缓存命中率是最先要看的关键指标。理论上缓存命中率达到 98% 以上磁盘随机读的压力才会小如果在 90% 以下徘徊先别急着加机器先检查是不是查询走了粗糙的全表扫描导致大量 unfiltered data 被拉进缓存。命中率可以从管理门户的 system monitor 看到也可以在^SYSMON界面观察。当命中率持续偏低优先看这三个参数参数影响常见误配置global buffer 大小数据缓存能力盲目撑满物理内存导致系统卡死routine buffer 大小代码缓存长期对 250G 库跑代码routine 不够引发频繁编译gmheap锁表和系统结构共享内存锁表报错时只会重启不会调参调整过程要循序渐进每次改动 10% 左右并在业务低峰期重启实例生效。重启前记录^LOCKTAB和当前全局缓存值方便重启后对比。4.3 用 SQL 侧反查性能问题虽然存储层是 global但 SQL 的调用仍然能暴露问题。对趋势类巡检我会把我常用的三条查询固定下来在管理门户的 SQL 界面执行按耗时排序查最近慢 SQL、按逻辑读次数查冗余索引、按命中次数查未走到索引的查询。这类查询在 Caché 的%SYS_PTools命名空间中尤其有用。它能告诉你某张表每次查询到底扫描了多少节点从而反推 global 层索引是否合理。一个需要避开的误区是不加限定条件就在 Caché SQL 上执行count(*)。对大数据表来说这个操作会遍历整个数据 global产生大量 buffer 脏页。正确做法是使用专门统计节点数的工具或控制条件到指定日期时间段再统计。5. 把维护动作沉淀成可复现的巡检清单5.1 终端巡检的最小模板我一般会把维护动作压缩成一个巡检脚本输出在一页报告中。脚本不一定复杂但必须覆盖三层存储层、日志层、进程层。存储层跑^%GSIZE日志层跑^JRNUTIL文件列表检查进程层跑^SYSMON。这比打开管理门户一个个点更快也能固定问题描述方式。5.2 日常巡检清单时间段巡检动作判断标准上班前检查磁盘和 journal 目录剩余空间剩余空间不低于数据卷 15%上班前^SYSMON查看缓存命中率命中率 ≥ 95%空闲缓冲池 5%午间低峰^%GSIZE扫描大 global单 global 日增长超过 5%确认业务原因晚间备份后切换 journal备份完成后必须看到新的 journal 文件生成周末抽查最近一次备份可恢复性在测试实例执行一次恢复流程这块就是日常数据库管理和维护里最有效的一招把不可见的事情做成定时动作。你不需要等到告警邮件只要每天盯住上面五个判断标准绝大多数问题在爆发前都会被看到。5.3 最终验证用备份目录里的双文件确认完整性完成备份后检查备份目录通常会出现两类主要产物一类是目标数据库的备份数据文件另一类是本次备份的 journal 文件。我每次都会确认这两个文件的时间戳是否匹配。时间戳相差超过一个实例启动周期说明备份过程中可能发生过非计划重启需要重新做一次完整备份。这份确认动作虽小却决定了恢复演练时到底能不能把你救回来。本文还有配套的精品资源点击获取 Caché数据库运维核心：从globals存储到备份恢复与监控调优
简介围绕Cache数据库管理和维护的专题培训课件主要面向数据库管理员、运维人员及Caché初学者系统讲解InterSystems Caché的安装配置、日志机制、备份恢复、镜像服务与日常管理维护要点也适用于金融、医疗等行业中对高可用和并发读写要求较高的数据密集型业务场景。资源为一个PPT演示文稿压缩包大小2.65MB幻灯片围绕Caché核心概念、管理工具、缓存机制、终端调试等模块展开并配有安装流程与操作演示方便学员对照学习和实践。目前已有88人学习下载。通过这份培训课件读者可以全面了解Caché的启动停止、SQL Manager、Control Panel、Configuration Manager等常用管理工具理解Journal日志与Shadow镜像的配置思路并掌握使用Studio编写MAC/CLS程序、利用Terminal执行备份恢复、通过Explorer管理Global等实践技能为后续独立完成Caché数据库部署、监控调优和故障处理打下扎实基础。1. 把 Caché 数据库管理和维护当成“存储引擎管理”比当成“SQL 管理”更靠谱多数人第一次接手 Caché 数据库管理和维护时第一反应是打开 ODBC 驱动按关系数据库的习惯把表结构导出来再考虑备份和调优。这个思路错得并不明显却会在恢复时害你。Caché 的表、对象视图和索引都只是访问层底层真正落盘的是 globals——一种无 schema 的多维数组。你在 SQL 里看到的一行数据存储上可能是^Sample.PersonD(ID)这样的节点索引走的是另一棵 global。于是很多传统数据库优化手段在 Caché 上要么无效要么会放大写放大。这篇不是课件复述而是按运维交接的路径把存储、备份、日志、监控和自动化串起来让你能在生产环境直接对着终端操作。2. 管理 Caché 数据库前先建立 global、buffer、journal 三个坐标系2.1 global 是 Caché 的最终存储形态Caché 的持久化核心是 globals也就是全局多维数组。一个 global 的名字以^开头例如^Demo(Person,1,Name)。你执行的每条 SQL、每次对象保存最终都会被运行时转换为对 globals 的读写。默认映射规则里定义一个持久类Sample.Person系统通常会生成^Sample.PersonD放数据、^Sample.PersonI放索引这不是魔法而是 Caché 的存储约定。所以做数据库管理和维护时第一件要养成的习惯是不看表空间大小看 global 大小。下面的命令在 Caché 终端里打开全局大小分析工具;; 切换到管理命名空间 ZN %SYS ;; 启动 global 大小分析 D ^%GSIZE^%GSIZE是个老牌巡检工具进入后能按命名空间扫描所有 globals列出记录数、节点数和空间占用。常用场景是先全量扫一遍再把增长最快的几个 global 和业务表对账比如订单表对应的^Order.OrderD是不是和业务峰值吻合。参数方面扫描级别可以选“仅统计上级节点”还是“统计到叶节点”生产环境建议先跑后者虽然慢一点但可以一次性定位到深层子节点。下面这张对照表是 Caché 数据库管理和维护里最容易绕晕的映射关系业务概念存储层形态维护动作类Sample.Person数据 global^Sample.PersonD索引 global^Sample.PersonI用^%GSIZE巡检这两个 global 的大小SQL 表字段global 的节点路径确认表字段改动是否涉及旧节点读取类定义与例程存放在%SYS命名空间的代码数据库备份时永远不要漏掉%SYS临时计算数据临时 global如^CacheTemp重启后消失不能作为业务数据对待这里的易错点是很多人只盯一个 global^Sample.PersonD忽略了多个索引 global。重建索引时索引 global 会被大规模重写如果数据库分配空间不足会在日志里出现 “TEMP” 文件增长异常。^%GSIZE的意义就是帮你提前看到哪个索引节点过度膨胀。2.2 buffer pool 和共享内存的边界要找清楚Caché 的共享内存由几个区域组成常被运维混为一谈global buffer 池管理数据缓存routine buffer 池管理编译后的代码缓存gmheap 提供锁表等共享结构。一个常见故障是 gmheap 满了现象不是慢而是进程直接报 lock table full。很多维护手册会建议你先调大全局缓存但对小内存配置的机器gmheap 不足会更早暴露。查看共享内存运行情况最直接的是系统监控工具ZN %SYS D ^SYSMON进入^SYSMON后主界面会显示进程数、系统状态和缓存使用情况。InterSystems 体系里$SYS命名下可以继续查内存细分项。对 dba 来说最重要的判断是“空闲缓冲池太小”是否频繁出现。如果空闲缓冲池常小于 5%说明 global buffer 配置偏小需要去管理门户的 memory 配置里调整而不是盲目加操作系统内存。2.3 journal 是恢复生命线不是可选项Caché 的 journal 负责记录每一次写操作和 WIJWrite Image Journal配合保证崩溃后的一致性。WIJ 是数据库恢复的起点journal 则是从备份点将系统带到崩溃点的手段。理解这件事你才会明白为什么备份完成后要立刻切换 journal而不是让它从上线一直写到天荒地老。开启和维护 journal 的通用命令是;; 在 %SYS 命名空间执行 journal 管理工具 D ^JRNUTIL这个工具提供切换当前日志、删除旧日志、查看日志文件列表等能力。生产维护里标准动作是在每日备份成功后切换 journal然后清除超过保留期限的日志文件。这里有一个别忽略的点journal 和 WIJ 默认可能在同一个目录如果文件系统空间被日志写满最严重的不是业务中断而是崩溃恢复时缺少可用日志导致恢复窗口拉长。3. Caché 数据库管理和维护的主流程备份、恢复与日志处理3.1 在线备份用 ^BACKUP 而不是导出 SQLCaché 的在线备份采用数据库级快照方式备份过程中不需要停业务。和传统数据库的dump不同它不会把数据导出成 INSERT 语句而是把 database 文件复制出来同时记录备份开始时的 journal 位置。这样恢复时才能做一致性回放。最常见的操作方式是进入终端执行;; 打开实例终端切换 %SYS ZN %SYS ;; 调出备份工具 DO ^BACKUP备份工具会让你选择备份哪些库、备份目录和是否为外部备份做冻结处理。外部备份时^BACKUP会先冻结所有数据库写操作完成后再解冻。这里有一个关键参数journal 切换最好每次备份完成后自动切换 journal。也就是说每次完成的物理备份配合备份后的新 journal 文件才能构成一条可完整恢复的时间链。军团式意义上不要把备份文件只放一份^BACKUP的备份目录和 journal 目录最好在不同磁盘。一个容易忽略的动作是备份完成后验证%SYS库。%SYS里包含用户、权限、命名空间映射和代码库信息很多运维只勾选业务库结果整体恢复后业务库接入报权限错。正确做法是把所有库包括%SYS、USER和代码库全部纳入备份集。建议物业的备份策略表格维护项频率保留时间说明全量备份每日一次7~14 天使用^BACKUP在线方式journal 切换备份后与备份对齐防止日志无限增长备份文件校验每周一次记录校验结果抽查最近备份能否被^BACKUP识别恢复演练每季度一次保留演练报告在测试实例上从头恢复3.2 恢复顺序先还原备份再回放 journal恢复的正确顺序很机械化但顺序错了会前功尽弃。先启动^BACKUP选择 restore 功能把备份的数据库文件还原到目标目录。还原完成后如果备份点的日志与当前目标之间存在多次 journal 切换就要用^JRNUTIL逐个应用 journal。这也是为什么每次备份后必须切换日志——可以清晰定位每一条恢复链的起点。ZN %SYS ;; 还原备份文件 DO ^BACKUP ;; 回放 journal 日志 DO ^JRNUTIL^JRNUTIL里选择“apply journal”会让指定目录中的日志文件按顺序作用到目标库。一个现实坑是生产环境经常同时存在主节点和异步镜像节点日志文件路径在两端不一致。恢复时如果直接指定生产端路径会导致找不到文件。我会在恢复文档中导出journal文件名清单而不是仅写目录。恢复之后要做三件事第一在%SYS中检查数据库状态和挂载状态确认没有只读标记第二做完整性检查最轻量的是打开管理门户对应 database 页面第三检查 journal 是否回放到了最新位置可以通过日志文件末条记录的时间戳对比确认。3.3 日志管理别让 journal 撑爆磁盘很多 Caché 数据库管理和维护事故不是突发故障而是 journal 长期不清理导致磁盘被写满。journal 文件默认有一定的数量阈值但要养成主动看它的习惯。D ^JRNUTIL进入后选择日志文件浏览可以按日期排序识别出大文件和过期文件。清理时需要先确认该日志文件已经被完整包含在已有的备份链中否则删除等于切断恢复路径。清理之后建议做一次 journal 目录大小统计根本目标是让 journal 目录控制在数据卷大小的 10% 以内超出时优先考虑提升备份频率而不是简单扩容。4. 用系统监控和参数判断 Caché 数据库运行是否健康4.1 监控工具怎么组合使用Caché 自带的终端监控工具各有侧重常见的组合方式如下工具用途何时使用^SYSMON系统整体状态、进程、内存日常巡检尤其早高峰前^%GSIZEglobal 大小与分布每周抽查增长过快的库^LOCKTAB锁表信息SQL 慢查询或事务卡住时^PERFMON性能采样按时间段汇总性能基线对比、容量规划在执行监控命令前先掌握一个前提Caché 的锁往往不是表级锁而是对象或行级锁锁名里通常带 global 节点路径。所以你在 SQL 层看到一个“lock table full”错误很快能映射到具体 global。;; 查看锁表 D ^LOCKTAB^LOCKTAB会输出持有锁的进程、锁的类型和对应 global 节点。比如看到一个进程长期持有^Sample.PersonD的排他锁你就能确定它在执行批量更新或索引重建而不是简单的查询卡住。4.2 缓存命中率与 buffer 参数调整Caché 数据库管理和维护里缓存命中率是最先要看的关键指标。理论上缓存命中率达到 98% 以上磁盘随机读的压力才会小如果在 90% 以下徘徊先别急着加机器先检查是不是查询走了粗糙的全表扫描导致大量 unfiltered data 被拉进缓存。命中率可以从管理门户的 system monitor 看到也可以在^SYSMON界面观察。当命中率持续偏低优先看这三个参数参数影响常见误配置global buffer 大小数据缓存能力盲目撑满物理内存导致系统卡死routine buffer 大小代码缓存长期对 250G 库跑代码routine 不够引发频繁编译gmheap锁表和系统结构共享内存锁表报错时只会重启不会调参调整过程要循序渐进每次改动 10% 左右并在业务低峰期重启实例生效。重启前记录^LOCKTAB和当前全局缓存值方便重启后对比。4.3 用 SQL 侧反查性能问题虽然存储层是 global但 SQL 的调用仍然能暴露问题。对趋势类巡检我会把我常用的三条查询固定下来在管理门户的 SQL 界面执行按耗时排序查最近慢 SQL、按逻辑读次数查冗余索引、按命中次数查未走到索引的查询。这类查询在 Caché 的%SYS_PTools命名空间中尤其有用。它能告诉你某张表每次查询到底扫描了多少节点从而反推 global 层索引是否合理。一个需要避开的误区是不加限定条件就在 Caché SQL 上执行count(*)。对大数据表来说这个操作会遍历整个数据 global产生大量 buffer 脏页。正确做法是使用专门统计节点数的工具或控制条件到指定日期时间段再统计。5. 把维护动作沉淀成可复现的巡检清单5.1 终端巡检的最小模板我一般会把维护动作压缩成一个巡检脚本输出在一页报告中。脚本不一定复杂但必须覆盖三层存储层、日志层、进程层。存储层跑^%GSIZE日志层跑^JRNUTIL文件列表检查进程层跑^SYSMON。这比打开管理门户一个个点更快也能固定问题描述方式。5.2 日常巡检清单时间段巡检动作判断标准上班前检查磁盘和 journal 目录剩余空间剩余空间不低于数据卷 15%上班前^SYSMON查看缓存命中率命中率 ≥ 95%空闲缓冲池 5%午间低峰^%GSIZE扫描大 global单 global 日增长超过 5%确认业务原因晚间备份后切换 journal备份完成后必须看到新的 journal 文件生成周末抽查最近一次备份可恢复性在测试实例执行一次恢复流程这块就是日常数据库管理和维护里最有效的一招把不可见的事情做成定时动作。你不需要等到告警邮件只要每天盯住上面五个判断标准绝大多数问题在爆发前都会被看到。5.3 最终验证用备份目录里的双文件确认完整性完成备份后检查备份目录通常会出现两类主要产物一类是目标数据库的备份数据文件另一类是本次备份的 journal 文件。我每次都会确认这两个文件的时间戳是否匹配。时间戳相差超过一个实例启动周期说明备份过程中可能发生过非计划重启需要重新做一次完整备份。这份确认动作虽小却决定了恢复演练时到底能不能把你救回来。本文还有配套的精品资源点击获取