SAP Netweaver Business Intelligence BI / BW » SAP Netweaver

SAPBINews NetWeaver BI 7.00 ABAP Support Package 20

admin — Fri, 24 Jul 2009 10:57:22 +0000

Symptom

Support Package 20 for BI Release 7.00
Other terms

SAPBWNEWS, Support Packages for 7.00, BW 7.00, BW Patches, BI, BI 7.00, SAPBINews, NW7.00, NetWeaver7.00, 7.0

Solution

This note contains the SAPBINews for Support Package 20 of BI Release 7.00. Here, you will find a list of all notes describing corrections or enhancements in Support Package 20. This note will be updated when other notes are added.
Note that BI 7.0 ABAP Support Package 20 is a part of SAP NW 7.0 Support Package Stack 18.
The information is divided into the following areas:
Manual actions that may be necessary:Factors you must take into account when you import the Support PackageErrors that may occur after you import the Support PackageGeneral information:Errors corrected by this Support Package; Enhancements delivered with this Support Package.See the release and information notes.

Factors you must take into account when you import the Support Package:
Before you import the Support Package, check your system for inactive objects.

Call transaction SE80, select “Inactive objects” and enter ‘*’ in the user field.
If information is displayed in the SAP namespace in the “Transportable Objects” section, you cannot import any Support Package.
You must first activate the inactive objects.
You can restart a terminated note installation consistently by using SNOTE consulting Note 1131831.
This activates the inactive objects. Do not delete inactive objects from the transport request.
Note that you are no longer allowed to delete objects from the transport request and doing so would cause extensive subsequent problems.
Note 822379 describes the correction procedure.

Find out about the latest SAP Notes that you also have to read and perhaps implement after you import Support Package 16.

Do not just indiscriminately implement all notes available after you import the corresponding Support Package. However, always implement “Hot News” and priority 1 notes.
In the search function in the notes database or on SAP Service Marketplace, use search term: “SAPKW70017″, and under “Search Criteria”, choose “Extended Search Criteria”; select “HotNews” and “Correction with high priority” as the “Priority”.
You can also restrict the search to a specific topic by entering the relevant specifications in the “Applic. Area” field, for example, “BW-WHM*”.

After you have imported a Support Package, you usuallymustuse transaction SNOTEto make further changes. Notes that have already been implemented may become inconsistent and may causefunctions to work incorrectly or syntax errors. Call transactionSNOTEandreimplementthe notes that have become inconsistent. When you have done this, your BW system is operative and consistent again.
Import the SNOTE corrections first and read the composite SAP Note 875986, which contains important notes about Note Assistant.
You should implement Notes 932065 and 948389 before you use transaction SNOTE to implement advance corrections. Otherwise, problems may occur when you try to deimplement notes again.
If documents have already been migrated to the portal, you may have to repeat the migration. For more information, see Note 950877.
If you have questions about downloading Support Package stacks, see Note 911032 ‘FAQ – SAP Support Package Stack Download’.
For minor revisions in the BI Accelerator, see Note 1079068.

Errors that may occur after you import the Support Package:

The elimination of internal business volume does not work for the elimination of all pairs of characteristics. Read Note 1275193.
The system issues error message RH 226 when you execute a query that uses time hierarchies. This is not a program error. The system simply carries out stricter checks that reveal this problem in the metadata of time characteristics. The long text for the error message describes how you can remove this error.

A user with limitied authorizations receives an exception in the class CL_RSR_RRK0_AUTHORIZATION, method AUTHORITY_02 for a query. For more information, see Note 1292293.

Errors corrected in this Support Package:
Errors corrected in the end user technology
If you use the same characteristic when generating query variables, too many numbers or numbers that are too large may be displayed when you have virtual InfoProviders (for example). For more information, see Note 1267220.
Errors corrected in the OLAP technology
Errors corrected in Warehouse Management
Extracting data from a DataStore object fails with the error message “Key figure unknown in InfoProvider “. This error occurs if the DataStore object serving as a source contains a referencing key figure.

Enhancements delivered with this Support Package:

Improvements to the end user technology
Improvements to the OLAP technology
Improvements to Warehouse Management

SAPBINews NW7.0 BI ABAP Support Package 21Symptom Support Package 21 for BI Release 7.00 Other terms...
Preliminary version of SAPBINews NW7.00 BI SP19Symptom Support Package 19 for BI Release 7.0 Other terms...
NW 7.01 SPS 04 Patch 3 note for BI JavaSymptom Support Package 04Patch 3of the BI Java component for...
NW 7.01 SPS 04 Patch 4 note for BI JavaSymptom Support Package 04Patch 4of the BI Java component for...
Prel vers SAPBINews NW7.0 BI Add-OnFrontend SP902 – GUI7.10Symptom Errors occur in Business Explorer components such as BEx...
BI 7.X Frontend SPPatch Delivery Schedule for BusinessByDSymptom This note describes availability and the production process of...
NW7.0 SPS 19 Patch 10 note for BI JavaSymptom Support Package 19Patch 10of the BI Java component for...
BI 7.X PreCalculation service delivery scheduleSymptom This note describes availability and the production process of...

System Landscape Copy for SAP NetWeaver BW

admin — Tue, 14 Jul 2009 13:05:00 +0000

Symptom

You want to copy a productive SAP solution landscape to create a non-productive system landscape for testing, quality assurance or other purposes. This copy scenario is referred to as “PRD to NPS”. Or you want to copy your productive landscape to a new productive landscape to change some property of the systems, like hardware, operating system or database. This copy scenario is referred to as “PRD to PRD”.
Since an SAP solution landscape often consists of multiple components that may or may not be based on NetWeaver, additional component-specific steps that are not described in the general System Copy Guide for SAP Web AS (Homogeneous and Heterogeneous System Copy for SAP Systems Based on SAP Web Application Server (ABAP or JAVA)) are required..
You can subscribe to this Note by adding an e-mail address to your profile. Go to -> http://service.sap.com -> MyProfile (in the header)
-> My personal data -> e-mail. To subscribe to this Note, click on the Subscribe link in the top line of the display. If the Note is changed, you will get an e-mail notification.

Other terms

System Copy, System Refresh, SAP BW

Reason and Prerequisites

