Way to find CTM taking more time to plan a demand

Hi,
Normally a demand in CTM gets planned in less than 1 second. But sometimes there are abnormailities may be because of Data or system and CTM takes more time to plan a demand. Is there a way or method to find why a demand has been planned in more time?
Need your help
Thanks
Deepak

Hi Deepak,
1) Once the CTM run is started, it will record & execute all the events of the program mentioned in the function module and each event will be stored in the OPTIMISER TRACE FILE. 
The trace files will be recorded in back end and you can check with basis team to help you in extracting & convert into your requirement form with suitable fields and you can develop a custom report on this so that you can execute on daily/weekly basis and analyse.  The trace file will be available only in optimiser server.
2) The other areas that you can look at is /SAPAPO/OPT12 - Process Overview wherein u will get process related informations but not at very detailed level
3) Check with basis team whether any database alerts can be developed if at all your CTM run gets strucks or extends for want of data or performance.
4) Check the application logs/inbound/outbound queues/sysfails which will figure out any specific item containing errors.
Regards
R. Senthil Mareeswaran.

Similar Messages

  • Create index is taking more time

    Hi,
    One of the concurrent program is taking more time , We generate the trace file and found that the create index is taking more time.
    Below is from the trace file and such type of index creation is happening lot of time in Oracle standard program.
    Can somebody let me know why there is a big difference between cpu and elapse time.
    We are seeing the PX Deq: Execute Reply Event as well.look idle time for database.
    Please let me know which parameter of the database is affecting this.
    CREATE INDEX ITEM_CATEGORIES_N2_BD9 ON ITEM_CATEGORIES_BD9(CATEGORY_SET_ID,
    SR_CATEGORY_ID,ORGANIZATION_ID,SR_INSTANCE_ID) PARALLEL TABLESPACE MSCX
    STORAGE( INITIAL 40960 NEXT 33554432 PCTINCREASE 0) PCTFREE 10 INITRANS 11
    MAXTRANS 255
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 3 0 0
    Execute 1 0.35 364.82 131168 117945 60324 0
    Fetch 0 0.00 0.00 0 0 0 0
    total 2 0.35 364.83 131168 117948 60324 0
    Misses in library cache during parse: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 80 (recursive depth: 2)
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    reliable message 1 0.00 0.00
    enq: KO - fast object checkpoint 1 0.01 0.01
    PX Deq: Join ACK 6 0.00 0.00
    PX Deq Credit: send blkd 112 0.00 0.01
    PX qref latch 7 0.00 0.00
    PX Deq: Parse Reply 3 0.00 0.00
    PX Deq: Execute Reply 604 1.96 364.42
    log file sync 1 0.00 0.00
    PX Deq: Signal ACK 1 0.00 0.00
    latch: session allocation 2 0.00 0.00
    Regards,

    user12121524 wrote:
    CREATE  INDEX ITEM_CATEGORIES_N2_BD9 ON ITEM_CATEGORIES_BD9(CATEGORY_SET_ID,
    SR_CATEGORY_ID,ORGANIZATION_ID,SR_INSTANCE_ID) PARALLEL  TABLESPACE MSCX
    STORAGE(  INITIAL 40960 NEXT 33554432 PCTINCREASE 0) PCTFREE 10 INITRANS 11
    MAXTRANS 255
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          3          0           0
    Execute      1      0.35     364.82     131168     117945      60324           0
    Fetch        0      0.00       0.00          0          0          0           0
    total        2      0.35     364.83     131168     117948      60324           0
    Misses in library cache during parse: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 80     (recursive depth: 2)
    Elapsed times include waiting on following events:
    Event waited on                             Times   Max. Wait  Total Waited
    ----------------------------------------   Waited  ----------  ------------
    reliable message                                1        0.00          0.00
    enq: KO - fast object checkpoint                1        0.01          0.01
    PX Deq: Join ACK                                6        0.00          0.00
    PX Deq Credit: send blkd                      112        0.00          0.01
    PX qref latch                                   7        0.00          0.00
    PX Deq: Parse Reply                             3        0.00          0.00
    PX Deq: Execute Reply                         604        1.96        364.42
    log file sync                                   1        0.00          0.00
    PX Deq: Signal ACK                              1        0.00          0.00
    latch: session allocation                       2        0.00          0.00
    What you've given us is the query co-ordinator trace, which basically tells us that the the coordinator waited 364 seconds for the PX slaves to tell it that they had completed their tasks ("PX Deq: Execute Reply" time). You need to look at the slave traces to find out where they spent their time - and that's probably not going to be easy if there are lots of parallel pieces of processing going on.
    If you want to do some debugging (in general) one option is to add a query against V$pq_tqstat after each piece of parallel processing and log the results to a named file, or write them to a table with a tag, as this will tell you how many slaves were involved, how, and what the distribution of work and time was.
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk
    To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
    "Science is more than a body of knowledge; it is a way of thinking"
    Carl Sagan

  • Query is taking more time to execute in PROD

    Hi All,
    Can anyone tell me why this query is taking more time when I am using for single trx_number record it is working fine but when I am trying to use all the records it is not fatching any records and it is keep on running.
    SELECT DISTINCT OOH.HEADER_ID
    ,OOH.ORG_ID
    ,ct.CUSTOMER_TRX_ID
    ,ool.ship_from_org_id
    ,ct.trx_number IDP_SHIPMENT_ID
    ,ctt.type STATUS_CODE
    ,SYSDATE STATUS_DATE
    ,ooh.attribute16 IDP_ORDER_NBR --Change based on testing on 21-JUL-2010 in UAT
    ,lpad(rac_bill.account_number,6,0) IDP_BILL_TO_CUSTOMER_NBR
    ,rac_bill.orig_system_reference
    ,rac_ship_party.party_name SHIP_TO_NAME
    ,raa_ship_loc.address1 SHIP_TO_ADDR1
    ,raa_ship_loc.address2 SHIP_TO_ADDR2
    ,raa_ship_loc.address3 SHIP_TO_ADDR3
    ,raa_ship_loc.address4 SHIP_TO_ADDR4
    ,raa_ship_loc.city SHIP_TO_CITY
    ,NVL(raa_ship_loc.state,raa_ship_loc.province) SHIP_TO_STATE
    ,raa_ship_loc.country SHIP_TO_COUNTRY_NAME
    ,raa_ship_loc.postal_code SHIP_TO_ZIP
    ,ooh.CUST_PO_NUMBER CUSTOMER_ORDER_NBR
    ,ooh.creation_date CUSTOMER_ORDER_DATE
    ,ool.actual_shipment_date DATE_SHIPPED
    ,DECODE(mp.organization_code,'CHP', 'CHESAPEAKE'
    ,'CSB', 'CHESAPEAKE'
    ,'DEP', 'CHESAPEAKE'
    ,'CHESAPEAKE') SHIPPED_FROM_LOCATION --'MEMPHIS' --'HOUSTON'
    ,ooh.freight_carrier_code FREIGHT_CARRIER
    ,NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('FREIGHT',ct.customer_trx_id,ct.org_id),0)
    + NVL(XX_FSG_NA_FASTRAQ_IFACE.get_line_fr_amt ('FREIGHT',ct.customer_trx_id,ct.org_id),0)FREIGHT_CHARGE
    ,ooh.freight_terms_code FREIGHT_TERMS
    ,'' IDP_BILL_OF_LADING
    ,(SELECT WAYBILL
    FROM WSH_DELIVERY_DETAILS_OE_V
    WHERE -1=-1
    AND SOURCE_HEADER_ID = ooh.header_id
    AND SOURCE_LINE_ID = ool.line_id
    AND ROWNUM =1) WAYBILL_CARRIER
    ,'' CONTAINERS
    ,ct.trx_number INVOICE_NBR
    ,ct.trx_date INVOICE_DATE
    ,NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('LINE',ct.customer_trx_id,ct.org_id),0) +
    NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('TAX',ct.customer_trx_id,ct.org_id),0) +
    NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('FREIGHT',ct.customer_trx_id,ct.org_id),0)INVOICE_AMOUNT
    ,NULL IDP_TAX_IDENTIFICATION_NBR
    ,NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('TAX',ct.customer_trx_id,ct.org_id),0) TAX_AMOUNT_1
    ,NULL TAX_DESC_1
    ,NULL TAX_AMOUNT_2
    ,NULL TAX_DESC_2
    ,rt.name PAYMENT_TERMS
    ,NULL RELATED_INVOICE_NBR
    ,'Y' INVOICE_PRINT_FLAG
    FROM ra_customer_trx_all ct
    ,ra_cust_trx_types_all ctt
    ,hz_cust_accounts rac_ship
    ,hz_cust_accounts rac_bill
    ,hz_parties rac_ship_party
    ,hz_locations raa_ship_loc
    ,hz_party_sites raa_ship_ps
    ,hz_cust_acct_sites_all raa_ship
    ,hz_cust_site_uses_all su_ship
    ,ra_customer_trx_lines_all rctl
    ,oe_order_lines_all ool
    ,oe_order_headers_all ooh
    ,mtl_parameters mp
    ,ra_terms rt
    ,OE_ORDER_SOURCES oos
    ,XLA_AR_INV_AEL_SL_V XLA_AEL_SL_V
    WHERE ct.cust_trx_type_id = ctt.cust_trx_type_id
    AND ctt.TYPE <> 'BR'
    AND ct.org_id = ctt.org_id
    AND ct.ship_to_customer_id = rac_ship.cust_account_id
    AND ct.bill_to_customer_id = rac_bill.cust_account_id
    AND rac_ship.party_id = rac_ship_party.party_id
    AND su_ship.cust_acct_site_id = raa_ship.cust_acct_site_id
    AND raa_ship.party_site_id = raa_ship_ps.party_site_id
    AND raa_ship_loc.location_id = raa_ship_ps.location_id
    AND ct.ship_to_site_use_id = su_ship.site_use_id
    AND su_ship.org_id = ct.org_id
    AND raa_ship.org_id = ct.org_id
    AND ct.customer_trx_id = rctl.customer_trx_id
    AND ct.org_id = rctl.org_id
    AND rctl.interface_line_attribute6 = to_char(ool.line_id)
    AND rctl.org_id = ool.org_id
    AND ool.header_id = ooh.header_id
    AND ool.org_id = ooh.org_id
    AND mp.organization_id = ool.ship_from_org_id
    AND ooh.payment_term_id = rt.term_id
    AND xla_ael_sl_v.last_update_date >= NVL(p_last_update_date,xla_ael_sl_v.last_update_date)
    AND ooh.order_source_id = oos.order_source_id --Change based on testing on 19-May-2010
    AND oos.name = 'FASTRAQ' --Change based on testing on 19-May-2010
    AND ooh.org_id = g_org_id --Change based on testing on 19-May-2010
    AND ool.flow_status_code = 'CLOSED'
    AND xla_ael_sl_v.trx_hdr_id = ct.customer_trx_id
    AND trx_hdr_table = 'CT'
    AND xla_ael_sl_v.gl_transfer_status = 'Y'
    AND xla_ael_sl_v.accounted_dr IS NOT NULL
    AND xla_ael_sl_v.org_id = ct.org_id;
    -- AND ct.trx_number = '2000080';
    }

    Hello Friend,
    You query will definitely take more time or even fail in PROD,becuase the way it is written. Here are my few observations, may be it can help :-
    1. XLA_AR_INV_AEL_SL_V XLA_AEL_SL_V : Never use a view inside such a long query , becuase View is just a window to the records.
    and when used to join other table records, then all those tables which are used to create a view also becomes part of joining conition.
    First of all please check if you really need this view. I guess you are using to check if the records have been created as Journal entries or not ?
    Please check the possbility of finding it through other AR tables.
    2. Remove _ALL tables instead use the corresponding org specific views (if you are in 11i ) or the sysnonymns ( in R12 )
    For example : For ra_cust_trx_types_all use ra_cust_trx_types.
    This will ensure that the query will execute only for those ORG_IDs which are assigned to that responsibility.
    3. Check with the DBA whether the GATHER SCHEMA STATS have been run atleast for ONT and RA tables.
    You can also check the same using
    SELECT LAST_ANALYZED FROM ALL_TABLES WHERE TABLE_NAME = 'ra_customer_trx_all'.
    If the tables are not analyzed , the CBO will not be able to tune your query.
    4. Try to remove the DISTINCT keyword. This is the MAJOR reason for this problem.
    5. If its a report , try to separate the logic in separate queries ( using a procedure ) and then populate the whole data in custom table, and use this custom table for generating the
    report.
    Thanks,
    Neeraj Shrivastava
    [email protected]
    Edited by: user9352949 on Oct 1, 2010 8:02 PM
    Edited by: user9352949 on Oct 1, 2010 8:03 PM

  • Query in timesten taking more time than query in oracle database

    Hi,
    Can anyone please explain me why query in timesten taking more time
    than query in oracle database.
    I am mentioning in detail what are my settings and what have I done
    step by step.........
    1.This is the table I created in Oracle datababase
    (Oracle Database 10g Enterprise Edition Release 10.2.0.1.0)...
    CREATE TABLE student (
    id NUMBER(9) primary keY ,
    first_name VARCHAR2(10),
    last_name VARCHAR2(10)
    2.THIS IS THE ANONYMOUS BLOCK I USE TO
    POPULATE THE STUDENT TABLE(TOTAL 2599999 ROWS)...
    declare
    firstname varchar2(12);
    lastname varchar2(12);
    catt number(9);
    begin
    for cntr in 1..2599999 loop
    firstname:=(cntr+8)||'f';
    lastname:=(cntr+2)||'l';
    if cntr like '%9999' then
    dbms_output.put_line(cntr);
    end if;
    insert into student values(cntr,firstname, lastname);
    end loop;
    end;
    3. MY DSN IS SET THE FOLLWING WAY..
    DATA STORE PATH- G:\dipesh3repo\db
    LOG DIRECTORY- G:\dipesh3repo\log
    PERM DATA SIZE-1000
    TEMP DATA SIZE-1000
    MY TIMESTEN VERSION-
    C:\Documents and Settings\dipesh>ttversion
    TimesTen Release 7.0.3.0.0 (32 bit NT) (tt70_32:17000) 2007-09-19T16:04:16Z
    Instance admin: dipesh
    Instance home directory: G:\TimestTen\TT70_32
    Daemon home directory: G:\TimestTen\TT70_32\srv\info
    THEN I CONNECT TO THE TIMESTEN DATABASE
    C:\Documents and Settings\dipesh> ttisql
    command>connect "dsn=dipesh3;oraclepwd=tiger";
    4. THEN I START THE AGENT
    call ttCacheUidPwdSet('SCOTT','TIGER');
    Command> CALL ttCacheStart();
    5.THEN I CREATE THE READ ONLY CACHE GROUP AND LOAD IT
    create readonly cache group rc_student autorefresh
    interval 5 seconds from student
    (id int not null primary key, first_name varchar2(10), last_name varchar2(10));
    load cache group rc_student commit every 100 rows;
    6.NOW I CAN ACCESS THE TABLES FROM TIMESTEN AND PERFORM THE QUERY
    I SET THE TIMING..
    command>TIMING 1;
    consider this query now..
    Command> select * from student where first_name='2155666f';
    < 2155658, 2155666f, 2155660l >
    1 row found.
    Execution time (SQLExecute + Fetch Loop) = 0.668822 seconds.
    another query-
    Command> SELECT * FROM STUDENTS WHERE FIRST_NAME='2340009f';
    2206: Table SCOTT.STUDENTS not found
    Execution time (SQLPrepare) = 0.074964 seconds.
    The command failed.
    Command> SELECT * FROM STUDENT where first_name='2093434f';
    < 2093426, 2093434f, 2093428l >
    1 row found.
    Execution time (SQLExecute + Fetch Loop) = 0.585897 seconds.
    Command>
    7.NOW I PERFORM THE SIMILAR QUERIES FROM SQLPLUS...
    SQL> SELECT * FROM STUDENT WHERE FIRST_NAME='1498671f';
    ID FIRST_NAME LAST_NAME
    1498663 1498671f 1498665l
    Elapsed: 00:00:00.15
    Can anyone please explain me why query in timesten taking more time
    that query in oracle database.
    Message was edited by: Dipesh Majumdar
    user542575
    Message was edited by:
    user542575

    TimesTen
    Hardware: Windows Server 2003 R2 Enterprise x64; 8 x Dual-core AMD 8216 2.41GHz processors; 32 GB RAM
    Version: 7.0.4.0.0 64 bit
    Schema:
    create usermanaged cache group factCache from
    MV_US_DATAMART
    ORDER_DATE               DATE,
    IF_SYSTEM               VARCHAR2(32) NOT NULL,
    GROUPING_ID                TT_BIGINT,
    TIME_DIM_ID               TT_INTEGER NOT NULL,
    BUSINESS_DIM_ID          TT_INTEGER NOT NULL,
    ACCOUNT_DIM_ID               TT_INTEGER NOT NULL,
    ORDERTYPE_DIM_ID          TT_INTEGER NOT NULL,
    INSTR_DIM_ID               TT_INTEGER NOT NULL,
    EXECUTION_DIM_ID          TT_INTEGER NOT NULL,
    EXEC_EXCHANGE_DIM_ID TT_INTEGER NOT NULL,
    NO_ORDERS               TT_BIGINT,
    FILLED_QUANTITY          TT_BIGINT,
    CNT_FILLED_QUANTITY          TT_BIGINT,
    QUANTITY               TT_BIGINT,
    CNT_QUANTITY               TT_BIGINT,
    COMMISSION               BINARY_FLOAT,
    CNT_COMMISSION               TT_BIGINT,
    FILLS_NUMBER               TT_BIGINT,
    CNT_FILLS_NUMBER          TT_BIGINT,
    AGGRESSIVE_FILLS          TT_BIGINT,
    CNT_AGGRESSIVE_FILLS          TT_BIGINT,
    NOTIONAL               BINARY_FLOAT,
    CNT_NOTIONAL               TT_BIGINT,
    TOTAL_PRICE               BINARY_FLOAT,
    CNT_TOTAL_PRICE          TT_BIGINT,
    CANCELLED_ORDERS_COUNT          TT_BIGINT,
    CNT_CANCELLED_ORDERS_COUNT     TT_BIGINT,
    ROUTED_ORDERS_NO          TT_BIGINT,
    CNT_ROUTED_ORDERS_NO          TT_BIGINT,
    ROUTED_LIQUIDITY_QTY          TT_BIGINT,
    CNT_ROUTED_LIQUIDITY_QTY     TT_BIGINT,
    REMOVED_LIQUIDITY_QTY          TT_BIGINT,
    CNT_REMOVED_LIQUIDITY_QTY     TT_BIGINT,
    ADDED_LIQUIDITY_QTY          TT_BIGINT,
    CNT_ADDED_LIQUIDITY_QTY     TT_BIGINT,
    AGENT_CHARGES               BINARY_FLOAT,
    CNT_AGENT_CHARGES          TT_BIGINT,
    CLEARING_CHARGES          BINARY_FLOAT,
    CNT_CLEARING_CHARGES          TT_BIGINT,
    EXECUTION_CHARGES          BINARY_FLOAT,
    CNT_EXECUTION_CHARGES          TT_BIGINT,
    TRANSACTION_CHARGES          BINARY_FLOAT,
    CNT_TRANSACTION_CHARGES     TT_BIGINT,
    ORDER_MANAGEMENT          BINARY_FLOAT,
    CNT_ORDER_MANAGEMENT          TT_BIGINT,
    SETTLEMENT_CHARGES          BINARY_FLOAT,
    CNT_SETTLEMENT_CHARGES          TT_BIGINT,
    RECOVERED_AGENT          BINARY_FLOAT,
    CNT_RECOVERED_AGENT          TT_BIGINT,
    RECOVERED_CLEARING          BINARY_FLOAT,
    CNT_RECOVERED_CLEARING          TT_BIGINT,
    RECOVERED_EXECUTION          BINARY_FLOAT,
    CNT_RECOVERED_EXECUTION     TT_BIGINT,
    RECOVERED_TRANSACTION          BINARY_FLOAT,
    CNT_RECOVERED_TRANSACTION     TT_BIGINT,
    RECOVERED_ORD_MGT          BINARY_FLOAT,
    CNT_RECOVERED_ORD_MGT          TT_BIGINT,
    RECOVERED_SETTLEMENT          BINARY_FLOAT,
    CNT_RECOVERED_SETTLEMENT     TT_BIGINT,
    CLIENT_AGENT               BINARY_FLOAT,
    CNT_CLIENT_AGENT          TT_BIGINT,
    CLIENT_ORDER_MGT          BINARY_FLOAT,
    CNT_CLIENT_ORDER_MGT          TT_BIGINT,
    CLIENT_EXEC               BINARY_FLOAT,
    CNT_CLIENT_EXEC          TT_BIGINT,
    CLIENT_TRANS               BINARY_FLOAT,
    CNT_CLIENT_TRANS          TT_BIGINT,
    CLIENT_CLEARING          BINARY_FLOAT,
    CNT_CLIENT_CLEARING          TT_BIGINT,
    CLIENT_SETTLE               BINARY_FLOAT,
    CNT_CLIENT_SETTLE          TT_BIGINT,
    CHARGEABLE_TAXES          BINARY_FLOAT,
    CNT_CHARGEABLE_TAXES          TT_BIGINT,
    VENDOR_CHARGE               BINARY_FLOAT,
    CNT_VENDOR_CHARGE          TT_BIGINT,
    ROUTING_CHARGES          BINARY_FLOAT,
    CNT_ROUTING_CHARGES          TT_BIGINT,
    RECOVERED_ROUTING          BINARY_FLOAT,
    CNT_RECOVERED_ROUTING          TT_BIGINT,
    CLIENT_ROUTING               BINARY_FLOAT,
    CNT_CLIENT_ROUTING          TT_BIGINT,
    TICKET_CHARGES               BINARY_FLOAT,
    CNT_TICKET_CHARGES          TT_BIGINT,
    RECOVERED_TICKET_CHARGES     BINARY_FLOAT,
    CNT_RECOVERED_TICKET_CHARGES     TT_BIGINT,
    PRIMARY KEY(ORDER_DATE, TIME_DIM_ID, BUSINESS_DIM_ID, ACCOUNT_DIM_ID, ORDERTYPE_DIM_ID, INSTR_DIM_ID, EXECUTION_DIM_ID,EXEC_EXCHANGE_DIM_ID),
    READONLY);
    No of rows: 2228558
    Config:
    < CkptFrequency, 600 >
    < CkptLogVolume, 0 >
    < CkptRate, 0 >
    < ConnectionCharacterSet, US7ASCII >
    < ConnectionName, tt_us_dma >
    < Connections, 64 >
    < DataBaseCharacterSet, AL32UTF8 >
    < DataStore, e:\andrew\datacache\usDMA >
    < DurableCommits, 0 >
    < GroupRestrict, <NULL> >
    < LockLevel, 0 >
    < LockWait, 10 >
    < LogBuffSize, 65536 >
    < LogDir, e:\andrew\datacache\ >
    < LogFileSize, 64 >
    < LogFlushMethod, 1 >
    < LogPurge, 0 >
    < Logging, 1 >
    < MemoryLock, 0 >
    < NLS_LENGTH_SEMANTICS, BYTE >
    < NLS_NCHAR_CONV_EXCP, 0 >
    < NLS_SORT, BINARY >
    < OracleID, NYCATP1 >
    < PassThrough, 0 >
    < PermSize, 4000 >
    < PermWarnThreshold, 90 >
    < PrivateCommands, 0 >
    < Preallocate, 0 >
    < QueryThreshold, 0 >
    < RACCallback, 0 >
    < SQLQueryTimeout, 0 >
    < TempSize, 514 >
    < TempWarnThreshold, 90 >
    < Temporary, 1 >
    < TransparentLoad, 0 >
    < TypeMode, 0 >
    < UID, OS_OWNER >
    ORACLE:
    Hardware: Sunos 5.10; 24x1.8Ghz (unsure of type); 82 GB RAM
    Version 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
    Schema:
    CREATE MATERIALIZED VIEW OS_OWNER.MV_US_DATAMART
    TABLESPACE TS_OS
    PARTITION BY RANGE (ORDER_DATE)
    PARTITION MV_US_DATAMART_MINVAL VALUES LESS THAN (TO_DATE(' 2007-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    NOCOMPRESS
    TABLESPACE TS_OS,
    PARTITION MV_US_DATAMART_07_NOV_D1 VALUES LESS THAN (TO_DATE(' 2007-11-11 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    NOCOMPRESS
    TABLESPACE TS_OS,
    PARTITION MV_US_DATAMART_07_NOV_D2 VALUES LESS THAN (TO_DATE(' 2007-11-21 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    NOCOMPRESS
    TABLESPACE TS_OS,
    PARTITION MV_US_DATAMART_07_NOV_D3 VALUES LESS THAN (TO_DATE(' 2007-12-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    NOCOMPRESS
    TABLESPACE TS_OS,
    PARTITION MV_US_DATAMART_07_DEC_D1 VALUES LESS THAN (TO_DATE(' 2007-12-11 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    NOCOMPRESS
    TABLESPACE TS_OS,
    PARTITION MV_US_DATAMART_07_DEC_D2 VALUES LESS THAN (TO_DATE(' 2007-12-21 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    NOCOMPRESS
    TABLESPACE TS_OS,
    PARTITION MV_US_DATAMART_07_DEC_D3 VALUES LESS THAN (TO_DATE(' 2008-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    NOCOMPRESS
    TABLESPACE TS_OS,
    PARTITION MV_US_DATAMART_08_JAN_D1 VALUES LESS THAN (TO_DATE(' 2008-01-11 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    NOCOMPRESS
    TABLESPACE TS_OS,
    PARTITION MV_US_DATAMART_08_JAN_D2 VALUES LESS THAN (TO_DATE(' 2008-01-21 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    NOCOMPRESS
    TABLESPACE TS_OS,
    PARTITION MV_US_DATAMART_08_JAN_D3 VALUES LESS THAN (TO_DATE(' 2008-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    NOCOMPRESS
    TABLESPACE TS_OS,
    PARTITION MV_US_DATAMART_MAXVAL VALUES LESS THAN (MAXVALUE)
    LOGGING
    NOCOMPRESS
    TABLESPACE TS_OS
    NOCACHE
    NOCOMPRESS
    NOPARALLEL
    BUILD DEFERRED
    USING INDEX
    TABLESPACE TS_OS_INDEX
    REFRESH FAST ON DEMAND
    WITH PRIMARY KEY
    ENABLE QUERY REWRITE
    AS
    SELECT order_date, if_system,
    GROUPING_ID (order_date,
    if_system,
    business_dim_id,
    time_dim_id,
    account_dim_id,
    ordertype_dim_id,
    instr_dim_id,
    execution_dim_id,
    exec_exchange_dim_id
    ) GROUPING_ID,
    /* ============ DIMENSIONS ============ */
    time_dim_id, business_dim_id, account_dim_id, ordertype_dim_id,
    instr_dim_id, execution_dim_id, exec_exchange_dim_id,
    /* ============ MEASURES ============ */
    -- o.FX_RATE /* FX_RATE */,
    COUNT (*) no_orders,
    -- SUM(NO_ORDERS) NO_ORDERS,
    -- COUNT(NO_ORDERS) CNT_NO_ORDERS,
    SUM (filled_quantity) filled_quantity,
    COUNT (filled_quantity) cnt_filled_quantity, SUM (quantity) quantity,
    COUNT (quantity) cnt_quantity, SUM (commission) commission,
    COUNT (commission) cnt_commission, SUM (fills_number) fills_number,
    COUNT (fills_number) cnt_fills_number,
    SUM (aggressive_fills) aggressive_fills,
    COUNT (aggressive_fills) cnt_aggressive_fills,
    SUM (fx_rate * filled_quantity * average_price) notional,
    COUNT (fx_rate * filled_quantity * average_price) cnt_notional,
    SUM (fx_rate * fills_number * average_price) total_price,
    COUNT (fx_rate * fills_number * average_price) cnt_total_price,
    SUM (CASE
    WHEN order_status = 'C'
    THEN 1
    ELSE 0
    END) cancelled_orders_count,
    COUNT (CASE
    WHEN order_status = 'C'
    THEN 1
    ELSE 0
    END
    ) cnt_cancelled_orders_count,
    -- SUM(t.FX_RATE*t.NO_FILLS*t.AVG_PRICE) AVERAGE_PRICE,
    -- SUM(FILLS_NUMBER*AVERAGE_PRICE) STAGING_AVERAGE_PRICE,
    -- COUNT(FILLS_NUMBER*AVERAGE_PRICE) CNT_STAGING_AVERAGE_PRICE,
    SUM (routed_orders_no) routed_orders_no,
    COUNT (routed_orders_no) cnt_routed_orders_no,
    SUM (routed_liquidity_qty) routed_liquidity_qty,
    COUNT (routed_liquidity_qty) cnt_routed_liquidity_qty,
    SUM (removed_liquidity_qty) removed_liquidity_qty,
    COUNT (removed_liquidity_qty) cnt_removed_liquidity_qty,
    SUM (added_liquidity_qty) added_liquidity_qty,
    COUNT (added_liquidity_qty) cnt_added_liquidity_qty,
    SUM (agent_charges) agent_charges,
    COUNT (agent_charges) cnt_agent_charges,
    SUM (clearing_charges) clearing_charges,
    COUNT (clearing_charges) cnt_clearing_charges,
    SUM (execution_charges) execution_charges,
    COUNT (execution_charges) cnt_execution_charges,
    SUM (transaction_charges) transaction_charges,
    COUNT (transaction_charges) cnt_transaction_charges,
    SUM (order_management) order_management,
    COUNT (order_management) cnt_order_management,
    SUM (settlement_charges) settlement_charges,
    COUNT (settlement_charges) cnt_settlement_charges,
    SUM (recovered_agent) recovered_agent,
    COUNT (recovered_agent) cnt_recovered_agent,
    SUM (recovered_clearing) recovered_clearing,
    COUNT (recovered_clearing) cnt_recovered_clearing,
    SUM (recovered_execution) recovered_execution,
    COUNT (recovered_execution) cnt_recovered_execution,
    SUM (recovered_transaction) recovered_transaction,
    COUNT (recovered_transaction) cnt_recovered_transaction,
    SUM (recovered_ord_mgt) recovered_ord_mgt,
    COUNT (recovered_ord_mgt) cnt_recovered_ord_mgt,
    SUM (recovered_settlement) recovered_settlement,
    COUNT (recovered_settlement) cnt_recovered_settlement,
    SUM (client_agent) client_agent,
    COUNT (client_agent) cnt_client_agent,
    SUM (client_order_mgt) client_order_mgt,
    COUNT (client_order_mgt) cnt_client_order_mgt,
    SUM (client_exec) client_exec, COUNT (client_exec) cnt_client_exec,
    SUM (client_trans) client_trans,
    COUNT (client_trans) cnt_client_trans,
    SUM (client_clearing) client_clearing,
    COUNT (client_clearing) cnt_client_clearing,
    SUM (client_settle) client_settle,
    COUNT (client_settle) cnt_client_settle,
    SUM (chargeable_taxes) chargeable_taxes,
    COUNT (chargeable_taxes) cnt_chargeable_taxes,
    SUM (vendor_charge) vendor_charge,
    COUNT (vendor_charge) cnt_vendor_charge,
    SUM (routing_charges) routing_charges,
    COUNT (routing_charges) cnt_routing_charges,
    SUM (recovered_routing) recovered_routing,
    COUNT (recovered_routing) cnt_recovered_routing,
    SUM (client_routing) client_routing,
    COUNT (client_routing) cnt_client_routing,
    SUM (ticket_charges) ticket_charges,
    COUNT (ticket_charges) cnt_ticket_charges,
    SUM (recovered_ticket_charges) recovered_ticket_charges,
    COUNT (recovered_ticket_charges) cnt_recovered_ticket_charges
    FROM us_datamart_raw
    GROUP BY order_date,
    if_system,
    business_dim_id,
    time_dim_id,
    account_dim_id,
    ordertype_dim_id,
    instr_dim_id,
    execution_dim_id,
    exec_exchange_dim_id;
    -- Note: Index I_SNAP$_MV_US_DATAMART will be created automatically
    -- by Oracle with the associated materialized view.
    CREATE UNIQUE INDEX OS_OWNER.MV_US_DATAMART_UDX ON OS_OWNER.MV_US_DATAMART
    (ORDER_DATE, TIME_DIM_ID, BUSINESS_DIM_ID, ACCOUNT_DIM_ID, ORDERTYPE_DIM_ID,
    INSTR_DIM_ID, EXECUTION_DIM_ID, EXEC_EXCHANGE_DIM_ID)
    NOLOGGING
    NOPARALLEL
    COMPRESS 7;
    No of rows: 2228558
    The query (taken Mondrian) I run against each of them is:
    select sum("MV_US_DATAMART"."NOTIONAL") as "m0"
    --, sum("MV_US_DATAMART"."FILLED_QUANTITY") as "m1"
    --, sum("MV_US_DATAMART"."AGENT_CHARGES") as "m2"
    --, sum("MV_US_DATAMART"."CLEARING_CHARGES") as "m3"
    --, sum("MV_US_DATAMART"."EXECUTION_CHARGES") as "m4"
    --, sum("MV_US_DATAMART"."TRANSACTION_CHARGES") as "m5"
    --, sum("MV_US_DATAMART"."ROUTING_CHARGES") as "m6"
    --, sum("MV_US_DATAMART"."ORDER_MANAGEMENT") as "m7"
    --, sum("MV_US_DATAMART"."SETTLEMENT_CHARGES") as "m8"
    --, sum("MV_US_DATAMART"."COMMISSION") as "m9"
    --, sum("MV_US_DATAMART"."RECOVERED_AGENT") as "m10"
    --, sum("MV_US_DATAMART"."RECOVERED_CLEARING") as "m11"
    --,sum("MV_US_DATAMART"."RECOVERED_EXECUTION") as "m12"
    --,sum("MV_US_DATAMART"."RECOVERED_TRANSACTION") as "m13"
    --, sum("MV_US_DATAMART"."RECOVERED_ROUTING") as "m14"
    --, sum("MV_US_DATAMART"."RECOVERED_ORD_MGT") as "m15"
    --, sum("MV_US_DATAMART"."RECOVERED_SETTLEMENT") as "m16"
    --, sum("MV_US_DATAMART"."RECOVERED_TICKET_CHARGES") as "m17"
    --,sum("MV_US_DATAMART"."TICKET_CHARGES") as "m18"
    --, sum("MV_US_DATAMART"."VENDOR_CHARGE") as "m19"
              from "OS_OWNER"."MV_US_DATAMART" "MV_US_DATAMART"
    where I uncomment a column at a time and rerun. I improved the TimesTen results since my first post, by retyping the NUMBER columns to BINARY_FLOAT. The results I got were:
    No Columns     ORACLE     TimesTen     
    1     1.05     0.94     
    2     1.07     1.47     
    3     2.04     1.8     
    4     2.06     2.08     
    5     2.09     2.4     
    6     3.01     2.67     
    7     4.02     3.06     
    8     4.03     3.37     
    9     4.04     3.62     
    10     4.06     4.02     
    11     4.08     4.31     
    12     4.09     4.61     
    13     5.01     4.76     
    14     5.02     5.06     
    15     5.04     5.25     
    16     5.05     5.48     
    17     5.08     5.84     
    18     6     6.21     
    19     6.02     6.34     
    20     6.04     6.75

  • CDP Performance Issue-- Taking more time fetch data

    Hi,
    I'm working on Stellent 7.5.1.
    For one of the portlet in portal its taking more time to fetch data. Please can some one help me to solve this issue.. So that performance can be improved.. Please kindly provide me solution.. This is my code for fetching data from the server....
    public void getManager(final HashMap binderMap)
    throws VistaInvalidInputException, VistaDataNotFoundException,
    DataException, ServiceException, VistaTemplateException
         String collectionID =
    getStringLocal(VistaFolderConstants.FOLDER_ID_KEY);
         long firstStartTime = System.currentTimeMillis();
    HashMap resultSetMap = null;
    String isNonRecursive = getStringLocal(VistaFolderConstants
    .ISNONRECURSIVE_KEY);
    if (isNonRecursive != null
    && isNonRecursive.equalsIgnoreCase(
    VistaContentFetchHelperConstants.STRING_TRUE))
    VistaLibraryContentFetchManager libraryContentFetchManager =
    new VistaLibraryContentFetchManager(
    binderMap);
    SystemUtils.trace(
    VistaContentFetchHelperConstants.CONTENT_FETCH_TRACE,
    "The input Parameters for Content Fetch = "
    + binderMap);
              resultSetMap = libraryContentFetchManager
    .getFolderContentItems(m_workspace);
    * used to add the resultset to the binder.
    addResultSetToBinder(resultSetMap , true);
    else
         long startTime = System.currentTimeMillis();
    * isStandard is used to decide the call is for Standard or
    * Extended.
    SystemUtils.trace(
    VistaContentFetchHelperConstants.CONTENT_FETCH_TRACE,
    "The input Parameters for Content Fetch = "
    + binderMap);
    String isStandard = getTemplateInformation(binderMap);
    long endTimeTemplate = System.currentTimeMillis();
    binderMap.put(VistaFolderConstants.IS_STANDARD,
    isStandard);
    long endTimebinderMap = System.currentTimeMillis();
    VistaContentFetchManager contentFetchManager
    = new VistaContentFetchManager(binderMap);
    long endTimeFetchManager = System.currentTimeMillis();
    resultSetMap = contentFetchManager
    .getAllFolderContentItems(m_workspace);
    long endTimeresultSetMap = System.currentTimeMillis();
    * used to add the resultset and the total no of content items
    * to the binder.
    addResultSetToBinder(resultSetMap , false);
    long endTime = System.currentTimeMillis();
    if (perfLogEnable.equalsIgnoreCase("true"))
         Log.info("Time taken to execute " +
                   "getTemplateInformation=" +
                   (endTimeTemplate - startTime)+
                   "ms binderMap=" +
                   (endTimebinderMap - startTime)+
                   "ms contentFetchManager=" +
                   (endTimeFetchManager - startTime)+
                   "ms resultSetMap=" +
                   (endTimeresultSetMap - startTime) +
                   "ms getManager:getAllFolderContentItems = " +
                   (endTime - startTime) +
                   "ms overallTime=" +
                   (endTime - firstStartTime) +
                   "ms folderID =" +
                   collectionID);
    Edited by: 838623 on Feb 22, 2011 1:43 AM

    Hi.
    The Select statment accessing MSEG Table is Slow Many a times.
    To Improve the performance of  MSEG.
    1.Check for the proper notes in the Service Market Place if you are working for CIN version.
    2.Index the MSEG table
    2.Check and limit the Columns in the Select statment .
    Possible Way.
    SELECT MBLNR MJAHR ZEILE BWART MATNR WERKS LIFNR MENGE MEINS
    EBELN EBELP LGORT SMBLN BUKRS GSBER INSMK XAUTO
    FROM MSEG
    INTO CORRESPONDING FIELDS OF TABLE ITAB
    WHERE WERKS EQ P_WERKS AND
    MBLNR IN S_MBLNR AND
    BWART EQ '105' .
    Delete itab where itab EQ '5002361303'
    Delete itab where itab EQ  '5003501080' 
    Delete itab where itab EQ  '5002996300'
    Delete itab where itab EQ '5002996407'
    Delete itab where itab EQ '5003587026'
    Delete itab where itab EQ  '5003587026'
    Delete itab where itab EQ  '5003493186'
    Delete itab where itab EQ  '5002720583'
    Delete itab where itab EQ '5002928122'
    Delete itab where itab EQ '5002628263'.
    Select
    Regards
    Bala.M
    Edited by: Bala Malvatu on Feb 7, 2008 9:18 PM

  • Snapshot Refresh taking More Time

    Dear All,
    We are facing a Snapshot refresh problem currently in Production Environment.
    Oracle Version : Oracle8i Enterprise Edition Release 8.1.6.1.0
    Currently we have created a Snapshot on a Join with 2 remote tables using Synonyms.
    ex:
    CREATE SNAPSHOT XYZ REFRESH COMPLETE WITH ROWID
    AS
    SELECT a.* FROM SYN1 a, SYN2 b
    Where b.ACCT_NO=a.ACCT_NO;
    We have created a Index on the above Snapshot XYZ.
    Create index XYZ_IDX1 on XYZ (ACCT_NO);
    a. The Explain plan of the above query shows the Index Scan on SYN1.
    If we query above Select Statement,it hardly takes 2 seconds to exedute.
    b. But the Complete Refresh of Snapshot XYZ is almost taking 20 Mins for just truncating and inserting 500 records and is generating huge Disk Reads as SYN1 in remote table consists of 32 Million records whereas SYN2 contains only 500 Records.
    If we truncate and insert inot a table as performed by the Complete refresh of Snapshot,it hardly takes 4 Seconds to refresh the table.
    Please let me know what might be the possible reasons for the Complete refresh of Snapshot taking more time.

    Dear All,
    While refreshing the Snapshot XYZ,I could find the following.
    a. Sort/Merge operation was performed while inserting the data into Snapshot.
    INSERT /*+ APPEND */ INTO "XYZ"
    SELECT a.* FROM SYN1 a, SYN2 b Where b.ACCT_NO=a.ACCT_NO;
    The above operation performed huge disk reads.
    b. By Changing the session parameter sort_area_size ,the time decreased by 50% but still the disk reads are huge.
    I would like to know why Sort/Merge Operation is performed in the above Insert?
    Edited by: Prashanth Deshmukh on Mar 13, 2009 10:54 AM
    Edited by: Prashanth Deshmukh on Mar 13, 2009 10:55 AM

  • Child Query taking more time

    Dear Gurus/Masters/All,
    I request your valuble assistance in tuning one of my SQL.
    We are using oracle 10.2.04 version and OS is HP-UX 11.23(ia64) version
    In my production environment one SQL is taking more time to complete the task. According to EXPLAIN PLAN, i observed that one of it's WHERE condition execution is causing the issue.
    I took the explain plan of the WHERE condition which is causing the issue. It is going for full table scan to satisfy the criteria. But a normal index exists on this column.
    Main Query WHERE condition and Explain Plan.
    SELECT column list ....
    FROM
        SIEBEL.S_ADDR_PER T1,
        SIEBEL.S_PTY_PAY_PRFL T2,
        SIEBEL.S_INVLOC T3,
        SIEBEL.S_ORDER T4,
        SIEBEL.S_ORG_EXT T5,
        SIEBEL.S_POSTN T6,
        SIEBEL.S_PARTY T7,
        SIEBEL.S_PROJ T8,
        SIEBEL.S_CON_ADDR T9,
        SIEBEL.S_ORG_EXT T10,
        SIEBEL.S_USER T11,
        SIEBEL.S_DOC_QUOTE T12,
        SIEBEL.S_ACCNT_POSTN T13,
        SIEBEL.S_INS_CLAIM T14,
        SIEBEL.S_USER T15,
        SIEBEL.S_ORG_EXT T16,
        SIEBEL.S_ASSET T17,
        SIEBEL.S_ORDER_TNTX T18,
        SIEBEL.S_ORG_EXT_TNTX T19,
        SIEBEL.S_PERIOD T20,
        SIEBEL.S_DEPOSIT_TNT T21,
        SIEBEL.S_ADDR_PER T22,
        SIEBEL.S_PAYMENT_TERM T23,
        SIEBEL.S_ORG_EXT_X T24,
        SIEBEL.S_ORG_EXT T25,
        SIEBEL.S_INSCLM_ELMNT T26,
        SIEBEL.S_INVOICE T27
    WHERE
       T25.BU_ID = T10.PAR_ROW_ID (+) AND
       T26.INSCLM_ID = T14.ROW_ID (+) AND
       T27.ELEMENT_ID = T26.ROW_ID (+) AND
       T27.LAST_UPD_BY = T15.PAR_ROW_ID (+) AND
       T4.QUOTE_ID = T12.ROW_ID (+) AND
       T3.CG_ASSSET_ID = T17.ROW_ID (+) AND
       T27.BL_ADDR_ID = T22.ROW_ID (+) AND
       T8.BU_ID = T5.PAR_ROW_ID (+) AND
       T27.PER_PAY_PRFL_ID = T2.ROW_ID (+) AND
       T27.REMIT_ORG_EXT_ID = T16.PAR_ROW_ID (+) AND
       T27.PROJ_ID = T8.ROW_ID (+) AND
       T27.BL_PERIOD_ID = T20.ROW_ID (+) AND
       T27.PAYMENT_TERM_ID = T23.ROW_ID (+) AND
       T12.BU_ID = T19.PAR_ROW_ID (+) AND
       T27.ACCNT_ID = T25.PAR_ROW_ID (+) AND
       T27.ORDER_ID = T18.ROW_ID (+) AND
       T4.SRC_INVLOC_ID = T3.ROW_ID (+) AND
       T27.ORDER_ID = T4.ROW_ID (+) AND
       T27.ACCNT_ID = T24.PAR_ROW_ID (+) AND
       T18.PR_DEPOSIT_ID = T21.ROW_ID (+) AND
       T27.BL_ADDR_ID = T9.ADDR_PER_ID (+) AND T27.ACCNT_ID = T9.ACCNT_ID (+) AND
       T27.BL_ADDR_ID = T1.ROW_ID (+) AND
       T25.PR_POSTN_ID = T13.POSITION_ID (+) AND T25.ROW_ID = T13.OU_EXT_ID (+) AND
       T13.POSITION_ID = T7.ROW_ID (+) AND
       T13.POSITION_ID = T6.PAR_ROW_ID (+) AND
       T6.PR_EMP_ID = T11.PAR_ROW_ID (+) AND
       (T27.INVC_TYPE_CD = :1)
    ORDER BY
       T27.INVC_DT;
    Explained.
    SQL> select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 2576210427
    | Id  | Operation                                              | Name              | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                                       |                   |    39M|    71G|       |   624M  (1)|278:42:59 |
    |   1 |  SORT ORDER BY                                         |                   |    39M|    71G|   150G|   624M  (1)|278:42:59 |
    |   2 |   NESTED LOOPS OUTER                                   |                   |    39M|    71G|       |   610M  (1)|272:11:24 |
    |   3 |    NESTED LOOPS OUTER                                  |                   |    39M|    70G|       |   515M  (1)|229:48:41 |
    |   4 |     NESTED LOOPS OUTER                                 |                   |    39M|    69G|       |   483M  (1)|215:41:04 |
    |   5 |      NESTED LOOPS OUTER                                |                   |    39M|    68G|       |   483M  (1)|215:41:04 |
    |   6 |       NESTED LOOPS OUTER                               |                   |    39M|    67G|       |   483M  (1)|215:41:04 |
    |   7 |        NESTED LOOPS OUTER                              |                   |    39M|    66G|       |   406M  (1)|181:17:50 |
    |   8 |         NESTED LOOPS OUTER                             |                   |    39M|    65G|       |   343M  (1)|153:12:57 |
    |   9 |          NESTED LOOPS OUTER                            |                   |    39M|    64G|       |   311M  (1)|139:04:56 |
    |  10 |           NESTED LOOPS OUTER                           |                   |    39M|    63G|       |   185M  (1)| 82:37:56 |
    |  11 |            NESTED LOOPS OUTER                          |                   |    39M|    54G|       |   108M  (1)| 48:11:29 |
    |  12 |             NESTED LOOPS OUTER                         |                   |    39M|    53G|       |   108M  (1)| 48:11:29 |
    |  13 |              NESTED LOOPS OUTER                        |                   |    39M|    51G|       |    76M  (1)| 34:03:51 |
    |  14 |               NESTED LOOPS OUTER                       |                   |    39M|    49G|       |    76M  (1)| 34:03:51 |
    |  15 |                NESTED LOOPS OUTER                      |                   |    39M|    46G|       |    76M  (1)| 34:03:51 |
    |  16 |                 NESTED LOOPS OUTER                     |                   |    39M|    44G|       |    76M  (1)| 34:03:51 |
    |  17 |                  NESTED LOOPS OUTER                    |                   |    39M|    40G|       |    65M  (1)| 29:25:49 |
    |  18 |                   NESTED LOOPS OUTER                   |                   |    39M|    39G|       |    65M  (1)| 29:25:49 |
    |  19 |                    NESTED LOOPS OUTER                  |                   |    39M|    38G|       |    65M  (1)| 29:25:49 |
    |  20 |                     NESTED LOOPS OUTER                 |                   |    39M|    34G|       |    65M  (1)| 29:17:44 |
    |  21 |                      NESTED LOOPS OUTER                |                   |    39M|    32G|       |    65M  (1)| 29:17:08 |
    |  22 |                       NESTED LOOPS OUTER               |                   |    39M|    31G|       |    65M  (1)| 29:09:04 |
    |  23 |                        NESTED LOOPS OUTER              |                   |    39M|    30G|       |  2043K  (9)| 00:54:42 |
    |  24 |                         NESTED LOOPS OUTER             |                   |    39M|    30G|       |  2043K  (9)| 00:54:42 |
    |  25 |                          NESTED LOOPS OUTER            |                   |    39M|    25G|       |  2015K  (7)| 00:53:57 |
    |  26 |                           NESTED LOOPS OUTER           |                   |    39M|    22G|       |  2015K  (7)| 00:53:57 |
    |  27 |                            NESTED LOOPS OUTER          |                   |    39M|    16G|       |  2015K  (7)| 00:53:57 |
    |* 28 |                             TABLE ACCESS FULL          | S_INVOICE         |    39M|     9G|       |  2015K  (7)| 00:53:57 |
    |  29 |                             TABLE ACCESS BY INDEX ROWID| S_PROJ            |     1 |   188 |       |     1   (0)| 00:00:01 |
    |* 30 |                              INDEX UNIQUE SCAN         | S_PROJ_P1         |     1 |       |       |     1   (0)| 00:00:01 |
    |  31 |                            TABLE ACCESS BY INDEX ROWID | S_PAYMENT_TERM    |     1 |   156 |       |     1   (0)| 00:00:01 |
    |* 32 |                             INDEX UNIQUE SCAN          | S_PAYMENT_TERM_P1 |     1 |       |       |     1   (0)| 00:00:01 |
    |  33 |                           TABLE ACCESS BY INDEX ROWID  | S_INSCLM_ELMNT    |     1 |    77 |       |     1   (0)| 00:00:01 |
    |* 34 |                            INDEX UNIQUE SCAN           | S_INSCLM_ELMNT_P1 |     1 |       |       |     1   (0)| 00:00:01 |
    |  35 |                          TABLE ACCESS BY INDEX ROWID   | S_INS_CLAIM       |     1 |   134 |       |     1   (0)| 00:00:01 |
    |* 36 |                           INDEX UNIQUE SCAN            | S_INS_CLAIM_P1    |     1 |       |       |     1   (0)| 00:00:01 |
    |  37 |                         TABLE ACCESS BY INDEX ROWID    | S_PERIOD          |     1 |    19 |       |     1   (0)| 00:00:01 |
    |* 38 |                          INDEX UNIQUE SCAN             | S_PERIOD_P1       |     1 |       |       |     1   (0)| 00:00:01 |
    |  39 |                        TABLE ACCESS BY INDEX ROWID     | S_USER            |     1 |    25 |       |     2   (0)| 00:00:01 |
    |* 40 |                         INDEX UNIQUE SCAN              | S_USER_U2         |     1 |       |       |     1   (0)| 00:00:01 |
    |  41 |                       TABLE ACCESS BY INDEX ROWID      | S_ORDER_TNTX      |     1 |    26 |       |     2   (0)| 00:00:01 |
    |* 42 |                        INDEX UNIQUE SCAN               | S_ORDER_TNTX_P1   |     1 |       |       |     1   (0)| 00:00:01 |
    |  43 |                      TABLE ACCESS BY INDEX ROWID       | S_DEPOSIT_TNT     |     1 |    45 |       |     1   (0)| 00:00:01 |
    |* 44 |                       INDEX UNIQUE SCAN                | S_DEPOSIT_TNT_P1  |     1 |       |       |     1   (0)| 00:00:01 |
    |  45 |                     TABLE ACCESS BY INDEX ROWID        | S_ORDER           |     1 |   101 |       |     2   (0)| 00:00:01 |
    |* 46 |                      INDEX UNIQUE SCAN                 | S_ORDER_P1        |     1 |       |       |     1   (0)| 00:00:01 |
    |  47 |                    TABLE ACCESS BY INDEX ROWID         | S_INVLOC          |     1 |    47 |       |     1   (0)| 00:00:01 |
    |* 48 |                     INDEX UNIQUE SCAN                  | S_INVLOC_P1       |     1 |       |       |     1   (0)| 00:00:01 |
    |  49 |                   TABLE ACCESS BY INDEX ROWID          | S_DOC_QUOTE       |     1 |    21 |       |     1   (0)| 00:00:01 |
    |* 50 |                    INDEX UNIQUE SCAN                   | S_DOC_QUOTE_P1    |     1 |       |       |     1   (0)| 00:00:01 |
    |* 51 |                  TABLE ACCESS FULL                     | S_ORG_EXT_TNTX    |     1 |    94 |       |     0   (0)| 00:00:01 |
    |  52 |                 TABLE ACCESS BY INDEX ROWID            | S_PTY_PAY_PRFL    |     1 |    74 |       |     1   (0)| 00:00:01 |
    |* 53 |                  INDEX UNIQUE SCAN                     | S_PTY_PAY_PRFL_P1 |     1 |       |       |     1   (0)| 00:00:01 |
    |  54 |                TABLE ACCESS BY INDEX ROWID             | S_ADDR_PER        |     1 |    84 |       |     2   (0)| 00:00:01 |
    |* 55 |                 INDEX UNIQUE SCAN                      | S_ADDR_PER_P1     |     1 |       |       |     1   (0)| 00:00:01 |
    |  56 |               TABLE ACCESS BY INDEX ROWID              | S_ADDR_PER        |     1 |    57 |       |     1   (0)| 00:00:01 |
    |* 57 |                INDEX UNIQUE SCAN                       | S_ADDR_PER_P1     |     1 |       |       |     1   (0)| 00:00:01 |
    |  58 |              TABLE ACCESS BY INDEX ROWID               | S_ORG_EXT         |     1 |    32 |       |     1   (0)| 00:00:01 |
    |* 59 |               INDEX UNIQUE SCAN                        | S_ORG_EXT_U3      |     1 |       |       |     1   (0)| 00:00:01 |
    |  60 |             TABLE ACCESS BY INDEX ROWID                | S_ORG_EXT         |     1 |    32 |       |     1   (0)| 00:00:01 |
    |* 61 |              INDEX UNIQUE SCAN                         | S_ORG_EXT_U3      |     1 |       |       |     1   (0)| 00:00:01 |
    |  62 |            TABLE ACCESS BY INDEX ROWID                 | S_ORG_EXT         |     1 |   256 |       |     2   (0)| 00:00:01 |
    |* 63 |             INDEX UNIQUE SCAN                          | S_ORG_EXT_U3      |     1 |       |       |     1   (0)| 00:00:01 |
    |  64 |           TABLE ACCESS BY INDEX ROWID                  | S_ACCNT_POSTN     |     1 |    32 |       |     3   (0)| 00:00:01 |
    |* 65 |            INDEX RANGE SCAN                            | S_ACCNT_POSTN_U1  |     1 |       |       |     2   (0)| 00:00:01 |
    |  66 |          TABLE ACCESS BY INDEX ROWID                   | S_POSTN           |     1 |    21 |       |     1   (0)| 00:00:01 |
    |* 67 |           INDEX UNIQUE SCAN                            | S_POSTN_U2        |     1 |       |       |     1   (0)| 00:00:01 |
    |  68 |         TABLE ACCESS BY INDEX ROWID                    | S_USER            |     1 |    25 |       |     2   (0)| 00:00:01 |
    |* 69 |          INDEX UNIQUE SCAN                             | S_USER_U2         |     1 |       |       |     1   (0)| 00:00:01 |
    |  70 |        TABLE ACCESS BY INDEX ROWID                     | S_ORG_EXT         |     1 |    32 |       |     2   (0)| 00:00:01 |
    |* 71 |         INDEX UNIQUE SCAN                              | S_ORG_EXT_U3      |     1 |       |       |     1   (0)| 00:00:01 |
    |  72 |       TABLE ACCESS BY INDEX ROWID                      | S_ASSET           |     1 |    24 |       |     2   (0)| 00:00:01 |
    |* 73 |        INDEX UNIQUE SCAN                               | S_ASSET_P1        |     1 |       |       |     2   (0)| 00:00:01 |
    |  74 |      TABLE ACCESS BY INDEX ROWID                       | S_CON_ADDR        |     1 |    36 |       |     3   (0)| 00:00:01 |
    |* 75 |       INDEX RANGE SCAN                                 | S_CON_ADDR_U1     |     1 |       |       |     2   (0)| 00:00:01 |
    |* 76 |     INDEX UNIQUE SCAN                                  | S_PARTY_P1        |     1 |    12 |       |     1   (0)| 00:00:01 |
    |  77 |    TABLE ACCESS BY INDEX ROWID                         | S_ORG_EXT_X       |     1 |    37 |       |     2   (0)| 00:00:01 |
    |* 78 |     INDEX RANGE SCAN                                   | S_ORG_EXT_X_U1    |     1 |       |       |     2   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
      28 - filter("T27"."INVC_TYPE_CD"=:1)
      30 - access("T27"."PROJ_ID"="T8"."ROW_ID"(+))
      32 - access("T27"."PAYMENT_TERM_ID"="T23"."ROW_ID"(+))
      34 - access("T27"."ELEMENT_ID"="T26"."ROW_ID"(+))
      36 - access("T26"."INSCLM_ID"="T14"."ROW_ID"(+))
      38 - access("T27"."BL_PERIOD_ID"="T20"."ROW_ID"(+))
      40 - access("T27"."LAST_UPD_BY"="T15"."PAR_ROW_ID"(+))
      42 - access("T27"."ORDER_ID"="T18"."ROW_ID"(+))
      44 - access("T18"."PR_DEPOSIT_ID"="T21"."ROW_ID"(+))
      46 - access("T27"."ORDER_ID"="T4"."ROW_ID"(+))
      48 - access("T4"."SRC_INVLOC_ID"="T3"."ROW_ID"(+))
      50 - access("T4"."QUOTE_ID"="T12"."ROW_ID"(+))
      51 - filter("T12"."BU_ID"="T19"."PAR_ROW_ID"(+))
      53 - access("T27"."PER_PAY_PRFL_ID"="T2"."ROW_ID"(+))
      55 - access("T27"."BL_ADDR_ID"="T1"."ROW_ID"(+))
      57 - access("T27"."BL_ADDR_ID"="T22"."ROW_ID"(+))
      59 - access("T8"."BU_ID"="T5"."PAR_ROW_ID"(+))
      61 - access("T27"."REMIT_ORG_EXT_ID"="T16"."PAR_ROW_ID"(+))
      63 - access("T27"."ACCNT_ID"="T25"."PAR_ROW_ID"(+))
      65 - access("T25"."ROW_ID"="T13"."OU_EXT_ID"(+) AND "T25"."PR_POSTN_ID"="T13"."POSITION_ID"(+))
      67 - access("T13"."POSITION_ID"="T6"."PAR_ROW_ID"(+))
      69 - access("T6"."PR_EMP_ID"="T11"."PAR_ROW_ID"(+))
      71 - access("T25"."BU_ID"="T10"."PAR_ROW_ID"(+))
      73 - access("T3"."CG_ASSSET_ID"="T17"."ROW_ID"(+))
      75 - access("T27"."BL_ADDR_ID"="T9"."ADDR_PER_ID"(+) AND "T27"."ACCNT_ID"="T9"."ACCNT_ID"(+))
           filter("T27"."ACCNT_ID"="T9"."ACCNT_ID"(+))
      76 - access("T13"."POSITION_ID"="T7"."ROW_ID"(+))
      78 - access("T27"."ACCNT_ID"="T24"."PAR_ROW_ID"(+))
    117 rows selected.SQL> EXPLAIN PLAN FOR
    2 SELECT * FROM SIEBEL.S_INVOICE T27 WHERE T27.INVC_TYPE_CD=:1;
    Explained.
    SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
    PLAN_TABLE_OUTPUT
    Plan hash value: 1810797629
    | Id  | Operation         | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |           |    39M|     9G|  2016K  (8)| 00:53:59 |
    |*  1 |  TABLE ACCESS FULL| S_INVOICE |    39M|     9G|  2016K  (8)| 00:53:59 |
    Predicate Information (identified by operation id):
       1 - filter("T27"."INVC_TYPE_CD"=:1)
    13 rows selected.Edited by: KODS on Feb 13, 2013 1:08 PM

    Dear Ivan,
    Please find the details below.
    select * from dba_indexes where index_name = 'S_INVOICE_U1';
    OWNER                          INDEX_NAME                     INDEX_TYPE                  TABLE_OWNER                    TABLE_NAME                     TABLE_TYPE  UNIQUENESS COMPRESSION PREFIX_LENGTH TABLESPACE_NAME                INI_TRANS MAX_TRANS INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE PCT_THRESHOLD INCLUDE_COLUMN FREELISTS FREELIST_GROUPS PCT_FREE LOGGING BLEVEL LEAF_BLOCKS DISTINCT_KEYS AVG_LEAF_BLOCKS_PER_KEY AVG_DATA_BLOCKS_PER_KEY CLUSTERING_FACTOR STATUS   NUM_ROWS SAMPLE_SIZE LAST_ANALYZED DEGREE                                   INSTANCES                                PARTITIONED TEMPORARY GENERATED SECONDARY BUFFER_POOL USER_STATS DURATION        PCT_DIRECT_ACCESS ITYP_OWNER                     ITYP_NAME                      PARAMETERS                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               GLOBAL_STATS DOMIDX_STATUS DOMIDX_OPSTATUS FUNCIDX_STATUS JOIN_INDEX IOT_REDUNDANT_PKEY_ELIM DROPPED
    SIEBEL                         S_INVOICE_U1                   NORMAL                      SIEBEL                         S_INVOICE                      TABLE       UNIQUE     DISABLED                  CRMSBL_AEM_INDEX                       2       255          65536                       1  2147483645                                                                           10 NO           3      902796     196739390                       1                       1         125598294 VALID    196739390   196739390 10-02-13      1                                        1                                        NO          N         N         N         DEFAULT     NO                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  YES                                                       NO         NO                      NO     
    select * from dba_ind_columns where index_name = 'S_INVOICE_U1' order by column_position;
    INDEX_OWNER                    INDEX_NAME                     TABLE_OWNER                    TABLE_NAME                     COLUMN_NAME                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      COLUMN_POSITION COLUMN_LENGTH CHAR_LENGTH DESCEND
    SIEBEL                         S_INVOICE_U1                   SIEBEL                         S_INVOICE                      INVC_NUM                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       1           200          50 ASC    
    SIEBEL                         S_INVOICE_U1                   SIEBEL                         S_INVOICE                      INVC_TYPE_CD                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   2           120          30 ASC    
    SIEBEL                         S_INVOICE_U1                   SIEBEL                         S_INVOICE                      CONFLICT_ID                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    3            60          15 ASC    

  • Oracle 11g: Oracle insert/update operation is taking more time.

    Hello All,
    In Oracle 11g (Windows 2008 32 bit environment) we are facing following issue.
    1) We are inserting/updating data on some tables (4-5 tables and we are firing query with very high rate).
    2) After sometime (say 15 days with same load) we are feeling that the Oracle operation (insert/update) is taking more time.
    Query1: How to find actually oracle is taking more time in insert/updates operation.
    Query2: How to rectify the problem.
    We are having multithread environment.
    Thanks
    With Regards
    Hemant.

    Liron Amitzi wrote:
    Hi Nicolas,
    Just a short explanation:
    If you have a table with 1 column (let's say a number). The table is empty and you have an index on the column.
    When you insert a row, the value of the column will be inserted to the index. To insert 1 value to an index with 10 values in it will be fast. It will take longer to insert 1 value to an index with 1 million values in it.
    My second example was if I take the same table and let's say I insert 10 rows and delete the previous 10 from the table. I always have 10 rows in the table so the index should be small. But this is not correct. If I insert values 1-10 and then delete 1-10 and insert 11-20, then delete 11-20 and insert 21-30 and so on, because the index is sorted, where 1-10 were stored I'll now have empty spots. Oracle will not fill them up. So the index will become larger and larger as I insert more rows (even though I delete the old ones).
    The solution here is simply revuild the index once in a while.
    Hope it is clear.
    Liron Amitzi
    Senior DBA consultant
    [www.dbsnaps.com]
    [www.orbiumsoftware.com]Hmmm, index space not reused ? Index rebuild once a while ? That was what I understood from your previous post, but nothing is less sure.
    This is a misconception of how indexes are working.
    I would suggest the reading of the following interasting doc, they are a lot of nice examples (including index space reuse) to understand, and in conclusion :
    http://richardfoote.files.wordpress.com/2007/12/index-internals-rebuilding-the-truth.pdf
    "+Index Rebuild Summary+
    +•*The vast majority of indexes do not require rebuilding*+
    +•Oracle B-tree indexes can become “unbalanced” and need to be rebuilt is a myth+
    +•*Deleted space in an index is “deadwood” and over time requires the index to be rebuilt is a myth*+
    +•If an index reaches “x” number of levels, it becomes inefficient and requires the index to be rebuilt is a myth+
    +•If an index has a poor clustering factor, the index needs to be rebuilt is a myth+
    +•To improve performance, indexes need to be regularly rebuilt is a myth+"
    Good reading,
    Nicolas.

  • Taking More Time while inserting into the table (With foriegn key)

    Hi All,
    I am facing problem while inserting the values into the master table.
    The problem,
    Table A -- User Master Table (Reg No, Name, etc)
    Table B -- Transaction Table (Foreign key reference with Table A).
    While inserting the data's in Table B, i need to insert the reg no also in table B which is mandatory. I followed the logic which is mentioned in the SRDemo.
    While inserting we need to query the Table A first to have the values in TableABean.java.
    final TableA tableA= (TableA )uow.executeQuery("findUser",TableA .class, regNo);
    Then, we need to create the instance for TableB
    TableB tableB= (TableB)uow.newInstance(TableB.class);
    tableB.setID(bean.getID);
    tableA.addTableB(tableB); --- this is for to insert the regNo of TableA in TableB.. This line is executing the query "select * from TableB where RegNo = <tableA.getRegNo>".
    This query is taking too much time if values are more in the TableB for that particular registrationNo. Because of this its taking more time to insert into the TableB.
    For Ex: TableA -- regNo : 101...having less entry in TableB means...inserting record is taking less than 1 sec
    regNo : 102...having more entry in TableB means...inserting record is taking more than 2 sec
    Time delay is there for different users when they enter transaction in TableB.
    I need to avoid this since in future it will take more time...from 2 sec to 10 sec, if volume of data increases mean.
    Please help me to resolve this issue...I am facing it now in production.
    Thanks & Regards
    VB

    Hello,
    Looks like you have a 1:M relationship from TableA to TableB, with a 1:1 back pointer from TableB to TableA. If triggering the 1:M relationship is causing you delays that you want to avoid there might be two quick ways I can see:
    1) Don't map it. Leave the TableA->TableB 1:M unmapped, and instead just query for relationship when you do need it. This means you do not need to call tableA.addTableB(tableB), and instead only need to call tableB.setTableA(tableA), so that the TableB->TableA relation gets set. Might not be the best option, but it depends on your application's usage. It does allow you to potentially page the TableB results or add other query query performance options when you do need the data though.
    2) You are currently using Lazy loading for the TableA->TableB relationship - if it is untriggered, don't bother calling tableA.addTableB(tableB), and instead only need to call tableB.setTableA(tableA). This of course requires using TopLink api to a) verify the collection is an IndirectCollection type, and b) that it is hasn't been triggered. If it has been triggered, you will still need to call tableA.addTableB(tableB), but it won't result in a query. Check out the oracle.toplink.indirection.IndirectContainer class and it's isInstantiated() method. This can cause problems though in highly concurrent environments, as other threads may have triggered the indirection before you commit your transaction, so that the A->B collection is not up to date - this might require refreshing the TableA if so.
    Change tracking would probably be the best option to use here, and is described in the EclipseLink wiki:
    http://wiki.eclipse.org/Introduction_to_EclipseLink_Transactions_(ELUG)#Attribute_Change_Tracking_Policy
    Best Regards,
    Chris

  • Oracle Drop command taking more time in AIX When compared to Windows

    Hi
    We are firing a normal Drop command on our database and the databse version is 10.2.0.4.The catabase is running on AIX v5.The command is taking more time than usual .
    There are no waits on session.Let me try to put the scenario in more simple terms.I have a nested table NT_TEST with record count 0 and i am dropping the statement using "Drop table NT_TEST" in windows it is getting dropped say some 218 Milli seconds.
    The same table when i am dropping it in AIX it is taking around 6 seconds.
    There are no locks ,Flashback is off,Triggers are not involved.Drop is not waiting on any transaction to complete.
    Could anybody help me out on this.

    Quite possible. On most Unixes asynchronous I/O requires purchasing extra options, and most sites just purchase the default O/S. Or asynchronous I/O is not enabled by default or the database is located on an ufs file system.
    You provided no info at all on your AIX configuration. AIX does have asynchronous I/O, it is not always enabled, and the number of slaves is usually way too low.
    As root, run smit aio and report the results.
    At his point your unfavorable comparison of Windows and AIX is quite unfair. Unix doesn't run out of the box.
    You know that famous joke 'If operating systems were airplanes'?
    In that joke, the Unix airplane is assembled on the spot, but the Windows airplane is three months late.
    Sybrand Bakker
    Senior Oracle DBA

  • CatSearch taking more time than full table scan

    Hi
    I have a table which has close to 140 million records. I had been exploring the option of using oracle text for search. So , I created an index(ctxcat) on the column Name by the following query.
    begin
         ctx_ddl.create_preference('FT_WL', 'BASIC_WORDLIST');
         ctx_ddl.set_attribute ('FT_WL', 'prefix-index','TRUE');
    end;
    create index history_namex on history(name) indextype is ctxsys.ctxcat parameters ('WORDLIST FT_WL');
    But when I executed the following query , I have found out that catsearch is taking more time. The queries and thier stats are :-
    1. select * from history where catsearch(name, 'Jake%', null) > 0 and rownum < 200;
    Elapsed : 00 : 00 : 00.13
    Statistics :
    112 recursive calls
    0 db block gets
    413 consistent gets
    28 physical reads
    0 redo size
    33168 bytes sent via SQL*Net to client
    663 bytes receuved via SQL*Net from client
    15 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    199 rows processed
    2. select * from history where name like 'Jake%' and rownum < 200;
    Elapsed : 00 : 00 : 00.05
    Statistics :
    1 recursive calls
    0 db block gets
    220 consistent gets
    383 physical reads
    0 redo size
    26148 bytes sent via SQL*Net to client
    663 bytes receuved via SQL*Net from client
    15 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    199 rows processed
    Can anyone explain why this is happening?
    PS : there is no conventional index on the name column.
    Edited by: 976934 on Dec 14, 2012 3:32 AM

    The asterisk (*) is simply the correct syntax for a wildcard using catsearch. If you use % instead, then you will not get the same results. Please see the section of the online documentation below, that shows that the asterisk is the wildcard for catsearch.
    http://docs.oracle.com/cd/E11882_01/text.112/e24436/csql.htm#CHDJBGHE
    Additionally, if you want to limit the rows, then you need to get the matching results in an inner sub-query, then use the rownum in an outer query. The way that you were doing it, it first limits the rows to the first 200, then checks which of those meet the criteria, instead of the other way around. So, the correct syntax should be the following, which should also be the most efficient.
    select * from  
           (select * from history
            where  catsearch (name, 'Jake*', null) > 0)
    where  rownum < 200;

  • Currency translation taking more time at first time in the report

    Hi All,
    Here is an issue regarding the currency translation in the report. when we click on the currency translation from the contaxt menu on the report, its taking more time for the first time to get the selection options. But it is fast from the second time onwards. It will be not user friendly if its takes more time for the first time. Is there any way to fast up the processing time for the first time when i go for the "currency translation" option at report level for the first time.
    let me know why it takes more time for the first time when we go for this option at report level.
    Thanks,
    Jack

    Once again from the top.
    This is undoubtedly not a database issue.
    I doubt you can fix it in the database.
    You can, however, spend a lot of hours asking questions and poking around if you are a consultant paid by the hour.
    But as long as you are looking for something to do here are some that won't fix the problem but may be worth a few minutes of your time.
    WHERE 1 = 1Are you kidding? Drop this nonsense. The Oracle optimizer is not brain dead. If it were my database I would also drop the parallel hint like a bad habit.
    /*+ parallel(rp1, 8) */Again the Oracle optimizer is not brain dead. Ask for parallel threads that don't exist and the database will just queue your SQL and let it sit there until sufficient resources become available.

  • Essbase Calculation Script taking more time in new environment

    Hi Everyone:
    We have four environments in our implementation.
    1. DEV Environment - 64 bit Essbase Version 11.1.1.3
    2. PreProd Environment - 32 bit Essbase Version 9.3.0
    3. PreProd Environment - 64 bit Essbase Version 11.1.1.3
    In the above mentioned environment PreProd Environment - 64 bit Essbase Version 11.1.1.3 is a newly installed
    environment.
    We have migrated our Application from PreProd Environment - 32 bit Essbase Version 9.3.0 to PreProd Environment - 64 bit Essbase Version 11.1.1.3. A calculation script that takes only 20 minutes in 32 bit PreProd is taking more than
    5 and half hours in newly installed 64 bit PreProd.
    We have also migrated our Application from DEV Environment - 64 bit Essbase Version 11.1.1.3 to PreProd Environment - 64 bit Essbase Version 11.1.1.3. The calculation script that takes only 20 minutes in 64 bit Dev is taking more than 5 and half hours in newly installed 64 bit PreProd.
    All the server settings and cache setting everything looks similar in all the three environments.
    Please advice us what are all the possibilities that creates the issue.
    Thanks and Regards,
    Prabhakar.

    Hi Cameron,
    Thanks for your reply.
    I have cross checked the Virtual memory in both servers,in new server it was declared high.
    Please find the cfg setting which we are using in our application.
    AGENTPORT 1423
    SERVERPORTBEGIN 32768
    SERVERPORTEND 33768
    AGENTDESC hypservice_1
    ;CSSREFRESHLEVEL auto
    ;SHAREDSERVICESREFRESHINTERVAL 30
    CALCCACHEHIGH 199999999
    CALCCACHEDEFAULT 150000000
    CALCCACHELOW     10000000
    CALCLOCKBLOCKDEFAULT 3000
    DATAERRORLIMIT 10000
    UPDATECALC FALSE
    EXCEPTIONLOGOVERWRITE FALSE
    CALCREUSEDYNCALCBLOCKS FALSE
    PORTUSAGELOGINTERVAL 15
    QRYGOVEXECTIME 600
    LOGMESSAGELEVEL INFO
    CALCPARALLEL 6
    MAXLOGINS 100000
    AGENTDELAY 100
    AGENTTHREADS 30
    AGTSVRCONNECTIONS 10
    SERVERTHREADS 25
    EXPORTTHREADS 1
    SSLOGUNKNOWN FALSE
    CALCNOTICEDEFAULT 10
    NETRETRYCOUNT 3000
    NETDELAY 2000
    __SM__BUFFERED_IO TRUE
    __SM__WAITED_IO TRUE
    and aslo find the caches that we define:
    Index cache:250000
    Data Cache:250000
    Data file cache:32768
    The all above settings are identical both servers.
    In New server ,only one script that is taking more time but remaining scripts are working fine with less time.
    We also did one test cause that splitting the script in to multiple and executed ,in this cause the script where we are using direct assigning value from member(say A1) to another member(Say A2) is taking more time.But same scripts we executed in old server it executes fine.
    Still we are not able to find out exact root cause for this issue.
    Could please anyone help me to resove this issue.
    Regards,
    Prabhakar.

  • Which statement is taking more time in a block?

    Hi,
    I have a plsql block with thousands of sql statements in it, line by line.
    My query is how can i know which particular sql statement is taking more time.
    Thanks,
    VInod

    910575 wrote:
    This is not the answer i expected.Having a 1000 SQLs statements in a single PL/SQL does not make any sense. Fact.
    This is not how one modularise software. And modularisation is a critically important fundamental.
    Each SQL means I/O. I/O is the single most expensive database operation. More I/O means slower performance.
    So why is a 1000+ SQL statements needed? Do these pull data into PL/SQL? If so, why? What does PL/SQL do with the data returned by these SQLs? Do the SQLs use bind variables? Can the SQLs be combined? What are the business requirements that need to be met?
    I just want to find which sql statement is taking more time in a procedure/bock.Not the correct approach. Performance need to look at the COMPLETE process. Not a single step in the process.
    Performance is a result of a sound design and proper implementation of this design into programming language code. It is not focusing on a single line of code and saying that is the problem and need to be fixed. The problem can be in the design. Can be in how that was written. And not in a single line of code.
    And seeing that you have 1000+ SQL statements in a single PL/SQL block - that IS an indication of a basic design flaw.

  • Source System Extraction taking more time

    Hi All,
    I Have an Issue, please help me out in this.
    We have two source systems in our process. One is working fine. We dont have any issue with that. But another source system taking more time to extract the data in the source system than usual. From few days only we are facing this problem. Record count is also normal. I am unable find root cause for this, please help me out regarding this issue.
    It is Full update. We are using Custom program to extract the data. It is running daily.
    Thanks in Advance.
    Regards,
    Suresh
    Edited by: sureshd on Jul 14, 2011 6:04 PM
    Edited by: sureshd on Jul 14, 2011 6:05 PM

    When a long running job is running in the source system side you can trace it through ST05. Simultaneously you can monitor the screen of SM50/SM66 to see what are the tables being accessed during the job.
    After the loading is completed, you can deactivate the trace and then go to the Display trace option where you would see various number of SQL statements along with their tables. Check which particular statement is an expensive one by looking at the time stamp.
    Then next job is to decide why that table is being accessed for so much of time and how to improve the run time of the table. check the fields inside the table and their selectivity and see wether any index already exist on that. You can do this by going into SE11. If index is not available on those specific fields ask your Basis Guy to create a secondary one on top of it which may help in better performance. hope it helps.

Maybe you are looking for

  • 3D graph issues in 8.6

      I'm trying to program a simple 3D simulation in LabVIEW and am running into numerous issues with the 3D graphs. 1) An old program I had used the 3D ActiveX graph.  When I load that VI, LV says it could not load the ActiveX control.  I never intenti

  • HT3775 I have a video file that is under quick play .mov and my macbook is telling me that it cannot read the file?

    I am trying to record something on my desktop and I recorded it with an application called iscreen recorder lite. I downloaded it off of the application store thinking it would save under a file my computer would recognize. When I tried to play the r

  • In search of a sample application

    Folks, I 've been searching for hours for a simple sample jsp application that uses beans to interact with a database and has add, edit, delete functionality. I'm sure their are oodles of them out there somewhere but it's proving a nightmare trying t

  • Abap code with relevant capital lettres and small letters

    Hi all, i wrote my code in capital letters and i want to change tables and data objects and other stuff into small letters .Is there any option in abap editor to change the code  as per the SAP standards. Thanks, Madhu

  • How to find which field is erroring

    Hi Can anyone out there tell me if there is a way in Forms 6i to find out which field on a block is raising an error? I have a situation where entering duff data into a field causes an error to be raised (the ON-ERROR trigger for that block is fired)