Sap Basis

The Basics of Basis
Administration:
Architecture, Interfaces,
Monitoring, and More!
Matt Lonstine
Symmetry Corporation
© Copyright 2014
Wellesley Information Services, Inc.
All rights reserved.
In This Session
• We will dive into the nuts and bolts of Basis Administration and
provide tips for administrators to ensure your SAP landscape
runs smoothly and efficiently
• For those new to Basis Administration, this session will provide
the groundwork you need to succeed, and more experienced
administrators will find it a useful refresher
• Come away with a clear understanding of SAP basic architecture,
interfaces, monitoring techniques, and much more!
1
What We’ll Cover
• Intro the standard architecture for small, medium, and large SAP
landscapes
• Overview of server equipment/infrastructure needed
• Monitoring Fundamentals
• System Performance Metrics and Customized Operations
Reporting
• Tip to current system performance and maintenance best
practices for life of SAP application
• SAP Fundamentals: pinpoint performance measurements from
hardware, database, and application layers
• Database Optimization – archiving, DB compression
• Monitoring and Business Expectations (IT role in Basis)
• Wrap-up
2
SAP Architecture – Small
• The most simple SAP architecture took the following forms:
3
Typical Very Small SAP Landscapes
• One-time, “big bang” implementations

• No ongoing rollouts
• Less than 100 users, less than $100M enterprise
• Appropriate for small SAP Business All-in-One implementations
• QAS server often added later
4
Typical Small SAP Landscape
5
Typical Small SAP Landscape (cont.)
• Three-system landscape (per major SAP application) most

common in SAP implementations
• Changes tested and promoted from DEV  QAS  PRD
• Servers running SAP database and application processes connect
through Local Area Network (LAN) or Wide Area Network (WAN) to
end users
• Usually SAP application processes and database processes run
on the same server – 2-tier architecture
6
SAP Architecture – Medium
• Typically referred to as Distributed environments, load balancing

becomes possible in this scenario
7
Typical Medium SAP Landscape
8
Features of a Medium SAP Landscape
• More and more SAP implementations involve multiple major SAP

applications
• With larger total data storage requirements, Storage Area Network (SAN)
technology starts to make sense
• An SAP Solution Manager system is required by SAP
• A pre-DEV system, typically called “sandbox” (SID=SBX) becomes
necessary
 System to prototype new SAP functionality without impacting SAP
production or the support of production
 System to test new infrastructure operations
 E.g., test a new tape backup device
• A 3-tier architecture with multiple application servers becomes

necessary with higher concurrent SAP user counts
 Application servers give most flexibility/control for administrators
9
SAP Architecture – Large
• In a large configuration, all potential individual instance options

are separated out into their own
10
Typical Large SAP Landscape
11
Features of a Large SAP Landscape
• Numerous systems to deploy and operate

• Larger technical staff and more complex operations
• Addition of a “Production break/fix” (PFX) system
 Copy of PRD data
 Used for testing of PRD problems without impacting production

or in-progress testing
• Larger, more exotic SAN architecture
• Deployment, operation of disaster recovery systems
 Additional set of “stand-by” servers to be used in case of a
disaster to primary servers
 Enables continued SAP application availability in the event of
the failure of primary SAP systems
12
SAP Architecture – New
• The standard SAP instance terminology has changed as of SAP

NetWeaver® 7.3
13
SAP Architecture – Changes for 2014
• Support has ended in 2013 for the following items:
 End of most dual-stack configuration options

 Most applications no longer offer a dual-stack option
 Separate stacks are required with the exception of Solution

Manager and PI
 Dual-stack option has been removed from sapinst or
Software Provisioning Manager
 7.2x onward kernels (DCK) are now standard
 Downward-compatible kernel versions are now the only
maintained kernels
14
Major SAP Applications Requiring Separate
Landscapes
• SAP ERP (Enterprise Resource Planning)
 Major functionality or “modules” within ECC
 Financial Accounting (FI)
 Controlling (CO)
 Sales and Distribution (SD)
 Materials Management (MM)
 Warehouse Management (WM)
 Quality Management (QM)
 Plant Maintenance (PM)
 Production Planning (PP)
15
Landscapes (cont.)
• SAP Business Information Warehouse (SAP BW)
 SAP NetWeaver® Business Intelligence (SAP NetWeaver BI)
 Data warehousing, modeling, and reporting
• SAP Customer Relationship Management (SAP CRM)

 Sales-centric customer management
• SAP Supply Chain Management (SAP SCM)

 Planning, collaboration, and coordination of supply chain
• SAP Supplier Relationship Management (SAP SRM)

 Analysis, sourcing, invoicing throughout supply chain
• HANA, SAP BusinessObjects

 Analytics tools and Business Suite database alternative
16
Landscapes (cont.)
• SAP NetWeaver Master Data Management (SAP NetWeaver MDM)
 Centralized storage and management of Master Data
• SAP Product Lifecycle Management (SAP PLM)

 Manage design, production, sales, and enhancements of products
• SAP Enterprise Portal (up to 6.0); SAP NetWeaver Portal

 Java-based Web portal application
• SAP NetWeaver Exchange Infrastructure (SAP NetWeaver XI)

 Process-centric collaboration among SAP and non-SAP applications
• SAP Solution Manager

 Facilitates technical support for SAP systems
 Now mandatory
17
Landscapes (cont.)
• Significantly reduce total cost of operations with Solution Manager
features
 Project Management
 Project Administration
 Service Desk
 Change Request Management
 Custom Development Management
 Solution Documentation
 Central Monitoring
 EarlyWatch Alerts
 Service Level Reporting
 Change Reporting
 Central System Administration
 Impact Analysis
 Central Job Scheduling
18
What We’ll Cover
landscapes
Reporting
• Wrap-up
19
Modern Servers
• Computing technology is continuing to change rapidly

 More computing power for less money
 Smaller physical sizes
 Amount of data storage exploding exponentially
 A standard SAP environment 3 years ago is now ½ the physical

size and twice the performance
• Best practices for SAP server technology “refresh”

 No Production servers over 3 years old
 No other servers over 5 years old (e.g., “DEV” and “QAS”)
 Couple server replacements as part of SAP software upgrade

cycle
20
SAP and the Cloud
• Public cloud
 SAP offers cloud applications like HANA, Business Suite on
HANA
 There are caveats to use cases or scenarios that can be
deployed (data size, throughput, connectivity)
• Private cloud
 This refers to a structured technical environment that includes
networking, storage, and computing power
• Hybrid cloud
 A combination of SAP deployment between on-premise and
cloud architecture
 Example: On-demand testing environment in the cloud
21
Modern Servers
• Performance gains are a valuable hidden ROI

 An “hourglass” on the screen lasting more than a couple of
seconds breaks user’s concentration
 1/10th of a second increase in response times for 200 users =
real ROI
• The first questions when tackling performance bottlenecks are:

 Do I have enough SAPS for the workload?
 Are there any bottlenecks that would limit capacity?
22
Storage
• SAP database sizes typically range in the 300GB to 1.5TB

• “Hard drives” remain the staple in SAP server environments
• “Spindle” count (i.e., number of hard drives) is critical in
database applications
 Numerous smaller disks are better than fewer larger disks
 Storage systems offer different “caching” features to achieve

high performance on the most frequently used data
 Storage systems offer tiered disk groups to present adequate
storage performance to the SAP systems
 Platinum disk – Production
 Silver disk – Quality Assurance
 Bronze disk – Development, Sandbox
23
Storage Technology Options
• SAN features
 Able to reallocate storage to different servers
 Lots of intelligence – caching, replication
 More options for copying, backing up data
• SANs are not inherently wonderful

 Expensive
 Tend be sold with a few large disks = poor database

performance
 Higher expertise to operate
24
SAP Storage Options
• The hardware is not the only variable in the equation

 HANA
 HANA’s speed is touted as a major selling point but

remember that the technology will become your RDBMS
 Using Solid State Drives (SSD) for selective tables may
provide adequate ROI
 HANA will support “most” SAP applications
 If you need to maintain a mixed RDBMS environment, you

will need to factor support and training into the equation
 Migrating to HANA may require upgrades, migrations
 There are requirements between SAP NetWeaver 7.31-7.4

and Unicode that are prerequisites to running HANA
25
Parts of an SAP Network Environment
Wide Area Network (WAN)
Ethernet
Cable Switch/Hub
Firewall
Router
26
Issues with Networking That Impact SAP
• Network bandwidth/segregation
 Need a big enough “pipe” for all needs, not just SAP
 Don’t want printers on same network as servers
• Network redundancy/reliability
 Dual switches/firewalls/routers
 If one device goes down, end users still in business
 Dual networking paths
 If one network connection goes down, end users still in

business
• Network security
 No hackers allowed in!
 Prevent introduction of viruses, etc.

27
Issues with Networking That Impact SAP (cont.)
• Network scalability
 Can your network grow with your needs?
• SAP GUI is considered a “light” client

 Not very heavy network load
 SAP network traffic seldom a source of trouble
• Network “maintenance” can be a big source of irritation in SAP

environments
28
SAP Application Architecture – Instance
• If both the SAP application and database processes

