Tuesday, January 14, 2014

SAP License Installation


SAP License Installation

SAP license can be installed using the SLICENSE transaction. Once it has been installed, the license key is activated immediately

This is the initial screen of the SLICENSE transaction. Make sure that you have received the license key, installation number, hardware key and expiration date from SAP. All the prerequisites can be requested from SAP Service Marketplace.
1. Run transaction code SLICENSE. Go to Install box and a pop up will appear.
2. Upload the license (in text file).

3. Check the status. Go to System -> Status.

SAP GUI Installation on a Workstation from an Installation Server

SAP GUI Installation on a Workstation from an Installation Server

The installation process from an installation server is flexible, easy, and customizable. It makes maintenance easier in any phase of the distribution process, for example, when applying patches.

When installing SAP front end components with server-based workstation installation:

The following options are available:

● Without user interaction (unattended)
● With user interaction (attended), where the user has the following options:
○ Select from installation packages that the administrator has configured
○ Select from a complete list of SAP front end components available on the installation server

The following table describes the return codes for NwSapSetup.exe

Return Codes Description
0 Process ended without detected errors
3 Another instance of SAPSetup is running
4 LSH failed
16 SAPSetup started on WTS without administrator privileges
26 WTS is not in install mode
27 An error occurred in COM
48 General error
67 Installation canceled by user
68 Invalid patch
69 Installation engine registration failed
70 Invalid XML files
129 Reboot is recommended
130 Reboot was forced
144 Error report created
145 Error report created and reboot recommended
146 Error report created and reboot forced



SAP GUI Packaging and Installation



SAP GUI Packaging and Installation

package and distribute SAP front end components on Windows using SAP Netweaver SAPSetup (NW SAPSetup) - SAP Installation Server Administration Tool

SAP’s Front-End Software Deployment Tool – Netweaver SAPSetup not only allows direct installations from distribution media, but also an Installation Server based deployment mechanism that helps distribute SAP Front-End Software to workstations over a network and also using Microsoft SCCM  to deploy the large number of users. 

Performance and Scalability --- Quick Sizer tool

SAP Initial hardware sizing

Quick Sizer is a Web-based tool designed to make the sizing of SAP Business Suite easier and faster. It has been developed by SAP in close cooperation with all platform partners and is free of cost.

With Quick Sizer you can translate business requirements into technical requirements. Simply fill in the online questionnaire, an up-to-date survey that is based on business-oriented figures. The results you obtain can help you select an economically balanced system that matches your company's business goals. This is especially useful for initial budget planning.

Quick Sizer calculates CPU, disk, memory and I/O resource categories based on throughput numbers, and the number of users working with the different SAP solutions in a hardware and database independent format.


Sizing is an iterative process that continuously brings together customers, hardware vendors and SAP, so that, for example, direct links to SAP's hardware vendors facilitate the tendering procedure

SAP Basis Daily Tasks

 SAP Basis Daily Tasks

These administrative tasks are usually performed by the SAP system administrator

  • SAP System R/3 System Status Check:
Logon Test
The availability of the SAP system is a pre-requisite for using the SAP system. If  you to establish connection to the SAP system the system must be up and running.
  • Backup Management:
DB12
It is recommended that backup of the SAP system daily. Success or failure of the backup run has to be monitored daily. Ensure that backups are done properly so that you can recover the system state when it’s required. When a backup run fails, you should immediately resolve the problem and possibly perform an “emergency” backup.
  • Application Servers Status Check:
SM51
Application servers used for load balancing, hence, the need for their availability. The application server represents the runtime environment the SAP system. Use transaction SM51 to display the status of the instances of your SAP system.
  • Work processes Status Check:
SM51
Work processes are essential for the effective functioning of the SAP system. It is important to ensure that all configured work processes possess their correct status at any point in time. The SAP administrator should be able to know when to add or redistribute work process based on usage analysis.
  • Failed Updates Monitoring:
SM13
Failed updates are transaction that is not committed in the database. As administrator you needs to critical review such updates. Examine the reason and reprocess the failed update if required.
  • System Log Review:
SM21
The SAP system has its own system log. The system log contains error, warning and problem messages. The application server records events and problems in the system log and has a log that contains the messages output.
  • Jobs Monitoring:
SM37/SM35
In order to optimize resources and increase performance of SAP systems, some operations are performed at the background, defined or standard jobs. Background job as it were, is supposed to perform assigned task. Review the status of jobs for failure or success.

SAP Web Dispatcher

SAP Web Dispatcher

