Reorganization of TemSe and Spool

In your R/3 system, you have found an inconsistency in the spool database or in the database for temporary sequential objects (TemSe).

There can be many different causes. For example, inconsistencies can occur if you delete table entries manually from the spool and TemSe tables, delete spool and TemSe objects from the file system or do not carry out the consistency checks correctly. Terminations of the report and transactions also cause these inconsistencies. An incorrectly executed client transport can also lead to inconsistencies in the TemSe and spool.
Inconsistencies do not 'just appear'. They always have concrete causes. However, in many cases it is impossible to determine these causes after they have occurred.
A precise analysis is generally only possible if you have a reproducible example. The following sections will therefore only describe how to detect and eliminate inconsistencies.

Definition of the term TemSe:
Some objects, which are normally not retained in the system for a long time, are stored in the temporary sequential objects (TemSe) data storage.
These are:

        1. Spool requests (TemSe name: Spool.......)

        2. Job logs (TemSe name: JOBLG........)

        3. Objects from other applications, for example Human Resources (TemSe name: HR.......), Financial Accounting - data medium exchange (TemSe name: DTA...)

        4. An object beginning with KONS. This object is regularly used by report RSPO1043 and should never be deleted (Note 98065).

        5. If the new log procedure is used for batch input (Note 175596), the batch input logs (TemSe Name:  BDC....).


Each TemSe object consists of a header entry in table TST01 and the actual object. It can be stored in the file system (always the case for job logs) or in table TST03 (always for HR data). In the case of spool entries, you can use a parameter to decide whether the object is stored in the file system or in table TST03 (default setting, see Note 20176). Spool requests also have entries in table TSP01 (header entries for the spool request) and possibly in table TSP02 (header entries for possible output requests).
With data medium exchange objects from Financial Accounting, you can determine whether the object is stored in TST03 or in the file system for the relevant runs (in the latter case, there is no header entry in TST01 so the object is no longer a TemSe object. You can use transaction FDTA to manage the objects). For more information about DTA objects and how to manage them, refer to the section on data medium exchange in the Accounts Receivable and Accounts Payable Accounting chapters in the online documentation (see also Note 15960).

NOTE:
TemSe cannot manage any objects larger than 2 GB, indepent of whether the object is stored in the database or at file system level. Particularly with spool orders, you need to divide them into several smaller ones.
Since spool orders larger than 2 GB cannot practically be handled, this restriction will not be changed.
Solution

    1. Check memory distribution in the TemSe data storage.

    -> Tools -> Administration
        -> Spool -> TemSe Administration (transaction SP12)
            -> TemSe database -> Memory allocation
    (as of Release 4.0A: -> Tools -> CCMS -> Spool -> TemSe Data Storage (transaction SP12))
            -> TemSe Data Storage -> Memory allocation


Here, you can check the distribution of your TemSe objects by age, client and creator. In this context, you should refer to Note 11070. Check whether the number of your TemSe objects is very large and whether many of your objects are stored with an unlimited retention period.

NOTE:
You cannot see the retention period of spool requests here: it is stored in table TSP01 and can be read from the header data for the spool request (transaction SP01).

NOTE THAT TEMSE IS NOT AN ARCHIVING SYSTEM
Furthermore, the maximum permitted number of spool requests is limited (Note 48284). Use print list archiving for spool requests.
The number of TemSe objects may vary considerably depending on the system. In some production systems, 30,000 or 40,000 objects would be quite normal (100,000 is still considered a lot). Always ensure that the number and memory allocation do not continually increase in your system.

    2. Delete any objects that are no longer required.

        A. Spool objects that are no longer required can be deleted using spool administration.

        -> Tools -> Administration
             -> Spool -> Spool administration (transaction SPAD)
                  -> Delete Old Spool Requests.
        (as of Release 4.0A: -> Tools -> CCMS -> Spool -> Spool Administration
           (transaction SPAD) -> Administration -> Delete Old Spool Requests

        Only use this online option if there are not many spool requests in the system.

        You can also execute report RSPO0041. Refer to Notes 41547 and 16083 for information on deleting outdated spool requests.
        In the meantime, an improved version of this report (RSPO1041) has been created, which you can download from sapserv3 (Note 130978).

        B. Delete obsolete job logs via report RSBTCDEL (Note 16083).

        C. Refer to Notes 98995 and 385283 if you want to delete HR objects.

        D. Use transaction FDTA to delete DTA objects from Financials (a description on how to do this is available in the online documentation). Display the list and use the Delete pushbutton.    Here, you can also check for possible inconsistencies (table REGUT contains a reference to TemSe object).

        E. To delete batch input logs that are no longer needed, use the RSBDCREO report (Note 25219).


NOTE:
If retention times for jobs and spool requests differ, then spool request numbers are sometimes reused. This can lead to invalid allocations. For more information, see Note 422136.

NOTE:
You can use the report RSTS0022 to delete old TemSe objects. Execute this report with care. Only execute it if you know precisely what you are deleting. This report does not take into account dependencies between TemSe tables and other tables, so inconsistencies may occur.

RSTS0022 SHOULD NEVER BE SCHEDULED ON A REGULAR BASIS

Only use the reports mentioned above for this. RSTS0022 can delete only the TemSe object and the header entry in TST01. It does not touch the entries in tables TSP01 and TSP02, which causes inconsistencies in the spooler. This can result in serious errors, for example, if a batch job tries to append a spool request to an existing one and no longer finds the TemSe object.
For this reason, run a consistency check on the spooler afterwards.

After you import the Support Packages mentioned in this note, report RSTS0022 can no longer be carried out from transaction SP12.

    3. Perform a consistency check on TemSe and the spooler.


IMPORTANT:
There are two fundamentally different consistency checks: the TemSe checks and consistency checks specific for the respective object type (spool, batch input, and so on).
Neither of the two checks contains the other check, which means you must use BOTH checks!
The TemSe consistency check checks the header entry in table TST01 and the corresponding object for ALL TemSe objects. The spool consistency check, for example, also checks the entries in tables TSP01 and TSP02, but only the spool objects are checked. For batch input logs, see Note 175596.

Both consistency checks are client-independent (refer to Note 375964 in the event of problems).

You can execute both consistency checks online or in the background. There is no significant difference. In production systems, we recommend that you do not use the online solution since a timeout may occur. If necessary, increase the value for parameter rdisp/max_wprun_time (Note 25528).

Essentially, the consistency checks contain only read operations and therefore cannot cause any 'damage'. This is also true if other users are working in the system. However, in this case the system might display temporary inconsistencies, because someone is currently writing to the TemSe (this problem can also occur when you execute the check in the background).
These are not genuine inconsistencies and must not be deleted. We recommend that you run the consistency check twice before a possible delete run, with a 30 minute interval between checks (this is an approximate value only; the exact interval depends on the jobs that are currently running). Only the inconsistencies that are displayed in both checks are genuine inconsistencies.

NOTE:
The spool consistency check also includes write access to the database, because it deletes out-of-date write locks. The default is 30 minutes, which is insufficient for many background jobs. A background job that runs for longer during this time terminates with the error described in Note 16534.
We therefore recommend that you choose a value that is sufficiently large (the new report RSPO1043 has a default value of 10,080 minutes, which corresponds to one week).
Since the value of 30 minutes for the online check cannot be changed, you should perform the consistency check in the background.

        A. TemSe consistency check


  1. Online:
     Transaction SP12 (menu path see above)
        -> TemSe Data Storage -> Consistency check

As a result, the system displays a list with the inconsistencies.

  2. In the background:
Run report RSTS0020. As a result, the system displays a list of the inconsistencies found. However, you do not have the option of deleting them. Wait some time, then run the consistency check a second time and compare the results. Inconsistencies that are found in both logs are genuine inconsistencies and should be deleted. However, bear in mind that long-running jobs for the current day might also be listed as inconsistencies in both logs.

Inconsistencies in TemSe CANNOT be deleted in the background.
You have two options for deleting:

a.) Run the consistency check online, as described above.
Select the inconsistencies to be deleted and choose:
'Delete Selected Entries' or 'Delete all', to delete the entire list.

