企业官网建设流程全解析

简介：这是一套面向数据库管理员与运维人员的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 的吞吐量和内存缓存的按块命中效率，选型时可以参考下表。

判断当前库块大小，终端里可以进%SYS查看数据库属性：

// 进入系统命名空间，系统管理工具都在这个命名空间下 zn "%SYS" // 打开交互式数据库管理工具 do ^DATABASE

^DATABASE是 Caché 里沿用多年的数据库管理实用程序，按提示进入 Databases 列表，选择某个库就能看到路径、挂载状态、块大小、当前文件大小以及扩展设置。不需要记住全部交互项，关键是学会用这个入口做挂载、卸载和扩容。熟悉图形界面的话，管理门户（Management Portal）的 Databases 页面也能看到同样信息，不同版本菜单位置有差异，直接在门户搜索框输入 Databases 最快。

2.3 命名空间映射：增长不均衡的真正原因

在 Namespace 配置里，一个命名空间可以映射多个数据库：全局变量映射、例程映射、类映射分别指定来源。生产环境常见的不均衡，是某个全局变量被映射到一个独立的库，而运维不知道，结果这个库先写满，命名空间整体报错。

维护动作很明确：每次规划新库时，先在命名空间映射里确认目标全局变量的分布；判断容量时不能只盯一个 .db 文件，要看该命名空间关联的所有数据库总大小。门户里进入 Namespace 页面，逐个展开映射可以看到GLOBAL、ROUTINE、CLASS三种映射项。如果某个全局变量增长特别快，可以单独给它建库并映射，避免和其他数据争抢同一个文件的空闲块。

2.4 磁盘告警时：自动扩展与<DISKFULL>

Caché 数据库在创建时有一个"自动扩展"开关和扩展大小（Expansion Size）。当文件写满时，写进程会尝试按扩展大小扩大 .db 文件；如果所在磁盘没有剩余空间，或者目录权限不足，控制台日志会出现<DISKFULL>错误，严重时该数据库会被自动置为 Unmounted，业务直接中断。

处理顺序建议这样：

1. 通过do ^DATABASE或门户查看报错库所在磁盘剩余空间；
2. 确认扩展大小设置是否合理，不要用默认的小步长，否则每次扩展都在抢锁；
3. 如果是长期增长业务，直接把扩展大小改为一次扩大 10% 或更大固定值，减少扩展次数；
4. 检查是否有未提交事务卡住，导致数据库文件无法正常扩展；
5. 磁盘扩容后再次挂载数据库，然后查看控制台日志确认没有持续报错。

提示：Caché 的库文件大小绝大多数时候大于实际数据量，空块本来就留在文件内部。看到文件占满磁盘时，优先扩容磁盘或迁移数据库，不要试图手工截断一个正在使用的 .db 文件。

3. Caché 内存参数：全局缓存、WIJ 与锁的调优红线

3.1 四个内存区域分别管什么

Caché 实例启动后，内存主要分为全局缓存（Global Buffers）、例程缓存（Routine Buffers）、通用内存堆（gmheap）和写镜像日志（WIJ）。很多人把全局缓存当成"缓存"，以为调大了只是更耗内存，其实它直接决定每一次全局变量读写的磁盘命中率。WIJ 则是 Caché 区别于传统数据库的关键：它记录缓冲池中已被修改的块，系统崩溃后靠 WIJ 把脏块状态还原，保证磁盘上的块集合一致。

全局缓存不是一个可以随意加大就完事的参数。对 64G 内存的机器，全局缓存给到 16G 到 24G 在生产中很常见，但如果机器上还有其他数据库实例，就要留足操作系统文件缓存和 Caché 例程缓存的空间，否则会发生磁盘换页，性能反而下降。

3.2 调参入口：CPF 的 Memory 段

Caché 实例配置文件是cache.cpf，内存相关配置在[Memory]段。一个典型的配置片段如下：

[Memory] globals=8GB ; 全局缓存 routine=512MB ; 例程缓存 gmheap=2GB ; 通用内存堆 locksiz=10MB ; 锁表大小 wijsize=512MB ; 写镜像日志大小

字段名以你当前实例导出的默认配置为准，不同小版本和 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，到达故障点前的事务为止。不要跳过全量备份直接回放日志，那是灾难恢复的最后手段，日常恢复用手工日志回放的时间成本通常不可接受。

4.5 完整性检查：恢复前先证明文件健康

完整性检查工具在%SYS命名空间下执行：

// 进入系统命名空间 zn "%SYS" // 执行数据库完整性检查 do ^Integrity

交互式程序会要求选择数据库，检查块引用完整性、索引与数据一致性。发现错误时不要尝试在线修改块，先把该库恢复到最后一次可用备份。完整性检查在恢复演练中要放在"验证备份文件能读"之后，检查报告全部通过，才进入业务验证阶段。

提示：至少每半年把生产备份恢复到一台临时实例，记录恢复耗时和日志回放耗时。恢复演练真正暴露的通常不是备份文件损坏，而是备份目录空间不足、日志归档中断、目标机器字符集或系统参数不一致这三类问题。

5. 收到告警后再动手的三个 Caché 维护技巧

5.1 库文件不缩小：用截断而不是文件收缩

Caché 数据库文件删除数据后不变小，是因为空块还留在文件内部。只有文件尾部的连续空闲块可以被截断（Truncate），中间的空块即使被标记为空闲，也不会缩小文件体积。所以"删了大量数据，文件没小"是常态，不是 Bug。

操作上，在do ^DATABASE或门户 Databases 页面选择对应库执行 Truncate。截断前先看库的空闲空间分布：如果空块集中在文件尾部，截断效果明显；如果映射切入到库文件后部还有大量数据，截断只会释放很小一部分。这类操作建议在业务低峰执行，因为截断过程需要对库文件做短时独占处理。若空块分散，不要反复截断，考虑新建库、把全局变量映射指过去、迁移数据，迁移完成后更换映射关系。

5.2 低成本巡检三件套

控制台日志是 Caché 自报故障的第一出口。很多<DISKFULL>错误不是发生在数据库文件上，而是发生在日志目录或备份目录上。巡检脚本建议把"最近 24 小时控制台日志错误数"作为指标，错误数超过阈值就告警，而不是等到磁盘满。

5.3 日志盘满时的正确处置顺序

日志盘满时最忌讳直接删除.journal文件。正确顺序是：先确认最近一次全量备份完好，再手动切换当前日志，等待系统生成新日志文件，然后把已切换的旧日志按归档策略复制到备份目录，确认复制完整后再清理原文件。如果磁盘已经写满到无法切换，说明日志目录和数据库目录在同一个文件系统上，这是设计问题，需要调整目录布局而不是继续清理历史日志。

本文还有配套的精品资源，点击获取