Select statement is very slow ?

I have the table created in Oracle:
CREATE TABLE tllog
(autoid NUMBER(10,0) NOT NULL,
txnum VARCHAR2(10),
txdate DATE,
brid VARCHAR2(4),
tlid VARCHAR2(4),
offid VARCHAR2(4),
cfrid VARCHAR2(4),
chkid VARCHAR2(4),
tltxcd VARCHAR2(4),
off_line VARCHAR2(1),
busdate DATE,
txdesc NVARCHAR2(200),
ipaddress VARCHAR2(20),
wsname VARCHAR2(50),
status NUMBER(1,0) DEFAULT 0,
batchname VARCHAR2(10),
micode VARCHAR2(3),
deleted NUMBER(1,0) DEFAULT 0,
msgamt NUMBER(10,0),
isparent NUMBER(1,0) DEFAULT 0,
parentid NUMBER(10,0) DEFAULT 0,
brcode NVARCHAR2(10),
tlname NVARCHAR2(15),
offname NVARCHAR2(15),
cfrname NVARCHAR2(15),
chkname NVARCHAR2(15),
txname NVARCHAR2(100),
status_text NVARCHAR2(50),
parent_text NVARCHAR2(50),
sicode VARCHAR2(10),
tmpid NUMBER(10,0),
childtltxcd VARCHAR2(4) DEFAULT NULL,
t_no NUMBER(1,0),
msgdate DATE,
col_value01 NVARCHAR2(2000),
col_type01 NVARCHAR2(1),
col_desc01 NVARCHAR2(2000),
col_value02 NVARCHAR2(2000),
col_type02 NVARCHAR2(1),
col_desc02 NVARCHAR2(2000),
col_value03 NVARCHAR2(2000),
col_type03 NVARCHAR2(1),
col_desc03 NVARCHAR2(2000),
col_value04 NVARCHAR2(2000),
col_type04 NVARCHAR2(1),
col_desc04 NVARCHAR2(2000),
col_value05 NVARCHAR2(2000),
col_type05 NVARCHAR2(1),
col_desc05 NVARCHAR2(2000),
col_value06 NVARCHAR2(2000),
col_type06 NVARCHAR2(1),
col_desc06 NVARCHAR2(2000),
col_value07 NVARCHAR2(2000),
col_type07 NVARCHAR2(1),
col_desc07 NVARCHAR2(2000),
col_value08 NVARCHAR2(2000),
col_type08 NVARCHAR2(1),
col_desc08 NVARCHAR2(2000),
col_value09 NVARCHAR2(2000),
col_type09 NVARCHAR2(1),
col_desc09 NVARCHAR2(2000),
col_value10 NVARCHAR2(2000),
col_type10 NVARCHAR2(1),
col_desc10 NVARCHAR2(2000),
col_value11 NVARCHAR2(2000),
col_type11 NVARCHAR2(1),
col_desc11 NVARCHAR2(2000),
col_value12 NVARCHAR2(2000),
col_type12 NVARCHAR2(1),
col_desc12 NVARCHAR2(2000),
col_value13 NVARCHAR2(2000),
col_type13 NVARCHAR2(1),
col_desc13 NVARCHAR2(2000),
col_value14 NVARCHAR2(2000),
col_type14 NVARCHAR2(1),
col_desc14 NVARCHAR2(2000),
col_value15 NVARCHAR2(2000),
col_type15 VARCHAR2(1),
col_desc15 NVARCHAR2(2000),
col_value16 NVARCHAR2(2000),
col_type16 NVARCHAR2(1),
col_desc16 NVARCHAR2(2000),
col_value17 NVARCHAR2(2000),
col_type17 NVARCHAR2(1),
col_desc17 NVARCHAR2(2000),
col_value18 NVARCHAR2(2000),
col_type18 NVARCHAR2(1),
col_desc18 NVARCHAR2(2000),
col_value19 NVARCHAR2(2000),
col_type19 NVARCHAR2(1),
col_desc19 NVARCHAR2(2000),
col_value20 NVARCHAR2(2000),
col_type20 NVARCHAR2(1),
col_desc20 NVARCHAR2(2000),
col_value21 NVARCHAR2(2000),
col_type21 NVARCHAR2(1),
col_desc21 NVARCHAR2(2000),
col_value22 NVARCHAR2(2000),
col_type22 NVARCHAR2(1),
col_desc22 NVARCHAR2(2000),
col_value23 NVARCHAR2(2000),
col_type23 NVARCHAR2(1),
col_desc23 NVARCHAR2(2000),
col_value24 NVARCHAR2(2000),
col_type24 NVARCHAR2(1),
col_desc24 NVARCHAR2(2000),
col_value25 NVARCHAR2(2000),
col_type25 NVARCHAR2(1),
col_desc25 NVARCHAR2(2000),
col_value26 NVARCHAR2(2000),
col_type26 NVARCHAR2(1),
col_desc26 NVARCHAR2(2000),
col_value27 NVARCHAR2(2000),
col_type27 NVARCHAR2(1),
col_desc27 NVARCHAR2(2000),
col_value28 NVARCHAR2(2000),
col_type28 NVARCHAR2(1),
col_desc28 NVARCHAR2(2000),
col_value29 NVARCHAR2(2000),
col_type29 NVARCHAR2(1),
col_desc29 NVARCHAR2(2000),
col_value30 NVARCHAR2(2000),
col_type30 NVARCHAR2(1),
col_desc30 NVARCHAR2(2000),
isbrid NUMBER(1,0) DEFAULT 1,
comicode VARCHAR2(3))
TABLESPACE users
STORAGE (
INITIAL 3145728
MINEXTENTS 1
MAXEXTENTS 2147483645
NOCACHE
MONITORING
ALTER TABLE tllog
ADD CONSTRAINT pk_tllog PRIMARY KEY (autoid)
USING INDEX
TABLESPACE system
STORAGE (
INITIAL 131072
MINEXTENTS 1
MAXEXTENTS 2147483645
Now, it has 1962 records .
I've created cache group (read only) for it on the Unix timesten server (RAM : 16GB). The server has configuration :
Driver=/opt/TimesTen/tt70/lib/libtten.so
DataStore=/timesten/vsd
# LogDir=/timesten/logs
Permsize=7168
TempSize=512
Uid=host
Pwd=host
OracleID=vsds
OraclePwd=host
PassThrough=1
DatabaseCharacterSet=AL32UTF8
ConnectionCharacterSet=AL32UTF8
I executed the sql "select * from tllog" took 19 seconds .
I think it's too slow for the easy sql ?
Please give me a advanced ./.
Many Thanks
TuanTA
Edited by: [email protected] on Mar 9, 2009 3:38 AM

1. Did you load the cache group with the data from Oracle (LOAD CACHE GROUP )?
-- Database is in Oracle type mode
create readonly cache group HOST.CG_TLLOG
autorefresh
mode incremental
interval 5000 milliseconds
state on
from
HOST.TLLOG (
AUTOID NUMBER(10) NOT NULL,
TXNUM VARCHAR2(10 BYTE) INLINE,
TXDATE DATE,
BRID VARCHAR2(4 BYTE) INLINE,
TLID VARCHAR2(4 BYTE) INLINE,
OFFID VARCHAR2(4 BYTE) INLINE,
CFRID VARCHAR2(4 BYTE) INLINE,
CHKID VARCHAR2(4 BYTE) INLINE,
TLTXCD VARCHAR2(4 BYTE) INLINE,
OFF_LINE VARCHAR2(1 BYTE) INLINE,
BUSDATE DATE,
TXDESC NVARCHAR2(200) NOT INLINE,
IPADDRESS VARCHAR2(20 BYTE) INLINE,
WSNAME VARCHAR2(50 BYTE) INLINE,
STATUS NUMBER(1),
BATCHNAME VARCHAR2(10 BYTE) INLINE,
MICODE VARCHAR2(3 BYTE) INLINE,
DELETED NUMBER(1),
MSGAMT NUMBER(10),
ISPARENT NUMBER(1),
PARENTID NUMBER(10),
BRCODE NVARCHAR2(10) INLINE,
TLNAME NVARCHAR2(15) INLINE,
OFFNAME NVARCHAR2(15) INLINE,
CFRNAME NVARCHAR2(15) INLINE,
CHKNAME NVARCHAR2(15) INLINE,
TXNAME NVARCHAR2(100) NOT INLINE,
STATUS_TEXT NVARCHAR2(50) INLINE,
PARENT_TEXT NVARCHAR2(50) INLINE,
SICODE VARCHAR2(10 BYTE) INLINE,
TMPID NUMBER(10),
CHILDTLTXCD VARCHAR2(4 BYTE) INLINE,
T_NO NUMBER(1),
MSGDATE DATE,
COL_VALUE01 NVARCHAR2(2000) NOT INLINE,
COL_TYPE01 NVARCHAR2(1) INLINE,
COL_DESC01 NVARCHAR2(2000) NOT INLINE,
COL_VALUE02 NVARCHAR2(2000) NOT INLINE,
COL_TYPE02 NVARCHAR2(1) INLINE,
COL_DESC02 NVARCHAR2(2000) NOT INLINE,
COL_VALUE03 NVARCHAR2(2000) NOT INLINE,
COL_TYPE03 NVARCHAR2(1) INLINE,
COL_DESC03 NVARCHAR2(2000) NOT INLINE,
COL_VALUE04 NVARCHAR2(2000) NOT INLINE,
COL_TYPE04 NVARCHAR2(1) INLINE,
COL_DESC04 NVARCHAR2(2000) NOT INLINE,
COL_VALUE05 NVARCHAR2(2000) NOT INLINE,
COL_TYPE05 NVARCHAR2(1) INLINE,
COL_DESC05 NVARCHAR2(2000) NOT INLINE,
COL_VALUE06 NVARCHAR2(2000) NOT INLINE,
COL_TYPE06 NVARCHAR2(1) INLINE,
COL_DESC06 NVARCHAR2(2000) NOT INLINE,
COL_VALUE07 NVARCHAR2(2000) NOT INLINE,
COL_TYPE07 NVARCHAR2(1) INLINE,
COL_DESC07 NVARCHAR2(2000) NOT INLINE,
COL_VALUE08 NVARCHAR2(2000) NOT INLINE,
COL_TYPE08 NVARCHAR2(1) INLINE,
COL_DESC08 NVARCHAR2(2000) NOT INLINE,
COL_VALUE09 NVARCHAR2(2000) NOT INLINE,
COL_TYPE09 NVARCHAR2(1) INLINE,
COL_DESC09 NVARCHAR2(2000) NOT INLINE,
COL_VALUE10 NVARCHAR2(2000) NOT INLINE,
COL_TYPE10 NVARCHAR2(1) INLINE,
COL_DESC10 NVARCHAR2(2000) NOT INLINE,
COL_VALUE11 NVARCHAR2(2000) NOT INLINE,
COL_TYPE11 NVARCHAR2(1) INLINE,
COL_DESC11 NVARCHAR2(2000) NOT INLINE,
COL_VALUE12 NVARCHAR2(2000) NOT INLINE,
COL_TYPE12 NVARCHAR2(1) INLINE,
COL_DESC12 NVARCHAR2(2000) NOT INLINE,
COL_VALUE13 NVARCHAR2(2000) NOT INLINE,
COL_TYPE13 NVARCHAR2(1) INLINE,
COL_DESC13 NVARCHAR2(2000) NOT INLINE,
COL_VALUE14 NVARCHAR2(2000) NOT INLINE,
COL_TYPE14 NVARCHAR2(1) INLINE,
COL_DESC14 NVARCHAR2(2000) NOT INLINE,
COL_VALUE15 NVARCHAR2(2000) NOT INLINE,
COL_TYPE15 VARCHAR2(1 BYTE) INLINE,
COL_DESC15 NVARCHAR2(2000) NOT INLINE,
COL_VALUE16 NVARCHAR2(2000) NOT INLINE,
COL_TYPE16 NVARCHAR2(1) INLINE,
COL_DESC16 NVARCHAR2(2000) NOT INLINE,
COL_VALUE17 NVARCHAR2(2000) NOT INLINE,
COL_TYPE17 NVARCHAR2(1) INLINE,
COL_DESC17 NVARCHAR2(2000) NOT INLINE,
COL_VALUE18 NVARCHAR2(2000) NOT INLINE,
COL_TYPE18 NVARCHAR2(1) INLINE,
COL_DESC18 NVARCHAR2(2000) NOT INLINE,
COL_VALUE19 NVARCHAR2(2000) NOT INLINE,
COL_TYPE19 NVARCHAR2(1) INLINE,
COL_DESC19 NVARCHAR2(2000) NOT INLINE,
COL_VALUE20 NVARCHAR2(2000) NOT INLINE,
COL_TYPE20 NVARCHAR2(1) INLINE,
COL_DESC20 NVARCHAR2(2000) NOT INLINE,
COL_VALUE21 NVARCHAR2(2000) NOT INLINE,
COL_TYPE21 NVARCHAR2(1) INLINE,
COL_DESC21 NVARCHAR2(2000) NOT INLINE,
COL_VALUE22 NVARCHAR2(2000) NOT INLINE,
COL_TYPE22 NVARCHAR2(1) INLINE,
COL_DESC22 NVARCHAR2(2000) NOT INLINE,
COL_VALUE23 NVARCHAR2(2000) NOT INLINE,
COL_TYPE23 NVARCHAR2(1) INLINE,
COL_DESC23 NVARCHAR2(2000) NOT INLINE,
COL_VALUE24 NVARCHAR2(2000) NOT INLINE,
COL_TYPE24 NVARCHAR2(1) INLINE,
COL_DESC24 NVARCHAR2(2000) NOT INLINE,
COL_VALUE25 NVARCHAR2(2000) NOT INLINE,
COL_TYPE25 NVARCHAR2(1) INLINE,
COL_DESC25 NVARCHAR2(2000) NOT INLINE,
COL_VALUE26 NVARCHAR2(2000) NOT INLINE,
COL_TYPE26 NVARCHAR2(1) INLINE,
COL_DESC26 NVARCHAR2(2000) NOT INLINE,
COL_VALUE27 NVARCHAR2(2000) NOT INLINE,
COL_TYPE27 NVARCHAR2(1) INLINE,
COL_DESC27 NVARCHAR2(2000) NOT INLINE,
COL_VALUE28 NVARCHAR2(2000) NOT INLINE,
COL_TYPE28 NVARCHAR2(1) INLINE,
COL_DESC28 NVARCHAR2(2000) NOT INLINE,
COL_VALUE29 NVARCHAR2(2000) NOT INLINE,
COL_TYPE29 NVARCHAR2(1) INLINE,
COL_DESC29 NVARCHAR2(2000) NOT INLINE,
COL_VALUE30 NVARCHAR2(2000) NOT INLINE,
COL_TYPE30 NVARCHAR2(1) INLINE,
COL_DESC30 NVARCHAR2(2000) NOT INLINE,
ISBRID NUMBER(1),
COMICODE VARCHAR2(3 BYTE) INLINE,
primary key (AUTOID));
2. How are you executing/timing this SQL? ttIsql or an application? Please give as much detail as possible.
in Oracle SQL developer

Similar Messages

Same select max is very slow in one program but fast in another

Hi,
I have a report that becomes very slow these few months. I used SQL trace for the report and found out its these codes that slow down the report:
SELECT MAX( mkpf~budat )
              FROM mkpf
    INNER JOIN mseg
                   ON mseg~mblnr = mkpf~mblnr AND mseg~mjahr = mkpf~mjahr
                INTO posting_date
           WHERE mseg~werks = w_matl-batch_reservations-werks
                 AND mseg~charg = w_matl-batch_reservations-charg
                 AND mseg~bwart IN ('261', 'Z61').
The thing is these codes have been used in different system, DEV, QAS, and PRD. But only in PRD it is very slow, other systems are pretty fast.
I even created a local copy of that report in PRD, with the same code. The local file runs fast and perfectly. But the original code is just slow.
Just wondering if anybody met this problem too? any ideas??

Hi Liu,
Index creation is not a advisable solution.Please follow the existing indexes by adding Mandt field.
Try like this
SELECT MAX( mkpf~budat )
              FROM mkpf
    INNER JOIN mseg
                   ON mseg~mblnr = mkpf~mblnr AND mseg~mjahr = mkpf~mjahr
                INTO posting_date
           WHERE mseg~mandt = sy-mandt
                  AND mkpf~mandt = sy-mandt
                  AND mseg~werks = w_matl-batch_reservations-werks
                 AND mseg~charg = w_matl-batch_reservations-charg
                 AND mseg~bwart IN ('261', 'Z61').
Hope it will be helpful.
Regards,
Kannan

Select statement takes very long

Hello from Germany,
how comes that from one week to another my select-statement "select MAX(PRIMARYKEY) from mytable t where t.IntegerColumn = 5" takes 20times longer (25s) than before (0,4s)?
The RowCount of myTable is 89899.
Best Regards
Marlon

Hi all together,
a "select * from all_tables" shows me or my table following facts:
PCT_free 0
PCT_used 0
INI_TRANS 0
MAX_TRANS 0
INITIAL_EXTENT 409600000
NEXT_EXTENT 5120000
MIN_EXTENT 1
MAX_EXTENT 2147483645
PCT_INCREASE 0
FREE_LISTS 1
NUM_ROWS 60829
BLOCKS 41559
Other facts needed?
Hope You can help me?!
Marlon

Select statement takes very long to run with order by clause.

Hi all,
I have a select statement which when I run without the order by clause takes arround 2 minutes to run. But with the order by clause it goes on for ever. I am trying to access the database server through a network which is not too fast.
The select statement is based on 9 views which are again based on some views. It also has inline views and outer joins. These views and inline views can not be done away with.
When selected without the order by clause it gives 3215 records.
Anything like 2 to 3 minutes will be Ok.
Thanks.
--Malay

The select statement is as follows :-
SELECT f.system_name,
a.signal_type,
f.sys_signal_name,
a.bus_desc,
b.vl_ident,
b.vl_name,
b.src_mac,
b.src_mac_addr,
b.dest_mac,
b.dest_mac_addr,
b.network,
bb.bufr_size_in_bytes,
bb.bag_in_ms,
bb.is_rma_used,
bb.is_ic_used,
bb.sub_vl_cnt,
bb.skew_max_in_ns,
cc.msg_name,
c.src_ip,
c.src_ip_addr,
c.src_port,
c.dest_ip,
c.dest_ip_addr,
c.dest_port,
cc.rate_in_ms,
cc.tx_mode,
cc.protocol,
cc.port_type,
cc.msg_length_in_bytes,
d.mnemonic,
d.start_addr32,
d.lsb,
d.end_addr32,
d.msb,
d.format,
d.init_value,
d.fs_mnemonic,
d.fs_afdx_data_id,
d.digital_data_id,
DECODE(
d.digital_datatype,
NULL, '',
'UNUSED', '',
api$util.concat_column_data(
'api_'
|| d.digital_datatype,
'digital_data_id',
d.digital_data_id,
bool.FALSE
) AS data_details,
f.connection_id
|| '_'
|| a.digital_bus_id
|| '_'
|| b.afdx_vl_id
|| '_'
|| bb.afdx_output_id
|| '_'
|| c.afdx_frame_id
|| '_'
|| cc.afdx_msg_id
|| '_'
|| d.afdx_data_id AS KEY
FROM api_afdx a,
api_afdx_vl b,
api_afdx_output bb,
api_afdx_frame c,
api_afdx_msg cc,
api_afdx_data d,
vf_signal e,
(SELECT DISTINCT aa.signal_id,
cc.system_name,
bb.connection_id,
bb.sys_signal_name
FROM vf_nodes aa,
vf_connections bb,
vf_system cc
WHERE aa.connection_id = bb.connection_id
AND bb.system_id = cc.system_id) f
WHERE e.signal_id = f.signal_id(+)
AND e.digital_bus_id = a.digital_bus_id
               AND a.digital_bus_id = bb.digital_bus_id(+)
AND bb.afdx_output_id = b.afdx_output_id(+)
               AND b.afdx_vl_id = c.afdx_vl_id(+)
AND bb.afdx_output_id = cc.afdx_output_id(+)
AND cc.afdx_msg_id = d.afdx_msg_id(+)
ORDER BY f.system_name,
a.signal_type,
f.sys_signal_name,
b.vl_name,
cc.msg_name,
d.start_addr32,
d.lsb;
Where api_afdx ,
api_afdx_vl ,
api_afdx_output ,
api_afdx_frame ,
api_afdx_msg ,
api_afdx_data ,
vf_signal ,
vf_nodes ,
vf_connections ,
vf_system
are all views.

Selecting text becomes very slow in terminal app

I use the terminal app a lot. Since I've upgraded to Lion, after running for a few days when I try to select some text to copy and paste, it gets slower and slower and eventually takes a minute or two to copy the text. Terminal just sits there and I can't select another terminal window. The copied text is not in the clipboard yet because if I try to paste into another app the old contents are there. I'm trying to figure out if there's something I do that triggers this or if it's just how long terminal's been running. It seems to be worse with multiple line selects. I often resize windows a lot - very wide to see output lines without wrap and then back narrow for normal output. I have a lot of saved lines per window (10,000). I move the laptop between home and work by just putting it to sleep, and when I plug it into a different size monitor all my open terminal windows come up about 50x100 pixels and I have to resize them back to normal size (that's new with Lion). But none of this is different from how I worked before Lion and it never got slow. When I'm working the delay makes it almost impossible to use copy and paste. If I reboot it's ok again for a while. Anyone else seen this? I've seen posts about the terminal app being slow to open, but this is different. Any ideas? thanks.

Please read this whole message before doing anything.
This procedure is a test, not a solution. Don’t be disappointed when you find that nothing has changed after you complete it.
Step 1
The purpose of this step is to determine whether the problem is localized to your user account.
Enable guest logins and log in as Guest. For instructions, launch the System Preferences application, select Help from the menu bar, and enter “Set up a guest account” (without the quotes) in the search box.
While logged in as Guest, you won’t have access to any of your personal files or settings. Applications will behave as if you were running them for the first time. Don’t be alarmed by this; it’s normal. If you need any passwords or other personal data in order to complete the test, memorize, print, or write them down before you begin.
Test while logged in as Guest. Same problem(s)?
After testing, log out of the guest account and, in your own account, disable it if you wish. Any files you created in the guest account will be deleted automatically when you log out of it.
Note: If you’ve activated FileVault in Mac OS X 10.7 or later, then you can’t enable the Guest account. Create a new account in which to test, and delete it, including its home folder, after testing.
Step 2
The purpose of this step is to determine whether the problem is caused by third-party system modifications that load automatically at startup or login.
Disconnect all wired peripherals except those needed for the test, and remove all aftermarket expansion cards. Boot in safe mode and log in to the account with the problem. The instructions provided by Apple are as follows:
Be sure your Mac is shut down.
Press the power button.
Immediately after you hear the startup tone, hold the Shift key. The Shift key should be held as soon as possible after the startup tone, but not before the tone.
Release the Shift key when you see the gray Apple icon and the progress indicator (looks like a spinning gear).
Safe mode is much slower to boot and run than normal, and some things won’t work at all, including wireless networking on certain Macs.
The login screen appears even if you usually log in automatically. You must know your login password in order to log in. If you’ve forgotten the password, you will need to reset it before you begin.
Test while in safe mode. Same problem(s)?
After testing, reboot as usual (i.e., not in safe mode.) Post the results of steps 1 and 2.

Select statement from bkpf slows down the system

hi guys,
i have this syntax for this coding:
        SELECT * FROM bkpf
         WHERE bukrs = ekko-bukrs
           AND awkey = xawkey
           AND gjahr = i_ir-budat(4)
           AND blart = 'RE'.
        CLEAR: titab.
        titab-ebeln = itab-ebeln.
        titab-ebelp = itab-ebelp.
        titab-budat = bkpf-budat.
        titab-bldat = bkpf-bldat.
        titab-xblnr = bkpf-xblnr.
        APPEND titab.
     ENDSELECT.
this coding really slows down the report seleection and sytem , can anybody advice on how to select the better way

Hi Ester,
First you need to avoid the select and endselect statement by using SELECT INTO TABLE.
Second issue is u are using non-key fields in where conditions are aweky, belnr and u r not using the belnr which is first key-field in the BKPF table.
Third one is try to use the fields in correct order which it is in table say in ur where codition it should be like bukrs, gjahr, blart, awkey,....
if you dont have a input field BELNR and u need to do really improve the performance with these input fields wht you have, its is better to create Secondary index with proper sequence for felds.
But i am not sure to give permission to create secondary index bec it takes more memory occupation like what exact BKPF tbale contains, you need to permission from client people along with BASIS people.
i am give sample code :
SELECT * FROM bkpf " try to specify the internal table with exact fileds instead '*'
    into table tbl _ bkpf
WHERE belnr = w_belnr
and    bukrs = ekko-bukrs
AND gjahr = i_ir-budat(4)
AND blart = 'RE'.
AND awkey = xawkey.
If sy-subrc = 0.
sory tbl_bkpf by belnr.
endif.
Let me know if any doubts.
<b>Reward with points if useful.</b>
Regards,
Vija

CTAS very slow

hi
My select query becomes very fast,instead when i'm creating a table with CTAS with same condition
becomes very slow.What could be wrong
oarcle 11.2.0.1
windows server 2008 64 bit

Josh Mathew wrote:
hi
My select query becomes very fast,instead when i'm creating a table with CTAS with same condition
becomes very slow.What could be wrong
oarcle 11.2.0.1
windows server 2008 64 bitJust out of curiosity, what is the value for OPTIMIZER_FEATURES_ENABLE? I am able to trigger a different execution plan on 11.2.0.1 when a SELECT statement is performed (very fast execution ~ 0.20 seconds) compared to when an INSERT INTO ... SELECT is performed (very slow ~ 30 minutes). This performance issue was triggered with a OPTIMIZER_FEATURES_ENABLE setting of 10.1.0.4 (Oracle Database 10.2.0.5 did not exhibit the same performance problem with the same 10.1.0.4 value for OPTIMIZER_FEATURES_ENABLE). A test case is provided here (note that the OPTIMIZER_MODE was set to ALL_ROWS for the test):
http://hoopercharles.wordpress.com/2010/12/18/select-statement-is-fast-insert-into-using-the-select-statement-is-brutally-slow-2/
I suggest taking a look at the execution plans to see if the execution plan is different for the plain SELECT statement compared to the CREATE TABLE AS - a script is provided in part 3 of the series. In your case a 10046 trace at level 8 might also indicate problems such as write delays related to redo. Also consider capturing a 10053 trace to see if something such as complex view merging is taking place during the CREATE TABLE AS syntax when the plain SELECT statement is not performing the complex view merging. Readers of the first part of the blog article series provided suggestions in the comments for troubleshooting similar problems.
Charles Hooper
Co-author of "Expert Oracle Practices: Oracle Database Administration from the Oak Table"
http://hoopercharles.wordpress.com/
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

Select query performance is very slow

Could you please explain me about BITMAP CONVERSION FROM ROWIDS
Why the below query going for two times BITMAP CONVERSION TO ROWIDS on the same table.
SQL> SELECT AGG.AGGREGATE_SENTENCE_ID ,
2         AGG.ENTITY_ID,
3         CAR.REQUEST_ID REQUEST_ID
4    FROM epic.eh_aggregate_sentence agg ,om_cpps_active_requests car
5   WHERE car.aggregate_sentence_id =agg.aggregate_sentence_id
6 AND car.service_unit = '0ITNMK0020NZD0BE'
7 AND car.request_type = 'CMNTY WORK'
8 AND agg.hours_remaining > 0
9 AND NOT EXISTS (SELECT 'X'
10                    FROM epic.eh_agg_sent_termination aggSentTerm
11                   WHERE aggSentTerm.aggregate_sentence_id = agg.aggregate_sentence_id
12                     AND aggSentTerm.date_terminated <= epic.epicdatenow);
Execution Plan
Plan hash value: 1009556971
| Id | Operation                           | Name                       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                    |                            |     5 |   660 |    99   (2)| 00:00:02 |
|* 1 | HASH JOIN ANTI                     |                            |     5 |   660 |    99   (2)| 00:00:02 |
|   2 |   NESTED LOOPS                      |                            |       |       |            |          |
|   3 |    NESTED LOOPS                     |                            |     7 |   658 |    95   (0)| 00:00:02 |
|* 4 |     TABLE ACCESS BY INDEX ROWID     | OM_CPPS_ACTIVE_REQUESTS    |    45 | 2565 |    50   (0)| 00:00:01 |
|   5 |      BITMAP CONVERSION TO ROWIDS    |                            |       |       |            |          |
|   6 |       BITMAP AND                    |                            |       |       |            |          |
|   7 |        BITMAP CONVERSION FROM ROWIDS|                            |       |       |            |          |
|* 8 |         INDEX RANGE SCAN            | OM_CA_REQUEST_REQUEST_TYPE |   641 |       |    12   (0)| 00:00:01 |
|   9 |        BITMAP CONVERSION FROM ROWIDS|                            |       |       |            |          |
|* 10 |         INDEX RANGE SCAN            | OM_CA_REQUEST_SERVICE_UNIT |   641 |       |    20   (0)| 00:00:01 |
|* 11 |     INDEX UNIQUE SCAN               | PK_EH_AGGREGATE_SENTENCE   |     1 |       |     0   (0)| 00:00:01 |
|* 12 |    TABLE ACCESS BY INDEX ROWID      | EH_AGGREGATE_SENTENCE      |     1 |    37 |     1   (0)| 00:00:01 |
| 13 |   TABLE ACCESS BY INDEX ROWID       | EH_AGG_SENT_TERMINATION    |    25 |   950 |     3   (0)| 00:00:01 |
|* 14 |    INDEX RANGE SCAN                 | DATE_TERMINATED_0520       |     4 |       |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - access("AGGSENTTERM"."AGGREGATE_SENTENCE_ID"="AGG"."AGGREGATE_SENTENCE_ID")
   4 - filter("CAR"."AGGREGATE_SENTENCE_ID" IS NOT NULL)
   8 - access("CAR"."REQUEST_TYPE"='CMNTY WORK')
10 - access("CAR"."SERVICE_UNIT"='0ITNMK0020NZD0BE')
11 - access("CAR"."AGGREGATE_SENTENCE_ID"="AGG"."AGGREGATE_SENTENCE_ID")
12 - filter("AGG"."HOURS_REMAINING">0)
14 - access("AGGSENTTERM"."DATE_TERMINATED"<="EPIC"."EPICDATENOW"())now this query is giving the correct result, but performance is slow.
Please help to improve the performance.
SQL> desc epic.eh_aggregate_sentence
Name                                      Null?    Type
ENTITY_ID                                          CHAR(16)
AGGREGATE_SENTENCE_ID                     NOT NULL CHAR(16)
HOURS_REMAINING                                    NUMBER(9,2)
SQL> desc om_cpps_active_requests
Name                                      Null?    Type
REQUEST_ID                                NOT NULL VARCHAR2(16)
AGGREGATE_SENTENCE_ID                              VARCHAR2(16)
REQUEST_TYPE                              NOT NULL VARCHAR2(20)
SERVICE_UNIT                                       VARCHAR2(16)
SQL> desc epic.eh_agg_sent_termination
Name                                      Null?    Type
TERMINATION_ID                            NOT NULL CHAR(16)
AGGREGATE_SENTENCE_ID                     NOT NULL CHAR(16)
DATE_TERMINATED                           NOT NULL CHAR(20)
.

user10594152 wrote:
Thanks for your reply.
Still i am getting same problemIt is not a problem. Bitmap conversion usually is a very good thing. Useing this feature the database can use one or several unselective b*indexes. Combine them and do a kind of bitmap selection. THis should be slightly faster than a FTS and much faster than a normal index access.
Your problem is that your filter criteria seem to be not very usefull. Whcih is the criteria that does the best reduction of rows?
Also any kind of NOT EXISTS is potentiall not very fast (NOT IN is worse). You can rewrite your query with an OUTER JOIN. Sometimes this will help, but not always.
SELECT AGG.AGGREGATE_SENTENCE_ID ,
        AGG.ENTITY_ID,
        CAR.REQUEST_ID REQUEST_ID
FROM epic.eh_aggregate_sentence agg
JOIN om_cpps_active_requests car ON ar.aggregate_sentence_id =agg.aggregate_sentence_id
LEFT JOIN epic.eh_agg_sent_termination aggSentTerm ON aggSentTerm.aggregate_sentence_id = agg.aggregate_sentence_id and aggSentTerm.date_terminated <= epic.epicdatenow
WHERE car.service_unit = '0ITNMK0020NZD0BE'
AND car.request_type = 'CMNTY WORK'
AND agg.hours_remaining > 0
AND aggSentTerm.aggregate_sentence_id is nullEdited by: Sven W. on Aug 31, 2010 4:01 PM

Latency is very high when SELECT statements are running for LONG

We are a simple DOWN STREAM streams replication environment ( Archive log is shipped from source , CAPTURE & APPLY are running on destination DB).
Whenever there is a long running SELECT statement on TARGET the latency become very high.
SGA_MAX_SIZE = 8GB
STREAMS_POOL_SIZE=2GB
APPLY parallelism = 4
How can resolve this issue?

Is the log file shipped but not acknowledge? -- NO
Is the log file not shipped? -- It is shipped
Is the log file acknowledged by not applied? -- Yes...But Apply process was not stopped. it may be slow or waiting for something?
It is 10g Environment. I will run AWR.. But what should i look for in AWR?

The problem is with the new operating system and sending photo via email when used in my iPad. From photo I selected 3 photos to send via email. I choose the upload key and choose to send by email. Typing text on the email is very slow.

The problem is with the new operating system and sending photo via email when used in my iPad.
From photo I selected 3 photos to send via email. I choose the upload key and choose to send by email. Typing text on the email is very slow. This is solved by saving the email as a draft and opening the email again from mail.
Can you amend he system to allow emails to be sent from photo as previously.

Have you tried restarting or resetting your iPad?
Restart: Press On/Off button until the Slide to Power Off slider appears, select Slide to Power Off and, after the iPad shuts down, then press the On/Off button until the Apple logo appears.
Reset: Press the Home and On/Off buttons at the same time and hold them until the Apple logo appears (about 10 seconds). Ignore the "Slide to power off"

Simple Select on VBPA using index running very slow

Hello,
We have a very simple selection on the table VBPA:
data:
begin of it_vbeln occurs 100,
vbeln like vbpa-vbeln,
end of it_vbeln.
select vbeln from vbpa
into table it_vbeln
where
kunnr = '##########'
and parvw = 'AG'.
All we're trying to accomplish is to find orders for a given customer number and type.
We have two indices "Z1" and "Z2" which respectively declare: KUNNR, and MANDT, KUNNR, PARVW.
In looking at a sql trace, it says it's using the VBPA~Z2 index, which is expected, and that its estimated costs are very low on the index:
SELECT STATEMENT ( Estimated Costs = 71 , Estimated #Rows = 63 )
       2 TABLE ACCESS BY INDEX ROWID VBPA
         ( Estim. Costs = 71 , Estim. #Rows = 63 )
         Estim. CPU-Costs = 553,782 Estim. IO-Costs = 71
           1 INDEX RANGE SCAN VBPA~Z2
             ( Estim. Costs = 3 , Estim. #Rows = 111 )
             Search Columns: 3
             Estim. CPU-Costs = 43,764 Estim. IO-Costs = 3
Despite declaring that it will do an index range scan, in SM51 it shows as Sequential Read (Table Scan?) and takes a VERY long time to return, about 60 - 120 seconds.
Since this is needed for a user exit that will be run during order creation, it needs to occur MUCH faster. Our entries in VBPA number above 10 million records currently.
Can anyone suggest either why the index does not appear to be helping (it takes just as long without the index), or perhaps another method for finding the orders for a given customer number.
Thank you,
Randy

Hi Randy,
I suggest you skip the attempts to speed up selecting on VBPA, but rather look into using table VAKPA for finding sales documents for a given partner number.
Greetings
Thomas

Very slow select query-

Hi Guys,
First of all apologies for the long post…
I have written a query to fetch some data but it’s really slow…
SELECT di.doc_no       doc_no,
       di.doc_class    doc_class,
       di.doc_sheet    doc_sheet,
       di.doc_rev      doc_rev
FROM dia_table di, pi_table pi
WHERE pi.user_id = 'alain'
AND   (1 IN (SELECT 1
             FROM   spg_table s, ur_table r
             WHERE r.identity     = pi.user_id
             AND    r.role         = s.role
             AND    s.privilege_id = 'ADMINISTRATOR' )
OR ( (di.edit_access = 1 OR di.view_access = 1) AND di.person_id = pi.person_id )
OR ( (di.edit_access = 1 OR di.view_access = 1) AND (di.person_id   = '*') )
OR ( (di.edit_access = 1 OR di.view_access = 1) AND (di.group_id IS NOT NULL)
      AND
     (1 IN   (SELECT 1
              FROM   dgm_table
              WHERE group_id = di.group_id
              AND ( person_id = pi.person_id OR person_id = '*' ) ) )
     )This will take more than 3 hours to run…
dia_table - 1400000 records
pi_table - 2500 records
spg_table - 20 records
ur_table - 12000 records
dgm_table - 1500 records
Can you please advice on what kind of modifications that I could do to improve the above query…
To get an idea I have the following results also…
1.
SELECT count(*)
FROM dia_table di, pi_table pi
WHERE di.doc_no LIKE '10012%';
If I run the above query (with out the where clause and with a extra condition to reduce the time to execute the query) it will return 481381 records within 4 seconds.
2.
SELECT count(*)
FROM dia_table di, pi_table pi
WHERE pi.user_id = 'alain'
AND   (1 IN (SELECT 1
             FROM   spg_table s, ur_table r
             WHERE r.identity     = pi.user_id
             AND    r.role         = s.role
             AND    s.privilege_id = 'ADMINISTRATOR' )
OR ( (di.edit_access = 1 OR di.view_access = 1) AND di.person_id = pi.person_id )
OR ( (di.edit_access = 1 OR di.view_access = 1) AND (di.person_id   = '*') )
OR ( (di.edit_access = 1 OR di.view_access = 1) AND (di.group_id IS NOT NULL) )
AND di.doc_no LIKE '10012%';
This will return 241999 records within135 seconds. (Without the final AND clause)
3.
SELECT count(*)
FROM dia_table di, pi_table pi
WHERE pi.user_id = 'alain'
AND   (1 IN (SELECT 1
             FROM   spg_table s, ur_table r
             WHERE r.identity     = pi.user_id
             AND    r.role         = s.role
             AND    s.privilege_id = 'ADMINISTRATOR' )
OR ( (di.edit_access = 1 OR di.view_access = 1) AND di.person_id = pi.person_id )
OR ( (di.edit_access = 1 OR di.view_access = 1) AND (di.person_id   = '*') )
OR ( (di.edit_access = 1 OR di.view_access = 1) AND (di.group_id IS NOT NULL)
      AND
     (1 IN   (SELECT 1
              FROM   dgm_table
              WHERE group_id = di.group_id
              AND ( person_id = pi.person_id OR person_id = '*' ) ) )
AND di.doc_no LIKE '10012%';
This will return 32299 records in 461 seconds. The extra condition (AND di.doc_no LIKE '10012%') was used to reduce the overall time taken so that I could see the execution times more quickly.I really appreciate any help/comments/advices you guys can provide…

Hi... hope this will be a help to provide a suggestion…
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 2456893396
| Id | Operation                      | Name                      | Rows | Byt
|   0 | SELECT STATEMENT               |                           | 1332K|
|   1 | CONCATENATION                 |                           |       |
|* 2 |   FILTER                       |                           |       |
|   3 |    MERGE JOIN CARTESIAN        |                           |   517 | 284
|* 4 |     TABLE ACCESS BY INDEX ROWID| DIA_TABLE                 |     1 |
|* 5 |      INDEX RANGE SCAN          | DIA_PK                    |     1 |
|   6 |     BUFFER SORT                |                           | 2393 | 263
|   7 |      TABLE ACCESS FULL         | PI_TABLE                  | 2393 | 263
|   8 |    INLIST ITERATOR             |                           |       |
|* 9 |     INDEX RANGE SCAN           | DGM_PK                    |     1 |
|* 10 |   FILTER                       |                           |       |
| 11 |    MERGE JOIN CARTESIAN        |                           |   897 | 493
|* 12 |     TABLE ACCESS FULL          | DIA_TABLE                 |     1 |
| 13 |     BUFFER SORT                |                           | 2393 | 263
| 14 |      TABLE ACCESS FULL         | PI_TABLE                  | 2393 | 263
PLAN_TABLE_OUTPUT
| 15 |    INLIST ITERATOR             |                           |       |
|* 16 |     INDEX RANGE SCAN           | DGM_PK                    |     1 |
|* 17 |   FILTER                       |                           |       |
|* 18 |    HASH JOIN                   |                           | 46630 | 25
| 19 |     TABLE ACCESS FULL          | PI_TABLE                  | 2393 | 263
|* 20 |     TABLE ACCESS FULL          | DIA_TABLE                 |   139K| 60
| 21 |    INLIST ITERATOR             |                           |       |
|* 22 |     INDEX RANGE SCAN           | DGM_PK                    |     1 |
|* 23 |   FILTER                       |                           |       |
| 24 |    NESTED LOOPS                |                           | 64224 | 34
| 25 |     TABLE ACCESS BY INDEX ROWID| PI_TAB                    |     1 |
|* 26 |      INDEX UNIQUE SCAN         | USER_ID_UX                |     1 |
| 27 |       NESTED LOOPS             |                           |     1 |
|* 28 |        INDEX FULL SCAN         | SYSTEM_PRIVILEGE_GRANT_PK |     1 |
|* 29 |        INDEX UNIQUE SCAN       | FND_USER_ROLE_RUNTIME_PK |     1 |
|* 30 |     TABLE ACCESS FULL          | DIA_TABLE                 | 1284K|
| 31 |    INLIST ITERATOR             |                           |       |
|* 32 |     INDEX RANGE SCAN           | DGM_PK                    |     1 |
--------------------------------------------------------------------------------Edited by: Napster on Oct 20, 2009 1:13 AM

[11g R2] Update-Select with BITMAP CONVERSION TO ROWIDS = very slow

Hi all,
I have to deal with some performance issues in our database.
The query below takes between 30 minutes and 60 minutes to complete (30 minutes during the batch process and 1h when I executed the query with SQLPLUS):
SQL_ID 4ky65wauhg1ub, child number 0
UPDATE fiscpt x    SET (x.cimld) =           (SELECT COUNT (*)
    FROM fiscpt f             WHERE f.comar = x.comar               AND
f.coint = x.coint               AND f.nucpt = x.nucpt               AND
f.codev != x.codev               AND f.cimvt != 0) WHERE x.comar IN
('CBOT', 'CME', 'EUREX', 'FOREX', 'LIFFE', 'METAL', 'OCC')
Plan hash value: 697684605
| Id | Operation                          | Name    | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers | Reads | OMem | 1Mem | Used-Mem |
|   0 | UPDATE STATEMENT                   |         |      1 |        |       |   773K(100)|          |      0 |00:22:22.30 |      36M|   7629 |       |       |          |
|   1 | UPDATE                            | FISCPT |      1 |        |       |            |          |      0 |00:22:22.30 |      36M|   7629 |       |       |          |
|   2 |   INLIST ITERATOR                  |         |      1 |        |       |            |          |    179K|00:00:00.37 |    1221 |      3 |       |       |          |
|* 3 |    INDEX RANGE SCAN                | FISCPT1 |      7 |    154K| 4984K|     5   (0)| 00:00:01 |    179K|00:00:00.23 |    1221 |      3 |       |       |          |
|   4 |   SORT AGGREGATE                   |         |    179K|      1 |    33 |            |          |    179K|01:02:58.45 |      35M|   3020 |       |       |          |
|* 5 |    TABLE ACCESS BY INDEX ROWID     | FISCPT |    179K|      1 |    33 |     4 (25)| 00:00:01 | 63681 |01:02:57.80 |      35M|   3020 |       |       |          |
|   6 |     BITMAP CONVERSION TO ROWIDS    |         |    179K|        |       |            |          |    121K|01:02:52.71 |      35M|    885 |       |       |          |
|   7 |      BITMAP AND                    |         |    179K|        |       |            |          | 87091 |01:02:52.25 |      35M|    885 |       |       |          |
|   8 |       BITMAP CONVERSION FROM ROWIDS|         |    179K|        |       |            |          |    179K|00:00:03.31 |     241K|      0 |       |       |          |
|* 9 |        INDEX RANGE SCAN            | FISCPT2 |    179K|   1547 |       |     1   (0)| 00:00:01 |   1645K|00:00:02.23 |     241K|      0 |       |       |          |
| 10 |       BITMAP CONVERSION FROM ROWIDS|         |    179K|        |       |            |          |    148K|01:02:44.98 |      35M|    885 |       |       |          |
| 11 |        SORT ORDER BY               |         |    179K|        |       |            |          |   2412M|00:52:19.70 |      35M|    885 | 1328K|   587K| 1180K (0)|
|* 12 |         INDEX RANGE SCAN           | FISCPT1 |    179K|   1547 |       |     2   (0)| 00:00:01 |   2412M|00:22:11.22 |      35M|    885 |       |       |          |
Query Block Name / Object Alias (identified by operation id):
   1 - UPD$1
   3 - UPD$1 / X@UPD$1
   4 - SEL$1
   5 - SEL$1 / F@SEL$1
Predicate Information (identified by operation id):
   3 - access(("X"."COMAR"='CBOT' OR "X"."COMAR"='CME' OR "X"."COMAR"='EUREX' OR "X"."COMAR"='FOREX' OR "X"."COMAR"='LIFFE' OR "X"."COMAR"='METAL' OR
              "X"."COMAR"='OCC'))
   5 - filter("F"."CIMVT"<>0)
   9 - access("F"."COINT"=:B1 AND "F"."NUCPT"=:B2)
12 - access("F"."COMAR"=:B1)
       filter(("F"."CODEV"<>:B1 AND "F"."COMAR"=:B2))
Column Projection Information (identified by operation id):
   2 - (upd=6; cmp=2,3,4,5) "SYS_ALIAS_4".ROWID[ROWID,10], "X"."COMAR"[VARCHAR2,5], "X"."COINT"[VARCHAR2,11], "X"."NUCPT"[VARCHAR2,8], "X"."CODEV"[VARCHAR2,3],
       "X"."CIMLD"[NUMBER,22]
   3 - "SYS_ALIAS_4".ROWID[ROWID,10], "X"."COMAR"[VARCHAR2,5], "X"."COINT"[VARCHAR2,11], "X"."NUCPT"[VARCHAR2,8], "X"."CODEV"[VARCHAR2,3], "X"."CIMLD"[NUMBER,22]
   4 - (#keys=0) COUNT(*)[22]
   5 - "F".ROWID[ROWID,10], "F"."COMAR"[VARCHAR2,5], "F"."COINT"[VARCHAR2,11], "F"."NUCPT"[VARCHAR2,8], "F"."CODEV"[VARCHAR2,3], "F"."CIMVT"[NUMBER,22]
   6 - "F".ROWID[ROWID,10]
   7 - STRDEF[BM VAR, 10], STRDEF[BM VAR, 10], STRDEF[BM VAR, 32496]
   8 - STRDEF[BM VAR, 10], STRDEF[BM VAR, 10], STRDEF[BM VAR, 32496]
   9 - "F".ROWID[ROWID,10]
10 - STRDEF[BM VAR, 10], STRDEF[BM VAR, 10], STRDEF[BM VAR, 32496]
11 - (#keys=1) "F".ROWID[ROWID,10]
12 - "F".ROWID[ROWID,10]
Note
   - dynamic sampling used for this statement (level=2)We intentionally don't gather statistics on the FISCPT table.
There are no indexes on the column updated so the slowness is not due to updating of indexes:
SQL> select index_name, column_name from user_ind_columns where table_name='FISCPT';
INDEX_NAME COLUMN_NAM
FISCPT1    NUCPT
FISCPT1    CODEV
FISCPT1    RGCID
FISCPT1    DATRA
FISCPT2    COINT
FISCPT2    NUCPT
FISCPT3    NUFIS
FISCPT1    COINT
FISCPT1    COMAR
9 ligne(s) sÚlectionnÚe(s).
SQL> select count(1) from FISCPT;
COUNT(1)
    179369If I replace the UPDATE-SELECT statement by a SELECT, the query runs in few seconds:
SQL> SELECT COUNT (*)
2               FROM fiscpt f, fiscpt x
3              WHERE f.comar = x.comar
4                AND f.coint = x.coint
5                AND f.nucpt = x.nucpt
6                AND f.codev != x.codev
7                AND f.cimvt != 0
8   and x.comar IN ('CBOT', 'CME', 'EUREX', 'FOREX', 'LIFFE', 'METAL', 'OCC');
COUNT(*)
     63681
EcoulÚ : 00 :00 :00.75
SQL> select * from table(dbms_xplan.display_cursor());
PLAN_TABLE_OUTPUT
SQL_ID 5drbpdmdv0gv1, child number 0
SELECT COUNT (*)              FROM fiscpt f, fiscpt x
WHERE f.comar = x.comar               AND f.coint = x.coint
AND f.nucpt = x.nucpt               AND f.codev != x.codev
   AND f.cimvt != 0 and x.comar IN ('CBOT', 'CME', 'EUREX', 'FOREX',
'LIFFE', 'METAL', 'OCC')
Plan hash value: 1326101771
| Id | Operation                      | Name    | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT               |         |       |       |       | 2477 (100)|          |
|   1 | SORT AGGREGATE                |         |     1 |    53 |       |            |          |
|* 2 |   HASH JOIN                    |         |   107K| 5557K| 4720K| 2477   (1)| 00:00:30 |
|   3 |    INLIST ITERATOR             |         |       |       |       |            |          |
|* 4 |     TABLE ACCESS BY INDEX ROWID| FISCPT |   107K| 3460K|       | 1674   (1)| 00:00:21 |
|* 5 |      INDEX RANGE SCAN          | FISCPT1 |   154K|       |       |   873   (0)| 00:00:11 |
|* 6 |    INDEX FAST FULL SCAN        | FISCPT1 |   154K| 3021K|       |   337   (0)| 00:00:05 |
Predicate Information (identified by operation id):
   2 - access("F"."COMAR"="X"."COMAR" AND "F"."COINT"="X"."COINT" AND
              "F"."NUCPT"="X"."NUCPT")
       filter("F"."CODEV"<>"X"."CODEV")
   4 - filter("F"."CIMVT"<>0)
   5 - access(("F"."COMAR"='CBOT' OR "F"."COMAR"='CME' OR "F"."COMAR"='EUREX' OR
              "F"."COMAR"='FOREX' OR "F"."COMAR"='LIFFE' OR "F"."COMAR"='METAL' OR "F"."COMAR"='OCC'))
   6 - filter(("X"."COMAR"='CBOT' OR "X"."COMAR"='CME' OR "X"."COMAR"='EUREX' OR
              "X"."COMAR"='FOREX' OR "X"."COMAR"='LIFFE' OR "X"."COMAR"='METAL' OR "X"."COMAR"='OCC'))
Note
   - dynamic sampling used for this statement (level=2)The optimizer parameters are at their default values.
The database is an 11.2.0.1 and the OS is a Linux Red hat.
can someone help me to tune this query please?

Thanks Tubby for your reply,
We don't gather statistics at all on this table because it's a process table: on the production database we may have several processes which insert/delet/update rows into this table so we prefer to rely on Dynamic Sampling instead of gathering statistics each time a process need to access this table.
I don't dynamic sampling is the problem here because when i use the level 10 the execution plan is the same:
SQL> alter session set optimizer_dynamic_sampling=10;
Session modifiÚe.
EcoulÚ : 00 :00 :00.00
SQL> explain plan for
2 UPDATE fiscpt x
3     SET (x.cimld) =
4            (SELECT COUNT (*)
5               FROM fiscpt f
6              WHERE f.comar = x.comar
7                AND f.coint = x.coint
8                AND f.nucpt = x.nucpt
9                AND f.codev != x.codev
10                AND f.cimvt != 0)
11   WHERE x.comar IN ('CBOT', 'CME', 'EUREX', 'FOREX', 'LIFFE', 'METAL', 'OCC');
ExplicitÚ.
EcoulÚ : 00 :00 :01.04
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 697684605
| Id | Operation                          | Name    | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | UPDATE STATEMENT                   |         |   179K| 5780K|   896K (20)| 02:59:23 |
|   1 | UPDATE                            | FISCPT |       |       |            |          |
|   2 |   INLIST ITERATOR                  |         |       |       |            |          |
|* 3 |    INDEX RANGE SCAN                | FISCPT1 |   179K| 5780K|     5   (0)| 00:00:01 |
|   4 |   SORT AGGREGATE                   |         |     1 |    33 |            |          |
|* 5 |    TABLE ACCESS BY INDEX ROWID     | FISCPT |     1 |    33 |     4 (25)| 00:00:01 |
|   6 |     BITMAP CONVERSION TO ROWIDS    |         |       |       |            |          |
|   7 |      BITMAP AND                    |         |       |       |            |          |
|   8 |       BITMAP CONVERSION FROM ROWIDS|         |       |       |            |          |
|* 9 |        INDEX RANGE SCAN            | FISCPT2 | 1794 |       |     1   (0)| 00:00:01 |
| 10 |       BITMAP CONVERSION FROM ROWIDS|         |       |       |            |          |
| 11 |        SORT ORDER BY               |         |       |       |            |          |
|* 12 |         INDEX RANGE SCAN           | FISCPT1 | 1794 |       |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   3 - access("X"."COMAR"='CBOT' OR "X"."COMAR"='CME' OR "X"."COMAR"='EUREX' OR
              "X"."COMAR"='FOREX' OR "X"."COMAR"='LIFFE' OR "X"."COMAR"='METAL' OR
              "X"."COMAR"='OCC')
   5 - filter("F"."CIMVT"<>0)
   9 - access("F"."COINT"=:B1 AND "F"."NUCPT"=:B2)
12 - access("F"."COMAR"=:B1)
       filter("F"."CODEV"<>:B1 AND "F"."COMAR"=:B2)
Note
   - dynamic sampling used for this statement (level=10)I have tested the query you provided and the execution plan is almost the same (A FILTER clause is added but the COST isthe same):
SQL> explain plan for
2 UPDATE   fiscpt x
3     SET (x.cimld) =
4            (SELECT COUNT (*)
5               FROM fiscpt f
6              WHERE f.comar = x.comar
7                AND f.coint = x.coint
8                AND f.nucpt = x.nucpt
9                AND f.codev != x.codev
10                AND f.cimvt != 0
11                and   f.comar IN ('CBOT', 'CME', 'EUREX', 'FOREX', 'LIFFE', 'METAL', 'OCC')
12                )
13   WHERE x.comar IN ('CBOT', 'CME', 'EUREX', 'FOREX', 'LIFFE', 'METAL', 'OCC');
ExplicitÚ.
EcoulÚ : 00 :00 :00.01
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1565986742
| Id | Operation                           | Name    | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | UPDATE STATEMENT                    |         |   154K| 4984K|   773K (20)| 02:34:41 |
|   1 | UPDATE                             | FISCPT |       |       |            |          |
|   2 |   INLIST ITERATOR                   |         |       |       |            |          |
|* 3 |    INDEX RANGE SCAN                 | FISCPT1 |   154K| 4984K|     5   (0)| 00:00:01 |
|   4 |   SORT AGGREGATE                    |         |     1 |    33 |            |          |
|* 5 |    FILTER                           |         |       |       |            |          |
|* 6 |     TABLE ACCESS BY INDEX ROWID     | FISCPT |     1 |    33 |     4 (25)| 00:00:01 |
|   7 |      BITMAP CONVERSION TO ROWIDS    |         |       |       |            |          |
|   8 |       BITMAP AND                    |         |       |       |            |          |
|   9 |        BITMAP CONVERSION FROM ROWIDS|         |       |       |            |          |
|* 10 |         INDEX RANGE SCAN            | FISCPT2 | 1547 |       |     1   (0)| 00:00:01 |
| 11 |        BITMAP CONVERSION FROM ROWIDS|         |       |       |            |          |
| 12 |         SORT ORDER BY               |         |       |       |            |          |
|* 13 |          INDEX RANGE SCAN           | FISCPT1 | 1547 |       |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   3 - access("X"."COMAR"='CBOT' OR "X"."COMAR"='CME' OR "X"."COMAR"='EUREX' OR
              "X"."COMAR"='FOREX' OR "X"."COMAR"='LIFFE' OR "X"."COMAR"='METAL' OR "X"."COMAR"='OCC')
   5 - filter(:B1='CBOT' OR :B2='CME' OR :B3='EUREX' OR :B4='FOREX' OR :B5='LIFFE' OR
              :B6='METAL' OR :B7='OCC')
   6 - filter(("F"."COMAR"='CBOT' OR "F"."COMAR"='CME' OR "F"."COMAR"='EUREX' OR
              "F"."COMAR"='FOREX' OR "F"."COMAR"='LIFFE' OR "F"."COMAR"='METAL' OR
              "F"."COMAR"='OCC') AND "F"."CIMVT"<>0)
10 - access("F"."COINT"=:B1 AND "F"."NUCPT"=:B2)
13 - access("F"."COMAR"=:B1)
       filter("F"."CODEV"<>:B1 AND ("F"."COMAR"='CBOT' OR "F"."COMAR"='CME' OR
              "F"."COMAR"='EUREX' OR "F"."COMAR"='FOREX' OR "F"."COMAR"='LIFFE' OR
              "F"."COMAR"='METAL' OR "F"."COMAR"='OCC') AND "F"."COMAR"=:B2)
Note
   - dynamic sampling used for this statement (level=2)I have executed this statement for 50 minutes and it is still running now
Furthermore, I have used the tuning advisor but it has not found any recommendation.
is it normal that oracle takes 1hour to update 175k rows?

My Photoshop CS3 goes very slow/choppy when I have a selection made.

Hello,
My Photoshop CS3 goes very slow/choppy when I have a selection made, with those little moving lines indicating the selection (the lines that look like walking ants). When I'm adding to the selection, it's fine again, because the "ants" aren't moving, same with when I hit Q to enter Quick Mask Mode--as long as the "ants" aren't moving, my Photoshop isn't slow. Is there any way to fix this? To either speed up Photoshop or to stop the "ants" from moving, and simply allow selections to be indicated by broken lines, but not moving broken lines?
Thanks

Operating System: Windows 7 Ultimate 32-bit (6.1, Build 7600) (7600.win7_rtm.090713-1255)
           Language: English (Regional Setting: English)
System Manufacturer: Tyan Computer Corporation
       System Model: S2668 Tiger i7505
               BIOS: PhoenixBIOS 4.0 Release 6.0
          Processor: Intel(R) Xeon(TM) CPU 3.06GHz (4 CPUs), ~3.1GHz
             Memory: 4096MB RAM
Available OS Memory: 3072MB RAM
          Page File: 2548MB used, 3589MB available
49.9 GB of 465 GB free.

Delete statements very slow

hi,
We have a performance issue the delete statements on the database are running very slow they are taking about 12 hours.
the delete statements are like
DELETE table_name
WHERE column1 = 'temp'
AND col2 LIKE 'A%'
AND col3 = 0;
that table has an composite index with 5 columns and the columns specified in the delete statements are in the order
column1 position 4
col2 position 3
col3 position 5
no additional indexes are present on the table

As already suggested get an execution plan for the deletes to see what it is doing to make informed decisions about what to do.
Until then ...
You said you have one index on 5 columns
WHERE column1 = 'temp'
AND col2 LIKE 'A%'
AND col3 = 0;
that table has an composite index with 5 columns and the columns specified in the delete statements are in the order
column1 position 4
col2 position 3
col3 position 5Oracle might be doing a skip scan on the index or a full table scan - it is possible neither is efficient for your operation. An index ordered by # of unique values (most unique first) on column1, col2, col3 might help performance on this delete if a small percentage of rows are being deleted (anywhere from 5% to maybe 30%, it depends). If a large percentage of rows are being deleted then a full table scan might be better.
If you have the license and the database is set up for it parallel DML is a possiblity - check the on-line documentation to see how to do the delete in parallel.

Select statement is very slow ?

Similar Messages

Maybe you are looking for