SAP_INFOCUBE_INDEXES_REPAIR

Hi All,
I have created a new sandbox BW system from a copy our BW Production. I used the Oracle database restore method for this.
Normally, before starting the backup on Production, I do " alter database force logging" and then use that backup for restore.
This time I forgot this and after all system copy steps were completed, I ran dbverify and it reported lots and lots of corrupt blocks due to corrupt indexes. This is a known problem and SAP note 547464 deals with it.
I am currently running report SAP_INFOCUBE_INDEXES_REPAIR to recreate/repair all indexes.
It has been running for a long time.
My concern is this - this report may be able to fix the indexes, but will dbverify still report corrupt blocks.
I get errors like:
BV-00200: Block, dba 76030411, already marked corrupted
Does anyone have experince with this and will this also be fixed with SAP_INFOCUBE_INDEXES_REPAIR?
Any suggestions, please help.
Cyrus

Hi,
DBV-00200 errors indicate corrupted blocks on database.
Did you confirm if the backup restored is reliable, free of corrupted data
Did you perform a hardware check in this target server ?
Many case of corrupted blocks can appear due hardware fails
Could you please execute the consistency check using the
analyze command ? See question 7 of note 365481.
Additionaly you can find more details in the note 23345
Also Check SAP Notes 547464 and 442763.
We came across same issue during our system refresh. Report SAP_INFOCUBE_INDEXES_REPAIR didnt worked for us. What we did is we dropped & recreated indexes for those particular cubes & ran DB verify job. corrupt block error didn't come again.
can you check whether any index creation/drop job ran during the backup time which you have restored.
This worked for us.
The cause of the problem might be that indexes on objects which trigger
the error were created with NOLOGGING option.
As discussed in note 442763, only the indexes are created this way,and they can be created again with the reported mentioned.
we have resolved this issue by taking backup at that time where no process chain runs.We restored same backup.
after executing DB verify after the system refresh block corruption warnings didn't come.
Additionally see :
863417 : FAQ: Database Archive modes and redo logs
23070 : Backup and Recovery: Basic Concepts (it is very old one but
provides the basic concepts)
You can use BR*Tools/BRBACKUP for database backup. See the URL :
http://help.sap.com/saphelp_nwpi71/helpdata/en/0b/5daf09b03344ad97338f838e09b9ee/frameset.htm
Hope this helps
Thanks,
Sushil
Edited by: Sushil Suryawanshi on May 20, 2009 12:02 AM

Similar Messages

Program SAP_INFOCUBE_INDEXES_REPAIR running longer

Hi Expert,
The program SAP_INFOCUBE_INDEXES_REPAIR to repair the indexs is taking more time of 4-5 hour which was earliar running for 5-10 mins.
Please help me to find out the possible cause and the performance improvement.
Thanks,
Ranjan

hi,
Instead of repairing the indexes you can do one thing is that on a weekly basis in process chain delete the entire index and create it again. In the repairing case it will search for the index and sometimes when the size is huge it may take hours.
regards,
Arvind.

Issue with index creation of an infocube.

Hi,
I have an issue with creation of index's for a info cube in SAP BI. when i create index's using
a process chain for the cube it is getting failed in the process chain. when i try to check the index's for this
cube manual the following below massage is shown.
*The recalculation can take some time (depending on data volume)*
*The traffic light status is not up to date during this time*
Even i tried to repair the index's using the standard program "SAP_INFOCUBE_INDEXES_REPAIR" in SE38
to repair the index so it is leading to dump in this case.
Dear experts with the above issue please suggest.
Regards,
Prasad.

Hi,
Please check the Performance tab in the Cube manage and try doing a repair index from there.
This generates a job so check the job in SM37 and see if it finishes. If it fails, check the job log which will give you the exact error.
These indices are F fact table indices so if nothing works, try activating the cube by the pgm 'RSDG_CUBE_ACTIVATE' and see if that resolves the issue.
Let us know the results.

Creation of index in BW

Hai Experts,
pls tell me what is the purpose of index and how can we create indexes in sap bw
when we are going to create indexes in real time projects(bw).
for best answers points will be rewarded.
Regards
djreddy

Hi,
Indexes are data structure sorted values containing pointer to records in table.
Indexes are use to improve data reading performance / query performance improvement but decreases data loading/writing performance .We delete/drop them during the data loading to data target and create again after loading finished. In BW normally we include this in process chain.In process chain before loading the data to cube use the delete index process and load the cibe and create index.
If you perform index creation for cube in the perforamence tab it is created automatically by the sysem.
What are indexes
what are the indexes of info cube and use
Infocube > Manage > Performance > Create(Repair) Index/Delete Index.
Database Indexes
With an increasing number of data records in the InfoCube, not only the load, but also the query performance can be reduced. This is attributed to the increasing demands on the system for maintaining indexes. The indexes that are created in the fact table for each dimension allow you to easily find and select the data. When initially loading data into the InfoCube, you should not create the indexes at the same time as constructing the InfoCube, rather only afterwards.
The indexes displayed are the secondary indexes of the F and E fact tables for the InfoCube. The primary indexes and those defined by the user are not displayed. The aggregates area deals with the associated indexes of the fact table for all aggregates of an InfoCube.
Checking Indexes
Using the Check Indexes button, you can check whether indexes already exist and whether these existing indexes are of the correct type (bitmap indexes).
Yellow status display: There are indexes of the wrong type
Red status display: No indexes exist, or one or more indexes are faulty
You can also list missing indexes using transaction DB02, pushbutton Missing Indexes. If a lot of indexes are missing, it can be useful to run the ABAP reports SAP_UPDATE_DBDIFF and SAP_INFOCUBE_INDEXES_REPAIR.
Deleting Indexes
For delta uploads with a large quantity of data (more than a million records), you should not align the database indexes of the InfoCube with every roll up, rather delete the indexes first, and then completely reconstruct them after rolling up.
Repairing Indexes
Using this function you can create missing indexes or regenerate deleted indexes. Faulty indexes are corrected.
Build Index
You can delete indexes before each data load and then rebuild them again afterwards. You can also set this automatic index build for delta uploads.
Thanks,
JituK

