Query too slow on dictionary objects
We need to optimize a query for a view running on 10.2.0.4 that is used when application code checks database privileges.
This query takes about 4 or 5 seconds and we would like to have about 1 second.
Thanks.
Here is the view definition and some queries to check related objects statistics:
SQL> set linesize 132
SQL> DROP VIEW RA;
View dropped.
SQL>
SQL> whenever sqlerror exit failure;
SQL>
SQL> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for HPUX: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
SQL>
SQL>
SQL> CREATE OR REPLACE FORCE VIEW RA
2 (
3 MAT,
4 APP,
5 RAPP,
6 OBJET,
7 TYPE_OBJET,
8 SELECT_PRIV,
9 UPDATE_PRIV,
10 INSERT_PRIV,
11 DELETE_PRIV,
12 EXECUTE_PRIV
13 )
14 AS
15 SELECT USER,
16 SUBSTR (rtp.role, INSTR (rtp.role,
17 '_',
18 1,
19 1)
20 + 1, INSTR (rtp.role,
21 '_',
22 1,
23 2)
24 - INSTR (rtp.role,
25 '_',
26 1,
27 1)
28 - 1),
29 SUBSTR (rtp.role, INSTR (rtp.role,
30 '_',
31 1,
32 2)
33 + 1),
34 rtp.table_name,
35 ao.object_type,
36 DECODE (SUM (DECODE (rtp.privilege, 'SELECT', 1, 0)),
37 0, 'N',
38 'O'),
39 DECODE (SUM (DECODE (rtp.privilege, 'UPDATE', 1, 0)),
40 0, 'N',
41 'O'),
42 DECODE (SUM (DECODE (rtp.privilege, 'INSERT', 1, 0)),
43 0, 'N',
44 'O'),
45 DECODE (SUM (DECODE (rtp.privilege, 'DELETE', 1, 0)),
46 0, 'N',
47 'O'),
48 DECODE (SUM (DECODE (rtp.privilege, 'EXECUTE', 1, 0)),
49 0, 'N',
50 'O')
51 FROM session_roles sr,
52 role_role_privs rrp,
53 role_tab_privs rtp,
54 all_objects ao
55 WHERE sr.role = rrp.granted_role
56 AND rrp.granted_role = rtp.role
57 AND rtp.owner = ao.owner
58 AND rtp.table_name = ao.object_name
59 GROUP BY USER,
60 SUBSTR (rtp.role, INSTR (rtp.role,
61 '_',
62 1,
63 1)
64 + 1, INSTR (rtp.role,
65 '_',
66 1,
67 2)
68 - INSTR (rtp.role,
69 '_',
70 1,
71 1)
72 - 1),
73 SUBSTR (rtp.role, INSTR (rtp.role,
74 '_',
75 1,
76 2)
77 + 1),
78 rtp.table_name,
79 ao.object_type;
View created.
SQL> set timing on
SQL> select count(*) from ra;
COUNT(*)
1911
Elapsed: 00:00:04.43
SQL> set timing off
SQL>
SQL> select count(*) from all_objects;
COUNT(*)
100135
SQL> select count(*) from dba_users;
COUNT(*)
430
SQL> select count(*) from role_tab_privs;
COUNT(*)
23048
SQL> select count(*) from role_role_privs;
COUNT(*)
103
SQL>
SQL> select count(*) from sys.obj$;
COUNT(*)
100909
SQL> select count(*) from sys.objauth$;
COUNT(*)
55547
SQL> select count(*) from sys.user$;
COUNT(*)
626
SQL> select count(*) from session_roles;
COUNT(*)
11
SQL>
SQL> column table_name format a20
SQL> column owner format a10
SQL> select owner, table_name, last_analyzed, num_rows
2 from dba_tables where table_name in ('OBJ$', 'OBJAUTH$', 'USER$');
OWNER TABLE_NAME LAST_ANAL NUM_ROWS
SYS OBJAUTH$ 15-JAN-09 59292
SYS USER$ 20-JAN-09 622
SYS OBJ$ 26-JAN-09 101319
SQL>
SQL> exec dbms_monitor.session_trace_enable();
PL/SQL procedure successfully completed.
SQL> select count(*) from ra;
COUNT(*)
1911
SQL>
SQL> exitand here is the trace file output processed by TKPROF:
TKPROF: Release 10.2.0.4.0 - Production on Thu Jan 29 12:26:45 2009
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Trace file: tdivers6_ora_3289.trc
Sort options: prsela exeela fchela
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
select count(*)
from
ra
call count cpu elapsed disk query current rows
Parse 1 0.30 0.28 0 0 0 0
Execute 2 0.00 0.00 0 0 0 0
Fetch 2 5.97 6.14 8873 215796 2 1
total 5 6.27 6.42 8873 215796 2 1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 29
Rows Row Source Operation
1 SORT AGGREGATE (cr=215796 pr=8873 pw=1492 time=6141145 us)
1911 VIEW (cr=215796 pr=8873 pw=1492 time=6143024 us)
1911 HASH GROUP BY (cr=215796 pr=8873 pw=1492 time=6141111 us)
5642 HASH JOIN (cr=215796 pr=8873 pw=1492 time=3550103 us)
23048 VIEW ROLE_TAB_PRIVS (cr=97752 pr=973 pw=720 time=1663608 us)
23048 HASH GROUP BY (cr=97752 pr=973 pw=720 time=1640558 us)
48358 HASH JOIN (cr=97752 pr=973 pw=720 time=1485959 us)
48358 NESTED LOOPS (cr=97718 pr=568 pw=315 time=1285418 us)
48358 HASH JOIN (cr=1000 pr=543 pw=315 time=705104 us)
48358 HASH JOIN (cr=966 pr=228 pw=0 time=650471 us)
24 INDEX FULL SCAN I_TABLE_PRIVILEGE_MAP (cr=1 pr=0 pw=0 time=44 us)(object id 315)
48358 FILTER (cr=965 pr=228 pw=0 time=553263 us)
48358 NESTED LOOPS OUTER (cr=965 pr=228 pw=0 time=504902 us)
48358 HASH JOIN (cr=965 pr=228 pw=0 time=69670 us)
281 VIEW VW_NSO_1 (cr=724 pr=0 pw=0 time=18432 us)
281 FILTER (cr=724 pr=0 pw=0 time=18430 us)
884 CONNECT BY WITH FILTERING (cr=724 pr=0 pw=0 time=18870 us)
175 TABLE ACCESS BY INDEX ROWID SYSAUTH$ (cr=13 pr=0 pw=0 time=1542 us)
175 FILTER (cr=9 pr=0 pw=0 time=1008 us)
1334 INDEX FAST FULL SCAN I_SYSAUTH1 (cr=9 pr=0 pw=0 time=1388 us)(object id 105)
0 FIXED TABLE FULL X$KZDOS (cr=0 pr=0 pw=0 time=3700 us)
709 NESTED LOOPS (cr=711 pr=0 pw=0 time=4927 us)
702 CONNECT BY PUMP (cr=0 pr=0 pw=0 time=712 us)
709 INDEX RANGE SCAN I_SYSAUTH1 (cr=711 pr=0 pw=0 time=5016 us)(object id 105)
55547 TABLE ACCESS FULL OBJAUTH$ (cr=241 pr=228 pw=0 time=55725 us)
0 TABLE ACCESS BY INDEX ROWID COL$ (cr=0 pr=0 pw=0 time=341993 us)
0 INDEX RANGE SCAN I_COL2 (cr=0 pr=0 pw=0 time=82258 us)(object id 46)
626 TABLE ACCESS FULL USER$ (cr=34 pr=0 pw=0 time=666 us)
48358 TABLE ACCESS BY INDEX ROWID OBJ$ (cr=96718 pr=25 pw=0 time=488644 us)
48358 INDEX UNIQUE SCAN I_OBJ1 (cr=48360 pr=9 pw=0 time=244641 us)(object id 36)
626 TABLE ACCESS FULL USER$ (cr=34 pr=0 pw=0 time=675 us)
1301755 MERGE JOIN CARTESIAN (cr=118044 pr=7600 pw=472 time=4379450 us)
13 HASH JOIN (cr=3701 pr=0 pw=0 time=40049 us)
11 NESTED LOOPS (cr=24 pr=0 pw=0 time=270 us)
11 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=44 us)
11 TABLE ACCESS CLUSTER USER$ (cr=24 pr=0 pw=0 time=165 us)
11 INDEX UNIQUE SCAN I_USER# (cr=13 pr=0 pw=0 time=71 us)(object id 11)
103 VIEW ROLE_ROLE_PRIVS (cr=3677 pr=0 pw=0 time=38669 us)
103 HASH GROUP BY (cr=3677 pr=0 pw=0 time=38664 us)
107 NESTED LOOPS (cr=3677 pr=0 pw=0 time=26928 us)
709 NESTED LOOPS (cr=2859 pr=0 pw=0 time=32914 us)
709 HASH JOIN (cr=730 pr=0 pw=0 time=20857 us)
281 VIEW VW_NSO_2 (cr=724 pr=0 pw=0 time=18016 us)
281 FILTER (cr=724 pr=0 pw=0 time=17734 us)
884 CONNECT BY WITH FILTERING (cr=724 pr=0 pw=0 time=18735 us)
175 TABLE ACCESS BY INDEX ROWID SYSAUTH$ (cr=13 pr=0 pw=0 time=1290 us)
175 FILTER (cr=9 pr=0 pw=0 time=1107 us)
1334 INDEX FAST FULL SCAN I_SYSAUTH1 (cr=9 pr=0 pw=0 time=1372 us)(object id 105)
0 FIXED TABLE FULL X$KZDOS (cr=0 pr=0 pw=0 time=3734 us)
709 NESTED LOOPS (cr=711 pr=0 pw=0 time=4908 us)
702 CONNECT BY PUMP (cr=0 pr=0 pw=0 time=8 us)
709 INDEX RANGE SCAN I_SYSAUTH1 (cr=711 pr=0 pw=0 time=4970 us)(object id 105)
1334 TABLE ACCESS FULL SYSAUTH$ (cr=6 pr=0 pw=0 time=1377 us)
709 TABLE ACCESS CLUSTER USER$ (cr=2129 pr=0 pw=0 time=10226 us)
709 INDEX UNIQUE SCAN I_USER# (cr=711 pr=0 pw=0 time=3340 us)(object id 11)
107 TABLE ACCESS CLUSTER USER$ (cr=818 pr=0 pw=0 time=4748 us)
107 INDEX UNIQUE SCAN I_USER# (cr=711 pr=0 pw=0 time=2658 us)(object id 11)
1301755 BUFFER SORT (cr=114343 pr=7600 pw=472 time=3038891 us)
100135 VIEW ALL_OBJECTS (cr=114343 pr=1464 pw=0 time=1703751 us)
100135 FILTER (cr=114341 pr=1462 pw=0 time=1603615 us)
100891 HASH JOIN (cr=1162 pr=885 pw=0 time=404937 us)
626 TABLE ACCESS FULL USER$ (cr=34 pr=0 pw=0 time=653 us)
100893 TABLE ACCESS FULL OBJ$ (cr=1128 pr=885 pw=0 time=202344 us)
6467 TABLE ACCESS BY INDEX ROWID IND$ (cr=13316 pr=325 pw=0 time=100349 us)
6653 INDEX UNIQUE SCAN I_IND1 (cr=6655 pr=6 pw=0 time=33710 us)(object id 39)
1 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=84 us)
295 NESTED LOOPS (cr=9014 pr=7 pw=0 time=86130 us)
8013 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=13120 us)
295 INDEX RANGE SCAN I_OBJAUTH1 (cr=9014 pr=7 pw=0 time=67890 us)(object id 103)
1261 NESTED LOOPS (cr=9710 pr=18 pw=0 time=73685 us)
2116 INDEX RANGE SCAN I_OBJAUTH1 (cr=9710 pr=18 pw=0 time=43916 us)(object id 103)
1261 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=18578 us)
1 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=134 us)
113 NESTED LOOPS (cr=63960 pr=164 pw=0 time=459981 us)
7740 MERGE JOIN CARTESIAN (cr=55444 pr=164 pw=0 time=260673 us)
692 NESTED LOOPS (cr=55444 pr=164 pw=0 time=349021 us)
19314 TABLE ACCESS BY INDEX ROWID DEPENDENCY$ (cr=13988 pr=161 pw=0 time=124307 us)
19314 INDEX RANGE SCAN I_DEPENDENCY1 (cr=10866 pr=78 pw=0 time=56695 us)(object id 122)
692 TABLE ACCESS BY INDEX ROWID OBJ$ (cr=41456 pr=3 pw=0 time=196875 us)
19104 INDEX UNIQUE SCAN I_OBJ1 (cr=22352 pr=1 pw=0 time=104614 us)(object id 36)
7740 BUFFER SORT (cr=0 pr=0 pw=0 time=16767 us)
8996 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=4729 us)
113 INDEX RANGE SCAN I_OBJAUTH1 (cr=8516 pr=0 pw=0 time=62018 us)(object id 103)
1 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=91 us)
557 NESTED LOOPS (cr=8885 pr=63 pw=0 time=61541 us)
557 NESTED LOOPS (cr=8885 pr=63 pw=0 time=51669 us)
1033 TABLE ACCESS BY INDEX ROWID TRIGGER$ (cr=6808 pr=22 pw=0 time=29043 us)
1034 INDEX UNIQUE SCAN I_TRIGGER2 (cr=5774 pr=0 pw=0 time=16231 us)(object id 126)
557 INDEX RANGE SCAN I_OBJAUTH1 (cr=2077 pr=41 pw=0 time=16683 us)(object id 103)
557 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=4121 us)
1 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=98 us)
718 NESTED LOOPS (cr=3722 pr=0 pw=0 time=37122 us)
1573 INDEX RANGE SCAN I_OBJAUTH1 (cr=3722 pr=0 pw=0 time=17269 us)(object id 103)
718 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=14844 us)
1 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=103 us)
1 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=66 us)
0 NESTED LOOPS (cr=4572 pr=0 pw=0 time=36383 us)
1235 MERGE JOIN CARTESIAN (cr=3241 pr=0 pw=0 time=16756 us)
95 NESTED LOOPS (cr=3241 pr=0 pw=0 time=19566 us)
768 TABLE ACCESS BY INDEX ROWID DEPENDENCY$ (cr=1562 pr=0 pw=0 time=9821 us)
768 INDEX RANGE SCAN I_DEPENDENCY1 (cr=1412 pr=0 pw=0 time=5531 us)(object id 122)
95 TABLE ACCESS BY INDEX ROWID OBJ$ (cr=1679 pr=0 pw=0 time=7912 us)
767 INDEX UNIQUE SCAN I_OBJ1 (cr=912 pr=0 pw=0 time=4147 us)(object id 36)
1235 BUFFER SORT (cr=0 pr=0 pw=0 time=2343 us)
1235 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=653 us)
0 INDEX RANGE SCAN I_OBJAUTH1 (cr=1331 pr=0 pw=0 time=9933 us)(object id 103)
1 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=116 us)
1 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=163 us)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=154 us)
1 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=236 us)
1 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=217 us)
1 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=120 us)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us)
1 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=151 us)
1 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=219 us)
1 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=139 us)
1 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=186 us)
1 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=184 us)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us)
0 VIEW (cr=0 pr=0 pw=0 time=0 us)
0 FAST DUAL (cr=0 pr=0 pw=0 time=0 us)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
db file sequential read 627 0.00 0.01
db file scattered read 103 0.00 0.01
direct path write temp 68 0.00 0.00
direct path read temp 6198 0.00 0.01
SQL*Net message from client 2 0.00 0.00
BEGIN dbms_monitor.session_trace_enable(); END;
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 3 57 0 1
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.00 0.00 3 57 0 1
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 29
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
SQL*Net message from client 1 0.00 0.00
select dummy
from
dual where USER not in ('OPS$EXPORA','SYSTEM','SYS','FOG','QUEST')
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 0 0 0
total 3 0.00 0.00 0 0 0 0
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 29 (recursive depth: 1)
Rows Row Source Operation
0 FILTER (cr=0 pr=0 pw=0 time=6 us)
0 TABLE ACCESS FULL DUAL (cr=0 pr=0 pw=0 time=0 us)
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 1 0.30 0.28 0 0 0 0
Execute 3 0.00 0.00 3 57 0 1
Fetch 2 5.97 6.14 8873 215796 2 1
total 6 6.27 6.42 8876 215853 2 2
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 3 0.00 0.00
SQL*Net message from client 3 0.00 0.00
db file sequential read 628 0.00 0.01
db file scattered read 103 0.00 0.01
direct path write temp 68 0.00 0.00
direct path read temp 6198 0.00 0.01
log file sync 2 0.00 0.00
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 17 0.02 0.01 1 0 2 0
Execute 29 0.02 0.01 0 0 0 0
Fetch 47 0.00 0.00 23 224 0 37
total 93 0.04 0.04 24 224 2 37
Misses in library cache during parse: 7
Misses in library cache during execute: 4
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 15 0.00 0.00
db file scattered read 4 0.00 0.00
3 user SQL statements in session.
28 internal SQL statements in session.
31 SQL statements in session.
Trace file: tdivers6_ora_3289.trc
Trace file compatibility: 10.01.00
Sort options: prsela exeela fchela
1 session in tracefile.
3 user SQL statements in trace file.
28 internal SQL statements in trace file.
31 SQL statements in trace file.
14 unique SQL statements in trace file.
7473 lines in trace file.
6 elapsed seconds in trace file.
Here is the output of DBMS_XPLAN.DISPLAY (I need to split the message because forum says "Your message exceeds the maximum length of 30000 characters"):
SQL> explain plan for select count(*) from ra;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 3431051537
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | | 830 (50)| 00:00:05 |
| 1 | SORT AGGREGATE | | 1 | | | |
| 2 | VIEW | | 1 | | 830 (50)| 00:00:05 |
| 3 | HASH GROUP BY | | 1 | 108 | 830 (50)| 00:00:05 |
|* 4 | HASH JOIN | | 1 | 108 | 829 (50)| 00:00:05 |
| 5 | VIEW | ROLE_TAB_PRIVS | 192 | 7488 | 281 (14)| 00:00:02 |
PLAN_TABLE_OUTPUT
| 6 | HASH GROUP BY | | 192 | 22272 | 281 (14)| 00:00:02 |
|* 7 | HASH JOIN | | 192 | 22272 | 280 (14)| 00:00:02 |
|* 8 | HASH JOIN | | 192 | 19200 | 272 (14)| 00:00:02 |
|* 9 | HASH JOIN | | 192 | 16128 | 265 (14)| 00:00:02 |
| 10 | INDEX FULL SCAN | I_TABLE_PRIVILEGE_MAP | 24 | 240 | 1 (0)| 00:00:01 |
| 11 | NESTED LOOPS | | 192 | 14208 | 264 (14)| 00:00:02 |
|* 12 | FILTER | | | | | |
| 13 | NESTED LOOPS OUTER | | 191 | 9550 | 71 (47)| 00:00:01 |
|* 14 | HASH JOIN | | 193 | 5211 | 69 (48)| 00:00:01 |
| 15 | VIEW | VW_NSO_1 | 2 | 10 | 2 (0)| 00:00:01 |
|* 16 | FILTER | | | | | |
PLAN_TABLE_OUTPUT
|* 17 | CONNECT BY WITH FILTERING | | | | | |
| 18 | TABLE ACCESS BY INDEX ROWID | SYSAUTH$ | | | | |
|* 19 | FILTER | | | | | |
| 20 | INDEX FAST FULL SCAN | I_SYSAUTH1 | 1325 | 5300 | 3 (34)| 00:00:01 |
|* 21 | FIXED TABLE FULL | X$KZDOS | 1 | 13 | | |
| 22 | NESTED LOOPS | | | | | |
| 23 | CONNECT BY PUMP | | | | | |
|* 24 | INDEX RANGE SCAN | I_SYSAUTH1 | 2 | 18 | 2 (0)| 00:00:01 |
| 25 | TABLE ACCESS FULL | OBJAUTH$ | 59508 | 1278K| 58 (42)| 00:00:01 |
| 26 | TABLE ACCESS BY INDEX ROWID | COL$ | 1 | 23 | 2 (0)| 00:00:01 |
|* 27 | INDEX RANGE SCAN | I_COL2 | 1 | | 1 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
| 28 | TABLE ACCESS BY INDEX ROWID | OBJ$ | 1 | 24 | 1 (0)| 00:00:01 |
|* 29 | INDEX UNIQUE SCAN | I_OBJ1 | 1 | | 0 (0)| 00:00:01 |
| 30 | TABLE ACCESS FULL | USER$ | 622 | 9952 | 6 (0)| 00:00:01 |
| 31 | TABLE ACCESS FULL | USER$ | 622 | 9952 | 6 (0)| 00:00:01 |
| 32 | MERGE JOIN CARTESIAN | | 5679 | 382K| 548 (68)| 00:00:03 |
|* 33 | HASH JOIN | | 1 | 31 | 20 (15)| 00:00:01 |
| 34 | NESTED LOOPS | | 1 | 19 | 1 (0)| 00:00:01 |
|* 35 | FIXED TABLE FULL | X$KZSRO | 1 | 3 | 0 (0)| 00:00:01 |
| 36 | TABLE ACCESS CLUSTER | USER$ | 1 | 16 | 1 (0)| 00:00:01 |
|* 37 | INDEX UNIQUE SCAN | I_USER# | 1 | | 0 (0)| 00:00:01 |
| 38 | VIEW | ROLE_ROLE_PRIVS | 6 | 72 | 18 (12)| 00:00:01 |
PLAN_TABLE_OUTPUT
| 39 | HASH GROUP BY | | 6 | 288 | 18 (12)| 00:00:01 |
| 40 | NESTED LOOPS | | 6 | 288 | 17 (6)| 00:00:01 |
| 41 | NESTED LOOPS | | 6 | 192 | 11 (10)| 00:00:01 |
|* 42 | HASH JOIN | | 6 | 96 | 5 (20)| 00:00:01 |
| 43 | VIEW | VW_NSO_2 | 2 | 10 | 2 (0)| 00:00:01 |
|* 44 | FILTER | | | | | |
|* 45 | CONNECT BY WITH FILTERING | | | | | |
| 46 | TABLE ACCESS BY INDEX ROWID | SYSAUTH$ | | | | |
|* 47 | FILTER | | | | | |
| 48 | INDEX FAST FULL SCAN | I_SYSAUTH1 | 1325 | 5300 | 3 (34)| 00:00:01 |
|* 49 | FIXED TABLE FULL | X$KZDOS | 1 | 13 | | |
PLAN_TABLE_OUTPUT
| 50 | NESTED LOOPS | | | | | |
| 51 | CONNECT BY PUMP | | | | | |
|* 52 | INDEX RANGE SCAN | I_SYSAUTH1 | 2 | 18 | 2 (0)| 00:00:01 |
| 53 | TABLE ACCESS FULL | SYSAUTH$ | 1325 | 14575 | 2 (0)| 00:00:01 |
| 54 | TABLE ACCESS CLUSTER | USER$ | 1 | 16 | 1 (0)| 00:00:01 |
|* 55 | INDEX UNIQUE SCAN | I_USER# | 1 | | 0 (0)| 00:00:01 |
| 56 | TABLE ACCESS CLUSTER | USER$ | 1 | 16 | 1 (0)| 00:00:01 |
|* 57 | INDEX UNIQUE SCAN | I_USER# | 1 | | 0 (0)| 00:00:01 |
| 58 | BUFFER SORT | | 11357 | 421K| 548 (68)| 00:00:03 |
| 59 | VIEW | ALL_OBJECTS | 11357 | 421K| 528 (70)| 00:00:03 |
|* 60 | FILTER | | | | | |
PLAN_TABLE_OUTPUT
|* 61 | HASH JOIN | | 100K| 8460K| 528 (70)| 00:00:03 |
| 62 | TABLE ACCESS FULL | USER$ | 622 | 9952 | 6 (0)| 00:00:01 |
|* 63 | TABLE ACCESS FULL | OBJ$ | 100K| 6886K| 508 (70)| 00:00:03 |
|* 64 | TABLE ACCESS BY INDEX ROWID | IND$ | 1 | 8 | 2 (0)| 00:00:01 |
|* 65 | INDEX UNIQUE SCAN | I_IND1 | 1 | | 1 (0)| 00:00:01 |
|* 66 | FIXED TABLE FULL | X$KZSPR | 14 | 98 | 1 (100)| 00:00:01 |
| 67 | NESTED LOOPS | | 2 | 30 | 2 (0)| 00:00:01 |
| 68 | FIXED TABLE FULL | X$KZSRO | 2 | 6 | 0 (0)| 00:00:01 |
|* 69 | INDEX RANGE SCAN | I_OBJAUTH1 | 1 | 12 | 1 (0)| 00:00:01 |
| 70 | NESTED LOOPS | | 1 | 15 | 2 (0)| 00:00:01 |
|* 71 | INDEX RANGE SCAN | I_OBJAUTH1 | 1 | 12 | 2 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
|* 72 | FIXED TABLE FULL | X$KZSRO | 1 | 3 | 0 (0)| 00:00:01 |
|* 73 | FIXED TABLE FULL | X$KZSPR | 8 | 56 | 1 (100)| 00:00:01 |
| 74 | NESTED LOOPS | | 1 | 29 | 3 (0)| 00:00:01 |
| 75 | NESTED LOOPS | | 1 | 26 | 3 (0)| 00:00:01 |
|* 76 | TABLE ACCESS BY INDEX ROWID | TRIGGER$ | 1 | 14 | 2 (0)| 00:00:01 |
|* 77 | INDEX UNIQUE SCAN | I_TRIGGER2 | 1 | | 1 (0)| 00:00:01 |
|* 78 | INDEX RANGE SCAN | I_OBJAUTH1 | 1 | 12 | 1 (0)| 00:00:01 |
|* 79 | FIXED TABLE FULL | X$KZSRO | 1 | 3 | 0 (0)| 00:00:01 |
|* 80 | FIXED TABLE FULL | X$KZSPR | 6 | 42 | 1 (100)| 00:00:01 |
| 81 | NESTED LOOPS | | 1 | 52 | 6 (0)| 00:00:01 |
| 82 | MERGE JOIN CARTESIAN | | 1 | 40 | 5 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
| 83 | NESTED LOOPS | | 1 | 37 | 5 (0)| 00:00:01 |
| 84 | TABLE ACCESS BY INDEX ROWID | DEPENDENCY$ | 1 | 10 | 4 (0)| 00:00:01 |
|* 85 | INDEX RANGE SCAN | I_DEPENDENCY1 | 1 | | 3 (0)| 00:00:01 |
|* 86 | TABLE ACCESS BY INDEX ROWID | OBJ$ | 1 | 27 | 1 (0)| 00:00:01 |
|* 87 | INDEX UNIQUE SCAN | I_OBJ1 | 1 | | 0 (0)| 00:00:01 |
| 88 | BUFFER SORT | | 2 | 6 | 4 (0)| 00:00:01 |
| 89 | FIXED TABLE FULL | X$KZSRO | 2 | 6 | 0 (0)| 00:00:01 |
|* 90 | INDEX RANGE SCAN | I_OBJAUTH1 | 1 | 12 | 1 (0)| 00:00:01 |
|* 91 | FIXED TABLE FULL | X$KZSPR | 6 | 42 | 1 (100)| 00:00:01 |
| 92 | NESTED LOOPS | | 1 | 15 | 2 (0)| 00:00:01 |
|* 93 | INDEX RANGE SCAN | I_OBJAUTH1 | 1 | 12 | 2 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
|* 94 | FIXED TABLE FULL | X$KZSRO | 1 | 3 | 0 (0)| 00:00:01 |
|* 95 | FIXED TABLE FULL | X$KZSPR | 8 | 56 | 1 (100)| 00:00:01 |
|* 96 | FIXED TABLE FULL | X$KZSPR | 3 | 21 | 1 (100)| 00:00:01 |
|* 97 | FIXED TABLE FULL | X$KZSPR | 11 | 77 | 1 (100)| 00:00:01 |
| 98 | NESTED LOOPS | | 1 | 52 | 6 (0)| 00:00:01 |
| 99 | MERGE JOIN CARTESIAN | | 1 | 40 | 5 (0)| 00:00:01 |
| 100 | NESTED LOOPS | | 1 | 37 | 5 (0)| 00:00:01 |
| 101 | TABLE ACCESS BY INDEX ROWID | DEPENDENCY$ | 1 | 10 | 4 (0)| 00:00:01 |
|*102 | INDEX RANGE SCAN | I_DEPENDENCY1 | 1 | | 3 (0)| 00:00:01 |
|*103 | TABLE ACCESS BY INDEX ROWID | OBJ$ | 1 | 27 | 1 (0)| 00:00:01 |
|*104 | INDEX UNIQUE SCAN | I_OBJ1 | 1 | | 0 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
| 105 | BUFFER SORT | | 2 | 6 | 4 (0)| 00:00:01 |
| 106 | FIXED TABLE FULL | X$KZSRO | 2 | 6 | 0 (0)| 00:00:01 |
|*107 | INDEX RANGE SCAN | I_OBJAUTH1 | 1 | 12 | 1 (0)| 00:00:01 |
|*108 | FIXED TABLE FULL | X$KZSPR | 6 | 42 | 1 (100)| 00:00:01 |
|*109 | FIXED TABLE FULL | X$KZSPR | 11 | 77 | 1 (100)| 00:00:01 |
|*110 | FIXED TABLE FULL | X$KZSPR | 6 | 42 | 1 (100)| 00:00:01 |
|*111 | FIXED TABLE FULL | X$KZSPR | 3 | 21 | 1 (100)| 00:00:01 |
|*112 | FIXED TABLE FULL | X$KZSPR | 6 | 42 | 1 (100)| 00:00:01 |
|*113 | FIXED TABLE FULL | X$KZSPR | 14 | 98 | 1 (100)| 00:00:01 |
|*114 | FIXED TABLE FULL | X$KZSPR | 11 | 77 | 1 (100)| 00:00:01 |
|*115 | FIXED TABLE FULL | X$KZSPR | 14 | 98 | 1 (100)| 00:00:01 |
PLAN_TABLE_OUTPUT
|*116 | FIXED TABLE FULL | X$KZSPR | 6 | 42 | 1 (100)| 00:00:01 |
|*117 | FIXED TABLE FULL | X$KZSPR | 11 | 77 | 1 (100)| 00:00:01 |
|*118 | FIXED TABLE FULL | X$KZSPR | 11 | 77 | 1 (100)| 00:00:01 |
|*119 | FIXED TABLE FULL | X$KZSPR | 3 | 21 | 1 (100)| 00:00:01 |
|*120 | FIXED TABLE FULL | X$KZSPR | 6 | 42 | 1 (100)| 00:00:01 |
|*121 | FIXED TABLE FULL| X$KZSPR | 6 | 42 | 1 (100)| 00:00:01 |
| 122 | VIEW | | 1 | 13 | 2 (0)| 00:00:01 |
| 123 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------------------------------
Similar Messages
-
Hi All,
I am firing the following query in a view to fetch data.
But the query is taking too much time to execute.
Iam using oracle8i. Please let me know if there are any suggestions on this query.
select MWN_VIEW.* from
select distinct pre.MERCHANT_NAME,pre.SIC_CODE as MCC_CODE,pre.MERCHANT_STATE,exp.AMTTAXUSD,exp.EXPDATE, decode(nvl(exp.AMTTAXUSD,0),0,'N','Y') ReportedTax
from ERSTMP.pre,ERSTMP.CLM,ERSTMP.exp
where
clm.RPTKEY=exp.RPTKEY AND
clm.RPTKEY=pre.RPTKEY AND
exp.PARIND <> 'Y' AND
clm.RPTTYPE = 'PCD'
and pre.PREFILLKEY=exp.PREFILLKEY
) MWN_view,
select min(exp.EXPDATE) Exp_date,pre.MERCHANT_NAME,Merchant_state from ERSTMP.pre,
ERSTMP.exp,ERSTMP.CLM
where
clm.RPTKEY=exp.RPTKEY AND
clm.RPTKEY=pre.RPTKEY AND
exp.PARIND <> 'Y' AND
clm.RPTTYPE = 'PCD'
and pre.PREFILLKEY=exp.PREFILLKEY
group by pre.MERCHANT_NAME,Merchant_state
) MWN_SD_View
where
MWN_View.MERCHANT_NAME=MWN_SD_View.MERCHANT_NAME
and MWN_View.EXPDATE=MWN_SD_View.Exp_date
and MWN_View.MERCHANT_STATE=MWN_SD_View.MERCHANT_STATE
and
MWN_view.MERCHANT_NAME not in
select A1.merchant_name from
select erstmp.pre.merchant_name from erstmp.pre,ERSTMP.CLM,ERSTMP.exp
where clm.RPTKEY=exp.RPTKEY AND
clm.RPTKEY=pre.RPTKEY AND
exp.PARIND <> 'Y' AND
clm.RPTTYPE = 'PCD'
and pre.PREFILLKEY=exp.PREFILLKEY
) A1,
(Select
decode(instr(NVL(Merchantswhochargetax.MERCHANTNAME,' '),'~'),
0, Merchantswhochargetax.MERCHANTNAME,
SUBSTR(Merchantswhochargetax.MERCHANTNAME,1,instr(NVL(Merchantswhochargetax.MERCHANTNAME,' '),'~')-1)) as MERCHANTNAME
from Merchantswhochargetax) A2
where
instr(A1.merchant_name,A2.MERCHANTNAME)>0Also: how long is it taking to run and how long would you like it to take?
Also: what version of the database are you running?
Also: post some stats. I would guess it's doing some heavy sorts.
Also: it's pretty ugly, lots of the same tables in the sub-queries - is there really no better way of sharing the data? If you're using 9i you really ought to investigate the WITH clause of the SELECT statement.
Finally, why so many in-line views? It makes your query harder to read.
Good luck, APC
SELECT DISTINCT pre.merchant_name
, pre.sic_code as mcc_code
, pre.merchant_state
, exp.amttaxusd
, exp.expdate
, decode(nvl(exp.amttaxusd,0),0,'N','Y') reportedtax
FROM erstmp.pre
, erstmp.clm
, erstmp.exp
WHERE clm.rptkey=exp.rptkey
AND clm.rptkey=pre.rptkey
AND exp.parind <> 'Y'
AND clm.rpttype = 'PCD'
AND pre.prefillkey=exp.prefillkey
AND exp.expdate = ( SELECT min(exp1.expdate)
FROM erstmp.pre pre1
, erstmp.clm clm1
, erstmp.exp exp1
WHERE clm1.rptkey=exp1.rptkey
AND clm1.rptkey=pre1.rptkey
AND exp1.parind <> 'Y'
AND clm1.rpttype = 'PCD'
AND pre1.prefillkey=exp1.prefillkey )
AND pre.merchant_name NOT IN ( SELECT pre2.merchant_name
FROM erstmp.pre2
, merchantswhochargetax A2
, erstmp.exp2
, erstmp.clm2
WHERE clm2.rptkey=exp2.rptkey
AND clm2.rptkey=pre2.rptkey
AND exp2.parind <> 'Y'
AND clm22.rpttype = 'PCD'
AND pre.prefillkey=exp2.prefillkey
AND instr(erstmp2.pre.merchant_name, substr(a2.merchantname, 1 , decode(instr(a2.merchantname, '~'), 0, length(a2.merchantname), instr(a2.merchantname, '~'))))>0 -
Query is too slow from bseg selection
SELECT BELNR BLDAT BUDAT XBLNR GJAHR tcode WAERS AWKEY FROM BKPF INTO
TABLE
ITBKPF WHERE BUKRS EQ P_BUKRS AND BELNR IN S_BELNR AND BUDAT IN
P_BUDAT
AND STBLG = ''
AND ( TCODE = 'MIRO' OR
TCODE = 'MR8M' OR
TCODE = 'MB11' OR
TCODE = 'MB1B' OR
TCODE = 'MIGO_GI' OR
TCODE = 'MIGO_TR' OR
TCODE = 'MB1A' ).
IF SY-SUBRC EQ 0.
SORT itBKPF.
ELSE.
MESSAGE 'No data for the relevant date' TYPE 'A'.
LEAVE LIST-PROCESSING.
ENDIF.
SELECT A1LIFNR A1NAME1 A1ORT01 A1STRAS B1~j_1icstno
INTO TABLE it_werks
FROM ( LFA1 AS A1 INNER JOIN j_1imocomp AS B1 ON A1werks = B1werks )
**********************************************this is too slow*************
SELECT BUKRS BELNR GJAHR BUZEI BUZID BSCHL SHKZG GSBER MWSKZ
DMBTR HKONT LIFNR LANDL Matnr werks MENGE EBELP xref3
INTO CORRESPONDING FIELDS OF TABLE ITABBSEG
FROM BSEG
FOR ALL ENTRIES IN ITBKPF
WHERE BELNR = ITBKPF-BELNR
AND GJAHR = ITBKPF-GJAHR
AND ( BSCHL = '86' OR BSCHL = '96' or BSCHL = '89' OR BSCHL = '99' )
AND WERKS IN S_WERKS
AND BUZID <> 'F' .
****************************************this is too slow
Moderator message: Please Read before Posting in the Performance and Tuning Forum
locked by: Thomas Zloch on Aug 5, 2010 2:08 PMYou should have provided the full key of the cluster file behind BSEG (RFBLG), every key is in BKPF, so add BUKRS
SELECT bukrs belnr gjahr buzei buzid bschl shkzg gsber mwskz
dmbtr hkont lifnr landl matnr werks menge ebelp xref3
INTO CORRESPONDING FIELDS OF TABLE itabbseg
FROM bseg
FOR ALL ENTRIES IN itbkpf
WHERE bukrs = itbkpf-bukrs
AND belnr = itbkpf-belnr
AND gjahr = itbkpf-gjahr
AND ( bschl EQ '86' OR bschl EQ '96' OR bschl EQ '89' OR bschl EQ '99' )
AND werks IN s_werks
AND buzid EQ 'F' .
You could also extract the whole accounting document in the internal table, and then delete record using the not-database-key selections.
SELECT bukrs belnr gjahr buzei buzid bschl shkzg gsber mwskz
dmbtr hkont lifnr landl matnr werks menge ebelp xref3
INTO CORRESPONDING FIELDS OF TABLE itabbseg
FROM bseg
FOR ALL ENTRIES IN itbkpf
WHERE bukrs = itbkpf-bukrs
AND belnr = itbkpf-belnr
AND gjahr = itbkpf-gjahr.
DELETE itabbseg WHERE
( bschl NE '86' AND bschl NE '96' AND bschl NE '89' AND bschl NE '99' )
OR NOT ( werks IN s_werks )
OR BUZID NE 'F' .
In both case, perform some tests with tools like SE30 or ST05.
Regards,
Raymond -
Execution of SQL Query to slow
Hey all!!!
I'm using 10g express edition with apex 3.1, when I run this query:
select asig.idasig IDASIG, asig.idAsig "Código Asignatura", asig.idasig ID,substr(asig.codigoasig||' '||asig.nombre,0,40) "Asignatura", p.nombre||' '||p.apellidos "Responsable", t.usuario "Técnico", substr(ea.estado,0,22) "Estado Asignatura", ec.estado "Estado Certificado", cert.idestado
from certificado cert, asignatura asig, histasig ha, profesor p, tecnico t, estado ea, estado ec
where cert.idasig = asig.idasig and
p.idprof = asig.idprof and
t.idtecnico = asig.idtecnico and
*(cert.idasig, cert.fecha) in (select idasig, max(fecha) from certificado group by idasig) and*
ec.idestado = cert.idestado and
ha.idasig = asig.idasig and
*(ha.idasig, ha.fecha) in (select idasig, max(fecha) from histasig group by idasig) and*
ea.idestado = ha.idestado
It gets too slow, making the query gets results in approximately 149s.
Someone can give me an idea...
PD:The case is that we have another query that make almost the same but with this one I get the results in less than 1s.These are the results:
TKPROF: Release 10.2.0.1.0 - Production on Mar Feb 10 10:35:58 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Trace file: C:\oraclexe\app\oracle\admin\XE\udump\xe_ora_4724.trc
Sort options: prsela exeela fchela
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
select asig.idasig ID1, asig.idAsig ID2, asig.idasig ID3,asig.codigoasig, asig.nombre, p.nombre,p.apellidos,t.usuario,ea.estado,ec.estado,cert.idestado
from certificado cert, asignatura asig, histasig ha, profesor p, tecnico t, estado ea, estado ec
where cert.idasig = asig.idasig and
p.idprof = asig.idprof and
t.idtecnico = asig.idtecnico and
(cert.idasig, cert.fecha) in (select idasig, max(fecha) from certificado group by idasig) and
ec.idestado = cert.idestado and
ha.idasig = asig.idasig and
(ha.idasig, ha.fecha) in (select idasig, max(fecha) from histasig group by idasig) and
ea.idestado = ha.idestado
call count cpu elapsed disk query current rows
Parse 1 0.15 0.14 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 64 102.17 102.43 0 369673 0 937
total 66 102.32 102.57 0 369673 0 937
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 36
Rows Row Source Operation
937 NESTED LOOPS (cr=369673 pr=0 pw=0 time=102241172 us)
937 NESTED LOOPS (cr=368672 pr=0 pw=0 time=103609539 us)
937 NESTED LOOPS (cr=5030 pr=0 pw=0 time=97377 us)
937 NESTED LOOPS (cr=3082 pr=0 pw=0 time=72064 us)
937 NESTED LOOPS (cr=2081 pr=0 pw=0 time=55194 us)
947 HASH JOIN RIGHT SEMI (cr=44 pr=0 pw=0 time=22573 us)
947 VIEW VW_NSO_1 (cr=17 pr=0 pw=0 time=4100 us)
947 HASH GROUP BY (cr=17 pr=0 pw=0 time=3151 us)
1659 INDEX FAST FULL SCAN PK_CERTIFICADO (cr=17 pr=0 pw=0 time=1728 us)(object id 15811)
1659 MERGE JOIN (cr=27 pr=0 pw=0 time=11173 us)
39 TABLE ACCESS BY INDEX ROWID ESTADO (cr=10 pr=0 pw=0 time=286 us)
39 INDEX FULL SCAN PK_ESTADO (cr=5 pr=0 pw=0 time=95 us)(object id 15790)
1659 SORT JOIN (cr=17 pr=0 pw=0 time=7693 us)
1659 INDEX FAST FULL SCAN PK_CERTIFICADO (cr=17 pr=0 pw=0 time=42 us)(object id 15811)
937 TABLE ACCESS BY INDEX ROWID ASIGNATURA (cr=2037 pr=0 pw=0 time=31871 us)
947 INDEX UNIQUE SCAN PK_ASIGNATURA (cr=1011 pr=0 pw=0 time=16230 us)(object id 15797)
937 TABLE ACCESS BY INDEX ROWID TECNICO (cr=1001 pr=0 pw=0 time=14632 us)
937 INDEX UNIQUE SCAN PK_TECNICO (cr=64 pr=0 pw=0 time=6532 us)(object id 15777)
937 TABLE ACCESS BY INDEX ROWID PROFESOR (cr=1948 pr=0 pw=0 time=20712 us)
937 INDEX UNIQUE SCAN PK_PROFESOR (cr=1001 pr=0 pw=0 time=11554 us)(object id 15795)
937 INDEX RANGE SCAN PK_HISTASIG (cr=363642 pr=0 pw=0 time=102276685 us)(object id 15809)
937 FILTER (cr=361692 pr=0 pw=0 time=101967826 us)
64914543 HASH GROUP BY (cr=361692 pr=0 pw=0 time=139395915 us)
94619691 INDEX FAST FULL SCAN PK_HISTASIG (cr=361692 pr=0 pw=0 time=94752646 us)(object id 15809)
937 TABLE ACCESS BY INDEX ROWID ESTADO (cr=1001 pr=0 pw=0 time=39308 us)
937 INDEX UNIQUE SCAN PK_ESTADO (cr=64 pr=0 pw=0 time=15348 us)(object id 15790)
alter session set sql_trace true
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 36
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 1 0.15 0.14 0 0 0 0
Execute 2 0.00 0.00 0 0 0 0
Fetch 64 102.17 102.43 0 369673 0 937
total 67 102.32 102.57 0 369673 0 937
Misses in library cache during parse: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 0 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
2 user SQL statements in session.
0 internal SQL statements in session.
2 SQL statements in session.
Trace file: C:\oraclexe\app\oracle\admin\XE\udump\xe_ora_4724.trc
Trace file compatibility: 10.01.00
Sort options: prsela exeela fchela
1 session in tracefile.
2 user SQL statements in trace file.
0 internal SQL statements in trace file.
2 SQL statements in trace file.
2 unique SQL statements in trace file.
147 lines in trace file.
134 elapsed seconds in trace file.We had seen that the possible problems are here:
937 INDEX RANGE SCAN PK_HISTASIG (cr=363642 pr=0 pw=0 time=102276685 us)(object id 15809)
64914543 HASH GROUP BY (cr=361692 pr=0 pw=0 time=139395915 us)
94619691 INDEX FAST FULL SCAN PK_HISTASIG (cr=361692 pr=0 pw=0 time=94752646 us)(object id 15809)The time spent is too much, but we don't see how can we solve this problem, any idea? -
Newbie - help needed with array and dictionary objects
Hi all
Please see the code below. I've posted this code in another thread however the original issue was resolved and this is now a new issue I'm having although centered around the same code.
The issue is that I'm populating an array with dictionary objects. each dictionary object has a key and it's value is another array of custom objects.
I've found that the code runs without error and I end up with my array as I'm expecting however all of the dictionary objects are the same.
I assume it's something to do with pointers and/or re-using the same objects but i'm new to obj-c and pointers so i am a bit lost.
Any help again is very much appreciated.
// Open the database connection and retrieve minimal information for all objects.
- (void)initializeDatabase {
NSMutableArray *authorArray = [[NSMutableArray alloc] init];
self.authors = authorArray;
[authorArray release];
// The database is stored in the application bundle.
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *documentsDirectory = [paths objectAtIndex:0];
NSString *path = [documentsDirectory stringByAppendingPathComponent:@"books.sql"];
// Open the database. The database was prepared outside the application.
if (sqlite3_open([path UTF8String], &database) == SQLITE_OK) {
// Get the primary key for all books.
const char *sql = "SELECT id, author FROM author";
sqlite3_stmt *statement;
// Preparing a statement compiles the SQL query into a byte-code program in the SQLite library.
// The third parameter is either the length of the SQL string or -1 to read up to the first null terminator.
if (sqlite3preparev2(database, sql, -1, &statement, NULL) == SQLITE_OK) {
// We "step" through the results - once for each row.
// We start with Letter A...we're building an A - Z grouping
NSString *letter = @"A";
NSMutableArray *tempauthors = [[NSMutableArray alloc] init];
while (sqlite3_step(statement) == SQLITE_ROW) {
author *author = [[author alloc] init];
author.primaryKey = sqlite3columnint(statement, 0);
author.title = [NSString stringWithUTF8String:(char *)sqlite3columntext(statement, 0)];
// FOLLOWING WAS LEFT OVER FROM ORIGINAL COMMENTS IN SQLBooks example....
// We avoid the alloc-init-autorelease pattern here because we are in a tight loop and
// autorelease is slightly more expensive than release. This design choice has nothing to do with
// actual memory management - at the end of this block of code, all the book objects allocated
// here will be in memory regardless of whether we use autorelease or release, because they are
// retained by the books array.
// if the author starts with the Letter we currently have, add it to the temp array
if ([[author.title substringToIndex:1] compare:letter] == NSOrderedSame){
[tempauthors addObject:author];
} // if this is different letter, then we need to deal with that too...
else {
// create a dictionary to store the current tempauthors array in...
NSDictionary *tempDictionary = [NSDictionary dictionaryWithObject:tempauthors forKey:@"authors"];
// add the dictionary to our appDelegate-level array
[authors addObject:tempDictionary];
// now prepare for the next loop...
// set the new letter...
letter = [author.title substringToIndex:1];
// remove all of the previous authors so we don't duplicate...
[tempauthors removeAllObjects];
// add the current author as this was the one that didn't match the Letter and so
// never went into the previous array...
[tempauthors addObject:author];
// release ready for the next loop...
[author release];
// clear up the remaining authors that weren't picked up and saved in the "else" statement above...
if (tempauthors.count > 0){
NSDictionary *tempDictionary = [NSDictionary dictionaryWithObject:tempauthors forKey:@"authors"];
[authors addObject:tempDictionary];
else {
printf("Failed preparing statement %s
", sqlite3_errmsg(database));
// "Finalize" the statement - releases the resources associated with the statement.
sqlite3_finalize(statement);
} else {
// Even though the open failed, call close to properly clean up resources.
sqlite3_close(database);
NSAssert1(0, @"Failed to open database with message '%s'.", sqlite3_errmsg(database));
// Additional error handling, as appropriate...
Message was edited by: dotnetterOk, so I know what the issue is now...I just don't know enough to be able to resolve it!
it's the tempAuthors objects.
It's an NSMutableArray which is create on the line before the start of the WHILE loop.
Having looked through the debugger, I can see that each dictionary object is created (with different codes which I assume are memory addresses) so all is well there. However, on each iteration of the loop in the middle there is an IF...ELSE... statement which in the ELSE section is clearing all objects from the tempAuthors array and beginning to repopulate it again.
Looking at the containing dictionary objects in the debugger I can see that the tempAuthors object that each contains has the same code (again, I'm assuming this is a memory address) - so if I understand correctly, it's the same object...I assumed that when I created the dictionary using the dictionWithObject call that I would be passing in a copy of the object, but it's referencing back to the object which I then go on to change.
Assuming the above is correct, I've tried several "stabs in the dark" at fixing it.
I've tried relasing the tempAuthors object within the ELSE and initialising it again via an alloc...init - but this didn't work and again looking through the debugger it looks as though it was confused as to which object it was supposed to be using on the following iteration of the WHILE loop (it tried to access the released object).
Having read a little more about memory management can someone tell me if I'm correct in saying that the above is because the tempAuthors object is declare outside the scope of the WHILE loop yet I then try to re-instantiate it within the loop (does that make sense???).
Sorry for the long post...the more I can understand the process the less I can hopefully stop relying on others for help so much.
I am continuing to read up on memory management etc but just not there yet.
Regards
Wayne -
Select Data from aufm too slow
Hi experts,
I have a query in my report but its performance too slow.
is there any proper way or any way to improve the performance of below query.
SELECT * FROM aufm into table i_aufm " collecting input material document numbers
WHERE mblnr GE '4900000000'
AND mjahr GE '2008'
AND zeile GT '0'
AND matnr EQ matnr_101-matnr
AND werks IN p_werks
AND charg EQ matnr_101-charg
AND bwart = '101'.Hi,
1 .Dont use * from any table.
2. Create a internal table that u want to retrieve the data from that table. (Structure).
Eg:
types : begin of str_ekko,
ebeln type ekko-ebeln,
bsart type ekko-bsart,
aedat type ekko-aedat,
endof str_ekko.
data : itab type table of str_ekko,
wa_itab type str_ekko.
In the above u want to take care that while creating the structure u want to look the sequence of fields in the table. in the same sequence u want to create the structure.
3 . The Select-options fields also wants be in the same field sequence of the table.
eg : select ebeln bsart aedat from ekko into table itab where ebeln in so_ebeln and
bsart in so_bsart and
aedat in so_aedat.
4. If the above things are not working just look the indexes of that table. Just create a secondary index with ur requirement. -
Performance is too slow on SQL Azure box
Hi,
Performance is too slow on SQL Azure box (Located in Europe)
Below query returns 500,000 rows in 18 Min. on SQL Azure box (connected via SSMS, located in India)
SELECT * FROM TABLE_1
Whereas, on local server it returns 500,000 rows in (30 sec.)
SQL Azure configuration:
Service Tier/Performance Level : Premium/P1
DTU : 100
MAX DB Size : 500GB
Max Worker Threads : 200
Max Sessions : 2400
Benchmark Transaction Rate : 105 transactions per second
Predictability : Best
Any suggestion would be highly appreciated.
Thanks,Hello,
Can you please explain in a little more detail the scenario you testing? Are you comparing a SQL Database in Europe against a SQL Database in India? Or a SQL Database with a local, on-premise SQL Server installation?
In case of the first scenario, the roundtrip latency for the connection to the datacenter might play a role.
If you are comparing to a local installation, please note that you might be running against completely different hardware specifications and without network delay, resulting in very different results.
In both cases you can use the below blog post to assess the resource utilization of the SQL Database during the operation:
http://azure.microsoft.com/blog/2014/09/11/azure-sql-database-introduces-new-near-real-time-performance-metrics/
If the DB utilizes up to 100% you might have to consider to upgrade to a higher performance level to achieve the throughput you are looking for.
Thanks,
Jan -
Flashback and transaction query very slow
Hello. I was wondering if anyone else has seen transaction queries be really slow and if there is anything I can do to speed it up? Here is my situation:
I have a database with about 50 tables. We need to allow the user to go back to a point in time and "undo" what they have done. I can't use flashback table because multiple users can be making changes to the same table (different records) and I can't undo what the other users have done. So I must use the finer granularity of undoing each transaction.
I have not had a problem with the queries, etc. I basically get a cursor to all the transactions in each of the tables and order them backwards (since all the business rules must be observed). However, getting this cursor takes forever. From that cursor, I can execute the undo_sql. In fact, I once had a cursor that did "union all" on each table and even if the user only modified 1 table, it took way too long. So now I do a quick count based on the ROWSCN (running 10g and tables have ROWDEPENDANCIES) being in the time needed to find out if this table has been touched. Based on that, I can create a cursor only for the tables that have been touched. This helps. But it is still slow especially compared to any other query I have. And if the user did touch a lot of tables, it is still way too slow.
Here is an example of part of a query that is used on each table:
select xid, commit_scn, logon_user, undo_change#, operation, table_name, undo_sql
from flashback_transaction_query
where operation IN ('INSERT', 'UPDATE', 'DELETE')
and xid IN (select versions_xid
from TABLE1
versions between SCN p_scn and current_scn
where system_id = p_system_id)
and table_name = UPPER('TABLE1')Any help is greatly appreciated.
-CarmineAnyone?
Thanks,
-Carmine -
Pl/sql block is too slow, should procedure a better option
Hi all,
how to tune A PL/SQL block that traverse cursors and fetch millions of records then execute inserts in different tables,
using execute immediate statement.
It's too slow and takes 10 hours to populate 40 tables having millions of records,
as i have to do some modifications in data so can not do it by CTAS,
i.e. a single sql statement.
Should i make a procedure, does it help .
Please help or suggest As i am New to PL/Sql
My code look like,
declare
cursor cur_table1 is
select field1,field2,field3,field4 from table1;
begin
for i in cur_table1
loop
execute immediate 'insert into table2 (field1,field2,field3,field4) '||
'select :1,field2,field3,field4 '||
' from table1 where field3= :2'
using i.field1||'_'||to_char(sysdate,'ddmmyyyy hh12:mi:ss',i.field1;
commit;
end if;
end;
Thanks and Regards,declare
cursor cur_projects is
select PROJECTID, PROJECTNAME, DESCRIPTION, DELETED, DELETINGDATE, ACTIVE, ADMINONLY, READONLY, SECURITYCLASS, PROJECTCONTACT, DEFAULTVERSION, DEFAULTSTARTPAGE, IMAGEPATH, MAXEXAMINEERRORS, LOCKTIMEOUT, MEMORYSAVINGLEVEL, PRELOADOBJECTS, PUBLICATIONSRCPROJNAME, CREATOR, CREATED, MODIFIER, MODIFIED from projects ;
cursor cur_projectversion(p_projectid projects.projectid%TYPE) is
select PROJECTID, PROJECTVERSIONID, PROJECTVERSIONNAME, DESCRIPTION, DELETED , DELETINGDATE, ACTIVE , ADMINONLY, READONLY, decode(EFFECTIVEDATE,null,trunc(sysdate),EFFECTIVEDATE) EFFECTIVEDATE, EXPIRATIONDATE, SECURITYCLASS, PROJECTCONTACT, DEFAULTVERSION, DEFAULTSTARTPAGE, IMAGEPATH, MAXEXAMINEERRORS, LOCKTIMEOUT, MEMORYSAVINGLEVEL, PRELOADOBJECTS, PUBLICATIONSRCPROJNAME, PUBLICATIONSRCPROJVERNAME, CREATOR, CREATED, MODIFIER, MODIFIED, PROFILELOADERCLASS /*, TRACKCHANGES */
from projectversions where PROJECTID=p_projectid ;
cursor cur_objects(p_projectid projects.projectid%TYPE,p_projectversionid projectversions.projectversionid%TYPE) is
select PROJECTID , PROJECTVERSIONID, OBJECTID , OBJECTKEY , PARENTID, KIND , NAME , TITLE , OWNER , CREATED, MODIFIER , MODIFIED , READY_TO_PUBLISH, LAST_PUBLISHED_DATE , LAST_PUBLISHER , EFFECTIVE_PUBLISHING_DATE , PUBLISHER , PUBLISHING_DATE /*, to_lob(scripttext) */ from OBJECTS where PROJECTID=p_projectid and PROJECTVERSIONID=p_projectversionid /*order by objectid */;
begin
for i in cur_projects
loop
dbms_output.put_line('PROJECTID => '||i.projectid);
dbms_output.put_line('_________________________________');
execute immediate 'insert into &TARGET_USER\.projects(locktimeout, memorysavinglevel , preloadobjects, projectid, projectname, description, deleted, deletingdate, active, adminonly, readonly, securityclass, projectcontact, defaultversion, defaultstartpage, imagepath, maxexamineerrors ) values (:1,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11,:12,:13,:14,:15,:16,:17) '
using i.locktimeout, i.memorysavinglevel, i.preloadobjects,i.projectid ,i.projectname , i.description , i.deleted , i.deletingdate , i.active , i.adminonly , i.readonly, i.securityclass, i.projectcontact , i.defaultversion, i.defaultstartpage , i.imagepath, i.maxexamineerrors;
for k in cur_projectversion(i.projectid)
loop
for l in cur_objects(k.projectid,k.projectversionid)
loop
cnt:=cnt+1;
select count(1) into object_exists from &TARGET_USER\.objects where objectid=l.objectid and projectversionid=1 and projectid=l.projectid;
if object_exists = 0
then
if l.objectid = 1 ------Book Object , objectid = 1 and parentid = 0
then
execute immediate 'INSERT INTO &TARGET_USER\.objects(PROJECTID,PROJECTVERSIONID,OBJECTID, OBJECTKEY,PARENTID,NAME, KIND,LAST_PUBLISHED_DATE,LAST_PUBLISHER,REVISIONID,DISPLAYORDER,READONLY,DELETED) values( :1,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11,:12,:13)'
using l.PROJECTID, 1, l.OBJECTID,l.OBJECTKEY, 0 , l.NAME,l.KIND, '' , '' , '', 0, 'N', 'N';
else
select count(1) into object_parentid_exists from objects where objectid=l.parentid and projectversionid=1 and projectid=l.projectid;
if object_parentid_exists = 0 ---Set Parentid as 1
then
cnt_parentid_1:=cnt_parentid_1+1;
execute immediate 'INSERT INTO &TARGET_USER\.objects(PROJECTID,PROJECTVERSIONID,OBJECTID, OBJECTKEY,PARENTID,NAME, KIND,LAST_PUBLISHED_DATE,LAST_PUBLISHER,REVISIONID,DISPLAYORDER,READONLY,DELETED) values( :1,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11,:12,:13)'
using l.PROJECTID, 1, l.OBJECTID,l.OBJECTKEY, 1 , l.NAME,l.KIND, '' , '' , '', 0, 'N', 'N';
else
execute immediate 'INSERT INTO &TARGET_USER\.objects(PROJECTID,PROJECTVERSIONID,OBJECTID, OBJECTKEY, PARENTID, NAME, KIND,LAST_PUBLISHED_DATE,LAST_PUBLISHER,REVISIONID,DISPLAYORDER,READONLY,DELETED) values( :1,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11,:12,:13)'
using l.PROJECTID, 1, l.OBJECTID,l.OBJECTKEY,l.PARENTID,l.NAME,l.KIND, '' , '' , '', 0, 'N', 'N';
end if;
end if ;
end if;
execute immediate 'INSERT INTO &TARGET_USER\.objectversions( PROJECTID, OBJECTID, PROJECTVERSIONID ,VERSIONNAME,OBJECTVERSIONID, REVISIONID,DESCRIPTION, TITLE , OWNER, CREATED, MODIFIER, MODIFIED, READY_TO_PUBLISH , LAST_PUBLISHED_DATE, LAST_PUBLISHER, EFFECTIVEDATE, SCRIPTTEXT, REVIEWSTATUS, READONLY, PUBLISHED, DELETED ) '||
'SELECT PROJECTID, OBJECTID, 1, owner||:1, PROJECTVERSIONID , '''', '''', TITLE, OWNER, CREATED, MODIFIER, MODIFIED, ''N'', '''' , '''', :2 , to_lob(SCRIPTTEXT), '''', ''N'', ''N'', '''' '||
'FROM OBJECTS '||
'WHERE PROJECTID= :3 and PROJECTVERSIONID= :4 and OBJECTID= :5'
using '_'||TO_CHAR(k.EFFECTIVEDATE,'DDMMYYHHMISS'),k.EFFECTIVEDATE,l.projectid,l.projectversionid,l.objectid;
end loop;
dbms_output.put_line(cnt||' OBJECTS, OBJECTVERIONS POPULATED');
dbms_output.put_line(cnt_parentid_1||' DUMPED UNDER BOOK FOLDER ');
cnt_parentid_1:=0;
cnt:=0;
............ -
"Core Audio Error Disk Too Slow" On Stage?
i use logic pro on my macbook pro(2gb ram 2,16ghz) and i'm completely satisfied with this combination.
Only when i'm playing live(electro music - loud environment - lots of sub/bass etc.) i sometimes get the message disk too slow/system overload, although i'm only playing some aiff files and some softsynths to it...
is it possible that my external disk(lacie d2 FW400) is skipping due to vibrations or is my Sudden Motion Sensor stepping in? i disabled it already... anyone the same problems or even an answer
thx in advance...
Macbook Pro Mac OS X (10.4.9) 2 gb RamIf you can afford it buy one of these http://www.sonnettech.com/product/temposataexpress34.html
and an external sata drive - sonett also make them http://www.sonnettech.com/product/fusion.html
Or any external sata drive will work if you only need the one drive. The sonett is good as it does port multiplying meaning you can have up to 10 drives running on your laptop
Although a quicker and cheaper fix could be to try putting the lacie on some neoprene. - this will cut out "most of the" bass thats transferring from say the stage to the drive, but it wont help if the bass is really loud as it is more than likely the airborne bass that is causing the errors.
If money is no object the sonnet solution is very good and in theory would be rock solid running in raid and mounted on neoprene.
Just a thought....
G5 DUAL 2.7GHZ 4 GIG RAM and G5 DUAL 2.5GHZ running as node, macbook pro 2.33 3 gig ram Mac OS X (10.4.9) Yamaha DM2000 -
Hi,
I've got a query running fast (3 sec.)
If I try to execute it on test enviroment, it takes about 2 minutes (!)
I see in both enviroments the explain plan is the same and so are the indexes used. I've also tried to rebuild the indexes and the tables that looked quite fragmented in test, but the result is always the same. Could it be that our test enviroment is slower and with lower performances? What else could I check? (Oracle Vers. is 8.1.7)
Thanks!812809 wrote:
steps to follow:
1.whether the candidate columns has index or notSometimes and index can cause a query to slow down rather than speed up, especially if a person has created too many indexes on a table and the optimiser can't figure out the best one to use.
2.go for explain plan and look the query not to fall under the category of Full Table ScanFull table scans are not always a bad thing. Sometimes they are faster than using the index. It depends. -
Getting attribute properties from client tier is too slow
Getting properties for view object attributes is too slow, because a called to the server is made for every attribute.
I noticed that when a property is gotten for an attribute all properties are retrieved for it, but I couldn't found a way to get all properties for all attributes in the ViewObject.See ApplicationModule.fetchAttributeProperties and it's usage in JClient in JDeveloper 9.0.3
-
Since upgrading to 4.1 LR has become too slow to use.
The problem lies primarily, but not restricted to, the noise reduction sliders. The luminance slider specifically.
Unless I can fix something I will have to return to an older version, Im actually thinking of going back to 3.6 which worked fine on my machine - AMD E2, Dual Core graphics, 4gm RAM.
Please help.The queries are the same across all three database platforms and have been examined by our dba's and run through SQL Server optimizer to get the access path. All queries are very simple...the system was originally written in Btrieve. It is "record at a time" in nature. The program that does the screen refresh does three seperate queries...all something like, select * from tablename where key = 'abc'. The program then combines the data into a single record and returns the results. Like I said...SQL Server 1 second. Each of the three tables has 30,000 records, all with unique keys. The data returned to the application is probably 50 records, each 200 bytes...all character data. All tests were done with the same workstation on the same LAN....I don't think LAN latency is the problem here. Using other query tools, the response back is good, as expected.
Another example...at application startup, we load all of the metadata (columns, primary key segments and index segments) into memory using the standard odbc api calls...SQLColumns, SQLPrimaryKeys and SQLStatistics. SQL Server loads this in maybe 8-10 seconds while Oracle loads in 15 minutes at best. These queries we don't control and it is still unbelievably slow. Again, using the ODBCTEST utility, the results for these api's come back pretty quick.
If it is our application causing the problem in some way then it should be equally slow across all platforms, right?
By the way, we had one of your Oracle Consultants in house trying to solve the metadata problem and he was unable to find any problem in our application and had no answers for us.
Thanks for the quick response.
Lon Diehl -
BI Server performance too slow
Hi experts,
I am facing an issue, my OBIEE sits on a Unix Platform. And many time the server performance is too slow, when I check the processes, Java under Orabi user is using more than 50% of the CPU utilization. I need to find the root cause behind it, as it is the production system and is affecting many users.
Thanks in advance.
MTThanks Prassu,
Yes the Server is performing too much calculations, but they are required as need to cache reports at daily level also,
I have an observation that the MAX_CACHE_ENTRY_SIZE [MAX_CACHE_ENTRY_SIZE = 1 MB;] parameter is set only for 1 MB, I can understand that if any query fetching more data than 1 MB will not be cached. But is there any chance that this will affect the server as well.
Thanks
MT -
Please anyone with expirience in applets accessing MySQL Server!
I made a test with a loop code executing queries and got the following conclusion:
In media a query takes more than 2 seconds. I used PrepareStatement for better performance but it doesn�t make it better. I�ve heart about persistent connection. It�s realy faster? You know anything I could do for better performance? Obs.: When I ping my server the time answer is 200 ms. I�m from Brazil. But I think it sholdn�t make the mysql too slow as it is. Please help me.....
I�m very thank for ur help..
My java code:
public void ConectaBD()
try
Class.forName("com.mysql.jdbc.Driver").newInstance();
//Class.forName("org.gjt.mm.mysql.Driver").newInstance();
catch(Exception e)
System.out.println("Error: " + e);
try
con = DriverManager.getConnection("jdbc:mysql://labinfor.com.br/labinfor_codvirtual?user=labinfor_cliente&password=800091");
catch(SQLException e)
System.out.println("Error: " + e );
e.printStackTrace();
public void Logon()
java.util.Date start = new java.util.Date();
long startTime = start.getTime();
if (ValidaCPF(TFCPF.getText()))
queryLogon = "SELECT Nome FROM clientes WHERE CPF='" + TFCPF.getText().trim() + "' AND senha='" + TFSenha.getText() + "'";
int indCon=0;
Timer t = new Timer(1000, this);
t.start();
while(indCon<100)
Conecta();
try
stmt[indStmt] = con.createStatement();
rsLogon = stmt[indStmt].executeQuery(queryLogon);
Achou = "false";
while (rsLogon.next())
Achou = "true";
StrNome = rsLogon.getString(1);
LValidaCPF.setText("Bem-vindo " + StrNome);
TFCPF.disable();
TFSenha.disable();
BLogon.setLabel("Logoff");
System.out.println("delay["+indCon+"]= "+System.currentTimeMillis());
if (Achou == "false")
LValidaCPF.setText("CPF ou senha incorreto");
Desconecta();
catch(Exception e)
System.out.println("Error: " + e);
indCon+=1;
}Connection times of 1 to 5 seconds are normal. Pool your connections.
To understand why:
First, setting up a TCP/IP connection takes roughly 50% longer than a ping; a ping is one packet to the server and one packet back, a TCP/IP handshake to create a connection is one packet to the server, one back, and another to the server. Then you have a required brief wait before the connection is considered complete; we'll ignore the wait and call it .3 seconds for the TCP/IP handshake.
Second, the database has to go through the login process. Just sending the login request and response is yet another packet round trip; in your case, that's another .2 seconds in just network time alone. With MySQL, the login involves checking the security of the connection and the user; it often requires a reverse DNS lookup on the IP address of the client. Probably 4 or 5 tables have to be queried and a user environment is created within the server. The server work for the login might take .75 seconds, at a guess. Adding the network time makes this step .95 seconds or so.
Third, there's the time it takes to do the query itself; another network round trip; .2 second network round trip, plus maybe .1 second to run the query on the database, for a total of .3 seconds.
Fourth, there's the time it takes to tear down the TCP/IP connection on connection close. That involves 4 packets, 2 round-trips, so add another .4 seconds.
Adding it all up, you get .3 + .95 + .3 + .4 = 1.95 seconds, of which .3 is your SQL query (network and DB time), .9 is network time for TCP/IP connection and login request, and .75 is DB time for the login.
Maybe you are looking for
-
I installed a new SSD drive in my computer and now Adobe Creative Suite Web Premium says I don't have a license. I have license. It was very expensive. I am disabled now, and I need this software working. Adobe Acrobat has been a primary tool for acc
-
COPA realignment in R/3 and affect in BW
Hello Everyone, When realignment is done in R/3 the delta in BW that has been running is "deactivated". So a new delta init must be done. With this said, is it correct that all data in the InfoProvider (that is within the timeframe of the delta), m
-
Pop-up Blocker with adobe on BT-Yahoo under IE9
I have installed BT-yahoo software with IE9 on Windows 7. Since the upgrade I am no longer statements or bills from bank or Electricity company when I request them. Their sites suggest adding the site address to pop-up blocker settings. This does not
-
Why does my iPad display Calendar info like all vertical?
My iPad is displaying Weekly Calendar info in a very odd vertical manner...anyone? Difficult to describe, is there a way to include images in this forum?
-
Can we have UPK on Oracle Project billing ie for Contract Projects???
Can we have UPK on Oracle Project billing ie for Contract Projects???