Re: error asynch descriptor resize, 11g R2 on ms w2k8 x64 on VMware ESX v4.0.0

Hi Paul,

Well, I already have a SR and bug open with Oracle Support (bug ID 9912045)
and it has been with their development team.
Despite the fact a bug had been created I was informed that the total waits
(under 1 sec) did not have negative effect on the queries even though waits
on "asynch descriptor resize" event occurred a lot.
I had also asked for some more details about this event, so far this is what
I have:

"* When the number asynch descriptors has to be resized, the outstanding aio

requests has to be reaped before the new context is created. This event is
used to track the async waits that are issued before the new asynch
context
is created.

event name - async descriptor resize
p1 - The existing number of outstanding I/O's with OS
p2 - old asynch limit that is currently set
p3 - new asynch limit that needs to be set
wait class - user class as this is currently used by direct path I/O.

Currently this wait event is mainly used in direct path I/O operations.
Direct path read/write wait event could not be used for this wait as we
are waiting for all outstanding I/O's rather than on a particular file.* "


Like I mentioned my case is still with development. I will share as much
information as reasonably possible once I have any news.

- Jozsef


On 3 November 2010 16:07, Paul Drake <bdbafh@xxxxxxxxx> wrote:

> environment:
>
> testing. not production.
> Oracle 11g R2 x64 standard edition one, 11.2.0.1 p6.
> MS W2K8 R1 x64 standard edition
> VMware ESX v4.0.0
>
> internal SAS RAID, p410 controller, no para-virtualization.
> (server is an older HP ML 370 G5, Intel Xeon 5400 series, so no
> virtualization features supported in the hardware).
>
> A hang analyze - text of interest describing the blocking session:
>
>
>     and is blocked by
>  => Oracle session identified by:
>     {
>                 instance: 1 (mydb.mydb)
>                    os id: 4004
>               process id: 34, ORACLE.EXE (SHAD)
>               session id: 86
>         session serial #: 2956
>     }
>     which is not in a wait:
>     {
>                last wait: 13 min 35 sec ago
>                 blocking: 1 session
>             wait history:
>               1.       event: 'asynch descriptor resize'
>                  time waited: 0.000006 sec
>                      wait id: 5216            p1: 'outstanding #aio'=0x0
>                                               p2: 'current aio
> limit'=0xffffffff
>                                               p3: 'new aio limit'=0x4b2
>               * time between wait #1 and #2: 0.283570 sec
>               2.       event: 'asynch descriptor resize'
>                  time waited: 0.000007 sec
>                      wait id: 5215            p1: 'outstanding #aio'=0x0
>                                               p2: 'current aio
> limit'=0xffffffff
>                                               p3: 'new aio limit'=0x4b2
>               * time between wait #2 and #3: 0.046643 sec
>               3.       event: 'asynch descriptor resize'
>                  time waited: 0.000007 sec
>                      wait id: 5214            p1: 'outstanding #aio'=0x0
>                                               p2: 'current aio
> limit'=0xffffffff
>                                               p3: 'new aio limit'=0x4b2
>
>
> It would appear that I will be experiencing the joy of opening an SR in a
> virtualized environment.
> Searches of the web and MOS returned little other than a post by April back
> in May and a short entry here:
> http://blog.younes.ca/2010/07/asynch-descriptor-resize.html
> and this:
> *asynch descriptor resize [ID 1081977.1]
>
> I'd greatly appreciate any insight anyone might have with respect to this
> prior to opening the SR.
> Yes, I do plan to attempt to reproduce this on bare metal.
> *
> thanks,
>
> Paul
>
>

Other related posts: