FAQ of near-Zero Downtime Maintenance for SAP Business Suite Systems
In this blog you find the answers to the most important questions we realized when communicating to customers, partners, and consultants.
You find the newest information about the near-Zero Downtime Maintenance (nZDM) for SUM in the SUM1.0 Guide and in SAP Notes 1678565 and
How to get key figures about the net process runtime and savings in your environment?
In the SUM directory under /abap/htdoc you will find the log file UPGANA.XML. When you copy this file and the UpgAnalysis.xsl file in a local directory and call the XML file you see it directly in a browser window.
When you run the SUM with nZDM on a test system at first you can use the figures to forecast your next run in production environment.
How to verify the needed database disc space?
As mentioned, the needed additional database disc space is minimized due to the focus on update/upgrade relevant tables for the copy to shadow operation. In order to calculate the needed DB disc-space you can use the experiences made in the first run.
In SUM directory under /SUM/abap/bin you find the log file “ALLTABU.DAT”, which shows the tables used by the R3TRANS. Besides of AIMs and conversions this table shows most of the table names part of the nZDM change recording.
Large tables (e.g. with size of 50 GB or more) can be identified with the help of the database analysis transaction in the Suite System (transaction DB02).
How to avoid long runtime of copy to shadow due to tables STXH and STXL?
In the previous SPs of SUM 1.0, when nZDM capabilities were delivered only on request, it was possible to get long copy to shadow runtime in pre-processing phase due to the STXH and STXLtables . Both tables are excluded from the shadow update with SUM 1.0 SP7.
Since the shipment of SUM 1.0 SP8 the copy to shadow is mainly taken over by a new technique "fast data copy". Issues regarding long running copy to shadow might be solved with this new technique finally.
Dumps in shadow system: PXA_NO_FREE_SPACE
If the parameter ABAP/buffersize is too small you'll get short dymps during the transfer process in the shadow. We recommend to extend the ABAP/buffersize to 800.000. (Trans.: RZ10)
See SAP Note 1678564, section 5 (Troubleshooting).
Why tables are not copied to the shadow?
The following exception have to be considered:
- Cluster tables
- Pool tables
- G tables
- Tables with large names (16 Characters with Secondery Indexes with 3 Letters)
- Index of tables
Big tables might be excluded from shadow operation due to a sapup parameter.
With the parameter set_max_tab_size = ON this feature is activated (default value). The parameter isu_max_tab_size = value in Kbyte (default 50 GB) is the threshold. See also SAP Note 1678564