b.) If you have many TemSe objects, use report
RSTS0030. Call RSTS0030 online
for areas of TemSe in which the consistency check found inconsistent objects. Select both the TST01 and TST03 checks (you do not have to list all TemSe objects).
Once the report has generated the object list, delete either the seletced or all inconsistencies.

Note that you can only enter a generic name (that is, using wildcards), not however, as an area with upper and lower limits.

NOTE:
Since deleting inconsistencies only includes the header entry in table TST01 and the actual TemSe object, an inconsistent spool request is not fully deleted. The entries in the two spooler tables are retained. For this reason, you should always use the spool consistency check to delete inconsistent spool requests.

        B. Spool consistency check

  1. Online:

    Transaction SPAD (menu path, see above)
          -> Check consistency (as of Release 4.X: Administration ->
          -> Consistency Check of Spool Database

  2. In the background:
There are two reports for the spool consistency check: RSPO0043 and RSPO1043. RSPO0043 can only display inconsistencies in the background, similar to RSTS0020 in TemSe.

Deleting inconsistencies in the spooler:

Up to and including Release 3.1I, you can only delete inconsistencies online using transaction SPAD or by starting RSPO0043 online. Then, eliminate the inconsistencies using 'Delete Selected Entries' or 'Delete all'.

As of Release 4.0A, the new report RSPO1043 is delivered in the standard system (Note 98065). It has two essential advantages:
It can delete inconsistencies in the background and it only deletes inconsistencies if it has found them in repeated runs, that is, there is no danger of deleting temporary inconsistencies. We therefore recommend that you use this report only as of Release 4.0A and that you schedule it on a daily basis.
Report RSPO1043 might list its own spool request as inconsistent. You can ignore this entry.

C. Consistency check for batch input: Use the reports RSBDCCKA and RSBDCCKT. For more information, see Note 175596.

Reset the profile parameter rdisp/max_wprun_time to its previous value when you have completed the online consistency check.

Which reports should be scheduled on a regular basis (see also Note16083)?
You should run the following reports daily:
RSPO0041 (or RSPO1041), RSBTCDEL: To delete outdated TemSe objects
RSPO1043, RSTS0024, and RSTS0043 for the consistency check

Composite SAP Note: Performance optimization during import

Performance during transport: Transports should be performed as quickly as possible to minimize system downtimes or to be able to make maintenance intervals as short as possible.

This note describes the issues that generally are to be taken into account. The first section involves issues that have to be taken into account, while other sections refer to options that lead to further improvements under certain circumstances.

    1. Homework:

        a) On UNIX: If the transport directory is mounted using NFS, use at least NFS 4 and leave the transport profile parameter "lock_check_wait_time=0" (this is the default value). For more information, see Note 132536.
        If "lock_check_wait_time=n" is set, you can expect that the import of m transport requests spends approximately 3*n*m seconds with "sleep" alone. Therefore, you must have  n=0 as of approximately 100 transport requests and higher.

        b) On Windows: Deactivate opportunistic locks (Note 690449).

        c) Use the "import all" strategy wherever possible.
        If you can use organizational measures to ensure that the sequence of transport requests in the queue is correct, you should ideally process it with the "import all" strategy. Even if you are still working with individual imports in the Q system, it may be an option for subsequent systems.

        d) If you work with the individual import strategy or if you use Transportation Management tools of SAP partners, you should consider Note 1008058.

        e) Let transport background jobs run on high-performance hosts without competion.
        The steps that are performed during an import are partially implemented in ABAP and are executed by SAP background processing. Note that the transport jobs (job name = RDD*, normally user = DDIC) without much competition run by other background jobs.
        For more information about control and about the server on which the transport jobs are running, see Note 1147300.

        f) Regular cleanup in the transport directory.
        Directories with too many files have a negative effect on performance on all platforms. Therefore, run "tp clearold all" regularly. This prevents the number of files in the subdirectories of <TRANSDIR> from becoming higher and higher and a performance bottleneck occurring at file system level.
        For more information about "clearold", see Note 312843.
        Also see the "System-specific log directories" paragraph in chapter 2 of this note.

        g) On DB2/MVS: Use a current R3trans version for the import: Kernel release 700 or higher, R3trans version from August 05, 2008 or later.

        h) In MSSQL: Use a current R3trans version for the import: Kernel release 700 or higher, R3trans version from March 22, 2010 or later.

    2. Further options for accelerating imports:

        a) "Accelerated Import" for a large number of small transports
        If you usually have many transport requests to import that are relatively small, you should then set the parameter "acc_import=true" in the transport profile. This activates the "accelerated import" with which the import steps DataDictionary import and main import (and possibly also Commandfile import, for example, if vers_at_imp is set) are each processed by a single R3trans process, so that the overhead, which normally occurs if a separate R3trans process is started for each transport request, no longer occurs.

        b) Using "activatemerged=true" to activate the ABAP Dictionary for multiple small transports
        If you typically have to import many transport requests that contain ABAP Dictionary objects (for example, domains, data elements, tables, indexes, views, and so on), you must set the parameter "activatemerged=true" in the transport profile. This ensures that the system does not activate the ABAP dictionary for each request; instead, it performs a joint activation run for all ABAP Dictionary objects that were imported in an import queue. This omits the overhead that occurs due to multiple activations of several transported objects and their dependent objects. In addition, the internal parallel processing potential of the ABAP Dictionary activation program can be better used.
        One disadvantage of this option is that a collective activation log exists rather that an individual activation log for each transport request; the activation logs then contain only a reference to the collective log. If it is important that the developer can see "their" activation errors directly, we recommend that you do not use this option yet for the consolidation system and that you wait until additional systems have been delivered.

        c) Import with parallel processes
        If you usually have large transport requests to import (with 100 or more objects, for example, client transports), you can then set the parameter "parallel=n" in the transport profile, whereby n is the maximum number of parallel processes. Since the ideal values for n depend to a large extent on the hardware and the database, we recommend that you start with small values and increase them gradually.
        For more information, see Note 1127194.

        d) System-specific log directories
        By default, all of the logs that are generated during the transport are stored in the directory <TRANSDIR>/log. If you set the transport profile parameter SID_LOG_FILES = TRUE, all of the logs of the transport activities and in particular, all of the transport request-specific logs, are stored in system-specific subdirectories <TRANSDIR>/log/<SID>. As a result, the number of files in the log directory is drastically reduced, leading to a considerable acceleration at file system level.

        e) Selective language import
        Importing deletions into language-dependent tables is faster with the profile parameter "sli=true" and the R3trans version from March 04, 2010 or later, particularly in the database DB2/6000.

    3. Options for shortening the system downtime:

        a) Delaying ABAP generation (see Note 1069417 for more information)

        b) When you transport large datasets that are mostly in the target system (for example, client transports in existing clients)
        It is worth using the R3trans version of July 4, 2008 or later for the import, since a performance improvement is effective for the internal comparison of table entries as of this version.

        c) Limiting table cache size
        R3trans tries to save time during the import by merging the existing table entries with the table entries that are to be imported, and it writes only the modified part to the database, thereby reducing the write database accesses. To so so, the system creates a main memory area dynamically that is up to 2GB in size (the table cache). If the main memory that is required for this purpose is available virtually but not physically, the operating system starts with paging, which undoes the expected performance improvement. In this case, it is better to limit the main memory that is occupied by the table cache. R3trans then automatically switches to DELETE/INSERT so no functional disadvantage arises.
        You limit the table cache with the R3trans option "tcs=nnn", whereby nnn is the number of bytes (for example, "tcs=100000000").
        To set this R3trans option, see Note 103582.

