Performance issue in a custom table

Hi All,
I have a ztable used in a program wherin I have a doubt of performance issue in selection.Its like :
    SELECT ship_no invoice_no
      INTO TABLE it_ship_no_hist
      FROM zco_cust_hist
      FOR ALL ENTRIES IN it_freight
      WHERE ship_no = it_freight-tknum.
there are 7 key fields in this table out of which one ( tknum ) is used in a where condition.The table is without any index.
   For performance purpose should I create an index with the very field 'tknum' in the index..can I do that or index should be created only along with non key fields.

Hi,
a table has - besides a few exceptions - always one index that is the primary key. The fields are the key fields in the same order as in the table.
The primary key is always there and therefore not displayed under the botton 'index'.
Is tknum a key field? What are the key fields in correct order? If it is in the key and maybe the first one, then it does not make sense that you create an index.
Siegfried

Similar Messages

Performance issue with a Custom view

Hi ,
I am pretty new to performance tuning and facing a performance issue with a custom view.
Execution time for view query is good but as soon as I append a where caluse to view query ,the execution time increases.
Below is the view query:
CREATE OR REPLACE XXX_INFO_VIEW AS
SELECT csb.system_id license_id,
cst.name license_number ,
csb.system_type_code license_type ,
csb.attribute3 lac , -- license authorization code
csb.attribute6 lat , -- license admin token
csb.attribute12 ols_reg, -- OLS Registration allowed flag
l.attribute4 license_biz_type ,
NVL (( SELECT 'Y' l_supp_flag
FROM csi_item_instances cii,
okc_k_lines_b a,
okc_k_items c
WHERE c.cle_id = a.id
AND a.lse_id = 9
AND c.jtot_object1_code = 'OKX_CUSTPROD'
AND c.object1_id1 = cii.instance_id||''
AND cii.instance_status_id IN (3, 510)
AND cii.system_id = csb.system_id
AND a.sts_code IN ('SIGNED', 'ACTIVE')
AND NVL (a.date_terminated, a.end_date) > SYSDATE
AND ROWNUM < 2), 'N') active_supp_flag,
hp.party_name "Customer_Name" , -- Customer Name
hca.attribute12 FGE_FLAG,
(SELECT /*+INDEX (oklt OKC_K_LINES_TL_U1) */
nvl(max((decode(name, 'eSupport','2','Enterprise','1','Standard','1','TERM RTU','0','TERM RTS','0','Notfound'))),0) covName --TERM RTU and TERM RTS added as per Vijaya's suggestion APR302013
FROM OKC_K_LINES_B oklb1,
OKC_K_LINES_TL oklt,
OKC_K_LINES_B oklb2,
OKC_K_ITEMS oki,
CSI_item_instances cii
WHERE
OKI.JTOT_OBJECT1_CODE = 'OKX_CUSTPROD'
AND oklb1.id=oklt.id
AND OKI.OBJECT1_ID1 =cii.instance_id||''
AND Oklb1.lse_id=2
AND oklb1.dnz_chr_id=oklb2.dnz_chr_id
AND oklb2.lse_id=9
AND oki.CLE_ID=oklb2.id
AND cii.system_id=csb.system_id
AND oklt.LANGUAGE=USERENV ('LANG')) COVERAGE_TYPE
FROM csi_systems_b csb ,
csi_systems_tl cst ,
hz_cust_accounts hca,
hz_parties hp,
fnd_lookup_values l
WHERE csb.system_type_code = l.lookup_code (+)
AND csb.system_id = cst.system_id
AND hca.cust_account_id =csb.customer_id
AND hca.party_id= hp.party_id
AND cst.language = USERENV ('LANG')
AND l.lookup_type (+) = 'CSI_SYSTEM_TYPE'
AND l.language (+) = USERENV ('LANG')
AND NVL (csb.end_date_active, SYSDATE+1) > SYSDATE)
I have forced an index to avoid Full table scan on OKC_K_LINES_TL and suppressed an index on CSI_item_instances.instance id to make the view query fast.
So when i do select * from XXX_INFO_VIEWit executes in a decent time,But when I try to do
select * from XXX_INFO_VIEW where active_supp_flag='Y' and coverage_type='1'
it takes lot of time.
Execution plan is same for both queries in terms of cost but with WHERE clause Number of bytes increases.
Below are the execution plans:
View query:
SELECT STATEMENT ALL_ROWS Cost: 7,212 Bytes: 536,237 Cardinality: 3,211
     10 COUNT STOPKEY
          9 NESTED LOOPS
               7 NESTED LOOPS Cost: 1,085 Bytes: 101 Cardinality: 1
                    5 NESTED LOOPS Cost: 487 Bytes: 17,043 Cardinality: 299
                         2 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 2,325 Cardinality: 155
                              1 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315
                         4 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2
                              3 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2
                    6 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1
               8 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1
     12 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 2 Bytes: 7 Cardinality: 1
          11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1
     28 SORT AGGREGATE Bytes: 169 Cardinality: 1
          27 NESTED LOOPS
               25 NESTED LOOPS Cost: 16,549 Bytes: 974,792 Cardinality: 5,768
                    23 NESTED LOOPS Cost: 5,070 Bytes: 811,737 Cardinality: 5,757
                         20 NESTED LOOPS Cost: 2,180 Bytes: 56,066 Cardinality: 578
                              17 NESTED LOOPS Cost: 967 Bytes: 32,118 Cardinality: 606
                                   14 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 3,465 Cardinality: 315
                                        13 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315
                                   16 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2
                                        15 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2
                              19 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1
                                   18 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1
                         22 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 5 Bytes: 440 Cardinality: 10
                              21 INDEX RANGE SCAN INDEX OKC.OKC_K_LINES_B_N2 Cost: 2 Cardinality: 9
                    24 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_TL_U1 Cost: 1 Cardinality: 1
               26 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_TL Cost: 2 Bytes: 28 Cardinality: 1
     43 HASH JOIN Cost: 7,212 Bytes: 536,237 Cardinality: 3,211
          41 NESTED LOOPS
               39 NESTED LOOPS Cost: 7,070 Bytes: 485,792 Cardinality: 3,196
                    37 HASH JOIN Cost: 676 Bytes: 341,972 Cardinality: 3,196
                         32 HASH JOIN RIGHT OUTER Cost: 488 Bytes: 310,012 Cardinality: 3,196
                              30 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_LOOKUP_VALUES Cost: 7 Bytes: 544 Cardinality: 17
                                   29 INDEX RANGE SCAN INDEX (UNIQUE) APPLSYS.FND_LOOKUP_VALUES_U1 Cost: 3 Cardinality: 17
                              31 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_B Cost: 481 Bytes: 207,740 Cardinality: 3,196
                         36 VIEW VIEW AR.index$_join$_013 Cost: 187 Bytes: 408,870 Cardinality: 40,887
                              35 HASH JOIN
                                   33 INDEX FAST FULL SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 112 Bytes: 408,870 Cardinality: 40,887
                                   34 INDEX FAST FULL SCAN INDEX AR.HZ_CUST_ACCOUNTS_N2 Cost: 122 Bytes: 408,870 Cardinality: 40,887
                    38 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1
               40 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 2 Bytes: 45 Cardinality: 1
          42 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_TL Cost: 142 Bytes: 958,770 Cardinality: 63,918
