企业官网建设流程全解析

简介：本资源是一份面向工业自动化领域工程师与系统集成人员的Intouch报警数据库配置技术指南，聚焦解决实际项目中Alarm DB Logger与SQL Server数据库对接、报警状态持久化及服务化部署等核心问题，尤其适用于电力、水处理等对报警可靠性要求严苛的行业场景。文档为单页PDF（12KB），内容精炼但覆盖完整配置链路：从SQL Server混合验证模式切换、数据库连接参数设置，到详细/合并记录模式选择、报警优先级范围定义、自定义查询语句编写，再到Alarm DB Logger作为Windows服务的注册流程，每步均附关键操作提示与注意事项。预览显示其特别强调身份验证强制要求、测试连接验证机制及配置向导分步逻辑，具备强实操性与排错参考价值。目前已有317人学习下载，适合需快速掌握Intouch报警数据落地规范的中级以上自动化开发与运维人员。

1. Intouch报警数据库配置：不是“配个连接”就完事，而是SQL Server混合模式+Alarm DB Logger服务化落地的硬核闭环

你是不是也遇到过这样的场景：Intouch画面里报警灯狂闪，但历史报警查不到一条记录？点开Alarm DB Logger Manager，测试连接明明显示“成功”，可一到实际运行，日志里就反复刷出那句玄学报错——“无法打开Intouch应用程序。请参阅记录器以获取详细信息。”？别急着重装软件，这90%不是Intouch的问题，而是你漏掉了那个被文档轻描淡写带过的前提：Alarm DB Logger只认SQL Server混合身份验证，且必须是SQL Server身份验证（sa或自定义SQL账户），Windows认证直接拒之门外。这份PDF不是操作手册的简化版，它是工业现场踩坑十年后沉淀下来的“血泪配置清单”：从SQL Server验证模式强制切换、ODBC驱动版本兼容性、到Alarm DB Logger作为Windows服务的启动权限陷阱，每一步都卡在真实产线重启失败的临界点上。适合正在备考自动化系统集成工程师（尤其电力/水厂方向）、刚接手老厂Intouch改造项目的调试工程师，以及被甲方逼着“今天必须把历史报警存进数据库”的现场实施人员——它不讲原理，只告诉你哪一步手抖按错，整套系统就瘫痪4小时。

2. SQL Server混合模式改造：从Windows认证到SQL认证的强制切换实操

Alarm DB Logger对认证方式的限制不是建议，是硬性拦截。当你在SQL Server Management Studio里看到“仅Windows身份验证”时，Alarm DB Logger Manager里的“测试连接”按钮根本不会触发真正的连接尝试——它连登录凭据都构造不出来。必须先让SQL Server本身支持SQL Server身份验证，再创建专用账户，这是所有后续配置的地基。

2.1 验证当前SQL Server身份验证模式

不要依赖安装时的记忆，直接用SQL Server Management Studio（SSMS）确认现状。以管理员身份启动SSMS，连接到目标实例（通常是localhost\SQLEXPRESS或你的计算机名\实例名），执行以下查询：

SELECT SERVERPROPERTY('IsIntegratedSecurityOnly') AS IsWindowsAuthOnly;

提示：返回值为1表示仅Windows认证；返回0表示已启用混合模式。若为1，必须执行下一步改造。

2.2 强制启用混合身份验证（SQL Server 2016+通用流程）

虽然原文以SQL Server 2005为例，但2016/2019/2022的界面逻辑一致，只是路径微调。关键不是“右键属性”，而是必须通过SSMS图形界面修改，命令行sp_configure在此场景下无效：

1. 在SSMS对象资源管理器中，右键服务器节点（如DESKTOP-ABC\SQLEXPRESS）→ 选择“属性”
2. 左侧导航栏点击“安全性”（Security）
3. 在右侧找到“服务器身份验证”（Server authentication）选项
4. 将单选框从“Windows 身份验证模式”切换为“SQL Server 和 Windows 身份验证模式”
5. 点击“确定”→ 此时SSMS会弹出警告：“更改此设置需要重启SQL Server服务。是否现在重启？” →务必选择“否”（关键！）

