Content Server Migration Stratergies
The content server installation has two flavors:
- SAP Content Server and SAP Cache Server (Legacy)
These versions have to depend on Microsoft IIS server (Windows) or Apache HTTP server (Unix) for web-engine.
- SAP Content Server and SAP Cache Server (7.5 or higher)
These newer versions of Content Servers are standalone and do not require any web-engine.
The below approaches can be used to migrate(Homogeneous/Heterogeneous) and consolidate the content server data:
- Performing backup/restore with a full backup, Incremental backups, and Log backups.
- Performing migration of the repositories via export/import (loadercli).
- Performing migration of the documents via the SAP customized reports.
- For any content server migration make sure that, enough data files and log files are added, taking source as a reference.(This is required to accommodate the source data)
- The target content server can be of higher version or equal to that of the source.
- Make sure the content servers on the source and target are of the same Installation flavor.
Note: Always make sure that the initial vanilla backup has been taken on the target system before making any changes.
The backup/Restore method.
In the above-mentioned method, we can take a full backup(as a single file or split files) on the source and multiple incremental backups and log backups during cutover for restoring the same onto the target.
Below are the commands that can be used for the same.
- Login to the Max-DB with the below commands:
su – sqd<SID>
./dbmcli -d <SID> -u CONTROL,<Password>
- Execute the below command to check the db state.
- Create a medium from the database backups downloaded from the source.
- Complete data backups are mapped to DATA file.
- Incremental data backups are mapped to PAGES file.
- Log backups are mapped to LOG file.
medium_put restore_dump <path to backup file/backup file name> FILE DATA 0 8 (Full backup part 1)
medium_put restore_dump1 <path to backup file/backup file name> FILE DATA 0 8 (Full backup part 2)
medium_put restore_dumpn <path to backup file/backup file name> FILE DATA 0 8 (Full backup part n)
medium_put restore_dump2 <path to backup file/backup file name> FILE PAGES 0 8 (Incremental backup)
medium_put restore_dump3 <path to backup file/backup file name> FILE LOG 0 8 (Log backups)
- Once all the media has been added, use the below command to check the added backup files.
- Change the database to admin mode before restoring.
Note: The database cannot be brought into online mode until all the files are recovered.
- Start the Content server restore with the below command.
- The subsequent backup parts have to be restored with below command.
- Make sure that the session remains the same between the restores. An alternate way to restore all the backups at once is with the below shell script.
echo db_admin >> recovery.cmd
echo db_connect >> recovery.cmd
echo recover_start restore_dump >> recovery.cmd
echo recover_replace restore_dump1 >> recovery.cmd
echo recover_replace restore_dump10 >> recovery.cmd
echo /sapdb/programs/bin/dbmcli -d <SID> -u control,<password> -i recovery.cmd >> run.cmd
- Execute the below command to run the restoration in the background.
nohup ./run.cmd &
- You can lookout for the status with the below command.
- For incremental backup use the command again.
- Make sure to clear the log before restoring the log backups.
util_execute clear log
- Before bringing the db online, execute the below command.
db_execute ALTER PASSWORD SUPERDBA <password>
load_systab -u SUPERDBA,<password>
- Now the database can be brought online.
- Now repoint the repositories to the migrated S/4hana system via OAC0 and check the connectivity via program RSCMST from SE38.
Export/Import method (loadercli):
Make sure that the repository is present on both source and target with the same name.
It would also work on the heterogenous combination (ex: Source-Windows & Target-Linux)
- Initially check the repository number by logging in with SAPR3 username and execute the below script in the source system.
select * from CONTREP
- Make note of the repository number (let’s consider X in our case) and prepare the below text files with the mentioned content.
EXPORT COLUMNS * FROM “SAPR3″.”DOCUMENTS000X” DATA OUTFILE ‘DOCUMENTS000X_full.data’ RECORDS
EXPORT COLUMNS * FROM “SAPR3″.”COMPONENTS000X” DATA OUTFILE ‘COMPONENTS000X_full.data’ RECORDS
- Export the data using the below commands.
./loadercli -d <SID> -u SAPR3,SAP -b /<path to file>/exportdocs1.txt
./loadercli -d <SID> -u SAPR3,SAP -b /<path to file>/exportcomps1.txt
- Copy the export files on the target server.
- Similarly check the repository number on the target
select * from CONTREP
- Let’s consider the repository number as X in our case and execute the below import commands.
IMPORT TABLE “SAPR3″.”DOCUMENTS000X” IGNORE DUPLICATES data instream file ‘DOCUMENTS000X_full.data’ RECORDS
IMPORT TABLE “SAPR3″.”COMPONENTS000X” IGNORE DUPLICATES data instream file ‘COMPONENTS000X_full.data’ RECORDS
- Import the data using the below commands.
./loadercli -d <SID> -u SAPR3,SAP -b /<path to file>/importdocs1.txt
./loadercli -d <SID> -u SAPR3,SAP -b /<path to file>/importcomps1.txt
Migration documents via custom Z programs (Z_DOC_COPY & Z_MIGRATE_ARCHIVELINK)
The advantage of using the mentioned reports is that they can be run periodically until the cutover.
Z_DOC_COPY (SAP Note 2774469)
This report can be used to copy the attachments from the source content server and copy the attachments to the target server one by one.
This report compares the list of attachments between source and target; therefore the report can be re-run/resumed anytime.
- Execute SE38 and run the report Z_DOC_COPY
Give the below inputs and click on execute.
Z_MIGRATE_ARCHIVELINK (SAP Note 1043676)
This report can be used to copy the attachments from the source content server to target, which are link based.
This report would change the link table entries and update the newly generated ids in the target repository.
- Execute SE38 and run the report Z_MIGRATE_ARCHIVELINK
Give the below inputs and click on execute buy checking the appropriate boxes.
The below blogs were used for the migration strategies mentioned above.
Special thanks to Alexander Kaiser, Ashok Dalai & B.T Praveen Kumar