run on one physical server, it is called “2-tier
architecture”
• If they run on separate physical servers, it is called
“3-tier architecture”
Source: Page 34, SAP R/3 System Administration, SAP PRESS
29
SAP Application Architecture – Traditional
• When an SAP end user presses ENTER, the SAP GUI user screen
data is sent (via TCP/IP network packets) to the dispatcher where
it is queued for processing by a work process
 No network traffic until end user presses ENTER
 Queuing based on first-come, first-served basis
 SAP ABAP programs process business logic
 Number and type of SAP work processes is configurable
 The more work processes,

the shorter the “wait state”
 Number of work processes
limited by physical
memory of server and other
factors
30
SAP Application Architecture – Traditional (cont.)
• SAP Dispatcher
 When an SAP end user logs into an SAP system, a set of
memory is allocated on the application server by the
“dispatcher” process
 Dispatcher process stores user’s SAP security profile and
information about user’s SAP session
 E.g., remembers previous screen when you click “green
arrow back”
31
• SAP Dispatcher (cont.)

 Size and characteristics of memory allocation set by SAP
system parameters
 Parameters set in a text file and read by the Dispatcher at
startup
 To change parameters, SAP application serving processes
must be stopped and restarted – requires an outage!
 Multiple application servers mitigate outages
 Size of memory limited by physical memory of server and

other factors
32
• Database thread
 SAP work processes result in simple SQL statements sent to a
coupled RDBMS “thread” process
 May or may not be on same physical server
 “2-tier architecture” means SAP and RDBMS processes run

on same server
 “3-tier architecture” means SAP application processes run
on a separate server from the RDBMS server
33
• Database thread (cont.)

 Database thread process calls the database and read/write/
update/delete actions performed
 Database thread returns results to SAP work process, to
dispatcher, and back to the end-user SAP GUI
 Large results buffered in dispatcher
 Downloaded to SAP GUI one page at a time
 Architecture makes for “light” network traffic and end-user

PC requirements
34
SAP Java Application Architecture
35
SAP Java Application Architecture – Web
• Numerous advantages to accessing SAP via a Web browser

(e.g., Microsoft Internet Explorer)
 No PC client application to deploy and maintain
 “Magic” for access via mobile and other end-user devices
 SAP doesn’t have to code the interface (already done by

the standard browser)
 End user doesn’t have to know what server they’re
connecting to
 Enables end-user business process orientation vs. “log-in here, log-in
there” application orientation
 End user logs into his/her job, not into a set of computer
applications
 Key philosophical component of enterprise service-oriented
architecture (enterprise SOA)
36
SAP Java Application Architecture – Web (cont.)
• May not solve all your problems

 Performance is slower for high volume SAP users
 Those performing many, many transactions
 More complex architecture
 Not all the bugs worked out
37
Security Tasks
• RSECNOTE
 Run bi-weekly or monthly to assess critical security gaps
affecting SAP applications
 Security corrections are contained in support packs
 Depending on support pack cycle frequency, you may be

somewhat current on security notes
 Quicklink for SAP Security-related information –

http://service.sap.com/public/security *
* Requires login credentials to the SAP Service Marketplace
38
Security Tasks (cont.)
39
• SAProuter
 The software firewall that SAP uses to provide support
 Don’t assume it’s secure!
 SAP Notes explain risks and remediation to make sure

SAProuter is secure
 Install the latest release
 Validate your saprouttab contains only current systems

and ports
 Think about ways to secure the SAProuter host (DMZ)
40
• Gateway security
 Methods as of Kernel 6.40 to secure the gateway against
unauthorized access
 Profile parameters
 gw/sec_info = $(DIR_GLOBAL)$(DIR_SEP)secinfo or
 gw/reg_info = $(DIR_GLOBAL)$(DIR_SEP)reginfo
 Access Control Lists (ACL) maintained through reginfo or

secinfo files
 P|D TP=name [NO=<n>] [HOST=<host>] [ACCESS=<host>]
[CANCEL=<host>]
41
What We’ll Cover
landscapes
Reporting
• Wrap-up
42
Daily Monitoring
• Daily Monitoring is all about being proactive

 CCMS or Technical Monitoring helps display key metrics
OS Database SAP
CPU DB File free space Work Process Availability
Memory DB Log free space Update Availability
Disk Cache performance ABAP Dump quantity
Paging/Swap Backup Status System Availability
Java Memory Performance
Many more …
 Create alerts for the checks above and other critical business
functions to notify appropriate team members
43
Daily Monitoring – Database Analysis
• Consolidate DB views into SAP Solution Manager

 This is useful when you consider HANA, SAP BusinessObjects
which lack standard ABAP monitoring tools
44
SAP GUI and Other Connectivity
• Managing connectivity is becoming more challenging due to the

multitude of options beyond SAP GUI
SAP
BusinessObjects
45
SAP GUI and Other Connectivity (cont.)
• How to tackle the challenge

 Consolidate external access
 Citrix
 Xen
 Organize delivery
 SAP GUI Server
 Central application deployments with preconfigured

connection properties
 Coordinate authorizations
 Single sign-on
 Active Directory, LDAP, SAP UME
46
What We’ll Cover
landscapes
Reporting
• Wrap-up
47
SAP Performance – SQL Analysis
• Analyze statements from transaction ST04

 Poor SQL performance can be highlighted in EWA too
• Organize statements by heaviest Elapsed time, buffer requests

and then by memory usage
 Keep in mind the number of executions to get put into
perspective how often then operations are accessed
• To analyze the individual statements, execute an explanation on
the statements to examine the efficiency and estimated resource
usage to perform the statement
• Look for notes on standard programs and tables that rank highly
48
Evolution of Basis
• As Analytics and Reporting have taken off, Basis responsibilities

have grown to include monitoring performance related to SLT,
HANA, SAP BusinessObjects, and associated applications
 Typical scenarios include:
 SLT Monitoring for active and failed queues
 Monitoring of SAP BusinessObjects performance, stability
 Monitoring HANA performance
49
Weekly Activities
• Review EarlyWatch Alerts

 Aggregate view of system performance and recommendations
 Great way to see trending information of important metrics
• Review SAP buffers performance

• Review Java performance
 Java heap memory usage
and daily throughput
50
Quarterly/Bi-Annual Activities
• Review throughput of all application I/O areas

 Are there work process bottlenecks?
 Are there performance “hot spots”?
 Daily peak load periods
 System Activity bottlenecks (backups, nightly batch, etc.)
 Review your worst performing transactions or processes
 SAP Services available to address SAP and custom code

between the database and application
 Kernel updates
 Develop a strategy to apply the latest or n-1 kernel version to

all systems
51
Quarterly/Bi-Annual Activities (cont.)
• Technical Upgrade Opportunities

 Operating System
 OS Patching
 Example, monthly patching of Windows systems
 Review the SAP Product Availability Matrix for approved OS

revisions or full versions
 Database
 All Database patches must be approved and validated by

SAP
 Check PAM for approved DB versions like SQL Server 2008
R2 or Oracle 11.2.0.3
52
• Update ST-PI, ST-A/PI in all ABAP-based systems

 EarlyWatch Alerts and any other SAP delivered services
depend on these components being current
• SAP Upgrades (Version Upgrades, Enhancement Packs, Support
Packs)
 Tools
 Upgrade Dependency Analyzer
 Helps identify business process dependencies and related

notes for explanations
 Business Function Prediction Service
 Uses SAP transactional history to validate the use of new

business processes based on enhancement pack
53
• As Basis, help determine application scenario dependencies
Source: SAP 54
• The goal is to see the forest from the trees. Where are the trends
in IT performance and the business agenda that we would use to
set direction?
 User population growth needs to be tracked
 Are users being spread out across applications servers?
 Database growth
 How quickly is data being added to the SAP databases?
 System activity
 Are new business requirements and initiatives adding

background jobs among other traffic in and out of the SAP
system?
55
• So what are my tools?

• User and System load management
 SM50 in each application instance can show you historical load
among process types
56

• Basis table maintenance
 SAP Note 706478 – Preventing Basis tables from increasing
considerably
 Over 60 tables that can be addressed for excessive growth
 Table cleanup ultimately will yield some performance gains

as table sizes decrease
 Standards will need to be created for data retention of tables

that require archiving for cleanup
57

• Archiving – Information Lifecycle Management (ILM)
 What are the benefits?
 Optimize system performance
 Control database growth
 Generate ROI
 Prerequisite to deleting old data
 What is achieved?
 Less data – faster queries
 Improve batch processing (shorter run times)
 Improve overall user experience
58
• Sizing
 SAP sizing should be an ongoing topic not only when reviewing
hardware refresh cycles
 SAP Quicksizer
 SAP standard tool to determine hardware resources

required to support the application with a given workload
 SAP Benchmarks – quicklink/benchmark
 Published performance for different vendor hardware

configurations against 2,000 business process orders
 Vendor tools
 Example: IBM Insight or HP TVMS
59
Specific Application Monitoring
• BW/BI
 Process Chain failures – RSMO, Solution Manager BW
Monitoring
 PSA-related table cleanup – RSA1, RSMO
• SCM – liveCache
 Health checks – /SAPAPO/OM13
 liveCache availability – LC10
• Portals – SAP NetWeaver
 Memory performance
 Portal Service Availability – SAP Solution Manager
• Process Integration
 Component, Message Monitoring – SXMB_MONI, Solution