BW - Unknown objects in ABAP Dictionary - DB Tables

Hello gurus,
As a result of the consistency check in DB02 transaction, our BW System is showing a high number of "DB Tables" and "DB Tables withouth unique index" as unknown objects in the ABAP dictionary.
Is there any way to solve these consistency issues detected in DB02?
Thanks
Regards

Hi Dibya,
I checked the SAP note 33814 and it tooke me to the SAP note 449891 - Temporary database objects in BW 3.X
According to the recommendations, I executed the report SAP_UPDATE_DBDIFF, and I got as result 579 secondary indexes missing in the DB from the and still the 5 DB Tables unknown in the ABAP dictionary and 2 DB Tables withouth unique index,
I executed the report SAP_INFOCUBE_INDEXES_REPAIR in order to try to repair the secondary missing indexes that were shwon but withouth getting any results.
Do you have any recommendation to solve this situation? In the original scenario the DB02 transaction wasn't reporting any missing index.
Thanks and regards,

Index Problem in Infocube

Hi BW lovers
I am having problem with the index in one of our cubes. This is the story:
1. I did a lot of compress on a cube with 41 000 000 records in. After that run DB statistics (ended up green).
2. After that I checked index in the performance tab and it was yellow.
3. I tried to repair index, and it did not help (still yellow)
4. Delete and created index again (still yellow)
5. I run a check in RSRV and there was one yellow saying "Index /BIC/FZHISTORY~900 type is BITMAP. Type NORMAL was expected". I tried to repair it but still the same problem.
6. I tried to run ABAP program SAP_INFOCUBE_INDEXES_REPAIR (still yellow)
7. Did all things in note 401242 (check DB02 etc)
Still yellow.... Anyone have a clue what to do?
Best Regards
/Pontus

I'm assuming this is an Oracle DB because of refrence to bitmap index.
The 900 index is an index that is added to the F fact table for InfoCubes wher you have specified they are to be partition (from the Extras menu option). This is an index on characteristic that was specified for partitioning (0CALMONTH or 0FISCPER). According to Note 217397, the index is supposed to be a bitmap index.
Partitioned Infocubes
There is an additional index for F facttables of partitioned infocubes in BW 3.x systems. Thereby it does not matter whether the infocube is standard or transactional. There is an additional bitmap index on the column of the F facttable that corresponds to the partitioning column of the E facttable This index's name is "900", i.e. "/BIC/F...~900" on the database.
So how do we reconcile your error msg and this Note? Msg saying it expected a Normal index and this Note saying it is supposed ot be bitmap?
This isn't a transactional cube is it?
Note 1024018 makes reference an earlier Note that indicates the 900 index was not included as part to of the rebuild index process at some previosu point, but the note it referenced didn't see, to clarify when the change was made. I would check and see if the 900 index actually gets rebuilt when you perform the repair.
Maybe you could have your DBA rebuild it if the Repair function is not doing it. Seems like some more OSS Note digging is in your future. Note 401242 - Problems with InfoCube or aggregate indexes - runs thru some diagnostic efforts you can pursue.
Note 1003360 - BW fact tables: Deleting index from process chain terminates - talks about a failure in PCs because the 900 index gets deleted twice.
Note sure what SP you're on - but since it looks like the 900 index has been a problem off and on, you'll have to see what Notes might be applicalable to your SP.

Reoccuring missing secondary indexes in BI systems

Hi Gurus,
I'm been experiencing the problem of missing secondary indexes for some time, and I would like to get to the bottom of this problem.
These are a few of the missing indexes (from DB02):-
/BIC/F100294-900
/BIC/F100365-900
/BIC/F100366-900
/BIC/F100368-900
/BIC/F100369-900
/BIC/F100386-900
/BIC/FZCFIGRLP-900
/BIC/FZCGLECRD-900
/BIC/FZCGLECRD2-900
/BIC/FZCGLECRD3-900
TSP03-1
TSP03L-A
Any idea what could be causing this???
And how do I solve this problem??? And how can I prevent these from reoccuring again???
Thanks.
Cheers,
KeatSeong

I see missing indexes on DB02 as well and ran SAP_INFOCUBE_INDEXES_REPAIR and I just have a couple more questions that I think is relevant to this chain:
1) It repaired some fact indexes like /BIC/F* and dimension indexes like /BIC/D* but in the report showed as follows for those cubes:
0 ZPP_C008 : 0 secondary indexes repaired.
2) I had some other dimension indexes like /BIC/D* that did not get repaired and I'm wondering why. See 4) below for how I repaired those.
3) I ran RSRV and these missing indexes like /BIC/D* do not show up as being an issue
4) When I run RSDU_INFOCUBE_INDEXES_REPAIR on that missing index like /BIC/D* I get E_REPAIRED = 0 and system error: RSDU_INFOCUBE_INDEXES_REPA_ORA but when I refresh DB02 the index is gone. When I go to RSDU_INFOCUBE_INDEXES_REPA_ORA and run it I got e_reparied - 11
Thanks for all your help.
Mike
Edited by: Michael Hill on May 26, 2010 6:49 PM

