/BIO/06* tables in DBDIF/DDNTT but not in DB - R3load tools

[Former Member]

During an OS/DB migration, we have found that in our SAP SCM system there are 8 /BI0/06* tables and while all are listed in DBDIFF and DDNTT, only 5 exist in the database:
/BI0/0600000001
/BI0/0600000002
/BI0/0600000003
/BI0/0600000004
/BI0/0600000005
/BI0/0600000006 <<< not in ORACLE database
/BI0/0600000007 <<< not in ORACLE database
/BI0/0600000008 <<< not in ORACLE database

When we run the R3load migration the R3ldctl program includes the three tables 6-8 (which are not in the DB) in a SAPAPPL STR package
definition and so the migration tools try to export a table that is not there.

We have run the SMIGR_CREATE_DDL report and this report does NOT include these tables in it's *SQL files.

Is there some safe process to make these tables consistent with what exists in the database pre-migration to make things simpler?

[Reagan · Accepted solution]

Hello

These are BI temporary tables.

Have you checked this SAP note ?

1139396 - Temporary database objects in BW 7.X

Regards

RB

[Former Member · Accepted solution]

Hi RG - I have read it but was unsure if the business may want to keep any of this temp data and have it still post migration - or if it is purely temp pre process or report (during runtime) and therefore totally safe to delete pre-migration

any idea?

Note excerpt:

"

• /BI0/06 ... are names of tables that are used during query processing, similar to the above-mentioned tables with prefix /BI0/01. These tables are reused but not deleted from the SAP DDIC.

"

Thanks, Jamie

Message was edited by: Jamie Neilan

[Reagan · Accepted solution]

Jamie,

You can either execute the report or create those table at the DB level using the Tx SE14.

I would create the tables at the database level and kick start the export.

Regards

RB

[Reagan · Accepted solution]

Check this Wiki to know about the tables

BW temporary database objects - SAP NetWeaver Business Warehouse - SCN Wiki

Regards

RB

[Former Member · Accepted solution]

Already read it

Thanks RB. I think I will go a marginally different route and backup+change the R3load files to exclude the 3 tables that do not exist - this way the target system should exactly match - however your notes have helped my understanding - thank you