Saving system specific tables - part 2
In a previous article we described a method to save your system specific data of your SAP system - data, which can not be taken from another system as it is unique for your SAP system, for example RFC connections and a lot of configuration data belonging to ALE, SAP Office, SAP Connect, the Security Audit Log and many more. In case something goes wrong with this data, it could be a hard task or nearly impossible to restore / reconfigure these settings - there is no other system with the same data, so you do not have any possibility to have a look or create a transport request.
Recently I found this in the SAP community forum (https://answers.sap.com/questions/13551577/sicf-accidently-activated-the-entire-tree.html):
A simple wrong click (which might happen every day, no one is safe from this, it can happen to anyone), and now there is a big problem to get back to the previous settings!
The answer to the question - in a nutshell - is: no, there is no way. There are some tools available in the area of the service definition, like exporting the active services and a mass activation tool, but typically there is no export file, and consequently nothing on which you can start the recovery. And the mentioned tools are specific to the service definitions, so you have to know about them and use them, and in this case it would be necessary to do that manually (because the export feature can be used in a dialog session only - no way to schedule it so that it will be executed periodically and automatically).
But with "Shortcut for SAP systems" you can use a generic approach, fitting to the service definitions as well as to many other settings. As written above we described this in another blog article - focused on the dialog function "Process table data using R3trans", dealing with the tables for the RFC connection. If we want to backup all system specific data periodically, using the command line tool is the preferable solution.
So here is a description of how you can set up a daily backup of system-specific data for being able to restore corrupted settings within a few minutes if necessary.
Ok, but which tables contain the system-specific data? Difficult to figure out... fortunately the SAP system gives us this information! We can use the "PCA tool" (Post Copy Automation). This tool is part of the SAP Landscape Management, enterprise edition software and SAP Landscape Management Cloud software. To use the full scope of its functions, you must either own an SAP Landscape Management, enterprise edition license or an SAP Landscape Management Cloud subscription. If this does not fit to your situation, you can not use it and likely not all software parts of the PCA tool are available in your system. But the good news is, that in every case we can use it to determine the tables which are worth to consider them in a backup.
1st step: Use the program Z_SHOW_PCA_TABLES supplied with our product (folder ABAPs, file 'ShowPCATables.txt', or download it here) to get the complete list. This is the selection screen:
The main usage of the PCA tool is in the context of system refreshes. With the "Refresh" option (1) we will get a complete list of the tables, that the PCA tool would export in front of a system refresh and import it afterwards in the post-processing. In other words, we will get a list of tables containing the system-specific configuration data.
The block "Data for XML file generation" is about the options for generating an XML file to be used with the "Shortcut for SAP systems" command line tool. The command line tool enables you to execute nearly all functions of "Shortcut for SAP systems" outside of the GUI application, executable on OS level. And it is not only about executing a single function - the command line tool allows us to execute multiple tasks with a single call. This is where we want to go to.
As we want to create a backup of the system-specific configuration data we set the flag at the corresponding field (2).
In the input field (3) we enter the connection to the SAP system. Input field (4) is for the target directory where the backup data is to be stored. Here we use a dedicated directory for this purpose (which is recommendable).
Now let's execute the program. We will receive a list of components and their related tables:
So this is the overall amount of components and tables that would be handled by the PCA tool (if you have the necessary license) in the context of a system refresh.
Above the table, you will find a button "XML file". With this button the ABAP program can generate an XML file that can be used by "Shortcut for SAP systems" command line tool for backing up the tables in files.
If you want, you can use the ALV filter and/or the selection mark in the 1st row to reduce the amount of components and/or tables. As this article is about backing up system specific data, we simply take all of the components and tables.
2nd step: Click on the "XML file" button
After this you will be asked for directory and filename of the XML file.
After generating and storing the XML file, you will get some information about the content of the generated XML file.
There is a difference of 'Total tables' to 'Distinct tables'. This is because some tables are listed in more than one component (e.g. the components ARCHIVE, ARCHIVE_ADK and ARCHIVE_CUST have some intersections regarding their tables, same is for components CRM, CRMINERP, PI_BASIS_CRM and some more).
Ok, let's have a look into the generated XML file.
For every component we will find a <Task> tag, addressing the "Process table data using R3trans" function in "Shortcut for SAP systems". In the <DefaultConnection> tag we find the connection given in the selection screen and in the <ServerFile> tags the path from the selection screen is used.
As written before the XML file is intended to be processed by the command line tool. So, let's execute it.
With this one-liner the content of all PCA components with their tables will be written into files in the SAP system:
It takes a few minutes. At the end you can see in the last message from the command line tool whether errors occurred or everything is fine.
RC 4... a warning. Let's have a look at the reason for this. You can also have a look into the XML file - the command line tool updates it and writes some information into it. At the end you will find a summary, and also each <Task> tag was enriched by a <Result> tag.
Having a look into the directory in the SAP system you can see lots of files. For each R3trans file you will also find a log file.
The log files were created by R3trans and contain some information about the tables and the amount of processed records. Here we can find the reason for the warning:
Here some information about a transport request comes up. Why?
R3trans works in general with a "control file" (containing the R3trans command, the specification of the client etc.) and - optionally - with a "command file", which is in fact a transport request. The tables to be processed can be specified in the control file and/or in the command file. For enabling R3trans to use parallelization (expecially for system refreshes the performance often becomes an issue), the tables are to be specified in a command file. The warning here results out of the use of a command file. When using the PCA tool for system refreshes, you will find the same warning. Not for every component a command file is used, therefore some tasks ended with RC 0.
More or less that's all! Using the command line tool and the XML file we can schedule a daily backup of this data. This can be done using a lean solution like the Windows Task Scheduler or a full-blown automation solution like UC4©.
In a nutshell, there is very little effort to set it up:
- create a backup directory on the SAP server
- create the XML file with the supplied ABAP program (this should be done individually for each system line on the development system, because the amount of tables depends on the SAP release and installed software components).
- schedule the one-liner (calling the command line tool with the XML file as argument) periodically.
In total: 5 minutes per SAP system? What little effort for such a huuuuge gain in security in your SAP operations.
If we get into the situation that by mistake the whole SICF tree was activated (like the unlucky guy mentioned above), we can easily restore the data in a minute. Just use the "Process table data using R3trans" function for "Import" and use the file containing the data.
After taking over the data from the XML file and clicking on the Execute button the data will be restored in few seconds.
There is a warning given. The reason for this is visible in the log file:
R3trans found that the data file was created on the same system. Yes, that's typical for a backup.
In case the "Buffer synchronization" was not set, due to table buffering it may take few minutes after executing the import (you may have a look into the open synchronizations by using transaction AL12), but finally the SICF tree will be the same as at the time the backup was made!
So, this would be an easy way to get more security in the operability of your SAP systems. In my opinion this should be done for every productively used system. Even if there are doubts that a simple import of the stored data might not be the best approach to fix a recent problem with lost data, the data is there and could also be used to restore it on another system - as an intermediate system where the data can be verified and adjusted if necessary. Once the data is available and usable, the possibilities are correspondingly diverse. Is the user department missing an important variant for a report which can not be recreated easily? Ok, let's make a backup of the variants on a test system, then restore the variants data from the backup of our productive system on the test system, put the variant into a transport request, release the transport request and finally restore the variants on the test system. Likely you will be the hero of the day.
The alternative to this easily done backup of system specific data is a point-in-time recovery of the whole system - if you exactly know the point in time when the data got lost. In practice, this would be a disaster and the very last way out and likely would create more problems than solving it - I never noticed that this really has been done on a productive system. You could also think about a point-in-time recovery on another (test) system, but also this option has some hurdles: you need to have the hardware resources and it is quite time-consuming. Likely it would take days instead of some minutes. The above described backup method can be set up with less effort and provides a tremendous increase in the ability to quickly fix a problem in your SAP systems.
Es gibt noch keine Rezension.