Delta Indexing

Hi All,
We have created a programme named RSRETDELTAINDEXING by refering SAP note 1003868 - KPRO Delta indexing report. Usually it indexes the delta indexing in search criteria. But presently it is not working.
If we do the full indexing through SAP standerd programme RSTIRIDX it is working. But the full indexing will take much time to index the same.
Can anyone help me out to solve this delta indexing issue..
Regards
Harshavardhan.G

If anyone has same problem in user search (who is who)...i found a solution, that works for me.
After a user changes his properties in his user profile i do the following
IIndexService indexService = (IIndexService)ResourceFactory.getInstance().getServiceFactory().getService(IServiceTypesConst.INDEX_SERVICE);
IIndex i = indexService.getIndex("ume");
IResourceFactory aResourceFactory = ResourceFactory.getInstance();
IResource rsrc = aResourceFactory.getResource(RID.getRID("/ume/users/" + user.getUniqueID() +".usr"), aResourceFactory.getServiceContext());
i.indexDocument(rsrc);
This way only the changed user is reindexed.
regards
Alex

Similar Messages

Talent Management - TM - Trex 7.1 - Delta Indexing

luke.....are you out there??
congrats on your blog being featured right on the SDN homepage... very nice...
http://scn.sap.com/community/erp/hcm/blog/2010/09/20/setting-up-netweaver-embedded-search-trex-for-sap-ehp4-talent-management
and congrats to Chris on his first two excellent blogs....
http://scn.sap.com/people/chris.mcnarney/blog/2010/08/26/whats-included-with-the-predefined-performance-management-process
http://scn.sap.com/people/chris.mcnarney/blog/2010/09/09/whats-included-with-the-predefined-performance-management-process--part-2
all 3 blogs are very helpful since there is little information available out there on these topics...
so we've been testing the delta indexing program very heavily - ESH_IX_PROCESS_CHANGE_POINTERS
we have found that it does not appear to be able to index new hires (new central_person index does not pick up the new CP). The only way this data can be indexed is by running a full re-index. That is problematic for us, b/c we were hoping to only do full re-indexing 1 a week or even 1 a month. our indexes take 2-3 hrs to complete and trex searching is pretty much inoperable during that time.
Have you tested new hires with delta indexing? it seems as a gap in the change_pointers program. We opened up OSS message to SAP.
some additional thoughts working with the program, relative to your blog. I would highly recommend that anyone testing this makes sure the following notes are implemented in your system. The first one is the most recent and we ourselves did not have that implemented.
1. 0.350 BC-EIM-ESH 1441190 Error in model assignments to logical system 24.02.2010
2. 0.230 BC-EIM-ESH 1408655 Alerts in syntax check due to unused indexes 18.11.2009
3. 0.260 PA-TM 1395703 Positions and termination are missing for indexing 30.10.2009
4. 0.330 BC-EIM-ESH 1249482 Functional corrections for Enterprise Search 7.01 SP03 26.01.2009
Another area which we found from testing: SAP by default does not delta index structural authority view. What this means is that if a new talent specialist is added with 741 relationship there access to see that structure will not be available in TREX search by default delta indexing. This would also impact existing organizations and positions shifted under existing 741 relationships.
The information in spro is actually quite helpful, you can find it in: talent management and talent development > basic settings > search > BAdI: Activate Delta Indexing for Authorization Data
Activtate the BADI, than the program to "create the change pointers" must run periodically in your system. This is done with RPTMC_CREATE_CHANGEPOINT_AUTH. Once that program creates the change pointers the next time your scheduled delta program runs (ESH_IX_PROCESS_CHANGE_POINTERS) all of the structural auths will be created and indexed correctly.
If we can just now get new hires to work with ESH_IX_PROCESS_CHANGE_POINTERS we will probably only run the full re-index once a week or once a month.
Let me know your thoughts,
Michael
Message was edited by: Luke Marson
Message was edited by: Luke Marson