Program runs very long: Performance analysis

A program runs for an exceptionally long time. How can you determine which database access takes too long.

Due to inadequate programming, a database acess can take an extremely long time. There can be various causes: multi-nested SELECT, not using indices effectively, missing or non-selective specifications in the WHERE clause, for-all-entries with empty table, no specifications in the selections screen (incorrect handling of variants), and so on.

Solution

    1. Determine whether the system is slow in total or only the particular program (see Note 15374). For the analysis and solution of general performance problems and for the support of the system administration you should carry out the EarlyWatch service in your system regularly.

    2. Determine which program is affected exactly. (Transaction profile -- see Note 15374). Transaction ST03 can be used for the identification of long-running transactions. With this transaction, the runtime statistics can displayed. Choose the button 'Choose for Analysis', select the computer, select the period; select the workprocess type via the buttons 'Dialog', 'Background' and display the runtimes via 'Top-Time' or 'Transaction Profile'. Potential causes of the problem with extensive database accesses typically have have a DB portion of >80% from the entire runtime.

    3. Creating the SQL trace:

        a) Activate the SQL TRACE immediately before executing the respective transaction. For this, call Transaction ST05 in a new mode. For Releases <= 4.0B, then choose the button TRACE ON and enter the user name for which you want to create a trace. As of Release 4.5A, enter the user name under 'Trace on with filter'.

                       As of Release 4.0A: With the radio buttons 'Trace Mode' you can log the response times via RFCs and Enque locks. We recommend to record this information in the trace.

                       Notes:
Make sure that the program to be examined runs on the same application server on which you started the ST05.
Ensure that you only measure one program at a time. That is, the traced user may have occupied only one workprocess on the application server.
During the first execution of a program, data bank accesses are carried out to fill R/3-internal buffers. A trace for the performance measurement can only be used with the second execution.

        b) After this, restart the transaction to be measured on the old window. When it is finished, switch off the SQL trace again by choosing the button 'Trace Off' and then select 'LIST TRACE'.

                       AS of Release 4.0A: Display all Trace Modes (activate all buttons). In the trace, choose the button 'More Info' or 'extended List', in order to display important details and time stamps and calling programs.

        c) In the displayed listing, you can now analyze all SQL statements with their particular DB delay time - column DURATION. The values are issued in the unit microseconds.

                       You can download the trace with Okay Code% PC. Use 'Not converted' as file format, since this text format can be read easiest and reprocessed, if necessary.

                       You can identify the calling program by doubleclicking on the particular line on the program or choosing the button 'ABAP display'. Note down the program name, the line number, changed by, since this information is required for further processing.

                       With the button 'Explain SQL' you receive an overview on how the database carried out the SQL query. You should also save this information since this information is essential for further analysis.
Under ORACLE: Click the table name(s). Also save the information on the indices defined on this table.

    4. Calls of runtime statistics (statistical records):
    In addition to the SQL trace we recommend to display the statistics records.
    Execute Transaction STAT on the same application server. Enter the name of the user you traced and enter the approximate time interval. On the statistics records, you can see the entire execution time, that is, not only the database time but also other portions which determine the runtime. Example (1) The CPU time which was needed on the application server and (2) times for loading and generating. If one of these response time portions is higher than the database time, generally no SQL problem exists but there are high execution times in the ABAP program (in case (1)) or there are problems with program or table buffers (in case (2)).
    Store this information since it is essential for further analysis.


Important: long access times are by no means always caused by unfavorable programming. There may be other reasons such as corrupt indexes, database tables blocked by other users, incorrect parameter setting of the database, bottleneck situation on the hard disks.

If you identified a long-running SQL query:
Do not carelessly change indexes. In particular, indices of the SAP standard should not be changed without SAP consultation.
If it is a long-running statement in the SAP standard system, open a message to SAP and enter the above-mentioned information in the message (program part, execution plan, index definitions, runtime statistics (statistical record)).
If the problem occurs due to program changes made by you, ask your consultant to solve the problem or request an EarlyWatch express (see Note 61781), in order to receive additional support by SAP.

Checklist: Performance analysis

Customer has Performanceproblems but no connection or only a poor remote connection to SAP.


We strongly recommend every customer to install a usable remote connection to an SAP SUPPORT Center as soon as possible.
Without this connection, the solution of problems will be delayed. In critical problems it also might be necessary to have an SAP consultant analyze the system on-site.

In the case of serious perfomance problems, the following lists have to be printed:

• Once for the whole system:
  
  SM51
  
  ORACLE :
  
  ST04 -> Goto -> State -> Parameter Changes -> History of file
  
  ST04
  
  DB02 -> Missing indices
  
  DB02 -> Freespace statistics
  
  DB02 -> Goto -> Check -> Reorganisation -> Extents/Table;Index
  
  
  INFORMIX :
  
  ST04 -> Button Shared memory incl.
  
  ST04 -> Goto -> Activity -> Current statistics -> Wait statistics
  
  ST04 -> Goto -> Activity -> Database log
                                      (for the last 3 days!)
  
  ST04 -> Goto -> State -> Parameter changes
  
  DB02 -> Missing indices
  
  DB02 -> Freespace statistics
  
  DB02 -> Goto -> Check -> Reorganisation -> Extents/Table;Index
  
  How often do you run an update statistics for the database?
  
  ADABAS D :
  
  ST04
  
  ST04 -> Goto -> State -> Parameter Changes -> History of file
  
  ST04 -> Goto -> State -> Configuration
  
  ST04 -> Goto -> State -> tables/indices ->  Select table : *
                                                  ->  Missing indices
  
  How often do you run an update statistics and an update columns for the database ?
   

For DB2 database server on UNIX and Windows NT

• ST04
  
  Do lock escalations exist that caused long lock-wait times or deadlocks?
  
  If the lock list full?
  
  DB12
  
  Were the RUNSTATS runs (ALL or DBSTATC) carried out properly?
  
   
• For every SAP instance:
  
  
  SM50 -> CPU
  
  ST06
  
  ST06 -> Goto -> Current local data -> Snapshot -> Top CPU process.
  
  ST03 -> Goto -> Current local data -> Today's workload --->>>
                   --->>> Tasktype profile
                    --->>> Tasktype profile and double click on Dialog
                    --->>> Transaction profile
  ST02
  
  ST02 -> Goto -> Current local data -> Storage
  
  ST02 -> Goto -> Current local data -> Storage -> Shared memory detail
  
  SA38: RSPFPAR -> Execute

Print these lists and forward them to SAP.

This procedure can only be used in emergency situations, and is not intended to replace the Early Watch Service or Remote Support.

R3trans: Performance problems and cluster

Symptom

Copying, transporting or deleting clients with the help of R3trans takes too long.
This note gives you a few options for speeding up these actions.
In addition, it also contains information about the 'normal' values for the runtimes and which performance benefits can be expected for the different options.
A performance problem exists, if the throughput of R3trans is significantly below the following values:

• Client copy:       120 MB/hour
   
• Client deletion:    80 MB/hour
   
• Export:            200 MB/hour
   
• Import:             80 MB/hour