Manager PI Monitoring
60
Business Intelligence (BI/BOBJ)
• SBOP BI Platform
 Mandatory for all business scenarios
 Central Management Console (CMC)
 Central Configuration Manager (CCM)
 Repository Diagnostic Tool
 SAP BusinessObjects Software Inventory Tool
 Upgrade management tool
• BI Launch Pad
 Installed with the BI platform
 SAP BusinessObjects Analysis, edition for OLAP
 SAP BusinessObjects Web Intelligence
 SAP BusinessObjects Explorer
 BI workspaces
61
SAP Lifecycle Management
• SAP ERP (Enterprise Resource Planning)

 Includes SAP ERP Central Component (SAP ECC)
 Key versions and progression
 SAP R/3 3.0F
 SAP R/3 3.1I
 SAP R/3 4.0B
 SAP R/3 4.6C
 SAP R/3 4.7
 mySAP ERP 2004 (with SAP ECC 5.0)
 SAP ERP 6.0 (with SAP ECC 6.0)
 Enhancement Packages
62
SAP Lifecycle Management (cont.)
63
• Enhancement Packages (EHPs) taking the place of traditional

upgrades
• Support Packages are NOT the same as Enhancement Packages
 EHPs provide optional new/improved functionality like:
 Simplified business processes and user interfaces
 Industry-specific enhancements
 Enterprise Service Bundles – enabling SOA
 Support Packs usually considered part of the general

maintenance strategy and include:
 Corrections to existing ABAP and Java components
 SAP Notes too complicated for SNOTE
64
• Enhancement Packages are cumulative – currently at EHP 7

for ERP
• Enhancement Packages are easy to implement from a functional
perspective
 Company chooses which functionality to “turn on” in the EHP
 Less testing required
• BUT from the technical side EHPs require much the same
investment as a traditional upgrade
65
Solution Manager 7.1
• A full suite of Basis tools for Technical Operations

 Solution Manager 7 is out of mainstream support
 Solution Manager 7.1 SP10 is latest available
 Required system for approving support packs and retrieving

necessary upgrade and enhancement pack media
 CCMS has been supplanted by Diagnostics Agents in support
of Technical Monitoring (there are exceptions to this)
66
Solution Manager 7.1 (cont.)
• Technical Monitoring
• System Monitoring App
67
Solution Manager 7.1 (cont.)
• Beyond system status and metrics, many other tools available to

provide insight to the environment
 Root Cause Analysis
 Data Volume Management
 BW, PI Monitoring
 More!
• When coming up with Solution Manager use cases, ask yourself

where there are gaps in your environment for monitoring,
reporting, and alerting
• Many other tools available in Solution Manager outside of
Technical Operations that meet needs between the IT and the
business
68
Sizing Solution Manager 7.1
• SAP has provided a guided spreadsheet to help understand the

resources required for Solution Manager based on technical
scenarios and connected systems
• Covers current requirements and three year storage projections

69
Kernel Maintenance
• In the past, your kernel version was dictated by the SAP

NetWeaver version
 Example:
ECC ECC 6 ECC 6 ECC 6
Release EHP4 EHP6
Kernel 7.0 7.01 7.20
 Source: http://service.sap.com/pam *
 Downward Compatible Kernels
 As of SAP NetWeaver 7.0 forward, you can use a unified 7.20/
7.21 kernel version
 Follow the instructions in SAP Note 1636252 closely for your
specific landscape requirements
* Requires login credentials to the SAP Service Marketplace
70
Kernel Patching
• Rolling Kernel Switch (RKS)

 Depending on your system architecture, you can now perform
kernel patches “online” through a process in which each
instance is patched individually
 Requirements
 Kernel version 7.10 onward
 ASCS instance configured (separate central services)
 Separate instance file systems (/sap/<SID>/<instance>/exe)
*SAP Note 953653 needs to be reviewed for incompatible kernels
71
Kernel Patching – Gotchas!
• Don’t forget about your custom kernel files!

 Often, unique files are maintained in the kernel directory that
will need to be retained and/or modified as part of the patch
process
 Saprouttab
 Third-party executables
 Backint
• Great opportunity to patch your saphostagents

 Apply the latest available patch independently to each system
or a tier at a time (Dev’s, QA’s … Prod) by using a central
patching location
72
What We’ll Cover
landscapes
Reporting
• Wrap-up
73
Causes of Poor SAP Application Performance
• Network performance from end-user PC to SAP servers and back

 Network capacity or “bandwidth” needs to be adequate
 SAP transaction ST03 (transactional performance) shows

average “end-to-end” performance
 Average SAP user response time of less than 1500ms is
considered acceptable
• Lack of physical memory in server

 SAP Transaction ST06 (OS monitor) provides information
 If there is not enough physical memory, the “swapping” field

is red
74
Causes of Poor SAP Application Performance (cont.)
• Not enough SAP Work Processes

 SAP transaction monitor showing excessive “wait times” for
user sessions indicates not enough work processes
• Underlying SAP database needs optimizing
 SAP transaction ST04 (database statistics) monitors database
performance
• 32-bit vs. 64-bit operating system and database
 Refers to the size of data packets server can process
 Newer versions of SAP, database, and operating systems can

now process in 64-bit packets
 A 64-bit upgrade may well be part of your next SAP upgrade
project
75
• Disk Input/Output (I/O) too slow

 Too few hard drives in storage system
 More disks enable more concurrent I/O = faster performance
 Poorly configured mapping of database to hard drives
 Bottlenecks occur when too many popular tables reside on

the same drive
 SAP Transaction ST06 (OS Monitor) helps show if disk I/O is
nicely spread out
 Without expertise SAN configuration tools can propagate
these issues
76
• SAP processes maintain data in server memory locations

called “buffers”
 Data retrieved from memory buffers is much faster than
from disk
 SAP transaction ST02 (memory buffers) monitors to
optimal use of these memory buffers
• Some SAP programs run slow
 Latest support packs often have code improvements
• Custom “Z” ABAP programs often poor performers

 SAP transaction ST03 (transactional performance) indicates
frequency programs are used and average processing time
77
BI Platform
• Central Management Console (CMC)

 Most day to day Administration will be done from CMC
 Web-based – http://server.domain:8080/BOE/CMC
 User/Group management
 Security
 APS configuration – A topic all on it’s own
 Licensing
• Central Configuration Manager

 Start/Stop SIA/Tomcat
 Add nodes to cluster
78
Authentication
• There are 4 different ways to authenticate

 Enterprise – Just a local account on an SAP BusinessObjects
system
 LDAP
 SAP – Authentication against an already existing SAP system
 Windows AD – Authentication based on Active Directory
79
Troubleshooting
• Monitoring section of CMC provides tons of useful information

 Can make custom “Watches” to track whatever you want
 Default watches will also provide some useful information
• Logs
 Located at <Install_Drive_Letter>:\Program Files (x86)\SAP
BusinessObjects\SAP BusinessObjects Enterprise XI
4.0\logging
 Check here when having issues
• Task Manager on OS
 Easy way to see which APS PIDs are using most CPU/memory
 Can tell which APS is getting hit when a process runs
80
What We’ll Cover
landscapes
Reporting
• Wrap-up
81
Emerging Trends in SAP Infrastructure
• More organizations are outsourcing to data center providers

• Overall, performance is increasing and prices are dropping
• Inherent high availability (redundancy) of components
• Virtual Private Networks (VPNs) replacing dedicated Wide Area
Networks (WANs)
• Server virtualization
 1 physical server acts like multiple servers
 Increased hardware utilization
 Decreased energy costs
 Increases flexibility in server management
 Allocation and Provisioning
 Clustering
 Improved Replication and backup features
82
Emerging Trends in SAP Infrastructure (cont.)
• Cloud computing
 Software as a Service (SAAS) – Applications on the Net that are
generally sold per user by month
 SAP Business by Design
 True “cloud-based” application
 Contains ERP, CRM, Analytics, and other functionality
 “Apps” on Demand (i.e., CRM on Demand)
 Same applications as Business Suite, but hosted and

provided at a per user per, month pricing model
 Infrastructure as a Service (IaaS) – Outsourced infrastructure in
terms of servers, storage, and networking
83
Hosted ECC
Firewall
Firewall
Cloud
SAP
CRM on Demand
Fax
84
• Cloud Computing
 What it is …
 Opportunity to leverage best TCO solutions for your

organization
 Business opportunities:
 Prototype new application with little or no up-front

investment
 Dynamically grow resources as needed – On-demand
 Licensing by the drink
 The cloud has bridged the gap to allow access to

applications anywhere
 Another tool in the IT belt to be used where appropriate
85
• Cloud Computing (cont.)

 What it is not …
 An end to current mainstream SAP architecture
 Complete replacement of your current landscape
 It is not a perfect fit for all situations or all customers
 A computing environment without issues
 Multi-tenancy concerns – performance, availability
 Security – access, compliance, data
 Less control over environment
 Time to enhancement modifications and patches
86
What We’ll Cover
landscapes
Reporting
• Wrap-up
87
Definitions
• High Availability (HA)

 Measures to ensure application availability
“in place”
 Reducing single points of failure in
technical architecture
 Utilizing redundant components – if one
goes down the other keeps working
 Having sound operations, competent
administrators
• Disaster Recovery (DR)
 Measures to ensure application availability
after a catastrophic event
 Think loss of your data center
