RE: db file parallel write
- From: "Lim, Binley" <Binley.Lim@xxxxxxxxxx>
- To: "'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 4 Mar 2004 15:22:41 +1300
Assuming "nothing has changed" is right, problems that suddenly appear, and
persist, is likely due to hardware-related issues.
In a previous role, I came a across a similar situation (Solaris server +
Netapp) where everything went on a go-slow one fine day. CPU time (sys) shot
up to 60-70% whereas normal operation would see it around 20%. Truss shows
lots of "poll" syscalls. Filer I/O was also high, but apparently this was
not to be interpreted literally, according to the vendor. First question
everyone asked was "what has changed"?
After the DBA/sysadmins went around verifying and "proving" that nothing has
changed, the vendors replaced a couple of disks, controller boards on the
Filer, network cards on both sides, and even changed to different ports on
the switch, and the problem went away. Go figure...
> -----Original Message-----
> From: DENNIS WILLIAMS [SMTP:DWILLIAMS@xxxxxxxxxxxxx]
> Sent: Thursday, March 04, 2004 9:34 AM
> To: 'oracle-l@xxxxxxxxxxxxx'
> Subject: RE: db file parallel write
>
> Sai
> I recall others on the list mentioning something similar with Netapp.
> Something inherent in the Netapp design. I would google oracle-l netapp
> and
> read the old threads.
> The other possibility is that you may be saturating the network
> connection with a lot of small requests. I would recommend that you tap
> your
> network engineer and have them look at what the wire is experiencing.
> My experience with Netapp has been positive overally but that you must
> be
> careful not to overload the wire.
>
>
>
> Dennis Williams
> DBA
> Lifetouch, Inc.
> dwilliams@xxxxxxxxxxxxx
>
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx]On
> Behalf Of Sai Selvaganesan
> Sent: Wednesday, March 03, 2004 1:37 PM
> To: oracle-l@xxxxxxxxxxxxx
> Subject: db file parallel write
>
>
> hi
>
> we are running oracle 9.2.0.4 on red hat and netapp as the storage.
> everything has been going on alright until a week back i/os have become
> very
> slow.
>
> we can see dbwr taking a very longtime to do a db file parallel write and
> all loadings (this is a dw system) is taking longer. the i/o on the filer
> shows 90% to 95% usage and hits 100% sometimes. this filer is shared
> between
> three other home grown applications but none of them has put in any new
> code. the slowness is showing up on all applications but this dw system is
> bound by some SLAs hence bad performance is easily noticeable.
>
> we have a tech ticket opened with the vendor but no response yet. has
> anyone
> in this list faced this kind of issues? no sql has changed and this
> storage
> setup has been working fine for more than 6 months now.
>
> thanks
> sai
>
>
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at //www.freelists.org/archives/oracle-l/
> FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
This communication is confidential and may contain privileged material.
If you are not the intended recipient you must not use, disclose, copy or
retain it.
If you have received it in error please immediately notify me by return email
and delete the emails.
Thank you.
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
