Documentacao Servidor SAP

Spacely Sprockets
Technical Infrastructure Document

1. GENERAL INFORMATION....................................................................................1
1.1 Company Data..........................................................................................................................................4
1.2 Locations...................................................................................................................................................4
1.3 Change History.........................................................................................................................................4
2. SAP SYSTEM & CLIENT LANDSCAPE............................................................5

2.1 SAP System Landscape Overview...........................................................................................................5
2.2 SAP Three System Landscape.................................................................................................................5
2.3 Two-Tier, Three-Tier and Three-Tier Distributed SAP Instance Setup..............................................5
2.4 SAP System & Client Landscape Diagram – Redraw to show each landscape horizaontally (R/3, CRM, APO, BW) Transports Paths go from Dev to
QAS, QAS to Prod. Showing DEV path directly to PROD is misleading. The diagram of the SAP Landscape does not require every server at each layer to be
displayed...................................................................................................................................................................6
2.5 SAP Clients...............................................................................................................................................7

2.5.1 R3D – Clients.........................................................................................................................................7
2.5.2 R3Q – Clients.........................................................................................................................................8
2.5.3 R3P – Clients..........................................................................................................................................8
2.5.13 Client Refresh Procedures...................................................................................................................9
3. NETWORK ENVIRONMENT...............................................................................10
3.1 Network Topology Diagram...................................................................................................................10
3.1.1 Wide Area Network..............................................................................................................................10
3.1.2 Local Area Network.............................................................................................................................10
3.1.3 SAP Network........................................................................................................................................10
Copyright © 2000 SAP AG. All rights reserved 1

Spacely Sprockets
3.2 Network Systems.....................................................................................................................................11
4. SYSTEM ENVIRONMENT...................................................................................13
4.1 SAP Systems Overview...........................................................................................................................13
4.2 R/3 Enterprise Landscape....................................................................................................................13

4.2.1 R/3 Development Environment Overview..........................................................................................13
4.2.2 R/3 Quality Assurance Environment Overview..................................................................................14
4.2.3 R/3 Production Environment Overview..............................................................................................15
5. DESKTOP ENVIRONMENT................................................................................18
5.1 Desktop Environment Overview..........................................................................................................18
5.2 Desktop Technical Requirements..........................................................................................................20
6. INPUT & OUTPUT DEVICES..............................................................................21

6.1 Device Overview......................................................................................................................................21
6.2 Output Devices........................................................................................................................................21

6.2.1 Printing................................................................................................................................................21
6.3 List of Input Devices..............................................................................................................................22

6.3.1 Input Devices.......................................................................................................................................22
6.4 Output Environment...............................................................................................................................24
6.5 Input Environment..................................................................................................................................24
7. SAP SOFTWARE INSTALLATION..................................................................25

7.1 SAP Software Installation Overview.....................................................................................................25

Spacely Sprockets
7.2 Installation of the SAP R/3 Instances....................................................................................................26
7.3 Installation of other SAP Software........................................................................................................26

7.3.1 Installation of SAP Portals...................................................................................................................26
7.3.2 Installation of SAProuter.....................................................................................................................26
7.3.3 Installation of SAP Connector.............................................................................................................26
7.3.4 Installation of Solution Manager.........................................................................................................26
8. CHANGE AND TRANSPORT SYSTEM (CTS)...................................................27

8.1 CTS Overview.........................................................................................................................................27
8.2 Transport Domains................................................................................................................................28

8.2.1 R/3 Change Transport Management System.......................................................................................28
8.3 Transporting Changes within a SAP Instance.....................................................................................28
8.4 Transporting Changes across SAP Instances.......................................................................................28

8.4.1 Ownership and Schedule for Transportation of Change Requests......................................................29
8.4.2 Releasing Change Requests for Population in the SAP Quality Assurance System...........................29
8.4.3 Moving Changes from the Quality Assurance System to the Production System..............................29
8.4.4 Post-Processing of Change Requests...................................................................................................30
8.4.5 Notification of Completed Transport Run to Core Team Members....................................................30
8.5 Change Request Standards...................................................................................................................30
9. SECURITY – USERS AND ROLES................................................................32

9.1 Security Overview...................................................................................................................................32
9.2 Users.........................................................................................................................................................32
9.2.1 R/3 Users..............................................................................................................................................32
9.2 Central User Administration.................................................................................................................32
10. SYSTEM MAINTENANCE...............................................................................33

Spacely Sprockets
10.1 System Maintenance Overview.............................................................................................................33
10.2 Support Packages....................................................................................................................................33
10.3 Kernel Patches........................................................................................................................................33
10.4 Upgrades..................................................................................................................................................33
11. BACKUP AND RECOVERY.............................................................................34

11.1 Backup.....................................................................................................................................................34
11.1.1 Backup Overview............................................................................................................................36
11.2 Recovery...................................................................................................................................................37
11.2.1 Restore After Disk Failure......................................................................................................................37
11.2.5 Restore after User Fault..........................................................................................................................38
11.2.6 Restore after Database Corruption.........................................................................................................38
11.2.7 Move to Different Hardware..................................................................................................................39

Spacely Sprockets
1. General Information
1.1 Company Data

Company name :
SAP customer number :
Responsible :
Document Version :
1.2 Locations
Data Center :
Users :
1.3 Change History
Date Name Description of Changes

