Note: you can also use the follow to get a single paramater:
# lsattr -El sys0 -a <attribute> [-a <attribute>]
At/After painful moment need stats from each layer (adapter, interface, protocol)
I am thinking of:
- entstat -d <device>
- netstat -nm # (of all CPU, not just CPU24)
- netstat -t # (especially when errors are occurring)
- svmon -G # for general statistics
- svmon -P -t 8 # more general statistics
- netstat -w -I -p ALL 10 120 # (to see if paging has any influence)
Before you start your backup
# netpmon -o File -d -P -T TraceBufferSize -O so
After it starts
# trcon
This collects a lot of data! so perhaps let it run for 5 minutes only and see what it produces. Get used to using it - practice - ahead of time!
Example:
# sleep 300; trcoff
It is the command trcoff that actually stops the trace and starts the creation of the output. Again - get familiar with how to use the command.
Note:
sleep is not necessary - just a handy way to stop after a fixed amount of time -
trcoff is needed in any case to stop the
trace and generate the report. If you do not specify
-d argument - the trace starts automatically (i.e., no
trcon needed).
From here on it is going to be too complex to handle this forum style - at least considering the amount of time I have. Continue asking for advice from IBM, but also from the VAR.
What I am concerned about, with Oracle - that usually uses lots of (pinned) memory (±75% at minimum, 80%+ is quite common), is that the network stack and Oracle are fighting for the memory and that "some" of the problem may be coming from memory overcommitment.
In short, get the application provider (might not be Oracle themselves, but an additional party) to help you on the client side with correcting/understanding the issues.