Execution plan for view query with WHERE clause:
SELECT STATEMENT ALL_ROWS Cost: 7,212 Bytes: 2,462,837 Cardinality: 3,211
     10 COUNT STOPKEY
          9 NESTED LOOPS
               7 NESTED LOOPS Cost: 1,085 Bytes: 101 Cardinality: 1
                    5 NESTED LOOPS Cost: 487 Bytes: 17,043 Cardinality: 299
                         2 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 2,325 Cardinality: 155
                              1 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315
                         4 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2
                              3 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2
                    6 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1
               8 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1
     12 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 2 Bytes: 7 Cardinality: 1
          11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1
     28 SORT AGGREGATE Bytes: 169 Cardinality: 1
          27 NESTED LOOPS
               25 NESTED LOOPS Cost: 16,549 Bytes: 974,792 Cardinality: 5,768
                    23 NESTED LOOPS Cost: 5,070 Bytes: 811,737 Cardinality: 5,757
                         20 NESTED LOOPS Cost: 2,180 Bytes: 56,066 Cardinality: 578
                              17 NESTED LOOPS Cost: 967 Bytes: 32,118 Cardinality: 606
                                   14 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 3,465 Cardinality: 315
                                        13 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315
                                   16 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2
                                        15 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2
                              19 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1
                                   18 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1
                         22 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 5 Bytes: 440 Cardinality: 10
                              21 INDEX RANGE SCAN INDEX OKC.OKC_K_LINES_B_N2 Cost: 2 Cardinality: 9
                    24 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_TL_U1 Cost: 1 Cardinality: 1
               26 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_TL Cost: 2 Bytes: 28 Cardinality: 1
     44 VIEW VIEW APPS.WRS_LICENSE_INFO_V Cost: 7,212 Bytes: 2,462,837 Cardinality: 3,211
          43 HASH JOIN Cost: 7,212 Bytes: 536,237 Cardinality: 3,211
               41 NESTED LOOPS
                    39 NESTED LOOPS Cost: 7,070 Bytes: 485,792 Cardinality: 3,196
                         37 HASH JOIN Cost: 676 Bytes: 341,972 Cardinality: 3,196
                              32 HASH JOIN RIGHT OUTER Cost: 488 Bytes: 310,012 Cardinality: 3,196
                                   30 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_LOOKUP_VALUES Cost: 7 Bytes: 544 Cardinality: 17
                                        29 INDEX RANGE SCAN INDEX (UNIQUE) APPLSYS.FND_LOOKUP_VALUES_U1 Cost: 3 Cardinality: 17
                                   31 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_B Cost: 481 Bytes: 207,740 Cardinality: 3,196
                              36 VIEW VIEW AR.index$_join$_013 Cost: 187 Bytes: 408,870 Cardinality: 40,887
                                   35 HASH JOIN
                                        33 INDEX FAST FULL SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 112 Bytes: 408,870 Cardinality: 40,887
                                        34 INDEX FAST FULL SCAN INDEX AR.HZ_CUST_ACCOUNTS_N2 Cost: 122 Bytes: 408,870 Cardinality: 40,887
                         38 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1
                    40 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 2 Bytes: 45 Cardinality: 1
               42 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_TL Cost: 142 Bytes: 958,770 Cardinality: 63,918

