Hi all,

This document is the first part of step by step system copy instructions SCM 7.0 based on NW7.01 (with LiveCache). Linux is x86_64bits and DB2 version is 10.1 FixPack3.

To prevent some misunderstandings and increase readibility, I prepared 3 seperate documents for DB2 restore and LiveCache MaxDB restore.

This part contains sapinst steps from the beginning until the "exit to restore DB2". Second part contains DB2 restore (from Snapshot) steps and third part contains LiveCache system copy instructions.

For the second part, that contains DB2 restore steps. go to link: SCM 7.0 (with LiveCache) DB2 Linux system copy-Part2/3 (DB2 restore)

For the third part, that contains LiveCache MaxDB restore screenshots and specific LC information, go to link : SCM 7.0 (with LiveCache) DB2 Linux system copy-Part3/3 (LiveCache restore)

IMPORTANT: Get the latest system copy guide from service.sap.com/instguides before you begin to execute the process. This document is designed as a secondary one, besides official system copy guide!

service.sap.com/instguides -> Alphabetical Index "S" ->SCM Server -> Using SCM 7.0 Server -> Installation Guides -> Select Linux and DB2.

SSID=Source SID

TSID=Target SID

Installation DVDs can be downloaded from Software Downloads | SAP Support Portal -> Inst. and Upgrades -> Alphabetical Index "S" ->SCM -> SCM 7.0 -> Installation -> Based on NW 7.01 .

• Download the latest version of SWPM from service.sap.com. I used this one : SWPM10SP07_6-20009701.SAR . After executing ./sapinst with root, point the path to SCM 7.0 system copy , like in the following screenshot.

• My source livecache and ABAP instances are on the same server. Below you see the target system filesystems.

• Enter target SID and FQDN. You can check your FQDN from /etc/hosts file. Then enter master password.

• Since we use snapshot backup to copy DB, select second option:

• Enter target DB TSID, ABAP schema user of source system, db2TSID password and other passwords. For ABAP schema user, you can check from source system via SAP GUI: System-->Status-->DB Owner (On the bottom right corner)

• Enter the path of kernel DVD. You can see the DVD number from screenshot.

• Enter LiveCache DB software owner information and installation media.

• Point DB2 DVDs for 10.1 FixPack3 and enter other DB2-specific information. Then give path for DB2 client/JDBC DVD.

• Provide system numbers and mark "Interrup before start". I chose this, in order to make some arrangements (eg. removing BTC processes to prevent background jobs to be executed immediately after system start). Provide source system 000 client DDIC password.

• Provide SL Controller DVD and confirm archive files to get unpacked.

• Provide LiveCache instance essential information. LiveCache user is SAP<LiveCacheSID>:

• Then you can see the a summary of parameters you have already provided. Have a look and start the process. It runs until "Exit to restore database":

To prevent some misunderstandings and increase readibility, I prepared 2 seperate documents for DB2 restore and LiveCache MaxDB restore.

For the second part, that contains DB2 restore steps. go to link: SCM 7.0 (with LiveCache) DB2 Linux system copy-Part2/3 (DB2 restore)

For the third part, that contains LiveCache MaxDB restore screenshots and specific LC information, go to link : SCM 7.0 (with LiveCache) DB2 Linux system copy-Part3/3 (LiveCache restore)

After completing DB2 restore, click OK and execute other SAPINST steps:

Hi All,

I need help here regarding one dump - MEMORY_NO_MORE_PAGING . Could any one please help me to guide the parameters needs to be tuned?

Is there any specific SAP Note which provide the Memory tuning ?

==============================================================================================

Hi

1. In which transaction code or report are you getting this dump? or could you share the full dump as attachment.

2. You can enable the transaction ST12 trace to find the root case of the transaction or reports.

3. Check you Memory & buffers over all usage

Refer the SAP KBA  1563748 - MEMORY_NO_MORE_PAGING" dump occurs

BR

SS

=================================================================================================

Hi Sriram,

Thanks for the help. Could you please tell me what are those parameters related to this dump.

What is the recommended parameter for any SAP system?

Hi Biswajit,

Hope you are doing good. For the dump MEMORY_NO_MORE_PAGING, follow the guidelines in note 133909 and try to increase the rdisp/PG_MAXFS value gradually. This would be enough.

Hope this helps.

_ _ _ _ _ _ _ _ _

Kind Regards,

Hemanth
SAP AGS
_ _ _ _ _ _ _ _ _

Thanks Hemanth,

I will follow this note for the increase of the parameter.

So now I want to close this thread, Thanks all for your support.

Hi Biswajit,

That’s great news. Please do keep us posted incase of any issues.You can double the value as an initial start. Also you can use /nSM04 -> Goto -> Memory to see a breakdown including SAP paging usage.

_ _ _ _ _ _ _ _ _

Kind Regards,

Hemanth
SAP AGS
_ _ _ _ _ _ _ _ _

=================================================================================

Hi Hemanth,

Thanks for your suggestion  . But I did not get any option on SM04---> goto -----> ? No option I get.

I am on SAP_BASIS=740 .

Is there any other way to get that value?

===================================================================================

Biswajit, this is the standard screen. Please can you check some other servers in your landscape as well?

Else try the report: RSM04000_ALV in /nSE38.

===============================================================================================

Hi Hemanth,

yes you are correct. But the program name you mentioned is not present in my system. But I checked it different system its working.

So this page memory section showing the user is using how much page ? correct? Could you please elaborate the screen info?

Yes, that is correct Biswajit.

Please see note 117907 - Display of SAP Memory usage in SM04 and ST02. " When you call SM04 and choose "Goto -> Memory", the system displays the memory that is allocated for each user; the bottom line specifies the total memory requirement for all users. The following memory types are available (for more information, see the online documentation for the memory management): Roll * Page * Mem(Total) * Mem(Priv.) " You can use this to get an overall picture of the engine and its memory requirements.

===============================================================================================

Hi Hemanth,

That's a very good SAP note you provided. The note itself says everything about the difference between ST02 memory and SM04 memory .

Thanks A lot.

I would like to invite you in another thread- http://scn.sap.com/thread/3721804

Check it from your side. The solution is still unknown.

This document was generated from the following discussion: MEMORY_NO_MORE_PAGING - Dump occurs frequently

Purpose

The purpose of this document is help in searching for specific content (relating to an error log) in the SAP Netweaver Application Server ABAP workprocess (or any other R/3 related service/process) traces. This can be a very tedious affair if many workprocesses are configured and this document explains how to do this from the SAP server end, rather than logging to the operating system to search in the actual trace file.

Example Scenario

Lets say the configured Single Sign On (SSO) setup between SAP Portal and the R/3 system fails with issues similar to:

Usually in such cases, the BASIS admin analyzes the J2EE and ABAP server logs. Now from the J2EE end, more details can be seen from the diagtool trace ( see http://service.sap.com/sap/support/notes/1045019 for SAP NW 6.40 and 7.00 servers and http://service.sap.com/sap/support/notes/1332726 for SAP NW 7.1+ servers), but when it comes to the ABAP server, the request can be handled by any one of the R/3 dialog workprocesses (usually one productive ABAP instance has 20 or more dialog workprocesses). Now searching all the dev_w0 files can be a cumbersome affair particularly if many ABAP instances are involved.


Solution

Use the ABAP server search function (TCode: /nSM51).

Type in the search text entry. There are some recurring error entries like “note 1055856” , “cannot create SAP logon ticket”, “TWPSSO2ACL”, “ticket issuer not trusted” etc. when there is an SSO issue. Or just use the user ID with which the issue was reproduced (or time or any other valid parameter).

The next screen shows you the exact trace file which has the error:

Navigate to the trace file (using /nAL11 or /nST11) and voila, you get more information:

Now, check the note and help documents to solve this. The only caveat is that this search is instance specific; if you have more than one ABAP server, this needs to be done individually on each instance.

NOTE: http://service.sap.com/sap/support/notes/1769367 :  Issuer of SSO ticket is not authorized also provides important information on troubleshooting such issues.

For a similar guide on checking application logs on an Application server JAVA, check:

http://scn.sap.com/community/netweaver-administrator/blog/2014/11/17/how-to-check-logs-for-particular-j2ee-application-issue

Hi All,

I need help here regarding one dump - MEMORY_NO_MORE_PAGING . Could any one please help me to guide the parameters needs to be tuned?

Is there any specific SAP Note which provide the Memory tuning ?

Refer the SAP KBA  1563748 - MEMORY_NO_MORE_PAGING" dump occurs

For the dump MEMORY_NO_MORE_PAGING, follow the guidelines in note 133909 and try to increase the rdisp/PG_MAXFS value gradually. This would be enough.

You can double the value as an initial start. Also you can use /nSM04 -> Goto -> Memory to see a breakdown including SAP paging usage.

This is the standard screen. Please can you check some other servers in your landscape as well?

Else try the report: RSM04000_ALV in /nSE38.

Please see note 117907 - Display of SAP Memory usage in SM04 and ST02. " When you call SM04 and choose "Goto -> Memory", the system displays the memory that is allocated for each user; the bottom line specifies the total memory requirement for all users. The following memory types are available (for more information, see the online documentation for the memory management): Roll * Page * Mem(Total) * Mem(Priv.) " You can use this to get an overall picture of the engine and its memory requirements.

That's a very good SAP note . The note itself says everything about the difference between ST02 memory and SM04 memory .

This document was generated from the following discussion: MEMORY_NO_MORE_PAGING - Dump occurs frequently

Oracle records database changes in its redo logs.

When Data Guard is activated, these changes are shipped from the primary to the standby and applied there.

This keeps the two databases synchronized with a time lag dependent on how often the changes are shipped and how long it takes to ship them.

ODG Standby Database Types

Physical Standby

• Identical to primary
• Updated via redo apply

Logical Standby

• Can be different structure to primary
• Updated via sql statements               

ODG – Available Modes

Mode

     =Maximum protection (LGWR, SYNC, AFFIRM)

               highest level of protection

               no data loss

               primary stops if redo data cannot be applied to the standby

     =Maximum availability (LGWR, SYNC, AFFIRM)

               high level of protection

               minimal data loss

               switches to maximum performance mode if standby unavailable

               automated catch-up of gaps if redo was not able to be written

     =Maximum performance (LGWR|ARCH, SYNC|ASYNC, AFFIRM|NOAFFIRM)

              medium level of protection

              some data loss

              primary not affected by standby unavailability

General objectives of DR system :

• Reduce recovery time in case of a disaster

                    Recovery Point Objective (RPO) = no more than X minutes of data loss

                    Recovery Time Objective (RTO) = Y hours from declaration of disaster

                    where X and Y are chosen by Project Build Team

• Reduce dependence on tapes

                    With tape based DR, tapes need to be shipped to DR site. Tapes can be lost or damaged with problems identified too late. ODG will know when a   redo log is missing or damaged at the point when it is to be applied to the standby not when the disaster has already occurred.

ODG Implementation Overview :

• Build Standby DB
• Setup network connection between primary and DR
• Refresh Standby with data from Primary DB (ship tapes or rsync over network)
• Synchronize databases (primary shutdown & apply redo logs or final rsync with primary in backup mode)
• Activate Oracle Data Guard
• Monitor (alert logs, network, primary db performance)
• Initial test - bring up standby to validate system

Configure required parameters on Primary and Secondary DB in init<SID>.ora or spfile as per Oracle online documentation - Data Guard

Concepts and Administration.

ODG Activation Overview

Once all ODG parameters are set, on the PRIMARY DB:

sqlplus / as sysdba

SQL> alter system set log_archive_dest_state_2=‘ENABLE';

SQL> show parameter log_archive_dest_state_2

Deactivate via:

sqlplus / as sysdba

SQL> alter system set log_archive_dest_state_2=‘DEFER';

SQL> show parameter log_archive_dest_state_2

ODG Troubleshooting

• Manual Monitoring options

          Database alert logs

          ST04N

• Automated Monitoring

          Alerts from OS level

          Solution Manger

          Oracle tools

Database alert logs

Oracle Alert Logs can be found in $SAPDATA_HOME/saptrace/background on both Primary database and Standby database.View the logs to check for messages / errors:

• more alert_<SID>.log | grep <ORA- / error / archival / GAP>
• tail –f alert_<SID>.log
• less alert_<SID>.log

Standby Database Backups

• Place the DB in read only mode
• Take a file system backup
• Place the DB back into managed recovery mode
• Clean up old redo logs after 2 successful backups

Disaster Recovery: High Level Overview

ODG Support: Common Problems

The following problems can occur :

• Missing logs
• Logs not being applied
• Cannot allocate new log
• Redo log storage filesystem full / filling

Problem: logs missing / not received

Problem: Redo logs not being applied

Problem: Can not allocate log

Problem: Redo storage full / filling

I have received complaint  from many users that short dump "DBIF_RSQL_SQL_ERROR" error occured in BI (i.e. BW) Quality system.

The error was "ORA-26040 data Block was Loaded using the NOLOGGING option".

This type of error  occurred only in BW system.   The problem occurred in BW Quality system after system refresh using restore / recovery Oracle database from BW Production system.

Tx code ST22

Execute brtool in ora<sid> to verify whether error occured pertaining to nologging.

Select  “6” – Check and verification

Select “1) Database System check