In case you are still in the process of defining your SAP BW system landscape, please read note 184447 and its attachements first, which will give you background information on logical system naming in BW landscapes.
The common procedure for the system copy of an SAP Solution landscape is described in the SAP Best Practice “SAP System Landscape Copy for SAP NetWeaver and SAP Solutions”. Please see SAP Note 885343 for more information on that document.
This Note contains supplemental information for copying SAP BW 2.x, 3.x and SAP NetWeaver BW 7.x (formerly known as SAP NetWeaver BI). BW is used as an umbrella term for SAP BW and SAP NetWeaver BW. NetWeaver AS (application server) is used as an umbrella term for Web AS and NetWeaver AS.
The Best Practice document and this Note have a common structure. The procedure described in the Best Practice is divided into several phases and steps that need to be executed for the system copy. This Note only lists the steps of the main document requiring BW-specific information and leaves out the steps that do not need additional actions in a BW system.
When copying an SAP BW system or another SAP solution connected to the BW system, you should work in parallel with the Best Practice and this Note to perform the required system copy steps.
Phase 1: Preliminary Tasks
The Solution part of this Note provides BW-specific enhancements to the steps 1.1 and 1.2. The latter step describes 10 copy scenarios, from which you should choose the one closest to your scenario.Phase 2: Preparations in Target Environment
Only 1 of the 10 copy scenarios requires BW-specific preparations in the target environment before the copy.Phase 3: Preparations in Source (Original) Environment
No BW-specific preparations are required in the source (original) environment before the copy.Phase 4: Copy Process
No BW-specific action is required.Phase 5: Final Activities in Source (Original) Environment
No final BW-specific activities are required in the source (original) environment after the copy.Phase 6: Final Activities in Target Environment
All 10 copy scenarios require final BW-specific activities in the target environment after the copy.

Note: In contrast to the Best Practice, this Note uses the term “source system” for the systems that load data to a BW system. The term “original system” is used for the system that is the source of the database copy.

Solution

This section describes the specific steps to be executed in each phase as given in the Best Practice.
Phase 1: Preliminary Tasks
Step 1.1: Get required documentation
To copy an SAP BW system landscape, you need the following documentation:
Newest version of this SAP NoteSAP Best Practice “System Landscape Copy for SAP NetWeaver and SAP Solutions”, see SAP Note 885343.System Copy Guide for SAP Systems Based on SAP NetWeaver 7.x or the System Copy Guide for SAP Web AS (”Homogeneous and Heterogeneous System Copy for SAP Systems Based on SAP Web Application Server”) for the underlying Web AS release of your BW 2.x or 3.x systemThe following additional SAP Notes:121163 BDLS: Converting logical system names369758 BDLS: New functionality and better performance524554 Storing destinations in the BW environment184447 Building a BW-system landscapeFor Netweaver 7.0 (2004s) BI systems:961551 70SP09: BDLS: DTPs are not converted929045 Correction: No PSA-userobj conversion in BDLS931029 Transformations are not taken into account (BDLS)981248 Correction: Backup for system copy only for old objects1000062 70SP13: Conversion of the logical system name1048947 Corr:Source syst names,pseudo D versions for transformations1055483 Renaming system in RDA tables (BDLS)1059278 70SP15: Error in transaction BDLS1070378 Correction: Hard-coded source system in DataSource program1097357 7.0 Support Package 16: Transaction BDLS terminates1107155 70SP17: Transport after system copy1122853 P17: BDLS does not convert staus manager tables1135964 70SP17: BDLS with transport connection1139924 BI7.0(SP18): System names converted incorrectly1142908 70SP18: BDLS does not convert pseudo D versions1146596 Correction: DataSources remain after source system deleted1148403 70SP18: BDLS after early replication1149141 70SP18: BDLS: log improvements1156599 Correction: 3.x DataSources are not collected1168471 Correction:Collecting transformations using emulated DS1169659 Correction: Process variants not entered by BDLS1180016 P19:BDLS conversion of PSA text table of status manager1224597 P19:BDLS:DataSource not converted1227247 APD: Analysis processes ignored in transaction BDLS1330317 InfoPackages for DSs missing when collecting for system copyDetails about database-specific preparation and post-processing for heterogeneous system copies can be found in the following SAP Notes:771209 NW04: System copy (supplementary note)777024 BW3.0 and BW3.1 System Copy (supplementary note)

Step 1.2: Define a clear copy strategy

