Error ORA-00942 in heterogeneous system copy

[Former Member]

Hi everybody!

Someone can help me? I got the nex error when I was making an heterogeneous system copy. I don't know if this error affects the export.

Compiled Jan 14 2006 06:36:14

/sapmnt/BWP/exe/R3load -datacodepage 1100 -e /tmp/sapinst_instdir/NW04/COPY/EXPORT/ABAP/COPY/NUC/DBEXP/SAPAPPL0.cmd -l /tmp/sapinst_instdir/NW04/COPY/EXPORT/

ABAP/COPY/NUC/DBEXP/SAPAPPL0.log -stop_on_error

(DB) INFO: connected to DB

(DB) INFO: DbSlControl(DBSL_CMD_NLS_CHARACTERSET_GET): WE8DEC

Syslog: k CPU : UMGSETTING&TRANS&UNICONV& &'N','U'&Warning& rscpexcc 29

Syslog: k CPU : UMGSETTING&EINDX&UNICONV& &'N','M'&Warning& rscpexcc 25

(rscpMC) Warn: UMGSETTINGS says: RADCUCNT not succesful

(GSI) INFO: dbname = "BWP20060217060223 "

(GSI) INFO: vname = "ORACLE "

(GSI) INFO: hostname = "srm-pro "

(GSI) INFO: sysname = "SunOS"

(GSI) INFO: nodename = "srm-pro"

(GSI) INFO: release = "5.9"

(GSI) INFO: version = "Generic_122300-15"

(GSI) INFO: machine = "sun4u"

(GSI) INFO: instno = "0020221516"

(EXP) ERROR: DbSlExeRead failed

rc = 103, table "/BI0/0100000001"

(SQL error 942)

error message returned by DbSl:

ORA-00942: table or view does not exist

(DB) INFO: disconnected from DB

/sapmnt/BWP/exe/R3load: job finished with 1 error(s)

/sapmnt/BWP/exe/R3load: END OF LOG: 20080209205617

I will appreciate your help.

Best Regards

[markus_doehr2 · Accepted solution]

Ok.

Did you delete the temporary BI views? Did you execute SMIGR_CREATE_DDL before you started the export?

It seems to me, that someone started a Unicode conversion preparation in that system but didn´t finish it completely (thus the warnings about UMG* tables).

Markus

[Former Member]

We have solved the problem applying the 672268 sap note, is related to support package level.

Thanks to all for your help.

Best Regards.

[Former Member]

The BW System uses different temporary objects for the query and other processes. The system often generates them outside of the ABAP Dictionary for performance reasons or because they cannot be defined there (as stored procedures or triggers).

All these objects have names that start with /BI0/0... followed by a number for the object type and an eight digit identification. A temporary table may be named /BI0/0101234567, for example.

There are the following type prefixes:

• /BI0/01 ... are temporary tables that save interim results in connection with query processing, transfer results from one query to another, and so on. These tables are used once. You can delete them if you like. Otherwise, the system deletes these tables automatically and reuses their names at another stage.

• /BI0/02 ... are like the /BI 0/01 ... ,however, they are used to process external hierarchies. There is a reuse mechanism for the results stored in these tables. There is no risk of damage if you remove these tables; however, the performance of the queries may deteriorate as a result.

• /BI0/03 ... are views that are generated when a query is processed. The BW System defines one view for every SQL query and accesses it using a simple SELECT * FROM <Viewname>. This avoids some problems that may arise when you issue the Structured Query Language (SQL) statement directly. There is no risk of damage if you remove these views, provided that they are not already used in a query. This means you can remove these views if no other user is logged on to the system. Generally these views are removed after processing of the query is completed. However, there may be "remainders" of queries that were not processed successfully.

• /BI0/04 ... are names of stored procedures that are used while the system compresses/condenses the InfoCube. They are removed after use.

• /BI0/05 ... are names of triggers that are used while the system compresses/closes the InfoCube. They are removed after use.

• /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. However, you can delete them without problems.

• /BI0/0D ... are names of tables that are used in context with the open hub function. They contain materialized results from open hub read processes. Even if these tables are temporary, the BW open hub should control the structure and deletion of these tables. Therefore you should not delete these tables.

*