Missing indexses in DB02

Hi ,
    When i am monitoring the system thru DB02 i m getting missing secondary indexses.....can anyone tell me why they actually come? how severe can they for the system? how can i adjust them?
The name of the indexes are
/BIC/FITC_MDP-020
/BIC/FITC_MDP-030
/BIC/FITC_MDP-040
/BIC/FITC_MDP-050
/BIC/FITC_MDP-060
/BIC/FITC_MDP-070
and as a matter of fact i have run abap report
SAP_INFOCUBE_INDEXES_REPAIR
though running it has repaired some indexes but not the one i want.plz suggest
siddharth
regards
Message was edited by:
        Siddharth Sharma

Hello Siddharth,
First, you have to check and search for the index already exists or not :
Through OS level :-
(sqlplus under sapr3 user)
select index_name, owner, num_rows from dba_indexes
where index_name = '          ' ;
you can rather ALTER or REBUILD it using
alter index sapr3." ~0" rebuild ;
Regards,
Jafer

Missing indexes in db02

Hello,
Checking DB02 i've found a list of missing primary indexes. I know that i can use SE14 to adjust the indexes but i found some decumentation that says that i should first check if double index for the primary index exist and elimenate them.
Please Advice.
David.

hi David,
oss note 157918
BW: DB02 shows "missing indexes"
Symptom
DB02 shows indexes of a fact table to be missing. Such indexes have names that start with prefixes /BI0/F or /BIC/F (BW 1.2, BW 2.x) or /BI0/E or /BIC/E (BW 2.x only).
Additional key words
Business Information Warehouse, InfoCube, Fact Table, Bitmap Indexes, Oracle, DB02, Unique Index
Cause and prerequisites
For BW 1.2, this only applies to Oracle-based systems. For BW 2.x, this might apply to any DB-platform.
BW 1.2 and BW 2.x take advantage of certain DB-specific features which are not supported by the data dictionary of R/3 4.0, 4.5 or 4.6 base systems. Prominent examples are bitmap indexes on fact tables (Oracle-based BW systems), partitioned/fragmented indexes, nologging and parallel index building facilities etc. Such features are used in BW by triggering native SQL statements which bypass the data dictionary.
While all these features improve performance of the BW system, there are, however, some other transactions that are also affected when the data dictionary is bypassed. Amongst these is DB02. It sometimes claims that certain indexes of infocube fact tables are missing while direct checks on the database level show that those indexes are not missing at all or substituted by equivalent indexes. The latter might happen in BW 2.x where the primary index on fact tables might be replaced by a non-unique index or simply skipped as it is not required. Therefore you can usually ignore those messages. Obviously, we are currently working on removing such inconsistent information. If you want to be sure on the indexing then check the solution section of this note.
Solution
For BW 1.2A systems (Oracle only):
You have to ask your local DBA to check the state of the indexes directly by looking at the USER_INDEXES table on the Oracle database.
For BW 1.2B systems (Oracle only):
There are two alternatives to check the secondary indexes of infocube and aggregate cubes fact tables:
           (1) Go to the Admin Workbench. Go to the infocube. Click the right mouse button and choose "InfoCube Performance". This leads you to a screen that shows the state of those indexes via traffic light semantics. There are also buttons to repair inconsitent states of the indexes.
           (2) Use transaction RSRV. Go to the tabstrip "Database". Choose the item "Indices of an InfoCube and its aggregates" and insert the (technical) infocube name (e.g. 0BWTC_C01) in the input box at the bottom of the screen. Press F8 ("Analysis") and wait until a red, yellow or green light appears beside "Indices of an InfoCube and its aggregates", i.e. in the "Result" column. Then press F6 ("Results") in order to see a detailed report on the index situation of that cube.
           (3) Go to SE37 and do a "single test" for the function module RSDU_CHECK_SECONDARY_INDEXES. Use the infocube's technical name (e.g. 0BWTC_C01) as the input parameter and 'X' for both, the I_COMPLETE_CHECK and I_WITH_AGGREGATES, parameters. Press F8 to run the module. Only the C_T_INDEX output parameter is relevant. It shows a list of indexes. Check the TYPE and STATUS columns. These should show 'BITMAP' and 'VALID' respectively.
For BW 2.0A systems (all DB-platforms):
For checking secondary indexes on individual infocubes the following methods can be applied, similar to the BW 1.2B solution:
           (1) Go to the Admin Workbench. Go to the infocube. Click the right mouse button and choose "Manage". Choose the tabstrip "Performance". This leads you to a screen that shows the state of those indexes via traffic light semantics. There are also buttons to repair inconsitent states of the (secondary) indexes.
           (2) same as (2) for BW 1.2B.
           (3) Go to SE37 and do a "single test" for the function module RSDU_INFOCUBE_INDEXES_CHECK. Use the infocube's technical name (e.g. 0BWTC_C01) as the input parameter, leave the I_FACTTAB initial, use 'X' for both, the I_COMPLETE_CHECK and I_WITH_AGGREGATES, parameters and use 'U' in the I_DOUBLE_FACTTAB parameter. Press F8 to run the module. Only the C_T_INDEX output parameter is relevant. It shows a list of indexes. Check the TYPE_CHECK, UNIQUE_CHECK, PARTITIONED_CHECK and STATUS_CHECK columns. These should show 'G' (= "green" = ok) respectively.
