SQL Query very slow.

I have a table which has 40million data in it. Of-course partitioned!.
begin
pk_cm_entity_context.set_entity_in_context(1);
end;
SELECT COUNT(1) FROM XFACE_ADDL_DETAILS_TXNLOG;
alter table XFACE_ADDL_DETAILS_TXNLOG rename to XFACE_ADDLDTS_TXNLOG_PTPART;
SELECT COUNT(1) FROM XFACE_ADDLDTS_TXNLOG_PTPART;
-- Create table
create table XFACE_ADDL_DETAILS_TXNLOG
REF_TXN_NO CHAR(40),
REF_USR_NO CHAR(40),
REF_KEY_NO VARCHAR2(50),
REF_TXN_NO_ORG CHAR(40),
REF_USR_NO_ORG CHAR(40),
RECON_CODE VARCHAR2(25),
COD_TASK_DERIVED VARCHAR2(5),
COD_CHNL_ID VARCHAR2(6),
COD_SERVICE_ID VARCHAR2(10),
COD_USER_ID VARCHAR2(30),
COD_AUTH_ID VARCHAR2(30),
COD_ACCT_NO CHAR(22),
TYP_ACCT_NO VARCHAR2(4),
COD_SUB_ACCT_NO CHAR(16),
COD_DEP_NO NUMBER(5),
AMOUNT NUMBER(15,2),
COD_CCY VARCHAR2(3),
DAT_POST DATE,
DAT_VALUE DATE,
TXT_TXN_NARRATIVE VARCHAR2(60),
DATE_CHEQUE_ISSUE DATE,
TXN_BUSINESS_TYPE VARCHAR2(10),
CARD_NO CHAR(20),
INVENTORY_CODE CHAR(10),
INVENTORY_NO CHAR(20),
CARD_PASSBOOK_NO CHAR(30),
COD_CASH_ANALYSIS CHAR(20),
BANK_INFORMATION_NO CHAR(8),
BATCH_NO CHAR(10),
SUMMARY VARCHAR2(60),
MAIN_IC_TYPE CHAR(1),
MAIN_IC_NO CHAR(48),
MAIN_IC_NAME CHAR(64),
MAIN_IC_CHECK_RETURN_CODE CHAR(1),
DEPUTY_IC_TYPE CHAR(1),
DEPUTY_IC_NO CHAR(48),
DEPUTY_NAME CHAR(64),
DEPUTY_IC_CHECK_RETURN_CODE CHAR(1),
ACCOUNT_PROPERTY CHAR(4),
CHEQUE_NO CHAR(20),
COD_EXT_TASK CHAR(10),
COD_MODULE CHAR(4),
ACC_PURPOSE_CODE VARCHAR2(15),
NATIONALITY CHAR(3),
CUSTOMER_NAME CHAR(192),
COD_INCOME_EXPENSE CHAR(6),
COD_EXT_BRANCH CHAR(6),
COD_ACCT_TITLE CHAR(192),
FLG_CA_TT CHAR(1),
DAT_EXT_LOCAL DATE,
ACCT_OWNER_VALID_RESULT CHAR(1),
FLG_DR_CR CHAR(1),
FLG_ONLINE_UPLOAD CHAR(1),
FLG_STMT_DISPLAY CHAR(1),
COD_TXN_TYPE NUMBER(1),
DAT_TS_TXN TIMESTAMP(6),
LC_BG_GUARANTEE_NO VARCHAR2(20),
COD_OTHER_ACCT_NO CHAR(22),
COD_MOD_OTHER_ACCT_NO CHAR(4),
COD_CC_BRN_SUB_ACCT NUMBER(5),
COD_CC_BRN_OTHR_ACCT NUMBER(5),
COD_ENTITY_VPD NUMBER(5) default NVL(sys_context('CLIENTCONTEXT','entity_code'),11),
COD_EXT_TASK_REV VARCHAR2(10)
partition by hash (REF_TXN_NO)
PARTITIONS 128
store in (FCHDATA1,FCHDATA2,FCHDATA3,FCHDATA4, FCHDATA5, FCHDATA6, FCHDATA7, FCHDATA8);
insert /*+APPEND NOLOGGING */ into XFACE_ADDL_DETAILS_TXNLOG
select /*+PARALLEL */ * from XFACE_ADDLDTS_TXNLOG_PTPART;
-- Add comments to the table
comment on table XFACE_ADDL_DETAILS_TXNLOG
is ' Additional Data log table ';
-- Add comments to the columns
comment on column XFACE_ADDL_DETAILS_TXNLOG.REF_TXN_NO
is 'Transaction Reference Number';
comment on column XFACE_ADDL_DETAILS_TXNLOG.REF_USR_NO
is 'User Reference Number';
comment on column XFACE_ADDL_DETAILS_TXNLOG.REF_KEY_NO
is 'Unique key to identify a leg of the transaction';
comment on column XFACE_ADDL_DETAILS_TXNLOG.REF_TXN_NO_ORG
is 'Original Transaction Reference Number';
comment on column XFACE_ADDL_DETAILS_TXNLOG.REF_USR_NO_ORG
is 'Original Transaction User Reference Number';
comment on column XFACE_ADDL_DETAILS_TXNLOG.RECON_CODE
is 'Reconciliation of transactions in future';
comment on column XFACE_ADDL_DETAILS_TXNLOG.COD_TASK_DERIVED
is 'Transaction mnemonic for the request';
comment on column XFACE_ADDL_DETAILS_TXNLOG.COD_CHNL_ID
is 'Channel ID';
comment on column XFACE_ADDL_DETAILS_TXNLOG.COD_SERVICE_ID
is 'Service ID';
comment on column XFACE_ADDL_DETAILS_TXNLOG.COD_USER_ID
is 'User ID';
comment on column XFACE_ADDL_DETAILS_TXNLOG.COD_AUTH_ID
is 'Authorizer ID';
comment on column XFACE_ADDL_DETAILS_TXNLOG.COD_ACCT_NO
is 'It can be Card number or MCA or GL or CASH GL';
comment on column XFACE_ADDL_DETAILS_TXNLOG.TYP_ACCT_NO
is 'Type of input (Valid values CARD, MCA, GL, CASH, LN)';
comment on column XFACE_ADDL_DETAILS_TXNLOG.COD_SUB_ACCT_NO
is 'MC Sub Account Number';
comment on column XFACE_ADDL_DETAILS_TXNLOG.COD_DEP_NO
is 'Deposit Number';
comment on column XFACE_ADDL_DETAILS_TXNLOG.AMOUNT
is 'Transaction Amount';
comment on column XFACE_ADDL_DETAILS_TXNLOG.COD_CCY
is 'Currency Code';
comment on column XFACE_ADDL_DETAILS_TXNLOG.DAT_POST
is 'Posting Date of the transaction';
comment on column XFACE_ADDL_DETAILS_TXNLOG.DAT_VALUE
is 'Value Date of the transaction';
comment on column XFACE_ADDL_DETAILS_TXNLOG.TXT_TXN_NARRATIVE
is 'Text Transaction Narrative';
comment on column XFACE_ADDL_DETAILS_TXNLOG.DATE_CHEQUE_ISSUE
is 'Date of Issue of Cheque';
comment on column XFACE_ADDL_DETAILS_TXNLOG.TXN_BUSINESS_TYPE
is 'Transaction Business Type';
comment on column XFACE_ADDL_DETAILS_TXNLOG.CARD_NO
is 'Card Number';
comment on column XFACE_ADDL_DETAILS_TXNLOG.INVENTORY_CODE
is 'Inventory Code';
comment on column XFACE_ADDL_DETAILS_TXNLOG.INVENTORY_NO
is 'Inventory Number';
comment on column XFACE_ADDL_DETAILS_TXNLOG.CARD_PASSBOOK_NO
is 'Card Passbook Number';
comment on column XFACE_ADDL_DETAILS_TXNLOG.COD_CASH_ANALYSIS
is 'Cash Analysis Code';
comment on column XFACE_ADDL_DETAILS_TXNLOG.BANK_INFORMATION_NO
is 'Bank Information Number';
comment on column XFACE_ADDL_DETAILS_TXNLOG.BATCH_NO
is 'Batch Number';
comment on column XFACE_ADDL_DETAILS_TXNLOG.SUMMARY
is 'Summary';
comment on column XFACE_ADDL_DETAILS_TXNLOG.MAIN_IC_TYPE
is 'IC Type';
comment on column XFACE_ADDL_DETAILS_TXNLOG.MAIN_IC_NO
is 'IC Number';
comment on column XFACE_ADDL_DETAILS_TXNLOG.MAIN_IC_NAME
is 'IC Name';
comment on column XFACE_ADDL_DETAILS_TXNLOG.MAIN_IC_CHECK_RETURN_CODE
is 'IC Check Return Code';
comment on column XFACE_ADDL_DETAILS_TXNLOG.DEPUTY_IC_TYPE
is 'Deputy IC Type';
comment on column XFACE_ADDL_DETAILS_TXNLOG.DEPUTY_IC_NO
is 'Deputy IC Number';
comment on column XFACE_ADDL_DETAILS_TXNLOG.DEPUTY_NAME
is 'Deputy Name';
comment on column XFACE_ADDL_DETAILS_TXNLOG.DEPUTY_IC_CHECK_RETURN_CODE
is 'Deputy IC Check Return Code';
comment on column XFACE_ADDL_DETAILS_TXNLOG.ACCOUNT_PROPERTY
is 'Account Property';
comment on column XFACE_ADDL_DETAILS_TXNLOG.CHEQUE_NO
is 'Cheque Number';
comment on column XFACE_ADDL_DETAILS_TXNLOG.COD_EXT_TASK
is 'External Task Code';
comment on column XFACE_ADDL_DETAILS_TXNLOG.COD_MODULE
is 'Module Code - CH, TD, RD , LN, CASH, GL';
comment on column XFACE_ADDL_DETAILS_TXNLOG.ACC_PURPOSE_CODE
is 'Account Purpose Code';
comment on column XFACE_ADDL_DETAILS_TXNLOG.NATIONALITY
is 'Nationality';
comment on column XFACE_ADDL_DETAILS_TXNLOG.CUSTOMER_NAME
is 'Customer Name';
comment on column XFACE_ADDL_DETAILS_TXNLOG.COD_INCOME_EXPENSE
is 'Income Expense Code';
comment on column XFACE_ADDL_DETAILS_TXNLOG.COD_EXT_BRANCH
is 'External Branch Code';
comment on column XFACE_ADDL_DETAILS_TXNLOG.COD_ACCT_TITLE
is 'Account Title Code';
comment on column XFACE_ADDL_DETAILS_TXNLOG.FLG_CA_TT
is 'Cash or Funds Transfer flag';
comment on column XFACE_ADDL_DETAILS_TXNLOG.DAT_EXT_LOCAL
is 'Local Date';
comment on column XFACE_ADDL_DETAILS_TXNLOG.ACCT_OWNER_VALID_RESULT
is 'Account Owner Valid Result';
comment on column XFACE_ADDL_DETAILS_TXNLOG.FLG_DR_CR
is 'Flag Debit Credit - D, C.';
comment on column XFACE_ADDL_DETAILS_TXNLOG.FLG_ONLINE_UPLOAD
is 'Flag Online Upload - O, U.';
comment on column XFACE_ADDL_DETAILS_TXNLOG.FLG_STMT_DISPLAY
is 'Statement Display Flag - Y/N, Y(Normal Reversal), N(Correction Reversal)';
comment on column XFACE_ADDL_DETAILS_TXNLOG.COD_TXN_TYPE
is 'To denote the kind of transaction:
1 ?Cash Credit Transaction
2 ?Cash Debit Transaction
3 ?Funds Transfer Credit Transaction
4 ?Funds Transfer Debit Transaction
comment on column XFACE_ADDL_DETAILS_TXNLOG.DAT_TS_TXN
is 'Date and Timestamp of the record being inserted';
comment on column XFACE_ADDL_DETAILS_TXNLOG.LC_BG_GUARANTEE_NO
is 'LC/BG Guarantee Number for which the request for the Liquidation has been initiated.';
comment on column XFACE_ADDL_DETAILS_TXNLOG.COD_OTHER_ACCT_NO
is 'Other Account No';
comment on column XFACE_ADDL_DETAILS_TXNLOG.COD_MOD_OTHER_ACCT_NO
is 'Module Code of Other Account No - CH, TD, RD , LN, CASH, GL';
comment on column XFACE_ADDL_DETAILS_TXNLOG.COD_CC_BRN_SUB_ACCT
is 'Branch Code for Sub Account';
comment on column XFACE_ADDL_DETAILS_TXNLOG.COD_CC_BRN_OTHR_ACCT
is 'Branch Code for Other Account';
-- Create/Recreate indexes
drop index IN_XFACE_ADDL_DETAILS_TXNLOG_1;
drop index IN_XFACE_ADDL_DETAILS_TXNLOG_2;
drop index IN_XFACE_ADDL_DETAILS_TXNLOG_3;
drop index IN_XFACE_ADDL_DETAILS_TXNLOG_4;
drop index IN_XFACE_ADDL_DETAILS_TXNLOG_5;
drop index IN_XFACE_ADDL_DETAILS_TXNLOG_6;
drop index IN_XFACE_ADDL_DETAILS_TXNLOG_7;
drop index IN_XFACE_ADDL_DETAILS_TXNLOG_8;
create index IN_XFACE_ADDL_DETAILS_TXNLOG_1 on XFACE_ADDL_DETAILS_TXNLOG (REF_TXN_NO, REF_KEY_NO, COD_SUB_ACCT_NO, COD_ENTITY_VPD)
GLOBAL PARTITION BY HASH (REF_TXN_NO, REF_KEY_NO, COD_SUB_ACCT_NO) PARTITIONS 128 STORE IN (FCHINDX1, FCHINDX2, FCHINDX3, FCHINDX4) PARALLEL (DEGREE 32) NOLOGGING;
create index IN_XFACE_ADDL_DETAILS_TXNLOG_2 on XFACE_ADDL_DETAILS_TXNLOG (REF_USR_NO, REF_KEY_NO, COD_SUB_ACCT_NO, COD_ENTITY_VPD)
GLOBAL PARTITION BY HASH(REF_USR_NO, REF_KEY_NO, COD_SUB_ACCT_NO) PARTITIONS 128 STORE IN (FCHINDX1, FCHINDX2, FCHINDX3, FCHINDX4) PARALLEL (DEGREE 32) NOLOGGING;
create index IN_XFACE_ADDL_DETAILS_TXNLOG_3 on XFACE_ADDL_DETAILS_TXNLOG (COD_SUB_ACCT_NO, FLG_STMT_DISPLAY,DAT_POST COD_ENTITY_VPD)
GLOBAL PARTITION BY HASH(COD_SUB_ACCT_NO, FLG_STMT_DISPLAY) PARTITIONS 128 STORE IN (FCHINDX1, FCHINDX2, FCHINDX3, FCHINDX4) PARALLEL (DEGREE 32) NOLOGGING;
create index IN_XFACE_ADDL_DETAILS_TXNLOG_4 on
XFACE_ADDL_DETAILS_TXNLOG (COD_ACCT_NO, REF_TXN_NO, COD_TXN_TYPE, COD_USER_ID, COD_EXT_BRANCH, COD_ENTITY_VPD)
GLOBAL PARTITION BY HASH(COD_ACCT_NO, REF_TXN_NO, COD_TXN_TYPE, COD_USER_ID, COD_EXT_BRANCH)
PARTITIONS 128 STORE IN (FCHINDX1, FCHINDX2, FCHINDX3, FCHINDX4) PARALLEL (DEGREE 32) NOLOGGING;
create index IN_XFACE_ADDL_DETAILS_TXNLOG_5 on XFACE_ADDL_DETAILS_TXNLOG (COD_USER_ID, DAT_POST, COD_ENTITY_VPD)
GLOBAL PARTITION BY HASH(COD_USER_ID) PARTITIONS 128 STORE IN (FCHINDX1, FCHINDX2, FCHINDX3, FCHINDX4) PARALLEL (DEGREE 32) NOLOGGING;
create index IN_XFACE_ADDL_DETAILS_TXNLOG_6 on XFACE_ADDL_DETAILS_TXNLOG (REF_TXN_NO_ORG, COD_ENTITY_VPD)
GLOBAL PARTITION BY HASH(REF_TXN_NO_ORG) PARTITIONS 128 STORE IN (FCHINDX1, FCHINDX2, FCHINDX3, FCHINDX4) PARALLEL (DEGREE 32) NOLOGGING;
create index IN_XFACE_ADDL_DETAILS_TXNLOG_7 on XFACE_ADDL_DETAILS_TXNLOG (DAT_EXT_LOCAL, DAT_POST,TXN_BUSINESS_TYPE, FLG_ONLINE_UPLOAD, COD_CHNL_ID, REF_TXN_NO, COD_ENTITY_VPD)
GLOBAL PARTITION BY HASH(DAT_EXT_LOCAL) PARTITIONS 128 STORE IN (FCHINDX1, FCHINDX2, FCHINDX3, FCHINDX4) PARALLEL (DEGREE 32) NOLOGGING;
/* Previous Key order: (COD_EXT_BRANCH,DAT_POST,REF_TXN_NO_ORG,COD_SERVICE_ID,COD_ENTITY_VPD) */
create index IN_XFACE_ADDL_DETAILS_TXNLOG_8 on XFACE_ADDL_DETAILS_TXNLOG (DAT_POST, COD_EXT_BRANCH, REF_TXN_NO_ORG, COD_SERVICE_ID, COD_ENTITY_VPD)
GLOBAL PARTITION BY HASH(DAT_POST) PARTITIONS 128 STORE IN (FCHINDX1, FCHINDX2, FCHINDX3, FCHINDX4) PARALLEL (DEGREE 32) NOLOGGING;
ALTER TABLE XFACE_ADDL_DETAILS_TXNLOG NOPARALLEL PCTFREE 50 INITRANS 128 LOGGING;
ALTER index IN_XFACE_ADDL_DETAILS_TXNLOG_1 NOPARALLEL INITRANS 128;
ALTER index IN_XFACE_ADDL_DETAILS_TXNLOG_2 NOPARALLEL INITRANS 128;
ALTER index IN_XFACE_ADDL_DETAILS_TXNLOG_3 NOPARALLEL INITRANS 128;
ALTER index IN_XFACE_ADDL_DETAILS_TXNLOG_4 NOPARALLEL INITRANS 128;
ALTER index IN_XFACE_ADDL_DETAILS_TXNLOG_5 NOPARALLEL INITRANS 128;
ALTER index IN_XFACE_ADDL_DETAILS_TXNLOG_6 NOPARALLEL INITRANS 128;
ALTER index IN_XFACE_ADDL_DETAILS_TXNLOG_7 NOPARALLEL INITRANS 128;
ALTER index IN_XFACE_ADDL_DETAILS_TXNLOG_8 NOPARALLEL INITRANS 128;
BEGIN
DBMS_RLS.ADD_POLICY(OBJECT_SCHEMA => UPPER('FCR44HOST'),
OBJECT_NAME => UPPER('XFACE_ADDL_DETAILS_TXNLOG '),
POLICY_NAME => 'FC_ENTITY_POLICY',
FUNCTION_SCHEMA => UPPER('FCR44HOST'),
POLICY_FUNCTION => 'pk_cm_vpd_policy.get_entity_predicate',
STATEMENT_TYPES => 'select,insert,update,delete',
UPDATE_CHECK => TRUE,
ENABLE => TRUE,
STATIC_POLICY => FALSE,
POLICY_TYPE => DBMS_RLS.SHARED_STATIC,
LONG_PREDICATE => FALSE,
SEC_RELEVANT_COLS => NULL,
SEC_RELEVANT_COLS_OPT => NULL);
END;
begin
dbms_stats.gather_table_stats(ownname => 'FCR44HOST',tabname => 'XFACE_ADDL_DETAILS_TXNLOG', cascade=>true,method_opt=>'for all columns size 1',degree => 32, GRANULARITY => 'PARTITION');
end;
Query which takes time.
INSERT INTO xface_addl_dtls_tlog_temp
(ref_txn_no,
ref_usr_no,
ref_key_no,
ref_txn_no_org,
ref_usr_no_org,
recon_code,
cod_task_derived,
cod_chnl_id,
cod_service_id,
cod_user_id,
cod_auth_id,
cod_acct_no,
typ_acct_no,
cod_sub_acct_no,
cod_dep_no,
amount,
cod_ccy,
dat_post,
dat_value,
txt_txn_narrative,
date_cheque_issue,
txn_business_type,
card_no,
inventory_code,
inventory_no,
card_passbook_no,
cod_cash_analysis,
bank_information_no,
batch_no,
summary,
main_ic_type,
main_ic_no,
main_ic_name,
main_ic_check_return_code,
deputy_ic_type,
deputy_ic_no,
deputy_name,
deputy_ic_check_return_code,
account_property,
cheque_no,
cod_ext_task,
cod_module,
acc_purpose_code,
nationality,
customer_name,
cod_income_expense,
cod_ext_branch,
cod_acct_title,
flg_ca_tt,
dat_ext_local,
acct_owner_valid_result,
flg_dr_cr,
flg_online_upload,
flg_stmt_display,
cod_txn_type,
dat_ts_txn,
lc_bg_guarantee_no,
cod_other_acct_no,
cod_mod_other_acct_no,
cod_cc_brn_sub_acct,
cod_cc_brn_othr_acct,
cod_ext_task_rev,
sessionid)
SELECT ref_txn_no,
ref_usr_no,
ref_key_no,
ref_txn_no_org,
ref_usr_no_org,
recon_code,
cod_task_derived,
cod_chnl_id,
cod_service_id,
cod_user_id,
cod_auth_id,
cod_acct_no,
typ_acct_no,
cod_sub_acct_no,
cod_dep_no,
amount,
cod_ccy,
dat_post,
dat_value,
txt_txn_narrative,
date_cheque_issue,
txn_business_type,
card_no,
inventory_code,
inventory_no,
card_passbook_no,
cod_cash_analysis,
bank_information_no,
batch_no,
summary,
main_ic_type,
main_ic_no,
main_ic_name,
main_ic_check_return_code,
deputy_ic_type,
deputy_ic_no,
deputy_name,
deputy_ic_check_return_code,
account_property,
cheque_no,
cod_ext_task,
cod_module,
acc_purpose_code,
nationality,
customer_name,
cod_income_expense,
cod_ext_branch,
cod_acct_title,
flg_ca_tt,
dat_ext_local,
acct_owner_valid_result,
flg_dr_cr,
flg_online_upload,
flg_stmt_display,
cod_txn_type,
dat_ts_txn,
lc_bg_guarantee_no,
cod_other_acct_no,
cod_mod_other_acct_no,
cod_cc_brn_sub_acct,
cod_cc_brn_othr_acct,
cod_ext_task_rev,
var_l_sessionid
FROM xface_addl_details_txnlog
WHERE cod_sub_acct_no = var_pi_cod_acct_no
AND dat_post between var_pi_start_dat AND var_pi_end_dat;
Index referred is in_xface_addl_details_txnlog_3.
First time when i execute the query it takes huge time. but subsequent queries are faster. This is only if i pass same account and criteria again.
Observed that first time it goes for physical reads which takes time. and subsequent runs physical reads are less.....
Request suggestions.....this is account statement inquiry user may have 10000txns in a day as well
Bymistake earlier i raised this in "Oracle -> Text"
Slow inserts due to physical reads every time for fresh account i am passin
They suggested to use bind variable. But as i know, we are already using bind variables to bind account number and start and end date.

