Perf issue : wrong choice of index
Hi,
I'm on 10.2.0.4, AIX5.3
Statistics have been gathered, they are up-to-date.
I have a query which run for several hours, here is the query :
UPDATE ps_AB_PDI_CN_TAO_TMP
SET country_2char = COALESCE((
SELECT c.COUNTRY_2CHAR
FROM PSOPRDEFN o
, PS_JOB j
, PS_LOCATION_TBL l
, PS_COUNTRY_TBL c
WHERE j.EMPLID = o.EMPLID
AND j.EFFDT = (SELECT MAX(j1.EFFDT)
FROM PS_JOB j1
WHERE j1.EMPLID = j.EMPLID
AND j1.EMPL_RCD = j.EMPL_RCD
AND j1.EFFDT <= sysdate)
AND j.EFFSEQ = (SELECT MAX(j2.EFFSEQ)
FROM PS_JOB j2
WHERE j2.EMPLID = j.EMPLID
AND j2.EMPL_RCD = j.EMPL_RCD
AND j2.EFFDT = j.EFFDT)
AND j.EMPL_RCD = (SELECT MAX(js.EMPL_RCD)
FROM PS_JOB js
WHERE js.EMPLID = j.EMPLID
AND js.EFFDT = (SELECT MAX(js1.EFFDT)
FROM PS_JOB js1
WHERE js1.EMPLID = js.EMPLID
AND js1.EMPL_RCD = js.EMPL_RCD
AND js1.EFFDT <= sysdate)
AND js.EFFSEQ = (SELECT MAX(js2.EFFSEQ)
FROM PS_JOB js2
WHERE js2.EMPLID = js.EMPLID
AND js2.EMPL_RCD = js.EMPL_RCD
AND js2.EFFDT = js.EFFDT))
AND l.SETID = j.SETID_LOCATION
AND l.LOCATION = j.LOCATION
AND l.EFFDT = (SELECT MAX(l1.EFFDT)
FROM PS_LOCATION_TBL l1
WHERE l1.SETID = l.SETID
AND l1.LOCATION = l.LOCATION
AND l1.EFFDT <= j.EFFDT)
AND l.EFF_STATUS = 'A'
AND c.COUNTRY = l.COUNTRY
AND o.oprid = ps_AB_PDI_CN_TAO_TMP.OPRID),' ' )
WHERE COUNTRY_2CHAR = ' ';Explain plan is the following :
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | UPDATE STATEMENT | | 1 | 52 | 45 (3)| 00:00:01 |
| 1 | UPDATE | PS_AB_PDI_CN_TAO_TMP | | | | |
|* 2 | TABLE ACCESS FULL | PS_AB_PDI_CN_TAO_TMP | 1 | 52 | 45 (3)| 00:00:01 |
| 3 | NESTED LOOPS | | 1 | 80 | 8 (0)| 00:00:01 |
| 4 | NESTED LOOPS | | 1 | 73 | 7 (0)| 00:00:01 |
| 5 | NESTED LOOPS | | 1 | 48 | 5 (0)| 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID | PSOPRDEFN | 1 | 15 | 2 (0)| 00:00:01 |
|* 7 | INDEX UNIQUE SCAN | PS_PSOPRDEFN | 1 | | 1 (0)| 00:00:01 |
| 8 | TABLE ACCESS BY INDEX ROWID | PS_JOB | 1 | 33 | 3 (0)| 00:00:01 |
|* 9 | INDEX RANGE SCAN | PS_JOB | 1 | | 2 (0)| 00:00:01 |
| 10 | SORT AGGREGATE | | 1 | 19 | | |
| 11 | FIRST ROW | | 14 | 266 | 3 (0)| 00:00:01 |
|* 12 | INDEX RANGE SCAN (MIN/MAX) | PSAJOB | 14 | 266 | 3 (0)| 00:00:01 |
| 13 | SORT AGGREGATE | | 1 | 22 | | |
| 14 | FIRST ROW | | 1 | 22 | 3 (0)| 00:00:01 |
|* 15 | INDEX RANGE SCAN (MIN/MAX) | PSAJOB | 1 | 22 | 3 (0)| 00:00:01 |
| 16 | SORT AGGREGATE | | 1 | 22 | | |
| 17 | FIRST ROW | | 1 | 22 | 7 (58)| 00:00:01 |
|* 18 | INDEX FULL SCAN (MIN/MAX) | PSIJOB | 1 | 22 | 7 (58)| 00:00:01 |
| 19 | SORT AGGREGATE | | 1 | 19 | | |
| 20 | FIRST ROW | | 14 | 266 | 3 (0)| 00:00:01 |
|* 21 | INDEX RANGE SCAN (MIN/MAX) | PSAJOB | 14 | 266 | 3 (0)| 00:00:01 |
| 22 | SORT AGGREGATE | | 1 | 22 | | |
| 23 | FIRST ROW | | 1 | 22 | 3 (0)| 00:00:01 |
|* 24 | INDEX RANGE SCAN (MIN/MAX)| PSAJOB | 1 | 22 | 3 (0)| 00:00:01 |
|* 25 | TABLE ACCESS BY INDEX ROWID | PS_LOCATION_TBL | 1 | 25 | 2 (0)| 00:00:01 |
|* 26 | INDEX RANGE SCAN | PS_LOCATION_TBL | 1 | | 1 (0)| 00:00:01 |
| 27 | SORT AGGREGATE | | 1 | 19 | | |
| 28 | FIRST ROW | | 1 | 19 | 2 (0)| 00:00:01 |
|* 29 | INDEX RANGE SCAN (MIN/MAX) | PS_LOCATION_TBL | 1 | 19 | 2 (0)| 00:00:01 |
| 30 | TABLE ACCESS BY INDEX ROWID | PS_COUNTRY_TBL | 1 | 7 | 1 (0)| 00:00:01 |
|* 31 | INDEX UNIQUE SCAN | PS_COUNTRY_TBL | 1 | | 0 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter("COUNTRY_2CHAR"=' ')
7 - access("O"."OPRID"=:B1)
9 - access("J"."EMPLID"="O"."EMPLID")
filter("J"."EFFDT"= (SELECT MAX("J1"."EFFDT") FROM "PS_JOB" "J1" WHERE "J1"."EFFDT"<=SYSDATE@! AND
"J1"."EMPL_RCD"=:B1 AND "J1"."EMPLID"=:B2) AND "J"."EFFSEQ"= (SELECT MAX("J2"."EFFSEQ") FROM "PS_JOB" "J2"
WHERE "J2"."EFFDT"=:B3 AND "J2"."EMPL_RCD"=:B4 AND "J2"."EMPLID"=:B5) AND "J"."EMPL_RCD"= (SELECT
MAX("JS"."EMPL_RCD") FROM "PS_JOB" "SYS_ALIAS_5" WHERE "JS"."EMPLID"=:B6 AND "JS"."EFFDT"= (SELECT
MAX("JS1"."EFFDT") FROM "PS_JOB" "JS1" WHERE "JS1"."EFFDT"<=SYSDATE@! AND "JS1"."EMPL_RCD"=:B7 AND
"JS1"."EMPLID"=:B8) AND "JS"."EFFSEQ"= (SELECT MAX("JS2"."EFFSEQ") FROM "PS_JOB" "JS2" WHERE "JS2"."EFFDT"=:B9
AND "JS2"."EMPL_RCD"=:B10 AND "JS2"."EMPLID"=:B11)))
12 - access("J1"."EMPLID"=:B1 AND "J1"."EMPL_RCD"=:B2 AND "J1"."EFFDT"<=SYSDATE@!)
15 - access("J2"."EMPLID"=:B1 AND "J2"."EMPL_RCD"=:B2 AND "J2"."EFFDT"=:B3)
18 - filter("JS"."EMPLID"=:B1 AND "JS"."EFFDT"= (SELECT MAX("JS1"."EFFDT") FROM "PS_JOB" "JS1" WHERE
"JS1"."EFFDT"<=SYSDATE@! AND "JS1"."EMPL_RCD"=:B2 AND "JS1"."EMPLID"=:B3) AND "JS"."EFFSEQ"= (SELECT
MAX("JS2"."EFFSEQ") FROM "PS_JOB" "JS2" WHERE "JS2"."EFFDT"=:B4 AND "JS2"."EMPL_RCD"=:B5 AND
"JS2"."EMPLID"=:B6))
21 - access("JS1"."EMPLID"=:B1 AND "JS1"."EMPL_RCD"=:B2 AND "JS1"."EFFDT"<=SYSDATE@!)
24 - access("JS2"."EMPLID"=:B1 AND "JS2"."EMPL_RCD"=:B2 AND "JS2"."EFFDT"=:B3)
25 - filter("L"."EFF_STATUS"='A')
26 - access("L"."SETID"="J"."SETID_LOCATION" AND "L"."LOCATION"="J"."LOCATION")
filter("L"."EFFDT"= (SELECT MAX("L1"."EFFDT") FROM "PS_LOCATION_TBL" "L1" WHERE "L1"."EFFDT"<=:B1 AND
"L1"."LOCATION"=:B2 AND "L1"."SETID"=:B3))
29 - access("L1"."SETID"=:B1 AND "L1"."LOCATION"=:B2 AND "L1"."EFFDT"<=:B3)
31 - access("C"."COUNTRY"="L"."COUNTRY")The line 18 looks weird, the index PSIJOB should not be used, but, according to the columns used in the query and the indexes definitions it should be PSAJOB instead.
Here the indexes definition :
PS_JOB PSAJOB EMPLID 1
PS_JOB PSAJOB EMPL_RCD 2
PS_JOB PSAJOB EFFDT 3
PS_JOB PSAJOB EFFSEQ 4
PS_JOB PSAJOB DEPTID 5
PS_JOB PSIJOB EMPL_RCD 1
PS_JOB PSIJOB REG_REGION 2
PS_JOB PSIJOB PAYGROUP 3
PS_JOB PSIJOB COMPANY 4
PS_JOB PSIJOB EMPL_STATUS 5
PS_JOB PSIJOB AB_APPR_STATUS 6
PS_JOB PSIJOB EFFDT 7
PS_JOB PSIJOB EFFSEQ 8
PS_JOB PSIJOB EMPLID 9If I drop the PSIJOB index, PSAJOB is used and query run in few minutes.
And here the explain plan if I drop this index :
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | UPDATE STATEMENT | | 1 | 52 | 45 (3)| 00:00:01 |
| 1 | UPDATE | PS_AB_PDI_CN_TAO_TMP | | | | |
|* 2 | TABLE ACCESS FULL | PS_AB_PDI_CN_TAO_TMP | 1 | 52 | 45 (3)| 00:00:01 |
| 3 | NESTED LOOPS | | 1 | 80 | 8 (0)| 00:00:01 |
| 4 | NESTED LOOPS | | 1 | 73 | 7 (0)| 00:00:01 |
| 5 | NESTED LOOPS | | 1 | 48 | 5 (0)| 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID | PSOPRDEFN | 1 | 15 | 2 (0)| 00:00:01 |
|* 7 | INDEX UNIQUE SCAN | PS_PSOPRDEFN | 1 | | 1 (0)| 00:00:01 |
| 8 | TABLE ACCESS BY INDEX ROWID | PS_JOB | 1 | 33 | 3 (0)| 00:00:01 |
|* 9 | INDEX RANGE SCAN | PS_JOB | 1 | | 2 (0)| 00:00:01 |
| 10 | SORT AGGREGATE | | 1 | 19 | | |
| 11 | FIRST ROW | | 14 | 266 | 3 (0)| 00:00:01 |
|* 12 | INDEX RANGE SCAN (MIN/MAX) | PSAJOB | 14 | 266 | 3 (0)| 00:00:01 |
| 13 | SORT AGGREGATE | | 1 | 22 | | |
| 14 | FIRST ROW | | 1 | 22 | 3 (0)| 00:00:01 |
|* 15 | INDEX RANGE SCAN (MIN/MAX) | PSAJOB | 1 | 22 | 3 (0)| 00:00:01 |
| 16 | SORT AGGREGATE | | 1 | 22 | | |
| 17 | FIRST ROW | | 1 | 22 | 7 (58)| 00:00:01 |
|* 18 | INDEX RANGE SCAN (MIN/MAX) | PSAJOB | 1 | 22 | 7 (58)| 00:00:01 |
| 19 | SORT AGGREGATE | | 1 | 19 | | |
| 20 | FIRST ROW | | 14 | 266 | 3 (0)| 00:00:01 |
|* 21 | INDEX RANGE SCAN (MIN/MAX) | PSAJOB | 14 | 266 | 3 (0)| 00:00:01 |
| 22 | SORT AGGREGATE | | 1 | 22 | | |
| 23 | FIRST ROW | | 1 | 22 | 3 (0)| 00:00:01 |
|* 24 | INDEX RANGE SCAN (MIN/MAX)| PSAJOB | 1 | 22 | 3 (0)| 00:00:01 |
|* 25 | TABLE ACCESS BY INDEX ROWID | PS_LOCATION_TBL | 1 | 25 | 2 (0)| 00:00:01 |
|* 26 | INDEX RANGE SCAN | PS_LOCATION_TBL | 1 | | 1 (0)| 00:00:01 |
| 27 | SORT AGGREGATE | | 1 | 19 | | |
| 28 | FIRST ROW | | 1 | 19 | 2 (0)| 00:00:01 |
|* 29 | INDEX RANGE SCAN (MIN/MAX) | PS_LOCATION_TBL | 1 | 19 | 2 (0)| 00:00:01 |
| 30 | TABLE ACCESS BY INDEX ROWID | PS_COUNTRY_TBL | 1 | 7 | 1 (0)| 00:00:01 |
|* 31 | INDEX UNIQUE SCAN | PS_COUNTRY_TBL | 1 | | 0 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter("COUNTRY_2CHAR"=' ')
7 - access("O"."OPRID"=:B1)
9 - access("J"."EMPLID"="O"."EMPLID")
filter("J"."EFFDT"= (SELECT MAX("J1"."EFFDT") FROM "PS_JOB" "J1" WHERE "J1"."EFFDT"<=SYSDATE@! AND
"J1"."EMPL_RCD"=:B1 AND "J1"."EMPLID"=:B2) AND "J"."EFFSEQ"= (SELECT MAX("J2"."EFFSEQ") FROM "PS_JOB" "J2"
WHERE "J2"."EFFDT"=:B3 AND "J2"."EMPL_RCD"=:B4 AND "J2"."EMPLID"=:B5) AND "J"."EMPL_RCD"= (SELECT
MAX("JS"."EMPL_RCD") FROM "PS_JOB" "SYS_ALIAS_5" WHERE "JS"."EMPLID"=:B6 AND "JS"."EFFDT"= (SELECT
MAX("JS1"."EFFDT") FROM "PS_JOB" "JS1" WHERE "JS1"."EFFDT"<=SYSDATE@! AND "JS1"."EMPL_RCD"=:B7 AND
"JS1"."EMPLID"=:B8) AND "JS"."EFFSEQ"= (SELECT MAX("JS2"."EFFSEQ") FROM "PS_JOB" "JS2" WHERE "JS2"."EFFDT"=:B9
AND "JS2"."EMPL_RCD"=:B10 AND "JS2"."EMPLID"=:B11)))
12 - access("J1"."EMPLID"=:B1 AND "J1"."EMPL_RCD"=:B2 AND "J1"."EFFDT"<=SYSDATE@!)
15 - access("J2"."EMPLID"=:B1 AND "J2"."EMPL_RCD"=:B2 AND "J2"."EFFDT"=:B3)
18 - access("JS"."EMPLID"=:B1)
filter("JS"."EFFDT"= (SELECT MAX("JS1"."EFFDT") FROM "PS_JOB" "JS1" WHERE "JS1"."EFFDT"<=SYSDATE@! AND
"JS1"."EMPL_RCD"=:B1 AND "JS1"."EMPLID"=:B2) AND "JS"."EFFSEQ"= (SELECT MAX("JS2"."EFFSEQ") FROM "PS_JOB"
"JS2" WHERE "JS2"."EFFDT"=:B3 AND "JS2"."EMPL_RCD"=:B4 AND "JS2"."EMPLID"=:B5))
21 - access("JS1"."EMPLID"=:B1 AND "JS1"."EMPL_RCD"=:B2 AND "JS1"."EFFDT"<=SYSDATE@!)
24 - access("JS2"."EMPLID"=:B1 AND "JS2"."EMPL_RCD"=:B2 AND "JS2"."EFFDT"=:B3)
25 - filter("L"."EFF_STATUS"='A')
26 - access("L"."SETID"="J"."SETID_LOCATION" AND "L"."LOCATION"="J"."LOCATION")
filter("L"."EFFDT"= (SELECT MAX("L1"."EFFDT") FROM "PS_LOCATION_TBL" "L1" WHERE "L1"."EFFDT"<=:B1 AND
"L1"."LOCATION"=:B2 AND "L1"."SETID"=:B3))
29 - access("L1"."SETID"=:B1 AND "L1"."LOCATION"=:B2 AND "L1"."EFFDT"<=:B3)
31 - access("C"."COUNTRY"="L"."COUNTRY")As you can see, the cost is exactly same for the line 18, however it is using a different index and scan.
Do you have any explanation why Oracle is using PSIJOB instead of PSAJOB in first case ?
How Oracle could prefer a INDEX FULL SCAN than INDEX RANGE SCAN (PS_JOB is a 3.3 millions rows table) ?
Lastly, here an extract of the trace 10053 file when PSIJOB is used :
QUERY BLOCK TEXT
SELECT MAX(js.EMPL_RCD)
FROM PS_JOB js
WHERE js.EMPLID = j.EMPLID
AND js.EFFDT = (SELECT MAX(js1.EFFDT)
FROM PS_JOB js1
WHERE js1.EMPLID = js.EMPLID
AND js1.EMPL_RCD = js.EMPL_RCD
AND js1.EFFDT <= sysdate)
AND js.EFFSEQ = (SELECT MAX(js2.EFFSEQ)
FROM PS_JOB js2
WHERE js2.EMPLID = js.EMPLID
AND js2.EMPL_RCD = js.EMPL_RCD
AND js2.EFFDT = js.EFFDT)
Index Stats::
Index: PSAJOB Col#: 1 2 3 4 5
LVLS: 2 #LB: 16434 #DK: 3155830 LB/K: 1.00 DB/K: 1.00 CLUF: 3020072.00
Index: PSIJOB Col#: 2 72 23 22 10 229 3 4 1
LVLS: 2 #LB: 21287 #DK: 3303072 LB/K: 1.00 DB/K: 1.00 CLUF: 3035026.00
SINGLE TABLE ACCESS PATH
BEGIN Single Table Cardinality Estimation
Column (#1): EMPLID(VARCHAR2)
AvgLen: 8.00 NDV: 116590 Nulls: 0 Density: 8.5771e-06
Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 255
Column (#3): EFFDT(DATE)
AvgLen: 8.00 NDV: 2085 Nulls: 0 Density: 2.6799e-04 Min: 2415386 Max: 2455585
Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 183
Column (#2): EMPL_RCD(NUMBER)
AvgLen: 3.00 NDV: 2 Nulls: 0 Density: 0.0026359 Min: 0 Max: 1
Histogram: Freq #Bkts: 2 UncompBkts: 5501 EndPtVals: 2
Column (#4): EFFSEQ(NUMBER)
AvgLen: 3.00 NDV: 5 Nulls: 0 Density: 9.0893e-05 Min: 0 Max: 4
Histogram: Freq #Bkts: 5 UncompBkts: 5501 EndPtVals: 5
Table: PS_JOB Alias: SYS_ALIAS_5
Card: Original: 3282026 Rounded: 28 Computed: 28.15 Non Adjusted: 28.15
END Single Table Cardinality Estimation
Access Path: index (index (FFS))
Index: PSAJOB
resc_io: 2848.00 resc_cpu: 653526199
ix_sel: 0.0000e+00 ix_sel_with_filters: 1
Access Path: index (FFS)
Cost: 3306.55 Resp: 3306.55 Degree: 1
Cost_io: 2848.00 Cost_cpu: 653526199
Resp_io: 2848.00 Resp_cpu: 653526199
Access Path: index (index (FFS))
Index: PSIJOB
resc_io: 3688.00 resc_cpu: 713117750
ix_sel: 0.0000e+00 ix_sel_with_filters: 1
Access Path: index (FFS)
Cost: 4188.36 Resp: 4188.36 Degree: 1
Cost_io: 3688.00 Cost_cpu: 713117750
Resp_io: 3688.00 Resp_cpu: 713117750
Access Path: index (Min/Max)
Index: PSAJOB
resc_io: 3.00 resc_cpu: 21564
ix_sel: 0.035714 ix_sel_with_filters: 0.035714
Cost: 7.13 Resp: 7.13 Degree: 1
Access Path: index (Min/Max)
Index: PSIJOB
resc_io: 3.00 resc_cpu: 21564
ix_sel: 0.035714 ix_sel_with_filters: 0.035714
Cost: 7.13 Resp: 7.13 Degree: 1
Best:: AccessPath: IndexRange Index: PSIJOB
Cost: 7.13 Degree: 1 Resp: 7.13 Card: 28.15 Bytes: 0
Card adjusted, Rounded Card: 1 Computed Card: 0.00
...Thanks.
I don't know if you are interested, but I did the following test, and I get a new explain plan :
SQL> alter session set optimizer_features_enable='9.2.0';
Session altered.
SQL>
SQL> DECLARE
2 my_task_name VARCHAR2(30);
3 my_sqltext CLOB;
4 BEGIN
5 my_sqltext := 'UPDATE ps_AB_PDI_CN_TAO_TMP
6 SET country_2char = COALESCE((
7 SELECT c.COUNTRY_2CHAR
8 FROM PSOPRDEFN o
9 , PS_JOB j
10 , PS_LOCATION_TBL l
11 , PS_COUNTRY_TBL c
12 WHERE j.EMPLID = o.EMPLID
13 AND j.EFFDT = (SELECT MAX(j1.EFFDT)
14 FROM PS_JOB j1
15 WHERE j1.EMPLID = j.EMPLID
16 AND j1.EMPL_RCD = j.EMPL_RCD
17 AND j1.EFFDT <= sysdate)
18 AND j.EFFSEQ = (SELECT MAX(j2.EFFSEQ)
19 FROM PS_JOB j2
20 WHERE j2.EMPLID = j.EMPLID
21 AND j2.EMPL_RCD = j.EMPL_RCD
22 AND j2.EFFDT = j.EFFDT)
23 AND j.EMPL_RCD = (SELECT MAX(js.EMPL_RCD)
24 FROM PS_JOB js
25 WHERE js.EMPLID = j.EMPLID
26 AND js.EFFDT = (SELECT MAX(js1.EFFDT)
27 FROM PS_JOB js1
28 WHERE js1.EMPLID = js.EMPLID
29 AND js1.EMPL_RCD = js.EMPL_RCD
30 AND js1.EFFDT <= sysdate)
31 AND js.EFFSEQ = (SELECT MAX(js2.EFFSEQ)
32 FROM PS_JOB js2
33 WHERE js2.EMPLID = js.EMPLID
34 AND js2.EMPL_RCD = js.EMPL_RCD
35 AND js2.EFFDT = js.EFFDT))
36 AND l.SETID = j.SETID_LOCATION
37 AND l.LOCATION = j.LOCATION
38 AND l.EFFDT = (SELECT MAX(l1.EFFDT)
39 FROM PS_LOCATION_TBL l1
40 WHERE l1.SETID = l.SETID
41 AND l1.LOCATION = l.LOCATION
42 AND l1.EFFDT <= j.EFFDT)
43 AND l.EFF_STATUS = ''A''
44 AND c.COUNTRY = l.COUNTRY
45 AND o.oprid = ps_AB_PDI_CN_TAO_TMP.OPRID),'' '' )
46 WHERE COUNTRY_2CHAR = '' ''';
47 my_task_name := DBMS_SQLTUNE.CREATE_TUNING_TASK(
48 sql_text => my_sqltext,
49 user_name => 'SYSADM',
50 scope => 'COMPREHENSIVE',
51 time_limit => 3600,
52 task_name => 'sysadm_avoid_psijob',
53 description => 'Task to avoid PSIJOB index on update - PDI');
54 END;
55 /
PL/SQL procedure successfully completed.
SQL>
SQL> BEGIN
2 DBMS_SQLTUNE.EXECUTE_TUNING_TASK( task_name => 'sysadm_avoid_psijob');
3 end;
4 /
PL/SQL procedure successfully completed.
SQL>
SQL> SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK( 'sysadm_avoid_psijob') from DUAL;
GENERAL INFORMATION SECTION
Tuning Task Name : sysadm_avoid_psijob
Tuning Task Owner : SYSADM
Scope : COMPREHENSIVE
Time Limit(seconds) : 3600
Completion Status : COMPLETED
Started at : 07/03/2009 20:35:36
Completed at : 07/03/2009 20:38:40
Number of Statistic Findings : 1
Number of SQL Profile Findings : 1
Schema Name: SYSADM
SQL ID : 7xcbcszgj1znc
SQL Text : UPDATE ps_AB_PDI_CN_TAO_TMP
SET country_2char = COALESCE((
SELECT c.COUNTRY_2CHAR
FROM PSOPRDEFN o
, PS_JOB j
, PS_LOCATION_TBL l
, PS_COUNTRY_TBL c
WHERE j.EMPLID = o.EMPLID
AND j.EFFDT = (SELECT MAX(j1.EFFDT)
FROM PS_JOB j1
WHERE j1.EMPLID = j.EMPLID
AND j1.EMPL_RCD = j.EMPL_RCD
AND j1.EFFDT <= sysdate)
AND j.EFFSEQ = (SELECT MAX(j2.EFFSEQ)
FROM PS_JOB j2
WHERE j2.EMPLID = j.EMPLID
AND j2.EMPL_RCD = j.EMPL_RCD
AND j2.EFFDT = j.EFFDT)
AND j.EMPL_RCD = (SELECT MAX(js.EMPL_RCD)
FROM PS_JOB js
WHERE js.EMPLID = j.EMPLID
AND js.EFFDT = (SELECT MAX(js1.EFFDT)
FROM PS_JOB js1
WHERE js1.EMPLID = js.EMPLID
AND js1.EMPL_RCD = js.EMPL_RCD
AND js1.EFFDT <= sysdate)
AND js.EFFSEQ = (SELECT MAX(js2.EFFSEQ)
FROM PS_JOB js2
WHERE js2.EMPLID = js.EMPLID
AND js2.EMPL_RCD =
js.EMPL_RCD
AND js2.EFFDT = js.EFFDT))
AND l.SETID = j.SETID_LOCATION
AND l.LOCATION = j.LOCATION
AND l.EFFDT = (SELECT MAX(l1.EFFDT)
FROM PS_LOCATION_TBL l1
WHERE l1.SETID = l.SETID
AND l1.LOCATION = l.LOCATION
AND l1.EFFDT <= j.EFFDT)
AND l.EFF_STATUS = 'A'
AND c.COUNTRY = l.COUNTRY
AND o.oprid = ps_AB_PDI_CN_TAO_TMP.OPRID),' ' )
WHERE COUNTRY_2CHAR = ' '
FINDINGS SECTION (2 findings)
1- Statistics Finding
Optimizer statistics for table "SYSADM"."PS_AB_PDI_CN_TAO_TMP" and its
indices are stale.
Recommendation
- Consider collecting optimizer statistics for this table.
execute dbms_stats.gather_table_stats(ownname => 'SYSADM', tabname =>
'PS_AB_PDI_CN_TAO_TMP', estimate_percent =>
DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE
AUTO');
Rationale
The optimizer requires up-to-date statistics for the table in order to
select a good execution plan.
2- SQL Profile Finding (see explain plans section below)
A potentially better execution plan was found for this statement.
Recommendation (estimated benefit<=10%)
- Consider accepting the recommended SQL profile.
execute dbms_sqltune.accept_sql_profile(task_name =>
'sysadm_avoid_psijob', replace => TRUE);
EXPLAIN PLANS SECTION
1- Original With Adjusted Cost
Plan hash value: 4225281431
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | UPDATE STATEMENT | | 48482 | 284K| 54 (19)| 00:00:01 |
| 1 | UPDATE | PS_AB_PDI_CN_TAO_TMP | | | | |
|* 2 | TABLE ACCESS FULL | PS_AB_PDI_CN_TAO_TMP | 48482 | 284K| 54 (19)| 00:00:01 |
| 3 | NESTED LOOPS | | 1 | 80 | 8 (0)| 00:00:01 |
| 4 | NESTED LOOPS | | 1 | 73 | 7 (0)| 00:00:01 |
| 5 | NESTED LOOPS | | 1 | 48 | 5 (0)| 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID | PSOPRDEFN | 1 | 15 | 2 (0)| 00:00:01 |
|* 7 | INDEX UNIQUE SCAN | PS_PSOPRDEFN | 1 | | 1 (0)| 00:00:01 |
| 8 | TABLE ACCESS BY INDEX ROWID | PS_JOB | 1 | 33 | 3 (0)| 00:00:01 |
|* 9 | INDEX RANGE SCAN | PSAJOB | 1 | | 2 (0)| 00:00:01 |
| 10 | SORT AGGREGATE | | 1 | 19 | | |
| 11 | FIRST ROW | | 10 | 190 | 3 (0)| 00:00:01 |
|* 12 | INDEX RANGE SCAN (MIN/MAX) | PSAJOB | 10 | 190 | 3 (0)| 00:00:01 |
| 13 | SORT AGGREGATE | | 1 | 22 | | |
| 14 | FIRST ROW | | 1 | 22 | 3 (0)| 00:00:01 |
|* 15 | INDEX RANGE SCAN (MIN/MAX) | PSAJOB | 1 | 22 | 3 (0)| 00:00:01 |
| 16 | SORT AGGREGATE | | 1 | 22 | | |
| 17 | FIRST ROW | | 1 | 22 | 9 (67)| 00:00:01 |
|* 18 | INDEX RANGE SCAN (MIN/MAX) | PSAJOB | 1 | 22 | 9 (67)| 00:00:01 |
| 19 | SORT AGGREGATE | | 1 | 19 | | |
| 20 | FIRST ROW | | 10 | 190 | 3 (0)| 00:00:01 |
|* 21 | INDEX RANGE SCAN (MIN/MAX) | PSAJOB | 10 | 190 | 3 (0)| 00:00:01 |
| 22 | SORT AGGREGATE | | 1 | 22 | | |
| 23 | FIRST ROW | | 1 | 22 | 3 (0)| 00:00:01 |
|* 24 | INDEX RANGE SCAN (MIN/MAX)| PSAJOB | 1 | 22 | 3 (0)| 00:00:01 |
|* 25 | TABLE ACCESS BY INDEX ROWID | PS_LOCATION_TBL | 1 | 25 | 2 (0)| 00:00:01 |
|* 26 | INDEX RANGE SCAN | PS_LOCATION_TBL | 1 | | 1 (0)| 00:00:01 |
| 27 | SORT AGGREGATE | | 1 | 19 | | |
| 28 | FIRST ROW | | 1 | 19 | 2 (0)| 00:00:01 |
|* 29 | INDEX RANGE SCAN (MIN/MAX) | PS_LOCATION_TBL | 1 | 19 | 2 (0)| 00:00:01 |
| 30 | TABLE ACCESS BY INDEX ROWID | PS_COUNTRY_TBL | 1 | 7 | 1 (0)| 00:00:01 |
|* 31 | INDEX UNIQUE SCAN | PS_COUNTRY_TBL | 1 | | 0 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter("COUNTRY_2CHAR"=' ')
7 - access("O"."OPRID"=:B1)
9 - access("J"."EMPLID"="O"."EMPLID")
filter("J"."EFFDT"= (SELECT /*+ INDEX ("J1" "PSAJOB") */ MAX("J1"."EFFDT") FROM "PS_JOB" "J1" WHERE
"J1"."EFFDT"<=SYSDATE@! AND "J1"."EMPL_RCD"=:B1 AND "J1"."EMPLID"=:B2) AND "J"."EFFSEQ"= (SELECT /*+ INDEX
("J2" "PSAJOB") */ MAX("J2"."EFFSEQ") FROM "PS_JOB" "J2" WHERE "J2"."EFFDT"=:B3 AND "J2"."EMPL_RCD"=:B4 AND
"J2"."EMPLID"=:B5) AND "J"."EMPL_RCD"= (SELECT /*+ INDEX ("SYS_ALIAS_5" "PSAJOB") */ MAX("JS"."EMPL_RCD") FR
"PS_JOB" "SYS_ALIAS_5" WHERE "JS"."EMPLID"=:B6 AND "JS"."EFFDT"= (SELECT /*+ INDEX ("JS1" "PSAJOB") */
MAX("JS1"."EFFDT") FROM "PS_JOB" "JS1" WHERE "JS1"."EFFDT"<=SYSDATE@! AND "JS1"."EMPL_RCD"=:B7 AND
"JS1"."EMPLID"=:B8) AND "JS"."EFFSEQ"= (SELECT /*+ INDEX ("JS2" "PSAJOB") */ MAX("JS2"."EFFSEQ") FROM "PS_JO
"JS2" WHERE "JS2"."EFFDT"=:B9 AND "JS2"."EMPL_RCD"=:B10 AND "JS2"."EMPLID"=:B11)))
12 - access("J1"."EMPLID"=:B1 AND "J1"."EMPL_RCD"=:B2 AND "J1"."EFFDT"<=SYSDATE@!)
15 - access("J2"."EMPLID"=:B1 AND "J2"."EMPL_RCD"=:B2 AND "J2"."EFFDT"=:B3)
18 - access("JS"."EMPLID"=:B1)
filter("JS"."EFFDT"= (SELECT /*+ INDEX ("JS1" "PSAJOB") */ MAX("JS1"."EFFDT") FROM "PS_JOB" "JS1" WHERE
"JS1"."EFFDT"<=SYSDATE@! AND "JS1"."EMPL_RCD"=:B1 AND "JS1"."EMPLID"=:B2) AND "JS"."EFFSEQ"= (SELECT /*+ IND
("JS2" "PSAJOB") */ MAX("JS2"."EFFSEQ") FROM "PS_JOB" "JS2" WHERE "JS2"."EFFDT"=:B3 AND "JS2"."EMPL_RCD"=:B4
AND "JS2"."EMPLID"=:B5))
21 - access("JS1"."EMPLID"=:B1 AND "JS1"."EMPL_RCD"=:B2 AND "JS1"."EFFDT"<=SYSDATE@!)
24 - access("JS2"."EMPLID"=:B1 AND "JS2"."EMPL_RCD"=:B2 AND "JS2"."EFFDT"=:B3)
25 - filter("L"."EFF_STATUS"='A')
26 - access("L"."SETID"="J"."SETID_LOCATION" AND "L"."LOCATION"="J"."LOCATION")
filter("L"."EFFDT"= (SELECT /*+ INDEX ("L1" "PS_LOCATION_TBL") */ MAX("L1"."EFFDT") FROM
"PS_LOCATION_TBL" "L1" WHERE "L1"."EFFDT"<=:B1 AND "L1"."LOCATION"=:B2 AND "L1"."SETID"=:B3))
29 - access("L1"."SETID"=:B1 AND "L1"."LOCATION"=:B2 AND "L1"."EFFDT"<=:B3)
31 - access("C"."COUNTRY"="L"."COUNTRY")
2- Using SQL Profile
Plan hash value: 1175485146
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | UPDATE STATEMENT | | 48482 | 284K| | 54 (19)| 00:00:01 |
| 1 | UPDATE | PS_AB_PDI_CN_TAO_TMP | | | | | |
|* 2 | TABLE ACCESS FULL | PS_AB_PDI_CN_TAO_TMP | 48482 | 284K| | 54 (19)| 00:00:01 |
| 3 | NESTED LOOPS | | 1 | 133 | | 17470 (4)| 00:03:30 |
| 4 | NESTED LOOPS | | 1 | 80 | | 8 (0)| 00:00:01 |
| 5 | NESTED LOOPS | | 1 | 73 | | 7 (0)| 00:00:01 |
| 6 | NESTED LOOPS | | 1 | 48 | | 5 (0)| 00:00:01 |
| 7 | TABLE ACCESS BY INDEX ROWID | PSOPRDEFN | 1 | 15 | | 2 (0)| 00:00:01 |
|* 8 | INDEX UNIQUE SCAN | PS_PSOPRDEFN | 1 | | | 1 (0)| 00:00:01 |
| 9 | TABLE ACCESS BY INDEX ROWID | PS_JOB | 1 | 33 | | 3 (0)| 00:00:01 |
|* 10 | INDEX RANGE SCAN | PSAJOB | 1 | | | 2 (0)| 00:00:01 |
| 11 | SORT AGGREGATE | | 1 | 19 | | | |
| 12 | FIRST ROW | | 10 | 190 | | 3 (0)| 00:00:01 |
|* 13 | INDEX RANGE SCAN (MIN/MAX)| PSAJOB | 10 | 190 | | 3 (0)| 00:00:01 |
| 14 | SORT AGGREGATE | | 1 | 115 | | | |
|* 15 | HASH JOIN | | 1 | 115 | | 10 (30)| 00:00:01 |
| 16 | NESTED LOOPS | | 1 | 75 | | 5 (20)| 00:00:01 |
| 17 | VIEW | VW_SQ_2 | 19 | 1007 | | 4 (25)| 00:00:01 |
| 18 | SORT GROUP BY | | 19 | 779 | | 4 (25)| 00:00:01 |
|* 19 | INDEX RANGE SCAN | PSAJOB | 19 | 779 | | 3 (0)| 00:00:01 |
|* 20 | INDEX UNIQUE SCAN | PS_JOB | 1 | 22 | | 1 (0)| 00:00:01 |
| 21 | VIEW | VW_SQ_1 | 19 | 760 | | 4 (25)| 00:00:01 |
| 22 | SORT GROUP BY | | 19 | 570 | | 4 (25)| 00:00:01 |
|* 23 | INDEX RANGE SCAN | PSAJOB | 19 | 570 | | 3 (0)| 00:00:01 |
|* 24 | TABLE ACCESS BY INDEX ROWID | PS_LOCATION_TBL | 1 | 25 | | 2 (0)| 00:00:01 |
|* 25 | INDEX RANGE SCAN | PS_LOCATION_TBL | 1 | | | 1 (0)| 00:00:01 |
| 26 | SORT AGGREGATE | | 1 | 19 | | | |
| 27 | FIRST ROW | | 1 | 19 | | 2 (0)| 00:00:01 |
|* 28 | INDEX RANGE SCAN (MIN/MAX) | PS_LOCATION_TBL | 1 | 19 | | 2 (0)| 00:00:01 |
| 29 | TABLE ACCESS BY INDEX ROWID | PS_COUNTRY_TBL | 1 | 7 | | 1 (0)| 00:00:01 |
|* 30 | INDEX UNIQUE SCAN | PS_COUNTRY_TBL | 1 | | | 0 (0)| 00:00:01 |
|* 31 | VIEW | VW_SQ_3 | 1 | 53 | | 17462 (4)| 00:03:30 |
| 32 | SORT GROUP BY | | 3299K| 129M| 379M| 17462 (4)| 00:03:30 |
| 33 | INDEX FULL SCAN | PSAJOB | 3299K| 129M| | 17462 (4)| 00:03:30 |
Predicate Information (identified by operation id):
2 - filter("COUNTRY_2CHAR"=' ')
8 - access("O"."OPRID"=:B1)
10 - access("J"."EMPLID"="O"."EMPLID")
filter("J"."EFFDT"= (SELECT MAX("J1"."EFFDT") FROM "PS_JOB" "J1" WHERE "J1"."EFFDT"<=SYSDATE@! AND
"J1"."EMPL_RCD"=:B1 AND "J1"."EMPLID"=:B2) AND "J"."EMPL_RCD"= (SELECT MAX("JS"."EMPL_RCD") FROM "PS_JOB"
"JS", (SELECT MAX("JS1"."EFFDT") "VW_COL_1","JS1"."EMPLID" "EMPLID","JS1"."EMPL_RCD" "EMPL_RCD" FROM
"PS_JOB" "JS1" WHERE "JS1"."EMPLID"=:B3 AND "JS1"."EFFDT"<=SYSDATE@! GROUP BY
"JS1"."EMPLID","JS1"."EMPL_RCD") "VW_SQ_1", (SELECT MAX("JS2"."EFFSEQ") "VW_COL_1","JS2"."EMPLID"
"EMPLID","JS2"."EMPL_RCD" "EMPL_RCD","JS2"."EFFDT" "EFFDT" FROM "PS_JOB" "JS2" WHERE "JS2"."EMPLID"=:B4
GROUP BY "JS2"."EMPLID","JS2"."EMPL_RCD","JS2"."EFFDT") "VW_SQ_2" WHERE "EMPL_RCD"="JS"."EMPL_RCD" AND
"EMPLID"="JS"."EMPLID" AND "JS"."EFFDT"="VW_COL_1" AND "JS"."EFFSEQ"="VW_COL_1" AND "EFFDT"="JS"."EFFDT"
AND "EMPL_RCD"="JS"."EMPL_RCD" AND "EMPLID"="JS"."EMPLID" AND "JS"."EMPLID"=:B5))
13 - access("J1"."EMPLID"=:B1 AND "J1"."EMPL_RCD"=:B2 AND "J1"."EFFDT"<=SYSDATE@!)
15 - access("JS"."EFFDT"="VW_COL_1" AND "EMPLID"="JS"."EMPLID" AND "EMPL_RCD"="JS"."EMPL_RCD")
19 - access("JS2"."EMPLID"=:B1)
20 - access("EMPLID"="JS"."EMPLID" AND "EMPL_RCD"="JS"."EMPL_RCD" AND "EFFDT"="JS"."EFFDT" AND
"JS"."EFFSEQ"="VW_COL_1")
filter("JS"."EMPLID"=:B1)
23 - access("JS1"."EMPLID"=:B1 AND "JS1"."EFFDT"<=SYSDATE@!)
filter("JS1"."EFFDT"<=SYSDATE@!)
24 - filter("L"."EFF_STATUS"='A')
25 - access("L"."SETID"="J"."SETID_LOCATION" AND "L"."LOCATION"="J"."LOCATION")
filter("L"."EFFDT"= (SELECT MAX("L1"."EFFDT") FROM "PS_LOCATION_TBL" "L1" WHERE "L1"."EFFDT"<=:B1
AND "L1"."LOCATION"=:B2 AND "L1"."SETID"=:B3))
28 - access("L1"."SETID"=:B1 AND "L1"."LOCATION"=:B2 AND "L1"."EFFDT"<=:B3)
30 - access("C"."COUNTRY"="L"."COUNTRY")
31 - filter("J"."EFFSEQ"="VW_COL_1" AND "EMPLID"="J"."EMPLID" AND "EMPL_RCD"="J"."EMPL_RCD" AND
"EFFDT"="J"."EFFDT")
-------------------------------------------------------------------------------{code}
If I accept this new explain plan, the query is not improved, it run longer than expected, especially longer than the previous one (using only PSAJOB).
Similar Messages
-
Performance issues with the Vouchers index build in SES
Hi All,
We are currently performing an upgrade for: PS FSCM 9.1 to PS FSCM 9.2.
As a part of the upgrade, Client wants Oracle SES to be deployed for some modules including, Purchasing, Payables (Vouchers)
We are facing severe performance issues with the Vouchers index build. (Volume of data = approx. 8.5 million rows of data)
The index creation process runs for over 5 days.
Can you please share any information or issues that you may have faced on your project and how they were addressed?Check the following logs for errors:
1. The message log from the process scheduler
2. search_server1-diagnostic.log in /search_server1/logs directory
If the build is getting stuck while crawling then we typically have to increase the Java Heap size for the Weblogic instance for SES> -
6d wrong choice for portrait work?
Ok guys,
I was debating for quite some time whether to by the 6d or the 70d. Then I debated the 6d vs 5dIII. I went with the 6d based on many reviews, opinins and some great help on this forum. I haven't really had the chance to put it through it's paces yet. I really hate reading manuals, so I bought this short Creative Live class the John Greengo held on the 6d. He was saying that hardly anyone would use this camera in the studio since you have to run it at 1/100 to get a decent sync speed. This makes me nauseous. This was the main reason I bought this camera was for studio portraits. Does anyone have any encouraging words to make me feel like I made the wrong choice? I definitgely want a full frame, so if this isn't the one, I would have to spend twice as much on the 5dIII.I should add... once upon a time nearly every camera that I worked with for studio photography... had a flash sync speed of 1/60th, there was no such thing as "high speed sync", and this really was no problem at all. It's not like we felt we needed to overcome a weakness in the camera to do studio shooting.
As Skirball points out, I do not think you'll have any trouble at all at 1/160th.
Tim Campbell
5D II, 5D III, 60Da -
Question on optimum choice of index - whether to use CTXCAT or CONTEXT
Hi ,
I have a situation in which there are short texts that are to be searched for diacritical characters and for that I implemented CTXCAT type of index. The solution works fine except for left side wild card search - in that case I have suggested the developers to use the query template feature. -this is the background information for the question I have and following example demonstrates it:
CREATE TABLE TEST_USER
FIRST_NAME VARCHAR2(64 CHAR) NOT NULL,
LAST_NAME VARCHAR2(64 CHAR) NOT NULL
CREATE INDEX TEST_USER_IDX3 ON TEST_USER
(FIRST_NAME)
INDEXTYPE IS CTXSYS.CTXCAT
PARAMETERS('LEXER cust_lexer');
CREATE INDEX TEST_USER_IDX4 ON TEST_USER
(LAST_NAME)
INDEXTYPE IS CTXSYS.CTXCAT
PARAMETERS('LEXER cust_lexer');
Don't worry about the cust_lexer, it is for diacritical search and it is not relevant to this question so I am not copying the code for the preference I created etc.
Now I have a row of data in the table with first_name column as Supervisor. If I run the below sql, it gives output:
SELECT *
FROM test_user
WHERE catsearch (first_name, 'Supervisor', NULL) > 0;
FIRST_NAME LAST_NAME
Supervisor upervisor
--even the below sql with wild card (*) at the end works fine...
SQL> SELECT *
2 FROM test_user
3 WHERE catsearch (first_name, 'Super*', NULL) > 0;
FIRST_NAME LAST_NAME
Supervisor upervisor
However the below sql queries doesn't give any output, though they should return the same row as above!
SQL> SELECT *
2 FROM test_user
3 WHERE catsearch (first_name, '*visor', NULL) > 0;
no rows selected
SQL> SELECT *
2 FROM test_user
3 WHERE catsearch (first_name, '*vis*', NULL) > 0;
no rows selected
--Using query template as below solves the issue:
select * from test_user
where catsearch(first_name,
'<query>
<textquery grammar="context">
%viso%
</textquery>
</query>','')>0
FIRST_NAME LAST_NAME
Supervisor upervisor
Note that I verified the query execution plan and it uses the index and there is no Full Table Scan:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 9 (100)| |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST_USER | 376 | 99K| 9 (0)| 00:00:01 |
|* 2 | DOMAIN INDEX | TEST_USER_IDX3 | | | | |
---------------------------------------------------------------------------------------------- Up to the above , all details were by way of the back ground...now the question is - it is this the right choice? I am using context grammer using query template. There is another thread on this forum where an expert (Barbara) said that
". It should be better to use a context index than a ctxcat index with a query template that uses context grammar. " -this was said on this question link: Re: Wildcard Search
So I am getting this doubt. However I have good data here that shows that the query doesn't do full table scan - still is it a bad choice? Note that there are several issues with CONTENT type of indexes( as per my limited understanding) - because they are not transactional in nature and so we have to take extra steps/measures to have the indexes updated which seems like a major pain area to me.
My doubt is , did I do the right thing by using query template or should I use the CONTEXT type of index instead of CTXCAT type of index?
Thanks,
Nirav
Edited by: orausern on Jan 17, 2013 1:40 AM
Edited by: orausern on Jan 17, 2013 1:43 AMI would just like to add a few comments.
Alhough it is documented that the ctxcxat index and catsearch do not support a wildcard in front of the term, a workaround is to use two asterisks on the left side of the term, as demonstrated below. I provide this only for clarification and interesting trivia. I would still use a context index for various reasons.
SCOTT@orcl_11gR2> CREATE TABLE TEST_USER
2 (FIRST_NAME VARCHAR2(64 CHAR))
3 /
Table created.
SCOTT@orcl_11gR2> INSERT INTO test_user VALUES ('Supervisor')
2 /
1 row created.
SCOTT@orcl_11gR2> CREATE INDEX TEST_USER_IDX
2 ON TEST_USER (FIRST_NAME)
3 INDEXTYPE IS CTXSYS.CTXCAT
4 /
Index created.
SCOTT@orcl_11gR2> SET AUTOTRACE ON EXPLAIN
SCOTT@orcl_11gR2> SELECT * FROM test_user
2 WHERE catsearch (first_name, '**vis*', NULL) > 0
3 /
FIRST_NAME
Supervisor
1 row selected.
Execution Plan
Plan hash value: 4046491764
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 142 | 3 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST_USER | 1 | 142 | 3 (0)| 00:00:01 |
|* 2 | DOMAIN INDEX | TEST_USER_IDX | | | | |
Predicate Information (identified by operation id):
2 - access("CTXSYS"."CATSEARCH"("FIRST_NAME",'**vis*',NULL)>0)
Note
- dynamic sampling used for this statement (level=2)
SCOTT@orcl_11gR2>The only time that I am aware of that there is a conflict between a wordlist and a lexer is when you specify stemming in both. If you are using stemming, you can still use both a wordlist and a lexer, but only set the stemmer attribute in the wordlist, not the index_stems attribute in the lexer. -
Performance issue with Oracle Text index
Hi Experts,
We are on Oracle 11.2..0.3 on Solaris 10. I have implemented Oracle Text in our environment and I am facing a strange performance issue that is happening in our environment.
One sql having CONTAINS clause is taking forever - more than 20 minutes and still does not complete. This sql has a contains clause and an exists clause and a not exists clause.
Now if I remove the exists clause and a not exists clause , it completes fast. but with those two clauses it is just taking forever. It is late night so i am not able to post the table and sql query details and will do so tomorrow but based on this general description, are there any pointers for me to review?
sql query doing fine:
SELECT
U.CLNT_OID, U.USR_OID, S.MAILADDR
FROM
access_usr U
INNER JOIN access_sia S
ON S.USR_OID = U.USR_OID AND S.CLNT_OID = U.CLNT_OID
WHERE U.CLNT_OID = 'ABCX32S'
AND CONTAINS(LAST_NAME , 'TO%' ) >0
--sql query that hangs forever:
SELECT
U.CLNT_OID, U.USR_OID, S.MAILADDR
FROM
access_usr U
INNER JOIN access_sia S
ON S.USR_OID = U.USR_OID AND S.CLNT_OID = U.CLNT_OID
WHERE U.CLNT_OID = 'ABCX32S'
AND CONTAINS(LAST_NAME , 'TO%' ) >0
and exists (--one clause here wiht a few table joins)
and not exists (--one clause here wiht a few table joins);
--Now another strange thing I found is if instead of 'TO%' in this sql, if I were to use 'ZZ%' or 'L1%' it works fast but for 'TO%' it goes slow with those two exists not exists clauses!
I will be most thankful for the inputs.
OrauserNHi Barbara,
First of all, thanks a lot for reviewing the issue.
Unluckily making the change to empty_stoplist did not work out. I am today copying the entire sql here that has this issue and will be most thankful for more insights/pointers on what can be done.
Here is the entire sql:
SELECT U.CLNT_OID,
U.USR_OID,
S.EMAILADDRESS,
U.FIRST_NAME,
U.LAST_NAME,
S.JOBCODE,
S.LOCATION,
S.DEPARTMENT,
S.ASSOCIATEID,
S.ENTERPRISECOMPANYCODE,
S.EMPLOYEEID,
S.PAYGROUP,
S.PRODUCTLOCALE
FROM ACCESS_USR U
INNER JOIN
ACCESS_SIA S
ON S.USR_OID = U.USR_OID AND S.CLNT_OID = U.CLNT_OID
WHERE U.CLNT_OID = 'G39NY3D25942TXDA'
AND EXISTS
(SELECT 1
FROM ACCESS_USR_GROUP_XREF UGX
INNER JOIN ACCESS_GROUP RELG
ON RELG.CLNT_OID = UGX.CLNT_OID
AND RELG.GROUP_OID = UGX.GROUP_OID
INNER JOIN ACCESS_GROUP G
ON G.CLNT_OID = RELG.CLNT_OID
AND G.GROUP_TYPE_OID = RELG.GROUP_TYPE_OID
WHERE UGX.CLNT_OID = U.CLNT_OID
AND UGX.USR_OID = U.USR_OID
AND G.GROUP_OID = 920512943
AND UGX.INCLUDED = 1)
AND NOT EXISTS
(SELECT 1
FROM ACCESS_USR_GROUP_XREF UGX
INNER JOIN
ACCESS_GROUP G
ON G.CLNT_OID = UGX.CLNT_OID
AND G.GROUP_OID = UGX.GROUP_OID
WHERE UGX.CLNT_OID = U.CLNT_OID
AND UGX.USR_OID = U.USR_OID
AND G.GROUP_OID = 920512943
AND UGX.INCLUDED = 1)
AND CONTAINS (U.LAST_NAME, 'Bon%') > 0;
Like I said before if the EXISTS and NOT EXISTS clause are removed it works in sub-second. But with those EXISTS and NOT EXISTS CLAUSE IT TAKES ANY WHERE FROM 25 minutes to more than one hour.
NOte also that it was not TO% but Bon% in the CONTAINS clause that is giving the issue - sorry that was wrong on my part.
Also please see below the ORACLE TEXT index defined on the table ACCESS_USER:
--definition of preferences used in the index:
SET SERVEROUTPUT ON size unlimited
WHENEVER SQLERROR EXIT SQL.SQLCODE
DECLARE
v_err VARCHAR2 (1000);
v_sqlcode NUMBER;
v_count NUMBER;
BEGIN
ctxsys.ctx_ddl.create_preference ('cust_lexer', 'BASIC_LEXER');
ctxsys.ctx_ddl.set_attribute ('cust_lexer', 'base_letter', 'YES'); -- removes diacritics
EXCEPTION
WHEN OTHERS
THEN
v_err := SQLERRM;
v_sqlcode := SQLCODE;
v_count := INSTR (v_err, 'DRG-10701');
IF v_count > 0
THEN
DBMS_OUTPUT.put_line (
'The required preference named CUST_LEXER with BASIC LEXER is already set up');
ELSE
RAISE;
END IF;
END;
DECLARE
v_err VARCHAR2 (1000);
v_sqlcode NUMBER;
v_count NUMBER;
BEGIN
ctxsys.ctx_ddl.create_preference ('cust_wl', 'BASIC_WORDLIST');
ctxsys.ctx_ddl.set_attribute ('cust_wl', 'SUBSTRING_INDEX', 'true'); -- to improve performance
EXCEPTION
WHEN OTHERS
THEN
v_err := SQLERRM;
v_sqlcode := SQLCODE;
v_count := INSTR (v_err, 'DRG-10701');
IF v_count > 0
THEN
DBMS_OUTPUT.put_line (
'The required preference named CUST_WL with BASIC WORDLIST is already set up');
ELSE
RAISE;
END IF;
END;
--now below is the code of the index:
CREATE INDEX ACCESS_USR_IDX3 ON ACCESS_USR
(FIRST_NAME)
INDEXTYPE IS CTXSYS.CONTEXT
PARAMETERS('LEXER cust_lexer WORDLIST cust_wl SYNC (ON COMMIT)');
CREATE INDEX ACCESS_USR_IDX4 ON ACCESS_USR
(LAST_NAME)
INDEXTYPE IS CTXSYS.CONTEXT
PARAMETERS('LEXER cust_lexer WORDLIST cust_wl SYNC (ON COMMIT)');
The strange thing is that, like I said, If I remove the exists clause the query returns very fast. Also if I modify the query to use only one NOT EXISTS clause and remove the other EXISTS clause it returns in less than one second. Also if I remove the EXISTS clause and use only the NOT EXISTS clause it returns in less than 4 seconds. But with both clauses it runs forever!
When I tried to get dbms_xplan.display_cursor to get the query plan (for the case of both exists and not exists clause in the query), it said that previous statement's sql id was 0 or something like that so that I was not able to see the query plan. I will keep trying to get this plan (it takes 25 minutes to one hour each time but will get this info soon). Again any pointers are most helpful.
Regards
OrauserN -
I connected my new iPhone 5 to my (now fully updated after two separate operating system upgrades!) MacBook Pro so that I could add my music to my new phone. Rather than configuring it as a new iPhone, I chose to configure it as my old iPhone, thinking that this would make it easier for my music to be there. WRONG. Now my new iPhone 5 looks exactly like my old iPhone 4 did in OCTOBER, 2012 - photos, messages, contacts... anything done since then is gone (that was the last time I had backed up my old phone, which unfortunately was not connected to the cloud and is also lost somewhere in a New England lake :-(). What I could really, really use help with is finding out if I can have a do-over on my choice and at least get my new phone looking/acting like the new phone it is, and bonus would be to have the photos and videos I took with it this past weekend (it's only five days old!) restored. Please help!
Look iTunes>Preferences>Devices...is a backup listed for your iPhone 5 dated BEFORE you restored your iPhone 4 backup to your iPhone 5? If not, your data is gone. If there is a backup, on your iPhone 5: Settings>General>Reset>Erase All Content & Settings. You should now be able to restore that backup, if it exists, to your iPhone 5.
-
Issues with using XMLType indexes against a table with XMLType column
I am attempting to use an XMLIndex with a Structured Component and not having too much luck. Not much data in metalink nor is the documentation very helpful:
http://download.oracle.com/docs/cd/E11882_01/appdev.112/e10492/xdb_indexing.htm#BCGHGIGC
The table DDL is as follows:
CREATE TABLE ECI_SCHEMA.REV_ITEM_EARN_DTL_VIRTUAL(
REV_ITEM_EARN_DTL_ID_NBR NUMBER(16,0) NOT NULL,
UNIQ_MSG_ID_NBR VARCHAR2(50) NOT NULL,
REV_ITEM_BILL_DTL_ID_NBR NUMBER(16,0),
PLAN_RACN_NBR NUMBER(10,0) NOT NULL,
INV_DTL_IMG SYS.XMLType NOT NULL,
NON_INV_DTL_IMG BLOB NOT NULL,
PART_KEY_CD GENERATED ALWAYS AS (MOD(PLAN_RACN_NBR,5)) VIRTUAL,
LAST_UPDT_TMSTP TIMESTAMP(6) NOT NULL,
INV_ID_NBR NUMBER(16,0),
ITEM_STATUS_CD VARCHAR2(1) DEFAULT 'A' NOT NULL
LOB (NON_INV_DTL_IMG) STORE AS NON_IDI_LOB (CHUNK 8192 PCTVERSION 10 CACHE)
TABLESPACE ECI_DATA
PARTITION BY RANGE (PART_KEY_CD)
PARTITION RIED_DAY0_PART
VALUES LESS THAN (1)
TABLESPACE ECI_DATA
PARTITION RIED_DAY1_PART
VALUES LESS THAN (2)
TABLESPACE ECI_DATA
PARTITION RIED_DAY2_PART
VALUES LESS THAN (3)
TABLESPACE ECI_DATA
PARTITION RIED_DAY3_PART
VALUES LESS THAN (4)
TABLESPACE ECI_DATA
PARTITION RIED_MAXVAL_PART
VALUES LESS THAN (MAXVALUE)
TABLESPACE ECI_DATA
XMLTYPE COLUMN "INV_DTL_IMG" STORE AS OBJECT RELATIONAL
XMLSCHEMA "someXdbDocument.xsd"
ELEMENT "revenueInvoice"
According to the documentation, I should be able to create a structured XMLIndex on the XMLType column with the following syntax:
SQL> create index eci_schema.rev_item_earn_dtl_virt_xmlix on eci_schema.rev_item_earn_dtl_virtual
2 (INV_DTL_IMG)
3 INDEXTYPE IS XDB.XMLIndex
4 parameters ('PATH TABLE RIED_PATH_TABLE')
5 local;
When I do this, I get the following error:
create index eci_schema.rev_item_earn_dtl_virt_xmlix on eci_schema.rev_item_earn_dtl_virtual
ERROR at line 1:
ORA-29958: fatal error occurred in the execution of ODCIINDEXCREATE routine
ORA-30959: The indexed column is not stored in CLOB.
What am I doing wrong? Based on the Oracle documentation, I was under the impression that 11.2 XMLIndex would work with Object Relational storage. Is this not the case?CREATE INDEX ECI_SCHEMA.REV_ITEM_EARN_DTL_IX7
ON ECI_SCHEMA.REV_ITEM_EARN_DTL
extractValue(inv_dtl_img, '/revenueInvoice/service/transportation/mstrTrkngNbr')
TABLESPACE ECI_REV_ITEM_EARN_DTL_IX7_ITS
LOGGING
PARALLEL(DEGREE 8 INSTANCES 1)
LOCAL
/Elements that occur at most once in each document can be indexed using extractValue(). Despite the fact that the index appears to be a functional index, when we create the index we automatically re-write the create index into a normal btree index on the column that contains the value for the element identified by the xpath.
Eg in the case of a functional index based on extractValue, defined on XMLType using Object relational storage, with an xpath that identifies a node that occurs at most once in each document is not a functional index, it's re-written into a plain old vanilla btree index. You can actually check this by looking in the system tables
Eg
SQL> connect system/oracle
Connected.
SQL> select table_name, index_name from all_indexes where owner = 'OE' and table_name = 'PURCHASEORDER';
TABLE_NAME INDEX_NAME
PURCHASEORDER LINEITEM_TABLE_MEMBERS
PURCHASEORDER ACTION_TABLE_MEMBERS
PURCHASEORDER SYS_C0011037
SQL> alter session set current_schema = OE
2 /
Session altered.
SQL> create unique index PO_REF_INDEX on PURCHASEORDER (extractValue(object_value,'/PurchaseOrder/Reference'));
Index created.
SQL> set lines 250
SQL> select index_name, index_type from all_indexes where owner = 'OE' and table_name = 'PURCHASEORDER';
INDEX_NAME INDEX_TYPE
PO_REF_INDEX NORMAL
LINEITEM_TABLE_MEMBERS NORMAL
ACTION_TABLE_MEMBERS NORMAL
SYS_C0011037 NORMAL
SQL> select * from dba_ind_expressions where table_name = 'PURCHASEORDER' and index_owner = 'OE'
2 /
no rows selectedFrom the above we can see that the index created on extractValue has been re-written in a plain old vanilla BTREE index, and there is no definition for it in dba_ind_expressions So assuming you were able to create the index and insert the data you should find that your index is not a functional index.
] -
Character display issue in French Web index tab
First of all, I'm working with RoboHelp 8.
There is a character display issue in the index tab of the web help. (See screenshot below)
The apostrophe, instead of displaying by itself, it has a backslash just before it: \'
In the hhk file, I started using the actual apostrophe ('), then replaced it with ' and finally tried '
(The htm files use utf-8 encoding). None of those options seemed to solve the issue.
Any help will be appreciated.Hi Steve,
Thanks for a very quick response. The problem is that the Title (name of the image filename is also the item number in Quote) and this is always not null. I am not sure how do I test whether the image is present in $OA_MEDIA directory or not. Does BI Publisher provide a way to find out whether an image filename exists in $OA_MEDIA or not.
If there is no such standard way provided by BI Publsher, then I guess I will have to write Java function that executes in the middle tier and returns whether file exists with that name in $OA_MEDIA.
Please let me know your view.
Thanks -
Metadata issues - wrong cover art, missing ratings etc
Hi,
I just bought a new iPhone 4S and upon setting up Home Sharing, I noticed that when I connect to my shared library albums and movies are displayed with incorrect cover art. In addition, the watched / unwatched status (the blue dot) for movies is wrong.
When playing music tracks, no ratings are displayed on the iPhone.
Has anyone else seen this behaviour and do you know of a fix?I am also having this issue, please fix this Apple, it all worked so well before the iOS5 update.
Ive tried fresh installs and restores yet home share video artwork is all messed up, and it seems completely random every time.The artwork shows fine when files are loaded locally onto my iPod touch 4G its only in Home Share that its wrong all the time and so annoying. -
Perf issues with Time series function in OBIEE
Attached is the SQL:
SELECT SUM (T256675.ACTIVITY_GLOBAL2_AMT) AS c1,
SUM (T256675.ACTIVITY_GLOBAL3_AMT) AS c2
FROM X_FINANCIAL_HIERARCHY_DH T610485 /* Dim_X_GLACCT_ALTVIEW_D */,
X_FINANCIAL_HIERARCHY_DH T610414 /* Dim_X_MGMT_ENTITY_D */,
W_GL_ACCOUNT_D T256463 /* Dim_W_GL_ACCOUNT_D */,
W_GL_BALANCE_F T256675 /* Fact_W_GL_BALANCE_F */,
SAWITH3,
SAWITH6
WHERE ( T256463.ROW_WID = T256675.GL_ACCOUNT_WID
AND T256463.X_FIN_HIER1_WID = T610485.ROW_WID
AND T256463.X_FIN_HIER5_WID = T610414.ROW_WID
AND T256675.BALANCE_DT_WID = SAWITH3.c3
AND SAWITH6.c1 = SAWITH3.c1
AND T610414.ACCOUNT_HIER8_NAME = 'Worldwide'
AND T610414.HIERARCHY_SOURCE = 'EntityMgmt'
AND T610485.ACCOUNT_HIER7_NAME = 'Controllable Expenses'
AND T610485.HIERARCHY_SOURCE = 'AltViews'
AND SAWITH6.c3 = '2009 / 11'
AND SAWITH6.c2 >= SAWITH3.c2
The SAWITH3 and SAWITH6 dimensions using time series fuctions are causing a full table scan on W_GL_BALANCE_F and W_GL_ACCOUNT_D . Though we are interested in just getting 2009/11 data; the queries generated by time series function TODATE is taking us against entire W_DAY_D data and is causing several performance issues.
W_GL_BALANCE_F table has index on GL_ACCOUNT_WID and BALANCE_DT_WID.
How can we force to use index on these columns for better performance.
Please advise us on the right approach to improve performance.
SQL for SAWITH3
===========
WITH SAWITH0 AS
SELECT T31328.ROW_WID AS c3, T31328.PER_NAME_FSCL_QTR AS c4,
ROW_NUMBER () OVER (PARTITION BY T31328.PER_NAME_FSCL_QTR ORDER BY T31328.PER_NAME_FSCL_QTR DESC)
AS c5,
T31328.PER_NAME_FSCL_MNTH AS c6,
ROW_NUMBER () OVER (PARTITION BY T31328.PER_NAME_FSCL_QTR, T31328.PER_NAME_FSCL_MNTH ORDER BY T31328.PER_NAME_FSCL_QTR DESC,
T31328.PER_NAME_FSCL_MNTH DESC) AS c7
FROM W_DAY_D T31328 /* Dim_W_DAY_D_Common */),
SAWITH1 AS
SELECT CASE
WHEN CASE SAWITH0.c5
WHEN 1
THEN SAWITH0.c3
ELSE NULL
END IS NOT NULL
THEN RANK () OVER (ORDER BY CASE SAWITH0.c5
WHEN 1
THEN SAWITH0.c3
ELSE NULL
END ASC NULLS LAST)
END AS c1,
CASE
WHEN CASE SAWITH0.c7
WHEN 1
THEN SAWITH0.c3
ELSE NULL
END IS NOT NULL
THEN RANK () OVER (PARTITION BY SAWITH0.c4 ORDER BY CASE SAWITH0.c7
WHEN 1
THEN SAWITH0.c3
ELSE NULL
END ASC NULLS LAST)
END AS c2,
SAWITH0.c3 AS c3, SAWITH0.c4 AS c4, SAWITH0.c6 AS c5
FROM SAWITH0),
SAWITH2 AS
SELECT MIN (SAWITH1.c1) OVER (PARTITION BY SAWITH1.c4) AS c1,
MIN (SAWITH1.c2) OVER (PARTITION BY SAWITH1.c4, SAWITH1.c5)
AS c2,
SAWITH1.c3 AS c3
FROM SAWITH1),
SAWITH3 AS
SELECT DISTINCT SAWITH2.c1 + 5 AS c1, SAWITH2.c2 AS c2,
SAWITH2.c3 AS c3
FROM SAWITH2),
SQL for SAWITH6
===========
SAWITH4 AS
SELECT T31328.PER_NAME_FSCL_MNTH AS c3, T31328.ROW_WID AS c4,
T31328.PER_NAME_FSCL_QTR AS c5,
ROW_NUMBER () OVER (PARTITION BY T31328.PER_NAME_FSCL_QTR ORDER BY T31328.PER_NAME_FSCL_QTR DESC)
AS c6,
ROW_NUMBER () OVER (PARTITION BY T31328.PER_NAME_FSCL_QTR, T31328.PER_NAME_FSCL_MNTH ORDER BY T31328.PER_NAME_FSCL_QTR DESC,
T31328.PER_NAME_FSCL_MNTH DESC) AS c7
FROM W_DAY_D T31328 /* Dim_W_DAY_D_Common */),
SAWITH5 AS
SELECT CASE
WHEN CASE SAWITH4.c6
WHEN 1
THEN SAWITH4.c4
ELSE NULL
END IS NOT NULL
THEN RANK () OVER (ORDER BY CASE SAWITH4.c6
WHEN 1
THEN SAWITH4.c4
ELSE NULL
END ASC NULLS LAST)
END AS c1,
CASE
WHEN CASE SAWITH4.c7
WHEN 1
THEN SAWITH4.c4
ELSE NULL
END IS NOT NULL
THEN RANK () OVER (PARTITION BY SAWITH4.c5 ORDER BY CASE SAWITH4.c7
WHEN 1
THEN SAWITH4.c4
ELSE NULL
END ASC NULLS LAST)
END AS c2,
SAWITH4.c3 AS c3, SAWITH4.c5 AS c4
FROM SAWITH4),
Thanks
Srini PendemHi Srini,
I've had quite a bit of performance issues with ToDate and Ago. I tended to create materialized views on my fact tables that would materialize those values as columns and that way I would avoid having to use the ToDate or Ago functions. Is there any chance you can implement a similar solution and bypass the time series functions entirely?
Just to check, those tables belong to BI Apps, right? If so, you can log an SR about the performance issue since it's an issue with the model that Oracle sold you.
Good luck!
-Joe -
Drilling down slow - Something wrong with Secondary Indexes
Hi,
I have a cube that on the whole works very well, but periodically when I drill down to some characteristics it runs extremely slowly.
The cube is in a our Test environment and is not being updated with data.
When I go to RSA1[Select Cube] Manage>Performance, the DB indexes are now green after reactivating the cube and recreating the indexes.
Yet, when I drill down to certain characteristics, I can see in SM50 the query is doing a sequential read. It looks as if the secondary index on this dimension is not doing its job or being ignored.
I have tried Checking the Cube Database Indexes in RSRV and all is okay. The Master Data in the relevant dimension all seems to be active.
Any suggestions on how to get to the bottom of this would be much appreciated.
A trace on the SQL is showing the following statement taking excessive time:
Select * from RSDCHABAS where CHABASNM = ? and OBJVERS = ?.
I'm not sure why it's getting stuck on this table and it just list of InfoObjects. It is not reading from the actual cube in this statement.
Regards
AdrianHi Adrian,
In BW we are while tranforming data from source system we are using this table to dump the data in table RSDCHABAS. Which is nothing but use as buffer.
Basically this issue is due to low Temporary memory available on the system. Please check Temp memory available in DB02 and send this to your basis team to clear / entend this temp memory.
This will deffinately resolve this error.
Regards,
Mahesh -
Filtering on lookup columns: wrong behavior with indexed columns!
Hi.
I already posted related problems. As one of my customers get other problems, I come back with my philosophical threads...
So: got a first parent list; a child list referencing parent list using 'X' lookup column.
If I got X indexed: filtering the child list on a value may give me several identical lines if child element has versions...
Other problem: I am not able to filter a view if the field is performed on a lookup linked to a calculated column (no result).
Has someone a solution for these 2 topics?Hi,
Would you mind providing more details about your first question? I’m not quite clear about how to reproduce the issue in my environment.
For the second question, we can reproduce this issue in a similar way.
It seems that lookup on calculated column will cause some unknown issue and there are no workarounds at this moment.
If there is a real need to filter the Lookup column, maybe we can find other workarounds instead of using Lookup column refer to the Calculated column according to the specific
business requirement.
What’s more, if you have several questions to ask, I suggest you post them into every single
thread to make others easier to focus on one question in one thread.
Best regards
Patrick Liang
TechNet Community Support -
iam working on hybrid app in SMP 2.3.
i have some issue on it .
i run the app first time select the choice field it will show at empty after click on outer space and then click the choice field again it shows the data
but my need is first time to select the choice field it shows the data pls help its urgent
i need some documents on SMP 2.3Hi Mani,
are you sure this is question is about SAP Mobile Documents? What product is SMP?
Best regards,
Peter -
Air 15 known issues - wrong screen size and dpi
Will the next update of Air 15 solve the issues below..
the dpi problem with iPhone 6 plus is a show stopper, i cant get away with delivering a reduced dpi
... under pressure to update 20+ applications ...
Known Issues AIR 15.0.0.183
[ iPhone 6 Plus] [Launch image] A blank screen observed in apps when Default-568h@2x is packaged.
[ iPhone 6 Plus] Wrong screen size and dpi is returned through the runtime APIs .
[ iPad 3 and later] iPhone Launch image(Default@2x. png ) appears on iPad if iPhone launch images are packaged along with iPad launch images
Well done to the Air team for the good work done so far, not easy keeping up with Apple on IOS8 at the moment...I am having simliar issue where I can get the iphone 6 launch image to work but not the iphone 6+ when using [email protected], 2208x1242. Also the stage.fullScreenWidth/Height give 1472x828, which is 2/3 the expected dimensions or 736x414 at scale factor 2, not 3. I hope adobe fixes this soon or we won't be able to launch new games with Apple as it is a requirement to have your apps Iphone 6/6+ optimized. If this isn't fixed soon were pretty much forced to abandon adobe and move onto another software solution that will allow us to build for Apple.
-
Say... What if MS E64 is not goin to be in retail... Only in OEM... which can be hard to get in some part of the world....
Alrighty... Don't get me wrong, athlon64 processors are nice. Able to do 64-bit stuff, got integrated memory controller... but what if MS E64 is not gonna be there... we'll all just be running 32 bit stuff... Was it worth it to get the athlon64??
I mean with Sempron 3100+ coming, we could have just spend way less to get that...Hi US PRO 666
You playing Devils Advocate here, the 666 and all. :hypecrite:
Well for my 2 bits worth. the FIS2R is the best MOBO about. Stable, lets me stir things up and turn them round, and still comes back for more. The amount of 'flakey ' progs that I load, ' just to see' what will happen, then remove them again. No other board would put up with. Still on my original installs of XP and XP64 bit. Though, it is probably time to do a reinstall. As I am always loking at 'new' stuff, I was thinking Neo2 and 939 pin, for next machine, I have managed to convince myself that we need another 64 bit computer, so have been looking for the next build. However, over the last couple of days, the Neo2 seems to have a prob or two, and is not as fast as I hoped. I'll wait for Sab & RexB to post their experiances, Ears on SAb? As I see it, at this moment, the best available would be the FIS2R and the 3700 AMD64 CPU. The K8N seems to be having some probs, which will take a month or so to sort out. So all in all, unless someone knows differant, my choice would still be the FIS2R and the AMD64s.
Cheers
jocko
Maybe you are looking for
-
How do I make my iMac g4 wireless?
I have an iMac g4 with 10.4 running. How can I make it wireless? If I can where is a good place to buy the part. I know apple does not make it anymore. Thanks for any help in advance.
-
My Adobe Reader Plugin does not Load in Some Machines
Hi , I have created a Plugin for Adobe Reader 9 and Adobe Reader X. As per the licence it has to work with both the version. My plugin gets loaded in Adobe Reader 9 and Adobe Reader X versions only in development machines and few of the testing machi
-
Hi All, When i select CIN details in MK02, nothing is coming. pls tell me is theresettings to be done? regards B Shar Edited by: Scorpio n on Feb 6, 2008 5:04 AM
-
Report run under oracle 10G , I can save it as pdf file under local pc's specified path (C:). However I can't find a way to redirect the same file to a local pc when run it in webformat ( using URL) . Does this mean when it is in a web report, it has
-
Unable to call conference on Android after installing WebEx
Hi, I'm using the WebEx android app on my Samsung Galaxy Note 2 (N7100). After installing the WebEx app, on the call screen, I see a WebEx button instead of the "Add call" button. I can still add a second call using the "overflow" menu. But after add