How-to Guide SAP NetWeaver 04

How To Minimize Downtime For Delta Initialization

Version 1.00 December 2004

Applicable Releases: SAP NetWeaver 04

 Copyright 2004 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C , World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data

contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. These materials are provided as is without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages. SAP NetWeaver How-to Guides are intended to simplify the product implementation. While specific product features and procedures typically are explained in a practical business context, it is not implied that those features and procedures are the only approach in solving a specific business problem using SAP NetWeaver. Should you wish to receive additional information, clarification or support, please refer to SAP Consulting. Any software coding and/or code lines / strings (Code) included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent.

1 Scenario
You would like to load data from your (SAP ERP) source system into an SAP BW system using the BW delta process. Initializing this delta process can take an exceptional amount of time, and for many DataSources, it imposes restrictions on the production system (for example, stopping work in the affected application component or having a high workload). You would like to minimize the amount of time and the restrictions that the initial load causes on the production system.

2 Introduction
The solution described in this paper includes only the steps that are absolutely necessary to execute it in the productive system and to execute the main workload in a copy. The steps that are performed on the production system only take a few minutes. Afterwards, SAP BW extracts the data from a copied (mirror) system rather than the production system, relieving all restrictions on the latter. Necessary for this scenario is the ability to quickly perform a system copy, or a synchronization/split of a mirror system. The scenario described here uses the TimeFinder from EMC2. TimeFinder software provides a fast and flexible way to create a physical copy of the R/3 database that can then be used to create a second instance of the database. The methods used in this guide are independent from whether you use TimeFinder or SRDF to create the copy of your database. More information on how to create the copy can be found in several EMC2 white papers listed in section 4. The following picture illustrates the solution.

BW Production

2 R/3 Production R/3 Mirror

1. 2. 3.

Trigger extraction (send request IDoc) without transferring data Split the mirror system. Extract data from the mirror system to BW.

-1-

4.

Transfer monitor information generated by extraction.

The initialization of the delta process is simulated in the production system without actually transferring data. Thus, the BW status information appears as if the extraction had already run. In doing so, delta data can already be collected in the production system. The data is subsequently transferred from the mirror system without disturbing the production system. A prerequisite for this process is that a simulation of the delta initialization process is already implemented for the respective extractor. You can check this in the ROOSOURCE table. The value "1" has to be in the INITSIMU field for the DataSource. For a better understanding, it would be helpful to become familiar with the components used in this example. Systems: Original source system (production system): o SAP ID: QY5 o Client 100 o Application server: pwdf0131 o Operating system: Windows NT o Release 4.5B, PI 2002.1 Mirror system o SAP ID: OY5 o Client 100 o Application server: emcmirror o Operating system: Windows NT o Release 4.5B, PI 2002.1 SAP BW-System o SAP ID: QB5 o Local source system entered in the BW system: QY5CLNT100 o DataSource / InfoSource: 2LIS_11_VAITM o Release 2.1C

-2-

3 The Step By Step Solution

3.1 Trigger the Extraction in SAP BW without Transferring Data
1. At the end of the extraction, you have to transfer monitor information from the mirror system into the original system using an RFC. In order to execute this RFC, the original system needs to already have an RFC-connection pointing to itself. If this RFC connection does not exist, create it in transaction SM59.

2. In the SAP BW system, enter your user as "Debugging User" in transaction RSADMIN.

-3-

3. Create or use an InfoPackage for initializing the delta process. Switch off the immediate update of data in the source system (the checkbox needs to be empty). This is only possible if you have completed step 2 for the current user (restart Administrator Workbench).

4. Now start the loading of data in the InfoPackage. By doing this, a request IDoc is sent to the source system that initially remains in the IDoc inbox of the production system without being directly processed.

-4-

3.2 Activities During Downtime (Synchronize and Split Mirror System, Enable Delta)
Downtime for your productive system begins. You have to make sure that no users or jobs are active in the system (check transactions SM04, SM50, and SM66). You need to complete the following steps:

Depending on the extractor, specific steps could be necessary that are also required for normal delta initializations (without mirror systems), for example, stopping the update. If necessary, these steps also need to be performed, but are not described in any further detail here.

Perform a system copy.

The original system is put in a position to write delta records into the delta queue. This is done by posting the request IDoc in a special mode (called DELTA_ENABLE).

5. Complete the required steps for copying the original system or for synchronizing the mirror system with the original system and the subsequent split. To do this, use your EMC2 documentation. In our example, the important steps are the following: Establish (synchronize): Establishing the copy might have already occurred during the preparation (before downtime) and includes the following steps: a. Shut down the R/3 mirror system in preparation for copying.

b. Shut down the database for the mirror system. c. Stop the SAPOSCOL, R/3 for the mirror system.

d. Unmount the disk drive(s) for the mirror system (Disk Administrator). e. Issue the "Establish" command.