注意：此处不能直接点“是”。因为重启服务会中断所有现有连接，而你尚未创建SQL登录账户，重启后可能连SSMS都连不上。先完成账户创建，再统一重启。

2.3 创建专用SQL Server登录账户（非sa！）

Alarm DB Logger要求显式输入用户名密码，sa账户因安全策略常被禁用或密码复杂导致ODBC连接失败。必须创建独立账户：

-- 在SSMS新建查询窗口，连接到master数据库，执行： CREATE LOGIN [intouch_alarm] WITH PASSWORD = 'YourStrongPass123!'; USE [master]; CREATE USER [intouch_alarm] FOR LOGIN [intouch_alarm]; -- 授予对报警数据库的db_owner权限（假设库名为AlarmDB） USE [AlarmDB]; CREATE USER [intouch_alarm] FOR LOGIN [intouch_alarm]; ALTER ROLE [db_owner] ADD MEMBER [intouch_alarm];

参数说明：YourStrongPass123!需满足SQL Server密码策略（大写+小写+数字+符号，长度≥8）。AlarmDB需替换为你实际创建的数据库名。db_owner是最低权限要求，若生产环境需更细粒度控制，至少授予INSERT,SELECT,UPDATE权限。

2.4 重启SQL Server服务并验证

此时才执行重启：

• 打开Windows服务管理器（services.msc）
• 找到服务名类似SQL Server (SQLEXPRESS)或SQL Server (MSSQLSERVER)
• 右键 →“重新启动”
• 重启完成后，在SSMS中用新账户intouch_alarm测试登录：新建连接 → 选择“SQL Server身份验证” → 输入用户名密码 → 确认能成功连接到AlarmDB库

逻辑说明：这步验证的是底层SQL Server是否真正接受SQL认证。如果此处失败，Alarm DB Logger Manager的“测试连接”必然失败，且错误信息模糊（常显示“连接超时”而非认证错误），必须卡在这一步解决。

3. Alarm DB Logger Manager配置向导：四步闭环配置与ODBC驱动兼容性校验

配置向导看似线性，但每一步都埋着产线级陷阱。尤其当你的SQL Server是2022版，而Intouch版本较老（如v10.1）时，“测试连接”成功不代表后续能写入——ODBC驱动版本不匹配会导致运行时静默丢数据。

3.1 数据库连接配置：服务器名、实例名与端口的精确写法

原文说“输入安装了报警数据库的计算机的节点名”，但实际中90%的翻车发生在服务器名填写错误：

参数说明：逗号,分隔IP和端口是ODBC标准语法，不是冒号。1433是SQL Server默认TCP端口，若自定义端口（如15000），必须写成192.168.1.100,15000。

3.2 记录模式选择：详细模式 vs 合并模式的业务影响

这不是技术偏好，而是直接影响HMI历史报警查询效率：

• 详细模式：每条报警状态变化（激活→确认→复位）生成独立记录，表结构含AlarmState字段（值为Active/Acknowledged/Normal）。优点：支持按状态筛选，如“只查已确认报警”；缺点：数据量爆炸，1个持续10分钟的报警可能产生30+条记录。
• 合并模式：单条记录包含StartTime、AckTime、EndTime三个时间戳字段。优点：存储紧凑，查询“某报警的完整生命周期”极快；缺点：无法单独统计“当前有多少未确认报警”，需额外逻辑解析。

实战建议：电力SCADA系统必选合并模式——调度员关注的是“这个报警从发生到结束用了多久”，而非“它被点了几次确认”。水厂PLC报警则推荐详细模式——运维需追溯“为什么操作员没及时确认”。

3.3 ODBC驱动版本强制校验（避坑核心）

Alarm DB Logger底层使用Microsoft ODBC Driver for SQL Server。Intouch v10.x默认捆绑ODBC Driver 11，而SQL Server 2019+要求Driver 17+。若不匹配，现象是：

• “测试连接”成功（驱动能握手）
• 但运行后日志报错：[08001] [Microsoft][ODBC Driver 17 for SQL Server]SSL Provider: The certificate chain was issued by an authority that is not trusted.

