Very slow day

Question

Hi all,
11.2.0.1
Aix 6.1
Yesterday Jan 15, 2014, we experienced very slow performance in our App. The webpage is hanging or disconnecting often and many transaction were dropped or not processed.
My boss told me to investigate the issue and find the cause. Again this topic is the most unmastered part of my carrier as dba.
There is no solid way I have found for a template for a clear solution. I have gathered 1 week worth of AWR stats reports just to campare baselines because that is what is always heard here.
Given a week awr statistics can you help me how to identify the cause of performance problem yesterday?
https://app.box.com/s/dna3i7auq1mel6gl1c4v
https://app.box.com/s/mumevcqqgu5c0b1mal4o
https://app.box.com/s/f24z3caboyknfyxhhcaj
https://app.box.com/s/xas3ra0qz081jp1ynso5
https://app.box.com/s/1ftb87kd2relqzzl9mnm
https://app.box.com/s/qqthfm6vpwdc3o5t1dfr
Kindly open report in notepad++ as this is in 500 linesize.
Thanks a lot,
pK

Answer 1

I already mentioned the db & OS version above
The application is just 3rd party developed in java.
Yes - but that is just one SMALL part of the info mentioned in that link about how to ask a question. Go back and read it again - especially the part about the info needed for a tuning request.
You also aren't responding to the questions or suggestions others have already posted. Alvaro posted this:
These logs you have provided are completely unformated and next to impossible to read. Why not just post the AWR HTML parts that are interesting? Such as: Time model, Top 5 Waits, Load profile.
Also, a one week AWR report is not very useful in your case. Focus on an AWR derived from the snapshots that make up the period the problem occurred.
The only comment you made was a sarcastic one about the formatting.
Why didn't you comment about the AWR suggestion that was made? If you want responders to help you have to be responsive to their comments. They are trying to help you.
You also never responded to the reply by Gayu0726:
To solve:
Identify the tables which read most.
Create index for the tables.
If index is already there, try to analyze it and gather statistics.
Check whether the index are in usable form.
You marked the reply 'helpful' but never said a word about whether you did those things and what the result was.
Himmy got the same treatment:
If this is an OLTP database can you try gathering stats on all tables of schemas used by the application.
Did you do that? Are the stats current? Why didn't you respond to let us know WHAT you are doing to solve the problem?
In short you seem to be relying on us to solve your problem and haven't provided ANY feedback about what, if anything, you are doing to solve it:
Yesterday Jan 15, 2014, we experienced very slow performance in our App. The webpage is hanging or disconnecting often and many transaction were dropped or not processed.
That's a good start to defining the problem.
My boss told me to investigate the issue and find the cause. Again this topic is the most unmastered part of my carrier as dba.
And it will likely continue to be 'unmastered' until you actually press the keyboard with your fingers and start doing things yourself.
There is no solid way I have found for a template for a clear solution.
If you 'experienced very slow performance' then, by definition, you MUST know that previously the performance was 'faster'.
That means that SOMETHING changed. The 'template' you seek is to determine WHAT CHANGED.
I have gathered 1 week worth of AWR stats reports just to campare baselines because that is what is always heard here.
Ok - so did you actually COMPARE the base lines to see what was different? What did you find was different? Why haven't you posted here and told us what you found that was different?
You have to use a process just like in those picture games for kids where they show two pictures and ask them: find the objects in the two pictures that are different.
Picture #1 - fast performance
Picutre #2 - slow performance
1. What changed between picture #1 and picture #2?
2. Did the amount of data in the tables (which you haven't told us anything about) change?
3. Did the statistics change? Or perhaps no one updated them lately?
4. Did the execution plans of any of the key queries change?
5. and so on, and so on
If you don't have picture #1 you will have a hard time comparing picture #2 to anything.
It is YOUR responsibility to post the information needed to help you. Post the info re stats, tables, execution plans, etc.