Quantcast
Channel: SCN : Blog List - All Communities
Viewing all articles
Browse latest Browse all 2548

How to automate heterogeneous system copy - Part I: Database export

$
0
0

Introduction

According to SAP documentation, heterogeneous system copies are used (as part of the SAP system lifecycle), when the operating system or underlying database system of an SAP system need to be changed.

 

Normally, SAP provides the heterogeneous system copy functionality in Software Provisioning Manager as part of the Software Logistics Toolset (sltoolset).

 

However, I have seen customer cases that use periodic system copies in order to build other non-productive SAP systems or test certain technical configurations.

From the software logistics perspective, performing a system copy requires quite a lot of user interaction in SWPM for activities such as:

  • export preparation
  • table splitting preparation
  • database export

 

This situation can be overcome by automating some of these aspects. The scrips described in this blog post, still in their initial version, can be successfully applied for non-productive operations. For productive use cases, some other improvements (that also include downtime optimization), might need to be applied.

 

Please note that the scripts below make use of SAP standard MIGMON and Package/Table Splitter executables.

 

Constraints for the initial version:

  • Oracle database is used as source database
  • Limited capabilities for table splitting
  • Not all capabilities of package splitter are used

 

 

 

Export prerequisites - export_prereqs.sh

Usage:

export_prereqs.sh <path to export directory>

 

export_prereqs.sh provides the following functionalities:

  • create export directory and depended directory structure
  • copy SAPJVM to export directory, so that it can be used my MIGMON
  • if there are kernel executables suitable for the current kernel release in kit directory:
    • back up the kernel in /sapmnt/<SID>/exe
    • copy R3* executables in kit directory to DIR_LIBRARY location

 

Structure of export directory:

  • DB [contains *.TPL files and directories for supported databases]
    • ORA
    • DB2
    • DB4
    • ADA
    • INF
    • DB6
    • MSS
  • EXCHANGE [exchange directory, stores .SGN files, in case parallel export/import is used]
  • BACKUP [backup location; kernel backup is performed in this directory]
  • MIGMON [Migration Monitor deployment directory]
    • export_logs [contains R3load logs, e.g. <package>.log]
  • LOG [runtime logs for different phases of the automatic system copy, e.g. table and package splitting]
  • DATA [contains *.STR, *.WHR, *STR.old files]

 

 

 

Table split file creation - create_splitfile.sh

Usage:

create_splitfile.sh [split size in GB]

 

create_splitfile.sh takes, as an optional argument, the split size in GB for the tables. If such a parameter is not supplied, the default value of 1GB will be used.

The script calls sqlplus /nolog @largest_tables, which returns the list of tables larger than 1GB. This list is processed further and the number of splits for each table is calculated.

File "split.txt" is also generated during this run - the format is the standard one:

table_name%number_of_splits

 

This script can also be used independently, as the format of the generated split.txt file can be also used in SWPM for table splitting.

 

Please note that table splitting currently supports Oracle database.

 

 

 

Table and package splitting - table_split.sh

Usage:

table_split.sh <path to split file> <path to DATA directory> <path to log directory>

The table and package splitter provide a quick way to perform the actual splitting.

Sequence of operations:

  1. Generate helper files for R3ta and R3ldctl
  2. Generate all STR files using R3ldctl
  3. Generate STR files for tables that will be split and make sure they are extracted from the initial packages (point 2 above), using R3ldctl -i. This point also uses one of the helper files generated in the first step.
  4. Start R3ta processes (in parallel) for table splitting and monitor the PIDs.
  5. After all R3ta processes are finished, start WHERE-splitter
  6. Run R3szchk, in order to estimate table sizes. This step is also needed for package splitting.
  7. Run package splitter with size limit: 700MB.
  8. Clean up remaining log files.

 

Current limitations for table_split.sh:

  • not all package split options are made available
  • package size is hard-coded.

 

 

 

Export preparation and start - export_prep.sh

Usage:

export_prep.sh <path to export directory>

 

The following features are included in export_prep.sh:

  • cleanup of DATA directory
  • extract Migration Monitor from kit directory to <export directory>/MIGMON
  • prepare export_monitor_cmd.properties with default settings, based on the choice for the export directory
  • set environment variables and start export_monitor.sh

 

Open points for export_monitor_cmd.properties:

  • add parameter for target codepage. Currently, codepage 4103 is hard-coded.

 

 

 

Download resources

The scripts used in the automation process can be downloaded from SAP Mobile Documents

 

 

Legend:

NotationMeaning
< ... >Mandatory parameter
[ ... ]Optional parameter

 

 

References:

- TADM70 (SAP System: OS and DB Migration)

- SAP Migration Monitor (MIGMON) and Package/Where Splitter, available on SAP Service Marketplace

- Automate WHR & STR file generation for Oracle Partitioned Tables, by Marius Batrinu


Viewing all articles
Browse latest Browse all 2548

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>