This blog contains experience gained over the years of implementing (and de-implementing) large scale IT applications/software.

Proving new Oracle Index in SAP Without a Transport

Let’s suppose you have created a new Oracle level index on a SAP table using SE11.
You’ve created it in DEV and proven that it changes the EXPLAIN PLAN using SQL Trace or Oracle level tools.

Unfortunately you don’t have a significant amount of data in your DEV instance, but you do have data in your UAT or integration test system.
You could release your workbench request that you will have created to create the new index in SE11, but this means a flurry of potential additional transports to remove it again if it doesn’t work.
You just want a proof of concept that can be removed again.

Since it’s entirely possible for you to create an index at the Oracle level below SAP, you just need to ensure that you create the index the same as SAP would.
You can choose a couple of methods to ensure this, but we will discuss the SAP biased method.

Using SE11, find the table on which the new index exists in DEV.

NOTE: We’re showing R/3 Enterprise, but it should be similar for Netweaver based systems.

Click the “Indexes…” button to list the indexes:

Double click the new index you created earlier.
Now on the menu, select “Utilities -> Activation Log”:

Click the magnifying glass icon next to the “Technical log for mass activation” option on the main screen.

Expand all the possible expansion icons:

Look for the text “CREATE” to find the create statement:

Copy the text and paste into SQL*Plus in any other SAP systems Oracle database to create the index.
You’re done.

Just remember that this index does not exist in the SAP data dictionary, so you must remove it once you have proven the EXPLAIN PLAN is working for the larger amount of data.

Transporting SAP User Groups

I’ve blogged about SAP user groups before: https://www.it-implementor.co.uk/2011/09/sap-user-groups.html
Let’s say you’ve set them up in your DEV system and now you’re expecing to just transport them.  Well, as with all things SAP, it’s never quite that easy.

Create a new workbench transport request in SE01, SE09 or SE10 (doesn’t matter which).
Then open the request at the request level by double clicking it.
Switch to change mode by clicking the pencil button:

Now manually type in the program Id, object type and object names as follows:

R3TR TABU USGRP
R3TR TABU USGRPT

Click Yes at the prompt:

On each item, click the Function button (key symbol):

Enter * in the Table Keys field:

Save the request again.

That’s it!

Release the transport and import into the next system.
This is a farily generic process that can b used to transport any table values.
NOTE: You should be aware that the “*” in the table key, means all items specific to the current client.