Hi,
You should always try using primary index fields, if not possible then secondary index fields.
Even if you cannot do anything from either of the two then try this,
Use Less distinct fields on the top.
In your case , you can use bukrs ,gjahr ,werks on the top in the where condition..then followed by less distinct values..
Even when you use secondary index if you have 4 fields in your sec index and you are using only two fields from the top then the index is useful only upto that two fields provided they are in sequence.

Issue in Modifying custom table

Hi Experts
Program Y00_MM modifying custom table Y00_IFS074 using internal table.
we have a sales company code field in table.
Internal table company code value is 00021345 .
But in custom table it updated as 21345. It should be 00021345.
few days back no problem with table updation. Now only i'am getting this issue. There is no changes in Report.
Kindly help me.

Hi,
Please use the below FM for the field BUKRS.
FM : CONVERSION_EXIT_ALPHA_OUTPUT.
This FM will add the leading zeros according to the field length.
Hope this will resolve your problem...

Performance issue with joins on table VBAK, VBEP, VBKD and VBAP

hi all,
i have a report where there is a join on all 4 tables VBAK, VBEP, VBKD and VBAP.
the report is giving performance issues because of this join.
all the key fields are used for the joining of tables. but some of the non-key fields like vbap-vstel, vbap-abgru and vbep-wadat are also part of select query and are getting filled.
because of these there is a performance issue.
is there any way i can improve the performance of the join select query?
i am trying "for all entries" clause...
kindly provide any alternative if possible.
thanks.

Hi,
Pls perform some of the below steps as applicable for the performance improvement:
a) Remove join on all the tables and put joins only on header and item (VBAK & VBAP).
b) code should have separate select for VBEP and VBKD.
c) remove the non key fields from the where clause. Once you retrieve data from the database into the internal table, sort the table and delete the entries which are not part of the non-key fields like vstel, abgru and wadat.
d) last option is you can create index in the VBAP & VBEP table with respect to the fields vstel, abgru & wadat ( not advisable)
e) buffering option on database tables also possible.
f) select only the fields into the internal table that are applicable for the processing logic and also the select query should contaian the field names in the same order as mentioned in the database table.
Hope this helps.
Regards
JLN

Perform DB lcoking on custom table

