Re: I/O issues on DB 11g

  • From: David Ramírez Reyes <dramirezr@xxxxxxxxx>
  • To: David Fitzjarrell <oratune@xxxxxxxxx>
  • Date: Wed, 23 Apr 2014 15:58:47 -0500

Interesting, I hadn't think about redo logs as part of the problem...

David Ramírez Reyes
Profesión: Padre de Familia



On 23 April 2014 15:54, David Fitzjarrell <oratune@xxxxxxxxx> wrote:

> Since you have both the controlfiles and the redo logs on the same disk as
> the  database that is likely impacting the I/O  operations for the
> database; db files are random-access, scattered read and write files and
> the controlfiles/redo logs are sequential read/write files.  Think about
> this for a moment;  you're mixing write patterns and that can slow down the
> datafile reads/writes as you wait for the disk heads to finish a redo or
> controlfile entry; the opposite is also true as controlfile/redo writes
> wait on datafifle processing.  It's not an ideal situation.
>
> You might consider having a disk solely for controlfiles and redo logs.
>
>
> David Fitzjarrell
> Primary author, "Oracle Exadata Survival Guide"
>   On Wednesday, April 23, 2014 2:40 PM, David Ramírez Reyes <
> dramirezr@xxxxxxxxx> wrote:
>  Hi All,
>
> This is the environment.
> Windows 2008 R1 Standard, Oracle DB 11g Standard R2, 8 cpu's, 16 GB of
> physical memory, 3 disk drives (1 for the OS, 1 for db files, 1 for
> backups).
>
> Now the problem:
> Since we went live with the 11g system about 1 year ago (we used to be on
> a very old and horrible 8i -don't ask why-), we have been receiving Email
> alerts about Disk Utilization; at the beginning I thought it should be a
> bug of the R2 version as I wrongly understood it was referring about
> filesystem space, which is not a problem.
> After several months of 5 or 8 daily mails, I decided to look at it on
> detail and check what was necessary to drop off that "false alarm".
> After Goggling, I realized that the alarm is not related to disk space,
> but I/O reads, as we have 3 db's on the same disk drive, each of them with
> 20 db files (the biggest DB has datafiles of about 6 GB, the smallest about
> 2 GB).
>
> The problem is not really "critical" now because general performance is
> "good" (we have more than a year with it!), but that of course does not
> mean it has to keep on with those problems (and that alarm is starting
> causing me headaches also!).
>
> The first two things I though were increasing the PGA size in order to
> reduce Virtual Memory usage (and, I/O as consequence) and add 2 more disk
> drives to split the db files of each db into a single and dedicated
> filesystem; I was also thinking about tuning some high I/O queries, but
> don't think the difference could be huge...
>
> Any ideas or suggestions?
>
> Thanks
>
>
> David Ramírez
>
>
>

Other related posts: