企业官网建设流程全解析

简介：面向数据库运维人员与技术人员的Sybase复制服务器使用技巧文档，聚焦分布式环境下数据复制与同步的常见问题；包内仅有1个docx文档，整体约68KB，内容紧凑，侧重实操经验。文档详细讲解了复制分区应设为数据流量的6倍、最大线程数需大于连接数的两倍加3、复制内存适当加大等配置优化原则；同时强调创建专用sa用户、确保RSSD_prim拥有sa权限、配置RSM客户端ID_SERVER等注意事项。迁移篇按断开复制代理、静止队列、删除分区、迁移数据库与RSSD、归零第二截断点、重建队列等步骤给出完整流程；故障处理部分针对DSI线程异常与队列阻塞，介绍了连续执行resume connection跳过阻塞事务、使用admin who与sqt检查队列号并清空问题队列等方法。常用命令方面整理有admin health、admin who_is_down、rs_config、sp_configure等执行示例。已有58人学习下载，适合需要自主排查复制故障的运维人员参考。

1. Sybase Replication Server 使用技巧：先从一次生产事故说起

Sybase Replication Server 常用来做主从库数据同步，但很多人第一次真正重视它，是从事故开始的。有一次值班，复制服务器的 DSI 线程忽然 down 掉，备库数据停在两小时前，队列积压持续上涨，业务侧对账全是差异。重启复制服务器没用，因为问题出在队列里的一条坏事务上。真正能救场的是按固定顺序处理：跳过阻塞事务、恢复 DSI、必要时清队列、重建分区。这份整理把 Sybase Replication Server 的常用配置、迁移步骤、故障处理和命令速查串成了一份可以直接照着操作的笔记，适合刚接手 ASE 复制链路的新人，也适合老 DBA 在做迁移或故障恢复前核对步骤，避免漏掉某一环导致复制长期中断。

2. 配置优化与权限注意事项：分区、线程数、内存和两个 rs 用户坑

2.1 复制分区：大小设为数据流量的六倍，按峰值验证

复制分区是复制服务器存放待投递事务的存储区域，主库日志被抽取线程读出来后，先落进分区，再由 DSI 线程读取并写入目标库。分区的本质是一个缓冲区，容量太小，流量高峰时直接写满，DSI 读不到数据，主库第二截断点也压不下去，最后整个复制链路卡死。容量太大又浪费磁盘，而且清空队列时扫描时间会变长。材料里给的经验值是“分区大小应为数据流量的 6 倍，一般可以设为 2G”，这个数字不是拍脑袋定的，是基于峰值时段日志产生量的估算。我一般会先在复制服务器上执行admin disk_space看历史占用曲线，再按每小时最大日志量的六倍去算，2G 作为一个起步参考值。

分区建好后不是一劳永逸，要定期看占用率。分区使用率长期超过 70%，就要考虑追加分区或者提前触发队列清理。追加分区的命令格式如下：

add partition partition_name on 'device_name' with size size go

partition_name是分区名，device_name是复制服务器所在设备的逻辑名，size要按设备块大小换算，不是直接写字节数。常见做法是取当前分区占用峰值的两倍作为新分区大小，避免刚加完又撑满。注意分区删除是危险操作，执行drop partition partition_name前必须确认队列已经静止，否则积压事务会全部丢失。

2.2 最大线程数：按连接数倒推，别用默认值

复制服务器的线程模型是每个连接在入站和出站两侧各占用一个工作线程，外加管理线程、定时任务线程等。默认配置在连接数多的时候会明显不够，表现是短期内大量连接处于等待状态，复制延迟飙升。材料里给的公式是“最大线程数应该大于连接数（数据库和复制服务器）乘以 2 加 3”，也就是把每个连接按两条线程算，再留三个线程给管理和健康检查。这里说的连接数不是当前实时连接数，而是峰值期主库、目标库、RSSD、RSM 等所有连接的总和。

修改位置在rs_config的 max threads 参数，改完后要重启复制服务器才生效。有一个容易踩的坑是线程数调大后，操作系统文件描述符上限没跟着调，启动时复制服务器直接报无法创建线程。所以调大线程数时，要把操作系统的 max processes、max files 一并检查。调完用admin who查看线程列表，确认每个数据服务器的 DSI、RSI 线程都正常起来了。