After Check database was completed, then view the check log file as shown in the figure below

As shown above ORA-01578 oracle data block corruption error was shown.  Normally block corruption is often due to a hardware error and there is a likely trace file or log entry that was created when it happened..

Open the trace file

I was  greatly relieved  that  from the trace file as shown in the above figure  the error ORA-26040 block corruption  was  the result of  NOLOGGING option.

The ORA-26040 error says that the “index”  was loaded using the “nologging” option and then possibly recovered from a backup before the nologging load.

The nologging option is a great way to speed-up inserts and index creation. It bypasses the writing of the  Primary Redo log, greatly improving performance .

However this approach is very dangerous if you need to roll-forward during this time period during a database recovery.

Therefore , before system refresh to BW Quality system, one must take a backup both before and after all nologging  operations.

It is not possible to roll-forward  through a point in time   since there are no images in the archived redo logs for this NOLOGGING operation. Hence full

backup  after performing any NOLOGGING operation is must.  Unfortunately  database backup team was not aware whether NOLOGGING was enabled for

some of the BW objects .

In SAP BW systems, ‘nologging’ for index creation from SAP level  is the default.

Indexes  for BW objects  “/BI*/F*” and “/BI*/E*”  are created with NOLOGGING . Hence drop only these indexes  “/BI*/F*” and “/BI*/E*”

The procedure for identifying the index name, partition table name  is described below

select segment_name,partition_name,segment_type ,block_id,blocks from dba_extents where (147445 between block_id and (block_id + blocks - 1)) and file_id=392 and rownum < 2

As shown above, the nologging was set on the creation of  index “/BIC/FGBIPC010~080”  for the given partition table name “/BIC/FGBIPC0100000000005”. Hence it is advisable to drop all the indexes  for the given partition table name rather than  dropping single  index  ““/BIC/FGBIPC010~080” .

The sql script to identify all the indexes for the given partition table name is as shown below

Then drop all the indexes associated with the given partition table as shown in the figure below.

Recreate the dropped indexes

The method to recreate the drop indexes can be done either using sql command  or ABAP report.

SAPLogin to  BW Quality system. Enter tx code se38 and report name “SAP_INFOCUBE_INDEXES_REPAIR "

Click execute (i.e. Press F8 key). New  screen appeared. Scroll down  continuously till you find green colour
highlighted as shown the figure below

Another method to to re-create the index using the following sql command

SQL> alter index  "<SAP-Schema>"."<index_name>"  rebuild partition "<SAP_SCHEMA>". "<partition_name>" online logging;

Execute brtool in ora<sid> to verify whether nologging  block corruption was cleared or not.

Select  “6” – Check and verification. Then Select “1"  Database System check

After Check database completed, then view the check log file as shown in the figure below

From the check log file,  nologging block corruption  for those  objects  was cleared i.e. ORA-01578 was not appearing in the check log file. This does not mean that the issue was resolved permanently. You need to execute database statistics and / or check database statistics frequently till no more error reported for other infocube objects.

Conclusion

• NOLOGGING option was enabled on couple of “/BI*/F*” and “/BI*/E*” objects in SAP BW production system. These are the infocubes objects. The indexes for these infocubes  objects had been created with “nologging”

• If you create an index with “nologging” option, Oracle database does not write the changes made to the index blocks to the online redologs. As a result the information is not written to the archive logs either.

• After restore to SAP Quality system during system refresh and apply recovery, many block corruption for infocube objects were reported  after executing brtools for database check or database statistics. That is an expected behaviour.

• Either drop or rebuild  all the infocubes indexes  immediately after system refresh and the error will be gone.

Best Practise  to prevent the NOLOGGING Block corruption after system  refresh from SAP BW Production to  SAP BW Quality

• Perform offline full database backup  in SAP BW production system– so no need to use recovery option  after restore to Quality system.

• In case offline database backup is not possible, then  use   online full database  backup both before and after all nologging  operations.

• NOLOGGING for index creation must be turned off with transaction code “SPRO” in BW production system. See the OSS note 1812719.

• SAP strongly recommend to perform database backup / restore / recovery  using  standard SAP BRbackup / BRrestore / BRrecovery tools .

• Use latest version and patch level  of BR*  tool  for your operating system. Brrestore and BRrecovery tool automatically repairs nologging indexes during brrecovery

• DO not use any other tool except SAP standard BR* tool.

FAQ

Question :  Why ORA-26040 data  block corruption  was not reported in SAP BW Production system after executing database check or database statistics  using brtools?

Ans: Because the SAP BW production system was never restored.  Incase if the SAP BW Production system crashed or or migration to new  hardware (Homogeneous System Migration), then data block corruption due to NOLOGGING on some tables  might be reported  in SAP  BW   Production  system  after restore and recovery  via incorrect version of brtools.

Author :          A Prasad Rao

Company:     Tata Consultancy Services Ltd

Eleven years experience as an Unix System and Oracle database Administration and sixteen years experience as SAP Basis Consultant.

Executed more than 10 SAP Technical Upgrade, combine Upgrade and Unicode conversion and SAP OS/DB Migration in different clients in geographically locations across the world.

Experience in SAP Basis troubleshooting, SAP Oracle performance issue.

Certified SAP OS/DB migration, certified OCP (Oracle Certification Professional) 9i Database and certified SAP WBE AS 640.

What is SAPS

SAPS is the standard SAP Benchmark of performance measurement ( i.e. measurement of CPU power). SAPS is an acroynm word for - SAP Application Performance Standard (SAPS).

It is hardware-independent unit of measurement that describes the performance of a system operation in the SAP environment. It is derived from the Sales and Distribution (SD) benchmark.

Hardware vendors do a benchmark on their hardware for SAP as per their methodology to see how many SD users can be supported. Each module has a weightage. The number of users in each module is converted to number of Normalized SD (NSD) and SAPS value can be obtained.

QuickSizer

Standard SAP sizing tool is available in SAP Marketplace called Quicksizer. However, SAP standard tool is for estimate only and is not accurate. It does not benefit to customers to get the exact sizing solution.

Sizing solution in QuickSizer tool is based on number of concurrent users in each module, approximate number of objects created in each module and approximate number of line items created in every hour.

However, practically, only business functionality who are familiar with business transactions may provide information regarding estimate number of objects created per hour in each module-wise and estimate number of  line items  created or processed in every hour. Basis or System Administration or technical consultants  are not sure what  data to be entered in order to fill up the sizing in Quicksizer tool.

The question is whether it is mandatory to fill up the standard SAP Quicksizng tool?. The answer is No.

SAP stongly advises customers to contact various Hardware vendors and obtain sizing Questionnaires form from each vendor. Filled-up Questionnaires form will be sent back to their hardware vendors. There is no need to enter number of objects  and / or  line number of items created or processed in every hour. Hadrware vendors have their own default values. They recommend configurations with sufficient headroom to avoid resource bottlenecks.

Basis consultants from implementation partner can assist customer to filled-up quationanaires form and also choose the correct hardware configuration.

Hardware vendors cannot help you estimate the impact of workload and infrastructure changes ind eployed environments.

Limitation in using SAPQuick Sizing Tools

Sizing calculation is not an accurate. It is an estimate. SAP advises customers to contact Hardware supplier to provide sizing solution based on the customer's requirement. Every Hardware supplier has its own sizing methodology.

Quicksizer estimates are based on assumptions - SAP  assumtions about resource requirements based on transaction volumes generated by the user and the hardware vendor's assumption about how deployed application will use system resources.

Quicksizer cannot help you estimate the impact of workload and infrastructure changes in deployed environments. When the CIO asks, "What will it take to support another five hundred users?" or "Can we do multiple application and infrastructure configurations?"

Inaccurate : No consideration of workload and infrastructure changes while sizing capacity and performance. Accuracy has been estimated at 20%. Hence it would be difficult to obtain the exact accuracy of SAPS value.

The following lists are not taken into account in SAP Quicksizer calculation.

• Unicode

• Custom Objects

• Workload (batch processing, print)

• Interface

SAPS Sizing Methodology

In this document, SAPS calculation is taken on the basis of only number of users and workload. SAPS calculation is taken into account only for SAPECC 6.0 with EHP and SAP Netweaver 7.0 and higher. Also this document is valid for  medium to large sized companies i.e. up to 3000 users and database size up to 2TB. This document is not valid for users beyond 3000 and database size  above 2TB.

Classification of SAP users:

Based on the working hours, SAP users are classified into Low, Medium and High users.

Low users:          Users that spend less than two hours working in SAP (Top Management levels such as Executives, CFO, CIO, Vice-President, General Managers, etc)

Medium users:    Users that spend around four hours in SAP (Middle executives level such as Manager, Dy. Manager, Sr. Engineer, Account Officer etc)

High users:          Users that spend more than four hours in SAP (Clerk, Supervisors, Junior Engineer, Junior Accounts officer, etc)

Based on my  experience in various Implementation and Upgrade projects , the SAPS value is not influenced by the above-mentioned type of users. Hence SAPS value does not vary between High, Medium and Low users.

Normalized  SD users:

Different modules have their own weightage. There are many various modules in SAP R/3 or ECC systems.

These are

PP          Production Planning

MM         Materials Management

SD          Sales and Distribution

FICO       Finance and Controlling

HCM       Human Capital Management

QM         Quality Management

Classify the users  who are involved in business transactions in each module. For example, if the number of users involved in Production Planning (PP) is 10, convert number of PP users to SD users. Thus one PP user is equivalent to 1.3SD user because  in the PP module, the number of Line items created per one PP transaction is more than the number of line items created in one SD transaction. Therefore for ten PP users, number of SD users will be 1.3*10 = 13SD users.

Similarly, one Human resources (HR) user equals 0.4SD user becasue in HR module there is less number of line items created per one HR transactions than in one SD transaction. One Plant Maintenance (PM) user is equivalent to 1.1SD user .

