InTouch报警数据落库SQL Server：Alarm DB Logger配置与问题排查

简介《Intouch报警数据库配置.pdf》是一份面向工业自动化从业者与相关考试考生的技术参考文档旨在解决InTouch报警系统中报警数据库从连接到查询的配置难题。文档以Alarm DB Logger为核心重点讲解SQL Server混合模式身份验证设置、数据库连接参数填写、详细与合并两种记录模式的选择、报警优先级范围与查询语句配置以及记录间隔和将记录器配置为Windows服务的具体方法能帮助读者避开常见配置误区并快速上手。资源为单个PDF文件压缩包体积约12KB内容精炼便于下载后随时查阅。目前已有317人学习适合正在备考或负责电力、水处理等系统报警数据库维护的工程技术人员。通过这份文档可掌握报警数据库配置的完整流程并获得可直接参照的配置要点与步骤提升系统报警记录的可靠性与查询效率。1. Intouch 报警数据库配置先解决身份验证再谈写库在 InTouch 组态现场报警能不能写进 SQL Server很多时候不是点位配得不对而是数据库这一侧的门槛没迈过去。最常见的场景是这样报警溢出显示正常、声音也响但翻历史报警记录时一片空白打开 Alarm DB Logger Manager 点测试连接直接弹登录失败。折腾半天最后发现 SQL Server 装的时候选了Windows 身份验证而 Alarm DB Logger 偏偏只认 SQL Server 身份验证。这份资料的意义就是把这条链路拆开身份验证怎么切、连接参数怎么填、记录模式怎么选、优先级和记录间隔怎么定以及最容易阴人的几个坑。适合正在做报警历史库落库的组态工程师也适合备考自动化系统组态相关考核的同学——Alarm DB Logger 的配置思路在实操考试里出现频率不低。2. SQL Server 混合模式Alarm DB Logger 能连库的第一道门槛2.1 为什么只认混合模式登录凭据的来路不同Alarm DB Logger 是 Wonderware 体系里负责把 InTouch 报警事件写到 SQL Server 的组件。它建立会话的方式不是走 Windows 集成认证而是拿配置向导里输入的 SQL 登录名和口令去跟数据库引擎握手。SQL Server 如果处于仅 Windows 身份验证模式引擎只接受 Windows 令牌任何 SQL 登录名的登录请求都会在握手阶段被拒掉。所以资料开头那句Alarm DB Logger 仅支持 SQL Server 身份验证并且 SQL Server 身份验证必须设置为混合模式不是选型偏好是登录协议定的死规矩。对熟手来说这条约束还有一层隐藏含义即使现场是域环境也别幻想用域账户免密连接。配置向导里那个用户名/口令必须对应 SQL Server 里真实存在的数据库登录名不是 Windows 账号。我们接过一个现场运维把公司域账号填进去测试连接报错后反复确认密码最后才发现填错了账号体系白折腾一上午。这类问题在技术群里问出来基本都会被回一句先看验证模式。从机制上理解这件事对后续排查特别有用Alarm DB Logger 是独立于 SQL Server 的外部进程它没有能力替用户去申请 Windows 令牌能提交的只有 SQL 凭据。因此数据库端必须开放 SQL Server 身份验证通道也就是混合模式——同时允许 Windows 登录名和 SQL 登录名进入。弄明白这个前提后面所有连接失败的排查都会少走弯路。2.2 从 Windows 验证切到混合验证SQL Server 2005 的操作路径如果安装 SQL Server 时已经定成了 Windows 验证模式补救路径不复杂。以 SQL Server 2005 为例打开 SQL Server Management Studio在对象资源管理器里右击服务器主机名弹出快捷菜单选择属性打开服务器属性对话框。左侧选择安全性页右侧服务器身份验证区域就是要动的地方。这里有两个选项Windows 身份验证模式以及 SQL Server 和 Windows 身份验证模式。把单选从前者切到后者点确定。资料原文特别提醒改完还要重启计算机才算数。生产环境里我一般不会真的重启整台机器重启 SQL Server 服务通常就能让新模式生效但如果你希望严格按官方路径来重启也不过分。要注意的是SQL Server 2005 以后的版本在 SSMS 里的入口基本一样高版本只是把安全性页的排版调整过逻辑没有变。两种模式的具体差异和影响整理成一张表更直观。验证模式接受的登录类型对 Alarm DB Logger 的影响改动生效方式Windows 身份验证模式仅 Windows 账户域账户或本地账户连接必失败测试连接报登录错误需切换到混合模式SQL Server 和 Windows 身份验证模式Windows 账户 SQL 登录名正常连接前提是账号密码正确且权限足够切换后重启 SQL Server 服务改完之后建议立刻验证一次用 SSMS 以 SQL Server 身份验证方式登录能进来就说明模式确实切过来了。如果还是报 18456问题多半不在模式而在 sa 账号被禁用、密码过期或者登录名不存在这些属于 2.3 要讲的收尾动作。2.3 切完模式之后的三个收尾动作第一确认 SQL 登录名可用。混合模式打开后SQL Server 默认的 sa 账号可能仍处于禁用状态。我们给报警库配连接时不要依赖 sa常见做法是新建一个专用登录名授予目标报警库的读写权限在 db_datareader 和 db_datawriter 两个固定数据库角色之间按需选择必要时再加 db_owner。用户名和口令要和稍后 Alarm DB Logger Manager 向导里填的完全一致一个字符都不能差否则测试连接时登录失败会绕一大圈。第二记清楚实例名再填服务器名。默认实例直接填主机名命名实例要填主机名\实例名。很多连接失败不是账号问题而是服务器名这一项填成了 IP或者漏了实例名。资料里服务器名字段要求填的是安装了报警数据库的计算机节点名不是随便填的别名。如果你拿不准自己是默认实例还是命名实例到 SQL Server 配置管理器里看一眼实例名比反复试 IP 靠谱得多。第三检查 SQL Server 的远程连接是否开启。如果 Alarm DB Logger 和 SQL Server 不在同一台机器光有混合模式还不够SQL Server 的 TCP/IP 协议必须在 SQL Server 配置管理器里启用否则客户端根本连不过去。这三件事做完数据库侧的准备工作才算闭环可以进第三章的配置向导了。3. 数据库连接与记录模式四个连接参数与一个二选一3.1 进入 Alarm DB Logger Manager 配置向导Alarm DB Logger Manager 是配置报警落库的图形化入口在 Wonderware System Management 控制台的工具视图里能找到。展开应用程序节点双击 Alarm DB Logger Manager再点击设置就会拉起配置向导。第一次打开时它会直接进入配置流程后续再打开则是修改已有配置入口没有变。一个容易被忽略的前置条件必须以管理员身份登录这台计算机否则后面某些写操作——尤其是把记录器配成 Windows 服务那一步——会因为没有权限而失败。我们在现场的习惯是凡是涉及 Wonderware 服务配置的操作一律用管理员账号启动控制台避免权限问题干扰判断。另外如果这台机器上同时装了多个 Wonderware 版本注意确认打开的是当前运行版本对应的管理器版本错配是隐藏的坑。3.2 四个连接参数服务器名、数据库名、用户名、口令向导第一步是配置数据库连接核心就是四个输入框。这四个参数看着简单踩坑率却很高逐个说一下。参数填什么典型踩坑点服务器名安装了报警数据库的计算机节点名默认实例填主机名命名实例填主机名\实例名填成 IP、漏掉实例名、跨机器时 TCP/IP 未启用数据库名InTouch 报警数据库名称即报警表所在的库库名写错库不存在时没先点创建用户名为该报警数据库创建的 SQL Server 登录名填成 Windows 域账号口令与上述登录名关联的密码密码含特殊字符被转义复制粘贴带入空格服务器名这一项资料原文说的是输入安装了报警数据库的计算机的节点名注意是节点名不是 IP。虽然大多数场景下填 IP 也能通但 Wonderware 组件对节点名的依赖性更强统一填节点名最稳妥。数据库名则要和你稍后创建或已有的报警库保持一致大小写、空格都要对上SQL Server 的排序规则对库名敏感。用户名和口令对应的是 SQL Server 登录名不是 Windows 账号这一点在 2.1 已经强调过这里再重申一遍Alarm DB Logger 只有 SQL 凭据这一条路可走。另外如果密码里有特殊字符先确认向导能原样接收。有些版本的向导对特殊字符处理不友好建议密码先用纯字母数字跑通全流程再考虑加复杂度。记住先通后优不要一上来就给自己加难度。3.3 详细模式与合并模式记录粒度的取舍连接参数下面是记录模式区域二选一详细或者合并。这个选择直接决定报警在数据库里长什么样。详细模式下为每个报警条件存储一条单独的记录——报警进入状态一条、确认一条、返回正常一条每个状态转换都独立成行。合并模式则是把报警的所有状态塞进一条记录同时包含每次转换的时间标签。两种模式的对比用一张表说清楚。维度详细模式合并模式记录形态每个报警状态一行一条记录包含全部状态和转换时间数据量报警频繁抖动时行数增长快行数少单行信息密度高查询场景按状态明细检索、统计各状态数量需要状态流转时间线、确认耗时分析典型代价存储膨胀快解析单行多个时间标签稍复杂我们的经验是如果现场对确认耗时报警持续时间这类指标有硬性要求合并模式更好用因为一条记录里能直接读出进入、确认、恢复三个时间点。如果只是想知道某段时间内各优先级报警各发生了多少次详细模式更直观。选型没有绝对对错但库一旦建起来、记录模式定了中途切换会很麻烦所以第一次就按报表需求想清楚别留到上线以后改。3.4 创建数据库与测试连接顺序错了会翻车向导里还有两个操作按钮创建测试连接。正常的顺序是先点创建把报警数据库建出来再点测试连接验证连通性。如果数据库还不存在就直接测试连接当然失败这是最基础的顺序问题。如果数据库已经存在创建按钮可能不会触发任何动作这时候直接测试连接即可。测试成功后系统会弹出一条消息指出已成功连接到数据库到这一步连接层面的配置就算打通了。这里有一个值得注意的细节Alarm DB Logger 创建的数据库结构是它自己生成的包含一组特定的报警记录表。不要拿别的系统的库名硬凑数据库名最好就用向导创建时生成的默认名或者在建库前规划好名称再让向导去建。我们遇到过有人为了统一规范把报警数据硬塞进业务库结果表结构和权限互相打架最后还得拆出来重配。4. 报警查询与记录间隔优先级范围与毫秒级写入节奏4.1 查询选择页面能改的只有三样连接配置完成后单击下一步进入查询选择页面。这一页有两个只读项报警状态框显示要记录的报警状态查询类型框显示查询类型。这两个是系统决定的不用也不能改因为报警状态和查询类型由 InTouch 运行系统的报警子系统按固定协议给出Alarm DB Logger 只是接收方不需要也不应该干预。真正能配的是三样从优先级、到优先级、报警查询。报警查询框用于输入在报警数据库中存储或检索数据要用的查询。这里的查询可以理解成一个过滤条件集合不必是一段完整的 T-SQL。常见做法是先沿用默认查询跑通全流程确认报警能落库之后再根据现场需要收紧查询条件。如果一上来就写一个复杂的自定义查询一旦查不出数据你很难判断是查询写错还是前面的连接有问题——排查变量越多越难定位。4.2 优先级范围起始值到结束值怎么圈InTouch 的报警优先级体系是 1 到 9991 最高999 最低。从优先级填范围的起始值到优先级填结束值系统只把落在这个区间内的报警写进数据库。比如只关心重要报警可以填 1 到 100想全量入库就填 1 到 999。这里有一个容易忽略的联动关系范围要和现场点位的实际优先级设置匹配。如果只圈了 1 到 100但大部分点位优先级都设在 500落库的数据会少得可怜。这里有个反向踩坑点起始值必须小于等于结束值。有些组态工程师习惯把高优先级放在后面填成 999 到 1结果是范围为空一条报警都进不了库而且测试连接还成功——因为连接是通的只是查询条件把数据全过滤了。排查时看到连接成功但无数据第一反应就该去看优先级范围的正反。我们一般会先导一份当前所有报警点的优先级清单再决定范围怎么圈而不是凭空拍一个数。另外注意点位的报警优先级如果被误设成 0 或超过 999会落在任何区间之外验证时要用一个已知优先级的点位来测别用状态不确定的点做实验。4.3 记录间隔毫秒级写入节奏的工程权衡下一步配置记录间隔单位是毫秒含义是把报警记录写入报警数据库的间隔时间。这一项是性能与实时性的平衡点不是越小越好。常见误区是把记录间隔当成报警响应速度来调恨不得设成 100ms。实际上报警上画面、声音提示是 InTouch 运行时的事落库延迟几百毫秒对操作员毫无感知。间隔设太小高并发报警时 SQL Server 要频繁处理小批量写入连接池和日志压力都会上来反而拖累整个系统。间隔写入频率适用场景1000 ms每秒一批报警量中等对查询实时性有要求3000–5000 ms每 3–5 秒一批常规生产现场落库延迟可接受10000 ms 以上每 10 秒一批报警量小或数据库负载敏感我们经历过一个现场工程师把间隔改成 200ms 想让报警更实时结果报警高峰时段 SQL Server CPU 冲高连带 InTouch 查询都变慢。后来调回 5000ms落库一条没少系统也稳了。这个坑太典型后文排查章节会再展开一次。记录间隔的原则是按报警吞吐量倒推而不是按感觉来定。另外提醒一句部分版本的记录器改完间隔后需要重启服务才会重新加载配置改完参数多看一眼服务状态省得白等一个周期。5. 常见问题排查报警不落库的四个真实场景接报警库的活最难的不是配置本身而是配置完成后看起来一切正常但数据就是不对。这一章把四个高频场景按现象 → 原因 → 解决拆开每个都是我们实际处理过的案例。5.1 报错 18456SQL Server 根本没开放 SQL 登录现象Alarm DB Logger Manager 点测试连接弹出 SQL Server 登录失败错误号 18456。原因SQL Server 仍处于 Windows 身份验证模式或者 SQL 登录名/密码对不上。18456 的具体 state 能进一步定位问题state 8 通常是登录名不存在state 1 是密码错误state 2 是账号被禁用。翻看 SQL Server 错误日志里的完整信息比只看错误号有效得多。解决先按第二章把验证模式切成混合并重启 SQL Server 服务再用 SSMS 以 SQL 登录名实测一次登录。能进说明账号没问题回到向导重新填用户名口令进不去就顺着 state 去查账号状态。如果账号被禁用在 SSMS 的安全性节点下把登录名启用即可如果密码过期重置后两边同步改。5.2 测试连接成功但库里一直没有数据现象向导里测试连接提示成功报警也在 InTouch 里正常产生但 SQL Server 的报警表始终是空的。原因这是最容易被误导的一种情况。连接成功只代表数据库通道通了不代表记录器在工作。常见原因有三个Alarm DB Logger 没有作为服务或应用程序真正运行优先级范围圈反了或范围为空报警全被过滤报警查询条件写得过严把数据都滤掉了。解决按排除法从最外层往里查。先看进程——Alarm DB Logger 是否在跑配置向导里记录器运行方式选的是正常应用程序但程序没启动等于没记录。再查优先级范围确认起始值小于等于结束值并且覆盖现场点位的实际优先级范围。最后检查报警查询必要时先清空自定义条件跑一轮排除查询干扰。三步走完基本能定位是哪一层把数据掐掉了。5.3 记录间隔设太小报警高峰时段数据库被拖垮现象间隔设成几百毫秒后报警集中爆发时 SQL Server CPU 飙高、写入变慢甚至 InTouch 侧查询也卡顿报警记录反而出现缺失。原因小间隔意味着高频小批量写入。报警量一大每个周期都要建立连接、执行插入、提交事务SQL Server 的日志写入和锁竞争随之上升系统吞吐被写操作拖累。数据库不是不能处理高频写入而是这种持续的小事务风暴对日志压力和锁等待很不友好。解决把间隔调到 1000ms 到 5000ms 之间先跑一天观察 SQL Server 负载和落库行数。如果报警量确实很大考虑切到合并记录模式减少行数或者换更强的磁盘和内存而不是继续往下压间隔。判断标准很简单落库延迟高一两秒没人抱怨数据库被拖垮可就是生产事故了。5.4 切到 Windows 服务后配置不生效改了等于没改现象在向导里把记录器运行方式改成Windows 服务并点完成重启后报警还是不落库配置看起来完全没生效。原因Alarm DB Logger 作为服务运行时读取的是服务进程自己持有的配置如果服务没有重启向导里改的内容不会自动加载。另一个隐蔽原因是服务使用了本地系统账户而本地系统账户没有访问 SQL Server 的权限服务上下文里的连接就会静默失败。解决每次改完配置去 Windows 服务列表里重启 Alarm DB Logger 对应的服务。同时检查服务的登录身份如果 SQL Server 在另一台机器给服务指定一个有权访问 SQL Server 的账户而不是默认的本地系统。改完身份后记得重启一次服务并回到向导里重新测试连接确认服务上下文下确实通了。6. 注册成 Windows 服务与落库验证最后一段路的三个动作6.1 把记录器从调试状态切到服务状态配置向导走到高级设置页时记录器运行方式区域有两个选项Windows 服务或正常应用程序。调试阶段选正常应用程序能看到即时日志方便观察配置有没有生效确认没问题后再以管理员身份重跑向导切到Windows 服务点完成。这样报警落库就能开机自启不依赖任何人手动开程序。注意切服务这一步必须以管理员身份操作否则完成按钮点了也可能没权限注册成功。6.2 落库验证三板斧第一板斧确认服务在跑。Windows 服务管理器里找到 Alarm DB Logger 对应的服务状态必须是正在运行。第二板斧触发一条真实报警等一个记录间隔然后查报警表是否新增了行。第三板斧核对优先级和状态字段确认落库的这条报警确实在配置范围内。用 SSMS 打开报警库跑一条查询就能看到结果。SELECT TOP 10 * FROM 报警记录表 ORDER BY 时间标签 DESC;上面这条查询用来确认新记录已写入具体表名以你创建报警库时生成的表结构为准。查询结果里能看到时间标签、优先级、报警状态这些字段就说明从配置到写入的整条链路都是通的。如果 TOP 10 查出来全是旧数据说明新报警没落进来回到第五章的排查顺序重新走一遍。6.3 一个值得养成的习惯报警库配置不像画面组态那样有即时视觉反馈它是典型的配错也看不出来的活等服务正式跑起来再发现就晚了。从那以后我每次配报警库都强制走一遍固定流程先确认 SQL Server 验证模式是混合再建专用登录名并实测登录然后打开向导填四个参数、测试连接接着用最小优先级范围触发一条报警验证落库最后切 Windows 服务再看一次运行状态。这套流程走完基本没有回头路可走。希望帮到你。本文还有配套的精品资源点击获取