2.3 _RSSD_prim 缺少 sa 权限：RSM 连不上配置的黑匣子

_RSD_prim 账号是复制服务器操作 RSSD 数据库用的账号，如果它在 ASE 里没有 sa 权限，RSM 客户端打开复制服务器配置时会报“无法访问复制服务器的配置”，但复制数据本身可能一切正常。这个现象很有迷惑性，因为它不影响数据同步，只影响管理面。解决方法是到 ASE 里给该账号授权：

grant sa to _RSSD_prim go

另外，ASE 要建立一个专门用于复制的 sa 用户，而且账号密码要和复制服务器完全一致。复制服务器在启动和连接时用的是这个账号，如果 ASE 端修改了密码而复制服务器配置没同步改，复制代理会反复重试连接，错误日志里全是连接失败记录。RSM 客户端则要配置 ID_SERVER 及其数据库地址，ID_SERVER 填错或者地址只配了本机，客户端就找不到真正的复制服务器。这三个配置是复制链路管理面的基础，建议在部署脚本里固化下来，不要靠手工维护。

3. 迁移复制服务器：从断代理到重建队列的九步操作顺序

3.1 前三步：断开复制代理、静止队列、删除分区

迁移复制服务器最忌讳顺序混乱，比如先迁移数据库再断复制代理，主库还在写日志，旧机器停机后新事务日志就断了，复制链路永久性中断。正确的第一步是断开复制代理，让主库停止向复制服务器输送日志。ASE 和复制服务器两侧都可以操作：

-- ASE 侧：停止指定库的复制代理 sp_stop_rep_agent db_name go

如果有多库复制，也可以从复制服务器侧统一挂起日志传输，等价语法是suspend log transfer from data_server.database all。这一步做完后，再执行admin quiesce force_rsi等待所有已接收事务回放完成，并用admin quiesce_check确认状态。force_rsi的作用是强制 RSI（入站接口）把队列中的事务全部处理完，只有返回值显示所有数据服务器都 quiet，才能进入下一步。最后执行drop partition partition_name删除正在使用的复制分区，把迁移时可能残留的队列文件句柄释放掉。

3.2 中间三步：挂起路由、迁移数据库、归零第二截断点

分区删除后，要挂起到方向路由，避免迁移过程中路由配置被其他会话修改。

suspend route to replication_server go

然后开始迁移数据库本体，包括复制数据库和 RSSD 数据库。这里有几个硬性要求：服务器名称要和以前完全一致，因为复制服务器配置里存的是逻辑服务器名，不认 IP；迁移后要重新建立 ASE 复制用户，并修改连接配置文件。如果是跨机器迁移，接口文件里的端口和服务名是重灾区，稍有不一致复制服务器就找不到目标库。

数据库迁移完成后，接着做第二截断点归零。这是一套固定组合命令：

use db_name go sp_stop_rep_agent db_name go dbcc settrunc('ltm','ignore') go use RSSD_db_name go rs_zeroltm data_server, database go use db_name go dbcc settrunc('ltm','valid') go

dbcc settrunc('ltm','ignore')是临时忽略第二截断点对日志截断的限制，rs_zeroltm把 RSSD 中记录的最后事务时间归零，让新的复制起点从当前日志位置开始。顺序不能错：先停复制代理，再忽略截断点，最后归零。如果先执行rs_zeroltm，RSSD 侧已经清零，但 ASE 侧日志还挂着旧截断点，之后恢复复制代理时可能出现日志空间被撑满的问题。

3.3 后三步：加分区、重建队列、恢复复制代理

截断点归零后，重新建立复制分区：

add partition partition_name on 'device_name' with size size go

然后重建队列，让复制服务器按新的分区配置生成入站和出站队列：

Rebuild queues go

Rebuild queues会读取 RSSD 中的发布、订阅、路由配置，重新生成队列结构。这一步结束后，用admin health和admin who, sqm确认队列状态正常，再看rs_helproute确认路由已挂起的状态已恢复。最后启动复制代理：

