简介Intouch报警数据库配置是一份面向工业自动化工程师、组态软件学习者和考试备考人群的PDF资料重点梳理Wonderware InTouch报警系统中报警数据库从连接到查询的完整配置流程。文档围绕Alarm DB Logger展开先说明SQL Server必须设为混合模式身份验证的注意事项再逐步演示服务器名、数据库名、用户名、口令等连接项填写详细/合并两种记录模式的选择以及记录间隔、报警优先级范围和查询语句的配置方法同时介绍通过Alarm DB Logger Manager配置向导测试连接、创建数据库以及以管理员身份将记录器设置为Windows服务的操作要点。资源为单个PDF文档约12KB内容紧凑、要点明确适合考前速览、项目部署时对照查阅或作为故障排查手册。目前已有317人学习下载对有InTouch报警系统维护与组态需求的技术人员具有直接参考价值。1. Intouch报警数据库配置为什么报警要落进SQL而不是留在HMI里值班电话晚上十一点响接起来是白班班长“加热炉那条高温报警我在HMI报警列表里翻了半天没找到你们到底记没记”这种场面的根源多半是Intouch报警数据库配置没做到位。把Intouch报警数据库配置想清楚就是让Intouch运行时里每一条报警/事件稳定落地到SQL Server这类关系库而不是留在HMI报警列表里等着被翻页翻丢。它解决的是三件具体事交接班查历史报警不用再去逐页翻、事故复盘能拿到可靠的时间线、故障统计报表能从数据库取数而不是靠人肉抄录。这套配置适合仪表、自控、SCADA运维和系统集成工程师尤其适合手头有一堆设备报警但至今还躺在HMI页面里的项目。2. 先选型再动手Alarm DB Logger与HistorianIntouch报警数据库配置该走哪条路现场问得最多的一个问题是Intouch报警数据库配置到底该走Alarm DB Logger还是上Historian很多工程师把这两者当二选一其实两条路线解决的是不同层面的问题。Intouch自带的Alarm DB Logger走的是“ODBC加关系库”这条路配置直接数据落到SQL Server里后续报表、交接班查询都方便System Platform Historian走的是“统一历史数据平台”的路报警和实时数据在同一套存储里适合已经上了System Platform的新项目或者多套Intouch集中管理的场景。做选择之前先看现状手里是存量单机Intouch还是新建设的多节点系统。2.1 两条路线怎么选单机存量项目用Alarm DB Logger接System Platform用HistorianAlarm DB Logger适合存量项目原因是配置改动最小。Intouch单独跑在一台工业PC机上SQL Server也在这台机器或同一网段通过ODBC数据源连接报警流一出站就写进库。常见版本的Intouch安装后都会带Alarm DB Logger Manager这个管理工具数据表结构由管理器自动生成不用DBA手工建模。缺点也明显它是独立的一份报警存储和实时数据库、历史数据库各自分开系统一多每套Intouch都要维护一份报警库查询起来还得串联。Historian路线适合已经有System Platform的厂。报警数据落进Historian之后能通过统一的数据服务查询还可以把报警事件和过程量放在同一条时间轴上做关联分析设备故障复盘时不需要先关联报警库和实时库。代价是部署和运维门槛高Historian本身要作为平台服务来管理底层存储也不太方便用通用SQL直接翻。对大多数只有一个中控室、几台Intouch节点的工厂上Historian属于杀鸡用牛刀。对比维度Alarm DB LoggerSystem Platform Historian适用形态Intouch独立版、存量单机项目已接入System Platform的新项目数据落地方式ODBC写入SQL Server等关系库Historian专有存储配置复杂度低DSN加管理器配置即可高需要部署和维护Historian查询方式直接写SQLHistorian API或报表服务多系统集中管理需各自配置可统一管理我一般这样判断项目已经上了System Platform体系报警和工艺量需要在同一平台里关联就顺着Historian走如果只是老的Intouch节点报警异常发生后需要快速翻历史、出报表、配合交接班复查Alarm DB Logger更实际。尤其不少存量项目里这套组件已经稳定运行很多年没必要为了“新架构”去折腾一套实时库平台。2.2 配置前先确认三件事ODBC数据源位数、SQL账号权限、Windows启动模式第一件是ODBC数据源位数。Intouch本身常见的是32位进程64位Windows上打开“ODBC数据源管理器”时如果不小心用了控制面板里的64位版本建出来的系统DSN在Intouch运行时根本看不到。正确做法是用C:\Windows\SysWOW64\odbcad32.exe启动32位ODBC管理器在这个界面里建系统DSN。提示32位ODBC管理器和64位ODBC管理器各维护一套DSN列表你在这个里建的DSN另一个里看不到。这是Intouch报警数据库配置里最常见的翻车点没有之一。第二件是SQL账号权限。不要直接拿sa给Alarm DB Logger用生产库用sa一旦被运维扫描扫出来就是大事故。常见做法是单独建一个账号只授予这个报警库的读写权限USE [master]; GO CREATE LOGIN intouch_alarm WITH PASSWORD NJx4!ks2#Qp9; GO USE IntouchAlarmDB; GO CREATE USER intouch_alarm FOR LOGIN intouch_alarm; GO ALTER ROLE db_datareader ADD MEMBER intouch_alarm; ALTER ROLE db_datawriter ADD MEMBER intouch_alarm; GO这段脚本的逻辑是先在SQL Server实例级建登录账号再在报警库里建对应的数据库用户最后把它加进db_datareader和db_datawriter两个角色。db_datareader负责Alarm DB Logger Manager建表后读取结构db_datawriter负责把报警写入事件表两个角色加起来正好覆盖运行和连接测试两个场景。密码里的特殊字符别省报警库虽然不像业务库那么敏感但数据库端口暴露在工控网里被扫描也不是稀罕事。第三件是Windows启动模式。Alarm DB Logger运行时是跟着Windows登录会话走的如果Intouch运行节点设置了自动登录那这个自动登录账号必须对ODBC DSN和SQL Server都有访问权如果用了运行服务账号还要确认该账号能读到64位注册表里的DSN配置。很多现场把工控机设成开机自动登录但账号密码被IT改了之后ODBC连接静默失败报警写入就悄悄断了。配置前把这几个前置条件一次性确认完后面才不会反复折腾。3. 建库、建DSN、配Alarm DB LoggerIntouch报警数据库配置的最小可跑通流程前置条件确认完之后就可以进入Intouch报警数据库配置的正式流程。这里按“建库、建DSN、配管理器、挂运行时、验证落地”五步走。先说明一点Alarm DB Logger Manager第一次配置时通常会自动生成需要的表结构所以建库这一步只需要把数据库外壳建好不需要手工建表。手工建表反而容易和Manager的表结构定义不一致后面查询时对不上字段。3.1 第一步在SQL Server里为Intouch报警数据库建库打开SSMS或者用sqlcmd执行下面的建库脚本USE [master]; GO IF DB_ID(NIntouchAlarmDB) IS NULL BEGIN CREATE DATABASE IntouchAlarmDB ON PRIMARY ( NAME NIntouchAlarmDB, FILENAME ND:\AlarmDB\IntouchAlarmDB.mdf, SIZE 512MB, FILEGROWTH 256MB ) LOG ON ( NAME NIntouchAlarmDB_Log, FILENAME ND:\AlarmDB\IntouchAlarmDB_log.ldf, SIZE 128MB, FILEGROWTH 128MB ); END; GOFILENAME里的路径要根据现场数据盘实际位置改不要在C盘里建报警库工控机系统盘稳定性和空间都不适合放长期增长的报警历史。SIZE和FILEGROWTH这两个参数值得多说两句数据库初始512MB、日志初始128MB是按“日报警量几千条、至少跑半年”的余量给的预分配避免一开始自动增长频繁触发FILEGROWTH设成固定值256MB而不是百分比是因为百分比增长在文件变大后一次可能要分配好几个GB统计等待时间会明显拉长极端情况下报警写入会跟着抖动。建完库之后Alarm DB Logger Manager会在配置数据库时自动创建报警表、事件表这些结构。如果自动建表失败先回到上一章的账号权限检查最常见原因是当前连接账号没有CREATE TABLE权限。3.2 第二步配置系统DSN并打通Alarm DB Logger Manager打开32位ODBC管理器添加“系统DSN”。驱动选“ODBC Driver 17 for SQL Server”或“SQL Server Native Client 11.0”以现场实际安装的驱动为准。填服务器地址时本地可以用localhost或实例机器名远程就填IP加实例名例如192.168.1.10\SQLEXPRESS。认证方式建议用SQL Server认证填上一步建的intouch_alarm账号默认数据库下拉框里选IntouchAlarmDB然后测试连接。DSN建好后从开始菜单里找到Alarm DB Logger Manager并打开。管理器的操作逻辑不复杂常见做法是新建一个数据库配置DSN下拉框里选刚建的IntouchAlarmDSN填上账号密码再选择要记录的报警类型。这里的报警类型一般有报警Alarm、事件Event、消息Message三类至少把Alarm和Event都勾上。字段选择上TagName、AlarmGroup、Priority、OccurrenceTime、EventValue这几项是后续查询和报表的必选字段尽量都保留。配置完成后先做一次“测试连接”确认Manager能正常读写数据库。测试通过后保存配置。有些版本的Manager会弹窗问是否自动创建表结构选“是”。这一步做完报警数据库的“后端”就绪接下来要把它挂进Intouch运行时。3.3 第三步把报警流挂进运行时并验证数据落地Alarm DB Logger的挂接方式常见做法是在WindowMaker里打开一个需要长期驻留的窗口从控件列表里找到Alarm DB Logger控件拖到窗口上保存后运行Viewer时它会自动装载配置并开始写库。如果你的项目里不想动画面也有把Alarm DB Logger配置成随系统启动的独立方式具体看现场用的是哪个版本的Intouch但无论哪种方式核心目标都是让它在WindowViewer运行时自动起来而不是每次手动去点。挂接完成后先在Intouch上手动触发一两条报警然后回到SQL Server里验证数据真的进去了。不要急着看业务数据先让数据库告诉你表结构是什么样的USE IntouchAlarmDB; SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE BASE TABLE; -- 得到实际的报警事件表名不同版本命名不同以查询结果为准这条SQL的作用是把库里的所有基表列出来。Alarm DB Logger Manager自动建的表名在不同版本里会有差异有叫报警事件主表的也有带日期后缀的所以先查出来再针对操作。拿到实际表名后再查最近写入的报警SELECT TOP 10 TagName, AlarmGroup, Priority, OccurrenceTime FROM [上一步查到的实际表名] ORDER BY OccurrenceTime DESC;代码里方括号不是让你照抄是要替换成上一步查到的实际表名。如果这个查询能返回刚才手动触发的报警记录说明Intouch报警数据库配置已经通了。如果查询返回空而Intouch确实报警了优先检查ODBC连接测试能否通过、账号有没有写权限如果表都没建出来回到3.1去看自动建表是否失败。4. 报警库查询得好用才叫配好分表策略、索引与报表账号报警能写进库只是及格查询好用才算配置到位。很多项目报警库跑半年后查询越来越慢SSMS里一条统计SQL能转几十秒问题基本都出在单表数据量过大、索引缺失、报表账号直接查生产表这三个地方。这一章把分表、索引、账号权限一次说清。4.1 报警库单表能撑多久容量估算与分表信号先做一个保守的容量估算。一条报警记录按512字节算里面包含了标签名、报警组、优先级、时间戳、报警值等字段再加上索引页的开销实际可能比这个大但512字节足够做规划。一个日报警量3000条的中型装置一年大概产生550MB数据日报警量一万条的现场一年就是接近2GB。SQL Server单表存几百万行其实还能工作配合上合理索引查询并不会立刻崩但超过千万行之后统计类查询延迟会明显上升。日均报警量年存储量估算建议方案1000条约200MB单表加索引即可5000条约1GB单表可接受考虑半年归档一次20000条约4GB按年分表或分区配置定期归档分表策略上常见做法有两种一种是在Alarm DB Logger配置里看是否支持按天或按月生成表名如果支持让它自动按时间周期建新表另一种是配置SQL Server Agent作业每周或每月把生产表里超过保留期限的数据搬到历史表。无论哪种目的都是让生产报警表保持在一个可控的数据量级查询快备份也快。我不建议一开始就上特别复杂的分区方案先按年分表或者定期归档等数据量真的到千万级再评估分区表。4.2 查询SQL按报警组、优先级和时间段取数报警数据库配好后最常用的查询就是按报警组、优先级和时间段统计。Intouch里报警组是用户在标记名字典里配置的分组通常按装置或工艺区域划分比如Heating_Furnace、Compressor_Area优先级范围是1到999数值越大越紧急999为最高。下面的SQL按报警组和优先级统计某个月的报警次数SELECT AlarmGroup, Priority, COUNT(*) AS AlarmCount FROM [实际表名] WHERE OccurrenceTime 2025-01-01 00:00:00 AND OccurrenceTime 2025-02-01 00:00:00 AND Priority 500 GROUP BY AlarmGroup, Priority ORDER BY AlarmCount DESC;这个查询的逻辑是先把时间窗口卡死再按报警组和优先级维度聚合最后按数量倒序排列。时间窗口用和而不是BETWEEN是为了避免边界误差这也是写时间查询的一个习惯。Priority 500这个条件是过滤阈值现场需要看哪些级别的报警按自己的报警分级习惯调整。如果查询结果里报警组名和Intouch画面上的不一致回去检查标记名字典里的报警组配置查询库里的是全名画面上显示的可能有简化后缀。4.3 索引怎么加才不拖累报警写入报警表是典型的“高写入、中查询”场景索引加得太多会直接拖慢报警写入因为每条报警插入时都要同步更新索引。所以索引宁缺毋滥只给最常用的查询路径建复合索引。如果你们现场的固定查询是“查某段时间内高优先级的报警”就建时间和优先级的复合索引USE IntouchAlarmDB; CREATE NONCLUSTERED INDEX IX_Alarm_Time_Priority ON [实际表名] (OccurrenceTime DESC, Priority DESC); GOOccurrenceTime DESC放在第一列是因为所有报警查询几乎都会带上时间范围时间列做前导列能让索引落到最小数据区间再配合Priority DESC过滤高优先级报警查询代价会大幅下降。索引数量建议控制在两三个以内除了这个复合索引外最多再建一个报警组相关的索引如果已经做了按天分表表的规模小甚至只需要这一个复合索引就够了。报表查询不要直接连生产库跑大统计把第2章的只读账号拿来给报表工具用权限上只给db_datareader避免报表里写错条件影响业务。5. Intouch报警数据库配置常见问题断录、连不上、时间对不上的五个排查记录报警数据库配置完运行三个月内最容易出的问题基本都集中在连接、账号、时区和自动启动这几类。下面这五条是从现场积累下来的高频故障每条按现象、原因、解决的顺序写遇到类似情况可以直接照着排查。5.1 32位/64位ODBC混用Manager测试通过Intouch运行时就是不写库现象Alarm DB Logger Manager里测试连接成功甚至手动查询都能看到表结构但Intouch运行时一报警数据库里一条记录都没有HMI端也没有任何报错。原因Manager和Intouch运行时进程位数不一致各自读到的ODBC DSN列表不一样。常见情况是64位系统上同时装了32位和64位ODBC驱动Manager用64位DSN测试通过Intouch运行时是32位进程读的是32位DSN列表那里根本没有配置。解决用C:\Windows\SysWOW64\odbcad32.exe打开32位ODBC管理器确认系统DSN里确实存在配置如果Manager里能选到DSN但Intouch里不行把DSN删掉重建一次确保两端引用的是同一个DSN名称。5.2 SQL账号密码过期某天开始报警静默断录现象没有改过任何配置报警突然从某天开始断录SQL Server日志里有大量登录失败记录错误码是18456。原因SQL Server启用了密码过期策略或者IT周期性改密后没有同步到Alarm DB Logger Manager的配置里。报警写入失败是静默的Intouch画面上不会有任何提示只有查库才发现断了。解决给intouch_alarm账号设置密码永不过期如果公司安全策略强制定期改密就把改密和同步Alarm DB Logger配置放进同一个运维变更单改完密码后在Manager里重新执行测试连接确认恢复写入。5.3 报警时间与写库时间差8小时交接班对不上账现象报警表里的OccurrenceTime比现场实际发生时间晚8小时或者早8小时交接班对报警记录时两边怎么都对不上。原因Intouch运行节点的操作系统不是北京时间或者SQL Server实例的时区与会话时区不一致。报警写入时Intouch按本地时间生成时间戳ODBC驱动和SQL Server再按各自时区做一次转换中间多了一次偏移。解决统一工控机Windows时区为北京时间并确认SQL Server实例时区一致如果驱动和连接串支持时区参数在ODBC连接设置里显式指定。排查时先看两条时间报警表的写入时间和Intouch画面报警发生时间两者差值恒定时基本就是时区问题。5.4 数据库自动增长太小报警量大时Intouch画面都跟着卡现象报警写入高峰时段Intouch运行时页面操作明显变慢报警列表刷新一顿一顿的数据库里看等待统计文件增长等待时间很高。原因建库时如果用了默认配置数据文件初始大小很小FILEGROWTH是10%或1MB每次扩容需要等待SQL Server分配新空间报警写入被阻塞进而拖累Intouch进程。解决按第3章的建库脚本重建参数或者对现有库执行ALTER DATABASE把FILEGROWTH改成固定值256MB初始大小调整到1GB以上。日志文件也一并处理并尽量保证数据和日志分别放在不同物理磁盘上。5.5 重启后Alarm DB Logger没有自动运行多一些断档记录现象工控机因为断电或系统补丁重启后Intouch画面正常但报警库从重启时刻开始没有新数据直到人工发现并重新启动Alarm DB Logger才恢复。原因Alarm DB Logger没有配置成随系统或随WindowViewer自动启动之前是现场工程师手动开的重启后没拉起来。解决在Alarm DB Logger Manager里把启动模式改为自动。如果Manager里没有明确的自动启动选项就把启动入口放到WindowViewer的启动脚本里或者做成Windows计划任务在登录时执行。确认后手动重启一次工控机再验证报警是否自动写入。6. 把报警数据库当成巡检对象断档SQL、容量估算与恢复习惯报警数据库配置完不是终点运行期最怕的是断录了没人发现。我的习惯是把它当一台重要设备纳入日常巡检每天早班用一条SQL查前一天各小时报警条数哪个小时是零而且现场肯定有报警的立刻处理。这条SQL不长但救过好几次场USE IntouchAlarmDB; DECLARE CheckStart DATETIME DATEADD(HOUR, -24, GETDATE()); SELECT CONVERT(char(13), OccurrenceTime, 120) AS AlarmHour, COUNT(*) AS Cnt FROM [实际表名] WHERE OccurrenceTime CheckStart GROUP BY CONVERT(char(13), OccurrenceTime, 120) ORDER BY AlarmHour; GOCONVERT(char(13), OccurrenceTime, 120)的作用是把时间截断到小时例如2025-06-01 08:30:00转成2025-06-01 08:00然后按这个小时聚合计数。巡检时主要看输出里有没有出现0或明显偏低的时段一般夜班报警量低可以理解但连续两小时为0就要警惕。容量估算我习惯按“日报警量乘以512字节再乘以1.5”来算年增长量这个系数把索引和碎片都盖进去了。日报警量五千条的项目一年大概1.4GB磁盘规划和备份保留周期都按这个数预留。如果某天报警量突然翻倍先别急着加索引看看是不是某个点位在高频抖动先把报警源头压下去再说。万一报警库真断档了恢复顺序也有讲究。先确认当前报警流是否已恢复写入如果Alarm DB Logger有内存缓冲等它自己flush一段时间如果断档期间开了Intouch自身的报警历史文件还能从那里面导出补救报表如果都没开这段盲区只能认账这也是为什么把巡检SQL加进早班习惯比事后补救重要得多。我吃过这个亏现在每到新项目第一件事就是把这条断档检查SQL交给当班工程师让他们每天上班顺手跑一遍。希望帮到你。本文还有配套的精品资源点击获取
简介Intouch报警数据库配置是一份面向工业自动化工程师、组态软件学习者和考试备考人群的PDF资料重点梳理Wonderware InTouch报警系统中报警数据库从连接到查询的完整配置流程。文档围绕Alarm DB Logger展开先说明SQL Server必须设为混合模式身份验证的注意事项再逐步演示服务器名、数据库名、用户名、口令等连接项填写详细/合并两种记录模式的选择以及记录间隔、报警优先级范围和查询语句的配置方法同时介绍通过Alarm DB Logger Manager配置向导测试连接、创建数据库以及以管理员身份将记录器设置为Windows服务的操作要点。资源为单个PDF文档约12KB内容紧凑、要点明确适合考前速览、项目部署时对照查阅或作为故障排查手册。目前已有317人学习下载对有InTouch报警系统维护与组态需求的技术人员具有直接参考价值。1. Intouch报警数据库配置为什么报警要落进SQL而不是留在HMI里值班电话晚上十一点响接起来是白班班长“加热炉那条高温报警我在HMI报警列表里翻了半天没找到你们到底记没记”这种场面的根源多半是Intouch报警数据库配置没做到位。把Intouch报警数据库配置想清楚就是让Intouch运行时里每一条报警/事件稳定落地到SQL Server这类关系库而不是留在HMI报警列表里等着被翻页翻丢。它解决的是三件具体事交接班查历史报警不用再去逐页翻、事故复盘能拿到可靠的时间线、故障统计报表能从数据库取数而不是靠人肉抄录。这套配置适合仪表、自控、SCADA运维和系统集成工程师尤其适合手头有一堆设备报警但至今还躺在HMI页面里的项目。2. 先选型再动手Alarm DB Logger与HistorianIntouch报警数据库配置该走哪条路现场问得最多的一个问题是Intouch报警数据库配置到底该走Alarm DB Logger还是上Historian很多工程师把这两者当二选一其实两条路线解决的是不同层面的问题。Intouch自带的Alarm DB Logger走的是“ODBC加关系库”这条路配置直接数据落到SQL Server里后续报表、交接班查询都方便System Platform Historian走的是“统一历史数据平台”的路报警和实时数据在同一套存储里适合已经上了System Platform的新项目或者多套Intouch集中管理的场景。做选择之前先看现状手里是存量单机Intouch还是新建设的多节点系统。2.1 两条路线怎么选单机存量项目用Alarm DB Logger接System Platform用HistorianAlarm DB Logger适合存量项目原因是配置改动最小。Intouch单独跑在一台工业PC机上SQL Server也在这台机器或同一网段通过ODBC数据源连接报警流一出站就写进库。常见版本的Intouch安装后都会带Alarm DB Logger Manager这个管理工具数据表结构由管理器自动生成不用DBA手工建模。缺点也明显它是独立的一份报警存储和实时数据库、历史数据库各自分开系统一多每套Intouch都要维护一份报警库查询起来还得串联。Historian路线适合已经有System Platform的厂。报警数据落进Historian之后能通过统一的数据服务查询还可以把报警事件和过程量放在同一条时间轴上做关联分析设备故障复盘时不需要先关联报警库和实时库。代价是部署和运维门槛高Historian本身要作为平台服务来管理底层存储也不太方便用通用SQL直接翻。对大多数只有一个中控室、几台Intouch节点的工厂上Historian属于杀鸡用牛刀。对比维度Alarm DB LoggerSystem Platform Historian适用形态Intouch独立版、存量单机项目已接入System Platform的新项目数据落地方式ODBC写入SQL Server等关系库Historian专有存储配置复杂度低DSN加管理器配置即可高需要部署和维护Historian查询方式直接写SQLHistorian API或报表服务多系统集中管理需各自配置可统一管理我一般这样判断项目已经上了System Platform体系报警和工艺量需要在同一平台里关联就顺着Historian走如果只是老的Intouch节点报警异常发生后需要快速翻历史、出报表、配合交接班复查Alarm DB Logger更实际。尤其不少存量项目里这套组件已经稳定运行很多年没必要为了“新架构”去折腾一套实时库平台。2.2 配置前先确认三件事ODBC数据源位数、SQL账号权限、Windows启动模式第一件是ODBC数据源位数。Intouch本身常见的是32位进程64位Windows上打开“ODBC数据源管理器”时如果不小心用了控制面板里的64位版本建出来的系统DSN在Intouch运行时根本看不到。正确做法是用C:\Windows\SysWOW64\odbcad32.exe启动32位ODBC管理器在这个界面里建系统DSN。提示32位ODBC管理器和64位ODBC管理器各维护一套DSN列表你在这个里建的DSN另一个里看不到。这是Intouch报警数据库配置里最常见的翻车点没有之一。第二件是SQL账号权限。不要直接拿sa给Alarm DB Logger用生产库用sa一旦被运维扫描扫出来就是大事故。常见做法是单独建一个账号只授予这个报警库的读写权限USE [master]; GO CREATE LOGIN intouch_alarm WITH PASSWORD NJx4!ks2#Qp9; GO USE IntouchAlarmDB; GO CREATE USER intouch_alarm FOR LOGIN intouch_alarm; GO ALTER ROLE db_datareader ADD MEMBER intouch_alarm; ALTER ROLE db_datawriter ADD MEMBER intouch_alarm; GO这段脚本的逻辑是先在SQL Server实例级建登录账号再在报警库里建对应的数据库用户最后把它加进db_datareader和db_datawriter两个角色。db_datareader负责Alarm DB Logger Manager建表后读取结构db_datawriter负责把报警写入事件表两个角色加起来正好覆盖运行和连接测试两个场景。密码里的特殊字符别省报警库虽然不像业务库那么敏感但数据库端口暴露在工控网里被扫描也不是稀罕事。第三件是Windows启动模式。Alarm DB Logger运行时是跟着Windows登录会话走的如果Intouch运行节点设置了自动登录那这个自动登录账号必须对ODBC DSN和SQL Server都有访问权如果用了运行服务账号还要确认该账号能读到64位注册表里的DSN配置。很多现场把工控机设成开机自动登录但账号密码被IT改了之后ODBC连接静默失败报警写入就悄悄断了。配置前把这几个前置条件一次性确认完后面才不会反复折腾。3. 建库、建DSN、配Alarm DB LoggerIntouch报警数据库配置的最小可跑通流程前置条件确认完之后就可以进入Intouch报警数据库配置的正式流程。这里按“建库、建DSN、配管理器、挂运行时、验证落地”五步走。先说明一点Alarm DB Logger Manager第一次配置时通常会自动生成需要的表结构所以建库这一步只需要把数据库外壳建好不需要手工建表。手工建表反而容易和Manager的表结构定义不一致后面查询时对不上字段。3.1 第一步在SQL Server里为Intouch报警数据库建库打开SSMS或者用sqlcmd执行下面的建库脚本USE [master]; GO IF DB_ID(NIntouchAlarmDB) IS NULL BEGIN CREATE DATABASE IntouchAlarmDB ON PRIMARY ( NAME NIntouchAlarmDB, FILENAME ND:\AlarmDB\IntouchAlarmDB.mdf, SIZE 512MB, FILEGROWTH 256MB ) LOG ON ( NAME NIntouchAlarmDB_Log, FILENAME ND:\AlarmDB\IntouchAlarmDB_log.ldf, SIZE 128MB, FILEGROWTH 128MB ); END; GOFILENAME里的路径要根据现场数据盘实际位置改不要在C盘里建报警库工控机系统盘稳定性和空间都不适合放长期增长的报警历史。SIZE和FILEGROWTH这两个参数值得多说两句数据库初始512MB、日志初始128MB是按“日报警量几千条、至少跑半年”的余量给的预分配避免一开始自动增长频繁触发FILEGROWTH设成固定值256MB而不是百分比是因为百分比增长在文件变大后一次可能要分配好几个GB统计等待时间会明显拉长极端情况下报警写入会跟着抖动。建完库之后Alarm DB Logger Manager会在配置数据库时自动创建报警表、事件表这些结构。如果自动建表失败先回到上一章的账号权限检查最常见原因是当前连接账号没有CREATE TABLE权限。3.2 第二步配置系统DSN并打通Alarm DB Logger Manager打开32位ODBC管理器添加“系统DSN”。驱动选“ODBC Driver 17 for SQL Server”或“SQL Server Native Client 11.0”以现场实际安装的驱动为准。填服务器地址时本地可以用localhost或实例机器名远程就填IP加实例名例如192.168.1.10\SQLEXPRESS。认证方式建议用SQL Server认证填上一步建的intouch_alarm账号默认数据库下拉框里选IntouchAlarmDB然后测试连接。DSN建好后从开始菜单里找到Alarm DB Logger Manager并打开。管理器的操作逻辑不复杂常见做法是新建一个数据库配置DSN下拉框里选刚建的IntouchAlarmDSN填上账号密码再选择要记录的报警类型。这里的报警类型一般有报警Alarm、事件Event、消息Message三类至少把Alarm和Event都勾上。字段选择上TagName、AlarmGroup、Priority、OccurrenceTime、EventValue这几项是后续查询和报表的必选字段尽量都保留。配置完成后先做一次“测试连接”确认Manager能正常读写数据库。测试通过后保存配置。有些版本的Manager会弹窗问是否自动创建表结构选“是”。这一步做完报警数据库的“后端”就绪接下来要把它挂进Intouch运行时。3.3 第三步把报警流挂进运行时并验证数据落地Alarm DB Logger的挂接方式常见做法是在WindowMaker里打开一个需要长期驻留的窗口从控件列表里找到Alarm DB Logger控件拖到窗口上保存后运行Viewer时它会自动装载配置并开始写库。如果你的项目里不想动画面也有把Alarm DB Logger配置成随系统启动的独立方式具体看现场用的是哪个版本的Intouch但无论哪种方式核心目标都是让它在WindowViewer运行时自动起来而不是每次手动去点。挂接完成后先在Intouch上手动触发一两条报警然后回到SQL Server里验证数据真的进去了。不要急着看业务数据先让数据库告诉你表结构是什么样的USE IntouchAlarmDB; SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE BASE TABLE; -- 得到实际的报警事件表名不同版本命名不同以查询结果为准这条SQL的作用是把库里的所有基表列出来。Alarm DB Logger Manager自动建的表名在不同版本里会有差异有叫报警事件主表的也有带日期后缀的所以先查出来再针对操作。拿到实际表名后再查最近写入的报警SELECT TOP 10 TagName, AlarmGroup, Priority, OccurrenceTime FROM [上一步查到的实际表名] ORDER BY OccurrenceTime DESC;代码里方括号不是让你照抄是要替换成上一步查到的实际表名。如果这个查询能返回刚才手动触发的报警记录说明Intouch报警数据库配置已经通了。如果查询返回空而Intouch确实报警了优先检查ODBC连接测试能否通过、账号有没有写权限如果表都没建出来回到3.1去看自动建表是否失败。4. 报警库查询得好用才叫配好分表策略、索引与报表账号报警能写进库只是及格查询好用才算配置到位。很多项目报警库跑半年后查询越来越慢SSMS里一条统计SQL能转几十秒问题基本都出在单表数据量过大、索引缺失、报表账号直接查生产表这三个地方。这一章把分表、索引、账号权限一次说清。4.1 报警库单表能撑多久容量估算与分表信号先做一个保守的容量估算。一条报警记录按512字节算里面包含了标签名、报警组、优先级、时间戳、报警值等字段再加上索引页的开销实际可能比这个大但512字节足够做规划。一个日报警量3000条的中型装置一年大概产生550MB数据日报警量一万条的现场一年就是接近2GB。SQL Server单表存几百万行其实还能工作配合上合理索引查询并不会立刻崩但超过千万行之后统计类查询延迟会明显上升。日均报警量年存储量估算建议方案1000条约200MB单表加索引即可5000条约1GB单表可接受考虑半年归档一次20000条约4GB按年分表或分区配置定期归档分表策略上常见做法有两种一种是在Alarm DB Logger配置里看是否支持按天或按月生成表名如果支持让它自动按时间周期建新表另一种是配置SQL Server Agent作业每周或每月把生产表里超过保留期限的数据搬到历史表。无论哪种目的都是让生产报警表保持在一个可控的数据量级查询快备份也快。我不建议一开始就上特别复杂的分区方案先按年分表或者定期归档等数据量真的到千万级再评估分区表。4.2 查询SQL按报警组、优先级和时间段取数报警数据库配好后最常用的查询就是按报警组、优先级和时间段统计。Intouch里报警组是用户在标记名字典里配置的分组通常按装置或工艺区域划分比如Heating_Furnace、Compressor_Area优先级范围是1到999数值越大越紧急999为最高。下面的SQL按报警组和优先级统计某个月的报警次数SELECT AlarmGroup, Priority, COUNT(*) AS AlarmCount FROM [实际表名] WHERE OccurrenceTime 2025-01-01 00:00:00 AND OccurrenceTime 2025-02-01 00:00:00 AND Priority 500 GROUP BY AlarmGroup, Priority ORDER BY AlarmCount DESC;这个查询的逻辑是先把时间窗口卡死再按报警组和优先级维度聚合最后按数量倒序排列。时间窗口用和而不是BETWEEN是为了避免边界误差这也是写时间查询的一个习惯。Priority 500这个条件是过滤阈值现场需要看哪些级别的报警按自己的报警分级习惯调整。如果查询结果里报警组名和Intouch画面上的不一致回去检查标记名字典里的报警组配置查询库里的是全名画面上显示的可能有简化后缀。4.3 索引怎么加才不拖累报警写入报警表是典型的“高写入、中查询”场景索引加得太多会直接拖慢报警写入因为每条报警插入时都要同步更新索引。所以索引宁缺毋滥只给最常用的查询路径建复合索引。如果你们现场的固定查询是“查某段时间内高优先级的报警”就建时间和优先级的复合索引USE IntouchAlarmDB; CREATE NONCLUSTERED INDEX IX_Alarm_Time_Priority ON [实际表名] (OccurrenceTime DESC, Priority DESC); GOOccurrenceTime DESC放在第一列是因为所有报警查询几乎都会带上时间范围时间列做前导列能让索引落到最小数据区间再配合Priority DESC过滤高优先级报警查询代价会大幅下降。索引数量建议控制在两三个以内除了这个复合索引外最多再建一个报警组相关的索引如果已经做了按天分表表的规模小甚至只需要这一个复合索引就够了。报表查询不要直接连生产库跑大统计把第2章的只读账号拿来给报表工具用权限上只给db_datareader避免报表里写错条件影响业务。5. Intouch报警数据库配置常见问题断录、连不上、时间对不上的五个排查记录报警数据库配置完运行三个月内最容易出的问题基本都集中在连接、账号、时区和自动启动这几类。下面这五条是从现场积累下来的高频故障每条按现象、原因、解决的顺序写遇到类似情况可以直接照着排查。5.1 32位/64位ODBC混用Manager测试通过Intouch运行时就是不写库现象Alarm DB Logger Manager里测试连接成功甚至手动查询都能看到表结构但Intouch运行时一报警数据库里一条记录都没有HMI端也没有任何报错。原因Manager和Intouch运行时进程位数不一致各自读到的ODBC DSN列表不一样。常见情况是64位系统上同时装了32位和64位ODBC驱动Manager用64位DSN测试通过Intouch运行时是32位进程读的是32位DSN列表那里根本没有配置。解决用C:\Windows\SysWOW64\odbcad32.exe打开32位ODBC管理器确认系统DSN里确实存在配置如果Manager里能选到DSN但Intouch里不行把DSN删掉重建一次确保两端引用的是同一个DSN名称。5.2 SQL账号密码过期某天开始报警静默断录现象没有改过任何配置报警突然从某天开始断录SQL Server日志里有大量登录失败记录错误码是18456。原因SQL Server启用了密码过期策略或者IT周期性改密后没有同步到Alarm DB Logger Manager的配置里。报警写入失败是静默的Intouch画面上不会有任何提示只有查库才发现断了。解决给intouch_alarm账号设置密码永不过期如果公司安全策略强制定期改密就把改密和同步Alarm DB Logger配置放进同一个运维变更单改完密码后在Manager里重新执行测试连接确认恢复写入。5.3 报警时间与写库时间差8小时交接班对不上账现象报警表里的OccurrenceTime比现场实际发生时间晚8小时或者早8小时交接班对报警记录时两边怎么都对不上。原因Intouch运行节点的操作系统不是北京时间或者SQL Server实例的时区与会话时区不一致。报警写入时Intouch按本地时间生成时间戳ODBC驱动和SQL Server再按各自时区做一次转换中间多了一次偏移。解决统一工控机Windows时区为北京时间并确认SQL Server实例时区一致如果驱动和连接串支持时区参数在ODBC连接设置里显式指定。排查时先看两条时间报警表的写入时间和Intouch画面报警发生时间两者差值恒定时基本就是时区问题。5.4 数据库自动增长太小报警量大时Intouch画面都跟着卡现象报警写入高峰时段Intouch运行时页面操作明显变慢报警列表刷新一顿一顿的数据库里看等待统计文件增长等待时间很高。原因建库时如果用了默认配置数据文件初始大小很小FILEGROWTH是10%或1MB每次扩容需要等待SQL Server分配新空间报警写入被阻塞进而拖累Intouch进程。解决按第3章的建库脚本重建参数或者对现有库执行ALTER DATABASE把FILEGROWTH改成固定值256MB初始大小调整到1GB以上。日志文件也一并处理并尽量保证数据和日志分别放在不同物理磁盘上。5.5 重启后Alarm DB Logger没有自动运行多一些断档记录现象工控机因为断电或系统补丁重启后Intouch画面正常但报警库从重启时刻开始没有新数据直到人工发现并重新启动Alarm DB Logger才恢复。原因Alarm DB Logger没有配置成随系统或随WindowViewer自动启动之前是现场工程师手动开的重启后没拉起来。解决在Alarm DB Logger Manager里把启动模式改为自动。如果Manager里没有明确的自动启动选项就把启动入口放到WindowViewer的启动脚本里或者做成Windows计划任务在登录时执行。确认后手动重启一次工控机再验证报警是否自动写入。6. 把报警数据库当成巡检对象断档SQL、容量估算与恢复习惯报警数据库配置完不是终点运行期最怕的是断录了没人发现。我的习惯是把它当一台重要设备纳入日常巡检每天早班用一条SQL查前一天各小时报警条数哪个小时是零而且现场肯定有报警的立刻处理。这条SQL不长但救过好几次场USE IntouchAlarmDB; DECLARE CheckStart DATETIME DATEADD(HOUR, -24, GETDATE()); SELECT CONVERT(char(13), OccurrenceTime, 120) AS AlarmHour, COUNT(*) AS Cnt FROM [实际表名] WHERE OccurrenceTime CheckStart GROUP BY CONVERT(char(13), OccurrenceTime, 120) ORDER BY AlarmHour; GOCONVERT(char(13), OccurrenceTime, 120)的作用是把时间截断到小时例如2025-06-01 08:30:00转成2025-06-01 08:00然后按这个小时聚合计数。巡检时主要看输出里有没有出现0或明显偏低的时段一般夜班报警量低可以理解但连续两小时为0就要警惕。容量估算我习惯按“日报警量乘以512字节再乘以1.5”来算年增长量这个系数把索引和碎片都盖进去了。日报警量五千条的项目一年大概1.4GB磁盘规划和备份保留周期都按这个数预留。如果某天报警量突然翻倍先别急着加索引看看是不是某个点位在高频抖动先把报警源头压下去再说。万一报警库真断档了恢复顺序也有讲究。先确认当前报警流是否已恢复写入如果Alarm DB Logger有内存缓冲等它自己flush一段时间如果断档期间开了Intouch自身的报警历史文件还能从那里面导出补救报表如果都没开这段盲区只能认账这也是为什么把巡检SQL加进早班习惯比事后补救重要得多。我吃过这个亏现在每到新项目第一件事就是把这条断档检查SQL交给当班工程师让他们每天上班顺手跑一遍。希望帮到你。本文还有配套的精品资源点击获取
