使用Apusic Studio监控SQL执行情况

本文介绍如何利用 ApusicAdminConsole 的数据源连接监控和数据源事件跟踪功能,来诊断业务数据访问慢及写入错误的问题。通过具体案例演示了如何定位 SQLServer 访问缓慢的原因。

前言

技术支持工作过程中,我们通常碰到这样两种情况:第一,访问业务数据慢,但又不知慢在何处;第二,写入的业务数据出错,但又不知为何出错。其实, Apusic Admin Console 工具中,包含了数据源连接监控和数据源事件跟踪两大功能,特别是后者,能够有效帮助我们去分析解决以上两种问题。本文将简要介绍如何使用 Admin Console 中的这两大功能。

 


1        数据源连接监控

1.1    添加 Apusic 应用服务器

数据源连接监控需要在 Apusic Admin Console 中添加 Apusic 应用服务器。下面描述 Step by Step 的添加过程。

1 )切换到“ Apusic 管理”透视图。

2 )在“ Apusic 服务器列表”视图中,点击鼠标右键,点击“增加服务器”。

3 )在弹出窗体,选择“ Apusic 应用服务器”。

4 )然后,选择“远程服务器”,输入主机、端口、用户、密码等信息,点击“ finish ”按钮完成。

1.2    启动 Apusic 应用服务器

一般情况下,启动 Apusic 应用服务器这个步骤不是必须的,因这个时候 Apusic 应用服务器可能已经正在运行了。如在测试或者调试环境,需要确认 Apusic 应用服务器已经启动。

1.3    连接 Apusic 应用服务器

在“ Apusic 服务器列表”视图中,点中刚添加的 Apusic ,点击鼠标右键,在弹出菜单中,点击“连接”。

然后再弹出窗体,输入用户、密码,点击“ ok ”按钮。

如有防火墙,请允许 eclipse 的连接。

1.4    使用数据源连接监控

连接上 Apusic 后,在 Apusic Admin Console 中,选择“数据源连接监控”透视图。

在“数据源连接监控”视图,双击所要监控的 Apusic 下的数据源。

在该数据源的视图中,我们就可以查看详细的连接使用的统计情况,包括创建数、关闭数、空闲连接数、总连接数、等待线程数等。

需要注意以下几点:

(1)    如等待线程数不为 0 ,则表示数据库连接池可能设置得不够大

(2)    如创建数明显大于关闭数,超出合理的水平,则表现可能存在连接泄漏

(3)    等待时间或使用时间峰值过大,表明可能存在数据库访问方面的瓶颈

除了统计数据外,还可以查看活动连接 / 非活动连接的调用栈。那些活动时间过长的连接,特别需要加于留意。

 


2        数据源事件跟踪

2.1    配置数据源事件跟踪

连接上 Apusic 后,在 Apusic Admin Console 中,选择“数据源事件跟踪”透视图。

选择菜单中的“文件” ->New-> “跟踪”。

在“新建跟踪”窗体,输入跟踪名,选择服务器,并选中需要跟踪的数据源,点“ Next ”按钮。

 

下一步需要将跟踪到的事件信息暂存到数据库中。添加 URL 、驱动类名、驱动类路径、表名等信息,点击“ Next ”按钮。

下一步比较关键,我们可以选定跟踪的事件类型,包括 SQL 的语句执行、连接获取、设置自动提交、连接提交、连接回滚、连接关闭等事件,以及事务的开始、完成事件。

我们也可以选择感兴趣的数据列进行查看,最后,点击“ Finish ”按钮,完成。。

数据源事件跟踪将自动启动,在数据源跟踪视图中,将可以看到 SQL 语句,执行时间,堆栈等非常重要的信息了。

 

2.2    实战数据源事件跟踪

某客户应用,数据库为 SQL Server ,反馈访问缓慢。通过数据源事件跟踪,定位到问题。为了便于阅读,剥离应用场景,演示代码如下:

