Statistics gather after 10g upgrade

I am on apps 11.5.10.2, database has been recently upgraded from 9.2.0.6 to 10.2.0.4. I used to periodically use GATHER SCHEMA STATISTICS (ALL SCHEMA), in the previous release of db.
What should be practiced after the upgrade? There are some custom schemas for third party tool. Does gather schema statistics concurrent program gather statistics for all the schema?
Thanks
SA

user593719 wrote:
Hussein,
To register a custom schema, I have to go thru the series of steps like registering application, creating a TOP etc., right? What if my custom application is in some other windows server and only schema is in the apps database? Do we need still follow the same steps?
Regards,
SAI am not sure why you have this custom schema in this Apps database. If your custom schema has nothing to do with Apps, you would be better off creating a separate instance for this custom app. You could then use the automatic stats gathering mechanism in 10g to gather stats for this custom schema app.
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/stats.htm#i41282
HTH
Srini

Similar Messages

Report giving error after 10g upgrade

We have a custom report which is erroring out after 10g upgrade. Following is the log file-->
**Starts**24-APR-2009 04:11:21
ORACLE error 3113 in FDPSTP
Cause: FDPSTP failed due to ORA-03113: end-of-file on communication channel
The SQL statement being executed at the time of the error was: SELECT R.Conc_Login_Id, R.Request_Id, R.Phase_Code, R.Status_Code, P
APP-FND-01564: ORACLE error 1000 in AFPGRG
Cause: AFPGRG failed due to ORA-01000: maximum open cursors exceeded.
The SQL statement being executed at the time of the error was: &SQLSTMT and was executed from the file &ERRFILE.
Start of log messages from FND_FILE
End of log messages from FND_FILE
ORACLE error 3114 in AFPRSR-Resubmit_Time
Cause: AFPRSR-Resubmit_Time failed due to ORA-03114: not connected to ORACLE
The SQL statement being executed at the time of the error was: SELECT R.Conc_Login_Id, R.Request_Id, R.Phase_Code, R
SELECT R.Conc_Login_Id, R.Request_Id, R.Phase_Code, R.Status_Code, P.A
Routine AFPPRD has encountered a fatal error. ORA-03114: not connected to ORACLE
Contact your system administrator or support representative.
Shutting down Concurrent Manager : 24-APR-2009 04:11:51
ORA-01041: internal error. hostdef extension doesn't exist
ORACLE error 3114 in AFPRSR-Resubmit_Time
Cause: AFPRSR-Resubmit_Time failed due to ORA-03114: not connected to ORACLE
The SQL statement being executed at the time of the error was: SELECT R.Conc_Login_Id, R.Request_Id, R.Phase_Code, R
List of errors encountered:
_ 1 _
Routine AFPCMT encountered an ORACLE error. ORA-01041: internal error.
hostdef extension doesn't exist
Review your error messages for the cause of the error. (=<POINTER>)
_ 2 _
Routine AFPPRD has encountered a fatal error. ORA-03114: not connected
to ORACLE
Contact your system administrator or support representative.
_ 3 _
Routine AFPPRD has encountered a fatal error. ORA-03114: not connected
to ORACLE
Contact your system administrator or support representative.
However the alert log has following-->
Errors in file /u07/fatstdb/10g/admin/FATST_fatstdb/udump/fatst_ora_10468.trc:
ORA-07445: exception encountered: core dump [qercoStart()+156] [SIGSEGV] [Address not mapped to object] [0x00000087D] [] []
I already increased the cursors from 700 to 900
How to fix it?

Hi,
However the alert log has following-->
Errors in file /u07/fatstdb/10g/admin/FATST_fatstdb/udump/fatst_ora_10468.trc:
ORA-07445: exception encountered: core dump [qercoStart()+156] [SIGSEGV] [Address not mapped to object] [0x00000087D] [] []Refer to the lookup to get more details about this error.
Note: 153788.1 - Troubleshoot an ORA-600 or ORA-7445 Error Using the Error Lookup Tool
https://metalink2.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=153788.1
I already increased the cursors from 700 to 900
How to fix it?Is it possible to increase OPEN_CURSORS to a higher value? Enable trace on this concurrent program, and see if this collects more details about the error.
Regards,
Hussein

DB Performance Issues after 10g Upgrade in EBS Instance

We have upgraded our Database from 9i to 10g as first part of EBS 11.5.9 to 11.5.10.2 upgrade. Currently our production is running on 11.5.9 apps with 10g DB.
Facing performance problems now. one of the them is, one Valueset query not using funcion based index while fired from the front end. but the same query when collected from SQL trace tkprofed file and executed from SQL Plus, it uses all proper indexes. We are not getting the cause of this.
Had anyone faced same kind of issues before. please suggest.
thanks,
Raj.