If your BW 2.0A system is on patch level 11 Make DB02 consistent by running the report SAP_UPDATE_DBDIFF (via SE38), go to DB02 and press the "Refresh" button in order to synchronise the information in DB02 with the DBDIFF table. This should provide you with a consistent view.
For BW 2.0B and BW 2.1C systems (all DB-platforms):
DB02 should work consistently in BW 2.0B / BW 2.1C with infocubes created in 2.0B / BW 2.1C. If you wish, you can still use the BW 2.0A approach. For infocubes that were created in BW 2.0A or BW 1.2 you need to adjust the index setup (on the facttables) by running the report SAP_INFOCUBE_INDEXES_REPAIR. The latter is available from BW 2.0B patch 3 onwards. It should be run in a background process as it might take a while to run through.
You also might want to run the report SAP_UPDATE_DBDIFF once in order to update the table DBDIFF that lists database objects whose data dictionary setting do not correspond to the actual setup and that should therefore be omitted in DB02 checks.
Source code corrections

The fact table of InfoCube 0OPA_C11 is missing 2 secondary indexes

Hello experts,
in RSRV i got the above mentioned message for my InfoCube 0OPA_C11. Before I tried to delete, repair and build up my indices in performance tab of the InfoCube.
I followed SAP Note '401242 - Problems with InfoCube or aggregate indexes'.
-> SAP_INFOCUBE_INDEXES_REPAIR repaired indexes and show no further problem, but problem still exists, in performance tab light is red and RSRV brings same message.
Does someone have any idea what further I can do?
Best regards,
Peter

Peter, refer to note 928037, it's FAQ about MaxDB indexes. I gave it a quick reading and I believe the answer to this issue lies beneath this doc! There are ways to check consistency of individual index, bad indexes and ways of eliminating them.
Also, refer to the below blog. Check the status of the secondary index in this case. I suspect they are bad or missing. There are ways to recreate them. Keep your basis guys in the loop.
http://wiki.sdn.sap.com/wiki/display/MaxDB/MaxDBIndex%28Secondary+Key%29
Hope this helps.
Edited by: Mann Krishna on Sep 10, 2010 3:50 PM

How to migrate the Objects from 3.1c to BI7

Hi,
We are in Functional Upgradation.
How to Migrate the Objects( Infocubes,DSO,Datasources,Rules...etc...) from 3.1C to BI 7.0
Please help me to doing this....
regards,
anil

BW Upgrade tasks (BW 3.1C to BI 7.0)
Prepare Phase:
Task How-To Who
Review BI 7.0 feature lists Review BI 7.0 feature lists for possible inclusion in developments. Basis/BW
Obtain the BI 7.0 upgrade guide Download the upgrade guide from http://service.sap.com/inst-guides -> SAP NetWeaver -> Upgrade
 Basis/BW
Review all upgrade SAP notes In addition to the upgrade guide, check, download, and review all SAP notes for your upgrade
 BI 7.0 Upgrade notes
 SAP Web Application Server 6.40 upgrade notes
 OS and DB specific upgrade notes
 SAP BW Add-on upgrade notes
(e.g. SAP SEM, ST-PI, etc)
 Plug-In upgrade SAP notes
 Other notes identified in above notes and/or upgrade guides.
 Basis/BW
Check DB and OS requirements for the target SAP BW release Check DB version/patch level and OS version/patch level required for upgrade
 First check the most current information from the SAP BW homepage http://Service.sap.com/BW -> <SAP BW release> -> Availability
 Additionally, the u201CPlatformsu201D link will take you to the main DB/OS page for BI 7.0 and SAP Web AS 6.40.
 Note: In some cases there are differing requirements for SAP BW 3.0B/SAP BW 3.1 Content and BI 7.0
 Basis
Check SAP BW Add-on upgrade requirements Do you have SAP BW add-ons installed that require additional handling (e.g. SAP SEM, Enterprise Portal Plug-in, etc)?
 SAP SEM (SAP BW based components) requires SAP SEM 4.0 which is part of the mySAP ERP 2004 suite.
 WP-PI release must be at 6.00 before the upgrade begins. As mentioned before this add-on is merged with PI_Basis after the upgrade.
 Basis
Check SAP BW upgrade requirements  Minimum Support Package and kernel levels for upgrade
 SAP BW Frontend requirements for new SAPGUI, SAP BW BEx Frontend and SAP BW Web applications.
 Source system Plug-In requirements Basis
Check compatibility requirements with 3rd party software  3rd Party Reporting tools (example: Crystal)
 ETL Tools (example: Ascential, DataStage, etc)
 Scheduling tools (example. Control-M, Maestro, etc)
 Monitoring tools (example: HP OpenView, Patrol, etc)
 Other OS or DB related tools Basis
Check new component requirements for BI 7.0  If SAP BW web reports were developed in SAP BW 2.x, a windows version of IGS 6.40 (Internet Graphics Service) is required for conversion and future rendering of web graphics (i.e. Charts and GIS Maps).
The IGS chart migration will also be required after the SAP BW web report conversion.
 If you used or activated any SAP BW Web Applications in SAP BW 3.x, or if you have used charts in SAP BW 2.x web reports, you will need a windows version of IGS 6.40 (Internet Graphics Service) to execute the IGS chart migration after the upgrade.
 If ESRI GIS software is in use, a different version of ESRI software maybe required for BI 7.0. (ArcView 8.2?).
 If you plan to use Information Broadcasting, please review the requirement for additional infrastructure components such as EP, KMC, Workbook pre-calculation service, and Web AS connectivity to your mail servers.
