尧图网站建设 
1. 场景分析为什么这个组合会被频繁提起1.1 从一次现场故障说起前阵子有个做政务系统的朋友找我说他们一套基于WebLogic的老应用要适配国产化环境数据库从Oracle切到瀚高结果部署完以后应用直接起不来控制台报了一堆数据源无法创建的异常。他截图给我看第一眼就知道问题出在哪驱动版本不对而且整个Domain的lib目录下还残留着Oracle的驱动类加载冲突了。这个场景在2024年到2025年特别常见。企业做信创适配中间件选来选去WebLogic依然是很多老牌Java应用无法绕开的一环。尤其那些从WebLogic 10g/11g时代就跑起来的系统代码里写了不少WebLogic特有的东西换Tomcat或者国产中间件风险不小。数据库这边瀚高HighGo数据库作为基于PostgreSQL内核的国产关系型数据库因为对Oracle兼容性做得比较早成了不少单位替换Oracle的首选目标。所以“WebLogic连瀚高”这个需求本质上不是一个新功能而是两套成熟技术栈之间的桥接。听起来简单实际踩坑不少。这篇文章把我实操过程中遇到的问题、排查的思路、最终确定的配置方案全部整理出来给后面接手类似任务的同学做个参考。1.2 核心难点在哪里先说结论WebLogic连瀚高难点不在连接本身而在于兼容性三层叠加。第一层是JDBC驱动兼容。WebLogic官方不提供瀚高的驱动需要从瀚高官方获取但瀚高的驱动本质上是PostgreSQL协议的扩展实现这就带来了类加载、驱动注册、URL格式、XA事务支持等一系列适配问题。第二层是WebLogic数据源的配置方式。WebLogic的数据源管理有自己的体系从WebLogic 12c开始支持JDBC穿越JDBC Forward能力可以复用数据源的事务管理能力把JDBC请求转发给内部数据源。但配置顺序、Classpath优先级、作用域处理任何一个地方错了都会导致应用层表现诡异。第三层是SQL兼容性。瀚高虽然做了Oracle兼容模式但绝大部分用户的应用代码里多多少少有些Oracle特有的写法比如dual表、sys_guid()、rownum分页、||字符串连接。数据源连上只是开始应用跑得起来才是目标。这三层问题只要理清楚了整个迁移流程就有了抓手。2. 动手之前的准备工作清单2.1 版本信息必须逐一确认开始配置之前先把版本矩阵理清楚。我这边实测过的组合是组件版本说明WebLogic12.2.1.4.012cR214c也能用但测试环境有限本文以12cR2为例瀚高数据库HGDB 6.1.3V6安全版基于PostgreSQL 12内核瀚高JDBC驱动highgo-jdbc-6.1.3.jar或者hgdbjdbc-版本号.jar瀚高官网下载部分版本命名不统一WebLogic JDBC支持默认自带12c版本对JDBC 4.0支持没问题JDK1.8.0_201WebLogic 12cR2强制要求JDK 8有个细节要特别提醒瀚高不同版本的驱动内部类名、包名、甚至支持的特性都有差异。比如早期的驱动类名是com.highgo.jdbc.Driver后期又出现了兼容PG的org.postgresql.Driver也可以连。拿错版本驱动勉强连上后续做XA或者批量插入的时候会出现一些莫名其妙的行为。所以最好是去瀚高官方技术支持渠道获取对应数据库小版本的驱动别图省事在Maven仓库拉一个旧版本。我自己保存驱动的习惯是在Domain目录下建一个lib子目录把驱动JAR丢进去然后在启动脚本setDomainEnv.sh里把CLASSPATH显式加上去。千万不要直接把驱动丢到WebLogic安装目录的lib下因为那是启动服务器的基础类路径污染了影响面太大。2.2 依赖包和类加载策略WebLogic的类加载机制比较特殊它的Classloader分为系统类加载器System Classpath、应用类加载器App Classpath和Web应用类加载器。数据源驱动的加载发生在系统级和应用级之间所以放驱动的位置会直接影响数据源能不能拿到完整驱动。我推荐的做法是放在Domain的lib目录并显式追加到CLASSPATH具体操作是这样cd /u01/app/oracle/domains/mydomain/lib # 假设驱动包已经上传到该目录 # 编辑 bin/setDomainEnv.sh在最终CLASSPATH拼接处追加 CLASSPATH${CLASSPATH}${CLASSPATHSEP}${DOMAIN_HOME}/lib/highgo-jdbc-6.1.3.jar export CLASSPATH有人会问为什么不直接放在DOMAIN_HOME/lib就能自动加载实际上WebLogic确实会自动加载这个目录下的JAR只不过对于部分版本的WebLogic自动加载的时机在数据源初始化之后导致你创建数据源时测试连接提示找不到驱动类。所以我更推荐显式追加的方式一次到位。另外要检查一下如果原来的应用依赖Oracle JDBC驱动建议把老的ojdbc*.jar先从lib目录里面清理掉。两条驱动同时在Classpath里面如果WebLogic内部某些代码引用了接口类恰好在两个包里都有实现轻则告警重则直接ClassCastException。提示WebLogic 12cR2自带的数据库驱动列表里没有瀚高但你不需要因此更改任何内置配置只需要让驱动在Classpath中可见即可。3. WebLogic数据源配置实操记录3.1 创建数据源的完整步骤我习惯用WebLogic控制台的图形界面来配数据源虽然有人喜欢用WLST脚本但第一次接通的时候图形界面能实时看到错误信息排查效率更高。控制台操作路径是服务 - 数据源 - 新建 - 通用数据源进入配置页后关键字段这么填名称HGDS自定义但要符合WebLogic的命名规范不要有空格和特殊字符JNDI名称jdbc/hgdb应用里引用这个建议统一规划命名别随手写数据库类型其他数据库驱动程序其它重点来了不要选任何WebLogic预置的驱动类型选其他之后下面会多出“JDBC驱动类”和“数据库URL”两个输入框。这里填JDBC驱动类com.highgo.jdbc.Driver 数据库URLjdbc:highgo://192.168.10.20:5866/hgtest?currentSchemapublicURL里的端口要留意瀚高数据库的默认端口是5866不是PostgreSQL的5432也不是Oracle的1521。这个端口在安装数据库的时候可以自定义建议在环境信息表里记录下来别到配置的时候才到处翻文档。下一步填写数据库连接属性数据库名称hgtest主机名192.168.10.20端口5866数据库用户名webuser密码对应密码然后一直下一步到“测试配置”这一步先点击“测试连接”。如果一切正常会显示连接成功的提示。这里如果报错大概率是URL格式或者驱动类名不对具体问题参考第5部分排查表格。3.2 连接池参数设计与负载考量数据源配置完成后还要对连接池参数做一轮调优。WebLogic数据源的连接池设置直接影响应用的并发能力默认值都比较保守生产环境一般要调整。我常用的参数组合如下参数建议值说明最大容量50根据应用并发量评估不能瞎设最小容量5保持基本链路通畅防止冷启动连接创建重试次数3默认10次太多数据库恢复时会产生大量无效连接连接保留时间60秒防止连接泄露占满连接池连接最大闲置时间300秒太短会让连接频繁重建太长容易积累老连接测试表名SQL SELECT 1每类驱动有不同的探测SQLPG内核的驱动用SELECT 1即可特别说一下“测试连接”机制。WebLogic支持后台定期测试连接测试方式有“测试连接”和“保留连接测试”两种。生产环境建议选择“测试连接”并配置测试频率为30秒。数据库重启时WebLogic能够自动恢复连接而不是一直报错直到应用重启。配置界面里还有一个“语句缓存”选项我通常设为50。这个参数会缓存常用的SQL预处理语句对减少解析开销有明显效果但也不是越大越好。语句缓存太大会占用内存尤其是SQL模式复杂的应用内存容易顶不住。3.3 穿越JDBC的配置方法如果你的应用里既有WebLogic数据源又有Spring管理的数据源或者应用通过java.sql.DriverManager直接获取连接这种场景就需要配置穿越JDBCJDBC Forward。穿越JDBC的本质把WebLogic数据源作为一个“代理”应用通过它拿到的连接实际上是从内部的数据源池里借的事务资源由WebLogic统一管理这样Spring的DataSourceTransactionManager和WebLogic的事务协调器才能对齐。在WebLogic控制台中的配置路径是新建数据源 - 选择“穿越JDBC”数据源 - 指定JNDI名称 - 选择一个已有的通用数据源作为“内部连接池”配置完成后应用里jdbc/hgdb这个JNDI拿到的数据源就具有了穿越能力。穿越JDBC有几个限制要提前知道底层内部数据源必须是通用数据源不能是其他穿越数据源穿越数据源不支持自定义XA事务连接池如果底层数据库本身不支持XA对瀚高数据库来说HGDB对XA的支持依赖hextrix组件没有启用时强行使用javax.sql.XADataSource会报错。我用的是单一数据源模式所以下面的操作都是非XA场景。4. 驱动选型与连接URL的参数解析4.1 瀚高JDBC驱动和PG驱动的取舍瀚高提供自家JDBC驱动的同时因为内核基于PostgreSQL原生的PostgreSQL JDBC驱动org.postgresql.Driver也可以连通瀚高数据库。面对这两种选择不少人有困惑。我的结论是优先使用瀚高官方驱动。原因有三条。第一官方驱动针对HGDB的Oracle兼容功能做过适配比如sys_guid()、dual表等语法在JDBC层的表现与瀚高数据库内部行为一致。用PG驱动虽然能用但遇到数据库层的Hints、强制索引等特性时可能出现行为不一致。第二瀚高驱动的URL支持currentSchema参数用于精确指定当前模式。PG驱动虽然也能通过options-csearch_path或currentSchema指定但在不同的HGDB版本中表现有差异。举个例子瀚高6.1.3版本的驱动和数据库配合直接设置currentSchema就可以正确解析不带schema前缀的表名而用PG 42.3.x版本驱动连同一个数据库部分场景下仍会解析到public模式。第三瀚高的驱动在事务隔离级别、系统列访问、批量更新效率方面做了特定优化如果遇到性能问题官方支持会让你提供驱动版本号他们方便定位。如果临时应急用org.postgresql.Driver也不是不行。我在测试环境验证过基础读写、预编译语句、事务提交回滚这些常规操作都没问题。但生产环境我强烈不建议这么干。4.2 JDBC URL里那些值得关注的参数瀚高JDBC驱动的URL结构如下jdbc:highgo://host:port/database?参数名值参数名值除了基础地址信息我建议你把下面这几个参数加上jdbc:highgo://192.168.10.20:5866/hgtest?currentSchemapubliccharSetutf-8defaultRowFetchSize100参数说明如下currentSchema指定默认模式解决“找不到表”的问题。这个参数放URL里比在应用代码里setSchema()更可靠因为数据源层面就固定了。charSet指定字符集虽然新版PG驱动已经支持UTF-8自动识别但部分老版本瀚高驱动里显式指定更稳能避免中文乱码。defaultRowFetchSize控制每次从数据库抓取的行数。设置太小会增加往返次数设置太大会让内存开销飙升。对于报表类大查询建议调到500左右对于OLTP小查询保持默认就行。URL参数还有一种写法是?Options-c search_pathpublic但这种方式在瀚高驱动上的表现不太一致我测试时发现在连接池环境下该参数偶尔失效。所以主推currentSchema参数。5. 应用适配中的SQL兼容问题与处理5.1 建表语句和数据类型映射连接配置搞定之后真正的迁移工作才刚开始。很多应用在WebLogic上跑得没问题数据库换成瀚高后最先暴露的是SQL兼容性问题。瀚高的V6版本提供多种数据库兼容模式常见的有pg、oracle、mysql。在初始化实例时或者创建数据库时可以指定CREATE DATABASE hgtest WITH TEMPLATE template0 ENCODING UTF8 LC_COLLATEzh_CN.UTF-8 LC_CTYPEzh_CN.UTF-8 CONNECTION LIMIT -1;进入数据库后通过SHOW compatible_mode;可以查看当前兼容模式。如果你要最大限度降低应用改造量建议在初始化时就设置为Oracle兼容模式。这套设置对序列、字符串连接、ID生成器、日期函数等行为都有影响。在建表语句上Oracle和瀚高的差异集中在几个点Oracle写法瀚高Oracle兼容模式写法备注NUMBER(10)NUMERIC(10)或NUMBER(10)Oracle兼容模式下NUMBER可用VARCHAR2(100)VARCHAR(100)兼容模式支持VARCHAR2DATETIMESTAMP瀚高建议用TIMESTAMPCLOBTEXT或CLOB大批量文本用TEXT性能更好SEQUENCE.NEXTVALSEQUENCE.NEXTVALOracle兼容模式下语法一致这里有个坑如果你的建表语句是从Oracle的导出工具生成的里面常带CREATE CLUSTER、CREATE TYPE BODY、CONNECT BY这类语法瀚高的Oracle兼容模式目前还没做到100%覆盖。我的实操经验是提前做一轮静态SQL扫描把不兼容的语句先筛出来逐个人工修订。5.2 UUID生成、序列和自增主键的玩法项目热词里提到的“瀚高数据库uuid”这里专门说一下。Oracle用户习惯用SYS_GUID()函数生成UUID瀚高在Oracle兼容模式下也提供了对应的SYS_GUID()实现。但你需要注意两点第一SYS_GUID()在瀚高里返回的是UUID字符串格式还是RAW类型不同版本行为不同。在6.1.x版本中SELECT SYS_GUID()返回的是一段32位十六进制字符串如果你在Oracle里的应用代码依赖RAW类型转VARCHAR2的隐式转换这里建议显式加上转换SELECT UPPER(REPLACE(CAST(SYS_GUID() AS VARCHAR(64)), -, )) FROM DUAL;第二PG模式下推荐的gen_random_uuid()函数需要先启用扩展CREATE EXTENSION IF NOT EXISTS pgcrypto; SELECT gen_random_uuid();这两个生成UUID的方式在应用代码里的使用路径不同。如果应用里用了MyBatis-plus的ID生成器它会走应用层的UUIDGenerator跟数据库无关如果是数据库默认值那就必须在建表时明确指定。还要注意序列缓存。WebLogic上的很多应用会通过Hibernate连接数据库建表Hibernate默认会用hibernate_sequence。在瀚高Oracle兼容模式下Hibernate生成的建表语句是create sequence hibernate_sequence start with 1 increment by 1这种语句没问题。但到了运行阶段序列的cache值默认是1高并发场景下会产生严重的序列争用。我建议提前执行ALTER SEQUENCE hibernate_sequence CACHE 100;如果是原来用Oracle的IDENTITY类型自增主键瀚高Oracle兼容模式下需要改成GENERATED BY DEFAULT AS IDENTITY或者利用序列设置默认值。这个迁移点如果没做全批跑数据的时候会明显感觉到性能差异。5.3 分页查询与动态SQL的差异性分页是WebLogic上跑的老系统最常见的Oracle兼容点。Oracle经典的分页三段式写法SELECT * FROM ( SELECT a.*, ROWNUM rn FROM ( SELECT * FROM t_orders ORDER BY create_time DESC ) a WHERE ROWNUM 20 ) WHERE rn 10;这段SQL在瀚高的Oracle兼容模式下是可以执行的但我实测下来还是要做一点适配更稳妥。原因是ROWNUM嵌套子查询时瀚高的优化器对部分复杂查询会生成错误的执行计划导致结果集不准确。推荐直接用PostgreSQL风格的分页语法兼容模式下也可以使用SELECT * FROM t_orders ORDER BY create_time DESC LIMIT 10 OFFSET 10;如果应用是一个老系统代码里SQL是动态拼的大量使用ROWNUM改造量会很大。建议写一个简单的正则替换工具把WHERE ROWNUM N和WHERE rn N这类模式自动转化。我们当时处理一个3000多行存储过程的时候就是用脚本批量替换再人工校对边界条件效率比手改快了近10倍。字符串连接也是高频差异。Oracle里用||这个瀚高兼容模式是支持的。但如果应用里面用的是CONCAT(a, b)这种双参数函数PG内核里CONCAT只支持双参数不过瀚高兼容模式一般扩充支持了多参数测试时要留意。还有NVL函数PG里对应的是COALESCE瀚高Oracle兼容模式也支持NVL这倒不用慌。日期函数方面Oracle的SYSDATE在瀚高Oracle兼容模式下支持TO_DATE、TO_CHAR也兼容。但TRUNC(SYSDATE)返回的精度、EXTRACT的字段行为会和Oracle略有差异。建议把所有日期操作集中在应用代码层完成减少对数据库函数的依赖。6. 常见问题与排错实战6.1 连接阶段的高频报错实际配置过程中大家遇到的坑基本都集中在连接阶段。我把亲自踩过的和帮别人排查过的典型案例整理成一个速查表。报错信息原因解决方案ClassNotFoundException: com.highgo.jdbc.Driver驱动JAR没放到Domain的lib下或CLASSPATH没生效重新检查驱动包位置和setDomainEnv.sh中的CLASSPATH设置Connection refused. Check that the hostname and port are correctIP/端口错误或瀚高数据库的pg_hba.conf没有放开远端访问修改pg_hba.conf增加对应网段的host记录然后SELECT pg_reload_conf();FATAL: password authentication failed账号密码错误或密码中有特殊字符确认瀚高用户的密码策略建议密码不含、#等可能在URL解析出问题的字符No suitable driver found for jdbc:highgoURL格式不符驱动不认识这个协议检查URL前缀必须是jdbc:highgo:如果是PG驱动前缀必须是jdbc:postgresql:Schema public not found数据库初始化时默认schema不是public指定currentSchema参数或修改数据库的search_pathORA-xxxxx或HG ERRCODE: 42P01: relation xxx does not exist表名没带schema前缀且search_path没包含目标schema设置URL的currentSchemaxxx或在SQL中显式写schema.table其中pg_hba.conf的问题最容易忽略。瀚高数据库安装完成后默认监听只允许本地连接。远程WebLogic服务器要连接必须修改数据目录下的pg_hba.conf增加一条类似以下内容的规则host all all 192.168.0.0/16 md5修改完后执行SELECT pg_reload_conf();这里的认证方式有md5和scram-sha-256两种瀚高6.1.x默认用的是md5千万不要在pg_hba.conf里指定一个和初始化参数不一致的认证方式不然会出现“认证方式不匹配”的报错。6.2 数据源通过测试但应用启动报错的诡异问题有一种情况很迷惑在WebLogic控制台测试连接是成功的但是应用部署启动后日志里一直在报获取连接超时。这类问题我在两个项目里都遇到过最终原因都指向同一个地方授权。具体来说WebLogic的管理用户和连接瀚高数据库的用户不是同一个。控制台测试连接走的是管理员配置的测试账号而应用通过JNDI获取连接时会走你在数据源里配置的“数据库用户”账号。如果这个账号权限不足比如没有对目标表的SELECT权限连接池里拿到的连接建立成功了但执行SQL时被数据库拒绝反映到应用层就成了连接被卡住或获取失败。解决思路把数据源配置里的用户换成一个具备实际业务表权限的账号并确保最小权限原则下该账号对关键表有CRUD权限。另外在瀚高里执行GRANT USAGE ON SCHEMA public TO webuser; GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO webuser;如果是新建的表默认权限还需要设置ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO webuser;6.3 事务与连接池性能相关排查WebLogic的数据源默认开启分阶段连接有时候数据源配置完之后连接池里的连接数一直增长但应用响应越来越慢。我在瀚高这边遇到过一个经典问题连接池里的连接被数据库侧的idle_in_transaction_session_timeout参数强制断开了而WebLogic仍以为连接是活的。这个参数是PostgreSQL 9.6以后引入的瀚高继承了该特性默认值是0表示不限时。但如果有人把它设成了比如60000一个持有连接但长时间不提交的事务到60秒会被数据库强制终止。应用下一次从这个池子取连接并执行SQL时就会收到org.postgresql.util.PSQLException: FATAL: terminating connection due to idle-in-transaction timeout。排查方法很直接在应用运行过程中在瀚高数据库里执行SELECT pid, state, wait_event_type, wait_event, query FROM pg_stat_activity WHERE state idle in transaction;如果看到大量这类连接要么是应用代码里事务管理不当要么就是数据库侧的超时设置过短。一般建议把数据库侧的idle_in_transaction_session_timeout设置为180000SQL标准事务一般不会超过这个时间。连接池方面WebLogic的Statement Prepare次数也需要关注。数据源级别开启缓存预备语句能显著降低PG内核数据库的解析开销但要注意缓存的是PreparedStatement如果应用SQL大量动态拼接命中率很低缓存了也白搭反而浪费内存。所以这个参数结合应用特点来设不是无脑开。7. 上线前必须做的验证与加固7.1 WebLogic侧的安全基线检查去年到今年WebLogic相关的安全通告一直没停过尤其是一些远程代码执行类漏洞利用工具在圈子里传播得很快。如果你们生产环境用的正好是WebLogic 10.3.6或者12.1.3这类老版本那我建议你把安全补丁升级作为数据库切换的伴生任务一起做。具体来说至少要做四件事第一升级到官方最新补丁包。WebLogic的补丁更新频率很快去Oracle官网下载对应版本的补丁执行OPatch应用即可。补丁打完以后把weblogic用户下的缓存清理掉不然偶尔会出现“补丁已打但漏洞扫描还是报风险”的假象。第二禁止不必要的T3协议入口。WebLogic的T3协议是历史漏洞重灾区如果应用不依赖RMI-IIOP就把默认的7001端口上的T3协议访问权限控制到最小范围。控制台操作路径是环境 - 服务器 - 管理服务器 - 协议 - 启用T3如果业务不需要直接取消勾选。此外可以通过网络层防火墙把7001端口只开放给特定的应用服务器网段。第三控制台管理路径不能暴露到公网。把/console路径加上访问限制WebLogic控制台自带的登录失败锁定策略默认偏弱建议把最大失败尝试次数设为3锁定时间设为30分钟。第四定期检查数据源的连接账号密码。数据库切换期间经常有临时账号残留这些账号如果权限过大就等于白送攻击者一个入口。瀚高这边可以通过视图查所有角色SELECT rolname, rolsuper, rolcreaterole, rolcreatedb FROM pg_roles ORDER BY rolsuper DESC, rolname;把不需要超级权限的账号全部收回来。7.2 数据一致性验证与回滚预案数据库切换最怕的是切换以后应用跑着跑着发现数据对不上。我建议上线前先做一轮数据一致性校验不要只看行数要看关键字段的哈希值。方案是在老库和新库之间对比核心表的行数、主键最大值、关键字段的值分布。如果是只读报表库可以写一个脚本遍历核心表对每张表执行SELECT COUNT(*), SUM(CRC32(CAST(主键字段 AS TEXT))) FROM 表名;在老库和新库都跑一遍结果一致基本可以放心。回滚预案也必不可少。我的建议是保留一套旧的WebLogic domain环境数据库连接配置指向老库。切换完成后至少保留一个观察窗口一般48小时期间新库数据以同步机制持续同步。一旦发现问题能把连接串改回去重启Domain即可回滚。这个操作听起来简单但如果没有提前准备好切换脚本故障时手忙脚乱是大概率事件。8. 几个值得参考的配置模板8.1 数据源配置样例下面是我在项目上最终稳定使用的数据源配置要点按WebLogic控制台的字段一一对应名称HG_DSJNDI名称jdbc/hg数据库驱动类com.highgo.jdbc.Driver数据库URLjdbc:highgo://10.10.20.15:5866/appdb?currentSchemaappcharSetutf-8defaultRowFetchSize200用户名app_user密码生产环境用WebLogic加密存储最大连接数50最小连接数5连接等待超时10秒连接创建重试次数3测试连接开启测试周期30秒测试SQLSELECT 18.2 WLST脚本方式如果服务器环境不允许频繁使用图形界面可以用WLST脚本创建数据源。脚本整体如下connect(weblogic,password,t3://127.0.0.1:7001) edit() startEdit() ds create(HG_DS, JDBCSystemResource) ds.setJNDINames(jdbc/hg) dp create(HG_DS, JDBCDataSourceParams, ds) dp.setJNDINames([jdbc/hg]) cp create(HG_DS, JDBCConnectionPoolParams, ds) cp.setMaxCapacity(50) cp.setMinCapacity(5) cd create(HG_DS, JDBCDataSourceParams, ds) # 驱动与URL x create(HG_DS, JDBCDriverParams, ds) x.setDriverName(com.highgo.jdbc.Driver) x.setUrl(jdbc:highgo://10.10.20.15:5866/appdb?currentSchemaapp) x.setPassword(password) # 属性 properties x.createProperty(user) properties.setValue(app_user) save() activate()这个脚本在WebLogic 12.2.1.4上实测通过。注意setPassword和properties.setValue两者都要设置密码和用户分属不同字段。另外创建完数据源后建议重启一下管理服务器确保JNDI绑定彻底生效。9. 学习资源与后续扩展建议9.1 学习渠道整理项目热词里有“瀚高数据库学习网站”我在做这个项目期间整理过一批实用资料渠道给大家做个参考。瀚高官方文档中心是优先级最高的资料。文档中心里面包含了数据库安装、兼容性说明、迁移工具指南内容比较全面。我第一次搭建HGDB的时候就是照着快速安装手册一步步来的整体比较顺畅。瀚高社区论坛和官方微信公众号也有一些技术文章更新比如Oracle迁移实战案例、典型故障处理这类内容。做信创项目的同学建议关注一下里面很多坑是前人踩过然后分享出来的能省不少时间。还有一类渠道容易被忽略PostgreSQL官方文档。既然瀚高内核基于PG那你把PG 12/13版的官方文档读透很多瀚高特有问题的本质都会原形毕露。尤其像锁等待、事务隔离级别、VACUUM机制这些问题PG文档比瀚高的产品文档写得还要细。9.2 后续可以做的延展方向数据库切换完成后有几个方向值得继续深化。一个是SQL性能调优。用EXPLAIN (ANALYZE, BUFFERS)分析慢SQL配合瀚高的pg_stat_statements插件可以快速定位高频SQL。相比Oracle的AWR报告这套体系的入门门槛更低但要看得懂Seq Scan和Index Scan的区别还是需要点PG内核知识。另一个方向是SQL审核工具的接入。如果团队规模大每个开发都能往数据库里跑SQL建议引入SQL审核机制在上线前拦截掉不规范SQL。不然今天一个隐式转换明天一个全表扫描数据库扛不到业务量起来的那一天。再一个是高可用架构建设。单机瀚高库如果跑的是核心业务建议及早规划主从或者集群方案。瀚高自带的hg_rman备份工具和streaming replication复制机制配置比Oracle Data Guard简单不少但同样需要测试环境验证。10. 实操中的体会与几个容易忽略的小细节最后说点不太容易写在官方文档里的东西都是实际操作中积累的感受。第一WebLogic连瀚高数据库第一步看似简单但整个迁移链条里配置数据源反而是最轻松的部分。真正花时间的是应用代码里的SQL兼容性适配。建议把静态SQL扫描放到项目计划里面留足时间。第二字符集乱码一定要在数据源层面解决不要在应用代码里反复转码。我遇到过一套系统应用代码里写了四五个编码转换逻辑最终在瀚高上对接时数据还是乱。后来把URL里的charSet参数固定为utf-8数据库初始化字符集也确认是UTF8问题才彻底解决。第三连接池大小不是越大越好。有人为了追求性能把最大连接数设到200结果瀚高数据库默认的max_connections才100连接全部堆积在数据库端等待。建议WebLogic侧连接池设到50以内数据库侧max_connections预留一半给DBA运维连接这样两头都安全。第四WebLogic的数据源监控页面值得每天看一眼。控制台“监控”页签下面能看到当前活跃连接数、等待连接数、连接泄露数。如果活跃连接长期接近上限不是连接池不够大而是SQL执行效率有问题这时候去调连接池是治标不治本。最后再分享一个小技巧在更换WebLogic数据源配置之前先手动用命令行测试一下驱动是否能连通瀚高数据库。写个简单的Java类加入驱动的classpath执行几行代码连接、查询、关闭。这一步5分钟就能做完但能把配置阶段的问题提前拦截住比在WebLogic控制台里反复试错省心得多。 WebLogic连接瀚高数据库：驱动配置与排错实战
1. 场景分析为什么这个组合会被频繁提起1.1 从一次现场故障说起前阵子有个做政务系统的朋友找我说他们一套基于WebLogic的老应用要适配国产化环境数据库从Oracle切到瀚高结果部署完以后应用直接起不来控制台报了一堆数据源无法创建的异常。他截图给我看第一眼就知道问题出在哪驱动版本不对而且整个Domain的lib目录下还残留着Oracle的驱动类加载冲突了。这个场景在2024年到2025年特别常见。企业做信创适配中间件选来选去WebLogic依然是很多老牌Java应用无法绕开的一环。尤其那些从WebLogic 10g/11g时代就跑起来的系统代码里写了不少WebLogic特有的东西换Tomcat或者国产中间件风险不小。数据库这边瀚高HighGo数据库作为基于PostgreSQL内核的国产关系型数据库因为对Oracle兼容性做得比较早成了不少单位替换Oracle的首选目标。所以“WebLogic连瀚高”这个需求本质上不是一个新功能而是两套成熟技术栈之间的桥接。听起来简单实际踩坑不少。这篇文章把我实操过程中遇到的问题、排查的思路、最终确定的配置方案全部整理出来给后面接手类似任务的同学做个参考。1.2 核心难点在哪里先说结论WebLogic连瀚高难点不在连接本身而在于兼容性三层叠加。第一层是JDBC驱动兼容。WebLogic官方不提供瀚高的驱动需要从瀚高官方获取但瀚高的驱动本质上是PostgreSQL协议的扩展实现这就带来了类加载、驱动注册、URL格式、XA事务支持等一系列适配问题。第二层是WebLogic数据源的配置方式。WebLogic的数据源管理有自己的体系从WebLogic 12c开始支持JDBC穿越JDBC Forward能力可以复用数据源的事务管理能力把JDBC请求转发给内部数据源。但配置顺序、Classpath优先级、作用域处理任何一个地方错了都会导致应用层表现诡异。第三层是SQL兼容性。瀚高虽然做了Oracle兼容模式但绝大部分用户的应用代码里多多少少有些Oracle特有的写法比如dual表、sys_guid()、rownum分页、||字符串连接。数据源连上只是开始应用跑得起来才是目标。这三层问题只要理清楚了整个迁移流程就有了抓手。2. 动手之前的准备工作清单2.1 版本信息必须逐一确认开始配置之前先把版本矩阵理清楚。我这边实测过的组合是组件版本说明WebLogic12.2.1.4.012cR214c也能用但测试环境有限本文以12cR2为例瀚高数据库HGDB 6.1.3V6安全版基于PostgreSQL 12内核瀚高JDBC驱动highgo-jdbc-6.1.3.jar或者hgdbjdbc-版本号.jar瀚高官网下载部分版本命名不统一WebLogic JDBC支持默认自带12c版本对JDBC 4.0支持没问题JDK1.8.0_201WebLogic 12cR2强制要求JDK 8有个细节要特别提醒瀚高不同版本的驱动内部类名、包名、甚至支持的特性都有差异。比如早期的驱动类名是com.highgo.jdbc.Driver后期又出现了兼容PG的org.postgresql.Driver也可以连。拿错版本驱动勉强连上后续做XA或者批量插入的时候会出现一些莫名其妙的行为。所以最好是去瀚高官方技术支持渠道获取对应数据库小版本的驱动别图省事在Maven仓库拉一个旧版本。我自己保存驱动的习惯是在Domain目录下建一个lib子目录把驱动JAR丢进去然后在启动脚本setDomainEnv.sh里把CLASSPATH显式加上去。千万不要直接把驱动丢到WebLogic安装目录的lib下因为那是启动服务器的基础类路径污染了影响面太大。2.2 依赖包和类加载策略WebLogic的类加载机制比较特殊它的Classloader分为系统类加载器System Classpath、应用类加载器App Classpath和Web应用类加载器。数据源驱动的加载发生在系统级和应用级之间所以放驱动的位置会直接影响数据源能不能拿到完整驱动。我推荐的做法是放在Domain的lib目录并显式追加到CLASSPATH具体操作是这样cd /u01/app/oracle/domains/mydomain/lib # 假设驱动包已经上传到该目录 # 编辑 bin/setDomainEnv.sh在最终CLASSPATH拼接处追加 CLASSPATH${CLASSPATH}${CLASSPATHSEP}${DOMAIN_HOME}/lib/highgo-jdbc-6.1.3.jar export CLASSPATH有人会问为什么不直接放在DOMAIN_HOME/lib就能自动加载实际上WebLogic确实会自动加载这个目录下的JAR只不过对于部分版本的WebLogic自动加载的时机在数据源初始化之后导致你创建数据源时测试连接提示找不到驱动类。所以我更推荐显式追加的方式一次到位。另外要检查一下如果原来的应用依赖Oracle JDBC驱动建议把老的ojdbc*.jar先从lib目录里面清理掉。两条驱动同时在Classpath里面如果WebLogic内部某些代码引用了接口类恰好在两个包里都有实现轻则告警重则直接ClassCastException。提示WebLogic 12cR2自带的数据库驱动列表里没有瀚高但你不需要因此更改任何内置配置只需要让驱动在Classpath中可见即可。3. WebLogic数据源配置实操记录3.1 创建数据源的完整步骤我习惯用WebLogic控制台的图形界面来配数据源虽然有人喜欢用WLST脚本但第一次接通的时候图形界面能实时看到错误信息排查效率更高。控制台操作路径是服务 - 数据源 - 新建 - 通用数据源进入配置页后关键字段这么填名称HGDS自定义但要符合WebLogic的命名规范不要有空格和特殊字符JNDI名称jdbc/hgdb应用里引用这个建议统一规划命名别随手写数据库类型其他数据库驱动程序其它重点来了不要选任何WebLogic预置的驱动类型选其他之后下面会多出“JDBC驱动类”和“数据库URL”两个输入框。这里填JDBC驱动类com.highgo.jdbc.Driver 数据库URLjdbc:highgo://192.168.10.20:5866/hgtest?currentSchemapublicURL里的端口要留意瀚高数据库的默认端口是5866不是PostgreSQL的5432也不是Oracle的1521。这个端口在安装数据库的时候可以自定义建议在环境信息表里记录下来别到配置的时候才到处翻文档。下一步填写数据库连接属性数据库名称hgtest主机名192.168.10.20端口5866数据库用户名webuser密码对应密码然后一直下一步到“测试配置”这一步先点击“测试连接”。如果一切正常会显示连接成功的提示。这里如果报错大概率是URL格式或者驱动类名不对具体问题参考第5部分排查表格。3.2 连接池参数设计与负载考量数据源配置完成后还要对连接池参数做一轮调优。WebLogic数据源的连接池设置直接影响应用的并发能力默认值都比较保守生产环境一般要调整。我常用的参数组合如下参数建议值说明最大容量50根据应用并发量评估不能瞎设最小容量5保持基本链路通畅防止冷启动连接创建重试次数3默认10次太多数据库恢复时会产生大量无效连接连接保留时间60秒防止连接泄露占满连接池连接最大闲置时间300秒太短会让连接频繁重建太长容易积累老连接测试表名SQL SELECT 1每类驱动有不同的探测SQLPG内核的驱动用SELECT 1即可特别说一下“测试连接”机制。WebLogic支持后台定期测试连接测试方式有“测试连接”和“保留连接测试”两种。生产环境建议选择“测试连接”并配置测试频率为30秒。数据库重启时WebLogic能够自动恢复连接而不是一直报错直到应用重启。配置界面里还有一个“语句缓存”选项我通常设为50。这个参数会缓存常用的SQL预处理语句对减少解析开销有明显效果但也不是越大越好。语句缓存太大会占用内存尤其是SQL模式复杂的应用内存容易顶不住。3.3 穿越JDBC的配置方法如果你的应用里既有WebLogic数据源又有Spring管理的数据源或者应用通过java.sql.DriverManager直接获取连接这种场景就需要配置穿越JDBCJDBC Forward。穿越JDBC的本质把WebLogic数据源作为一个“代理”应用通过它拿到的连接实际上是从内部的数据源池里借的事务资源由WebLogic统一管理这样Spring的DataSourceTransactionManager和WebLogic的事务协调器才能对齐。在WebLogic控制台中的配置路径是新建数据源 - 选择“穿越JDBC”数据源 - 指定JNDI名称 - 选择一个已有的通用数据源作为“内部连接池”配置完成后应用里jdbc/hgdb这个JNDI拿到的数据源就具有了穿越能力。穿越JDBC有几个限制要提前知道底层内部数据源必须是通用数据源不能是其他穿越数据源穿越数据源不支持自定义XA事务连接池如果底层数据库本身不支持XA对瀚高数据库来说HGDB对XA的支持依赖hextrix组件没有启用时强行使用javax.sql.XADataSource会报错。我用的是单一数据源模式所以下面的操作都是非XA场景。4. 驱动选型与连接URL的参数解析4.1 瀚高JDBC驱动和PG驱动的取舍瀚高提供自家JDBC驱动的同时因为内核基于PostgreSQL原生的PostgreSQL JDBC驱动org.postgresql.Driver也可以连通瀚高数据库。面对这两种选择不少人有困惑。我的结论是优先使用瀚高官方驱动。原因有三条。第一官方驱动针对HGDB的Oracle兼容功能做过适配比如sys_guid()、dual表等语法在JDBC层的表现与瀚高数据库内部行为一致。用PG驱动虽然能用但遇到数据库层的Hints、强制索引等特性时可能出现行为不一致。第二瀚高驱动的URL支持currentSchema参数用于精确指定当前模式。PG驱动虽然也能通过options-csearch_path或currentSchema指定但在不同的HGDB版本中表现有差异。举个例子瀚高6.1.3版本的驱动和数据库配合直接设置currentSchema就可以正确解析不带schema前缀的表名而用PG 42.3.x版本驱动连同一个数据库部分场景下仍会解析到public模式。第三瀚高的驱动在事务隔离级别、系统列访问、批量更新效率方面做了特定优化如果遇到性能问题官方支持会让你提供驱动版本号他们方便定位。如果临时应急用org.postgresql.Driver也不是不行。我在测试环境验证过基础读写、预编译语句、事务提交回滚这些常规操作都没问题。但生产环境我强烈不建议这么干。4.2 JDBC URL里那些值得关注的参数瀚高JDBC驱动的URL结构如下jdbc:highgo://host:port/database?参数名值参数名值除了基础地址信息我建议你把下面这几个参数加上jdbc:highgo://192.168.10.20:5866/hgtest?currentSchemapubliccharSetutf-8defaultRowFetchSize100参数说明如下currentSchema指定默认模式解决“找不到表”的问题。这个参数放URL里比在应用代码里setSchema()更可靠因为数据源层面就固定了。charSet指定字符集虽然新版PG驱动已经支持UTF-8自动识别但部分老版本瀚高驱动里显式指定更稳能避免中文乱码。defaultRowFetchSize控制每次从数据库抓取的行数。设置太小会增加往返次数设置太大会让内存开销飙升。对于报表类大查询建议调到500左右对于OLTP小查询保持默认就行。URL参数还有一种写法是?Options-c search_pathpublic但这种方式在瀚高驱动上的表现不太一致我测试时发现在连接池环境下该参数偶尔失效。所以主推currentSchema参数。5. 应用适配中的SQL兼容问题与处理5.1 建表语句和数据类型映射连接配置搞定之后真正的迁移工作才刚开始。很多应用在WebLogic上跑得没问题数据库换成瀚高后最先暴露的是SQL兼容性问题。瀚高的V6版本提供多种数据库兼容模式常见的有pg、oracle、mysql。在初始化实例时或者创建数据库时可以指定CREATE DATABASE hgtest WITH TEMPLATE template0 ENCODING UTF8 LC_COLLATEzh_CN.UTF-8 LC_CTYPEzh_CN.UTF-8 CONNECTION LIMIT -1;进入数据库后通过SHOW compatible_mode;可以查看当前兼容模式。如果你要最大限度降低应用改造量建议在初始化时就设置为Oracle兼容模式。这套设置对序列、字符串连接、ID生成器、日期函数等行为都有影响。在建表语句上Oracle和瀚高的差异集中在几个点Oracle写法瀚高Oracle兼容模式写法备注NUMBER(10)NUMERIC(10)或NUMBER(10)Oracle兼容模式下NUMBER可用VARCHAR2(100)VARCHAR(100)兼容模式支持VARCHAR2DATETIMESTAMP瀚高建议用TIMESTAMPCLOBTEXT或CLOB大批量文本用TEXT性能更好SEQUENCE.NEXTVALSEQUENCE.NEXTVALOracle兼容模式下语法一致这里有个坑如果你的建表语句是从Oracle的导出工具生成的里面常带CREATE CLUSTER、CREATE TYPE BODY、CONNECT BY这类语法瀚高的Oracle兼容模式目前还没做到100%覆盖。我的实操经验是提前做一轮静态SQL扫描把不兼容的语句先筛出来逐个人工修订。5.2 UUID生成、序列和自增主键的玩法项目热词里提到的“瀚高数据库uuid”这里专门说一下。Oracle用户习惯用SYS_GUID()函数生成UUID瀚高在Oracle兼容模式下也提供了对应的SYS_GUID()实现。但你需要注意两点第一SYS_GUID()在瀚高里返回的是UUID字符串格式还是RAW类型不同版本行为不同。在6.1.x版本中SELECT SYS_GUID()返回的是一段32位十六进制字符串如果你在Oracle里的应用代码依赖RAW类型转VARCHAR2的隐式转换这里建议显式加上转换SELECT UPPER(REPLACE(CAST(SYS_GUID() AS VARCHAR(64)), -, )) FROM DUAL;第二PG模式下推荐的gen_random_uuid()函数需要先启用扩展CREATE EXTENSION IF NOT EXISTS pgcrypto; SELECT gen_random_uuid();这两个生成UUID的方式在应用代码里的使用路径不同。如果应用里用了MyBatis-plus的ID生成器它会走应用层的UUIDGenerator跟数据库无关如果是数据库默认值那就必须在建表时明确指定。还要注意序列缓存。WebLogic上的很多应用会通过Hibernate连接数据库建表Hibernate默认会用hibernate_sequence。在瀚高Oracle兼容模式下Hibernate生成的建表语句是create sequence hibernate_sequence start with 1 increment by 1这种语句没问题。但到了运行阶段序列的cache值默认是1高并发场景下会产生严重的序列争用。我建议提前执行ALTER SEQUENCE hibernate_sequence CACHE 100;如果是原来用Oracle的IDENTITY类型自增主键瀚高Oracle兼容模式下需要改成GENERATED BY DEFAULT AS IDENTITY或者利用序列设置默认值。这个迁移点如果没做全批跑数据的时候会明显感觉到性能差异。5.3 分页查询与动态SQL的差异性分页是WebLogic上跑的老系统最常见的Oracle兼容点。Oracle经典的分页三段式写法SELECT * FROM ( SELECT a.*, ROWNUM rn FROM ( SELECT * FROM t_orders ORDER BY create_time DESC ) a WHERE ROWNUM 20 ) WHERE rn 10;这段SQL在瀚高的Oracle兼容模式下是可以执行的但我实测下来还是要做一点适配更稳妥。原因是ROWNUM嵌套子查询时瀚高的优化器对部分复杂查询会生成错误的执行计划导致结果集不准确。推荐直接用PostgreSQL风格的分页语法兼容模式下也可以使用SELECT * FROM t_orders ORDER BY create_time DESC LIMIT 10 OFFSET 10;如果应用是一个老系统代码里SQL是动态拼的大量使用ROWNUM改造量会很大。建议写一个简单的正则替换工具把WHERE ROWNUM N和WHERE rn N这类模式自动转化。我们当时处理一个3000多行存储过程的时候就是用脚本批量替换再人工校对边界条件效率比手改快了近10倍。字符串连接也是高频差异。Oracle里用||这个瀚高兼容模式是支持的。但如果应用里面用的是CONCAT(a, b)这种双参数函数PG内核里CONCAT只支持双参数不过瀚高兼容模式一般扩充支持了多参数测试时要留意。还有NVL函数PG里对应的是COALESCE瀚高Oracle兼容模式也支持NVL这倒不用慌。日期函数方面Oracle的SYSDATE在瀚高Oracle兼容模式下支持TO_DATE、TO_CHAR也兼容。但TRUNC(SYSDATE)返回的精度、EXTRACT的字段行为会和Oracle略有差异。建议把所有日期操作集中在应用代码层完成减少对数据库函数的依赖。6. 常见问题与排错实战6.1 连接阶段的高频报错实际配置过程中大家遇到的坑基本都集中在连接阶段。我把亲自踩过的和帮别人排查过的典型案例整理成一个速查表。报错信息原因解决方案ClassNotFoundException: com.highgo.jdbc.Driver驱动JAR没放到Domain的lib下或CLASSPATH没生效重新检查驱动包位置和setDomainEnv.sh中的CLASSPATH设置Connection refused. Check that the hostname and port are correctIP/端口错误或瀚高数据库的pg_hba.conf没有放开远端访问修改pg_hba.conf增加对应网段的host记录然后SELECT pg_reload_conf();FATAL: password authentication failed账号密码错误或密码中有特殊字符确认瀚高用户的密码策略建议密码不含、#等可能在URL解析出问题的字符No suitable driver found for jdbc:highgoURL格式不符驱动不认识这个协议检查URL前缀必须是jdbc:highgo:如果是PG驱动前缀必须是jdbc:postgresql:Schema public not found数据库初始化时默认schema不是public指定currentSchema参数或修改数据库的search_pathORA-xxxxx或HG ERRCODE: 42P01: relation xxx does not exist表名没带schema前缀且search_path没包含目标schema设置URL的currentSchemaxxx或在SQL中显式写schema.table其中pg_hba.conf的问题最容易忽略。瀚高数据库安装完成后默认监听只允许本地连接。远程WebLogic服务器要连接必须修改数据目录下的pg_hba.conf增加一条类似以下内容的规则host all all 192.168.0.0/16 md5修改完后执行SELECT pg_reload_conf();这里的认证方式有md5和scram-sha-256两种瀚高6.1.x默认用的是md5千万不要在pg_hba.conf里指定一个和初始化参数不一致的认证方式不然会出现“认证方式不匹配”的报错。6.2 数据源通过测试但应用启动报错的诡异问题有一种情况很迷惑在WebLogic控制台测试连接是成功的但是应用部署启动后日志里一直在报获取连接超时。这类问题我在两个项目里都遇到过最终原因都指向同一个地方授权。具体来说WebLogic的管理用户和连接瀚高数据库的用户不是同一个。控制台测试连接走的是管理员配置的测试账号而应用通过JNDI获取连接时会走你在数据源里配置的“数据库用户”账号。如果这个账号权限不足比如没有对目标表的SELECT权限连接池里拿到的连接建立成功了但执行SQL时被数据库拒绝反映到应用层就成了连接被卡住或获取失败。解决思路把数据源配置里的用户换成一个具备实际业务表权限的账号并确保最小权限原则下该账号对关键表有CRUD权限。另外在瀚高里执行GRANT USAGE ON SCHEMA public TO webuser; GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO webuser;如果是新建的表默认权限还需要设置ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO webuser;6.3 事务与连接池性能相关排查WebLogic的数据源默认开启分阶段连接有时候数据源配置完之后连接池里的连接数一直增长但应用响应越来越慢。我在瀚高这边遇到过一个经典问题连接池里的连接被数据库侧的idle_in_transaction_session_timeout参数强制断开了而WebLogic仍以为连接是活的。这个参数是PostgreSQL 9.6以后引入的瀚高继承了该特性默认值是0表示不限时。但如果有人把它设成了比如60000一个持有连接但长时间不提交的事务到60秒会被数据库强制终止。应用下一次从这个池子取连接并执行SQL时就会收到org.postgresql.util.PSQLException: FATAL: terminating connection due to idle-in-transaction timeout。排查方法很直接在应用运行过程中在瀚高数据库里执行SELECT pid, state, wait_event_type, wait_event, query FROM pg_stat_activity WHERE state idle in transaction;如果看到大量这类连接要么是应用代码里事务管理不当要么就是数据库侧的超时设置过短。一般建议把数据库侧的idle_in_transaction_session_timeout设置为180000SQL标准事务一般不会超过这个时间。连接池方面WebLogic的Statement Prepare次数也需要关注。数据源级别开启缓存预备语句能显著降低PG内核数据库的解析开销但要注意缓存的是PreparedStatement如果应用SQL大量动态拼接命中率很低缓存了也白搭反而浪费内存。所以这个参数结合应用特点来设不是无脑开。7. 上线前必须做的验证与加固7.1 WebLogic侧的安全基线检查去年到今年WebLogic相关的安全通告一直没停过尤其是一些远程代码执行类漏洞利用工具在圈子里传播得很快。如果你们生产环境用的正好是WebLogic 10.3.6或者12.1.3这类老版本那我建议你把安全补丁升级作为数据库切换的伴生任务一起做。具体来说至少要做四件事第一升级到官方最新补丁包。WebLogic的补丁更新频率很快去Oracle官网下载对应版本的补丁执行OPatch应用即可。补丁打完以后把weblogic用户下的缓存清理掉不然偶尔会出现“补丁已打但漏洞扫描还是报风险”的假象。第二禁止不必要的T3协议入口。WebLogic的T3协议是历史漏洞重灾区如果应用不依赖RMI-IIOP就把默认的7001端口上的T3协议访问权限控制到最小范围。控制台操作路径是环境 - 服务器 - 管理服务器 - 协议 - 启用T3如果业务不需要直接取消勾选。此外可以通过网络层防火墙把7001端口只开放给特定的应用服务器网段。第三控制台管理路径不能暴露到公网。把/console路径加上访问限制WebLogic控制台自带的登录失败锁定策略默认偏弱建议把最大失败尝试次数设为3锁定时间设为30分钟。第四定期检查数据源的连接账号密码。数据库切换期间经常有临时账号残留这些账号如果权限过大就等于白送攻击者一个入口。瀚高这边可以通过视图查所有角色SELECT rolname, rolsuper, rolcreaterole, rolcreatedb FROM pg_roles ORDER BY rolsuper DESC, rolname;把不需要超级权限的账号全部收回来。7.2 数据一致性验证与回滚预案数据库切换最怕的是切换以后应用跑着跑着发现数据对不上。我建议上线前先做一轮数据一致性校验不要只看行数要看关键字段的哈希值。方案是在老库和新库之间对比核心表的行数、主键最大值、关键字段的值分布。如果是只读报表库可以写一个脚本遍历核心表对每张表执行SELECT COUNT(*), SUM(CRC32(CAST(主键字段 AS TEXT))) FROM 表名;在老库和新库都跑一遍结果一致基本可以放心。回滚预案也必不可少。我的建议是保留一套旧的WebLogic domain环境数据库连接配置指向老库。切换完成后至少保留一个观察窗口一般48小时期间新库数据以同步机制持续同步。一旦发现问题能把连接串改回去重启Domain即可回滚。这个操作听起来简单但如果没有提前准备好切换脚本故障时手忙脚乱是大概率事件。8. 几个值得参考的配置模板8.1 数据源配置样例下面是我在项目上最终稳定使用的数据源配置要点按WebLogic控制台的字段一一对应名称HG_DSJNDI名称jdbc/hg数据库驱动类com.highgo.jdbc.Driver数据库URLjdbc:highgo://10.10.20.15:5866/appdb?currentSchemaappcharSetutf-8defaultRowFetchSize200用户名app_user密码生产环境用WebLogic加密存储最大连接数50最小连接数5连接等待超时10秒连接创建重试次数3测试连接开启测试周期30秒测试SQLSELECT 18.2 WLST脚本方式如果服务器环境不允许频繁使用图形界面可以用WLST脚本创建数据源。脚本整体如下connect(weblogic,password,t3://127.0.0.1:7001) edit() startEdit() ds create(HG_DS, JDBCSystemResource) ds.setJNDINames(jdbc/hg) dp create(HG_DS, JDBCDataSourceParams, ds) dp.setJNDINames([jdbc/hg]) cp create(HG_DS, JDBCConnectionPoolParams, ds) cp.setMaxCapacity(50) cp.setMinCapacity(5) cd create(HG_DS, JDBCDataSourceParams, ds) # 驱动与URL x create(HG_DS, JDBCDriverParams, ds) x.setDriverName(com.highgo.jdbc.Driver) x.setUrl(jdbc:highgo://10.10.20.15:5866/appdb?currentSchemaapp) x.setPassword(password) # 属性 properties x.createProperty(user) properties.setValue(app_user) save() activate()这个脚本在WebLogic 12.2.1.4上实测通过。注意setPassword和properties.setValue两者都要设置密码和用户分属不同字段。另外创建完数据源后建议重启一下管理服务器确保JNDI绑定彻底生效。9. 学习资源与后续扩展建议9.1 学习渠道整理项目热词里有“瀚高数据库学习网站”我在做这个项目期间整理过一批实用资料渠道给大家做个参考。瀚高官方文档中心是优先级最高的资料。文档中心里面包含了数据库安装、兼容性说明、迁移工具指南内容比较全面。我第一次搭建HGDB的时候就是照着快速安装手册一步步来的整体比较顺畅。瀚高社区论坛和官方微信公众号也有一些技术文章更新比如Oracle迁移实战案例、典型故障处理这类内容。做信创项目的同学建议关注一下里面很多坑是前人踩过然后分享出来的能省不少时间。还有一类渠道容易被忽略PostgreSQL官方文档。既然瀚高内核基于PG那你把PG 12/13版的官方文档读透很多瀚高特有问题的本质都会原形毕露。尤其像锁等待、事务隔离级别、VACUUM机制这些问题PG文档比瀚高的产品文档写得还要细。9.2 后续可以做的延展方向数据库切换完成后有几个方向值得继续深化。一个是SQL性能调优。用EXPLAIN (ANALYZE, BUFFERS)分析慢SQL配合瀚高的pg_stat_statements插件可以快速定位高频SQL。相比Oracle的AWR报告这套体系的入门门槛更低但要看得懂Seq Scan和Index Scan的区别还是需要点PG内核知识。另一个方向是SQL审核工具的接入。如果团队规模大每个开发都能往数据库里跑SQL建议引入SQL审核机制在上线前拦截掉不规范SQL。不然今天一个隐式转换明天一个全表扫描数据库扛不到业务量起来的那一天。再一个是高可用架构建设。单机瀚高库如果跑的是核心业务建议及早规划主从或者集群方案。瀚高自带的hg_rman备份工具和streaming replication复制机制配置比Oracle Data Guard简单不少但同样需要测试环境验证。10. 实操中的体会与几个容易忽略的小细节最后说点不太容易写在官方文档里的东西都是实际操作中积累的感受。第一WebLogic连瀚高数据库第一步看似简单但整个迁移链条里配置数据源反而是最轻松的部分。真正花时间的是应用代码里的SQL兼容性适配。建议把静态SQL扫描放到项目计划里面留足时间。第二字符集乱码一定要在数据源层面解决不要在应用代码里反复转码。我遇到过一套系统应用代码里写了四五个编码转换逻辑最终在瀚高上对接时数据还是乱。后来把URL里的charSet参数固定为utf-8数据库初始化字符集也确认是UTF8问题才彻底解决。第三连接池大小不是越大越好。有人为了追求性能把最大连接数设到200结果瀚高数据库默认的max_connections才100连接全部堆积在数据库端等待。建议WebLogic侧连接池设到50以内数据库侧max_connections预留一半给DBA运维连接这样两头都安全。第四WebLogic的数据源监控页面值得每天看一眼。控制台“监控”页签下面能看到当前活跃连接数、等待连接数、连接泄露数。如果活跃连接长期接近上限不是连接池不够大而是SQL执行效率有问题这时候去调连接池是治标不治本。最后再分享一个小技巧在更换WebLogic数据源配置之前先手动用命令行测试一下驱动是否能连通瀚高数据库。写个简单的Java类加入驱动的classpath执行几行代码连接、查询、关闭。这一步5分钟就能做完但能把配置阶段的问题提前拦截住比在WebLogic控制台里反复试错省心得多。