Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Frequently asked Questions when Using BW Post Copy Automation -

former_member195645
Participant
‎2013 Mar 20 12:02 PM
14,768

- in a SAP NetWeaver BW on SAP HANA
  Migration Context

This page lists the topics to consider when using  BW PCA in a SAP NetWeaver BW on SAP HANA migration context. Last update: 2nd July 2015

1.    Installation

1.1  LVM license

Typically the process starts with getting the license for LVM in place. As BW PCA is embedded into the Post-Copy Automation framework this is licensed by LVM and requires a valid LVM license. Customers wanting to use BW PCA Initial Copy (incl. delta queue cloning feature), need to contact their Account Executive / Global Account Director to get the according license. For questions on licensing please contact your AE or LVM Solution Management Jens.Rolke@sap.com). Due to involvement of different parties to get the license in place you should start getting the license early in your project phase. The details on the license installation you find in the installation guide at http://service.sap.com/~sapidb/011000358700000175442014E.

1.2   Where can I download the software, I can’t find the software in service market place.

Before being able to see the software you have to be registered as a LVM customer. This requires the license for LVM (see point 1). In case this is in place you can find the software under following the path http://service.sap.com/swdc --> Installations and Upgrades --> Browse our Download Catalog --> SAP NetWeaver and Complementary Products --> SAP NW LANDSC VIRT MGT ENT --> SAP NW LANDSC VIRT MGT ENT 2.0 --> Installation.

1.3   What is the install footprint for BW PCA?

The functionality of BW PCA is delivered via notes and support packages. However in order to use the
tool, you need a license key for LVM. This key is an add-on, so SAP is able to restrict access to the functionality.

1.4   What are the required SAP notes I have to implement?

To get a list of the notes required in ECC and BW, please follow the instruction mentioned in the  note http://service.sap.com/sap/support/notes/1707321 (for BW notes) and http://service.sap.com/sap/support/notes/1614266 (for basis notes) in all systems affected by BW PCA. Execute the note analyzer report attached to the note 1614266 and choose  the right option for the affected system to download and implement the needed notes. Lessons learned from customer that used BW PCA are, that you should execute this report with the latest XML file in ECC and BW immediately before starting your system copy procedure. That ensures that you have the latest developments / corrections in your systems.

1.5   I don’t copy the ERP system. Do I still have to install notes in the ECC?

There are currently several notes that need to be applied to your ECC systems. Which of those apply to your system, you can check out using the note analyzer report attached in note http://service.sap.com/sap/support/notes/1707321, choose the option “Post-Copy Automation requirements for BW source system that will not be copied”.

2.   Further information

2.1   Where within SAP do I find more information about BW PCA Initial Copy?

We have created an official SDN page regarding the BW PCA Initial Copy functionality with presentation material and details on which licenses are required, etc. Please visit http://scn.sap.com/docs/DOC-32414 For more info about the whole scope of BW PCA please visit the SCN page:http://scn.sap.com/docs/DOC-54097 (System Copy Automation for SAP Business Warehouse System Landscapes (BW PCA))

2.2  Are there any recorded sessions available

We have 2 recorded sessions that should provide an overview of the BW PCA Initial Copy procedure.

  1. German session: https://sap.emea.pgiconnect.com/p81522211/
  2. English session: http://scn.sap.com/docs/DOC-34256
  3. There is an RDS solution available. In case you want to make yourself familiar with it have a look at https://service.sap.com/rds-hana-bwmig.

2.3  Is there an RDS solution available?

There is an RDS solution available. In case you want to make yourself familiar with it have a look at https://service.sap.com/rds-hana-bwmig.

2.4  More practical infos :

3.   Impact of the cloning on ECC and BW

3.1   What happens to my ECC environment?

3.1.1   Do I have to lock ECC against data changes?

The cloning of the queues can happen without any implication to the operational processes in ECC. All Queues visible in transaction RSA7 get cloned and will be populated as soon as they are available. Existing queues are not influenced. Cloning means, we double the pointers for delta queues, not the data behind. The data is kept in ECC as long as the cloned BW system hasn’t picked up the deltas as well (growth of ARFCSDATA table). So please consider that in your overall planning as this phase of growing delta queues should be as short as possible.

3.1.2  Do I have to open the ECC for metadata changes?

If note 1855474 is implemented (it is part of aforementioned note analyzer list), then the source system doesn’t need to be changeable during the PCA procedure.

3.2  What happens during the cloning process and what are things I should consider:


The cloning of the queues can be divided into 2 phases.

  1. The whole procedure starts by executing the step “Clone delta queues in BW source system” with the task list
    SAP_BW_COPY_INITIAL_PREPARE in the original BW system. This step processes the queues of each configured BW source system that is connected to BW. The process clones the relevant queues in the underlying BW source system by creating the relevant entries in the metadata tables.
  2. In the step Synchronize delta queues in BW source system the task list has to synchronize the cloned queues with the
    original queues in the underlying BW source systems by processing the single queues sequentially. With recent feature improvement the synchronization procedure enables parallelization in different BW source systems to speed up the process. If you have created a large amount of LUWs in ECC between the clone step and the synchronization step, the runtime of this synchronization step can be significant long. In Pilot projects, we have seen runtimes of up to 5 hours. As a recommendation here you should empty the queues before cloning by getting deltas into BW. Furthermore you should keep the time between the clone step and the synchronization step as short as possible.

3.3  Which delta queues get cloned and which applications do not support BW PCA?

All delta queues which are visible in transaction RSA7 get cloned. However those extractors that developed an own change pointer management which can only deliver one single BW system will not be treated by BW PCA delta queue clone, i.e. though the cloning in RSA7 might appear ok, the DataSource can encounter errors during data load. This means those applications have to check whether there is a workaround possible (e.g. duplication of the datasource, own logic, etc.). The industry solution IS-H is such an example.

Please have a look at note http://service.sap.com/sap/support/notes/1932459 for unsupported data sources.

3.4  What should I consider once the delta queues get very large in between the single phases I am able to extract towards the connected BW?

If the delta queue got very large (e.g. during system copy and HANA Migration) you can use the parameter MAXPAK in the InfoPackage of a delta upload (->Scheduler –> Data Source Default Data Transfer) and configure the relevant parameter. See notes http://service.sap.com/sap/support/notes/1160555 and http://service.sap.com/sap/support/notes/1231922 for details.

3.5  What is the impact on the BW system?

3.5.1  Can I still load data and execute Queries?

After the cloning task has started, new delta initializations cannot be done anymore until the prepare task list is finished after the database export. When the queue synchronization phase has started (which can take a few hours in case of large delta queues) delta loads or initializations of deltas cannot be executed until the synchronization process is over, the BW database is exported and the prepare task list is finished. You can minimize the time needed for synchronization by following the advices given below in section “Runtime considerations”. Reporting on existing data is however still possible during that phase until the BW is shut down for database export.

3.5.2  Do I have to set the BW system to changeable?

If you have installed the latest version of the XML file of note http://service.sap.com/sap/support/notes/1707321 then the BW system does not have to be changeable during the PCA procedure.

4.  How to Use the Task Lists

4.1   What are the task lists I have to execute and in which system do I have to do that?

In the original BW you have to execute the task list SAP_BW_COPY_INITIAL_PREPARE. After you copied the system you execute the task list SAP_BW_BASIS_COPY_INITIAL_CONFIG in the copied system. For details on the procedure please check the configuration guide at http://service.sap.com/~sapidb/011000358700000368892013E

4.2  Should I continue the execution of the task list SAP_BW_COPY_INITIAL_PREPARE (i.e. after the step Confirm export) in the copied system?

No, the task list SAP_BW_COPY_INITIAL_PREPARE should only be executed in the original BW system. Please continue the task list after the step Confirm export in the original BW system using transaction STC02.

Don’t create a new execution of a task list (e.g. SAP_BW_COPY_INITIAL_PREPARE) via transaction STC01 while there is already an execution in process. Use transaction STC02 in order to resume the execution instead.

4.3  How should I execute the cloning step-by-step?

A good procedure in case you don’t use the Database Migration Option of Software Upgrade Manager (DMO of SUM) is the following:

  1. Extract all deltas in the original BW system using standard procedure. Some of our customers created an own Process Chain
    that includes all Delta InfoPackages and executed this Process Chain. Ideally you do this twice in order to also remove the data in the delta queue which is stored for possible delta repeat request.
  2. Clone delta queues by executing BW PCA task list SAP_BW_COPY_INITIAL_PREPARE in original BW system.
  3. Extract all deltas in the original BW system once more (is checked in the BW PCA procedure). Ideally you do this twice in
    order to also remove the data in the delta queue which is stored for possible delta repeat request.
  4. Synchronize delta queues by continuing BW PCA task list SAP_BW_COPY_INITIAL_PREPARE in original BW system.
  5. Export BW database and startup original BW followed by executing regularly tasks as you do it usual
  6. Resume the task list SAP_BW_COPY_INITIAL_PREPARE in transaction STC02 in the original BW
    system.
  7. Parallel you can import BW database to build a new cloned BW system.
  8. Extract deltas in cloned BW system twice (by using Process Chain from Step i))
  9. Optional upgrade cloned BW system to your target release.
  10. Extract deltas in your upgraded BW system twice (by using Process Chain from Step i))
  11. Migrate your database to SAP HANA
  12. Run post migration activities
  13. Extract and execute deltas in BW on HANA on a regularly basis

