Heterogeneous System Copy Export: Table Splitting

I recently had a customer who requiered an OS/DB migration for their ABAP 8TB database.

The particular case for this customer was the unavailability to export and import in week window, during acceptable times of table VBOX, which was around 500 GB in size, and no data could be deleted from it until the system was migrated on the new target platform.

Using the SAPInst tool for your particular version, you can find the "Table Splitting Preparation". What this does is making a preparation for splitting the table in multiple R3Load packages, which later allows for multiple R3Load packages during import, thus allowing parallelization depending on your hardware and making the overall copy process faster.

First of all, you have to calculate in how many packages you are going to split your "trouble table". My advice is to split a table up to packages of 5 GB max. In this case, my 500 GB VBOX table should split into 10 packages.

1- Create an empty text file containing the list of table(s) you want to split and their number of packages. For example, my splittable.txt contains:
              
                           VBOX%10

The format of this file is %.

2- Place the the file on an empty directory.

3- Create a directory where you will place later the Export Dump.

4- Run SAPinst for your particular version and choose - - Software Life-Cycle Options - System Copy - - Based on - Table Splitting Preparation.

5- Fill in the requiered data. Choose 1 Parallel R3ta Run per CPU if your system is on a High Load (choose 1 x 2 CPUs if on very high load), and if on low load choose 2 R3ta processes per CPU.

6- Copy the resulting WHR files to the DATA directory of the Export directory created on step 3.


Later on, execute the database export which will cause your SAP System to stop.

Use the resulting Split Preparation + DB Export on your target system to Import the Load. You can customize the order of the packages editing the order_by.txt file located on the export directory.

The infamous SAP DPMON tool

I often get a lot of incidents and questions from customers and colleagues about not being able to access the SAP system (ABAP) when all the given Dialog process are busy or with any other status different than Waiting.

Well, just to let you know, there is no real need to logon into the system to get a picture of what is going on with dialog process and workprocesses in general.

You can use the infamous DPMON (Dispatcher Monitor) tool from operating system level.
This tool can be found either at the instance exe´s directory or from the kernel repository sys/exe/run/ directory.

DPMON lets you manage workprocess as in the same manner like in SM50 transaction. You can:

- Have a quick look at the Dispatcher and workprocess table, with current status of each process.
- Increase/Decrease trace level.
- End a workprocess if you think that is really necessessary!

To launch DPMON:

- Logon to the operating system with your adm user.
- Execute dpmon -pf=/path/to/your/instance_profile, generally: /sapmnt/sys/profile/server_sid_no.pfl or in Windows \\server\sapmnt\sys\profile.
- The command options and actions are available through text based UI.

DPMON saved lots of customers and colleagues unwanted system downtime!!

Remote or onsite Technical Consulting Services

Last couple of years have been truly a nightmare of work schedules!!!
For all my readers and followers, I can tell you now Im available for remote or onsite technical consulting services.

Covered services:

(all platforms, products and versions)

- SAP System Arquitecture Design.
- SAP System Technical Implementation Projects (Installations, System Copies, Migrations, Unicode Conversions).
- SAP Solution Manager E2E Implementation.
- On Demand complex Incident and Change Management.
- SAP System Platform Technical Training.

I do only accept payments through PayPal. I currently have quite a pretty flexible schedule for remote services. To know more about my rates, and availability, please use the contact section.

Re-importing a SPAM/SAINT Support Package

Due to errors, because you want to roll-back to any SPAM version, or just because SAP Support has requested you to do so; you can implement the following workaround to re-import a current (or older!) SPAM/SAINT update to your system.


Procedure:

1- Call transaction SEPS --> Goto --> Inbox, and order by column Subject. Search for all the SAPKD* packages (for example SAPKD70026).

2- Take note of all the .PAT files associated to the SPAM packages and make a backup copy of these files.

3- Go back to SEPS --> Goto --> Inbox, and order by colum Subject. Select all entries with status C or N, and delete them (this will also delete the .PAT files in the EPS/in directory).

4- After that you can upload the desired SPAM package you want to import to the EPS/in directory, either through front-end (tx SPAM), or through backend (SAPCAR).

5- Import the SPAM update: tx SPAM --> Import SPAM/SAINT Update


This procedure might be useful to other components (though i never tried it), but please keep in mind that is very dangerous!!! To re-import other component Support Packages, you should ask SAP Support.

Hardware Handling for SAP/SQL Server 2008

Here is an updated document of the Best Practices (including hardware design) of SQL Server 2008 implementation for SAP.

Most of the design foundations are applicable by logic to any other Database platform, excluding of course, specific SQLServer configuration.

I highly recommend its reading:

http://download.microsoft.com/download/d/9/4/d948f981-926e-40fa-a026-5bfcf076d9b9/SAP_SQL2008_Best%20Practices_Part_I.docx

For us, IT guys (and girls), I suggest you pay big attention to:

- Hardware selection (page 27)
- Installation and configuration (page 32)
- SQL Server on NUMA (page 56)
- Transparent Database Encryption (page 75)
- Windows Server specific configurations (page 95)

If you are new to SAP, or are just a DBA in your organization, I also suggest reading the introductory part of the document (What is SAP / How does SAP interact with SQL Server)

Limited SAP ORACLE support for VMWare

A few months ago, SAP did not support ORACLE under a VMWare enviroment.
Now the support has increased a bit, but still with the following limitations:

- Only version 10.2.0.4 or higher (no 9.x, no 10.2.0.2)
- Only single instance (no RAC support)
- If you plan to virtualize your SAP/Oracle system under Microsoft platform, the minimun version supported is Windows Server 2008.
- When opening an OSS message, you have clearly state that this system runs under VMWare.


Note the following:

"If the problem is determined not to be a known Oracle issue, the problem will be forwarded to VMware for support. When the customer can demonstrate that the issue occurs when running on the native OS, Oracle will resume support."

Check OSS Note 1173954 for more information

Hyper-V virtualization for systems running on Windows / SQL Server

Hyper-V technology from Microsoft is now officially supported by SAP even for production usage.

The following combinations of OS/DB are supported for SAP under Hyper-V:

- Windows / DB2 for LUW
- Windows / SQL Server

Regarding Oracle virtualization usage for production, at the moment is not supported -- not even under VMWare or XEN (see note 1173954).

One of the big goals of correctly designing a virtualization solution, is to correctly set-up I/O access throuhput, access to memory and CPU. For production, memory and CPU assigment should be left at least the minimum requeriments fixed.

For I/O performance, it is strongly recommended that you set-up direct raw access for Database files over SAN disks. It is also recommened that you check with you SAN hardware vendor the certified configuration and distribution of Disks for your SAP system.