Spacely Sprockets
2. SAP System & Client Landscape
2.1 SAP System Landscape Overview
The Spacely Sprockets project will implement one SAP components: R/3 Enterprise 4.7 Extension Set 2.00 (R/3). Spacely Sprockets will
purchase Dell Windows using servers for its Development and Quality Assurance instances and IBM eServer xSeries servers for Production
instances. IBM will be the vendor of choice for obtaining SAN storage arrays. The OS of choice is Windows 2003 and the database will
be MS SQL Server 2000.
Further implementation will create the need for servers to support Portals so ESS (Employee Self-Service) and MSS (Manager Self-Service)
subsystems can be used.
2.2 SAP Three System Landscape
Spacely Sprockets has elected to implement the SAP recommended Three System Landscape. This landscape provides for a Development
system, a Quality Assurance system, and a Production system in a separate, self-contained environment.
A three system landscape provides the maximum protection for isolating “destructive” changes, allows developer testing without
impacting the performance of other systems, and provides more flexible user training.
The following is a diagram of the typical SAP three system landscape:
Quality
System
Develo
pment
Assurance Production
System System
2.3 Two-Tier, Three-Tier and Three-Tier Distributed SAP Instance Setup
Spacely Sprockets will be implementing a combination of two-tier, three-tier and three-tier distributed setups. Low use, low priority
systems such as the Development system will be installed with the Database Instance (DB), Central Instance (CI), and Dialog Instance
(DI) installed on one server while mission critical systems like the Production environment may be spread across two or more servers.
The last layer of the tier is always the presentation layer, which can either be SAPGUI for Windows, SAPGUI for Java, or SAPGUI for
HTML. This is the diagram of the SAP Tier System:

Spacely Sprockets
2.4 R/3 Enterprise Instances with Host Names
system # system name description Hostname of CI SAP installation number

00 R3D R/3 Development System sttxsapd01 0020190495
00 R3Q R/3 Quality Assurance System sttxsapq01 0020190495
00 R3P R/3 Production System sttxsapdb01 0020190495
2.5 SAP Clients

2.5.1 R3D – Clients
Client Purpose currency category client- client-

# dependent independent
settings settings

Spacely Sprockets
100 Referred to as the “Golden USD No Changes No Changes
Client” . All other clients were Allowed Allowed
created from this one.
No configuration will be entered

in the Golden Client. The
Golden Client will receive
Transports from the
Configuration Client. The only
exception to this is that client
100 will be the “parent” client
for CUA and will contain all
users, roles, and profiles for
R3D Client 200 and R3P Client
300.
Future client copies will

originate from this client.
110 “Sandbox Client”. The USD Changes No Changes
functional team will use this allowed – No Allowed
client to test various Tracking
configuration options.
This client is created from a

client copy of 100 and will be
refreshed as needed.
120 “Configuration Client” . This USD Changes Cross-Client
will be the “Configuration Allowed – Configuration
Client”. All configurations will Automatic Allowed
be created in this client. Tracking

Spacely Sprockets
130 “ABAP Client”. This client is USD No Changes Repository
for the sole use of the ABAP Allowed Changes Allowed
development team. They will
do all of their development and
testing from this client.
2.5.2 R3Q – Clients
Client Purpose currency category client-dependent client-independent

# settings settings
200 “Golden QAS Client” USD No Changes Allowed No Changes Allowed
210 “GoldenConfigurationClient” USD No Changes Allowed No Changes Allowed
This Client will be created from the Golden QAS Client and
contain the data required for executing Integration Tests.
220 “Training Refresh Client” USD No Changes Allowed No Changes Allowed
Client containing “Good” Training Data.

221 “Training Client” USD No Changes Allowed No Changes Allowed
2.5.3 R3P – Clients
Client Purpose currency category client-dependent client-independent

# settings settings
300 “Production Live Client” . This is the production client USD No Changes Allowed No Changes Allowed
for R/3.
It will be created based on the Production Build

Specification yet to be written. This Specification will
outline the process to build Production based on the
Transports used to build the QAS Clients during testing.

Spacely Sprockets
2.5.13 Client Refresh Procedures
Source target client copy justification frequency reference #

system/client system/client profile in diagram

Spacely Sprockets
3. Network Environment
3.1 Network Topology Diagram

3.1.1 Wide Area Network
Information not yet available.
3.1.2 Local Area Network
3.1.3 SAP Network
3.1.3.1 SAP Router Documentation
SAProuter is a software router provided by SAP to communicate between SAP systems and SAP Support (formerly known OSS).
In the past, SAProuter was only available to clients willing to invest in the hardware and implementation costs of X.25, frame
relay, etc. connections. In the past few years, however SAP has adopted technology to allow VPN communication with it’s clients
via the internet. However SAP still has very exactly protocol requirements due to security, and must be FAXed information as the
client’s expected means of communication. This information includes client server and VPN IP addresses, type of router, etc.
You must use SAProuter to control and log the connections between SAP and your R/3 System. SAProuter is used at SAP Active
Global Support.

Spacely Sprockets
3.1.3.2SAProuter Hardware
SAProuter will be installed on a Dell Model 2650 2.4Ghz-Dual-512K 1GB-2D which it will share with a SAP Web AS instance
supporting Solution Manager. The SAProuter table will be resides on the same server.
 The denied and permitted routes and IP addresses have yet to be determined.

3.2 Network Systems
Purpose IP address hostname vendor model operating system

Spacely Sprockets

Spacely Sprockets
4. System Environment
4.1 SAP Systems Overview
4.2 R/3 Enterprise Landscape
4.2.1 R/3 Development Environment Overview
This is the Development environment for SAP R/3.
4.2.1.1R3D Servers Hardware & Software Specifications

R3D - system configuration – database instance and central instance.
Specifications Comments
Hardware Vendor Dell
Model PowerEdge 2650
CPU-Qty-Cache 4x 3184 Mhz
RAM 4GB
Raid Drives
Network IP address 10.2.5.10
Host name sttxsapd01
Domain Name
Static Routing
Network Services
OS Vendor Microsoft
Version Windows 2003
Patch Level
Code Page US_ENG
Software SAP SAP – SID R3D
SAP – System # 00
Component Release 4.70 SR 1
Basis Release 6.20
Kernel Patch Level Most current
Hot Pack / LCP # Most current
Code Page 1100
DBMS Vendor MS SQL Server
Version 2000
Patch Level 3a
Code Page 1100
4.2.1.2 OS-Users
Application User Name Uid Group Name

All R3dadm R3dadm Local User
SAP_R3D_GlobalAdmin
All SAPServiceR3D SAPServiceR3D Local User
SAP_R3D_GlobalAdmin

Spacely Sprockets
4.2.1.3File Directory Structure
Directory Purpose Size [GB]

C:\Program Files\Microsoft SQL Server MS SQL Server Executables
F:\TEMPDB MS SQL Server TEMPDB
E:\usr\sap\R3D SAP R/3 Executables
\\sttxsapd01\sapmnt\trans R/3 Transport Directory
G:\R3DDATA1 SAP Database Data
F:\R3DLOG1 SAP Database Log Data
4.2.2 R/3 Quality Assurance Environment Overview
This is the Quality Assurance environment for SAP R/3.
4.2.2.1R3Q Servers Hardware & Software Specifications
R3Q - system configuration – database instance server

Hardware Vendor Dell
Model PowerEdge 2850
RAM 2GB
Raid Drives
Host name sttxsapq01
Domain Name
Static Routing
Network Services
OS Vendor Microsoft
Patch Level
Code Page US_ENG
Software SAP SAP – SID R3Q
SAP – System # 00
Basis Release 6.20
Code Page 1100
Version 2000
Patch Level 3a
Code Page 1100

Spacely Sprockets
4.2.2.2OS-Users
Application User Name uid Group Name

All R3qadm R3qadm Local User
SAP_R3Q_GlobalAdmin
All SAPServiceR3Q SAPServiceR3Q Local Users
SAP_R3Q_GlobalAdmin
4.2.2.3 File Directory Structure

F:\TEMPDB MS SQL Server TEMPDB
E:\usr\sap\R3Q SAP R/3 System Files
\\sttxsapd01\sapmnt\trans R/3 Domain Transport
F:\R3DDATA1 SAP Database Data
E:\R3DLOG1 SAP Database Log Data
4.2.3 R/3 Production Environment Overview
This is the Production environment for SAP R/3.

4.2.3.1R3P Servers Hardware & Software Specifications
PRD - system configuration – database instance and central instance server
Hardware Vendor IBM
Model eServer xSeries 346
RAM 4GB
Raid Drives
Host name sttxsapdb01
Domain Name
Static Routing
Network Services
OS Vendor Microsoft
Patch Level
Code Page US_ENG
Software SAP SAP – SID R3P
SAP – System # 00

Spacely Sprockets
Basis Release 6.20
Code Page 1100
Version 2000
Patch Level 3a
Code Page 1100
PRD - system configuration – application instance server
Hardware Vendor IBM
Model eServer xSeries 336
RAM 4GB
Raid Drives
Host name sttxsapp01
Domain Name
Static Routing
Network Services
OS Vendor Microsoft
Patch Level
Code Page US_ENG
Software SAP SAP – SID R3P
SAP – System # 00
Basis Release 6.20
Code Page 1100
Version 2000
Patch Level 3a
Code Page 1100
4.2.3.2 OS-Users
Application User Name uid Group Name

All R3padm R3padm Local User
SAP_R3P_GlobalAdmin
All SAPServiceR3P SAPServiceR3P Local Users
SAP_R3P_GlobalAdmin
4.2.3.3 File Directory Structure

Spacely Sprockets
E:\TEMPDB MS SQL Server TEMPDB
D:\usr\sap\R3P SAP R/3 System Files
\\sttxsapd01\sapmnt\trans R/3 Domain Transport
G:\R3PDATA1 SAP Database Data
E:\R3PLOG1 SAP Database Log Data

Spacely Sprockets
5. Desktop Environment
5.1 Desktop Environment Overview
The SAP Presentation software comes in three version: SAPGui for Windows, SAPGui
for Java, and SAPGui for HTML. At this time, SAPGui 6.20 Compilation 3 is the most
current version.
SAP does an excellent job of working with software partner Microsoft to keep up with
new Windows technology. A matrix of the supported SAPGui – Windows OS follows.

Spacely Sprockets

Spacely Sprockets
5.2 Desktop Technical Requirements
SAP has exacting technical specifications for workstations supporting SAPGui. These specifications vary
depending on the operating system, patch level of the operating system, and SAP components to be
accessed via the SAPGui instance.
In order to use the most current version of SAPGui which is SAPGui 6.40 Patch Level 4, the following
criteria must be met.
OS OS Service IE IE Service Memor Monitor/Resoluti Process

Pack Pack y on or
Win ME 5.5 64 MB 17” - 1024 x 768 P233+

Win 2000 5.5 64 MB 17” - 1024 x 768 P233+
Win XP 5.5 64 MB 17” - 1024 x 768 P233+
NT 4.0 Service Pack 4 5.5 64 MB 17” - 1024 x 768 P233+

Spacely Sprockets
6. Input & Output Devices
6.1 Device Overview
6.2 Output Devices

6.2.1 Printing
SAP breaks down printer into three categories: local printing, front-end printing, and remote
printing. Local printing is the fastest print method.
Spacely Sprockets will provide a list of all local and remote printers at all supported locations
with IP address, printer model, etc. to be added to SAP. These printer will be added in the SAP
Development systems and ported into the Quality Assurance and Production environments.
6.2.1.1 Local Printing
When you print locally, the SAP spool process sends the data to a printer that is set up on the
operating system of the application server. The print request is then forwarded from the spool
system of the operating system to the relevant printer. You can connect the printer locally to
the computer or you can access it over the network.
6.2.1.2 Remote Printing
The SAP spool process can access any printing system in the network that can handle the lpr/lpd
protocol. This protocol originates from BSD UNIX and is an industry standard for controlling
printing. It is supported by many modern operating systems and by network-enabled printers.
The line printer requester is a client and sends the print data to the server (lpd side). Using this
protocol, various data formats, for example, PostScript or PCL can be transmitted.
Window PCs do not usually have a line printer daemon (lpd). To be able to print using lpr/lpd,
SAP developed its own lpd program for PCs called SAPlpd, which is installed with the SAP
frontend. SAPlpd contains some extensions of the lpd protocol, for example, data compression,
encryption using the SAP standard SNC, and data transmission using the SAProuter.

Spacely Sprockets
Remote printing is the slowest way to print from SAP. Unfortunately, most of the hand-held
output devices will need to be used via remote printing.
6.2.1.3 Front-End Printing
Another option when printing from the SAP System is front-end printing, which lets you access
printers that are not defined in the SAP spool system.
The output data is transmitted directly over the SAPGui to the front-end PC. To do this, the
existing connection between the SAPGui and the application server is used, so that an additional
network connection is not required. The SAPGui starts SAPlpd on the front-end PC and
transmits the print data to it. SAPlpd then sends the data to the Windows standard printer or to
another printer installed on the operating system.

Spacely Sprockets
6.3 List of Input Devices

6.3.1 Input Devices
Input # Vendor Model

Device

Spacely Sprockets
6.4 Output Environment
Output SAP SAP Spool OS Queue Device AccessMet Usage Loca

Type Device Server or Print Type hod
Name name
Print
Fax
Email
Page
Barcode
6.5 Input Environment
Input Device Location Usage Server

Type Name
Barcode
Handheld
PDA

Spacely Sprockets
7. SAP Software Installation
7.1 SAP Software Installation Overview
SAP components must be installed as detailed in the SAP Technical Installation guide for that
component.
All installations will include the following steps:
 Download of latest installation manual

 Setup of Windows environment variables
 Setup of Windows administration users
 Setup of Windows server environment
 Installation of J2EE Java SDK
 Installation of Oracle 9.2 Database
 Patching of the Oracle 9.2 Database
 Installation of SAP Central Instance
 Installation of SAP Database Instance
 Installation of SAP Application Instance (only for systems with additional dialog instances)
 Validation of SAP Installation
 Request and Installation of SAP License
 Creation of Basis Support Team users
 Configuration of Change and Transport System
 Application of outstanding Support Packages
 Import of Add-on components for OLTP and other plug-in support
 Replacement of SAP Kernel
 Mass regeneration of ABAP programs
 Installation of SAP Online Documentation
 Installation of additional languages
 Client copy of client 000 to client 100
 Loading the PCC
 Refresh of database statistics
 Creation of SAP_ALL limited role for Core Team Members
 Creation of Core Team Member users
 Creation of System users
 Creation of RFC links between new instance and existing SAP instances

Spacely Sprockets
 Creation of output devices
This document will not get into the specifics of these or any other installation steps as the SAP
installation procedures are a constantly changing and evolving technology. The latest version of the
installation manuals can be downloaded from http://service.sap.com/instguides.
7.2 Installation of the SAP R/3 Instances
Spacely Sprockets will be installing SAP R/3 Enterprise 4.70 SR 1 on Windows 2000 using Oracle 9.2.
The installation will consist of a database instance and a central instance, plus an additional dialog
instance for R3P. For the R3D environment, all three instances will be installed on one server. For the
R3Q environment, the database will be installed on one server with the central instance on another
server. For the PRD environment, the database instance, central instance, and application instance will
be installed on separate servers.
Spacely Sprockets has elected to implement the following R/3 Enterprise Core products:
<I don’t know this information>
7.3 Installation of other SAP Software
Spacely Sprockets has elected to install a number of additional components and component extensions.
7.3.1 Installation of SAP Portals
This information is not yet available.

7.3.2 Installation of SAProuter

7.3.3 Installation of SAP Connector

7.3.4 Installation of Solution Manager

Spacely Sprockets
8. Change and Transport System (CTS)
8.1 CTS Overview
The SAP system includes a collection of tools closely linked to the ABAP workbench and the customizing
functions, which are very important for managing and coordinating development and customizing work within a
group of SAP systems. These tools form the overall Change and Transport System (CTS).
The CTS components are in charge of performing essential functions in the overall development and
customization environment, and thus in the implementation process as well as in the operation and support after
productive start.
Among the functions of the different CTS tools are:
 Administration and control of new development requests

 Modification and correction of repository objects
 Recording and auditing of all configuration settings and changes
 Configuration of development classes
 Locking of objects to avoid parallel work
 Version management
 Documentation of changes
 Assurance of teamwork development
 Transporting of objects and settings changes among systems
 Logging of transport results
 Setting the system change options
 Recording of where and by whom changes are made
 Configuration of the systems landscape
Integration of the CTS into the SAP landscape is dependent on the correct configuration of the whole transport
chain. The following summary guideline provides the necessary steps for configuring the transport system,
although these steps only have to be performed once. Configuration steps are made up of three basic tasks:
 Configure the transport directory and TPPARAM . The transport directory \usr\sap\trans is created by the
installation program, and is unique within SAP system type. In other words, a \usr\sap\trans directory is
created for all R/3 instances but only one directory is the controlling transport directory for all the R/3
instances. You have to make sure that this directory can be accessed correctly among systems within a
transport group. As of R/3 release 4.6, no manual configuration of TPPARAM is necessary.
 Initialize the change and transport organizer (CTO) . This is accomplished by transaction SE06 and is