so if anyone is interested, from my previous post I mentioned that new hires were not getting picked up by the change pointers program.
after further testing though, we found that when the authorization recon program identifies the new hires and appropriately creates a change pointer.
conclusion: to avoid full re-indexing of trex indexes, perform the following steps:
1. implement / activate the BADI - HRTMC_AUTHORITY_VIEW - talent management -> basic settings -> search
2. Schedule program RPTMC_CREATE_CHANGEPOINT_AUTH - every 30 mins, or 1 or 2 hr. This program will capture whenever anything changes from an authorization data perspective. This would include identifiying new central persons (new hires) or new TMC specialist being setup with 741 relationship. This program "creates change pointers" which than feeds the main delta program - ESH_IX_PROCESS_CHANGE_POINTERS.
3. Use Luke's blog on the instructions for the delta program - ESH_IX_PROCESS_CHANGE_POINTERS - this program you can have run every 5 mins, 10 mins, 15 mins, based on your needs. this processes all delta changes, the first time the program runs after the RPTMC_CREATE_CHANGEPOINT_AUTH program finishes it will also processes the data authorization changes, otherwise every other time the program is running it will catch non-data authorization for all the other indexes (employee name change, new performance rating, new potential, position name change, new profiiciency scale, new career profile data, etc).
hope this helps somebody!
michael
Edited by: Michael L Pappis on Oct 7, 2010 12:05 AM

Embedded Search - no delta Indexing

