This content has been marked as final. Show 12 replies
The same disk at the same time?
If not how did you remove the file system?
> My conclusion is that the problem is in ASM....
Yeah... the following analogy describes you and your approach pretty well. IMO.
Empirical Scientist. White lab coat. Clipboard. In lab. Table in lab. Glass jar on table. A fly in the jar.
The scientist opens the jar, and places the fly on the table. He claps his hand. The fly flies away. He notes on his clipboard, "The fly's hearing is excellent!".
He catches the fly. He tears off the wings from the poor fly and places it on the table. Again he claps his hand. Puzzled, he claps his hands again. He notes on his clipboard, "A fly cannot hear when it does not have wings!!". He then writes, "Conclusion: The hearing organs of a fly is situated in its wings".
A conclusion based on observation only is idiotic.
Excellent analogy, I couldn't stop laughing :-)
when install ASM, i use only /dev/hdisk1.....after....remove ASM......create a /u02 - jfs2 pointing to /dev/hdisk1 and create a tablespace in /u02.
I not expressed correctly!
The objective was not to compare. Only demonstrate that in my tests ASM was 10x slower.
And i would like to know if someone had performance problems with ASM.
Care to tell how you benchmarked I/O using a cooked file system versus a raw disk with ASM? Care to explain how you factored in o/s cache + db buffer cache versus ASM + db buffer cache - how you ensured you are comparing apples with apples?
He probably used the #1 instrument in 'tunning' a database: his watch!
Senior Oracle DBA
Excellent analoggy Billy :-).For sure , I shall remember it. I am sure there will be many times it will be used by me.
> Excellent analoggy Billy :-).For sure , I shall remember it. I am sure there will be many
times it will be used by me.
I've first heard it back in the 90's when dealing with troubleshooting software and performance issues (a pet hobby of mine - some like taking toasters and TVs apart, I like doing that with software).
And as you are planning to Aman, I have used it numerous times in well over a decade now. :-)
In my view it cuts very close to the bone why using the simplistic "elapsed time" approach to many performance related issues is so fatally flawed. It also shows how important it is to know WHAT exactly what you are observing - kind of a twisted Copenhagen Interpretation where ignorance of the experiment collapses the wave function and produces totally meaningless results... ;-)
I must say that its really a straight hammer hit over the head when some one is talking about wall clock time approach for tuning.I really couldnt stop laughing after reading it.
Surely I shall use it whenever it will be required and I am sure that it will surely raise an eyebrow :-).
Thanks again for it.
How you concluded that the performance with ASM is bad. (i.e what statistics... whether you are seeing high I/O or something else!!!).
As per bug 5893614 Full table scans can be very slow on ASM compared to file system. If you are seeing waits on 'db file scattered read" then it may be the case.
It is better to collect AWR report for the time when database is performing slow.