Hardware vendors do a benchmark on their hardware for SAP as per their methodology to see how many SD users can be supported. The number of users in each module are converted into number of Normalized SD user (NSD) and SAPS value can be obtained.

SAP QuickSizer tool: To Obtain SAPS for number of named users

The tool is available in SAP MarketPlace website. This requires S-userid and password. CLick the following website link

http://service.sap.com/quicksizing

(A)     Sample result for SAPS value is  shown in the figure

SAPS value based on Workloads

After obtaining SAPS for given users from SAP QuickSizer tool, additionally, the following lists must be taken in to account for calculating SAPS value.

These are

• Custom Objects

• Interfaces

• Batch Loads

• Unicode

(B)     Rule of Thumb for Custom Objects:

Nearly all the SAP customers have large number of custom objects. Objects can be programs, tables, function modules etc. Custom programs consume much more SAP extended memory and high CPU utilization takes place because  of inefficient coding or expensive sql coding. Hence SAPS value for custom objects is also to be considered.

Based on EWA reports from various customers, it is recommended that for custom objects with reporting required SAPS  to be increased by 30% as a user executes most of the custom objects in a Dialog workprocesses. Thus taking custom objects into account

New SAPS for Custom objects = 30% of SAPS obtained from SAPQuickSizer tool

(C)     Rule of Thumb for Interfaces

Additionally 15 % more for standard SAP BI interface with SAP ECC system is taken into account (since SAP Business Intelligence i.e. BI 7.0 extracts data from ECC 6.0, hence heavy processing takes place in ECC 6.0 system (see the transaction code sm50 with user "Aleremote" )  thus drastically lowering the performance . Hence required SAPS value is increased by 15%).

Furthermore, Non-SAP interface with ECC system is to be taken into account i.e. ECC system send / receive data from Non-SAP using IDOC. Hence required SAPS value is increased by 5%.Thus for SAP Bi and  Non-SAP interafce with ECC system = 15+5 = 20% . Therefore

New SAPS value for Interface = 20% of SAPS obtained from SAP Quick Sizing tool.

(D)     Rule of Thumb for Batch Loads

Experience showed that batch load depends on the number of application servers including primary instance.  Number of dialog instances required depends on the number of users executing batch loads.

For example, assume for 1000 named users. one Primary instance and one Dialog Instance  installed.  In this scenario, batch loads for two servers will be extremely high where large number of  batch jobs processing takes place becasuse batch jobs are distributed in only twos servers only.

However, if there are three Dialog instance servers installed in addition to Primary instance server, batch jobs are distributed in four servers . Hence load in each server can be medium to high for same number of users.

If there are more than five Dialog instance servers  installed in addition to Primary instance server, batch jobs are distributed in six servers or more. Thus load in each server can be low to medium.

Note that, experience shows that for more number of batch jobs running in parallel in all application servers installed, high IO utilization will take place on database server.  This will  slows  down overall Production system performance i.e. there will be high intensive read / write operation on Disk / filesystems storage in  database server.

Thus it is advisable to schedule the jobs  after office hours. Also It is advisable not to increase number of background work processes beyond 3  during office hours i.e. should not be > 3 background workprocesses in each application servers including primary instance server. This will improve  IO  performance and enable end users to work in SAP production system comfortably.

It is recommended that 25% extra be taken account for  up to 3000 named users

Thus new SAPS value for Batch load = 25% of SAPS obtained from SAP QuickSizer tool

(E)     Thumb rule for Unicode System loads

Unicode systems use between 1 and 5 bytes of space to store single characters. As a result, the resources of the system could be doubled.

Practically, the load on the CPU caused by the applications, increased by about 25-35%. The load on the RAM, again caused by application programs / transactions  increased by about 50%.

It is advisable that 25% extra be taken so the required SAPS  is increased by 25%  for the databse size up to 2.5TB and irrespective of the number of users.

Thus SAPS for unicode system = 25% of SAPS obtained from SAP Quicksizer tool.

(F) Final SAPS result for Production system

Total SAPS value (F)  = SAPS value obtained from SAP quick sizer tool (A) + SAPS value obtained from Custom Load (B) + SAPS value obtained from Interfaces (C) + SAPS value obtained from Batch load (D) + SAPS obtained from uniocde (E) .

Sample example is shown in the figure below.

Accuracy has been estimated at  55% because  we have taken estimate value for custom loads, interfaces, uniocde  and batch loads. Also other processes such as data Archiving, Monthly/Quarterly/yearly closing account , full offline/online backup etc are not taken into account.

SAPS for Non-Production systems

SAPS for Development server

Only business configuration data is created in the development system. There will be no master and applications data . Custom objects are created in development server and also unit testing takes place in this server.

Thus only few developers will be used in the development server.

Thumb Rule: 35% of  Final SAPS taken in Production system  (F) will be used  for Development server.

SAPS  for Quality Server

In Quality system, data such as Master, Applications, User, Business configuration will be present in the Quality server. Periodically, data in the quality system is refreshed with full Production data.  Customizing data and / or custom objects imported into Quality system by means of transport requests that were created and released in the development system. After transport requests imported into the quality server, business consultants test business transactions or reports to ensure no error occured in the quality system.

Thus there will be some workprocesses (Dialog / background) running in the quality server during testing the transactions or reports.

Thumb Rule: 65% of  Final SAPS taken in porduction system (F) will be used for Quality server.

FAQ

Usually similar questions arises from various SAP customers

1)           What SAPS value are required for database server and SAPS value for Central Instance Server ?

Though SAP recommends 30% of Final SAPS value for database server and 70% of Final SAPS value for Central Instance server.

I do not agree with SAP recommendation as the performance issue is mostly due to high database server load because more number of workprocesses status in "running" (as in transaction code sm50 or sm66) connected to database server for data fetch  ( you can see in transaction code sm50 or sm66 "Sequential database read" or commit data i.e. saving records or line items to the database server ((high intensive Read and Write operations on the Disk storage  in the database server causes extremely high IO load).

Hence it is strongly advisable to have higher SAPS value for Database server.

2)     How many Application servers are required i.e. required number of Dialog Instance servers ?

Total number of workprocesses  depends on the number of CPU or cores installed in the server. One core (  for CPU speed less than 3GHz) can handle two  workprocesses. For CPU speed is 3GHz or higher, one  core can handle five  workprocesses. So for example if Central Instance has 6 cores and its CPU speed is 3.2Ghz then maximum number of workprocesses permissible is 30.  To increase beyond workprocesses, you need additional application server (i.e. Dialog Instance Server).

3) What about SAPS value after version upgrade ?

For version upgrade from SAP R/3 4.6C or below to SAP ECC 6.0 with EHP 4 or higher  or SAP WEB AS 620 and below upgrade to SAP Netweaver 7.3 and higher  without unicode   existing SAPS to be increased by 40% or by 60%  with unicode. 

For version upgrade from SAP ECC 5.0 to SAP ECC 6.0 with EHP 4 or higher or SAPWEB AS 640 and higher upgrade to NW 7.3 and higher. existing SAPS to be increased by 20% for non-unicode and 30% for uniocde

SAPS is not relevant for for EHP upgrade or SP stack upgrade,  However, for additional number of users, SAPS calculation is to be taken in to account.

Summary

Quicksizer estimates are based on assumptions. This white paper describes sizing exercises which includes custom objects, interfaces, Batch loads and Unicode to obtain SAPS in more accurate results.

Related Content

http://www.sap.com/solutions/benchmark/index.epx

http://service.sap.com/quicksizer   - For Sizing exercises,  QuickSizer tool from SAP MarketPlace

http://www.sap.com/solutions/benchmark/pdf/IBM_NewsJuly2010.pdf

SAP Performance tuning with Oracle 11G in OS/ AIX

Summary:-

This document contains how to tune the parameters in SAP level as well in database level based on your hardware, SAP application and database configuration.

Author: Brindavan Mookaiah

Designation: SAP BASIS Consultant

Instruction

The information about the parameters which show here are after analysis from our system landscape. It might be different from your landscape. If you are facing any performance issue in your system then you should analysis first for past three months data like response  time, CPU utilization , database load , new z*program ,expensive SQL statement ,snote , might be if user access backend system from portal..etc…  . This document only shows how to analysis and do the tuning based on the hardware, SAP application and database. We have analyzed and found that nothing can be increased any hardware or update patches or any z*program created by ABAP developers (include any new variants on existing z*program) or any expansive SQL statement using like “join queries ,using selection screen more” are causing performance issue.  Here we have the system performed very well before and recently it causing performance issue due to the RAM has taken and shared to some other system, this caused performance issue in our system. But, system is not overloaded with any new SAP application changes, so we have to analysis and tune the parameters based on current RAM.

Information on eye

CPU utilization : If your CPU utilization is too high and not with SAP application and database then check with OS team to find the which process causing slow the system or might be increase the CPU resource

Database: If the system loaded with only database and not with CPU or RAM or SAP application then analyze the database and tune the parameters in database level .

SAP Application : If system slow due to the SAP application then tune the parameters like “abap/heap_area_total  , abap/heap_area_nondia , abap/heap_area_dia , EM/TOTAL_SIZE_MB” based on your hardware RAM or check the active BG job or Z* program ,expensive SQL statement  can be tune by ABAP pers .

Here we have the system performed very well before and recently it causing performance issue due to the RAM has taken and shared to some other system, this caused performance issue in our system.

SAP Appliaction : PPM system

OS                    : AIX

Database           : Oracle 11G

We have checked first about the CPU utlizaton at OS level using nmon on AIX operating system.

Login in to OS level with "SIDADM" and type command " nmon"

and the type "C"

To check the RAM type "M"

To check the top process the type "topas"

Here we have found that the system is runnin very less free space of RAM.So we have increase the RAM or you have to find anyother way to tune the parameters to fix the perfomance issue.

Now check the SAP appliaction  and Database as well.

We have analyzed the below parameters which are assigned value in SAP and DB level.

Based on our analysis we found that the system heap memory is not used at all.  So, we are planning to take 2GB of memory (heap memory) and assign to DB.

We have some database buffer cache issue which physical read is too high not sufficient.

Also we are planning to tune the extend memory as well.

In SAP level you check the various parameters from t-code  ST02  and T-code DB02 for database analysis

Please find the detail information to tune the parameters in SAP and DB level.

In SAP side we have

EM/TOTAL_SIZE_MB = 18432 MB

abap/heap_area_dia = 4000683008Bytes

abap/heap_area_nondia = 4000683008Bytes

abap/heap_area_total = 8000000000Bytes

We will  change the parameter like below

EM/TOTAL_SIZE_MB = 10240MB

abap/heap_area_dia = 3000683008Bytes

abap/heap_area_nondia = 3000683008Bytes

abap/heap_area_total = 6000000000Bytes

By this way we will release 2GB of memory (1GB from abap/heap_area_dia and 1GB from abap/heap_area_nondia), this 2GB will be shared to DB parameter as shown below.

In DB side we have,

Buffer Cache Size (DB_CACHE_SIZE): 2617245696Bytes

Shared Pool Size (shared_pool_size): 2617245696Bytes

Maximum SGA Size (sga_max_size): 5284823040Bytes

We will  add this additional 2GB  to the below parameters,

Buffer Cache Size (DB_CACHE_SIZE): 3171557120Bytes

Shared Pool Size (shared_pool_size): 2931818496Bytes

Maximum SGA Size (sga_max_size): 6284823040Bytes