Hi, I have written a program that uses an Editable ALV grid to update entries in a custom table. But I wnat to be able to lock users from performing updates when another user is in the transaction. Can you tell me how best to do this?

Moderator message - Please do not ask basic questions - thread locked
Rob

Strange issue in updating custom table after upgrade ECC6.0! Please help!

Hello everyone:
    I have some code (shown below) that deletes and updates some SAP tables and one custom table:
    DELETE T5UBV   FROM TABLE DEL_T5UBV.
DELETE ZCHRZIP FROM TABLE DEL_ZCHRZIP.
MODIFY ZCHRZIP FROM TABLE WRITE_ZCHRZIP.
MODIFY T5UBV   FROM TABLE WRITE_T5UBV.
COMMIT WORK.
For SAP table the code above works fine but for custom table it overrides all exisiting data! It should keep some existing data in custom table ZCHRZIP and append any extra data from internal table WRITE_ZCHRZIP. This functions as designed if I run in fore ground but in background it just overrides instead of modifying and appending! This is happening only after upgrade ECC6.0. Any thoughts? Please let me know.
Thanks.
Mithun

Mithun,
Comment below code
DELETE ZCHRZIP FROM TABLE DEL_ZCHRZIP.
<b>Reward if it helps,</b>
Satish

View objects performance issue with oracle seeded tables

While i am writing a view object on a oracle seeded tables like MTL_PARAMETERS, its taking more time to show in the oaf page.I am trying to display all these view object columns in detail disclosure of advanced table. My Application is taking more than two minutes to display the view columns of the query which is returning just 200 rows. Please help me how to improve performance when my query using seeded tables.
This issue is happening only in R12 view object and advanced tables.
Edited by: vlsn on Jun 24, 2012 11:36 PM

Hi All,
Here is architecture of my application:
Java application creates XML from the screen values and then inserts that XML
into a framework(separate DB schema) table . then Java calls a Stored Procedure from same framework DB and in SP we have following steps.
1. It fatches XML from the XML type table and inserts XML into screen specific XML TYPE table in the framework DB Schema. This table has a trigger which parses XML and then inserts XML values into GTT which are created in separate product schemas.
2. it calls Product SP and then in product SP we have business logic. Product SP
does the execution and then inserts response into Response GTT.
3. Response XML is created by using XML generation function and response GTT.
I hope u will understand my architeture this time and now let me know if GTT are good in this scenario or not. also please not that i need data in GTT only during execution and not after that. i dont want to do specific delete which i have to do if i am using normal tables.
Regards,
Vikas Kumar

Performance for join 9 custom table with native SQL ?

Hi Expert,
I need your opinion regarding performance to join 9 tables with native sql. Recently i have to tunning some customize extraction cost report. This report extract about 10 million cost of material everyday.
The current program actually, try to populate the condition data and insert into customize table and join all the table to get data using native sql.
SELECT /*+ ordered use_hash(mst,pg,rg,ps,rs,dpg,drg,dps,drs) */
            mst.werks, ....................................
FROM
            sapsr3.zab_info mst,
            sapsr3.zab_pc pg,
            sapsr3.zab_rc rg,
            sapsr3.zab_pc ps,
            sapsr3.zab_rc rs,
            sapsr3.zab_g_pc dpg,
            sapsr3.zab_g_rc drg,
            sapsr3.zab_s_pc dps,
            sapsr3.zab_s_rc drs
        WHERE mst.zseq_no = :p_rep_run_id
        AND mst.werks = :p_werks
        AND mst.mandt = rg.mandt(+)
        AND mst.ekorg = rg.ekorg(+)
        AND mst.lifnr = rg.lifnr(+)
        AND mst.matnr = rg.matnr(+)
        ...............................................   unitl all table (9 tables)
        AND ps.mandt = dps.mandt(+)
        AND ps.knumh = dps.knumh(+)
        AND ps.zseq_no = dps.zseq_no(+)
        AND COALESCE (dps.kbetr, drs.kbetr, dpg.kbetr, drg.kbetr) <> 0
It seems the query ask for database to using hashed table. would that be it will burden the database ? and impacted to others sap process ?
Please advise
Thank You and Best Regards

you can only argue coming from measurements and that is not the case.
Coming from the code, I see only that you do not understand it at all, so better leave it as it is. It is not a hash table, but a hash join on these table.

