I've asked a dba to look at your questions/comments.

 

I'm looking at a blog post http://recoverymonkey.org/2014/09/18/when-competitors-try-too-hard-and-miss-the-point-part-two/

 

It discusses how to read a STATIT for sequential I/O size.  I have a statit listing . . .

 

 

disk             ut%  xfers  ureads--chain-usecs writes--chain-usecs cpreads-chain-usecs greads--chain-usecs gwrites-chain-usecs

/aggrfcp/plex0/rg0:

0b.01.0           54 107.88    0.00   2.11  2211   1.00  34.35   214   1.91  13.48   276 104.97  64.00   188   0.00   ....     .

0b.01.1           55 107.96    0.00   2.11  1684   1.13  30.56   216   1.86  12.90   347 104.97  64.00   192   0.00   ....     .

0b.01.10          56 111.70    4.14   4.76  1852   0.98  29.22   258   1.61   6.35   750 104.97  64.00   195   0.00   ....     .

0b.01.2           56 110.67    4.07   4.72  1814   0.65  43.40   192   0.98   9.70   565 104.97  64.00   200   0.00   ....     .

0b.01.3           56 110.75    4.16   4.72  1856   0.66  43.15   199   0.97  10.01   517 104.97  64.00   201   0.00   ....     .

0b.01.4           57 110.85    4.23   4.71  1751   0.65  42.99   194   1.00   9.96   517 104.97  64.00   206   0.00   ....     .

0b.01.5           57 110.62    4.06   4.97  1770   0.65  43.42   194   0.94  10.15   522 104.97  64.00   210   0.00   ....     .

0b.01.6           57 110.63    4.05   4.82  1764   0.65  43.55   197   0.96   9.83   562 104.97  64.00   210   0.00   ....     .

0b.01.7           57 110.73    4.12   4.61  1853   0.66  43.27   196   0.98   9.13   603 104.97  64.00   217   0.00   ....     .

0b.01.8           57 110.74    4.16   4.72  1844   0.65  43.54   197   0.95   9.18   583 104.97  64.00   218   0.00   ....     .

0b.01.9           57 110.75    4.16   4.76  1819   0.65  43.06   207   0.97   9.13   560 104.97  64.00   223   0.00   ....     .

 

This looks like it's doing sequential reads in 4k I/O's.

I have multiple of these listings and they are all the same.

 

 

rick

 

 

 

 

 

 

 

 

Is this NFS or FC?

 

By default, Oracle does sequential reads in 1M chunks. If they have a 16k block size on the database, it should be reading in units of 64, not 128. Also, just because Oracle tries to read 1MB chunks doesn't mean the database can do that.

 

They really shouldn't be using cio as a mount option either. Any remotely current version of Oracle will mount the datafiles with concurrent IO so long as they have filesystemio_options=setall, which is also what they should have.

 

If you can send me a sample report from 'awrrpt.sql' of no more than one hour elapsed time from a period where they are unhappy with performance, I will take a look and what's going on. I can say with 100% certainty that if they really are doing multiblock reads with 16K units the problem isn't ONTAP. I suppose it could be a 16K block size on a badly fragmented jfs2 filesystem, but I really doubt it. I think something is being misinterpreted.

 

 

OnTap 8.1.2p1

 

Our DBA's are complaining that our nSeries (N3220/FAS2240) is reading really slow due to it only returning small 16k blocks.  The DBA's are saying the Oracle multi-block read ahead should be reading 128 x 16k blocks = 2m read, but it's only seems to be reading/returning 16k at a time.

 

On a AIX filesystem mounted CIO, if I run

    "dd if=/dev/zero of=z bs=1m count=9999"

I see writes of 500k. 

 

In the same filesystem mounted CIO, if I read an existing db file

  "dd if=<dbfile> of=/dev/null bs=1m"

I see reads of up to 30k.

 

 

Q) Is there a limit in OnTap on read size?

 

 

Thanks

 

Rick