Force record to be indexed

Hi,
I'm working on portal 10gr3 and I face a problem with the 'portal.wwsbr_api.set_attribute'.
I'm able to set an attribute through this procedure but, the modified record is not take into account when index are update. The record modified is on table 'portal.wwv_thingattributes'.
Is there a way to flag a record to be take into when indexes are updated ?
I have a lot of update to do (correction of inconsistencies on translated data) and can ask a dba to perform some tasks if necessary.
Thank you for any help, Eddy.

Yep. Theres an option ImageAlign of the ActionPainter, Options infront or behind.

Similar Messages

Query tuning and how to force table to use index?

Dear Experts,
i have two (2) question regarding performance during DRL.
Question # 1
There is a column name co_id in every transaction table. DBA suggest me to add [co_id='KPG'] in every clause which forces query to use index, resulting immediate processing. As an index was created for each table on the co_id column.
Please note that co_id has constant value 'KPG' through out the table. is it make sense to add that column in where caluse like
select a,b,c from tab1
where a='89' and co_id='KPG'
Question # 2
if i am using a column name in where clause having index on it and that column is not in my column list does it restrict query for full table scan. like
select a,b,c,d from tabletemp
where e='ABC';
Thanks in advance
Edited by: Fiz Dosani on Mar 27, 2009 12:00 PM

Fiz Dosani wrote:
Dear Experts,
i have two (2) question regarding performance during DRL.
Question # 1
There is a column name co_id in every transaction table. DBA suggest me to add [co_id='KPG'] in every clause which forces query to use index, resulting immediate processing. As an index was created for each table on the co_id column.
Please note that co_id has constant value 'KPG' through out the table. is it make sense to add that column in where caluse like
select a,b,c from tab1
where a='89' and co_id='KPG'If co_id is always 'KPG' it is not needed to add this condition to the table. It would be very stupid to add an (normal) index on that column. An index is used to reduce the resultset of a query by storing the values and the rowids in a specified order. When all the values are equal and index justs makes all dml operations slower without makeing any select faster.
And of cause the CBO is clever enough not to use such a index.
>
Question # 2
if i am using a column name in where clause having index on it and that column is not in my column list does it restrict query for full table scan. like
select a,b,c,d from tabletemp
where e='ABC';
Yes this is possible. However it depends from a few things.
1) How selective this condition is. In general an index will be used when selectivity is less than 5%. This factor depends a bit on the database version. it means that when less then 5% of your rows have the value 'ABC' then an index access will be faster than the full table scan.
2) Are the statistics up to date. The cost based optimizer (CBO) needs to know how many values are in that table, in the columns, in that index to make a good decision bout using an index access or a full table scan. Often one forgets to create statistics for freshly created data as in temptables.
Edited by: Sven W. on Mar 27, 2009 8:53 AM

How do you record the current index?

Hi everyone,
Im sorry if this problem seems basic, but I have a for loop that controls motor movement, and I have a separate while loop that is responsible for all data acquisition. I am wondering if there is a way to record the current index number from the for loop in my DAQ loop? I tried wiring the index down to the array in the while loop, but it seems to prevent the while loop from starting up.
I can throw up some pictures if necessary, but im hoping this can be done easily.
Thanks!