Make sure you have all of the recommended performance patches for 11.5.9, and gather stats for SYS and SYSTEM in the following manner:
Oracle E-Business Suite Recommended Performance Patches
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=244040.1
Collecting Statistics with Oracle Apps 11i
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=368252.1
execute dbms_stats.unlock_schema_stats('SYS');
execute dbms_stats.unlock_schema_stats('SYSTEM');
exec dbms_stats.gather_schema_stats('SYSTEM',options=>'GATHER', estimate_percent => 100, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('SYS',options=>'GATHER', estimate_percent => 100, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_fixed_objects_stats();
commit;
exec dbms_stats.DELETE_TABLE_STATS('SYS','X$KCCRSR');
exec dbms_stats.LOCK_TABLE_STATS('SYS','X$KCCRSR');
commit;
The last 3 commands resolve problems with RMAN, in case you are using it.
Rman Backup is Very Slow selecting from V$RMAN_STATUS
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=375386.1
Poor performance when accessing V$RMAN_BACKUP_JOB_DETAILS
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=420200.1
Troubleshooting Oracle Applications Performance Issues
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=169935.1
Debugging General Performance Issues with Oracle Apps
http://blogs.oracle.com/schan/newsItems/departments/optimizingPerformance/2007/05/18#a1548
Performance Tuning the Apps Database Layer
http://blogs.oracle.com/schan/newsItems/departments/optimizingPerformance/2007/05/17#a1562
Preventing Apps 11i Performance Issues in Four Steps
http://blogs.oracle.com/schan/newsItems/departments/optimizingPerformance/2007/05/21#a1566

Performance issue after 10G upgrade.

All,
We recently upgraded to 10G (Version:10.2.0.3.0) after which the below query causing the problem. This query is written in a pl/sql package called by a Perl program. The Perl program is running forever without completion during some attempts and sometimes it is completing very fast. We did some kind of debugging and found that everytime the program is getting stucked up at this below given query and not at all proceeding from here even if we leave it for 2 - 3 days. During a successful attempt it completes in 3 - 4 hrs. This query is taking 2 explain plan as given below and it seems one of them is best and the other one is worst. Plan 2 is best and plan 1 is worst.
Is there any suggestion in fixing this and the reason why two explain plans are picking up?....Num of records on the tables is as given below...
Can you please provide me some detailed information as i'm a beginner in these performance tuning concepts?
Your help will be much appreciated..
Tables No. of records
ult_cust_master 551925
us_state_county 3223
customer 1559
turfbuilder_group2_empcnt_tmp 44K
ult_cust_sale 2430143
ucsi_item 9714371
SELECT cust.cust_num, cust.cust_name, cust.emp_count, cust.sic1,
 cust.s1_description, NVL (cust_sale.qty, 0) qty,
 NVL (cust_sale.mot_amt, 0) mot_amt,
 NVL (cust_sale.cust_amt, 0) cust_amt, cust.min_sale_dt,
 cust.max_sale_dt, cust.cust_status
FROM (SELECT DISTINCT ucm.cust_num, f.cust_name cust_name,
 NVL (te.tet_emp_count, 0) emp_count, b.min_sale_dt,
 b.max_sale_dt, f.cust_status, sc1.sic1,
 sc1.s1_description
 FROM ult_cust_master ucm,
 us_state_county u,
 customer f,
 (SELECT div_cd, ctry_cd, cust_num,
 MIN (ucs_dt) min_sale_dt,
 MAX (ucs_dt) max_sale_dt
 FROM ult_cust_sale
 WHERE div_cd = :b4
 AND ctry_cd = :b3
 AND rec_status = 'A'
 GROUP BY div_cd, ctry_cd, cust_num) b,
 sic1 sc1,
 (SELECT tet_code, tet_vm_code, tet_type,
 tet_emp_count
 FROM turfbuilder_group2_empcnt_tmp
 WHERE tet_type = 'D') te
 WHERE f.div_cd = ucm.div_cd
 AND f.ctry_cd = ucm.ctry_cd
 AND f.cust_num = ucm.cust_num
 AND b.div_cd = ucm.div_cd
 AND b.ctry_cd = ucm.ctry_cd
 AND b.cust_num = ucm.cust_num
 AND te.tet_code(+) = ucm.cust_num
 AND te.tet_vm_code = sc1.sic1
 AND f.div_cd = :b4
 AND f.ctry_cd = :b3
 AND ucm.ucm_stcnty_fips_cd = u.usc_st_cnty_cd
 AND UPPER (u.usc_state_abbrev) NOT IN ('PR', 'VI')
 AND ucm.rec_status = 'A'
 AND u.rec_status = 'A'
 AND sc1.rec_status = 'A'
 AND f.cust_imp21_dealer_fg = 'Y'
 AND NVL (f.cust_test_dealer_fg, 'N') <> 'Y') cust,
 (SELECT c.cust_num cust_num, sc2.sic1,
 SUM (DECODE (a.ucsii_unit_fg,
 'Y', a.ucsii_qty * 1,
 a.ucsii_qty * 0
 ) qty,
 SUM (a.ucsii_qty * a.ucsii_mot_unit_pr) mot_amt,
 SUM (a.ucsii_qty * a.ucsii_ult_unit_pr) cust_amt
 FROM ucsi_item a,
 ult_cust_sale b,
 ult_cust_master c,
 sic2 sc2,
 us_state_county u
 WHERE a.div_cd = b.div_cd
 AND a.ctry_cd = b.ctry_cd
 AND a.cust_num = b.cust_num
 AND a.ucm_mailbox_num = b.ucm_mailbox_num
 AND a.ucm_seq = b.ucm_seq
 AND a.ucs_seq = b.ucs_seq
 AND c.div_cd = b.div_cd
 AND c.ctry_cd = b.ctry_cd
 AND c.cust_num = b.cust_num
 AND c.ucm_mailbox_num = b.ucm_mailbox_num
 AND c.ucm_seq = b.ucm_seq
 AND SUBSTR (c.ucm_sic_cd, 1, 2) = sc2.sic2
 AND c.ucm_stcnty_fips_cd = u.usc_st_cnty_cd
 AND a.ucsii_in_apmr_fg = 'Y'
 AND a.ucsii_audit_data_cd = 'G'
 AND a.ucsii_contract_id IN
 ('BRANDED',
 'CTR',
 'WARIS',
 'RADIUS',
 'BRNDCONV',
 'BRNDTRNK'
 AND ( (a.ucsii_unit_fg = 'Y')
 OR (a.ucsii_unit_fg = 'N' AND a.ucsii_item_num LIKE '%.%')
 AND c.div_cd = :b4
 AND c.ctry_cd = :b3
 AND UPPER (u.usc_state_abbrev) NOT IN ('PR', 'VI')
 AND u.rec_status = 'A'
 AND c.rec_status = 'A'
 AND a.rec_status = 'A'
 AND sc2.rec_status = 'A'
 AND b.ua_cd = 'ENDCUST'
 AND b.rec_status = 'A'
 AND b.ucs_dt BETWEEN TO_DATE (:b2, 'dd mon yyyy')
 AND TO_DATE (:b1, 'dd mon yyyy')
 GROUP BY c.cust_num, sc2.sic1) cust_sale
WHERE cust.cust_num = cust_sale.cust_num(+) AND cust.sic1 = cust_sale.sic1(+)------------------------------------------------------------------------------------------------------------------------
{color:blue}
Execution Plan – 1:
Plan hash value: 2237978112
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 643 (100)| |
|* 1 | HASH JOIN OUTER | | 1 | 175 | 643 (2)| 00:00:08 |
| 2 | VIEW | | 1 | 118 | 74 (5)| 00:00:01 |
| 3 | HASH UNIQUE | | 1 | 310 | 74 (5)| 00:00:01 |
| 4 | HASH GROUP BY | | 1 | 310 | 74 (5)| 00:00:01 |
|* 5 | FILTER | | | | | |
| 6 | NESTED LOOPS | | 1 | 310 | 73 (3)| 00:00:01 |
| 7 | NESTED LOOPS | | 1 | 278 | 70 (2)| 00:00:01 |
| 8 | NESTED LOOPS | | 1 | 187 | 69 (2)| 00:00:01 |
| 9 | NESTED LOOPS | | 1 | 148 | 68 (2)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 100 | 52 (2)| 00:00:01 |
|* 11 | TABLE ACCESS FULL | TURFBUILDER_GROUP2_EMPCNT_TMP | 1 | 52 | 51 (2)| 00:00:01 |
|* 12 | TABLE ACCESS BY INDEX ROWID| SIC1 | 1 | 48 | 1 (0)| 00:00:01 |
|* 13 | INDEX UNIQUE SCAN | SYS_C001278 | 1 | | 1 (0)| 00:00:01 |
|* 14 | TABLE ACCESS BY INDEX ROWID | ULT_CUST_MASTER | 517 | 24816 | 16 (0)| 00:00:01 |
|* 15 | INDEX RANGE SCAN | XIF9ULT_CUST_MASTER | 505 | | 1 (0)| 00:00:01 |
|* 16 | TABLE ACCESS BY INDEX ROWID | US_STATE_COUNTY | 1 | 39 | 1 (0)| 00:00:01 |
|* 17 | INDEX UNIQUE SCAN | XPKSTATE_COUNTY | 1 | | 1 (0)| 00:00:01 |
|* 18 | TABLE ACCESS BY INDEX ROWID | CUSTOMER | 1 | 91 | 1 (0)| 00:00:01 |
|* 19 | INDEX UNIQUE SCAN | XPKCUSTOMER | 1 | | 1 (0)| 00:00:01 |
|* 20 | INDEX RANGE SCAN | XIE1ULT_CUST_SALE | 13514 | 422K| 2 (0)| 00:00:01 |
| 21 | VIEW | | 1 | 57 | 569 (2)| 00:00:07 |
| 22 | HASH GROUP BY | | 1 | 209 | 569 (2)| 00:00:07 |
|* 23 | FILTER | | | | | |
|* 24 | TABLE ACCESS BY INDEX ROWID | UCSI_ITEM | 1 | 74 | 1 (0)| 00:00:01 |
| 25 | NESTED LOOPS | | 1 | 209 | 568 (1)| 00:00:07 |
| 26 | NESTED LOOPS | | 1 | 135 | 567 (1)| 00:00:07 |
|* 27 | HASH JOIN | | 1491 | 110K| 118 (3)| 00:00:02 |
|* 28 | TABLE ACCESS FULL | SIC2 | 83 | 996 | 2 (0)| 00:00:01 |
| 29 | TABLE ACCESS BY INDEX ROWID | ULT_CUST_MASTER | 186 | 9858 | 13 (0)| 00:00:01 |
| 30 | NESTED LOOPS | | 1500 | 96000 | 115 (2)| 00:00:02 |
|* 31 | TABLE ACCESS FULL | US_STATE_COUNTY | 8 | 88 | 9 (12)| 00:00:01 |
|* 32 | INDEX RANGE SCAN | TEST | 186 | | 1 (0)| 00:00:01 |
|* 33 | TABLE ACCESS BY INDEX ROWID | ULT_CUST_SALE | 1 | 59 | 1 (0)| 00:00:01 |
|* 34 | INDEX RANGE SCAN | XIE1ULT_CUST_SALE | 1 | | 1 (0)| 00:00:01 |
|* 35 | INDEX RANGE SCAN | XPKUCSI_ITEM | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("CUST"."CUST_NUM"="CUST_SALE"."CUST_NUM" AND "CUST"."SIC1"="CUST_SALE"."SIC1")
5 - filter((:B3=:B3 AND :B4=:B4))
11 - filter("TET_TYPE"='D')
12 - filter("SC1"."REC_STATUS"='A')
13 - access("TET_VM_CODE"="SC1"."SIC1")
14 - filter("UCM"."REC_STATUS"='A')
15 - access("UCM"."DIV_CD"=:B4 AND "UCM"."CTRY_CD"=:B3 AND "TET_CODE"="UCM"."CUST_NUM")
filter(("UCM"."DIV_CD"=:B4 AND "UCM"."CTRY_CD"=:B3))
16 - filter((UPPER("U"."USC_STATE_ABBREV")<>'PR' AND UPPER("U"."USC_STATE_ABBREV")<>'VI' AND
"U"."REC_STATUS"='A'))
17 - access("UCM"."UCM_STCNTY_FIPS_CD"="U"."USC_ST_CNTY_CD")
18 - filter(("F"."CUST_IMP21_DEALER_FG"='Y' AND NVL("F"."CUST_TEST_DEALER_FG",'N')<>'Y'))
19 - access("F"."DIV_CD"=:B4 AND "F"."CTRY_CD"=:B3 AND "F"."CUST_NUM"="UCM"."CUST_NUM")
filter(("F"."DIV_CD"=:B4 AND "F"."CTRY_CD"=:B3))
20 - access("DIV_CD"=:B4 AND "CTRY_CD"=:B3 AND "CUST_NUM"="UCM"."CUST_NUM" AND "REC_STATUS"='A')
filter(("DIV_CD"=:B4 AND "CTRY_CD"=:B3 AND "REC_STATUS"='A'))
23 - filter(TO_DATE(:B2,'dd mon yyyy')<=TO_DATE(:B1,'dd mon yyyy'))
24 - filter((("A"."UCSII_UNIT_FG"='Y' OR ("A"."UCSII_ITEM_NUM" LIKE '%.%' AND "A"."UCSII_UNIT_FG"='N')) AND
"A"."UCSII_IN_APMR_FG"='Y' AND INTERNAL_FUNCTION("A"."UCSII_CONTRACT_ID") AND "A"."UCSII_AUDIT_DATA_CD"='G'
AND "A"."REC_STATUS"='A'))
27 - access("SC2"."SIC2"=SUBSTR("C"."UCM_SIC_CD",1,2))
28 - filter("SC2"."REC_STATUS"='A')
31 - filter((UPPER("U"."USC_STATE_ABBREV")<>'PR' AND UPPER("U"."USC_STATE_ABBREV")<>'VI' AND
"U"."REC_STATUS"='A'))
32 - access("C"."UCM_STCNTY_FIPS_CD"="U"."USC_ST_CNTY_CD" AND "C"."DIV_CD"=:B4 AND "C"."CTRY_CD"=:B3 AND
"C"."REC_STATUS"='A')
33 - filter(("B"."UA_CD"='ENDCUST' AND "C"."UCM_MAILBOX_NUM"="B"."UCM_MAILBOX_NUM"))
34 - access("B"."DIV_CD"=:B4 AND "B"."CTRY_CD"=:B3 AND "C"."CUST_NUM"="B"."CUST_NUM" AND
"C"."UCM_SEQ"="B"."UCM_SEQ" AND "B"."UCS_DT">=TO_DATE(:B2,'dd mon yyyy') AND "B"."REC_STATUS"='A' AND
"B"."UCS_DT"<=TO_DATE(:B1,'dd mon yyyy'))
filter("B"."REC_STATUS"='A')
35 - access("A"."DIV_CD"=:B4 AND "A"."CTRY_CD"=:B3 AND "A"."CUST_NUM"="B"."CUST_NUM" AND
"A"."UCM_MAILBOX_NUM"="B"."UCM_MAILBOX_NUM" AND "A"."UCM_SEQ"="B"."UCM_SEQ" AND "A"."UCS_SEQ"="B"."UCS_SEQ")
{color}
{color:green}
Execution Plan – 2:
Plan hash value: 2023039777
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | | 3341 (100)| |
|* 1 | HASH JOIN RIGHT OUTER | | 12967 | 2216K| | 3341 (5)| 00:00:41 |
| 2 | VIEW | | 1 | 57 | | 607 (6)| 00:00:08 |
| 3 | HASH GROUP BY | | 1 | 209 | | 607 (6)| 00:00:08 |
|* 4 | FILTER | | | | | | |
|* 5 | TABLE ACCESS BY INDEX ROWID | UCSI_ITEM | 1 | 74 | | 1 (0)| 00:00:01 |
| 6 | NESTED LOOPS | | 1 | 209 | | 606 (6)| 00:00:08 |
| 7 | NESTED LOOPS | | 1 | 135 | | 605 (6)| 00:00:08 |
|* 8 | HASH JOIN | | 1 | 123 | | 604 (6)| 00:00:08 |
|* 9 | TABLE ACCESS BY INDEX ROWID| ULT_CUST_SALE | 1214 | 71626 | | 455 (7)| 00:00:06 |
|* 10 | INDEX SKIP SCAN | XIE1ULT_CUST_SALE | 1 | | | 455 (7)| 00:00:06 |
| 11 | TABLE ACCESS BY INDEX ROWID| ULT_CUST_MASTER | 245 | 12985 | | 17 (0)| 00:00:01 |
| 12 | NESTED LOOPS | | 1971 | 123K| | 148 (2)| 00:00:02 |
|* 13 | TABLE ACCESS FULL | US_STATE_COUNTY | 8 | 88 | | 9 (12)| 00:00:01 |
|* 14 | INDEX RANGE SCAN | TEST | 245 | | | 1 (0)| 00:00:01 |
|* 15 | TABLE ACCESS BY INDEX ROWID | SIC2 | 1 | 12 | | 1 (0)| 00:00:01 |
|* 16 | INDEX UNIQUE SCAN | XPKSIC2 | 1 | | | 1 (0)| 00:00:01 |
|* 17 | INDEX RANGE SCAN | XPKUCSI_ITEM | 1 | | | 1 (0)| 00:00:01 |
| 18 | VIEW | | 12967 | 1494K| | 2732 (5)| 00:00:33 |
| 19 | HASH UNIQUE | | 12967 | 3254K| 6936K| 2732 (5)| 00:00:33 |
|* 20 | HASH JOIN | | 12967 | 3254K| | 1998 (6)| 00:00:24 |
| 21 | VIEW | | 410 | 16400 | | 1781 (5)| 00:00:22 |
| 22 | HASH GROUP BY | | 410 | 13120 | | 1781 (5)| 00:00:22 |
|* 23 | FILTER | | | | | | |
|* 24 | INDEX RANGE SCAN | XIE1ULT_CUST_SALE | 1963K| 59M| | 1781 (5)| 00:00:22 |
|* 25 | HASH JOIN | | 4792 | 1015K| | 215 (7)| 00:00:03 |
|* 26 | TABLE ACCESS FULL | SIC1 | 11 | 528 | | 2 (0)| 00:00:01 |
|* 27 | HASH JOIN | | 4792 | 790K| | 212 (6)| 00:00:03 |
|* 28 | TABLE ACCESS BY INDEX ROWID | CUSTOMER | 1003 | 79237 | | 4 (0)| 00:00:01 |
|* 29 | INDEX RANGE SCAN | XIF317CUSTOMER | 1371 | | | 1 (0)| 00:00:01 |
|* 30 | HASH JOIN | | 4794 | 421K| | 207 (6)| 00:00:03 |
| 31 | TABLE ACCESS BY INDEX ROWID | ULT_CUST_MASTER | 245 | 8820 | | 17 (0)| 00:00:01 |
| 32 | NESTED LOOPS | | 1971 | 136K| | 148 (2)| 00:00:02 |
|* 33 | TABLE ACCESS FULL | US_STATE_COUNTY | 8 | 280 | | 9 (12)| 00:00:01 |
|* 34 | INDEX RANGE SCAN | TEST | 245 | | | 1 (0)| 00:00:01 |
|* 35 | TABLE ACCESS FULL | TURFBUILDER_GROUP2_EMPCNT_TMP | 8914 | 165K| | 58 (14)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("CUST"."CUST_NUM"="CUST_SALE"."CUST_NUM" AND "CUST"."SIC1"="CUST_SALE"."SIC1")
4 - filter(TO_DATE(:B2,'dd mon yyyy')<=TO_DATE(:B1,'dd mon yyyy'))
5 - filter((("A"."UCSII_UNIT_FG"='Y' OR ("A"."UCSII_ITEM_NUM" LIKE '%.%' AND "A"."UCSII_UNIT_FG"='N')) AND
"A"."UCSII_IN_APMR_FG"='Y' AND INTERNAL_FUNCTION("A"."UCSII_CONTRACT_ID") AND "A"."UCSII_AUDIT_DATA_CD"='G' AND
"A"."REC_STATUS"='A'))
8 - access("C"."DIV_CD"="B"."DIV_CD" AND "C"."CTRY_CD"="B"."CTRY_CD" AND "C"."CUST_NUM"="B"."CUST_NUM" AND
"C"."UCM_MAILBOX_NUM"="B"."UCM_MAILBOX_NUM" AND "C"."UCM_SEQ"="B"."UCM_SEQ")
9 - filter("B"."UA_CD"='ENDCUST')
10 - access("B"."DIV_CD"=:B4 AND "B"."CTRY_CD"=:B3 AND "B"."UCS_DT">=TO_DATE(:B2,'dd mon yyyy') AND
"B"."REC_STATUS"='A' AND "B"."UCS_DT"<=TO_DATE(:B1,'dd mon yyyy'))
filter(("B"."UCS_DT">=TO_DATE(:B2,'dd mon yyyy') AND "B"."REC_STATUS"='A' AND "B"."UCS_DT"<=TO_DATE(:B1,'dd
mon yyyy')))
13 - filter((UPPER("U"."USC_STATE_ABBREV")<>'PR' AND UPPER("U"."USC_STATE_ABBREV")<>'VI' AND "U"."REC_STATUS"='A'))
14 - access("C"."UCM_STCNTY_FIPS_CD"="U"."USC_ST_CNTY_CD" AND "C"."DIV_CD"=:B4 AND "C"."CTRY_CD"=:B3 AND
"C"."REC_STATUS"='A')
15 - filter("SC2"."REC_STATUS"='A')
16 - access("SC2"."SIC2"=SUBSTR("C"."UCM_SIC_CD",1,2))
17 - access("A"."DIV_CD"=:B4 AND "A"."CTRY_CD"=:B3 AND "A"."CUST_NUM"="B"."CUST_NUM" AND
"A"."UCM_MAILBOX_NUM"="B"."UCM_MAILBOX_NUM" AND "A"."UCM_SEQ"="B"."UCM_SEQ" AND "A"."UCS_SEQ"="B"."UCS_SEQ")
20 - access("B"."DIV_CD"="UCM"."DIV_CD" AND "B"."CTRY_CD"="UCM"."CTRY_CD" AND "B"."CUST_NUM"="UCM"."CUST_NUM")
23 - filter((:B3=:B3 AND :B4=:B4))
24 - access("DIV_CD"=:B4 AND "CTRY_CD"=:B3 AND "REC_STATUS"='A')
filter(("DIV_CD"=:B4 AND "CTRY_CD"=:B3 AND "DIV_CD"=:B4 AND "CTRY_CD"=:B3 AND "REC_STATUS"='A'))
25 - access("TET_VM_CODE"="SC1"."SIC1")
26 - filter("SC1"."REC_STATUS"='A')
27 - access("F"."DIV_CD"="UCM"."DIV_CD" AND "F"."CTRY_CD"="UCM"."CTRY_CD" AND "F"."CUST_NUM"="UCM"."CUST_NUM")
28 - filter(("F"."DIV_CD"=:B4 AND "F"."CUST_IMP21_DEALER_FG"='Y' AND NVL("F"."CUST_TEST_DEALER_FG",'N')<>'Y'))
29 - access("F"."CTRY_CD"=:B3)
30 - access("TET_CODE"="UCM"."CUST_NUM")
33 - filter((UPPER("U"."USC_STATE_ABBREV")<>'PR' AND UPPER("U"."USC_STATE_ABBREV")<>'VI' AND "U"."REC_STATUS"='A'))
34 - access("UCM"."UCM_STCNTY_FIPS_CD"="U"."USC_ST_CNTY_CD" AND "UCM"."DIV_CD"=:B4 AND "UCM"."CTRY_CD"=:B3 AND
"UCM"."REC_STATUS"='A')
35 - filter("TET_TYPE"='D')
{color}
Edited by: user3030284 on Oct 28, 2008 9:42 PM


{size:12}
All,


We recently upgraded to 10G (Version:10.2.0.3.0) after which the below query causing the problem. This query is written in a pl/sql package called by a Perl program. The Perl program is running forever without completion during some attempts and sometimes it is completing very fast. We did some kind of debugging and found that everytime the program is getting stucked up at this below given query and not at all proceeding from here even if we leave it for 2 - 3 days. During a successful attempt it completes in 3 - 4 hrs. This query is taking 2 explain plan as given below and it seems one of them is best and the other one is worst. Plan 2 is best and plan 1 is worst.
Is there any suggestion in fixing this and the reason why two explain plans are picking up?....Num of records on the tables is as given below...
Can you please provide me some detailed information as i'm a beginner in these performance tuning concepts?
Your help will be much appreciated..


Tables No. of records
ult_cust_master 551925
us_state_county 3223
customer 1559
turfbuilder_group2_empcnt_tmp 44K
ult_cust_sale 2430143
ucsi_item 9714371
{size}


 /* Formatted on 2007/09/30 20:37 (Formatter Plus v4.8.5) */ SELECT cust.cust_num, cust.cust_name, cust.emp_count, cust.sic1, cust.s1_description, NVL (cust_sale.qty, 0) qty, NVL (cust_sale.mot_amt, 0) mot_amt, NVL (cust_sale.cust_amt, 0) cust_amt, cust.min_sale_dt, cust.max_sale_dt, cust.cust_status FROM (SELECT DISTINCT ucm.cust_num, f.cust_name cust_name, NVL (te.tet_emp_count, 0) emp_count, b.min_sale_dt, b.max_sale_dt, f.cust_status, sc1.sic1, sc1.s1_description FROM ult_cust_master ucm, us_state_county u, customer f, (SELECT div_cd, ctry_cd, cust_num, MIN (ucs_dt) min_sale_dt, MAX (ucs_dt) max_sale_dt FROM ult_cust_sale WHERE div_cd = :b4 AND ctry_cd = :b3 AND rec_status = 'A' GROUP BY div_cd, ctry_cd, cust_num) b, sic1 sc1, (SELECT tet_code, tet_vm_code, tet_type, tet_emp_count FROM turfbuilder_group2_empcnt_tmp WHERE tet_type = 'D') te WHERE f.div_cd = ucm.div_cd AND f.ctry_cd = ucm.ctry_cd AND f.cust_num = ucm.cust_num AND b.div_cd = ucm.div_cd AND b.ctry_cd = ucm.ctry_cd AND b.cust_num = ucm.cust_num AND te.tet_code(+) = ucm.cust_num AND te.tet_vm_code = sc1.sic1 AND f.div_cd = :b4 AND f.ctry_cd = :b3 AND ucm.ucm_stcnty_fips_cd = u.usc_st_cnty_cd AND UPPER (u.usc_state_abbrev) NOT IN ('PR', 'VI') AND ucm.rec_status = 'A' AND u.rec_status = 'A' AND sc1.rec_status = 'A' AND f.cust_imp21_dealer_fg = 'Y' AND NVL (f.cust_test_dealer_fg, 'N') <> 'Y') cust, (SELECT c.cust_num cust_num, sc2.sic1, SUM (DECODE (a.ucsii_unit_fg, 'Y', a.ucsii_qty * 1, a.ucsii_qty * 0 ) ) qty, SUM (a.ucsii_qty * a.ucsii_mot_unit_pr) mot_amt, SUM (a.ucsii_qty * a.ucsii_ult_unit_pr) cust_amt FROM ucsi_item a, ult_cust_sale b, ult_cust_master c, sic2 sc2, us_state_county u WHERE a.div_cd = b.div_cd AND a.ctry_cd = b.ctry_cd AND a.cust_num = b.cust_num AND a.ucm_mailbox_num = b.ucm_mailbox_num AND a.ucm_seq = b.ucm_seq AND a.ucs_seq = b.ucs_seq AND c.div_cd = b.div_cd AND c.ctry_cd = b.ctry_cd AND c.cust_num = b.cust_num AND c.ucm_mailbox_num = b.ucm_mailbox_num AND c.ucm_seq = b.ucm_seq AND SUBSTR (c.ucm_sic_cd, 1, 2) = sc2.sic2 AND c.ucm_stcnty_fips_cd = u.usc_st_cnty_cd AND a.ucsii_in_apmr_fg = 'Y' AND a.ucsii_audit_data_cd = 'G' AND a.ucsii_contract_id IN ('BRANDED', 'CTR', 'WARIS', 'RADIUS', 'BRNDCONV', 'BRNDTRNK' ) AND ( (a.ucsii_unit_fg = 'Y') OR (a.ucsii_unit_fg = 'N' AND a.ucsii_item_num LIKE '%.%') ) AND c.div_cd = :b4 AND c.ctry_cd = :b3 AND UPPER (u.usc_state_abbrev) NOT IN ('PR', 'VI') AND u.rec_status = 'A' AND c.rec_status = 'A' AND a.rec_status = 'A' AND sc2.rec_status = 'A' AND b.ua_cd = 'ENDCUST' AND b.rec_status = 'A' AND b.ucs_dt BETWEEN TO_DATE (:b2, 'dd mon yyyy') AND TO_DATE (:b1, 'dd mon yyyy') GROUP BY c.cust_num, sc2.sic1) cust_sale WHERE cust.cust_num = cust_sale.cust_num(+) AND cust.sic1 = cust_sale.sic1(+) 


{color:green}


Explain Plan -- 1:


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 643 (100)| |
|* 1 | HASH JOIN OUTER | | 1 | 175 | 643 (2)| 00:00:08 |
| 2 | VIEW | | 1 | 118 | 74 (5)| 00:00:01 |
| 3 | HASH UNIQUE | | 1 | 310 | 74 (5)| 00:00:01 |
| 4 | HASH GROUP BY | | 1 | 310 | 74 (5)| 00:00:01 |
|* 5 | FILTER | | | | | |
| 6 | NESTED LOOPS | | 1 | 310 | 73 (3)| 00:00:01 |
| 7 | NESTED LOOPS | | 1 | 278 | 70 (2)| 00:00:01 |
| 8 | NESTED LOOPS | | 1 | 187 | 69 (2)| 00:00:01 |
| 9 | NESTED LOOPS | | 1 | 148 | 68 (2)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 100 | 52 (2)| 00:00:01 |
|* 11 | TABLE ACCESS FULL | TURFBUILDER_GROUP2_EMPCNT_TMP | 1 | 52 | 51 (2)| 00:00:01 |
|* 12 | TABLE ACCESS BY INDEX ROWID| SIC1 | 1 | 48 | 1 (0)| 00:00:01 |
|* 13 | INDEX UNIQUE SCAN | SYS_C001278 | 1 | | 1 (0)| 00:00:01 |
|* 14 | TABLE ACCESS BY INDEX ROWID | ULT_CUST_MASTER | 517 | 24816 | 16 (0)| 00:00:01 |
|* 15 | INDEX RANGE SCAN | XIF9ULT_CUST_MASTER | 505 | | 1 (0)| 00:00:01 |
|* 16 | TABLE ACCESS BY INDEX ROWID | US_STATE_COUNTY | 1 | 39 | 1 (0)| 00:00:01 |
|* 17 | INDEX UNIQUE SCAN | XPKSTATE_COUNTY | 1 | | 1 (0)| 00:00:01 |
|* 18 | TABLE ACCESS BY INDEX ROWID | CUSTOMER | 1 | 91 | 1 (0)| 00:00:01 |
|* 19 | INDEX UNIQUE SCAN | XPKCUSTOMER | 1 | | 1 (0)| 00:00:01 |
|* 20 | INDEX RANGE SCAN | XIE1ULT_CUST_SALE | 13514 | 422K| 2 (0)| 00:00:01 |
| 21 | VIEW | | 1 | 57 | 569 (2)| 00:00:07 |
| 22 | HASH GROUP BY | | 1 | 209 | 569 (2)| 00:00:07 |
|* 23 | FILTER | | | | | |
|* 24 | TABLE ACCESS BY INDEX ROWID | UCSI_ITEM | 1 | 74 | 1 (0)| 00:00:01 |
| 25 | NESTED LOOPS | | 1 | 209 | 568 (1)| 00:00:07 |
| 26 | NESTED LOOPS | | 1 | 135 | 567 (1)| 00:00:07 |
|* 27 | HASH JOIN | | 1491 | 110K| 118 (3)| 00:00:02 |
|* 28 | TABLE ACCESS FULL | SIC2 | 83 | 996 | 2 (0)| 00:00:01 |
| 29 | TABLE ACCESS BY INDEX ROWID | ULT_CUST_MASTER | 186 | 9858 | 13 (0)| 00:00:01 |
| 30 | NESTED LOOPS | | 1500 | 96000 | 115 (2)| 00:00:02 |
|* 31 | TABLE ACCESS FULL | US_STATE_COUNTY | 8 | 88 | 9 (12)| 00:00:01 |
|* 32 | INDEX RANGE SCAN | TEST | 186 | | 1 (0)| 00:00:01 |
|* 33 | TABLE ACCESS BY INDEX ROWID | ULT_CUST_SALE | 1 | 59 | 1 (0)| 00:00:01 |
|* 34 | INDEX RANGE SCAN | XIE1ULT_CUST_SALE | 1 | | 1 (0)| 00:00:01 |
|* 35 | INDEX RANGE SCAN | XPKUCSI_ITEM | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("CUST"."CUST_NUM"="CUST_SALE"."CUST_NUM" AND "CUST"."SIC1"="CUST_SALE"."SIC1")
5 - filter((:B3=:B3 AND :B4=:B4))
11 - filter("TET_TYPE"='D')
12 - filter("SC1"."REC_STATUS"='A')
13 - access("TET_VM_CODE"="SC1"."SIC1")
14 - filter("UCM"."REC_STATUS"='A')
15 - access("UCM"."DIV_CD"=:B4 AND "UCM"."CTRY_CD"=:B3 AND "TET_CODE"="UCM"."CUST_NUM")
filter(("UCM"."DIV_CD"=:B4 AND "UCM"."CTRY_CD"=:B3))
16 - filter((UPPER("U"."USC_STATE_ABBREV")<>'PR' AND UPPER("U"."USC_STATE_ABBREV")<>'VI' AND
"U"."REC_STATUS"='A'))
17 - access("UCM"."UCM_STCNTY_FIPS_CD"="U"."USC_ST_CNTY_CD")
18 - filter(("F"."CUST_IMP21_DEALER_FG"='Y' AND NVL("F"."CUST_TEST_DEALER_FG",'N')<>'Y'))
19 - access("F"."DIV_CD"=:B4 AND "F"."CTRY_CD"=:B3 AND "F"."CUST_NUM"="UCM"."CUST_NUM")
filter(("F"."DIV_CD"=:B4 AND "F"."CTRY_CD"=:B3))
20 - access("DIV_CD"=:B4 AND "CTRY_CD"=:B3 AND "CUST_NUM"="UCM"."CUST_NUM" AND "REC_STATUS"='A')
filter(("DIV_CD"=:B4 AND "CTRY_CD"=:B3 AND "REC_STATUS"='A'))
23 - filter(TO_DATE(:B2,'dd mon yyyy')<=TO_DATE(:B1,'dd mon yyyy'))
24 - filter((("A"."UCSII_UNIT_FG"='Y' OR ("A"."UCSII_ITEM_NUM" LIKE '%.%' AND "A"."UCSII_UNIT_FG"='N')) AND
"A"."UCSII_IN_APMR_FG"='Y' AND INTERNAL_FUNCTION("A"."UCSII_CONTRACT_ID") AND "A"."UCSII_AUDIT_DATA_CD"='G'
AND "A"."REC_STATUS"='A'))
27 - access("SC2"."SIC2"=SUBSTR("C"."UCM_SIC_CD",1,2))
28 - filter("SC2"."REC_STATUS"='A')
31 - filter((UPPER("U"."USC_STATE_ABBREV")<>'PR' AND UPPER("U"."USC_STATE_ABBREV")<>'VI' AND
"U"."REC_STATUS"='A'))
32 - access("C"."UCM_STCNTY_FIPS_CD"="U"."USC_ST_CNTY_CD" AND "C"."DIV_CD"=:B4 AND "C"."CTRY_CD"=:B3 AND
"C"."REC_STATUS"='A')
33 - filter(("B"."UA_CD"='ENDCUST' AND "C"."UCM_MAILBOX_NUM"="B"."UCM_MAILBOX_NUM"))
34 - access("B"."DIV_CD"=:B4 AND "B"."CTRY_CD"=:B3 AND "C"."CUST_NUM"="B"."CUST_NUM" AND
"C"."UCM_SEQ"="B"."UCM_SEQ" AND "B"."UCS_DT">=TO_DATE(:B2,'dd mon yyyy') AND "B"."REC_STATUS"='A' AND
"B"."UCS_DT"<=TO_DATE(:B1,'dd mon yyyy'))
filter("B"."REC_STATUS"='A')
35 - access("A"."DIV_CD"=:B4 AND "A"."CTRY_CD"=:B3 AND "A"."CUST_NUM"="B"."CUST_NUM" AND
"A"."UCM_MAILBOX_NUM"="B"."UCM_MAILBOX_NUM" AND "A"."UCM_SEQ"="B"."UCM_SEQ" AND "A"."UCS_SEQ"="B"."UCS_SEQ")


{color}


{color:blue}


Explain Plan -- 2:


| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | | 3341 (100)| |
|* 1 | HASH JOIN RIGHT OUTER | | 12967 | 2216K| | 3341 (5)| 00:00:41 |
| 2 | VIEW | | 1 | 57 | | 607 (6)| 00:00:08 |
| 3 | HASH GROUP BY | | 1 | 209 | | 607 (6)| 00:00:08 |
|* 4 | FILTER | | | | | | |
|* 5 | TABLE ACCESS BY INDEX ROWID | UCSI_ITEM | 1 | 74 | | 1 (0)| 00:00:01 |
| 6 | NESTED LOOPS | | 1 | 209 | | 606 (6)| 00:00:08 |
| 7 | NESTED LOOPS | | 1 | 135 | | 605 (6)| 00:00:08 |
|* 8 | HASH JOIN | | 1 | 123 | | 604 (6)| 00:00:08 |
|* 9 | TABLE ACCESS BY INDEX ROWID| ULT_CUST_SALE | 1214 | 71626 | | 455 (7)| 00:00:06 |
|* 10 | INDEX SKIP SCAN | XIE1ULT_CUST_SALE | 1 | | | 455 (7)| 00:00:06 |
| 11 | TABLE ACCESS BY INDEX ROWID| ULT_CUST_MASTER | 245 | 12985 | | 17 (0)| 00:00:01 |
| 12 | NESTED LOOPS | | 1971 | 123K| | 148 (2)| 00:00:02 |
|* 13 | TABLE ACCESS FULL | US_STATE_COUNTY | 8 | 88 | | 9 (12)| 00:00:01 |
|* 14 | INDEX RANGE SCAN | TEST | 245 | | | 1 (0)| 00:00:01 |
|* 15 | TABLE ACCESS BY INDEX ROWID | SIC2 | 1 | 12 | | 1 (0)| 00:00:01 |
|* 16 | INDEX UNIQUE SCAN | XPKSIC2 | 1 | | | 1 (0)| 00:00:01 |
|* 17 | INDEX RANGE SCAN | XPKUCSI_ITEM | 1 | | | 1 (0)| 00:00:01 |
| 18 | VIEW | | 12967 | 1494K| | 2732 (5)| 00:00:33 |
| 19 | HASH UNIQUE | | 12967 | 3254K| 6936K| 2732 (5)| 00:00:33 |
|* 20 | HASH JOIN | | 12967 | 3254K| | 1998 (6)| 00:00:24 |
| 21 | VIEW | | 410 | 16400 | | 1781 (5)| 00:00:22 |
| 22 | HASH GROUP BY | | 410 | 13120 | | 1781 (5)| 00:00:22 |
|* 23 | FILTER | | | | | | |
|* 24 | INDEX RANGE SCAN | XIE1ULT_CUST_SALE | 1963K| 59M| | 1781 (5)| 00:00:22 |
|* 25 | HASH JOIN | | 4792 | 1015K| | 215 (7)| 00:00:03 |
|* 26 | TABLE ACCESS FULL | SIC1 | 11 | 528 | | 2 (0)| 00:00:01 |
|* 27 | HASH JOIN | | 4792 | 790K| | 212 (6)| 00:00:03 |
|* 28 | TABLE ACCESS BY INDEX ROWID | CUSTOMER | 1003 | 79237 | | 4 (0)| 00:00:01 |
|* 29 | INDEX RANGE SCAN | XIF317CUSTOMER | 1371 | | | 1 (0)| 00:00:01 |
|* 30 | HASH JOIN | | 4794 | 421K| | 207 (6)| 00:00:03 |
| 31 | TABLE ACCESS BY INDEX ROWID | ULT_CUST_MASTER | 245 | 8820 | | 17 (0)| 00:00:01 |
| 32 | NESTED LOOPS | | 1971 | 136K| | 148 (2)| 00:00:02 |
|* 33 | TABLE ACCESS FULL | US_STATE_COUNTY | 8 | 280 | | 9 (12)| 00:00:01 |
|* 34 | INDEX RANGE SCAN | TEST | 245 | | | 1 (0)| 00:00:01 |
|* 35 | TABLE ACCESS FULL | TURFBUILDER_GROUP2_EMPCNT_TMP | 8914 | 165K| | 58 (14)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("CUST"."CUST_NUM"="CUST_SALE"."CUST_NUM" AND "CUST"."SIC1"="CUST_SALE"."SIC1")
4 - filter(TO_DATE(:B2,'dd mon yyyy')<=TO_DATE(:B1,'dd mon yyyy'))
5 - filter((("A"."UCSII_UNIT_FG"='Y' OR ("A"."UCSII_ITEM_NUM" LIKE '%.%' AND "A"."UCSII_UNIT_FG"='N')) AND
"A"."UCSII_IN_APMR_FG"='Y' AND INTERNAL_FUNCTION("A"."UCSII_CONTRACT_ID") AND "A"."UCSII_AUDIT_DATA_CD"='G' AND
"A"."REC_STATUS"='A'))
8 - access("C"."DIV_CD"="B"."DIV_CD" AND "C"."CTRY_CD"="B"."CTRY_CD" AND "C"."CUST_NUM"="B"."CUST_NUM" AND
"C"."UCM_MAILBOX_NUM"="B"."UCM_MAILBOX_NUM" AND "C"."UCM_SEQ"="B"."UCM_SEQ")
9 - filter("B"."UA_CD"='ENDCUST')
10 - access("B"."DIV_CD"=:B4 AND "B"."CTRY_CD"=:B3 AND "B"."UCS_DT">=TO_DATE(:B2,'dd mon yyyy') AND
"B"."REC_STATUS"='A' AND "B"."UCS_DT"<=TO_DATE(:B1,'dd mon yyyy'))
filter(("B"."UCS_DT">=TO_DATE(:B2,'dd mon yyyy') AND "B"."REC_STATUS"='A' AND "B"."UCS_DT"<=TO_DATE(:B1,'dd
mon yyyy')))
13 - filter((UPPER("U"."USC_STATE_ABBREV")<>'PR' AND UPPER("U"."USC_STATE_ABBREV")<>'VI' AND "U"."REC_STATUS"='A'))
14 - access("C"."UCM_STCNTY_FIPS_CD"="U"."USC_ST_CNTY_CD" AND "C"."DIV_CD"=:B4 AND "C"."CTRY_CD"=:B3 AND
"C"."REC_STATUS"='A')
15 - filter("SC2"."REC_STATUS"='A')
16 - access("SC2"."SIC2"=SUBSTR("C"."UCM_SIC_CD",1,2))
17 - access("A"."DIV_CD"=:B4 AND "A"."CTRY_CD"=:B3 AND "A"."CUST_NUM"="B"."CUST_NUM" AND
"A"."UCM_MAILBOX_NUM"="B"."UCM_MAILBOX_NUM" AND "A"."UCM_SEQ"="B"."UCM_SEQ" AND "A"."UCS_SEQ"="B"."UCS_SEQ")
20 - access("B"."DIV_CD"="UCM"."DIV_CD" AND "B"."CTRY_CD"="UCM"."CTRY_CD" AND "B"."CUST_NUM"="UCM"."CUST_NUM")
23 - filter((:B3=:B3 AND :B4=:B4))
24 - access("DIV_CD"=:B4 AND "CTRY_CD"=:B3 AND "REC_STATUS"='A')
filter(("DIV_CD"=:B4 AND "CTRY_CD"=:B3 AND "DIV_CD"=:B4 AND "CTRY_CD"=:B3 AND "REC_STATUS"='A'))
25 - access("TET_VM_CODE"="SC1"."SIC1")
26 - filter("SC1"."REC_STATUS"='A')
27 - access("F"."DIV_CD"="UCM"."DIV_CD" AND "F"."CTRY_CD"="UCM"."CTRY_CD" AND "F"."CUST_NUM"="UCM"."CUST_NUM")
28 - filter(("F"."DIV_CD"=:B4 AND "F"."CUST_IMP21_DEALER_FG"='Y' AND NVL("F"."CUST_TEST_DEALER_FG",'N')<>'Y'))
29 - access("F"."CTRY_CD"=:B3)
30 - access("TET_CODE"="UCM"."CUST_NUM")
33 - filter((UPPER("U"."USC_STATE_ABBREV")<>'PR' AND UPPER("U"."USC_STATE_ABBREV")<>'VI' AND "U"."REC_STATUS"='A'))
34 - access("UCM"."UCM_STCNTY_FIPS_CD"="U"."USC_ST_CNTY_CD" AND "UCM"."DIV_CD"=:B4 AND "UCM"."CTRY_CD"=:B3 AND
"UCM"."REC_STATUS"='A')
35 - filter("TET_TYPE"='D')


{color}

Slow performance after 10g upgrade

After upgrade from 9.2.0.3.0 to 10.2.0.1.0, the following query runs extremely slow, any suggestion how to adjust the DB settings without re-writing this query
SELECT SUM (ABS (ship_net_clc_amt))
FROM ship_dtl
WHERE order_section_number = '940007320686'
AND SUBSTR (misc_charge_code, 1, 2) IN ('72', '77', 'A9')
AND ics_status_flag2 IN ('W', 'S')
AND dsr_trans_date >= to_date('1/1/2008', 'MM/DD/YYYY')
AND dsr_trans_date < to_date('1/31/2008', 'MM/DD/YYYY')
AND product_base_number NOT IN (SELECT DISTINCT sku
FROM ap_smb_sku_based
WHERE fiscal_period = '200801'
AND country = 'TAIWAN')
AND quota_product_line_code IN (SELECT pl
FROM ap_pl_bu
WHERE bu = '3C')
The exec plan for 10g (optimizer mode = ALL ROWS) is
------------------------------------------------------------------------------------------------------------------------------|
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop ||
------------------------------------------------------------------------------------------------------------------------------|
| 0 | SELECT STATEMENT | | 1 | 49 | 7 (15)| 00:00:01 | | ||
| 1 | SORT AGGREGATE | | 1 | 49 | | | | ||
|* 2 | FILTER | | | | | | | ||
|* 3 | TABLE ACCESS BY LOCAL INDEX ROWID| SHIP_DTL | 1 | 42 | 1 (0)| 00:00:01 | 39 | 39 ||
| 4 | NESTED LOOPS | | 1 | 49 | 5 (20)| 00:00:01 | | ||
| 5 | SORT UNIQUE | | 1 | 7 | 3 (0)| 00:00:01 | | ||
|* 6 | TABLE ACCESS FULL | AP_PL_BU | 1 | 7 | 3 (0)| 00:00:01 | | ||
| 7 | PARTITION RANGE SINGLE | | 3 | | 0 (0)| 00:00:01 | 39 | 39 ||
|* 8 | INDEX RANGE SCAN | IX_SHIP_DTL_ORD_SEC_NM | 3 | | 0 (0)| 00:00:01 | 39 | 39 ||
| 9 | PARTITION RANGE SINGLE | | 1 | 39 | 2 (0)| 00:00:01 | 25 | 25 ||
|* 10 | TABLE ACCESS FULL | AP_SMB_SKU_BASED | 1 | 39 | 2 (0)| 00:00:01 | 25 | 25 ||
------------------------------------------------------------------------------------------------------------------------------|
The exec plan for 9i (optimizer mode=choose) for
----------------------------------------------------------------------------------------------------------------|
| Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop ||
----------------------------------------------------------------------------------------------------------------|
| 0 | SELECT STATEMENT | | 1 | 47 | 10 | | ||
| 1 | SORT AGGREGATE | | 1 | 47 | | | ||
| 2 | FILTER | | | | | | ||
| 3 | HASH JOIN SEMI | | 1 | 47 | 8 | | ||
| 4 | TABLE ACCESS BY LOCAL INDEX ROWID| SHIP_DTL | 1 | 36 | 5 | 13 | 13 ||
| 5 | INDEX RANGE SCAN | IX_SHIP_DTL_ORD_SEC_NR | 9 | | 3 | 13 | 13 ||
| 6 | TABLE ACCESS FULL | AP_PL_BU | 2 | 22 | 2 | | ||
| 7 | TABLE ACCESS FULL | AP_SMB_SKU_BASED | 1 | 21 | 2 | 13 | 13 ||
Thanks.
Liz

ship_dtl has 94690531 records
ap_smb_sku_based has 19 records
ap_plbu has 19 records
The query returns a single row, because it calculates the sum. The query could be better written to get rid of IN or NOT IN which are costly. But I just wonder why the plans/performance are so different?
I used analyze to analyze other tables and it is still working fine in 10g. Now based on the plans, do you think anything wrong ?
10g -
-------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib ||
-------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 0 | SELECT STATEMENT | | 1 | 50 | 10 (-550| 00:00:01 | | | | | ||
| 1 | SORT AGGREGATE | | 1 | 50 | | | | | | | ||
|* 2 | FILTER | | | | | | | | | | ||
|* 3 | PX COORDINATOR | | | | | | | | | | ||
| 4 | PX SEND QC (RANDOM) | :TQ10002 | 1 | 50 | 66 (5)| 00:00:01 | | | Q1,02 | P->S | QC (RAND) ||
|* 5 | FILTER | | | | | | | | Q1,02 | PCWC | ||
| 6 | MERGE JOIN | | 1 | 50 | 66 (5)| 00:00:01 | | | Q1,02 | PCWP | ||
| 7 | SORT JOIN | | 2 | 14 | 4 (50)| 00:00:01 | | | Q1,02 | PCWP | ||
| 8 | BUFFER SORT | | | | | | | | Q1,02 | PCWC | ||
| 9 | PX RECEIVE | | 4 | 28 | 2 (0)| 00:00:01 | | | Q1,02 | PCWP | ||
| 10 | PX SEND HASH | :TQ10000 | 4 | 28 | 2 (0)| 00:00:01 | | | | S->P | HASH ||
| 11 | SORT UNIQUE | | 4 | 28 | 2 (0)| 00:00:01 | | | | | ||
|* 12 | TABLE ACCESS FULL | AP_PL_BU | 4 | 28 | 2 (0)| 00:00:01 | | | | | ||
|* 13 | SORT JOIN | | 1 | 43 | 62 (2)| 00:00:01 | | | Q1,02 | PCWP | ||
| 14 | PX RECEIVE | | 1 | 43 | 61 (0)| 00:00:01 | | | Q1,02 | PCWP | ||
| 15 | PX SEND HASH | :TQ10001 | 1 | 43 | 61 (0)| 00:00:01 | | | Q1,01 | P->P | HASH ||
| 16 | PX PARTITION RANGE ITERATOR | | 1 | 43 | 61 (0)| 00:00:01 | KEY | KEY | Q1,01 | PCWC | ||
|* 17 | TABLE ACCESS BY LOCAL INDEX ROWID| SHIP_DTL | 1 | 43 | 61 (0)| 00:00:01 | KEY | KEY | Q1,01 | PCWP | ||
|* 18 | INDEX RANGE SCAN | IX_SHIP_DTL_ORD_SEC_NR | 14 | | 49 (0)| 00:00:01 | KEY | KEY | Q1,01 | PCWP | ||
| 19 | PARTITION RANGE SINGLE | | 1 | 39 | 2 (0)| 00:00:01 | 14 | 14 | | | ||
|* 20 | TABLE ACCESS FULL | AP_SMB_SKU_BASED | 1 | 39 | 2 (0)| 00:00:01 | 14 | 14 | | | ||
-------------------------------------------------------------------------------------------------------------------------------------------------------------------|Plan for 9i
-----------------------------------------------------------------------------------------------------------------------------------------------|
| Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop | TQ |IN-OUT| PQ Distrib ||
-----------------------------------------------------------------------------------------------------------------------------------------------|
| 0 | SELECT STATEMENT | | 1 | 53 | 74 | | | | | ||
| 1 | SORT AGGREGATE | | 1 | 53 | | | | | | ||
| 2 | FILTER | | | | | | | | | ||
| 3 | FILTER | | | | | | | | | ||
| 4 | HASH JOIN SEMI | | 1 | 53 | 72 | | | 30,01 | P->S | QC (RAND) ||
| 5 | PARTITION RANGE ITERATOR | | | | | KEY | KEY | 30,01 | PCWP | ||
| 6 | TABLE ACCESS BY LOCAL INDEX ROWID| SHIP_DTL | 1 | 42 | 54 | KEY | KEY | 30,01 | PCWP | ||
| 7 | INDEX RANGE SCAN | IX_SHIP_DTL_ORD_SEC_NR | 21 | | 37 | KEY | KEY | 30,01 | PCWP | ||
| 8 | TABLE ACCESS FULL | AP_PL_BU | 2 | 22 | 2 | | | 30,00 | S->P | BROADCAST ||
| 9 | TABLE ACCESS FULL | AP_SMB_SKU_BASED | 1 | 39 | 2 | 14 | 14 | | | ||
-----------------------------------------------------------------------------------------------------------------------------------------------|

Performance of subselect and innerjoins after 10g upgrade

Short Text
Long runtime exist clause in subselect
Long Text
We have started experience very long runtimes after installing Oracle
10g with the following program:
RVV50R10C
There are many different variants stored for this program. After the
Oracle upgrade the variant named: HEP_DRSHP_COMM will not run to
completion. We have observed the following about the job that makes it
unique from the other variants. It is using the Department field in
the selection. When the job started the following SQL statement can be
identified by using SM51 and displaying the jobs details:
SELECT
FROM
"VEPVG" T_00
WHERE
T_00 . "MANDT" = :A0 AND T_00 . "VSTEL" IN
( :A1 , :A2 , :A3 , :A4 , :A5 ) AND T_00 . "LEDAT"
BETWEEN :A6 AND :A7 AND NOT ( T_00 . "LIFSP" BETWEEN :A8 AND :A9 )
AND EXISTS ( SELECT * FROM
"VBKD" T_100 WHERE T_100 . "MANDT" = :A10 AND T_100 . "VBELN" =
T_00 . "VBELN" AND T_100 .
"ABTNR" = :A11 )
The subselect to VBKD is the source of the problem. If an execution
plan is ran against the statement the Oracle explain will show the
following:
Execution Plan
SELECT STATEMENT ( Estimated Costs = 2 , Estimated #Rows = 1 )
7 FILTER
6 NESTED LOOPS SEMI
( Estim. Costs = 2 , Estim. #Rows = 1 )
Estim. CPU-Costs = 14,773 Estim. IO-Costs = 2
3 INLIST ITERATOR
2 TABLE ACCESS BY INDEX ROWID VEPVG
( Estim. Costs = 1 , Estim. #Rows = 1 )
Estim. CPU-Costs = 11,460 Estim. IO-Costs = 1
1 INDEX RANGE SCAN VEPVG~0
( Estim. Costs = 1 , Estim. #Rows = 2 )
Search Columns: 3
Estim. CPU-Costs = 8,351 Estim. IO-Costs = 1
5 TABLE ACCESS BY INDEX ROWID VBKD
Estim. CPU-Costs = 3,313 Estim. IO-Costs = 0
4 INDEX RANGE SCAN VBKD~LOC
Search Columns: 1
Estim. CPU-Costs = 1,504 Estim. IO-Costs = 0
The use of the VBKD~LOC index is causing the poor performance. You can
review our jobs HEP_1101_DAILY, EP_1101_HOMED, HEP_1114_DAILY,
HEP_3114_DAILY which previous to the upgrade their runtime were all
less than 10 mins. These jobs fail to complete.
I would like to also ask about OSS NOTE 841280
This note does not apply to 10g but its description seems very
relevant. Would you recommend setting the parameter alwayssemi_join
= off in this release of Oracle. Is there some other setting? The
execution plan should reflect that VBKD~0 is selected.

Are the clients using JInitiator or their local JRE?

Problem with EBS 11.5.10 after 10g upgrade

hi,
i have upgraded my oracle databse from 9.2.0.5 to 10.2.0.3 , my EBS version is 11.5.10, platform is HP UX 11.11
after sourcing env file on new 10 g home
i ran
perl adbldxml.pl tier=db appsuser=apps appspasswd=pasword
and then
adconfg .sh contextfile=path appspass=password
but it exited with an error
[AutoConfig Error Report]
The following report lists errors AutoConfig encountered during each
phase of its execution. Errors are grouped by directory and phase.
The report format is:
<filename> <phase> <return code where appropriate>
[SETUP PHASE]
AutoConfig could not successfully execute the following scripts:
Directory: /oradvp/ora/proddb/9.2.0/Apache/perl/bin/perl -I /oradvp/ora/proddb/9.2.0/Apache/perl/lib/5.00503 -I /oradvp/ora/proddb/9.2.0/Apache/perl/lib/site_perl/5.005 -I /oradvp/ora/proddb/9.2.0/appsutil/perl -I /oradvp/ora/proddb/10.2.0/appsutil/perl /oradvp/ora/
proddb/10.2.0/appsutil/scripts/DVP_test
adchknls.pl INSTE8_SETUP 1
AutoConfig is exiting with status 1
The log file for this session is located at: /oradvp/ora/proddb/10.2.0/appsutil/log/DVP_test/01201440/adconfig.log
~
~
~
~
~
i checked perl5lib
echo $PERL5LIB
/oradvp/ora/proddb/10.2.0/perl/bin:/oradvp/ora/proddb/10.2.0/perl:/oradvp/ora/proddb/9.2.0/Apache/perl/lib/5.00503:/oradvp/ora/proddb/9.2.0/Apache/perl/lib/site_perl/5.005:/oradvp/ora/proddb/9.2.0/appsutil/perl
echo $PATH
/oradvp/ora/proddb/10.2.0/perl:/oradvp/ora/proddb/10.2.0/bin:/oradvp/ora/proddb/9.2.0/Apache/perl/bin:/oradvp/ora/proddb/9.2.0/bin:/usr/ccs/bin:/usr/sbin:/oradvp/ora/proddb/9.2.0/jre/1.4.2/bin:/usr/bin:/etc:/usr/bin/X11:/usr/local/bin:/opt/bin:/usr/bin:/opt/perl5:/opt/j
ava1.3/bin:/opt/softbench/bin:/usr/bin:/usr/ccs/bin:/usr/contrib/bin:/opt/ansic/bin:/opt/ipf/bin:/opt/hparray/bin:/opt/nettladm/bin:/opt/upgrade/bin:/opt/fcms/bin:/opt/resmon/bin:/opt/pd/bin:/usr/bin/X11:/usr/contrib/bin/X11:/opt/graphics/common/bin:/opt/gnome/bin:/opt/
mozilla:/opt/mx/bin:/opt/ignite/bin:/var/opt/netscape/servers/shared/bin:/var/opt/netscape/servers/bin/slapd/server:/var/opt/netscape/servers/bin:/usr/sbin/diag/contrib:/opt/java1.4/jre/bin:/opt/spb/bin:/opt/wbem/bin:/opt/wbem/sbin:/opt/aCC/bin:/opt/langtools/bin:/opt/i
make/bin:/opt/hpnpl//bin:/opt/sanmgr/commandview/client/sbin:.
$
and when i run this
$ which perl
/oradvp/ora/proddb/9.2.0/Apache/perl/bin/perl
it gives a path of old 9i home , how do i change it
i am not able to see the error
can any one help me with it
Edited by: Adroit77 on Jan 20, 2009 1:55 AM

hello sir,
ur solution worked for me but when i tried upgrading again with patch set 10.2.0.4
during adconfig , it gave the following error
AutoConfig Error Report]
he following report lists errors AutoConfig encountered during each
hase of its execution. Errors are grouped by directory and phase.
he report format is:
<filename> <phase> <return code where appropriate>
[PROFILE PHASE]
AutoConfig could not successfully execute the following scripts:
Directory: /oradvp/ora/proddb/10.2.0/appsutil/install/DVP_test
afdbprf.sh INSTE8_PRF 1
AutoConfig is exiting with status 1
when i ran afdbprf.sh
it gave this error
afdbprf.sh started at Fri Jan 23 18:45:51 IST 2009
The environment settings are as follows ...
ORACLE_HOME : /oradvp/ora/proddb/10.2.0
ORACLE_SID : DVP
PATH : /oradvp/ora/proddb/10.2.0/perl/bin:/oradvp/ora/proddb/10.2.0/perl/bin:/oradvp/ora/proddb/10.2.0/bin:/usr/ccs/bin:/usr/sbin:/oradvp/ora/proddb/10.2.0/jre/1.4.2/bin:/usr/bin:/etc:/usr/bin/X11:/usr/local/bin:/opt/bin:/usr/bin:/opt/perl5:/opt/java1.3/bi
n:/opt/softbench/bin:/usr/bin:/usr/ccs/bin:/usr/contrib/bin:/opt/ansic/bin:/opt/ipf/bin:/opt/hparray/bin:/opt/nettladm/bin:/opt/upgrade/bin:/opt/fcms/bin:/opt/resmon/bin:/opt/pd/bin:/usr/bin/X11:/usr/contrib/bin/X11:/opt/graphics/common/bin:/opt/gnome/bin:/opt/mozilla:/
opt/mx/bin:/opt/ignite/bin:/var/opt/netscape/servers/shared/bin:/var/opt/netscape/servers/bin/slapd/server:/var/opt/netscape/servers/bin:/usr/sbin/diag/contrib:/opt/java1.4/jre/bin:/opt/spb/bin:/opt/wbem/bin:/opt/wbem/sbin:/opt/aCC/bin:/opt/langtools/bin:/opt/imake/bin:
/opt/hpnpl//bin:/opt/sanmgr/commandview/client/sbin:.
LD_LIBRARY_PATH : /oradvp/ora/proddb/10.2.0/lib32:/oradvp/ora/proddb/10.2.0/lib:/usr/dt/lib:/usr/openwin/lib:/oradvp/ora/proddb/10.2.0/ctx/lib
Executable : /oradvp/ora/proddb/10.2.0/bin/sqlplus
SQL*Plus: Release 10.2.0.4.0 - Production on Fri Jan 23 18:45:52 2009
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
ERROR:
ORA-12504: TNS:listener was not given the SID in CONNECT_DATA
ERRORCODE = 1 ERRORCODE_END
but i am able to connect to oracle DB using apps user, how can this be possible??

After 10g Upgrade, Unable to start apps listener.

1. Apps 11.5.10.2 DB 9.2.0.8
2. Successfully upgraded DB to 10.2.0 (Metalink Note: 362203.1)
3. Ran ADCONFIG on DB successfully
4. Ran ADCONFIG on Apps successfully.
5. Restarted Server
All services started successfully except
1. Apps Listener
2. Report Server
3. Concurrent Manager
Further investigation reveals the issue is with Apps Listener. When I start apps listener manually ...
E:\oracle\prodcomn\admin\scripts\PROD_r12srvr>adalnctl start apps/fumble
ECHO is off.
ECHO is off.
Mon 05/12/2008 08:14 PM
ECHO is off.
The environment settings are as follows ...
ECHO is off.
ORACLE_HOME : e:\oracle\prodora2\8.0.6
LOCAL : PROD
ORACLE_SID :
PATH : e:\oracle\prodora2\8.0.6\bin;c:\jdk13\bin;e:\oracle\prodora2\8.0.6\bin;c:\jdk13\bin;e:\oracle\prodappl\au\11.5.0\bin;e:
\oracle\prodappl\fnd\11.5.0\bin;e:\oracle\prodappl\ad\11.5.0\bin;E:\oracle\prodora2\iAS\appsoui\jre\1.3.1\bin;E:\oracle\prodora2\iAS\Apache\
perl\5.00503\bin\MSWin32-x86\;e:\oracle\prodcomn\util\unzip\unzip;e:\oracle\prodora2\8.0.6\bin;c:\jdk13\bin;C:\vscommon\msdev98\BIN;c:\vc8\B
IN;C:\vscommon\TOOLS\WINNT;C:\vscommon\TOOLS;e:\oracle\prodappl\au\11.5.0\bin;e:\oracle\prodappl\fnd\11.5.0\bin;e:\oracle\prodappl\ad\11.5.0
\bin;E:\oracle\prodora2\iAS\appsoui\jre\1.3.1\bin;E:\oracle\prodora2\iAS\Apache\perl\5.00503\bin\MSWin32-x86\;e:\oracle\prodcomn\util\unzip\
unzip;e:\oracle\prodora2\8.0.6\bin;c:\jdk13\bin;C:\MKS\bin\x11;C:\vscommon\Tools\WinNT;C:\vscommon\MSDev98\Bin;C:\vscommon\Tools;c:\vc8\bin;
c:\mks\mksnt;c:\mks\bin;c:\jdk13;c:\r11itools;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;
LD_LIBRARY_PATH : e:\oracle\prodora2\8.0.6\lib
ECHO is off.
ECHO is off.
Starting listener process "APPS_PROD" ...
ECHO is off.
LSNRCTL80 for 32-bit Windows: Version 8.0.6.3.0 - Production on 12-MAY-2008 20:14:58
(c) Copyright 1999 Oracle Corporation. All rights reserved.
Connecting to (ADDRESS=(PROTOCOL=TCP)(Host=r12srvr)(Port=1627))
TNS-12224: TNS:no listener
TNS-12541: TNS:no listener
TNS-12560: TNS:protocol adapter error
TNS-00511: No listener
32-bit Windows Error: 61: Unknown error
LSNRCTL80 for 32-bit Windows: Version 8.0.6.3.0 - Production on 12-MAY-2008 20:15:00
(c) Copyright 1999 Oracle Corporation. All rights reserved.
Starting tnslsnr80: please wait...
Service OraclePRODOra806_3TNSListener80APPS_PROD start pending.
Service OraclePRODOra806_3TNSListener80APPS_PROD started.
TNS-12560: TNS:protocol adapter error
adalnctl.cmd exiting with status 3
The error 3 means "The system cannot find the path specified".
Anyone! Please help me. It is very very urgent.
Thanks in advance.
S. Sundar

This is Oracle Apps. Did you check all requirements before upgrading only the database layer to 10g?
You may need to change your start/stop scripts to reflect the changes to the database layer (listener ports etc).
E-Business Suite Forum?
http://forums.oracle.com/forums/category.jspa?categoryID=3

Performance issue with form after 10g upgrade

Hi Team,
Last week we have upgraded our systems to 10g database.
Ever since we did an upgrade there is a huge performance issues with the custom forms and this is causing a major setback to our business. Before the upgrade the forms were running with our any performance issues.
Can anyone please help me in finding out the reason behind the performance issue(May be a tar or performance tuning).
Many Thanks in Advance.
Regards
Kumar

Like Jan said,
You must supply more information so we can help you, like where the degradation happens?, in processing? in navigation? in forms loading?? where?
You may also do a little test. Create a one button form, just a canvas and a button, you can include a message in when-button-pressed trigger.
run it and see what happens.
Tony

Managers not running after 10g upgrade

hi,
recently i upgraded my databse from 9.2.0.5 to 10.2.0.3
i followed all the steps correctly to upgrade database but managers are not getting up
my EBS version is 11.5.10.2 . and OS is HP UX 11.11
Edited by: MeakinS on Sep 11, 2008 12:21 PM

Meakin,
Do the following:
$ adcmctl.sh stop apps/<appspwd>
Make sure there's no FNDLIBR process.Give it couple of mins to clear all the FNDLIBR processes. To check that, do the following:
ps -ef|grep -i fndlibr
Once these processes are down. Run cmclean.sql, Please find the script in the note given by Hussein.
$ sqlplus apps/apps @cmclean.sql.
You need to issue commit, once the script is done.
Then start the CM, using adcmctl.sh start apps/apps
Do check the log file for any errors. Though you see a exit code "0", it's always a good practise to check the logfiles. If you find any errors in the logfile, do update us. If not, Run Auto-config and re-try.

Heavu CPU Utilization of Dictionary Query - After 9i to 10g Upgrade

Hi Friends,
We have migrated our production DB from Oracle 9i(Windows) to Oracle 10g(AIX) and after that a heavy cpu utilization query is coming frequently and hence many timeouts are happening in the application.
Application is connecting to the database through Java Application (JDBC).
Once the application service is started, below query is invoked and CPU takes around 20% continuously.
The interesting thing is this query is not owned by the application schema but by SYS and it's invoked from Application Schema.
We have raised an SR but still no luck.
Any help will be very much appreciated.
SELECT -- Packaged procedures with no arguments package_name AS procedu
re_cat, owner AS procedure_schem, object_name AS procedure_name, NULL
, NULL, NULL, 'Packaged procedure' AS remarks, 1 AS procedure_type
FROM all_arguments WHERE argument_name IS NULL AND data_type IS NULL AN
D package_name LIKE :3 ESCAPE '/' AND owner LIKE :4 ESCAPE '/' AND obje
ct_name LIKE :5 ESCAPE '/' UNION ALL SELECT -- Packaged procedures with a
rguments package_name AS procedure_cat, owner AS procedure_schem, obj
ect_name AS procedure_name, NULL, NULL, NULL, 'Packaged procedure'
AS remarks, 1 AS procedure_type FROM all_arguments WHERE argument_name IS
NOT NULL AND position = 1 AND position = sequence AND package_name L
IKE :3 ESCAPE '/' AND owner LIKE :4 ESCAPE '/' AND object_name LIKE :5
ESCAPE '/' UNION ALL SELECT -- Packaged functions package_name AS proce
dure_cat, owner AS procedure_schem, object_name AS procedure_name, NU
LL, NULL, NULL, 'Pa
Regards,
Savad

Pl do not post duplicate threads - Heavy CPU Utilization of Dictionary Query - After 9i to 10g Upgrade
Srini

Join Issues After 4i to 10g Upgrade

Hi,
We have noticed issues with folder joins after upgrading from 4i to 10g. These joins existed and worked as expected in 4i. But after the upgrade to 10g, reports will pull all data instead of limiting to the parameters.
For example, we have a order headers folder and invoice headers folder in a business area created from the database. The 2 folders have a join. If I create a report that pulls columns from both folders and then create parameters to limit the invoice creation date, it will pull all records from the database instead of limiting to the parameters.
Has anyone else experienced this issue? Can someone point me to some documentation that relates to the issue?
Any help is greatly appreciated!
Thanks,
Troy

Hi Troy,
I seem to remember that there is a difference in how 4i and 10g handle outer joins. There is also an issue associated with applying joins to different types of folders. Please send me a copy of the SQL generated from the "view SQL" function for this worksheet and I'll try to help you debug the issue. It would also be helpful if you could do this for 4i also.
--Srinu

Check Writer Hangs after 10G database upgrade

Hi Gurus,
Can anybody let me know how i can trace check writer concurrent process.
It seems to hang after we upgraded the database to 10g version.
Thanks,
S.

The log file shows
/u31/oracle/fimsprodappl/pay/11.5.0/bin/PYUGEN
Program was terminated by signal 11
Should i do some thing with PYUGEN (rebuild/relink) after 10G database upgrade.
We are on HP-UX 11 (PA-RISC) 64 bit.
S

Perfomance Issue after Database Upgrade in 11i

Hi All,
We upgraded database from 9.2.0.5 to 10.2.0.4, the system was running fine. One month after upgrade we changed the compatibility from 9.2.0 to 10.2.0 for compatibilty and optimizers. Since then perfomance is poor for self service and PTO carry over is taking more then 10 hours, earlier which completes in 1:15 min to 1:30 min. I logged a SR and following with Oracle Support.
Are there any _"Best Practices"_ to be followed after database upgrade from 9i to 10g in 11.5.10.2.
All the database parameters has been set as recommeded by metalink note:216205.1
How frequently gather schema statistics should be run on production?
Thnaks in Advance for help.

Are there any _"Best Practices"_ to be followed after database upgrade from 9i to 10g in 11.5.10.2.
All the database parameters has been set as recommended by metalink note:216205.1
The best practice is to adjust initialization parameters as per the note referenced above.
In addition, review the following note carefully:
Note: 744143.1 - Tuning performance on eBusiness suite
https://metalink2.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=744143.1
How frequently gather schema statistics should be run on production?Note: 168136.1 - How Often Should Gather Schema Statistics Program be Run?
https://metalink2.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=168136.1

9i 10g upgrade execution plan differences.

Hi all,
I am tring to find execution plan differences after I upgrade production system from 9i to 10gR2. So I have restored only needed tablespaces from my production system (9i) to a new machine and then upgraded thiat Oracle server to 10GR2. At this new server I run a script to get new execution plans of 10g. What suprises me is that query plans of 10g is different and most of new plans choose to access tables via indexes instead of full table scans stated in the original plans taken from 9i. My idea about those differences is that the optimizer takes some values for its cost formula from other system tables that I do not have in 10g server.I guess I am missing something which is not documented in upgrade book.
any idea?
Regards.

9i database is my production database and I regularly run cron jobs for missing or stale statistics on all tables. So there is no possibility to hit a problem on object level statistics. I guess that I am missing something about system level statistics which are the part of the formula (single block read time etc) for cost calculating. So I tried to use setting some statastics via dbms_stat.set_system_statistics procedure, but it did not work.
Any idea?
Regards.
ALPER ÖNEY

Statistics gather after 10g upgrade

Similar Messages

Maybe you are looking for