one of the first tasks to perform after installation of the R/3 system.
 Create a default development class . To be able to transport development objects, you must define a
class which is not local (such as $TMP) or for test purposes (all starting with T). You should define the
development class in the range allowed for customers, starting with Y or Z.
 Configure transport systems and routes . This configuration step is performed using transaction STMS.
Configuration using transaction STMS should be performed in client 000 of the transport domain, that is
the SAP instance controlling the flow of transports.
Spacely Sprockets will use the standard three systems in a group recommended by SAP, following the design
below. Please note that the Delivery route is determined by the functional team once standards for Change
Release and Approval have been designed.

Spacely Sprockets
Developme Transport
ZXXX
Quality Assurance Production
System
System System
nt
SAP Delivery
8.2 Transport Domains

8.2.1 R/3 Change Transport Management System
R3D will be the CTS domain controller for the SAP R/3 landscape. All R/3 transport cofiles, data files,
logs, etc. will be stored in the \usr\sap\trans directory created during the installation of the R/3 R3D
system. It is mandatory that the R3D \usr\sap\trans directory be accessible by the other R/3 instances,
R3Q and R3P, as well as any application servers dedicated to R/3 added later.
Change request creation will be limited to the R3D 100 and 130 clients.
The ZR3D transport layer will be used to facilitate transport flow from R3D to R3Q and R3P.
Transport
ZR3D
R3Q R3P
R3D
SAP Delivery
8.3 Transporting Changes within a SAP Instance
Change requests may be migrated by users between certain clients in the SAP Development system R3D using
transaction SCC1. The transports do not need to be released before this migration can be done.
8.4 Transporting Changes across SAP Instances
Change requests are moved from the Development instance R3D to the Quality Assurance instance R3Q
automatically. Once transports are released from in instance R3D, they are automatically added to the R3Q
import queue. A job is scheduled to import these changes into the R3Q instance every 15 minutes. The
transports in the R3Q import queue go to clients 200 and 210.
Before a change can be imported into the Production R3P instance, it must be approved using the STMS_QA
transaction by:
The system administration

The request owner
The department head

Spacely Sprockets
Once all three of these roles have approved the transport, a job running daily at 7pm will move the change
requests into client 300 of R3P.
8.4.1 Ownership and Schedule for Transportation of Change Requests
The Basis Support team will perform all manual transports across SAP instances. Transports will occur
between the SAP Development R3D instance and the R3Q instance every 15 minutes. This schedule is
subject to change.
Special requests for transports outside of the normally scheduled times will be performed due to
emergency situations only (ie a Production system is crashing, etc.) Poor planning is not an emergency.
Change requests will be transported across instances at these times:
R3D  R3D Client 100 6am and 6pm daily

R3D  R3Q Client 200 Every 15 minutes
R3Q Client 210
R3Q  R3P Client 300 7pm daily
8.4.2 Releasing Change Requests for Population in the SAP Quality Assurance System
The owner of the change request, or a member of the Core Team designated to this task by one of the
project managers, will release the change request when it is ready to go into the R3Q Quality Assurance
system. Releasing change requests are not the responsibility of the Basis Support Team. Once the
Change Request is released in the R3D Development system, it will automatically be sent to the
transport queue of the R3Q Quality Assurance system. Any change request appearing in the queue of
the SAP Quality Assurance system will automatically be transported during the next scheduled transport
run. More than one entry per change request will appear in the import queue due to movement to
multiple clients in R3Q.
Developers need to be cognitive of the fact that transports are moved into R3Q Quality Assurance and
R3P Production systems in the order that they appear in the transport queue (ie in the order in which
they were released). If any change requests must be run in a specific order, the Basis Support Team
must be notified BEFORE the change requests have been released in order to prevent improper
transport.
8.4.3 Moving Changes from the Quality Assurance System to the Production System
All Change Requests must be approved by both the functional group team leader and a project manager
before being moved into the R3P Production environment. The approval process is in the hands of the
Core Team and can be inserted here at a later date. In order to insure that the Production environment
correctly matches the environment where changes were tested, an approval for production Change
Request may be delayed pending approval of prior Change Requests.
Approval for moves into Production can be either a transactional or written process. SAP supplies the
STMS_QA transaction to facilitate the approval process. This transaction can be configured to meet
Spacely Sprockets needs. If a written approval form is to be used, the form will need to take into
account the 4 component nature of the Spacely Sprockets landscape.
The following page contains an example of a Change and Transport Request Form.
Project Management Date
Approval

Spacely Sprockets
8.4.4 Post-Processing of Change Requests
Change requests can require post-processing after successfully being moved to a target SAP system.
While the Basis Support Team will make every effort to intercept non-zero return codes generated from
a transport run, it must be remembered that a return code of 4 often happens and is commonly ignored.
It is ultimately the responsibility of the Core Team member owning the change request to verify the
proper transportation of the change and to notify the Basis Support Team if assistance is needed with
any post-processing instructions.
8.4.5 Notification of Completed Transport Run to Core Team Members
At the end of each business day, the Basis Support Team will distribute a list of Change Requests
transported that day. This list will be distributed via e-mail using a Spacely Sprockets distribution list.
8.5 Change Request Standards
Change Requests generated by Core Team Members must be attached to a development class supported by the
ZXXX transport layer. These transport layers are:
ZR3D R/3 Development System

SAP SAP’s Standard Transport Layer
The description entered at the time of the Change Request creation must follow the following standard:
WWW: XX: YYY: ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
Where:
WWW is the initials of the owner of the change request
XX is the 2 letter abbreviation of the component
YYY is the client where the change request was generated
ZZZ... is a short description of the change made
Example:
JCS: BC: 000: Application of OSS Note 752052 – FI Fix for GL