解决方案：

1. 下载最新ODBC Driver：访问微软官网搜索"ODBC Driver 18 for SQL Server"（2023年最新稳定版）
2. 安装时勾选“为所有用户安装”（关键！否则Alarm DB Logger服务无权限读取）
3. 在Windows ODBC数据源管理器（odbcad32.exe）中，切换到“系统DSN”页签 → 确认存在名为"ODBC Driver 18 for SQL Server"的驱动

验证命令：在PowerShell中执行Get-OdbcDriver | Where-Object {$_.Name -like "*SQL Server*"}，输出应含ODBC Driver 18 for SQL Server。

3.4 创建数据库的隐藏条件

原文说“单击创建以创建数据库”，但实际触发条件是：

• 数据库名字段必须填不存在的库名（如填AlarmDB但该库不存在）
• 用户账户intouch_alarm必须对master库有CREATE DATABASE权限（默认无）

若权限不足，点击“创建”后无任何提示，日志静默失败。临时解决方案：

USE [master]; GRANT CREATE DATABASE TO [intouch_alarm]; -- 创建后立即回收权限（安全最佳实践） REVOKE CREATE DATABASE FROM [intouch_alarm];

4. 报警查询与优先级过滤：从“全量记录”到“精准捕获”的工业级裁剪

Alarm DB Logger的“报警查询”功能不是SQL语句编辑器，而是Intouch内部报警标签的元数据过滤器。填错一个字符，整个报警记录模块就失效。

4.1 报警状态与查询类型的映射关系

原文提到“只读的报警状态框显示要记录的报警状态”，但未说明其来源。该状态由Intouch工程中的报警组（Alarm Group）配置决定：

关键逻辑：Alarm DB Logger不解析Intouch脚本，只读取编译后的报警组二进制元数据。因此修改报警组后，必须重新下载（Download）Intouch工程到运行节点，否则配置不生效。

4.2 报警查询框的语法规范（非标准SQL）

此处易被误解为可写任意SQL，实际是Intouch专有语法，仅支持以下操作符：

• AND/OR（大写）
• =/!=/>/<
• 字符串用单引号：'HighTemp'
• 通配符用*（非%）：Tagname LIKE 'PUMP*'

错误示例：
SELECT * FROM AlarmTable WHERE Priority > 50→语法错误，Alarm DB Logger直接忽略整条配置
正确写法：
Priority > 50 AND Category = 'Critical'

4.3 记录间隔的物理意义与采样陷阱

“以毫秒为单位输入将报警记录写入报警数据库的间隔”——这不是轮询周期，而是报警事件去抖动（Debouncing）时间窗。例如设为5000（5秒）：

• 同一报警标签在5秒内连续触发10次，只记录首次触发时刻
• 若第6秒再次触发，则视为新事件记录

参数选择经验：

• PLC级快速报警（如电机过流）：设100~500ms，避免高频抖动
• HMI人工确认类报警（如“阀门未关到位”）：设5000~30000ms，防止操作员连点确认产生冗余记录

5. Alarm DB Logger服务化部署：Windows服务权限与启动失败的终极排查

配置成Windows服务不是为了“后台运行”，而是解决Intouch运行账户与数据库账户的权限上下文隔离问题。很多项目在“正常应用程序”模式下调试成功，一转服务就报错，根源在此。

5.1 服务账户权限的三重校验

Alarm DB Logger服务默认以Local System账户运行，但该账户无权访问网络SQL Server（除非SQL Server明确授权NT AUTHORITY\SYSTEM）。必须改为专用账户：

1. 在服务管理器中，找到服务名Alarm DB Logger
2. 右键 →“属性”→ 切换到“登录”页签
3. 选择“此账户”→ 输入intouch_alarm（即2.3创建的SQL账户）
4. 关键步骤：点击“浏览”→ 在弹出窗口中输入intouch_alarm→ 点击“检查名称” → 确认解析为yourdomain\intouch_alarm→ 输入密码两次

