Re: ASM parameters

"Mladen Gogala" <mgogala_at_yahoo.com> wrote in message news:479b5213$0$1344$834e42db_at_reader.greatnowhere.com...
> On Sat, 26 Jan 2008 15:18:09 +0000, Mladen Gogala wrote:
>
>> However, ASM instance parameters are very poorly documented. There are
>> no documents explaining how to monitor and change those parameters.
>> Performance can be, as is the case with OCFS, abysmal if everything is
>> left on default.
>
> ASM instances also have wait interface. All of the classic wait
> event tables have their ASM counterparts. I looked into V$SYSTEM_EVENT
> table:
>
> SQL> select event,time_waited from v$system_event order by 2 desc;
>
> EVENT
> TIME_WAITED
> ----------------------------------------------------------------
> -----------
> rdbms ipc message
> 226141091
> DIAG idle wait
> 20574722
> pmon timer
> 20571058
> gcs remote message
> 20568154
> ges remote message
> 20523925
> SQL*Net message from client
> 10515309
> DFS lock handle
> 190351
> PX Idle Wait
> 73904
> kfk: async disk IO
> 27319
> log write(even)
> 25253
> log write(odd)
> 24735
>
> EVENT
> TIME_WAITED
> ----------------------------------------------------------------
> -----------
> DBFG waiting for reply
> 9752
> enq: AD - deallocate AU
> 6938
> enq: AD - allocate AU
> 6467
> enq: HD - contention
> 4561
> ASM mount : wait for heartbeat
> 438
> rdbms ipc reply
> 269
> GCS lock open S
> 231
> SQL*Net message to client
> 213
>
> I wonder whether buffer cache hit ratio would make sense for the ASM
> instances and how to calculate it. I will let you know of my findings.
> --
> http://mgogala.freehostia.com

(db block gets + consistent gets - physical reads)/(db block gets + consistent gets)

Well, but then again, many "experts" in this group think BCHR does not matter even in regular databases. LMAO. Received on Sat Jan 26 2008 - 13:12:04 CST