Spacely Sprockets
9. Security – Users and Roles
9.1 Security Overview
All SAP users will be assigned roles matching their respective job assignments. These roles will be
initially created by copying a standard SAP supplied role and modifying the copy to match Spacely
Sprockets needs. The authorization objects and authorizations contained in each role will be designated
by the Functional Team and implemented by the Basis Support Team. All role and user configuration
will take place in R3D Development instance client 100.
Once the roles have been created, users will be attached. Users and roles for R/3 will be moved to the
R3Q Quality Assurance system and imported into the Training Golden Client. All users trained in SAP
functionality will be required to use their real user IDs given to them on the final day of user training.
The user’s supervisor will be required to verify that the user has “shaken out” their assigned role and
can successfully perform all tasks for which they have received training.
9.2 Users
9.2.1 R/3 Users
9.2.1.1Core Team Users
R3D: Core Team Members will be assigned a security role designed to allow them as
much access as possible while still securing the R3D instance. At this time 3 roles have
been identified: core team leaders, core team members, and ABAP programmers.
These roles will to designed to facilitate speedy configuration, customization, and
development.
R3Q: Core Team Members will have the same authorizations as in the R3D system.
R3P: Core Team Leads will have the same authorizations as in the R3D system until
post GoLive when they will be assigned to roles fitting their regular SAP duties. Core
Team Members, including Experio consultants, will be assigned to a display only version
of the SAP_ALL role.
9.2.1.2Communication Users
Special communications users will be created in all three R/3 instances to facilitate
remote function calls between the SAP systems and to other external non-SAP
programs. These users are password protected but do not require a SAP log on screen.
These users will have all authorizations needed to perform the specific tasks to which
they are designed. Users ALEREMOTE, WF_BATCH, RFC_USER, TMSADM and ITSUSER
are included in this group. Other communications users for SAP Portals, TREX, etc. will
be added as needed.
9.2.1.3Basis Users
The Basis Support Team will be directly connected to the SAP_ALL and SAP_NEW
profiles. The SAP supplied users SAP* and DDIC will have their passwords changed as
soon as post-installation work as been completed.
9.2.1.4Non-Core Team Users
All users outside of the Core Team must be assigned to a limited security role in all R/3
systems.

Spacely Sprockets
9.2 Central User Administration
Spacely Sprockets will implement Central User Administration (CUA). R3D Client 100 will be the parent
client with R3Q Client 200 and R3P Client as children in the CUA model. The Basis team will create and
maintain this model using CUA specific transactions SCUA, SCUM, and SCUL as well inbound and
outbound RFC/ALE queue functions such as SMQS.
10. System Maintenance
10.1 System Maintenance Overview
SAP maintenance comes in the form of support packages and kernel replacements.
Support packages are changes and fixes to SAP ABAP code, and thus must be applied from within the
SAP instance using transaction SPAM in client 000 by a non-DDIC user.
Kernel patches are changes and fixes to SAP executable files stored on the operating system of the SAP
server. Kernel patches may require that the SAP instance be taken down in order to replace programs in
use when an instance is up. They are applied by a simple file overwrite by the <sid>adm of the SAP
instance.
It is important to note that it is in Spacely Sprockets best interest to install and maintain one Basis
version 6.20 and avoid having different Basis version combinations like 4.6D and 6.20. This will provide
uniformity for moving changes between systems as well as making the system maintenance process
easier to perform.
10.2 Support Packages
All released support packages will be applied immediately after SAP system installation. After initial
installation, support packages will be installed every two months, and in an emergency on demand.
Application of support packages will be stopped six weeks before GoLive and only SAP Notes application
to correction known problems.
The support packages will be applied in the Development instance of the SAP landscape. After one
week, the support package will be applied to the Quality Assurance instance following by installation in
the Production instance a week after that.
Mass generation of all ABAP programs will be performed after every support package application.
10.3 Kernel Patches
The newest kernel for the R/3 software will be downloaded and applied at installation time. On other
kernel patches will be done unless it is a SAP recommendation to resolve an issue.
A kernel patch will first be applied to the R3D Development instance of the SAP landscape. As soon as
the patch can be successfully tested, it will be moved into R3Q Quality Assurance and R3P Production.
10.4 Upgrades
Upgrades to new versions of SAP software is not covered in the scope of this project.

Spacely Sprockets
11. Backup and Recovery
11.1 Backup
The database of a SAP system contains critical company data, which is protected by a backup strategy.
A backup strategy must be planned carefully to meet a company's individual requirements and tested to
see if it works.
An intact and current database backup is crucial for database recovery. Recovery time is a critical factor
as R/3 is primarily an online transaction processing application. The backup strategy should clearly
define procedures for fast restore and recovery.
The correct backup strategy is determined by the:
 Data volume requiring backup
 Tools available for backup
 Time available for complete database recovery
There are two basic types of failure which require database recovery:
 Media failure affecting particular data files, or the entire disk.
 Logical failure, for example, inadvertently modifying or dropping a table.
For a MS SQL Server database, you need to back up the:
 Data Files
 Log Files
