简介这是一套面向数据库管理员与运维人员的Cache数据库Caché管理和维护专题培训课件。围绕InterSystems公司这款高性能、可扩展的对象关联型数据库课件从正确安装与配置开始逐步演示在Windows下的启动与停止操作深入讲解日志记录、备份恢复、镜像服务等运维核心环节并结合控制面板、配置管理器等工具帮助读者掌握数据库状态监控、内存与命名空间设置、缓存优化及常见故障排查方法。资源为1个PPT演示文稿压缩包大小为2.65MB内容结构紧凑、重点突出。目前已有88人学习。通过本课件学习者可系统建立Caché管理工具链如Studio、Terminal、Explorer、SQL Manager的完整认知理解全局变量缓存与数据库的交互机制积累从部署到日常维护的实战技能为支撑金融、医疗、电信等领域的高可用业务系统提供扎实参考。1. Caché 运维先丢掉 Oracle 习惯块、全局变量和日志才是本体从 Oracle 转过来管 Caché 的第一个月我几乎每天都在解释同一个问题为什么删了那么多数据库文件体积一点没降。Caché 没有表空间也没有收缩表段这种说法它的存储单位是块Block业务数据以全局变量Global这种多维稀疏数组落盘命名空间负责把逻辑视图和物理库组合起来日志Journal同时承担崩溃恢复和灾难恢复两条链路。这些差异决定了 Caché 数据库管理和维护真正要抓的三条线文件层面靠块管理做扩展与截断内存层面靠全局缓存、WIJ 和锁表调优数据安全层面靠在线备份与日志归档。下面按这三条线把落地路径讲清楚适合刚接手 Caché 的运维 DBA也适合要写医院信息科运维手册的同事。2. Caché 存储结构全局变量与命名空间映射的维护动作2.1 全局变量决定了库文件不释放这个前提Caché 的表最终由持久化类映射到全局变量例如^PATIENT(ID, 1)。全局变量按字典序在块中连续存放删除数据时只是把对应的块标记为空闲物理文件不会自动收缩。这和 InnoDB 的 B 树页复用不同回收空间必须由 Caché 自身的截断逻辑处理不能指望等数据库自动变小。所以管理和维护的第一步是先看清当前实例上有多少数据库文件.db、每个文件映射给了哪些命名空间。一个 Caché 实例默认有CACHE、USER、DOCBOOK等数据库医院生产环境通常是APP、HIS、ENSEMBLE这类自定义库。多个数据库通过命名空间Namespace组成一个逻辑空间比如HISDATA命名空间可能同时包含业务库和日志库的一部分全局变量。这里最常见的坑是以为一个命名空间就是一个库结果在扩容时只给其中一个 .db 加磁盘空间而另一个已经写满。2.2 块大小建库之后不能改的硬参数创建 Caché 数据库时可以选块大小常见选项有 8K、16K、32K、64K部分版本还保留 4K 选项默认一般是 8K。运行中的库块大小是固定的更改只能重建库再重新映射。块大小直接影响单次 I/O 的吞吐量和内存缓存的按块命中效率选型时可以参考下表。块大小典型场景维护上要注意的点4K / 8K传统 OLTP小事务随机读写多小事务占优但大块扫描时 I/O 次数会变多16K中等事务混合读写兼顾随机和顺序读新建库的常见选择32K / 64K大字段、BLOB、批量分析顺序读效率高但块缓冲命中粒度粗锁竞争可能放大判断当前库块大小终端里可以进%SYS查看数据库属性// 进入系统命名空间系统管理工具都在这个命名空间下 zn %SYS // 打开交互式数据库管理工具 do ^DATABASE^DATABASE是 Caché 里沿用多年的数据库管理实用程序按提示进入 Databases 列表选择某个库就能看到路径、挂载状态、块大小、当前文件大小以及扩展设置。不需要记住全部交互项关键是学会用这个入口做挂载、卸载和扩容。熟悉图形界面的话管理门户Management Portal的 Databases 页面也能看到同样信息不同版本菜单位置有差异直接在门户搜索框输入 Databases 最快。2.3 命名空间映射增长不均衡的真正原因在 Namespace 配置里一个命名空间可以映射多个数据库全局变量映射、例程映射、类映射分别指定来源。生产环境常见的不均衡是某个全局变量被映射到一个独立的库而运维不知道结果这个库先写满命名空间整体报错。维护动作很明确每次规划新库时先在命名空间映射里确认目标全局变量的分布判断容量时不能只盯一个 .db 文件要看该命名空间关联的所有数据库总大小。门户里进入 Namespace 页面逐个展开映射可以看到GLOBAL、ROUTINE、CLASS三种映射项。如果某个全局变量增长特别快可以单独给它建库并映射避免和其他数据争抢同一个文件的空闲块。2.4 磁盘告警时自动扩展与DISKFULLCaché 数据库在创建时有一个自动扩展开关和扩展大小Expansion Size。当文件写满时写进程会尝试按扩展大小扩大 .db 文件如果所在磁盘没有剩余空间或者目录权限不足控制台日志会出现DISKFULL错误严重时该数据库会被自动置为 Unmounted业务直接中断。处理顺序建议这样通过do ^DATABASE或门户查看报错库所在磁盘剩余空间确认扩展大小设置是否合理不要用默认的小步长否则每次扩展都在抢锁如果是长期增长业务直接把扩展大小改为一次扩大 10% 或更大固定值减少扩展次数检查是否有未提交事务卡住导致数据库文件无法正常扩展磁盘扩容后再次挂载数据库然后查看控制台日志确认没有持续报错。提示Caché 的库文件大小绝大多数时候大于实际数据量空块本来就留在文件内部。看到文件占满磁盘时优先扩容磁盘或迁移数据库不要试图手工截断一个正在使用的 .db 文件。3. Caché 内存参数全局缓存、WIJ 与锁的调优红线3.1 四个内存区域分别管什么Caché 实例启动后内存主要分为全局缓存Global Buffers、例程缓存Routine Buffers、通用内存堆gmheap和写镜像日志WIJ。很多人把全局缓存当成缓存以为调大了只是更耗内存其实它直接决定每一次全局变量读写的磁盘命中率。WIJ 则是 Caché 区别于传统数据库的关键它记录缓冲池中已被修改的块系统崩溃后靠 WIJ 把脏块状态还原保证磁盘上的块集合一致。参数通俗作用给小的症状给大的代价globals数据库块缓冲相当于 Buffer Cache磁盘读高GLOSTAT miss 率高占用大量内存可能引发系统级换页routine编译例程缓存首次调用变慢热路径代码反复编译通常几百 MB 足够再大收益不明显gmheap锁表、共享结构、系统监控锁分配失败、监控异常占内存且需要重启生效locksiz锁表条目内存LOCK超时、锁不足报错占内存需要重启生效wijsizeWIJ 缓冲大小大事务写集中时写守护进程阻塞恢复时回放时间变长全局缓存不是一个可以随意加大就完事的参数。对 64G 内存的机器全局缓存给到 16G 到 24G 在生产中很常见但如果机器上还有其他数据库实例就要留足操作系统文件缓存和 Caché 例程缓存的空间否则会发生磁盘换页性能反而下降。3.2 调参入口CPF 的 Memory 段Caché 实例配置文件是cache.cpf内存相关配置在[Memory]段。一个典型的配置片段如下[Memory] globals8GB ; 全局缓存 routine512MB ; 例程缓存 gmheap2GB ; 通用内存堆 locksiz10MB ; 锁表大小 wijsize512MB ; 写镜像日志大小字段名以你当前实例导出的默认配置为准不同小版本和 IRIS 之间略有差异。修改后需要重启实例生效。全局缓存可以在管理门户的 Memory 页面做动态调整但 gmheap、locksiz 这类共享结构在启动后基本固定错误地改小了会在高并发时直接报错。判断当前值是否够用最直接的办法是看系统监控里的内存段状态。如果gmheap在运行几天后接近上限说明进程通信或锁结构比你预想的稠密这类问题单靠重启只是暂时缓解要找到占用共享堆的对象通常是 ECP 连接数或锁表过长。3.3 用 GLOSTAT 判断全局缓存够不够终端里执行do ^GLOSTAT会出现一个持续滚屏的统计输出展示全局变量引用次数、写次数、目录缓冲命中情况。这个工具不要求理解每一列关键是看 miss 比例在业务高峰持续采样 5 到 10 分钟如果全局引用次数很高而命中率始终上不去说明全局缓存偏小。do ^GLOSTAT的输出里还有一个容易被忽略的点它会把数据库目录缓冲和全局块缓冲分开统计。目录缓冲Directory Cache负责定位块的位置如果这部分的 miss 率高说明全局块分布太散很多全局变量分散在大量数据库文件中这时候把高度关联的全局映射到同一个数据库里比单纯加大缓存更有效。3.4 锁一半的性能故障都在锁没设好Caché 的锁按全局变量节点计数跨进程修改同一个节点时锁表占用会上升。锁表配置不足时应用层拿到的是LOCK超时错误而不是数据库 IO 问题。日常维护要看两个页面管理门户的 Processes 页面看会话状态和当前执行语句Locks 页面看锁持有者和等待者。如果频繁出现Lock Table Full类提示优先确认应用代码是否在长事务里持有锁比如先lock ^Order(2025-01)再做大量写入最后才释放。开发侧的正确做法是把锁范围和事务边界对齐用tstart/tcommit包裹并在try/catch里保证释放。运维侧不要把查锁当成临时操作建议每天定时抓一次锁表快照记录锁峰值再决定是否调大locksiz。注意锁表参数改大后必须重启。不要用重启机器清锁当作处理手段那只适合紧急恢复锁重建后业务还会卡在同样位置。4. Caché 备份、日志与恢复一次恢复演练定生死4.1 为什么备份必须单独安排Caché 没有直接复制 .db 文件就能用作备份的说法。运行中的库文件处于动态写状态裸拷贝出来的块集合可能前后不一致。在线备份Online Backup利用 WIJ 和日志的一致性机制可以在业务不停机的情况下备份一组数据库冷备份则必须停实例再复制文件。两类备份都依赖日志来补足备份时间点到故障时间点之间的变更。生产环境的基础备份策略是三件套实例级一致性备份、日志归档、定期恢复演练。只做文件拷贝、不做日志归档等于只备份到某个时间点之前日常 Caché 运维里最常见的恢复失败不是备份文件损坏而是日志链断了。4.2 在线备份的最小操作流程在管理门户的 Backup 页面可以创建备份任务选择要备份的数据库生成.cbk文件。也可以用经典命令行方式// 进入系统命名空间 zn %SYS // 进入备份管理实用程序 do ^BACKUP^BACKUP会列出实例上的数据库按选择执行全量备份输出备份文件名和完成状态。参数方面要注意备份目录Backup Directory生产环境建议把备份目录放在独立磁盘上避免和数据库文件或日志目录相互挤占空间。备份之后立刻做一件事在门户 Restore 页面选择刚才的.cbk文件执行 Verify 验证。验证通过只能证明文件可读不能证明数据逻辑时间点完整但它是恢复前成本最低的一道关卡。4.3 Journal 日志恢复链的延长线Caché 的 Journal 记录数据库每一次变更是崩溃恢复和灾难恢复的共同基础。运维上要处理的 Journal 问题有三个目录位置、切换时机、归档清理。日志目录默认在实例 mgr 下应该单独放到另一块磁盘。如果日志目录和数据库目录在同一个文件系统上数据库写满磁盘时日志也写不进去恢复链就断了。Journal 切换可以按时间或大小触发也可以手动强制切换。在终端里do ^JRNUTIL进入日志管理实用程序可以查看当前日志状态、执行切换和清理管理门户对应位置是 Journal 页面。清理日志有一个不能突破的前提某一卷日志只有在它之前的所有日志都完整归档、并且对应的全量备份链完整时才允许删除。删日志省出来的空间远小于恢复失败造成的停机时间。建议配置自动归档策略把切换下来的日志复制到备份磁盘或磁带归档完成后再由系统按保留周期清理。4.4 备份类型选型与恢复顺序备份类型适用场景恢复时还需要什么冷备份计划停机窗口停机后日志回放在线备份日常全量备份备份后的 Journal 日志日志归档配套全量备份做增量恢复最近全量备份镜像Mirror高可用主备切换不需要常规恢复但误删会同步恢复顺序固定为先恢复最近一次全量备份再按时间顺序回放该备份之后的 Journal到达故障点前的事务为止。不要跳过全量备份直接回放日志那是灾难恢复的最后手段日常恢复用手工日志回放的时间成本通常不可接受。4.5 完整性检查恢复前先证明文件健康完整性检查工具在%SYS命名空间下执行// 进入系统命名空间 zn %SYS // 执行数据库完整性检查 do ^Integrity交互式程序会要求选择数据库检查块引用完整性、索引与数据一致性。发现错误时不要尝试在线修改块先把该库恢复到最后一次可用备份。完整性检查在恢复演练中要放在验证备份文件能读之后检查报告全部通过才进入业务验证阶段。提示至少每半年把生产备份恢复到一台临时实例记录恢复耗时和日志回放耗时。恢复演练真正暴露的通常不是备份文件损坏而是备份目录空间不足、日志归档中断、目标机器字符集或系统参数不一致这三类问题。5. 收到告警后再动手的三个 Caché 维护技巧5.1 库文件不缩小用截断而不是文件收缩Caché 数据库文件删除数据后不变小是因为空块还留在文件内部。只有文件尾部的连续空闲块可以被截断Truncate中间的空块即使被标记为空闲也不会缩小文件体积。所以删了大量数据文件没小是常态不是 Bug。操作上在do ^DATABASE或门户 Databases 页面选择对应库执行 Truncate。截断前先看库的空闲空间分布如果空块集中在文件尾部截断效果明显如果映射切入到库文件后部还有大量数据截断只会释放很小一部分。这类操作建议在业务低峰执行因为截断过程需要对库文件做短时独占处理。若空块分散不要反复截断考虑新建库、把全局变量映射指过去、迁移数据迁移完成后更换映射关系。5.2 低成本巡检三件套检查项命令 / 位置观察重点控制台日志System Logs Console Log是否有DISKFULL、DATABASE、WIJ 相关报错全局缓存命中do ^GLOSTAT高峰时段持续 miss 比例是否偏高日志目录使用率Journal 页面 / 磁盘 df日志文件是否在预期保留期内快速增长控制台日志是 Caché 自报故障的第一出口。很多DISKFULL错误不是发生在数据库文件上而是发生在日志目录或备份目录上。巡检脚本建议把最近 24 小时控制台日志错误数作为指标错误数超过阈值就告警而不是等到磁盘满。5.3 日志盘满时的正确处置顺序日志盘满时最忌讳直接删除.journal文件。正确顺序是先确认最近一次全量备份完好再手动切换当前日志等待系统生成新日志文件然后把已切换的旧日志按归档策略复制到备份目录确认复制完整后再清理原文件。如果磁盘已经写满到无法切换说明日志目录和数据库目录在同一个文件系统上这是设计问题需要调整目录布局而不是继续清理历史日志。本文还有配套的精品资源点击获取 Caché数据库运维核心：全局变量、日志与备份恢复实践
简介这是一套面向数据库管理员与运维人员的Cache数据库Caché管理和维护专题培训课件。围绕InterSystems公司这款高性能、可扩展的对象关联型数据库课件从正确安装与配置开始逐步演示在Windows下的启动与停止操作深入讲解日志记录、备份恢复、镜像服务等运维核心环节并结合控制面板、配置管理器等工具帮助读者掌握数据库状态监控、内存与命名空间设置、缓存优化及常见故障排查方法。资源为1个PPT演示文稿压缩包大小为2.65MB内容结构紧凑、重点突出。目前已有88人学习。通过本课件学习者可系统建立Caché管理工具链如Studio、Terminal、Explorer、SQL Manager的完整认知理解全局变量缓存与数据库的交互机制积累从部署到日常维护的实战技能为支撑金融、医疗、电信等领域的高可用业务系统提供扎实参考。1. Caché 运维先丢掉 Oracle 习惯块、全局变量和日志才是本体从 Oracle 转过来管 Caché 的第一个月我几乎每天都在解释同一个问题为什么删了那么多数据库文件体积一点没降。Caché 没有表空间也没有收缩表段这种说法它的存储单位是块Block业务数据以全局变量Global这种多维稀疏数组落盘命名空间负责把逻辑视图和物理库组合起来日志Journal同时承担崩溃恢复和灾难恢复两条链路。这些差异决定了 Caché 数据库管理和维护真正要抓的三条线文件层面靠块管理做扩展与截断内存层面靠全局缓存、WIJ 和锁表调优数据安全层面靠在线备份与日志归档。下面按这三条线把落地路径讲清楚适合刚接手 Caché 的运维 DBA也适合要写医院信息科运维手册的同事。2. Caché 存储结构全局变量与命名空间映射的维护动作2.1 全局变量决定了库文件不释放这个前提Caché 的表最终由持久化类映射到全局变量例如^PATIENT(ID, 1)。全局变量按字典序在块中连续存放删除数据时只是把对应的块标记为空闲物理文件不会自动收缩。这和 InnoDB 的 B 树页复用不同回收空间必须由 Caché 自身的截断逻辑处理不能指望等数据库自动变小。所以管理和维护的第一步是先看清当前实例上有多少数据库文件.db、每个文件映射给了哪些命名空间。一个 Caché 实例默认有CACHE、USER、DOCBOOK等数据库医院生产环境通常是APP、HIS、ENSEMBLE这类自定义库。多个数据库通过命名空间Namespace组成一个逻辑空间比如HISDATA命名空间可能同时包含业务库和日志库的一部分全局变量。这里最常见的坑是以为一个命名空间就是一个库结果在扩容时只给其中一个 .db 加磁盘空间而另一个已经写满。2.2 块大小建库之后不能改的硬参数创建 Caché 数据库时可以选块大小常见选项有 8K、16K、32K、64K部分版本还保留 4K 选项默认一般是 8K。运行中的库块大小是固定的更改只能重建库再重新映射。块大小直接影响单次 I/O 的吞吐量和内存缓存的按块命中效率选型时可以参考下表。块大小典型场景维护上要注意的点4K / 8K传统 OLTP小事务随机读写多小事务占优但大块扫描时 I/O 次数会变多16K中等事务混合读写兼顾随机和顺序读新建库的常见选择32K / 64K大字段、BLOB、批量分析顺序读效率高但块缓冲命中粒度粗锁竞争可能放大判断当前库块大小终端里可以进%SYS查看数据库属性// 进入系统命名空间系统管理工具都在这个命名空间下 zn %SYS // 打开交互式数据库管理工具 do ^DATABASE^DATABASE是 Caché 里沿用多年的数据库管理实用程序按提示进入 Databases 列表选择某个库就能看到路径、挂载状态、块大小、当前文件大小以及扩展设置。不需要记住全部交互项关键是学会用这个入口做挂载、卸载和扩容。熟悉图形界面的话管理门户Management Portal的 Databases 页面也能看到同样信息不同版本菜单位置有差异直接在门户搜索框输入 Databases 最快。2.3 命名空间映射增长不均衡的真正原因在 Namespace 配置里一个命名空间可以映射多个数据库全局变量映射、例程映射、类映射分别指定来源。生产环境常见的不均衡是某个全局变量被映射到一个独立的库而运维不知道结果这个库先写满命名空间整体报错。维护动作很明确每次规划新库时先在命名空间映射里确认目标全局变量的分布判断容量时不能只盯一个 .db 文件要看该命名空间关联的所有数据库总大小。门户里进入 Namespace 页面逐个展开映射可以看到GLOBAL、ROUTINE、CLASS三种映射项。如果某个全局变量增长特别快可以单独给它建库并映射避免和其他数据争抢同一个文件的空闲块。2.4 磁盘告警时自动扩展与DISKFULLCaché 数据库在创建时有一个自动扩展开关和扩展大小Expansion Size。当文件写满时写进程会尝试按扩展大小扩大 .db 文件如果所在磁盘没有剩余空间或者目录权限不足控制台日志会出现DISKFULL错误严重时该数据库会被自动置为 Unmounted业务直接中断。处理顺序建议这样通过do ^DATABASE或门户查看报错库所在磁盘剩余空间确认扩展大小设置是否合理不要用默认的小步长否则每次扩展都在抢锁如果是长期增长业务直接把扩展大小改为一次扩大 10% 或更大固定值减少扩展次数检查是否有未提交事务卡住导致数据库文件无法正常扩展磁盘扩容后再次挂载数据库然后查看控制台日志确认没有持续报错。提示Caché 的库文件大小绝大多数时候大于实际数据量空块本来就留在文件内部。看到文件占满磁盘时优先扩容磁盘或迁移数据库不要试图手工截断一个正在使用的 .db 文件。3. Caché 内存参数全局缓存、WIJ 与锁的调优红线3.1 四个内存区域分别管什么Caché 实例启动后内存主要分为全局缓存Global Buffers、例程缓存Routine Buffers、通用内存堆gmheap和写镜像日志WIJ。很多人把全局缓存当成缓存以为调大了只是更耗内存其实它直接决定每一次全局变量读写的磁盘命中率。WIJ 则是 Caché 区别于传统数据库的关键它记录缓冲池中已被修改的块系统崩溃后靠 WIJ 把脏块状态还原保证磁盘上的块集合一致。参数通俗作用给小的症状给大的代价globals数据库块缓冲相当于 Buffer Cache磁盘读高GLOSTAT miss 率高占用大量内存可能引发系统级换页routine编译例程缓存首次调用变慢热路径代码反复编译通常几百 MB 足够再大收益不明显gmheap锁表、共享结构、系统监控锁分配失败、监控异常占内存且需要重启生效locksiz锁表条目内存LOCK超时、锁不足报错占内存需要重启生效wijsizeWIJ 缓冲大小大事务写集中时写守护进程阻塞恢复时回放时间变长全局缓存不是一个可以随意加大就完事的参数。对 64G 内存的机器全局缓存给到 16G 到 24G 在生产中很常见但如果机器上还有其他数据库实例就要留足操作系统文件缓存和 Caché 例程缓存的空间否则会发生磁盘换页性能反而下降。3.2 调参入口CPF 的 Memory 段Caché 实例配置文件是cache.cpf内存相关配置在[Memory]段。一个典型的配置片段如下[Memory] globals8GB ; 全局缓存 routine512MB ; 例程缓存 gmheap2GB ; 通用内存堆 locksiz10MB ; 锁表大小 wijsize512MB ; 写镜像日志大小字段名以你当前实例导出的默认配置为准不同小版本和 IRIS 之间略有差异。修改后需要重启实例生效。全局缓存可以在管理门户的 Memory 页面做动态调整但 gmheap、locksiz 这类共享结构在启动后基本固定错误地改小了会在高并发时直接报错。判断当前值是否够用最直接的办法是看系统监控里的内存段状态。如果gmheap在运行几天后接近上限说明进程通信或锁结构比你预想的稠密这类问题单靠重启只是暂时缓解要找到占用共享堆的对象通常是 ECP 连接数或锁表过长。3.3 用 GLOSTAT 判断全局缓存够不够终端里执行do ^GLOSTAT会出现一个持续滚屏的统计输出展示全局变量引用次数、写次数、目录缓冲命中情况。这个工具不要求理解每一列关键是看 miss 比例在业务高峰持续采样 5 到 10 分钟如果全局引用次数很高而命中率始终上不去说明全局缓存偏小。do ^GLOSTAT的输出里还有一个容易被忽略的点它会把数据库目录缓冲和全局块缓冲分开统计。目录缓冲Directory Cache负责定位块的位置如果这部分的 miss 率高说明全局块分布太散很多全局变量分散在大量数据库文件中这时候把高度关联的全局映射到同一个数据库里比单纯加大缓存更有效。3.4 锁一半的性能故障都在锁没设好Caché 的锁按全局变量节点计数跨进程修改同一个节点时锁表占用会上升。锁表配置不足时应用层拿到的是LOCK超时错误而不是数据库 IO 问题。日常维护要看两个页面管理门户的 Processes 页面看会话状态和当前执行语句Locks 页面看锁持有者和等待者。如果频繁出现Lock Table Full类提示优先确认应用代码是否在长事务里持有锁比如先lock ^Order(2025-01)再做大量写入最后才释放。开发侧的正确做法是把锁范围和事务边界对齐用tstart/tcommit包裹并在try/catch里保证释放。运维侧不要把查锁当成临时操作建议每天定时抓一次锁表快照记录锁峰值再决定是否调大locksiz。注意锁表参数改大后必须重启。不要用重启机器清锁当作处理手段那只适合紧急恢复锁重建后业务还会卡在同样位置。4. Caché 备份、日志与恢复一次恢复演练定生死4.1 为什么备份必须单独安排Caché 没有直接复制 .db 文件就能用作备份的说法。运行中的库文件处于动态写状态裸拷贝出来的块集合可能前后不一致。在线备份Online Backup利用 WIJ 和日志的一致性机制可以在业务不停机的情况下备份一组数据库冷备份则必须停实例再复制文件。两类备份都依赖日志来补足备份时间点到故障时间点之间的变更。生产环境的基础备份策略是三件套实例级一致性备份、日志归档、定期恢复演练。只做文件拷贝、不做日志归档等于只备份到某个时间点之前日常 Caché 运维里最常见的恢复失败不是备份文件损坏而是日志链断了。4.2 在线备份的最小操作流程在管理门户的 Backup 页面可以创建备份任务选择要备份的数据库生成.cbk文件。也可以用经典命令行方式// 进入系统命名空间 zn %SYS // 进入备份管理实用程序 do ^BACKUP^BACKUP会列出实例上的数据库按选择执行全量备份输出备份文件名和完成状态。参数方面要注意备份目录Backup Directory生产环境建议把备份目录放在独立磁盘上避免和数据库文件或日志目录相互挤占空间。备份之后立刻做一件事在门户 Restore 页面选择刚才的.cbk文件执行 Verify 验证。验证通过只能证明文件可读不能证明数据逻辑时间点完整但它是恢复前成本最低的一道关卡。4.3 Journal 日志恢复链的延长线Caché 的 Journal 记录数据库每一次变更是崩溃恢复和灾难恢复的共同基础。运维上要处理的 Journal 问题有三个目录位置、切换时机、归档清理。日志目录默认在实例 mgr 下应该单独放到另一块磁盘。如果日志目录和数据库目录在同一个文件系统上数据库写满磁盘时日志也写不进去恢复链就断了。Journal 切换可以按时间或大小触发也可以手动强制切换。在终端里do ^JRNUTIL进入日志管理实用程序可以查看当前日志状态、执行切换和清理管理门户对应位置是 Journal 页面。清理日志有一个不能突破的前提某一卷日志只有在它之前的所有日志都完整归档、并且对应的全量备份链完整时才允许删除。删日志省出来的空间远小于恢复失败造成的停机时间。建议配置自动归档策略把切换下来的日志复制到备份磁盘或磁带归档完成后再由系统按保留周期清理。4.4 备份类型选型与恢复顺序备份类型适用场景恢复时还需要什么冷备份计划停机窗口停机后日志回放在线备份日常全量备份备份后的 Journal 日志日志归档配套全量备份做增量恢复最近全量备份镜像Mirror高可用主备切换不需要常规恢复但误删会同步恢复顺序固定为先恢复最近一次全量备份再按时间顺序回放该备份之后的 Journal到达故障点前的事务为止。不要跳过全量备份直接回放日志那是灾难恢复的最后手段日常恢复用手工日志回放的时间成本通常不可接受。4.5 完整性检查恢复前先证明文件健康完整性检查工具在%SYS命名空间下执行// 进入系统命名空间 zn %SYS // 执行数据库完整性检查 do ^Integrity交互式程序会要求选择数据库检查块引用完整性、索引与数据一致性。发现错误时不要尝试在线修改块先把该库恢复到最后一次可用备份。完整性检查在恢复演练中要放在验证备份文件能读之后检查报告全部通过才进入业务验证阶段。提示至少每半年把生产备份恢复到一台临时实例记录恢复耗时和日志回放耗时。恢复演练真正暴露的通常不是备份文件损坏而是备份目录空间不足、日志归档中断、目标机器字符集或系统参数不一致这三类问题。5. 收到告警后再动手的三个 Caché 维护技巧5.1 库文件不缩小用截断而不是文件收缩Caché 数据库文件删除数据后不变小是因为空块还留在文件内部。只有文件尾部的连续空闲块可以被截断Truncate中间的空块即使被标记为空闲也不会缩小文件体积。所以删了大量数据文件没小是常态不是 Bug。操作上在do ^DATABASE或门户 Databases 页面选择对应库执行 Truncate。截断前先看库的空闲空间分布如果空块集中在文件尾部截断效果明显如果映射切入到库文件后部还有大量数据截断只会释放很小一部分。这类操作建议在业务低峰执行因为截断过程需要对库文件做短时独占处理。若空块分散不要反复截断考虑新建库、把全局变量映射指过去、迁移数据迁移完成后更换映射关系。5.2 低成本巡检三件套检查项命令 / 位置观察重点控制台日志System Logs Console Log是否有DISKFULL、DATABASE、WIJ 相关报错全局缓存命中do ^GLOSTAT高峰时段持续 miss 比例是否偏高日志目录使用率Journal 页面 / 磁盘 df日志文件是否在预期保留期内快速增长控制台日志是 Caché 自报故障的第一出口。很多DISKFULL错误不是发生在数据库文件上而是发生在日志目录或备份目录上。巡检脚本建议把最近 24 小时控制台日志错误数作为指标错误数超过阈值就告警而不是等到磁盘满。5.3 日志盘满时的正确处置顺序日志盘满时最忌讳直接删除.journal文件。正确顺序是先确认最近一次全量备份完好再手动切换当前日志等待系统生成新日志文件然后把已切换的旧日志按归档策略复制到备份目录确认复制完整后再清理原文件。如果磁盘已经写满到无法切换说明日志目录和数据库目录在同一个文件系统上这是设计问题需要调整目录布局而不是继续清理历史日志。本文还有配套的精品资源点击获取