Re: Oracle 10g on Solaris 10 non-global zones with asynchronous I/O
From: joel garry <joel-garry_at_home.com>
Date: Thu, 11 Mar 2010 08:49:25 -0800 (PST)
Message-ID: <68d03d73-484e-4fd7-ab97-28a520022fa7_at_x23g2000prd.googlegroups.com>
On Mar 10, 10:55 pm, Bruce <brucemcgill...._at_gmail.com> wrote:
> Hi All,
>
> I note that using direct I/O (by setting the forcedirectio while
> mounting the database file systems) and bypassing the file system
> cache may improve database performance significantly, but this should
> be done only for file systems in which database files and redo log
> files exist. If direct I/O is used and there is not enough database
> buffer cache, it may even decrease the performance by moving the
> problem from double buffering to a lack of database buffer cache. So,
> this performance tuning must be planned carefully, and the database
> buffer cache should be sized properly. The direct I/O option should
> not be used for other file systems used by other applications because
> they still need the UFS buffer cache.
>
> Now, I have Oracle database installed inside a non-global zone and I
> see a lot of Asynchronous I/O wait warnings in the Oracle Alert log
> file. Storage mount points with UFS filesystem contain the Oracle
> datafiles and redo log files. In addition, two Oracle datafiles of 10
> GB each reside on the local disks. The Oracle init.ora parameter to
> set asynchronous I/O for Oracle database files is
> FILESYSTEMIO_OPTIONS= SETALL.
>
> Although the above parameter was set during the database installation,
> the aiowait warnings don't seem to disappear.
>
> Can I use the "forcedirectio" option at the Operating System /etc/
> vfstab file for Oracle datafiles and redo log files?
>
> Or, should I just move the Oracle database files residing on the local
> disks to the external storage? Will this take care of aiowait warnings
> and if yes, how? The storage is a DAS.
>
> Regards,
> Bruce
Date: Thu, 11 Mar 2010 08:49:25 -0800 (PST)
Message-ID: <68d03d73-484e-4fd7-ab97-28a520022fa7_at_x23g2000prd.googlegroups.com>
On Mar 10, 10:55 pm, Bruce <brucemcgill...._at_gmail.com> wrote:
> Hi All,
>
> I note that using direct I/O (by setting the forcedirectio while
> mounting the database file systems) and bypassing the file system
> cache may improve database performance significantly, but this should
> be done only for file systems in which database files and redo log
> files exist. If direct I/O is used and there is not enough database
> buffer cache, it may even decrease the performance by moving the
> problem from double buffering to a lack of database buffer cache. So,
> this performance tuning must be planned carefully, and the database
> buffer cache should be sized properly. The direct I/O option should
> not be used for other file systems used by other applications because
> they still need the UFS buffer cache.
>
> Now, I have Oracle database installed inside a non-global zone and I
> see a lot of Asynchronous I/O wait warnings in the Oracle Alert log
> file. Storage mount points with UFS filesystem contain the Oracle
> datafiles and redo log files. In addition, two Oracle datafiles of 10
> GB each reside on the local disks. The Oracle init.ora parameter to
> set asynchronous I/O for Oracle database files is
> FILESYSTEMIO_OPTIONS= SETALL.
>
> Although the above parameter was set during the database installation,
> the aiowait warnings don't seem to disappear.
>
> Can I use the "forcedirectio" option at the Operating System /etc/
> vfstab file for Oracle datafiles and redo log files?
>
> Or, should I just move the Oracle database files residing on the local
> disks to the external storage? Will this take care of aiowait warnings
> and if yes, how? The storage is a DAS.
>
> Regards,
> Bruce
There are a bunch of MOS notes on solaris setall, including one about a mandatory patch. It varies by Oracle version/patch level, which I can't seem to find in your post. Start with How To Verify Whether DIRECTIO is Being Used [ID 555601.1]
jg
-- _at_home.com is bogus. http://www.computerworld.com.au/article/338698/internet_hit_by_wave_ransom_malware/Received on Thu Mar 11 2010 - 10:49:25 CST