From: Russ_Fish@idx.com
Date: Thu Nov 06 2003 - 09:47:03 EST
Thanks go to:
1. Martin Rønde Andersen
2. John Lanier
3. Andy Cohen
4. Peter Solodov
We ended up using Peter's suggestion (larger db_block_buffers, or
db_cache_size in 9i) as it does not require a server bounce.
1. Martin recommended looking at some of the HSZ params, and noted that
the HSZ70 will only ever be so fast:
Since you are talking about import, (writes) , you should have a look at
io's pr. Second.
The type of disks you can have in a hsz70 rarely goes over 100 io's
pr.second. How many disks/spindles are you writing to ?
If for example you have 4 disks , you should not expect more than 400
io's pr. Second !! Etc. Etc.
Try this for a hint to see your io's pr second:
# collect -sd -i 5
One could during import temporarely addvol a lun with alot of spindles,
and remove it later.
I also asked about changing the value of CACHE_FLUSH_TIMER, and he
replied:
Last .. I have seen CACHE_FLUSH_TIMER go both ways, just try changing it
while you have collect running, to see if it makes any difference, as
goes with maximum_cache_transfer_size
2. John recommended a number of tuning docs, URLs to which are given
below:
http://otn.oracle.com/products/oracle9i/pdf/high_avail_clusters.pdf
http://www.tru64unix.compaq.com/oracle9irac/truclusterintro.html
http://fluid.mro.cpqcorp.net/solnintegration/oracleapp.shtml
http://www.tru64unix.compaq.com/docs/best_practices/clus_bps.html
3. Andy recommended looking at the _TRU64_DIRECTIO_DISABLED parameter, but this does not appear to be supported in 9i (if someone knows differently, please let us know and I'll publish a second summary):
You may want to check with Oracle Support about this 'hidden' init.ora
parameter setting:
_TRU64_DIRECTIO_DISABLED = TRUE
We moved from 4.0F to 5.1A and upgraded from 7.3.4 to 8.1.7 and as a
result
the database kept crashing (not the problem you're having I know). Oracle
support suggested we try the above setting and now the database stays up.
The irony is that we have a much larger, much more heavily used database
on
the same box using the same ORACLE_HOME that doesn't need this setting.
4. Peter gave an RTFM to the list archive, the fount of all Tru64
knowledge:
http://www.ornl.gov/lists/mailing-lists/tru64-unix-managers/2002/12/msg00192.html
Thanks as always--this list rules!
Original message follows:
Hi all--
This is probably a bit off topic, but I'm hoping someone has a similar
config and has seen this problem before.
We have an ES40, 4 CPU, 8 GB connected to an HSZ70. The system performs
nicely with one exception--it crawls when we run Oracle exports, imports, and table drops. We've tested large unix to unix file copies, and those
work fine, so we're thinking it's somehow related to Oracle 9.2.0 disk
writes under 5.1B. We've tried all the Oracle-recommended tricks (large
rollback segment, noarchivelog, /dev/timedev, etc.) but so far it hasn't
helped. The system has plenty of free memory (no swapping at all), and if the collective memory serves us, we did not see this problem when the
system was 4.0F with Oracle 8.1.7.
Any hints, suggestions, etc. greatly appreciated--we have some unhappy
users on our hands (so what's new).
--Russ
----------------------------------------------------
NOTICE OF CONFIDENTIALITY
----------------------------------------------------
The information in this email, including attachments, may be confidential and/or privileged and may contain confidential health information. This email is intended to be reviewed only by the individual or organization named as addressee. If you have received this email in error please notify IDX immediately - by return message to the sender or to security@idx.com - and destroy all copies of this message and any attachments. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of IDX. Confidential health information is protected by state and federal law, including, but not limited to, the Health Insurance Portability and Accountability Act of 1996 and related regulations.
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:43 EDT