如何查找应用程序的数据库往返次数
我是一名 java 程序员,我想知道我的应用程序完成了多少数据库调用/行程。我们使用 Oracle 作为我们的关系数据库。
通过 Oracle,我了解了一种更改会话统计信息和生成跟踪文件的方法。以下是要触发的查询:
ALTER SESSION SET TIMED_STATISTICS = TRUE;
ALTER SESSION SET SQL_TRACE = TRUE;
生成跟踪文件后,可以使用 TKProf 实用程序读取它们。但不能使用这种方法,因为:
- 我的应用程序使用 hibernate 和 spring 框架,因此应用程序没有会话句柄。
- 即使我们获得了跟踪文件,我也需要知道这组查询是一次性(批量)还是单独触发的。我不确定 TkProf 输出是否有助于理解这一点。
有人有更好的建议吗?
I am a java programmer and I want to know how many database calls/trips are done by my application. We use Oracle as our relational database.
With oracle, I got to know about a way to alter session statistics and generate the trace files. Below are the queries to be fired:
ALTER SESSION SET TIMED_STATISTICS = TRUE;
ALTER SESSION SET SQL_TRACE = TRUE;
After the trace files are generated, they could be read using the TKProf utility. But this approach cannot be used because:
- my application uses hibernate and spring frameworks and hence the application does not have an handle to the session.
- Even if we get the trace files, I need to know whether the set of queries are fired in one go (in a batch) or separately. I am not sure if TkProf output could help to understand this.
Does anyone have any better suggestions?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
在 TkProf 中,您基本上可以将往返次数视为“调用”次数(尽管也有例外,因此需要较少的往返次数,例如,理论上,单行选择的解析/执行/获取是可能的)单次往返,即 Oracle 所谓的“精确获取”功能)。然而,作为估计,tkprof 的数据已经足够好了。
如果跟踪等待事件,您应该直接在原始跟踪中看到“SQL*Net from/to client”等待事件,但我认为 tkprof 不会显示它(不确定,请尝试一下)。
另一种方法是查看会话统计信息:
但是,如果您在应用程序中执行此操作,则会减慢应用程序的速度,并且您收到的数据将包括该选择的往返次数。
A 写了几篇关于往返优化的文章:
In TkProf, you can basically tell the number of round-trips as the number of "calls" (although there are exceptions so that less round trips are required, e.g. parse/execute/fetch of a single row select is, theoretically, possible in a single round trip, the so called "exact fetch" feature of oracle). However as a estimate, the tkprof figures are good enough.
If trace wait events, you should directly see the 'SQL*Net from/to client' wait events in the raw trace, but I think tkprof does not show it (not sure, give it a try).
Another way is to look into the session statistics:
However, if you do that in your app, you will slowdown your app, and the figures you receive will include the round-trips for that select.
A wrote a few articles about round-trip optimization:
首先,使用专用数据库(或时间范围)进行此测试,这样它就不会轻易与其他会话混淆。
其次,查看视图 v$session 来识别休眠的会话。 USERNAME、OSUSER、TERMINAL、MACHINE 应该使这一点显而易见。 SID 和 SERIAL# 列唯一标识会话。实际上SID在任何时候都是唯一的。仅当会话断开并重新连接时才需要 SERIAL#。
第三,使用 v$sessstat(根据 v$session 中的 SID、SERIAL# 进行过滤)和 v$statname(如 Markus 所示)来提取往返次数。您可以在测试前拍摄快照,运行测试,然后再次查看这些值并确定完成的工作。
也就是说,我不确定它本身是否是一个特别有用的措施。 TKPROF 将更加详细,并且更加关注时间(这是一个更有用的衡量标准)。
Firstly, use a dedicated database (or timeframe) for this test, so it doesn't get easily confused with other sessions.
Secondly, look at the view v$session to identify the session(s) for hibernate. The USERNAME, OSUSER, TERMINAL, MACHINE should make this obvious. The SID and SERIAL# columns uniquely identify the session. Actually the SID is unique at any time. The SERIAL# is only needed if you have sessions disconnecting and reconnecting.
Thirdly, use v$sessstat (filtered on the SID,SERIAL# from the v$session) and v$statname (as shown by Markus) to pull out the number of round trips. You can take a snapshot before the test, run the test, then look at the values again and determine the work done.
That said, I'm not sure it is a particularly useful measure in itself. The TKPROF will be more detailed and is much more focussed on time (which is a more useful measure).
最好是获取正在运行的会话的专用事件 10046 级别 12 跟踪文件。您将在那里找到所有详细信息。这意味着您可以查看应用程序将针对每个执行的命令执行多少次提取以及相关的等待事件/经过的时间。可以使用 Oracle 工具(如 TKPROF 或 Oracle Trace Analyzer)或第三方工具(如 [QueryAdvisor][1])来分析结果。
顺便说一句,您可以要求 DBA 定义一个数据库触发器,在登录后自动激活 Oracle filetrace。所以捕获文件应该不是问题。
RU
[1]:http://www.queryadvisor.com/“使用 QueryAdvisor 进行 TKPROF Oracle 跟踪文件分析”
Best would be to get a dedicated event 10046 level 12 tracefile of the running session. You will find there all information in detail. This means that you can see how many fetches the application will do per executed command and the related wait events/elapsed time. The resul can be analyzed using tool from Oracle like TKPROF or Oracle Trace Analyzer or Third party tools like [QueryAdvisor][1].
By the way you can ask your DBA to define a database trigger activating Oracle filetrace automatic after login. So capturing the file should not be the problem.
R.U.
[1]: http://www.queryadvisor.com/"TKPROF Oracle tracefile analysis with QueryAdvisor"