Teradata Unity下SessionID不匹配及被动路由配置问询

被动路由模式下的SessionID篡改判定 #

• 你当前遇到的查询返回0行的核心原因，是现有Unity采用主动代理路由模式：Unity作为会话的中间连接端点介入全链路交互，会自主维护一套内部会话映射关系，替换TCP报文中原本携带的数据库侧SessionID，导致抓包提取的SessionID和DBC.SESSIONINFO中存储的SESSIONNO值不匹配。
• 被动路由（透明透传路由）模式下，Unity仅做三层/二层报文的无状态转发，不介入TCP连接的握手、载荷交互流程：
  • 不会修改Teradata会话建立报文中携带的SessionID字段
  • 不会替换数据库侧返回给客户端的真实会话标识值
  • 该模式下抓包提取的SessionID与数据库内部存储的SESSIONNO完全一致，不会出现值不匹配的问题
• 顺带提一句：你写的查询语句里的视图名存在拼写缺漏，Teradata环境下存储会话信息的标准视图为DBC.SESSIONINFO，就算路由配置正确，拼写错误的视图名也会导致查询无结果，别在这类低级问题上踩坑。

Unity路由规则的生产实践经验 #

• 路由切换后先做对照校验再上线代码：别等DBA说配置完成就直接开始跑正式逻辑，先拉测试账号建1个常规会话做值比对：一边在客户端网段抓包，记录解析得到的SessionID；一边在数据库侧执行SELECT SESSIONNO, USERNAME, LOGONTIME FROM DBC.SESSIONINFO WHERE USERNAME = '<测试账号名>'拿到真实SESSIONNO，两个值完全匹配后再开始写正式解析逻辑，避免中间存在其他代理层的悄悄篡改，白费功夫。
• 报文解析阶段记得过滤无效报文：哪怕开启被动透传模式，只要Unity配置了空闲会话强制断连策略，就会主动发送一批携带内部映射SessionID的TCP FIN/RST断连报文，解析代码需要过滤掉这类非会话建立阶段的报文，不要把断连报文中的标识误判为真实业务会话的SessionID。
• 路由模式不用为了抓包硬切：如果你的解析代码部署在数据库服务端网段，其实无需调整Unity的现有路由配置——主动路由模式下Unity自身会维护「客户端连接-数据库真实会话」的映射关系，直接读取这套映射表就能拿到匹配的SessionID，比逐包解析的可靠性更高。只有当你的代码部署在客户端网段、必须直接解析客户端发出的TCP报文时，才需要申请调整为被动路由模式。
• 加密场景提前确认传输状态：被动透传模式下的Unity不会解密SSL加密的会话载荷，如果你的Teradata会话走了加密传输，就算路由配置正确，抓包拿到的也是加密后的密文载荷，根本无法提取到内部的SessionID字段，提前确认好抓包位置能否拿到解密后的明文，避免做无用的配置调整。

额外提醒：Teradata的SessionID是存储在会话初始化握手报文的专门逻辑载荷字段中，和TCP端口号没有固定映射关系，不要试图直接用TCP端口号推导SessionID值，这是该场景下非常常见的踩坑点。

内容的提问来源于stack exchange，提问作者Thrama