Performance issue when selection LIPS table into program.

Hi expert,
I have created Pending sales order report , in that i am facing performance problem for selection of LIPS table.
i have tried to use VLPMA table but performance has not been improved so, is their any need to create secondary index and
if yes then which fields of lips table i have to includes in index.
Please reply.
Regards,
Jyotsna

>
UmaDave wrote:
> Hi ,
> 1.Please make use of PACKAGE in your select query , it will definetly improve the performance.
> 2.Please use the primary index by passing the fields in where clause in the order in which they appera in LIPS table.
> 3.You can also create a secondary index with the fields which you are using in where clause of select query and maintain the fields in the same sequence (where clause and secondary index)
> 4.If there is any inner joins (more than 3) then reduce them and have few mare select queries for them and make use of for all entries.
>
> This will definitely improve the performance to great extend.
>
> Hope this is helpful.
> Regards,
> Uma
Please do some more research before offering advice:
PACKAGE SIZE is for memory management, not performance.
Creating a secondary index is using a hammer to swat a fly and the order in the SELECT is not relevant.
FAE does not improve performance over a JOIN.
Rob

Performance issue related to BSIS table:pls help

Theres a select statement which fetches data from BSIS table.
As in the where clause the only key field used is BUKRS its consuming more time.Below is the code.
Could you please tell me how to improvise this piece of code.
I tried to fecth first from BKPF table based on the selection screen paramater t001-bukrs and then for all entries in BKPF fetched from BSIS.But it didnt worked.
your help would be very much appreciated.Thanks in advance.
SELECT bukrs waers ktopl periv
         FROM t001
         INTO TABLE i_ccode
         WHERE bukrs IN s_bukrs.
SELECT bukrs hkont gjahr belnr buzei bldat waers blart monat bschl
shkzg mwskz dmbtr wrbtr wmwst prctr kostl
           FROM bsis
           INTO TABLE i_bsis
           FOR ALL ENTRIES IN i_ccode
           WHERE bukrs EQ i_ccode-bukrs
           AND   budat IN i_date.
Regards
Akmal
Moved by moderator to the correct forum
Edited by: Matt on Nov 6, 2008 4:10 PM

Dnt go for FOR ALL ENTRIES it will not help in this case .Do like below , you can see a lot of performance improvement.
SELECT bukrs waers ktopl periv
         FROM t001
         INTO TABLE i_ccode
         WHERE bukrs IN s_bukrs.
sort i_ccode by bukrs.
LOOP AT i_ccode.
   SELECT bukrs hkont gjahr belnr buzei bldat waers blart         monat bschl shkzg mwskz dmbtr wrbtr wmwst prctr kostl
         FROM bsis
        APPENDING TABLE i_bsis
        WHERE bukrs EQ i_ccode-bukrs
        AND   budat IN i_date.
ENDLOOP.
I dnt know why perform is good for the above query than "bulrs in so_bukrs" .This willl help , i m sure. this approach helped me.
Edited by: Karthik Arunachalam on Nov 6, 2008 8:52 PM

Performance issues in million records table

I Have a scenario wherein have some 20 tables each with a million and more records. [ Historical ]
On an average I do add 1500 - 2500 records a day... i.e would add a million records every year on an average
Am looking for archival solutions for these master tables.
Operations on Archival Tables, would be limited to read.
Expected benefits
User base would be around 2500 users on the whole - but expect 300 - 500 parallel users at the max.
Very limited usage on Historical data - compared to operations on current data
Performance on operations over current data is important compared over that on historical data
Environment - Oracle 9i - Should be migrating to Oracle 10g sooner.
Some solutions i cud think of ...
[ 1 ] Put every archived record into a archival table and fetch it from there
i.e clearly distinguish searches as current or archival - prior to searching
the impact i feel is again archival tables are ever increasing by approx a million in a year
[ 2 ] Put records into various archival tables each differentiated by a year
For instance every year i do replicate the set of tables and that year data goes into that table.
how do i do a fetch??
Note - i do have a unique way of identifying each record in my master table - the primary key is based on YYYYMMXXXXXXXXXX format eg: 2008070000562330, will the year part help me in anyway to check with the correct table
The major concern is i do have a very good response based on indexing and other common things, but would not want this to downgrade in a year and more, but expect to improvise on the current response timings and also do ensure to conitnue the same over a period of time.
Also I don't want to make change to every query in my app - until there is no way out..