The below information is explained  about the current database buffer and shared pool size in database level.

Current running Database buffer case size :-

Login into OS level with "oraSID" and excute the below SQL command

COLUMN size_for_estimate FORMAT 999,999,999,999 heading 'Cache Size (MB)'

COLUMN buffers_for_estimate FORMAT 999,999,999 heading 'Buffers'

COLUMN estd_physical_read_factor FORMAT 999.90 heading 'Estd Phys|Read Factor'

COLUMN estd_physical_reads FORMAT 999,999,999 heading 'Estd Phys| Reads'

column size_for_estimate       format 999,999,999,999

column buffers_for_estimate    format 999,999,999

column estd_physical_read_factor format 999.90

column estd_physical_reads       format 999,999,999

SELECT size_for_estimate, buffers_for_estimate

     , estd_physical_read_factor, estd_physical_reads

  FROM V$DB_CACHE_ADVICE

WHERE name          = 'DEFAULT'

   AND block_size    = (SELECT value FROM V$PARAMETER

                         WHERE name = 'db_block_size')

   AND advice_status = 'ON';

The following output shows that if the cache was 2,160 MB, rather than the current size of 2,400 MB, the estimated number of physical reads would increase by a factor of 1.05.This means it would not be advisable to decrease the cache size

However, increasing the cache size 3024  would potentially decrease reads by a factor of  5%

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

                                Estd Phys    Estd Phys

Cache Size (MB)      Buffers Read Factor        Reads

---------------- ------------ ----------- ------------

             240       29,565        4.97  132,153,593      -->   10 % of current szie

             480       59,130        3.15   83,773,834

             720       88,695        2.24   59,611,205

             960      118,260        1.74   46,099,883

           1,200      147,825        1.45   38,412,908

           1,440      177,390        1.28   33,925,209

           1,680      206,955        1.17   31,088,982

           1,920      236,520        1.10   29,228,940

           2,160      266,085        1.05   27,878,798    

           2,400      295,650        1.01   26,880,033     -->  Current size

                               Estd Phys    Estd Phys

Cache Size (MB)      Buffers Read Factor        Reads

---------------- ------------ ----------- ------------

           2,496      307,476        1.00   26,568,531

           2,640      325,215         .98   26,150,487

           2,880      354,780         .96   25,506,595

           3,120      384,345         .94   25,026,134

           3,360      413,910         .93   24,608,745

           3,600      443,475         .91   24,254,741

           3,840      473,040         .90   23,938,076

           4,080      502,605         .89   23,696,871

           4,320      532,170         .88   23,504,570

           4,560      561,735         .88   23,336,835       -->  200% Current size

                                Estd Phys    Estd Phys

Cache Size (MB)      Buffers Read Factor        Reads

---------------- ------------ ----------- ------------

           4,800      591,300         .87   23,175,753

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Checked the share pool size with following SQL Command

SELECT POOL,NAME, ROUND(BYTES/(1024*1024),2) FREE_MB FROM V$SGASTAT WHERE POOL='shared pool'AND NAME='free memory'ORDER BY BYTES DESC;

Shared pool size :-

Current size       : 2496 MB

Free space size : 363 MB

You find the total SGA memory alloacted as well with following Command

select component,current_size from v$SGA_DYNAMIC_COMPONENTS;

We have only 363 MB free space left . So , we are planning to increase 2796 MB.  We have done  SGA monitoring & PGA also , In SGA montoring we have found there is no memory available.

we have checked in SAP level using T-code DB02.

And check the startup overhead in Shared Pool of  Database is 19321563Bytes as well.

By increasing the above DB parameters we can reduce the overhead.

By this way the  system will be bit faster than perivous.

Note: Before changing any parmeters do the complete anaysis from hardware side,database side and SAP side .There are so many parameters in SAP side to tune, before doing any parameters changes in SAP side raise OSS message to SAP and get their suggestion & recommendation from them.

Heterogeneous System Copy - R3load Method

As I described before, the source SAP system (W8M) is installed in Windows Server 2008 (R2) on a MaxDB 7.8 (x64) database. For this purpose, I need to use the SAP specific copy method - R3load (export and import) - because I will have a different database engine/vendor in the target platform. The R3load method consists of the export of all source database contents and then the import of all that content in the target SAP system database (Oracle database in this specific case). Therefore there are two stages:

s

• 1. Export Phase (source system)
• 2. Import Phase (target system)

1. Export Phase

Thisexport phasewas performed in the source server (sapwinmax). For this I usedthe Software Provisioning Managertool(version70SWPM*). For this purpose I ran the following two phases:

s

• 1.1. Export Preparation
• 1.2. Database Instance Export

1.1. Export Preparation

Finish with success:

1.2. Database Instance Export

Note: This warning is related with a task that I didn´t performed before and it is described in the system copy guide at chapter "Generating DDL Statements". So for this you need to go to transaction SE38 and run the ABAP report SMIGR_CREATE_DDL:

... export continuation:

As in my case was not generated any file, I selected the option "No, skip the report and run the export without SQL files"

You can see in the following video all the details of the "Parameter Summary" screen:

Finish with success:

- Size of the export directory that was generated at the end of this Export Phase:

=> CHECK THE CONTINUATION OF THIS DOCUMENT IN THE FOLLOWING LINK:

SAP Migration – Win/MaxDB <=> Win & Linux/Oracle DB - PART 3

2. Import Phase

As I described before, I will perform a SAP distributed installation in the target side/server, this is, the SAP itself on Windows Server 2012 (R2) and the Oracle database (11.2.0.4) in Linux SLES 11 SP3. For this installation activity I will use the export dump that was created during the export phase that I described in the PART 2 of this document. During the following procedure I will show you how to perform the import phase of this heterogeneous system copy activity. As I said before, for the SAP installation you should never use the <sid>adm user, use a non-SAP OS user, for example in my case I have a specific OS user for this task: sapadmin (this user must be administrator of the server).

I ask you attention for some details that I will mention here, specialty the task that it´s necessary to run in linux side, in order to run the Oracle database installation you must first prepare this host with specific user (<sid>adm) and groups (sapsys; sapinst), thus avoiding some errors, at level permissions, during the Database Instance installation. This user and group must previously exist in the linux side for this type of implementation and for this reason you need to run the "Global Host Preparation for an ABAP System" that I will mention more later in this document.

This import phasewas performed in both target server, in Windows Server 2012 (R2) and Linux SLES 11 SP3 (sapwinci and saplindb). For this I usedthe Software Provisioning Managertool(version70SWPM*). For this purpose I will run the following four phases:

s

• 2.1. ASCS Instance installation (sapwinci host - Win Srv 2012 (R2));
• 2.2. Global Host Preparation for an ABAP System (saplindb host - SLES 11 (SP3));
• 2.3. Database Instance installation (saplindb host - SLES 11 (SP3));
• 2.4. Central Instance installation (sapwinci host - Win Srv 2012 (R2)).

2.1. ASCS Instance installation (sapwinci host - Win Srv 2012 (R2))

Press "OK"

Press "No"

You can see in the following video all the details of the "Parameter Summary" screen:

Finish with success:

- New LOD system in SAPMMC console (ASCS Instance):

- New OS administrators users lodadm and sapadm:

- New OS users -- lodadm, SAPServiceLOD and sapadm:

2.2. Global Host Preparation for an ABAP System (saplindb host - SLES 11 (SP3))

In way to understand why I run this phase (that is not mentioned in SAP installation guide), please read the introduction section at the beginning of this document part 3.

- As "root" run the Software Provisioning Manager (70SWPM version):

You can see in the following video all the details of the "Parameter Summary" screen:

Finish with success:

As you can see in the following images, the specific user and groups werecreated in linux host(lodadm; sapsys; sapinst). For this verification you just need to check the content of /etc/group by running the command cat /etc/group:

Note: Now this server are ready to host the oracle database, now you can start the next step - Database Instance installation.

=> CHECK THE CONTINUATION OF THIS DOCUMENT IN THE FOLLOWING LINK:

SAP Migration – Win/MaxDB <=> Win & Linux/Oracle DB - PART 4

2.3. Database Instance installation (saplindb host - SLES 11 (SP3))

- As "root" run the Software Provisioning Manager (70SWPM version):

==>  Error - Profile Directory doesn´t exist  <==

Node /sapwinci/LOD/SYS/profile does not exist

At this point we need to give the path of SAP profile directory, in this specific case this profile directory is in windows host which is, as you know, the host where I installed the SAP ASCS Instance. Therefore it´s crucial that both servers are connected to each other and you must ensure that the linux server (saplindb) has permissions to read and write on windows server (sapwinci) in this specific path/directory.

To correct this issue you need to check first the .host file in windows and linux server. For example in windows host you need to insert the IP address and the hostname of linux server:

Then you may perform a verification and test the connection between the servers using the ping command:

Besides that you need to check the permissions of \sapmnt directory which is the shared directory in windows server for the SAP directory path. In my case I add full control to the group Everyone (which is not recommended in a production environment):

You need to mount the windows share profile directory /sapwinci/LOD/SYS/profile and for this you first need to create a directory, for instance the /sapwinci and then you need to mount the /sapwinci/sapmnt in the linux server using the following command:

mount -t cifs //sapwinci/sapmnt -o username=sapadmin,password=******,uid=lodadm,gid=sapsys /sapwinci

After all this tasks and corrections, I started again the software provisioning manager and it stopped again with an error, this one related with a specific profile parameter.

==>  Error - Profile Directory doesn´t exist  <==

Profile parameter rdisp/msserv_internal is not set for instance ASCS00/LOD on host sapwinci.

SOLUTION: Set the parameter in the default profile and restart the instance.

For more information see SAP Note 821875

Check if the rdisp/msserv_internal has the value 3900 (39nn):

Restart the SAP system (LOD system):

You can continue with the Database Instance installation:

Note: For a heterogeneous system copy you will need to generate the migration key at support.sap.com/migrationkey. Enter the installation number of your source system when prompted.

You can see in the following video all the details of the "Parameter Summary" screen:

This is the size of file system before the Oracle database installation:

=> CHECK THE CONTINUATION OF THIS DOCUMENT IN THE FOLLOWING LINK:

SAP Migration – Win/MaxDB <=> Win & Linux/Oracle DB - PART 5

Important: Duringthe "Database Instance" installation the Software Provisioning Manager stops and prompts you to install the Oracle database software:

You need to proceed as follows to install the Oracle 11.2g database software (11.2.0.4 version).

==>Oracle Database Installation<==

Important: You need to run the Oracle RUNINSTALLER with the user ora<sid> (in this specific case the oralod user).

- Updating the SAP RUNINSTALLER Scripts

s

If a newer version is available, I recommend that you update the Oracle Installation scripts, which are attached to SAP note 1524205 (Oracle 11.2.0: Database Software Installation). In my specific case all the installation scripts are up to date, in the latest version (Patch Level 043).

- Installing the Oracle Database Software

s

For more information about the current patch set and how to install Oracle database 11.2 software, see the following SAP notes:

s

1431799 - Oracle 11.2.0: Current Patch Set

1524205 - Oracle 11.2.0: Database Software Installation

For more information about the troubleshooting installation read the SAP note 1431796 (Oracle 11.2.0: Troubleshooting the Software Installation).

You need to start the X in the linux server. For this you can use a X software, for example the Xming software:

Start the Oracle Universal Installer (OUI) with the Oracle database software owner, the user ora<sid>, as follows:

Press "Yes".

Press "Yes".

Press the button "Fix & Check Again".

The OUI prompts to execute some scripts as "root":

