cancel
Showing results for 
Search instead for 
Did you mean: 

Create missing objects at once (in batch)

symon_braunbaer
Participant
0 Kudos

Dear Experts,

I've got 2 questions, I apologize that I'm putting them together in one thread, if you badmouth me a lot for

doing it, I will open another thread 🙂

1) After SPS implementation on a BW system, ST04 diagnostics shows a lot of missing objects in the DB,

like 20-30 tables and over 100 missing secondary indexes. There is a button next to each of them, which

provides the option to create the object on DB level. But for nearly 200 objects all together - isn't there a

possibility to do them all in some kind of batch mode ? As it's quite cumbersome to click that many times...

2) I have a table missing in the ABAP dictionary (NetWeaver 7.4) - the table is MLICHECK~

While there are a lot of notes about MLICHECK, there is nothing about MLICHECK~ or at least I'm not sure

how to search for it. As table MLICHECK stores the old licenses, for 7.4 this table is no longer required. Does

that mean that I can simply drop both tables (MLICHECK and MLICHECK~) on DB level ?

And I have checked, that there is an entry in DBDIFFVIEW for MLICHECK. If I drop the table on DB level,

won't I get another error, that MLICHECK doesn't exeist on the DB level ?

Please advise on how to proceed. Many thanks in advance!

Accepted Solutions (1)

Accepted Solutions (1)

Reagan
Product and Topic Expert
Product and Topic Expert
0 Kudos

1 - There is an option for Mass Processing in Tx SE14 - DB Requests - Mass Processing. Displaying Requests for Mass Processing - Application Development on AS ABAP - SAP Library. As I have not done this before I cannot provide the exact steps but I believe you need to select all the missing indexes in Tx DBACOCKPIT / DB02 and then go for the option "create in DB" which will then queue up the items for mass processing. You next call Tx SE14 for mass processing and get them executed. I don't have a system to cross check and give you the exact steps but you can poke around in the Tx DBACOCKPIT / DB02 screen options and get it working.

2 - MLICHECK~ tables appears to be a shadow table. Shadow tables are created during an upgrade/update. The shadow tables have ~ at the end. I wouldn't do anything with the MLICHECK table but I would query the table MLICHECK~ from the database level and see if it is empty before I drop.

Use this link as a reference: Missing database objects - zavisko.comzavisko.com

symon_braunbaer
Participant
0 Kudos

Thanks, Reagan, your answer is very helpful!

Of course it's a shadow table, how didn't I think about this earlier!

I did a few checks on DB level. MLICHECK~ is indeed a table, it is marked as a valid object and it is empty:

SQL> select count(*) from "SAPSR3"."MLICHECK~";

  COUNT(*)

----------

         0

Are you really sure, that it's really safe to just drop the MLICHECK~ table on DB level ?

Many thanks in advance!

Reagan
Product and Topic Expert
Product and Topic Expert
0 Kudos

Cross check whether the table MLICHECK~ is owned by the SAPSR3 schema or the shadow schema (if it still exists). If the table MLICHECK (not MLICHECK~) is present at the DB level then check the entries in that table. If the shadow table has no entries in it then it should be safe to drop the table. I would leave the main table (MLICHECK) as it is even though it is not used for the licenses as advised in the note 1523316 - Table MLICHECK is reported as missing in database. After the drop you can check the system functionality and also run the BR*Tools "Check" as well to see if things are OK.

symon_braunbaer
Participant
0 Kudos

Hi Reagan,

MLICHECK~ is owned by SAPSR3 as well. MLICHECK is also empty:

SQL> select count(*) from SAPSR3.MLICHECK;

  COUNT(*)

----------

         0

I won't touch MLICHECK, because there is an entry for it in DBDIFF and it doesn't cause any problems.

I would appreciate if you could answer this quickly, as I have to export this system in the afternoon today and I'd like to fix both inconsistencies (MLICHECK~ and ORA_COCKPIT_HELPER before that.

Many thanks!

symon_braunbaer
Participant
0 Kudos

Hi Reagan,

I found this problem on all the systems of that landscape. MLICHECK and MLICHECK~ have exactly the same columns, so in the end I have dropped MLICHECK~. If it's really needed, it can be recreated as select * from MLICHECK.

But once again, many thanks for the hint that it's a shadow table! I really didn't think of that aspect!

Reagan
Product and Topic Expert
Product and Topic Expert
0 Kudos

Just drop the shadow table. Nothing will happen to the system

Add an exception for the table ORA_COCKPIT_HELPER

symon_braunbaer
Participant
0 Kudos

Thanks a lot, Reagan, another point for you

Take care!

Answers (0)