Oracle WebLogic 数据库连接原理及案例探讨

Presentation on theme: "Oracle WebLogic 数据库连接原理及案例探讨"— Presentation transcript:

1 Oracle WebLogic 数据库连接原理及案例探讨

2 关于我 一 一 一 一 一 一 一 郑波涛 （helloweblogic) 上海东方龙马 中间件技术顾问
浙江Oracle User Group 联合创始人 一 博客： 一 QQ： 一 TEL： ZJOUG China中间件 一

3 主题 WLS JDBC的架构 6种JDBC典型故障 经典故障案例

4 JDBC的架构

5 JDBC的架构 通过java 标准编程访问： 对应用程序透明的、可靠的性能：
WSL DataSource 是一个成熟的、稳定的连接池功能，并有一些高级组件可选： 通过java 标准编程访问： DS 可以通过管理进行配置 使用标准 JDNI API调用 使用标准的jdbc API get/close 数据库连接 对应用程序透明的、可靠的性能： Prepared Statement 缓存 自动实现数据库故障的切换和恢复 支持App访问jdbc 驱动特定的对象，以实现对特定供应商的标准进行扩展

6 JDBC的架构 Generic Data Source Multi Data Source GridLink DataSource
WebLogic有3中连接类型Data Source： Generic Data Source Multi Data Source GridLink DataSource WLS Data Source和WLS JTA 事务服务紧紧的集成在一起 JAVA EE应用应始终使用WLS DS App应用可以使用JTA 事务

7 JDBC的架构 JTA 事务和JDBC事务的区别： 分为局部事务和全局事务（分布式事务） 分布式事务即涉及多个数据库的事务
关于事务 分为局部事务和全局事务（分布式事务） 分布式事务即涉及多个数据库的事务 XA规范-2pc协议（2Phase Commit） WebLogic 实现了对对全局事务的单阶段优化

8 JDBC的架构 用与连接单一数据库的DS 实际支持任何JDBC标准的驱动 支持多节点的url配置 Generic Data Sources
(address=(host= ) (protocol=tcp)(port=1521))(address=(host= )(protocol=tcp) (port=1521)) (load_balance=yes)(failover=yes))(connect_data=(service_name= db.hello.com)))

9 JDBC的架构 实际上是包含多个Generic Data Source 用于多节点数据库
Multi Data Sources 实际上是包含多个Generic Data Source 用于多节点数据库 支持JTA事务之间的load-balancing策略和failover 配置静态化，去节点手动执行 是一种比较老的连接RAC数据库的策略 11g中增加到了Grid Link DS

10 JDBC的架构 Multi Data Sources

11 JDBC的架构 专用连接RAC 集群数据库环境 11gr2中新增加的连接RAC 集群的策略 GridLink Data Sources
一个RAC 集群对应一个DS 快速的连接恢复，自动适应RAC的拓扑变化 针对各RAC节点的压力进行分发，实现动态负载均衡 配置容易，简便 使用SCAN地址配置方式、ONS/FAN时间驱动通知方式 完美支持Oracle database 12c Web session Affinity Transaction Affinity Oracle Notification Service，分主节点ONS和子节点ONS，就是Oracle分布式集群系统中各服务器上发布和上报因为用户手工初始化、依赖服务失败、运行失败，自动重启等原因产生的"UP，DOWN，Not_restart，Restart_failed，Node_Down，preConn_Up，preConn_Down"事件的进程，是构成高可用性容灾系统的心跳服务。 ps -ef |grep ons只能看到ONS服务是否在运行中，onsctl ping才能确认ORC服务运行是否正常。

12 JDBC的架构 GridLink Data Sources 通过Active GridLink for RAC 将性能提升 3 倍
将 WebLogic 与数据库 RAC 集群相集成 • 动态负载平衡 RAC 节点请求 • RAC 节点事务关联为本地处理 • 无论 RAC 怎样发生变化也能保持连接

13 GridLink DS 快速连接恢复(Fast Connection Failover) 快速的数据库错误定位
自动从pool中消除无效的连接 自动识别新加入或者去除的RAC节点

14 GridLink DS 动态负载均衡(Runtime Connection Load Balancing)
可以根据负荷分配请求到不同的RAC节点

15 GridLink DS Web Session-base Affinity 针对对应用选择一个最佳性能的RAC 实例作为连接
平均响应时间减半、互联流量大幅减少

16 GridLink DS Transection-base Affinity
基于全局事务id,而不是ds 确保不同的ds连接是同一个RAC 节点

17 GridLink DS 可用性大大提高 通过ONS提供故障通知 与幸存节点建立新连接 恢复通知 正常RAC节点关闭
Oracle Notification Service，分主节点ONS和子节点ONS，就是Oracle分布式集群系统中各服务器上发布和上报因为用户手工初始化、依赖服务失败、运行失败，自动重启等原因产生的"UP，DOWN，Not_restart，Restart_failed，Node_Down，preConn_Up，preConn_Down"事件的进程，是构成高可用性容灾系统的心跳服务。 ps -ef |grep ons只能看到ONS服务是否在运行中，onsctl ping才能确认ORC服务运行是否正常。

18 GridLink DS 性能大大提高 RCLB可将运行时连接负载分配给空闲的节点 性能提升2-3倍 提高性能的可预测性

19 GridLink DS 提高可管理性 GridLink可隔离WebLogic不收RAC更改的影响 自动检测RAC节点
更简单 更可靠、零停机

20 动态添加 RAC 节点 响应时间缩短约 30%