Hitachi Consulting has provided Spacely Sprockets with a DOS Batch file that will backup the database
and log files on each R/3 server. It consists of the following code:
@echo off
rem For R3D---Create a directory on <backup_server> called R3DBackup
if exist e:\usr\sap\R3D\SYS\exe\run\saposcol.exe (
net stop MSSQLSERVER
xcopy \\10.2.5.10\R3DDATA1\R3DDATA1.mdf \\<backup_server>\R3DBackup /Q /H /S /Y
xcopy \\10.2.5.10\R3DDATA2\R3DDATA2.ndf \\<backup_server>\R3DBackup /Q /H /S /Y
xcopy \\10.2.5.10\R3DDATA3\R3DDATA3.ndf \\<backup_server>\R3DBackup /Q /H /S /Y
xcopy \\10.2.5.10\R3DLOG1\R3DLOG1.ldf \\<backup_server>\R3DBackup /Q /H /S /Y
net start MSSQLSERVER
goto :AllDone
)
rem For R3Q---Create a directory on <backup_server> called R3QBackup
if exist e:\usr\sap\R3Q\SYS\exe\run\saposcol.exe (
xcopy \\10.2.5.11\R3QDATA1\R3QDATA1.mdf \\<backup_server>\R3QBackup /Q /H /S /Y
xcopy \\10.2.5.11\R3QDATA2\R3QDATA2.ndf \\<backup_server>\R3QBackup /Q /H /S /Y
xcopy \\10.2.5.11\R3QDATA3\R3QDATA3.ndf \\<backup_server>\R3QBackup /Q /H /S /Y
xcopy \\10.2.5.11\R3QLOG1\R3QLOG1.ldf \\<backup_server>\R3QBackup /Q /H /S /Y
)
rem For R3P---Create a directory on <backup_server> called R3PBackup
if exist e:\usr\sap\R3P\SYS\exe\run\saposcol.exe (

Spacely Sprockets
xcopy \\10.2.5.15\R3PDATA1\R3PDATA1.mdf \\<backup_server>\R3PBackup /Q /H /S /Y
xcopy \\10.2.5.15\R3PDATA2\R3PDATA2.ndf \\<backup_server>\R3PBackup /Q /H /S /Y
xcopy \\10.2.5.15\R3PDATA3\R3PDATA3.ndf \\<backup_server>\R3PBackup /Q /H /S /Y
xcopy \\10.2.5.15\R3PLOG1\R3PLOG1.ldf \\<backup_server>\R3PBackup /Q /H /S /Y
)
@echo "Don't know this server"
:AllDone
To increase fault tolerance, SAP and Microsoft recommend mirroring the control files and online redo log
files. The mirrored copy of a file should be on a different physical disk than its corresponding original
copy. To increase fault tolerance even further, connect the disks to different disk controllers.

Spacely Sprockets
11.1.1 Backup Overview

SAP recommends a backup cycle of at least four weeks. This means that you cannot overwrite a tape
used for database or offline redo log backup for at least four weeks. The larger the backup cycle, the
more backups are available for recovery. Large backup cycles help protect against errors which are not
immediately apparent.
Backups can be done with the database either online (hot) or offline (cold). Performing online backups
instead of offline backups:
 enables 7x24 hours operation of the R/3 system
 avoids the performance loss caused by database buffers needing to be reloaded after an
offline backup
Since online backups put an extra load on the hardware resources of the database server, online
backups should be performed when system activity is low and no time critical jobs are running, (for
example, at night).
If system availability requirements permit, a full offline backup should be performed at least once during
the backup cycle. The consistency of offline backups does not depend on the intactness of offline redo
logs, as is the case with online backups. For recovery you need the complete sequence of offline redo
log files since the last backup - for online backups or offline backups.
In addition to the database backup, you need to backup the offline redo log files. If any one of the
offline redo log files is unusable, for example, due to a physical tape error, complete recovery is not
possible. Therefore, you should save each offline redo log file twice on different tapes.
 All redo log files in the archive directory which have been archived once are written to tape.
 All redo log files which have been archived twice are deleted from the archive directory.
 All offline redo log files which have not yet been archived are written to tape SAP
recommends repeating this procedure daily, to:
 ensure data security
 reduce the amount of redo log data in the archive directory
One of the most critical errors is the "archiver stuck” situation, which causes a complete standstill of the
database and hence of the R/3 System. This error occurs when no more free space is available in the

Spacely Sprockets
archive directory. To prevent "archiver stuck” situations , the size of the archive directory should be at
least four times the average volume of redo information generated per day.
11.2 Recovery
There are different reasons why errors may occur that make it necessary to restore the database:
· Disk failure
A disk may crash resulting in the loss of the transaction log or database files.
· User fault
A user may, for example, unintentionally delete a file or import a wrong transport.
· Database corruption
In rare cases, a logical error may be discovered in the database.
· Move to different hardware
A disaster might have destroyed existing hardware or a move to faster hardware might be
necessary.
After a power failure the database does not have to be restored. When the power is cut off, the system
shuts down abruptly and the execution of transactions is interrupted. The SQL Server has an automatic
recovery mechanism to deal with this situation. When the database is restarted, an automatic recovery
mechanism starts working. This means open transactions are rolled back and completed transactions
that were not written to the data files at the time of shutdown are re-executed.
The most effective method to restore a database depends on the type of error that has occurred.
Finding out exactly what happened is therefore the first step in any restore process. The following
describes different error situations and gives an overview of the steps required to restore the database
in these situations.
11.2.1 Restore After Disk Failure
The procedure to follow in order to repair a damaged database after disk failure differs, depending on
how files have been allocated to disks and which of these disks have been damaged. This
documentation assumes that you have distributed your system to 3 different disk systems. This complies
with SAP’s recommendations that at least the following components of your system should be located
on different disks:
· Log files of the SAP database

· Data files of the SAP database
· SAP, SQL Server and Windows executables, and other databases, for example, msdb,
master and tempdb

