on 2007 Jun 26 8:16 PM
We are planning on implementing BIA for our BI system and are in the initial investigation stage. I wanted to know if BIA indexes created in Dev can be transported to remaining systems (QA and Prod), or do we have to create them again in each system (like agregates). What's the correct strategy.
Thanks
Pl check this out:
http://help.sap.com/saphelp_nw70/helpdata/en/22/e19142969bd665e10000000a155106/frameset.htm
Ravi Thothadri
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Smitha,
The correct strategy would be to recreate the indexes again from scratch on your PROD system. Practically speaking, a BIA index is considered an aggregate on BW side and so, it needs more or less the same handling. Let me give you some more explanations:
From a technical point of view, it would be possible to exchange indexes between BIA installations by exporting/importing them. However, indexes copied this way would not be usable from the BW system as this BW system will neither have nor get the necessary information about the existence of those indexes! That means, the indexes would not be recognized as such. I cannot tell which steps would also have to be taken in order to manipulate the BW system to bypass the actual indexing process. Furthermore, there would also be the problem of the different namespaces under which the indexes are kept on BIA, even though it is a minor issue. Usually, you will use a distinct sid on the QA, DEV, and PROD system, e.g., BWQ, BWD, BWP.
Seen apart from the mentioned problems, can you really make sure that the data on the DEV BW system database is exactly the same as on the PROD BW system? If not you would run into severe inconsistencies anyway.
So, the question is if all the effort to be spent (exporting indexes on DEV BIA, importing them on PROD, and manipulating the BW PROD system in order to know about the existence of the indexes) and the danger of running into new unforeseen problems is really less than just reindexing all the cubes on PROD? How much time will the indexing process take? Roughly speaking, BIA can index about 200mio. records (with 15 to 20 attributes) per hour. With certain parameter adaptations on BW, it is also possible to increase this number.
Best regards,
Sascha.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
If the definition of configuration was related to the RFC connection for BI accelerator then yes we have to create that individually in Production and Test systems.
aapplies to RSADMIN table.
<b>More Insights on 1 BIA per landscape -</b>
Only one BI accelerator server can be used for each BI system. This is because the master data tables stored in the BI accelerator server can be used by multiple BI accelerator indexes. However, this does not work if the data is distributed across various BI accelerator servers.
Hope it Helps
Chetan
@CP..
Same box you can connect to production BI box once tested.
Ravi Thothadri
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
<b>BI Accelerator Landscape -</b>
SAP recommends using one BI Accelerator box for the production system and one for the test system. This enables you to test queries - usually with smaller data volume.
Note: there are no transports necessary from one BI Accelerator box to another.
So no need of transports for BIA indexes ..howeever whats your landscape.
Hope it Helps
Chetan
@CP..
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Our system will have one for QA and one for Prod. So according to what u said, the indexes created in QA will have to be created again in prod box after testing is complete. Correct me if that's wrong. Is there any way to actually transport them, so that we don't have to recreate them in each system?
User | Count |
---|---|
58 | |
10 | |
7 | |
7 | |
6 | |
6 | |
5 | |
5 | |
5 | |
5 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.