Note that R3trans should only be used for copying clients up to Release 2.1.
During a client export/import R3trans is implicitly called via the transport program tp and is therefore active up to Release 4.0.

Reason and Prerequisites


Several causes for the performance problems are possible:

    1. Cluster tables

              Cluster tables are an SAP mechanism that allows you to store several logically connected entries, also from different "logical" tables, in one "physical" table entry. In addition to other advantages (such as the definition of tables with a lot of key fields), these clusters also allow quick access to this data on the condition that the table entries that logically belong together are always read together.

For actions such as copying, transporting or deleting clients, these entries are not treated as a logical unit, but are processed as a simple table. This results in poorer performance than for transparently stored tables.

This performance deterioration is strengthened by the fact that the cluster records are compressed when they are stored. For actions such as CLIENTREMOVE, the cluster records must therefore first be read and expanded. The entries that belong to a certain logical table are then deleted. The remaining entries of the other logical tables are then recompressed and the changed cluster record is written back to the database. This is naturally costlier than a simple DELETE statement in the database.

The same applies to transporting and copying clients.

These problems occur particularly frequently with the following tables: CDCLS: CDHDR CDPOS PCDHDR PCDPOS (in Releases < 4.0A)
RFBLG: BSEC BSED BSEG BSES BSET
The end of this note describes how to determine the size of your cluster tables.

    2. Transparent tables

              For transparent tables (tables that have a corresponding table with the same structure at database level), there may be performance problems when copying with the option "client copy".

    3. Main memory bottlenecks

              When you transport clients, main memory bottlenecks can occur during the import. This can adversely affect paging or swapping at operating system level, depending on the system configuration.

    4. Database problems

    A further possible source of performance problems is:

        a) Missing indices

        b) Un-released locks

        c) Lock escalation (ADABAS)

        d) Rollback segments too small (Oracle)

        e) Strong fragmentation of database indices or LONG RAW fields (Oracle)

        f) (Wrong) statistics on internal tables (Oracle)

Solution


Depending on the cause, different solutions:

    1. Cluster tables

        a) Deletion of a client (clientremove)

           If a client is deleted with R3trans, this is generally done with an R3trans control file that has approximately the following contents:

                    clientremove
client = ...
select *

           R3trans now works through the physical cluster tables in the logical table sequence, causing the performance losses described above.

           In Releases <= 3. 0F, a solution to this is to delete the largest clusters manually before starting R3trans:

                    Determine which clusters are particularly large.

                    For each of these clusters, delete the entries of the client to be deleted by manually executing the following SQL command, either with your own ABAP program or with database tools (sqlplus, dbaccess, xquery):
   DELETE FROM <cluster_name> WHERE MANDT = '<client>'
Thus, for example
   DELETE FROM RFBLG WHERE MANDT = '002'

                    You can then delete the remaining client specific table entries with R3trans and the control file described above.

                    Since the R/3 System carries out row-locking on the database level, during this process very large rollback segments or an extremely large number of locks are created on the database. Please refer to note 102034 for further details.

                    The names of all client-specific cluster tables can be found with the following SELECT command:    SELECT TABNAME FROM DDNTT
     WHERE TABTYPE = 'C' AND CLIENTPOS > 0

                    The performance benefit that is to be expected when you delete the physical clusters instead of the logical tables is approx. a factor of 3.

           As of R3trans Release 3. 1G, this workaround is no longer required. For control files of the type

                    clientremove client = ...
select *

           R3trans deletes at the physical level.

        b) Copying a client (client copy)

           Copying a client in a system is not generally handled by R3trans but by client administration tools within the SAP System.
If, for some reason, you want to copy individual tables directly with R3trans, this can be done with a control file of the following type:

                    clientcopy
source client = ...
target client = ...
select * from <tabelle>
select * from <tabelle>

           For cluster tables, the same effects can be achieved as during client deletion. As a solution, it is recommended to delete the target clients first, as described under 1a) or to first delete the contents of the table to be copied.

           If you want to copy all logical tables of a cluster, the name of the cluster table can also be entered directly in the R3trans control file. Example:

                    clientcopy source client = ...
target client = ...
select * from rfblg

           The performance benefit that can be expected when you copy physical clusters instead of logical tables can be estimated at approximately a factor of 5 (if entries already exist in the target client) or 3 (if the target client is empty).

           A client copy can also be carried out by export/import, see 1c). In this case, you can expect a performance gain in the region of a factor of 1.5 in comparison to a direct copy.

           As of Release 3. 1G, R3trans copies the physical cluster tables directly with "select *" in a client copy.

        c) Transport (Export/Import)

           Transporting a client between systems is generally done with the client administration tools within the SAP System. These generate a transport request that is implicitly transferred to the transport tools tp and R3trans for the client transport. Depending on the chosen client copy profile, cluster tables can also be contained in such a client transport (especially if a copy profile was chosen "with application data").

           The problems described above can also occur on cluster tables causing performance problems here.

           A possible solution is to delete the larger cluster tables in the target system before the import, as described under 1a).

           Reason: When importing, R3trans attempts to merge the table entries transported with the existing ones in memory and to only write the changed table entries. To do this, all entries from the logical tables must be read and expanded, requiring considerable resources. The strategy of only writing back changed records, in order to avoid database accesses is less effective for cluster tables, as a change to the logical table entry suffices to force the physical table entry to be written back to the database. A previous deletion of the physical clusters can significantly improve the speed of this.

          

           A further way to speed this up is to exclude the cluster tables during the normal client transport and deal with them separately. The solution however, requires that the source and target systems are either both ASCII or both EBCDIC systems.

           For this, proceed as follows:

           For the purpose of the export, a transport is created by the client administration tools that can also contain the name of the logical cluster tables. The logical table names must be removed from this transport request by executing the following SQL command either with your own ABAP program or with the database tools (sqlplus, dbaccess, xquery):

                    UPDATE E071 SET PGMID = '*' WHERE TRKORR = '<transport_request>'
AND OBJ_NAME IN ('<tab1>','<tab2>',...,'<tabn>');

           Then carry out the transport as usual:

                    tp export <transport_request> client=...

           The missing cluster tables are then transported, so that the physical cluster tables rather than the logical ones are exported and imported when using R/3trans directly.

           Exporting the physical cluster tables:
Log on as < sid>adm to an application server on the source system and change to the directory /usr/sap/trans/tmp.
Create an R3trans control file exp.ctl with the following contents:   export
  client = ...
  file = '/usr/sap/trans/data/cluster.dat'
  select * from <cluster_name>
  select * from <cluster_name>
  ...Then list all physical clusters whose logical tables were previously removed from the transport request.
Start the export afterwards with the command   R3trans -w exp.log exp.ctlA log is then written in the file exp.log, the data is exported to the file cluster.dat.

           If you do not have a central transport directory, you must copy the file /usr/sap/trans/data/cluster.dat into the transport directory of the target system.

           Importing the physical cluster tables:
Log on as < sid>adm to an application server on the target system and change to the directory /usr/sap/trans/tmp.
Create an R3trans control file imp.ctl with the following contents:   import
  file = '/usr/sap/trans/data/cluster.dat'
  client = ...Then start the import with the following command:           R3trans -w imp.log imp.ctlA log is written to the file imp.log.

           If you only encounter performance problems during the import and can at least re-export the cluster records, it is not necessary to modify the previously generated transport request and export it a second time. In this case, it is sufficient to prevent the import of the logical cluster tables and then re-transport the physical cluster tables as described above.
