Select query in ms-access
hai to all
iam new to java
what is select query in ms-access with where condition?
is this query work in ms-access
rsAdmnno=stAdmnno.executeQuery("select * from StudentDetails where Admnno=''"+Admnno+"'");
here Admnno is the field name
and student details is the table name is it works
please help me
thanks
Never used access myself. Your statement looks okay and you didn't mention a specific problem, are you getting an error message?
Here is a guide on SQL for access
http://www.adit.co.uk/html/sql_for_access.htm
Similar Messages
-
Oracle SQL Select query takes long time than expected.
Hi,
I am facing a problem in SQL select query statement. There is a long time taken in select query from the Database.
The query is as follows.
select /*+rule */ f1.id,f1.fdn,p1.attr_name,p1.attr_value from fdnmappingtable f1,parametertable p1 where p1.id = f1.id and ((f1.object_type ='ne_sub_type.780' )) and ( (f1.id in(select id from fdnmappingtable where fdn like '0=#1#/14=#S0058-3#/17=#S0058-3#/18=#1#/780=#5#%')))order by f1.id asc
This query is taking more than 4 seconds to get the results in a system where the DB is running for more than 1 month.
The same query is taking very few milliseconds (50-100ms) in a system where the DB is freshly installed and the data in the tables are same in both the systems.
Kindly advice what is going wrong??
Regards,
PurushothamSQL> @/alcatel/omc1/data/query.sql
2 ;
9 rows selected.
Execution Plan
Plan hash value: 3745571015
| Id | Operation | Name |
| 0 | SELECT STATEMENT | |
| 1 | SORT ORDER BY | |
| 2 | NESTED LOOPS | |
| 3 | NESTED LOOPS | |
| 4 | TABLE ACCESS FULL | PARAMETERTABLE |
|* 5 | TABLE ACCESS BY INDEX ROWID| FDNMAPPINGTABLE |
|* 6 | INDEX UNIQUE SCAN | PRIMARY_KY_FDNMAPPINGTABLE |
|* 7 | TABLE ACCESS BY INDEX ROWID | FDNMAPPINGTABLE |
|* 8 | INDEX UNIQUE SCAN | PRIMARY_KY_FDNMAPPINGTABLE |
Predicate Information (identified by operation id):
5 - filter("F1"."OBJECT_TYPE"='ne_sub_type.780')
6 - access("P1"."ID"="F1"."ID")
7 - filter("FDN" LIKE '0=#1#/14=#S0058-3#/17=#S0058-3#/18=#1#/780=#5#
8 - access("F1"."ID"="ID")
Note
- rule based optimizer used (consider using cbo)
Statistics
0 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
0 bytes sent via SQL*Net to client
0 bytes received via SQL*Net from client
0 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
9 rows processed
SQL> -
Performance issue with select query and for all entries.
hi,
i have a report to be performance tuned.
the database table has around 20 million entries and 25 fields.
so, the report fetches the distinct values of two fields using one select query.
so, the first select query fetches around 150 entries from the table for 2 fields.
then it applies some logic and eliminates some entries and makes entries around 80-90...
and then it again applies the select query on the same table using for all entries applied on the internal table with 80-90 entries...
in short,
it accesses the same database table twice.
so, i tried to get the database table in internal table and apply the logic on internal table and delete the unwanted entries.. but it gave me memory dump, and it wont take that huge amount of data into abap memory...
is around 80-90 entries too much for using "for all entries"?
the logic that is applied to eliminate the entries from internal table is too long, and hence cannot be converted into where clause to convert it into single select..
i really cant find the way out...
please help.chinmay kulkarni wrote:Chinmay,
Even though you tried to ask the question with detailed explanation, unfortunately it is still not clear.
It is perfectly fine to access the same database twice. If that is working for you, I don't think there is any need to change the logic. As Rob mentioned, 80 or 8000 records is not a problem in "for all entries" clause.
>
> so, i tried to get the database table in internal table and apply the logic on internal table and delete the unwanted entries.. but it gave me memory dump, and it wont take that huge amount of data into abap memory...
>
It is not clear what you tried to do here. Did you try to bring all 20 million records into an internal table? That will certainly cause the program to short dump with memory shortage.
> the logic that is applied to eliminate the entries from internal table is too long, and hence cannot be converted into where clause to convert it into single select..
>
That is fine. Actually, it is better (performance wise) to do much of the work in ABAP than writing a complex WHERE clause that might bog down the database. -
Getting deadlock detected while waiting for resource error for select Query.....
Hi all,
i am getting a below error whenever executing the below select query....
some times it will show dead lock detected while waiting for resource and terminated...
some times it executes and gives result..
but all the time it writes an alert to alert log
Plesae suggest how to resolve the issue..........
Thanks in advance
Env: Linux / Oracle 11.2.0.3.3
Error from alert log:
Errors in file /u01/oracle/oracle/diag/rdbms/bdrdb/bdrdb/trace/bdrdb_p017_6076.trc:
ORA-00060: deadlock detected while waiting for resource
ORA-10387: parallel query server interrupt (normal)
Trace file info... bdrdb_p017_6076.trc:
Trace file /u01/oracle/oracle/diag/rdbms/bdrdb/bdrdb/trace/bdrdb_p017_6076.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /u01/oracle/oracle/product/11.2.0/dbhome_1
System name: Linux
Node name: bdrdb.cteplindia.com
Release: 2.6.18-308.el5PAE
Version: #1 SMP Fri Jan 27 17:40:09 EST 2012
Machine: i686
Instance name: bdrdb
Redo thread mounted by this instance: 1
Oracle process number: 92
Unix process pid: 6076, image: [email protected] (P017)
*** 2013-11-04 23:18:57.915
*** SESSION ID:(423.59970) 2013-11-04 23:18:57.915
*** CLIENT ID:() 2013-11-04 23:18:57.915
*** SERVICE NAME:(bdrdb) 2013-11-04 23:18:57.915
*** MODULE NAME:() 2013-11-04 23:18:57.915
*** ACTION NAME:() 2013-11-04 23:18:57.915
*** 2013-11-04 23:18:57.915
DEADLOCK DETECTED ( ORA-00060 )
[Transaction Deadlock]
Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
PS-00000001-00000011 92 423 S 33 128 S X
BF-2ed08c01-00000000 33 128 S 92 423 S X
session 423: DID 0001-005C-00081126 session 128: DID 0001-0021-00067D23
session 128: DID 0001-0021-00067D23 session 423: DID 0001-005C-00081126
DEADLOCK DETECTED ( ORA-00060 )
[Transaction Deadlock]
Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
PS-00000001-00000011 92 423 S 33 128 S X
BF-2ed08c01-00000000 33 128 S 92 423 S X
session 423: DID 0001-005C-00081126 session 128: DID 0001-0021-00067D23
session 128: DID 0001-0021-00067D23 session 423: DID 0001-005C-00081126
Rows waited on:
Session 423: no row
Session 128: obj - rowid = 00021DC1 - AAAh3BAAVAAAQL/AAA
(dictionary objn - 138689, file - 21, block - 66303, slot - 0)
----- Information for the OTHER waiting sessions -----
Session 128:
sid: 128 ser: 46176 audsid: 1836857 user: 102/DBLOCAL
flags: (0x8000041) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
flags2: (0x40009) -/-/INC
pid: 33 O/S info: user: oracle, term: UNKNOWN, ospid: 31611
image: [email protected]
client details:
O/S info: user: masked, term: masked, ospid: 5924:568
machine: masked program: Toad.exe
application name: TOAD background query session, hash value=526966934
current SQL:
application name: TOAD background query session, hash value=526966934
current SQL:
SELECT DISTINCT B_FP_TEST.TEST_ID
FROM B_FP_TEST,
B_USER_INFO,
J_FP_INVESTIGATOR,
L_TEST_STATUS,
L_ATMS_TEST_TYPE,
j_op_test_anml
WHERE B_FP_TEST.TEST_ID = J_FP_INVESTIGATOR.TEST_ID
AND B_FP_TEST.TEST_TYPE_ID = L_ATMS_TEST_TYPE.ATMS_TEST_TYPE_ID
AND B_USER_INFO.B_USER_INFO_ID = J_FP_INVESTIGATOR.INVESTIGATOR_ID
AND B_FP_TEST.STATUS_ID = L_TEST_STATUS.STATUS_ID
AND B_FP_TEST.IS_DELETED = :"SYS_B_00"
AND B_FP_TEST.TEST_NUM NOT IN (:"SYS_B_01", :"SYS_B_02", :"SYS_B_03")
AND L_ATMS_TEST_TYPE.IS_DELETED = :"SYS_B_04"
AND J_FP_INVESTIGATOR.is_pi = :"SYS_B_05"
AND L_TEST_STATUS.STATUS IN (:"SYS_B_06", :"SYS_B_07", :"SYS_B_08")
AND j_op_test_anml.test_id = B_FP_TEST.TEST_ID
----- End of information for the OTHER waiting sessions -----
*** 2013-11-04 23:18:57.916
dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=3, mask=0x0)
----- Error Stack Dump -----
ORA-00060: deadlock detected while waiting for resource
ORA-10387: parallel query server interrupt (normal)
----- SQL Statement (None) -----
Current SQL information unavailable - no cursor.
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
More......
Query:
SELECT DISTINCT B_FP_TEST.TEST_ID
FROM B_FP_TEST,
B_USER_INFO,
J_FP_INVESTIGATOR,
L_TEST_STATUS,
L_ATMS_TEST_TYPE,
j_op_test_anml
WHERE B_FP_TEST.TEST_ID = J_FP_INVESTIGATOR.TEST_ID
AND B_FP_TEST.TEST_TYPE_ID = L_ATMS_TEST_TYPE.ATMS_TEST_TYPE_ID
AND B_USER_INFO.B_USER_INFO_ID = J_FP_INVESTIGATOR.INVESTIGATOR_ID
AND B_FP_TEST.STATUS_ID = L_TEST_STATUS.STATUS_ID
AND B_FP_TEST.IS_DELETED = 0
AND B_FP_TEST.TEST_NUM NOT IN (1, 2, 99)
AND L_ATMS_TEST_TYPE.IS_DELETED = 0
AND J_FP_INVESTIGATOR.is_pi = 1
AND L_TEST_STATUS.STATUS IN ('Scheduled', 'In-Progress', 'Completed')
AND j_op_test_anml.test_id = B_FP_TEST.TEST_ID
AND ( (j_op_test_anml.end_date BETWEEN TO_DATE ('28-Oct-2013') - 1
AND TO_DATE ('04-Nov-2013') + 1)
OR (j_op_test_anml.start_date BETWEEN TO_DATE ('28-Oct-2013') - 1
AND TO_DATE ('04-Nov-2013') + 1)
OR (TO_DATE ('28-Oct-2013') BETWEEN j_op_test_anml.start_date
AND j_op_test_anml.end_date)
OR (TO_DATE ('04-Nov-2013') BETWEEN j_op_test_anml.start_date
AND j_op_test_anml.end_date))
AND L_ATMS_TEST_TYPE.IS_DELETED = 0
AND B_FP_TEST.DATASOURCE_ID = 9
Query Exp plan:
Plan hash value: 3398228788
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 1501 | 102K| 1929 (1)| 00:00:24 | | | | | |
| 1 | HASH UNIQUE | | 1501 | 102K| 1929 (1)| 00:00:24 | | | | | |
| 2 | CONCATENATION | | | | | | | | | | |
| 3 | PX COORDINATOR | | | | | | | | | | |
| 4 | PX SEND QC (RANDOM) | :TQ30005 | 241 | 16870 | 800 (1)| 00:00:10 | | | Q3,05 | P->S | QC (RAND) |
|* 5 | HASH JOIN | | 241 | 16870 | 800 (1)| 00:00:10 | | | Q3,05 | PCWP | |
| 6 | PX RECEIVE | | 246 | 15990 | 797 (1)| 00:00:10 | | | Q3,05 | PCWP | |
| 7 | PX SEND HASH | :TQ30004 | 246 | 15990 | 797 (1)| 00:00:10 | | | Q3,04 | P->P | HASH |
|* 8 | HASH JOIN | | 246 | 15990 | 797 (1)| 00:00:10 | | | Q3,04 | PCWP | |
| 9 | PX RECEIVE | | 573 | 29223 | 793 (1)| 00:00:10 | | | Q3,04 | PCWP | |
| 10 | PX SEND HASH | :TQ30003 | 573 | 29223 | 793 (1)| 00:00:10 | | | Q3,03 | P->P | HASH |
|* 11 | HASH JOIN | | 573 | 29223 | 793 (1)| 00:00:10 | | | Q3,03 | PCWP | |
| 12 | BUFFER SORT | | | | | | | | Q3,03 | PCWC | |
| 13 | PX RECEIVE | | | | | | | | Q3,03 | PCWP | |
| 14 | PX SEND BROADCAST | :TQ30000 | | | | | | | | S->P | BROADCAST |
| 15 | NESTED LOOPS | | | | | | | | | | |
| 16 | NESTED LOOPS | | 485 | 20855 | 781 (0)| 00:00:10 | | | | | |
| 17 | TABLE ACCESS BY GLOBAL INDEX ROWID| J_OP_TEST_ANML | 485 | 10185 | 296 (0)| 00:00:04 | ROWID | ROWID | | | |
|* 18 | INDEX RANGE SCAN | IDX$$_2D190001 | 485 | | 4 (0)| 00:00:01 | | | | | |
|* 19 | INDEX UNIQUE SCAN | FT_TEST_ID_PK | 1 | | 0 (0)| 00:00:01 | | | | | |
|* 20 | TABLE ACCESS BY GLOBAL INDEX ROWID | B_FP_TEST | 1 | 22 | 1 (0)| 00:00:01 | ROWID | ROWID | | | |
| 21 | PX BLOCK ITERATOR | | 70382 | 549K| 11 (0)| 00:00:01 | | | Q3,03 | PCWC | |
|* 22 | TABLE ACCESS FULL | J_FP_INVESTIGATOR | 70382 | 549K| 11 (0)| 00:00:01 | | | Q3,03 | PCWP | |
| 23 | BUFFER SORT | | | | | | | | Q3,04 | PCWC | |
| 24 | PX RECEIVE | | 3 | 42 | 3 (0)| 00:00:01 | | | Q3,04 | PCWP | |
| 25 | PX SEND HASH | :TQ30001 | 3 | 42 | 3 (0)| 00:00:01 | | | | S->P | HASH |
|* 26 | TABLE ACCESS FULL | L_TEST_STATUS | 3 | 42 | 3 (0)| 00:00:01 | | | | | |
| 27 | BUFFER SORT | | | | | | | | Q3,05 | PCWC | |
| 28 | PX RECEIVE | | 30 | 150 | 3 (0)| 00:00:01 | | | Q3,05 | PCWP | |
| 29 | PX SEND HASH | :TQ30002 | 30 | 150 | 3 (0)| 00:00:01 | | | | S->P | HASH |
|* 30 | TABLE ACCESS FULL | L_ATMS_TEST_TYPE | 30 | 150 | 3 (0)| 00:00:01 | | | | | |
| 31 | NESTED LOOPS | | | | | | | | | | |
| 32 | NESTED LOOPS | | 3 | 210 | 329 (1)| 00:00:04 | | | | | |
| 33 | NESTED LOOPS | | 3 | 195 | 329 (1)| 00:00:04 | | | | | |
|* 34 | HASH JOIN | | 2 | 114 | 325 (1)| 00:00:04 | | | | | |
| 35 | NESTED LOOPS | | | | | | | | | | |
| 36 | NESTED LOOPS | | 6 | 258 | 322 (1)| 00:00:04 | | | | | |
| 37 | PARTITION RANGE SINGLE | | 6 | 126 | 316 (1)| 00:00:04 | 7 | 7 | | | |
|* 38 | TABLE ACCESS FULL | J_OP_TEST_ANML | 6 | 126 | 316 (1)| 00:00:04 | 7 | 7 | | | |
|* 39 | INDEX UNIQUE SCAN | FT_TEST_ID_PK | 1 | | 0 (0)| 00:00:01 | | | | | |
|* 40 | TABLE ACCESS BY GLOBAL INDEX ROWID | B_FP_TEST | 1 | 22 | 1 (0)| 00:00:01 | ROWID | ROWID | | | |
|* 41 | TABLE ACCESS FULL | L_TEST_STATUS | 3 | 42 | 3 (0)| 00:00:01 | | | | | |
|* 42 | TABLE ACCESS BY INDEX ROWID | J_FP_INVESTIGATOR | 1 | 8 | 2 (0)| 00:00:01 | | | | | |
|* 43 | INDEX RANGE SCAN | FI_TEST_ID_PK | 1 | | 1 (0)| 00:00:01 | | | | | |
|* 44 | INDEX UNIQUE SCAN | L_ATMS_TEST_TYPE_PK | 1 | | 0 (0)| 00:00:01 | | | | | |
|* 45 | TABLE ACCESS BY INDEX ROWID | L_ATMS_TEST_TYPE | 1 | 5 | 1 (0)| 00:00:01 | | | | | |
| 46 | PX COORDINATOR | | | | | | | | | | |
| 47 | PX SEND QC (RANDOM) | :TQ20003 | | | | | | | Q2,03 | P->S | QC (RAND) |
| 48 | NESTED LOOPS | | | | | | | | Q2,03 | PCWP | |
| 49 | NESTED LOOPS | | 33 | 2310 | 399 (2)| 00:00:05 | | | Q2,03 | PCWP | |
|* 50 | HASH JOIN | | 33 | 2145 | 397 (2)| 00:00:05 | | | Q2,03 | PCWP | |
| 51 | PX RECEIVE | | 78 | 3978 | 393 (1)| 00:00:05 | | | Q2,03 | PCWP | |
| 52 | PX SEND HASH | :TQ20002 | 78 | 3978 | 393 (1)| 00:00:05 | | | Q2,02 | P->P | HASH |
|* 53 | HASH JOIN | | 78 | 3978 | 393 (1)| 00:00:05 | | | Q2,02 | PCWP | |
| 54 | BUFFER SORT | | | | | | | | Q2,02 | PCWC | |
| 55 | PX RECEIVE | | | | | | | | Q2,02 | PCWP | |
| 56 | PX SEND BROADCAST | :TQ20000 | | | | | | | | S->P | BROADCAST |
| 57 | NESTED LOOPS | | | | | | | | | | |
| 58 | NESTED LOOPS | | 66 | 2838 | 382 (1)| 00:00:05 | | | | | |
| 59 | PARTITION RANGE SINGLE | | 66 | 1386 | 316 (1)| 00:00:04 | 7 | 7 | | | |
|* 60 | TABLE ACCESS FULL | J_OP_TEST_ANML | 66 | 1386 | 316 (1)| 00:00:04 | 7 | 7 | | | |
|* 61 | INDEX UNIQUE SCAN | FT_TEST_ID_PK | 1 | | 0 (0)| 00:00:01 | | | | | |
|* 62 | TABLE ACCESS BY GLOBAL INDEX ROWID | B_FP_TEST | 1 | 22 | 1 (0)| 00:00:01 | ROWID | ROWID | | | |
| 63 | PX BLOCK ITERATOR | | 70382 | 549K| 11 (0)| 00:00:01 | | | Q2,02 | PCWC | |
|* 64 | TABLE ACCESS FULL | J_FP_INVESTIGATOR | 70382 | 549K| 11 (0)| 00:00:01 | | | Q2,02 | PCWP | |
| 65 | BUFFER SORT | | | | | | | | Q2,03 | PCWC | |
| 66 | PX RECEIVE | | 3 | 42 | 3 (0)| 00:00:01 | | | Q2,03 | PCWP | |
| 67 | PX SEND HASH | :TQ20001 | 3 | 42 | 3 (0)| 00:00:01 | | | | S->P | HASH |
|* 68 | TABLE ACCESS FULL | L_TEST_STATUS | 3 | 42 | 3 (0)| 00:00:01 | | | | | |
|* 69 | INDEX UNIQUE SCAN | L_ATMS_TEST_TYPE_PK | 1 | | 0 (0)| 00:00:01 | | | Q2,03 | PCWP | |
|* 70 | TABLE ACCESS BY INDEX ROWID | L_ATMS_TEST_TYPE | 1 | 5 | 1 (0)| 00:00:01 | | | Q2,03 | PCWP | |
| 71 | PX COORDINATOR | | | | | | | | | | |
| 72 | PX SEND QC (RANDOM) | :TQ10003 | | | | | | | Q1,03 | P->S | QC (RAND) |
| 73 | NESTED LOOPS | | | | | | | | Q1,03 | PCWP | |
| 74 | NESTED LOOPS | | 33 | 2310 | 399 (2)| 00:00:05 | | | Q1,03 | PCWP | |
|* 75 | HASH JOIN | | 34 | 2210 | 397 (2)| 00:00:05 | | | Q1,03 | PCWP | |
| 76 | PX RECEIVE | | 78 | 3978 | 393 (1)| 00:00:05 | | | Q1,03 | PCWP | |
| 77 | PX SEND HASH | :TQ10002 | 78 | 3978 | 393 (1)| 00:00:05 | | | Q1,02 | P->P | HASH |
|* 78 | HASH JOIN | | 78 | 3978 | 393 (1)| 00:00:05 | | | Q1,02 | PCWP | |
| 79 | BUFFER SORT | | | | | | | | Q1,02 | PCWC | |
| 80 | PX RECEIVE | | | | | | | | Q1,02 | PCWP | |
| 81 | PX SEND BROADCAST | :TQ10000 | | | | | | | | S->P | BROADCAST |
| 82 | NESTED LOOPS | | | | | | | | | | |
| 83 | NESTED LOOPS | | 66 | 2838 | 382 (1)| 00:00:05 | | | | | |
| 84 | PARTITION RANGE SINGLE | | 66 | 1386 | 316 (1)| 00:00:04 | 7 | 7 | | | |
|* 85 | TABLE ACCESS FULL | J_OP_TEST_ANML | 66 | 1386 | 316 (1)| 00:00:04 | 7 | 7 | | | |
|* 86 | INDEX UNIQUE SCAN | FT_TEST_ID_PK | 1 | | 0 (0)| 00:00:01 | | | | | |
|* 87 | TABLE ACCESS BY GLOBAL INDEX ROWID | B_FP_TEST | 1 | 22 | 1 (0)| 00:00:01 | ROWID | ROWID | | | |
| 88 | PX BLOCK ITERATOR | | 70382 | 549K| 11 (0)| 00:00:01 | | | Q1,02 | PCWC | |
|* 89 | TABLE ACCESS FULL | J_FP_INVESTIGATOR | 70382 | 549K| 11 (0)| 00:00:01 | | | Q1,02 | PCWP | |
| 90 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 91 | PX RECEIVE | | 3 | 42 | 3 (0)| 00:00:01 | | | Q1,03 | PCWP | |
| 92 | PX SEND HASH | :TQ10001 | 3 | 42 | 3 (0)| 00:00:01 | | | | S->P | HASH |
|* 93 | TABLE ACCESS FULL | L_TEST_STATUS | 3 | 42 | 3 (0)| 00:00:01 | | | | | |
|* 94 | INDEX UNIQUE SCAN | L_ATMS_TEST_TYPE_PK | 1 | | 0 (0)| 00:00:01 | | | Q1,03 | PCWP | |
|* 95 | TABLE ACCESS BY INDEX ROWID | L_ATMS_TEST_TYPE | 1 | 5 | 1 (0)| 00:00:01 | | | Q1,03 | PCWP | |
Predicate Information (identified by operation id):
5 - access("B_FP_TEST"."TEST_TYPE_ID"="L_ATMS_TEST_TYPE"."ATMS_TEST_TYPE_ID")
8 - access("B_FP_TEST"."STATUS_ID"="L_TEST_STATUS"."STATUS_ID")
11 - access("B_FP_TEST"."TEST_ID"="J_FP_INVESTIGATOR"."TEST_ID")
18 - access("J_OP_TEST_ANML"."START_DATE">=TO_DATE(' 2013-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-11-05
00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
19 - access("J_OP_TEST_ANML"."TEST_ID"="B_FP_TEST"."TEST_ID")
20 - filter("B_FP_TEST"."DATASOURCE_ID"=9 AND "B_FP_TEST"."IS_DELETED"=0 AND "B_FP_TEST"."TEST_NUM"<>1 AND "B_FP_TEST"."TEST_NUM"<>2 AND
"B_FP_TEST"."TEST_NUM"<>99)
22 - filter("J_FP_INVESTIGATOR"."IS_PI"=1)
26 - filter("L_TEST_STATUS"."STATUS"='Completed' OR "L_TEST_STATUS"."STATUS"='In-Progress' OR "L_TEST_STATUS"."STATUS"='Scheduled')
30 - filter("L_ATMS_TEST_TYPE"."IS_DELETED"=0)
34 - access("B_FP_TEST"."STATUS_ID"="L_TEST_STATUS"."STATUS_ID")
38 - filter("J_OP_TEST_ANML"."END_DATE">=TO_DATE(' 2013-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "J_OP_TEST_ANML"."END_DATE"<=TO_DATE(' 2013-11-05
00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND (LNNVL("J_OP_TEST_ANML"."START_DATE">=TO_DATE(' 2013-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR
LNNVL("J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-11-05 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))))
39 - access("J_OP_TEST_ANML"."TEST_ID"="B_FP_TEST"."TEST_ID")
40 - filter("B_FP_TEST"."DATASOURCE_ID"=9 AND "B_FP_TEST"."IS_DELETED"=0 AND "B_FP_TEST"."TEST_NUM"<>1 AND "B_FP_TEST"."TEST_NUM"<>2 AND
"B_FP_TEST"."TEST_NUM"<>99)
41 - filter("L_TEST_STATUS"."STATUS"='Completed' OR "L_TEST_STATUS"."STATUS"='In-Progress' OR "L_TEST_STATUS"."STATUS"='Scheduled')
42 - filter("J_FP_INVESTIGATOR"."IS_PI"=1)
43 - access("B_FP_TEST"."TEST_ID"="J_FP_INVESTIGATOR"."TEST_ID")
44 - access("B_FP_TEST"."TEST_TYPE_ID"="L_ATMS_TEST_TYPE"."ATMS_TEST_TYPE_ID")
45 - filter("L_ATMS_TEST_TYPE"."IS_DELETED"=0)
50 - access("B_FP_TEST"."STATUS_ID"="L_TEST_STATUS"."STATUS_ID")
53 - access("B_FP_TEST"."TEST_ID"="J_FP_INVESTIGATOR"."TEST_ID")
60 - filter("J_OP_TEST_ANML"."END_DATE">=TO_DATE(' 2013-11-04 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-11-04
00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND (LNNVL("J_OP_TEST_ANML"."END_DATE">=TO_DATE(' 2013-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR
LNNVL("J_OP_TEST_ANML"."END_DATE"<=TO_DATE(' 2013-11-05 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))) AND (LNNVL("J_OP_TEST_ANML"."START_DATE">=TO_DATE(' 2013-10-27
00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR LNNVL("J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-11-05 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))))
61 - access("J_OP_TEST_ANML"."TEST_ID"="B_FP_TEST"."TEST_ID")
62 - filter("B_FP_TEST"."DATASOURCE_ID"=9 AND "B_FP_TEST"."IS_DELETED"=0 AND "B_FP_TEST"."TEST_NUM"<>1 AND "B_FP_TEST"."TEST_NUM"<>2 AND
"B_FP_TEST"."TEST_NUM"<>99)
64 - filter("J_FP_INVESTIGATOR"."IS_PI"=1)
68 - filter("L_TEST_STATUS"."STATUS"='Completed' OR "L_TEST_STATUS"."STATUS"='In-Progress' OR "L_TEST_STATUS"."STATUS"='Scheduled')
69 - access("B_FP_TEST"."TEST_TYPE_ID"="L_ATMS_TEST_TYPE"."ATMS_TEST_TYPE_ID")
70 - filter("L_ATMS_TEST_TYPE"."IS_DELETED"=0)
75 - access("B_FP_TEST"."STATUS_ID"="L_TEST_STATUS"."STATUS_ID")
78 - access("B_FP_TEST"."TEST_ID"="J_FP_INVESTIGATOR"."TEST_ID")
85 - filter("J_OP_TEST_ANML"."END_DATE">=TO_DATE(' 2013-10-28 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-10-28
00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND (LNNVL("J_OP_TEST_ANML"."END_DATE">=TO_DATE(' 2013-11-04 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR
LNNVL("J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-11-04 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))) AND (LNNVL("J_OP_TEST_ANML"."END_DATE">=TO_DATE(' 2013-10-27
00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR LNNVL("J_OP_TEST_ANML"."END_DATE"<=TO_DATE(' 2013-11-05 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))) AND
(LNNVL("J_OP_TEST_ANML"."START_DATE">=TO_DATE(' 2013-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR LNNVL("J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-11-05
00:00:00', 'syyyy-mm-dd hh24:mi:ss'))))
86 - access("J_OP_TEST_ANML"."TEST_ID"="B_FP_TEST"."TEST_ID")
87 - filter("B_FP_TEST"."DATASOURCE_ID"=9 AND "B_FP_TEST"."IS_DELETED"=0 AND "B_FP_TEST"."TEST_NUM"<>1 AND "B_FP_TEST"."TEST_NUM"<>2 AND
"B_FP_TEST"."TEST_NUM"<>99)
89 - filter("J_FP_INVESTIGATOR"."IS_PI"=1)
93 - filter("L_TEST_STATUS"."STATUS"='Completed' OR "L_TEST_STATUS"."STATUS"='In-Progress' OR "L_TEST_STATUS"."STATUS"='Scheduled')
94 - access("B_FP_TEST"."TEST_TYPE_ID"="L_ATMS_TEST_TYPE"."ATMS_TEST_TYPE_ID")
95 - filter("L_ATMS_TEST_TYPE"."IS_DELETED"=0)Excellent piece of follow-up on my first suggestion.
I nearly made a comment about how the plan doesn't show Bloom filter pruning either - and then I realised why not. The plan you've shown us comes from Explain Plan with literal values present; the trace file shows bind variables with names that are generated when cursor_sharing is set to force or similar - so the run-time plan and the plan from explain plan are almost guaranteed to be different.
Oracle support will need you to supply the plan you get from trying to run the query and then making a call to dbms_xplan.display_cursor() - dbms_xplan in 10g | Oracle Scratchpad If you do this I think you'll find that the pstart/pstop columns contain entries like :BF0000, and you may even find operations link PX JOIN FILTER CREATE / PX JOIN FILTER USE
A couple of generic notes:
if a query does sufficient work to merit parallel execution, then it's usually better to supply the best possible information to the optimizer, which means using literals rather than bind variables - you could try executing the query with the hint /*+ cursor_sharing_exact */ to stop Oracle from turning your literals into binds; it might be the presence of bind variables that's making the optimizer choose a path that has to include bloom filter pruning in your case.
Where you have the to_date() call you've used a four-digit year - which is a very good thing and helps the optimizer - but it's also a good idea to include an explicit format string as well: with a four-digit year this probably won't make any difference, but it avoids any risk of ambiguity for the optimizer.
I made a comment about the P->S stage and bottlenecks - I spent a couple more minutes looking at the plan, and I see the optimizer has used concatentation: in effect it has run three query blocks one after the other and fed the results to the query co-ordinator - in this case the P->S would make no difference to the end-user response time there's always a final P->S to the coordinator, you just happen to have three of them.
Regards
Jonathan Lewis -
Time Taking while firing a select Query
i am unable to access the table "X" in ABC schema
its taking toooooooooo much time while firing just a select query
how to resolve it
"SELECT digital_signing_cert
FROM X"could be due to huge table size,crosscheck this from user_segments view.
select bytes/1024/1024 "MB" from user_segments where segment_name='X';
also check database alert log for any error. -
Select query with secondary index
hi,
i have a report which is giving performance issues on a perticular select query on KONH table.
the select query doesnt use the primary key fields and table already has around 19 million entries.So there was a secondary index created for the fields in the table.
now, KONH is a client specific table, and hence has MANDT as the first field. when the table is not indexed it is sorted according to the order of fields, like first MANDT, then primary key fields and then remaining fields.. (correct me if i am wrong)
but the secondary index created doesnt has MANDT in it..(yea, a mistake! )...
but instead of correccting the secondary index, i am told to change the select query..
so, i used a "client specific" syntax to sort the issue.. but i dont understand whre i should put the "where mandt eq sy-mandt" clause..
should i put it right after all my secondary index fields are over? or what happens to the order of fields which are not present in the list of secondary index?
kindaly help.
thanx.Hi chinmay kulkarni,
its better if you can ask concerned person to add MANDT field in your index as well....
Indexes and MANDT
If a table begins with the mandt field, so should its indexes. If a table begins with mandt and an index doesn't, the optimizer might not use the index.
Remember, if you will, Open SQL's automatic client handling feature. When select * from ztxlfa1 where land1 = 'US' is executed, the actual SQL sent to the database is select * from ztxlfa1 where mandt = sy-mandt and land1 = 'US'. Sy-mandt contains the current logon client. When you select rows from a table using Open SQL, the system automatically adds sy-mandt to the where clause, which causes only those rows pertaining to the current logon client to be found.
When you create an index on a table containing mandt, therefore, you should also include mandt in the index. It should come first in the index, because it will always appear first in the generated SQL.
Index: Technical key of a database table.
Primary index: The primary index contains the key fields of the table and a pointer to the non-key fields of the table. The primary index is created automatically when the table is created in the database.
Secondary index: Additional indexes could be created considering the most frequently accessed dimensions of the table.
Structure of an Index
An index can be used to speed up the selection of data records from a table.
An index can be considered to be a copy of a database table reduced to certain fields. The data is stored in sorted form in this copy. This sorting permits fast access to the records of the table (for example using a binary search). Not all of the fields of the table are contained in the index. The index also contains a pointer from the index entry to the corresponding table entry to permit all the field contents to be read.
When creating indexes, please note that:
An index can only be used up to the last specified field in the selection! The fields which are specified in the WHERE clause for a large number of selections should be in the first position.
Only those fields whose values significantly restrict the amount of data are meaningful in an index.
When you change a data record of a table, you must adjust the index sorting. Tables whose contents are frequently changed therefore should not have too many indexes.
Make sure that the indexes on a table are as disjunctive as possible.
(That is they should contain as few fields in common as possible. If two indexes on a table have a large number of common fields, this could make it more difficult for the optimizer to choose the most selective index.)
For Example...
SELECT KUNNR KUNN2 INTO TABLE T_CUST_TERR
FROM KNVP CLIENT SPECIFIED
WHERE MANDT = SY-MANDT " here MANDT shd be first
AND KUNN2 IN S_TERR
AND PARVW LIKE 'Z%'.
Accessing tables using Indexes
The database optimizer decides which index on the table should be used by the database to access data records.
You must distinguish between the primary index and secondary indexes of a table. The primary index contains the key fields of the table. The primary index is automatically created in the database when the table is activated. If a large table is frequently accessed such that it is not possible to apply primary index sorting, you should create secondary indexes for the table.
The indexes on a table have a three-character index ID. '0' is reserved for the primary index. Customers can create their own indexes on SAP tables; their IDs must begin with Y or Z.
If the index fields have key function, i.e. they already uniquely identify each record of the table, an index can be called a unique index. This ensures that there are no duplicate index fields in the database.
When you define a secondary index in the ABAP Dictionary, you can specify whether it should be created on the database when it is activated. Some indexes only result in a gain in performance for certain database systems. You can therefore specify a list of database systems when you define an index. The index is then only created on the specified database systems when activated
Also pls have a look on below link
http://www.sapfans.com/sapfans/forum/devel/messages/30240.html
Hope it will solve your problem..
Reward points if useful...
Thanks & Regards
ilesh 24x7 -
Sample XML format that can be used to write a SELECT query
Hello,
I want to use and XML file in the scenario FILE to JDBC where i use the operation as SELECT in which i want to embbed an sql statemnet which is equivalent to
SELECT EMPNO, NAME FROM EMPLOYEE WHERE EMPNO>1
as in the form of XML format like,
<?xml version="1.0" encoding="UTF-8"?>
<ns0:MT_JDBC_SELECT_JDBC_REQ xmlns:ns0="http://JDBC_SELECT">
<STATEMENT>
<TABLENAME ACTION="SELECT">
<TABLE>EMPTEST</TABLE>
<ACCESS>
<EMPNO></EMPNO>
<NAME></NAME>
</ACCESS>
<KEY>
<EMPNO compareOperation="GT">1</EMPNO>
</KEY>
</TABLENAME>
</STATEMENT>
</ns0:MT_JDBC_SELECT_JDBC_REQ>
Can i do like this?
PLease help me out in using various conditions in the XML file formats like the above.
Thanks,
Soorya.Hello raj,
I would like to write the query in that format where i mentioned as,
<?xml version="1.0" encoding="UTF-8"?>
<ns0:MT_JDBC_SELECT_JDBC_REQ xmlns:ns0="http://JDBC_SELECT">
<STATEMENT>
<TABLENAME ACTION="SELECT">
<TABLE>EMPTEST</TABLE>
<ACCESS>
<EMPNO></EMPNO>
<NAME></NAME>
</ACCESS>
<KEY>
<EMPNO compareOperation="GT">1</EMPNO>
</KEY>
</TABLENAME>
</STATEMENT>
</ns0:MT_JDBC_SELECT_JDBC_REQ>
without giving clear SQL statement as you mentioned here like,
<ns0:MT_JDBC_SELECT_JDBC_REQ xmlns:ns0="http://JDBC_SELECT">
<STATEMENT>
<TABLENAME ACTION="SQL_QUERY">
<ACCESS>SELECT EMPNO, NAME FROM EMPLOYEE WHERE EMPNO > '$EMPNO$</ACCESS>
<KEY>
<EMPNO>1</EMPNO>
</KEY>
</TABLENAME>
</STATEMENT>
</ns0:MT_JDBC_SELECT_JDBC_REQ>
Thanks,
Soorya -
Select query in not working for Count(*)
Hi,
Our batch team running one query that is selecting one table TSFHEAD and this query is hanging. Below are diffrent shenario in which the select query is running on this table.
select * from tsfhead where create_id = 'BATCH' and create_date = '26-OCT-12';
--not returning any rows and hanging
select * from tsfhead where create_id = 'BATCH' ---returning rows
select * from tsfhead where create_date = '26-OCT-12'; --- returning rows
select count(*) from tsfhead ----not returning rows and hanging
This table TSFHEAD has 59000 rows.
SQL> explain plan for select * from tsfhead where create_id = 'BATCH' and create_date = '26-OCT-12';
Explained.
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 415503093
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 67 | 215 (1)| 00:00:03 |
|* 1 | TABLE ACCESS FULL| TSFHEAD | 1 | 67 | 215 (1)| 00:00:03 |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
1 - filter("CREATE_ID"='BATCH' AND "CREATE_DATE"='26-OCT-12')
I don't know why this query behaving in this manner.Please help.RanVijai_dba wrote:
Thanks for your reply. But +"select count(*) from tsfhead"+ is hanging and +"select * from tsfhead where create_date = '26-OCT-12' "+ is showing records.It might be showing records, but not necessarily the correct records.
As sb points out, you are treating dates as strings rather than the DATE datatype. That means you could be querying the wrong data, and your query is also not safe in different environments. It could also effect the query execution plan. Also, as pointed out, you should be ideally using 4 digit years. There were many headaches caused by the use of 2 digit years that most companies corrected as part of the millenium bug fixes prior to the year 2000... well over a decade ago, and most good designs now ensure that 4 digit years are used as standard.
So your query would be better written as:
select * from tsfhead where create_date = TO_DATE('26-OCT-2012','DD-MON-YYYY')When you say:
select count(*) from tsfhead... is hanging, you say the table has around 59000 rows in it, and in reality that's a small amount of records, so a count(*) shouldn't take long at all, even doing a full table scan.
Post the explain plan for that simple count(*) query for us. (and ensure you use {noformat}{noformat} tags to keep the formatting on the forum, as described in {message:id=9360002}) -
Select Query failing on a table that has per sec heavy insertions.
Hi
Problem statement
1- We are using 11g as an database.
2- We have a table that is partitioned on the date as range partition.
3- The insertion of data is very high.i.e. several hundreds records per sec. in the current partitioned.
4- The data is continuously going in the current partitioned as and when buffer is full or per sec timer expires.
5-- We have to make also select query on the same table and on the current partitioned say for the latest 500 records.
6- Effecient indexes are also created on the table.
Solutions Tried.
1- After analyzing by tkprof it is observed that select and execute is working fine but fetch is taking too much time to show the out put. Say it takes 1 hour.
2- Using the 11g sql advisior and SPM several baseline is created but the success rate of them is observed also too low.
please suggest any solution to this issue
1- i.e. Redisgn of table.
2- Any better way to quey to fix the fetch issue.
3- Any oracle seetings or parameter changes to fix the fetch issue.
Thanks in advance.
Regards
Vishal SharmaI am uploading the latest stats please let me know how can improve as this is taking 25 minutes
####TKPROF output#########
SQL ID : 2j5w6bv437cak
select almevttbl.AlmEvtId, almevttbl.AlmType, almevttbl.ComponentId,
almevttbl.TimeStamp, almevttbl.Severity, almevttbl.State,
almevttbl.Category, almevttbl.CauseCode, almevttbl.UnitType,
almevttbl.UnitId, almevttbl.UnitName, almevttbl.ServerName,
almevttbl.StrParam, almevttbl.ExtraStrParam, almevttbl.ExtraStrParam2,
almevttbl.ExtraStrParam3, almevttbl.ParentCustId, almevttbl.ExtraParam1,
almevttbl.ExtraParam2, almevttbl.ExtraParam3,almevttbl.ExtraParam4,
almevttbl.ExtraParam5, almevttbl.SRCIPADDRFAMILY,almevttbl.SrcIPAddress11,
almevttbl.SrcIPAddress12,almevttbl.SrcIPAddress13,almevttbl.SrcIPAddress14,
almevttbl.DESTIPADDRFAMILY,almevttbl.DestIPAddress11,
almevttbl.DestIPAddress12,almevttbl.DestIPAddress13,
almevttbl.DestIPAddress14, almevttbl.DestPort, almevttbl.SrcPort,
almevttbl.SessionDir, almevttbl.CustomerId, almevttbl.ProfileId,
almevttbl.ParentProfileId, almevttbl.CustomerName, almevttbl.AttkDir,
almevttbl.SubCategory, almevttbl.RiskCategory, almevttbl.AssetValue,
almevttbl.IPSAction, almevttbl.l4Protocol,almevttbl.ExtraStrParam4 ,
almevttbl.ExtraStrParam5,almevttbl.username,almevttbl.ExtraStrParam6,
IpAddrFamily1,IPAddrValue11,IPAddrValue12,IPAddrValue13,IPAddrValue14,
IpAddrFamily2,IPAddrValue21,IPAddrValue22,IPAddrValue23,IPAddrValue24
FROM
AlmEvtTbl PARTITION(ALMEVTTBLP20100323) WHERE AlmEvtId IN ( SELECT * FROM
( SELECT /*+ FIRST_ROWS(1000) INDEX (AlmEvtTbl AlmEvtTbl_Index) */AlmEvtId
FROM AlmEvtTbl PARTITION(ALMEVTTBLP20100323) where ((AlmEvtTbl.Customerid
= 0 or AlmEvtTbl.ParentCustId = 0)) ORDER BY AlmEvtTbl.TIMESTAMP DESC)
WHERE ROWNUM < 602) order by timestamp desc
call count cpu elapsed disk query current rows
Parse 1 0.10 0.17 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 42 1348.25 1521.24 1956 39029545 0 601
total 44 1348.35 1521.41 1956 39029545 0 601
Misses in library cache during parse: 1
Optimizer mode: FIRST_ROWS
Parsing user id: 82
Rows Row Source Operation
601 PARTITION RANGE SINGLE PARTITION: 24 24 (cr=39029545 pr=1956 pw=1956 time=11043 us cost=0 size=7426 card=1)
601 TABLE ACCESS BY LOCAL INDEX ROWID ALMEVTTBL PARTITION: 24 24 (cr=39029545 pr=1956 pw=1956 time=11030 us cost=0 size=7426 card=1)
601 INDEX FULL SCAN ALMEVTTBL_INDEX PARTITION: 24 24 (cr=39029377 pr=1956 pw=1956 time=11183 us cost=0 size=0 card=1)(object id 72557)
601 FILTER (cr=39027139 pr=0 pw=0 time=0 us)
169965204 COUNT STOPKEY (cr=39027139 pr=0 pw=0 time=24859073 us)
169965204 VIEW (cr=39027139 pr=0 pw=0 time=17070717 us cost=0 size=13 card=1)
169965204 PARTITION RANGE SINGLE PARTITION: 24 24 (cr=39027139 pr=0 pw=0 time=13527031 us cost=0 size=48 card=1)
169965204 TABLE ACCESS BY LOCAL INDEX ROWID ALMEVTTBL PARTITION: 24 24 (cr=39027139 pr=0 pw=0 time=10299895 us cost=0 size=48 card=1)
169965204 INDEX FULL SCAN ALMEVTTBL_INDEX PARTITION: 24 24 (cr=1131414 pr=0 pw=0 time=3222624 us cost=0 size=0 card=1)(object id 72557)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 42 0.00 0.00
SQL*Net message from client 42 11.54 133.54
db file sequential read 1956 0.20 28.00
latch free 21 0.00 0.01
latch: cache buffers chains 9 0.01 0.02
SQL ID : 0ushr863b7z39
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE
NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false')
NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),0), NVL(SUM(C2),0)
FROM
(SELECT /*+ IGNORE_WHERE_CLAUSE NO_PARALLEL("PLAN_TABLE") FULL("PLAN_TABLE")
NO_PARALLEL_INDEX("PLAN_TABLE") */ 1 AS C1, CASE WHEN
"PLAN_TABLE"."STATEMENT_ID"=:B1 THEN 1 ELSE 0 END AS C2 FROM
"SYS"."PLAN_TABLE$" "PLAN_TABLE") SAMPLESUB
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.01 1 3 0 1
total 3 0.00 0.01 1 3 0 1
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 82 (recursive depth: 1)
Rows Row Source Operation
1 SORT AGGREGATE (cr=3 pr=1 pw=1 time=0 us)
0 TABLE ACCESS FULL PLAN_TABLE$ (cr=3 pr=1 pw=1 time=0 us cost=29 size=138856 card=8168)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 1 0.01 0.01
SQL ID : bjkdb51at8dnb
EXPLAIN PLAN SET STATEMENT_ID='PLUS30350011' FOR select almevttbl.AlmEvtId,
almevttbl.AlmType, almevttbl.ComponentId, almevttbl.TimeStamp,
almevttbl.Severity, almevttbl.State, almevttbl.Category,
almevttbl.CauseCode, almevttbl.UnitType, almevttbl.UnitId,
almevttbl.UnitName, almevttbl.ServerName, almevttbl.StrParam,
almevttbl.ExtraStrParam, almevttbl.ExtraStrParam2, almevttbl.ExtraStrParam3,
almevttbl.ParentCustId, almevttbl.ExtraParam1, almevttbl.ExtraParam2,
almevttbl.ExtraParam3,almevttbl.ExtraParam4,almevttbl.ExtraParam5,
almevttbl.SRCIPADDRFAMILY,almevttbl.SrcIPAddress11,almevttbl.SrcIPAddress12,
almevttbl.SrcIPAddress13,almevttbl.SrcIPAddress14,
almevttbl.DESTIPADDRFAMILY,almevttbl.DestIPAddress11,
almevttbl.DestIPAddress12,almevttbl.DestIPAddress13,
almevttbl.DestIPAddress14, almevttbl.DestPort, almevttbl.SrcPort,
almevttbl.SessionDir, almevttbl.CustomerId, almevttbl.ProfileId,
almevttbl.ParentProfileId, almevttbl.CustomerName, almevttbl.AttkDir,
almevttbl.SubCategory, almevttbl.RiskCategory, almevttbl.AssetValue,
almevttbl.IPSAction, almevttbl.l4Protocol,almevttbl.ExtraStrParam4 ,
almevttbl.ExtraStrParam5,almevttbl.username,almevttbl.ExtraStrParam6,
IpAddrFamily1,IPAddrValue11,IPAddrValue12,IPAddrValue13,IPAddrValue14,
IpAddrFamily2,IPAddrValue21,IPAddrValue22,IPAddrValue23,IPAddrValue24 FROM
AlmEvtTbl PARTITION(ALMEVTTBLP20100323) WHERE AlmEvtId IN ( SELECT * FROM
( SELECT /*+ FIRST_ROWS(1000) INDEX (AlmEvtTbl AlmEvtTbl_Index) */AlmEvtId
FROM AlmEvtTbl PARTITION(ALMEVTTBLP20100323) where ((AlmEvtTbl.Customerid
= 0 or AlmEvtTbl.ParentCustId = 0)) ORDER BY AlmEvtTbl.TIMESTAMP DESC)
WHERE ROWNUM < 602) order by timestamp desc
call count cpu elapsed disk query current rows
Parse 1 0.28 0.26 0 0 0 0
Execute 1 0.01 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.29 0.27 0 0 0 0
Misses in library cache during parse: 1
Optimizer mode: FIRST_ROWS
Parsing user id: 82
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
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 13 0.71 0.96 3 10 0 0
Execute 14 0.20 0.29 4 304 26 21
Fetch 92 2402.17 2714.85 3819 70033708 0 1255
total 119 2403.09 2716.10 3826 70034022 26 1276
Misses in library cache during parse: 10
Misses in library cache during execute: 6
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 49 0.00 0.00
SQL*Net message from client 48 29.88 163.43
db file sequential read 1966 0.20 28.10
latch free 21 0.00 0.01
latch: cache buffers chains 9 0.01 0.02
latch: session allocation 1 0.00 0.00
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 940 0.51 0.73 1 2 38 0
Execute 3263 1.93 2.62 7 1998 43 23
Fetch 6049 1.32 4.41 214 12858 36 13724
total 10252 3.78 7.77 222 14858 117 13747
Misses in library cache during parse: 172
Misses in library cache during execute: 168
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 88 0.04 0.62
latch: shared pool 8 0.00 0.00
latch: row cache objects 2 0.00 0.00
latch free 1 0.00 0.00
latch: session allocation 1 0.00 0.00
34 user SQL statements in session.
3125 internal SQL statements in session.
3159 SQL statements in session.
Trace file: ora11g_ora_2064.trc
Trace file compatibility: 11.01.00
Sort options: default
6 sessions in tracefile.
98 user SQL statements in trace file.
9111 internal SQL statements in trace file.
3159 SQL statements in trace file.
89 unique SQL statements in trace file.
30341 lines in trace file.
6810 elapsed seconds in trace file.
###################################### AutoTrace Output#################
Statistics
3901 recursive calls
0 db block gets
39030275 consistent gets
1970 physical reads
140 redo size
148739 bytes sent via SQL*Net to client
860 bytes received via SQL*Net from client
42 SQL*Net roundtrips to/from client
73 sorts (memory)
0 sorts (disk)
601 rows processed -
Dear experts,
Is there a way for the following SELECT query to be improved?
The problem that I'm seeing here is that the same table (l_item_tab) is being queried twice in the SELECT query (due to the "table joins", a and b). How can I improve the data retrieval here? And I also can't change the SELECT query to be out of the loop - ledger is a select-option and multiple values are possible.
* Get Ledger
SELECT * FROM t881 INTO TABLE lt_t881
WHERE rldnr IN s_rldnr.
LOOP AT lt_t881.
* Get FI-SL user-defined item table based on ledger
PERFORM get_sl_item_tab USING lt_t881-rldnr CHANGING l_item_tab.
" L_ITEM_TAB is populated here
* Get SL line items
SELECT * APPENDING CORRESPONDING FIELDS OF TABLE gt_glu1
FROM (l_item_tab) AS a
WHERE
rldnr IN s_rldnr " Ledger
AND rbukrs IN s_bukrs " Company code
AND ryyrkeg_wwsub IN s_wwsub " Subsystem
AND racct IN s_racct " Account no
AND ryymac IN s_yymac " Management area
AND rtcur IN s_rtcur " Trx currency
AND docnr IN s_docnr " Doc. number
AND docty IN s_docty " Doc. type
AND docct EQ c_docct_l " Doc. category (L = Local)
AND ryear IN s_ryear " Fiscal year
AND budat IN s_budat " Posting date
AND yystodt IN s_stodt " Reversal date
AND yystgrd IN s_stgrd " Reversal reason
AND yyintref IN s_intref " Interface ID
AND NOT exists
( SELECT * FROM (l_item_tab) AS b
WHERE
b~rldnr = a~rldnr AND
b~docnr = a~docnr AND
b~rbukrs = a~rbukrs AND
( ( ( b~docct = c_docct_y
OR b~docct = c_docct_x ) AND
b~refryear = a~ryear ) OR
( ( b~docct = c_docct_u
OR b~docct = c_docct_t ) AND
b~ryear = a~ryear ) )
ENDLOOP.
Edited by: Rob Burbank on Jun 23, 2010 12:33 PM>
Siegfried Boes wrote:
> > Will certainly try this out too..
> maybe you should think twice .... The usage of a subselect is that the result set is not transferred to the application server it is only needed
> during the selection.
>
> You should anser the following questions:
> + who wrote the code? you or? I get the impression that you don't know what is intended.
> + SQL Trace, what are the numbers for repeated executions, (go to summary by SQL statement), duration, execution, records
> + how many different tables are accessed, l_item_tab is dynamic
> + what knid of tables are accessed?
>
> Siegfried
Hi Siegfried,
- The codes are currently existing ones and they were not written by me too. I just do know that the first / main SELECT statement in the query is for retrieving FI special ledger line item data records, while the second / sub SELECT statement is to ensure that the line item data records are not already reversed, and not a reversal.
- In the summarized SQL trace of a sample test run: executions = 1, identical executions = 0, duration = 700247324 (almost 100% of the total processing durations), records = 0 (there should be more records returned in an actual production run)
- Only one table, ZZGLV4A (custom) is accessed based on the selection screen variant. ZZGLV4A is an FI special ledger line item table and its data volume: 455 mil. data records. Note: The codes are written for a report that runs in the background, and the selection screen variant is used for the executions too. The table accessed (l_item_tab is ZZGLV4A in this case) depends on the ledger inputted here - only one ledger is specified for the current selection screen variant.
- Table accessed - FI special ledger line item data.
I tried tuning the query a little further by just properly specifying the WHERE fields - only a minimal improvement is observed, an average of about 6% of runtime improvement only (tested via SE30 in the development box for ZZGLV4A but its table volume is 4 mil. data records here only). This obviously works only for the table ZZGLV4A for now, I'm afraid.
Any other ideas on how such subqueries can be improved generally (maybe secondary indexes)? The subquery is certainly re-hitting the same table at least twice.
Thanks for the inputs once again! -
SELECT query takes too much time! Y?
Plz find my SELECT query below:
select w~mandt
wvbeln wposnr wmeins wmatnr wwerks wnetwr
wkwmeng wvrkme wmatwa wcharg w~pstyv
wposar wprodh wgrkor wantlf wkztlf wlprio
wvstel wroute wumvkz wumvkn wabgru wuntto
wawahr werdat werzet wfixmg wprctr wvpmat
wvpwrk wmvgr1 wmvgr2 wmvgr3 wmvgr4 wmvgr5
wbedae wcuobj w~mtvfp
xetenr xwmeng xbmeng xettyp xwepos xabart
x~edatu
xtddat xmbdat xlddat xwadat xabruf xetart
x~ezeit
into table t_vbap
from vbap as w
inner join vbep as x on xvbeln = wvbeln and
xposnr = wposnr and
xmandt = wmandt
where
( ( werdat > pre_dat ) and ( werdat <= w_date ) ) and
( ( ( erdat > pre_dat and erdat < p_syndt ) or
( erdat = p_syndt and erzet <= p_syntm ) ) ) and
w~matnr in s_matnr and
w~pstyv in s_itmcat and
w~lfrel in s_lfrel and
w~abgru = ' ' and
w~kwmeng > 0 and
w~mtvfp in w_mtvfp and
x~ettyp in w_ettyp and
x~bdart in s_req_tp and
x~plart in s_pln_tp and
x~etart in s_etart and
x~abart in s_abart and
( ( xlifsp in s_lifsp ) or ( xlifsp = ' ' ) ).
The problem: It takes too much time while executing this statement.
Could anybody change this statement and help me out to reduce the DB Access time?
ThxWays of Performance Tuning
1. Selection Criteria
2. Select Statements
Select Queries
SQL Interface
Aggregate Functions
For all Entries
Select Over more than one internal table
Selection Criteria
1. Restrict the data to the selection criteria itself, rather than filtering it out using the ABAP code using CHECK statement.
2. Select with selection list.
SELECT * FROM SBOOK INTO SBOOK_WA.
CHECK: SBOOK_WA-CARRID = 'LH' AND
SBOOK_WA-CONNID = '0400'.
ENDSELECT.
The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list
SELECT CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK
WHERE SBOOK_WA-CARRID = 'LH' AND
SBOOK_WA-CONNID = '0400'.
Select Statements Select Queries
1. Avoid nested selects
SELECT * FROM EKKO INTO EKKO_WA.
SELECT * FROM EKAN INTO EKAN_WA
WHERE EBELN = EKKO_WA-EBELN.
ENDSELECT.
ENDSELECT.
The above code can be much more optimized by the code written below.
SELECT PF1 PF2 FF3 FF4 INTO TABLE ITAB
FROM EKKO AS P INNER JOIN EKAN AS F
ON PEBELN = FEBELN.
Note: A simple SELECT loop is a single database access whose result is passed to the ABAP program line by line. Nested SELECT loops mean that the number of accesses in the inner loop is multiplied by the number of accesses in the outer loop. One should therefore use nested SELECT loops only if the selection in the outer loop contains very few lines or the outer loop is a SELECT SINGLE statement.
2. Select all the records in a single shot using into table clause of select statement rather than to use Append statements.
SELECT * FROM SBOOK INTO SBOOK_WA.
CHECK: SBOOK_WA-CARRID = 'LH' AND
SBOOK_WA-CONNID = '0400'.
ENDSELECT.
The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list and puts the data in one shot using into table
SELECT CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK
WHERE SBOOK_WA-CARRID = 'LH' AND
SBOOK_WA-CONNID = '0400'.
3. When a base table has multiple indices, the where clause should be in the order of the index, either a primary or a secondary index.
To choose an index, the optimizer checks the field names specified in the where clause and then uses an index that has the same order of the fields. In certain scenarios, it is advisable to check whether a new index can speed up the performance of a program. This will come handy in programs that access data from the finance tables.
4. For testing existence, use Select.. Up to 1 rows statement instead of a Select-Endselect-loop with an Exit.
SELECT * FROM SBOOK INTO SBOOK_WA
UP TO 1 ROWS
WHERE CARRID = 'LH'.
ENDSELECT.
The above code is more optimized as compared to the code mentioned below for testing existence of a record.
SELECT * FROM SBOOK INTO SBOOK_WA
WHERE CARRID = 'LH'.
EXIT.
ENDSELECT.
5. Use Select Single if all primary key fields are supplied in the Where condition .
If all primary key fields are supplied in the Where conditions you can even use Select Single.
Select Single requires one communication with the database system, whereas Select-Endselect needs two.
Select Statements SQL Interface
1. Use column updates instead of single-row updates
to update your database tables.
SELECT * FROM SFLIGHT INTO SFLIGHT_WA.
SFLIGHT_WA-SEATSOCC =
SFLIGHT_WA-SEATSOCC - 1.
UPDATE SFLIGHT FROM SFLIGHT_WA.
ENDSELECT.
The above mentioned code can be more optimized by using the following code
UPDATE SFLIGHT
SET SEATSOCC = SEATSOCC - 1.
2. For all frequently used Select statements, try to use an index.
SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA
WHERE CARRID = 'LH'
AND CONNID = '0400'.
ENDSELECT.
The above mentioned code can be more optimized by using the following code
SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA
WHERE MANDT IN ( SELECT MANDT FROM T000 )
AND CARRID = 'LH'
AND CONNID = '0400'.
ENDSELECT.
3. Using buffered tables improves the performance considerably.
Bypassing the buffer increases the network considerably
SELECT SINGLE * FROM T100 INTO T100_WA
BYPASSING BUFFER
WHERE SPRSL = 'D'
AND ARBGB = '00'
AND MSGNR = '999'.
The above mentioned code can be more optimized by using the following code
SELECT SINGLE * FROM T100 INTO T100_WA
WHERE SPRSL = 'D'
AND ARBGB = '00'
AND MSGNR = '999'.
Select Statements Aggregate Functions
If you want to find the maximum, minimum, sum and average value or the count of a database column, use a select list with aggregate functions instead of computing the aggregates yourself.
Some of the Aggregate functions allowed in SAP are MAX, MIN, AVG, SUM, COUNT, COUNT( * )
Consider the following extract.
Maxno = 0.
Select * from zflight where airln = LF and cntry = IN.
Check zflight-fligh > maxno.
Maxno = zflight-fligh.
Endselect.
The above mentioned code can be much more optimized by using the following code.
Select max( fligh ) from zflight into maxno where airln = LF and cntry = IN.
Select Statements For All Entries
The for all entries creates a where clause, where all the entries in the driver table are combined with OR. If the number of entries in the driver table is larger than rsdb/max_blocking_factor, several similar SQL statements are executed to limit the length of the WHERE clause.
The plus
Large amount of data
Mixing processing and reading of data
Fast internal reprocessing of data
Fast
The Minus
Difficult to program/understand
Memory could be critical (use FREE or PACKAGE size)
Points to be must considered FOR ALL ENTRIES
Check that data is present in the driver table
Sorting the driver table
Removing duplicates from the driver table
Consider the following piece of extract
Loop at int_cntry.
Select single * from zfligh into int_fligh
where cntry = int_cntry-cntry.
Append int_fligh.
Endloop.
The above mentioned can be more optimized by using the following code.
Sort int_cntry by cntry.
Delete adjacent duplicates from int_cntry.
If NOT int_cntry[] is INITIAL.
Select * from zfligh appending table int_fligh
For all entries in int_cntry
Where cntry = int_cntry-cntry.
Endif.
Select Statements Select Over more than one Internal table
1. Its better to use a views instead of nested Select statements.
SELECT * FROM DD01L INTO DD01L_WA
WHERE DOMNAME LIKE 'CHAR%'
AND AS4LOCAL = 'A'.
SELECT SINGLE * FROM DD01T INTO DD01T_WA
WHERE DOMNAME = DD01L_WA-DOMNAME
AND AS4LOCAL = 'A'
AND AS4VERS = DD01L_WA-AS4VERS
AND DDLANGUAGE = SY-LANGU.
ENDSELECT.
The above code can be more optimized by extracting all the data from view DD01V_WA
SELECT * FROM DD01V INTO DD01V_WA
WHERE DOMNAME LIKE 'CHAR%'
AND DDLANGUAGE = SY-LANGU.
ENDSELECT
2. To read data from several logically connected tables use a join instead of nested Select statements. Joins are preferred only if all the primary key are available in WHERE clause for the tables that are joined. If the primary keys are not provided in join the Joining of tables itself takes time.
SELECT * FROM EKKO INTO EKKO_WA.
SELECT * FROM EKAN INTO EKAN_WA
WHERE EBELN = EKKO_WA-EBELN.
ENDSELECT.
ENDSELECT.
The above code can be much more optimized by the code written below.
SELECT PF1 PF2 FF3 FF4 INTO TABLE ITAB
FROM EKKO AS P INNER JOIN EKAN AS F
ON PEBELN = FEBELN.
3. Instead of using nested Select loops it is often better to use subqueries.
SELECT * FROM SPFLI
INTO TABLE T_SPFLI
WHERE CITYFROM = 'FRANKFURT'
AND CITYTO = 'NEW YORK'.
SELECT * FROM SFLIGHT AS F
INTO SFLIGHT_WA
FOR ALL ENTRIES IN T_SPFLI
WHERE SEATSOCC < F~SEATSMAX
AND CARRID = T_SPFLI-CARRID
AND CONNID = T_SPFLI-CONNID
AND FLDATE BETWEEN '19990101' AND '19990331'.
ENDSELECT.
The above mentioned code can be even more optimized by using subqueries instead of for all entries.
SELECT * FROM SFLIGHT AS F INTO SFLIGHT_WA
WHERE SEATSOCC < F~SEATSMAX
AND EXISTS ( SELECT * FROM SPFLI
WHERE CARRID = F~CARRID
AND CONNID = F~CONNID
AND CITYFROM = 'FRANKFURT'
AND CITYTO = 'NEW YORK' )
AND FLDATE BETWEEN '19990101' AND '19990331'.
ENDSELECT.
1. Table operations should be done using explicit work areas rather than via header lines.
READ TABLE ITAB INTO WA WITH KEY K = 'X BINARY SEARCH.
IS MUCH FASTER THAN USING
READ TABLE ITAB INTO WA WITH KEY K = 'X'.
If TAB has n entries, linear search runs in O( n ) time, whereas binary search takes only O( log2( n ) ).
2. Always try to use binary search instead of linear search. But dont forget to sort your internal table before that.
READ TABLE ITAB INTO WA WITH KEY K = 'X'. IS FASTER THAN USING
READ TABLE ITAB INTO WA WITH KEY (NAME) = 'X'.
3. A dynamic key access is slower than a static one, since the key specification must be evaluated at runtime.
4. A binary search using secondary index takes considerably less time.
5. LOOP ... WHERE is faster than LOOP/CHECK because LOOP ... WHERE evaluates the specified condition internally.
LOOP AT ITAB INTO WA WHERE K = 'X'.
ENDLOOP.
The above code is much faster than using
LOOP AT ITAB INTO WA.
CHECK WA-K = 'X'.
ENDLOOP.
6. Modifying selected components using MODIFY itab TRANSPORTING f1 f2.. accelerates the task of updating a line of an internal table.
WA-DATE = SY-DATUM.
MODIFY ITAB FROM WA INDEX 1 TRANSPORTING DATE.
The above code is more optimized as compared to
WA-DATE = SY-DATUM.
MODIFY ITAB FROM WA INDEX 1.
7. Accessing the table entries directly in a "LOOP ... ASSIGNING ..." accelerates the task of updating a set of lines of an internal table considerably
Modifying selected components only makes the program faster as compared to Modifying all lines completely.
e.g,
LOOP AT ITAB ASSIGNING <WA>.
I = SY-TABIX MOD 2.
IF I = 0.
<WA>-FLAG = 'X'.
ENDIF.
ENDLOOP.
The above code works faster as compared to
LOOP AT ITAB INTO WA.
I = SY-TABIX MOD 2.
IF I = 0.
WA-FLAG = 'X'.
MODIFY ITAB FROM WA.
ENDIF.
ENDLOOP.
8. If collect semantics is required, it is always better to use to COLLECT rather than READ BINARY and then ADD.
LOOP AT ITAB1 INTO WA1.
READ TABLE ITAB2 INTO WA2 WITH KEY K = WA1-K BINARY SEARCH.
IF SY-SUBRC = 0.
ADD: WA1-VAL1 TO WA2-VAL1,
WA1-VAL2 TO WA2-VAL2.
MODIFY ITAB2 FROM WA2 INDEX SY-TABIX TRANSPORTING VAL1 VAL2.
ELSE.
INSERT WA1 INTO ITAB2 INDEX SY-TABIX.
ENDIF.
ENDLOOP.
The above code uses BINARY SEARCH for collect semantics. READ BINARY runs in O( log2(n) ) time. The above piece of code can be more optimized by
LOOP AT ITAB1 INTO WA.
COLLECT WA INTO ITAB2.
ENDLOOP.
SORT ITAB2 BY K.
COLLECT, however, uses a hash algorithm and is therefore independent
of the number of entries (i.e. O(1)) .
9. "APPEND LINES OF itab1 TO itab2" accelerates the task of appending a table to another table considerably as compared to LOOP-APPEND-ENDLOOP.
APPEND LINES OF ITAB1 TO ITAB2.
This is more optimized as compared to
LOOP AT ITAB1 INTO WA.
APPEND WA TO ITAB2.
ENDLOOP.
10. DELETE ADJACENT DUPLICATES accelerates the task of deleting duplicate entries considerably as compared to READ-LOOP-DELETE-ENDLOOP.
DELETE ADJACENT DUPLICATES FROM ITAB COMPARING K.
This is much more optimized as compared to
READ TABLE ITAB INDEX 1 INTO PREV_LINE.
LOOP AT ITAB FROM 2 INTO WA.
IF WA = PREV_LINE.
DELETE ITAB.
ELSE.
PREV_LINE = WA.
ENDIF.
ENDLOOP.
11. "DELETE itab FROM ... TO ..." accelerates the task of deleting a sequence of lines considerably as compared to DO -DELETE-ENDDO.
DELETE ITAB FROM 450 TO 550.
This is much more optimized as compared to
DO 101 TIMES.
DELETE ITAB INDEX 450.
ENDDO.
12. Copying internal tables by using ITAB2[ ] = ITAB1[ ] as compared to LOOP-APPEND-ENDLOOP.
ITAB2[] = ITAB1[].
This is much more optimized as compared to
REFRESH ITAB2.
LOOP AT ITAB1 INTO WA.
APPEND WA TO ITAB2.
ENDLOOP.
13. Specify the sort key as restrictively as possible to run the program faster.
SORT ITAB BY K. makes the program runs faster as compared to SORT ITAB.
Internal Tables contd
Hashed and Sorted tables
1. For single read access hashed tables are more optimized as compared to sorted tables.
2. For partial sequential access sorted tables are more optimized as compared to hashed tables
Hashed And Sorted Tables
Point # 1
Consider the following example where HTAB is a hashed table and STAB is a sorted table
DO 250 TIMES.
N = 4 * SY-INDEX.
READ TABLE HTAB INTO WA WITH TABLE KEY K = N.
IF SY-SUBRC = 0.
ENDIF.
ENDDO.
This runs faster for single read access as compared to the following same code for sorted table
DO 250 TIMES.
N = 4 * SY-INDEX.
READ TABLE STAB INTO WA WITH TABLE KEY K = N.
IF SY-SUBRC = 0.
ENDIF.
ENDDO.
Point # 2
Similarly for Partial Sequential access the STAB runs faster as compared to HTAB
LOOP AT STAB INTO WA WHERE K = SUBKEY.
ENDLOOP.
This runs faster as compared to
LOOP AT HTAB INTO WA WHERE K = SUBKEY.
ENDLOOP. -
Dear all ,
I am fetching data from pool table a006. The select query is mentioned below.
select * from a005 into table i_a005 for all wntries in it_table
where kappl = 'V'
and kschl IN s_kschl
and vkorg in s_vkorg
and vtweg in s_vtgew
and matnr in s_matnr
and knumh = it_table-knumh .
here every fields are primary key fields except one field knumh which is comparing with table it_table. Because of these field this query is taking too much time as KNUMH is not primary key. And a005 is pool table . So , i cant create index for same. If there is alternate solutions , than please let me know..
Thank You ,
And in technical setting of table ITS Metioned as Fully buffered and size category is 0 .. But data are around 9000000. Is it issue or What ? Can somebody tell some genual reason ? Or improvement in my select query.........
Edited by: TVC6784 on Jun 30, 2011 3:31 PMTVC6784 wrote:
Hi Yuri ,
>
> Thanks for your reply....I will check as per your comment...
> bUT if i remove field KNUMH From selection condition and also for all entries in it_itab , than data fetch very fast As KNUMH is not primary key..
> . the example is below
>
> select * from a005 into table i_a005
> where kappl = 'V'
> and kschl IN s_kschl
> and vkorg in s_vkorg
> and vtweg in s_vtgew
> and matnr in s_matnr.
>
> Can you comment anything about it ?
>
> And can you please say how can i check its size as you mention that is 2-3 Mb More ?
>
> Edited by: TVC6784 on Jun 30, 2011 7:37 PM
I cannot see the trace and other information about the table so I cannot judge why the select w/o KNUMH is faster.
Basically, if the table is buffered and it's contents is in the SAP application server memory, the access should be really fast. Does not really matter if it is with KNUMH or without.
I would really like to see at least ST05 trace of your report that is doing this select. This would clarify many things.
You can check the size by multiplying the entries in A005 table by 138. This is (in my test system) the ABAP width of the structure.
If you have 9.000.000 records in A005, then it would take 1,24 Gb in the buffer (which is a clear sign to unbuffer). -
Query works in Access but not CF
I wrote this query initially in access to extract the data I
wanted out of my table. In MS Access, the query works fine, returns
the desired data. When I run the query from my CF page, i get the
following error:
Error Executing Database Query.
[Macromedia][SequeLink JDBC Driver][ODBC
Socket][Microsoft][ODBC Microsoft Access Driver] Too few
parameters. Expected 2.
Can anyone tell me why? Below is my queryAs the IIF function is a valid CF function, it may not be
getting passed as 'plain text' to Access, instead CF
may be attempting to compile the function and pass the
result. If you can turn on debugging and for a short time set it to
include the SQL being passed in error messages, you can see what is
really going on.
Another option is to create/save the query in the Access
database and reference that instead of a table in your CFQUERY
call. Since you are just running a staright query and not passing
anything from CF (unless I am mistaken), calling the Access query
for your results would work fine.
<CFQUERY ...>
SELECT * FROM myQueryName
</CFQUERY>
HTH,
CR -
Hi, I wish to select rows from a database. This is the query I wrote:
"SELECT * FROM opencalls WHERE ProblemDescription LIKE '*upgrade*'".
When I run this query in MS Access itself, there is no problem, I get the required rows. But when I run it in my program, I get no results. When I remove the *, there is no problem either in my Java program. What's the correct way to make my program interprete the *?
Thanks, Roellook... i don't know why u r using the * character?? in SQL if u wanna place a one character matching u should use _ (underscore) and for more than one character matching u should use % so for example if u wanna look in a table for the matching of the word "Cookie" and u want this word to be the first word in the sentance of that field u do the following:
SELECT * FROM table_name WHERE field_name LIKE 'Cookie%';
this will take care of that. suppose u wanna look for sentances that have the first word as either Rook or Book then u can use that query with the Underscore as the first character:
SELECT * FROM table_name WHERE field_name LIKE '_ook%';
for ur case u wanna query the table for any sentences that have the word upgrade.. then u should use the following:
SELECT * FROM opencalls WHERE ProblemDescription LIKE '%upgrade%';
i think this will work fine...i hope this would be the solution for ur problem : )
Khalid -
Issue with select query for secondary index
Hi all,
I have created a secondary index A on mara table with fields Mandt and Packaging Material Type VHART.
Now i am trying to write a report
Tables : mara.
data : begin of itab occurs 0.
include structure mara.
data : end of itab.
*select * from mara into table itab*
CLIENT SPECIFIED where
MANDT = SY-MANDT and
VHART = 'WER'.
I'm getting an error
Unable to interpret "CLIENT". Possible causes of error: Incorrect spelling or comma error.
if i change to my select query to
*select * from mara into table itab*
where
MANDT = SY-MANDT and
VHART = 'WER'.
I'm getting an error
Without the addition "CLIENT SPECIFIED", you cannot specify the client field "MANDT" in the WHERE condition.
Let me know if iam wrong and we are at 4.6c
ThanksLike I already said, even if you have added the mandt field in the secondary index, there is no need the use it in the select statement.
Let me elaborate on my reply before. If you have created a UNIQUE index, which I don't think you have, then you should include CLIENT in the index. A unique index for a client-dependent table must contain the client field.
Additional info:
The accessing speed does not depend on whether or not an index is defined as a unique index. A unique index is simply a means of defining that certain field combinations of data records in a table are unique.
Even if you have defined a secondary index, this does not automatically mean, that this index is used. This also depends on the database optimizer. The optimizer will determine which index is best and use it. So before transporting this index, you should make sure that the index is used. How to check this, have a look at the link:
[check if index is used|http://help.sap.com/saphelp_nw70/helpdata/EN/cf/21eb3a446011d189700000e8322d00/content.htm]
Edited by: Micky Oestreich on May 13, 2008 10:09 PM
Maybe you are looking for
-
Itunes installation pckg error with Windows Vista
I keep trying to install itunes onto my new computer and keep getting this message, "This installation package could not be opened. Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a
-
Why does my slingbox no longer work on my firefox?
my slingbox no longer works, even though the slingbox site says it works with firefox 4 or above.
-
I've noticed that when certain games are close to launch that Best Buy often offers free expedited shipping, which usually results in getting the game on release date. I assume this is because they know they will have the game early enough to offer r
-
User SAAPOS has no RFC authorization for function group SYST
Dear Experts , I am facing this issue kindly help me to sort out this issue. User SAAPOS has no RFC authorization for function group SYST Thanks in advance Thanks & Regards, Srinivasan.V Moderator message: please search for available information and
-
Hi:) I'm trying to export a 3 minute and 25 second edited video to burn to DVD. The video was recorded on a Canon HV20 (consumer HD) and on HD DV tapes, when I make a Quicktime movie the quality looks great but when try to burn that on to DVD using i