Detailed information is available in the SAP NetWeaver u201904 master planning guide (http://service.sap.com/instguides -> SAP NetWeaver).
 Basis
Test and distribute new SAP BW Frontend
  Install and test the new BI 7.0 Frontend (including the new version of SAPGUI for Windows if applicable).
 A detailed FAQ on the new BI 7.0 Frontend is available on the SAP service marketplace alias BWFAQ (http://service.sap.com/BWFAQ).
 After successful testing, the new SAPGUI for Windows and SAP BW Frontend can be distributed to the BW teams and end users.
 Basis
Alpha Conversion:
Ensure that your InfoObject data is consistent from a u201Cconversionu201D perspective (Alpha Converter tool) Check that you have executed the Alpha Converter tool to check the consistency of your InfoObject definitions and data for InfoObjects that utilize the ALPHA, NUMCV and GJAHR conversion exits.
Note: The Alpha conversion is not part of the SAP BW upgrade itself, but the upgrade simply checks to ensure you have successfully executed the check tool.
Transaction RSMDCNVEXIT
Check the system status:
 u201CAll Characteristics Have Correct Internal Valuesu201D: The Alpha converter has been successful executed. The upgrade preparation can continue.
 u201CNo Check yet/Inconsistent Internal Vales existu201D:
The Alpha converter check has not been executed.
 u201CCharacteristics have Inconsistent Internal Valuesu201D:
The Alpha converter tool check has been executed and data problems have been detected. The InfoObject and data must be processed before the upgrade can be started.
 BW
Upgrade SAP Note updates Check for newer versions of your SAP notes for the Upgrade.
Tip: The SAP service marketplace offers an option to subscribe to OSS notes so you can be notified of changes when you log on.
 Basis/BW
Confirm SAP BW support package, kernel and DB/OS configuration Analyze current Support Package and DB/OS/Kernel configurations in your SAP BW landscape in relation to the SAP BW 3.x upgrade requirements.
 Apply necessary support packages, kernel patches, and DB and OS patches to meet upgrade requirements
 Basis
Alignment of SAP BW objects within your SAP BW system landscape Check and, where required, re-align SAP BW Objects and developments in your SAP BW system landscape (Development, Quality Assurance and Production).
SAP BW Object differences can impact the quality of testing in the Development and Test environment and can lead to change management issues.
 This check is to minimize risk and ensure productive objects are being tested prior to the Production upgrade.
Where alignment issues exist and realignment is not possible, alternative testing plans should be devised.
 Basis/BW
Confirm all developments are deployed. Ensure that all SAP BW developments are deployed or they are to be re-developed/tested after the upgrade.
 In the DEV system, all SAP BW development transports should be released (i.e. transport created and released) and imported to all downstream systems (i.e. QAS and PRD systems).
For SAP BW developments not already collected in the transport collector, a decision must be made:
Deploy the developments or wait until the upgrade has completed to deploy.
o Development to be deployed should be collected, released, and imported into the QAS and PRD systems.
o Developments that should be deployed after the upgrade should be re-tested/re-developed after the upgrade.
 In the QAS or PRD systems, ensure that all SAP BW development transports have been imported prior to the upgrade.
 BW
Implement BI 7.0 Business Explorer Frontend Install, evaluate, test and distribute the new BI 7.0 Business Explorer Frontend.
 Basis/BW
Pre-upgrade Process:
Download required BI 7.0 support package Stack for inclusion in the upgrade Determine the equivalent support package level of the source SAP BW release and the target SAP BW release.
 There is a minimum requirement that you upgrade to at least the equivalent support package level on the target SAP BW release so that you do not lose functionality, corrections, and data.
 It is recommended to upgrade to the latest version of all support packages during the upgrade via the upgradeu2019s support package binding functionality.
 BI 7.0 Support Packages are delivered via SAP NetWeaver u201904 Support Package stacks (SP-Stacks). It is not recommended to partially apply some of the SP-Stacksu2019 individual support packages. You should apply all of the SP-Stacks support packages at once.
For more information on the SP-Stacks and SAP NetWeaver SP-Stacks, please see the SAP service marketplace alias SP-Stacks (http://service.sap.com/sp-stacks)
 You should also review, download, and bind in support packages for all add-on components that are installed on SAP BW and will be upgraded during the SAP BW upgrade (e.g. SEM-BW, ST-PI, etc)
 Basis
Apply latest Support Package tool patch Apply latest SPAM patch before executing PREPARE Basis
Validate the SAP BW (ABAP) Data Dictionary and the Database Data Dictionary for consistency Check Database consistency
 Transaction DB02:
o Execute ABAP SAP_UPDATE_DBDIFF and re-execute DB02 check. This gives a truer view of the SAP BW objects in DB02.
o Check missing database objects (indices, tables, etc)
o Missing indices may identify erred data loads or process problems
Tip: Missing indices on InfoCubes can be restored by RSRV or ABAP SAP_INFOCUBE_INDEXES_REPAIR
Note: check for running data loads before executing a repair!
o Check DDIC/DB consistency
 Verify database objects and consistency
(e.g. SAPDBA check for offline data files)
 BW
Remove unnecessary SAP BW temporary database objects Delete all SAP BW temporary database objects:
 Execute routine housekeeping ABAP SAP_DROP_TMPTABLES.
 This reduces the numbers of database objects that need to be copied during the upgrade.
 Note: take care not to delete objects that are in use as this will cause queries, compressions, etc to terminate.
 BW
Validate your SAP BW Objects for correctness prior to your upgrade Using the SAP BW Analysis Tool (transaction RSRV), perform extensive tests on all important SAP BW Objects to ensure their correctness prior to the upgrade.
Note: this test should be repeatable so you can re-validate after the upgrade!
 Ensure that any inconsistencies are identified and corrected
 RSRV has a number of extensive tests and if all checks are executed will consume a large amount of time. Multiple tests can be performed in parallel.
 Tip: Some corrections in development can be deployed to other systems via transport in advance of the next upgrade.
 BW
Ensure DB Statistics are up to date prior to the upgrade  Check DB statistics for all tables.
Tables without statistics, especially system tables, can seriously impact upgrade runtimes.
 Check DB statistics for missing Indexes for InfoCubes and Aggregates
o User transaction RSRV to check BW
Check SAP BW Support Package status Check the status of all support packages (via transaction SPAM)
 Ensure the Support Package queue is empty
 Confirm all applied Support Packages Basis
Check all u2018Repairsu2019 Check for unreleased repair transports
 Release all unreleased transports
In your QAS and PRD system, check if all repair transports have been imported (i.e. systems are aligned)
 Import missing repair transports into down stream systems. This will avoid differing message and/or errors during the upgrade.
 BW
Check InfoObject status  Check for revised (modified) InfoObjects that have not been activated.
All InfoObjects should be active or saved (not activate):
o Check all inactive InfoObjects:
Transaction RSD1 (Edit InfoObjects),
click on u201CAll InfoObjectsu201D radio button and click the u201CDisplayu201D button.
Modified InfoObjects are denoted by yellow triangles!
o Determine if revision should be activated or removed.
 'Reorgu2019 or u2018Repairu2019 all InfoObjects
This checks and repairs any discrepancies in the InfoObject definition and structures. It is common to have obsolete DDIC and table entries for InfoObjects after multiple upgrades and definition changes. These obsolete entries normally do not effect normal SAP BW operations.
 Transaction RSD1 (Edit InfoObjects), Select u201CExecute Repairu201D or u201CExecute Reorgu201D Use expert mode for selective executions.
 BW
All ODS data loads must be activated.  Activate all inactivated ODS Object requests.
All ODS u2018Mu2019 tables must be emptied prior to the upgrade as a new activate process is implemented
o Inactivated ODS request can be located via the Admin workbench -> u2018Monitoringu201D button -> u2018ODS Status Overviewu201D
 BW
All Transfer and Update rules should be active  Check for inactive Update and Transfer Rules
o All update rules and transfer rules should be active or deleted.
o Look into the table RSUPDINFO for update rules and search for the version "not equal" to "A". Likewise use the table RSTS for Transfer rules/structure. BW
All InfoCubes should be active  Check for inactive InfoCubes and Aggregates (Aggregates are InfoCubes too!)
o All InfoCubes should be activated or deleted.
o Execute ABAP RSUPGRCHECK to locate any inactive InfoCubes. See SAP note 449160.
 BW
All Web Report objects should be consistent prior the upgrade.  Check the consistency of your SAP BW web objects (web reports, web templates, URLs, roles, etc). All objects should be consistent prior to web object conversion after the upgrade. It is recommended to ensure consistency before the upgrade.
o For Original release SAP BW 3.x:
A SAP BW web reporting objects check can be executed via a new check in RSRV. This is provided via a SAP BW support package.
Please see SAP note 484519 for details.
 BW
Backup your system before starting PREPARE Before execution PREPARE, perform a full database backup (including File system). Ensure you can recover to the point in time before PREPARE was executed.
 Database admin
Address any instructions/errors generated by PREPARE  Address any issues listed in log files Checks. Log generated by PREPARE.
o Repeat PREPARE until all checks are successful. Basis
Complete any Logistic V3 data extractions and suspend V3 collection processes  Extract and empty Logistics V3 extractor queues on SAP R/3 source systems.
o The V3 extraction delta queues must be emptied prior to the upgrade to avoid any possible data loss. V3 collector jobs should be suspended for the duration of the upgrade.
They can be rescheduled after re-activation of the source systems upon completion of the upgrade.
 Note: If you perform any data loads after executing PREPARE, re-check the status of all delta queues in SAP BW and the source systems(s).
 BW
Complete any data mart data extractions and suspend any data mart extractors  Load and Empty all Data mart Delta Queues in SAP BW. (e.g. for all export DataSources)
o The SAP BW Service SAPI, which is used for internal and u2018BW to BWu2019 data mart extraction, is upgraded during the SAP BW upgrade. Therefore, the delta queues must be emptied prior to the upgrade to avoid any possibility of data loss.
 Note: If you perform any data loads after executing PREPARE, re-check the status of all delta queues in SAP BW and the source systems(s).
 BW
Check that your customer defined data class definitions conform to SAP standards  Check all customer created Data classes used by SAP BW Objects (i.e. InfoCubes, ODS Objects, Aggregates, InfoObjects, and PSAs) to ensure they conform to SAP standards.
o Check your data class definitions as detailed in SAP Notes 46272 and 500252.
o Incorrect data classes could create activation errors during the upgrade.
 BW
Remove unnecessary SAP BW temporary database objects Delete all SAP BW temporary database objects:
 Execute routine housekeeping ABAP SAP_DROP_TMPTABLES.
For more information see SAP note 308533 (2.x) and 449891 (3.x).
 This reduces the numbers of database objects that need to be copied during the upgrade.
 Note: take care not to delete objects that are in use as this will cause queries, compressions, etc to terminate.
 Basis/BW
Backups! Before executing the upgrade, ensure that you have a backup strategy in place so you can return to the point where loading was completed and the upgrade started.
Ensuring you can return to a consistent point in time (without having to handle rollback or repeats of data loads) is key to having a successful fallback plan.
 Database Admin
Before Execution:
All SAP BW administration tasks should have ceased  Cease all SAP BW administration tasks such as Object maintenance, query/web template maintenance, data loads, transports, etc at the beginning of the upgrade.
The Administrators Workbench and the Data Dictionary are locked in the early phases of the upgrade.
 Reminder: Users can execute queries until the time that the upgrade determines that the SAP BW System should be closed*
- timing depends on the type of upgrade selected
 Basis/Admin
Remove unnecessary SAP BW temporary database objects Repeat the deletion of all SAP BW temporary database objects after you have stopped using the SAP BW Admin workbench*
 Execute routine housekeeping ABAP SAP_DROP_TMPTABLES.
For more information see SAP note 308533 (2.x) and 449891 (3.x).
- timing depends on the type of upgrade selected
 BW
Check system parameters Check OS, DB, and Instance profile parameters.
 Check System Instance parameters for new BI 7.0 specific parameters. See SAP note 192658 for details
 Check for any DB specific parameters for BI 7.0
 Check for any new OS parameters Basis
Check Database archiving mode Turn database archive log mode back on if it was disabled during the upgrade!
 Database Admin
After Execution:
Check the systemu2019s installation consistency Execute Transaction SICK to check installation consistency
 BW
Check the system logs Perform a technical systems check.
 Example: Check system and all dispatcher logs (inc. ICM logs)
 Basis
Apply latest executable binaries Apply the latest 6.40 Basis Kernel for all executables
 Tip: use the SAP NetWeaver u201904 SP-Stack selection tool to find all binaries. (http://service.sap.com/swdc)
 Basis
Review BI 7.0 Support Packages for follow-up actions.  Review SAP Notes for all SAP BW Support packages applied during (bound into the upgrade) and applied after the upgrade:
o Search for Note with the keyword u201CBWu201D, u201CSAPBWNEWSu201D, and u201C<BW release>u201D
o Follow any required instructions identified in the SAP Notes
 Basis
Apply latest patches  Apply the latest SPAM patch
 Apply any required support packages that were not bound into the upgrade.
 Basis
Apply additional BI 7.0 Support Packages
(if required)  SAP recommends that customer remain current on SAP Support Packages.
 Review SAP Notes for all SAP BW Support packages applied in previous task.
o Search for Notes with the keyword u201CBWu201D, u201CSAPBWNEWSu201D, and u201C<BW release>u201D
o Follow any required instructions identified in the SAP Notes
 Basis
Resolve any modified SAP delivered Role issues If SAP delivered Roles were modified, then these modifications may incorrectly appear in the upgrade modification adjustment tool (SPAU).
 Review and implement SAP note 569128 as required Basis
Configuring Information Broadcasting EP/KMC Connections
 If you plan to use the EP integration functionality of Information broadcasting (Broadcast to the EPu2019s PCD, Broadcast to KMC, or Broadcast to Collaboration Rooms):
 Ensure the SAP EP is at the same SP-Stack level as your SAP BW system.
 Follow the online help documentation to configure and connect the SAP BW system and the SAP EP system. (http://help.sap.com).
 For broadcasting to KMC, ensure that KM has the u2018BEx Portfoliou2019 content available.
 Basis
Re-check SAP BW Object and consistency Execute RSRV to check SAP BW Object consistency
 Repeat tests that we executed prior to the upgrade.
 Validate results BW
Check InfoCube views for consistency Check consistency of InfoCube fact table views
 It is possible that fact table view /BIC/V<InfoCube>F is missing if a number of SAP BW upgrades have been performed before. See SAP Note 525988 for instructions for the check and repair program.
 BW
Perform SAP BW Plug-in (SAPI) upgrade follow-up tasks  If required, Re-activate the SAP BW u201CMyselfu201D source system in SAP BW.
 The SAP BW internal plug-in (SAPI), which is used for internal data mart extraction and u2018BW to BWu2019 communication, is upgraded during the SAP BW upgrade. The source system is de-activated to prevent extractions and loading during the upgrade.
 It may be required to replicate export DataSources and reactivate transfer structures/rules for internal data loads (i.e. ODS Object to InfoCube objects).
o Tip: It is advised to do this step for all export DataSources to avoid possible errors during execution of InfoPackages
 Check that all other Source Systems are active.
o Activate as required. Basis/BW
Check SAP BW Personalization is implemented (SAP BW 2.X upgrades will have performed this in the previous task).
Validate that personalization has been activated in your SAP BW system.
Note: It has been observed that in some cases, BEx Personalization has to be re-activated after an upgrade from SAP BW 3.x to BI 7.0. It is advised to check the status of personalization after the upgrade.
 Enter the IMG (transaction SPRO), select SAP Business Warehouse -> Reporting relevant settings -> General Reporting Settings -> Activate Personalization in BEx
Check the status of the Personalization settings. All entries should be active u2013 highlighted by an unchecked check box.
 To activate highlighted Personalization, click Execute. BW
For SAP BW 2.0B/2.1C -> BI 7.0 Upgrades:
Convert ODS secondary indexes to new standard For SAP BW 2.0B/2.1C -> BI 7.0 Upgrades:
Convert any customer created ODS Object secondary indexes to the new ODS Object index maintenance process.
 Re-create all indexes in the ODS Object definition screen in transaction RSA1.
 ODS indexes must conform to the new naming convention
 BW
Converting IGS chart settings
 Convert you existing IGS chart settings (converts IGS chart settings from BLOB to new XML storage format)
 Ensure you have the latest SAP Web AS 6.40 IGS (stand alone windows version) installed and working
o Test via transaction RSRT
 Execute the conversion process as directed the BI 7.0 upgrade guide.
 Note: This step is required for all BI 7.0 upgrades Basis
Backup your SAP BW system Perform a full database backup (including the File system)
Remember to adjust your backup scripts to include new components such as the J2EE engine, pre-calculation service, etc.
 Database Admin

Error in Update optimizer statistics - index is in unusable state

Hello,
we have this error in log Check and update optimizer statistics:
12.02.2009 23:21:20 'BEGIN DBMS_STATS.GATHER_TABLE_STATS (OWNNAME => '"SAPPB1"', TABNAME => '"/BIC/FZPPC0002"', ESTIMATE_PERCENT => 10, METHOD_OPT =
12.02.2009 23:21:20 ORA-20000: index "SAPPB1"."/BIC/FZPPC0002~010" or partition of such index is in unusable state
12.02.2009 23:21:20 ORA-06512: at "SYS.DBMS_STATS", line 13452
12.02.2009 23:21:20 ORA-06512: at "SYS.DBMS_STATS", line 13472
12.02.2009 23:21:20 ORA-06512: at line 1
12.02.2009 23:21:20 BR0886E Checking/collecting statistics failed for table SAPPB1./BIC/FZPPC0002
i can temporary fix this problem when i delete and recreate index via SE14, but this help only for one next running update statistics, every next running update statistics has same error: index "SAPPB1"."/BIC/FZPPC0002~010" or partition of such index is in unusable state. Exist any definitive solution for this problem. Thanks

Hi,
Two methods for checking/repairing Indexing issues
1)RSRV for a particular cube
2)SAP_INFOCUBE_INDEXES_REPAIR report
You can also use this sql to rebuild an Index.
alter index <index name> rebuild online; Or you can rebuild Index by using ABAP report 'RSANAORA'.
Please check below thread it may help you.
/message/6483705#6483705 [original link is broken]
https://forums.sdn.sap.com/click.jspa?searchID=12942068&messageID=2052264
Thanks,
Sushil

Regularly for an infocube ZPRG_C02 where indexes are corrupting !

Hi All,
We are facing this problem Regular for infocube ZPRG_C02 where indexes are corrupting, these can be manually resolved on running SAP_INFOCUBE_INDEXES_REPAIR report but Which isn't ideal and preferred , This cube is updated daily, and the process includes steps to delete and recreate indexes.
ORACLE: The status of index /BIC/FZPRG_C02~010 is INVALID
Is their any process , where we can avoid , corrupting these indexes
How to go about this, any suggestion
Whether BW Intervention is required in this ? or Is it a BW issue ?
How to perform cude index degradation, Please suggest.
BI System is on SAP EHP 1 for SAP NetWeaver 7.0
B I Support pack level information :
SAP_BW 701 0006 SAPKW70106 SAP Business Warehouse

Perform RSRV test -
Fact- and Dimension- Table of an InfoCube
Database Indices of an InfoCube and Its Aggregates
Check Database Parameter(s)
Otherwise Re-activate the Cube

How to check for active internet connection in iOS device

Hello All,
Recently I've come to know that there are some API's provided by Flex 4.6 in Flash Builder 4.6 which are not supported in iOS based devices like iPhone and iPad.
You can check the list here - http://help.adobe.com/en_US/as3/iphone/WS789ea67d3e73a8b24b55b57a124b32b5b57-7fff.html
Now I'm helpless because in my cross-platform app, I need consinuously active internet connection and if it is not available, I want to show errors.
Can any one help me about this.
Thanks for reading

Hi,
we can check indexs uisng T codes SE11 and DB02
Useful to run the ABAP reports SAP_UPDATE_DBDIFF and SAP_INFOCUBE_INDEXES_REPAIR.
relevent links:
http://help.sap.com/saphelp_nw70/helpdata/en/80/1a6473e07211d2acb80000e829fbfe/content.htm
Re: Checking Indexes using SE11 and DB02
Regards,
BBC
Edited by: BBC Achari on Jul 4, 2010 6:23 PM
Edited by: BBC Achari on Jul 4, 2010 6:25 PM

Error in DB02

In DB02 ->Alerts ->Database Check, I have two error message:
Name..............................Number of message.....Description
MISSING_INDEX..............2...................................Index: SAPSR3./BIC/B0000406000KE # Table has no index
MISSING_STATISTICS....32.................................Table: SAPSR3./BIC/B0000414000 # Table or index has no optimizer statistics
What does it mean? What table is it (BIC/B0000406000KE and ./BIC/B0000414000)?
How can I sovle it?

hello,
if it is all green. then there must be any other problem. please go through the following links hope it will help you.
*Missing Index: Process chain Error*
Sometimes there might be missing indexes in the PW1 environment. This can be checked in transaction DBO2 (Missing Indexes). Sometimes it could be such that the DB statistics were run at a time while the cubes are being loaded and hence the indexes are missing. Hence the first step for such issues is to refresh the data base statistics as shown in the figure. Doing this, updates the database statistics. If this does not solve the issue, go the infocube 'Manage', Performance tab and select 'Repair Indexes (Immediately)'. After this the database statistics need to be updated again via DBO2.If the table for which the index is missing not an infocube, in such a case the index can be created as shown in the first diagram. Highlight the index and select 'Create in DB'.
Can be recreated via SAP_INFOCUBE_INDEXES_REPAIR
Some more info:
Reoccuring missing secondary indexes in BI systems
http://www.erphome.net/pdf/saezpdf/081saez.pdf

SAP_INFOCUBE_INDEXES_REPAIR

Similar Messages

Maybe you are looking for