Database slow response

Question

Hi Guys,
I am running Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production on Solaris 10.
I upgraded my database from 9i (9.2.0.4.0 - 64bit Production) to 11gR2 (11.2.0.3.0 - 64bit Production)--now I am experiencing slow response from the queries.
Below please find my Top 5 Wait Events:
Top 5 Timed Foreground Events
Event     Waits     Time(s)     Avg wait (ms)     % DB time     Wait Class
db file sequential read      3,573,342     7,796     2     71.69     User I/O
DB CPU          2,780          25.56     
db file parallel read     37,346     327     9     3.01     User I/O
direct path write temp     3,947     248     63     2.28      User I/O
Disk file operations I/O     20,134     170     8     1.56      User I/O
It looks like I have a serious I/O issues here--but how do I see if this is indeed the case?
Please Help!!!!!!
Thanks in advance.
Edited by: user11979518 on Nov 1, 2012 5:05 AM

Answer 1

user11979518 wrote:
Thanks Guys for the replies,
I strongly feel that this link--http://jonathanlewis.wordpress.com/category/oracle/statspack/ posted on this thread by Girish, really addresses my problems.
I used memory target during the upgrade.
Below are the reports from AWR:
This statement inetersted me most:
The DBA had decided to trust Oracle to do the right thing after the upgrade, so he had set the memory_target
and eliminated all the other memory parameters, including the db_keep_cache_size.I did exactly that on during my upgrade.
Here is the report from my database:
Segments by Physical Read Requests:
Owner          Tablespace Name          Object Name               Subobject Name     Obj. Type     Physical Reads     %Total
CTRONLIV     AXS_AP2               PAY_HISTORY                         TABLE          9,286,075     60.12
CTRONLIV     AXS_AP2               AP_VCHRS                         TABLE          2,732,117     17.69
CTRONLIV     AXS_AR2               APPL_HIST_HDRS                          TABLE          1,216,941     7.88
CTRONLIV     AXS_API2          SIY_X51                              INDEX          775,911          5.02
CTRONLIV     AXS_API3          CHCK_RECON_TRANDATE_IDX                    INDEX          263,826          1.71
Segments by UnOptimized Reads:
Owner          Tablespace Name          Object Name               Subobject Name     Obj. Type     UnOptimized Reads     %Total
CTRONLIV     AXS_AP2               PAY_HISTORY                         TABLE          9,278,509          69.33
CTRONLIV     AXS_AR2               APPL_HIST_HDRS                         TABLE          1,215,931          9.09
CTRONLIV     AXS_API2          SIYA_X51                         INDEX          775,915               5.80
CTRONLIV     AXS_AP2               AP_VCHRS                         TABLE          752,067               5.62
CTRONLIV     AXS_API3          CHCK_RECON_TRANDATE_IDX                    INDEX          263,826               1.97
See how much better your report looks when I put in tags for you?
Looking at the report it shows that I have done 9.2M read requests from table PAY_HISTORY and 1.2 M read requests from table APPL_HIST_HDRS,resulting in 9.2 M blocks reads from one table and 1.2M blocks read from the other, now I checked the sizes of the two tables:--PAY_HISTORY-->30GB and APPL_HIST_HDRS-->34GB.
I used dbms_metadata.get_ddl(),as suggested on the link,to see the DDL of the two tables...the storage parameter are as follows :
FOR table PAY_HISTORY:
) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 1048576 NEXT 20971520 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
For table APPL_HIST_HDRS:
) PCTFREE 10 PCTUSED 0 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 2147483648 NEXT 209715200 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
Does these mean that my tables were assigned to use KEEP buffer pool ?
Or are they are assigned to use defualt buffer pool, if so does it mean that my cache is not working and if so, how do I rectify this issue?
BUFFER_POOL DEFAULT means they were put into a pool named DEFAULT.  You should leave them there and work on the actual problem first.  There are queries to find out what is in the various pools, you can check that (and sometimes there are surprises).  But in general, leave it until after fixing the code that is making the problem.
You should look at the top SQL and see if it is accessing those objects.  You should look at all SQL accessing those objects.  Look at the plans, including predicates.  You can post those here for more help, see the thread about how to post a tuning request.  The most likely thing is that some plan is not the best.  After you fix that, you may find your problems magically change.  (Assuming you checked all the config stuff I suggested).