The checker informs that it is necessary install the sysstat package. You can execute the installation of this specific package through the YaST2:

After the installation of sysstat package you can proceed withthe installation:

Once again the OUI prompts to execute some scripts as "root":

Note: The patch set software is now installed in the installation Oracle home. You now have to install the required SAP Bundle Patch. For this installation I will not perform this installation but it's highly recommended that you apply the latest SBP, it contains a lot of errors corrections, relevant PSU (Patchset Updates), merge fixes, oracle patches, etc. For more information about the SAP bundle patch please read the following SAP notes:

s

1431793 - Oracle 11.2.0: Upgrade Scripts

1027012 - MOPatch - Install Multiple Oracle Patches in One Run

1431800 - Oracle 11.2.0: Central Technical Note

Since all the tasks were done, you can proceed with the SAP installation wizard (Software Provisioning Manager) from the stage that it stopped (Press "OK"):

Finish with success:

This is the size of file system after the Oracle database installation:

=> CHECK THE CONTINUATION OF THIS DOCUMENT IN THE FOLLOWING LINK:

SAP Migration – Win/MaxDB <=> Win & Linux/Oracle DB - PART 6

2.4. Central Instance installation (sapwinci host - Win Srv 2012 (R2))

Start the installation of the last phase - Central Instance:

You can see in the following video all the details of the "Parameter Summary" screen:

Finish with success:

- New LOD system in SAPMMC console (with ASCS and CI Instances):

Post-Installation

I will not describe here in detail all the follow-up activities that you need to perform after a heterogeneous system copy, this is not the goal of this document, but you need to read and complete all the steps that are mentioned in the SAP system copy guide and also in the SAP installation guide. Next I'll describe some tasks that are required to do in a similar scenario:

s

- Performing a full installation backup (you can use the Oracle BR*Tools);

s

- Install the SAP license;

s

- Checking the recommended Oracle database parameters (Check the SAP notes 1431798 (Oracle 11.2.0: Database Parameter Settings); 1171650 (Automated Oracle DB parameter check));

s

