Rule Index Creation taking indefinte time

I am using Oracle 10.2.0.3 database. I have a model with nearly 250000 triples. When I am trying to create rule index on it using 'rdfs' rulebase, it is taking indefinite time. Yesterday night I have started the script and even after 15 hours it was still not completed. When I checked in the RDFI_RULEINDEX_INFO view, it is showing its status as invalid. I am able to create rulindex with 'rdf' on the same model. Also, I am able to create rule indexes on all other models with 'rdfs'.
Can you tell me why this is happening? This is a priority task for me, please reply soon.
Thanks,
Rajesh Narni.
Edited by: rajesh narni on Sep 10, 2008 10:59 PM

Below is the PL/SQL procedure that i am calling:
begin
sdo_rdf_inference.create_rules_index(
'Sample_rix',
sdo_rdf_models('SampleModel'),
sdo_rdf_rulebases('rdfs')
end;
I am able to create rule indexes for all other models with the combination of rdfs and rdf rulebase. For the SampleModel, I could create a rule index with rdf rulebase. But I could not create a rule index with rdfs rulebase and SampleModel.
Thanks,
Rajesh.

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

  • Index Deletion taking more time

    Dear BWers,
    I am facing a problem with Index deletion of some of the cubes (total 10). Two weeks back index deletion of all the cubes used to complete in less time. But from the last two weeks, index deletion process is taking more time, almost triple the time it used to take.
    Any idea why this could have happened or any pointers to documents on improving the time taken by index deletion processes will be highly appreciated and will also be rewarded.
    Thanks in advance.
    Madhav

    Madhav,
       Make sure you required Background Process available.
    One more thing... you can ask your DBA/Basis folks to look into it. They can tell you what is happening at the DB Level.
    You try to analyze that from SM51.
    Nagesh Ganisetti.
    Assign points if it helps.

  • Why oracle text index column taking long  time

    why oracle text index column is taking long time to return result.I created text index on a column if I run the query on a single table result is very fast.If I join table with other table (10 records only )
    it is taking long time but in explain plan it is searching by index only.
    I created this index for searching a varchar2 column,the data is comma seperated values like ( UK,US,IT,BR) and the table having records 20 lakhs.Normally if I query with like operater
    ( like '%US%' ) it is taking full table scan because I am using '%' both sides. Please help me on this regard how to search the data with less time. Here is may sample code and explain plan.
    SQL*Plus: Release 9.2.0.1.0 - Production on Wed Jan 28 16:54:22 2009
    Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
    Connected to:
    Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
    With the Partitioning, OLAP and Oracle Data Mining options
    JServer Release 9.2.0.1.0 - Production
    SQL> set timing on
    SQL> set linesize 180
    SQL> explain plan for SELECT T.esongid FROM (SELECT A.ESONGID FROM wcmedeco.EDECO_ESONGS_TERR_CTRY 
    A WHERE CONTAINS(A.TERR_CTRY_NAMES,'US')>0  
      2  GROUP BY A.ESONGID)K,T
      3  WHERE  K.ESONGID=T.ESONGID;
    Explained.
    Elapsed: 00:00:00.01
    SQL> select *from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    | Id  | Operation                      |  Name                   | Rows  | Bytes | Cost  |
    |   0 | SELECT STATEMENT               |                         |     1 |    26 |     4 |
    |   1 |  NESTED LOOPS                  |                         |     1 |    26 |     4 |
    |   2 |   VIEW                         |                         |     1 |    13 |     4 |
    |   3 |    SORT GROUP BY               |                         |     1 |    89 |     4 |
    |   4 |     TABLE ACCESS BY INDEX ROWID| EDECO_ESONGS_TERR_CTRY  |     1 |    89 |     2 |
    |   5 |      DOMAIN INDEX              | IDX_TERR_CTRY_NAMES     |       |       |     0 |
    |   6 |   INDEX RANGE SCAN             | IDX_ESONGID_T           |     1 |    13 |     1 |
    PLAN_TABLE_OUTPUT
    Note: cpu costing is off, 'PLAN_TABLE' is old version
    14 rows selected.
    Elapsed: 00:00:00.00
    SQL> Regards,
    Rajasekhar

    You have not formatted your code properly so we cannot see the query you're executing. Please put some line breaks in.
    Secondly, how fresh are the statistics on those tables? Are you really returning one record out of twenty million?
    Cheers, APC
    blog: http://radiofreetooting.blogspot.com

  • Parallel Index creation takes more time...!!

    OS - Windows 2008 Server R2
    Oracle - 10.2.0.3.0
    My table size is - 400gb
    Number of records - 657,45,95,123
    my column definition first_col varchar2(22) ; -> I am creating index on this column
    first_col -> actual average size of column value is 10
    I started to create index on this column by following command
    CREATE INDEX CALL_GROUP1_ANO ON CALL_GROUP1(A_NO) LOCAL PARALLEL 8 NOLOGGING COMPRESS ;
    -> In my first attempt after three hours I got an error :
    ORA-01652: unable to extend temp segment by 128 in tablespace TEMP
    So I increased the size of temp tablespace to 380GB ,Because i expect the size of first_col index this much.
    -> In my second attempt Index creation is keep going even after 17 hours...!!
    Now the usage of temp space is 162 GB ... still it is growing..
    -> I checked EM Advisor Central ADDM :
    it says - The PGA was inadequately sized, causing additional I/O to temporary tablespaces to consume significant database time.
    1. why this takes this much of Temp space..?
    2. It is required this much of time to CREATE INDEX in parallel processing...? more than 17 hrs
    3. How to calculate and set the size of PGA..?

    OraFighter wrote:
    Oracle - 10.2.0.3.0
    My table size is - 400gb
    Number of records - 657,45,95,123
    my column definition first_col varchar2(22) ; -> I am creating index on this column
    first_col -> actual average size of column value is 10
    I started to create index on this column by following command
    CREATE INDEX CALL_GROUP1_ANO ON CALL_GROUP1(A_NO) LOCAL PARALLEL 8 NOLOGGING COMPRESS ;
    Now the usage of temp space is 162 GB ... still it is growing..The entire data set has to be sorted - and the space needed doesn't really vary with degree of parallelism.
    6,574,595,123 index entries with a key size of 10 bytes each (assuming that in your choice of character set one character = one byte) requires per row approximately
    4 bytes row overhead 10 bytes data, 2 bytes column overhead for data, 6 bytes rowid, 2 bytes column overhead for rowid = 24 bytes.
    For the sorting overheads, using the version 2 sort, you need approximately 1 pointer per row, which is 8 bytes (I assumed you're on 64 bit Oracle on this platform) - giving a total of 32 bytes per row.
    32 * 6,574,595,123 / 1073741824 = 196 GB
    You haven't said how many partitions you have, but you might want to consider creating the index unusable, then issuing a rebuild command on each partition in turn. From "Practical Oracle 8i":
    <blockquote>
    In the absence of partitioned tables, what would you do if you needed to create a new index on a massive data set to address a new user requirement? Can you imagine the time it would take to create an index on a 450M row table, not to mention the amount of space needed in the temporary segment. It's the sort of job that you schedule for Christmas or Easter and buy a couple of extra discs to add to the temporary tablespace.
    With suitably partitioned tables, and perhaps a suitably friendly application, the scale of the problems isn't really that great, because you can build the index on each partition in turn. This trick depends on a little SQL feature that appears to be legal even though I haven't managed to find it in the SQL reference manual:
         create index big_new_index on partitioned_table (colX)
         local
         UNUSABLE
         tablespace scratchpad
    The key word is UNUSABLE. Although the manual states that you can 'alter' an index to be unusable, it does not suggest that you can create it as initially unusable, nevertheless this statement works. The effect is to put the definition of the index into the data dictionary, and allocate all the necessary segments and partitions for the index - but it does not do any of the real work that would normally be involved in building an index on 450M rows.
    </blockquote>
    (The trick was eventually documented a couple of years after I wrote the book.)
    Regards
    Jonathan Lewis

  • Index creation a long time..Please help to tune the creation time.

    Hi all,
    I am creating a index after using impdp to put the data in that table.
    Below is my index creation command.The index creation takes ~30 minutes .
    Can the forum memebers suggest me how to put this index creation with parallel clause or otherwise to reduce the time it takes to create the index?
    +++++++++++++++++++++++++++++++++++++++++++++++
    spool incre_HUNTER_PK_1.log
    set lines 200 pages 0 echo on feedback on timing on time on
    alter session enable parallel dml;
    alter session enable parallel ddl;
    CREATE UNIQUE INDEX "HUNTER_PK" ON "HUNTER" ("HUNTER_NUM", "BILL_SEQ", "BILL_VERSION")
    PCTFREE 10 INITRANS 2 MAXTRANS 255 NOLOGGING COMPUTE STATISTICS
    STORAGE(INITIAL 4294967296 NEXT 16777216 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "HUNTER_LARGE_02";
    ALTER TABLE HUNTER ADD PRIMARY KEY ("HUNTER_NUM", "BILL_SEQ", "BILL_VERSION") USING INDEX HUNTER_PK;
    ALTER INDEX "HUNTER_PK" NOLOGGING NOPARALLEL;
    spool off
    +++++++++++++++++++++++++++++++++++++++++++++++
    Some other details:
    1. My imdp command import nearly the below details
    . . imported "HUSTY"."HUNTER" 42.48 GB 218185783 rows
    2. It is a non-partitioned table.
    3. I cant drop the table at the target.
    Regds,
    Kunwar

    Kunwar wrote:
    Can the forum memebers suggest me how to put this index creation with parallel clause or otherwise to reduce the time it takes to create the index?
    What version of the database?
    Creating indexes in parallel is described in the documentation. Search the on-line documentation for the syntax for create index; if there aren't any specific examples of creating indexes in parallel do a Google search for "create index parallel"

  • Create Index Step taking long time

    I have a create index step in process chain for a infocube. The Create Index step is takes more time. The requests in this cube are rolled up and compressed. The batch process are also avaliable. But still the create index step takes more time. Any suggestions to reduce the time of create index step?

    Hi,
    If you have more Data in Cube then it will take some time..check any Dumps in ST22 and SM21. Ask Basis Team any Error messages in DB02 and check.
    Else goto to RSRV
    Tests in Transaction RSRV --> Database --> Database Indices of an InfoCube and Its Aggregates
    Give Cube name and execute it and see the errors then if any RED color, ckick on Repaire Icon and see.
    Thanks
    Reddy

  • Materialized view creation taking long time

    Hi All,
    We are creating a dimensional OLAP model with the Materialized views. In that we are having 7 dimensions and 1 fact table. I have created all the dimensions with the materialized views with out any problem. But when im trying to create my Fact materialized view it is running for 14 hours and is still running. I'm waiting to see when it will complete. The select statement in the Fact MV returns only 19 records and that too in seconds. But when i use the same select statement for MV creation it is taking a long time. I dont know how long it gonna take. How can i reduce this long running time. Mean while my fact MV is having nearly 15 joins with other physical tables and dimensions.
    Thanks in advance,
    Karthick

    Hi all,
    Thanks for your reply..
    I think i dint clearly mention my problem..
    The select statement for the MV will return 19 records. But when im trying to create the MV it is taking quite a long time. it ran for >14 hours but still it dint create a MV. Why is it happening like this? Is it possible to increase the performance.
    Thanks,
    Karthick

  • Table access by index rowid taking more time

    Hi All
    I've a query like
    update tab1
      set col1 = ( select col2 from
                           tab2 
                    where tab1.id = tab2.id) table 1 has arnd 10,000 rows
    table 2 has arnd 1,700,000 rows and has a primay key on column id.
    This query is taking around 20 secs to execute. I checked the xplan and most of time taken for table access by index rowid.
    Could you please suggest what can be the reason for this. (Can it be the clustering factor or something else)
    I checked the stats for the tab2, its just three days old.
    Regards
    Ashwani

    >
    table 1 has arnd 10,000 rows
    table 2 has arnd 1,700,000 rows and has a primay key on column id.
    This query is taking around 20 secs to execute. I checked the xplan and most of time taken for table access by index rowid.
    Could you please suggest what can be the reason for this. (Can it be the clustering factor or something else)
    I checked the stats for the tab2, its just three days old.
    >
    If you checked the xplan why haven't you posted it so we can look at it? Then we could see what table is being accessed by index rowid. Presumably it is table 2 but we the plan would eliminate the need to make assumptions.
    The clustering factor could be a factor. You haven't told us how table1 is being accessed. All rows are being updated so a full table scann is most likely but again the plan would actually show the access.
    Did you query the dictionary to see what the clustering factor is? Post the results of that
    SQL> select index_name, leaf_blocks, avg_leaf_blocks_per_key, avg_data_blocks_per_key, clustering_factor, distinct_keys
    2 from dba_indexes
    3 where owner = 'schema'
    4 and index_name in ('index_b','index_a');

  • Index creation during prime time

    In a production environment, where a table is accessed by online users, can an index be created on the table at the same time ? I mean, will this affect performance and is it only performance that is affected. Insert, Delete, update and select operations will be performed by users at the time. Which of these areas will be affected and are there any other potential issues ? (The table is a partitioned table with 30 partitions)
    Thanks

    404045, it would have been nice if you would have mentioned the version of Oracle you are working with and what kind of table the index is being built on: heap, IOT, partitioned, non-partitioned.
    As Vivek mentioned you can add the index online if you have version 9+ otherwise as Syed said the create index operation will require an exclusive lock on the table and hold up all DML. More than likely if the table is busy you will not be able to get the lock to run the create index.
    From a couple of tests Online index create and rebuild operations definitely affect the performance of DML operations on the base table and these DML operations definitely affect the time it takes for the index to build.
    HTH -- Mark D Powell --

  • Index synchronization taking long time

    We are trying to do content search on documents in a table. We have around 320 Gigs of data on version 9.0.1.1.0 of IFS.
    When we try to run index synchronization on the table it has taken more than 48 hours and hasn't completed.
    begin
    ctx_ddl.sync_index ( idx_name => 'ifs_text' );
    end
    We can’t afford to let it run for that long.
    Any help is greatly appreciated.

    First try the easy things -
    * Increase the memory setting in your call to SYNC_INDEX - if you are able.
    * Run in parallel
    * Do it off-peak hours of course
    If still not acceptable, a couple of more questions will help clarify the situation some.
    * How many records are pending (ctx_pending)
    * Run ctx_report.describe_index and ctx_report.index_size and report those (send them to my e-mail if too big to post - [email protected] )
    I think the remainder of my questions will be answered by the ctx_report output. If you need help on ctx_report, I have an Oracle magazine article on the subject that might help you generate the output. It is at: http://www.oracle.com/technology/oramag/oracle/04-sep/o54text.html.
    -Ron

  • Creation of  rules index failing with ORA-01652 exception

    I am trying to create a rules index in the following way,
    BEGIN
         SEM_APIS.CREATE_RULES_INDEX(
         'APPS_RDF_IDX',
         SEM_Models('SEMANTIC_SEARCH_MODEL'),
         SEM_Rulebases('OWLPRIME','SEMANTIC_SEARCH_RULEBASE'));
    END;
    with semantic_search_rulebase having about 5 rules and with 28839 triples in the model.
    When I am trying to run create index it fails after a long time by throwing exception
    ORA-01652: unable to extend temp segment by 128 in tablespace TEMP
    though TEMP is allocated 5GB memory.
    Please clarify me on the following questions,
    1. How much TEMP space should be allocated if the triples are going to be in millions and rules at about 10 to 100 and why is indexing taking a lot of TEMP space with a less amount of triples.
    2. How much time normally would create rules index take with triples of size from thousands to millions.
    3. How to make the create rules index run faster.
    Thanks,
    Phani

    First of all, please start using create_entailment API instead of that create_rules_index API.
    Regarding 1), 5GB temp space is not a whole lot.
    It is hard to say exactly how much you need because you have user defined rules.
    Regarding 2) and 3), please check out the following inference best practice paper.
    http://www.oracle.com/technology/tech/semantic_technologies/pdf/semantic_infer_bestprac_wp.pdf
    Also, if you like, please post your rules and I may be able to help you model
    some of your rules using native OWL constructs.

  • Time, more taken in index creation

    when i create an normal index on one column or an composite index on 3-4 columns on a table having say 9-10 million records, the time is too much, i did it in our test database & it too upto an hour to create the index. Please help in explaining, why it is taking so much time.
    regards.

    Well it depends what you consider the time should be. Indexing a table of 10m records is going to take time but to speed things up a bit you could specify NOLOGGING in the index creation script, you should take a backup afterwards though.
    HTH
    David

  • Oracle Text Index taking Much time for retreiving records

    Hi,
    I an using the context based index on the table with the xmltype column and using the mentioned preferences, fuzzy, stemming and substring.
    I m also using the INPATH and the HASPATH operators to search on the XML contents.
    The total no of records in the table is 1,14,24,340.
    When i execute the query on the table it is taking atleast 20 secs to return the results.
    Could anyone suggest some method to improve the performance ?

    Hi,
    Please find belwo the details,
    Table Structure - sample_t(id NUMBER, type VARCHAR2(10),smpl_xml XMLTYPE)
    Preference:
    begin
    ctx_ddl.create_preference('SAMPLE_PREF', 'BASIC_WORDLIST');
    ctx_ddl.set_attribute('SAMPLE_PREF','FUZZY_MATCH','ENGLISH');
    ctx_ddl.set_attribute('SAMPLE_PREF','FUZZY_SCORE','0');
    ctx_ddl.set_attribute('SAMPLE_PREF','FUZZY_NUMRESULTS','200');
    ctx_ddl.set_attribute('SAMPLE_PREF','SUBSTRING_INDEX','TRUE');
    end;
    Index Creation:
    CREATE INDEX sample_dmn_idx ON sample_t(smpl_xml)
    INDEXTYPE IS CTXSYS.CONTEXT FILTER BY type PARAMETERS
    ('LEXER basic_lexer_pref
    WORDLIST SAMPLE_PREF
    SECTION GROUP CTXSYS.PATH_SECTION_GROUP');
    Query :
    select ts.id from sample_t ts
    WHERE CONTAINS (ts.smpl_xml, 'HASPATH(/ROOT/VAL/chars/_7= "POWDERED FRUIT DRINKS")
    AND HASPATH(/ROOT/VAL/chars/_46= "POUCH")
    AND HASPATH(/ROOT/VAL/chars/_62= "LEMONADE")
    AND HASPATH(/ROOT/VAL/chars/_88= "PIED")
    AND HASPATH(/ROOT/VAL/chars/_732= "SWEET")
    AND HASPATH(/ROOT/VAL/chars/_2971= "ALL FAMILY")
    AND HASPATH(/ROOT/VAL/chars/_3115= "UNKNOWN")
    AND HASPATH(/ROOT/VAL/chars/_3182= "YES")
    AND HASPATH(/ROOT/VAL/chars/_3340= "OTHER")',1) > 0
    AND ts.type = 'ITEM'
    Query Data:_     
    ID TYPE           smpl_xml
    1      ITEM                <ROOT> <CODE>927</CODE> <VAL> <chars> <_7>AFTER SHAVE LOTIONS..</_7> <_27>OLD SPICE..</_27> <_46>REMAINING..</_46> <_4006>OLD SPICE..</_4006> </chars> </VAL> </ROOT>
    Plan hash value: 1588539682
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 562K| 52M| 308K (1)| 01:01:43 |
    |* 1 | TABLE ACCESS BY INDEX ROWID| sample_t               | 562K| 52M| 308K (1)| 01:01:43 |
    |* 2 | DOMAIN INDEX | sample_dmn_idx     | | | 222K (0)| 00:44:34 |
    Predicate Information (identified by operation id):
    1 - filter("TS"."ENTY_TYP_MNM"='ITEM')
    2 - access("CTXSYS"."CONTAINS"(SYS_MAKEXML(0,"SYS_NC00004$"),'HASPATH(/ROOT/VAL/chars/_7= "POWDERED FRUIT DRINKS") AND
    HASPATH(/ROOT/VAL/chars/_46= "POUCH") AND
    HASPATH(/ROOT/VAL/chars/_62= "LEMONADE") AND
    HASPATH(/ROOT/VAL/chars/_88= "PIED") AND
    HASPATH(/ROOT/VAL/chars/_732= "SWEET") AND
    HASPATH(/ROOT/VAL/chars/_2971= "ALL FAMILY") AND
    HASPATH(/ROOT/VAL/chars/_3115= "UNKNOWN") AND
    HASPATH(/ROOT/VAL/chars/_3182= "YES") AND
    HASPATH(/ROOT/VAL/chars/_3340= "OTHER")',1)>0)
    Edited by: user13780543 on Aug 17, 2011 2:12 AM
    Edited by: user13780543 on Aug 17, 2011 2:13 AM
    Edited by: user13780543 on Aug 17, 2011 2:14 AM

  • Sales order creation, standard event trigger is taking long time .

    We have a requirement where we are sending data to CRM system using RFC function module. This data is sent while sales order creation or change. We have used standard event BUS2032.CREATED to trigger CRM FM in sales order creation mode. In sales order change mode, we are using custom event. In production system, our custom change event is getting triggered fine and data is sent to CRM system with small time lag of around 1 minute. But, while sales order creation, standard event trigger is taking long time ( sometimes about 20 minutes) in production system.
    We tried triggering same custom event at the time of sales order creation using FM u2018SWE_EVENT_CREATE_IN_UPD_TASKu2019 as well but, still we are not able to improve performance of the event trigger at sales order creation.
    Regards,
    Sushee Joshi

    HI,
    we have written SWE_EVENT_CREATE in update task
    I think instead of calling in update task simply call to function module CALL FUNCTION "SWE_EVENT_CREATE" might trigger the event immediately.. Did you try to check in this way..
    OR
    And I also suggest you to check the entry in SWE2 txn with respect to your workflow tempalte, may be you have enable the option ENABLE EVENT QUEUE, this could be one of the reasons.. If it is enabled please disable it (uncheck)
    Please check..
    Regards
    Pavan

Maybe you are looking for