88
High Availability (HA) for SAP
• Hardware venders provide proprietary “fail-over” solutions

 Microsoft – MS Cluster
 HPUX – Service Guard
 IBM AIX – HACMP
 IBM AS/400 – various; e.g., MIMIX
• These solutions connect your SAP PRD system with another

server
 “Heartbeat” monitor back and forth
 Scripts executed upon detection of a failure to move SAP to the

other server
 End users interrupted to last SAP transaction, simply log
back in
89
High Availability – Active-Passive
90
High Availability – Active-Active
91
High Availability
• SAP SPOF
 Enqueue, Message Server Services
• Database failover
 Failover based on host failure triggers
 Automated cutover procedure
• Host failover
 Virtual Machine cutover based on custom failure scenarios
• Storage Failover
 SAN replication as an example
• (Not factoring in total Datacenter relevant pieces – Power,

Cooling, etc.)
92
High Availability (cont.)
• SPOF (Single Points of Failure)

 Application, Database, Host failover
 Solutions are dependent on OS platform and Database
 IT needs to understand business requirements for SAP

availability
 This determines the layers and overall complexity of HA
systems
93
Disaster Recovery (DR)
• Resumption of SAP availability somewhere else

• IT budget line item that gets deleted every year 
• Primary business considerations
 Recovery Point Objective = RPO
 How much data is the business willing to lose?
 Recovery Time Objective = RTO
 How quickly do you need to be back in operation?
 Cost
 How much is the business willing to spend to minimize RPO

and RTO?
94
Disaster Recovery Options
• Classic off-site tape recovery

 Lowest cost solution
 RPO and RTO measured in days
• Classic off-site tape with active log shipping

 RPO reduced to minutes/hours via copying database logs over
the network
 RTO still measured in days
• “Hot” standby server

 Most expensive
 High network bandwidth required to replicate database
 RPO and RTO measured in minutes
95
Disaster Recovery
• The topic of DR is much bigger than copying SAP ECC to another

Datacenter
 Start with RPO and RTO objectives
 RPO (Recovery Point Objective)
 How much data can be lost? 5 minutes … 5 hours?
 RTO (Recovery Time Objective)
 How quickly do we need to be back up and running?
 Determine what functionality the Business deems necessary in

the event of a true DR
 Example, running payroll is a requirement
 Third-party solutions need to be included in the DR plan
96
Disaster Recovery – Technical Considerations
• Tiered DR Plan
 Providing DR for every productive system may be too
expensive
 Hot DR for critical SAP production components (Tier 1)
 Cold DR for ancillary applications that would need the

application reinstalled (Tier 2, 3)
• Bandwidth
 Can your communication channel support the change
replication rates to your DR environment?
 Hardware and software solutions available to help compress
network traffic
 Plan for capacity increases based on Business initiatives for
new applications or additional system load
97
What We’ll Cover
landscapes
Reporting
• Wrap-up
98
SAP Technical Staffing
• Help Desk/Data Center operations

 Receive and escalate end-user problems
• Network administration
 Masters of the wiring closet
• Desktop administration (PC support)
 Distribute and maintain SAP GUI to end-user PCs
• Server infrastructure administration
 UNIX or Windows administrators
 SAN and backup administration
• Database administration (DBA)
 Manage SAP and other databases in the enterprise
• SAP Security administration
 Often a part-time role
99
SAP Basis Administration
• Basis/SAP NetWeaver administrators manage the technical application of SAP
 Basis Administrators work with SAP project teams to:
 Translate business requirements into technical requirements
 Engineer change management system
 Design SAP server landscape (size and specifications)
 Provide project technical support
 Perform day-to-day monitoring and maintenance of SAP systems
 Monitor all SAP NetWeaver components and performance
 Look for errors in database and OS logs
 Oversee batch schedule
 Apply SAP Notes and Support Packs
 Oversee availability, capacity, and performance
 Level 2 and 3 problem escalation
100
Strategies for SAP Technical Staffing
Is IT truly a core competency of your enterprise?
• Consider outsourcing of entire SAP environment – “managed

hosting”
• Consider outsourcing or staff augmentation of SAP NetWeaver
admin
 Basis administration is a highly specialized role
 Out-tasking is an alternative to hiring, training, and retaining
 Access to a much larger support team – deeper expertise
• Rethink internal technical staffing

 Reorganize to have a dedicated SAP technical team
 Don’t try to scrimp or “get by” with inadequate staffing
 Consider the cost of a day of down time 101

What We’ll Cover
landscapes
Reporting
• Wrap-up
102
Where to Find More Information
• http://scn.sap.com/docs/DOC-25454#section55
 High Availability – Frequently Asked Questions on SCN