Hi,
Read the following documentation link about Partitioning in Oracle.
Best Regards,
Alex

Performance issue with sys.user_history$ table

Hi,
I am investigating performance for one of my client's databases (which is at 9.2.0.8) as they are experiencing intermittent poor response. In the Statspack report (Top SQL section) I can see that a catalog table called SYS.USER_HISTORY$ is being accessed very frequently. Now I understand that this would be a result of password limits being set in users' profile but each time the table is accessed, it would appear to incur a full table scan resulting in over 7,500 gets each time. The total buffer gets (and physical blocks read) from this table account for a high percentage of the total and since the highest waits are buffer and I/O related this must be a major factor. Here is an extract from the Statspack report:
CPU Elapsd
Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value
2,327,138 316 7,364.4 7.8 190.22 4889.61 3236020785
select password_date from user_history$ where user# = :1 order by password_date desc
2,320,524 313 7,413.8 7.8 199.41 4278.44 3584552880
delete from user_history$ where password_date < :1 and user# = :2
2,272,260 308 7,377.5 7.6 169.36 3453.12 822812381
select 1 from dual where exists (select password from user_history$ where password = :1 and user# = :2)
Physical Reads Executions Reads per Exec %Total Time (s) Time (s) Hash Value
1,448,689 316 4,584.5 20.6 190.22 4889.61 3236020785
select password_date from user_history$ where user# = :1 order by password_date desc
1,269,172 313 4,054.9 18.1 199.41 4278.44 3584552880
delete from user_history$ where password_date < :1 and user# = :2
1,206,906 308 3,918.5 17.2 169.36 3453.12 822812381
select 1 from dual where exists (select password from user_history$ where password = :1 and user# = :2)
Is there any way to improve access to this table? Since it's a catalog table, I presume it would not be acceptable to an index to it but, for example, would it be acceptable to assign it to a suitably sized KEEP buffer pool which should at least reduce the amount of physical I/O incurred?
Any ideas would be appreciated.
Regards,
Ian Brennan

Hi,
Here is the remaining information which I have now gathered:-
select count(*) from dba_users;
24681
select count(*) from sys.user_history$;
1258133
select profile, limit from dba_profiles where resource_name = 'PASSWORD_REUSE_TIME';
PROFILE LIMIT
DEFAULT UNLIMITED
PRS2_DEFAULT_PROFILE 365
select bytes from dba_segments where SEGMENT_NAME='USER_HISTORY$';
61865984
explain plan for
select password_date from user_history$ where user# = :1 order by password_date desc;
SELECT STATEMENT CHOOSE
Cost: 647 Bytes: 913 Cardinality: 83
2 SORT ORDER BY
Cost: 647 Bytes: 913 Cardinality: 83
1 TABLE ACCESS FULL SYS.USER_HISTORY$
Cost: 638 Bytes: 913 Cardinality: 83
Any further thoughts?

Insert performance issue with Partitioned Table.....

Hi All,
I have a performance issue during with a table which is partitioned. without table being partitioned
it ran in less time but after partition it took more than double.
1) The table was created initially without any partition and the below insert took only 27 minuts.
Total Rec Inserted :- 2424233
PL/SQL procedure successfully completed.
Elapsed: 00:27:35.20
2) Now I re-created the table with partition(range yearly - below) and the same insert took 59 minuts.
Is there anyway i can achive the better performance during insert on this partitioned table?
[ similerly, I have another table with 50 Million records and the insert took 10 hrs without partition.
with partitioning the table, it took 18 hours... ]
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 4195045590
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 643K| 34M| | 12917 (3)| 00:02:36 |
|* 1 | HASH JOIN | | 643K| 34M| 2112K| 12917 (3)| 00:02:36 |
| 2 | VIEW | index$_join$_001 | 69534 | 1290K| | 529 (3)| 00:00:07 |
|* 3 | HASH JOIN | | | | | | |
| 4 | INDEX FAST FULL SCAN| PK_ACCOUNT_MASTER_BASE | 69534 | 1290K| | 181 (3)| 00:00
| 5 | INDEX FAST FULL SCAN| ACCOUNT_MASTER_BASE_IDX2 | 69534 | 1290K| | 474 (2)| 00:00
PLAN_TABLE_OUTPUT
| 6 | TABLE ACCESS FULL | TB_SISADMIN_BALANCE | 2424K| 87M| | 6413 (4)| 00:01:17 |
Predicate Information (identified by operation id):
1 - access("A"."VENDOR_ACCT_NBR"=SUBSTR("B"."ACCOUNT_NO",1,8) AND
"A"."VENDOR_CD"="B"."COMPANY_NO")
3 - access(ROWID=ROWID)
Open C1;
Loop
Fetch C1 Bulk Collect Into C_Rectype Limit 10000;
Forall I In 1..C_Rectype.Count
Insert test
     col1,col2,col3)
