Yes, I know that. Can't do that (yet). If I could have, I would have before bothering the list. This is Production. I'm too new at this site to know what I can do and what I can't do. =20 While the insert was running, I could see the wait event, db file sequential read, and which files/blocks were being waited on. I can understand the reason for that wait event. I'm trying to understand the high number of I/Os. Mark -----Original Message----- From: Gogala, Mladen [mailto:Mladen.Gogala@xxxxxxxx]=20 Sent: Wednesday, September 22, 2004 12:53 PM To: Mark Strickland Cc: oracle-l@xxxxxxxxxxxxx Subject: RE: Performance Question - High I/O per Insert Did you run in with event 10046 enabled, on level 8, in order to see what are you waiting for and which recursive SQL statements are waiting=20 for the I/O events? That would be the 0th thing, even before the first one. -- Mladen Gogala A & E TV Network Ext. 1216 > -----Original Message----- > From: Mark Strickland [mailto:mstrickland@xxxxxxxxxxxxx]=20 > Sent: Wednesday, September 22, 2004 3:42 PM > To: oracle-l@xxxxxxxxxxxxx > Subject: Performance Question - High I/O per Insert >=20 >=20 > I'm trying to understand why I'm seeing a high number of I/Os=20 > for inserts. Inserts are through SQL*Loader conventional=20 > patch. Average row length is 129 bytes, no longs or blobs. =20 > The table has five indexes and each index has a blevel of 2. =20 > According to v$sqlarea, each insert uses 650 logical I/Os, 69=20 > physical I/Os. I would expect fewer than 20 I/Os per insert.=20 > There are db file sequential read waits on the data files=20 > that make up the index tablespace. That file system also=20 > contains the archived logs. Not surprised at the contention.=20 > Can someone point me in the right direction to understand this? Thx. > =20 >=20 > Mark Strickland >=20 > Drugstore.com >=20 > Seattle, WA >=20 >=20 > -- > //www.freelists.org/webpage/oracle-l >=20 -- //www.freelists.org/webpage/oracle-l