Select Query Takes more time
Hi All,
I have cloned KSB1 tcode to custom one as required by business.
Below query takes more time than excepted.
Here V_DB_TABLE = COVP.
Values in Where clause are as follows
OBNJR in ( KSBB010000001224 BT KSBB012157221571)
GJAHR in blank
VERSN in '000'
WRTTP in '04' and '11'
all others are blank
VT_VAR_COND = ( CPUDT BETWEEN '20091201' and '20091208' )
SELECT (VT_FIELDS) INTO CORRESPONDING FIELDS OF GS_COVP_EXT
FROM (V_DB_TABLE)
WHERE LEDNR = '00'
AND OBJNR IN LR_OBJNR
AND GJAHR IN GR_GJAHR
AND VERSN IN GR_VERSN
AND WRTTP IN GR_WRTTP
AND KSTAR IN LR_KSTAR
AND PERIO IN GR_PERIO
AND BUDAT IN GR_BUDAT
AND PAROB IN GR_PAROB
AND (VT_VAR_COND).
Checked in table for this condition it has only 92 entries.
But when i execute program takes long time as 3 Hrs.
Could any one help me on this
>1.Dont use SELECT/ENDSELECT instead use INTO TABLE addition .
> 2.Avoid using corresponding addition.create a type and reference it.
> If the select is going for dump beacause of storage limitations ,then use Cursors.
you got three large NOs .... all three recommendations are wrong!
The SE16 test is going in the right direction ... but what was filled. Nobody knows!!!!
Select options:
Did you ever try to trace the SE16? The generic statement has for every field an in-condition!
Without the information what was actually filled, nobody can say something there
are at least 2**n combinations possible!
Use ST05 for SE16 and check actual statement plus explain!
Similar Messages
-
Count (*) for select stmt take more time than execute a that sql stmt
HI
count (*) for select stmt take more time than execute a that sql stmt
executing particular select stmt take 2.47 mins but select stmt is using the /*+parallel*/ (sql optimer) in that sql command for faster execute .
but if i tried to find out total number of rows in that query it takes more time ..
almost 2.30 hrs still running to find count(col)
please help me to get count of row faster.
thanks in advance...797525 wrote:
HI
count (*) for select stmt take more time than execute a that sql stmt
executing particular select stmt take 2.47 mins but select stmt is using the /*+parallel*/ (sql optimer) in that sql command for faster execute .
but if i tried to find out total number of rows in that query it takes more time ..
almost 2.30 hrs still running to find count(col)
please help me to get count of row faster.
thanks in advance...That may be because your client is displaying only the first few records when you are running the "SELECT *". But when you run "COUNT(*)", the whole records has to be counted.
As already mentined please read teh FAQ to post tuning questions. -
What is the reason for query take more time to execute
Hi,
What is the reason for the query take more time inside procedure.
but if i execute that query alone then it excute within a minutes.
query includes update and insert.I have a insert and update query when I execute
without Procedure then that query execute faster but
If I execute inside procedure then It takes 2 hours
to execute.Put you watch 2 hours back and the problem will disappear.
do you understand what I want to say?I understood what you wanted to say and I understood you didn't understood what I said.
What does the procedure, what does the query, how can you say the query does the same as the procedure that takes longer. You didn't say anything useful to have an idea of what you're talking about.
Everyone knows what means that something is slower than something else, but it means nothing if you don't say what you're talking about.
To begin with something take a look at this
When your query takes too long ...
especially the part regarding the trace.
Bye Alessandro -
Query Takes more Time when i execute from the Instant client.
Hi,
Currently in our Env we have some Queries takes more time when we run from the Instant Client.
System Details
OS=Solaris 10 x86 64bit
Oracle 10.2.0.4
Client Side
$ sqlplus trd_trd_ro/trd_trd_ro@prdba001/TRADE1
SQL*Plus: Release 10.2.0.2.0 - Production on Mon Aug 9 16:26:25 2010
Copyright (c) 1982, 2005, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Release 10.2.0.4.0 - Production
SQL> set timing on
SQL> select mod(lastinstmessagesequence, 1000000000) LastInstIDSeqNo from tibex_msgseqbyuseralias where useralias='2221';
no rows selected
Elapsed: 00:01:54.19
SQL> Disconnected from Oracle Database 10g Release 10.2.0.4.0 - ProductionSame Query running on Server Side
^C130-oracle@prdba001 txt: sql
Database: trd_trd_owner/trd_trd_owner@prdba001/TRADE1
SQL*Plus: Release 10.2.0.4.0 - Production on Mon Aug 9 17:15:18 2010
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Release 10.2.0.4.0 - Production
trd_trd_owner@TRADE1> set timing on
trd_trd_owner@TRADE1> select mod(lastinstmessagesequence, 1000000000) LastInstIDSeqNo from tibex_msgseqbyuseralias where useralias='2221';
no rows selected
Elapsed: 00:00:00.12
trd_trd_owner@TRADE1> exitKindly help me what could be the Issues.Hi Charles,
Thanks for your Quick response.I pulled the info.
sys@TRADE1> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('bpxr7axhxaqvy',NULL,'ALLSTATS LAST'));
PLAN_TABLE_OUTPUT
SQL_ID bpxr7axhxaqvy, child number 0
select /*+ GATHER_PLAN_STATISTICS */ mod(lastinstmessagesequence, :"SYS_B_0") LastInstIDSeqNo from
tibex_msgseqbyuseralias where useralias=:"SYS_B_1"
Plan hash value: 1955857846
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
| 1 | SORT GROUP BY NOSORT | | 1 | 21 | 0 |00:00:00.06 | 6121 |
| 2 | VIEW | | 1 | 21 | 0 |00:00:00.06 | 6121 |
| 3 | UNION-ALL | | 1 | | 0 |00:00:00.06 | 6121 |
| 4 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.05 | 3073 |
|* 5 | TABLE ACCESS FULL | TIBEX_QUOTE | 1 | 30080 | 0 |00:00:00.05 | 3073 |
| 6 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 |
| 7 | TABLE ACCESS BY INDEX ROWID| TIBEX_ORDER | 1 | 971 | 0 |00:00:00.01 | 3 |
|* 8 | INDEX RANGE SCAN | TIBEX_ORDER_IDX_OLT | 1 | 971 | 0 |00:00:00.01 | 3 |
| 9 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 |
|* 10 | TABLE ACCESS FULL | TIBEX_TSTRADE | 1 | 1 | 0 |00:00:00.01 | 3 |
| 11 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 |
|* 12 | TABLE ACCESS FULL | TIBEX_IOIREQUEST | 1 | 1 | 0 |00:00:00.01 | 3 |
| 13 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 126 |
|* 14 | TABLE ACCESS FULL | TIBEX_BESTEXREL | 1 | 1 | 0 |00:00:00.01 | 126 |
| 15 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 2862 |
|* 16 | INDEX FAST FULL SCAN | SYS_C0058325 | 1 | 339 | 0 |00:00:00.01 | 2862 |
| 17 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 31 |
|* 18 | TABLE ACCESS FULL | TIBEX_EDPPULLORDERS | 1 | 1 | 0 |00:00:00.01 | 31 |
| 19 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 20 | INDEX RANGE SCAN | SYS_C0058803 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 21 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 22 | INDEX RANGE SCAN | SYS_C0057785 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 23 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 24 | INDEX RANGE SCAN | SYS_C0057827 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 25 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 |
|* 26 | TABLE ACCESS FULL | TIBEX_DELETEADMIN | 1 | 1 | 0 |00:00:00.01 | 3 |
| 27 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 28 | INDEX RANGE SCAN | SYS_C0058148 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 29 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 30 | INDEX RANGE SCAN | SYS_C0058264 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 31 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 32 | INDEX RANGE SCAN | SYS_C0058516 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 33 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 34 | INDEX RANGE SCAN | SYS_C0058561 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 35 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 36 | INDEX RANGE SCAN | SYS_C0058783 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 37 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 38 | INDEX RANGE SCAN | SYS_C0058977 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 39 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 40 | INDEX RANGE SCAN | SYS_C0058859 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 41 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 42 | INDEX RANGE SCAN | SYS_C0059197 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 43 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 |
|* 44 | TABLE ACCESS FULL | TIBEX_CANCELTRDADMIN | 1 | 1 | 0 |00:00:00.01 | 3 |
| 45 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 |
|* 46 | TABLE ACCESS FULL | TIBEX_BULKCANCELADMIN | 1 | 1 | 0 |00:00:00.01 | 3 |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
5 - filter("LASTINSTUSERALIAS"=:SYS_B_1)
8 - access("LASTINSTUSERALIAS"=:SYS_B_1)
10 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
12 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
14 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
16 - filter("USERALIAS"=:SYS_B_1)
18 - filter("USERALIAS"=:SYS_B_1)
20 - access("USERALIAS"=:SYS_B_1)
22 - access("USERALIAS"=:SYS_B_1)
24 - access("USERALIAS"=:SYS_B_1)
26 - filter(("USERALIAS" IS NOT NULL AND "USERALIAS"=:SYS_B_1))
28 - access("USERALIAS"=:SYS_B_1)
30 - access("USERALIAS"=:SYS_B_1)
32 - access("USERALIAS"=:SYS_B_1)
34 - access("USERALIAS"=:SYS_B_1)
36 - access("USERALIAS"=:SYS_B_1)
38 - access("USERALIAS"=:SYS_B_1)
40 - access("USERALIAS"=:SYS_B_1)
42 - access("USERALIAS"=:SYS_B_1)
44 - filter("USERALIAS"=:SYS_B_1)
46 - filter("USERALIAS"=:SYS_B_1)
SQL_ID bpxr7axhxaqvy, child number 1
select /*+ GATHER_PLAN_STATISTICS */ mod(lastinstmessagesequence, :"SYS_B_0") LastInstIDSeqNo from
tibex_msgseqbyuseralias where useralias=:"SYS_B_1"
Plan hash value: 1955857846
Plan hash value: 1955857846
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
| 1 | SORT GROUP BY NOSORT | | 1 | 21 | 0 |00:00:00.12 | 8545 |
| 2 | VIEW | | 1 | 21 | 0 |00:00:00.12 | 8545 |
| 3 | UNION-ALL | | 1 | | 0 |00:00:00.12 | 8545 |
| 4 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.10 | 5496 |
|* 5 | TABLE ACCESS FULL | TIBEX_QUOTE | 1 | 21056 | 0 |00:00:00.10 | 5496 |
| 6 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 4 |
| 7 | TABLE ACCESS BY INDEX ROWID| TIBEX_ORDER | 1 | 660 | 0 |00:00:00.01 | 4 |
|* 8 | INDEX RANGE SCAN | TIBEX_ORDER_IDX_OLT | 1 | 660 | 0 |00:00:00.01 | 4 |
| 9 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 |
|* 10 | TABLE ACCESS FULL | TIBEX_TSTRADE | 1 | 1 | 0 |00:00:00.01 | 3 |
| 11 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 |
|* 12 | TABLE ACCESS FULL | TIBEX_IOIREQUEST | 1 | 1 | 0 |00:00:00.01 | 3 |
| 13 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 126 |
|* 14 | TABLE ACCESS FULL | TIBEX_BESTEXREL | 1 | 1 | 0 |00:00:00.01 | 126 |
| 15 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.02 | 2862 |
|* 16 | INDEX FAST FULL SCAN | SYS_C0058325 | 1 | 339 | 0 |00:00:00.02 | 2862 |
| 17 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 31 |
|* 18 | TABLE ACCESS FULL | TIBEX_EDPPULLORDERS | 1 | 1 | 0 |00:00:00.01 | 31 |
| 19 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 20 | INDEX RANGE SCAN | SYS_C0058803 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 21 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 22 | INDEX RANGE SCAN | SYS_C0057785 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 23 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 24 | INDEX RANGE SCAN | SYS_C0057827 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 25 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 |
|* 26 | TABLE ACCESS FULL | TIBEX_DELETEADMIN | 1 | 1 | 0 |00:00:00.01 | 3 |
| 27 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 28 | INDEX RANGE SCAN | SYS_C0058148 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 29 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
PLAN_TABLE_OUTPUT
|* 30 | INDEX RANGE SCAN | SYS_C0058264 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 31 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 32 | INDEX RANGE SCAN | SYS_C0058516 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 33 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 34 | INDEX RANGE SCAN | SYS_C0058561 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 35 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 36 | INDEX RANGE SCAN | SYS_C0058783 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 37 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 38 | INDEX RANGE SCAN | SYS_C0058977 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 39 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 40 | INDEX RANGE SCAN | SYS_C0058859 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 41 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 42 | INDEX RANGE SCAN | SYS_C0059197 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 43 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 |
|* 44 | TABLE ACCESS FULL | TIBEX_CANCELTRDADMIN | 1 | 1 | 0 |00:00:00.01 | 3 |
| 45 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 |
|* 46 | TABLE ACCESS FULL | TIBEX_BULKCANCELADMIN | 1 | 1 | 0 |00:00:00.01 | 3 |
Predicate Information (identified by operation id):
5 - filter("LASTINSTUSERALIAS"=:SYS_B_1)
8 - access("LASTINSTUSERALIAS"=:SYS_B_1)
10 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
12 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
14 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
16 - filter("USERALIAS"=:SYS_B_1)
18 - filter("USERALIAS"=:SYS_B_1)
20 - access("USERALIAS"=:SYS_B_1)
22 - access("USERALIAS"=:SYS_B_1)
24 - access("USERALIAS"=:SYS_B_1)
26 - filter(("USERALIAS" IS NOT NULL AND "USERALIAS"=:SYS_B_1))
28 - access("USERALIAS"=:SYS_B_1)
30 - access("USERALIAS"=:SYS_B_1)
32 - access("USERALIAS"=:SYS_B_1)
34 - access("USERALIAS"=:SYS_B_1)
36 - access("USERALIAS"=:SYS_B_1)
38 - access("USERALIAS"=:SYS_B_1)
40 - access("USERALIAS"=:SYS_B_1)
42 - access("USERALIAS"=:SYS_B_1)
44 - filter("USERALIAS"=:SYS_B_1)
46 - filter("USERALIAS"=:SYS_B_1)
SQL_ID bpxr7axhxaqvy, child number 2
select /*+ GATHER_PLAN_STATISTICS */ mod(lastinstmessagesequence, :"SYS_B_0") LastInstIDSeqNo from
tibex_msgseqbyuseralias where useralias=:"SYS_B_1"
Plan hash value: 1955857846
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads |
| 1 | SORT GROUP BY NOSORT | | 1 | 21 | 1 |00:00:00.13 | 8476 | 3 |
| 2 | VIEW | | 1 | 21 | 1 |00:00:00.13 | 8476 | 3 |
| 3 | UNION-ALL | | 1 | | 1 |00:00:00.13 | 8476 | 3 |
| 4 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.10 | 5283 | 0 |
|* 5 | TABLE ACCESS FULL | TIBEX_QUOTE | 1 | 21056 | 0 |00:00:00.10 | 5283 | 0 |
| 6 | SORT GROUP BY NOSORT | | 1 | 1 | 1 |00:00:00.01 | 148 | 3 |
| 7 | TABLE ACCESS BY INDEX ROWID| TIBEX_ORDER | 1 | 660 | 150 |00:00:00.01 | 148 | 3 |
PLAN_TABLE_OUTPUT
|* 8 | INDEX RANGE SCAN | TIBEX_ORDER_IDX_OLT | 1 | 660 | 150 |00:00:00.01 | 5 | 0 |
| 9 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 | 0 |
|* 10 | TABLE ACCESS FULL | TIBEX_TSTRADE | 1 | 1 | 0 |00:00:00.01 | 3 | 0 |
| 11 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 | 0 |
|* 12 | TABLE ACCESS FULL | TIBEX_IOIREQUEST | 1 | 1 | 0 |00:00:00.01 | 3 | 0 |
| 13 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 126 | 0 |
|* 14 | TABLE ACCESS FULL | TIBEX_BESTEXREL | 1 | 1 | 0 |00:00:00.01 | 126 | 0 |
| 15 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.02 | 2862 | 0 |
|* 16 | INDEX FAST FULL SCAN | SYS_C0058325 | 1 | 339 | 0 |00:00:00.02 | 2862 | 0 |
| 17 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 31 | 0 |
|* 18 | TABLE ACCESS FULL | TIBEX_EDPPULLORDERS | 1 | 1 | 0 |00:00:00.01 | 31 | 0 |
| 19 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
|* 20 | INDEX RANGE SCAN | SYS_C0058803 | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
| 21 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
|* 22 | INDEX RANGE SCAN | SYS_C0057785 | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
| 23 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
|* 24 | INDEX RANGE SCAN | SYS_C0057827 | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
| 25 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 | 0 |
|* 26 | TABLE ACCESS FULL | TIBEX_DELETEADMIN | 1 | 1 | 0 |00:00:00.01 | 3 | 0 |
| 27 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
|* 28 | INDEX RANGE SCAN | SYS_C0058148 | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
| 29 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
|* 30 | INDEX RANGE SCAN | SYS_C0058264 | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
| 31 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
|* 32 | INDEX RANGE SCAN | SYS_C0058516 | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
| 33 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
|* 34 | INDEX RANGE SCAN | SYS_C0058561 | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
| 35 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
|* 36 | INDEX RANGE SCAN | SYS_C0058783 | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
| 37 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
|* 38 | INDEX RANGE SCAN | SYS_C0058977 | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
| 39 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
|* 40 | INDEX RANGE SCAN | SYS_C0058859 | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
| 41 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
|* 42 | INDEX RANGE SCAN | SYS_C0059197 | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
| 43 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 | 0 |
|* 44 | TABLE ACCESS FULL | TIBEX_CANCELTRDADMIN | 1 | 1 | 0 |00:00:00.01 | 3 | 0 |
| 45 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 | 0 |
|* 46 | TABLE ACCESS FULL | TIBEX_BULKCANCELADMIN | 1 | 1 | 0 |00:00:00.01 | 3 | 0 |
Predicate Information (identified by operation id):
5 - filter("LASTINSTUSERALIAS"=:SYS_B_1)
8 - access("LASTINSTUSERALIAS"=:SYS_B_1)
10 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
12 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
14 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
16 - filter("USERALIAS"=:SYS_B_1)
18 - filter("USERALIAS"=:SYS_B_1)
20 - access("USERALIAS"=:SYS_B_1)
22 - access("USERALIAS"=:SYS_B_1)
24 - access("USERALIAS"=:SYS_B_1)
26 - filter(("USERALIAS" IS NOT NULL AND "USERALIAS"=:SYS_B_1))
28 - access("USERALIAS"=:SYS_B_1)
30 - access("USERALIAS"=:SYS_B_1)
32 - access("USERALIAS"=:SYS_B_1)
34 - access("USERALIAS"=:SYS_B_1)
36 - access("USERALIAS"=:SYS_B_1)
38 - access("USERALIAS"=:SYS_B_1)
PLAN_TABLE_OUTPUT
40 - access("USERALIAS"=:SYS_B_1)
42 - access("USERALIAS"=:SYS_B_1)
44 - filter("USERALIAS"=:SYS_B_1)
46 - filter("USERALIAS"=:SYS_B_1)
249 rows selected. -
Query Take more time on timesten
Hi
One query takes lot of time on timesten , while the same query takes less time on oracle
Query :-
select *
from (SELECT RELD_EM_ENTITY_ID,
RELD_EXM_EXCH_ID,
RELD_SEGMENT_TYPE,
NVL(RELD_ACC_TYPE, 0) ACC_TYPE, --END ASHA
ROUND(NVL(sum(RELD_RTO_EXP), -1), 2) RTO_EXP,
ROUND(NVL(sum(RELD_NE_EXP), -1), 2) NET_EXP,
ROUND(NVL(sum(RELD_MAR_UTILIZATION), -1),
2) MAR_EXP,
ROUND(decode(sign(sum(C.reld_m2m_exp)),
-1,
abs(sum(C.reld_m2m_exp)),
0),
2) M2M_EXP,
NVL(OLM_SUSPNSN_FLG, 'A') SUSPNSN_FLG,
EM_RP_PROFILE_ID
FROM ENTITY_MASTER A,
ORDER_LMT_MASTER B,
RMS_ENTITY_LIMIT_DTLS C
WHERE A.EM_CONTROLLER_ID = 100100010000
AND A.EM_ENTITY_ID = C.RELD_EM_ENTITY_ID
AND C.RELD_EM_ENTITY_ID = B.OLM_EPM_EM_ENTITY_ID(+)
AND C.RELD_SEGMENT_TYPE = 'E'
AND C.RELD_EXM_EXCH_ID = B.OLM_EXCH_ID(+)
AND C.RELD_EXM_EXCH_ID <> 'ALL'
AND B.OLM_SEM_SMST_SECURITY_ID(+) =
'ALL'
AND ((A.EM_ENTITY_TYPE IN ('CL') AND
A.EM_CLIENT_TYPE <> 'CC') OR
A.EM_ENTITY_TYPE <> 'CL')
AND B.OLM_PRODUCT_ID(+) = 'M' --Added by Harshit Shah on 4th June 09
GROUP BY RELD_EM_ENTITY_ID,
RELD_EXM_EXCH_ID,
RELD_SEGMENT_TYPE,
RELD_ACC_TYPE,
OLM_SUSPNSN_FLG,
EM_RP_PROFILE_ID,
OLM_PRODUCT_ID
UNION --union all removed by pramod on 08-jan-2012 as it was giving multiple rows
SELECT RELD_EM_ENTITY_ID,
RELD_EXM_EXCH_ID,
RELD_SEGMENT_TYPE SEGMENTID,
NVL(RELD_ACC_TYPE, 0) ACC_TYPE, --END ASHA
ROUND(NVL(SUM(RELD_RTO_EXP), -1), 2) RTO_EXP,
ROUND(NVL(SUM(RELD_NE_EXP), -1), 2) NET_EXP,
ROUND(NVL(SUM(RELD_MAR_UTILIZATION), -1),
2) MAR_EXP,
ROUND(decode(sign(SUM(C.reld_m2m_exp)),
-1,
abs(SUM(C.reld_m2m_exp)),
0),
2) M2M_EXP,
NVL(OLM_SUSPNSN_FLG, 'A') SUSPNSN_FLG,
EM_RP_PROFILE_ID
FROM ENTITY_MASTER A,
ORDER_LMT_MASTER B,
RMS_ENTITY_LIMIT_DTLS C
WHERE A.EM_CONTROLLER_ID = 100100010000
AND A.EM_ENTITY_ID = B.OLM_EPM_EM_ENTITY_ID
AND B.OLM_EPM_EM_ENTITY_ID = C.RELD_EM_ENTITY_ID(+)
AND C.RELD_SEGMENT_TYPE = 'E'
AND B.OLM_EXCH_ID = 'ALL'
AND B.OLM_SEM_SMST_SECURITY_ID(+) =
'ALL'
AND ((A.EM_ENTITY_TYPE IN ('CL') AND
A.EM_CLIENT_TYPE <> 'CC') OR
A.EM_ENTITY_TYPE <> 'CL')
AND B.OLM_PRODUCT_ID(+) = 'M' --Added by Harshit Shah on 4th June 09
GROUP BY RELD_EM_ENTITY_ID,
RELD_EXM_EXCH_ID,
RELD_SEGMENT_TYPE,
RELD_ACC_TYPE,
OLM_SUSPNSN_FLG,
EM_RP_PROFILE_ID,
OLM_PRODUCT_ID
UNION --union all removed by pramod on 08-jan-2012 as it was giving multiple rows
SELECT RELD_EM_ENTITY_ID,
RELD_EXM_EXCH_ID,
RELD_SEGMENT_TYPE,
NVL(RELD_ACC_TYPE, 0) ACC_TYPE, --END ASHA
ROUND(NVL(sum(RELD_RTO_EXP), -1), 2) RTO_EXP,
ROUND(NVL(sum(RELD_NE_EXP), -1), 2) NET_EXP,
ROUND(NVL(sum(RELD_MAR_UTILIZATION), -1),
2) MAR_EXP,
ROUND(decode(sign(sum(C.reld_m2m_exp)),
-1,
abs(sum(C.reld_m2m_exp)),
0),
2) M2M_EXP,
NVL(OLIM_SUSPNSN_FLG, 'A') SUSPNSN_FLG,
EM_RP_PROFILE_ID
FROM ENTITY_MASTER A,
DRV_ORDER_INST_LMT_MASTER B,
RMS_ENTITY_LIMIT_DTLS C
WHERE A.EM_CONTROLLER_ID = 100100010000
AND A.EM_ENTITY_ID = C.RELD_EM_ENTITY_ID
AND C.RELD_EM_ENTITY_ID =
B.OLIM_EPM_EM_ENTITY_ID(+)
AND C.RELD_SEGMENT_TYPE = 'D'
AND C.RELD_EXM_EXCH_ID = B.OLIM_EXCH_ID(+)
AND C.RELD_EXM_EXCH_ID <> 'ALL'
AND B.OLIM_INSTRUMENT_ID(+) = 'ALL'
AND ((A.EM_ENTITY_TYPE IN ('CL') AND
A.EM_CLIENT_TYPE <> 'CC') OR
A.EM_ENTITY_TYPE <> 'CL')
GROUP BY RELD_EM_ENTITY_ID,
RELD_EXM_EXCH_ID,
RELD_SEGMENT_TYPE,
RELD_ACC_TYPE,
OLIM_SUSPNSN_FLG,
EM_RP_PROFILE_ID
UNION --union all removed by pramod on 08-jan-2012 as it was giving multiple rows
SELECT RELD_EM_ENTITY_ID,
RELD_EXM_EXCH_ID,
RELD_SEGMENT_TYPE SEGMENTID,
NVL(RELD_ACC_TYPE, 0) ACC_TYPE, --END ASHA
ROUND(NVL(SUM(RELD_RTO_EXP), -1), 2) RTO_EXP,
ROUND(NVL(SUM(RELD_NE_EXP), -1), 2) NET_EXP,
ROUND(NVL(SUM(RELD_MAR_UTILIZATION), -1),
2) MAR_EXP,
ROUND(decode(sign(SUM(C.reld_m2m_exp)),
-1,
abs(SUM(C.reld_m2m_exp)),
0),
2) M2M_EXP,
NVL(OLIM_SUSPNSN_FLG, 'A') SUSPNSN_FLG,
EM_RP_PROFILE_ID
FROM ENTITY_MASTER A,
DRV_ORDER_INST_LMT_MASTER B,
RMS_ENTITY_LIMIT_DTLS C
WHERE A.EM_CONTROLLER_ID = 100100010000
AND A.EM_ENTITY_ID = B.OLIM_EPM_EM_ENTITY_ID
AND B.OLIM_EPM_EM_ENTITY_ID =
C.RELD_EM_ENTITY_ID(+)
AND C.RELD_SEGMENT_TYPE = 'D'
AND B.OLIM_EXCH_ID = 'ALL'
AND B.OLIM_INSTRUMENT_ID(+) = 'ALL'
AND ((A.EM_ENTITY_TYPE IN ('CL') AND
A.EM_CLIENT_TYPE <> 'CC') OR
A.EM_ENTITY_TYPE <> 'CL')
GROUP BY RELD_EM_ENTITY_ID,
RELD_EXM_EXCH_ID,
RELD_SEGMENT_TYPE,
RELD_ACC_TYPE,
OLIM_SUSPNSN_FLG,
EM_RP_PROFILE_ID)
ORDER BY RELD_EM_ENTITY_ID,
RELD_SEGMENT_TYPE,
RELD_EXM_EXCH_ID;
Please suggest what should i check for this.As always when examining SQL performance, start by checking the query execution plan. If you use ttIsql you can just prepend EXPLAIN to the query and the plan will be displayed. e.g.
EXPLAIN select ...........;
Check the plan is optimal and all necessary indexes are in place. You may need to add indexes depending o what the plan shows.
Please note that Oracle database can, and usually does, execute many types of query in parallel using multiple CPU cores. TimesTen does not currently support parallelisation of individual queries. Hence in some cases Oracle database may indeed be faster than TimesTen due to the parallel execution that occurs in Oracle.
Chris -
Query takes more time from client
Hi,
I have a select query (which refers to views and calls a function), which fetches results in 2 secs when executed from database. But takes more than 10 mins from the client.
The tkprof for the call from the client is given below. Could you please suggest, what is going wrong and how this can be addressed?
The index IDX_table1_1 is on col3.
Trace file: trace_file.trc
Sort options: exeela
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 ROUND(SUM(NVL((col1-col2),(SYSDATE - col2)
FROM
table1 WHERE col3 = :B1 GROUP BY col3
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 7402 0.27 7.40 0 0 0 0
Fetch 7402 1.13 59.37 1663 22535 0 7335
total 14804 1.40 66.77 1663 22535 0 7335
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 32 (ORADBA) (recursive depth: 1)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
0 SORT (GROUP BY NOSORT)
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'table1'
(TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF 'IDX_table1_1'
(INDEX)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 1663 1.37 57.71
OVERALL TOTALS FOR ALL NON-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
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 16039 3.09 385.04
db file scattered read 34 0.21 1.42
latch: cache buffers chains 26 0.34 2.14
SQL*Net break/reset to client 2 0.05 0.05
SQL*Net message to client 2 0.00 0.00
SQL*Net message from client 2 79.99 79.99
SQL*Net message to dblink 1 0.00 0.00
SQL*Net message from dblink 1 0.00 0.00
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 7402 0.27 7.40 0 0 0 0
Fetch 7402 1.13 59.37 1663 22535 0 7335
total 14804 1.40 66.77 1663 22535 0 7335
Misses in library cache during parse: 0
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 1663 1.37 57.71
1 user SQL statements in session.
0 internal SQL statements in session.
1 SQL statements in session.
1 statement EXPLAINed in this session.
Trace file: trace_file.trc
Trace file compatibility: 10.01.00
Sort options: exeela
1 session in tracefile.
1 user SQL statements in trace file.
0 internal SQL statements in trace file.
1 SQL statements in trace file.
1 unique SQL statements in trace file.
1 SQL statements EXPLAINed using schema:
ORADBA.prof$plan_table
Default table was used.
Table was created.
Table was dropped.
84792 lines in trace file.
4152 elapsed seconds in trace file.Edited by: agathya on Feb 26, 2010 8:39 PMI have a select query (which refers to views and calls a function), which fetches results in 2 secs when >executed from database. But takes more than 10 mins from the client.You are providing proof for the latter part of your statement above.
But not for the former part (fetches in 2 secs when exec'd from db).
It would have been nice if you also provide the sql-trace information for that.
Without it we cannot help you much. Other than making the observation that you obviously have a query that is I/O bound, and that I/O on your system is rather slow: on average an I/O takes 0.04 seconds (66.77 divided by 1663). -
Hi,
My emp table contains one milion of records.
delete from emp;
commit;
select count(*)
from emp;
I had perform the above three queries parallely. After applying the commit operation, To retrive the no.of records
in that table it takes some more time after that it display the result zero.
I have faced this question recently in one of the interview. why it is taking some more time..
can any one help me?Did you read the link provided?
A high water mark is the set of blocks that have at one point contained data. You
might have 1000 blocks allocated to a table but only 500 are under the HWM.
The blocks under the HWM are the blocks that will be read when the table is full scanned. In your sample code, when you insert 1Milion records, the data will reside in some number of blocks - Say 1000. Now the HWM is 1000. When you delete the data, HWM will not get reset..
And after delete, when you count, a FULL TABLE SCAN will happen. Which will scan all the blocks under HWM. So, here 1000 blocks will get read, even if there is no "data". That way your query will take time..
Whats the solution? - Do a TRUNCATE or do a SHRINK.
NOW - Tell us - What is your concern? -
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> -
Select query taking more time..
Hi friends..
The below inner join statement is taking more time , can any body sugget me to improve the performance . I tried FOR ALL ENTRIES also but that also taking more time than inner join statement .
SELECT a~vbeln from vbap as a inner join vakpa as b
on avbeln = bvbeln
into corresponding fields of table IT_VAKPA
where a~WERKS IN S_IWERKS
and a~pstyv NE 'ZRS'
and b~vkorg = IVKORG
and b~audat IN IAUDAT
and b~vtweg IN IVTWEG.
Regards
ChetanHi Chetan ,
VAKPA is an index table. From the select query , it has been observed that you are not fetching any data from VAKPA. Only you have added some selection paramenters in where clause of select query.
My suggestion will be instead of using VAKPA in inner join you use VBAK along with VBAP. All the fields that you are using as selection condition from VAKPA are there in VBAK.
I am sure performance of query will be improved.
If still duo to business logic you need to use VAKPA, try to create secondary non unique index on fields VKORD,AUDATand VTWEG on table VAKPA.
However I will recommend you to go for first option only. If this does not work then go for second option.
Hopfully this will help you.
Regards,
Nikhil -
Hi All.
When i execute select query from View it takes about 00:00:45:12 sec to pull the data , but when i execute same query in some other system(different database with same table structure) it takes about 00:00:02:05 sec.
1)I have tried by dropped and recreated the index then i tried by exec dbms_stats.gather_table_stats procedure still no luck.
Please help me to understand the reason difference in response time
Thanks
sankardid you run the EXPLAIN PLAN?
-
Select query takes long time....
Hi Experts,
I am using a select query in which inspection lot is in another table and order no. is in another table. this select query taking very long time, what is the problem in this query ? Pl. guide us.
select bPRUEFLOS bMBLNR bCPUDT aAUFNR amatnr aLGORT a~bwart
amenge aummat asgtxt axauto
into corresponding fields of table itab
*into table itab
from mseg as a inner join qamb as b
on amblnr = bmblnr
and azeile = bzeile
where b~PRUEFLOS in insp
and b~cpudt in date1
and b~typ = '3'
and a~bwart = '321'
and a~aufnr in aufnr1.
Yusufhi
instead of using 'move to corresponding of itab' fields use 'into table itab'.....
coz......if u use move to corresponding it will search for all the appropriate fields then it will place u r data........instead of that declare apprpiate internal table and use 'into table itab'.
and one more thing dont use joins ......coz joins will decrease u r performance .....so instead of that use 'for all entries' ....and mention all the key fields in where condition ........
ok
reward points for helpful answers -
Query take more time to execute
Hi
I am using in sql select statement two non exist statements it is taken more time to execute the query ,non exist is any impact query performance
thank's[email protected] wrote:
I am using in sql select statement two non exist statements it is taken more time to execute the query ,non exist is any impact query performanceI have a query that is using even more time to execute. Do I win? -
Hi,
My database in 10g(10.2.0.4), I fire delete query which deletes 5 Lacs records from the table but it is taking more time to delete.
My table and indexes on that table in Nologging mode, Database in Archive Log Mode.
Can you please help to minize the time?
Execution Plan
0 DELETE STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1 Bytes=62)
1 0 DELETE OF 'CORP_MESSAGEQUEUE'
2 1 INDEX (RANGE SCAN) OF 'INDEX_CORP_MESSAGEQUEUE_PROC' (IN
DEX) (Cost=2 Card=1 Bytes=62)
Statistics
754 recursive calls
635137 db block gets
4773 consistent gets
181579 physical reads
268073944 redo size
630 bytes sent via SQL*Net to client
608 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
1 sorts (memory)
4 sorts (disk)
483328 rows processed
AnandEven if the table is in nologing mode there will be redo generated for the DML. It is clear from your statistics that redo is being generated for the delete. Loging is only effective for few of the operations as given bellow. I think there is no issue with the query the redo and undo generation is taking time. Just tune your configuration like.
No redo log files.
size of redo log.
Undo tablespace size.
undo retentation.
Pga_aggrigate_target.
temporary tablespace sizing.
754 recursive calls
635137 db block gets
4773 consistent gets
181579 physical reads
**268073944 redo size**
630 bytes sent via SQL*Net to client
608 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
1 sorts (memory)
4 sorts (disk)
483328 rows processed
NOLOGGING: Oracle will generate a minimal number of redo log entries in order to protect the data dictionary, and the operation will probably run faster. Logging can be disabled at the table level or the tablespace level.
If it is done at the tablespace level then we create indexes or tables in this tablespace; they will be in NOLOGGING mode.
A table or an index can be created with NOLOGGING mode or it can be altered using ALTER TABLE/INDEX NOLOGGING.
NOLOGGING is active in the following situations and while running one of the following commands but not after that.
- DIRECT LOAD (SQL*Loader)
- DIRECT LOAD INSERT (using APPEND hint)
- CREATE TABLE ... AS SELECT
- CREATE INDEX
- ALTER TABLE MOVE
- ALTER TABLE ... MOVE PARTITION
- ALTER TABLE ... SPLIT PARTITION
- ALTER TABLE ... ADD PARTITION (if HASH partition)
- ALTER TABLE ... MERGE PARTITION
- ALTER TABLE ... MODIFY PARTITION, ADD SUBPARTITON, COALESCE SUBPARTITON, REBUILD UNUSABLE INDEXES
- ALTER INDEX ... SPLIT PARTITION
- ALTER INDEX ... REBUILD
- ALTER INDEX ... REBUILD PARTITION
Logging is stopped only while one of the commands above is running.
So if a user runs this:
ALTER INDEX new_index NOLOGGING.
The actual rebuild of the index does not generate redo (all data dictionary changes associated with the rebuild will do) but after that any DML on the index will generate redo this includes direct load insert on the table which the index belongs to.
All the following statements will generate redo despite the fact the table is in NOLOGGING mode:
- INSERT INTO new_table_nolog_test ...,
- UPDATE new_table_nolog_test SET ...,
- DELETE FROM new_table_nolog_test ..
The following will not generate redo (except from dictionary changes and indexes):
- INSERT /*APPEND/ ...
- ALTER TABLE new_table_nolog_test MOVE ...
- ALTER TABLE new_table_nolog_test MOVE PARTITION ...
practicle example:
SQL> select value OLD_VALUE
from v$mystat, v$statname
where v$mystat.statistic# = v$statname.statistic#
and v$statname.name = 'redo size'; 2 3 4
OLD_VALUE
0
SQL> /
OLD_VALUE
0
SQL>
SQL> create table T_NOLOG nologging as select * from all_objects;
Table created.
SQL> select (value - &OLD_VALUE) OLD_VALUE
from v$mystat, v$statname
where v$mystat.statistic# = v$statname.statistic#
and v$statname.name = 'redo size'; 2 3 4
Enter value for old_value: 0
old 1: select (value - &OLD_VALUE) OLD_VALUE
new 1: select (value - 0) OLD_VALUE
OLD_VALUE
91848
SQL> delete from T_NOLOG ;
106229 rows deleted.
SQL> select (value - &OLD_VALUE) OLD_VALUE
from v$mystat, v$statname
where v$mystat.statistic# = v$statname.statistic#
and v$statname.name = 'redo size'; 2 3 4
Enter value for old_value: 91848
old 1: select (value - &OLD_VALUE) OLD_VALUE
new 1: select (value - 91848) OLD_VALUE
OLD_VALUE
39389988
SQL> -
Select Statement takes more time after immediate insert statement..
Hello,
I found below scenario
1. I have table TABLE1 which has index on COL1 field. It has around 40 columns and 100000 rows.
2. whenever i insert 100000 rows in bulk with changing indexed key column and executing SELECT statement in same session then it takes around 3 mins to complete.
3. However, if i open new session and execute same select statement then it returns in 2-3 seconds.
I didnt get anything in XPLAN.. :(
I felt Buffer Clean is cause to take time. please let me know your opinion.
Thanks in Advance
Sachsach09 wrote:
Hello,
I found below scenario
1. I have table TABLE1 which has index on COL1 field. It has around 40 columns and 100000 rows.
2. whenever i insert 100000 rows in bulk with changing indexed key column and executing SELECT statement in same session then it takes around 3 mins to complete.
3. However, if i open new session and execute same select statement then it returns in 2-3 seconds.
I didnt get anything in XPLAN.. :(
I felt Buffer Clean is cause to take time. please let me know your opinion.Are you running the query in the other session after running it from the first?
Aman.... -
hi all ,
can you please advice me in my plans
i have query run daily as a job it take 3 minute always
but today it takes 1:10 hours why this happen i see the jobs there is no other job running in the time of this query run
by the way can you tell me what i need to check ??????
MANY THANKSHi,
when query's performance changes like that, the primary suspect is a change in the execution plan. You can use this query to check this:
select begin_interval_time, plan_hash_value
from dba_hist_snapshot sn,
dba_hist_sqlstat st
where sn.snap_id = st.snap_id
and sql_id = <sql_id here>
order by begin_interval_time desc;Once you confirm that this is due to a change in the execution plan (there other scenarios possible, but less likely), you can start looking why the change
occured.
Most common causes are change in statistics, appearance or removal of histograms, or bind variables peeking unusual values.
Best regards,
Nikolay
Maybe you are looking for
-
Why does my macbook intermittently lose internet connection when I have internet service?
Hello, I have checked around on Apple forums as well as the wider internet. My situation is just a bit different than the other solutions I read about. I have a MacBook, 10.6.8. I have an internet antenna that plugs into the modem, that I plug into m
-
Was wondering if anyone can help...I am not very computer friendly but want to be able to edit my photos, use them as jpegs, order prints etc. When I double click on a thumbnail ( am presuming the thumbnails are the small photos ) I get a grey screen
-
HTTP error .401 Unauthorized
Hello experts, We are unable to upload image file, getting error " HTTP error .401 Unauthorized " what could be the reason , how can i resolve this error . please help ....... Thanks & Regards, KNM
-
Airport Extreme With MBPro and iMac
I'm about to set up a new airport extreme. Right now I am connected to the internet through an older airport extreme, not mine, so I can't use the wifi because I'm locked out. Can someone please tell me the very first steps to initiating the new air
-
Safe to use Dock when updating iPhone firmware?
When future firmware updates become available for iPhone via iTunes, is it safe to go through the update process connecting the iPhone to my MacBook Pro via the Dock or must it be using the cable only? I read on an online forum that one user tried up