sp_start_rep_agent db_name go

启动后不要急着离开，观察至少 30 分钟。常见情况是代理启动成功但 DSI 线程仍然 down，原因是目标库上某个表结构和订阅定义不一致，这种问题迁移前没暴露，迁移后就只能通过resume connection逐步处理。所以迁移后的健康检查至少要覆盖健康状态、队列占用、DSI 线程三部分。

4. 常用命令速查：admin who 系列与代理恢复、挂起

4.1 状态类命令：先学会读输出再动手

复制服务器的状态命令集中在admin系列，每次排障都绕不开。最基础的是admin health，返回 OK 表示主进程正常。admin who列出当前所有线程，包含线程类型、所属数据服务器、状态。更细一点的是admin who_is_down和admin who_is_up，直接筛选出断线和在线的线程清单，省去在完整线程列表里翻找的功夫。

队列监控要用admin who, sqm，它的输出里有几个关键列：First Seg. block、Last Seg. block、Next read。这三个数值越接近，说明队列越空；差值拉大说明积压。admin who, sqt则是看队列事务线程，重点是 inf 列，形如******x:y，x位置是队列号，如果显示为负数，说明该队列中的事务状态异常，这个队列已经不可正常处理了。磁盘占用则用admin disk_space查看，判断分区是否要扩容。

4.2 配置查询命令：rs_help 家族一页纸

配置查询命令主要面向 RSSD 中的系统表，常用的有这些：

这些命令在 RSM 客户端和 isql 里都可以执行。实际排障时我一般先跑rs_helproute确认路由方向有没有乱，再跑rs_helpdb看复制库状态，最后才决定要不要动队列。配置查询命令不会修改数据，可以放心反复执行。

4.3 恢复与挂起命令：resume connection 的两个参数要分清

DSI 线程 down 后，恢复命令是resume connection，有两个可选参数，含义完全不同：

-- 跳过当前阻塞事务 resume connection to data_server.database skip transaction go -- 重新执行当前事务 resume connection to data_server.database execute transaction go

skip transaction是跳过当前事务继续投递后面的数据，适合目标库已经存在相同记录、无法再插入的场景；execute transaction是让 DSI 重新执行该事务，适合 DSI 因网络抖动或锁超时误判失败的情况。选错参数会放大故障：目标库数据冲突时选 execute transaction，DSI 会反复执行失败事务，队列越积越多。复制代理的启停则是 ASE 侧操作：

-- 启动复制代理 sp_configure 'enable rep agent threads', 1 sp_config_rep_agent 'enable' sp_start_rep_agent db_name go -- 停止复制代理 sp_configure 'enable rep agent threads', 0 sp_config_rep_agent 'disable' sp_stop_rep_agent db_name go

注意sp_configure和sp_config_rep_agent在 ASE 不同版本里作用域有差异，低版本只认sp_configure，高版本推荐用sp_config_rep_agent。恢复代理后一定要用admin who确认线程真正起来了，而不是只在配置层面置为 enable。

4.4 用户权限命令：最小化复制专用账号

复制服务器的用户管理一般遵循最小权限原则：

create user user_name set password passwd null go grant sa to user_name go

set password后面的null表示不设置登录有效期限制，适合长期运行的复制账号。grant sa是授予系统管理员权限，注意复制服务账号不像业务账号需要大量表权限，sa 权限已经覆盖了对 RSSD 系统表的访问。删除账号用drop user user_name。这里有一个容易忽略的点：如果复制服务器和 ASE 之间已经建立了连接，直接 drop user 会导致正在运行的复制链路断开，应该先停复制代理再删账号。

5. 故障排查与避坑：队列阻塞、负数队列、截断点不归零

5.1 DSI 线程 down，备库延迟持续拉大

现象：admin who中 DSI 线程状态为 down，admin who, sqm显示队列占用不断上涨，备库数据时间戳停留在很久以前，业务查询已经能感知到延迟。

原因：目标库执行复制事务失败，最常见的是主键冲突或唯一索引冲突。DSI 线程重试若干次后进入挂起状态，后续所有事务都堵在队列里，形成一个越积越大的阻塞点。