- Updating Oracle optimizer statistics (Check the SAP note 974781 (Oracle internal maintenance jobs);

s

- Delete all entries from the following tables: DBSTATHORA, DBSTAIHORA, DBSTATIORA, DBSTATTORA;

s

- Delete the user OPS$<SOURCE_SAPSID>ADM;

s

- Update the SAP Kernel and the BR*Tools (DBA* files);

s

- Check the RFC´s, Jobs, STMS, etc...

=> Other tips:

s

- Check the SAP and Oracle services:

s

1. Check if the database is running via sqlplus (select status from v$instance;):

2. Check in the linux host all the oracle processes:

3. Check in the windows host all the SAP services:

- Stop SAP / Oracle database (LOD system)

s

1. Stop the SAP system (LOD) in the sapwinci host as <sid>adm:

2. StoptheOracledatabase (LOD) in the saplindb host (using the sqlplus):

3. Stop the Oracle listener service as ora<sid>:

- Start SAP / Oracle database (LOD system)

s

1. Start the Oracle listener service as ora<sid>:

2. StarttheOracledatabase (LOD) in the saplindb host (using the sqlplus):

3. Start the SAP system (LOD) in the sapwinci host as <sid>adm:

- Disable Archive log mode (NOARCHIVELOG):

s

First of all always make sure that you got a backup plan for your SAP system and in this case you need to set the oracle database to "Archivelog Mode" so you can be able to recover your system. But sometimes you may need to set your oracle database to "Noarchivelog Mode", for instance when you run the SGEN transaction in your SAP system. In this kind of tasks, I always recommend that you change it because if you don´t do this the database will generate a lot of archive logs and possibly will completely fill up the size of your file system. For this task you need to stop the SAP system and then use the following SQL commands:

- Disable the Oracle password life time:

s

Just a quick reminder about maybe the most common small problem in new 11g installations / upgrades.

When you entering in the Oracle 11g world, remember to do something to the default setting of password life time of 180 days. If you do nothing, your users / schema, the SAP system will cease to work after 180 days, so this is very important. For this you need to run the following sql command:

select profile, limit from dba_profiles where RESOURCE_NAME='PASSWORD_LIFE_TIME';

s

alter profile default limit PASSWORD_LIFE_TIME unlimited;

- BR*Tools for Oracle DBA:

s

BR*Tools is the program package containing BRSPACE, BRBACKUP, BRARCHIVE, BRRESTORE, BRRECOVER, BRCONNECT, and BRTOOLS.

BRTOOLS is the program that displays the character-based menus from which the other BR programs are called. It works together with BRGUI to generate a graphical user interface.

As ora<sid> run the command "brtools":

- DBA Cockpit

s

The DBA Cockpit is a platform-independent tool that you can use to monitor and administer your database. It provides a graphical user interface (GUI) for all actions and covers all aspects of handling a database system landscape.

You access the DBA Cockpit by calling transaction DBACOCKPIT:

Motivations

I decided to create this document because I see a lot of doubts in a lot of SCN threads and all over "SAP world" not only regarding the process of SAP heterogeneous system copy but mainly in how to perform an installation of SAP system on two differents/heterogeneous platforms, in this particulary case, a distributed SAP installation between Windows and Linux servers. Therefore I decided to perform these two topics in one only activity and describe them in detail during this document. This document is organized in six parts:

== Part 1 ==

- Motivations

- Overview

- Considerations

- Documentation

- SAP DVD Media

- Operating System Preparation

  -- Linux Server Preparation (SLES 11 SP3)

  -- Windows Server Preparation (Win Srv 2012 (R2))

 

== Part 2 ==

- Heterogeneous System Copy - R3load Method

  -- 1. Export Phase

    --- 1.1. Export Preparation

    --- 1.2. Database Instance Export

 

== Part 3 ==

  -- 2. Import Phase

    --- 2.1. ASCS Instance installation (sapwinci host - Win Srv 2012 (R2))

    --- 2.2. Global Host Preparation for an ABAP System (saplindb host - SLES 11 (SP3))

 

== Part 4 ==

    --- 2.3. Database Instance installation (saplindb host - SLES 11 (SP3))

 

== Part 5 ==

      ---- Oracle Database Installation

        ----- Updating the SAP RUNINSTALLER Scripts

        ----- Installing the Oracle Database Software

 

== Part 6 ==

    --- 2.4. Central Instance installation (sapwinci host - Win Srv 2012 (R2))

- Post-Installation

  -- Check the SAP and Oracle services

  -- Stop SAP / Oracle database (LOD system)

  -- Start SAP / Oracle database (LOD system)

  -- Disable Archive log mode (NOARCHIVELOG)

  -- Disable the Oracle password life time

  -- BR*Tools for Oracle DBA

  -- DBA Cockpit

Overview

This document will show how to perform a SAPheterogeneoussystem copy (also knownas "Migration of SAP System") in a heterogeneous platforms, this is, the target environment it will be a SAP system installed in a windows server and the Oracle database will run in a linux server. In this specific case the SAP system product that I will copy/install during this activity is a SAP SRM 7.0 / NW 7.01.

The SAP sourceenvironment is astandardSAPinstallation (in one server) running in a WindowsServer 2008(R2) on a MaxDB7.8(X64) database. By the other hand the SAP targetenvironmentwill be installed indistributed platform (in two servers) inheterogeneous environments, I mean, the central SAP instance (ASCS andthePAS services) will beinstalled in a WindowsServer 2012(R2) andthe database instancewill be installed on an Oracle11.2g(11.2.0.4) running in a Suse Linux Enterprise Server 11 (SP3).

Considerations

- The SID of the SAP source system is W8M and the SID of the SAP target system will be LOD.

- Both SAP installations (at source and target) were performed locally, this is not a domain installation, I didn´t use any domain users only local users, therefore this is a SAP local installation.

- You need to guarantee that you don´t use the <sid>adm user to perform he SAP installation, for this purpose you need to create a local user and add this user to the Administrators group in Windows Server.

- The Windows Server has 2 Gb of RAM and the Linux SLES has 3 Gb of RAM.

- The source environment (Central Installation) has the following server:

• Windows Server 2008 (R2) – sapwinmax

- The target environment (Distributed Installation) has two servers:

• Windows Server 2012 (R2) – sapwinci
• Suse Linux Enterprise Server 11 (SP3) – saplindb

- Overview of the architecture:

Documentation

SAP DVD Media

Operating System Preparation

This chapter resume some tips that you may consider as an important requirement when you want to install a SAP system in Linux and Windows operation systems.

Linux Server Preparation (SLES 11 SP3)

As you may know SAP supports three linux distributions (Oracle Linux OS, Red Hat Enterprise Linux and SUSE Linux Enterprise Server) --> SAP on Linux

In this specific case I use Suse Linux Enterprise Server where I will install the Oracle database. I installed the SLES 11 SP3 version that is specific for SAP system applications. You can perform the download of this distro here: SUSE Linux Enterprise Server for SAP Applications

This is a overview of some things that you may set as a requirement for a SAP installation or in some specific cases, as this is, when you want to install an Oracle database over a Linux server (SLES).

- Login as "root":

- Set the "Clock and Time Zone" to your own region and time zone:

- Set the correct settings in "Keyboard Properties":

- Linux SLES registration (this task is very important because you will need to install an individual linux package and for that you need to register your linux):

- Setting up the Swap space in linux (I created a file with 3,5 Gb of size):

Note: Don´t forget to set the swap file that you created in the /etc/fstab, in this way you guarantee that swap space will set after a Linux system reboot.

- Add the IP and hostname linux to /etc/hosts file:

- Change the hostname (to saplindb):

- Check the temp environment variable (TMPDIR) and set the umask to 022:

- Check the "limit" values:

- Check the linux shell that you are running:

- Create a specific SAP directory for you can put the DVD media files for this installation:

- Filesystem size:

Windows Server Preparation (Win Srv 2012 (R2))

As you may know SAP supports Windows Server platform --> SAP on Microsoft Windows

In this specific case I use Windows Server 2012 (R2) where I will install the SAP system (LOD) as a copy of the source system (W8M).

This is a overview of some things that you may set as a requirement for a SAP installation over a Windows Server 2012 (R2).

- Set virtual memory (SWAP/Page file) with 10 Gb:

- Disable the internet explorer enhanced security configuration:

- Disable the User Account Control (UAC):

- Turn off windows firewall:

- Change the windows hostname (sapwinci)

- Check Windows system settings:

- Create a specific SAP directory for you can put the DVD media files for this installation:

- Partition disk space:

=> CHECK THE CONTINUATION OF THIS DOCUMENT IN THE FOLLOWING LINK:

SAP Migration – Win/MaxDB <=> Win & Linux/Oracle DB - PART 2

This document contains information for LiveCache system copy part of an SCM7.0 system copy. In the previous 2 parts, we have completed ABAP system copy and opened the system. Now we restore LiveCache instance from source system to target system through MaxDB Database Studio.

LiveCache version of SCM system is 7.7.07 Build48. LiveCache is installed on the same Linux x86_64 server with ABAP SCM 7.0 part.

Related SAP Notes:

457425 - Homogene liveCache-Kopie mit Hilfe von Backup/Restore

632357 - Sicherung der Daten aus dem liveCache für SCM >= 4.0

To prevent some misunderstandings and increase readibility, I prepared 3 seperate documents for DB2 restore and LiveCache MaxDB restore.

This part contains sapinst steps from the beginning until the "exit to restore DB2". Second part contains DB2 restore (from Snapshot) steps and third part contains LiveCache system copy instructions.

For the first part, that contains system copy screenshots (until restore) and information, go to link: SCM 7.0 (with LiveCache) DB2 Linux system copy-Part1/3 (Until restore)

For the second part, that contains DB2 restore steps. go to link: SCM 7.0 (with LiveCache) DB2 Linux system copy-Part2/3 (DB2 restore)

• After finishing SCM ABAP DB2 restore (system copy), we can install LiveCache instance. Point the path like in the screenshot, in the screen of SWPM sapinst. Then enter LiveCache SID and master password:

• Provide LiveCache 7.7 DVD location:

• Provide LiveCache user details and other parameters like in the screenshots:

• Provide locations and sizes for your LiveCache MaxDB log and data volumes. You can check your source LiveCache configuration to be sure.

• After checking sapinst parameter summary screen, you can execute it. There are 5 steps to be completed:

• Download the latest LiveCache patch from SWDC and patch it with the following command like below:

root-> pwd

/tmp/LC_Update/lca700032_livecache-linux-64bit-x86_64-7_7_07_50

root-> ./SDBUPD -d <LiveCacheSID> -u control,PASSWORD

Livecache 7.7.07.50

• Open your MaxDB Database Studio and register your both source and target LiveCache MaxDB servers. Firstly prepare a backup of source system via Right click -> Administration Tasks -> Backup... Then move the backup file to your target system to restore. Execute restore like in the screenshots:

• Finally restart your LiveCache instance through LC10 from your ABAP System.

     My LC10 screen is like this now:

TROUBLESHOOTING

• During MaxDB recovery, I got the following error. The same error is also discussed in that SCN link:
• Can't start Database Instance after a recovery with error

To overcome this error, click to "Medium COM" button on left bottom corner and take a new backup from your source system with the block size mentioned in the error code:

-903 Host file I/O error 6,Data recovery failed 113,Open medium on /tmp/XXXX for READ failed Servertask Info: because Error in backup task occured Job 1 (Backup / Restore Medium Task) [executing] WaitingT140 Result=3700 Error in backup task occured, Error code 3700 "hostfile_error" 127,RTE header size 524288 instead of 65536 bytes on medium /xxxxxx .

Calculate block size to give, dividing the header size in the error code by 1024, to convert it to KB. For example in my case, there was an error code with the value 524288 and I divided it by 1024. 524288/1024 = 512KB . I gave this value to make a new source system MaxDB backup. Then restoring it went fine!

• In LC10 screen I had a warning "Instance ONLINE, but no SQL access possible" . Due to this error, LiveCache reports, jobs can not be executed. SCN link for similar error:

Cannot open SQL connection to liveCache LCA

Also you can check your WP Workprocess logs under /usr/sap/SID/DVEBMGSSN/work . You'll see this error there:

*** ERROR => different codepage: application=UNICODE, LVC=ASCII

I changed the DefaultCodePage like in the screenshot, from ASCII to UNICODE and restarted LiveCache. The error is lost.

• 1864995 - sql error -4025 when connecting from SCM to livecache

When we first install a new ABAP system, one of the parameters required is the name of the transport host. The installation tool defaults to the host on which we are installing, and if this is the first system in the landscape, this is often the choice we make. As frequently the first system installed is the development, or DEV, system, it's very common for DEV to become the central transport host as well as the transport domain controller (setup almost immediately after installation when we first configure STMS, and not to be confused with a Windows Active Directory domain controller).

This is all well and good, but fast forward a few (or maybe quite a few) years, and inevitably the day arrives when we would like to migrate our systems onto shiny new hardware. The System Copy guide documents the process of moving our ABAP system quite well, but it doesn't go into much (or any) detail about moving our Transport Domain Controller, nor does it talk about moving our transport host.

The example below assumes a Windows host, but the procedure should be easily adaptable to other operating systems.

What is a Central Transport Host?

Put simply, this is the location of \usr\sap\trans. If, during installation, we specify the current host (i.e., the one on which we are running the installer) as the transport host, then the installer will create the trans folder and its various subfolders, along with the rest of the folder structure required for the installation. If we specify a different host, then the installer will not create the trans folder, but instead will (or might) create a system parameter that points to the other host.

\usr\sap\trans is the folder containing all of our exported (released) transport requests, configuration information for our transport domain (or landscape), logs of transport request exports and imports, and by default the EPS Inbox which is used by SPAM and SAINT for support packs, add-ons, etc.

In a typical scenario, each transport domain will have just one \usr\sap\trans folder, and all the systems in that domain will use that same central folder.

Setting up the New Transport Host

Having determined that we need to migrate the transport host, the first decision is where to put it. It does not actually have to be on an SAP system. It could, for instance, be in a shared network location accessible by all the SAP systems in the transport domain. Or, it could move with the DEV system to the new DEV host. This decision depends upon our needs, and there is no right or wrong answer for all scenarios.

Either way, I recommend migrating the transport host before migrating the DEV system (or whichever system in the domain we are migrating first). This will simplify things later, as then we generally only need specify the hostname of the new transport host during installation with SWPM of each new target system.

Create Folder Structure

This part is simple. On the target host, at the root of the selected drive or volume, create an empty folder called \usr, then subfolder \sap and further subfolder \trans.

If we follow general system installation recommendations, then we may install the Solution Manager Diagnostics Agent (SMD or DAA) on the host before installing anything else, and in this case the \usr\sap folder will already exist, and we should use that.

Make sure the drive has plenty of free space, enough to accommodate the files we're going to move into it, plus headroom for future transports and support packs.

Copy Files and Subfolders

Easy. Simply copy (or move) all of the subfolders and their contents from the source system \usr\sap\trans to the target system \usr\sap\trans. If our source system is not in use at this point (and it really shouldn't be), then rename the source trans folder to something like trans.bak to ensure that it doesn't give us a false positive during our testing for success later.

Create sapmnt Share

Share the folder \usr\sap (not \usr\sap\trans) as sapmnt. For now, give Administrators full control and everyone else no access.

Create SAP_LocalAdmin Group

On the target host, create the local group SAP_LocalAdmin, and add the Active Directory global groups SAP_<SID>_GlobalAdmin to it, where <SID> represents the System ID of each SAP system in our transport domain.

Grant SAP_LocalAdmin 'Full Control' to both the sapmnt share and the \usr\sap folder (and all subfolders, which should happen by default).

Test that these permissions are correct by logging on to one of the other SAP hosts as <sid>adm and then navigate to \\<new_trans_host>\sapmnt\trans, and create, read, and delete a test file.

SAPTRANSHOST and DIR_TRANS

Here is where the fun begins. Depending on how long ago we first installed our source SAP system, and how old the installer program (i.e., sapinst) was, we might find any number of locations where pointers to the transport directory exist. We need to find all of them, and in most cases delete them, so that there is only one.

There are essentially three variables or parameters of importance to us: SAPTRANSHOST, DIR_TRANS, and DIR_EPS_ROOT. Each of these could be set (or not) in the default or instance profiles of our SAP systems, or one of them (SAPTRANSHOST) may be set externally, as an environment variable or as a DNS (Domain Name System) alias.

DIR_EPS_ROOT defines the location of the EPS Inbox and other structures for SPAM and SAINT, and if not explicitly set it will be derived as \\<SAPTRANSHOST>\sapmnt\trans\EPS. Unless we have intentionally separated the EPS inbox from the transport folders, this parameter should be left unset, i.e. at the default. So, delete it wherever we find it.

Likewise, DIR_TRANS defines the location of the transport folder root, i.e. \usr\sap\trans, for STMS. This one is fairly commonly found set in instance profiles, but could also be in a default profile. If we use a central transport host and we stick to the default folder names, as described here, then there is no need to set this parameter. We should delete it wherever we find it.

Parameter Priority

DIR_TRANS is the parameter that STMS will use to find the transport folders. If both SAPTRANSHOST and DIR_TRANS are set in a profile, DIR_TRANS will take precedence in determination. If DIR_TRANS is not explicitly set, then the system will substitute standard values to calculate it as \\<SAPTRANSHOST>\sapmnt\trans.

Therefore, if we eliminate DIR_TRANS from all profiles, determination rests only upon a correct setting of SAPTRANSHOST. This becomes the key to simplifying our migration.

STMS is going to look first for DIR_TRANS to be explicitly set. If it doesn't find it, it will substitute as mentioned above using the value of SAPTRANSHOST. It will look first for SAPTRANSHOST in the local system's Instance Profile, and if not found there, then in the Default Profile. If it doesn't find it in any profile, it will look for it as an environment variable (for the user SAPService<SID> or <sid>adm) or via the operating system's hostname resolution.

SAPTRANSHOST

SAPTRANSHOST may be set as a parameter in the instance profile, the default profile, or as an alias in the hosts file or DNS. At various times installation programs and documentation have defaulted to or recommended different approaches.

DNS

If we have only a single transport domain, and we have ready access to manipulate our DNS (Domain Name System) server, then setting an 'alias' record in DNS for SAPTRANSHOST to point to the IP address of the central transport host may be the easiest option. This is a task usually managed by network operations staff and not SAP system administration staff, so we won't go into the procedure here. Also, for that reason, it may be simpler to not rely upon DNS for this parameter.

The other complication associated with setting SAPTRANSHOST in DNS is that we may have more than one transport domain, and possibly also more than one central transport host. This could be the case, for instance, if we have one transport domain for our ECC landscape, and another domain for our SRM landscape, and perhaps another for BW, etc.

Finally, a DNS alias ends up as the lowest priority for determination, as it will be overridden by any of the other methods that could be used.

HOSTS

An alternative to DNS is to maintain the alias in the local hosts file. This was very common with early ABAP (i.e. R/3) systems, so we must definitely check for this and correct it (or potentially eliminate it).

The hosts file is a repository of IP addresses and hostnames maintained in the local server's filesystem. This is a mechanism for name resolution that predates DNS. In the event of an entry in the hosts file that conflicts with an entry in DNS, the hosts entry will take priority (but only for name resolutions on the local host).

The file is located at C:\Windows\system32\drivers\etc\hosts. It is a simple ASCII text file that can be edited with Notepad.

Look for entries similar to:

192.168.0.1     hostname.domain.com     SAPTRANSHOST

Obviously, the IP address will likely be different. Here, we have two options. We can edit the line so that the IP address and hostname match our new central transport host, or we can simply delete the line (assuming we have a working DNS system so that the actual hostname will be resolved correctly, but this is usually the case).

If we don't find such a line, we can insert a new one with the correct information, or we can ignore it and leave it alone. After all, there is another option.

Default Profile

The next place to look is for the SAPTRANSHOST parameter to be set in either the Default or Instance Profile. If it is set as a DNS or HOSTS alias, then it may not be set in the profiles at all. Ideally it should only be set in one place or the other, not both. Currently, SWPM will configure this as a parameter in the Default Profile on installation, so this is the practice I recommend.

It should be set in only one place, so we are going to eliminate any SAPTRANSHOST alias from the hosts file and any parameter for this (or DIR_TRANS) in the Instance Profile, and ensure it is set correctly in the Default Profile.

Environment Variable

There is one other possible place where a misconfigured SAPTRANSHOST variable could cause us grief. It is rare, but we might find it set as an environment variable for the <sid>adm user. If so, we should eliminate it and rely instead on the Default Profile. This will be much easier to manage going forward.

Restart

Unfortunately, changing this parameter in the system profiles, or for that matter in the hosts file, requires a restart of the application to take effect. In the case of a change in the hosts file, it also requires a restart of the SAP service (which is a good idea generally, anyway, when restarting the system for profile parameter changes, as some parameters require this as well).

Yes, this means there will be a brief production downtime to get this into effect, so plan ahead.

TP at the OS Level

One possible advantage to setting SAPTRANSHOST as a DNS alias or environment variable could have been for use with the tp command when used outside the ABAP system from the server console's command prompt. It is rare these days to use tp instead of STMS, but there are occasions that call for it. The proper way to handle this, however, is to set TRANSDIR in the transport domain profile. This is done via STMS.

Logon to the transport domain controller (possibly the DEV system), and go into transaction STMS. Select System Overview, then double-click on the system that is the Controller (there is a small icon next to the System ID for the primary and backup controllers; hover over them with the mouse to see a pop-up text identifying them).

Select the Transport Tool tab. There we should see a parameter called TRANSDIR. If it is not correctly set, change to edit mode and correct it.

It should have the Global flag checked, and the value should be \\<central_transport_host>\sapmnt\trans.

Save changes and select Yes to distribute changes immediately.

Testing and Wrap-up

So, we have exhaustively and methodically ensured that SAPTRANSHOST is correctly set in the Default Profile of all systems in our transport domain, and that both it and DIR_TRANS are not set anywhere else. At this point, everything should be working, but let's double-check.

While still logged into STMS on the transport controller, back out to the System Overview, highlight all the systems in the list (click on the column header), then one after the other select SAP System... Check... Connection Test, then Transport Directory, then Transport Tool. We should see green checkmarks for all tests, and when we expand the test results we should see that the new transport host is being used.

Now select Display Transport Groups, then Check Transport Groups. If all is correct, we should see a grid of green lights.

Back out two steps and go into Transport Routes. Select Configuration... Check... Transport Routes and then Request Consistency... In All Systems. It's not really all that time-consuming, so select yes for the warning prompt.

Finally, back out one step and go into Import Overview. Select Refresh. After a bit we should a green status for each of our systems' import queues. Drilling into a queue should show any waiting requests, and import histories should be complete with logs.

If any of the above checks yields an error, then we will need to go to the system involved with the error and double-check that we have eliminated and corrected all parameters, variables, and aliases, and that the system has read/write access to the transport folder.

Hi all,

This document is the first part of step by step system copy instructions SCM 7.0 based on NW7.01 (with LiveCache). Linux is x86_64bits and DB2 version is 10.1 FixPack3.

To prevent some misunderstandings and increase readibility, I prepared 3 seperate documents for DB2 restore and LiveCache MaxDB restore.

This part contains sapinst steps from the beginning until the "exit to restore DB2". Second part contains DB2 restore (from Snapshot) steps and third part contains LiveCache system copy instructions.

For the second part, that contains DB2 restore steps. go to link: SCM 7.0 (with LiveCache) DB2 Linux system copy-Part2/3 (DB2 restore)

For the third part, that contains LiveCache MaxDB restore screenshots and specific LC information, go to link : SCM 7.0 (with LiveCache) DB2 Linux system copy-Part3/3 (LiveCache restore)

IMPORTANT: Get the latest system copy guide from service.sap.com/instguides before you begin to execute the process. This document is designed as a secondary one, besides official system copy guide!

service.sap.com/instguides -> Alphabetical Index "S" ->SCM Server -> Using SCM 7.0 Server -> Installation Guides -> Select Linux and DB2.

SSID=Source SID

TSID=Target SID

Installation DVDs can be downloaded from Software Downloads | SAP Support Portal -> Inst. and Upgrades -> Alphabetical Index "S" ->SCM -> SCM 7.0 -> Installation -> Based on NW 7.01 .

• Download the latest version of SWPM from service.sap.com. I used this one : SWPM10SP07_6-20009701.SAR . After executing ./sapinst with root, point the path to SCM 7.0 system copy , like in the following screenshot.

• My source livecache and ABAP instances are on the same server. Below you see the target system filesystems.

• Enter target SID and FQDN. You can check your FQDN from /etc/hosts file. Then enter master password.

• Since we use snapshot backup to copy DB, select second option:

• Enter target DB TSID, ABAP schema user of source system, db2TSID password and other passwords. For ABAP schema user, you can check from source system via SAP GUI: System-->Status-->DB Owner (On the bottom right corner)

• Enter the path of kernel DVD. You can see the DVD number from screenshot.

• Enter LiveCache DB software owner information and installation media.

• Point DB2 DVDs for 10.1 FixPack3 and enter other DB2-specific information. Then give path for DB2 client/JDBC DVD.

• Provide system numbers and mark "Interrup before start". I chose this, in order to make some arrangements (eg. removing BTC processes to prevent background jobs to be executed immediately after system start). Provide source system 000 client DDIC password.

• Provide SL Controller DVD and confirm archive files to get unpacked.

• Provide LiveCache instance essential information. LiveCache user is SAP<LiveCacheSID>:

• Then you can see the a summary of parameters you have already provided. Have a look and start the process. It runs until "Exit to restore database":

To prevent some misunderstandings and increase readibility, I prepared 2 seperate documents for DB2 restore and LiveCache MaxDB restore.

For the second part, that contains DB2 restore steps. go to link: SCM 7.0 (with LiveCache) DB2 Linux system copy-Part2/3 (DB2 restore)

For the third part, that contains LiveCache MaxDB restore screenshots and specific LC information, go to link : SCM 7.0 (with LiveCache) DB2 Linux system copy-Part3/3 (LiveCache restore)

After completing DB2 restore, click OK and execute other SAPINST steps:

This document contains information about DB2 10.1 FP3 restore steps. DB2 restore has been executed from the latest snapshot of the source system. Source system is an SCM 7.0 based on NW7.01, running DB2 10.1 FP3 on Linux x86_64.

To prevent some misunderstandings and increase readibility, I prepared 3 seperate documents for DB2 restore and LiveCache MaxDB restore.

This part contains sapinst steps from the beginning until the "exit to restore DB2". Second part contains DB2 restore (from Snapshot) steps and third part contains LiveCache system copy instructions.

For the first part, that contains system copy screenshots (until restore) and information, go to link: SCM 7.0 (with LiveCache) DB2 Linux system copy-Part1/3 (Until restore)

For the third part, that contains LiveCache MaxDB restore screenshots and specific LC information, go to link : SCM 7.0 (with LiveCache) DB2 Linux system copy-Part3/3 (LiveCache restore)

Restore steps would possibly differ in your environment, since those steps change dependent to the landscape infrastructure, filesystem structure, directory structure and used softwares in backup&storage processes.

SSID, ssid : Refers to source system SID.

TSID, tsid : Refers to target system SID.

• 1.Prepare relocation script on source system. Then copy it to target system. It is used to "relocate" source DB files copied from snapshot, to target DB.

Source system :

Su - db2<tsid>

brdb6brt -bm 5 -replace TSID=SSID,db2<ssid>=db2<tsid>

Relocation Script:  ./TSID_NODE0000.scr

• 2.Create mount points and mount the source system snapshot filesystems under those mount points on target system.

Target system:

root-> mkdir /tmp/SNAP_sapdata

root-> mkdir /tmp/SNAP_db2<ssid>

root-> mount -t nfs XXXXX:/vol_XXX_source_dbdata/dbdata/db/db2/db2_source_sapdata /tmp/SNAP_sapdata

root-> mount -t nfs XXXXX:/vol_XXX_source_dbdata/dbdata/db/db2/db2_source_db2<ssid> /tmp/SNAP_db2<ssid>

• 3.Copy source system files from snapshot backup to target system directories:

root-> pwd

/tmp/SNAP_sapdata/.snapshot/snap-daily_DATE_OF_LATEST_SNAP

root-> date; cp -Ppr * /db2/<TSID>/sapdata/ ; date

root-> pwd

/tmp/SNAP_sapdata/.snapshot/snap-daily_DATE_OF_LATEST_SNAP

root-> cp -pPr * /db2/<TSID>/db2<tsid>/

• 4.Rename directories and adjust file authorizations according to the target system users:

root-> pwd

/db2/<TSID>/sapdata

root-> mv db2<ssid> db2<tsid>

root-> pwd

/db2/<TSID>/sapdata/db2<tsid>/NODE0000

root-> mv <SSID> <TSID>

root-> pwd

/db2/<TSID>/db2<tsid>

root-> chown -R db2<tsid>:db<tsid>adm NODE0000/

root-> pwd

/db2/<TSID>/sapdata

root-> chown -R db2<tsid>:db<tsid>adm db2<tsid>

• 5.After those adjustments, we can execute the script that we've already prepared in the first step. Script initialize the target DB.

targetHost:db2<tsid>> db2inidb <TSID> as mirror relocate using <SSID>_NODE0000.scr

Relocating database...

DBT1006N  The "/db2/<TSID>/sapdata1/db2<tsid>/NODE0000/<TSID>/T0000000/C0000000.CAT" file or device could not be opened.

Unable to relocate database, cannot continue.

This error comes up, if the target and source system filesystem-directory structures differ. To overcome this, I've created symbolic links:

root-> ln -s sapdata sapdata1

root-> ....

root-> ln -s sapdata sapdata16

targetHost:db2<tsid>> db2inidb <TSID> as mirror relocate using <SSID>_NODE0000.scr

Relocating database...

Files and control structures were changed successfully.

Database was catalogued successfully.

DBT1000I  The tool completed successfully.

Database relocation was successful.

DBT1000I  The tool completed successfully.

• 6.Copy your source system's DB2 archive logs to target system, to make rollforward your target DB. On target system preape a script (rollforward<TSID>.clp) including rollforward command. In our case we've made "end of logs" recovery but "point-in-time" recovery is also possible.

     Run the script and complete your rollforward process.

targetHost:db2<tsid>>  db2 -tvf rollforward<TSID>.clp

rollforward db <TSID> to end of logs and complete OVERFLOW LOG PATH(/tmp/Temporary_Space_for_Source_Archive_Logs/)

                                 Rollforward Status

Input database alias                   = <TSID>

Number of members have returned status = 1

Member ID                              = 0

Rollforward status                     = not pending

Next log file to be read               =

Log files processed                    = S000xxxx.LOG - S000yyyy.LOG

Last committed transaction             = date-06.09.36.000000 Local

DB20000I  The ROLLFORWARD command completed successfully.

• 7.Activate your target DB. This command starts to create online DB logs under your /db2/TSID/log_dir directory.

targetHost:db2<tsid> >db2 activate db <TSID>

DB20000I  The ACTIVATE DATABASE command completed successfully.

• 8.Grant authorizations on your target database.

su - <tsid>adm

db2 grant secadm on database to user db2<tsid>

db2 grant dbadm on database to user db2<tsid>

db2 grant dbadm on database to user <schema_owner>

db2 grant dbadm on database to user <schema_owner>

su - db2<tsid>

db2 grant secadm on database to user <tsid>adm

db2 grant dbadm on database to user <tsid>adm

db2 grant dbadm on database to user <schema_owner>

db2 grant dbadm on database to user <schema_owner>

• 9.Drop and recreate your SYSTOOLSTMPSPACE.

targetHost:db2<tsid> > db2 -tvf /tmp/SCRIPT.clp

drop tablespace "SYSTOOLSTMPSPACE"

DB20000I  The SQL command completed successfully.

drop tablespace "SYSTOOLSPACE"

DB20000I  The SQL command completed successfully.

CREATE USER TEMPORARY TABLESPACE "SYSTOOLSTMPSPACE" IN DATABASE PARTITION GROUP IBMCATGROUP PAGESIZE 16384 MANAGED BY AUTOMATIC STORAGE EXTENTSIZE 2 PREFETCHSIZE AUTOMATIC BUFFERPOOL IBMDEFAULTBP OVERHEAD 7.500000 TRANSFERRATE 0.060000 FILE SYSTEM CACHING DROPPED TABLE RECOVERY OFF

DB20000I  The SQL command completed successfully.

CREATE LARGE TABLESPACE "SYSTOOLSPACE" IN DATABASE PARTITION GROUP IBMCATGROUP PAGESIZE 16384 MANAGED BY AUTOMATIC STORAGE AUTORESIZE YES INITIALSIZE 32 M MAXSIZE NONE EXTENTSIZE 2 PREFETCHSIZE AUTOMATIC BUFFERPOOL IBMDEFAULTBP OVERHEAD 7.500000 TRANSFERRATE 0.060000 NO FILE SYSTEM CACHING DROPPED TABLE RECOVERY OFF

DB20000I  The SQL command completed successfully.

• 10.Install DB2 licenses.

targetHost:db2<tsid> > db2licm -a db2ese_c.lic

targetHost:db2<tsid> > db2licm -l

• 11.Restart your target DB and try to connect to it. Check R3trans connectivity.

targetHost:db2<tsid> > db2stop force

targetHost:db2<tsid> > db2start

targetHost:db2<tsid> >db2 connect to <TSID>

   Database Connection Information

Database server        = DB2/LINUXX8664 10.1.3

SQL authorization ID   = DB2<TSID>

Local database alias   = <TSID>

targetHost:<tsid>adm > R3trans -d

This is R3trans version 6.23 (release 720 - 31.10.12 - 20:12:06).

unicode enabled version

R3trans finished (0000).

TROUBLESHOOTING:

• <SQL0727N An error occurred during implicit system action type "3".>

Under installation directory sapinst_instdir

root-> more last_command.out

SELECT 'CALL SYSPROC.ADMIN_TASK_REMOVE(''' || RTRIM(NAME) || ''',' || CASE WHEN END_TIME IS NULL THEN 'NULL' ELSE '''' || RTRIM(CAST (END_TIME AS char(40))) || '''' END || ');' FROM SYSTOOLS.ADMIN_TASK_LIST WHERE PROCEDURE_SCHEMA = 'SA

PTOOLS'

SQL0727N  An error occurred during implicit system action type "3".

Information returned for the error includes SQLCODE "-204", SQLSTATE "42704"

and message tokens "SYSTOOLS.ADMINTASKS". SQLSTATE=56098

SOLUTION

http://scn.sap.com/thread/2098004

db2 "drop view SYSTOOLS.ADMIN_TASK_LIST"

• SQL0556N  An attempt to revoke a privilege, security label,.....

REVOKE DBADM ON DATABASE from user <TSID>ADM

DB21034E  The command was processed as an SQL statement because it was not a

valid Command Line Processor command.  During SQL processing it returned:

SQL0556N  An attempt to revoke a privilege, security label, exemption, or role

from "<TSID>ADM" was denied because "<TSID>ADM" does not hold this privilege,

security label, exemption, or role.  SQLSTATE=42504

SOLUTION

db2 grant dbadm on database to user <tsid>adm

Purpose

The purpose of this document is to assist with the processing of pending V3 update requests (transaction SM13).

Cause

V3 update requests are called "collective run updates", and are not automatically processed by the update mechanism.

These updates are not considered to be critical or urgent.

Critical/urgent update requests should be created as a V1 update.

Solution

A background job (transaction SM36/SM37) needs to be schedule to collect and process pending V3 update requests.

Each application area has to provide its own job / report.

Therefore, the first step is to verify whether the application has such report, and what are the guidelines provided by the application regarding how to schedule the job (daily, weekly, etc.).

In case the application does not provide such report, the generic report "RSM13005" can be used.

See also

• SAP note 552300 - FAQ: Update

Related spaces:

• SAP NetWeaver Application Server
• SAP NetWeaver Technology Platform

SAP Performance tuning with Oracle 11G in OS/ AIX

Summary:-

This document contains how to tune the parameters in SAP level as well in database level based on your hardware, SAP application and database configuration.

Author: Brindavan Mookaiah

Designation: SAP BASIS Consultant

Instruction

The information about the parameters which show here are after analysis from our system landscape. It might be different from your landscape. If you are facing any performance issue in your system then you should analysis first for past three months data like response  time, CPU utilization , database load , new z*program ,expensive SQL statement ,snote , might be if user access backend system from portal..etc…  . This document only shows how to analysis and do the tuning based on the hardware, SAP application and database. We have analyzed and found that nothing can be increased any hardware or update patches or any z*program created by ABAP developers (include any new variants on existing z*program) or any expansive SQL statement using like “join queries ,using selection screen more” are causing performance issue.  Here we have the system performed very well before and recently it causing performance issue due to the RAM has taken and shared to some other system, this caused performance issue in our system. But, system is not overloaded with any new SAP application changes, so we have to analysis and tune the parameters based on current RAM.

Information on eye

CPU utilization : If your CPU utilization is too high and not with SAP application and database then check with OS team to find the which process causing slow the system or might be increase the CPU resource

Database: If the system loaded with only database and not with CPU or RAM or SAP application then analyze the database and tune the parameters in database level .

SAP Application : If system slow due to the SAP application then tune the parameters like “abap/heap_area_total  , abap/heap_area_nondia , abap/heap_area_dia , EM/TOTAL_SIZE_MB” based on your hardware RAM or check the active BG job or Z* program ,expensive SQL statement  can be tune by ABAP pers .

Here we have the system performed very well before and recently it causing performance issue due to the RAM has taken and shared to some other system, this caused performance issue in our system.

SAP Appliaction : PPM system

OS                    : AIX

Database           : Oracle 11G

We have checked first about the CPU utlizaton at OS level using nmon on AIX operating system.

Login in to OS level with "SIDADM" and type command " nmon"

and the type "C"

To check the RAM type "M"

To check the top process the type "topas"

Here we have found that the system is runnin very less free space of RAM.So we have increase the RAM or you have to find anyother way to tune the parameters to fix the perfomance issue.

Now check the SAP appliaction  and Database as well.

We have analyzed the below parameters which are assigned value in SAP and DB level.

Based on our analysis we found that the system heap memory is not used at all.  So, we are planning to take 2GB of memory (heap memory) and assign to DB.

We have some database buffer cache issue which physical read is too high not sufficient.

Also we are planning to tune the extend memory as well.

In SAP level you check the various parameters from t-code  ST02  and T-code DB02 for database analysis

Please find the detail information to tune the parameters in SAP and DB level.

In SAP side we have

EM/TOTAL_SIZE_MB = 18432 MB

abap/heap_area_dia = 4000683008Bytes

abap/heap_area_nondia = 4000683008Bytes

abap/heap_area_total = 8000000000Bytes

We will  change the parameter like below

EM/TOTAL_SIZE_MB = 10240MB

abap/heap_area_dia = 3000683008Bytes

abap/heap_area_nondia = 3000683008Bytes

abap/heap_area_total = 6000000000Bytes

By this way we will release 2GB of memory (1GB from abap/heap_area_dia and 1GB from abap/heap_area_nondia), this 2GB will be shared to DB parameter as shown below.

In DB side we have,

Buffer Cache Size (DB_CACHE_SIZE): 2617245696Bytes

Shared Pool Size (shared_pool_size): 2617245696Bytes

Maximum SGA Size (sga_max_size): 5284823040Bytes

We will  add this additional 2GB  to the below parameters,

Buffer Cache Size (DB_CACHE_SIZE): 3171557120Bytes

Shared Pool Size (shared_pool_size): 2931818496Bytes

Maximum SGA Size (sga_max_size): 6284823040Bytes

The below information is explained  about the current database buffer and shared pool size in database level.

Current running Database buffer case size :-

Login into OS level with "oraSID" and excute the below SQL command

COLUMN size_for_estimate FORMAT 999,999,999,999 heading 'Cache Size (MB)'

COLUMN buffers_for_estimate FORMAT 999,999,999 heading 'Buffers'

COLUMN estd_physical_read_factor FORMAT 999.90 heading 'Estd Phys|Read Factor'

COLUMN estd_physical_reads FORMAT 999,999,999 heading 'Estd Phys| Reads'

column size_for_estimate       format 999,999,999,999

column buffers_for_estimate    format 999,999,999

column estd_physical_read_factor format 999.90

column estd_physical_reads       format 999,999,999

SELECT size_for_estimate, buffers_for_estimate

     , estd_physical_read_factor, estd_physical_reads

  FROM V$DB_CACHE_ADVICE

WHERE name          = 'DEFAULT'

   AND block_size    = (SELECT value FROM V$PARAMETER

                         WHERE name = 'db_block_size')

   AND advice_status = 'ON';

The following output shows that if the cache was 2,160 MB, rather than the current size of 2,400 MB, the estimated number of physical reads would increase by a factor of 1.05.This means it would not be advisable to decrease the cache size

However, increasing the cache size 3024  would potentially decrease reads by a factor of  5%

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

                                Estd Phys    Estd Phys

Cache Size (MB)      Buffers Read Factor        Reads

---------------- ------------ ----------- ------------

             240       29,565        4.97  132,153,593      -->   10 % of current szie

             480       59,130        3.15   83,773,834

             720       88,695        2.24   59,611,205

             960      118,260        1.74   46,099,883

           1,200      147,825        1.45   38,412,908

           1,440      177,390        1.28   33,925,209

           1,680      206,955        1.17   31,088,982

           1,920      236,520        1.10   29,228,940

           2,160      266,085        1.05   27,878,798    

           2,400      295,650        1.01   26,880,033     -->  Current size

                               Estd Phys    Estd Phys

Cache Size (MB)      Buffers Read Factor        Reads

---------------- ------------ ----------- ------------

           2,496      307,476        1.00   26,568,531

           2,640      325,215         .98   26,150,487

           2,880      354,780         .96   25,506,595

           3,120      384,345         .94   25,026,134

           3,360      413,910         .93   24,608,745

           3,600      443,475         .91   24,254,741

           3,840      473,040         .90   23,938,076

           4,080      502,605         .89   23,696,871

           4,320      532,170         .88   23,504,570

           4,560      561,735         .88   23,336,835       -->  200% Current size

                                Estd Phys    Estd Phys

Cache Size (MB)      Buffers Read Factor        Reads

---------------- ------------ ----------- ------------

           4,800      591,300         .87   23,175,753

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Checked the share pool size with following SQL Command

SELECT POOL,NAME, ROUND(BYTES/(1024*1024),2) FREE_MB FROM V$SGASTAT WHERE POOL='shared pool'AND NAME='free memory'ORDER BY BYTES DESC;

Shared pool size :-

Current size       : 2496 MB

Free space size : 363 MB

You find the total SGA memory alloacted as well with following Command

select component,current_size from v$SGA_DYNAMIC_COMPONENTS;

We have only 363 MB free space left . So , we are planning to increase 2796 MB.  We have done  SGA monitoring & PGA also , In SGA montoring we have found there is no memory available.

we have checked in SAP level using T-code DB02.

And check the startup overhead in Shared Pool of  Database is 19321563Bytes as well.

By increasing the above DB parameters we can reduce the overhead.

By this way the  system will be bit faster than perivous.

Note: Before changing any parmeters do the complete anaysis from hardware side,database side and SAP side .There are so many parameters in SAP side to tune, before doing any parameters changes in SAP side raise OSS message to SAP and get their suggestion & recommendation from them.