My Replies below.
Whenever you post provide your 4 digit Oracle version (SELECT * FROM V$VERSION).
Ans :
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
"CORE     11.2.0.3.0     Production"
TNS for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
1. If your question is about the INSERT query into xface_addl_dtls_tlog_temp why didn't you post any information about the DDL for that table? Is it the same structure as the table you did post DDL for?
Ans :
-- Create table
create global temporary table XFACE_ADDL_DTLS_TLOG_TEMP
REF_TXN_NO CHAR(40) not null,
REF_USR_NO CHAR(40) not null,
REF_KEY_NO VARCHAR2(50),
REF_TXN_NO_ORG CHAR(40),
REF_USR_NO_ORG CHAR(40),
RECON_CODE VARCHAR2(25),
COD_TASK_DERIVED VARCHAR2(5),
COD_CHNL_ID VARCHAR2(6),
COD_SERVICE_ID VARCHAR2(10),
COD_USER_ID VARCHAR2(30),
COD_AUTH_ID VARCHAR2(30),
COD_ACCT_NO CHAR(22),
TYP_ACCT_NO VARCHAR2(4),
COD_SUB_ACCT_NO CHAR(16),
COD_DEP_NO NUMBER(5),
AMOUNT NUMBER(15,2),
COD_CCY VARCHAR2(3),
DAT_POST DATE,
DAT_VALUE DATE,
TXT_TXN_NARRATIVE VARCHAR2(60),
DATE_CHEQUE_ISSUE DATE,
TXN_BUSINESS_TYPE VARCHAR2(10),
CARD_NO CHAR(20),
INVENTORY_CODE CHAR(10),
INVENTORY_NO CHAR(20),
CARD_PASSBOOK_NO CHAR(30),
COD_CASH_ANALYSIS CHAR(20),
BANK_INFORMATION_NO CHAR(8),
BATCH_NO CHAR(10),
SUMMARY VARCHAR2(60),
MAIN_IC_TYPE CHAR(1),
MAIN_IC_NO VARCHAR2(150),
MAIN_IC_NAME VARCHAR2(192),
MAIN_IC_CHECK_RETURN_CODE CHAR(1),
DEPUTY_IC_TYPE CHAR(1),
DEPUTY_IC_NO VARCHAR2(150),
DEPUTY_NAME VARCHAR2(192),
DEPUTY_IC_CHECK_RETURN_CODE CHAR(1),
ACCOUNT_PROPERTY CHAR(4),
CHEQUE_NO CHAR(20),
COD_EXT_TASK CHAR(10),
COD_MODULE CHAR(4),
ACC_PURPOSE_CODE VARCHAR2(15),
NATIONALITY CHAR(3),
CUSTOMER_NAME CHAR(192),
COD_INCOME_EXPENSE CHAR(6),
COD_EXT_BRANCH CHAR(6),
COD_ACCT_TITLE VARCHAR2(360),
FLG_CA_TT CHAR(1),
DAT_EXT_LOCAL DATE,
ACCT_OWNER_VALID_RESULT CHAR(1),
FLG_DR_CR CHAR(1),
FLG_ONLINE_UPLOAD CHAR(1),
FLG_STMT_DISPLAY CHAR(1),
COD_TXN_TYPE NUMBER(1),
DAT_TS_TXN TIMESTAMP(6),
LC_BG_GUARANTEE_NO VARCHAR2(20),
COD_OTHER_ACCT_NO CHAR(22),
COD_MOD_OTHER_ACCT_NO CHAR(4),
COD_CC_BRN_SUB_ACCT NUMBER(5),
COD_CC_BRN_OTHR_ACCT NUMBER(5),
COD_EXT_TASK_REV VARCHAR2(10),
SESSIONID NUMBER default USERENV('SESSIONID') not null
on commit delete rows;
-- Create/Recreate indexes
create index IN_XFACE_ADDL_DTLS_TLOG_TEMP on XFACE_ADDL_DTLS_TLOG_TEMP (COD_SUB_ACCT_NO, REF_TXN_NO, COD_SERVICE_ID, REF_KEY_NO, SESSIONID);
2. Why doesn't your INSERT query use APPEND, NOLOGGING and PARALLEL like the first query you posted? If those help for the first query why didn't you try them for the query you are now having problems with?
Ans :
I will try to use append but i cannot use parallel since i have hardware limitations.
3. What does this mean: 'Index referred is in_xface_addl_details_txnlog_3.'? You haven't posted any plan that refers to any index. Do you have an execution plan? Why didn't you post it?
Ans :
Plan hash value: 4081844790
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | INSERT STATEMENT | | | | 5 (100)| | | |
| 1 | LOAD TABLE CONVENTIONAL | | | | | | | |
| 2 | FILTER | | | | | | | |
| 3 | PARTITION HASH ALL | | 1 | 494 | 5 (0)| 00:00:01 | 1 | 128 |
| 4 | TABLE ACCESS BY GLOBAL INDEX ROWID| XFACE_ADDL_DETAILS_TXNLOG | 1 | 494 | 5 (0)| 00:00:01 | ROWID | ROWID |
| 5 | INDEX RANGE SCAN | IN_XFACE_ADDL_DETAILS_TXNLOG_3 | 1 | | 3 (0)| 00:00:01 | 1 | 128 |
4. Why are you defining 37 columns as CHAR datatypes? Are you aware that CHAR data REQUIRES the use of the designated number of BYTES/CHARACTERS?
Ans :
I understand and appreciate your points, but since it is huge application and is built over a period of time. I am afraid if i will be allowed to do change on datatypes. there are lot of queries over this table.
5. Are you aware that #4 means those 37 columns columns, even if all of them are NULL, mean that your MINIMUM record length is 1012? Care to guess how many of those records Oracle can fit into an 8k block? And that is if you ignore the other 26 VARCHAR2, NUMBER and DATE columns.
Two of your columns take 192 bytes MINIMUM even if they are null
CUSTOMER_NAME CHAR(192),
COD_ACCT_TITLE CHAR(192)
Why are you wasting all of that space? If you are using a multi-byte character set and your data is multi-byte those 37 columns are using even more space because some characters will use more than one byte.
If the name and title average 30 characters/bytes then those two columns alone use 300+ unused bytes. With 40 million records those unused bytes, just for those two columns take 12 GB of space.
WIth a block size of 8k that would totally waste 1.5 million blocks that Oracle has to read just to ignore the empty space that isn't being used.
I highly suspect that your use of CHAR is a large part of this performance problem and probably other performance problems in your system. Not only for this table but for any other table that uses similar CHAR datatypes and wastes space.
Please reconsider your use of CHAR datatypes like this. I can't imagine what justification you have for using them.
Ans :
I understand your points, but since it is huge application is built over a period of time. I am afraid if i will be allowed to do change on datatypes.
I have to manage in current situation. Not expecting query to respond in millisecs but not even 40secs which is happening currently.
Edited by: Rohit Jadhav on Dec 30, 2012 6:44 PM