注意：此处密码必须与SQL Server中intouch_alarm登录密码完全一致。Windows服务账户密码变更后，SQL Server密码不会自动同步，需手动更新。

5.2 启动失败的四大现象与根因定位

5.3 避坑：常见问题与血泪排查清单

现象1：服务启动成功，但SQL Server Profiler抓不到任何INSERT语句
→原因：Alarm DB Logger服务账户intouch_alarm对AlarmDB库只有db_datareader权限，缺少INSERT权限
→解决：在SSMS中执行ALTER ROLE [db_datawriter] ADD MEMBER [intouch_alarm];

现象2：Intouch画面报警闪烁，但Alarm DB Logger日志显示Alarm queue is empty
→原因：Intouch工程中报警组的Log to Database属性未勾选（默认关闭）
→解决：在Intouch Designer中打开报警组属性 → 勾选Log to Database→ 重新下载工程

现象3：配置向导中“测试连接”成功，但服务模式下报Login failed for user 'intouch_alarm'
→原因：SQL Server的intouch_alarm账户被设为“强制密码过期”，而Windows服务无法交互式更新密码
→解决：在SSMS中执行ALTER LOGIN [intouch_alarm] WITH PASSWORD_EXPIRY = OFF;

现象4：Alarm DB Logger服务启动后，Intouch主程序崩溃退出
→原因：Alarm DB Logger与Intouch版本不兼容（如Intouch v11.5需Alarm DB Logger v3.0+，旧版v2.x会冲突）
→解决：查阅Intouch安装目录下的Readme.txt，确认配套的Alarm DB Logger版本号，从Wonderware官网下载对应补丁包

现象5：数据库记录时间比实际报警晚30秒以上
→原因：Windows系统时间与PLC时间不同步，且Alarm DB Logger默认使用本地系统时间戳
→解决：在Intouch工程中启用Use PLC Time for Alarms（需PLC支持SNTP），或在Windows中配置NTP服务器同步

6. 生产环境验证技巧：用SQL Server Profiler抓取真实写入行为与故障回滚预案

配置完成不等于可用。真正的验收不是看“测试连接成功”，而是用SQL Server Profiler捕获到第一条INSERT INTO AlarmDB.dbo.AlarmLog语句，并验证时间戳、报警标签、状态字段全部准确。这才是工业现场签字交付的底线。

6.1 Profiler最小化跟踪模板配置

为避免性能干扰，禁用所有无关事件：

操作步骤：启动Profiler → 新建跟踪 → 选择上述事件 → 在“列筛选器”中设置DatabaseName为AlarmDB→ 点击“运行”。此时触发Intouch一次报警，观察是否出现INSERT语句。

6.2 关键字段验证表（AlarmDB.dbo.AlarmLog结构）

Alarm DB Logger默认建表语句生成以下核心字段，必须逐项核对：

6.3 故障回滚的后悔药：配置文件备份与服务状态快照

生产环境最怕“改完就炸”。每次修改配置前，必须执行三步保命操作：

1. 备份配置文件：

   :: 在Alarm DB Logger安装目录（如C:\Program Files\Wonderware\AlarmDBLogger\）执行 copy AlarmDBLogger.cfg AlarmDBLogger.cfg.bak.%date:~0,4%%date:~5,2%%date:~8,2%

2. 导出服务当前状态：

   # PowerShell命令，导出服务配置快照 Get-Service "Alarm DB Logger" | Select-Object Name, Status, StartType, DisplayName | Export-Csv "AlarmDBLogger_Service_Snapshot.csv" -Encoding UTF8

3. 记录SQL Server登录状态：

   -- 在SSMS中执行，保存当前登录账户状态 SELECT name, is_disabled, password_hash FROM sys.sql_logins WHERE name = 'intouch_alarm';

我的血泪习惯：从那以后我每次在客户现场做Alarm DB Logger配置，都强制走一遍这三步——哪怕只是改一个毫秒数。因为见过太多人改完“记录间隔”从5000改成1000，结果SQL Server磁盘IO打满，连远程桌面都卡死，而.bak文件就是唯一救命稻草。希望帮到你。

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