The following components belong to a SAP BW system landscape. Unless you are only refreshing an existing landscape copy, these components must be installed and configured in the target landscape:
BW server (SAP NetWeaver AS9
The BW server can be copied using a NetWeaver AS copy procedure. Alternatively you can reload the required data into the BW system after copying the systems serving as BW data sources.J2EE (as of BW 3.5)

Usually the above components have dependencies on the systems or solutions listed below. To ensure a consistent target landscape, consider copying these components together with the BW landscape. In this case you also need to execute the copy procedure specific to these components.
One or more source systems (SAP systems such as ERP, CRM, SEM, APO, other BW systems, or non-SAP systems) can be linked to a BW system.The BW system can be source system to one or more other systems (i. e. other BW, SEM or APO systems).

Keep data consistency between BW and all connected systems in mind. Check whether there are additional dependencies that need to be taken into consideration.

Copy Scenarios

Several copy scenarios are possible in a BW environment. Find the scenario that is closest to yours in the below list. This scenario specifies which steps need to be executed.
Scenario group A: You want to copy the whole system group, i.e. a BW system and all its connected source systems.
Scenario A1: You want to copy the entire system infrastructure connected by the BW source system connections (that means the entire system group). You want to replace a productive system group [PRD to PRD].Scenario A2: You want to copy the entire system infrastructure connected by the BW source system connections (that means the entire system group). You want to create a new non-productive system group or refresh an existing non-productive system group [PRD to NPS, installation or refresh]. If the whole system group is refreshed, the installation and refresh scenario do not differ, since all the systems are overwritten.

Scenario group B: You want to copy the BW system only; the source systems are not copied.
Scenario B1: You want to copy a single BW system of the group; the source system is not copied. You want to replace a productive BW system [PRD to PRD].Scenario B2: You want to copy a single BW system of the group; the source system is not copied. You want to create a new non-productive copy [PRD to NPS, installation].Scenario B3: You want to copy a single BW system of the group; the source system is not copied. You want to refresh an existing non-productive BW system by copying the source-system-independent objects from the productive BW system [PRD to NPS, refresh].Scenario B4: You want to copy a single BW client of the group; the source system is not copied. You want to create a new non-productive client [PRD to NPS, installation, client].

Scenario group C: You want to copy the source system only; the BW system is not copied.
Scenario C1: You want to copy a single source system of a BW system; the BW system is not copied. You want to replace a productive source system of a BW system [PRD to PRD].Scenario C2: You want to copy a single source system of a BW system; the BW system is not copied. You want to create a new non-productive source system (of an existing non-productive BW system) by copying the productive source system [PRD to NPS, installation].Scenario C3: You want to copy a single source system of a BW system; the BW system is not copied. You want to refresh an existing non-productive source system (of a non-productive BW system) by copying the productive source system [PRD to NPS, refresh].Scenario C4: You want to copy a single source system client of a BW system; the BW system is not copied. You want to create a new non-productive source system client (of an existing non-productive BW system) [PRD to NPS, installation, client] or refresh an existing source system client [PRD to NPS, refresh, client].

In the following descriptions, look for the copy phases that are valid for your scenario.
=====================================================================
Scenario A1
You want to copy the entire system infrastructure connected by the BW source system connections (the entire system group). You want to replace a productive system group [PRD to PRD].
Phase 3: Preparations in Source (Original) Environment
Step 3.3: Stop productive operation in the original BW system
SAP NetWeaver 7.0: Stop all daemons for real-time data acquisition in transaction RSRDA.SAP NetWeaver 7.2: Execute report RS_SYSTEM_SHUTDOWN to stop process chains and real-time data acquisition.

This has to be done before locking the RFC users and before stopping and disabling the other background jobs, e.g. by executing report BCTRANS1.
Phase 6: Final Activities in Target Environment
Step 6.4: Correct RFC destinations
Modify the RFC destinations. Change the hosts in the appropriate RFC destinations so that they refer to the correct system. See Note 524554.
Since SAP does not support the renaming of productive systems, step 6.7 “Execute Transaction BDLS if you want to rename a system” is omitted here.
Step 6.8: Perform BW-specific adaptations
The following steps are necessary when the host has been changed:
If you are using BI Planning, adjust the server name of the BI Enqueue Server in the administration transaction RSPLSE. For details, see Note 996238.Reset RFC destination for process chain transport postprocessing. Use transaction RSTPRFC to correct the host.If you are using a BW Accelerator, refer to SAP Note 1146983 for further instructions.

Step 6.16: Restart productive operation in the target BW system
SAP NetWeaver 7.0: Restart daemons for real-time data acquisition in transaction RSRDA.SAP NetWeaver 7.2: Execute report RS_SYSTEM_SHUTDOWN to restart process chains and real-time data acquisition.

This has to be done after unlocking the RFC users and after configuring the number of background work processes.
=====================================================================
Scenario A2
You want to copy the entire system infrastructure connected by the BW source system connections (the entire system group). You want to create a new non-productive system group or refresh an existing non-productive system group [PRD to NPS, installation or refresh]. If the whole system group is refreshed, the installation and refresh scenario do not differ since all systems are overwritten.
Phase 3: Preparations in Source (Original) Environment
Step 3.3: Stop productive operation in the original BW system
SAP NetWeaver 7.0: Stop all daemons for real-time data acquisition in transaction RSRDA.SAP NetWeaver 7.2: Execute report RS_SYSTEM_SHUTDOWN to stop process chains and real-time data acquisition.

This has to be done before locking the RFC users and before stopping and disabling the other background jobs, e.g. by executing report BCTRANS1.
Phase 5: Final Activities in Source (Original) Environment
Step 5.4: Restart productive operation in the original BW system
SAP NetWeaver 7.0: Restart daemons for real-time data acquisition in transaction RSRDA.SAP NetWeaver 7.2: Execute report RS_SYSTEM_SHUTDOWN to restart process chains and real-time data acquisition.

This has to be done after unlocking the RFC users but it should be done before restarting and enabling the other background jobs, e.g. by executing report BCTRANS2.
Phase 6: Final Activities in Target Environment
Step 6.4: Correct RFC destinations
Delete or modify the RFC destinations that point to the original systems. Ensure that an RFC destination exists with the new logical name (which will be assigned in step 6.7) in every connected BW or SAP source system. Change the hosts in the appropriate RFC destinations so that they refer to the correct system. See Note 524554.
Step 6.7: Execute Transaction BDLS if you want to rename a system
If you want to rename one or more of the copied systems, execute transaction BDLS both in the client you wish to rename and in all connected SAP source systems. No other activities (for example, execution of Administrator Workbench / Data Warehousing Workbench (RSA1)) can be performed in the system during conversion!
Read Notes 121163 and 369758 for details about transaction BDLS.
Step 6.8: Perform BW-specific adaptations
The following steps are necessary if the logical system name has been changed:
Execute the following task on the BW system and the SAP source systems.
Reactivate all partner profiles that contain the new logical system name after renaming. Execute transaction WE20 to reactivate the partner profiles. Choose “Partner type LS (logical system)”, enter the logical system name of the partner on tab “classification”, change the partner status from “I” (inactive) to “A” (active), and save.

Execute the following tasks on the BW system:
Update logical system descriptions in RSA1. For each SAP source system that was converted using BDLS, change the description to match the new logical system name.Reset generation flag for ODS activation programs. Call transaction RSSGPCLA and highlight program class RSDRO_ACTIVATE. Click #set status# and #OK#. Repeat for program class RSDRO_EXTRACT and RSDRO_UPDATEIf you are using a BW Accelerator, refer to SAP Note 1146983 for further instructions.

Execute the following step if the host has been changed:
If you are using BI Planning, adjust the server name of the BI Enqueue Server in the administration transaction RSPLSE. For details see Note 996238.Reset RFC destination for process chain transport postprocessing. Use transaction RSTPRFC to correct the host.

This has to be done before locking the RFC users and before stopping and disabling the other background jobs, e.g. by executing report BCTRANS1.
Phase 6: Final Activities in Target Environment
Step 6.4: Correct RFC destinations
Modify the RFC destinations. Change the hosts in the appropriate RFC destinations so that they refer to the correct system. See Note 524554.
Since SAP does not support the renaming of productive systems, step 6.7 “Execute Transaction BDLS if you want to rename a system” is omitted here.
Step 6.8: Perform BW-specific adaptations
The following steps are necessary if the host has been changed:
Adjust the table RSLOGSYSDEST for the RFC destinations of the SAP source systems and the myself system. This table contains the relationship between the logical system names and RFC destinations.If you are using BI Planning, adjust the server name of the BI Enqueue Server in the administration transaction RSPLSE. For details, see Note 996238.Reset RFC destination for process chain transport postprocessing. Use transaction RSTPRFC to correct the host.If you are using a BW Accelerator, refer to SAP Note 1146983 for further instructions.

This has to be done after unlocking the RFC users but it should be done before restarting and enabling the other background jobs, e.g. by executing report BCTRANS2.
Phase 6: Final Activities in Target Environment
Step 6.4: Delete source system assignments in the target BW after the copy
Directly after the copy, there is a connection between the target BW system and the source systems of the original BW system. Delete the source system connections of the target BW system without changing the source system connections in the original SAP source system.
In the target BW, change the contents of the “target host” field in all RFC destinations for SAP source systems to a non-existent address (transaction SM59). Caution: This step is very important, as otherwise the original source system will be changed!
Delete ALL SAP source systems in the RSA1 source system tree of the target BW system. Caution: This step deletes all transfer rules and PSA tables of these source systems, and the data is lost. A message is generated stating that the source system cannot be accessed (since you deleted the host of the RFC connection). Choose “Ignore”.
Delete all obsolete RFC destinations pointing to the original environment.
Step 6.7: Rename the target BW system and convert the logical system names
If you want to rename the copied system, execute transaction BDLS. No other activities (for example, execution of Administrator Workbench / Data Warehousing Workbench (RSA1)) can be performed in the system during conversion!
Read Notes 121163 and 369758 for details about transaction BDLS.
Step 6.8: Perform BW-specific adaptations
Perform the following steps if the logical system name has been changed:
Reset generation flag for ODS activation programs. Call transaction RSSGPCLA and select program class RSDRO_ACTIVATE. Click #set status# and #OK#. Repeat for program class RSDRO_EXTRACT and RSDRO_UPDATE

Perform the following steps if the host has been changed:
Adjust the table RSLOGSYSDEST for the RFC destinations of the SAP source systems and the myself system. This table contains the relationship between the logical system names and RFC destinations.If you are using BI Planning, adjust the server name of the BI Enqueue Server in the administration transaction RSPLSE. For details see Note 996238.Reset RFC destination for process chain transport postprocessing. Use transaction RSTPRFC to correct the host.If you are using a BW Accelerator, refer to SAP Note 1146983 for further instructions.

This has to be done after unlocking the RFC users and after configuring the number of background work processes.
=====================================================================
Scenario B3
You want to copy a single BW system of the group; the source system is not copied. You want to refresh an existing non-productive BW system by copying the source-system-independent objects from the productive BW system [PRD to NPS, refresh].
Remark:As a consultant, you may also read note 1333302, which describes a simplified copy scenario for special system landscapes.
Phase 2: Preparations in Target Environment
Step 2.1: Save source-system-dependent objects
Create a special transport with the source-system-dependent objects (transfer structures, InfoPackages, …) in the transport connection of the target BW system to be overwritten (transport collector -> grouping: system copy) for each SAP source system. In the area “Source System Assignments”, select the source systems for which you want to collect the source-system-dependent objects. Select all collected objects, even if some are not selected by default.
Caution: We recommend that you have a look at the object list of the transport to make sure that it contains all necessary objects. If this transport is inconsistent, the source-system-dependent objects are lost when the target BW system is overwritten. Do not forget to release the transport before the copy.
Remark: This transport request can also be created in the copied BW system after replacement by the productive BW (before step 6.4).
If the source system of the productive BW and the source system of the target BW deliver the very same datasources, this does not make a difference. However…
… if the source system of the target BW delivers additional datasources, the corresponding transformations would be lost.
… if the source system of the productive BW delivers additional datasources, this would lead to import errors later.
Step 2.3: Delete source-system-assignments in the target BW system before the copy
In the target BW system to be overwritten, delete all SAP source systems in the Administrator Workbench / Data Warehousing Workbench (RSA1). DO NOT delete the myself system!
This step is necessary to delete all source-system-dependent objects from the source system (the objects of the old source system connection would interfere with the new source system connection, which will be created after the copy).
Phase 3: Preparations in Source (Original) Environment
Step 3.3: Stop productive operation in the original BW system
SAP NetWeaver 7.0: Stop all daemons for real-time data acquisition in transaction RSRDA.SAP NetWeaver 7.2: Execute report RS_SYSTEM_SHUTDOWN to stop process chains and real-time data acquisition.

This has to be done after unlocking the RFC users but it should be done before restarting and enabling the other background jobs, e.g. by executing report BCTRANS2.
Phase 6: Final Activities in Target Environment
Step 6.4: Delete source system assignments in the target BW system after the copy
Directly after the copy, there is a connection between the target BW system and the source systems of the original BW system. Delete the source system connections of the target BW system without changing the source system connections in the original SAP source system.
In the target BW system, change the contents of the “target host” field in all RFC destinations for SAP source systems to a non-existent address (transaction SM59). Caution: This step is very important, as otherwise the original source system is changed!
Delete ALL SAP source systems in the RSA1 source system tree of the target BW system. Caution: This step deletes all transfer rules and PSA tables of these source systems, and the data is lost. A message is generated stating that the source system cannot be accessed (since you deleted the host of the RFC connection). Choose “Ignore”.
Delete all obsolete RFC destinations pointing to the original environment.
Step 6.7: Rename the target BW system and convert the logical system names
Assign the name assigned to it before it was overwritten with the productive BW system (logical system name, table T000) to the target BW system. Use transaction BDLS to convert the logical system name in all the relevant tables. No other activities (for example, execution of Administrator Workbench / Data Warehousing Workbench (RSA1)) can be performed in the system during conversion!
Read Notes 121163 and 369758 for details about transaction BDLS.
Step 6.8: Perform BW-specific adaptations
Connect the source systems that were connected to the target BW system before it was overwritten. Use the Administrator Workbench / Data Warehousing Workbench (RSA1), right mouse click on Source Systems and choose Create. In NetWeaver 7.x (2004s or higher) systems, do NOT replicate the DataSources.
Perform the following steps if the logical system name has been changed:
Update logical system descriptions in RSA1. For each SAP source system that was converted using BDLS, change the description to match the new logical system name.Reset generation flag for ODS activation programs. Call transaction RSSGPCLA and select program class RSDRO_ACTIVATE. Click #set status# and #OK#. Repeat for program class RSDRO_EXTRACT and RSDRO_UPDATE.

Step 6.9: Import the transport with the source-system-dependent objects
Import the transport request created before the system copy.
Do not forget to adjust RSLOGSYSMAP. This table is maintained in the target system of a transport and provides a mapping for the transport of source-system-dependent objects in BW systems. This means that it maps the source-system-dependent objects of R/3DEV to R/3PROD.
Step 6.16: Restart productive operation in the target BW system
SAP NetWeaver 7.0: Restart daemons for real-time data acquisition in transaction RSRDA.SAP NetWeaver 7.2: Execute report RS_SYSTEM_SHUTDOWN to restart process chains and real-time data acquisition.

This has to be done after unlocking the RFC users but it should be done before restarting and enabling the other background jobs, e.g. by executing report BCTRANS2.
Phase 6: Final Activities in Target Environment
Step 6.7: Rename the target client and convert the logical system names
Assign a new name to the target BW client (logical system name, table T000). Use transaction BDLS to convert the logical system name in all the relevant tables. No other activities (for example, execution of Administrator Workbench / Data Warehousing Workbench (RSA1)) can be performed in the system during conversion!
Ensure that you select the (non-default) option “Conversion of client-specific tables (e.g. after a client copy)” in transaction BDLS. You must not convert client-independent tables under any circumstances! If you cannot select this option, you are using an obsolete version of transaction BDLS. Get the latest patch for the transaction!
Read Notes 121163 and 369758 for details about transaction BDLS.
Step 6.8: Perform BW-specific adaptations
The newly created client is not a BW client, i.e it cannot be used to start the Administrator Workbench / DataWarehousing Workbench (RSA1) and load data. It is not connected to any BW source system and, as a result, no BW-specific activities are necessary in this step.
Step 6.16: Restart productive operation in the target BW system
SAP NetWeaver 7.0: Restart daemons for real-time data acquisition in transaction RSRDA.SAP NetWeaver 7.2: Execute report RS_SYSTEM_SHUTDOWN to restart process chains and real-time data acquisition.

Note: Do not delete the RFC destination between the target SAP source system and the productive BW system! The system needs the destination during the deletion to obtain metadata information from the productive BW system (only a read access).
Execute function module RSAP_BIW_DISCONNECT in the copied target SAP source system using the following parameters:
I_BIW_LOGSYS = I_OLTP_LOGSYS = I_FORCE_DELETE = ‘X’

This step deletes all obsolete BW connections. Repeat this step for all entries in table RSBASIDOC.
Caution: DO NOT enter a value in the field “RFC target sys”. This would cause the function module to run in the system specified there!
Step 6.7: Rename the target SAP source system and convert the logical system names
If you want to rename the copied system, execute transaction BDLS. You cannot perform any other activities in the system during conversion!
Read Notes 121163 and 369758 for details about transaction BDLS.
=====================================================================
Scenario C3
You want to copy a single source system of a BW system; the BW system is not copied. You want to refresh an existing non-productive source system (of a non-productive BW system) by copying the productive source system [PRD to NPS, refresh].
Phase 6: Final Activities in Target Environment
Step 6.4: Delete copied source system assignments
Directly after the copy, there is a connection between the copied SAP source system and the original (productive) BW. Delete the source system connections of the copied SAP source system without changing the source system connections between the original BW and SAP source system connection by executing following procedure:
Check table RSBASIDOC in the newly copied target SAP source system to determine all existing source system connections.
If the table is empty, you do not have to execute function module RSAP_BIW_DISCONNECT.If entries exist, note down all these entries: fields RLOGSYS and SLOGSYS.

This step deletes all obsolete BW connections. Repeat this step for all entries in table RSBASIDOC.
Caution: DO NOT enter a value in the field “RFC target sys”. This would cause the function module to run in the system specified there!
In the copied source system: Delete all obsolete RFC destinations pointing to the original environment.
Step 6.7: Rename the target SAP source system and convert the logical system names
Assign the name assigned to the overwritten SAP source system (logical system name, table T000) to the target SAP source system. Use transaction BDLS to convert the logical system name in all the relevant tables. No other activities can be performed in the system during conversion.
Read Notes 121163 and 369758 for details about transaction BDLS.
Step 6.8: Perform BW-specific adaptations
Restore the source system connection in the BW system connected to the overwritten SAP source system
Start the Administrator Workbench / Data Warehousing Workbench (RSA1), right mouse click on the source system, and choose Restore.
Repair the delta queue
In the BW system: Execute report RSSM_OLTP_INIT_DELTA_UPDATE for each datasource, which has an active init request. Provide the field ‘ALWAYS’ with value ‘X’.
This will push the init / delta information of the BW into the source system, thus allows to continue loading delta or to do a new init.
=====================================================================
Scenario C4
You want to copy a single source system client of a BW system; the BW system is not copied. You want to create a new non-productive source system client (of an existing non-productive BW system) [PRD to NPS, installation, client] or refresh an existing source system client [PRD to NPS, refresh, client].
Phase 6: Final Activities in Target Environment
Step 6.7: Rename the target SAP source system and convert the logical system names
Assign the name assigned to the overwritten SAP source system client (logical system name, table T000) to the target SAP source system client. If the client created by the copy is a new client, choose a new name. Use transaction BDLS to convert the logical system name in all the relevant tables. No other activities can be performed in the system during conversion.
Ensure that you select the (non-default) option “Conversion of client-specific tables (e.g. after a client copy)” in transaction BDLS. You must not convert client-independent tables under any circumstances! If you cannot select this option, you are using an obsolete version of transaction BDLS. Get the current patch for the transaction!
Read Notes 121163 and 369758 for details about transaction BDLS.

SAPBINews NetWeaver BI 7.00 ABAP Support Package 20Symptom Support Package 20 for BI Release 7.00 Other terms...
NW 7.01 SPS 04 Patch 3 note for BI JavaSymptom Support Package 04Patch 3of the BI Java component for...
NetWeaver 7.0/7.10: System copy (supplementary note)Symptom This note contains additions to the guidelines. Other terms...
BI 7.X precalculation service – First Customer ShipmentSymptom This note is intended to help how to upgrade...
BI 7.X precalculation service – SP901Symptom This note is intended to help how to upgrade...
SAP System Installation ProblemsSymptom Customer is having an error or problem when trying...
NW 7.01 SPS 04 Patch 4 note for BI JavaSymptom Support Package 04Patch 4of the BI Java component for...
SAPBINews NW7.0 BI ABAP Support Package 21Symptom Support Package 21 for BI Release 7.00 Other terms...

NetWeaver 7.0/7.10: System copy (supplementary note)

admin — Mon, 29 Jun 2009 00:54:13 +0000

Symptom

This note contains additions to the guidelines.
Other terms

Partitioned tables, bitmap indexes, clustered indexes, encoded vector index (EVI), UMG_POOL_TABLE, performance during activation of transfer rule (control indicator L_PSAVER)
Reason and Prerequisites

You want to copy an NetWeaver system homogeneously or heterogeneously using R3load.
A heterogeneous database migration to INFORMIX is not supported.
Solution

Contents
——1. General prerequisites for SAP kernel WEB AS 7.02. Tasks before the export3. Tasks after the export4. Tasks after the import5. Special notes for Database Platform DB26. Special notes for Database Platform DB47. Special notes for Database Platform DB68. Special notes for Database Platform MSSQL9. Special notes for Database Platform MAXDB10. Special notes for the ORACLE Database Platform
1. General prerequisites for SAP kernel WEB AS 7.0
—————————————————-
Prerequisite for the homogeneous or heterogeneous system copy when you do not change the database platform: Ensure that your system meets the following requirements: R3load, R3sychk, BW 7.0, BASIS 7.0 patch level 7. Ensure that you use the new tools (R3load, R3szchk) both in the source system when you export the data and in the target system when you import the data.
Irrespective of these minimal requirements, SAP recommends that you import the current Support Packages since the development is updated constantly.
CAUTION: Since possible program errors have been corrected over time and continue to be corrected, we recommend that you always import the most current Support Package for basis and also for BW.
2. Tasks before the export
———————–
Start program SMIGR_CREATE_DDL before you export data from the source system. You can use this program to copy database objects that do not correspond to SAP standard system. These objects contain partitioned (fragmented) tables and bitmap indexes. Specific files of type .SQL are generated for these objects. These files contain native DLL (create) statements and can be analyzed using R3load. Proceed as follows:Log on to the productive BW client as a user with SAP_ALL rights.Call program SMIGR_CREATE_DDL in transaction SE38.Select the database platform and the database version of your target system.Set the ‘Unicode migration’ indicator if your target system is an SAP Unicode system.Specify a directory for the ‘.SQL’ files to be generated. (If this directory is blank after the program has run, there are no tables in the system that must be treated as BW-specific. This is the case if BW is not operated actively in the system. This note is then no longer relevant and you can proceed in accordance with the standard guidelines.)Execute program ‘SMIGR_CREATE_DDL’. The system now generates the DDL statements and writes them to the specified directory.You must ensure that no further changes (such as, activations, data loads to cubes or field changes) are carried out in the BW system after you call report SMIGR_CREATE_DDL and before you export the data. The best way to do this is to call this report directly before you export the data while the system is locked for the user.

If there are problems with the temporary tables during the test import, you can use the report SAP_DROP_TMPTABLES before the export (see Note 1139396). This report deletes all temporary tables. However, this temporarily affects the performance of the queries in the source system.3. Tasks after the export
————————
Before you import the data, copy the generated DDL files of type to the export directory of the target system. The export directory for pure ABAP systems is /DB/. The export directory for double-stack systems (ABAP and JAVA) is /ABAP/DB/. This is the only option for R3load to evaluate these specific files.4. Tasks after the import
————————
After the import has been carried out successfully, you must run report RS_BW_POST_MIGRATION.
See Notes 1077644 and 948780, before you run report RS_BW_POST_MIGRATION.
Before you run report RS_BW_POST_MIGRATION, connect all source systems to the migrated BW system. This is required to ensure that new versions of all PSA (Persistent Staging Area) tables are migrated. Furthermore, you must ensure that all connected SAP systems are active while program RS_BW_POST_MIGRATION is running. Depending on whether or not you have changed the database platform, you must run report RS_BW_POST_MIGRATION with another variant in the background. The program must run in the background so that the spool log remains available. When you do so, DB2 on zOS, DB2 on AS400 and DB2 on UNIX/NT are treated as three different database platforms.
If you have changed the database platform, use variant &POSTMGRDB. If you have NOT changed the database platform, use variant &POSTMGR. Program RS_BW_POST_MIGRATION carries out all necessary adjustments after the system copy. This includes adjusting the database-specific ABAP Dictionary entries (modify, delete, enhance), invalidating database-specific (generated) programs, deleting temporary objects from specific LRU buffers, migrating more recent versions for the PSA tables and adjusting table DBDIFF. The runtime of the program may be a few hours.
Note 1149665 adds new parameters (described in detail below) to optimize the performance during the “PSA Tables” processing step (control indicator L_PSAVER):L_TI_LT (time stamp format: yy.yym.mdd.hhm.mss
yyyy = year
mm = month
dd = day
hh = hours
mm = minutes
ss = seconds
For example 20.080.325.150.813)
If this parameter is set, only transfer rules that were last activated before the time stamp are taken into account. This parameter is very useful if the L_PSAVER processing step has terminated. When the time stamp L_TI_GT is chosen properly, the processing step can be restarted from the place where it terminated.
Table RSTS can be used to determine the time stamp. It may also be possible to use the user (field TSTPNM) or the last time of activation (field TIMESTMP) to add the value from the field TIMESTMP to the parameter L_TI_LT.
L_TI_GT (time stamp format: yy.yym.mdd.hhm.mss)
If this parameter is set, only transfer rules that were last activated after the time stamp are taken into account. These parameters can be used to exclude transfer rules that are no longer used from processing. To determine a suitable time stamp, you can use the last change date of the Persistent Staging Area template RSTMPL81:
Call transaction SE38 for the program RSTMPL81.
Choose the “Utilities” menu followed by “Versions” then
-> “Version management”. The date and time of the active
version is the required time stamp.L_SRCSYS (Select option for source systems)
This parameter can be used to restrict processing to certain source systems.
5. Special Database Platform DB2
——————————–6. Special database platform DB4
——————————–Also use the “Installation Guide” specific to the platform and product. You can find the Installation Guide on the SAP Service Marketplace.For the migration you can use any installation master DVD for Release 7.00 or 7.10 on the IBM system i.See Note 744735, which provides an overview of special features of the migration with target platform DB2 UDB for system i (DB2/400).
Due to their considerable performance advantages, pay particular attention to the “iSeries InPlace Unicode conversion” for homogeneous Latin-1 migrations.Note 782993 describes how, when you execute a homogenous migration of an SAP product to DB2/400, Basis Release 6.20 and higher, you can change the storage parameters of database objects (such as tables and indexes) without causing any additional downtime.Heterogeneous system copy to target DB2/400 or platform-specific actions after the import:
Secondary indexes of BW fact tables are not created automatically at the time of the heterogeneous system copy with the target platform IBM iSeries (DB4). After you have executed program ‘RS_BW_POST_MIGRATION’ as described above, proceed as follows if you want to migrate a BW system or a system based on BW (SEM, SCM/APO):For performance reasons, when you are later using BW systems, we strongly recommend that you set up the EVI stage 2 support as outlined in Note 501572 However, do not start programs ‘SAP_INFOCUBE_INDEXES_CHG_DB4′ and ‘SAP_INFOCUBE_INDEXES_REPAIR’ that are described in the note.The next step is to set up the entire secondary database indexes of the BW fact tables. This procedure can run in parallel if you use Symmetric Multi Processing (SMP). SMP is an additional product for DB2/400. If you operate SMP you must implement Note 601110 in your system, so that the BW indexes can be set up in parallel.You can now use program ‘SAP_SANITY_CHECK_DB4′ to check the settings for the EVI stage 2 support and to check the usage of SMP. See Note 541508 for more detailed information.If you decide to activate the SMP, you must set up the missing indexes. To do this, start program ‘SAP_INFOCUBE_INDEXES_REPAIR’ in the background.

7. Special Database Platform DB2 for LUW (DB6)
———————————————-Possible performance problem when loading data to MDC tables with the LOAD utility:
Under certain circumstances, loading data to tables that use MDC may take longer than a “LOAD” to non-MDC tables.
This problem occurs under the following conditions:You have defined MDC on the target table.You have chosen “LOAD” as the method for loading data to the MDC table.The input data for the table is not sorted according to MDC columns, for example, if the data is sorted according to the primary key but the MDC columns are not the first columns in the primary key.
Solution: To improve the LOAD performance of unsorted data in MDC tables, increase the value of the database configuration parameter “UTIL_HEAP_SZ” to approximately 250,000 4 KB pages.
Also set the value of the “DATA BUFFER” parameter for the “LOAD Utility” to at least 200,000 4 KB pages. Note that you cannot start multiple R3load processes with these settings because the available utility heap is already completely used for the “DATA BUFFER” of the first process.
If you use the R3load utility (which calls a CLI version of the “LOAD”), you can set the shell environment variable DB6LOAD_DATA_BUFFER_SIZE to the required “DATA BUFFER” value (approx. 200,000 pages). R3load will then transfer the value from the environment variable to the “LOAD Utility”. See Note 454173 for more information about the environment variable DB6LOAD_DATA_BUFFER_SIZE.
The performance problem mentioned above doesnotoccur if the input data for an MDC table is sorted according to the MDC columns or the target table for loading data does not have MDC.Important information about multidimensional clustering (MDC) tables:If you use DB2 Version 9.1 up to and including FixPak 4, you cannot use DB2 LOAD to load MDC tables while using the row compression feature. In this case, data may be corrupted as described in DB2 APAR IZ21943. FixPak 5 solves the problem.We recommend that you use INSERT instead of LOAD.If you migrate to a DB6 database with several DPF partitions and you want to compress tables directly while loading the data, you must refer to Note 1156514 (DB6: Possible data loss during system copy of SAP BI).Important corrections:Implement Note 919530 if you are using a Support Package level lower than SAP BASIS 7.00 Support Package 08. Otherwise, errors may occur when you activate BW objects in the target system. Implement this note in the source system.Implement Note 1060114 if you are using a Support Package level lower than SAP BASIS 7.00 Support Package 13. Otherwise, the Data Definition Language (DDL) for write-optimized DataStore object tables is generated incorrectly. Implement this note in the source system.Implement Note 1010353 if you are using a Support Package level lower than SAP BW 7.00 Support Package 13 and DB2 V8.1. The DDL generated with SMIGR_CREATE_DDL contains ‘COMPRESS NO’, which leads to a syntax error in DB2 V8.1. This problem does not occur for DB2 V9. Implement this note in the source system.Implement Note 1049456 if you are using a Support Package level lower than SAP BW 7.00 Support Package 14. P indexes on F fact tables are optional in SAP BW 7.00. DBDIFF entries are generated for the P indexes in report RS_BW_POST_MIGRATION even if they do not exist. Due to the entries in DBDIFF, missing P indexes on F fact tables are displayed in transaction DB02. The corrections contained in this note ensure that a DBDIFF entry is made only for existing indexes.By default, range partitioned InfoCubes in the source system are not migrated to MDC in the DB6 target system. If you have range partitioned InfoCubes in the source system, you must implement Note 1062348 in the target system. If you do not implement this note, errors occur when you activate these InfoCubes and inconsistencies occur in the BW metadata with reference to partitioning. Note 1023410 (SAP BW 7.00 Support Package 12 and SAP BASIS 7.00 Support Package 13) allows you to convert range partitioned InfoCubes to MDC. This activation problem does not occur then.Note 1167138 corrects the error where the program SMIGR_CREATE_DDL does not add COMPRESS YES to CREATE TABLE statements, even if the RSADMIN parameter DB6_ROW_COMPRESSION is set to YES. This correction is provided in Support Package 17 for SAP BASIS 7.00.Use of multidimensional clustering (MDC)
SAP BW 7.00 supports DB2 multidimensional clustering for InfoCubes, DataStore objects and Persistent Staging Area (PSA) tables. Take the following points into account when migrating to DB6:Note 1023410 allows you to convert range partitioned InfoCubes in the source system to MDC on the partitioning time characteristic in the DB6 target system. The package dimension is also selected as an MDC dimension for the F fact table. Proceed as described in the note when you call SMIGR_CREATE_DDL to generate the DDL with MDC.If you want to convert range partitioned InfoCubes to MDC, you must implement Note 1150148 as well as Note 1023410. If you do not implement this note, the BW metadata of the InfoCubes does not display that the InfoCube uses MDC after the migration.SAP BW 7.00 Support Package 10 changes the default for the use of MDC for PSA and the DataStore activation queue and change log tables from YES to NO (see Note 971135 for more information). Report SMIGR_CREATE_DDL generates the DDL for DataStore and PSA tables in accordance with this default. That is, up to and including SAP BW 7.00 Support Package 09, DDL for PSA and the DataStore activation queue and change log tables are generated by default on the REQUEST or SID columns. As of SAP BW 7.00 Support Package 10, MDC is no longer generated by default. MDC has potential performance advantages when loading and deleting data. However, it is also limited in that no online reorganization for MDC tables is possible. You can use the RSADMIN parameter DB6_MDC_FOR_PSA to control MDC for PSA and the DataStore activation queue and change log tables directly. If you set the parameter in the system to YES before calling SMIGR_CREATE_DDL, DDL will always be generated with MDC. If you set the parameter to NO, DDL will always be generated without MDC.
For more information about MDC, refer to the manual “SAP NetWeaver 7.0 and higher Business Intelligence – Administration Tasks: IBM DB2 Universal Database for Linux, UNIX, and Windows” on SAP Service Marketplace under:
http://service.sap.com/instguidesnw70 -> Operations ->?Database-Specific Guides

8. Special Database Platform MSSQL
———————————-If you migrate to SQL Server 2005, you must manually activate partitioning before you use your BW system. You do not require to activate it for migrations of systems external to BW.
You can perform the partitioning using RSADMIN parameter MSS_FORCE_PARTITIONING_ON. Note 869407 describes how to activate this parameter.
In addition, you must implement Notes962124, 996263 and 1010854if you migrate to SQL 2005 (from any database platform or from SQL Server 2000).If you migrate from the ORACLE database platform (on which the partitioning may have been used), you must ensure that there are no more than 999 partitions in all partitioned ORACLE tables. If F fact tables have more than 999 partitions, you must first condense your cube so that the F fact tables do not contain more than 999 partitions.
You can use the following query on your ORACLE database to check in sqlplus if tables with more than 999 partitions exist:
select table_name from user_part_tables
where partition_count >= 1000 and table_name like ‘/%’As of Basis Support Package 06 (SAPKB70006), this restriction is obsolete. Theoretically, you can now process 1.000 or more partitions for each database object during the migration.If you migrate from ORACLE, DB2, AS400 or INFORMIX to SQL Server (SQL 2000 or SQL 2005), implement Notes962124, 965695and996263if they are required for your release (lower than Basis Support Package 11 for NetWeaver 04). These notes are relevant for a correct partitioning layout and correct P indexes on the E fact table and the F fact table.If you migrate from SQL Server 2005 to an SQL Server 2005 release, we recommend that you use system copy function sp_attach_db/spdetach_db (see Note 151603).
If you must perform a migration using our migration process (for example, Unicode migration), you must at least import Basis Support Package 9 for NetWeaver 04s (Support Package 18 for NetWeaver 04).
Otherwise, the system does not partition your table in your target system.If you migrate from SQL Server 2000 to SQL Server 2000 or SQL Server 2005, implement Notes961591, 962124and996263. This way, you avoid creating a duplicate non-cluster primary index during the import. These notes describe how to avoid such duplicate index errors.If you do not choose a target release for SQL Server in report SMIGR_CREATE_DDL, the system uses Server 2000 as the default.
If you want to migrate to SQL Server 2005, you must choose SQL Server 2005 from the input help.9. Special Database Platform MAXDB
———————————-If you perform a system copy or migration using the Unicode conversion on MaxDB-based systems, implement Note 1002250 during the export preparation.If problems occur during the import while report UMG_POOL_TABLE is running, see Note 1002250.A correction in Basis Support Package 6 (SAPKB70006) prevents that incorrect SQL commands for creating indexes are generated in SMIGR_CREATE_DDL. See Note 896023.To support MaxDB clustering, implement Notes 1020006 and 1095135 in the source system before SMIGR_CREATE_DDL is executed.Note 1014782 comprises general questions and answers about MaxDB/liveCache system copy.10. Special ORACLE Database Platform
———————————–
Implement Note 925309.
Program SMIGR_CREATE_DDL
You do not have to specify a database version.
When you make a homogeneous or heterogeneous system copy without changing the database platform, the necessary information about generating DDL statements is read directly from the system catalog. To do this, the system checks all database objects to see if the memory parameters differ from the parameters in the standard system. This applies, for example, to partitioned tables and bitmap indexes. Note 519407 describes how you can accelerate processing during the DDL generation. Ensure that the cubes are correctly condensed (see Notes 407260 and 5900370) so that your system performance is optimal.

See Note 813562 if you use ASSM on your Oracle database.

System Landscape Copy for SAP NetWeaver BWSymptom You want to copy a productive SAP solution landscape...
SAPBINews NetWeaver BI 7.00 ABAP Support Package 20Symptom Support Package 20 for BI Release 7.00 Other terms...