Statspack的Rollback per transaction计算方法

今天研究statspack report,发现load profile中有一项Rollback per transaction居然高达70%。如此高的回滚率,应用程序方面应该是出现了很多错误,导致事务被回滚。但我检查了应用程序的日志,却没有发现任何问题。于是google了一下,发现原来问题是出在statspack计算Rollback per transaction的公式上面。

 

1。Oracle中的rollback分成两种,user rollback和transaction rollback。只要是用户发出rollback命令,无论是否真的有数据回滚,user rollback都会增加。但transaction rollback只有发生了真正的回滚才会增加。测试如下:

SQL> select name, value from v$sysstat where name in ('user rollbacks', 'transaction rollbacks');

NAME                                VALUE
------------------------------ ----------
user rollbacks                       6800
transaction rollbacks                   5

SQL> rollback;
Rollback complete.

SQL> rollback;
Rollback complete.

SQL> select name, value from v$sysstat where name in ('user rollbacks', 'transaction rollbacks');

NAME                                VALUE
------------------------------ ----------
user rollbacks                       6802
transaction rollbacks                   5

SQL> create table test (id int);
Table created.

SQL> insert into test values (1);
1 row created.

SQL> rollback;
Rollback complete.

SQL> select name, value from v$sysstat where name in ('user rollbacks', 'transaction rollbacks');

NAME                                VALUE
------------------------------ ----------
user rollbacks                       6803
transaction rollbacks                   6

 

2。Statspack中计算Rollback per transaction的公式为:Rollback per transaction% = user rollback/(user rollback+user commit); 

 

3。一些ORM实现会在成功commit之后发出一个rollback的命令(这个还不知道是为什么)。这样就会产生大量并没有实际数据回滚的user rollback。

 

综合以上原因,就导致了很高的Rollback per transaction%。虽然对实际性能没有什么影响,但会给分析者带来一种错觉。而真正对性能有影响的Rollback per transaction%,计算公式应当为:

 

Rollback per transaction% = transaction rollback/(transaction rollback+user commit); 

你可能感兴趣的:(oracle,sql,orm,Google)