解决：先到复制错误日志里定位是哪个表、哪条事务失败，然后连续执行resume connection to data_server.database skip transaction，每执行一次跳过一个阻塞事务，重复执行直到 DSI 恢复工作。如果队列里坏事务很多，可以连续多执行几次，而不是只执行一次。跳过的事务要记录时间点和表名，之后单独补数。

5.2 admin who, sqt 输出队里列号为负数

现象：admin who, sqt输出中 inf 列形如******x:y，其中x位置是负数。

原因：这个队列中的事务标记异常，队列扫描线程无法按正常顺序读取和分发，可能由强制断电、复制服务器进程被杀或者磁盘写满导致。

解决：用admin who, sqm查到这个队列对应的q_number，确认q_type是出站（0）还是入站（1），然后执行sysadmin sqm_purge_queue q_number, q_type将该队列的数据清空。清空后该队列所有未投递事务都会丢失，需要重建队列并从主库重新抽取。这在操作前一定要知会业务方，不能只当技术操作直接执行。

5.3 队列正常但日志截断不了

现象：复制状态显示正常，但执行dump tran xxx with truncate_only报错或者日志空间一直不释放，复制数据库的第二截断点长时间停在旧位置。

原因：RSSD 中记录的最后事务时间没有归零，ASE 认为复制代理还需要保留这部分日志。这种情况常见于复制代理异常停止后又被强行拉起的场景，或者迁移过程中漏掉了rs_zeroltm步骤。

解决：按迁移章节的顺序处理：先sp_stop_rep_agent db_name，再dbcc settrunc('ltm','ignore')，然后到 RSSD 执行rs_zeroltm data_server, database，最后dbcc settrunc('ltm','valid')恢复。归零前要评估丢失复制起点的风险，如果主库日志已经因为空间压力被截断过，归零后需要全量重新同步。

5.4 RSM 无法访问复制服务器配置

现象：RSM 客户端能连接主库，但打开复制服务器配置时报权限错误或找不到配置对象。

原因：_RSSD_prim账号在 ASE 中缺少 sa 权限，无法读取 RSSD 里的配置表。另一个常见原因是 RSM 客户端配置里 ID_SERVER 的数据库地址指向了错误的服务器。

解决：在 ASE 中执行grant sa to _RSSD_prim，然后在 RSM 客户端重新连接。如果授权后仍报错，检查 ID_SERVER 配置是否指向正确的主机和端口，必要时删除客户端缓存重新配置。这类问题不影响数据复制本身，容易被人忽略，但会在你需要改配置时卡住整个操作窗口。

6. 一个进阶技巧：独立模式清空队列后的数据再同步

复制状态正常但队列不断增长，或者确认某个队列里的事务已经损坏，靠resume connection已经救不回来时，就要考虑清空队列。先把复制服务器停掉，用独立模式启动。独立模式是在启动批处理里加-M参数，这样复制服务器只加载 RSSD 配置，不连接主库和目标库，避免清队列过程中新的日志不断进入。

# 原启动脚本基础上加 -M，进入独立模式 startserver -f RS_APP.cfg -M

然后用 SQL Advantage 连接 RSSD，先执行admin who, sqm拿到队列号和类型：

admin who, sqm go

记录输出中的队列号q_number和类型q_type，0 表示出站队列，1 表示入站队列，然后逐条清空：

sysadmin sqm_purge_queue q_number, q_type go

执行后admin disk_space会看到队列空间被释放。但清空队列等于丢掉了所有未投递事务，所有参与复制的表已经不同步，必须重新做一次全量同步。常见做法是把主库的表bcp out出来，再bcp in到目标库，同时检查复制错误日志里最初导致队列卡住的原因，通常逃不开主键约束或唯一索引冲突。有一次我清完队列急着恢复业务，忘了把出站队列的q_number记下来，结果连着把入站队列也清了，回放起点彻底丢失，只能全量重灌。从那以后我每次做队列清理，都强制先导出一份队列清单和待同步表的 bcp 快照，再执行任何破坏性操作。希望帮到你。

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