<%@ page import="java.sql.*"%>

<%@ page import="javax.sql.*"%>

<%@ page import="javax.naming.*"%>

<%

Context ctx = null;

DataSource ds = null;

Connection conn = null;

Statement stmt = null;

ResultSet rs = null;

String jndi = "cyDataSource";

String sql_insert = "insert into test(id,name,code) values(1,'1','1')";

String sql_update = "update test set name='2'";

String sql_query = "select * from test";

try {

ctx = new InitialContext();

ds = (DataSource)ctx.lookup(jndi);

conn = ds.getConnection();

 

conn.setAutoCommit(false);

stmt = conn.createStatement();

stmt.executeUpdate(sql_insert);

stmt.close();

 

conn.setAutoCommit(true);

stmt = conn.createStatement();

stmt.executeUpdate(sql_update);

 

stmt = conn.createStatement();

rs = stmt.executeQuery(sql_query);

while(rs.next()) {

       System.out.println("id:" + rs.getObject(1) + " |name:" + rs.getObject(2) + " |code:" + rs.getObject(3));

       out.println("id:" + rs.getObject(1) + " |name:" + rs.getObject(2) + " |code:" + rs.getObject(3));

}

} catch (Exception e) {

e.printStackTrace();

} finally{

}

%>

代码很简单,大意是对某个表进行插入操作后,因连接被传来传去,中间处理比较混乱,事务并未提交,这时同一连接又去访问该表进行更新操作。

我们依照上节的介绍,依样画瓢,开始数据源事件跟踪。然后,当访问演示页面时,发现页面半天不动,后台也没啥动静, JVM 也很正常,究竟发生什么事?代码执行到何处被阻塞了?

看起来好像很难,不过,这时候或者就是数据源事件跟踪工具发挥作用的时候了。通过观察数据源事件跟踪工具的输出,我们发现,连接在执行完第二次 setAutoCommit 后,未能继续执行后续的 Update 语句,显然,该语句涉及的表给锁住了。例子很简单,大家感兴趣的话可以动手做做。或者爱动手的你,把 SQL Server 换成 Oracle ,结果又会是如何呢?

 

内容概要:本文通过一个典型的嵌入式开发困境——因供应链问题需紧急更换传感器芯片,引出使用C语言实现工厂模式来解决代码强耦合问题。文章首先介绍如何利用C语言的结构体和函数指针模拟面向对象中的“接口”概念,定义统一的传感器操作接口(Sensor_Ops),实现业务层与具体驱动的解耦。接着展示“青铜段位”的简单工厂模式,通过switch-case根据宏定义选择具体传感器实现,使更换芯片只需修改一行代码。进一步,文章引入“王者段位”的自动注册工厂模式,利用编译器的section特性,将各传感器驱动的操作集自动注册到指定内存段,工厂通过遍历该段自动发现所有可用传感器,真正实现了“对扩展开放,对修改关闭”的开闭原则。最后阐述了该模式在硬件模拟(Mock)、多版本兼容和团队协作方面的实战价值。; 适合人群:从事嵌入式系统开发,具备一定C语言基础和项目经验的工程师,特别是常面临硬件变更、多型号产品维护或团队协作开发的从业者。; 使用场景及目标:①当项目中存在同类外设(如传感器、显示屏、存储芯片)多种选型,需要灵活切换时;②希望实现硬件抽象,便于在无实物硬件时进行软件仿真和单元测试;③构建多硬件版本产品(如Pro/Lite版),用一套代码库支持不同配置;④促进团队分工协作,降低驱动开发与业务逻辑之间的依赖和冲突。; 阅读建议:此资源不仅提供了代码范例,更重要的是传达了一种解耦和模块化的设计思想。建议读者在理解基本原理后,动手实践,尝试在自己的项目中应用简单工厂模式,并逐步过渡到自动注册模式,同时思考如何将此思想推广到其他模块(如通信、存储等)的设计中。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值