Please do not "throw up pictures". Instead, post code. Attach a VI, or create a Snippet (which looks like a picture, but can be dragged onto a LabVIEW Block Diagram and, by NI Magic, becomes executable, editable, clickable LabVIEW code.
Bob Schor

Fms force record live streams

Hi there,
Just wondering if it is possible to force recording of all streams in a given application ...
So the scenario s that the client is sending live stream, but as well as this we need to recrd that stream . I know I can do sass and create a stream object. But I ned red if there was a better way which would be a simple config option
Many thanks
Matt

Hi Matt,
I don't think you can accomplish DVR without writing a server side script.
You can, however, go through this- the DVR reference guide:
http://help.adobe.com/en_US/flashmediaserver/devguide/WS236AE81A-5319-4327-9E44-310A93CA09 C6Dev.html
Thanks.

Force use of an INDEX in ABAP

Is there a way to force the use of an index for a select statement in ABAP?
Is it possible ? Maybe with EXEC SQL . . .
Here find a trace
SELECT STATEMENT ( Estimated Costs = 28.747 , Estimated #Rows = 9 )
    5 2 TABLE ACCESS BY INDEX ROWID EDIDC
   ( Estim. Costs = 28.747 , Estim. #Rows = 9 )
           1 INDEX RANGE scan EDIDC~3
    ( Estim. Costs = 1.207 , Estim. #Rows = 269.667 )
As we can see sql optimizer choose index 3 but I though index 1 is better....
regards,

Hi Guys,
With reference to Indexes, the best way to use them is to check out all the fields that are available in the index and make your Select Query in such a way that :
(1) The fields in the index are present in your query.
(2) The fields are in the same order in the index and the query.
(3) OR conditions are avoided in the same line. E.g. Where ( matnr = '10000034' OR maktx = 'BB Prod.')
- Such statements are to be avoided.
If in a table there are many indexes SAP will decide by itself which index to use. This decision is based on a sampling percentage. This data is filled based on your configuration and can be viewed in ST05. In case the data has not been updated, you may find that SAP will use an index which you might not find suitable. Hence a situation may come up when you are required to force an index to be used in your SELECT query.

TREX: delete single records in an index

Hey guys,
is there a way to delete one single record on a TREX index?
I am using function module TREX_EXT_UPDATE_DOC_ATTRIBUTES.
I don't want to delete the whole index because it takes to much time to build it up again. Therefore i want delete single records. I have the doc-key to identify the record but how to delete it?
   thx,
      Ming

You set the field doc_action = 'D' for deindexing records, and set doc_action = 'I' for indexing records, and then call the function module
ls_doc-doc_key = "enter doc key here
ls_doc-doc_action = 'D'. "for deindexing
"set other fields similarly
APPEND ls_doc TO lt_docs.
CALL FUNCTION 'TREX_EXT_INDEX'
      EXPORTING
        I_INDEX_ID                          = gs_trex_doc-index_id
        I_RFC_DESTINATION           = lc_rfc_destn
        I_INDEX_DOCUMENT_LIST = lt_docs
      IMPORTING
        E_RETURN_CODE   = lv_return_code
        E_RETURN_TEXT     = lv_return_text
      EXCEPTIONS
        CONVERSION_ERROR      = 1
        RFCSERVER_ERROR       = 2
        ERROR                 = 3
        OTHERS                = 4.
if you want to delete attributes use the function module "TREX_EXT_DELETE_ATTRIBUTE"
hope this helps

Force Spotlight to Index a FW HDD

Hello!
Well, I recently aquired (as in 2 days ago) a Seagate 400GB FireWire/USB drive. I have it connected via FW.
Well, after formatting it to Mac Extended format, I partitioned it for a 60G section (intended for a secondary boot volume) and a 320 GB volume.
Yesterday, I coppied all 6 gig of data from our old G4's hard drive. Tonight, I want to look for a couple of files - but spotlight hasn't indexed anything - so not even find will find the files.
How do you force spotlight to index a hard drive?
-Dan

To force a volume to index just drag it into the privacy window for a moment and then drag it out.
-mj
[email protected]

Forcing to use index

I have a query which is taking 2 minutes to respond. When I see the explain plan, it said for two tables it is doing the full table scan. So I tried forcing to use the index on the inner tables(xcm, detail) of the views(vw_xcm , vw_vw_detail). But it is still not using indexes when the query is running. Please let me know if I am forcing the indexes right.
Here is my code
SELECT x.customer_gci AS hdr_borrower_gci,
 x.industry_group_name AS hdr_borrower_sector,
 x.industry_subgroup_name AS hdr_borrower_industry,
 CAST (NULL AS number) AS hdr_incremental_fvo_amt,
 x.industry_subgroup_code AS hdr_industry_cd,
 x.industry_subgroup_name AS hdr_industry,
 CAST (NULL AS integer) AS hdr_cds_tenor,
 x.industry_group_code AS hdr_req_borrower_sector_cd,
 x.industry_subgroup_code AS hdr_req_borrower_industry_cd,
 x.customer_gci AS dtl_borrower_gci,
 x.customer_name AS dtl_company_name,
 (SELECT NVL (MAX (market_cap), 0)
 FROM data_v2 kmv
 WHERE kmv.asof_date = (SELECT MAX (actual_data_date)
 FROM fvo_process_dtl dtl
 WHERE dtl.process_name = 'KMV')
 AND kmv.spineid = x.spineid
 AND kmv.market_cap <> 0)
 AS dtl_marketcap,
 x.industry_subgroup_name AS dtl_industry,
 x.dtl_region,
 (SELECT SUM (NVL (notional, 0))
 FROM vw_gcm
 WHERE datestamp = (SELECT MAX (datestamp)
 FROM vw_fvo_gcm_trade)
 AND familygci = family_gci
 AND rpt_product = 'LOAN'
 AND rpt_risk_group = 'FVO')
 AS dtl_current_fvo_amt,
 NULL AS dtl_trader_liquidity_cd,
 CAST (NULL AS number) AS dtl_manager_acceptable_amt,
 NULL AS dtl_lastused_date,
 NULL AS dtl_trader_comments,
 NULL AS dtl_manager_comments,
 CAST (NULL AS number) AS dtl_incremental_fvo_amt,
 x.industry_subgroup_code AS dtl_industry_code,
 x.spineid,
 (SELECT SUBSTR (MAX(TO_CHAR (ratingdate, 'YYYYMMDD')
 || iss.issuerrating),
 9
 FROM issuerrating iss
 WHERE iss.ratingschemeid =
 (SELECT rs.ratingschemeid
 FROM ratingscheme rs
 WHERE rs.ratingschemename = 'SNP')
 AND iss.ratingtypeid = (SELECT rt.ratingtypeid
 FROM ratingtype rt
 WHERE rt.ratingtypecode = 'LT')
 AND iss.ratingdate <= TRUNC (SYSDATE)
 AND iss.issuerrating NOT IN
 ('NR',
 'WR',
 'SD',
 'NM',
 'NRpi',
 'Rpi',
 'R',
 'SDpi')
 AND iss.spineid = x.spineid)
 AS dtl_snp_rating,
 (SELECT SUBSTR (MAX(TO_CHAR (ratingdate, 'YYYYMMDD')
 || iss.issuerrating),
 9
 FROM rating iss
 WHERE iss.ratingschemeid =
 (SELECT rs.ratingschemeid
 FROM rating rs
 WHERE rs.ratingschemename = 'MOODYS')
 AND iss.ratingtypeid = (SELECT rt.ratingtypeid
 FROM ratingtype rt
 WHERE rt.ratingtypecode = 'LT')
 AND iss.ratingdate <= TRUNC (SYSDATE)
 AND iss.issuerrating NOT IN ('NR', 'WR', 'SD')
 AND iss.spineid = x.spineid)
 AS dtl_moodys_rating,
 risk_rating AS dtl_internal_rating
 FROM (SELECT /* + INDEX(xcm fvo_xcm_customer_ix3) INDEX(id fvo_ecris_d_industry_dtl_ix1)*/ xcm.customer_gci AS customer_gci,
 xcm.customer_name AS customer_name,
 TRIM (REPLACE (id.industry_group_name, '"', ' '))
 AS industry_group_name,
 id.industry_group_code,
 TRIM (REPLACE (id.industry_subgroup_name, '"', ' '))
 AS industry_subgroup_name,
 id.industry_subgroup_code,
 TRIM (REPLACE (id.industry_subgroup_name, '"', ' '))
 AS dtl_industry,
 (SELECT threealphacountrycode
 FROM xcm_region_country_map r
 WHERE r.twoalphacountrycode = xcm.country_code
 AND r.regioncode != 'INTL'
 AND r.region IN ('North American', 'EMEA'))
 AS dtl_region,
 (SELECT spineid
 FROM companymap cm
 WHERE cm.sourcereferenceid = 24
 AND cm.sourcereferencevalue = xcm.customer_gci
 AND cm.enddate IS NULL)
 AS spineid,
 xcm.family_gci AS family_gci,
 xcm.risk_rating AS risk_rating
 FROM vw_xcm xcm,
 (SELECT naics_code,
 industry_group_name,
 industry_group_code,
 industry_subgroup_name,
 industry_subgroup_code
 FROM vw_detail
 WHERE industry_subgroup_code IS NOT NULL) id
 WHERE xcm.period = (SELECT MAX (period)
 FROM vw_xcm)
 -- AND xcm.industry_detail_key =
 -- id.industry_detail_key
 AND xcm.naics_code = id.naics_code
 AND TRIM (xcm.customer_gci) NOT LIKE 'S%') x
{code}

Sometimes the cost-based optimizer will not take hints because it thinks it knows better. This is a matter of debate here on OTN, where some posters dogmatically assert that hints are instructions that must be followed. My experience is different. I have on rare occasions used perfectly good hints (usually INDEX) that the database simply refused to use.
Someone noted on a post a month or two ago that there may be a glitch with the CBO where it loses indexes when considering execution plans. This was based on a 10053 trace, which will show the different access paths considered during query evaluation.
Ultimately the CBO is deciding you query is more efficient not to use the indexes, even with your hint.
Looking again at your query I'll note that it is very complicated with inline views and more inline views. The CBO has trouble running multiple views efficiently - inline views, views of views, views joined to views - because views have no valid statistics associated with them. The choices the CBO makes based on views use defaults that are all but certain to be incorrect.
In particular, your index use for "id" makes no sense because it is an inline view. you could try using a global hint by pushing the hint inside the view, something like
INDEX(id.table_in_view fvo_ecris_d_industry_dtl_ix1)Unfortunately, the table inside the inline view id itself appears to be a view compliating this effort.
Try using the USE_NL hint instead of INDEX and see if that helps
Good luck

How to compile the hint to force selection statement to use index

Hello expert,
will you please tell me how to compile the hint to force selection statement to use index?
Many Thanks,

Not sure what you mean by compile, but hint is enclosed in /*+ hint */. Index hint is INDEX(table_name,index_name). For example:
SQL> explain plan for
2 select * from emp
3 /
Explained.
SQL> @?\rdbms\admin\utlxpls
PLAN_TABLE_OUTPUT
Plan hash value: 3956160932
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |    14 |   546 |     3   (0)| 00:00:01 |
|   1 | TABLE ACCESS FULL| EMP |    14 |   546 |     3   (0)| 00:00:01 |
8 rows selected.
SQL> explain plan for
2 select /*+ index(emp,pk_emp) */ *
3 from emp
4 /
Explained.
SQL> @?\rdbms\admin\utlxpls
PLAN_TABLE_OUTPUT
Plan hash value: 4170700152
| Id | Operation                   | Name   | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |        |    14 |   546 |     2   (0)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| EMP    |    14 |   546 |     2   (0)| 00:00:01 |
|   2 |   INDEX FULL SCAN           | PK_EMP |    14 |       |     1   (0)| 00:00:01 |
9 rows selected.
SQL> Hint in the above example is forcing optimizer to use index which resul;ts in a bad execution plan. Most of the time optimizer does not need hints and chooses an optimal plan. In most cases sub-optimal plan is result of stale or incomplete statistics.
SY.

How to force a Index?

HI, i know that using the hint /*+ index(NOMBRE_TABLA NOMBRE_INDICE) */ it force to use an index specified.
but is another way to do this?
i hear that doing this it work too, and in the explain plan looks good but does't retrieve data.
example
select a.field1
from table1 a, table2 b
where a.fieldkey1 = b.fieldkey1
and -a.fieldkey2 = b.fieldkey2
index1 = a.fieldkey1
index2 = a.fieldkey2
look the minus sign in the index 2
can someone help me about this?
Thanks, sorry by my english

Intentional index supression usually occurs with the rule-based optimizer, when the RBO chose to use an index but not the one you wanted or perhaps to force a full table scan for some reason. Its not widely used these days. Modifying a column value should suppress index use; the way its usually done is to add 0 to numbers/dates or concatenate a null to strings leaving the actual value unchanged. IF you need to do this (and I'm wondering why you do) document your code some Those Who Come After don't see strange code and immediately change it on sight
select *
from whatever
where number_column + 0 = whatever
or string_column || null = whatever

Oracle Hint on Table MKPF and MSEG : force index MSEG~M to be utilize

Hi Experts, I'm quite new to ABAP performance tuning, I try to put details as much as I can in my question below, just to have a quick overview of my problem below, I want to use/force in my SQL below to force the utilization of index MSEG~M.
added an Oracle Hint forcing index MSEG~M
SELECT MATNR BWART MENGE
FROM   MKPF
INNER JOIN MSEG
     ON MKPFMANDT EQ MSEGMANDT
    AND MKPFMBLNR EQ MSEGMBLNR
    AND MKPFMJAHR EQ MSEGMJAHR
   INTO CORRESPONDING FIELDS OF TABLE T_MSEG2
WHERE MKPF~BUDAT IN S_GSTRP    "(index bud should be used)
   AND MSEG~MJAHR IN R_DOCYEAR
   AND BWART IN ('931', '932',
                  '901', '902',
                  '701', '702',
                  '703', '704',
                  '707', '708',
                  '711', '712',
                  '713', '714',
                  '715', '716',
                  '717', '718',
                  '551', '552',
                  '553', '554',
                  '555', '556') "ZZCHK: Constants Not Applicable
         AND MATNR IN R_MATNR3
         AND MATNR IN R_COMPNTS
         AND WERKS EQ P_WERKS
%_hints oracle u2018INDEX(u201CMKPFu201D u201CMSEG~Mu201D)u2019.
Note: I'm assuming that you'll take not some comments on further enhancement:
- " INTO CORRESPONDING FIELDS "
- use of field symbols
- I didn't modify it yet since my focus if for MSEG~M
- cannot make material number as mandatory field
Objective: Force to use index MSEG~M
Problem:
After adding the Oracle Hint, I did the analysis in ST05 and it seems like index M is still not being forcefully
utilize instead MSEG~0 is being used.
I replaced the Oracle Hint with:
%_hints oracle u2018INDEX(u201CT_01u201D u201CMSEG~Mu201D)u2019.
In ST05, I can get see that index MSEG~M is now being utilize BUT worst thing happened after applying this, the program timed out.
I already take a look on the following Notes: 129385, 130480, 772497, 162034, 818321 but nothing seems to be helpful in my problem.
Questions:
1. In syntax %_hints oracle u2018INDEX(u201CT_01u201D u201CMSEG~Mu201D)u2019. T_01 stands for MKPF right which is the first table, do you what's the reason for the program time out after adding this Oracle Hint? Is this the proper syntax?
2. How can I force in my code to use index MSEG~M without any program timeout?
For the whole source code of my question above, please see the link:
http://rapidshare.com/files/211740852/ZDXX0028.txt.html

Hi Thomas, thanks with the prompt reply (even if it's Saturday )
Yes, MKPF~BUD is being used.
The budat selection is narrowed to 28 days though users can input any date range, a warning message will just be displayed if budat selection exceeded.
Yes, optimizer usually chooses the right index; I'm not in as the same experience as you are though, but I find it interesting that after I added the Oracle hints (several combination) the performance of the program was optimize up to 40% to 50%.
I uploaded a detailed SQL trace and the ABAP change done in my program, if you'll notice in the summary of the changes, after adding some hints, the duration of the program was improved..
(SQL Trace Summary of my program) this worth taking a look
http://rapidshare.com/files/211870091/ZD28_SQL_Trace.zip.html
I made a custom index in MSEG, but unfortunately I doubt that it will be approve by our performance capacity team. But I somehow have a hunch that this will further optimize the program.
MSEG~Z03
MANDT     Client
WERKS     Plant
BWART     Movement Type (Inventory Management)
LGORT     Storage Location
What do you think Thomas and SAP experts?
**Sorry for pasting the whole ST05 result
     SELECT STATEMENT          ( Estimated Costs = 131.250 , Estimated #Rows = 450 )
                    6          FILTER
                    Filter Predicates
                    5          NESTED LOOPS
                    ( Estim. Costs = 131.249 , Estim. #Rows = 450 )
          Estim. CPU-Costs = 1.885.249.948 Estim. IO-Costs = 129.700
                    2          TABLE ACCESS BY INDEX ROWID          MKPF
                    ( Estim. Costs = 14.442 , Estim. #Rows = 288.570 )
               Estim. CPU-Costs = 206.401.140 Estim. IO-Costs = 14.272
               1          INDEX RANGE SCAN          MKPF~BUD
                    ( Estim. Costs = 655 , Estim. #Rows = 519.426 )
          Search Columns: 2
          Estim. CPU-Costs = 30.640.783 Estim. IO-Costs = 630
          Access Predicates          Filter Predicates
                    4          TABLE ACCESS BY INDEX ROWID          MSEG
                    Estim. CPU-Costs = 5.818 Estim. IO-Costs = 0
          Filter Predicates
          3          INDEX RANGE SCAN          MSEG~0
               Search Columns: 3
     Estim. CPU-Costs = 1.564 Estim. IO-Costs = 0
     Access Predicates          Filter Predicates

Query don't use the right index when using bind variables

Hi people !
I need some help because I have an issue with a query that don t use the right Indexes as it should
First of all, I have mainly three tables :
ORDER : Table that contains description for each Order (approximately 1 000 000 Records)
ORDER_MVTS : Table that contains the tasks made (called movements) to set up each Orders
with quantity of packages prepared for each product (approximately 10 000 000 Records)
PRODUCT : Tables that contains the products (approximately 50 000 Records)
When I launch the query with hard coded values, it brings back response very fast
because it uses the right index (ORDER_DHR_VALID) which represent the date and hour of the order
(with format 'DD/MM/YYYY HH24:MI:SS'). The selectivity for this index is good.
NB 1: I have to use the trick " >= Trunc(date) and < trunc(date) +1 " to filter on a simple date because
the index contains hour and minutes (I know it wasn't probably a bright idea at conception time).
NB 2: The index on ORDER_MVTS.PRODUCT_CODE is'nt discriminating enough because there is'nt enough different products.
It's the same for index on CUSTOMER_CODE and on MVT_TYPE so only the index on ORDER.DHR_VALID is good.
Here is the correct explain plan when I execute the query with hard coded values :
SELECT SUM(ORDER_MVTS.NB_PACKAGE)
FROM ORDER_MVTS, PRODUCT, ORDER
WHERE ORDER.DHR_VALID >= TRUNC(to_date('14/11/2008 10:04:56','DD/MM/YYYY HH24:MI:SS'))
AND ORDER.DHR_VALID < TRUNC(to_date('14/11/2008 10:04:56','DD/MM/YYYY HH24:MI:SS')) + 1
AND ORDER_MVTS.MVT_TYPE = 'DELIVERY'
AND PRODUCT.CODE = ORDER_MVTS.PRODUCT_CODE
AND ORDER_MVTS.ORDER_CODE = ORDER.CODE
AND ORDER.CUSTOMER_CODE = 'ADIDAS'
AND PRODUCT.CODE = 1234
Rows Row Source Operation
1 SORT AGGREGATE
2 NESTED LOOPS
4 NESTED LOOPS
2 INDEX UNIQUE SCAN (object id 378548) --> PRODUCT_PK
4 TABLE ACCESS BY INDEX ROWID ORDER
777 INDEX RANGE SCAN (object id 378119) --> ORDER_DHR_VALID
2 TABLE ACCESS BY INDEX ROWID ORDER_MVTS
30 INDEX RANGE SCAN (object id 377784) --> ORDER_MVTS_ORDER_FK
Now the problem is when the query is used in a Cursor with bind variables.
It seems like Oracle don't use index on ORDER.DHR_VALID because he can't figure out that he have
to actually filter on a short period of time (only one day).
So Oracle uses the index on ORDER_MVTS.PRODUCT_CODE which is'nt a bright idea (it takes 10 secondes instead of just one)
Here is the bad explain plan :
Rows Row Source Operation
1 SORT AGGREGATE
2 NESTED LOOPS
722 NESTED LOOPS
2 INDEX UNIQUE SCAN (object id 378548) --> PRODUCT_PK
722 TABLE ACCESS BY INDEX ROWID ORDER_MVTS
1790 INDEX RANGE SCAN (object id 377777) --> ORDER_MVTS_PRODUCT_FK
2 TABLE ACCESS BY INDEX ROWID ORDER
1442 INDEX UNIQUE SCAN (object id 378439) --> ORDER_PK
Now I have found two solutions to this problem :
1) using a Hint to force the use of index on ORDER.DHR_VALID (with /*+ INDEX(ORDER ORDER_DHR_VALID) */ )
2) Using Dynamic SQL and keeping the date hard coded (but not the other values except mvt_type)
For example :
QUERY :=
'SELECT SUM(ORDER_MVTS.NB_PACKAGE)
FROM ORDER_MVTS, PRODUCT, ORDER
WHERE ORDER.DHR_VALID >= TRUNC(TO_DATE('''||To_char(P_DTE_VAL,'DD/MM/YYYY')||''',''DD/MM/YYYY'')) '||
AND ORDER.DHR_VALID < TRUNC(TO_DATE('''||To_char(P_DTE_VAL,'DD/MM/YYYY')||''',''DD/MM/YYYY'')) + 1 '||
AND ORDER_MVTS.MVT_TYPE = 'DELIVERY'
AND PRODUCT.CODE = ORDER_MVTS.PRODUCT_CODE
AND ORDER_MVTS.ORDER_CODE = ORDER.CODE
AND ORDER.CUSTOMER_CODE = :CUSTOMER
AND PRODUCT.CODE = :CODE ';
These two solutions work but Number 1 is bad in theory because it uses a Hint
and Number 2 may be difficult to code.
So my question is : Does someone knows another solution to force the use of index ORDER_DHR_VALID that can be simple and reliable.
Thank you very much for support
Edited by: remaï on Apr 1, 2009 4:08 PM

What version of oracle you have? CBO work is different in 9i and 10g.
Usually cost based optimizer do not want to use index for >< condition with binding variables because optimizer can not use statistic to determine selectivity, and by default selectivity of <> operators is low.
(As I remember '>' selectivity by default is 5%, you have two conditions > and <, therefore resulting selectivity will be 0.05*0.05=0.0025 as two independent events, but selectivity of other conditions
ORDER_MVTS.MVT_TYPE = 'DELIVERY' or ORDER.CUSTOMER_CODE = 'ADIDAS' looks much better for CBO)
The best solution I see is do not use binding variables. Actually your query looks as searching query, which executes not so often, therefore you will not have perfomance win along of skipping execution plan creation.
Edited by: JustasVred on Apr 1, 2009 10:10 AM

Context Index World Lexer ORA-03113: end-of-file on communication channel

I have release 10g Release 1 (10.1.0.2.0) for Windows and trying to take advantage of the World Lexer.
My table is:
create table worldtest(
filename char(32),
content blob
I've created a preference for the WORLD_LEXER:
     begin
     ctx_ddl.create_preference('wlex', 'WORLD_LEXER');
     end;
Right now I'm working with 10,000 records of PDF, MS-Word, Text, and HTM documents. When I try and create a context index using this lexer:
create index i_ctx_wc on worldtest(content)
indextype is ctxsys.context
parameters ('lexer wlex');
The following error is returned, and I have to use drop index force to remove the index. Without 'Force' a message is return saying the index is an a loading state, but nothing is occuring.
create index i_ctx_wc on worldtest(content)
indextype is ctxsys.context
ERROR at line 1:
ORA-03113: end-of-file on communication channel
The indexing works fine when I leave the world lexer preference out.
Any suggestions would be wonderful. I've been banging my head on this one for a while.
Thanks.

Hi,
I couldn't reproduce (different version which is perhaps the problem). Check out bug 4056162. ORA-3113 related to the use of the world lexer. The resolution is not published externally, so no help there, but the bug is closed so perhaps support can provide some insight.
Thanks.

How to utilize index in selection statement

hi
how to utilize index in selection statement and how is it reduces performance whether another alternative is there to reduce performance .
thanks

Hi Suresh,
For each SQL statement, the database optimizer determines the strategy for accessing data records. Access can be with database indexes (index access), or without database indexes (full table scan).The cost-based database optimizer determines the access strategy on the basis of:
*Conditions in the WHERE clause of the SQL statement
*Database indexes of the table(s) affected
*Selectivity of the table fields contained in the database indexes
*Size of the table(s) affected
*The table and index statistics supply information about the selectivity of table fields, the selectivity of combinations of table fields, and table size. Before a database access is performed, the database optimizer cannot calculate the exact cost of a database access. It uses the information described above to estimate the cost of the database access.The optimization calculation is the amount by which the data blocks to be read (logical read accesses) can be reduced. Data blocks show the level of detail in which data is written to the hard disk or read from the hard disk.
Inroduction to Database Indexes
When you create a database table in the ABAP Dictionary, you must specify the combination of fields that enable an entry within the table to be clearly identified. Position these fields at the top of the table field list, and define them as key fields.
After activating the table, an index is created (for Oracle, Informix, DB2) that consists of all key fields. This index is called a primary index. The primary index is unique by definition. As well as the primary index, you can define one or more secondary indexes for a table in the ABAP Dictionary, and create them on the database. Secondary indexes can be unique or non-unique. Index records and table records are organized in data blocks.
If you dispatch an SQL statement from an ABAP program to the database, the program searches for the data records requested either in the database table itself (full table scan) or by using an index (index unique scan or index range scan). If all fields requested are found in the index using an index scan, the table records do not need to be accessed.
A data block shows the level of detail in which data is written to the hard disk or read from the hard disk. Data blocks may contain multiple data records, but a single data record may be spread across several data blocks.
Data blocks can be index blocks or table blocks. The database organizes the index blocks in the form of a multi-level B* tree. There is a single index block at root level, which contains pointers to the index blocks at branch level. The branch blocks contain either some of the index fields and pointers to index blocks at leaf level, or all index fields and a pointer to the table records organized in table blocks. The index blocks at leaf level contain all index fields and pointers to the table records from the table blocks.
The pointer that identifies one or more table records has a specific name. It is called, for example, ROWID for Oracle databases. The ROWID consists of the number of the database file, the number of the table block, and the row number within the table block.
The index records are stored in the index tree and sorted according to index field. This enables accelerated access using the index. The table records in the table blocks are not sorted.
An index should not consist of too many fields. Having a few very selective fields increases the chance of reusability, and reduces the chance of the database optimizer selecting an unsuitable access path.
Index Unique Scan
If, for all fields in a unique index (primary index or unique secondary index), WHERE conditions are specified with '=' in the WHERE clause, the database optimizer selects the access strategy index unique scan.
For the index unique scan access strategy, the database usually needs to read a maximum of four data blocks (three index blocks and one table block) to access the table record.
select * from VVBAK here vbeln = '00123' ......end select.
In the SELECT statement shown above, the table VVBAK is accessed. The fields MANDT and VBELN form the primary key, and are specified with '=' in the WHERE clause. The database optimizer therefore selects the index unique scan access strategy, and only needs to read four data blocks to find the table record requested.
Index Range Scan
select * from VVBAP here vbeln = '00123' ......end select.
In the example above, not all fields in the primary index of the table VVBAP (key fields MANDT, VBELN, POSNR) are specified with '=' in the WHERE clause. The database optimizer checks a range of index records and deduces the table records from these index records. This access strategy is called an index range scan.
To execute the SQL statement, the DBMS first reads a root block (1) and a branch block (2). The branch block contains pointers to two leaf blocks (3 and 4). In order to find the index records that fulfill the criteria in the WHERE clause of the SQL statement, the DBMS searches through these leaf blocks sequentially. The index records found point to the table records within the table blocks (5 and 6).
If index records from different index blocks point to the same table block, this table block must be read more than once. In the example above, an index record from index block 3 and an index record from index block 4 point to table records in table block 5. This table block must therefore be read twice. In total, seven data blocks (four index blocks and three table blocks) are read.
The index search string is determined by the concatenation of the WHERE conditions for the fields contained in the index. To ensure that as few index blocks as possible are checked, the index search string should be specified starting from the left, without placeholders ('_' or %). Because the index is stored and sorted according to the index fields, a connected range of index records can be checked, and fewer index blocks need to be read.
All index blocks and table blocks read during an index range scan are stored in the data buffer at the top of a LRU (least recently used) list. This can lead to many other data blocks being forced out of the data buffer. Consequently, more physical read accesses become necessary when other SQL statements are executed
DB Indexex :Concatenation
In the concatenation access strategy, one index is reused. Therefore, various index search strings also exist. An index unique scan or an index range scan can be performed for the various index search strings. Duplicate entries in the results set are filtered out when the search results are concatenated.
Select * from vvbap where vbeln in ('00123', '00133', '00134').
endselect.
In the SQL statement above, a WHERE condition with an IN operation is specified over field VBELN. The fields MANDT and VBELN are shown on the left of the primary index. Various index search strings are created, and an index range scan is performed over the primary index for each index search string. Finally, the result is concatenated.
Full Table Scan
select * from vvbap where matnr = '00015'.
endselect
If the database optimizer selects the full table scan access strategy, the table is read sequentially. Index blocks do not need to be read.
For a full table scan, the read table blocks are added to the end of an LRU list. Therefore, no data blocks are forced out of the data buffer. As a result, in order to process a full table scan, comparatively little memory space is required within the data buffer.
The full table scan access strategy is very effective if a large part of a table (for example, 5% of all table records) needs to be read. In the example above, a full table scan is more efficient than access using the primary index.
In Brief
Index unique scan: The index selected is unique (primary index or unique secondary index) and fully specified. One or no table record is returned. This type of access is very effective, because a maximum of four data blocks needs to be read.
Index range scan: The index selected is unique or non-unique. For a non-unique index, this means that not all index fields are specified in the WHERE clause. A range of the index is read and checked. An index range scan may not be as effective as a full table scan. The table records returned can range from none to all.
Full table scan: The whole table is read sequentially. Each table block is read once. Since no index is used, no index blocks are read. The table records returned can range from none to all.
Concatenation: An index is used more than once. Various areas of the index are read and checked. To ensure that the application receives each table record only once, the search results are concatenated to eliminate duplicate entries. The table records returned can range from none to all.
Regards,
Balaji Reddy G
***Rewards if answers are helpful

Index array is not getting new values from DAQ

I am measuring force values with my DAQ card and these values are always changing. However, in my programming something is not working right with the way I have things set up. After my DAQ I have a "Convert to Dynamic Data" and after that I have an "Index Array". When the program is executing and I turn on the highlight option I do not get changing force values after the "Convert to Dynamic Data" and therefore no changing force values enter my "Index Array". Whaterever the first value is that gets passed to the "Convert to Dynamic Data" is the only value that I get for the remainder of the program. I tried plugging in an indicator between the DAQ and the "Convert to Dynamic Data" and it did show varying values. Please help with my program. I have tried messing with the properties of the "Convert to Dynamic Data" and nothing has worked. I am stuck and cannot see how to fix this problem. I have attached my program as it is currently put together.
Thank You In Advance,
Gabe.
Attachments:
Actuator_Gabe_Oct27_Flat_Sequence_XY_+Measurement_File.vi ‏131 KB

Please know that the best option is to review the concepts discussed to further understand programming in LabVIEW. Perhaps you could take a look through ni.com/gettingstarted and ni.com/lv101 to have a look at some of the online help materials. I have included a VI snippet of the while loop containing the changes. Further, the code you attached contains a lot of customer controls and VIs, which are not common to all LabVIEW users. It is a best practice to only attach the code of value to the question/post, and to have the most simplified version of the problem.
Best,
Adam
Academic Product Manager
National Intruments

Force record to be indexed

Similar Messages

Maybe you are looking for