Spacely Sprockets
11.2.2 SAP Data Disk Crash
The SAP database normally resides on a RAID5 storage system for increased protection against data
loss. If a single disk fails it simply needs to be replaced and will not disrupt database operation.
However, if the whole RAID system crashes, the consequences are serious. The SAP database will be
damaged, work in the system will come to a standstill and a database restore will have to be performed
before resuming normal work.
To restore the database after this type of failure, you first have to immediately backup the most recent
transaction logs. Once this has been done, you can restore the database by loading the latest database
backup and applying the succeeding transaction log backups.
11.2.3 SAP Log Disk Crash
The SAP log records all the changes that are made to the database. They enable transactions to be
redone when a database is restored and therefore play a central role in any restore operation. For this
reason, SAP recommends that they be written to a RAID1 storage system that ensures data is protected
against loss by a mirroring strategy. The transaction log will only be lost, if the original and mirrored log
disk fail.
If the entire log disk system crashes, you need to proceed in the same way as for a failure of the SAP
data disk. The only difference is that you will not, in a first step, be able to backup the transaction logs
that were in use at the time of the failure. You have to begin by restoring the most recent database
backup and then continue with the application of the available transaction log backups.
You can only restore your database to the state it had at the time of the last log backup. All the
following changes are lost because the current transaction log is damaged and it is therefore impossible
to re-execute the changes it contains.
11.2.4 Executables Disk Crash
If your disk system with all other files except the transaction log and SAP data files fails, this has far
reaching consequences for the system. The Windows operating system, SAP executables, SQL server
executables, msdb and master databases will be gone.
The best way to rectify the situation is to restore the crashed disk on the basis of the last available full
Windows backup.

Spacely Sprockets
11.2.5 Restore after User Fault
A user might erroneously delete a table or import a wrong transport. Depending on what has happened,
there are different ways in which you can proceed. One of the options that may be useful is a point in
time recovery. It can restore the database to the state it had on a specific day at a specific time. Before
you implement this procedure, SAP recommends that you first perform a full Windows backup. This
safeguards you from losing your data, if the tape for restoring the database is unreadable.
For more information see the SQL Server Books Online.
11.2.6 Restore after Database Corruption
When you recognize that the data in your database is corrupted you need to diagnose the problem more
precisely. The optimal method of restoring the integrity of the database depends on the extent and
cause of the damage. You probably need assistance from your SAP Basis consultant, in order to analyze
the error and find the most effective solution. It may be possible to repair the corrupted database. Other
options are:
· Database and transaction log restore
· Point in Time Recovery
11.2.7 Move to Different Hardware
There are two reasons why you may need to restore the entire system on different hardware:
· Total loss of hardware.

· Database copy, for example from a test system to a productive system.

Documentacao Servidor SAP

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Documentacao Servidor SAP

Încărcat de

Drepturi de autor:

Formate disponibile

Spacely Sprockets

Technical Infrastructure Document

1.3 Change History.........................................................................................................................................4

2. SAP SYSTEM & CLIENT LANDSCAPE............................................................5

2.2 SAP Three System Landscape.................................................................................................................5

2.3 Two-Tier, Three-Tier and Three-Tier Distributed SAP Instance Setup..............................................5

2.5 SAP Clients...............................................................................................................................................7

2.5.13 Client Refresh Procedures...................................................................................................................9

Copyright © 2000 SAP AG. All rights reserved 1

4.2 R/3 Enterprise Landscape....................................................................................................................13

5.2 Desktop Technical Requirements..........................................................................................................20

6. INPUT & OUTPUT DEVICES..............................................................................21

6.2 Output Devices........................................................................................................................................21

6.3 List of Input Devices..............................................................................................................................22

6.4 Output Environment...............................................................................................................................24

6.5 Input Environment..................................................................................................................................24

7. SAP SOFTWARE INSTALLATION..................................................................25

Copyright © 2000 SAP AG. All rights reserved 2

7.3 Installation of other SAP Software........................................................................................................26

8. CHANGE AND TRANSPORT SYSTEM (CTS)...................................................27

8.2 Transport Domains................................................................................................................................28

8.3 Transporting Changes within a SAP Instance.....................................................................................28

8.4 Transporting Changes across SAP Instances.......................................................................................28

8.5 Change Request Standards...................................................................................................................30

9. SECURITY – USERS AND ROLES................................................................32

9.2 Central User Administration.................................................................................................................32

10. SYSTEM MAINTENANCE...............................................................................33

Copyright © 2000 SAP AG. All rights reserved 3

10.2 Support Packages....................................................................................................................................33

10.3 Kernel Patches........................................................................................................................................33

11. BACKUP AND RECOVERY.............................................................................34

Copyright © 2000 SAP AG. All rights reserved 4

1.1 Company Data

1.3 Change History

Date Name Description of Changes

Copyright © 2000 SAP AG. All rights reserved 5

2. SAP System & Client Landscape

2.1 SAP System Landscape Overview

2.2 SAP Three System Landscape

The following is a diagram of the typical SAP three system landscape:

2.3 Two-Tier, Three-Tier and Three-Tier Distributed SAP Instance Setup

Copyright © 2000 SAP AG. All rights reserved 6

2.4 R/3 Enterprise Instances with Host Names

system # system name description Hostname of CI SAP installation number

2.5 SAP Clients

Client Purpose currency category client- client-

Copyright © 2000 SAP AG. All rights reserved 7

No configuration will be entered

Future client copies will

This client is created from a

Copyright © 2000 SAP AG. All rights reserved 8

2.5.2 R3Q – Clients

Client Purpose currency category client-dependent client-independent

Client containing “Good” Training Data.

2.5.3 R3P – Clients

Client Purpose currency category client-dependent client-independent

It will be created based on the Production Build

Copyright © 2000 SAP AG. All rights reserved 9

2.5.13 Client Refresh Procedures

Source target client copy justification frequency reference #

Copyright © 2000 SAP AG. All rights reserved 10

3.1 Network Topology Diagram

Information not yet available.

3.1.2 Local Area Network