Freitag, 18. November 2011

Different results in v$asm_operation views

During some performance tests, I was wondering why rebalancing of one out of two hard disks was extremely fast - in my opinion it was too fast.
After some headache I found out, that the rebalancing caused an entry in v$asm_operation view of ASM instance. The particular row was missing in v$asm_operation view of RDBMS instance.

Rule of thumb:
Be careful when querying dynamic performance views v$asm_%. Their content depends on the instance against which you are connected

Donnerstag, 17. November 2011

Performance ASM Redundancy Normal vs. Rendundancy External

Recently, I did do some performance testing and I want to share my results:

during no heavy workload periods
  • Swingbench Business transactions experience 56% more DB Time when switching to Normal Redundancy 
  • db file scattered read raised by 8% to 79%
  • log file parallel write raised by 10% to 49%
  • db file parallel write raised by 16% to 30% 
during heavy workload periods
  • Swingbench Business transactions experience 165% more DB Time when switching to Normal Redundancy
  • db file scattered read raised by 4% to 76%
  • log file parallel write shrinked by 5% to 49%
  • db file parallel write raised by 7% to 28%
The rule of thumb which we can derive:
  • If you have a system with heavy workload than you should not use Redundancy Normal.
Values for physical write bytes per transaction did not change.
This means DBWR statistics do not care about diskgroup redundancy.