Split (system separation): Splitting the two systems so that the systems are now independent of one another. a. File system flush with symntctl (only with

-5-

Windows NT/2000). b. Issue the split command.

6. Call up the transaction BALE (<4.6C) or BD87 (>= 4.6C) next in the original system. To determine the request IDoc number, double click on the respective line (message type RSRQST, status 64):

7. Open the view for "Data records". Monitor the IDoc entries by double clicking on the data records, especially if there are several. You can see the IDoc number in the header.

-6-

8. On the right-hand side, you can see the screen that appears after double clicking on a data record. Here you find all of the information that is important for identifying the correct IDoc (for example, DataSource, time stamp, or selection criteria).

9. Call up the function module RSC1_ZDD_DELTA_ENABLE (transaction SE37, F8) and specify the request IDocnumber in parameter I_DOCNUM. Afterwards, the system is able to collect deltas for the DataSource and now you can resume work in the production system.

3.3 Extraction from the Mirror System, Transfer of Monitor Information

The next step includes extracting the data from the mirror system and transferring it to the SAP BW system while the production operation is now running in the original system. 10. To do this, you next have to start the R/3 mirror system. The following steps are described in detail in the EMC2 documentation. For a Windows NT operating system, for example, the following steps have to be completed: Mount the disk drive (mirror system). Start the database (mirror system). Start SAPOSCOL, SAPSERVICE Set up a user in the mirror system that has database authorization for the mirror

-7-

systems SID. (This point does not apply if the original system already has such a user, because this also exists in the mirror system.) Start the R/3 System (mirror system). 11. Depending on what needs to be done in the mirror system, it could be necessary to set up the transport system in transaction STMS. Since no transports are actually run, the configuration does not matter, and you can use the default values.

12. After you have completed the possible, additional steps dependent on the DataSource (for example, creating setup tables), post the request IDoc as usual in the mirror system (meaning NOT with the report that was used in the original system). To do this, start transaction BD87 and choose "Posting" of the IDoc with status 64.

-8-

13. Enter the same IDoc number that you already specified in step 7, and start the processing.

14. The extraction is now running. You can check the status as usual in the BW monitor. There you also find the unique request number that the system has assigned for this loading process. This number is needed later on.

15. In this step, the monitor information that was collected in the mirror system, during the extraction, is transferred into the original system so that useful monitoring is possible for the DeltaInit request. This includes the following: Information for the data packages sent during the extraction Information for the Info-IDocs sent during the extraction Entries in the application log Update for the delta administration tables To transfer the monitor information, execute the function module RSC1_ZDD_REPLAY_SET. You receive the request number from the monitor

-9-

and enter the RFC connection from step 1 in the second field.

- 10 -

4 Appendix
DataSources used With our tests, the following DataSources were used (as examples): 2LIS_11_VAITM 0FI_AR_3 0FI_AP_3 Restriction for the Extracted Tables The following only applies if the system ID of the mirror system differs from the original system ID. (In our example QY5 is different from OY5.) If you follow the EMC2 procedure, a "Clean-Up" script is executed on the mirror system after the split. This prevents scheduled tasks (for example, batch and print jobs) from being executed in the mirror system. To do this, the script changes the control entries in specific tables. Although it is highly improbable that these tables will play a role in a BW extraction, it should be mentioned that after modification, the content of the tables no longer agrees with that in the original system, and your extraction could transfer incorrect data into the SAP BW system. This concerns the following tables: TCESYST, TCESYSTT TSYST, TSYSTT TASYS TCECPSTAT, TCEDELI TADIR E071, E070, E070L TBTCS, TBTCO TSP01, TSP02, TSP02F, TSP0E, TSPVJOB, TST01, TST03, TSP03, TSP03C, TSP03D TEMSG, TEMSI Several DataSources Without restrictions, you can use this process simultaneously for several extractions. This is to ensure that you have downtime once, or that the number of downtimes is minimized. This applies to simultaneous delta initializations (with selection criteria) of one DataSource, as well as simultaneous delta intitializations of different DataSources. Additional Documents (EMC2)
Oracle, Windows NT - Creating Second Instance Copies for SAP with TimeFinder Bringing Up an SAP R/3 Second Instance at http://www.emc.com/techlib Oracle, UNIX - Creating Second Instance Copies for SAP with TimeFinder Bringing Up an SAP R/3 Second Instance at http://www.emc.com/techlib SQL Server 2000 and Windows 2000 Creating Second Instance Copies for mySAP with TimeFinder at http://www.emc.com/techlib Creating Hot Snapshots and Standby Databases with IBM DB2 Universal Database V7.2 and EMC TimeFinder at http://www.emc.com/techlib and http://www.ibm.com Using Multiple BCV Database Copies with IBM DB2 Universal Database V7.2 and EMC TimeFinder at http://www.emc.com/techlib and http://www.ibm.com

- 11 -

www.sdn.sap.com/irj/sdn/howtoguides