4.4  Are there further task list which are interesting for me?

BW Housekeeping task list can be applied prior to system copy and migration (see note http://service.sap.com/sap/support/notes/1829728).

5.   Runtime considerations

5.1   How long will the execution of the task list take in the original system

The cloning phase itself is quite fast. The synchronization phase will take longer, it was however parallelized and hence also won’t take days, especially if you follow the step by step procedure given above. It is however crucial, that the sync step doesn’t encounter failed delta data loads. These loads are already given as warning in the clone step, and will cause the sync step to halt in error in the check phase. You are then asked to repair these loads, and in case the only possible repair is to delete the initialization, then you are in trouble, because no changes to initializations are allowed anymore after the clone step. Most time in past projects has been spent with repairing old and outdated loads rather than the plain run time of the automated steps. For that reason make sure that all DataSources with active delta initialization do indeed work and have been loaded recently (cf step i. in the procedure outlined above). Run the SAP_BW_COPY_INITIAL_PREPARE in check mode first to detect potential problematic candidates and fix them before you run the task list in execution mode.

5.2  How long will the execution of the task list
take in the cloned system

Most long running steps like reconnect or TSPREFIX-Rename have recently been parallelized in the different BW source systems to speed up the process. We have seen that the runtime is sometimes determined by the runtime of BDLS, not so much for the initial copy (which this FAQ concentrates on), because usually only the BW system itself is renamed, but for refresh scenarios, where also the source systems are renamed. The BDLS runtime has been improved a lot recently within PCA. With parallelization of conversion jobs based on table entries, the runtime of BDLS especially for BW systems can be reduced significantly. For better planning and preparation of your project you should run the analysis report RBDLS_CHECK beforehand in your productive BW system to extract the relevant tables for conversion and get estimation about how to schedule the BDLS process. For more information look at the following links: 
http://scn.sap.com/docs/DOC-60122

https://scn.sap.com/docs/DOC-62597

/ BW on RDBMS system landscape?

In case you used the BW InfoObject 0LOGSYS in DSOs, InfoCubes or Masterdata objects, the runtime of BDLS can be significant. In that case consider to execute the procedure given in note http://service.sap.com/sap/support/notes/1894679

6.  Landscape considerations

6.1   Can we have a mixed BW on HANA

With help of BW PCA (delta queue cloning and initial copy configuration) you can copy a BW system which can then be upgraded and migrated to HANA. However it is not recommended to have a mixed system landscape (Dev, QA and prod) running on different databases. For more info please refer http://scn.sap.com/docs/DOC-41509 (page 25 ff.) SAP Note 1808450 - Homogenous system landscape for on BW-HANA

6.2  I want to upgrade/migrate my original system. Does PCA initial copy help me here?

You can use PCA initial copy to create a temporary synchronized copy of your original system which can be used by the end users during the time in which you upgrade / migrate your original system. After the original system is again productive, you can decommission the copied system.

6.3  Is the copied system synchronized in all aspects?

The cloning procedure covers only Service API extraction from ERP systems. ODP extraction is currently under development.

If you use DB Connect source systems, then the DBCON entries are copied as well, so you would extract the same data into either BW system. In case this is not desired, you would have to change the DBCON entries manually.

If you use WebService Push Data Load, then the remote WebService Systems will continue to send the data into the original BW only. In case it shall send
it to the new BW instead (or as well), the WebService System must be changed, eventually even by adopting the code of the Service.

If you load data into further (data mart) BW systems, then you have to decide, whether the Data Mart shall receive the data from the original or from
the new BW system or from both. If you chose to switch the delivery to the new BW, then you need to manually change the host in the RFC destinations of the DataMart system and execute BDLS there to point to the new BW. If you chose to receive data from both BW systems, you can connect the new BW system manually and use the data flow copy tool within the DataMart to copy the data flows which load from the original BW.

If you use planning tools, then the plan data will be stored in one BW only, depending on which one you execute the planning. The other system is not synchronized, except you use dedicated SLT features. Every other change not related to DataLoads, like e.g. workflow processes, are also not synchronized, but could be with specialized setup of SLT processes.

6.4  How long can both BW systems be maintained parallel?

If the restrictions given above are mitigated, then the systems can in principle be operated infinitely in parallel.

7.   Deletion / Undo of the Cloning

7.1    When the original BW is decommissioned, the original delta queues should not be filled anymore. What is the advised method of deleting these delta queues?

The easiest way to decommission the original BW system is to stop all loading processes followed by a deletion of source systems in the Administrator Workbench. The related delta queues of the source systems have to be deleted in RSA7 manually resp. with the report given in note http://service.sap.com/sap/support/notes/2014906.

7.2  Customer wants to decommission a BW source system or reset the cloned delta queues created by BW PCA and restart the configuration. What are the required steps?

Suppose you have a BW source system connection from a source system A to a BW system B. For this connection, delta is recorded. You want to delete the connection and the delta ecording. There are three cases to consider, for which we need to describe hat happens in BW system B and BW source system A when decommissioning the ystem.

7.2.1   Not even in source system A, an entry in table RSBASIDOC exists for BW system B

This is the case after elta queue cloning for PCA, when the new BW system B was not yet created and onnected to source system A.

You should copy the -Report attached to SAP note http://service.sap.com/sap/support/notes/2014906 to your source system A and execute it,
passing the logical system name of BW system B as input parameter.

This will cause the following changes in source ystem A:

  1. delete the ALE change pointer delta recording
    in table TBDA2. Delta is no longer recorded for those.
  2. delete the delta DataSources from RSA7
    belonging to BW system B. Delta is no longer recorded for those.

7.2.2  Within the BW system B, the source system A is visible n the Administrator Workbench.

In this case you have o delete the source system A from the administrator workbench in the source ystem tree in BW system B.

This will cause the following changes in BW system B:

  1. the entry for source system A in table SBASIDOC will be deleted
  2. all source system dependent metadata for system  will be deleted

This will cause the following changes in source system A:

  1. the entry for BW system B in table RSBASIDOC will be deleted
  2. all entries in table ROOSGEN for BW system B will be deleted
  3. the ALE change pointer delta recording is set to inactive in table TBDA2. The delta is no longer recorded for those. The entries of table TBDA2 are not deleted, as this is not required, as delta is no longer recorded.
  4. all delta DataSources in RSA7 of source system A pointing to BW system B appear as red. Nevertheless the delta is still recorded for those.

Therefore you have to copy the Z-report attached to SAP note http://service.sap.com/sap/support/notes/2014906to your source system A and execute it, passing system B as input parameter.

In the source system A following changes are caused by this report:

  • delete the ALE change pointer delta recording in table TBDA2. Delta is no longer recorded for those.
  • delete the delta DataSources from RSA7 belonging to BW system B. Delta is no longer recorded for those.

7.2.3  Within the BW system B the source System A is not visible in the Administrator Workbench or does not exist in the metadata tables of BW system B. But in source system A, in table RSBASIDOC, the entry for connection towards BW system B is still present.

In this case you have to execute function module RSAP_BIW_DISCONNECT in single test in source system A, passing the logical system name of BW system B as input parameter for the BW system, and the logical system name of source system A as input parameter for the OLTP-system. Do also set the FORCE_DELETE parameter to X.

This will cause the following changes in source system A:

  • the entry in table RSBASIDOC is deleted all entries in table ROOSGEN for BW system B are deleted
  • the ALE change pointer delta recording is set to inactive in table TBDA2. The delta is no longer recorded for those. The table entries are not deleted.
  • all delta DataSources in RSA7 of source system A pointing to BW system B appear as red. Nevertheless the delta is still recorded for those.

Therefore you have to copy the Z-report attached to SAP note 2014906 to your source system A and execute it, passing the logical system name of BW system B as input parameter.

In the source system A following changes are caused by this report:

  • delete the ALE change pointer delta recording in table TBDA2. Delta is no longer recorded for those.
  • delete the delta DataSources from RSA7 belonging to BW system B. Delta is no longer recorded for those.

7.3  Useful reports

We had a few customer situations in which the PCA procedure detected inconsistencies in already existing queues in the ECC environment. As this leads to a stop in the whole PCA procedure until the whole issue is fixed, we recommend to schedule the report RSC1_DIAGNOSIS in ECC, to check the consistency of the queues which should be cloned.

3 Comments
Labels in this area
Popular Blog Posts