Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 12:51 (Drew)
    • No Format
      Without the stats, the query will use rule-based optimizer (RBO) and will pick up all of the indexes it can find because it's one of the rules.  Generally, if the tables are created correctly, the stats would certainly help.  The query is a simple one and should not be difficult for CBO to find the best way.  Here I think the drop and recreate table is not a good practice in that case.  The two tables  (before dropped and the recreated one) are different objects in the database with different object id. Oracle will gather stats for that table for sure.
      
      If you run:
      select table_name, to_char(last_analyzed,'mm/dd/yyyy hh24:mi:ss') from user_table where lower(table_name)='coursemanagement_section_ta';
      
      You will find when it's last analyzed.
      Have you tried to adjust this parameter, optimizer_index_cost_adj ?
      If not, please try to read through the following and see if that can help.  To start with, you can let this parameter equals 50.
      http://www.dba-oracle.com/oracle_tips_cost_adj.htm
      
  • 07:00 (Patrick) I've rebuilt the TA tables with current data and the synonyms now point there. The job completed at 7am.
  • 12:20 (Prabhu) I disable monitor when tables dropped and enable when new ones created as below.
    • No Format
      ---Enable monitoring
      SQL> alter index sakai_external.CM_INST_TA_PERSON_IDX monitoring usage;
      Index altered.
      SQL> alter index sakai_external.CM_SECTION_TA_EID_IDX monitoring usage;
      Index altered.
      SQL> select index_name, table_name, monitoring, used, end_monitoring from v$object_usage;
      no rows selected
      
      ---Disable monitoring
      alter index sakai_external.CM_INST_TB_PERSON_IDX nomonitoring usage;
      alter index sakai_external.CM_SECTION_TB_EID_IDX nomonitoring usage;
      

Saturday 10-06-2007

  • 24:00 (Oracle) run stats
  • 06:58 (Patrick) I switched to the recreated TB tables. The job started at 6:58am and completed at 7:06.
    • I checked the problem query on both the TA and TB tables and it looks like the indexes are still being used.
    • I noticed that there are 151 pairs of duplicate EID's in the SECTION table. Have we considered changing the view to weed those out?
    24:00 (Oracle) run stats

Friday 10-05-2007

  • 22:00 (Oracle) run stats
  • 14:49 (Patrick)
    • No Format
      Thanks, Brian. I created the indexes and added these statements to the
      script that recreates the tables for the synonym switch. There are
      currently no outstanding queries in the poor performance category.
      
  • 11:43 (Brian)
    • No Format
      Oh, I see, I didn't put an index on it because it was all null.  Okay,
      here are indexes for the courseset_eid and courseoffering_eid columns,
      both of which are all null.
      
      CREATE INDEX CM_MEMBERSHIP_TA_CS_IDX ON COURSEMANAGEMENT_MEMBERSHIP_TA
      (COURSESET_EID) STORAGE(INITIAL 50M NEXT 10M);
      CREATE INDEX CM_MEMBERSHIP_TB_CS_IDX ON COURSEMANAGEMENT_MEMBERSHIP_TB
      (COURSESET_EID) STORAGE(INITIAL 50M NEXT 10M);
      
      CREATE INDEX CM_MEMBERSHIP_TA_CO_IDX ON COURSEMANAGEMENT_MEMBERSHIP_TA
      (COURSEOFFERING_EID) STORAGE(INITIAL 50M NEXT 10M);
      CREATE INDEX CM_MEMBERSHIP_TB_CO_IDX ON COURSEMANAGEMENT_MEMBERSHIP_TB
      (COURSEOFFERING_EID) STORAGE(INITIAL 50M NEXT 10M);
      
      That will create the indexes on both tables.
      

...