最初由 tramplhg 发布
[B]这个98代表的是bytes吗? [/B]
According to documentation, yes. Oracle is notorious in sometimes not making a clear distinction between number of I/O's and number of blocks for the I/O.
You should always tell us your Oracle version. My test in 10.2.0.2.0 shows that the change in the statistic 'undo change vector size' is very close to the change in v$rollstat.writes after I insert a number into a very simple table. You can do the same test. But I don't know if pre-10g version has any statistic like this.
Yong Huang
最初由 Yong Huang 发布
[B]
According to documentation, yes. Oracle is notorious in sometimes not making a clear distinction between number of I/O's and number of blocks for the I/O.
You should always tell us your Oracle version. My test in 10.2.0.2.0 shows that the change in the statistic 'undo change vector size' is very close to the change in v$rollstat.writes after I insert a number into a very simple table. You can do the same test. But I don't know if pre-10g version has any statistic like this.
Yong Huang [/B]
Yong Huang,
我得oracle版本是9207, 在v$sysstat 我没有发现关于产生undo大小得参数, 也没有你上面提到得'undo change vector size'。
我现在感到这个98到底是怎么算出来得, 我测试过,对于insert语句不管你插入得row多大,都是98。
我知道rowid是18位得,那不应该是98啊!!!! [/B]
Before 10g, you have to rely on v$transaction.used_ublk, which is number of undo blocks the transaction is using. The 10g statistic 'undo change vector size' is just a more accurate way to report undo for your session, and of course it persists after the transaction is finished (committed or rolled back). The conversion between these two is probably
v$transaction.used_ublk = ceil('undo change vector size' / db_block_size)
I don't have an answer as to how 98 bytes comes from your insert. We may be able to find it by doing research with some Metalink documents. Obviously Oracle has to do a lot of other work behind the scenes (recursive SQLs).
Yong Huang
最初由 Yong Huang 发布
[B]
Before 10g, you have to rely on v$transaction.used_ublk, which is number of undo blocks the transaction is using. The 10g statistic 'undo change vector size' is just a more accurate way to report undo for your session, and of course it persists after the transaction is finished (committed or rolled back). The conversion between these two is probably
v$transaction.used_ublk = ceil('undo change vector size' / db_block_size)
I don't have an answer as to how 98 bytes comes from your insert. We may be able to find it by doing research with some Metalink documents. Obviously Oracle has to do a lot of other work behind the scenes (recursive SQLs).
Yong Huang [/B]