Hi Experts,
i want to configure Embedded Search in CRM 7.0. TREX is well configured and all Embedded Search configuration steps are done. I created all BO-Connectors in ESH_COCKPIT. But now I can`t start delta indexing (Actions-Schedule Indexing) because the Button is grey. The status of the connectors is new.
I also tried scheduling indexing with the report ESH_ADM_INDEX_ALL_SC, but it takes no effect.
What should i do?
Thanks,
Tobi

you mean on 7.0 and now you are on 7.1. Can you please be specific as i am also facing the same problem. i am on TREX 7.1 and tried report 'ESH_IX_PROCESS_CHANGE_POINTERS' but no any effact on trex search result. I created soem new data for job family and talent groups but its not coming up in HRTMC searches.
apprecite any help..
Mani

Embedded Search delta indexing

Hello all,
i am trying to create delta indexing for EA-HRXXX component in SAP ECC 6 EH4 on TREX search 7.10 (standalone) but its not taking into account my changes.
I created some test data on ECC6 EH4 system related to talent group (new talent group) and job family (for talents) , now my HRTMC_Search_OBJECTS not retruning data related to those objects. i tried to run program 'ESH_IX_PROCESS_CHANGE_POINTERSESH_IX_PROCESS_CHANGE_POINTERS' as said in documentation (http://help.sap.com/saphelp_nw70ehp1/helpdata/en/47/fb4c38469e59e8e10000000a421937/frameset.htm) but its not showing results.
any reply will be highly appreciateed.
Mani

Hi Mani,
yes, there are moderators in SDN.
But in the end the forums are community froums - they are not a support system with guaranteed answering times or anything of the like. So, if you have questions about mission critical errors, please do use SAP support.
If you are looking for answers to "how to..:" questions, SDN forums are a great channel, but - again - without any answering guarantee.
By the way, I understood you correctly that you have found an answer to your query, right?
Even if that may have been "not possible"...
Best, Karsten

BIA Delta Index Merge

Hi Gurus,
                 We have some cubes for BIA. In most of the cases, cubes get full and delta loads from different info sources and in some cases we have to delete the prior requests from the cubes.
Now I have following questions:-
1.     Which cube is best candidate for rebuilding the index and which for delta index?
2.     Which step in process chain we should call a program to merge the delta index?
3.     Should we create a separate process chain to merge delta index after all the loads are finished or we should call in the existing process chain.
Please help.
Warm Regards,
Anil

Hi Gurus,
                 We have some cubes for BIA. In most of the cases, cubes get full and delta loads from different info sources and in some cases we have to delete the prior requests from the cubes.
Now I have following questions:-
1.     Which cube is best candidate for rebuilding the index and which for delta index?
2.     Which step in process chain we should call a program to merge the delta index?
3.     Should we create a separate process chain to merge delta index after all the loads are finished or we should call in the existing process chain.
Please help.
Warm Regards,
Anil

When to set delta index flag for master data?

In transaction RSDDBIAMON2 option "Set Delta Flag" shows:
Table Name                     |Table Size          |Delta Index
/BIC/FTSGCSGMC          |10,155,000          |check mark in box
/BIC/DTSGCSGM1           |5,000,000           |check mark in box
/BI0/SVERSION               |700                    |check mark in box
When should I check the "Delta Index" column for fact, dimension, and master tables? I believe I need to check fact and dimension tables for delta BIA to occur during roll up so users can see the newly loaded requests but I am uncertain on when and why I should check this box for master data.
Thanks for your input.

Vitaliy,
Thanks for answering another of my question. Yes, we load master data a couple of times a day so based on your answer, I should also check box "Delta Index" for the master tables as well. Thanks for helping me understand this point.
If the below is our approach, #2 should be checked for all tables, correct?
1) Create/fill BIA index for cube "A"
2) Check the box "Delta Index" for all the tables which includes fact, dimension, and master tables for cube "A" .
3) Run process chain to roll up cube "A" daily
4) Run process chain to merge cube "A" weekly
Many thanks,
Thao

How to use the delta index in TREX?

We have been using TREX with EP KM for 2 years.
However we never used the delta index functionality.
Could you share your experience on how to use delta indexes?
Thanks!

Hai,
Please check the below link.....
http://help.sap.com/saphelp_nw70/helpdata/EN/d9/0418418291a854e10000000a1550b0/frameset.htm
Regards,
Yoganand.V

How to track BIA delta index merge and rebuild

Hi Gurus,
 I have set up process chains which load the BIA delta index and full index rebuild in separate process chains.
Is there any way to check if BIA is behaving as desired? I know to check RSDDSTATTREX table.
Regards,
Anil

Not a reply from Guru..
But I put my thoughts in and here are few take aways for you ,which you may wish to have a look in to..
PS - BI Accelerator is quite a Virgin territory ..few documentations or persons worked with ..
You can execute some performance checks with tcode - RSRV to validate the same.
BI Accelerator Performance Checks
1)Size of Delta Index
If you have chosen delta mode for an index of a table, new data is not written to the main index but to the delta index. This can significantly improve performance during indexing. However, if the delta index is large, this can have a negative impact on performance when you execute queries. When the delta index reaches 10% of the main index, the system displays a warning.
The system performs a merge for the index in repair mode. The settings are retained.
2) Propose Delta Index for Indexes
It is useful to create a delta index for large indexes that are often updated with new data. New data is not written to the main index, but to the delta index. This can significantly improve the performance of indexing, since the system only performs the optimize step on the smaller set of data from the delta index. The data from the delta index is used at the runtime of the query.
The system determines proposals from the statistics data: Proposals are those indexes that received new data more than 10 times during the last 10 days. A prerequisite for these proposals is that the statistics for the InfoCube are switched on.
Data in the main index and delta index should be merged at regular intervals (see test Size of Delta Index).
In repair mode, the system sets the Has Delta Indexproperty for the proposed indexes. The delta index is created when the data is next loaded for this index.
3)Compare Size of Fact Tables with Fact Index
The system calculates the number of records in both fact tables (E and F tables) for the InfoCube and compares them with the number of records in the fact index of the BI accelerator index. If the number of records in the BI accelerator index is significantly greater than the number in the InfoCube (more than a 10% difference), you can improve query performance by rebuilding the BIA index.
The following circumstances can result in differences in the numbers of records:
○ The InfoCube was compressed after the BI accelerator index was built. Since the BI accelerator index is not compressed, it may contain more records than the InfoCube.
○ Requests were deleted from the InfoCube after the BI accelerator index was built. The requests are deleted from the BIA index in the package dimension only. The records in the fact index are therefore no longer referenced and no longer taken into account when the query is executed; however, they are not deleted.
http://help.sap.com/saphelp_nw2004s/helpdata/en/6b/cda64246c6c96ae10000000a155106/content.htm
Hope it Helps
Chetan
@CP..

Integrating a Delta Index into the Main Index Using the Python Schedule

Dear All
As per below link we are failed to merge the delta to main index in Trex 7.10.
http://help.sap.com/saphelp_banking60/helpdata/ru/89/65a740aa053a13e10000000a155106/content.htm
Kindly help us
Regards
Sriram

Hi Mikhail
1. I did find any error message
2 In the Corntab.ini file at the end typed **0 14 * * * "python mergeDeltaIndex.py --silent --allIndexes=1 ''** is it right or not ?
3. after that how we can find weather out setting are correct or not?
Kindly help us
Regards
Sriram

TREX - how to setup delta indexing?

Hi,
I have got TREX installed and I could search in Succession Planning.
However, when I changed some data (for e.g. assigning a new user id to a PERNR), that new ID couldn't perform a search on employee.
I have scheduled the program ESH_IX_PROCESS_CHANGE_POINTERS, and this program could be completed without error.
But still, I couldn't perform a search until I manually run program ESH_ADM_INDEX_ALL_SC.
FYI, I'm following Luke's guide to setup the TREX:
Setting up NetWeaver Embedded Search (TREX) for SAP HCM Talent Management EhP4, 5 and 6
Regards

The program ESH_IX_PROCESS_CHANGE_POINTERS is little bit different than regular background job.
It looks like a hang, but this program will keep calling SUBMIT of itself. It takes care of its own scheduling based on parameters you provide.
It will finish only after 'Exit processing after [hours]' you gave in selection screen.
Infact its not struck at 'Indexing object type: HRTMC_REL_S_JF_450'
It says that is the last index it worked on.
If it finds change pointers to any other object, it will index them and add a message at the end of job log saying 'Indexing object type: xxxxxx'. Make a change in org and monitor this job to validate this.
You see the job 'on hold', 'SLEEP' because it will wait for a while before it start checking for change pointers again. This duration is based on 'Delay[seconds]' parameter you specified in selection screen.
I thing your problem is that change pointers are not being generated properly which is the task of program RPTMC_CREATE_CHANGEPOINT_AUTH.
Thanks,
Nag

ABAP to set "Switched on/off BIA indexes for queries" flag?

Hi everyone,
Does anyone know if the "Switch on/off BIA Indexes for Queries" can be set for a specific cube by a delivered ABAP?
Here's my scenario. We go live with BIA next Monday 9/22. I've indexed our cubes in production BIA this past weekend and they're rolled up nightly. Until the go-live, I've manually set the "Switched Off for Queries" flag via RSDDBIAMON > BI Accelerator > Index Settings > Switch on/off BIA Indexes for Queries".
However, one indexed cube is deleted fully every night by the flag in the full load infopackage. In testing, I saw that the BIA fact table index was fully deleted when the E and F tables of the cube were truncated, and then reindexed when the full package is loaded and rolled up. This is all ok.
The issue is that after the delete, load and rollup, the "Switched Off for Queries" flag is not set. I have had to manually reset to off in the morning. This won't be an issue (hopefully) once we go live, but it does seem like a bug and I'll likely submit a customer message. I would think the delete, index and rollup process should not change the status of this flag.
Does anyone know if that flag can be programatically set?
Thanks for any advice,
Doug

Thanks, Vitaliy!
I think you're exactly right. Its seems to be a bug in processing of just this specific type of index reprocessing, e.g. dropping and reindexing. The indexing process properly retains INA status on the other delta indexed cubes.
I'm barely ABAP OO literate, but do understand enough to find, review and test the class and method code. Thanks for finding it!
Also, I reviewed table RSDDTREXDIR and it is correct/current. It does spawn another question, though. The field ITYPE (Type of BIA Index) is consistently ICB exept for 2 cubes/indexes, which are typed as PA2 and PA9. When I check possible values on the domain, RSDDTREX_TAGGR_TYPE, it only lists ICB and ICF (Infocube - flat).
Any idea what types PA2 and PA9 are, and why these 2 cubes would be different? From my perspective, they're basic infocubes, same as all the others.
Thanks again,
Doug

Webinar: Understanding TREX Indexing and Search Options

SAP NetWeaver Know-How Network Webinar:
Understanding TREX Indexing and Search Options
Wednesday 25 August 2004
11 a.m. EDT
On Wednesday 25 August, Larry Brambrut, an EP RIG Consultant, hosts the webinar titled Understanding TREX Indexing and Search Options as part of the ongoing SAP NetWeaver Know-How Network Webinar Series.
Heres how Larry describes his webinar presentation:
This session will describe the enhancements to "Search and Classification"(TREX) in NetWeaver '04 and EP 6.0 SP2 Patch 6. The session will include a discussion of the CM enhancements such as new crawlers, new search UI options and plug-ins, and TREX enhancements such as the new TREX architecture, delta indexing, and new TREX Admin Tool.
SDN invites you to post your questions to the presenter prior to the webinar and continue the online discussion afterward.
How to Participate
(Please go to the SDN webinar schedule page to find more information)
Dial-in Information:
Date: Wednesday 25 August 2004
Time: 11 a.m. EDT
Within the U.S., call: +1.888.428.4473
Outside the U.S., call: +1.651.291.0618
Password: NetWeaver04
WebEx Information:
Topic: SAP NetWeaver Know-How Network
Date: Wednesday 25 August 2004
Time: 11 a.m. EDT
Meeting Number: 742391500
Meeting Password: netweaver04 (lowercase)
WebEx Link: sap.webex.com
Replay Information:
A recorded replay of this call will be available for approximately three months after the webinar. Access this recording by dialing the appropriate number and using the replay access code 720155.
Toll-free: +1.800.475.6701
International: +1.320.365.3844

About the SAP NetWeaver Know-How Webinar Series
The SAP NetWeaver Know-How Webinar Series is driven by the SAP NetWeaver Regional Implementation Group (RIG), part of the SAP Development organization. The mission of the SAP NetWeaver RIG is to enable customers, employees, and partners to successfully implement the SAP NetWeaver solution. This SAP RIG has expertise in BI, EP, XI, and WebAS. They contribute their implementation expertise to the SDN implementation forums as well as to the SAP NetWeaver Know-How Webinar Series.
Disclaimer
SDN is not responsible for any changes to the webinar schedule. The webinar schedule may be changed or cancelled without prior notice.

Hi there,
I just read this thread, and maybe someone here can answer my current trex question:
I have created an ordinary CM repository, and created an index with this repository as source. Now the problem: I would like to exclude files in the repository with specific mimetypes from the TREX indexing process.
I have verified that the TrexValidMimetypes.ini does not contain any reference to the Mimetypes I'm creating, but never the less, the document titles are searchable and are returned when searching.
How do I get around this issue?
Is it possible in NW04 or EP6.0 SP3 PXXX??
Regards,
Hco

Talent Search not showing name for one employee

Hi
I am facing issue in talent search, it is not showing employee name after search. This is happening only for one user, means surely it will be master data issue,application is working fine.
But now I want where to see that data maintained.
Please help with this if anyone knows about it.
-Yogesh

Hi Yogesh,
If it is only one employee that it isn't showing for then it could be authorizations. Some other suggestions are:
- Incorrect or no name for CP object
- Incorrect authorizations of user used for delta-indexing
My guess would to be to look at authorizations first.
Best regards,
Luke

ETL Stops but no error logged

Hi All,
I have an ETL that runs ok in several environments, but having just migrated it to a new UAT environment we are experiencing regular unexplained shutdowns.
There are no failed tasks, it just stops. This message appears in theserver logs.
1861 SEVERE Thu Aug 16 22:46:05 BST 2012 ETL seems to have completed. Invoking shut down dispatcher after the notification from the last running task.
1862 SEVERE Thu Aug 16 22:46:05 BST 2012 Finishing ETL Process.
The last task to complete was an SDE, this has an associated SIL which hasn't run, so why does the DAC think the ETL has finished?
I see there have been similar posts in teh past, but the fifference here is that more than three hundred tasks had completed ok, and when I restart the ETL it will run the rest ok.
Any ideas anyone?
thanks
Ed

Hello Florian,
may be the usual problem of an active index during loading of a datacube. The index maintainance has to recreate the indizes while loading, and it have to do this in parallel if you have more than one data package loading. This may mean deadlock or memory problems.
Please drop the index of the Cube (Manage->Performance->Delte Index (Now)) and retry your load. Don't forget to rebuild the index after load.
You can do this in a process chain too.
Kind regards,
Jürgen

Process dependencies in process chain

Hi All,
in one of my process chain i have at the end :
delte index -> Load DTP -> Create index -> Compress cube ->generate db stats
but system is showing this warning
A type "Construct Database Statistics" process cannot follow process "Compression of the InfoCube"
and in table RSPCTYPESDEP i an entry stating that :
generate db stats after a compression of cube "makes no sense but not completely wrong".
can you explain why generate db stats after compress make no sense ?
Regards.

Hi Anns,
It is always recommended to keep the create DB stats before compression.The advantage of the DB stats is to improve the query performance as well as loading performance.
check the below links for more information
/thread/2026714 [original link is broken]
http://help.sap.com/saphelp_nw04/helpdata/en/d5/e80d3dbd82f72ce10000000a114084/content.htm
Regards,
Venkatesh

Delta Indexing

Similar Messages

Maybe you are looking for