The SAP Web Dispatcher acts as a Single Point Of Access to the SAP System for users acessing the system via Browser (IE, FF). Therefore, it is located between the Internet / Intranet and the SAP System. The Web Dispachter acts as a load balancer and can redirect, reject or accept connections. When it accepts a connection, it balances the load to ensure an even distribution across the servers.

The SAP Web Dispatcher(SAP WD)  is only useful in web-enabled scenarios. This is, when the SAP systems are accessed over HTTP(S). In a normal R/3 / ECC scenario the users will access the systems over the SAPGui and won't utilize the Web Dispatcher. The SAP WD can be used in ABAP/Java systems and in pure Java systems, as well as in pure ABAP systems. The usage is recommended when you use an SAP system with several SAP Web Application Servers for Web applications. The Web Dispatcher is associated with one Application Server (AS). This has to be the AS where the Message Server (MS) is running. One Web Dispatcher can only be associated with one AS.

The SAP WD acts as an Single Point Of Access (SPOA) and therefore, also as a Single Point Of Failure (SPOF). You can leverage the SPOA functionality to simplify your landscape

SAP Dual Stack

SAP system that contains installations of both Application Server ABAP and Application Server Java is called as dual stack

SAP Dual Stack Strategy

SAP system that contains installations of both Application Server ABAP ( and Application Server Java (AS Java).
A dual-stack system has the following characteristics:
  • Common SID for all application servers and the database
  • Common startup framework

  • Common database (with different schemas for ABAP and Java) 
Lets Say Dual stack is required for
  • PI/XI
  • Solution Manager
  • Mobile up to NW 7.0
Optional Use case
  • BI 7
  • ESS scenarios in dual stack
  • Java Usage Types in NetWeaver Systems (e.g. Enterprise Portal)
SAP strategy
  • Running SAP NetWeaver application components in single stack
  • Exception: Solution Manager will stay dual stack
SAP Application Server Setup recommendations
  • Setup SAP systems as single stack whenever possible

SAP BASIS STANDARD REPORTS

SAP BASIS STANDARD REPORTS

BASIS

RSCOLL00     Performance Collector
RSBPCOLL     Collect Values for statistics
RSSNAPDL     Delete ABAP Dumps
RSTRFCER     Delete EXEC LUWs
Delete old jobs
RSBPSTDE     Delete old job statistics
RSBTCPRIDEL    Reorganization of Print Parameters for Background Jobs
RSPO1041    Delete old Spool Files
Delete XMI-LOG Files
RSPO1043    Spool Data-Consistentcy check in Background (SP12)
Delete Central User Administration
RSBDCREO    Delete Old Batch input Files
SAPconnect: Start Send Process Fax/Email
RSTBPDEL    Delete Entries in DBTABLOG
RSARFCER    Deletes entries in arfcstate and arfcdata for RFCs  (ARFC)
RSTRFCES    Deletes tRFC and qRFC entries  (arfcrstate, trfcqout)
RSTS0024    Deletes joblogheaders 4m TST01 that are older thanjobs in TBTCO
SBAL_DELETE    deletes application logs (balhdr)
RBDCPCLR    Deletes Obsolete change pointers
RSARFCEX    Retries entries in sm58 that may have failed due to temp conn errors
RSARFCDL     Cleans up log file for sm58 transfers
RSN3_STAT_COLLECTOR- Non R/3 Stat collector   
RSAL_BATCH_TOOL_DISPATCHING - Job for monitoring   
RSN3_AGGR_REORG    Program for Starting the Reorganization Function

DATABASE

View v$tables
RSORADJV    Select DBA tables
RSANAORA    Analyze table stats

TMS ( Transport Management System)

 RDDNEWPP    Schedule DDIC Jobs
RSTMSTIQ    Adjust Queue
TMS_BCI_START_SERVICE - Automatic import     

Sunday, January 12, 2014

Oracle Database Installation for SAP

Oracle Database Installation for SAP


When Oracle Database software is installed, a starter database should not be created, because the SAP install process will create a database for the application and will load data into the tables
During the course of the SAP installation, the sapinst program will stop as shown in figure below and ask the administrator to perform the Oracle install.



When installing the Oracle software, the Oracle Universal Installer tool must be used. The following procedure should be followed before the Oracle Universal Installer tool is started.

*************************************************************************************************************
1.      Open another X term and set the DISPLAY variable for user ora<sid> (example: oradb1)
Setenv DISPLAY <IP Address:0.0>
Setenv ORACLE_HOME /oracle/DB1/102_64
Setenv ORACLE_SID DB1
cd to /oracle/stage/102_64/database/SAP

*************************************************************************************************************
Shows the initial screen of the Oracle Universal Installer


2
Select the components as shown and then click the Next button to continue with the install. This will bring up the prerequisite check screen


3
Verify the identified prerequisites, and click the Next button once these are met. This will display the summary screen

4
Verify the summary screen and then click the Install button. This will start the Oracle software installation with a status indicator indicating the progress. After progressing through the different installation steps, the Oracle Universal Installer will stop at the screen and ask the administrator to execute a script as root user.

5
open another terminal window, log in as root, and execute the root.sh script. The execution details of the root.sh script are as follows:

***************************************************************************************************
[sapdb1] /oracle/DB1/102_64 #./root.sh
Running Oracle10 root.sh script...
The following environment variables are set as:
ORACLE_OWNER= oradb1
ORACLE_HOME= /oracle/DB1/102_64
*****************************************************************************************************

6
Enter the full pathname of the local bin directory: [/usr/local/bin]:
*****************************************************************************************************

The file "dbhome" already exists in /usr/local/bin. Overwrite it?
(y/n) [n]: y
Copying dbhome to /usr/local/bin ...
The file "oraenv" already exists in /usr/local/bin. Overwrite it?
(y/n) [n]: y
Copying oraenv to /usr/local/bin ...
The file "coraenv" already exists in /usr/local/bin. Overwrite it?
(y/n) [n]: y
Copying coraenv to /usr/local/bin ...
Finished running generic part of root.sh script.
Now product-specific root actions will be performed.
*******************************************************************************************************
7
Click the OK button after the root.sh script is executed successfully. This will complete the Oracle Database software installation successfully

Saturday, January 11, 2014

SAP Application Dataflow in the Oracle Database

SAP Application Dataflow in the Oracle Database

In SAP applications, end-user requests are processed by the Oracle database as follows:

1. The end user logs into the SAP system via the SAP front end and executes a business transaction.

2. The user request is executed by the SAP dialog work process.

3. The Oracle server detects the incoming call, accepts the call, and sets up a dedicated server process.

4. There is a one-to-one relationship between SAP work processes and Oracle server (shadow) processes.

5. The user runs the SQL statement and commits the transaction.
6. The server process looks into the shared pool of the Oracle Database for any reusable SQL.

7. If it finds a reusable SQL, then it verifies authorization.

8. If it does not find reusable SQL, then a new, shared SQL area is allocated and is parsed and processed.

9. The server process then retrieves data from the SGA or the datafile.

10. The Oracle server process modifies the data blocks in the SGA and, when efficient, the database writer writes the changes permanently to the data files.

11. The log writer records committed transactions to the online redo log files.

12. A reply is sent back to the user regarding the status of the transaction call (success or error).


Oracle Database Internal Architecture

Oracle Database Internal Architecture


Oracle Database internals consist of two main components: the database and the Oracle instance. The database is the static part of the Oracle system, and the Oracle instance is the memory structures and the Oracle background processes that are started when the database is started. The Oracle Database internal architecture is shown in below figure
























Database

The Oracle Database includes all the files that constitute the dataset. This includes the datafiles, control files, online redo log files, and offline archive log files. When an Oracle system is started, the database files are associated with the Oracle instance, and any operations the user performs are recorded in the appropriate files at the operating system level. The following definitions will clarify the different files that constitute the Oracle Database.

Tablespaces

Oracle manages data in logical units referred to as tablespaces. A logical tablespace consists of one or several physical files referred to as datafiles. When a new database object, such as a table or an index, is created this occurs in an assigned tablespace. When the tablespace is running out of space, it can be extended by adding datafiles. SAP follows specific naming conventions for the tablespaces.

Datafiles

Datafiles are actual physical files at the operating system level with set naming conventions to which the data is saved by database operations. Datafiles can be added to the tablespace as long as the mount point has space allocated and is available for such growth. In real-life production SAP systems, there will be tens and hundreds of datafiles depending upon the database growth of a given business operation.

Control Files

A control file has the list of physical datafiles and the paths where such files are located. When an Oracle instance is started, the system reads the control file to open the datafiles and redo log files and make it available for general database operations. Since the control file is such an important file, usually more than one copy exists at different locations at the operating system level.

Redo Log Files

When data is changed in the Oracle system, it is not permanently written to the datafiles right away. The data changes are written to the redo log files. In case there is a power failure, for example, data is applied back from the redo logs at instance start. In this way any data loss is prevented. Modified data is not written on a synchronous manner permanently to the datafiles immediately because of performance reasons. Instead, the data is written to the datafiles from time to time.

Offline Archive Log Files

The online redo log files are automatically moved to an offline device when the Oracle database is configured to turn on the archive log mode. When needed, offline archive log files can be used to perform a database point-in-time recovery.

Instance

When an Oracle Database is started it will start the background processes and open the memory structures configured for the database, and this is referred to as an Oracle instance. The Oracle instance is associated with the physical static database files to manage the database operations.

Memory Structures

Memory structures such as the system global area (SGA) are opened at the Oracle instance start and are based on the configuration parameter information.

System Global Area

The system global area is a shared memory region allocated to an Oracle instance based on the configuration parameters.
The SGA has two primary subareas: the database buffer cache and the redo log buffer. The Oracle SQL command “show sga” displays the current configuration of the SGA in the Oracle Database. This information can be obtained by using the following commands after you log in to the system at the operating system level as ora<sid> user:

*****************************************************************************************************************
moiz_cmd> sqlplus '/as sysdba'

SQL*Plus: Release 10.2.0.4.0 - Production on Tue Sep 21 00:54:33 2010
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> show sga

Total System Global Area 7962544640 bytes
Fixed Size 2094544 bytes
Variable Size 3707767344 bytes
Database Buffers 4238002688 bytes
Redo Buffers 14680064 bytes

******************************************************************************************************************

Database Buffer Cache

The database buffer cache is a set of database buffers that keep the modified and unmodified blocks of data in the memory area to facilitate faster access to it.

Redo Log Buffer

The redo log buffer keeps a log of changes to the data in the memory area. The size of the redo log is static.

Background Processes

When an Oracle instance is started a set of Oracle processes are started in memory and run in the background.

Background processes are like jobs that perform common tasks to manage the proper functioning of the Oracle instance.

Several kinds of background jobs are started at the instance start and perform a specific job function. Some of the examples of background processes are process monitor, system monitor, and lock process.

Process Monitor (PMON)

For every end-user process there is a 1:1 Oracle shadow process. PMON monitors the Oracle shadow process. If a user process crashes, PMON cleans up the orphaned Oracle shadow process and makes sure the data consistency is maintained.

System Monitor (SMON)

SMON performs recovery functions at instance start, writing an alert log when an instance process fails and conducting cleanup of temporary segments when not required.

Lock Process

This background process works as a lock manager monitor.

Recoverer (RECO)

Recoverer manages the in-doubt distributed transactions in distributed databases.

Other Processes

There are other critical background processes that operate in an Oracle database. The most important of these are covered in the following sections.

Database Writer (DBWR)

The DBWR writes the data from the database buffer cache to the data files.

Log Writer (LGWR)

The LGWR writes the redo log buffer to redo log files on the disk.

Archiver (ARC0)

The archiver process will automatically write the online redo logs to archive log files at an offline storage location (initially, this is the local disk). This process does this when the Oracle Database is configured to run with archive mode on.

Checkpoint (CKPT)
The CKPT process writes all modified database cache buffers in SGA to the datafiles.
The following command at the operating system level shows the Oracle background processes:

******************************************************************************************************************** 
moiz> ps -ef | grep ora_

moiz 1527 1 0 Aug30 00:00:26 ora_pmon_DX1
moiz 1533 1 0 Aug30 00:08:20 ora_dbw0_DX1
moiz 1535 1 0 Aug30 00:10:27 ora_lgwr_DX1
moiz 1537 1 0 Aug30 00:02:50 ora_ckpt_DX1
moiz 1539 1 0 Aug30 00:04:57 ora_smon_DX1
moiz 1541 1 0 Aug30 00:00:00 ora_reco_DX1
moiz 1594 1 0 Aug30 00:02:47 ora_arc0_DX1

********************************************************************************************************************

Oracle Database Installation and Configuration for SAP

Oracle Database Installation and Configuration for SAP

As we know several relational database management systems are fully supported by SAP applications

In this post we will use Oracle Database as an example to cover the database management concepts and tools provided by SAP to support the application install and maintenance

Oracle Database is the first database designed for enterprise grid computing, the most flexible and cost effective way to manage information and applications.

The database has logical structures and physical structures. Because the physical and logical structures are separate, the physical storage of data can be managed without affecting the access to logical storage structures.

Overview of Physical Database Structures
The following s explains the physical database structures of an Oracle database, including datafiles, redo log files, and control files.

Overview of Logical Database Structures
The logical storage structures, including data blocks, extents, and segments, enable Oracle to have fine-grained control of disk space use.