Re: ASM parameters

On Jan 26, 10:18 am, Mladen Gogala <mgog..._at_yahoo.com> wrote:
> On Fri, 25 Jan 2008 14:10:52 -0800, Charles Hooper wrote:
> > Thanks for the clarification. With the inclusion of DB_CACHE_SIZE,
> > DB_FILE_MULTIBLOCK_READ_COUNT, and MBRC, I jumped to the conclusion that
> > you were performance tuning data retrieval, rather than RMAN
> > performance.
>
> > A quick Google search found a couple interesting articles that might be
> > helpful:
> > While the following is specific to Oracle 11g (most will likely apply to
> > 10g R2), it does discuss how ASM requires slighly different parameters
> > for optimal performance. You have probably already found this article,
>
> Oracle10 can work with Oracle11 ASM. There is a good recipe for
> performance improvement on large databases in the ML note 368055.1.
> My management agreed to let me try Oracle10g with Oracle11 ASM, but
> I am still waiting for the hardware.
> 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 have classic structure:
>
> oracle 13376 1 0 Jan25 ? 00:00:00 asm_pmon_+ASM
> oracle 13378 1 0 Jan25 ? 00:00:00 asm_psp0_+ASM
> oracle 13380 1 0 Jan25 ? 00:00:00 asm_mman_+ASM
> oracle 13382 1 0 Jan25 ? 00:00:00 asm_dbw0_+ASM
> oracle 13384 1 0 Jan25 ? 00:00:00 asm_lgwr_+ASM
> oracle 13386 1 0 Jan25 ? 00:00:00 asm_ckpt_+ASM
> oracle 13388 1 0 Jan25 ? 00:00:00 asm_smon_+ASM
> oracle 13390 1 0 Jan25 ? 00:00:00 asm_rbal_+ASM
> oracle 13392 1 0 Jan25 ? 00:00:09 asm_gmon_+ASM
> oracle 13760 1 0 Jan25 ? 00:00:00 oracle+ASM (DESCRIPTION=
> (LOCAL=Y
> oracle 32739 32738 0 10:07 ? 00:00:00 oracle+ASM (DESCRIPTION=
> (LOCAL=Y
>
> They also have similar parameters as the ordinary instances:
> NAME TYPE VALUE
> ------------------------------------ -----------
> ------------------------------
> instance_type string asm
> SQL> show parameter db_cache_size
>
> NAME TYPE VALUE
> ------------------------------------ -----------
> ------------------------------
> db_cache_size big integer 128M
> SQL> show parameter read_count
>
> NAME TYPE VALUE
> ------------------------------------ -----------
> ------------------------------
> db_file_multiblock_read_count integer 256
>
> I noticed rather significant differences in RMAN transfer rates when these
> parameters are modified. You are one of the most experienced DBA's on
> this group and I am grateful for your suggestions.
>
> --http://mgogala.freehostia.com

Mladen, thanks for the complement. However, there have been several cases where I might take an hour or longer researching an answer, when some of the other contributors to the group take 5 minutes or less to provide an answer that is more accurate and better described than the answer I would have posted. On a day to day basis, in addition to (fighting with) Oracle, I deal with a lot of other things that have nothing to do with databases (Windows, Linux, firewalls, vpn equipment, MS Exchange, computer hardware, phone equipment, network equipment, Fanuc CNC controls, training, etc.). The goal is to learn more than one forgets each day. There are a number of very knowledgeable DBAs (and developers) contributing to this group, but unfortunately not all of the answers provided in 5 minutes or less convey meaningful content.

A couple other references that might be helpful: Metalink Note:5576584.8, Bug 5576584 - Poor ASM parallel read performance, affects ASM on 10.2.0.3 and below, fixed in 10.2.0.4. It looks like a patch is available for 10.2.0.3 on Linux, which is dated March 2007. However, the last update to the bug report is January 16, 2008 (there is an update to the bug report in November that might make some DBAs uneasy). I am not sure if this would affect RMAN performance, but you might want to take a look at the bug report.

"Take the Guesswork Out of Database Layout and I/O Tuning with Automatic Storage Management"
http://www.oracle.com/technology/products/database/asm/pdf/take%20the%20guesswork%20out%20of%20db%20tuning%2001-06.pdf "The Kernel Sequential File I/O (ksfq) provides support for sequential disk/tape access and buffer management. Ksfq allocates 4 sequential buffers by default. The size of the buffers is determined by dbfile_direct_io_count parameter set to 1MB by default. Some of the ksfq clients are Datafile, Redolog file, RMAN, Archive log file, Datapump, Data Guard and the File Transfer Package."

Please continue to keep the group informed of your progress.

Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. Received on Sat Jan 26 2008 - 21:14:14 CST