Values
     val1, val2,val3);
V_Rec := V_Rec + Nvl(C_Rectype.Count,0);
Commit;
Exit When C_Rectype.Count = 0;
C_Rectype.delete;
End Loop;
End;
Total Rec Inserted :- 2424233
PL/SQL procedure successfully completed.
Elapsed: 00:51:01.22
Edited by: user520824 on Jul 16, 2010 9:16 AM

I'm concerned about the view in step 2 and the index join in step 3. A composite index with both columns might eliminate the index join and result in fewer read operations.
If you know which partition the data is going into beforehand you can save a little bit of processing by specifying the partition (which may not be a scalable long-term solution) in the insert - I'm not 100% sure you can do this on inserts but I know you can on selects.
The APPEND hint won't help the way you are using it - the VALUES clause in an insert makes it be ignored. Where it is effective and should help you is if you can do the insert in one query - insert into/select from. If you are using the loop to avoid filling up undo/rollback you can use a bulk collect to batch the selects and commit accordingly - but don't commit more often than you have to because more frequent commits slow transactions down.
I don't think there is a nologging hint :)
So, try something like
insert /*+ hints */ into ...
Select
     A.Ing_Acct_Nbr, currency_Symbol,
     Balance_Date,     Company_No,
     Substr(Account_No,1,8) Account_No,
     Substr(Account_No,9,1) Typ_Cd ,
     Substr(Account_No,10,1) Chk_Cd,
     Td_Balance,     Sd_Balance,
     Sysdate,     'Sisadmin'
From Ideaal_Cons.Tb_Account_Master_Base A,
     Ideaal_Staging.Tb_Sisadmin_Balance B
Where A.Vendor_Acct_Nbr = Substr(B.Account_No,1,8)
   And A.Vendor_Cd = b.company_no
      ;Edited by: riedelme on Jul 16, 2010 7:42 AM

Performance Issue's Related in Adance table in advance table

Hi,
Can anybody let me know what are the performance issues in advance table in advance table,because i am having big performance issue while implementing advance table in advance table, my inner table is rendering very slowly.
Thanks

Table in a table is a performance eating structure :), because ur VL will cache both parent and child VO rows in JVM.The only way to improve the performance is to tune your sql queries.
--Mukul

Performance issue in SQL while using max

Hi
I have log table which desired changed date. if any transaction entered for the changed date and less, then the name and location should be shown based on change log table. if change log entry has two values for a same date for a customer then need to show the max value for the row.
Log table
ID   CUSTOMER_ID                NAME        LOCATION      CHANGED_DATE
1          1                      sar          boston          11-1-13
2          2                      var          chn             12-1-13
3          1                      gar          boston          13-1-13
4          1                      nar          boston          13-1-13
Transaction table
ID            CUSTOMER_ID               DATE         QTY
1                 1                    11-1-13       10
2                 2                    12-1-13        9
3                 1                    10-1-13        8
4                 1                    13-1-13        7
Required Result
ID            CUSTOMER_ID                 NAME               LOCATION            DATE         QTY
1                 1                       sar                  boston            11-1-13       10
2                 2                       var                  chn               12-1-13        9
3                 1                       sar                  boston            10-1-13        8
4                 1                       nar                  boston            13-1-13        7I got the above result using the max when multiple log entry for same date. but if use max value i got performance issue when log entry table has more entries.
can you help me in this?
Edited by: Tsk on Apr 23, 2013 1:12 AM

How do I ask a question on the forums?
SQL and PL/SQL FAQ

Performance issue in a custom table

Similar Messages

Maybe you are looking for