Similar Messages

  • SQL query very slow on Data warehouse

    Guys,
    Is there any soul who is an expert on SQL ? I do run this query agaist a 2 table and a view which has 30 million rows. Unfortunately the table is partitioned but not the Unique index.
    This query takes about 3 hours to run. Is there anyway of writing this in a better way ??
    select
    a.xcm_consumer_pk,
    b.p_vin_prtn_c,
    b.vin_type_c,
    b.vin_id_c,
    b.cveh_owner_cycle_r,
    b.veh_reg_no_c,
    b.veh_make_c,
    b.veh_model_c,
    b.veh_deriv_c,
    b.veh_reg_y,
    b.cveh_link_start_y,
    b.cveh_prd_rpl_y,
    b.cveh_sl_dlr_c,
    c.cu26_address_x
    from
    xcm_cu01_customer a, xcm_cv01_cons_veh b,
    xcm_view_cons_latest_e_mail c
    where
    a.country_iso3_c = 'GBR'
    and (a.cust_brand_c in ('F','Y'))
    and a.xcm_consumer_pk = b.xcm_consumer_pk(+)
    and b.cveh_owner_cycle_r(+) = 1
    and b.cveh_link_end_y(+) between SYSDATE and '31-Dec-9999'
    and a.xcm_consumer_pk = c.xcm_consumer_pk(+)
    The definition of the view xcm_view_cons_latest_e_mail is as below.
    SELECT
    A.xcm_consumer_pk,
    A.cu26_type_c,
    A.p_update_s,
    A.cu26_address_x
    FROM XCM_CU26_E_MAIL A
    WHERE TO_CHAR(NVL(A.p_update_s, '01-Jan-0001'), 'YYYYMMDD') || NVL(A.cu26_type_c, ' ') =
         (SELECT MAX(TO_CHAR(NVL(b.p_update_s, '01-Jan-0001'), 'YYYYMMDD') || NVL(b.cu26_type_c, ' '))
         FROM XCM_CU26_E_MAIL b
         WHERE A.xcm_consumer_pk = b.xcm_consumer_pk);
    Most of our query uses the same format and ver 9.2.0.2 has totally screwed up our job times.. Any idea please ??

    In addition to Maurice's questions:
    Are you sure you really need the outer joins?
    From your statement "... and ver 9.2.0.2 has totally screwed up our job times" I assume that you have recently upgraded. So:
    Are you sure that all relevant indexes exist on the new version?
    Have you analyzed all the tables involved since the upgrade?
    Are you sure that the init parameters are set appropriately? Note that depending on what version you upgraded from, you may need to make substantial changes to various parameters to get optimal performance.
    John

  • Query very slow!

    I have Oracle 9i and SUN OS 5.8
    I have a Java application that have a query to the Customer table. This table has 2.000.000 of records and I have to show its in pages (20 record each page)
    The user query for example the Customer that the Last Name begin with “O”. Then the application shows the first 20 records with this condition and order by Name.
    Then I have to create 2 querys
    1)
    SELECT id_customer,Name
    FROM Customers
    WHERE Name like 'O%'
    ORDER BY id_customer
    But when I proved this query in TOAD it take long to do it (the time consuming was 15 minutes)
    I have the index in the NAME field!!
    Besides, if the user want to go to the second page the query is executed again. (The java programmers said me that)
    What is your recommendation to optimize it????? I need to obtain the information in
    few seconds.
    2)
    SELECT count(*) FROM Customers WHERE NAME like 'O%'
    I have to do this query because I need to known How many pages (20 records) I need to show.
    Example with 5000 records I have to have 250 pages.
    But when I proved this query in TOAD it take long to do it (the time consuming was 30 seconds)
    What is your recommendation to optimize it????? I need to obtain the information in
    few seconds.
    Thanks in advance!

    This appears to be a dulpicate of a post in the Query very slow! forum.
    Claudio, since the same folks tend to read both forums, it is generally preferred that you post questions in only one forum. That way, multiple people don't spend time writing generally equivalent replies.
    Justin
    Distributed Database Consulting, Inc.
    http://www.ddbcinc.com/askDDBC

  • Oracle interview questions;; query very slow

    Hai
    Most of time in interview they ask..
    WHAT IS THE STEPS U DO WHEN UR QUERY IS RUNNNING VERY SLOW..?
    i used to say
    1) first i will check for whether table is properly indexed or not
    2) next properly normalized or not
    interviewers are not fully satisfied with these answers..
    So kindly tell me more suggestion
    S

    Also when checking the execution plan, get the actual plan using DBMS_XPLAN.DISPLAY_CURSOR, rather than the predicted one (EXPLAIN PLAN FOR). If you use a configurable IDE such as SQL Developer of PL/SQL Developer it is worth taking the time to set this up in the session browser so that you can easily capture it while it's running. You might also look at the estimated vs actual cardinalities. While you're at it you could check v$session_longops, v$session_wait and (if you have the Diagnostic and Tuning packs licenced) v$active_session_history and the various dba_hist% views.
    You might try the SQL Tuning Advisor (DBMS_SQLTUNE) which generates profiles for SQL statements (requires ADVISOR system privilege to run a tuning task, and CREATE ANY SQL PROFILE to apply a profile).
    In 11g look at SQL Monitor.
    Tracing is all very well if you can get access to the tracefile in a reasonable timeframe, though in many sites (including my current one) it's just too much trouble unless you're a DBA.
    Edited by: William Robertson on Apr 18, 2011 11:40 PM
    Sorry Rob, should probably have replied to oraclehema rather than you.

  • Sql query extremely slow in the new linux environment , memory issues?

    We just migrated to a new dev environment in Linux REDHAT5, and now the query is very slow, and I used the TOAD to run the query, it took like 700 msecond to finish, however from any server connection, the sql query takes hours to finish.
    I checked toad monitor, it said need to increase db_buffer_cache and shared pool too small.
    Also three red alert from toad is:
    1. Library Cache get hit ratio: Dynamic or unsharable sql
    2. Chained fetch ratio: PCT free too low for a table
    3. parse to execute ratio: HIgh parse to execute ratio.
    App team said it ran real quick in the old AIX system, however I ran it in old system, and monitored in the toad, it gave me all same 5 red alerts in old system, and it did provide query results a lot quicker though.
    Here is the parameters in the old system (11gr1 on AIX):
    SQL> show parameter target
    NAME TYPE VALUE
    archive_lag_target integer 0
    db_flashback_retention_target integer 1440
    fast_start_io_target integer 0
    fast_start_mttr_target integer 0
    memory_max_target big integer 0
    memory_target big integer 0
    pga_aggregate_target big integer 278928K
    sga_target big integer 0
    SQL> show parameter shared
    NAME TYPE VALUE
    hi_shared_memory_address integer 0
    max_shared_servers integer
    shared_memory_address integer 0
    shared_pool_reserved_size big integer 31876710
    shared_pool_size big integer 608M
    shared_server_sessions integer
    shared_servers integer 0
    SQL> show parameter db_buffer
    SQL> show parameter buffer
    NAME TYPE VALUE
    buffer_pool_keep string
    buffer_pool_recycle string
    db_block_buffers integer 0
    log_buffer integer 2048000
    use_indirect_data_buffers boolean FALSE
    SQL>
    In new 11gr2 Linux REDHAT parameter:
    NAME TYPE VALUE
    archive_lag_target integer 0
    db_flashback_retention_target integer 1440
    fast_start_io_target integer 0
    fast_start_mttr_target integer 0
    memory_max_target big integer 2512M
    memory_target big integer 2512M
    parallel_servers_target integer 192
    pga_aggregate_target big integer 0
    sga_target big integer 1648M
    SQL> show parameter shared
    NAME TYPE VALUE
    hi_shared_memory_address integer 0
    max_shared_servers integer
    shared_memory_address integer 0
    shared_pool_reserved_size big integer 28M
    shared_pool_size big integer 0
    shared_server_sessions integer
    shared_servers integer 1
    SQL> show parameter buffer
    NAME TYPE VALUE
    buffer_pool_keep string
    buffer_pool_recycle string
    db_block_buffers integer 0
    log_buffer integer 18857984
    use_indirect_data_buffers boolean FALSE
    SQL>
    Please help. Thanks in advance.

    Duplicate question. Originally posted in sql query slow in new redhat enviornment
    Please post in just one forum.

  • SQL Azure very slow

    Hi Experts
    We have SQL Azure database that is running very slow, so i took a backup of the database and restored on my on premise sql server express edition. 
    I tried a update statement on a logs tables that have approximately about 1,062,367 records.
    UPDATE logs set FileId = NULL
    where LEN(FileId) < 36
    The above update statement updates about 910,593 records on localhost host in 20 sec and if i run the same updates statement on SQL Azure it took 40mins and 16sec. The update statement was issues using SQL Server management studio installed on my local machine.
    With reference to internet connection, we have fiber connection with download speed of 70.62mbps and upload speed of 84.09mbps 
    I am not sure whats going wrong with SQL Azure database i.e. could there be a specific fault on my database at Microsoft side etc.
    Any advice or suggestion will be highly appreciated.
    Kind Regards
    Bhavesh
    Bhavesh

    I have waited for 40 min for the update to complete and it has successfully and updated logs table so i can't re-run the update statement again because there will be no records to update.
    I have managed to find another example that took about 10 mins to complete on the SSMS but when ran the same query on the azure management portal it took only 6 secs which puzzled me. 
    Here is the query: 
    select   
     l.Value3 as ClientReference,
     l.[Key] as ActivityUser,
     l.Value2 as FormDisplayName,
     l.Value6 as Status,
     l.DateStamp as LastUpdated,
     l.[Action] as FileDescription,
     l.CompanyId as ClientID,
     l.FileId as FileID,
     f.id
    from Logs l
    LEFT OUTER JOIN files f on f.Id = l.FileId 
    where l.AccountId = 578
    and type = 1
    The above query returns about 3694 records only.
    Here is the details of the query performance 
    Azure Management Portal
    Duration(ms): 6487
    CPU(ms): 2443
    Logical Reads: 74729
    Physical Reads: 66147
    Logical Writes: 0
    SSMS
    Duration(ms): 615259
    CPU(ms): 3666
    Logical Reads: 74729
    Physical Reads: 71370
    Logical Writes: 0
    Any update will be appreciated.
    Bhavesh

  • SPATIAL QUERY VERY SLOW

    I CAN TO EXECUTE THIS QUERY BUT IT IS VERY SLOW, I HAVE 2 TABLE , ONE A WITH 250.000 SITE AND B WITH 250.000 POINTS, I WANT TO DETERMINING HOW MANY RISK INSIDE THE SITES.
    THANKS
    JGS
    SELECT B.ID, A.ID, A.GC, A.SUMA
    FROM DBG_RIESGOS_CUMULOS_SITE A, DBG_RIESGOS_CUMULOS B
    WHERE A.GC = 'PATRIMONIAL FENOMENOS SISMICOS' AND A.GC=B.GC
    AND SDO_RELATE(B.GEOMETRY, A.GEOMETRY, 'MASK=INSIDE') = 'TRUE';
    100 RECORS IN 220 '' SLOWWWWW

    I would do two things:
    1) Ensure Oracle is patched with the latest 10.2.0.4 patches
    This is the list I've been working with:
    Patch 7003151
    Patch 6989483
    Patch 7237687
    Patch 7276032
    Patch 7307918
    2) Write the query like this
    SELECT /*+ ORDERED*/ B.ID, A.ID, A.GC, A.SUMA
    FROM DBG_RIESGOS_CUMULOS B, DBG_RIESGOS_CUMULOS_SITE A
    WHERE B.GC = 'PATRIMONIAL FENOMENOS SISMICOS'
    AND A.GC=B.GC
    AND SDO_ANYINTERACT(A.GEOMETRY, B.GEOMETRY) = 'TRUE';

  • User Defined Type - Array bind Query very slow

    Hi.
    I have following Problem. I try to use Oracle Instant Client 11 and ODP.NET to pass Arrays in SELECT statements as Bind Parameters. I did it, but it runs very-very slow. Example:
    - Inittial Query:
    SELECT tbl1.field1, tbl1.field2, tbl2.field1, tbl2.field2 ... FROM tbl1
    LEFT JOIN tbl2 ON tbl1.field11=tbl2.field0
    LEFT JOIN tbl3 ON tbl2.field11=tbl3.field0 AND tbll1.field5=tbl3.field1
    ...and another LEFT JOINS
    WHERE
    tbl1.field0 IN ('id01', 'id02', 'id03'...)
    this query with 100 elements in "IN" on my database takes 3 seconds.
    - Query with Array bind:
    in Oracle I did UDT: create or replace type myschema.mytype as table of varchar2(1000)
    than, as described in Oracle Example I did few classes (Factory and implementing IOracleCustomType) and use it in Query,
    instead of IN ('id01', 'id02', 'id03'...) I have tbl1.field0 IN (select column_value from table(:prmTable)), and :prmTable is bound array.
    this query takes 190 seconds!!! Why? I works, but the HDD of Oracle server works very hard, and it takes too long.
    Oracle server we habe 10g.
    PS: I tried to use only 5 elements in array - the same result, it takes also 190 seconds...
    Please help!

    I recommend you generate an explain plan for each query and post them here. Based on what you have given the following MAY be happening:
    Your first query has as static IN list when it is submitted to the server. Therefore when Oracle generates the execution plan the CBO can accurately determine it based on a KNOWN set of input parameters. However the second query has a bind variable for this list of parameters and Oracle has no way of knowing at the time the execution plan is generated what that list contains. If it does not know what the list contains it cannot generate the most optimal execution plan. Therefore I would guess that it is probably doing some sort of full table scan (although these aren't always bad, remember that!).
    Again please post the execution plans for each.
    HTH!

  • 10g Form - first execute query - very slow

    I have the following issue:
    Enter an application
    open a form in enter query mode
    first time execute query is very slow (several minutes)
    every other time it's quick (couple seconds or less)
    I can leave the form, use other forms within the app, come back and query is still quick. It's only the first time after initially launching the app.
    Any ideas what might be causing this?

    We have the same application running in 6i client/server DB-9i in production. We are testing the upgraded application that is 10g forms on OAS DB-10g. We don't have the issue in the current production client/server app.

  • Sql query runing slow with lower cost

    Hello
    I am working on Oracle 11g and AIX.I have one sql query which is ruing slow as reported by user.
    When i am commenting few line of code it is runing fast.
    I noticed that the execution plan cost of first query is less and second ...as cost of sccond qurey is more.But users are say it is runing fast.
    How it can possiable ?
    Any idea why second query is runing fast after commenting few columns in select and group by clause.
    Query 1
    SELECT PH.CTRL_NBR, PD.SEQ_NBR,PH.CNTRY,PH.SHIP_DATE, PHI.WAVE_NBR, PD.ID, PD.QTY,
    IM.PACK_QTY,
    IM.UNIT_VOL,
    IM.PACK_QTY,
    MAX(CD.PACK_QTY) AS CASE_QTY,
    IM.UNIT_WT
    FROM HDR PH,
    HDR_INTRNL PHI,
    DTL PD,
    HDR CH,
    CASEDTL CD,
    IMASTER IM
    WHERE PH.CTRL_NBR = PHI.CTRL_NBR
    AND PD.CTRL_NBR = PH.CTRL_NBR
    AND PD.QTY > 0
    AND SUBSTR(CD.ID, 1, 9) = SUBSTR(PD.ID, 1, 9)
    AND CD.CASENBR = CH.CASENBR
    AND CH.STAT_CODE BETWEEN '10' AND '90'
    AND IM.ID = PD.ID
    AND PHI.WAVE_NBR='EL57893'
    GROUP BY PH.CTRL_NBR, PD.SEQ_NBR, PH.CNTRY, PH.SHIP_DATE, PHI.WAVE_NBR, PD.ID, PD.QTY,
    IM.PACK_QTY,
    IM.UNITVOL,
    IM.UNITWT,
    IM.PACK_QTY
    Query 2 .
    SELECT PH.CTRL_NBR,
    PD.SEQ_NBR,
    PH.CNTRY,
    PH.SHIP_DATE,
    PHI.WAVE_NBR,
    PD.ID,
    PD.QTY,
    -- IM.PACK_QTY,
    -- IM.UNIT_VOL,
    -- IM.PACK_QTY,
    MAX(CD.PACK_QTY) AS CASE_QTY,
    -- IM.UNIT_WT
    FROM HDR PH,
    HDR_INTRNL PHI,
    DTL PD,
    HDR CH,
    CASEDTL CD,
    IMASTER IM
    WHERE PH.CTRL_NBR = PHI.CTRL_NBR
    AND PD.CTRL_NBR = PH.CTRL_NBR
    AND PD.QTY > 0
    AND SUBSTR(CD.ID, 1, 9) = SUBSTR(PD.ID, 1, 9)
    AND CD.CASENBR = CH.CASENBR
    AND CH.STAT_CODE BETWEEN '10' AND '90'
    AND IM.ID = PD.ID
    AND PHI.WAVE_NBR='EL57893'
    GROUP BY PH.CTRL_NBR, PD.SEQ_NBR, PH.CNTRY, PH.SHIP_DATE, PHI.WAVE_NBR, PD.ID, PD.QTY,
    --IM.PACK_QTY,
    --IM.UNITVOL,
    --IM.UNITWT,
    --IM.PACK_QTY
    Edited by: oradba11 on Sep 6, 2012 2:11 PM
    Edited by: oradba11 on Sep 6, 2012 2:12 PM

    oradba11 wrote:
    Hello
    I am working on Oracle 11g and AIX.I have one sql query which is ruing slow as reported by user.
    When i am commenting few line of code it is runing fast.
    I noticed that the execution plan cost of first query is less and second ...as cost of sccond qurey is more.But users are say it is runing fast.
    How it can possiable ? <snip>
    This doesn't address your question, but let me suggest that for your own sanity you start brining some formatting to your sql. And for the sanity of those on this forum of whom you expect assistance, you preserve that formatting through the use of the code tags (see the FAQ for details).
    I've done the first one for you, as an example of what I mean
    SELECT
         PH.CTRL_NBR
    ,     PD.SEQ_NBR
    ,     PH.CNTRY
    ,     PH.SHIP_DATE
    ,     PHI.WAVE_NBR
    ,     PD.ID
    ,     PD.QTY
    ,     IM.PACK_QTY
    ,     IM.UNIT_VOL
    ,     IM.PACK_QTY
    ,     MAX(CD.PACK_QTY) AS CASE_QTY
    ,     IM.UNIT_WT
    FROM
         HDR PH
    ,     HDR_INTRNL PHI
    ,     DTL PD
    ,     HDR CH
    ,     CASEDTL CD
    ,     IMASTER IM
    WHERE
         PH.CTRL_NBR = PHI.CTRL_NBR
       AND  PD.CTRL_NBR = PH.CTRL_NBR
       AND  PD.QTY > 0
       AND  SUBSTR(CD.ID, 1, 9) = SUBSTR(PD.ID, 1, 9)
       AND  CD.CASENBR = CH.CASENBR
       AND  CH.STAT_CODE BETWEEN '10' AND '90'
       AND  IM.ID = PD.ID
       AND  PHI.WAVE_NBR='EL57893'
    GROUP BY
         PH.CTRL_NBR
    ,     PD.SEQ_NBR
    ,     PH.CNTRY
    ,     PH.SHIP_DATE
    ,      PHI.WAVE_NBR
    ,      PD.ID
    ,      PD.QTY
    ,      IM.PACK_QTY
    ,     IM.UNITVOL
    ,     IM.UNITWT
    ,     IM.PACK_QTY

  • Sql query runs slower from the application

    Hi,
    We are using oracle 9ias on AIX box.The jdk version used: 1.3.1 . From the j2ee application when we perfom a search, the sql query takes for ever to return the results. I know that we are waiting on the database because I can see the query working when I look at TOAD.But if i run the same query on the database server itself, it returns the results in less than a sec. Could you guys throw some light on how we could troubleshoot this problem. Thanks.

    When the results have to travel over the network, it is slow, and when they don't, it is fast.
    That is what you are saying, correct?
    So your approach should be to not bring so much data over the network. Don't select columns you don't need, and don't select rows you don't need.

  • UNION making query very slow... solution?

    Hi Guys,
    I want to get the records of two tables in one view. Option available in oracle is UNION.
    I have used UNION between two select statement. There are above 15,000 records in one table and around 200 in the other one.
    But after using this UNION between the select statements my view have become very slow.
    Can i use a order by command in the following view, I have tried but it gives error. What is the alternate of a UNION.
    Please help. All of our reports depend on this view and its very slow.
    the script of the view is as follows:
    CREATE OR REPLACE VIEW "COMMON"."V_SEL_SYS_EMP" AS
    Select Employee.Emp_Employees.Employee_ID,
    trim(Employee.Emp_Employees.Emp_F_Name) ||' '|| trimemployee.Emp_Employees.Emp_L_Name) As
    Emp_Name, Employee.Emp_Employees.Branch_ID,
    Common.Com_Branches.Br_Name, COMMON.COM_BRANCHES.REGION_ID,
    COMMON.COM_REGIONS.REGION_NAME, COMMON.COM_BRANCHES.CHAPTER_ID,
    COMMON.COM_CHAPTERS.CHAPTER_NAME, Employee.Emp_Employees.Company_ID,
    Common.Com_Companies.Comp_Name, Employee.Emp_Employees.Department_ID,
    Common.Com_Departments.Dept_Name, Employee.Emp_Employees.Religion_ID,
    Common.Com_Religions.Religion_Name, Employee.Emp_Employees.Premises_ID,
    Common.Com_Premises.Premises_name, Employee.Emp_Employees.Categ_ID,
    Employee.Emp_Categories.Categ_Name, Employee.Emp_Employees.Desig_ID,
    Employee.Emp_Employees.Desig_Suffix, Employee.Emp_Designations.Designation,
    EMPLOYEE.EMP_EMPLOYEES.PAY_SCALE, EMPLOYEE.EMP_EMPLOYEES.BASIC_SAL,
    Employee.Emp_Employees.HEAD_OF_DEPT, Employee.Emp_Employees.Birth_Date,
    Employee.Emp_Employees.Emp_Gender, Employee.Emp_Employees.Emp_Status,
    Employee.Emp_Employees.Hire_Date, Employee.Emp_Employees.Conf_Date,
    Employee.Emp_Employees.Left_Date, Employee.Emp_Employees.Emp_Photo,
    Employee.Emp_Emp_Info.E_Mail,Employee.Emp_Employees.Dept_Head_Id FROM Employee.Emp_Employees, Common.Com_Branches,
    Common.Com_Companies, Common.Com_Departments, Common.Com_Religions, Common.Com_Premises,
    Employee.Emp_categories,
    Employee.Emp_Designations, Employee.Emp_Emp_Info, COMMON.COM_REGIONS,common.com_chapters
    Where (Employee.Emp_Employees.Branch_ID = Common.Com_Branches.Branch_ID(+))
    and (Employee.Emp_Employees.Company_ID = Common.Com_Companies.Company_ID(+))
    AND (COM_BRANCHES.REGION_ID = COM_REGIONS.REGION_ID(+))
    AND (COM_BRANCHES.CHAPTER_ID = COM_CHAPTERS.CHAPTER_ID(+))
    and (Employee.Emp_Employees.Department_ID = Common.Com_Departments.Department_ID(+))
    and (Employee.Emp_Employees.Religion_ID = Common.Com_Religions.Religion_ID(+))
    and (Employee.Emp_Employees.Premises_ID = Common.Com_Premises.Premises_ID(+))
    and (Employee.Emp_Employees.Categ_ID = Employee.Emp_Categories.Categ_ID(+))
    and (Employee.Emp_Employees.Desig_ID = Employee.Emp_Designations.Desig_ID(+))
    and (Employee.Emp_Employees.Employee_ID = Employee.Emp_Emp_Info.Employee_ID(+))
    UNION
    Select Common.Com_Non_Employees.Non_Employee_ID,
    trim(Common.Com_Non_Employees.First_Name) ||' '|| trim(Common.Com_Non_Employees.Last_Name)
    As Emp_Name, Common.Com_Non_Employees.Branch_ID,
    Common.Com_Branches.Br_Name, COMMON.COM_BRANCHES.REGION_ID,
    COMMON.COM_REGIONS.REGION_NAME, COMMON.COM_BRANCHES.CHAPTER_ID,
    COMMON.COM_CHAPTERS.CHAPTER_NAME, Common.Com_Non_Employees.Company_ID,
    Common.Com_Companies.Comp_Name, Common.Com_Non_Employees.Department_ID,
    Common.Com_Departments.Dept_Name, Common.Com_Non_Employees.Religion_ID,
    Common.Com_Religions.Religion_Name, NULL as Premises_ID,
    NULL as Premises_name, NULL as Categ_ID, NULL as Categ_Name,
    Common.Com_Non_Employees.Desig_ID, Common.Com_Non_Employees.Desig_Suffix,
    Employee.Emp_Designations.Designation, NULL as PAY_SCALE,
    NULL as BASIC_SAL, NULL as HEAD_OF_DEPT, NULL as Birth_Date,
    Common.Com_Non_Employees.Emp_Gender, NULL as Emp_Status,
    NULL as Hire_Date,NULL as Conf_Date,NULL as Left_Date,NULL as Emp_Photo,
    Employee.Emp_Emp_Info.E_Mail,Null as Dept_Head_ID
    FROM Common.Com_Non_Employees, Common.Com_Branches,
    Common.Com_Companies,
    Common.Com_Departments, Common.Com_Religions, Common.Com_Premises,
    Employee.Emp_categories, Employee.Emp_Designations, Employee.Emp_Emp_Info, COMMON.COM_REGIONS,
    common.com_chapters
    Where (Common.Com_Non_Employees.Branch_ID = Common.Com_Branches.Branch_ID(+))
    and (Common.Com_Non_Employees.Company_ID = Common.Com_Companies.Company_ID(+))
    AND (COM_BRANCHES.REGION_ID = COM_REGIONS.REGION_ID(+))
    AND (COM_BRANCHES.CHAPTER_ID = COM_CHAPTERS.CHAPTER_ID(+))
    and (Common.Com_Non_Employees.Department_ID = Common.Com_Departments.Department_ID(+))
    and (Common.Com_Non_Employees.Religion_ID = Common.Com_Religions.Religion_ID(+))
    and (Common.Com_Non_Employees.Desig_ID = Employee.Emp_Designations.Desig_ID(+))
    and (Common.Com_Non_Employees.NOn_Employee_ID = Employee.Emp_Emp_Info.Employee_ID(+))
    without UNION the two selet commands retrieve data in a quick manner.
    Plis help!
    Imran Baig

    use UNION ALL instead of UNION.
    If you still feel slow then generate the trace and see what is the bottle neck.
    alter session set events '10046 trace name context forever, level 8'
    select * from veww;
    alter session set events '10046 trace name context off';
    use tkprof to format the trace file generated by the event, you can find trace in your udump directory. And see what are the waiting events.
    Jaffar
    OCP DBA

  • Sql is very slow

    Sql Query
    SELECT DISTINCT '13ck0823ba', ' ', b.emplid,
                    NVL ((SELECT SUM (b3.total_gross)
                            FROM sysadm.ps_pay_calendar a3,
                                 sysadm.ps_pay_check b3
                           WHERE a3.run_id = a.run_id
                             AND b3.emplid = b.emplid
                             AND b3.company = b.company
                             AND b3.paygroup = b.paygroup
                             AND b3.pay_end_dt = b.pay_end_dt
                             AND a3.company = b.company
                             AND a3.paygroup = b.paygroup
                             AND a3.pay_end_dt = b.pay_end_dt),
                         0
                    0,
                    NVL ((SELECT SUM (b1.lbr_dist_amt)
                            FROM sysadm.ps_py_ldtl_tbl a1,
                                 sysadm.ps_tl_payable_time b1
                           WHERE a1.run_id = a.run_id
                             AND b1.emplid = b.emplid
                             AND a1.pay_system = b1.pay_system
                             AND a1.payroll_req_num = b1.payroll_req_num),
                         0
                        ) AS tl_pay_amt,
                    0,
                    NVL ((SELECT /*+ USE_NL(B2 C2) */
                                 SUM (c2.oi_foreign_amt)
                            FROM sysadm.ps_py_ldtl_tbl a2,
                                 sysadm.ps_tl_payable_time b2,
                                 sysadm.ps_oi_prj_resource c2
                           WHERE a2.run_id = a.run_id
                             AND b2.emplid = b.emplid
                             AND a2.pay_system = b2.pay_system
                             AND a2.payroll_req_num = b2.payroll_req_num
                             AND b2.emplid = c2.emplid
                             AND (   b2.seq_nbr = c2.seq_nbr
                                  OR b2.seq_nbr = SUBSTR (c2.resource_id, -13, 12)
                             AND b2.dur = c2.trans_dt
                             AND c2.analysis_type = 'TLB'),
                         0
                        ) AS tlb_pay,
                    0, 0, 0
               FROM sysadm.ps_pay_calendar a, sysadm.ps_pay_check b
              WHERE a.run_id = '13CK0823BA'
                AND a.company = b.company
                AND a.paygroup = b.paygroup
                AND a.pay_end_dt = b.pay_end_dt;
    Explain Plan
    | Id  | Operation                      | Name               | Rows  | Bytes | Cost (%CPU)| Time     | Inst   |IN-OUT|
    |   0 | SELECT STATEMENT               |                    |   354 | 18054 |     7  (15)| 00:00:01 |        |      |
    |   1 |  SORT AGGREGATE                |                    |     1 |    56 |            |          |        |      |
    |   2 |   NESTED LOOPS                 |                    |       |       |            |          |        |      |
    |   3 |    NESTED LOOPS                |                    |     1 |    56 |     4   (0)| 00:00:01 |        |      |
    |*  4 |     INDEX RANGE SCAN           | PS0PAY_CALENDAR    |     1 |    26 |     1   (0)| 00:00:01 |        |      |
    |*  5 |     INDEX RANGE SCAN           | PS1PAY_CHECK       |     1 |       |     2   (0)| 00:00:01 |        |      |
    |   6 |    TABLE ACCESS BY INDEX ROWID | PS_PAY_CHECK       |     1 |    30 |     3   (0)| 00:00:01 |        |      |
    |   7 |  SORT AGGREGATE                |                    |     1 |    40 |            |          |        |      |
    |*  8 |   HASH JOIN                    |                    |    11 |   440 |   151   (1)| 00:00:02 |        |      |
    |*  9 |    INDEX RANGE SCAN            | PS0PY_LDTL_TBL     |    10 |   190 |     2   (0)| 00:00:01 |        |      |
    |  10 |    TABLE ACCESS BY INDEX ROWID | PS_TL_PAYABLE_TIME |   953 | 20013 |   148   (0)| 00:00:02 |        |      |
    |* 11 |     INDEX RANGE SCAN           | IDX$$_49B90004     |   953 |       |     5   (0)| 00:00:01 |        |      |
    |  12 |  SORT AGGREGATE                |                    |     1 |   118 |            |          |        |      |
    |  13 |   NESTED LOOPS                 |                    |     1 |   118 |    79   (0)| 00:00:01 |        |      |
    |  14 |    NESTED LOOPS                |                    |     1 |    99 |    78   (0)| 00:00:01 |        |      |
    |  15 |     REMOTE                     | PS_PROJ_RESOURCE   |    18 |  1206 |     6   (0)| 00:00:01 | FSLINK | R->S |
    |* 16 |     TABLE ACCESS BY INDEX ROWID| PS_TL_PAYABLE_TIME |     1 |    32 |     4   (0)| 00:00:01 |        |      |
    |* 17 |      INDEX RANGE SCAN          | IDX$$_49B90004     |     1 |       |     3   (0)| 00:00:01 |        |      |
    |* 18 |    INDEX RANGE SCAN            | PS0PY_LDTL_TBL     |     1 |    19 |     1   (0)| 00:00:01 |        |      |
    |  19 |  HASH UNIQUE                   |                    |   354 | 18054 |     7  (15)| 00:00:01 |        |      |
    |  20 |   NESTED LOOPS                 |                    |   354 | 18054 |     6   (0)| 00:00:01 |        |      |
    |* 21 |    INDEX RANGE SCAN            | PS0PAY_CALENDAR    |     3 |    78 |     2   (0)| 00:00:01 |        |      |
    |* 22 |    INDEX RANGE SCAN            | PSEPAY_CHECK       |   103 |  2575 |     2   (0)| 00:00:01 |        |      |
    Predicate Information (identified by operation id):
       4 - access("A3"."RUN_ID"=:B1 AND "A3"."COMPANY"=:B2 AND "A3"."PAYGROUP"=:B3 AND "A3"."PAY_END_DT"=:B4)
       5 - access("B3"."EMPLID"=:B1 AND "B3"."COMPANY"=:B2 AND "B3"."PAYGROUP"=:B3 AND "B3"."PAY_END_DT"=:B4)
       8 - access("A1"."PAY_SYSTEM"="B1"."PAY_SYSTEM" AND SYS_OP_UNDESCEND(SYS_OP_DESCEND("PAYROLL_REQ_NUM"))="B1
                  "."PAYROLL_REQ_NUM" AND SYS_OP_DESCEND("PAYROLL_REQ_NUM")=SYS_OP_DESCEND("B1"."PAYROLL_REQ_NUM"))
       9 - access("A1"."RUN_ID"=:B1)
      11 - access("B1"."EMPLID"=:B1)
      16 - filter(("B2"."SEQ_NBR"="SEQ_NBR" OR "B2"."SEQ_NBR"=TO_NUMBER(SUBSTR("RESOURCE_ID",-13,12))) AND
                  "B2"."DUR"="TRANS_DT")
      17 - access("B2"."EMPLID"="EMPLID")
           filter("B2"."EMPLID"=:B1)
      18 - access("A2"."RUN_ID"=:B1 AND "A2"."PAY_SYSTEM"="B2"."PAY_SYSTEM" AND
                  SYS_OP_DESCEND("PAYROLL_REQ_NUM")=SYS_OP_DESCEND("B2"."PAYROLL_REQ_NUM"))
           filter(SYS_OP_UNDESCEND(SYS_OP_DESCEND("PAYROLL_REQ_NUM"))="B2"."PAYROLL_REQ_NUM")
      21 - access("A"."RUN_ID"='13CK0823BA')
      22 - access("A"."COMPANY"="B"."COMPANY" AND "A"."PAYGROUP"="B"."PAYGROUP" AND
                  "A"."PAY_END_DT"="B"."PAY_END_DT")
    Remote SQL Information (identified by operation id):
      15 - SELECT /*+ USE_NL ("PS_PROJ_RESOURCE") */ "RESOURCE_ID","ANALYSIS_TYPE","TRANS_DT","FOREIGN_AMOUNT","E
            MPLID","SEQ_NBR" FROM "SYSADM"."PS_PROJ_RESOURCE" "PS_PROJ_RESOURCE" WHERE "EMPLID"=:1 AND
            "ANALYSIS_TYPE"='TLB' (accessing 'FSLINK' )
    57 rows selected.

    Kindly find the actual plan.
    SQL Monitoring Report
    SQL Text
    SELECT /* sqlt_s31029 */ DISTINCT '13ck0823ba' , ' ' , B.EMPLID , NVL(( SELECT SUM(B3.TOTAL_GROSS) FROM SYSADM.PS_PAY_CALENDAR A3 , SYSADM.PS_PAY_CHECK B3 WHERE A3.RUN_ID = A.RUN_ID AND B3.EMPLID = B.EMPLID AND B3.COMPANY = B.COMPANY AND B3.PAYGROUP = B.PAYGROUP AND B3.PAY_END_DT = B.PAY_END_DT AND A3.COMPANY = B.COMPANY AND A3.PAYGROUP = B.PAYGROUP AND A3.PAY_END_DT = B.PAY_END_DT ),0), 0, NVL( ( SELECT SUM(B1.LBR_DIST_AMT) FROM SYSADM.PS_PY_LDTL_TBL A1 , SYSADM.PS_TL_PAYABLE_TIME B1 WHERE
    A1.RUN_ID = A.RUN_ID AND B1.EMPLID = B.EMPLID AND A1.PAY_SYSTEM = B1.PAY_SYSTEM AND A1.PAYROLL_REQ_NUM = B1.PAYROLL_REQ_NUM ),0)AS TL_PAY_AMT, 0, NVL( ( SELECT /*+ USE_NL(B2 C2) */ SUM(C2.OI_FOREIGN_AMT) FROM SYSADM.PS_PY_LDTL_TBL A2 , SYSADM.PS_TL_PAYABLE_TIME B2 , SYSADM.PS_OI_PRJ_RESOURCE C2 WHERE A2.RUN_ID = A.RUN_ID AND B2.EMPLID = B.EMPLID AND A2.PAY_SYSTEM = B2.PAY_SYSTEM AND A2.PAYROLL_REQ_NUM = B2.PAYROLL_REQ_NUM AND B2.EMPLID = C2.EMPLID AND ( B2.SEQ_NBR = C2.SEQ_NBR OR B2.SEQ_NBR =
    SUBSTR( C2.RESOURCE_ID,-13,12)) AND B2.DUR = C2.TRANS_DT AND C2.ANALYSIS_TYPE = 'TLB' ),0) AS TLB_PAY,0,0,0 FROM SYSADM.PS_PAY_CALENDAR A, SYSADM.PS_PAY_CHECK B WHERE A.RUN_ID = '13CK0823BA' AND A.COMPANY = B.COMPANY AND A.PAYGROUP = B.PAYGROUP AND A.PAY_END_DT = B.PAY_END_DT
    Global Information
    Status              :  DONE (ALL ROWS)
    Instance ID         :  1
    Session             :  SYS (594:719)
    SQL ID              :  7kw0g9wd8456b
    SQL Execution ID    :  16777216
    Execution Started   :  09/18/2013 03:35:47
    First Refresh Time  :  09/18/2013 03:36:02
    Last Refresh Time   :  09/18/2013 07:04:57
    Duration            :  12550s
    Module/Action       :  sqltxadmin.sqlt$a (xecute)/31029 41 ALTER SESSION SET EVENT
    Service             :  SYS$USERS
    Program             :  [email protected] (TNS V1-V3
    Fetch Calls         :  143
    Global Stats
    ====================================================================================================
    | Elapsed |   Cpu   |    IO    | Concurrency | Cluster  |  Other   | Fetch | Buffer | Read | Read  |
    | Time(s) | Time(s) | Waits(s) |  Waits(s)   | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
    ====================================================================================================
    |   12550 |    6451 |     1079 |        0.01 |     2.61 |     5018 |   143 |     2G | 206K |   2GB |
    ====================================================================================================
    SQL Plan Monitoring Details (Plan Hash Value=298818496)
    ================================================================================================================================================================================================
    | Id |            Operation             |        Name        |  Rows   | Cost |   Time    | Start  | Execs |   Rows   | Read  | Read  |  Mem  | Activity |           Activity Detail           |
    |    |                                  |                    | (Estim) |      | Active(s) | Active |       | (Actual) | Reqs  | Bytes | (Max) |   (%)    |             (# samples)             |
    ================================================================================================================================================================================================
    |  0 | SELECT STATEMENT                 |                    |         |      |     12536 |    +15 |  2125 |     2125 |       |       |       |          |                                     |
    |  1 |   SORT AGGREGATE                 |                    |       1 |      |     12536 |    +15 |  2125 |     2125 |       |       |       |          |                                     |
    |  2 |    NESTED LOOPS                  |                    |         |      |     12536 |    +15 |  2125 |     2163 |       |       |       |          |                                     |
    |  3 |     NESTED LOOPS                 |                    |       1 |    4 |     12536 |    +15 |  2125 |     2163 |       |       |       |          |                                     |
    |  4 |      INDEX RANGE SCAN            | PS0PAY_CALENDAR    |       1 |    1 |     12536 |    +15 |  2125 |     2125 |       |       |       |          |                                     |
    |  5 |      INDEX RANGE SCAN            | PS1PAY_CHECK       |       1 |    2 |     12536 |    +15 |  2125 |     2163 |  1575 |  12MB |       |     0.01 | db file sequential read (1)         |
    |  6 |     TABLE ACCESS BY INDEX ROWID  | PS_PAY_CHECK       |       1 |    3 |     12536 |    +15 |  2163 |     2163 |    78 | 624KB |       |          |                                     |
    |  7 |   SORT AGGREGATE                 |                    |       1 |      |     12536 |    +15 |  2124 |     2124 |       |       |       |          |                                     |
    |  8 |    HASH JOIN                     |                    |      11 |  151 |     12536 |    +15 |  2124 |    29600 |       |       |    1M |          |                                     |
    |  9 |     INDEX RANGE SCAN             | PS0PY_LDTL_TBL     |      10 |    2 |     12536 |    +15 |  2124 |    70092 |       |       |       |          |                                     |
    | 10 |     TABLE ACCESS BY INDEX ROWID  | PS_TL_PAYABLE_TIME |     953 |  148 |     12550 |     +1 |  2124 |       3M |  192K |   1GB |       |     0.90 | Cpu (2)                             |
    |    |                                  |                    |         |      |           |        |       |          |       |       |       |          | db file sequential read (111)       |
    | 11 |      INDEX RANGE SCAN            | IDX$$_49B90004     |     953 |    5 |     12551 |     +0 |  2124 |       3M | 11273 |  88MB |       |     0.06 | db file sequential read (8)         |
    | 12 |   SORT AGGREGATE                 |                    |       1 |      |     12536 |    +15 |  2124 |     2124 |       |       |       |          |                                     |
    | 13 |    NESTED LOOPS                  |                    |       1 |   79 |     12536 |    +15 |  2124 |    33990 |       |       |       |          |                                     |
    | 14 |     NESTED LOOPS                 |                    |       1 |   78 |     12536 |    +15 |  2124 |       3M |       |       |       |          |                                     |
    | 15 |      REMOTE                      | PS_PROJ_RESOURCE   |      18 |    6 |     12547 |     +4 |  2124 |       3M |       |       |       |     4.13 | Cpu (1)                             |
    |    |                                  |                    |         |      |           |        |       |          |       |       |       |          | SQL*Net message from dblink (58)    |
    |    |                                  |                    |         |      |           |        |       |          |       |       |       |          | SQL*Net more data from dblink (459) |
    | 16 |      TABLE ACCESS BY INDEX ROWID | PS_TL_PAYABLE_TIME |       1 |    4 |     12539 |    +12 |    3M |       3M |       |       |       |     2.14 | Cpu (268)                           |
    | 17 |       INDEX RANGE SCAN           | IDX$$_49B90004     |       1 |    3 |     12536 |    +15 |    3M |       4G |       |       |       |     0.48 | Cpu (60)                            |
    | 18 |     INDEX RANGE SCAN             | PS0PY_LDTL_TBL     |       1 |    1 |     12536 |    +15 |    3M |    33990 |       |       |       |     0.01 | Cpu (1)                             |
    | 19 |   HASH UNIQUE                    |                    |     354 |    7 |     12536 |    +15 |     1 |     2117 |       |       |    1M |          |                                     |
    | 20 |    NESTED LOOPS                  |                    |     354 |    6 |     12536 |    +15 |     1 |     2147 |       |       |       |          |                                     |
    | 21 |     INDEX RANGE SCAN             | PS0PAY_CALENDAR    |       3 |    2 |     12536 |    +15 |     1 |        7 |       |       |       |          |                                     |
    | 22 |     INDEX RANGE SCAN             | PSEPAY_CHECK       |     103 |    2 |     12536 |    +15 |     7 |     2147 |    70 | 560KB |       |          |                                     |
    ================================================================================================================================================================================================

  • Execution of SQL Query to slow

    Hey all!!!
    I'm using 10g express edition with apex 3.1, when I run this query:
    select asig.idasig IDASIG, asig.idAsig "C&oacute;digo Asignatura", asig.idasig ID,substr(asig.codigoasig||' '||asig.nombre,0,40) "Asignatura", p.nombre||' '||p.apellidos "Responsable", t.usuario "T&eacute;cnico", substr(ea.estado,0,22) "Estado Asignatura", ec.estado "Estado Certificado", cert.idestado
    from certificado cert, asignatura asig, histasig ha, profesor p, tecnico t, estado ea, estado ec
    where cert.idasig = asig.idasig and
    p.idprof = asig.idprof and
    t.idtecnico = asig.idtecnico and
    *(cert.idasig, cert.fecha) in (select idasig, max(fecha) from certificado group by idasig) and*
    ec.idestado = cert.idestado and
    ha.idasig = asig.idasig and
    *(ha.idasig, ha.fecha) in (select idasig, max(fecha) from histasig group by idasig) and*
    ea.idestado = ha.idestado
    It gets too slow, making the query gets results in approximately 149s.
    Someone can give me an idea...
    PD:The case is that we have another query that make almost the same but with this one I get the results in less than 1s.

    These are the results:
    TKPROF: Release 10.2.0.1.0 - Production on Mar Feb 10 10:35:58 2009
    Copyright (c) 1982, 2005, Oracle.  All rights reserved.
    Trace file: C:\oraclexe\app\oracle\admin\XE\udump\xe_ora_4724.trc
    Sort options: prsela  exeela  fchela 
    count    = number of times OCI procedure was executed
    cpu      = cpu time in seconds executing
    elapsed  = elapsed time in seconds executing
    disk     = number of physical reads of buffers from disk
    query    = number of buffers gotten for consistent read
    current  = number of buffers gotten in current mode (usually for update)
    rows     = number of rows processed by the fetch or execute call
    select asig.idasig ID1, asig.idAsig ID2, asig.idasig ID3,asig.codigoasig, asig.nombre, p.nombre,p.apellidos,t.usuario,ea.estado,ec.estado,cert.idestado
    from certificado cert, asignatura asig, histasig ha,  profesor p, tecnico t, estado ea, estado ec
    where cert.idasig = asig.idasig and
    p.idprof = asig.idprof and
    t.idtecnico = asig.idtecnico and
    (cert.idasig, cert.fecha) in (select idasig, max(fecha) from certificado group by idasig) and
    ec.idestado = cert.idestado and
    ha.idasig = asig.idasig and
    (ha.idasig, ha.fecha) in (select idasig, max(fecha) from histasig group by idasig) and
    ea.idestado = ha.idestado
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.15       0.14          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch       64    102.17     102.43          0     369673          0         937
    total       66    102.32     102.57          0     369673          0         937
    Misses in library cache during parse: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 36 
    Rows     Row Source Operation
        937  NESTED LOOPS  (cr=369673 pr=0 pw=0 time=102241172 us)
        937   NESTED LOOPS  (cr=368672 pr=0 pw=0 time=103609539 us)
        937    NESTED LOOPS  (cr=5030 pr=0 pw=0 time=97377 us)
        937     NESTED LOOPS  (cr=3082 pr=0 pw=0 time=72064 us)
        937      NESTED LOOPS  (cr=2081 pr=0 pw=0 time=55194 us)
        947       HASH JOIN RIGHT SEMI (cr=44 pr=0 pw=0 time=22573 us)
        947        VIEW  VW_NSO_1 (cr=17 pr=0 pw=0 time=4100 us)
        947         HASH GROUP BY (cr=17 pr=0 pw=0 time=3151 us)
       1659          INDEX FAST FULL SCAN PK_CERTIFICADO (cr=17 pr=0 pw=0 time=1728 us)(object id 15811)
       1659        MERGE JOIN  (cr=27 pr=0 pw=0 time=11173 us)
         39         TABLE ACCESS BY INDEX ROWID ESTADO (cr=10 pr=0 pw=0 time=286 us)
         39          INDEX FULL SCAN PK_ESTADO (cr=5 pr=0 pw=0 time=95 us)(object id 15790)
       1659         SORT JOIN (cr=17 pr=0 pw=0 time=7693 us)
       1659          INDEX FAST FULL SCAN PK_CERTIFICADO (cr=17 pr=0 pw=0 time=42 us)(object id 15811)
        937       TABLE ACCESS BY INDEX ROWID ASIGNATURA (cr=2037 pr=0 pw=0 time=31871 us)
        947        INDEX UNIQUE SCAN PK_ASIGNATURA (cr=1011 pr=0 pw=0 time=16230 us)(object id 15797)
        937      TABLE ACCESS BY INDEX ROWID TECNICO (cr=1001 pr=0 pw=0 time=14632 us)
        937       INDEX UNIQUE SCAN PK_TECNICO (cr=64 pr=0 pw=0 time=6532 us)(object id 15777)
        937     TABLE ACCESS BY INDEX ROWID PROFESOR (cr=1948 pr=0 pw=0 time=20712 us)
        937      INDEX UNIQUE SCAN PK_PROFESOR (cr=1001 pr=0 pw=0 time=11554 us)(object id 15795)
        937    INDEX RANGE SCAN PK_HISTASIG (cr=363642 pr=0 pw=0 time=102276685 us)(object id 15809)
        937     FILTER  (cr=361692 pr=0 pw=0 time=101967826 us)
    64914543      HASH GROUP BY (cr=361692 pr=0 pw=0 time=139395915 us)
    94619691       INDEX FAST FULL SCAN PK_HISTASIG (cr=361692 pr=0 pw=0 time=94752646 us)(object id 15809)
        937   TABLE ACCESS BY INDEX ROWID ESTADO (cr=1001 pr=0 pw=0 time=39308 us)
        937    INDEX UNIQUE SCAN PK_ESTADO (cr=64 pr=0 pw=0 time=15348 us)(object id 15790)
    alter session set sql_trace true
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        0      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        0      0.00       0.00          0          0          0           0
    total        1      0.00       0.00          0          0          0           0
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 36 
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.15       0.14          0          0          0           0
    Execute      2      0.00       0.00          0          0          0           0
    Fetch       64    102.17     102.43          0     369673          0         937
    total       67    102.32     102.57          0     369673          0         937
    Misses in library cache during parse: 1
    OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        0      0.00       0.00          0          0          0           0
    Execute      0      0.00       0.00          0          0          0           0
    Fetch        0      0.00       0.00          0          0          0           0
    total        0      0.00       0.00          0          0          0           0
    Misses in library cache during parse: 0
        2  user  SQL statements in session.
        0  internal SQL statements in session.
        2  SQL statements in session.
    Trace file: C:\oraclexe\app\oracle\admin\XE\udump\xe_ora_4724.trc
    Trace file compatibility: 10.01.00
    Sort options: prsela  exeela  fchela 
           1  session in tracefile.
           2  user  SQL statements in trace file.
           0  internal SQL statements in trace file.
           2  SQL statements in trace file.
           2  unique SQL statements in trace file.
         147  lines in trace file.
         134  elapsed seconds in trace file.We had seen that the possible problems are here:
    937               INDEX RANGE SCAN PK_HISTASIG (cr=363642 pr=0 pw=0 time=102276685 us)(object id 15809)
    64914543       HASH GROUP BY (cr=361692 pr=0 pw=0 time=139395915 us)
    94619691       INDEX FAST FULL SCAN PK_HISTASIG (cr=361692 pr=0 pw=0 time=94752646 us)(object id 15809)The time spent is too much, but we don't see how can we solve this problem, any idea?

  • Update Query very slow

    Hi All
    I have three setups on which i have to run same query which is mentioned below. The execution plan on all three setups is same for the mentioned query. Still in one of the setup the query is taking almost 8 Hrs to complete. while in rest 2 setups it takes 2 Hrs to complete. The Ram Available for the setup is Same(16 GB). I tried to increase yhe SGA size but not got the expected results. i do not have DBA support for the same. I have also analysed and changed the parameter Index_OPtimizer_cost and made sure vthat this parameter is same for all three setups.
    The main problem is i can not modify the query as it is been generated during on the processes. But as mentioned earlier the query generated on all three setup is same. I also changed log_buffer_size. The query is :
    UPDATE /*+ BYPASS_UJVC */ ( SELECT Main Table_name.n_exp_covered_amt_irb AS T0 , CASE WHEN COND0 = 0 THEN BP0 ELSE BP1 END AS T1 FROM Global temp table , Main Table Name WHERE Main Table Name.n_gaap_skey=Gloabl Temp table.n_gaap_skey AND Main Table Name.n_run_skey=Gloabl Temp table.n_run_skey AND Main Table Name.n_acct_skey=Gloabl Temp table.n_acct_skey AND Main Table Name.fic_mis_date=Gloabl Temp table.fic_mis_date) SET T0 = T1
    Indexes are same on the All three setups also one index is present for the column name mentioned in the where clause of the query.
    The oracle version used is 10.0.1.0 in first setup in second setup i am using 10.0.2.0 and in third setup it's 10.0.4.0. The query is taking time where 10.0.2.0 version is installed.
    When i have looked in to the session while the query e=was executing SORT OUTPUT was taking most of the time.
    Thanks in Advance. It's very critical for me to get it resolved.Any suggestions are extremely welcome.

    Hi,
    please check the indexes on the colums of table where sort is happening. if indexes are not there then create it or rebuilt it. also the sql tuning advisor
    recommendation in dbconsole.
    thanks

Maybe you are looking for