Skip to Content

A story for TechEd 2011?


From Nov ’10 to Feb ’11, I was working on “Upgrade, Unicode Conversion and Dual Stack Split” of NW 7 SPS 16 Dual Stack system running on Oracle 11g on Solaris. The Database size was 1.2TB.


We learnt we couldn’t “Combine Upgrade and Unicode Conversion”(CU&UC) due to our software level. Since upgrade was more critical to install BOBJ, we decided to perform three activities in this order:

  1. Dual Stack Upgrade
  2. Unicode Conversion 
  3. Dual Stack Split

We wanted to get all three activities completed during three-day weekend. 


Initially I started reading and downloading materials from upgrade section of Service Marketplace. Three or four days later, I realized upgrade tool couldn’t be used to upgrade from NW 7.0 SPS 16 to EhP1 SPS 7. Instead I learnt I was supposed to use EhP Installer. I also learnt SAP delivers four different tools to upgrade depending on what you’re upgrading:

  1. SAPUp:    To upgrade from Pre-NW 7.0 version to EhP1 (CU & UC is possible)
  2. SAP EhPi: To upgrade from NW 7.0 to EhP1 for either ABAP or Dual but not for Java Stack.
  3. SAINT:     To upgrade from NW 7.0 to EhP1 for SolMan
  4. JSPM:      To upgrade from Java 7.0 to EhP1

Note: As of April 21, 2011, SAPehpi 7.10 is replaced by Software Update Manager (SUM), note 1251735.

Distribution Monitor or Not…

If possible, we wanted to avoid using Distribution Monitor due to extra time needed to set it up. Instead we explored the possibility of using Oracle’s data pump to export and import for Unicode Conversion. However we learnt that method was not technically feasible. So we ended up working on optimizing SAP’s exp/imp procedures.


We used a tool called EhPi. This tool-as I understand it-is just a front-end tool like SAPGUI. Our system was Non_Unicode. I couldn’t find Non_Unicode version of EhPi. Since this tool relies on other executables to perform database specific tasks, I assumed I would be okay with using Unicode Version of EhPi. I couldn’t find any documentation suggesting I could use Unicode version for Non_unicode systems. And I didn’t want to spend time looking for documentation nor opened message. I continued and successfully upgraded sandbox system using Unicode version of EhPi. 

Unicode Conversion

I adjusted the number of parallel jobs, Oracle parameters and I/O related parameters to optimize both export and import jobs. After converting sandbox (Production size) twice and QA system (production like), we were satisfied with the performance of export and import jobs.

Dual Stack Split

We had challenges in splitting dual stack only for the first system. After successfully spitting the sandbox system, we had no issues in splitting other systems. We used “export content from Dual stack and import content into Single stack system” method. This may not work for all customers.

SAP Global Support’s Confusion

In QA system, we ran into a new issue during upgrade. We didn’t run into that issue in other systems. We upgraded QA just 2 weeks before upgrading our production system. We tried to troubleshoot but didn’t have the luxury of spending several hours. While spending time troubleshooting, we opened a message in parallel. Unfortunately the message didn’t help because SAP Global Support initially thought we were using wrong version (Unicode) of EhPi (based on log) to upgrade Non-Unicode version of NW. By the time they realized non-Unicode version was not available, we’ve already identified the reason, fixed it and began our Unicode Conversion.


Two hours into validation of our production system, BW team identified a serious issue. We started receiving ORA-00600 errors. More details in this blog: [original link is broken] [original link is broken] [original link is broken] [original link is broken] [original link is broken] [original link is broken]


We were satisfied with the performance after adjusting:

  • Number of parallel jobs
  • PSA and Change logs deletion
  • Oracle Parameters and
  • I/O Parameters.

For larger databases and/or customers with availability constraints, these options are available:

  • Distribution Monitor and/or
  • Evaluate the system for “Drop before export/recreate after import” secondary indexes of less critical but large ODS tables. This way we could rebuild the indexes after turning over the system to business for validation.
Be the first to leave a comment
You must be Logged on to comment or reply to a post.