EHPI fails at phase MAIN_SHDRUN/RUN_RADTBUCACT...

During the phase MAIN_SHDRUN/RUN_RADTBUCACT the process fails.  Inside the shadow instance, if you run the program RADTBUCACT manually, you will get the SQL error cannot find stored procedure 'sap_get_object_type'

If you look inside the database, you will see that the stored procedure is there under the <sid> schema, not the sid_shd schema. If you try to run MSSPROCS, you may run into problems as well, since the shadow instance is a remote connection.


To resolve this, you need to create the stored procedure manually.
The easiest way for non-DBA types is to browse to the stored procedures in your database using SQL Management Studio. Right-click on the sap_get_object_type procedure, and choose to script the object as "CREATE" to a query analyzer window. Then change the "CREATE proc" line to reference sid_shd rather than just sid and execute.


The following stored procedures will all have to be available in the sid_shd schema in order for MAIN_SHDRUN/RUN_RADTBUCACT to complete successfully:

• sap_get_index_columns
• sap_get_index_id
• sap_get_index_type
• sap_get_object_type
• sap_get_single_table_of_index
• sap_get_sqltext
• sap_get_table_columns

However, if you do just these stored procedures, you will likely run into the same issue in Phase MAIN_SHDRUN/ACT_UPG, but it will not look as obvious.  The errors you see will have you running in circles trying to setup/fix the transport domain configuration because of RC=12, etc, but the problem really is the fact that there are more missing stored procedures (look at any cancelled batch jobs that were kicked off in your system during this phase, you will see them failing after not finding a stored procedure).  You can either step through this one stored procedure at a time, which will get extremely time-consuming, or you can simply create all of the stored procedures that exist under the sid schema.  The easiest way to do this is as follows:

1. Open up SQL Management Studio
2. Browse to the stored procedures in your SAP database (they are located under "programmability")
3. Highlight all the stored procedures in the sid schema, right-click, and chose to script to QA window
4. Do a find/replace. Replace all [sid]. with [sid_shd]. (do not forget the brackets and period "." or else you will be messing up the scripts.
5. Execute

This will give you some warnings, but it will create all the stored procedures and will get you through this phase of the upgrade.

I hope this helps...

Checks after phase MAIN_SHDRUN/ALTNTAB_FILL were negative!...

Checks after phase MAIN_SHDRUN/ALTNTAB_FILL were negative!Last error code set: BATCH JOB RDDNT2MT FAILED: Error(s) found in the log(s), accumulated in "ALTNTFI.ELG"

In the ALTNTFI.ELG log it contains the following two lines:

"No shadow system""(environment parameter)""auth_shadow_upgrade" "No shadow system""DB-connect not against shadow tables !"

Just in case anyone is running into this error while attempting to upgrade to EHP4 on Windows, here is the solution I came up with:

1. Set the USER Environment Variable ‘auth_shadow_upgrade’ to ‘1’ for the <SID>adm user (set the variable while logged in as that user)
2. Change the Shadow Instance service to run with the <SID>adm account
3. Stop the Shadow Instance (you can leave the Central and SCS Instances running)
4. Start the Shadow Instance
5. Continue the EHPI process from where it left off

The reasoning behind this is that the Shadow Instance must see that environment variable in order for it to connect properly to the database in order to continue with the PreProcessing steps.  There are other ways to force the instance to start with the <SID>adm credentials, but this is the easiest method in my opinion.

Although it would work in many cases, I would not recommend setting a SYSTEM Environment variable, because it will cause trouble if you have multiple SAP instances installed on this server, or if you have to stop/restart the Central or SCS Instances.  You only want the Shadow Instance running with the 'auth_shadow_upgrade' environment variable.

HOWEVER, you MUST remove this environment variable completely prior to the PREPARATION Phase. Otherwise it will cause problems with the upgrade.  This parameter is set and unset during the upgrade process, and leaving it permanently set via the environment variable will not allow it to be "un-set" by the instance profile.

hope this helps...

SAPEHPI "Error when creating cofile for transport request ..."

I just thought I would get on here and share some information about a problem we had while in the Configuration Stage for an upgrade to Enhancement Package 4 for ECC 6.0.
During the PREP_EXTENSION/SUBMOD_EXTENSION_NEW/EHP_INCLUSION phase, SAPEHPI attempts to create data and cofiles for the EHP components. We ran into the following error:

Disassembling patch queue failed rc = 3, reason = 'Error when creating cofile for transport request SAPK-700IHINWEBCUIF

A few of the usual causes for this are:

1. OS Permissions
2. Package corruption (no longer in BIN format, etc)
3. Low disk space in the Transport Directory or EHPI Directory

Typically OS Permissions are the culprit when you run into an error creating the data and/or cofiles for a transport, and that was also the case here. However, you will need to note that there are multiple places to check the permissions.  Not only do you have to make sure that your [SID]ADM user has full rights to the Transport Directory (usually usr/sap/trans on the transport host), but for the purposes of EHPI on Windows, the SYSTEM user must have full rights to the EHPI directory (the directory where you are running the EHPI from).

Apparently on site here, someone had altered the default permissions for the entire drive that EHPI was sitting on, and thus SYSTEM was unable to make changes.

After opening up the security settings for another drive and changing the EHPI drive to match, the process continued on without a hitch.

hope this helps...