• www.saphana.com/community/blogs/blog/2013/04/30/what-is-the-
definition-of-a-cloud
 Floyd Strimling, “What Is the Definition of a Cloud?” (SAP
HANA Blog, April 2013).
• http://wiki.scn.sap.com/wiki/display/TechOps/Home
 SAP source for Solution Manager technical offerings (Wikis and
How-To documents)
• http://scn.sap.com/community/netweaver
 SAP NetWeaver Technology Platform on SCN
103
7 Key Points to Take Home
• Analyzing performance goals is a moving target. Factor in all

pertinent performance metrics across the OS, DB and application
during assessments.
• SAP Solution Manager 7.1 should be a key component of your
SAP Operational strategy
• When performing system analyses, review the entire technology
stack from the OS and underlying hardware to database and
finally SAP
• Consider the many permutations and configuration options for
your SAP architecture to cover availability, disaster recovery, and
load balancing
104
7 Key Points to Take Home (cont.)
• Always consider end-to-end business process effects when

taking on upgrades or support packs
 Only changing a portion of the systems involved in the process
will create major headaches
• When implementing a monitoring and alerting framework, look to
create alerts before they become critical events, and assign
notifications to the proper individuals
• Maintaining a healthy SAP environment requires a structured
maintenance approach through a weekly, monthly, and bi-annual
analysis and corrective activities
105
Your Turn!
How to contact me:

Matt Lonstine
mlonstine@sym-corp.com
Please remember to complete your session evaluation

106
Disclaimer
SAP, R/3, mySAP, mySAP.com, SAP NetWeaver®, Duet\®, PartnerEdge, and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and
service names mentioned are the trademarks of their respective companies. Wellesley Information Services is neither owned nor controlled by SAP.
107
Wellesley Information Services, 20 Carematrix Drive, Dedham, MA 02026
Copyright © 2014 Wellesley Information Services. All rights reserved.

Sap Basis

Încărcat de

Informații document

Titlu original

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

Sap Basis

Încărcat de

Drepturi de autor:

Formate disponibile

The Basics of Basis

• The most simple SAP architecture took the following forms:

• One-time, “big bang” implementations

• Three-system landscape (per major SAP application) most

• Typically referred to as Distributed environments, load balancing

• More and more SAP implementations involve multiple major SAP

 E.g., test a new tape backup device

• A 3-tier architecture with multiple application servers becomes

• In a large configuration, all potential individual instance options

• Numerous systems to deploy and operate

 Used for testing of PRD problems without impacting production

• The standard SAP instance terminology has changed as of SAP

• Support has ended in 2013 for the following items:

 End of most dual-stack configuration options

 Separate stacks are required with the exception of Solution

 Financial Accounting (FI)

 Sales and Distribution (SD)

 Materials Management (MM)

 Warehouse Management (WM)

 Quality Management (QM)

 Plant Maintenance (PM)

 Production Planning (PP)

 Data warehousing, modeling, and reporting

• SAP Customer Relationship Management (SAP CRM)

• SAP Supply Chain Management (SAP SCM)

• SAP Supplier Relationship Management (SAP SRM)

• HANA, SAP BusinessObjects

• SAP Product Lifecycle Management (SAP PLM)

• SAP Enterprise Portal (up to 6.0); SAP NetWeaver Portal

• SAP NetWeaver Exchange Infrastructure (SAP NetWeaver XI)

• SAP Solution Manager

• Computing technology is continuing to change rapidly

 Smaller physical sizes

 Amount of data storage exploding exponentially

 A standard SAP environment 3 years ago is now ½ the physical

• Best practices for SAP server technology “refresh”

 No other servers over 5 years old (e.g., “DEV” and “QAS”)

 Couple server replacements as part of SAP software upgrade

• Performance gains are a valuable hidden ROI

• The first questions when tackling performance bottlenecks are:

 Are there any bottlenecks that would limit capacity?

• SAP database sizes typically range in the 300GB to 1.5TB

 Storage systems offer different “caching” features to achieve

 Silver disk – Quality Assurance

 Bronze disk – Development, Sandbox

 Lots of intelligence – caching, replication

 More options for copying, backing up data

• SANs are not inherently wonderful

 Tend be sold with a few large disks = poor database

• The hardware is not the only variable in the equation

 HANA’s speed is touted as a major selling point but

 If you need to maintain a mixed RDBMS environment, you

 There are requirements between SAP NetWeaver 7.31-7.4

 Don’t want printers on same network as servers

 If one device goes down, end users still in business

 Dual networking paths

 If one network connection goes down, end users still in

 Prevent introduction of viruses, etc.

• SAP GUI is considered a “light” client

 SAP network traffic seldom a source of trouble

• Network “maintenance” can be a big source of irritation in SAP

• If both the SAP application and database processes

Source: Page 34, SAP R/3 System Administration, SAP PRESS