"billjohnson" <member45480_at_dbforums.com> wrote in message
news:3516938.1066939108_at_dbforums.com...
>
> Ok - I read through the replies and there seems to be a fair amount of
> discussion regarding hardware. I have heard the same song and dance
> from our UNIX Admin team that the Disk I/O is raid-1, HP Disk, dedicated
> drives....for our redo logs. We are seeing 30% of the DB time in a
> statspack report going to "log file sync" wait. It just jumped through
> the roof from 5% about 1 week ago. I need to find some other
> measurement that will allow me to confirm whether this is a hardware
> issue or a program commit/update issue. When looking at the stats pack
> report, the "user commits" line shows the following:
>
> Statistic Total per Second per
> Trans
>
> --------------------------------- ---------------- ------------ ----------
--
>
> user commits 92,676 25.7
> 1.0
>
>
>
> This number is no different in average commits per second than then the
> system was only spending 5% of the overall time in log file sync wait.
> I need some additional direction on nailing down the real source of the
> problem. This is a 16-way RP-8400 HP-UX 11.i environment running SAP
> 4.0B on an Oracle 8.1.7.3 instance. We have about 5,000 users on this
> system. Any ideas? I am a DBA - not a UNIX Admin.
>
>
> --
> Posted via http://dbforums.com
Apart from the Total user commits, Check the redo size for any anomalies.
If all things look equal, ask the UNIX admins to check for any hardware
problem.
My gut feeling is that there is a hardware problem / I/O subsystem problem.
Apart from all this, go through all the changes that have been applied to
the production system
which might have incresed the redo size generation.
Anurag
Received on Sat Oct 25 2003 - 12:54:39 CDT
