泛微 Ecology SQL Server 数据库运维三板斧:全量备份 / 收缩日志 / 还原

本文命令基于 SQL Server 2016+ 测试。日志收缩效果与数据库 recovery model 强相关,操作前务必确认当前模式。

一、全量备份

基本命令

BACKUP DATABASE ecology
TO DISK = 'D:\bak\ecology_full_20250816.bak'
WITH INIT,                -- 覆盖目标文件中的所有现有备份集
     STATS = 10,          -- 每完成 10% 输出一次进度
     COMPRESSION;         -- 启用备份压缩,通常节省 80% 磁盘空间

三个参数的含义:

⚠️ INIT 会删除目标文件中的所有历史备份集。如果同一 .bak 文件里有差异备份(differential backup)或日志备份(log backup),执行 INIT 后这些备份集永久丢失。泛微 Ecology 通常只做全量备份,这种情况下 INIT 是安全的。

💡 建议的备份命名规范:ecology_full_YYYYMMDD.bak —— 日期在文件名里,不用 INIT 也能通过文件名区分版本。生产环境推荐 每日全量 + 每 15 分钟日志备份 的组合。

备份到网络路径(推荐做法)

BACKUP DATABASE ecology
TO DISK = '\\NASServer\SQLBackup\ecology_full_20250816.bak'
WITH COMPRESSION,
     STATS = 10;

💡 把备份写到独立存储而不是数据库服务器本地盘,可以防止服务器硬盘故障导致备份一起丢。泛微 Ecology 数据库通常 50GB~200GB,建议 NAS 留至少 2 倍数据库大小的空间。

二、收缩事务日志

核心前提:只有 SIMPLE 恢复模型的数据库,日志才能被 SHRINKFILE 真正收缩。FULL 恢复模型的数据库,日志在 LOG_BACKUP 之前永远不会真正释放空间。

第一步:备份(或截断)事务日志

有备份空间 → 标准日志备份:

BACKUP LOG ecology
TO DISK = 'D:\bak\ecology_log_20250816.trn'
WITH COMPRESSION;

没有备份空间 → 丢弃日志(高风险,仅紧急释放空间时使用):

-- ⚠️ 危险:此命令不生成日志备份,截断后无法做 point-in-time 恢复
-- 仅在磁盘即将爆满、无法立即做日志备份时临时使用
BACKUP LOG ecology TO DISK = 'NUL';

⚠️ BACKUP LOG TO NUL 会永久丢失日志链。一旦执行,此数据库只能在最近一次日志备份的时间点之后恢复,无法再做 point-in-time 恢复。生产库严禁使用,除非磁盘已满到连 SSMS 都打不开。

💡 正确做法:如果磁盘紧张,优先增大备份盘或改用压缩备份,而不是截断日志。COMPRESSION 参数通常能让 .trn 文件比数据文件小 5~10 倍。

第二步:收缩日志文件

USE ecology;
GO
DBCC SHRINKFILE (ecology_Log, 20480);   -- 目标收缩到 20 MB (单位:页,1页=8KB)

💡 DBCC SHRINKFILE 的单位是页(8KB):20480 页 = 20480 × 8KB = 163,840KB ≈ 160MB,不是 20MB。如果想让日志收缩到真正 20MB,应该用 2560(20MB ÷ 8KB/页)。

💡 SHRINKFILE 会从日志文件末尾向前推移已使用的 VLFs(virtual log files,虚拟日志文件),不会删除仍在使用的日志,所以实际收缩结果可能比目标大——这是正常行为。

第三步:查看日志空间使用情况

DBCC SQLPERF(LOGSPACE);

输出示例:

Database Name   Log Size (MB)   Log Space Used (%)   Status
--------------------------------------------------------------
ecology         20480.00        3.27                 0

💡 关键列是 Log Space Used (%)。如果日志已收缩到目标大小但使用率仍 >80%,说明:

1. 仍有未提交的长事务持有日志末端
2. 复制/CDC/镜像等组件在等待日志

这种情况 SHRINKFILE 不会生效,需先解决长事务或相关组件。

防止日志再次暴涨的长期方案

三、还原数据库

第一步:查看备份文件中的逻辑文件名

RESTORE FILELISTONLY
FROM DISK = 'D:\bak\ecology_backup_2025_08_14_020000_7656250.bak';

输出示例:

LogicalName     PhysicalName                         Type  FileGroupName
----------------------------------------------------------------------
ecology_Data    D:\SQLData\ecology.mdf               D     PRIMARY
ecology_Log     D:\SQLData\ecology_log.ldf           L     NULL

💡 FILELISTONLY 只读不写,不会触发还原,安全。必须先拿到逻辑文件名(ecology_Data / ecology_Log),否则 MOVE 参数会报"找不到逻辑名"。

第二步:还原数据库(可能需要 MOVE)

场景 A:原始路径可用,直接还原:

RESTORE DATABASE ecology
FROM DISK = 'D:\bak\ecology_backup_2025_08_14_020000_7656250.bak'
WITH REPLACE,
     STATS = 5;

场景 B:原始路径不可用(如 E:\ 盘损坏),需要 MOVE:

⚠️ 必须提前创建目标目录,否则报错:Directory E:\Database does not exist。

RESTORE DATABASE ecology
FROM DISK = 'D:\bak\ecology_backup_2025_08_14_020000_7656250.bak'
WITH MOVE 'ecology_Data' TO 'E:\Database\ecology.mdf',    -- 数据文件目标路径
     MOVE 'ecology_Log'  TO 'E:\Database\ecology_log.ldf', -- 日志文件目标路径
     REPLACE,          -- 覆盖已有数据库(紧急时使用,会丢失未提交事务)
     STATS = 5;        -- 每 5% 输出进度

💡 MOVE 适合以下场景:

• 磁盘损坏,原路径不可用
• 数据库迁移到新服务器,路径结构不同
• 泛微 Ecology 安装时默认路径是 D:\ 或 C:\,迁移到新服务器后路径变了

REPLACE 适合:紧急覆盖同名数据库,接受丢失最后一次备份后写入的数据。日常恢复不要用 REPLACE,优先用新数据库名(如 ecology_restore_test)先验证备份完整性。

第三步:查询还原进度

SELECT
    r.session_id,
    r.command,
    r.percent_complete,
    r.start_time,
    r.estimated_completion_time / 1000 / 60  AS est_minutes_remaining,
    r.total_elapsed_time       / 1000 / 60  AS elapsed_minutes
FROM sys.dm_exec_requests r
WHERE r.command LIKE 'RESTORE%';

💡 还原与备份可以并行做:RESTORE FILELISTONLY + RESTORE VERIFYONLY(验证备份完整性)可以在正式还原前先执行,确保备份文件没损坏:

RESTORE VERIFYONLY FROM DISK = 'D:\bak\ecology_full_20250816.bak';

返回 The backup set is valid 则备份完好。

泛微 Ecology 备份策略建议

泛微 Ecology 数据库通常 50GB~200GB,建议如下:

💡 泛微 Ecology 有一个特点:数据库频繁写操作(流程流转、附件上传等),日志增长快。建议 recovery model 保持 FULL + 定时日志备份,而不是改成 SIMPLE——否则万一需要 point-in-time 恢复,日志已丢失。

⚠️ 泛微 Ecology 不支持 NORECOVERY 还原后直接应用日志。如果用 WITH NORECOVERY 做备用库,需要确认泛微中间件的数据库连接配置是否支持只读副本。

📚 相关阅读

• CentOS 7 EOL 后更换阿里云 Vault yum 源 — 另一类"旧系统维护"场景,思路相通