You can prevent the import of the logical cluster tables as follows:

                    Terminate the import.

                    Mark the logical cluster tables as successfully imported with the following SQL command:

                      If R3trans release <= 3.0F:

                        UPDATE E071 SET LOCKFLAG = ':'
    WHERE TRKORR = '<transport request>'
    AND OBJ_NAME IN (SELECT TABNAME FROM DDNTT WHERE REFNAME =
    '<clustername>')

                      If R3trans release >= 3.1G:

                        UPDATE E071 SET LOCKFLAG = '2'
    WHERE TRKORR  = '<transport request>'
AND OBJ_NAME IN (SELECT TABNAME FROM DDNTT WHERE REFNAME =
    '<clustername>')

                    Afterwards, restart the terminated import and make sure that this runs without unconditional mode 1.

           The performance benefit that can be expected when transporting the physical clusters instead of the logical tables is approx. a factor of 3.

           Client transports with application tables are often required because a test system should be supplied with "actual" data from a productive system either on a regular basis, or just once. In these cases, it would also be possible to set up the test system as a database copy.

           We are currently working on a solution whereby R3trans directly transports the physical clusters.

    2. Transparent tables

        a) When you delete or transport clients, no particular performance problems are known.

        b) A performance loss can result when copying a client for transparent tables, so R3trans currently avoids array-inserts. Instead, the table entries are individually inserted into the target clients with INSERT/UPDATE sequences.

           A possible solution here is to delete the target client (see 1a). As a result, all table entries can be written with INSERTs and need not be written on the second attempt with UPDATE.

           A second possible solution is to carry out the client copy as an export and subsequent import in the target clients. In this case, the performance gain is achieved by merging the table entries in the main memory (described under 1c)), and by the fact that database accesses are saved and internal array-inserts are used.

           We are currently working on a solution whereby array-inserts can also be used internally during the clientcopy.

    3. Main memory bottlenecks

        a) When you delete or copy clients, no memory bottlenecks are known to cause performance losses.

        b) When you transport clients, it is possible that memory bottlenecks occur during the import that may have an effect on the performance. The memory requirement results from merging the table entries in memory, as described under 1c).

           Note 6588 describes how to reduce the main memory requirement for an R3trans import.

    4. Database problems

           A further source of performance problems may be:

        a) Missing indices
        Missing indices always cause performance losses.
        Problems of this type can be analyzed with Transaction ST04. For further details, see Note 15374.

        b) Unreleased database locks from other processes (exclusive lockwaits)
        Database locks from other processes cause the R3trans process to stop.
        Problems of this type can be analyzed with Transaction ST04. For further details, see Note 15374.

        c) Lock escalation (ADABAS)
        For processes that block too many individual records of a table, the database system carries out lock escalation, that is, an attempt is made to set an exclusive lock at table level. If other processes work on the same table, the escalation process hangs. For further details, see Note 65946.

        d) Rollback segments too small (ORACLE)
        Rollback segments that are too small or a tablespace PSAPROLL that has been defined too small can cause R3trans to terminate and therefore also cause a time loss. Detailed information on this is contained in Notes 10146, 60233, and 102034.

        e) Fragmentation of database indices or LONG RAW fields (Oracle)
        If a client is created several times (for example, when you delete and copy clients periodically), it is possible that the increasing fragmentation of indices and LONG RAW fields causes a dramatical loss of performance. A typical feature of this problem is that the performance losses increase each time.

                    There has been very little research of these problems, and the solutions presented here should only be carried out after consulting the SAP Hotline.
Fragmentation of indices:
Potentially, all tables can be affected.
Solution: Delete the database indices for the tables in question and recreate them.
Fragmentation of LONG RAW fields:
This particularly affects the cluster tables.
The problem may occur under

                    UNIX with oracle release < 7.1.6

                    NT with oracle release < 7.2.3

           Solution: Install an oracle patch (see Note 28293) or reorganize the concerned tables. Useful information to accelerate table reorganizations can be found in Note 12621.

        f) (Wrong) statistics on internal tables (Oracle)

                       Very rarely, performance problems can be caused by statistics on Oracle internal tables which lead to the use of the cost based optimizer (CBO). For further information refer to Note 138639.


Determining the cluster tables and their current size To determine which cluster tables are particularly large in your system, proceed as follows:

• Determining all cluster tables with the DD information system:
  
  Development -> Dictionary -> Environment -> Information system, or Transaction SE85.
  Other objects -> Select Pooled/cluster tables.
  Function "All selections", choose table type "CLUSTER" and execute.
  You now get a list of all known clusters in the system.
   
• Open a second session and navigate to the database analysis tools:
             Administration -> System administration -> Monitor -> Performance -> Database -> Tables/indexes.
   
• For each of the cluster tables in the list, determine the current memory requirements in the database as follows:
  Select the function "Detailed analysis" and enter the name of the cluster.
  On the next screen, position the cursor on the name of the cluster and select the function "Analysis".
  The memory requirements for the table are now displayed.

Installing Microsoft Loopback Adapter in Windows 2003 Server

Adding Microsoft Loopback Adapter
Adding Microsoft Loopback Adapter is very important part of SAP Installation because SAP software work on Network so it require network setting to install, to avoid disconnection in the process of installation we set Microsoft Loopback Adapter.
First we install Microsoft Loopback Adapter and give a live IP to that adaptor and do all the installation, after installation is done we change the IP address of this Loopback Adaptor to the live Network Adaptor and disable this Microsoft Loopback Adaptor.
To install Microsoft Loopback Adapter
go to control panel >> add new hardware Click Next

It will search for the new hardware installed …


In the next step it will ask for the new hardware installed ?
Select on Yes… and click Next > Button

  

Select  “Add a new hardware device” and click Next > button


Select “Install the hardware that I manually select from a list advanced”
And click Next


Scroll Down to the bottom and select “Network Adaptor”
 
Select Microsoft in the “Manufacture Window” and Microsoft Loopback Adapter in the “Network Adapter Window”
And then click next


This will finish the installation of and Microsoft Loopback Adapter

Now we need to give the IP address to this Microsoft Loopback Adapter for this
Go to
Start >> Network Adaptor >> Select  Microsoft Loopback Adapter and click on properties
Local Area Connection Property


 Property >>
For this installation I am using this IP (192.168.1.5)
Setting Microsoft Loopback Adaptor is done..

Setting Virtual Memory or Page file size for SAP installation

Virtual memory in SAP installation is very important because SAP installation consume lots of memory… so it is batter to give good amount of memory..
To set Virtual Memory we normally take this formula
Initial Size = RAM x 4 times (approx.)
Max = RAM x 4 + 500 MB
Right mouse click on my computers >> Click on Property
System Property window will open
>> Click on Performance Option

>> in Virtual memory >> Click Change


>> Select the Drive on which u want to give Virtual Memory

How to set up Gateway logging

You want to log the actions of the SAP Gateway. This is especially interesting if you use external programs regularly and you want to ensure a smooth operation.

Using the profile parameter gw/logging

You can use the parameter gw/logging to activate/deactivate logging for certain actions.

The parameter has the following syntax:
LOGFILE=<name> ACTION=[TERSMPXVOC] [MAXSIZEKB=n] [SWITCHTF=t] [FILEWRAP=on]
The individual options mean the following:

1. ACTION: You can log the following actions:

           (T): Network actions: Opening and closing network connections

           (E): Starting external programs

           (R): Registering/deregistering servers

           (S): Security settings and their changes (reloading files)

           (s): Only rejected secinfo and reginfo accesses; see also (Z).

           (M): Monitor commands

           (P): Dynamic changes to parameters

           (X): Start/stop/signals of the Gateway

           (V): Creating and deleting conversation IDs

           (O): Opening RFC connections

           (C): Open/close/data traffic for RFC connections

           (Z): Secinfo and reginfo accesses for which no rule applies.