21 典型JDBC故障6宗之一 <BEA > <Failed to initialize the application ‘TestDataSource’ due to error weblogic.application.ModuleException: . weblogic.application.ModuleException: at weblogic.jdbc.module.JDBCModule.prepare(JDBCModule.java:289) at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:93)at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:387) weblogic.common.ResourceException: Could not create pool connection. The DBMS driver exception was: The Network Adapter could not establish the connection - – - – - – 或者- – - – - - weblogic.common.ResourceException: weblogic.common.ResourceException: Could not create pool connection. The DBMS driver exception was: Io exception: The Network Adapter could not establish the connection

22 典型JDBC故障6宗之一 检查<DOMAIN_HOME>\config\jdbc下的每一个数据源的配置文件，xml文件，数据库的URL,TNS名称，端口等等的配置是否正确，这要和DBA进行确认； 检查weblogic启动中驱动程序加载是否正确，即驱动jar包是否在classpath中，这个默认是有的； 如果检查都是成功的，可以使用dbping命令来测试一下数据库是否正常。测试的命令如下：java -classpath /bea103/wl_server103/server/lib/weblogic.jar utils.dbping ORACLE_THIN <dbUserName> <dbPasswoes> <dbURL> telnet 数据库服务器的端口是否成功

23 典型JDBC故障6宗之二 <localhost.localdomain> <AppServer01> <[ACTIVE] ExecuteThread: '95' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> < > <BEA > <Received exception while creating connection for pool "np": Io exception: Got minus one from a read call> Caused by: java.sql.SQLRecoverableException: Io exception: Got minus one from a read call

24 典型JDBC故障6宗之二 数据库在维护的时候或者数据库在不一致状态下发生的，比如数据库还没起好在unmounting状态
检查Server log查看报错的最早时间，并和数据库端进行比对确认； 与DBA进行确认，在这个时间点数据库端发生了什么事情。 为了进一步详细获取信息，可以使用一些debug参数 -Dweblogic.resourcepool.max_test_wait_secs=xx -Dweblogic.debug.DebugJDBCSQL=true -Dweblogic.log.StdoutSeverity=Debug

25 典型JDBC故障6宗之三 console看到数据源的状态是SUSPENDED/DISABLED状态
首先可以使用telnet检查数据的端口是否正常。 再可以使用其他一些客户端连接数据库用户名和DS的一样。 如果可以，可以手动将数据源进行停止再启动，命令如下： 1），执行suspend: java weblogic.Admin -url t3://localhost:7001 -username weblogic -password weblogic SUSPEND_POOL DataSourceName 2），执行启动：java weblogic.Admin -url t3://localhost:7001 -username weblogic -password weblogic RESUME_POOL DataSourceName

26 典型JDBC故障6宗之四 <Warning> <JDBC> <BEA > <Forcibly releasing inactive connection back into the connection pool “TestDataSource”, currently reserved by: java.lang.Exception 非环境问题，意思是“你的应用程序已经获取到一个Connection对象并没有释放，或者因为一直在等待数据库的返回而hanging“ 连接泄露 可以通过inactive time out缓解

27 典型JDBC故障6宗之五 java.sql.SQLException: Closed Connection
At oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:70) 应用获取到的connection对象是不可用的 将连接池的“Test Connection On Reserve”参数打开 执行select 1 from dual 测试

28 典型JDBC故障6宗之六 java.sql.SQLException: No more data to read from socket
at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1200) at oracle.jdbc.driver.T4CMAREngine.unmarshalSB1(T4CMAREngine.java:1155) at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:279) 应用程序以及从数据源获取到了一个数据库连接对象，但是应用程序自身以及检测到这个连接以及time out 或者已经是staled状态了。 需要手工进行数据库的重启或者是WebLogic Server的重启 简单一招：将数据源重新部署一下，使连接池进行重置

29 Support Pattern: JDBC_Causes_Server_Hang
再赠送一个经典故障： Support Pattern: JDBC_Causes_Server_Hang

30 Support Pattern: JDBC_Causes_Server_Hang
问题现象分析 App 或wls本身调用的connection会阻塞一个thread的执行 长时间占用thread 即使transaction超时，也不会终止，wls只是标记为rollback 抛出异常如下： 最终导致 Server 挂起！ 无休止的Hung。。。。 唯一的办法：restart ! <ExecuteThread: '64' for queue: 'default' has been busy for "740" seconds working on the request "Scheduled Trigger", which is more than the configured time (StuckThreadMaxTime) of "600" seconds.> <kernel identity> <> <000339> <ExecuteThread: '66' for queue: 'default' has become "unstuck".>

31 Support Pattern: JDBC_Causes_Server_Hang
为什么发生此问题？ 在JDBC代码中使用了DriverManager.getConnection() 发送给DB的SQL执行时间异常的长 配置了JDBC连接池的数据库挂起且不及时从调用返回 低速或超载的网络导致数据库调用速度减慢或挂起 死锁导致所有执行线程挂起和永久等待 JDBC 连接池中的 RefreshMinutes 或 TestFrequencySeconds 属性导致 WebLogic Server 中出现挂起期间。 JDBC 连接池收缩和数据库连接的重新创建使响应时间变长

32 Support Pattern: JDBC_Causes_Server_Hang
如何处理此问题？ 分析挂起的Server实例，通过threadump分析 优化JDBC代码，主要是SQL 优化JDBC连接池的配置 优化数据库的性能，比如表索引，sql执行计划,数据量大小

33 经验分享 分析问题，要尽可能的走自己的路 从Java虚拟机的角度而不是应用程序的角度考虑问题
尽可能的通过参数和配置而不是改应用代码来解决问题 不要轻易认同开发人员的问题解决方式 不要被用户和开发人员误导入歧途 否则可真就是“自寻死路”

34 Thank You ! ZJOUG 微 信 公 众 号：【ZJOUG】 Helloweblogic微信公众号：【China中间件】