• /BI0/0P... are tables that occur in the course of an optimized preprocessing that contains many tables. For more information, see Note 514907.

[Former Member]

Thanks Sergo And Markus

Actually we ran the report SMIGR_CREATE_DDL but creates the next error while running:

Runtime Errors DBIF_DSQL2_SQL_ERROR

Exceptn CX_SY_NATIVE_SQL_ERROR

Date and Time 12.02.2008 17:32:48

Database error text........: "ORA-00920: invalid relational operator"

Database error code .......: 920

Triggering SQL statement...: "FETCH NEXT "

Internal call code.........: "[DBDS/NEW DSQL]"

In other words we understand that if we do not run the report or if we have some tables (/BI0/***** ) we can run the export without problems, does it right ?

Also we will replace the R3**** tools with the newest version.

Best Regards

Reynaldo Rebolledo.

[Former Member]

As I have understood at you present BW system. If you will not make SMIGR_CREATE_DDL report (you must run this report in background in our base the report It was carried out 7500 s.) most likely you can create the export, but in the import phase there will be big problems ( I observed all this ). You must run this report.

Read through in notes about SAP_DROP_TMPTABLES, may be will help create the report.

[Former Member]

Hi Sergo

If we try to run the report in Production we get the next error:

Runtime Error DBIF_DSQL2_SQL_ERROR

Except. CX_SY_NATIVE_SQL_ERROR

Date and Time 13.02.2008 11:24:40

Database error text........: "ORA-00920: invalid relational operator"

Database error code .......: 920

Triggering SQL statement...: "FETCH NEXT "

Internal call code.........: "[DBDS/NEW DSQL]"

Please check the entries in the system log (Transaction SM21).

We found the note 640553 but we are not sure about it, we do not understand at all.

In Develop the report runs without problems.

Best Regards

Reynaldo Rebolledo.

[Former Member]

Hi Reynaldo Rebolledo Romero. Check the sp packegs and kernel releses from DEV and PROD systems,

as the Oracle Interim patches (OPATCH).

[Former Member]

Tasks before the export

-

---

Start the SMIGR_CREATE_DDL program before you export the data from the source system. This program allows you to copy database objects that do not correspond to SAP standards. These objects include partitioned (fragmented) tables and bitmap indexes. Special '<TABART>.SQL' files are generated for these objects. These files contain 'native DDL' (create) statements and can be analyzed by R3load. Proceed as follows:

• Log on to the live BW client as a user with 'SAP_ALL' rights.

• Go to transaction SE38 and call program 'SMIGR_CREATE_DDL'.

• Select the database platform and the database version of your target system.

• Set the 'Unicode migration' indicator if your target system is an SAP Unicode system.

• Specify a directory for the '<TABART>.SQL' files to be generated.

• Execute program 'SMIGR_CREATE_DDL'. The system now generates the DDL statements and writes them into the directory specified.

• You must ensure that no more changes, such as activations or field changes, are made in the BW system after you call the SMIGR_CREATE_DDL report and before you export the data. The safest thing to do is to call this report directly before the export while the system is still locked for the user.

• The report SMIGR_CREATE_DDL creates files of the form <TABART>.SQL. If these files are not created, then BW-specific processing is not required because tables of this type do not exist in the system. This is the case if BW is not operated actively in the system. In this case, this note no longer applies and the migration should be carried out in accordance with the standard guidelines.

You can access report 'SAP_DROP_TMPTABLES' (see Note 449891) before the export if you experienced problems with temporary tables during the test import. This report deletes all temporary tables. However, this has a short-term impact on query performance in the source system.

Tasks after the export

-

---

Copy the generated DDL '<TABART>. SQL' files to the <export directory>/DB/<DBSYS> of the target system before you import the data. This is the only way that R3load can evaluate these special files.

Tasks after the import

-

---

After the successful import, you must call report RS_BW_POST_MIGRATION.

For more information, see Note 948780.

[markus_doehr2]

Are you trying to export a Unicode system with parameters of non-unicode (codepage 1100)?

Markus

[Former Member]

Hi Markus!

No, the export is from non-unicode database to non-unicode database.

Thanks.

Best Regards

[markus_doehr2]

On top of that - use the LATEST R3load/dboraslib.so to export the system (your tools 2 years old).

Markus