2. LOGFILE: Name of the log file:

           Special characters that are replaced for the runtime may occur in the file name:

           %y : Year

           %m : Month

           %d : Day

           %h : Hour

           %t : Minute

           %s : Second

           For example: gw_log_%y-%m-%d is replaced for: gw_log-2007-02-28

3. MAXSIZEKB: Maximum size of the log file in kilobytes:

           When the file exceeds this size, a new file is opened and the new file name may change if the special characters are used. This is the case unless a condition is specified for SWITCHTF that occurs beforehand.

4. SWITCHTF: Open a new file again after a certain amount of time unless a condition was specified for MAXSIZEKB that occurs beforehand.

           You can specify the following values here:

           year  : a new file is opened after a year

           month : after a month

           week  : after a week

           day   : after a day

           hour  : after an hour

5. FILEWRAP: Reusing the file

           This parameter can have only the value "on". If this value is set, no new file is written, rather the file already opened is reset and described again. The special values for the parameter LOGFILE are used only when you open the file for the first time.

Example:

If the parameter is set to the value
gw/logging: ACTION=SPXM LOGFILE=gw_log-%y%m%d SWITCHTF=day
security settings, dynamic parameter changes, signals to the Gateway and monitor commands are logged.

Caution: You must create a secinfo.dat and a reginfo.dat accordingly in order to separate reginfo and secinfo in logging. Otherwise, you see only secinfo entries (also for server registrations). For more information, read the online documentation on the SAP Help Portal.

Gateway Monitor

Logging settings were implemented in the Gateway Monitor (transaction SMGW). To do so, proceed as follows::

Transaction SMGW -> Goto -> Expert Functions -> Logging

When you call this, the current setting is displayed. If the caller has the required authorization (AUTHORITY-CHECK OBJECT 'S_ADMI_FCD' ID 'S_ADMI_FCD' FIELD 'PADM'), he/she can change and activate the settings. They are then active immediately for the Gateway. Deactivating all log events causes the open file to close.

This function is also provided in earlier releases. The following kernel patches are required for this:

7.00: 119
6.40: 194

You must import the corresponding Support Packages for the Gateway Monitor enhancements.
620 SAPKB62063
640 SAPKB64021
700 SAPKB70013

You can also use the function without these Support-Packages; to do so, you must enter the parameter gw/logging as described above in the instance profile with the required attributes.

Caution: For kernel release 640, the parameter
gw/resolve_phys_addr = 1
must be set, otherwise the system logs only the IP addresses instead of the host names.

Documentation

The documentation for gateway logging is available on the Help Portal at:
http://help.sap.com/saphelp_nw04s/helpdata/en/CB/8C882C6FB546F987880EB97C9FB23A/frameset.htm
The documentation for Gateway administration is available at: http://help.sap.com/saphelp_nw70/helpdata/en/4c/16c4b18a0d40c1be3b7839f884e1e2/frameset.htm

Step by step procedure to generate the SAP Solution Manager key

A SAP Solution Manager key is required for installing and upgrading SAP software.

Actions in the SAP Solution Manager System
(Minimum requirement: SAP Solution Manager 3.1 Support Package 20 of the ST component, or 3.2 Support Package 4 of the ST component, or SAP Solution Manager 7.0 with Support Package 9 for products of SAP Business Suite 2005)

Start System Landscape Maintenance (transaction SMSY) in your Solution Manager System.
To create your SAP system in the system landscape, proceed as follows:

• Select the landscape component "Systems", and select "Create New System" from the context menu.
• Enter the system ID in the following dialog box as the system.
  
• Select the relevant product (e.g SAP ECC) and the corresponding product version(ECC 5.0) from the input help. Choose "Save".
  
• Complete the system data as far as possible. You can find further documentation about this in the online help.
  
• Save your entries.
   

To generate the key, go to the menu option "Landscape Components" (Release 3.1), or "System Landscape" (Release 3.2) and select the entry "Other Object".

"Landscape Components" (Release 3.1), or "System Landscape" (Release 3.2/7.0) and select the entry "Other Object".

• Set the "System" indicator and from the input help, select the system for which you want to perform an installation or an upgrade. If you created the system in   the SAP Solution Manager in the previous step, select this system.
  
• Select "Generate Installation/Upgrade Key".
  
• Enter the necessary data, and select "Generate Key". The system displays the key.

Action in the Installation / Upgrade tool

    Enter this key in the installation tool or in the upgrade

High Availability SAP System on Windows Server 2008 (R2)

This note provides database-specific information about how to perform a new installation or a system copy of one of the following high-availability SAP systems on a Windows Server 2008 (R2) Failover Cluster:

• SAP systems based on SAP NetWeaver '04 SR1 (Web AS 6.40)

• SAP CRM 2007 and SAP SCM 5.1

• SAP systems based on SAP Netweaver 7.0 SR3

• SAP systems based on SAP Netweaver 7.0 EHP1 SR1

• SAP systems based on SAP Netweaver 7.1 (except SAP NetWeaver CE 7.1 SR5)

• SAP NetWeaver CE 7.1 SR5

• SAP systems based on SAP Netweaver 7.1 EHP1 (incl. SAP NetWeaver CE 7.1 EHP1)

• SAP Netweaver CE 7.2

This note applies for the following databases:

• SQL Server

• Oracle

• MaxDB

• IBM DB2 for Linux, Unix, and Windows

In this note, "Windows Server 2008 (R2)" - with (R2) written in parentheses - means that the information applies to both Windows Server 2008 and Windows Server 2008 R2.
Other terms
High availability, HA, upgrade, system copy, Windows Server 2008, Windows Server 2008 R2, 6.40, 7.0, 7.01, 7.10, 7.11, 7.2
Reason and Prerequisites
Check whether your system is released for productive use on Windows Server 2008 R2 in the SAP Product Availability Matrix (PAM) at:
http://service.sap.com/pam

This note is a supplement to the existing notes, installation and system copy guides that are available for the installation on a Windows Server 2008 (R2) Failover Cluster.
Solution
---------------------------------------------------------------------
I.  GENERAL INFORMATION
---------------------------------------------------------------------


Oracle:
If you perform an installation or system copy on Windows Server 2008 R2 with Oracle 10.2.0.5 and Oracle 11.2.0, use Oracle Fail Safe version 3.4.2 (available on DVD51038964).

SAP MaxDB:
For installations and system copies with MaxDB use always the originally released RDBMS DVD.

• Installation with MaxDB on Windows Server 2008 R2:
  MaxDB supports Windows Server 2008 R2 with version 7.8 and higher. Therefore, you have to upgrade your MaxDB database immediately after the installation to version 7.8 or higher.

• System copy with MaxDB 7.8:
  If your SAP system already uses MaxDB database version 7.8, check the following SAP notes:

• 1466917, for SAP systems based on SAP kernel 6.40

• 1469675, for SAP systems based on SAP kernel 7.0*

• 1478170, for SAP systems based on SAP kernel 7.1*

IBM DB2 for Linux, Unix, and Windows:
For the installation of your DB2 database on an MSCS node, use SAP note 1493410. It contains corrections to the high availability section of the installation guides.
---------------------------------------------------------------------
II. INSTALLATION / SYSTEM COPY ON WINDOWS SERVER 2008 (R2)
---------------------------------------------------------------------

SAP systems based on SAP NetWeaver '04 SR1 (Web AS 6.40):
Not supported

SAP CRM 2007 and SAP SCM 5.1
For more information, see SAP Note 1333785.

SAP systems based on SAP NetWeaver 7.0 SR3 and SAP systems based on SAP NetWeaver 7.0 EHP1 SR1:

Windows Server 2008 (R2) Failover Cluster:
It is very important to follow the Windows 2008 specific steps described in the installation or system copy guides to install SAP systems based on Netweaver 7.0 SR3 and based on SAP Netweaver 7.0 EHP1 SR1 on Windows High Availability with the following additions:

• Make sure you start the SAPInst executable in the command prompt for the(A)SCS installation as follows:
  sapinst.exe SAPINST_USE_HOSTNAME=<virtual hostname (A)SCS instance>

• Before you create the File Server cluster resource, add the "File Services" role on both cluster nodes using the Server Manager. For SAP NetWeaver 7.0 SR3 systems, see chapters for the installation of the SCS or ASCS instance; for SAP NetWeaver 7.0 EHP1 SR1 systems see chapter: "Windows Server 2008: Creating the SAP Services and Applications".

           Windows Server 2008 R2:
Preliminary steps:

• For SAP Netweaver 7.0 SR3: Execute the steps a) to J) as specified in the section Windows 2008 of the chapter "Installing the central Services Instance for ABAP(ASCS) or SCS".

• For SAP Netweaver 7.0 EHP1 SR1: Execute the steps 1) to 10) as specified in the Chapter "Windows Server 2008: Creating the SAP Services and Applications".

           To create the File Server cluster resource on Windows Server 2008 R2,

• for SAP NetWeaver 7.0 SR3 do not use the preparation steps(steps k, l, m, n) in the  chapter 'Installing the central Services Instance for ABAP(ASCS) OR (SCS).

• for SAP NetWeaver 7.0 EHP1 SR1, do not use steps 11, 12, 13, 14 in chapter: "Windows Server 2008: Creating the SAP Services and Applications"

           Instead, create the File Server cluster resource as follows:

• Open a command prompt in Administrative mode and type:
  cluster res "SAP <SID> FileServer" /CREATE /GROUP:"SAP <SID>" /TYPE:"File Server"

• Set the dependencies of the newly created File Server resource to the Disk and the Virtual Network Name resources

• After you have performed the installation option "First MSCS Node", manually adjust the sapmnt file share security as follows:
  Open the Failover Cluster Manager, and select the SAP <SAPSID> cluster group.
  In the Share Folders window, right-click the sapmnt share and choose "Properties".
  Set full access to the following groups:
  local group Administator
  domain group <domain>SAP_<SID>_GlobalAdmin

• For the Database instance installation in Node one, make sure the Node one is the owner of the DB and SAP Cluster Groups.

SAP systems based on SAP NetWeaver 7.1 (except SAP NetWeaver CE 7.1 SR5):
Proceed as described in the installation or system copy guide for your SAP NetWeaver 7.1 including Enhancement Package 1 system.
However, you have to use a modified Installation Master DVD, which you have to create as follows:

1. Download the SAP NetWeaver 7.1 EHP1 Installation Master DVD from SAP Service Marketplace and copy it to a local disk.

2. Download the 710_Installation_Master_PATCH.zip file attached to this SAP note to a local directory and extract it.

3. Go to the folder of the extracted files, where the DATA_UNITS folder is located.

4. Copy all extracted files, including the DATA_UNITS folder, to the root directory (this is the directory where the original DATA_UNITS folder is located) of the SAP NetWeaver 7.1 EHP1 Installation Master DVD.

5. Download the control_710_EHP1.zip file.

6. Replace the control.xml file on the Installation Master DVD with the downloaded one.
You find the control.xml file on the Installation Master DVD in the following directory:
<Local_Directory>DATA_UNITS<platform>NW07WEBASIND

SAP NetWeaver CE 7.1 SR5:

1. Use chapters "Planning" to "Installing the Central Services Instance (SCS)" of section "High Availability with Microsoft Cluster Service" of the installation guide for your SAP NetWeaver 7.0 Java including Enhancement Package 1 SR1 system.

Note the following exceptions for Windows Server 2008 R2:

• Before you create the File Server cluster resource, add the "File Server" role on both cluster nodes using the Server Manager (see chapter: "Windows Server 2008: Creating the SAP Services and Applications").

• Do not create the File Server cluster resource on Windows Server 2008 R2 as described in steps 11, 12, 13, 14 of chapter: "Windows Server 2008: Creating the SAP Services and Applications". Instead, create the File Server cluster resource as follows:
  Open a command prompt in Administrative mode and type:
  cluster res "SAP <SID> FileServer" /CREATE /GROUP:"SAP <SID>" /TYPE:"File Server"

2. Proceed as described in installation guide for your SAP NetWeaver CE 7.1 SR5 system with the following additions:

a) Install the SCS instance with a prepared virtual host name as described in chapter: "Installing the Central Services Instance (SCS)".
You can ignore the Prerequisites Checker warning on Windows Server 2008 R2 regarding the support of Windows Server 2008 R2

b) After you have installed the SCS instance, manually adjust the sapmnt file share security as follows:
Open the Failover Cluster Manager and select the SAP <SID> cluster group.
In the Share Folders window, right-click the sapmnt share and choose "Properties".
Set full access to the following groups:
local group Administator
domain group <domain>SAP_<SID>_GlobalAdmin

c) Start the installation of the database instance with the existing SCS virtual host name.

d) After you have finished the database instance installation, adapt the environment variables PATH and SAPEXE for the <sapsid>adm user as follows:

Open a command prompt, and enter the following command:
runas /profile /user:<Domain><sid>adm cmd

Open a new command prompt as <sid>adm user, and enter:
regedit
Go to HKEY_CURRENT_USEREnvironment
Set the PATH and SAPEXE variables to the following value:

\<SCSVirtualHostName>sapmnt<SID>SYSexeuc<Platform>

e) Before you install the ERS instance, move the SCS instance to another node.

f) If you plan to install the central instance (CI) and/or a dialog instance (DI) locally on the cluster nodes, make sure that you move the SCS instance on another node, before you start the installation.
Note that as of SAP NetWeaver 7.1, the central instance and the dialog instance are called primary application server and additional application server.

SAP systems based on SAP NetWeaver 7.1 EHP1 (incl. SAP NetWeaver CE 7.1 EHP1):

For Oracle database:

Do not use the control_710_EHP1_CE.zip or control_710_EHP1.zip file attached to this note, if you perform an installation or system copy on Windows Server 2008 R2.
For installation on Windows Server 2008 R2 please use the latest Installation Master DVD from SAP Service Marketplace.

For other databases continue as follows:

• Windows Server 2008 Failover Cluster:
  Proceed as described in the installation or system copy guide.

• Windows Server 2008 R2 Failover Cluster:
  Proceed as described in the installation or system copy guide.
  However, you have to use a modified Installation Master DVD, which you have to create as follows:

a) Copy the SAP NetWeaver Installation Master DVD to a <Local_Directory>.

b) Download the control.xml file for your SAP system that is attached to this note and extract it.

• For SAP Netweaver CE 7.1 EHP1, download:
  control_710_EHP1_CE.zip
  control_710_EHP1.zip (for SAP systems with database SAP MaxDB only - fix from note 1315107 is already included)

• For other SAP systems based on SAP NetWeaver 7.1 EHP1, download: control_710_EHP1.zip

c) Change to the <Local_Directory> where you have copied the SAP NetWeaver Installation Master DVD.

d) Replace the control.xml file with the downloaded one.
The control.xml file is located in the following directory on the installation Master DVD:

• For SAP Netweaver CE 7.1 EHP1, you find it in:
  <Local_Directory>DATA_UNITS<platform>CE71IND

• For other SAP systems based on SAP NetWeaver 7.1 EHP1, you find it in:
  <Local_Directory>DATA_UNITS<platform>NW07WEBASIND

SAP NetWeaver CE 7.2:
Proceed as described in the installation or system copy guide.

Unable to download an SAP Note with SNOTE in a SAP System.

Unable to download an SAP Note with SNOTE in a SAP System.

I encountered an issue when I tried to download a SAP Note using SNOTE in my SAP System.

Error connecting to SAPOSS from a remote location: Unable to translate into a number.

The SAP Note *** is currently unavailable.

Even if I utilise the Logon Group 'EWA' after implementing SAP Note 766505, the RFC connection SAPOSS is too slow.


Solution

SAPNet R/3 Frontend does not have a copy of the Note. Because all of the dialogue processes in the [EWA] servers are engaged with the EarlyWatch Alert data transmission from customers' systems into SAPNet R/3 Frontend, SAPNet R/3 Frontend is excessively slow. This is more likely to happen on Mondays and Tuesdays, when we receive the majority of the data packages.

You can connect to the SAPNet R/3 Frontend using an alternative RFC-destination to increase download speed. The following two adjustments are required in order to do so:

1. Copy the destination SAPOSS: to a new RFC-destination called "SAPSNOTE."

This creates a SAPOSS connection using t-code OSS1 in the standard system.

For RFC connections, go to the setup screen (transaction SM59).

Expand the ABAP Connections node and double-click the SAPOSS connection to select it.

Change the client to OO1 on the Technical Settings tab page. Select the Logon & Security tab page and enter CPIC as the connection SAPOSS password. Make a backup of your information.

Select Connection -> Copy and give the new destination the name SAPSNOTE.

In the new RFC connection, change the following parameters: Page with tabs: Technical Specifications

 Load Distribution: Choose Yes.

Target System ID: Enter OSS.

Group: Enter 1_PUBLIC.

In the new RFC connection, change the following parameters: Page with tabs: Security & Login

Client: Enter 001.

User: Enter OSS_SNOTE.

Password: Enter CPIC.

As an alternative, you can use SAP Download Manager to download the Note from SAP Service Marketplace and then upload it to your SAP system using SNOTE. Please keep in mind that SAP Notes can only be downloaded through SAP Download Manager.

http://service.sap.com/notes
Display the Note with the Note number.
'Download'
Start your Download Manager in your PC (If you do not have it, install it from http://service.sap.com/download-basket --> Get Download Manager).
Logon to your SAP system.
TA:  snote
[Menu] Goto --> Upload Notes

http://service.sap.com/noteassistant contains full information about Note Assistant (SNOTE).

Dispatcher remains yellow, although the system is running

In the MMC, the dispatcher stays yellow, with the status 'Dialog Queue Info unavailable'. However, the system continues to run.

When the kernel was changed, the sapstartsrv.exe file was not replaced.This is because the SAP Service was not stopped at the time of the exchange. The service is automatically restarted after stopping, as long as an MMC containing the system in the object list is open.
Please close all MMC instances, including those that may be running on personal PCs and then stop the SAP Service. You can now copy the sapstartsrv.exe file to the Run directory again.

What to do my SAProuter does not run

If your SAProuter does not run do the following steps.
1. Create the subdirectory SAProuter in the directory /usr/sap/.

2. Download the latest version from sapserv3, directory /general/misc/saprouter. Also see the corresponding file 'README' in this directory. Copy programs 'saprouter' and 'niping' into the directory /usr/sap/saprouter.
    If you cannot copy the programs from sapserv3, you can get a (possibly out-of-date) version from the directory /usr/sap/<SID>/SYS/exe/run.

3. Add the following lines to the file /users/<SID>adm/startsap_<host name>_<instance number> before the lines '#Start OS-Collector daemon'.

    # # Start saprouter
    #
    SRDIR=/usr/sap/saprouter
    if [ -f $SRDIR/saprouter ];then
       echo "nStarting saprouter Daemon " | tee -a $LOGFILE
       echo "--------------------------- " | tee -a $LOGFILE
       $SRDIR/saprouter -r -W 30000 -R $SRDIR/saprouttab
                      | tee -a $LOGFILE &
    fi
    This entry automatically starts the SAProuter during the system start and it ensures that the SAProuter is always started. Since the SAProuter should continue to run after R/3 is shut down no respective entry is included in the Stopsap Script. If you boot the R/3 several times, the system displays error messages when the SAProuter is started. You can ignore these error messages. The entry of the SAProuter in the Startup Script is a recommendation. However, you can also start the SAProuter manually.

4. The corresponding routing table must be maintained in /usr/sap/saprouter/saprouttab.

5. Remarks

As of version 25 the SAProuter must have a routing table. The router terminates with an error message if it cannot read the table. If you do not want an authorization check use the line 'P * * *'.

Installation steps of the SAPRouter as Windows NT Service

Setting up the SAProuter as a Windows NT service.

If the Saprouter has already been entered as a service with srvany.exe, the definition of the service from the registry (path: HKLM -> System
-> CurrentControlSet -> Services -> SAPRouter) should first be removed and then the machine should be rebooted.

With the following command you can newly define the service from the command line:
'ntscmgr install SAProuter -b <path>saprouter.exe -p "service -r
<parameter>" '

Replace <path> with the corresponding path to saprouter.exe and <parameter> with any parameters required. It is important that all parameters be in a character string delimited by ".

As of version 25 (3.0E) a route permission table file (SAPROUTTAB) must be specified for the Saprouter. When you want to specify the SAProuttab you consequently must also enter '-R <path>saprouttab' as a <parameter> and create a corresponding SAPROUTTAB (see Note 30289). An installation command could thus be as follows:

ntscmgr install SAPRouter -b c:saproutersaprouter.exe -p "service -r -R c:saprouterSAPROUTTAB"

If no path to SAPROUTTAB is specified, the SAPROUTTAB must be in a directory which is contained in the PATH variable of the NT system environment, thus for example the SYSTEM32 directory of the Windows NT installation. If the SAPROUTTAB should be in a special directory, this path to SAPROUTTAB must be specified.

Proceed as follows after the installation to maintain the general attributes of the service:

• Go to 'Control Panel -> Services: SAPRouter -> Button: Startup', set the startup type to 'Automatic' and enter a user. The SAPRouter should NOT run under the system account.
   
• To avoid the error message 'The description for Event ID (0) ...' in the NT Eventviewer you must make the following entries in the Registry. Under:
  HKEY_LOCAL_MACHINE -> SYSTEM -> CurrentControlSet -> Services -> Eventlog -> Application
  enter the following key:      SAPRouter
  
  Under this, define the two following values:
  
  EventMessageFile   (REG_SZ)    : <local_path>sapevents.dll
  TypesSupported    (REG_DWORD) :  0x7
  
  All required files (ntscmgr.exe, saprouter.exe, sapevents.dll) can be found in your usrsap<SID>sysexerun directory.

SAPRouter on a firewall computer:
------------------------------------------------

The NTSCMGR utility creates the SAPRouter Service with predefined dependencies from NT Workstation Service and NT Server Service. If the SAPRouter is to be installed on a firewall and if the Server Service is to be stopped, the dependencies of the SAPRouter need to be adjusted. To do so, open the registry editor (REGEDT32.EXE) and switch to the following subkey:
    HKLMSystemCurrentControlSetServicesSAPRouter
Double-click the parameter DependOnService on the right hand side of the window and delete the entry 'LanmanServer' from the displayed list. Exit the registry editor and restart SAPRouter Service.