Copy Tadm53 o Adm520 en Col62 Nopw

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y

SAP AG 2006

ADM520 Database Administration MS SQL Server

© SAP AG 2006

Database Administration – Microsoft SQL Server

Diese Seite wird von Andrea für euch noch erstell!

SAPNetWeaver 2004s

2006/Q2

Material number 50080718

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y

SAP AG 2006

Copyright 2006 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in

any form or for any purpose without the express permission of

SAP AG. The information contained herein may be changed

without prior notice.

Copyright

Some software products marketed by SAP AG and its distributors contain proprietary software

components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390,

OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are

trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web

Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology

invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, 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. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y

SAP AG 2006

Required Knowledge:

SAPTEC - Fundamentals of SAP Web AS

Working knowledge of the Microsoft SQL Server 2005

database and the Microsoft Windows 2000 or Windows

2003 operating system

Working knowledge of the SAP NetWeaver system

Recommended Knowledge:

For the administration of SAP NetWeaver systems, the

courses SAP Web AS Implementation & Operation I and II

are necessary

Course Prerequisites

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y

SAP AG 2006

This course is intended for the following audiences:

Database administrators

SAP system administrators

Technical consultants

Project team members

Duration: 3 day(s)

Target Audience

User notes

These training materials are not a self-study program. They complement the explanations provided by

your course instructor. Space is provided on each page for you to note down additional information.

There may not be sufficient time during the course to complete all the exercises. The exercises provide

additional examples that are covered during the course. You can also work through these examples in

your own time to increase your understanding of the topics.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y

© SAP AG ADM520 1-1

SAP AG 2006

Course Overview

Contents:

” Course Goals

” Course Objectives

” Course Content

” Course Overview Diagram

” Main Business Example

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Course Goals

This course will prepare you to:

” Explain the architecture and main features of Microsoft SQL

Server 2005

” Improve the knowledge of database administrators concerning

the usage of the CCMS database tools and the SQL Server tools

” Develop suitable backup and restore strategies

” Detect and solve performance problems

” Detect and solve Microsoft SQL Server specific error situations

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Course Objectives

After completing this course, you will be able to:

” Describe the main feature of Microsoft SQL Server Architecture

” Describe the implementation of SAP NetWeaver under Microsoft

SQL Server 2005

” Monitor and identify performance problems of Microsoft SQL

Server and find solutions for the problems detected

” Explain and perform different backup types and define a suitable

backup strategy

” Perform and verify a database restore

” Handle common errors and perform regular tasks

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Unit 5 Database Backup

Unit 6 Database Restore

Unit 7 Regular Maintenance

and Error Handling

Unit 8 Conclusion

Unit 1 Course Overview

Unit 2 SQL Server Architecture

Unit 3 How SAP NetWeaver

Uses SQL Server

Unit 4 Performance Monitoring

and Tuning

Preface

Appendixes

Course Content

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Course Overview Diagram



Unit 3 How SAP NetWeaver Uses SQL Server

Unit 4 Performance Monitoring and Tuning



Unit 7 Regular Maintenance and Error Handling

Unit 8 Conclusion

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SQL Server Architecture: Contents

Contents:

Database Server and Database Instances

Authentication

Databases, Schemas, Files, Filegroups, and Partitions

Database Objects

Memory Management

Logging

Locking

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SQL Server Architecture: Unit Objectives

After completing this unit, you will be able to:

” Describe the main features of SQL Server 2005

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SQL Server Architecture: Course Overview Diagram








Unit 8 Conclusion

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SQL Server Architecture: Business Example

” Your company implemented an SAP system based

on SAP NetWeaver 2004s and Microsoft SQL Server

2005 (for example, mySAP ERP 2005 or SAP

Enterprise Portal). Your IT specialists want to

understand the main features of SQL Server.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Server

SQL Server

Windows server

Database server, a process

running the database system

Database 1 Database 2

The term database server is often used to describe the physical computer on which the database runs.

For the purpose of this explanation of the Microsoft SQL Server architecture, database server refers to

the operating system process on Microsoft Windows that represents the active, programmed side of the

database system. All management of the database system is performed through and by the database

server, and all communication with the database systems goes through the database server.

When the database server is running, the database system is up and you can connect to the databases.

When the database server is not running, the databases are down.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Server and Database Instances

Windows Server

SQL Server default instance

sapprod

SQL Server named instance

PR1

SQL Server (MSSQLSERVR)

SQL Server Agent (MSSQLSERVER)

SQL Server (PR1)

SQL Server Agent (PR1)

msdbmaster tempdb model

msdbmaster tempdb model

Microsoft SQL Server supports multiple instances of the Microsoft SQL Server database engine running

concurrently on the same computer. Each instance of the Microsoft SQL Server database engine has its

own set of system and user databases that are not shared between instances.

Microsoft SQL Server has default and named instances:

• The default instance is identified by the name of the computer on which the instance is running.

When a client program such as the SQL Server Management Studio specifies only the computer

name in its request to connect to Microsoft SQL Server, a connection to the default instance of the

database engine on that computer is established. There can be only one default instance on any

computer; the default instance can be of any version of Microsoft SQL Server.

• All instances of the database engine other than the default instance are identified by a name specified

during installation of the instance, and are thus known as named instances. Clients must provide

both the computer name and the instance name of any named instance to which they are attempting

to connect. The computer name and instance name are specified in the format

computer_name\instance_name.

Multiple named instances can run on a computer. Only database engines of Microsoft SQL Server 2000

and later versions can operate as a named instance.

Named instances do not share any executables; they allow different service pack levels and require

separate maintenance.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Services

Under Microsoft Windows, a program can be started as a service. A service runs in the background and

has no graphical user interface. To automatically or manually start and stop services at system startup,

use the Control Panel services.

Microsoft SQL Server has the following services:

• SQL Server (MSSQLSERVER): Database server or database engine

• SQL Server Agent (MSSQLSERVER): Automatic task execution (jobs) and SQL Server alert

handling

• SQL Server FullText Search (MSSQLSERVER): Allows the indexing of text data in SQL Server

databases

• SQL Server Browser: Identifies all instances of SQL Server on the computer, and notes the ports and

named pipes that they use.

To start and stop these services, use the SQL Server Management Studio or the SQL Server

Configuration Manager. The service SQL Server (MSSQLSERVER) can also be started remotely from

another computer. Starting SQL Server is the same as starting the service SQL Service

(MSSQLSERVER).

SQL Server can be started and stopped manually typing the following in the command prompt:

• net start "SQL Server (MSSQLSERVER)" or net mssqlserver to start the default instance

• net start "SQL Server (instancename)" or net start MSSQL$instancename to start the named

instance

• sqslservr to start the default instance

• sqlservr -s <instancename> to start the named instance

The SQL Server Agent (MSSQLSERVER) service must be started automatically together with SQL

Service (MSSQLSERVER) so scheduled jobs are executed.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Startup Options

When Microsoft SQL Server is installed, the setup procedure writes a set of default startup options in

the Windows registry. These startup options are used to specify an alternate master database file, master

database log file, or error log file, for example.

The default startup options can be overridden temporarily or permanently to start an instance of SQL

Server by using additional startup options. These options are explained in detail in SQL Server Books

Online.

Using startup option –g specifies an integer number of MB of memory that SQL Server will leave

available for memory allocations within the SQL Server process, but outside the SQL Server memory

pool. The default is 256 megabytes (MB). Details are explained in later slides.

To use startup options every time when SQL Server instance is started, use the SQL Server Management

Studio or SQL Server Configuration Manager. These tools save the startup options as registry keys so

SQL Server always starts with the startup options.

The startup options, which are stored in the Windows registry, are also reported in the SQL Server error

log under Registry startup parameters.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

” DBCC commands

” Start-up option using

-T option in the SQL Server Configuration Manager

-T option from the command line

Trace Flags

Trace Flags can be activated in the following ways:

SQL Server can be started with a specified trace flag in effect. Trace flags are used to start servers with

nonstandard behavior. This provides a better understanding of SQL Server or even a change in the way

SQL Server will react to specific conditions.

You can activate a trace flag in the following ways:

• Using the commands DBCC TRACEON, DBCC TRACEOFF. Command DBCC TRACESTATUS(-

1) shows the trace flags currently set.

• Using the command DBCC TRACEON (T, -1): The -1 addition sets trace flag for all client

connections, rather than for a single client connection.

• Setting SQL Server start-up option using the SQL Server Configuration Manager

• Using the option –T<traceflag> when starting from command line

For example, if trace flag 1204 is set, the resources and types of locks participating in a deadlock and

also the current command affected are returned.

See SQL Server Books Online for details.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SQL Server Configuration Options

1 2

name minimum maximum config_value run_value

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

min server memory (MB) 0 2147483647 0 0

max server memory (MB) 16 2147483647 2147483647 2147483647

1 2

Microsoft SQL Server configuration options are set using stored procedure sp_configure or using the

server properties in the SQL Server Management Studio. See SQL Server Books Online for more

details.

The configured values (1) are pulled from the sys.configurations table in the master database and

represent the server's current configuration. The running values (2) show with which values Microsoft

SQL Server runs at the time the server properties are called or sp_configure is executed.

Some configuration options are advanced options. You can only see and modify them using

sp_configure, if the configuration option show advanced options is set.

Use command reconfigure with override to update the currently configured value of a configuration

option. Because some configuration options require a server stop and restart to update the currently

running value, reconfigure does not always update the currently running value. The option with override

disables the configuration value checking.

For dynamic configuration parameters, changes take effect immediately. For static configuration

parameters, changes take effect after you shut down and restart Microsoft SQL Server.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Client Server Architecture

Workstation A

OLE DB

Named Pipes Net-Library

SQL Server

Low-level network protocol,

e.g. TCP/IP, Named Pipes, VIA,

Shared Memory

Client X

Workstation B

ODBC

TCP/IP Net-Library

Named Pipes Net-Library TCP/IP Net-Library

TDS (Tabular Data Streams)

Client Y

Windows server

Net-Library

API

Microsoft

communication

format

Client applications can connect to Microsoft SQL Server using the TCP/IP, Named Pipes, VIA, or

shared memory network protocols, which must be enabled on both the client and server to work.

Microsoft SQL Server can service requests on all enabled protocols at once. Clients connect to

Microsoft SQL Server with a single protocol. If the client program does not know which protocol SQL

Server is listening on, the client can be configured to sequentially attempt multiple protocols in the order

listed in SQL Server Configuration Manager.

Because of the variety of networks, SQL Server developers implemented a network abstraction level

known as Net-Library.

On the server side of the communication, the Net-Libraries are part of the Database Engine.

On the client side, the Net-Libraries are part of the SQL Native Client (SNAC), which is shipped with

Microsoft SQL Server 2005, or Microsoft Data Access Components (MDAC), which is part of the

Windows operating system.

Several application programming interfaces (APIs) are available, for example, OLE DB. Other client

applications can use the ODBC interface.

When the SQL Server Database Engine communicates with an application, it formats the

communication in a Microsoft communication format known as a tabular data stream (TDS) packet.

The Net-Libraries on both the server and the client computers encapsulate the TDS packet inside a

standard communication protocol, such as TCP/IP or Named Pipes.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Connections, Sessions and Requests

sys.dm_exec_connections: one row per connection established to a SQL Server Instance

sys.dm_exec_sessions: one row per authenticated session associated with an active connection

sys.dm_exec_requests: one row per request executed within a session

After the SQL Native Client is installed on a client computer, the client is immediately ready to connect

to an instance of Microsoft SQL Server. The information the client application must supply is the

computer name and instance name. Dynamic Management View sys.dm_exec_connections returns

information about the connections established to an instance of Microsoft SQL Server on various

databases by different users, and the details of each connection.

Dynamic Management View sys.dm_exec_sessions returns one row per authenticated session on

Microsoft SQL Server. Each row is identified by a session ID, which is associated with an active

connection. This session ID is also known as SQL Server process ID (SPID).

Dynamic Management View sys.dm_exec_requests returns information about each request that is

executing within Microsoft SQL Server. Each request within a session has an ID that is unique in the

context of the session.

For more information on sessions, requests and connections, see the “How SAP NetWeaver Uses SQL

Server” unit.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Processes and Threads

Process...

Windows server

Thread 1 Thread NThread 2 Fiber 1 2 .. n

A process is a program that is currently being executed. Under Microsoft Windows, each process has its

own address space to keep processes separate from each other and prevent interference. The process is

also the owner of all the program resources, such as file handles and access tokens.

The thread is the basic unit of activity in Windows. Each process has at least one thread, and may have

multiple threads. Windows assigns time slices on physical processors to threads. All threads can run

concurrently. Since no address space switch is involved, switching between threads within the same

process is much faster than a conventional process switch in operating systems that run without the

thread concept.

SQL Server has an internal layer that implements an environment similar to an operating system for

scheduling and synchronizing concurrent tasks without having to call the Windows kernel. This internal

layer can schedule fibers as effectively as it works with threads. A fiber is a unit of execution. Fibers

run in the context of the threads that schedule them. Each thread can schedule multiple fibers.

Lightweight pooling, one of the SQL Server configuration options, controls whether SQL Server uses

threads or fibers. The default is 0, in which case SQL Server schedules a thread per concurrent user

command. If lightweight pooling is set to 1, then SQL Server uses fibers instead of threads.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Processes and Threads (2)

Workstation A

OLE DB

Named Pipes Net-Library

TCP/IP

Client

process X

Workstation B

OLE DB

TCP/IP Net-Library

Client

process Y

Named Pipes Net-Library TCP/IP Net-Library


SQLSERVR

process...Thread 1 Thread 2 Thread 3 Thread N

Windows server

Named Pipes

Every connection between a client and SQL Server uses one thread in the sqlservr.exe process. SQL

Server uses thread pooling to optimize performance when large numbers of clients are connected to the

SQL Server. The maximum size of this pool is controlled by max worker threads, an SQL Server

configuration option.

The default value for max worker threads, 0, allows SQL Server to automatically configure the number

of worker threads at start-up. The automatically configured number of max worker threads depends on

the number of CPUs, the architecture of the database server, and the version of SQL Server.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

” Lazy Writer

” Lock Manager

” Log Writer

” Checkpoint

” Background Task

Special Threads

The Lazy Writer thread scans the data cache to write dirty pages to disk. The Lazy Writer thread sleeps

for about a second. When it is restarted, it checks the size of the free buffer list in the buffer pool. If the

free buffer list is below a certain point, the Lazy Writer thread scans the buffer cache to write dirty

pages to disk. The Lazy Writer also checks if there is enough free physical memory on the system. If the

free memory drops below 4 MB and Windows starts paging, the Lazy Writer reduces the memory

occupied by SQL Server, provided that SQL Server can adjust its memory dynamically.

The Lock Manager dynamically adjusts the resources it uses for larger databases, eliminating the need

to adjust the locks server configuration option manually. Details on the locking mechanism are

explained in later slides.

The Log Writer records are written asynchronously to disk in a write-ahead way, except when:

• A commit forces all pending records for a transaction to disk

• A checkpoint forces all pending records for all transactions to disk

The Checkpoint thread scans the buffer cache for dirty pages and writes to disk any buffer page that are

marked as dirty. Checkpoints typically find few dirty pages to write to disk because most dirty pages get

written to disk by the worker threads or Lazy Writer thread in the period between two checkpoints.

The Background task checks every 30 minutes if the database or the transaction log files can be shrunk,

in case the database option autoshrink is set. It also starts every 5 seconds and checks 20 data pages to

see if they contain ghost records. Ghost records are deleted logically but not physically.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Authentication

Security Modes

Microsoft SQL Server must verify that the login ID supplied on each connection is authorized to access

the database server. This process is known as authentication.

Microsoft SQL Server supports the following mechanisms for authentication:

• SQL Server security: A connection to Microsoft SQL Server is established through a Microsoft

SQL Server login and password, for example, using login ID sa.

• Trusted security: A connection to Microsoft SQL Server is established using the Windows user

account. When a user connects to Microsoft SQL Server through a Windows user account, SQL

Server verifies that the account name and password were validated when the user logged on to the

operating system. The SQL Server client then requests a trusted connection to SQL Server. The

properties of a trusted connection include the Windows group and user accounts of the client that

opened the connection.

A member of the SQL Server sysadmin fixed server role, for example, login ID sa, must first specify

to Microsoft SQL Server all the Windows accounts or groups that can connect to SQL Server. By

default, all members of the Windows BUILTIN\Administrators group, the local administrator's

group, are members of the sysadmin fixed server role.

Microsoft SQL Server can operate in one of the following authentication modes:

„ Windows authentication mode allows users to connect using trusted security

„ SQL Server and Windows authentication mode allows users to connect using either trusted security

or SQL Server security.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Databases and Files

Databases

Files

msdbmaster tempdb

.ldf.mdf

.ldf.mdf

.ldf.mdf

model

.ldf.mdf

The system databases are as follows:

• master holds all the system level information for a SQL Server system. It stores all login accounts

and all system configuration parameters.

• msdb is used by SQL Server Agent for scheduling alerts and jobs.

• tempdb holds all temporary tables for all users connected to SQL Server. It also fulfills any other

temporary storage needs. Every time SQL Server is started, tempdb is re-initialized. The

initialization is recorded as “clearing tempdb” in the error log.

• model is used as the template for all databases created on SQL Server.

SQL Server maps a database over at least two operating system files. Data and log information are never

contained in the same file, and individual files are used by only one database.

The primary or master file (.mdf) contains the start-up information and system tables for the database

and is used to store data. Every database has one primary file. Further data files are referred to as

secondary or next files (.ndf). Secondary data files are optional. Transaction log files (.ldf) contain the

log information used to recover the database. Each database must have at least one log file.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Resource Database

Resource

Resource Database

Files

Mssqlsystemresource.ldf

Mssqlsystemresource.mdf

The Resource database is a hidden read-only database that contains all the system objects that are

included with SQL Server 2005.

The Resource database allows you to quickly perform a version upgrade and to easily uninstall service

packs. In earlier versions of Microsoft SQL Server, upgrading required dropping and creating system

objects. Because the Resource database file contains all system objects, an upgrade is now accomplished

simply by copying the single Resource database file to the local server. Similarly, rolling back system

object changes in a service pack only requires overwriting the current version of the Resource database

with the older version.

The physical file name of the Resource database is Mssqlsystemresource.mdf. By default, this file is

located in the data directory of the SQL Server installation.

Each instance of SQL Server has one associated Mssqlsystemresource.mdf file, and instances do not

share this file.

The Resource database should be accessed only in an error situation. When SQL Server is in single-user

mode, using statement USE mssqlsystemresource will switch to the Resource database.

The ID of the Resource database is always 32767.

For details, see SQL Server Books Online.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Schemas

test

User Databases

schemas

test1.table1

test1.table2

test1.table3

test1.table4

…

test1

test2.table1

test2.table2

test2.table3

test2.table4

…

test2

dbo.table1

dbo.table2

dbo.table3

dbo.table4

…

dbo

sys.objects

sys.indexes

sys.filegroups

sys.schemas

…

sys

e.g.

select * from test.test1.table1

database name schema name table name

A schema is a collection of database entities that form a single namespace. A namespace is a set in

which every element has a unique name.

For example, to avoid name collisions, no two tables in the same schema can have the same name. Two

tables can have the same name only if they are in separate schemas.

Microsoft SQL Server 2005 introduces default schemas, which are used to resolve the names of objects

that are referred to without their fully qualified names. In Microsoft SQL Server 2005, each user has a

default schema, which specifies the first schema that will be searched by the server when it resolves the

names of objects. The default schema can be set and changed. If it is left undefined, the database user

will have dbo (database owner) as its default schema.

sys.schemas contains one row for each schema in a database.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Files and Filegroups

System tables and

other user tablesPRIMARY

Objects Filegroups

Filegroups are named collections of files. They offer an additional administrative layer for data

placement and tasks such as backup and restore operations. Data files are assigned to exactly one

filegroup. A single table uses space in all files within the one filegroup.

The PRIMARY filegroup is created when SQL Server is installed.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Automatic Growth

Volume E:Database files

Data1.Mdf

(Autogrow ONLY for out-of-space failure)

Data2.Ndf

Data4.NdfVolume F:

: Free space

Database files grow automatically only if the option autogrow is set and no further space is available on

any of the database files in the filegroup.

Filegroups use a proportional fill strategy across all the files within each filegroup. As data is written to

the filegroup, SQL Server writes an amount proportional to the free space in the file to each file within

the filegroup, rather than writing all the data to the first file until full and then writing to the next file.

For example, if File1 has 100 MB free and File2 has 200 MB free, one extent is allocated from File1,

two extents from File2, and so on. This way both files become full at about the same time and simple

striping is achieved.

Transaction log files, however, cannot be part of a filegroup; they are separate from one another. The

transaction log grows using a fill-and-go strategy rather than a proportional fill strategy. Therefore,

when a log file is added, it may not be used by the transaction log until the other files have been filled

first.

More details on autogrow are outlined in the “Regular Maintenance and Error Handling” unit.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Partitioning

Year / Month Customer Sales

2003/01 4711 10

2003/01 4712 15

2003/01 4713 20

2003/01 4714 23

2003/02 4711 44

2003/02 4713 32

2003/02 4714 17

Table

Partition

Table

Partition

Horizontal or Range Partitioning

Database

Table

(logical)

Table

Partition

Table

Partition

Partitioning a database table improves performance and simplifies maintenance. By splitting a large

table into smaller, individual tables, queries accessing only a fraction of the data can run faster because

there is less data to scan.

Microsoft SQL Server supports horizontal partitioning or range partitioning. It divides a table into

multiple tables. Each table then contains the same number of columns, but fewer rows. For example, a

table could be partitioned horizontally into x tables, with each smaller table representing one month of

data for a specific year. Any queries requiring a specific month's data only reference the appropriate

table.

It is faster to drop a table partition than to delete that part of a table.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Objects

§Name xyz abc

Name xyz abc

Logical Database Objects

System

Representation

Physical

representation

Tables Views Constraints Stored Indexes

Procedures

System Tables

Pages Pages Pages

A Microsoft SQL Server database consists of tables that contain data and other objects such as views,

indexes, and stored procedures defined to support the activities performed on the data.

These database objects are stored on pages in physical memory, along with other data objects defined in

the system tables.

Pages can be of different page types used in the data files of a SQL Server database:

• Data pages: Data rows with all data, except text and image pages

• Index pages: Contain index entries

• Text/Image pages: Contain large object data types, such as text, ntext, and variable length columns

when the data row exceeds 8 KB such as varchar, nvarchar.

• Special pages

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Space Allocation

11

22

33

Page File

Row 1

Row 2

Row 3

Tables X

8 Pages = 1 Extent

Page 8

Row 1

Row 2

Page 17

Row 3

0 1 2 3 4 5 6 7

8 9 10 11 12 13 14 15

16 17 18 19 20 21 22 23

Extents

The page is the unit of data storage in SQL Server. Pages are 8 KB in size. SQL Server allocates pages

to objects and reuses space freed up by deleted rows. These operations are internal to the system and use

data structures not visible to users.

Extents are the basic unit in which space is allocated to tables and indexes. An extent consists of eight

contiguous pages, or 64 KB. A new table or index allocates first pages from mixed extents. That means

extents can contain pages from different objects. Extents are called uniform when a table or index

allocates all eight pages.

Log files do not contain pages, they contain a series of log records, allocated on virtual log files. Details

on the structure of log files are explained in the “Database Backup” unit.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Special Pages

First extent on each file

8 contiguous pages = 1 extent (64 KB)

File header Contains information about the attributes of the file

PFS Page allocation / free space availability (in %)Page Free Space

(S)GAM Usage of extents (free, mixed, full)(Secondary) Global Allocation Map

BCM Changes of extents when in Bulked_logged recovery mode

Bulk Changed Map

DCM Changes of extents since last database backup

Differential Changed Map

Boot page Contains information about the attributes of the databaseexists only in the primary data file

File Boot

header PFS GAM SGAM BCM DCM page ...

0 1 2 3 6 7 8

File Header is a special page that contains information about the file.

Page Free Space (PFS) pages record whether an individual page has been allocated, and the amount of

space free on each page. Each PFS page covers 8000 pages. For each page, the PFS has a bitmap

recording whether the page is empty, 1-50% full, 51-80% full, 81-95% full, or 96-100% full. Once an

extent has been allocated to an object, Microsoft SQL Server uses the PFS pages to record which pages

in the extent are allocated or free, and how much free space is available for use.

Global Allocation Map (GAM) pages record which extents have been allocated. Each GAM covers

64000 extents, or nearly 4 GB of data. The GAM has one bit for each extent. If the bit is 1, the extent is

free; if the bit is 0, the extent is allocated.

Shared Global Allocation Map (SGAM) pages record which extents are currently used as mixed extents

and have at least one unused page. Each SGAM covers 64000 extents, or nearly 4 GB of data. The

SGAM has one bit for each extent it covers. If the bit is 1, the extent is being used as a mixed extent and

has free pages; if the bit is 0, the extent is not being used as a mixed extent, or it is a mixed extent whose

pages are all in use.

Index Allocation Map (IAM) pages map the extents in a database file used by a heap or index. Each

heap or index has one or more IAM pages recording all the extents allocated to the object. A heap or

index has at least one IAM for each file on which it has extents. A heap or index may have more than

one IAM for a file if the range of the extents for the heap or index on that file exceeds the range that an

IAM can record.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


Bulk Changed Map (BCM) pages record the extents which have been changed by bulk operations such

as CREATE INDEX since the last transaction log backup. If the bit is 1, the extent has been changed by

a bulk operation, if the bit is 0, the extent has not been changed. BCM pages are only relevant when the

recovery model of the database is set to bulk_logged.

…

…

Differential Changed Map (DCM) pages record which extent has changed since the last execution of

BACKUP DATABASE. Each DCM covers 64000 extents, or nearly 4 GB of data. If the bit for one

extent is 1, the extent has been changed since the last BACKUP DATABASE, if the bit is 0, the extent

has not been changed. See also the “Database Backup” unit.

The Boot page is the ninth page in the database file, that is, the first page of the second extent. It is

stored in the primary database file and in the first transaction log file. The boot page contains attributes

of the database. It records attributes which are needed for an automatic recovery. See also the “Database

Restore” unit.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Non-Clustered Index (on a Heap)

Level 1

Intermediate nodes

Level 0

Leaf nodes

Heidelberg,

Germany

L.A.,

USA

Atlanta,

USA

London,

United King.

Manchester,

United King.

Paris,

France

Berlin,

Germany

Washington,

USA

Walldorf,

Germany

New York,

USA

Page pointer

Rid (row identifier):

- File ID,

- Page number,

- Row number

Data

Pagesindid = 0

New York

Paris

Walldorf

Washington

nonclustered

key valuesrid

Atlanta

Berlin

Heidelberg

L.A.

London

Manchester rid

Atlanta

New York

Level n

RootIndex

Pagesindid >= 2

A table without clustered index is called a heap. This is because the data rows are stored without

ordering in a bunch of pages. The heap is shown in yellow.

This graphic displays data and index pages of a table. The search fields are “City” and “Country” and

contain a non-clustered index in the City field.

Indexes are used to speed up searching for records in tables. Indexes can be created for a frequently used

search field or a combination of search fields.

An index is a B tree, which is searched from the highest level (root page) to the lowest level (leaf

pages). The index is shown in blue.

Microsoft SQL Server has the following index types:

• Non-clustered index

• Clustered index

You can create as many non-clustered indexes for a table as needed.

Retrieval of a row, which is uniquely identified by the index key, through a non-clustered index requires

the following page accesses:

• One page for each index level

• One access on the data page

The location of a data row is stored on the leaf level of the non-clustered index and consists of a row

identifier (RID) comprised of the file number, page number, and slot number of the row.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Clustered Index

Data

Pages

Level 1(indid=1)

Level 0(indid=0) France,

Paris,

EuropeGermany,

Berlin,

EuropeGermany

Heidelberg,

Europe

Germany,

Walldorf,

EuropeUnited King.,

London,

EuropeUnited King.,

Manchester,

Europe

USA,

Atlanta,

North AmericaUSA,

L.A.,

North AmericaUSA,

New York,

North America

Page pointer

USA,

Washington,

North America

clustered

key

France,

Paris

Germany,

Walldorf.

USA,

Atlanta

USA,

Washingtonkey

Index

Pages

A clustered index dictates the physical storage order of the data in the table. That means a table or view

can contain only one clustered index. All inserts are done at the location where they fit in the ordering

sequence of the clustered index key.

A clustered index is organized as a B tree. Each page in a clustered index holds a page header followed

by index rows. Each clustered index row contains a key value and a pointer to either a page or a data

row. Each page in a clustered index is known as an index node. The top node of the B tree is the root

node. The bottom nodes in the clustered index are known as the leaf nodes. In a clustered index, the

data pages make up the leaf nodes. Index levels between the root and the leaves are known as

intermediate levels.

For a clustered index, root points to the top of the clustered index. SQL Server navigates down the

clustered index to find the row corresponding to a clustered index key. To find a range of keys, SQL

Server navigates through the clustered index to find the starting key value in the range, and then scans

through the data pages. To find the first page in the chain of data pages, SQL Server follows the leftmost

pointers from the leaf node of the clustered index.

An indexed view is a view with a unique clustered index. Creating a unique clustered index on a view

physically materializes the view. A unique clustered index must be created on a view before any other

indexes can be defined on the same view.

For more information, see SQL Server Books Online.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Non-Clustered Index with a Clustered Index

Index Pages

New York

Paris

Walldorf

Washington

USA,

New YorkFrance,

ParisGermany,

WalldorfUSA,

Washington

clustered key

values

Data

Pages

Level 1 (indid 1)

Level 0 (indid 0)

leaf nodes

Clustered Index

root

Atlanta

Berlin

Heidelberg

L.A.

London

Manchester

USA,

AtlantaGermany,

BerlinGermany,

HeidelbergUSA,

L.A.United King.,

LondonUnited King.,

Manchester

search via clustered index key (country, city)

Atlanta

New York

...

clustered key

values

Index

Pages

Index

Pages

Non-clustered Index

If a table has a clustered index, the leaf nodes of all non-clustered indexes use the concatenated key

columns of the clustered index (= clustering key) as the row locator rather than the physical row

identifier (RID). If a table does not have a clustered index, non-clustered indexes continue to use the

RID to point to the data pages.

In both cases, the row locator is stable. When a leaf node of a clustered index is split (data page), the

non-clustered indexes do not need to be updated because the row locators are still valid. If a table does

not have a clustered index, page splits on the data pages do not occur, they occur only on the index

pages.

Create the clustered index before creating any non-clustered indexes. Existing non-clustered indexes on

tables are rebuilt when a clustered index is created.

For indexed views, non-clustered indexes can be created only on a view that has a unique clustered

index already defined.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Index PagesIndex

Pages

Non-clustered Index

01345, B

93456, NY

...

01345, B

01590, B

67227, BW

78900, CA

79111, LD

79999, MN

93456, NY

95678, PR

98756, WA

98786, WA

01345, B, Berlin

01346, B, Berlin

01446, B, Berlin

01447, B, Berlin

01546, B, Berlin

01547, B, Berlin

01590, B, Berlin

01591, B, Berlin

01595, B, Berlin

01596, B, Berlin

01596, B, Berlin

01601, B, Berlin

93456, NY, New York

93457, NY, New York

93458, NY, New York

94470, NY, Newark

94475, NY, Newark

95017, NY, Newark

98756, WA, Seattle

98758, WA, Redmond

98761, WA, Olympia

98766, WA, Tacoma

98766, WA, Tacoma

98770, WA, Belleview

…

CREATE NONCLUSTERED INDEX

IX_Adress

ON dbo.Adress (Zip Code, Province)

INCLUDE (city);

Included Columns for Covered Indexes

In Microsoft SQL Server 2005, the functionality of non-clustered indexes can be extended by adding

included columns, known as non-key columns, to the leaf level of the index. Whereas the key columns

are stored at all levels of the non-clustered index, non-key columns are stored only at the leaf level. This

is because the non-key columns have the following benefits:

• They can be data types not allowed as index key columns.

• They are not considered by the database engine when calculating the number of index key columns

or index key size. In this way, exceeding the current index size limitations and the maximum index

key size can be avoided.

An index with included non-key columns can significantly improve query performance when all

columns in the query are included in the index either as key or non-key columns. Performance gains are

achieved because the query optimizer can locate all the column values within the index; table or

clustered index data is not accessed resulting in fewer disk I/O operations.

When an index contains all the columns referenced by the query, it is referred to as covering the query.

Such an index is known as a covering index.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Memory Management

data cache log cache

SQL Server Buffer Pool

procedure cache

Memory-to-Leave

Net Libraries

OLE DB Provider

lock memory

Extended stored procedures

Worker thread stack

All memory request > 8 KB

CLR memory

Microsoft SQL Server organizes its memory into these distinct regions:

• Buffer pool

• Memory-to-leave region

When Microsoft SQL Server starts, it computes the upper size of the buffer pool, which is the size to

which SQL Server will allow the buffer pool to grow. This size is based on several parameters such as

amount of physical memory on the system, number of server threads and various startup parameters.

The buffer pool is organized in 8-KB pages and it is used for:

• lock memory

• procedure cache

• connection memory (if network package size <= 8 KB)

• all other memory requests <= 8 KB

• data cache (all remaining pages of buffer pool)

By default the memory-to-leave region is reserved for

• worker thread stack memory

• CLR memory

• extended stored procedures (for example, third-party management tools)

• all memory requests > 8 KB

…

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


…

The size of the memory-to-leave region is determined by the formula: max worker threads * 0.5MB + "-

g <Memory>“, where the amount of configuration option max worker threads depends on the

architecture and the amount of CPUs on the database server. A 64-bit machine with 8 CPUs would

result in 576 max worker threads, which sets the memory-to-leave region to 0,5 MB * 576 + 256MB =

544 MB, assuming that startup option –g is not set and the default value of 256MB is taken.

The min server memory and max server memory configuration options establish upper and lower limits

to the amount of memory used by the buffer pool of Microsoft SQL Server. The buffer pool does not

immediately acquire the amount of memory specified in min server memory. The buffer pool starts with

only the memory required to initialize. As the database engine workload increases, it keeps acquiring the

memory required to support the workload. The buffer pool does not free any of the acquired memory

until it reaches the amount specified in min server memory. Once min server memory is reached, the

buffer pool then acquires and frees memory as needed. It never drops its memory allocation below the

level specified in min server memory, and never acquires more memory than the level specified in max

server memory.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Logging

BEGIN TRAN

UPDATE

INSERT

DELETE


log1.ldfdata1.mdf data2.ndf data3.ndf

A database transaction is a series of SQL commands that are completed or not executed at all. A

transaction is started with the command BEGIN TRAN. All commands within one transaction are

handled as one atomic unit by SQL Server.

Each SQL Server database has a transaction log that records data modifications made in the database.

The log records the start and end of every transaction and associates each modification with a

transaction. SQL Server stores the information in the log to either redo (roll forward) or undo (roll back)

the data modifications that make up a transaction. Each record in the log is identified by a unique log

sequence number (LSN).

When a transaction begins all modifiable operations such as INSERT, DELETE and UPDATE are first

stored in the data and log cache of SQL Server’s buffer pool.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Commit

BEGIN TRAN

UPDATE

INSERT

DELETE

COMMIT


LOG WRITER


To end a transaction, use the command COMMIT TRAN or ROLLBACK TRAN. SQL Server then

writes all logging information from this transaction to the log file and sends a message to the application

program confirming the COMMIT TRAN. This ensures that all confirmed changes from SQL Server are

logged onto a physical disk. Records to be changed are first stored in a cache. Sometimes the records to

be changed are only up to date in the cache.

All log records are written to disk before the corresponding data modification (a write ahead log).

A write-ahead log ensures that no data modifications are written to disk before the associated log

record.

A COMMIT operation forces all log records for a transaction to the log file so that the transaction is

fully recoverable even if the server is shut down. A COMMIT operation does not have to force all the

modified data pages to disk as long as all the log records are flushed to disk. A system recovery can roll

the transaction forward or backward using only the log records.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Checkpoints

CHECKPOINT

or Lazy Writerdata cache log cache


During a checkpoint, all dirty data pages and log records in the cache are written to the files. First log

records, then data pages are written.

A checkpoint can be manual or automatic:

• Manual checkpoint (transact-SQL command Checkpoint)

• Automatic checkpoint done by the Lazy Writer

Recovery interval, an SQL Server configuration option, controls how frequently SQL Server issues a

checkpoint in each database. Checkpoints are done on a per database basis. The recovery interval sets

the maximum number of minutes per database that SQL Server needs to recover databases. The default

is 0, indicating automatic configuration by SQL Server. This means a recovery time of less than one

minute. This doesn't mean SQL Server does a checkpoint every minute. The frequency of the

checkpoints depends on number modifications in the database.

The recovery interval option is an advanced option.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

” When a checkpoint statement is issued

” When ALTER DATABASE is issued

” When an instance of Microsoft SQL Server is stopped

” Automatically, depending on the recovery interval

Checkpoints occur

When Do Checkpoints Occur?

Microsoft SQL Server always generates automatic checkpoints. The interval between automatic

checkpoints is based on the number of records in the log. The time interval between automatic

checkpoints is long if few modifications are made in the database. And it occurs frequently if a lot of

data is modified.

The interval between automatic checkpoints also depends on the recovery model. This is explained in

detail in the “Database Restore” unit.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

detail stats.

Begin TransactionUpdate MARA set MATNR = ‘4711’ where MATNR=

‘0000’

Insert into KUNR values (‘9087’, ‘Microsoft’,

‘Redmond’)

Select * from KUNR where KNR = ‘5679’

LSN LSN LSN LSN LSN LSN LSN

301 302 303 304 305 306 307

Begin Tran1 Update Begin Tran2 Update Commit Checkpoint Begin Tran3

MONI MARA Tran1

Tran1 Tran2

MinLSN

303

Boot page

Transaction log

detail stats.

Begin TransactionUpdate MONI set KEY = ‘4711’ where KEY= ‘0000’;

Commit

Logical Sequence Number

During a checkpoint, the log sequence number (LSN) of the first transaction log record at which a

system-wide recovery must start is written to the database boot page. This LSN is referred to as the

Minimum Recovery LSN (MinLSN) and is the lowest of the following values:

• The LSN of the checkpoint

• The LSN of the start of the oldest active transaction

Every database within one Microsoft SQL Server instance has its own transaction log.

The automatic recovery process is explained in detail in the “Database Restore” unit.

More details on the transaction log is found in the “Database Backup” unit.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Lock Modes

detail stats.

Select

detail stats.

Select

detail stats.

Select

detail stats.

Update

detail stats.

Update

....ExclusiveShared

An RDBMS processes a large number of transactions simultaneously. A lock synchronizes simultaneous

accesses to an object. When a transaction accesses an object, the object is temporarily locked to prevent

other transactions from accessing it simultaneously.

The type of lock determines which operations from other transactions can be executed on the locked

object. Types of locks are as follows:

• Shared (S)

- Used for operations that do not change or update data (read-only operations), such as a SELECT

statement.

• Exclusive (X)

- Used for data-modification operations, such as UPDATE, INSERT, or DELETE. This type of lock

ensures that multiple updates cannot be made to the same resource at the same time.

• Update (U)

- Used on resources that can be updated. This type of lock prevents a common form of deadlock that

occurs when multiple sessions are reading, locking, and potentially updating resources later.

• Intent (I)

- Used to establish a lock hierarchy.

• Schema (Sch)

- Used when an operation dependent on the schema of a table is being executed.

The types of schema lock are schema stability (Sch-S) and schema modification (Sch-M).

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Lock Resources

Row

Table

.... 8 pages

Data rows

Index rows Key range

Database (single user)

Extent

Page

SQL Server has multi-granular locking, which allows different types of resources to be locked by a

transaction. These resources are locked at a level appropriate to the task by using a dynamic locking

strategy to determine the most cost-effective locks.

SQL Server can lock the following resources, which are listed in order of increasing granularity:

• RID: row identifier, used to individually lock a single row within a heap

• KEY: row lock within a clustered index, used to protect key ranges in serializable transactions

• PAG: 8 KB data or index page

• EXT: extent, contiguous group of eight data or index pages

• HOBT: a heap or B-tree. A lock protecting an index or the heap of data pages in a table that

does not have a clustered index.

• TABLE: an entire table, including all data and indexes

• FILE: a database file

• APPLICATION: an application-specified resource

• METADATA: metadata locks

• ALLOCATION_UNIT: an allocation unit

• DATABASE: the entire database

The finer the lock granularity, the more locks are needed. For example, when accessing a table with

100,000 pages, you can use 100,000 page locks or only one table lock. More locks require more

administration time.

If the lock granularity is coarse, other transactions must wait longer until the lock is released.

To display the current locks use the sys.dm_tran_locks dynamic management view or the sp_lock

system stored procedure or use the Activity Monitor in the Microsoft SQL Server Management Studio.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Lock Escalation

Fine-grain locks

Coarse-grain locks

Exclusive (X)

Intent exclusive (IX)

Lock escalation( large number of rows

or pages → table lock )

Minimize cost of locking

Table

Transaction 1

Row

Page

Row

Exclusive (X)

11

22

33

44

55Intent exclusive (IX)

SQL Server may dynamically escalate the granularity or type of locks. Lock escalation is the process of

converting many fine-grain locks into fewer coarse-grain locks, thus reducing system overhead. Page or

row locks are converted into one table lock.

In this example, a transaction requests rows from a table for update purpose. SQL Server automatically

acquires locks (1) on the affected rows and places higher level intent locks (2) on the pages or index that

contain those rows. The table that contains the rows also receives an intent exclusive lock (3). When the

number of locks held by the transaction exceeds a threshold, SQL Server attempts to change the intent

lock on the page to a stronger lock, for example, an intent exclusive would change to an exclusive lock

(4). After acquiring the stronger lock, all row level locks held by the transaction on the page are

released, reducing lock overhead (5).

SQL Server may choose to use both row and page locking for the same query. In a join, for example,

page locks are placed on one table, whereas row locks might be placed on the other table. This reduces

the likelihood of lock escalation.

SQL Server’s query optimizer chooses the lock granularity when the execution plan is compiled.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Transaction Isolation Level

T1

T2

X=5

update X

X=7

select X

rollback

X=7

X=5X=7

T1

T2

select X,Y

X=7

Y=2

update X, delete Y

select X,Y

X=4X=4X=7

Y=2

X=7,Y=2 X=4,Y unknown

T1

T2

select <10

insert X, update Y, Z

Y=7 select <10 X=5,Y=8, Z=3

Dirty

read

Non-

repeatable

read

Phantom

X=5

Y=8

Z=3

X=5

Y=8

Z=3

Y=7

Z=12

Y=7

Z=12

changing command

reading command

X=7 data read

Several users running concurrent transactions can cause inconsistencies in the data read by other users.

The following situations may occur:

• Dirty read: Transaction T1 updates data X. Another transaction T2 then selects X before T1

performs a COMMIT. T1 then performs a ROLLBACK. So T2 has read a value for X that never

existed in the database as consistent (committed) data.

• Non-repeatable read: Transaction T1 selects data X, Y. Another transaction T2 then updates X and

deletes Y and commits. T1 then selects X, Y again. It reads a modified value for X and discovers that

Y does not exist.

• Phantom data: Transaction T1 selects all the data that satisfies the condition less than 10. Only X is

returned. Transaction T2 then creates data Z and updates Y so as to satisfy the condition less than 10.

T2 commits. T1 then again selects all the data less than 10. Now X, Y, and Z are returned. So new

data appeared (phantom data).

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Transaction Isolation Level (2)

YesYesYesRead committed

Snapshot

NoNoNoSerializable

NoNoNoSnapshot

YesNoNoRepeatable read

YesYesNoRead committed

YesYesYesRead uncommitted

Phantom Non-repeatable read Dirty read Isolation level

The transaction isolation level determines to what degree one transaction is isolated from other

transactions. A lower isolation level increases concurrency but at the expense of data correctness. A

higher isolation level ensures that data is correct, but can negatively affect concurrency. The isolation

level set by an application determines the locking behavior used by SQL Server.

To define the isolation level for a connection to the database, use the transact-SQL command SET

TRANSACTION ISOLATION LEVEL.

The SQL-99 standard defines the following isolation levels, all of which are supported by the Microsoft

SQL Server Database Engine:

• Read uncommitted accepts all dirty reads, non-repeatable reads and phantoms. No shared locks are

issued and no exclusive locks are honored.

• Read committed avoids dirty reads. To achieve this shared locks are held while data is being read.

But the data can be changed before the end of the transaction, resulting in non-repeatable reads or

phantom data. This option is the SQL Server default.

• Repeatable read avoids both dirty and non-repeatable reads. It sets locks on all data used in a query

and prevents other users from updating the data. Phantom data can occur.

• Serializable avoids all dirty reads, non-repeatable reads and phantoms. It sets a range lock on the

data range selected. Other users cannot update or insert rows into that data range until the transaction

is complete.

SQL Server 2005 also supports the following transaction isolation levels that use row versioning.

• Read committed snapshot, a read committed isolation level, uses row versioning to provide

statement-level read consistency.

• Snapshot uses row versioning to provide transaction-level read consistency. When reading rows

modified by another transaction, they retrieve the version of the row that existed when the

transaction started.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Start an SQL Server Instance with a Trace Flag: Unit Overview Diagram

SQL Server Architecture

Lesson 1: Start an SQL Server Instance with a Trace Flag

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Start an SQL Server Instance with a Trace Flag: LessonObjectives

After completing this lesson, you will be able to:

” Start and stop an SQL Server instance

” Describe the different startup options and how to

set a trace flag

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Start an SQL Server Instance with a Trace Flag:Business Example

” An SAP support engineer asks you to set a certain

trace flag in order to analyze locking behavior on

your database server. Your IT specialists have to

know how to set a trace flag as a startup option and

how to monitor which trace flags are set.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Start an SQL Server Instance with a Trace Flag: LessonSummary

You should now be able to:

” Start and stop an SQL Server instance database

” Describe the different startup options and how to

set a trace flag

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SQL Server Architecture: Unit Summary


” Describe the main features of SQL Server 2005

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


Exercises

Unit: SQL Server Architecture

Topic: Start an SQL Server Instance with a Trace Flag

At the conclusion of this exercise, you will be able to:

• Start and stop an SQL Server instance

• Describe the different startup options and how to set a trace flag

An SAP support engineer asks you to set a certain trace flag in order to

analyze locking behavior on your database server. Your IT specialists

have to know how to set a trace flag as a startup option and how to

monitor which trace flags are set.

1 Start an SQL Server instance with a trace flag

1-1 Connect to your SQL Server named instance <server name>\T##, where ## is the

group you have been assigned to. How do you connect to a SQL Server named

instance using the SQL Server Management Studio?

1-2 Check which trace flags are currently set on your SQL Server named instance.

Which command do you execute?

1-3 Start the SQL Server Configuration Manager and search for the service that runs

your SQL Server named instance T##. What is the name of the service?

1-4 Change the startup options of your service, so your SQL Server named instance

runs with trace flag 1204. What do you enter as Startup parameter?

1-5 Restart your SQL Server named instance T## and check the result. What is

displayed now?

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


Solutions

Unit: SQL Server Architecture

Topic: Start an SQL Server instance with a trace flag

1 Start an SQL Server instance with a trace flag

1-1 Connect to the SQL Server named instance Txx, where xx is the group you have

been assigned to. In the Start menu call Programs -> Microsoft SQL Server 2005 ->

SQL Server Management Studio. In the Connect To Server screen, choose

Server Type: Database Engine

Server Name: TWDF0326\Txx

Authentication: Windows Authentication

or

SQL Server Authentication with SQL Server login id sa.

1-2 Check which trace flags are currently set on your SQL Server named instance Txx.

To do so, execute command DBCC TRACESTATUS (-1) in a Query Window,

which displays the status of all trace flags that are currently enabled globally.

If no trace flags are set, the query returns

DBCC execution completed. If DBCC printed error messages, contact your system

administrator.

1-3 Start the SQL Server Configuration Manager. In the Start menu call Programs ->

Microsoft SQL Server 2005 -> Configuration Tools -> SQL Server Configuration

Manager. Search for the service which runs your SQL Server named instance Txx.

The service which runs SQL Server named instance Txx is called SQL Server

(Txx).

1-4 To change the startup options of your service, so your SQL Server named instance

runs with trace flag 1204 right click the service SQL Server (Txx) and choose

Properties. In the Advanced tab mark Startup Parameter. After the last startup

option enter -T1204. Separate parameters with a semi-colon, for example, -c;-T.

Then click button Apply.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


1-5 Restart SQL Server named instance Txx. To do so, right click the service SQL

Server (Txx) and click Restart. After the instance is restarted, check the result using

command DBCC TRACESTATUS (-1). This command should now return:

Trace Flag Status Global Session

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

1204 1 1 0

(1 row(s) affected)

DBCC execution completed. If DBCC printed error messages, contact your system

administrator.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

How SAP NetWeaver Uses SQL Server

Contents:

Client/Server Architecture with the SAP NetWeaver

ABAP and Java Stack

Database Connection

Authentication

Database Access and Security

Databases Used by SAP NetWeaver

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

How SAP NetWeaver Uses SQL Server: Unit Objectives


” Describe the architectural specifics under Microsoft

SQL Server 2005 and SAP NetWeaver

” Monitor and identify connections made to Microsoft

SQL Server

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

How SAP NetWeaver Uses SQL Server: Course Overview Diagram








Unit 8 Conclusion

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

How SAP NetWeaver Uses SQL Server: Business Example

” Your company runs an SAP system based on SAP

NetWeaver 2004s and Microsoft SQL Server 2005

(for example, ERP 2005 or Enterprise Portal). Your

IT specialists want to understand the

implementation of the SAP system on Microsoft

SQL Server.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SAP NetWeaver

SAP NetWeaver™

Co

mp

osit

e A

pp

licati

on

Fra

mew

ork

PEOPLE INTEGRATION

Multi channel access

Portal Collaboration

INFORMATION INTEGRATION

Bus. Intelligence

Master Data Mgmt

Knowledge Mgmt

PROCESS INTEGRATION

Integration

Broker

Business

Process Mgmt

APPLICATION PLATFORM

J2EE

DB and OS Abstraction

ABAP

Life

Cyc

le M

gm

t

… SAP Web Application Server

Open standards

Web services capabilities out of the box

Scalability

Security

Common installation plus administration

Software lifecycle management

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SAP NetWeaver Application Server

SAP GUI Browser

Internet Communication Manager (ICM)

Dispatcher

WP

ABAP

VM

Java

VM

WP

ABAP

VM

Java

VM

WP

ABAP

VM

Java

VM

Gate

wa

y

ABAP/

Java

Engine

SAP Database Schema

Java Dispatcher

Java

SP

Java

VM

Java

VMSDM

J2EE

Engine

SAP Database Schema

JCo

Message

Server

Enqueue

Server

Central

Services

R RJava

SP

The SAP NetWeaver Application Server is the central foundation for the entire SAP software stack. It

provides a platform for other SAP NetWeaver components (Portal, XI, and so on), as well as for ABAP

and Java applications. The full J2EE standard is supported. The SAP NetWeaver Application Server is

the further development of the SAP Web Application Server.

SAP NetWeaver consists of several application server instances. In addition to the dialog instances,

there is one central instance that contains the message server and the enqueue server. It cannot process

any dialog requests. A dialog instance consists of the following components:

• The Internet Communication Manager (ICM) sets up the connection to the Internet. It can process

both server and client Web requests. It supports the protocols HTTP, HTTPS, and SMTP. The SAP

Web AS may serve a Web server or a client.

• The dispatcher distributes the requests to the work processes. If all the processes are occupied the

requests are stored in the dispatcher queue.

• The work processes execute ABAP or Java programs.

• The SAP Gateway makes the RFC interface between the SAP instances available (within an SAP

System and beyond system boundaries).

• The Message Server exchanges messages and balances the load in the SAP system.

The J2EE component of the SAP NetWeaver Application Server contains the following components

• Java Dispatcher

• Server Process

• Software Deployment Manager

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


…

…

The SAP NetWeaver Application Server can be installed in the following ways:

• ABAP system (with integrated VM Container). In the illustration, these components are in the blue

box on the left. With this installation you can run ABAP programs and selected SAP Java

applications. The Java WM is only used in a few SAP applications.

• Java system. In the illustration, these components are in the green box on the right. With this

installation you can run J2EE applications but not any ABAP programs.

• ABAP and Java system. These are all the components in the illustration.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Access in SAP NetWeaver Environment (ABAP)

SAP InstanceSAP NetWeaver

Application

Server

Database

Server SQL Server

Database ABAP schema

SAP Work Process

Database Access Agent

Dbms independent database interface

(R/3 DB IF)

Dbms dependent database interface

(DBSL IF)

Web Browser SAP GUI Application Client

Open SQL

Native SQL

Microsoft SQL Server accesses objects stored in databases on the database server and accepts all

requests from SAP NetWeaver through the database interface from the database access agent.

The database access agent in the work processes handles database requests, and consists of several

subcomponents. One of these subcomponents is the database vendor-independent R/3 database

interface (R/3 DB IF), which handles accesses to table and dictionary buffers.

The database access agent also provides the Database SQL Library Interface (DBSL IF), which is

database vendor-specific. All components on the SAP system side of this interface are independent of

the database used. On the database side of the interface, only system components provided by the

database vendor are used.

The main task of the DBSL IF is the mapping of ABAP Open SQL statements to the database vendor-

specific SQL language.

The Database Interface is integrated in the ABAP runtime environment. The statements of Open SQL

and Native SQL access the database using this database interface.

• Open SQL is a set of SQL realized in ABAP using ABAP statements. With Open SQL, data in

database tables, which is defined in the ABAP Dictionary, can be read and changed.

• Native SQL statements can be listed in the ABAP programs between special delimiters. Database-

specific SQL statements and special SAP-specific statements are possible. Native SQL statements

are handled by the Native SQL interface of the database interface.

An ABAP-based SAP NetWeaver component accesses data stored in the ABAP schema of the database

<SID>. This schema is usually called <sid>. For example, an SAP system such as BI or ECC called

PRD has a schema called prd, in which ABAP components are stored. For more information on

schemas, see the “SQL Server Architecture” unit.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Access in SAP NetWeaver Environment (Java)

SAP InstanceSAP NetWeaver

Application

Server

Database

Server SQL Server

Database

SAP Work Process

Java Virtual Machine

J2EE Engine

Java schema

Open SQL for Java

Web Browser SAP GUI Application Client

Java Server Process

Java Virtual Machine

Open SQL for Java Framework

Open SQL for Java

Framework

JDBC driver

Open SQL/SQLJ

All programming models that SAP provides for database access from Java programs are based on the

Open SQL for Java framework, which provides performance-enhancing mechanisms, such as table buffering and statement pooling, while providing vendor-independent access to various databases, such as Microsoft SQL Server. The Open SQL for Java enables Java users to develop database access independently of a particular database system. This goal is achieved as follows: • By defining a subset of SQL that is comprehensible for all database systems • By defining a subset of JDBC drivers that is compatible with all database systems

The Open SQL for Java framework provides a wrapper of the proprietary JDBC (Java Database Connectivity ) drivers. The JDBC is part of the J2EE 1.3 standard.

SQLJ is a standard for using Java and SQL together. It was developed by a consortium of companies includin IBM, Informix, Microsoft, Sun, Sybase and Oracle. Using SQLJ, SQL statements can directly be embedded into the Java code. The advantage of SQLJ over JDBC is that the SQL statement check occurs at design time in the SAP NetWeaver Developer Studio. This shortens the entire application development cycle.

Using Open SQL and JDBC, you can select and modify data in existing database tables. The tables are created in the Java Directory.

All these programming models are based on a common persistence infrastructure within the J2EE Engine. The infrastructure is built on an SQL engine that processes all SQL statements created anywhere within the Java server. The main tasks of the SQL engine are to achieve: • Portability of the Open SQL language subset across all database platforms supported by SAP • Performance optimizations through client-side data buffering • Easy maintenance by appropriate database-independent monitoring and tracing facilities

A Java-based SAP NetWeaver component accesses data stored in the Java schema of the database <SID>. This schema is usually called SAP<SID>DB. For example, an SAP system such as EP called PRD has a schema called SAPPRDDB, in which Java components are stored. For more information on schemas, see the “SQL Server Architecture” unit.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SQL Server Network Configuration

The SQL Server Configuration Manager is used to:

• Change the default protocol used by clients when attempting to connect to the server.

• Change the order in which all enabled protocols are attempted, when connecting to a server. If it is

not possible to connect to the server with the first protocol, the second available protocol will be tried

and so on.

• Create client connections to specified servers and save them as configuration entries. Configuration

entries consist of a server alias, a client protocol, and any relevant connection parameters, such as a

pipe name or port number.

• Display information about the SQL Server client protocols currently installed on the system.

Currently the following Net-Libraries are used and forced by the DBSL:

• Central Instance / Application Server: TCP/IP is forced by the DBSL (Computer name <>

Database Hostname)

• Central System: Named Pipes is forced by the DBSL (Computer name = Database Hostname)

• Cluster (SAP / SQL on different nodes): TCP/IP is forced (Computer name <> Database

Hostname)

• Cluster (SAP / SQL on same nodes): TCP/IP is forced (Computer name <> Database Hostname)

For detailed recommendations, see SAP Note 208632.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Connections

SAP NetWeaver

Application

Server

Database

Server

SQL Server

TCP/IP Net-Library


TCP/IP Net-Library

TCP/IP

SAP Work

Process

SAP Work

Process

SNAC (SQL Server Native Access Client)

SAP

Instance

Each SAP work process is connected to the database server through several connections that are used

for executing database commands. These connections are handled by the DBSL interface, which is

implemented using Microsoft OLE DB.

The SQL Server Native Access Client (SNAC) is a new OLE DB driver shipped with Microsoft SQL

Server 2005. This native client is a stand-alone data access Application Programming Interface (API). It

combines the SQL OLE DB Provider and the SQL ODBC Driver into one native dynamic link library

(DLL) and also provides new functionality that is separate and distinct from the Microsoft Data Access

Components (MDAC). SQL Server Native Access Client takes advantage of new SQL Server 2005

features such as Multiple Active Result Sets (MARS).

Note: MDAC is part of the Microsoft Windows operating system. SNAC is shipped with SQL Server

2005 and must therefore be installed on every SAP application server.

See SAP note 734034 for more details.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Multi-Connectivity

” Default connection

” Service connection

” Additional DBCON connection standard when using

ST04

An SAP system has the following types of

database connections:

An SAP system has these types of database connections:

• the default connection

• the service connection

• additional DBCON-connections

The default connection, which is established by the work processes at startup time, is the normal

connection to the SAP database. In the developer trace file, the default connection is labeled with

con_name=R/3.

The service connection is an additional connection to the SAP system’s database. The service

connection allows you to use your own transaction for database operations of an ABAP compilation to

separate the ABAP compilation from the current ABAP execution. In the developer trace file, the

service connection is labeled with con_name=R/3* with an additional label such as NUMBUF or

WORKFLOWTRAC.

An additional DBCON connection makes it possible to access additional databases via ABAP Native

SQL. The database can be of the same dbms type as the default connection, or it can be of any of the

other dbms types with existing DBSL ports (for example, Oracle). The DBCON connections are mainly

used in the database monitors such as DB02 or ST04. In the developer trace file, a DBCON connection

is labeled with con_name=++DBO++0000.

To support the service connection or an additional connection to another database of its dbms type, the

DBSL implementation must be able to manage multiple connects.

…

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


…

To support these multi-connects to different database systems, SAP on the other side must be able to use

different DBSLs in one work process. Since release 4.5B, the DBSL implementation is done in separate

shared libraries and dynamic linked libraries (dll). So, if an SAP system based on a database of vendor

X wants to access a database of vendor Y, it loads the appropriate dll for Y.

It works only if there is a DBSL implementation for that database system on the application server’s

operating system platform. For example, multi-connect to Microsoft SQL Server databases can only be

done on Microsoft systems; there is no DBSL port for Microsoft SQL Server on Windows systems.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Connection to SAP Work Processes

SAP NetWeaver

Application

Server

SAP Instance

SQL Server

Database

Server

01

READ COMMITTED

READ UNCOMMITTED

0 Consistent transactions

1 Dirty read selectsSAP

Work

Process

The following connections are used for each SAP work process, with the following isolation levels:

• Connection 0 for Committed Read selects, DML statements and so on.

This connection has transaction isolation level committed read and it uses transaction control.

• Connection 1 for uncommitted read and DDL statements. This connection has transaction isolation

level read uncommitted and it runs in autocommit mode, that is, every individual statement is

committed immediately.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Multiple Active Result Sets (MARS)

” MARS is new to Microsoft SQL Server 2005

” Clients can maintain multiple active statements on one

connection

” MARS enables interleaved execution rather that parallel

” Only SNAC supports MARS not MDAC

” Using MARS, server side cursors are avoided

Microsoft SQL Server 2005 supports a new feature known as Multiple Active Result Sets (MARS).

This feature allows the client to maintain multiple active statements on one connection. In earlier

versions, when using SQL Server default result sets, the application had to process or cancel all result

sets from one batch before it could execute any other batch on that connection. Microsoft SQL Server

2005 introduces a new connection attribute that allows applications to have more than one pending

request per connection, and, in particular, to have more than one active default result set per connection.

MARS simplifies DBSL design with the following new capabilities:

• Applications can have multiple default result sets open and can interleave reading from them.

• Applications can execute other statements (for example, INSERT, UPDATE, DELETE, and stored

procedure calls) while default result sets are open.

MARS enables the interleaved execution of multiple requests within a single connection. That is, it

allows a batch to run, and within its execution, it allows other requests to execute. Note: MARS is

defined in terms of interleaving, not in terms of parallel execution.

Only SNAC versions of OLEDB support MARS on the client side, and only Microsoft SQL Server

2005 or later supports MARS on the server side.

One of the great benefits of MARS is the possibility to avoid opening a large number of connections and

to avoid using server side cursors. Server side cursors are expensive to set up and require many network

roundtrips for larger result sets. These cursors were mainly used on connection 0 for multiple active

selects that need to run in committed read isolation level. In some cases, cursors were also used in

uncommitted read (on connection 2) to avoid opening too many connections.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SQL Sessions Monitor

To start the SQL Session Monitor, choose transaction ST04. Choose Detail analysis menu then SQL

processes. By default, the output is sorted by the session ID for the most recent request associated with

this connection. The sessions are also grouped by the host process ID (PID), which is the process ID of

the SAP work process.

The Appl. Srv. column displays the host name of the database client. For all connections established by

the SAP system, this is the name of the SAP application server to which the SAP user is connected.

Each SAP work process opens at least two database connections, each of which is identified by its

session ID (SID) associated with this connection and labeled by the Application program name

R3<T><nn>[<pp>] (<m>)<type>[SNAC] OLEDB:

• <T>: Work process identifier (D: Dialog, B: Background, S: Spool, U: Update, E: Enqueue, 2:

Update2, ‘ ‘:external tool such as saplicense or tp)

• <nn>: Work process number

• <pp>: The handle ID of a service connection that has been opened from an ABAP report

• <m>: Number of connection, 0 or 1

• <type>: Connection context controlled by the DBIF

- comm rd: Committed read

- unc rd: uncommitted read, for example, dirty read selects

• [SNAC] stands for SQL Native Access Client the OLE DB library provider used. Microsoft Data

Access Components (MDAC) is no longer required.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


• …

• …

• Example

- R3D18(0)comm rd [SNAC] OLEDB

- R3D18[1](1)unc rd [SNAC] OLEDB

The work process identifier might not be valid after an operation mode switch.

To display the command that is last executed for a session, select the row and click SQL statement.

You can switch between active and inactive sessions, sessions only connected to the SAP system, or all

sessions.

The information displayed is retrieved from different dynamic management views such as

sys.dm_exec_connections, sys.dm_exec_sessions and sys.dm_exec_requests.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SQL Server Activity Monitor

Microsoft SQL Server processes can also be displayed using the Activity Monitor in the SQL Server

Management Studio.

The following status values are possible:

• Running: The process is currently performing work.

• Runnable: The process has a connection and has successfully run in the past. It currently has no work

to perform.

• Sleeping: The process has work to perform, but is waiting for something, such as a lock or user input.

• Background: A background process that wakes up periodically to execute work.

• Suspended: The process has work to perform but has been stopped. The status field does not contain

the reason why the process was suspended. The Wait Type field may contain information about why

the process is suspended.

For detailed information, see SQL Server Books Online.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Data Select From ABAP: Table Buffers

SAP NetWeaver

Application

Server

SAP Instance


SAP Work Process

DBSL IF

Shared

buffers

select * from T100

where ...

endselect.

This section explains how the SAP system accesses the database when executing ABAP programs.

In ABAP, you access the database by using Open SQL commands. The ABAP program and its Open

SQL commands are independent of the database system.

An Open SQL command is converted into a standard form and is passed to the Database Access Agent.

The Database Access Agent checks whether the accessed table is buffered in an SAP table buffer. If the

table is buffered, the data is retrieved from the SAP buffers and results are supplied without accessing

the database.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Data Select From ABAP: PREPARE

SAP NetWeaver

Application

Server

SAP Instance

SAP Work Process


DBSL IF

Database Server

SQL Server

dbs/mss/temp_stmt_reuse_cnt

Stmt OLE DB Stmt text

Id object

34 SELECT SELECT …

OLE DBsp_prepexec (SELECT OBJECT, TABNAME, INDNAME, FROM TBTCO WHERE FCT IN (@P1, @P2, @P3, @P4, ...))

select * from T100

where ...

endselect.

If the requested data is not found in the SAP buffers, the DBSL IF translates the Open SQL command to

one SQL statement.

When an Open SQL statement is sent to the database access agent, the operation is known as the

PREPARE operation. In the SQL trace (transaction ST05), this operation is marked as PREPARE. The

following steps are performed:

• The statement is analyzed by the database access agent and its origin is classified.

• The open SQL statement is converted into a native SQL statement.

• If the statement is called the first time, that is, if it is not found in the local cache, it is prepared on

the database using system stored procedure sp_prepexec, which then returns a SQL Server statement

ID.

• The SQL Server statement ID is stored along with the statement text and the OLE DB command

object in the small local cache.

SAP profile parameter dbs/mss/temp_stmt_reuse_cnt (default 100) controls the size of the local cache of

OLE DB objects.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Data Select From ABAP: OPEN and FETCH

SAP NetWeaver

Application

Server

SAP Instance

SAP Work Process


DBSL IF

OLE DB

Sp_execute ( 34, (@P1, @P2, @P3, @P4, ...))

Database Server

SQL Server

select * from T100

where ...

endselect.

dbs/mss/temp_stmt_reuse_cnt

Stmt OLE DB Stmt text

Id object

34 SELECT SELECT …

Direct SQL statements are executed using system stored procedure sp_execute in the OLE DB interface.

This stored procedure executes a transact-SQL statement, which can be reused many times or has been

built dynamically. The transact-SQL statement can contain embedded parameters. If the statement is

found in the local cache, it is executed using system stored procedure sp_execute.

When the SQL statements is executed, it is compiled and optimized and an execution plan is created. If

the statement already exists and an execution plan is still in cache, the execution plan is reused.

The execution of the direct SQL statement starts with the OPEN operation.

The group of records returned when a direct SQL statement is executed is known as a result set. While

the direct SQL statement is executed, the result set is transferred from SQL Server to the requesting

SAP work process. This is known as the FETCH operation.

When the statement is eliminated from the local cache, an sp_unprepare is executed.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Windows Authentication

SAP Application

server

Database

server

MSSQL

server

<DOMAIN>\

SAPService<SID>

pubs

<SID>

SAP System

Set user <sid>

MSSQL_SCHEMA = <sid>or

dbs/mss/schema = <sid>

SQL Server

schema

Access to

<sid> objects

<sid>

SQL Server user

Authori-

zation

Example:

Login ID

Default schema

<sid>

<sid>

Logon at

SQL Server

<DOMAIN>\

SAPService<SID>

As of Release 4.5A, the SAP system uses trusted connections when running with SQL Server

exclusively. With this method, no SQL Server login IS is used for SAP work process connections. The

Windows user running the SAP service (SAPService<SID>) connects to the database server.

Access to SQL Server is controlled by the Microsoft Windows account or group, which is checked when

logging on to the operating system on the application server. When SAP work processes connect to SQL

Server, they request a Windows trusted connection to SQL Server. SQL Server does not open a trusted

connection unless the SAP application server has successfully logged on using a valid Windows

account. In this case SQL Server does not have to check the account. SQL Server gets the user account

information from the trusted connection properties and matches them against the Windows accounts

defined as valid SQL Server logins. If SQL Server finds a match, it accepts the connection.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Databases in an SAP NetWeaver SQL Server System

msdbmaster tempdb

.ldf.mdf

.ldf.mdf

.ldf.mdf

<SID>

.ldf.mdf

Databases

Files

model

.ldf.mdf

During SQL Server installation, the master, tempdb, and msdb databases are created.

• master: Records all system level information for a Microsoft SQL Server system, that is, all login

accounts, system configuration settings, existence of all other databases and the location of the

primary files.

• msdb: Used by SQL Server Agent for scheduling alerts and jobs, for example, regular backups.

• tempdb: Contains all temporary tables and is re-created every time SQL Server is started. Temporary

tables are automatically dropped at disconnect, and no connections are active when the system is shut

down.

• model: Is used as the template for all databases created on the SQL Server instance. Modifications

made to the model database, such as database size, collation, recovery model, and other database

options, are applied to any databases created afterward.

In addition to the standard databases created in every SQL Server installation, a database is created for

the SAP system. This database receives a three-letter identification (for example, PRD, TST).

In this course, the SAP database is referred to as <SID>.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SAP NetWeaver App. Server

Database Server

Multiple Databases

PR1 PR3

ERP SCM CRM

master msdb tempdb model

PR2

This illustration shows one Microsoft SQL Server instance that hosts multiple SAP databases.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006


Database Server

PR1 PR3

ERP SCM CRM

PR2

Multiple Instances

mastermsdb

tempdbmodel

mastermsdb

tempdbmodel

mastermsdb

tempdbmodel

PR2

This illustration shows several Microsoft SQL Server instances on one physical machine, where each

machine hosts one SAP database

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006


Database Server

ERP SCM CRM

PR2

Multiple Schemas (MCOD)

master msdb tempdb model

PR1

PR2

PR3

The screen shows one Microsoft SQL Server instance and one SAP database, which contains

information for multiple SAP systems. Each of these SAP systems is stored in a different schema.

SAP makes it possible to store data of different SAP components in one single database. This data

coexists in different schemas or under different database users.

In the situation shown, all three databases share the same data files on the file system.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SAP Database Files

SAP Database <SID>

Files

File System <drive>:\<SID>DATA1\<SID>DATA1.mdf

<drive>:\<SID>DATA2\<SID>DATA2.ndf

<drive>:\<SID>DATAn\<SID>DATAn.ndf

<drive>:\<SID>LOG1\<SID>LOG1.ldf

<drive>:\<SID>LOGm\<SID>LOGm.ldf

PRIMARYFilegroup

...

<drive>:\<SID>DATA3\<SID>DATA3.ndf

...

<SID>DATA1

<SID>DATA2

<SID>DATA3

<SID>DATAn

<SID>LOG1

<SID>LOGm

...

Each database has two logical parts: data (data files) and transaction log (log files).

When SQL Server and the SAP system are installed, the data files of the <SID> database are created in

the directories <drive>:\<SID>DATA1\<SID>DATA1.mdf and

<drive>:\<SID>DATAn\<SID>DATAn.ndf, where n is the number of the file. The data files may reside

on different physical drives. The standard installation creates 4 to 16 data files, depending on the

system. This makes it easier to expand the database. See the “Regular Maintenance and Error Handling”

unit.

The transaction log file is created in the directories <drive>:\<SID>LOG1\<SID>LOG1.ldf and

<drive>:\<SID>LOGm\<SID>LOGm.ldf, where m is the number of the file. The standard installation

creates one log file.

After a standard installation, all SAP data files reside in the default filegroup PRIMARY.

Stored procedure sp_helpfile returns the physical names and attributes of files associated with the

current database. Use this stored procedure to determine the names of files attached to one database.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Tempdb Database Files

tempdb Database

Files

File System <drive>:\< MSSQL root>\data\tempdb.mdf

<drive>:\< MSSQL root>\data\tempdb2.ndf

<drive>:\< MSSQL root>\data\tempdbn.ndf

<drive>:\<MSSQL root>\data\templog.ldf

PRIMARYFilegroup

...

<drive>:\< MSSQL root>\data\tempdb3.ndf

...

tempdev

tempdev2

tempdev3

tempdevn

templog

...

tempdb

The standard installation creates one tempdb data file. Depending on different factors such as SAP

product and number of CPUs on the database server, it might make sense to create more than one

tempdb data file. See the “Regular Maintenance and Error Handling” unit and the “Performance

Monitoring and Tuning” unit.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Collation Supported by SAP NetWeaver

SELECT SERVERPROPERTY('collation')

SELECT DATABASEPROPERTYEX(‚<SID>','collation')

SQL_Latin1_General_CP850_BIN2

SQL_Latin1_General_CP850_BIN2

A collation specifies the code page that is the bit pattern that represents each character. Collation also

determines the rules for how to sort and compare data.

On SAP NetWeaver 2004s under Microsoft SQL Server 2005, unicode collation

SQL_Latin1_General_CP850_BIN2 (BIN2) must be set up for both the SQL Server instance and the

SAP database. This stands for the binary sort order with the use of the 850 multilingual character set.

Note: Before upgrading Microsoft SQL Server 2000 used as the SAP database to Microsoft SQL Server

2005, make sure that the server and database collations are set to SQL_Latin1_General_CP850_BIN2.

Refer to SAP Notes 600027 and 799058 for information on how to check and change this.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Connections: Unit Overview Diagram

How SAP NetWeaver Uses SQL Server

Lesson 1: Database Connections

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Connections: Lesson Objectives


” Explain how SAP NetWeaver opens connections to

the database and executes SQL statements on the database

” Identify Microsoft SQL Server sessions using

monitoring tools on the SAP system and kill

sessions using Microsoft SQL Server tools and

commands

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Connections: Business Example

” Your SAP users identify a sudden performance

decrease on the SAP system. Transactions that

usually run fast take too long. Your IT specialists

have to use the SAP monitoring tools to determine

what causes the slow down. In the end, they have to

kill certain database sessions using Microsoft SQL

Server commands.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Connections: Lesson Summary


” Explain how SAP NetWeaver opens connections to

the database and executes SQL statements on the database

” Identify Microsoft SQL Server sessions using

monitoring tools on the SAP system and kill

sessions using Microsoft SQL Server tools and

commands

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

How SAP NetWeaver Uses SQL Server: Unit Summary


” Describe the architectural specifics under Microsoft SQL

Server 2005 and SAP NetWeaver

” Monitor and identify connections to Microsoft SQL Server

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


Exercises

Unit: How SAP NetWeaver Uses SQL Server

Topic: Database Connections


• Explain how SAP NetWeaver opens connections to the database and

executes SQL statements on the database

• Identify SQL Server sessions using monitoring tools on the SAP

system and kill sessions using SQL Server tools and commands

Your SAP users identify a sudden performance decrease on the SAP

system. Transactions that usually run fast take too long. Your IT

specialists have to use the SAP monitoring tools to determine what causes

the slow down. In the end, they have to kill certain database sessions

using SQL Server commands.

1 Database Connections

1-1 Log on to the SAP system using your ADM520-## user, where ## is the group you

have been assigned to. Go to the SAP SQL Session Monitor using transaction

ST04. In a new mode, execute SAP report ZADM520SESSIONS_## using

transaction SE38.

1-2 Go to the SAP SQL Session monitor and filter all sessions executing SAP report

ZADM520SESSIONS_##. How do you set a filter for the ABAP report?

1-3 Monitor the CPU consumption of the report. What sessions have been opened to the

database? What can be read from column “Application Program”?

1-4 You decide it is safe to stop this report immediately as it is causing a performance

decrease. You decide that it is best to kill the corresponding SQL Server session

that consumes a lot of CPU. How do you determine the SQL Server session ID

(SID)?

Which statement or tool do you use to kill SQL Server sessions?

1-5 What happens after the session is killed?

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


Solutions

Unit: How SAP NetWeaver uses SQL Server

Topic: Database Connections

1 Database Connections

1-1 Logon to the SAP System using your ADM520-xx user, where xx is the group you

have been assigned to. Go to the SAP SQL Session Monitor. To do so call

transaction ST04, go to the Detail analysis menu and click button SQL processes.

This shows all connections opened to the SQL Server. Per default the output is

grouped by the host process id (column Host PID).

In a new mode, execute SAP report ZADM520SESSIONS_xx using transaction

SE38.

1-2 Go to the SAP SQL Session monitor and filter all sessions executing report

ZADM520SESSIONS_xx. You can filter the output by any column shown in the

ALV grid. Mark column Name of the ABAP report. Click on button Set Filter.

Enter ZADM520SESSIONS_xx as filter criteria and click Execute. Afterwards only

sessions executing report ZADM520SESSIONS_xx are displayed. To remove the

filter, go to filter and click Delete Filter.

1-3 Monitor the CPU consumption of the report in column CPU ms using the Refresh

button.

For each nested select in report ZADM520SESSIONS_xx a MARS session has

been opened.

Column Application Program shows something like the following:

R3D01(1)unc rd [SNAC] OLEDB

D: Dialog Work Process

01: work process 01

(1)unc rd: connection 1, which is the uncommitted read connection

[SNAC] OLEDB: SNAC OLEDB provider is used

1-4 You decide it is safe to stop this report immediately as it is causing a performance

decrease. You decide that it is best to kill the corresponding SQL Server session

which consumes a lot of CPU.

Connect to the SQL Server default instance using Windows authentication or SQL

Server authentication with SQL Server login id sa. In a Query Window you can use

SQL command KILL <SID> to kill a session. Alternatively you can search for the

session in the SQL Server Activity Monitor, mark it, choose the right mouse button

and choose Kill Process. The SQL Server Activity Monitor is found in the SQL

Server Management Studio under folder Management.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


1-5 The SAP report ZADM520SESSIONS_xx returns runtime error

DBIF_REPO_SQL_ERROR. Developer trace file (transaction ST11) shows an

entry like:

B ***LOG BYM=> severe DB error 233 ; work process in reconnect status

[dbsh#2 @ 1123] [dbsh 1123 ]

B ***LOG BY4=> sql error 233 performing SEL on table REPOLOAD

[dbrepo#3 @ 2656] [dbrepo 2656 ]

B ***LOG BY0=> [233] Named Pipes Provider: No process is on the other end of

the pipe.

[233] Communication link failure [dbrepo#3 @ 2656] [dbrepo 2656 ]

…

B Connection 0 opened (DBSL handle 0)

B Wp Hdl ConName ConId ConState TX PRM RCT TIM MAX OPT

Date Time DBHost

B 000 000 R/3 000000000 ACTIVE NO YES NO 000 255 255

20060704 132625 TWDF0326

B 000 001 ++DBO++0040 000000031 DISCONNECTED NO NO NO 000

255 255 20060704 123414 TWDF0326

B Successful reconnect for connection:

B 0: name = R/3, con_id = 000000000 state = ACTIVE , perm = YES, reco =

NO , timeout = 000, con_max = 255, con_opt = 255, o

B ***LOG BYY=> work process left reconnect status [dblink#3 @ 733] [dblink

0733 ]

The SAP work process reconnects again.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Performance Monitoring and Tuning

Contents:

SQL Server Configuration

Disk Layout and I/O Monitoring

Cache Size Tuning

CPU Utilization

Lockwait Situations

Expensive Statements

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Performance Monitoring and Tuning: Unit Objectives


” Monitor the performance of Microsoft SQL Server

” Identify the source of database performance

problems

” Find solutions to the performance problems

detected

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Performance Monitoring and Tuning: Course Overview Diagram








Unit 8 Conclusion

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Performance Monitoring and Tuning: Business Example

” The SAP workload monitors show that the high

overall response time of your productive SAP

system is mainly caused by high database response

time. As a member of the SAP project team, you

analyze the performance of Microsoft SQL Server

using SAP tools.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Sources of Database Performance Problems

Performance problems

due to:

Poor database

configuration

Inefficient applications

Poor hardware

configuration

1 2

Poor configuration

Poor database performance normally results from problems with database configuration, application

coding problems, or hardware capacity. This section explains how to identify and correct these

problems.

The first step is normally to tune the database and hardware configuration. Use the Database Monitors

to:

• Check the general database configuration

• Verify the efficiency of the application coding

Note: Tuning inefficient application coding may allow you to avoid buying new hardware.

Because changing the database configuration may affect the amount of hardware required, this unit

explains how to check if your current hardware configuration allows the necessary database

configuration changes.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SQL Server Configuration

Disk

layout

Configuration

Options

Memory

Management

Poor hardware

configuration

Disks

CPU

Main

Memory

Poor database

configuration

Poor configuration

This section discusses the following areas of database configuration:

• Disk layout

• SQL Server configuration options

• Memory Management

An entry point into performance analysis and tuning should always be the Global Workload Monitor

(transaction ST03G). Using this monitor, you can determine the source of possible performance

problems using many analysis views.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Optimal Disk Layout (Data Separation)

min. 5 GB min. 20 GB

<SID>

data files

SQL Server

tempdbpaging file(s) <SID> Transaction

Log file(s)

1-4 GB 1-2 GB

SQL Server

tempdbTempdb data files

tempdb

Transaction log

File(s)

1-2 GB

RAID1 RAID1 RAID1 RAID5

Suggested disk requirements

Disk input/output (I/O) is the most time-consuming operation for the database system. Therefore,

performance can be improved significantly by:

• Using fast disks and I/O controllers

• Physically separating files with high I/O activity so that they can operate concurrently

Maximum throughput can be achieved by placing the following four types of files on separate physical

disks (or disk systems/controllers):

• paging file(s): The paging files contain temporary data that do not require redundancy to ensure data

security. For high availability, RAID1 should be used. Since these files are write-intensive, they

should not be placed on RAID 5 systems. If they are small enough to fit on one disk, RAID

technology is not required.

• SQL Server tempdb file(s): The tempdb database is created in the directory \TEMPDB. SAP

recommends the use of RAID1.

• <SID> transaction log file(s): The transaction log is created by default in the directory <SID>LOG1.

The transaction log requires a minimum of 5 GB. SAP recommends the use of RAID1.

• <SID> data files: Data files are created by default in the directories \<SID>DATA<N>. The

minimum space required for all files is 20 GB. For security and performance reasons locate these

files on a separate disk system. To ensure data redundancy, SAP recommends the use of RAID5 or

RAID1.

To check the hardware resources refer to the SAP Installation Guide found on the SAP Service

Marketplace at service.sap.com under quicklink instguides. The minimum requirements for a small SAP

system installation (application server and database server) are given in the figure. Depending on the

amount of data involved, the requirements will change.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SAP Data Files

Considerations:

” Manageability: “as few as possible”

” Performance: “as many as necessary”

” The minimum number of data files may be calculated by the

formula:

MIN (3; number of CPUs).

The number of SAP data files is chosen during SAP product installation. The SAP installation typically

uses three data files by default, which is appropriate for the majority of smaller SAP installations.

In Microsoft SQL Server, data access performance within a data file is not related to the size of the data

file, but to its concurrency on internal administration pages within the data file. See the “SQL Server

Architecture” unit for details on special pages.

For the best performance, the ideal number of data files for the SAP installation is typically equal to the

number of CPU or processor cores dedicated to Microsoft SQL Server at a 1:1 ratio. There must be at

least three data files.

Additional data files are sometimes required for handling reasons such as when data files become too

large to handle in copying.

Note: The number of CPUs or processor cores dedicated to Microsoft SQL Server depends also on the

affinity mask configuration option, which is explained in the following slides.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Tempdb Performance

File System X:\tempdb\tempdb.mdf

Y:\tempdb\templog.ldf

SQL SERVER

Windows server

tempdev

tempdev2

tempdev3

tempdev8

tempdb

…

templog

X:\tempdb\tempdb1.ndf

X:\tempdb\tempdb2.ndf

X:\tempdb\tempdb8.ndf…

Tempdb is the temporary database for Microsoft SQL Server. Tempdb is used by queries to execute

large join, sort, and group operations when the SQL Server buffer pool cannot provide enough memory.

The usage of tempdb differs according to the type of workload. The types of workloads are:

• Online Transactional Processing (OLTP) oriented workloads – SAP products with OLTP-

oriented workloads including SAP CRM and SAP EP, use tempdb infrequently such as for larger

join operations, aggregation, and smaller sorts. tempdb typically does not load or sort a lot of data

and does not affect performance. For installation, set the tempdb space from 1 to 2 GB. For SAN

storage, tempdb can share space with the tempdb log files.

• Online Analytical Processing (OLAP) oriented workloads –SAP products with OLAP-oriented

workloads including SAPNetWeaver BI expand tempdb to larger sizes. For example, join operations,

especially those that fully scan the fact table of a cube, use a lot of space to store temporary result

sets such as large sorts, or to build aggregates. In these cases, tempdb is used to perform most of the

work because the memory space usually is not sufficient to process this amount of data. In extreme

cases, when the whole fact table is read in order to build an aggregate, tempdb can grow to the size

of the fact table, up to several hundred gigabytes.

• To prevent bottlenecks on tempdb, perform these steps:

- Set the tempdb size to 1.5 times the space of the largest fact table.

- Manage tempdb as a normal SAP database. If the contention is on special administrative pages,

increase the tempdb data files to distribute the workload across all files. Choose as many files as

there are CPUs.

- Do not place tempdb on the same partition and disks that contain the transaction log.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Wait Statistics

1

2

3

To analyze performance issues with Microsoft SQL Server, information about wait situations

encountered by threads can be used. View sys.dm_os_wait_stats returns specific types of wait times

during query execution. High wait times can indicate bottlenecks or hot spots on a server instance. For

example, page I/O latch waits (wait type PAGEIOLATCH_SH for read operation or

PAGEIOLATCH_EX for write operation) indicate slow I/O response times.

These wait types can indicate whether your I/O subsystem is experiencing a bottleneck, but they do not

provide any visibility on the physical disk(s) that experience the problem.

The Latch wait time per Request (ms) shown in the ST04 Current Activity screen shows the average

latch wait time in microseconds to read a requested page from disk into the buffer (1). The wait time

value per read request is built from the quotient of (wait time) / (number of requests).

The values shown in ST04 can be displayed as calculated since database restart (2) or as a floating

average over the last 20 minutes (3).

The statistics collected in the dynamic management view sys.dm_os_wait_stats are not persisted across

SQL Server restarts, and all data is cumulative since the last time the statistics were reset or the server

was started.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Collector

1

2

Starting with SAP Web Application Server release 6.10, SAP delivers an additional SQL Agent job for

all systems running on Microsoft SQL Server. This job regularly collects database performance data,

which is needed in transactions ST04, DB02 and RZ20. This data is crucial for database performance

tuning. Leave this job enabled at all times.

The DB collector can be started using transaction ST04 and clicking DB Collector.

The counters, such as the PAGEIOLATCH_SH, which are collected by the DB collector, can be

displayed as a snapshot (1) or over a time series to analyze a critical time frame (2). The counters are

divided into certain categories such as I/O, memory, and buffer access.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Analyzing Disk I/O Problems: SQL Server I/O Statistics

1

2

3

4

SQL Server collects I/O statistics for the data and log files for all the databases on an SQL Server

instance. You can use these I/O statistics to compare the activity for each data file and to determine

whether activity is evenly distributed over the data files.

The I/O statistics are included in ST04: choose Detail Analysis menu → IO per File. You can choose

between tempdb and the SAP database.

The “IO wait: ms per read operation” column displays the average wait time for one read operation in

ms and is calculated from the output of SQL Server system function fn_virtualfilestats. For acceptable

performance, this value should be below 10 ms for all data files (1). For the transaction log files, the

average wait time is much smaller than for data files (2).

Additionally data collected by the SAP system is sampled every 20 minutes to allow an analysis of

certain time windows. All columns named "...recently" refer to this period (3).

fn_virtualfilestats counts the statistics since SQL Server start.

In the ST04 Current Activity screen, the I/O wait time per read operation is shown in the IOStall per

Request (ms) figure for all files (4).

For more information, see SQL Server Books Online and SAP Note 521750.

Using the Reset/Since reset function, the current I/O performance can be specifically analyzed starting

from the moment of the Reset. It can be used for the SAP database and tempdb at the same time.

Reference values are stored within the ABAP program and are lost when leaving the screen.

Counters Latch wait time per Request (ms) and IOStall per Request (ms) in ST04 are related. But both

counters are calculated and maintained by different modules within SQL Server. IOStall is a counter

from an I/O perspective (file system access time), whereas the latch wait time is a counter from the

buffer management inside the SQL Server engine.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Analyzing Disk I/O Problems: Performance Monitor

Disk queue

length up to

45 >> 4

(2 disks)

100% Disk time

Disk I/O performance can be measured using the Performance Monitor (from Start, choose Settings →

Control Panel → Administrative Tools → ҏPerformance).

Note: Windows does not show the physical disks in the RAID system. Therefore, you first need to

divide the performance counters by the number of physical disks.

• For RAID 1 (and RAID 0+1), multiply the number of I/O write requests by 2.

• For RAID 5, multiply the writes by N-1, where N is the number of physical disks in the RAID-

system, to get the number of physical disk I/O requests.

When “% Disk Time = 100,” you must check I/O performance. The disk queue length (read + write

queue) per physical disk should not significantly exceed 2, otherwise there is an I/O bottleneck.

To get disk performance data, enable the disk performance object using command diskperf -y (a

Windows reboot is required afterwards).

For long term monitoring, use the Performance Monitor to create a log file with snapshot data from the

specified update intervals.

For more information about using the Performance Monitor, see SAP Note 110529 and Windows

Online Help.

To find the peak throughput for a whole RAID system or the whole I/O bus, measure disk I/O

performance on all physical disks.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

I/O System Tuning: Summary

Slow RAID

identified?

Avg. disk queue

length > 2 * phys.

Disks in RAID

Yes

Change hardware

configurationI/O stats per file

show IO wait for

one file > 10 ms

High db

response

time?

High

PAGEIO-

LATCH_SH

SAP data file tempdb data file

Data separation

Optimal?

Separate tempdb,

SAP data, SAP log

and page file

Separate tempdb,

data and log

# of data files

=

# of CPUs?

Increase number

of data files

Check for expensiveStatements, Cache

Size and CPU

Yes

Yes

No NoData separation

Optimal?

Yes

No Yes

Yes

Yes

Yes

Check for SQL Serverconfiguration

No

When you have identified an I/O bottleneck, you can address it by doing one or more of the following:

• Check the memory configuration of Microsoft SQL Server. If Microsoft SQL Server has been

configured with insufficient memory, it will incur more I/O overhead.

• Examine expensive statements. Improved statements will minimize I/O.

• Check for a proper data separation and distribution.

• Ask your hardware partner to check your hardware configuration. This might lead to:

- Increase I/O bandwidth.

- Add more physical drives to the current disk arrays and/or replace your current disks with faster

drives. This helps to boost both read and write access times. But don't add more drives to the

array than your I/O controller can support.

- Add faster or additional I/O controllers. Consider adding more cache (if possible) to your current

controllers.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Statement Execution

Database

RDBMSData cache

Procedure cache

parsed SQL

statements and

execution plan

Memory

SAP Work Process

SELECT *

FROM MARA

WHERE ...

Tables Indexes

MARA

MARA_1

MARA_0

SQL connections

sp_prepexec

(SELECT *

FROM MARA…)

1

An Open SQL statement coming from an ABAP program is executed as a direct statement on SQL

Server using system stored procedures sp_prepexec and sp_execute. Sp_execute executes a Transact-

SQL statement or batch, which can be reused many times or has been built dynamically (for example,

statements coming from FOR ALL ENTRIES). It uses a handle ID, which is prepared using system

stored procedure sp_prepexec.

The part of the buffer pool that is used to store execution plans is referred to as the procedure cache.

When any SQL statement is executed in Microsoft SQL Server, the relational engine first looks through

the procedure cache to verify that an existing execution plan for the same SQL statement exists. SQL

Server reuses any existing plan it finds, saving the overhead of recompiling the SQL statement. If no

existing execution plan exists, SQL Server generates a new execution plan for the query. System stored

procedure sp_prepexec parses the SQL statement and creates an execution plan, which is then stored in

the procedure cache (step 1).

SQL Server automatically allocates the necessary space and dynamically adjusts the size of the

procedure cache from the available buffer pool.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Statement Execution (2)

Database

RDBMS

Data cache

Procedure cache

Memory

Tables Indexes

MARA

MARA_1

MARA_0

SQL connections

0x1237

0x8921

3

44

sp_execute(

Handle_id,

…)

2

5

SAP Work Process

SELECT *

FROM MARA

WHERE ...

sp_execute is used to execute a Transact-SQL statement several times when only parameter values in the

statement change. Because the Transact-SQL statement itself remains constant and only the parameter

values change, the SQL Server query optimizer is likely to reuse the execution plan it generates for the

first execution (step 2). Once the execution plan is in the procedure cache, the statement can be

executed.

The execution plan determines which indexes are to be used for table access (step 3).

The required pages of the used indexes and tables are transported from the disk into the data cache for

further processing (step 4). The SQL Server Query Processor selects the data required and returns it

through the database interface to the SAP work process (step “5).

Details on sp_execute and sp_prepexec are discussed in the “How SAP NetWeaver Uses SQL Server”

unit.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SQL Server Performance Analysis Monitor

1

2

3

4 SQL Server Buffer Pool

5

6

It is a performance gain if the data and index pages required are already stored in the data cache from

previous use.

To display the most important performance parameters of the database, use transaction ST04 to start the

SQL Server Performance Analysis Monitor.

The current size of the SQL Server buffer pool (1) is displayed along with the physical memory on the

database machine (2).

SQL Memory Setting (3) shows the memory allocation strategy used, and shows the following:

• FIXED: SQL Server has a constant amount of memory allocated, which is set by SQL Server

configuration options min server memory (MB) = max server memory (MB).

• RANGE: SQL Server dynamically allocates memory between min server memory (MB) < > max

server memory (MB).

• AUTO: SQL Server dynamically allocates memory between 4 MB and the physical available

memory, which is set by min server memory (MB) = 0 and max server memory (MB) = 2147483647

(2 PB).

• FIXED-AWE: SQL Server has a constant amount of memory allocated, which is set by min server

memory (MB) = max server memory (MB). In addition the address windowing extension

functionality of Windows is enabled.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SQL Server memory displayed in Current Memory (MB) (1) is divided into the data cache, the

procedure cache, the lock cache and the free page list (4). In the example above, the buffer pool sums up

to approximately 1801 MB, leaving 153 MB for other memory request less than or equal to 8 KB.

…

…

A detailed description of the memory options is found in the following slides and in the “SQL Server

Architecture” unit.

An analysis of the SQL Server memory usage is only meaningful if the database has been running for

several hours with a typical workload. The time SQL Server has been started is displayed along with the

time of the displayed analysis (5).

The data cache hit ratio and the procedure cache hit ratio (6) shows the average percentage of requested

data pages respectively requested procedures found in the cache. This counter is derived from dynamic

management view sys.dm_os_performance_counters (buffer cache hit ratio/buffer cache hit ratio base).

The counter does not reflect the hit ratio since startup because Microsoft SQL Server provides this

counter as a counter that is updated and reset regularly. A meaningful cache hit ratio can be displayed

using a counter for Buffer lookup/per page reads. This is the ratio between all buffer requests and the

buffer requests that could be handled without reading data from disk.

Before increasing SQL Server memory, you must check if there is sufficient main memory available.

Operating system paging is a sign of insufficient main memory, especially on the database server. Start

transaction ST06 and choose Detail analysis menu → ҏPrevious hours → ҏMemory. The number of pages

in per hour should not exceed 20% of the available physical memory. For optimal performance, the

value should be 0.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SQL Server Memory Settings

” SQL Server Memory Options

max server memory (MB)

min server memory (MB)

awe enabled

” Size of physical and virtual memory

” SAP NetWeaver Scenarios

Microsoft SQL Server memory management was outlined in the “SQL Server Architecture” unit.

Managing SQL Server memory involves consideration of the SQL Server configuration options:

• max server memory (MB)

• min server memory (MB)

• awe enabled

How memory should be configured for SQL Server further depends on:

• The coexistence of other SAP components on one physical machine (that is, either a central instance

or an update instance on the same machine as Microsoft SQL Server runs)

• The amount of available RAM and virtual memory

• Windows operating system (32-bit or 64-bit)

Recommended memory settings are detailed in SAP Note 879941.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Memory Options for Different SAP NetWeaver Scenarios

” Dedicated Database Server

max server memory (MB) = 2147483647

min server memory (MB) = 0

” SAP Central System

” max server memory (MB) = min server memory (MB)

The recommended values of the configuration options min server memory (MB) and max server memory

(MB) differ in each of the following scenarios:

• Dedicated database server: On a dedicated database server no other application or service runs on

the same hardware where Microsoft SQL Server is installed. In this scenario you can leave the

default behavior of automatic memory adjustment. This is achieved by setting min server memory

(MB) to 0 and max server memory (MB) to 2147483647 or to the amount of available main memory.

Actually the only thing you should ensure is that max server memory is not less than the physical

memory available on the server.

• SAP central system: On an SAP central system, the same hardware is shared by Microsoft SQL

Server and the SAP central instance. As a starting point we recommend giving about a third of

physical memory to Microsoft SQL Server. For example, on a server with 4 GB physical memory

you give 1200 MB to 1500 MB to Microsoft SQL Server. On an SAP central system, we recommend

setting min and max server memory to the same value. If you have additional SAP application

servers, then you may need to increase the amount of memory for Microsoft SQL Server. The SAP

instance on the database server only takes a small percentage of the physical memory. Because this

decreases the amount of memory for the SAP central instance, it may be a good idea to have a

dedicated database server for huge systems.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Non Paged AWE memory

Windows Address Space (32-Bit)

page files physical RAM ( > 4GB )

Memory

2GB kernel 2GB user adress space

boot.ini on 32-bit

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows"

/3GB /PAE

2.5GB user1.5GB kernel/3GB /PAE

/USERVA=2560

3GB flat user adress space1GB kernel/3GB /PAE

1

2

3

4

/PAE

3GB user adress space1GB kernel

All 32-bit applications have 4 GB of process address space. Windows provides applications access to

2 GB of process address space, known as user address space. The remaining 2 GB are reserved for the

operating system, also known as kernel address space. (1)

The Microsoft Windows 2003 Server operating system has a boot.ini switch that can provide

applications with access to 3 GB of process address space, limiting the kernel mode address space to

1 GB. To enable this, the /3GB parameter must be added to the boot.ini file. (2)

With the /Userva switch, you can customize how the memory is allocated when you use the /3GB

switch. The number following /Userva= is the amount of memory in megabytes (MB) that will be

allocated as user address space.

Address Windowing Extensions (AWE) is an extension to the memory management of Windows that

allows applications to address more memory than the 2-3 GB that is available through standard 32-bit

addressing. AWE lets applications acquire physical memory, and then dynamically map views of the

non-paged memory to the 32-bit address space. Although the 32-bit address space is limited to 4 GB, the

non-paged memory can be much larger. This enables memory-intensive applications, such as large

database systems, to address more memory than can be supported in a 32-bit address space. To enable

the Physical Address Extension (PAE) /pae must be added to the boot.ini file. (4) Windows sets PAE

automatically when it detects more than 4 GB of main memory. The application can then enlarge the

user address space, if it switches AWE on.

Note: If there is more than 16 GB of physical memory available on a computer, the operating system

needs 2 GB of process address space for system purposes and therefore can support only a 2-GB user

mode address space. In order for AWE to use the memory range above 16 GB, the /3GB parameter must

not be in the boot.ini file. If it is, the operating system cannot address any memory above 16 GB.

Microsoft SQL Server 2005 Enterprise Edition can access up to 64 gigabytes (GB) of memory on

Windows 2000 Server and Windows Server 2003.

Note: On a Windows 64-bit system, the above mentioned switches are not necessary.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

CPU Utilization Analysis

1

2

3

Transaction ST04 shows the CPU usage of Microsoft SQL Server. The header section of the ST04 main

screen displays the number of CPUs installed on the computer where SQL Server is running and the

number of CPUs that can be used by SQL Server (1). SQL Server 2005 supports processor affinity using

the following affinity mask options:

• affinity mask (also known as CPU affinity mask): controls the association between the SQL Server

and the processors

• affinity I/O mask: binds SQL Server disk I/O to the specified processors

CPU and I/O affinity support for servers with 33 to 64 processors requires the use of additional

configuration options:

• affinity64 mask

• affinity64 I/O mask

Affinity support for servers with 33 to 64 processors is not available on 32-bit operating systems.

In folder Current Activity, counter CPU Busy (2) shows the fraction of time over the last 20 minutes that

the sqlservr.exe executable was busy on a CPU. This counter is calculated on a per second basis. The

value range is between 0 and the number of processors available for SQL Server. If the value of the

counter is consistently close to the number of processors, a CPU bottleneck may exist.

If the CPU is busy with other processes than sqlserver.exe, it will not be shown in the SQL Server CPU

counters.

Counter IO Busy (3) shows the fraction of time over the last 20 minutes that the sqlservr.exe was busy

doing I/O operations. This counter is calculated on a per second basis. IO Busy is part of CPU busy.

To display values since startup, go to DB Analysis → Since Startup.

Note: Each CPU counts separately, that is, if 3 CPUs are used in 2 seconds, CPU busy = 6. If 1 CPU

was used and 2 were unused in 2 seconds, CPU idle = 4.

To check the history of the CPU utilization, use transaction ST04 and choose DB Collector.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

CPU and Cache Tuning: Summary

Poor SQL

statements?

Cache hit ratio

> 98%?

CPU busy <

Amount of CPUs

OS paging?All CPUs available

for SQL Server?

Tune poor

statements

Increase SQL Server

memoryand set

memory mode

Increase server main

memory

Add CPU(s)to server or

move applicationsto other servers

Yes Yes

YesYes

No No

NoNo

Yes

No

+

Overall DB

performance

bad

good

IncreaseCPUs for

SQL Server

Before tuning memory or CPU for Microsoft SQL Server, you should make sure that poor SQL

statements are already tuned because they can significantly affect memory or CPU utilization. How to

detect and tune poor SQL statements is discussed later in this unit.

Before increasing SQL Server memory, you must check if sufficient main memory is available.

Operating system paging is a sign of insufficient main memory; especially on the database server.

The SQL Server configuration options should be set as described in SAP Note 879941 and earlier slides.

Before increasing the number of CPUs on the server, check the usage of the CPUs for other applications

that could be moved to other servers (for example, SAP work processes). Also check the CPU

utilization history of the Windows processes. Use transaction ST06, choose Detail analysis menu, then

Top CPU processes. Alternatively, use the Windows Task Manager.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SQL Server Configuration: Summary

Disk

layout

Configuration

Options

Memory

Management

Hardware

configuration

Main

memory

CPU

Disks

Poor database

configuration

Poor configuration

Cache

hit ratio

SQL Server

CPU utilization

High I/O

wait timesOperating

system

pagingCPU

utilization

Disk

response

times> 98%

Busy < # CPUs

(SQL Server)

PAGEIOLATCH_SH

and

PAGEIOLATCH_EX

2 * idle > busy

(total)

Wait queue

and low

transfer rate

Page in

< 20% of RAM

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Application Problems

LockwaitsPoorly

qualified

statements

Poor configuration

Poor database

configuration

Poor hardware

configuration


due to:

Too many

unnecessary

statements


Slow or long running SQL statements can contribute to excessive resource consumption such as CPU,

I/O activity and memory. Even if SQL Server queries are properly designed, they might not perform as

expected if there is no appropriate index supporting that particular query. CPU, I/O, and memory usage

and tuning is covered earlier in this unit.

The following situations may result in slow running statements:

• Lockwaits: Caused by long running transactions that hold locks, which block other transactions that

want to get the same locks. The cause of the blocking can be a poor application design, bad query

plans, the lack of useful indexes, and an SQL Server instance that is improperly configured for the

workload.

• Too many unnecessary statements: Poor coding causes many small statements to be read in a loop

or results in data being read multiple times.

• Poorly qualified statements:

- Insufficient selection criteria is given.

- The database optimizer has no efficient access path to the requested data (for example, in the case

of missing indexes).

- The database optimizer does not find the best access path (due to an inappropriate execution plan).

- In addition to missing indexes, there may be indexes that are not used. Because all indexes have to

be maintained, this affects the DML statements.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Exclusive Lockwait

If many users are waiting

for a specific lock, they may

block all other users.

Frontend

users

SAP Application Server

SAP Work processes

Database

data

row

In this example, a large number of SAP user requests are channeled into a smaller number of SAP work

processes on the SAP application server.

A user holding a lock occupies an SAP work process. Other users trying to apply the same lock will

have to wait and at the same time occupy their own SAP work process.

As the number of lockwaits increases, fewer and fewer SAP user requests can be processed by the

available SAP work processes.

In the worst case (lockwaits = number of SAP work processes), a small number of users can cause the

entire SAP system to freeze.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Lockwait Situations

Time

Acquires

MARA Lock

A long period

of processingCommit

Update

MARA

Working...WAITING!Update

MARA

Requests

MARA Lock

Acquires

MARA LockCommit

Working...WAITING!Update

MARA

Requests

MARA Lock

Acquires

MARA Lock

WAITING ...Update

MARA

Requests

MARA Lock

Locked

by:

WP 1 WP 2 WP 3MARA

SAP

Work

Process 2

SAP

Work

Process 3

SAP

Work

Process 4

SAP

Work

Process 3

When updates are programmed, the time that the program holds a lock should be kept as short as

possible.

This diagram illustrates how the wait time to acquire a lock increases when several work processes are

waiting to acquire a lock on the same object, and a long time is needed to process each update.

Work process 1 acquires a lock to update table MARA. When work process 2 requests a lock on the

same object, it has to wait for work process 1 to release its lock. Work process 1 takes a long time

processing before it performs a commit and releases the lock.

While work process 2 is waiting to acquire the lock, a lock request from work process 3 is pending.

Work process 3 has to wait until work process 2 performs a commit. Work process 3 has to wait even

longer than work process 2 because it has to wait for work process 1 and 2 to complete their commit.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Monitoring Exclusive Lockwait Situations

Exclusive lockwait situations due to database locks are shown in the SAP SQL Server Performance

Analysis Monitor (use transaction ST04 and choose Detail analysis menu → ҏExclusive Lockwaits).

The Host PID is the process ID of an SAP work process. The owner of the lock is shown in a blue line

and holds the status granted shown by a green signal in the first column. All blocked sessions are shown

below and have the status Waiting indicated by the red signal.

The second line in the Blocked By column shows the SQL Server process ID (SPID) that blocks the

session.

See SAP Note 806342 for details on analyzing exclusive lockwait situations.

Note: Do not mix up deadlocks and blocking locks.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Monitoring Exclusive Lockwait Situations (2)

1

234

Current lockwait situation can also be monitored using the Activity Monitor in the SQL Server

Configuration Manager. This is useful when no SAP work process is available to call the SAP

monitoring tools such as ST04.

On the database server, choose Management → ҏActivity Monitor → ҏProcess Info. This displays all the

SQL Servers sessions, which are identified by their process ID (SPID).

Blocking is indicated by the Blocking column, which contains a blocking lock holder (1).

The Blocked By column contains the lock holder SPID that holds a lock requested by the session (2).

The Suspended icon in the Process ID column shows that the process has work to perform but has been

stopped. The Wait Type column contains information about why the process is suspended (4).

Stored procedure sp_block lists sessions that are blocked and the sessions that are blocking them.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Blocking Lock Statistics

1

Blocking in RDBMS is common and is needed to maintain the transactional consistency. However,

when the wait time for locks is too long, database response time is impaired.

To identify blocking situations, use the blocking lock statistics, which can be collected in ST04 by

choosing Detailed Analysis Menu → Blocking Lockstats.

This monitor displays the history of exclusive lockwaits of the last 7 days. Data is only available when

data collection has been enabled by clicking Turn collector job on. This job, which is known as SAP

CCMS_<schema_name>_<SID>_Blocking_Lockstats, will run every minute checking for exclusive

lock waits. Any exclusive lock wait situation found at that time is stored in a database table. Information

about both the sessions blocked (displayed in red) and the sessions holding locks and blocking other

sessions (displayed in white) is stored. Entries older than one week are dropped by a second job, known

as SAP CCMS_<schema_name>_<SID>_Cleanup_Saplocks. The job can be disabled by clicking Turn

collector job off (1).

Leave this job running on your system.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

If Buffer Lookups Per SQL Batch >> 30

Aggregated View:

” Statement Analysis by Runtime (SAP SQL Statistics)

” Statement Analysis by Buffer Lookups (SQL Requests)

Finding Expensive Statements

If ABAP Report or Transaction with high db response time found

Non-Aggregated View:

” SQL Trace (ST05)

” SQL Server Profiler

To detect if expensive SQL statements impair the database response time, the following tools and values

are important:

• Buffer Lookups Per SQL Batch: The average number of buffer page lookups per executed batch

indicates how often batches make buffer accesses. If this value exceeds 30, this indicates SQL

statements that read a lot of (unnecessary) data. In this case, search for expensive statements using

the SAP SQL Statistics and/or the SQL Requests. This counter can be seen in ST04 under Current

Activity. Statistical data on this value can be seen using the performance history (in ST04 choose

Detailed Analysis Menu → Performance history).

• SAP SQL Statistics: Statistical information about the execution of the most expensive statements

coming through the DBSL are stored in a local cache for each SAP instance. These statistics can be

used to identify statements that put a lot of load on the database in terms of runtime.

• SQL Requests: Statistics about the execution of statements are stored in SQL Server view

sys.dm_exec_query_stats. These statistics can be used to identify statements that put a lot of load on

the database in terms of buffer lookups.

• SQL Trace: This tool lists all statements that are executed on the database. The trace must be

explicitly switched on and off. This trace tool is used for ABAP programs or transactions. The SQL

trace can be used if you want to analyze ABAP reports or transactions with a high database response

time.

• SQL Profiler: If no SAP system is available, for example, in a Java environment, the SQL Server

Profiler can be used to trace queries executed on an SQL Server instance.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SQL Statistics

SAP Work

Process

SAP Instance

MSSTATS cache

SELECT "CLIENT","USERNAME",

SELECT "TABNAME","NO_OF_LINE

INSERT INTO SNAP (DATUM, UZE

SELECT T_00."ROLLNAME",T_00.

INSERT INTO SNAP (DATUM, UZE

SELECT "MANDT","RECEIVER","C

DECLARE @O000 nvarchar(128),

SELECT "OBJECT","ERROR","LOC

Stats info

Switch

On / Off

SQL Server

SQL connections

Sp_execute

The msstats cache of each SAP instance stores statistical information about the execution of the most

expensive statements in terms of runtime. It keeps information such as:

• Duration of the slowest and average execution (in ms)

• Number of executions (since the statistics were turned on)

• Number of rows returned during the fastest, slowest, and average running execution

• Parameter values for the execution that returned the maximum number of rows

To view these statistics, start transaction ST04 and choose Detail analysis menu →ҏSAP SQL Statistics.

By default, the collection of these statistics is switched on (SAP instance profile parameter

dbs/mss/stats_on = 1). The statistics can be displayed for a single application server or for all the

servers.

Cache entries are tagged with names starting with “##”. These names are used as internal names in the

memory.

The msstats cache is controlled by SAP instance profile parameter dbs/mss/par_stmt_cache_size

(default 500). This parameter controls how much memory is used when statement statistics are

collected.

The quotient of the total runtime with fetch to the runtime with fetch of a single statement tells the load

a single statement puts on the database. The most expensive statement on the database in terms of

runtime with fetch is listed at the top. In the example above, the first statement in the list causes a load

of approximately 5% (1995 sec / 37640 sec * 100). Single statements that cause 2% of load or more

should be analyzed further.

Note: Before analyzing expensive statements, the SAP system should run for several hours with a

typical workload.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SQL Requests

1

2 3

Another monitor used to identify expensive statements is the SQL Request Monitor. To access monitor,

start transaction ST04 and choose Detail Analysis Monitor → SQL Requests. This monitor provides a

view of the SQL Server sys.dm_exec_query_stats view. It can be used in addition to the SAP SQL

statistics monitor.

The dynamic management view sys.dm_exec_query_stats contains statistics about the performance of

SQL statements such as the number of logical reads, the CPU consumption, and the number of

executions. How long data is kept in sys.dm_exec_query_stats depends on how abundant memory is for

Microsoft SQL Server.

The records displayed in the SQL Request Monitor are sorted by the total amount of logical reads (1)

respectively buffer lookups per default; that is, the statement which has the most buffer lookups in total

is displayed at the top. The database load can now be calculated by the quotient of the logical reads of

one single statement and the total logical reads of the system.

The statistics can also be sorted by the total CPU time (2) or the total physical reads (3). Those

statements that cause 2% of load or more should be analyzed further. These are probably the same

statements as detected in the SAP SQL Statistics monitor.

By default the 50 statements with the highest database load are displayed. The number of statements

displayed can be changed in the Edit menu.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SQL Trace

1

2

3 45 67

The SQL trace tool can be used to analyze a single report or transaction that is known to have a high

database response time, for example, after having analyzed the Transaction Profile in the Global

Workload Monitor (ST03G).

To start, stop, and display the SQL trace, start transaction ST05 or choose Tools → ҏAdministration

→ ҏMonitor → ҏTraces → ҏPerformance Trace.

To display the time stamps and program names in the trace list, choose Display Detailed Trace List. All

statements that were sent from the SAP work processes to the database are displayed.

To identify identical statements, choose Trace List → Display Identical Selects (1). Identical statements

are probably caused by one statement being executed repeatedly. To directly access the corresponding

ABAP program line, choose Display Call Position in ABAP Program (2).

The Records column (3) shows the number of read or manipulated rows. The Return code (RC) column

(4) shows the result value of the database operation. The duration (execution time) of the statement is

shown in the Duration column (5). The time is specified as: seconds.milliseconds.microseconds

The Statement column (6) shows the statement executed on the database. The Operation column (7)

displays PREPARE, OPEN, FETCH as outlined in the “How SAP NetWeaver Uses SQL Server” unit.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SQL Server Profiler

The SQL Server Profiler is a graphical trace tool for monitoring events of an SQL Server instance. For

example, a database instance can be analyzed to detect statements that impair performance.

The SQL Server Profiler can be started by choosing Start → All Programs → Microsoft SQL Server

2005 → Performance Tools → SQL Server Profiler.

Use SQL Server Profiler to monitor only the events in which you are interested. If traces become too

large, they can be filtered based on the information required, so that only a subset of the event data is

collected. Monitoring too many events adds overhead to the server and the monitoring process.

For more details, see SQL Server Books Online.

In the example above, a statement is captured by the SQL Server Profiler and has been sent through the

DBSL to the database server using stored procedure sp_prepexec in order to prepare it and retrieve a

handle ID. The statement text is displayed in the lower part of the screen. This procedure is described in

more detail in the “How SAP NetWeaver Uses SQL Server” unit.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Too Many Statements

RDBMSData Cache

Procedure Cache

Memory

SAP Work Process

Tables Indexes

SQL Connections

WHILE ...

SELECT *

FROM MARA

WHERE ...

ENDWHILE.

SQL Trace

ST05

MARA

MARA_1

MARA_0SQL Server

Profiler Trace

Database

In this example, the same SELECT statement may be executed several times. If the conditions in the

WHERE clause do not change, the same data is read several times from the database.

To find this kind of duplication, you can run an SQL trace (transaction ST05) or use the SQL Server

Profiler. SQL trace (ST05) logs the communication between the SAP work processes and the database

by using specific filters, such as an SAP user. The SQL Server Profiler is used to filter for specific

events. It can be used to filter a certain host process ID such as a background work process.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Poorly Qualified Statements

High execution time + returning few records

If the runtime (duration) of the statement exceeds a given threshold value of 100 thousand

microseconds, it is highlighted in red in the ST05 Trace. If a statement returns few rows and has a long

execution time, the statement must be improved.

An inefficient statement can have several consequences:

• The database is kept busy processing many data pages.

• CPU load is increased on the database server.

• An SAP work process is blocked by the report and there are long wait times for other processes.

• Several pages are displaced from the database buffer pool.

• Performance can be harmed system-wide by expensive statements.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SQL Server Optimizer

Database

RDBMS

Data cache

Memory

SAP Work Process

Tables Indexes

MARA

MARA_1

MARA_0

SQL connections

SELECT *

FROM MARA

WHERE MANDT = 001

AND BISMT IN (...)

Optimizer

Explain:

Execution path

Used index

Table definition

...

Statistics

The SQL Server Optimizer is a cost-based optimizer that minimizes the number of pages to be read. It

estimates the costs for each index used and compares these to the cost of a table scan for each table to be

accessed.

For this cost estimation, the SQL Server Optimizer uses statistical information about the data

distribution, which is stored for each index in a statistics page.

Some common reasons for long execution times:

• No index exists and therefore the whole table is read sequentially in a full table scan.

• The index used is not very selective, so a large range has to be read in an index range scan.

• The SQL Server Optimizer re-uses the execution plan, which keeps an unsuitable strategy.

• The statement is badly formulated and selects much more data than is actually necessary.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Automatic Update Statistics

SQL Servers query optimizer uses statistical information to determine the optimal execution plan by

estimating the cost of using an index to evaluate the query. When an index is created, the query

optimizer automatically stores statistical information about the indexed columns. As the data in a

column changes, index and column statistics can become out-of-date and cause the query optimizer to

make non-optimal decisions on how to process a query. Therefore statistics need to be updated.

Several database options in Microsoft SQL Server update and create statistics automatically:

• AUTO_UPDATE_STATISTICS: The query optimizer automatically updates statistical information

periodically as the data in the tables changes. A statistics update is initiated whenever the statistics

used in a execution plan fail a test for current statistics. Almost always, statistical information is

updated when approximately 20 percent of the data rows has changed.

• AUTO_UPDATE_STATISTICS_ASYNC: A query that initiates an update of out-of-date statistics

must wait for those statistics to be updated before compiling and returning a result set. This can

cause unpredictable query response times. In Microsoft SQL Server 2005, this database option

provides asynchronous statistics updating.

• AUTO_CREATE_STATISTICS: The query optimizer automatically creates statistics for columns

without indexes that are used in a predicate.

Automatic statistics generation can be disabled for a particular column or index using stored procedure

sp_autostats. Note: This is recommended for tables VBDATA, VBMOD, and VBHDR.

Note: Index statistics only affect the optimizer decisions. If you see the best index is already used, it

makes no sense to update statistics. You should just think if a better index can be defined.

SAP strongly recommends setting database options "auto create statistics", "auto update statistics" and

"auto update statistics async " to ON. These database options for the <SID>-database can be set by

executing alter database <SID> set <database option> on.

The Database Allocation Monitor (transaction DB02) shows, among other information, the database

options set for a particular database.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Getting More Information

Information from SAP Data Dictionary:• Table fields

• Indexes and index fields

Explanation of Query:• Which index is used

• Access method used

• JOIN sequence

Jump to ABAP source:• Show ABAP statement

SQL Statement:• Show SQL statement text

Detailed information about a single statement can be displayed in the introduced monitors, such as the

SQL Trace tool (ST05), the SAP SQL Statistics (ST04) and the SQL Requests (ST04):

• Display Details respectively SQL Statements shows:

- The complete statement

- The parameter values and types used

• DDIC Information shows:

- The table structure according to the SAP Data Dictionary (field definitions)

- The indexes defined on the table(s) used, as written in the SAP Data Dictionary

• Explain shows the Optimizer decisions (for the time of the explanation). That is, the indexes used

and the JOIN sequence.

• Display Call Position in ABAP Program respectively ABAP Code shows the related ABAP

statement.

When the SQL Server Profiler is used to analyze events, SQL Server commands must be executed to

display information such as the execution plan:

• To view the statistics for a table, use command DBCC SHOW_STATISTICS.

• To view the execution plan of a statement, set the SET SHOWPLAN_TEXT ON property in a query

window to display the execution plan information for each query in text.

For the detailed description of the SQL Server commands, see SQL Server Books Online.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Understanding the Execution Plan

1

23

5

4

Understanding execution plans plays a vital role when fine-tuning a query. Execution plan output shows

information about how the query is processed by Microsoft SQL Server, that is, what tables and indexes

are used and the strategy that is carried out to process a query.

The output of the optimizer explanation consists of the complete statement (1) followed by the explain

tree (2). In the explain tree, the root node shows the statement type (for example, SELECT) (3). Except

the root node, each following node represents a working step necessary for the statement execution. The

execution works from the bottom to the top to produce the results for the statement. Everything

belonging to the same node has the same indentation level.

Below the statement type, the strategy used for this step is displayed followed by the parameters for the

strategy (for example, filter values, index names, index fields, operators, and values) (4). The most

common strategies are:

• Index seek

• Index scan

• Clustered index seek and scan

• Joins – nested loop, hash and merge

For every strategy the estimated number of rows returned and the estimated cost for I/O and CPU

resources (these numbers have a virtual unit and are only used for comparing different execution plans)

are displayed (5).

A detailed description on how to analyze an execution plan is given in SQL Server Books Online.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Getting Table and Index Information

To display detailed information on a table and its indexes, use the database allocation monitor

(transaction DB02) and choose Detail analysis, then enter the table name. The table information is

displayed in different folders:

• General: This folder displays size information about the table. Total rows displays the current

number of rows in the table (see 1). Row modification counter shows the number of changed rows

since the last update statistics (see 2). An update statistics operation resets this counter to 0.

• Indexes: This folder displays all indexes including their names, their columns and the last update

statistics date. The index depth shows the longest path from the root page to a leaf page of the index

(see 4).

- Note: A clustered index always has one level less than the same index created as a non- clustered

index because the data pages are stored at the lowest level of the index. See the “SQL Server

Architecture” unit for details about different index types.

- If the database option Auto create statistics is set to ON (see 3), column statistics are created

automatically by SQL Server. These automatically created histograms have a name starting with

_WA_Sys_ (see 7).

• Fields: This folder displays information about the table columns and their data types.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Index Statistics

To display the statistical information stored in the SAP system for each index, start transaction DB02

and choose Detailed analysis, then enter the table name. In the screen displayed, select the requested

index and choose Show statistics. Alternatively you can execute command DBCC

SHOW_STATISTICS in a query window of the SQL Server Management Studio.

Statistics maintained on each table in SQL Server help the optimizer in cost-based decision making and

include among others:

• The date of last update of these statistics

• Number of rows in the table

• Number of rows sampled for the statistics

• All Density value for each column and column combination – This value is calculated by dividing 1

by the number of different values or value combinations for the field or fields. The index is best if

the combined useable columns have a very low density and only a few duplicates exist for a given

combination.

• Average key length

When statistics are created, the Database Engine sorts the values of the columns on which the statistics

are being built and creates a histogram based on up to 200 of these values, separated by intervals. This is

shown in the section below for the values of the first index column (histogram). The histogram provides

statistical information about the frequency of any single value in the table. Statistics are comprised in

the following information:

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


• RANGE_HI_KEY: Upper bound value of a histogram range (step).

• …

• …

• RANGE_ROWS: Number of rows from the sample that fall within the range, excluding the upper

bound.

• EQ_ROWS: Number of rows from the sample that are equal in value to the upper bound of the

histogram step.

• DISTINCT_RANGE_ROWS: Number of distinct values within a range, excluding the upper bound.

• AVG_RANGE_ROWS: Average number of duplicate values within a histogram step, excluding the

upper bound (RANGE_ROWS / DISTINCT_RANGE_ROWS for DISTINCT_RANGE_ROWS >

0).

• The value RANGE_ROWS is equal to AVG_RANGE_ROWS multiplied by

DISTINCT_RANGE_ROWS.

Statistics on indexes are automatically created whenever a new index is built.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

How to Tune an Expensive SQL Statement

Poor

statement

DDIC

info

SQL

ExplainWhere-

used list

Create or change

secondary index

in DDIC + DB

Update

statistics

Re-code

Yes

Yes

Yes

No

No

No

Re-code by

specifying an

optimizer hint

Yes

Statistics

page

Switch on

auto updstats

Yes

No

Inefficient

coding?

Is there a

suitable

index?

Good

Optimizer

decision?

Index

statistics

up to

date?

Autoupdate

stats on?

If you were to tune this expensive statement, you might consider creating a secondary index. However,

creating a secondary index does not solve all problems, in fact, it may have its own consequences. For

example, if you increase the number of indexes on a table, the duration of INSERTS, DELETES and

UPDATES also increases. A possible solution would be to change an existing index, for examle, by

adding an additional field.

Now you must determine how to create a useful index.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

” A good index

Is used in many statements

Is used often

Contains only selective fields

Is small and possibly covered

How to Create a Useful Index

If an index is used often, the database request time and the database load are reduced.

A selective field has:

• Many different values in the real data in the table

• A small number of data rows with identical values, compared to the total number of rows within the

table

If an index is small, many index rows fit on one index page. This is especially useful for index row

scans that may be triggered, for example, by comparison operators.

A covered index contains all selected fields plus all the fields in the WHERE clause. It prevents

accesses to the data pages. Consider using included columns in an index. See the “SQL Server

Architecture” unit.

Before you make changes to SAP objects, such as create an additional index or change an existing

index, search for SAP Notes to determine if the problem is known. If it is not known, consult SAP

Support.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

How to Determine Selective Field Combination

Almost 100% selectivity is fine

To obtain the current selectivity of each combination of columns for a table, start transaction DB02 and

choose Detail analysis → ҏTable name →ҏSelectivity. You can select any columns that can be indexed,

other than image or text fields.

From the screen displayed, you can check the following:

• Number of distinct entries for your selection

• Total number of rows in the table

• Selectivity (in percent)

If you enter a combination of fields, you cannot tell if only one of the given fields is selective or if the

combination gives high selectivity. Therefore, you should always check the sub-selections.

A more accurate (but more costly) way to get the selectivity of field combinations is to use the density

function. The result is weighted according to the number of occurrences for each distinct value.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

How to Create an Index

3

1 2

Always use the SAP Data Dictionary (transaction SE11) to maintain indexes. From the initial SE11

screen, choose Goto → Indexes to access the maintenance screen for indexes. A list of all the table

indexes that exist in the ABAP Dictionary is displayed. The following functions are offered in the next

screen:

• Create database index: Create a secondary index or the primary index of a transparent table in the

database (1).

• Delete database index: Delete a secondary index of a transparent table in the database. The primary

index of a transparent table created in the database cannot be deleted as long as the table still exists in

the database (2)

• Change database index: Select one index and click Enter to go to the maintenance screen of an index

(3).

For more details, see the SAP NetWeaver documentation.

Note: Creating an index with included columns is not (yet) supported by the SAP Data Dictionary. They

can only be created using transact-SQL command CREATE INDEX. See SQL Server Books Online for

details on the syntax. See the “SQL Server Architecture” unit for more information on included columns.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Optimizer Hints

RDBMS Memory

SAP Work Process

SQL connections

SELECT *

FROM MARA

WHERE MANDT = 001

Optimizer

Procedure cache

execution plan:

clustered index seekSAP Work

Process

SELECT *

FROM MARA

WHERE MANDT = 002

Execution plan is reused.

High execution time because

of inappropriate strategy

Optimizer hints can be used to force the query optimizer to use a specified strategy when processing a

query. Optimizer hints can be set in the ABAP. See SAP Notes 129385 and 13338. Appending the

following hint, for example, to a SELECT in the ABAP has the effect that Microsoft SQL Server creates

a new execution plan every time the SELECT is executed:

%_hints mssqlnt '&REPARSE&'

This makes sense when the selectivity of an individual or a few SELECTs is extremely different.

Because the SQL Server query optimizer typically selects the best execution plan for a query, hints

should only be set in close cooperation with SAP support.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Expensive SQL Statements: Summary

” An expensive SQL statement needs many reads and can

cause system-wide performance problems

” Analyzing an expensive SQL statement

Transaction Profile in ST03G → high database request time

SQL Trace → statements with long response times

SAP SQL Statistics → high execution times

SQL Requests → high number of logical reads

Process overview → report and table name

Where used list → table

” Tuning an expensive SQL statement

Create/change an index

Check if Auto update statistics is on

Understand the DB Optimizer

Rewrite poor coding

Use optimizer hints

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Application Problems: Summary

LockwaitsPoorly

qualified

statements

Poor configuration

Poor database

configuration

Poor hardware

configuration


due to:

Exclusive

lockwaits,

Blocking

lockstats

SQL Profiler,

SQL TraceSAP SQL

Statistics

SQL Trace,

SQL Requests

Too many

unnecessary

statements


Application problems typically involve either lock contention or inefficient SQL coding.

SQL problems are normally caused by statements that are being executed more frequently than

necessary or individual statements that are very expensive.

A statement can be expensive because of poor WHERE clauses, missing indexes, or poor optimizer

decisions due to outdated statistics.

If you determine that both the database configuration and the application have been adequately tuned

and you still have performance problems, SAP recommends that you consult your hardware partner

about additional hardware. This course does not cover a hardware analysis.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Detect an Expensive Statement: Unit Overview Diagram


Lesson 1: Detect an Expensive Statement

Lesson 2: Monitor an SQL Server Instance without ABAP Stack

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Detect an Expensive Statement: Lesson Objectives


” Identify a performance problem using the SQL trace

” Apply an appropriate solution for the performance

problem

” Check the result

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Detect an Expensive Statement: Business Example

” In your productive SAP system, you have identified

a long-running SAP transaction with a high

database response time. As a member of the SAP

project team, you trace the transaction using the

SQL trace tool ST05. After identifying the problem,

you solve it and check the result.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Detect an Expensive Statement: Lesson Summary


” Identify a performance problem using the SQL trace

” Apply an appropriate solution for the performance

problem

” Check the result

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Monitor an SQL Server Instance without ABAP Stack: Unit Overview Diagram


Lesson 1: Detect an Expensive Statement

Lesson 2: Monitor an SQL Server Instance without ABAP Stack

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Monitor an SQL Server Instance without ABAP Stack: Lesson Objectives


” Create a DBCON entry for a remote database

connection

” Monitor a remote Microsoft SQL Server instance

without SAP system

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Monitor an SQL Server Instance without ABAP Stack: Business Example

” Your SAP Enterprise Portal that runs on a Microsoft

SQL Server 2005 reports some problems. To be able

to monitor this server, you want to create a

connection by adding an entry in the DBCON table.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Monitor an SQL Server Instance without ABAP Stack: Lesson Summary


” Create a DBCON entry for a remote database

connection

” Monitor a remote Microsoft SQL Server instance

without SAP system

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Performance Monitoring and Tuning: Unit Summary


” Analyze the performance of Microsoft SQL Server

” Identify the source of database performance

problems

” Find solutions to the performance problems

detected

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


Exercises

Unit: Performance Monitoring and Tuning

Topic: Detecting an Expensive Statement

• At the conclusion of this exercise, you will be able to:

• Identify a performance problem using the SQL trace

• Apply an appropriate solution for the performance problem

• Check the result

In your productive SAP system you have identified a long running SAP

transaction, with a long database response time. As a member of the SAP

project team, you trace the transaction using the SQL trace tool ST05.

After having identified the problem, you solve it and check the result.

1 SQL Trace

1-1 Report ZADM520PERF##, where ## is the group number you have been assigned

to, selects a record from different application tables. Start ST05 to turn on the trace,

execute report ZADM520PERF## using transaction SE38. In ST05, turn off the

trace, and display the trace results.

Look for long access times, that is, accesses that are marked red in the trace list.

Check for the slow statement for the OPEN operation. Which index was used for

the slow statement?

1-2 Apply the appropriate change to speed up the execution. Repeat the steps above and

check the results.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y



Topic: Monitoring an SQL Server Instance without ABAP Stack


• Create a DBCON entry for a remote database connection

• Monitor a remote SQL Server instance without SAP system

Your Enterprise Portal, which runs on a Microsoft SQL Server 2005

database, reports some database problems. To be able to monitor this

server, you want to use the SAP SQL Server Performance Monitor

(ST04) and have to create a connection by adding an entry in the DBCON

table.

2 Monitor a non-local SQL Server Instance using the SAP SQL Server Performance Monitor

(ST04)

2-1 If you want to monitor a non-local SQL Server Instance, use the database multi-

connect. First define a DBCON connection. Suppose the SQL Server instance you

want to monitor is named instance T## and the database you want to connect to is

T##, where ## corresponds to the group you have been assigned to.

Start ST04, the SAP SQL Server Performance Monitor, and click Change

connection data. Then choose Goto → Maintain DBCON in the menu.

Note: The Change connection data button is available only on the entry screen of

the database monitor transaction, not on any subsequent screen.

In the Maintain DBCON screen, create a new DBCON entry and fill in the fields

required.

Hint: If you need help, go to the Application Help in the menu. The documentation

can be found in a document titled "Monitoring Remote SQL Server Databases."

2-2 After having created the DBCON entries, create the T-SQL objects on your target

database T##, where ## corresponds to the group you have been assigned to. In the

Maintain and set monitor multi-connect data screen select Goto → Create TSQL

objects.

2-3 After successfully having created the TSQL objects, you can apply these settings to

the local session. Now you are able to monitor SQL Server instance T##.

In the SQL Server Performance Monitor (ST04) main screen, check which trace

flags are set.

Also check the developer trace files (ST11) and search for the DBCON connection.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


Solutions


Topic: Application Problems

1 SQL Trace

1-1 Report ZADM520PERFxx, where xx is the group number you have been assigned

to, selects a record from different application tables. Call ST05 to turn on the trace,

execute report ZADM520PERFxx using transaction SE38. In ST05, turn off the

trace, and display the trace results by choosing button Display Trace.

Look for high access times, i.e. accesses which are marked red in the trace list. In

the different reports, the following application tables are accessed and the following

solution must be applied:

Report Access Solution

ZADM520PERF00 table COEP using OBJNR Create secondary index

on OBJNR

ZADM520PERF01 Table GLPCA using

SGTXT

Create secondary index

on SGTXT


MATNR


on MATNR


AUBEL


on AUBEL

ZADM520PERF04 Table SCPRSVALS using

TABLENAME


on TABLENAME

ZADM520PERF05 Table OCSCMPLOBJ

using OBJ_NAME


on OBJ_NAME

ZADM520PERF06 Table SEOSUBCODF

using SCONAME


on SCONAME

Display the trace by choosing button Display Trace in transaction ST05. Position

your cursor on the slow statement, and choose Explain.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


1-2 Performance can be improved by creating a secondary index on the column given

above.

Use transaction SE11. Display the affected table. Choose Button Indexes .., then

button Create -> Create Index. Enter an ID for the new index, e.g. Z. In the

following screen give a short description and enter the required index field(s). Then

press button Save. If necessary create a new workbench request or use request

MS9K900004. Afterwards the index needs to be created on the database. To do so,

press button Activate then choose Utilities -> Database Utility. Press button Create

Database Index.

Trace the program again and check if the runtime has improved and the new index

is used.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


2. Monitor a non-local SQL Server Instance using the SAP SQL Server Performance Monitor

(ST04)

2-1 If you want to monitor a non-local SQL Server Instance, you can use the database

multi-connect. Define a DBCON connection first. Suppose the SQL Server instance

you want to monitor is instance Txx and the database you want to connect to is Txx,

where xx corresponds to the group you have been assigned to.

Call the SAP SQL Server Performance Monitor (ST04) and click button Change

connection data. Then choose Goto -> Maintain DBCON in the menu. Note, that

the Change connection data button is only available on the entry screen of your

database monitor transaction, not on any subsequent screen. In the Maintain

DBCON screen, create a new DBCON entry and fill in the fields required:

Connection name:

Enter any name, e.g. your group name (xx). This is the name by which your remote

database connection is identified.

Database system:

This field must display MSS.

DB server (instance):

Enter the name of the target SQL Server instance that you want to monitor from

your local SAP system, i.e. <servername>\Txx, where xx is the group number you

have been assigned to.

Database login:

SQL Server login with System Administrator privileges, that is this login should be

member of the sysadmin fixed server role on the target SQL Server instance. If such

a login does not exist, you have to create it on the target SQL Server instance. The

SAP multi-connect mechanism allows both integrated security logins and the use of

SQL Server authentication. For security reasons, we highly recommend to use

integrated security (Windows authentication). Use Windows security. Therefore

leave this field empty.

Password / Re-enter password:

For integrated security, leave these fields empty.

Database name:

Enter the name of the target database, i.e. Txx.

Database user:

For remote database monitoring, leave this field empty. This will ensure that the

database connection has dbo privilege.

Object source schema:

This database schema contains all SAP database monitor objects, for example,

stored procedures, user defined functions and tables. They implement the low-level

database monitor functions.

Enter the txx (lower case) of the target database.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


Keep connection open:

Leave this field empty.

Other parameters:

Leave this field empty.

Choose button Save. The status bar shows message ‘DBCON entry <dbconname>

saved’.

Now mark your newly created entry and press button Select entry, then go back. In

the Maintain and set monitor multi-connect data screen you should see your newly

created DBCON entry. If you click button Apply to local session, active error

message shows SQL error 2812: Could not find stored procedure 't01.sap_tf_versi

on'. You now need to create the necessary objects on your target database.

2-2 After having created the DBCON entries, create the T-SQL objects on your target

database Txx, where xx corresponds to the group you have been assigned to. In the

Maintain and set monitor multi-connect data screen select Goto -> Create TSQL

objects.

The dialog box Create SAP T-SQL Object with the following sections appears:

Connection prerequisites:

DB Connection:

Displays the connection name, which corresponds to the multi-connect record in

table DBCON. This is the connection name you have given in 2.1.

Check:

This button is either followed by a green check mark or by a red failure symbol.

The red failure symbol appears, if an illegal object source schema is specified. For

example, it is not allowed to overwrite the T-SQL objects of an older SAP release.

For troubleshooting, refer to the message area at the bottom of the dialog box.

Object source schema:

Schema name:

Allows you to create the object source schema and provides it with the required

privileges. Create the schema txx (lower case), where xx is the group you have been

assigned to. If the schema already exists, the button is grayed out.

SAP TSQL objects:

Existing version:

If the necessary T-SQL remote database monitoring objects and scripts already

exist on the target SQL Server database, this field displays the version of those

objects.

The button allows you to (re)create the objects. It is enabled, if the connection

prerequisites are fulfilled and if the object source schema exists.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


The radio buttons on the right allow you to choose whether you want to install the

SAP T-SQL objects without enabling any SQL Agent jobs (Minimum set) or if you

want to install the objects and enable the jobs (Standard set). Choose Standard set

and press button Create objects.

Last message:

This area displays the result of the last action and helps you to troubleshoot

problems.

The following screen now displays the objects which have been created.

2-3 After successfully having created the T-SQL objects you can apply these settings to

the local session. Now you are able to monitor SQL Server named instance Txx.

In the SQL Server Performance Monitor (ST04) main screen you should see

Connected to: <servername> Txx <connection name>

Now press button Refresh.

If you have successfully set trace flag 1204 in exercise 1.1 in Unit 1: SQL Server

Architecture, you should see this trace flag displayed in the Overview folder.

The developer trace file for the work process which has performed ST04, shows an

entry like:

B Tue Jun 27 13:58:43 2006

B create_con (con_name=<connection name>)

B New connection 1 created

B Connect to <connection name> as sa with MSSQL_SERVER=<servername>

MSSQL_DBNAME=Txx MSSQL_SCHEMA=dbo OBJECT_SOURCE=txx

C dbmssslib.dll patch info

C patchlevel 0

C patchno 60

C patchcomment MSSQL: dbdd_get_size, SpaceUsedForTable(view) (951027)

C Network connection used from <sourceserver> to <servername> using

tcp:<servername>

C Connected to db server : [<servername>] server_used : [tcp:<servername>],

dbname: Txx, dbuser: dbo

C pn_id:<servername>_TxxDBO_MS9

B Connection 1 opened (DBSL handle 1)

B Wp Hdl ConName ConId ConState TX PRM RCT TIM MAX OPT

Date Time DBHost

B 000 000 R/3 000000000 ACTIVE NO YES NO 000 255 255

20060624 135954 <sourcserver>

B 000 001 <connectionname> 000000893 ACTIVE NO NO NO 004

255 255 20060627 135843 <servername>

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Backup

Contents:

Prevention of Data Loss

Backup Categories

Perform and Verify Backups

Backup Strategies

High Availability Solutions

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Backup: Unit Objectives


” Describe and perform the different backup

categories that are supported under SQL Server

using the DBA Planning Calendar and SQL Server

tools

” Explain the technical implementation of the

described backup categories and name the involved

system tables

” Verify the backup

” Define a suitable backup or high-availability

strategy

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Backup: Course Overview Diagram








Unit 8 Conclusion

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Backup: Business Example

” Your company runs SAP ERP 2005 based on

Microsoft SQL Server 2005. You need to become

familiar with the different backup categories under

Microsoft SQL Server in order to define a backup

strategy that is suitable for your company’s needs.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Importance of Database Backup

To prevent data loss, a valid backup is necessary

Data

loss

Logical errors(Such as a corruption)

External factors(Such as fire or water

damage)

Physical errors(Such as a media failure)

User errors(Such as a faulty transport)

External factors, physical errors, and logical errors can all lead to data loss and system downtime.

An effective backup strategy and recovery plan is essential in minimizing system downtime and data

loss.

To ensure the availability of your SAP system, the backup strategy developed by your database

administrator must be carefully tested. Testing your strategy by restoring a set of backups and

recovering your database prepares you to respond effectively to a disaster.

Additionally, backups of a database are useful for routine purposes, such as copying a database from one

server to another and setting up database mirroring.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Prevention: Physical Separation of data

<SID> data files <SID> transaction

Log file(s)

SAP, Microsoft

SQL Server

and Windows

executables

A well-designed disk layout ensures minimal impact of data loss due to hardware errors, as well as well-

performing system operation.

If the <SID> data files are lost, a restore and recovery is necessary. To be able to restore to the point

right before the failure, both <SID> data and log files should separated. In addition the Microsoft SQL

Server executables should reside on a separate volume.

Data separation is also discussed in the “Performance Monitoring And Tuning” unit.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Prevention: Redundancy

Reducing the risk of a restore or data loss by mirroring

Must be mirrored using

RAID5 to reduce the risk of

a restore

<SID>DATA1, ..., n

<SID>LOG

SAP directory

SQL Server directory

Page file

Database data files

Transaction Log files

executables

Must be mirrored using RAID1

to reduce the risk of a restore

Must be mirrored using RAID1

to reduce the risk of a restore

As part of a proper backup strategy, the consequences of losing specific database files must be

considered and appropriate measures to reduce these risks must be taken. The <SID> database data files,

transaction log files, the Microsoft SQL Server executables, and SAP executables must be mirrored

using the RAID technology. See the “Performance Monitoring and Tuning” unit for details. Refer also

to the SAP Installation Guides under service.sap.com/instguides.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Backup Categories

” Data Backup

” Transaction Log Backup

” Differential Backup

” Full Installation Backup

<SID>

<SID>

<SID>

msdbmaster

Microsoft SQL Server supports the following backups:

• Data backups

• Differential backups

• Transaction log backups (in the full and bulk-logged recovery models)

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Data Backup

Copy all used data pages to the backup media

Data

Andre Vasser Hil Frenzen

X0 X1 X2 X3 X4 X5 X6 X7

Kojak MagnumDerrick Marple

X8 X9 X10 X11 X12 X13 X14 X15

Landis Wolf Wang Kerber Kania Thomas Merdes

X16 X17 X18 X19 X20 X21 X22 X23

Mozart Bach Strauss Wagner Beeth.

X24 X25 X26 X27 X28 X29 X30 X31

1

Copy all used log pages to the backup media

Set the timestamp of the backup to the time

when the backup has finished

Transaction Log

begin update begin insert commit chkp insert rollback

LSN0 LSN1 LSN2 LSN3 LSN4 LSN5 LSN6 LSN7

delete




2

3

A data backup includes all of the data in a specific database or set of filegroups or files. Microsoft SQL

Server supports full, partial, and file backups.

In a full backup, formally known as full database backup, all user-defined objects, system tables and

data of one database are copied to a backup medium. The full database backup is done while the

database is online and thus has a slight performance impact. Therefore the database should be backed up

at times when the workload is minimal.

Operations that cannot run during a database or transaction log backup include:

• File management operations such as the ALTER DATABASE statement with either the ADD FILE

or REMOVE FILE options.

• Shrink database or shrink file operations. This includes auto-shrink operations.

In addition to backing up the data pages, the transaction log is stored. Restoring the database from this

backup means that the status of the time when the backup of the database ended is reached. This backup

includes transactions that were performed during the backup.

The transaction log is not truncated when you perform a full backup.

The partial backup stores a specific filegroup, the file backup stores specific database files. These

backup types are not covered in this course. Please refer to SQL Server Books Online for details.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Transaction Log Backup

Copy all used log pages to the backup media

begin1 update begin2 insert commit2 chkp insert begin3


delete dump commit1 chkp insert insert delete delete


insert



1

Transaction Log

Truncate the inactive portion of the transaction log





insert



2

Transaction Log

When the transaction log is backed up, all used pages, from the transaction log of an individual

database, which were not backed up in a previous log backup, are backed up (1). Next the transaction

log is truncated, that is, the inactive part is deleted (2).

By creating transaction log backups, which are also known as log backups, a database can be restored

to any point in time contained within the sequence of transaction logs, right up to the point of failure.

When creating a transaction log backup, the starting point of the backup is where the previous

transaction log backup ended (if a transaction log backup has been created). In this example, it begins

with the log sequence number 0, because no transaction log backup has been created since the full

database backup. A subsequent transaction log backup would start with log sequence number 17.

Although part of the transaction log is backed up with a database backup, this is not taken into account

for the transaction log backup.

The transaction log cannot be backed up, if the recovery model is set to simple.

A transaction log backup can only be created after a preceding full data or a differential backup. In

Microsoft SQL Server 2005, you can back up the log while a full backup is running.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Truncating the Transaction Log

Transaction Log

Start of logical log

unused

End of logical log

Virtual Log 1 Virtual Log 2 Virtual Log 3 Virtual Log 4

MinLSN

Determine the

MinLSN before the

Transaction Log is

truncated

1

Transaction Log

Start of logical log

unused

End of logical log

Virtual Log 1 Virtual Log 2 Virtual Log 3 Virtual Log 4

2

Truncate the log

before the start of

the Virtual Log

containing the

MinLSN

Virtual Log 5

Virtual Log 5

MinLSN

If log records were never deleted from the transaction log, the log would keep growing until it filled all

the available space on the disks holding the log file(s). Therefore old log records that are no longer

needed for recovering or restoring a database must be deleted to make space for new log records. The

process of deleting these log records is known as truncating the log.

The active part of the transaction log can never be truncated. The active part of the log is needed to

recover the database at any time and to roll back transactions. It must always be present in the database.

If the server fails, the database must be recovered when SQL Server is restarted. The record at the start

of the active portion of the log is identified by the minimum recovery log sequence number (MinLSN).

See also the “SQL Server Architecture” unit.

Transaction logs are divided internally into sections known as virtual log files. Virtual log files are the

unit of truncation. When a transaction log is truncated, all log records before the start of the virtual log

file containing the MinLSN are deleted. The part of virtual log 4 beyond the end of the logical file has

never been used.

Truncating does not mean physically deleting. It simply marks the virtual log file as inactive. Truncation

does not reduce the size of a physical log file. Instead, it reduces the size of the logical log file and frees

disk space for reuse.

When the unused space at the end of the last virtual log is used up, the logging of the transactions starts

again at the beginning of the first virtual log.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Recovery Models

Transaction Log

Transaction Log

BCM

303

Begin Tran2

Insert

MARA ….

304

Create index

Page x

Tran1

305

Update

A002 set ...

Tran2

306

Commit

Tran1

307

Delete A001

Where ...

Tran2

308

Checkpoint

302

Begin Tran1

Create index

ZMARA_1 ...

301

Insert

MARD …

Tran3

Full

Bulked_logged

303

Begin Tran2

Insert

MARA ….

304 305

Update

A002 set ...

Tran2

306

Commit

Tran1

307

Delete A001

Where ...

Tran2

308

Checkpoint

302

Begin Tran1

Create index

ZMARA_1 ...

301

Insert

MARD …

Tran3

303

Begin Tran2

Insert

MARA ….

304 305

Update

A002 set ...

Tran2

306

Commit

Tran1

307

Delete A001

Where ...

Tran2

308

Checkpoint

302

Begin Tran1

Create index

ZMARA_1 ...

301

Insert

MARD …

Tran3

Simple

Extent x

Transaction Log

In Microsoft SQL Server, you can use predefined recovery models to support planning your backup and

recovery strategy. Recovery models offer different levels of system performance and data security

requirements.

Microsoft SQL Server provides the following recovery models:

• Full: Full Recovery provides the ability to recover the database to the point of failure or to a specific

point in time. All operations, including bulk operations such as CREATE INDEX, and bulk loading

data, are fully logged in the transaction log. Every page of the newly created index tree gets written

to the transaction log. When creating a clustered index the data pages will also be written to the log.

The transaction log is truncated only by a transaction log backup.

• Bulk logged: Bulk Logged Recovery provides protection against media failure combined with the

best performance and minimal log space usage. Extents changed by bulk load operations such as

CREATE INDEX are marked in the Bulk Changed Map (BCM), but not logged. All other database

operations are fully logged. When the transaction log is backed up, both the transaction log data and

the marked extents are backed up. Log backups generated can only be completely restored again.

• Simple: Simple Recovery requires the least administration. In this model, data is recoverable only to

the most recent full database or differential backup. Transaction log backups are not used, and

minimal transaction log space is used. Bulk inserts and the creation of new indexes are not logged. A

log truncation occurs every time a checkpoint is processed.

You can set the recovery models for each database using the Database Property in the SQL Server

Management Studio or the ALTER DATABASE statement. See SQL Server Books Online for more

details.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


…

…

Check to see which model is active, using the DATABASEPROPERTYEX function, the SAP Database

Allocation Monitor (transaction DB02) or the SQL Server Management Studio. In a productive SAP

system, we recommend setting the Full Recovery model for the SAP database. Only in exceptional

cases, can the Full Recovery model be changed to bulk logged. These cases are outlined in the “Regular

Maintenance and Error Handling” unit.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Differential Database Backup

Data

Copy all modified extents since the last

full backup to the backup media2

Copy all used log pages

to the backup media

Set the timestamp of the backup to the time

when the backup has finished

begin update begin insert commit chkp insert rollback


delete




3

4

Read the DCM pages to determine

which extents have been changed

since the last full backup

1DCM

DCMDCM

Transaction Log

Transaction Log

Andre Vasser Schu

X0 X1 X2 X3 X4 X5 X6

Kojak Rex Derrick Marple

X7 X8 X9 X10 X11 X12 X13

Dilg Wolf Wang Kerber Kania Thom

X14 X15 X16 X17 X18 X19 X20

A full backup can be supplemented by differential database backups that record only the changes made

to the database since the last full database backup. Each subsequent differential database backup records

all the changes made to a database after the last full database backup. If a full backup is created,

followed by multiple differential database backups, only the full backup and the last differential

database backup created must be restored.

Differential backups are used primarily in heavily used systems where a failed database must be brought

up as quickly as possible. Differential backups are smaller than full backups, so a restore from a

differential backup takes less time, because only the extents that contain modifications are restored.

These extents are recorded in the Differential Changed Map (DCM).

During a differential backup, Microsoft SQL Server backs up the transaction log to produce a consistent

database when the database is restored.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Full Installation Backup

Directory Files

X:\<SID>DATA1 Primary data file

X:\<SID>DATA2 Secondary data file

X:\<SID>DATA3 Secondary data file

Y:\<SID>LOG1 Transaction log file

Z:\Tempdb data and log files of the tempdb

C:\Program Files\Microsoft SQL Server\90\

COM application programming interfaces

Tools tools such as Books Online

C:\Program Files\Microsoft SQL Server\MSSQL.1\

Backup Default Backup directory

Binn MS SQL Server executables

Data System and sample database files

FTData Root directory of full-text catalog

Install Installation scripts and logs

Jobs Temporary job output files

LOG Errorlogs and Joblogs

D:\usr\sap\ SAP kernel, related files, SDM

\usr\sap\trans SAP Transport directory

D:\WINNT Windows System directory

Windows Registry

Copy all SAP, Microsoft

SQL Server and Windows

files to the backup media

1

Create a document

containing

the file structure

2

File System

Structure

Perform a full offline backup of the following to the backup media at least after installation and after

each SAP upgrade or Microsoft SQL Server upgrade:

• SAP file tree, the operating system files and the registry

• Database data files, transaction log files

• Microsoft SQL Server executables

• System database files

To ensure that the correct actions are performed in case of a system crash, you should create a document

containing the file structure of the whole system. This document must be available and understood by

the person who performs the database restore.

Regular file system backups are also important for storage of the software deployment manager (SDM),

which might be in use when running a Java-based SAP NetWeaver Application Server. The SDM

contains all deployments that are used outside the SAP database.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

How to Perform a Backup

regular

Mon Tue Wed Thu Fri Sat

Tue Wed Thu Fri Sat Sun

Mon Tue Wed Thu Fri Sat Sun

Mon

SunTue


Tue

unplanned

28 days

Backup

cycle

DBA Planning Calendar

DB13 or DB13C

SQL Server

Management Studio

Query Editor

Backups can be performed in the following ways:

• Using the DBA Planning Calendar (transaction DB13) or the central DBA Planning Calendar

(transaction DB13C)

• On the database level, using the SQL Server Management Studio

• On the database level, using the transact-SQL statement BACKUP

Other backup tools can also be used, but are not covered in this course.

Course TADM10, SAP Web AS Implementation and Operation I, provides a description of how to use

the DBA Planning Calendar.

Do not use Windows Backup to perform backups of the SAP database. Windows Backup should be

used to perform a complete offline system backup.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Backup Devices

Backup on local

or network disk device

Parallel backup on

more than one tape

Single backup on tapeR3DUMP0

R3DUMP0

R3DUMP1

R3DUMP2

Backup with third-party

software using named pipes Third-party

software

Windows

Backup

TAPE

TAPE

DISK

PIPE

Database X

You can use several different backup devices for a Microsoft SQL Server backup:

• One or more tape backup devices (for example, devices R3DUMP0, R3DUMP1, and so on, created

during the installation of the SAP system)

• Disk device (local or network) or network backup is possible, but SQL Server must run under a

domain user.

• Named pipe device, used by third-party software

For small SAP databases (up to around 300 GB), backups should be performed on a single tape device,

for example, a DLT tape.

Larger SAP databases can be backed up using one device and several tapes, written sequentially. If more

than one tape device is available (directly connected to the computer), tapes can be written in parallel

onto these devices. A parallel backup is recommended if the time frame is small.

Backup to tape, whether to a single tape or to multiple tapes using the sequential or parallel backup

procedure, is supported by the DBA Planning Calendar.

To manage the backup of the SAP database into a disk backup device, use SQL Server Backup.

Afterwards, use Windows Backup to back up the files onto a backup media. For this type of database

backup, use Windows Backup to restore the database backup file on disk, then use the database restore

facility with the backup file. The advantage of this method is that the backup to disk is quite fast and

another computer may then be used to perform the Windows Backup.

Third-party software can also be used to perform backups. Data is transferred using named pipes. Third-

party software can also be used to back up to tape devices located on a different computer than the one

where Microsoft SQL Server is installed.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

DBA Planning Calendar - Concept

SQL Server AgentLogs (msdb

Tables, SAP Tables)

SAP Layer

Database

Layer

DB Interface

To create a backup job, the DBA Planning Calendar (transaction DB13 or DB13C) issues an SQL

command, which defines and schedules a job using the SQL Server Agent. These jobs call stored

procedures <schema>.sap_backup_databases, <schema>. sap_backup_diff_databases and <schema>.

sap_backup_log to create a full backup, a differential backup, and a transaction log backup.

A job created by the DBA Planning Calendar can be defined to run immediately or on a recurring

schedule, for example, once a week. Once you have created a job, you can view the job definition by

double-clicking the job name. The job definition is displayed in the Action Parameters folder. If the

requirements of an action change, you can modify the action by selecting its name and choosing Edit. If

the action is no longer needed, simply delete it by choosing Delete.

Each scheduled job to be executed by SQL Server Agent is stored in table sysjobs on database msdb.

Their names start with SAP CCMS and can be viewed using the SQL Server Management Studio.

The central DBA Planning Calendar (transaction DB13C) gives you a single point from which to

manage the following:

• Databases of different type and versions on remote SAP systems

• SAP systems of different releases

• Non-SAP databases

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Scheduling Database Backups

BACKUP

Transaction

log

BACKUP

Data files

The DBA Planning Calendar supports the following backups from the SAP NetWeaver system:

• Full database backup

• Differential database backup

• Transaction log backup

• User database backup

In addition, the DBA Planning Calendar can be used to schedule a database consistency check (DBCC

Check). This is described in more detail in the “Regular Maintenance and Error Handling” unit.

These actions can be scheduled to run on their own, once or repeatedly. Alternatively, they can be

scheduled to run in combination with other actions by choosing Pattern Setup. A pattern specifies a

combination of actions that are executed at predefined intervals and can be scheduled together. The

planning pattern in the DBA Planning Calendar lets you to schedule a database consistency check and a

full database backup together.

To schedule a single action, double-click the day and time on which you want a backup scheduled. In

the selection screens, make the following selections:

• the required action

• database(s) you want to back up

• one (or more) backup device

• the time the action has to start

• if needed, the recurrence of the action

For detailed information on how to use the DBA Planning Calendar, see the SAP Online Help.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Media Names

Database

R = <SID>

M = msdb

S = master

I = combination <SID> included

Type

D = database

L = trans. log

Tapecount

Device names

Number

01 - 31 =

day of

the

month+ = differential P = parallel

S = sequential

C = combination <SID> not included

O = other database

The media on which the backup is performed is identified by a label. This label identifies the contents

and indicates the type and day of the backup. The label is given automatically when backups are

scheduled using the DBA Planning Calendar.

The media label consists of five characters:

• The first character indicates the type of data on the media:

- R = SAP database <SID>

- S = master database

- M = msdb database

- O = Other database backup

- I = More than one database is backed up on the tape and the SAP database <SID> is included

- C = More than one database is backed up on the tape and the SAP database <SID> is not

- included

• The second character indicates the type of backup:

- D = Full database backup

- L = Transaction log backup

- + = Differential database backup

• The next two characters (numbers) indicate the day of the month.

• The last character on the label indicates whether it is a parallel or a sequential backup.

Note: Do not mix transaction log backups and full database backups on one media

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Media Names - Example

ID15S = One tape of a sequential (S) , full backup (D) of SAP, master, and msdb

databases (I) on day 15 of the month

RD05P = One tape of a parallel (P), full backup (D) of SAP database (R) on

day 5 of the month

ID15S

Stick label

on tape cartridge

Label all tapes used for backups. When creating a backup using SQL Server tools, type in a tape name

and stick a label with the same name on the tape medium.

The first tape label in this example is ID15S. Following the naming convention outlined, previously, this

label indicates a full backup of the SAP, master, and msdb databases, performed on the 15th day of the

month.

The second example is RD05P. This tape contains an SAP database backup. The backup was performed

on day 5 of the month. The letter “P” indicates a parallel backup was performed.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database and Log Backup Parameters

Full

Backup

Transaction

Log Backup Logmsdbmaster<SID>

For the first Backup onlyFor the last Backup only

For a full backup, use the following parameters:

• Tape unload Rewinds the tape after the backup. Set this for backups to tape devices.

• Init tape Overwrites existing backups if the expiration period is over and the media

name corresponds to the day the backup is performed.

• Verify Backup Checks backup to see if all data on the media is readable.

• Expiration period Set to 27 days.

For transaction log backups, set the following parameters as indicated:

• Unload tape Set for the last transaction log backup of the day stored on this tape

• Initialize tape Set for the first transaction log backup on the media when the media is

reused

• Verify Backup Set for all backups

• Expiration period Set to 27 days

When the Format tape parameter is used, the media name and all data on the media are overwritten, no

matter what the media retention or expiration period. Use Format tape only when a new medium is

used.

The Init tape parameter allows you to overwrite backups on media if the expiration period is in the past.

The media name is not overwritten and can be used for identifying the media.

…

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


…

Verify Backup executes transact-SQL command RESTORE VERIFYONLY on the chosen backup

medium after performing the backup. We recommend that you set this option for each backup

performed. It checks that the backup set is complete and that all volumes are readable. However,

RESTORE VERIFYONLY does not attempt to verify the structure of the data contained in the backup

volumes. If the backup is valid, SQL Server returns the message, “The backup set is valid.” This

message is displayed in a dialog box after double-clicking on the task. If it is not valid, you should

repeat the backup on a new medium.

For a detailed description of transact-SQL command RESTORE VERIFYONLY, see SQL Server Books

Online.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Backup using the SQL Server Management Studio

Options page

General page

To back up the database using the SQL Server Management Studio, select an SQL Server instance,

select the database, right-click and choose Task → Back Up. Select Full as the backup type.

A media set name must be specified using the SAP naming conventions explained earlier. A description

is optional. An expiration period must be set to prevent the media to be overwritten within 27 days.

Select the destination(s).

In the Options page, different options can be set. If you want to write to an existing backup medium,

choose Backup to the existing media set. This option is recommended if your backup medium is already

initialized with the media name and expiration period. Make sure to select Check media set name and

expiration period to prevent accidentally writing to the wrong backup medium. When the backup is

completed, you should verify the media integrity of the backup.

Do not select the Perform checksum checkbox. Selecting this option increases the workload, and

decreases the backup throughput of the backup operation. SAP recommends performing a consistency

check of the whole database at least once within a backup cycle. For details, see the “Database

Maintenance And Error Handling” unit.

The database can be backed up using the transact-SQL command BACKUP DATABASE, which is

described in detail in the SQL Server Books Online.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Log Backup Using the SQL Server Management Studio

General page

Options page

To back up the transaction log using the SQL Server Management Studio, choose an SQL Server

instance, select the database, right-click and choose Task → Back Up. Under Backup type, select

Transaction log. Select the destination.

A media set name must be specified. Use the SAP naming conventions explained earlier in this unit. A

description is optional. An expiration period must be set to prevent the media from being overwritten

within 27 days. Select the destination(s). In the example above, a parallel log backup is created to

backup devices R3DUMP4 and R3DUMP5.

In the Option page, different options can be set. If you want to write to an existing backup medium,

choose Backup to the existing media set. This option is recommended if your backup medium is already

initialized with the media name and expiration period. Make sure to select Check media set name and

expiration period to prevent accidentally writing to the wrong backup medium. When the backup is

completed, you should verify the media integrity of the backup.

Because the inactive portion of the transaction log must be removed, you must select Truncate the

transaction log. This option is activated only if you specify Transaction Log as the backup type on the

General page.

The database can be backed up using the transact-SQL command BACKUP LOG, which is described in

detail in the SQL Server Books Online.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Tape Options

When the SQLServerAgent service is started, it queries the system tables in the msdb database to

determine what jobs to start. If a backup job is scheduled, for example, using transaction DB13, SQL

Server Agent will pass the backup command to SQL Server. If the tape device is not ready at the

specified time, SQL Server will normally cancel the job and write an error to the error log. The

following timeout values are available to overcome such a problem:

• Wait indefinitely: Wait indefinitely for SQL Server to respond.

• Try once then quit: Try once and then time out when waiting for SQL Server to respond.

• Try for minute(s): Specifies that SQL Server will time out if a backup tape is not available within the

period specified.

We recommend trying for 10 minutes and then sending a timeout message.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

File System Backup Using Windows Backup Tools

The entire system, including all Windows, SAP and SQL Server files must be backed up regularly using

a backup tool such as the Windows Backup Utility. Backing up these files is necessary for a restore

operation when the disk on which SQL Server and SAP executables are located crashes. In addition, it

serves as an additional backup that may play a vital role in dealing with emergency situations where

other routine backups have been damaged. Choose Start → Programs → Accessories → System Tools

→ Backup to open the Windows Backup tool. For detailed information, see the Windows Online Help.

Windows, SAP and SQL Server files need to be backed up:

• After your SAP NetWeaver installation

• After installing a Windows or SQL Server Service pack

• Before special actions such as an SAP upgrade

Windows Backup Tool only backs up closed files. Therefore the services SQL Server

(MSSQLSERVER), SQL Server Agent (MSSQLSERVER), SAP<SID>_<InstanceNo>, the SAPOsCol

and all other SQL Server related services must be stopped. See the “SQL Server Architecture” unit for a

detailed description of the services.

You must also back up the local registry.

Never use Windows backup for regular database backups that are part of a predefined backup and

restore strategy. When you restore such a Windows backup, the database and transaction log files are

restored to the state they were at the time you ran the Windows Backup. No subsequent differential or

log backups can be applied. Therefore you can not do a point-in-time database recovery. This means that

the changes you made to the database since the last Windows Backup are lost and cannot be redone.

Instead, always use SQL Server-based backups for regular database and log backups.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

28 days

Additional

backup

Transaction log backups of <SID>

Consistency check of <SID>

Database backup of <SID>,

master and msdb

Verify the backups

Backup Cycle Recommendations

Transaction log backups of <SID>

Database backup of <SID>,

master and msdb

SAP recommends a backup cycle of 4 weeks, respectively 28 days.

A pool of tapes for database and transaction log backups is required. Ensure that enough tapes are

provided in each tape pool to span the entire backup cycle. SAP recommends having 30% more tapes

than required. Backup tapes can be reused at the end of a backup cycle (after 28 days).

To verify a backup, you must check the database for physical errors using a consistency check. You

must perform this verification at least once in the backup cycle. You should also check whether the

individual backups can be read.

• Note: For details on consistency checks, refer to the “Regular Maintenance and Error Handling” unit.

Remove the last verified full backup of each cycle from the tape pool, and keep this backup in long-term

storage. Replace the tapes, and initialize new ones.

Perform additional backups after each database structure modification or a system upgrade. Place these

additional backups in long-term storage.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Backup Requirements and Effort

Backup time

Restore time

High availability

Training

Acquisition costs

Administrative workload

Long Short

No Yes

Long Short

Short Long

Low High

Low High

?

?

?

?

?

?

Requirements. Depending on your situation, you may need one backup scenario or a combination of

several advanced backup scenarios. When you define your backup scenario, you must consider:

• How long it takes to perform a backup

• The maximum time required for a complete database restore

• To what extent your backup strategy provides additional security in case of a hardware failure

Costs. Your backup scenario will also depend on:

• How much training the administrator requires

• The amount of database administration required for implementation and production operation

• The acquisition costs

Now that you are familiar with the different backup types supported by SAP and Microsoft tools, we

can introduce various advanced backup scenarios. The following screens introduce various advanced

backup scenarios supported by SAP tools, ranked according to the above criteria using a smiley matrix.

This ranking is intended as a rough guideline only.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Single Database and Transaction Log Backups

DB13:

Full daily backup

of master, msdb and <SID>

to one tape

ID01S RL01S

<SID><SID>

<SID>

DB13:

Transaction log backup

of <SID> to one tape

each hour

Training

Backup

time

Restore

time

High availability


Acquisition

costs

msdb

master

<SID>

Database Backup Transaction Log Backup

This scenario is the reference point for ranking all other scenarios.

A full backup of the SAP database should be performed daily on a permanent storage medium, for

example, a data tape. This backup category records the complete state of the data in the database at the

time the backup operation completes. The master database and the msdb database must also be backed

up daily.

The transaction log of the SAP database must also be backed up in order to restore the database to a

specific point in time. The transaction log contains information on database changes, which is used for

roll-forward and roll-back operations. SAP recommends scheduling log backups at least every 30 to 60

minutes. The number of transaction log backups depends on the size of the transaction log (normally 5

GB) and the transaction rate of your system.

Transaction log backups are much smaller in size than database backups, because they contain only the

changes since the last transaction log backup. Therefore, a transaction log backup has a low impact on

system performance, if performed during normal operation.

A transaction log must be backed up before the transaction log file is full. If the transaction log is full,

no further database transactions can be performed. For a solution on how to handle a full transaction log,

see the “Regular Maintenance and Error Handling” unit. After the transaction log backup, all inactive

log information is truncated from the transaction log file.

The database and transaction log backups must not be written to the same backup device.

SAP recommends this strategy because it meets the needs of most customers.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Parallel Tape Support

DB13:

Full daily database backup


to more than one tape

Database Backup Transaction Log Backup

ID01P

ID01P

ID01P

RL01P

RL01P

DB13:


of <SID> to more than

one tape

Training

Backup

time

Restore

time

High availability


Acquisition

costs

<SID><SID>

<SID>

msdb

master

<SID><SID>

To reduce backup time and the time required for restoring the database and the transaction log,

transaction DB13 supports the parallel use of multiple devices. This strategy can also be used if all

databases or the volume of all transactions logs to be backed up will not fit on one single tape and

automatic or manual device changing is not possible. A disadvantage may be that if one device cannot

be read, the whole backup cannot be restored. Therefore, we recommend that you always verify the

structure of the backup on the device as explained earlier.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Two-Step Disk Backup

Slow second step

Windows Backup

Fast first step DB13:

Full daily database backup


to DISK_DEV1

<SID>

DISK_DEV2

DISK_DEV1

<SID><SID>

Fast first step DB13:

Transaction Log Backup of

<SID> to DISK_DEV2

RL01S ID01S

Slow second step

Windows Backup

Training

Backup

time

Restore

time

High availability


Acquisition

costs

msdb

master

<SID>

A two-step disk backup is performed as follows:

• First, a full database or transaction log is made to disk. Typically, this is faster than a backup to tape.

• Second, the files are backed up from disk to tape.

The advantages of the two-step disk backup are:

• It reduces backup time.

• It reduces restore time (if the required files are still available on disk).

• Backups can be saved to remote disks, through shared folders.

First, additional backup devices on disk must be created for the database backups and the transaction log

backups. Enough disk space to hold these backups must be available.

• Note: The size of a database backup corresponds roughly to the used size of the database because

only used pages are copied to the backup media.

Second, the files are copied to tape using Windows Backup or another third-party tool.

If the backups on disk are still available when a restore is necessary, the restore time is reduced. If the

backups are no longer available, the restore will need to be performed from tape.

The advantage of the two-step disk backup strategy is that backups that are performed to a remote disk

are physically separated from the server. In case of fire or flood, the backup on the remote disk may still

be available.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Supplementary Differential Database Backup

Sun Mon Fri

<SID>

DB13:

Full weekly database

backup of master, msdb

and <SID> to one tape

ID01S

<SID>

R+02S

DB13:

Differential daily

database backup of

<SID> to one tape

RL02S

...

<SID><SID>

DB13:


of <SID> to one tape

Training

Backup

time

Restore

time

High availability


Acquisition

costs

msdb

master<SID>

Using a full, differential database backup and transaction log backups together can reduce the time

needed to restore a database back to any point in time after the database backup was created.

Additionally, creating both differential database and transaction log backups can increase the robustness

of backup procedures in the event that either a transaction log backup or differential database backup

becomes unavailable, for example, due to media failure. Differential backups reduce the runtime of the

backup itself because during the backup procedure the DCM page is read to determine which extents

have changed.

Typically, combined full, differential database backups and transaction log backups involve creating full

backups at longer intervals, differential database backups at medium intervals, and transaction log

backups at shorter intervals. For example, create full backups weekly, differential database backups

daily, and transaction log backups hourly.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Monitoring Backups

Mon Tue Wed Thu Fri Sat

Tue Wed Thu Fri Sat Sun


Mon

SunTue


Tue

28 days

Backup

cycle


DB13 or DB13C

SQL Server

Management Studio

Explorer CCMS Monitoring Tool (DB12)

Database backups

!! ii

??

Event Viewer

regularadditional

You must check regularly whether the backup jobs were completed successfully. Always check that:

• The most recent backup has run successfully

• All the backups in the backup cycle are being executed according to the schedule. Gaps in a backup

sequence can have serious consequences in a subsequent attempt to restore the database.

• The backup and restore process works successfully and enables you to restore your database to a

correct and consistent state

Single backups of databases and transaction logs can be monitored in different ways:

• Use the DBA Planning Calendar (transaction DB13 or DB13C).

• If the SAP system is unavailable, use the SQL Server Management Studio and the Event Viewer to

check backup job execution.

• To display the SQL Server error log, use the Explorer or the SQL Server Management Studio. Using

the Explorer, select the drive and the MSSQL.1\MSSQL\LOG\ path. The current error log is in file

ERRORLOG. All recent error logs can be found in files ERRORLOG.1 to ERRORLOG.6. By

default, Microsoft SQL Server maintains up to seven error logs. The number of error logs can be

configured in the SQL Server Management Studio.

• To display the SQL Server Agent error log, use the Explorer or the SQL Server Management Studio.

Using the Explorer, select the drive and the MSSQL.1\MSSQL\LOG\ path. The extension of each

archived error log indicates the age of the error log. For example, an extension of .1 indicates the

newest archived error log. The file with the extension OUT is the current log file.

• To check the backup cycle, use the DBA Planning Calendar (transaction DB13) or the CCMS

Monitoring Tool (transaction DB12).

To meet the requirements of its disaster recovery implementation, transaction logs might be backed up

very often (every minute) thus increasing the job history. You therefore might have to increase the

maximum job history log size to prevent a loss of job history data. This can be done using the SQL

Server Agent properties.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Monitoring Using the DBA Planning Calendar

SQL Server Agent

Database LayerDB Interface

SAP Layer

msdb tables

You can check whether your most recent database and transaction log backups are usable in the DBA

Planning Calendar. It is best to check the backup immediately after the backup has finished and before

you remove the tape.

You should check whether the transaction log backups are completed successfully on a daily basis.

Omitting such a check could have serious consequences. In the event of a hardware crash and a

subsequent restore operation, this may result in the loss of several hours of data.

The status of a finished action is marked red if the action failed or green if the action was completed

successfully. To display more information on a completed action, select the action and double-click,

then go to folder Program Log. Each action not run successfully should be checked immediately.

The primary attributes of a backup job scheduled using the DBA Planning Calendar are:

• Jobname: The name of the job. Backups scheduled using the DBA Planning Calendar always begin

with SAP CCMS [Log | Database | Diff DB] of <database list> [timestamp]. The timestamp specifies

the scheduling time and is always unique.

• Stepname: A job step is an action that the job takes on a database or a server. DB13 always plans one

step, even if more than one databases are backups up in one DB13 action.

• Command: The command that is executed in the job: sap_backup_databases,

sap_backup_diff_databases or sap_backup_log.

The task history section returns information on the job and the job step execution. This information is

read from msdb table sysjobsteps, which contains the information for each step in a job to be executed.

Table sysjobhistory contains information about the execution of scheduled jobs.

If the option verify has been chosen, the runtime of the scheduled is longer even though the backup itself

is already finished. The verification of the backup is done after the backup is completed and belongs to

the job, but not to the backup.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Monitoring Using the CCMS

Checking individual backups is not sufficient to ensure that your backup strategy is being implemented

successfully. You should also periodically check all of your database backups together to make sure that

your strategy is being adhered to and there are no gaps in the sequence.

In the SAP system, the Database Backup History (transaction DB12) offers an overview of all database

backups and all transaction log backups.

Choose Backup History. A result list appears showing technical details about all backups that have been

executed for the last 30 days (default). Select a backup and choose History for additional details.

If a backup failed, analyze exactly what happened. To do so, it is necessary to also look at the SQL

Server error logs.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Verification Using the SQL Server Management Studio

To display the job history in the SQL Server Management Studio, select folder SQL Server Agent, item

Jobs.

All the jobs scheduled from the SAP system begin with “SAP”; for example, “SAP CCMS DB backup

of <Databases>.” Select a job in the list, right-click and choose View History to retrieve more

information on the jobs.

• Note: Do not use the SQL Server Management Studio to change the attributes of jobs coming from

the SAP system. They should always be modified using the DBA Planning Calendar.

SQL Server keeps the history data of backups and jobs in system tables in database msdb. Some system

tables were mentioned in previous slides. Tables that contain information about backups include:

• backupfile: contains one row for each backup made

• backupset: contains one row for each backup set

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Backup Errors – Additional Information

If a backup error occurs, you can find additional information in the Event Viewer and in the database

error log. Further notification in case of a failure of the scheduled job can be defined using the

Enterprise Manager.

To open the Event Viewer, choose Start → Settings → Control Panel → Administrative Tools → Event

Viewer.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

High Availability

Solutions:

Log Shipping

Database Mirroring

Failover Clustering

High Availability Solutions operating SAP NetWeaver are not explicitly supported by SAP, although

SAP takes care that SAP software is capable of being installed and operated in a high available

environment. The following high availability solutions are discussed in the next slides:

• Log Shipping

• Database Mirroring

• Failover Clustering

Note: For more information about high availability aspects with SAP solutions, see SAP Service

Marketplace at service.sap.com/ha and refer to SAP Note 853572.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Log Shipping

Secondary serverPrimary server

DISK_DEV1

<SID> <SID>

RL02SID02S

<SID><SID>

<SID><SID>

DISK_DEV2

Daily Windows Backup of

DISK_DEV2

to tape

Daily Windows Backup of

DISK_DEV1

to tape

DB13:

Full Database Backup of

<SID>, master and msdb

to tape

Full Database Backup


to DISK_DEV1 once

DB13:

Transaction Log Backup of

<SID> to DISK_DEV2 each

hour

Training

Backup

time

Restore

time

High availability

Admin. workload

Acquisition

costs

msdb

master

<SID>

msdb

master

<SID>

Log shipping allows you to maintain a warm (also known as a hot) standby server for a particular

database by automatically sending transaction log backups from that database on a primary server to a

secondary database on another server, known as the standby or secondary server. At the secondary

server, these transaction log backups are restored to the secondary database, keeping it synchronized

with the primary database.

The secondary server can be brought online if the primary server fails. The secondary server contains a

copy of the databases on the primary server, including the system databases. This copy is maintained by

initially backing up the databases on the primary server and restoring them once on the secondary

server. If the primary server fails, the secondary database must be opened manually by the administrator,

and can take on the role of the primary database. A log shipping configuration does not automatically

fail over from the primary server to the secondary server.

The transaction log backups from the primary server are applied on the secondary database. This allows

a delayed restore on the secondary server in case of a possible user error. Setting the log shipping

interval to five minutes would mean that if a disaster occurred, five minutes of transaction log data

could be lost.

You should not rely on log shipping alone to keep your production data safe. In addition, perform

regular database backups on tape or a remote disk. This way, you will have the safety of a permanent

backup device in case you decide to perform a fail-over to your standby database server.

Note: Certain structural changes such as the creation and deletion of data files on the primary database

are not automatically replicated on the secondary database. In this case, the recovery is stopped, and the

database administrator must resolve the situation manually.

This scenario is highly dependent on the implementation, therefore, you must plan the environment in

detail. See SQL Server Books Online for a detailed description.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database mirroring can be configured in these ways:

Asynchronous Mirroring:

Æ Keep the mirror close to the same state as the primary server

Æ Limit loss in case of failure to a few transactions

Æ Provide a complete second image of the database

Æ Does not affect performance of the primary server

Æ Is not suitable for automatic failover

Æ Synchronous Mirroring with Failover

Æ Requires a witness

Æ Keep the mirror database constantly on the same state

Æ No committed transactions are lost in case of failure

Æ Provide failover capabilities through reconnect

Æ Provide a complete second image

Æ Synchronous mirroring without failover

Database Mirroring Configurations

Microsoft SQL Server 2005 supports database mirroring. Using this functionality information that is

submitted to the transaction log on the primary database server is also submitted to the transaction log of

a secondary database server.

Microsoft SQL Server supports the following different configurations:

• Synchronous mirroring with failover: The primary server can be configured to require

acknowledgement from the secondary server that the information has been committed to the

secondary server's transaction log before the primary server acknowledges the commit operation to

the sending application. Failover capability is provided with the help of a witness.

• Synchronous mirroring without failover: The primary server can be configured to require

acknowledgement from the secondary server that the information has been committed to the

secondary server's transaction log before the primary server acknowledges the commit operation to

the sending application. No failover capability is provided.

• Asynchronous mirroring: The primary server can be configured to not require acknowledgement

from the secondary server before the primary server returns an acknowledgement to the submitting

application.

The advantage of synchronous mirroring is that the data must be committed to the transaction log file on

both the primary server and the secondary server before the submitting application receives

acknowledgement of a committed transaction. Synchronous database mirroring ensures that both the

primary and secondary servers have the same information at the same time.

…

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


…

The advantage of asynchronous mirroring is that network latency between the primary and secondary

servers in the database mirror pair does not cause a delay in acknowledging transactions to the

submitting application. The primary server sends the commit acknowledgement to the sending

application without waiting for a reply from the secondary server. Asynchronous database mirroring is

best suited to avoid delays in committing transactions in an environment where an organization does not

have too great a distance between the primary and secondary servers.

Mirroring is implemented on a per database basis and works only with databases that use the full

recovery model.

Note: Database mirroring is enabled in Microsoft SQL Server 2005 SP1.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Asynchronous Mirroring

Commit

Write to

Local

Log

Transmit to Mirror

Write to to

Remote

Log

Acknowledge

Committed

in Log

1

23

2

3

4

SAP NetWeaver

Application Server

<SID><SID>

Transaction

log

<SID>

Transaction

log

Primary

Database

Server

Secondary

Database

Server

<SID>

In database mirroring, an SQL Server 2005 instance continuously sends database transaction log records

to a copy of the database on another standby SQL Server instance. The primary database and server

have the role of a principal, and the receiving database and server have the role of a mirror. The

principal is also known as the primary server. The mirror is called the secondary server.

• Note: The principal and mirror servers must be separate instances of Microsoft SQL Server 2005.

Data changes are recorded in the transaction log before any changes to actual data pages are made. The

transaction log records are placed first in a database's log buffer in memory, and after a commit flushed

to disk (1). The primary database server sends these log records simultaneously to the mirror instance

(2). When the secondary database server receives the log records, it places the log records first into the

mirror database's log buffer and then flushes them to disk (3). Those transaction log records are later

replayed on the mirror. After the transaction log got committed on the primary database server (3), a

commit confirmation to the application is sent (4).

There is no wait for acknowledge from the mirror and no guarantee of providing all committed data on

the mirror. Performance is not impaired by latency. This scenario is usable for longer distances,

however, good network quality is required.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Synchronous Mirroring

Acknowledge

Acknowledge4

5Commit

Write to

Local

Log

Transmit to Mirror

Write to to

Remote

Log

Committed

in Log

1

23

2

3

SAP NetWeaver

Application Server

<SID><SID>

Transaction

log

<SID>

Transaction

log

Primary

Database

Server

<SID>

The transfer is synchronous because the primary database server will wait for both its local commit, for

example, flushing of log buffer pages to disk. and for the mirror's response (4) that it has completed its

commit before the transaction is considered completed and an acknowledgement is sent to the

application (5).

In a synchronous mirroring scenario, it is guaranteed that every committed transaction is on the mirror.

When there is no acknowledge from mirror, no commit confirmation is sent to the application.

The latency to send data to mirror and to persist transaction log data on mirror does extend time to

confirm commit to application. Therefore both servers are limited in distance, a reliable network

connection is necessary, and excellent network throughput is necessary.

Automatic failover has the following requirements:

• Synchronous database mirroring is only possible in combination with a witness server. A witness

server ideally resides on a third computer and monitors the status of the principal and mirror servers.

• Witness servers can be SQL Express Edition of Microsoft SQL Server 2005.

• Application needs automatic re-connect mechanism in case connection to the primary database

server is lost.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Failover Clustering

Database server and

standby host work in a

cluster

If the database server

fails, the standby host

takes over its tasks:

File system

reassignment

Restart of the database

(with recovery)

No replication of DB files

Cluster software depends

on OS platform

Cluster Interconnect

common files

Cluster Node 1:

Central Instance

public network

SAP

files

<SID>LOG1

Cluster

Lock /Quorum

<SID>DATA1

<SID>DATA2

<SID>DATA3

Cluster Node 2:

BootDisk

Database

BootDisk

A cluster is a set of computers that looks like a single computer to the outside. Each node in the cluster

works on its own resources. The nodes in a cluster are connected and check each other's status using

heartbeat signals. If one node fails, another node can be used by a switchover mechanism. The resources

of the failed node are assigned to a surviving node. A failover cluster is an effective solution to prevent

unplanned downtime.

When the database starts after a failover, an automatic recovery has to be performed. All open

transactions that were not committed before the crash have to be rolled back, committed transactions

have to be rolled forward.

Keep in mind when sizing your system that the surviving computers need to be powerful enough to

continue production operation with additional workload following failover.

Cluster software such as the Microsoft Cluster Server depends on the underlying operating system. It

can protect databases, as well as other applications and resources.

Note: For more information about Microsoft Cluster Server, refer to the installation guides and to SAP

Notes 106275 and 112266.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

High Availability: Summary

Shared Disk Array

and Controllers

Additional secondary

server and optionally

witness

Additional

secondary server

Hardware

Requirements

User and System-

databasesUser DatabaseUser DatabaseScope

Yes, if RAID is defectOnly in asynchronous

mode

Yes, since last

transaction

log backup

Data Loss

Short, detection,

failover and

automatic

recovery

Short, detection and

failover

Dependent on

Transaction log

backup

frequency

Downtime

Yes

Only in synchronous

mode with the

use of a witness

server

NoAutomatic Failover

Yes

Only in synchronous

mode with the

use of a witness

server

NoFailure Detection

Failover Clustering Database MirroringLog Shipping Isolation level

Note: For more information about high availability aspects with SAP solutions, visit SAP Service

Marketplace at service.sap.com/ha and refer to SAP Note 853572.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Back Up a User Database: Unit Overview Diagram

Database Backup

Lesson 1: Back Up a User Database

Lesson 2: Back Up a Transaction Log

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Back Up a User Database: Lesson Objectives


” Perform a database backup using the DBA Planning

Calendar

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Back Up a User Database: Business Example

” As a database administrator, you want to schedule

regular database backups of your productive SAP

system that fulfill the requirements of your backup

strategy. For this purpose, you choose the DBA

Planning Calendar.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Back Up a User Database: Lesson Summary


” Perform a database backup using the DBA Planning

Calendar

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Back Up a Transaction Log: Unit Overview Diagram

Database Backup

Lesson 2: Back Up a Transaction Log

Lesson 1: Back Up a User Database

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Back Up a Transaction Log: Lesson Objectives


” Perform a transaction log backup using the

Microsoft SQL Server tools

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Back Up a Transaction Log: Business Example

” As a database administrator, you detect that your

transaction log grows significantly fast. In order to

prevent a full transaction log, you decide to perform

an unplanned additional backup of the transaction

log for which you use the SQL Server Configuration

Manager.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Back Up a Transaction Log: Lesson Summary


” Perform a transaction log backup using the

Microsoft SQL Server tools

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Backup: Unit Summary


” Describe and perform the different backup types

that are supported under SQL Server using the SAP

Planning Calendar and SQL Server tools

” Explain the technical implementation of the

described backup types and name the involved

system tables

” Verify the backup

” Define a suitable backup or high-availability

strategy

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


Exercises

Unit: Database Backup

Topic: Back Up a User Database


• Perform and verify database and transaction log backups using the


As a database administrator, you want to schedule regular database

backups of your productive SAP system, which fulfill the requirements of

your backup strategy. For this purpose, you choose the DBA Planning

Calendar.

1 Back up the database using the DBA Planning Calendar. Perform a full database backup

using the DBA Planning Calendar.

1-1 Call the DBA Planning Calendar. Schedule a full database backup of all three

databases (<SID>, master and msdb) recurring weekly at 0:00 (+ ##) a.m. to backup

device R3DUMP4 starting tomorrow. Note: ## is the group number you have been

assigned to. For example, if your group is 5, then you schedule a weekly full

database backup at 5:00 a.m

Which options do you have to set?

1-2 Schedule a transaction log backup for the day after tomorrow at 00:00 a.m. (+ ##)

to backup device R3DUMP5.

Which options do you have to set?

1-3 Check the parameters of your scheduled tasks.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y



Topic: Back Up a Transaction Log


• Perform and verify database and transaction log backups using the


As a database administrator, you want to schedule regular database

backups of your productive SAP system, which fulfill the requirements of

your backup strategy. For this purpose you choose the DBA Planning

Calendar.

2 Back up the database using the SQL Server Management Studio. Perform an immediate full

database backup of databases master and T##, where ## is the group number you have been

assigned to, and back up the transaction log of database T## using the SQL Server

Management Studio.

2-1 Open the SQL Server Management Studio. On your SQL Server instance T##,

perform an immediate full database backup of databases master and T## to back up

devices R3DUMP1 and R3DUMP2.

What are the naming conventions for the media set name, assuming that T## is the

SAP database?

What other options do you set?

2-2 Perform an immediate backup of the transaction log of database T## to R3DUMP3.

What options will you set?

What are the naming conventions for the volume labels assuming that T## is the

SAP database?

2-3 Check the backups.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


Solutions


Topic: Backup a User Database

1 Back up the database using the DBA Planning Calendar. Perform a full database

backup using the DBA Planning Calendar, as described in Unit 4: Database Backup.

1-1 Call the DBA Planning Calendar under Tools ĺ CCMS ĺ DB Administration ĺ

Planning Calendar ĺ DB13 – Local (transaction code DB13). In the Action Pad

mark Full Database Backup. Mark the selected hour, e.g. 5.00 a.m. and click button

Add. In the next dialog box, databases master, msdb and SID must be selected. In

the Select backup devices for backup section select backup device R3DUMP4.

Set the expiration period to 27 days.

You need to set the following options: Init Tape, Tape Unload, and Verify Backup.

In the Recurrence tab click every 1 week.

Afterwards click button Add.

1-2 Call the DBA Planning Calendar under Tools ĺ CCMS ĺ DB Administration ĺ

Planning Calendar ĺ DB13 – Local (transaction code DB13). In the Action Pad

mark Transaction Log Backup. Mark the selected hour, e.g. 5.00 a.m. and click

button Add. In the Select backup devices for backup section select backup device

R3DUMP5.

Set the expiration period to 27 days.

Set Init Tape and Verify Backup since it is the first backup you are performing on

R3DUMP5.

1-3 To check the parameters, double-click the actions.

2 Back up the database using the SQL Server Management Studio. Perform an immediate full

database backup of databases Txx and master and backup the transaction log of database

Txx using the SQL Server Management Studio.

2-1 Open the SQL Server Management Studio. Connect to instance Txx. Open folder

Databases and mark database Txx. Use the right-mouse button and choose Task ->

Back up ..

Select the database (Txx) from the database list, and select backup type full. Give a

name and description and set Backup set will expire after 27 days.

In the destination list, select both backup devices R3DUMP1 and R3DUMP2. If

only one backup device is displayed in the list, add a second device by choosing

button Add.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


In the Options page, choose radio button backup to a new media set, and erase all

existing backup sets. Under New media set name give the name of the media set

after the SAP naming conventions: ID<dd>P, where <dd> stands for the day of the

month.

Then choose checkbox Verify backup when finished. Press button OK.

After the backup is completed a message box appears stating: The backup of

database ‘<Txx>’ completed successfully.

Click OK to confirm this message.

Do the same for database master, but make sure that you set the Append to the

existing backup set option in the Options page. This ensures that the backup will be

appended to the devices. If you mark Check media set name and backup set

expiration and give the name given before, the media name and its expiration

period will be checked for correctness.

Then choose checkbox Verify backup when finished. Press button OK.


database ‘master’ completed successfully.


2-2 Open the SQL Server Management Studio. Connect to instance Txx. Open folder

Databases and mark database Txx. Use the right-mouse button and choose Task ->

Back up ..

Select the database (Txx) and backup type Transaction Log. Give a name and

description and set Backup set will expire after 27 days. Select backup device

R3DUMP3.

In the Options page, choose radio button backup to a new media set, and erase all

existing backup sets. Under New media set name give the name of the media set

after the SAP naming conventions: RL<dd>S, where <dd> stands for the day of the

month.

Then choose checkbox Verify backup when finished. Mark radio button Truncate

the transaction log. Press button OK.


database ‘<Txx>’ completed successfully.


2-3 Check the entries in the SQL Server error log.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Restore

Contents:

Restore strategies and scenarios

Restore methods

Checking the restore

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Restore: Unit Objectives


” Perform a database restore using Microsoft SQL

Server tools

” Perform a complete system setup

” Describe the different restore methods and

scenarios

” Check the restore

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Restore: Course Overview Diagram








Unit 8 Conclusion

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Restore: Business Example

” Before going live with your mySAP ERP 2005

system, your company must test if your backup

strategy is appropriate. Your IT department

discusses the different restore scenarios and

methods to be able to create procedures and

escalation plans in the event of a failure.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Goals of a Database Restore Strategy



Database restore without loss of data

Restoring the database to a specific point in time

Database restore in a specific time window

(for various scenarios)

Document your procedures and escalation plansProcedure and

escalation plan


damage)


If data is lost due to external factors, such as fire or water damage to your hardware, or physical

errors, such as a hardware failure, you must restore the database up to the point in time when

the database crashed. If a full restore is possible and the backup strategy is set up properly, only

data from uncommitted transactions before the error will be lost.

If data is lost due to logical errors, such as an unintentionally imported transport, you must

restore the database up to a point in time shortly before the error occurred.

To ensure that the correct actions are performed for each of the different scenarios, create a

document containing organizational descriptions of procedures and an escalation plan. This

document must be available and understood by the person who performs the database restore.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Principles of a Database Restore

Availability

ONLINETarget

Actual

OFFLINE

Replace hardware

and set up system

Problem

analysis

Apply

transaction

logs

Automatic

recovery

Time

Restore

database

Apply

differential

backups

An appropriate backup and restore strategy ensures minimum down time when the SAP system

becomes unavailable due to an error. SAP recommends that you plan these strategies in

advance and test them in your test system.

When you plan your backup strategy, consider how long you can afford to shut down the SAP

system in different scenarios. To calculate the total time required for a full database restore,

include the following times required for:

• Analyzing the error

• Replacing the required hardware, and setting up the operating system and file systems

• Restoring the database from the last full database backup

• Applying the last differential database backup if differential backups were made

• Performing a forward recovery from the backed up transaction logs, which were made after

the full or the differential database backup

• Automatic recovery if SQL Server is restarted

The maximum downtime of a productive SAP system is the time from when the error is noted

to the time when the administrator finishes checking the restored system.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Automatic Recovery

Step 1User 1

User 2

Begin Tran1

Begin Tran2

x1

x2

Data Cache

Step 2User 1

User 2

Commit Tran1

Action written to

transaction log

dirty

SQL Server goes down due to power outage before checkpoint occurs Step 3

dirty

x1

x2

<SID>LOG1<SID>DATA1

Begin Trans1

Begin Trans2

Trans1: update

Trans2: insert

Commit Trans1

SQL Server

SQL Server

Microsoft SQL Server stops processing, for example, if an operator restarts the server while

users are connected and working in databases or if there is a sudden power outage. An

automatic recovery is then carried out when Microsoft SQL Server is restarted. This ensures

that all transactions committed before system failure are physically entered in the database

because the corresponding modified data pages might not have been flushed to the data files

yet. All other partially completed and thus uncommitted transactions are rolled back. An

example of this principle is illustrated on the screen.

Two transactions, TRAN1 and TRAN2, are started by two different users. The transactions are

recorded in the transaction log as BEGIN TRAN1 and BEGIN TRAN2. Both transactions

change pages in the data cache, and these pages are marked dirty.

In the second step, user 1 ends the transaction with a COMMIT TRAN1. SQL Server writes all

log information on transaction TRAN1 in the transaction log. COMMIT confirms that all the

affected log records in the cache are written to the transaction log.

A checkpoint causes Microsoft SQL Server to write the data pages marked dirty to the

database. In this example, however, Microsoft SQL Server and the Microsoft Windows Server

go down before the checkpoint, due a power outage.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Automatic Recovery (2)

Step 4Roll backWritten TRAN1

to database <SID>DATA1

Date Source Message

05/09/2006 08:11:15 spid5s Recovery is complete. This is an informational message only. No user action is required.

05/09/2006 08:11:14 spid9s Starting up database 'tempdb'.

05/09/2006 08:11:12 spid13s Starting up database 'AKK'.

05/09/2006 08:11:12 spid12s Starting up database 'msdb'.

05/09/2006 08:11:10 Server SQL Server is now ready for client connections. This is an informational message; no user action is required.

05/09/2006 08:11:10 Server Dedicated admin connection support was established for listening locally on port 1434.

…….

05/09/2006 08:11:10 spid9s Clearing tempdb database.

05/09/2006 08:11:09 spid9s Starting up database 'model'.

05/09/2006 08:11:09 spid5s Server name is ‘sapprd'. This is an informational message only. No user action is required.

05/09/2006 08:11:08 spid5s The resource database build version is 9.00.2047. This is an informational message only. No user action is r

05/09/2006 08:11:08 spid5s Starting up database 'mssqlsystemresource'.

05/09/2006 08:11:07 spid5s SQL Trace ID 1 was started by login "sa".

05/09/2006 08:11:06 spid5s Recovery is writing a checkpoint in database 'master' (1). This is an informational message only. No user ac

05/09/2006 08:11:05 spid5s Starting up database 'master'.

05/09/2006 08:11:04 Server Database mirroring has been enabled on this instance of SQL Server.

….

05/09/2006 08:10:58 Server Server process ID is 1920.

05/09/2006 08:10:58 Server All rights reserved.

05/09/2006 08:10:58 Server (c) 2005 Microsoft Corporation.

05/09/2006 08:10:57 Server Microsoft SQL Server 2005 - 9.00.2047.00 (Intel X86) Apr 14 2006 01:12:25 Copyright (c) 1988-2005

Begin Trans1

Begin Trans2

Trans1: update

Trans2: insert

Commit Trans1

In the fourth step, the Microsoft Windows Server and Microsoft SQL Server are started again.

Whenever Microsoft SQL Server is started, the automatic recovery is processed in each SQL

Server database:

• The LSN of the last checkpoint is read from the database boot block along with the

Minimum Recovery LSN.

• The transaction log is scanned from the Minimum Recovery LSN to the end of the log. All

committed dirty pages are rolled forward by redoing the logical operation recorded in the log

record.

• Microsoft SQL Server then scans backward through the log file rolling back all uncompleted

transactions by applying the opposite of the logical operation recorded in the log records.

This type of recovery is also done by a RESTORE statement. After restoring the copy of the

database or log, the RESTORE statement also has to ensure that all committed log records are

rolled forward and all uncompleted transactions are rolled back. Restoring is the process of

copying data from a backup and applying logged transactions to the data to roll it forward to the

target recovery point, Recovery is the process that makes the database consistent and brings the

database online.

Microsoft SQL Server provides configuration option Recovery interval (min) for automatic

recovery. It defines the maximum time in minutes needed for an automatic recovery per

database. Microsoft SQL Server uses this option to determine when a checkpoint must be

released. The default is 0, indicating automatic configuration by Microsoft SQL Server. In

practice, this means a recovery time of less than one minute and a checkpoint approximately

every minute for each database. Note: You can check the result of an automatic recovery in the

Microsoft SQL Server error log.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Restore Scenarios


damage)


Possible

error

situations

Hardware Move(to a newer hardware)



Errors requiring a database restore are caused by one of the following:

• Hardware failure, for example, when a disk crashes and affects the data or transaction log

files

• A logical error resulting in a database corruption

• User error, such as the accidental imported transport

• A disaster that destroys existing hardware

• A move to new hardware involving the whole database system

If any of the above situations occur, use the restore procedures described in the following

slides.

After a power failure, the database does not have to be restored. When power is cut off, the

system shuts down abruptly and all current transactions are aborted. Microsoft SQL Server has

an automatic recovery mechanism to deal with such a situation. This mechanism has already

been explained.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Restore Due to Media Failure

<SID>LOG1

PRIMARY


SAP, SQL

Server

and Windows

executables

Hardware

Move

User errors

Possible

error

situations

Logical

errors

External factors

<SID>DATA3

<SID>DATA2

<SID>DATA1

The procedure required to bring the database back to its original state differs depending on how

files are distributed on the system and which systems or disks are affected by the failure.

Assuming that data distribution follows the recommendations in the SAP Installation Guide and

as described in course ADM100, then the system files should be distributed across the

following volumes as follows:

• Volume 1 – Log files of the SAP database

• Volume 2 – Data files of the SAP database

• Volume 3 – SAP executables, Microsoft SQL Server executables, Microsoft Windows

executables

The procedure used for a database restore depends on which volume crashed.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SAP Data Volume Crash

Back up recent

transaction log

Replace disk in RAID

system

Restore SAP database

Restore transaction logs

Check restore operation

<SID>

<SID>

<SID>

Procedure and

escalation plan

PRIMARY

Apply differential

backups

<SID>

<SID>DATA3

<SID>DATA2

<SID>DATA1

The SAP data files reside in a RAID5 system for increased data security. If a single disk fails, it

must be replaced and the RAID5 system must be synchronized. Database operation is not

interrupted. However, if the whole RAID5 system crashes, the SAP system comes to a

standstill. An error is written to the Microsoft SQL Server error log. In this case the database

must be restored.

To restore the database after an SAP data volume crash, perform these steps:

• Immediately back up the current transaction log before shutting down Microsoft SQL

Server.

• Replace disks in the RAID5 system; the disks should be formatted and assigned the same

drive letter as the old ones.

• Restore the database by applying the most current database backup.

• If differential database backups were made after the last full database backup, apply the most

current differential database backup.

• Restore the transaction log by applying all transaction logs created since the most current

database backup or the most current differential backup, then restore the transaction log

created immediately after the volume crashed.

• Check the restore.

These steps must be described in detail in a separate document explaining your procedure and

escalation plan.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


…

…

Note: If the disks on which the database resides are damaged, work performed after the last

transaction log backup will be lost unless you back up the most current transaction log. Do this

before shutting down Microsoft SQL Server. The current transaction log can only be backed up

if the disks holding the transaction log and the executables disk are undamaged.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Backing Up the Current Transaction Log

BACKUP LOG PRD to R3DUMP0 WITH NO_TRUNCATE, FORMAT

SAPPRD SQLQuery1.sql

RL01S

If the disks on which the SAP database resides crashes, it is important to immediately back up

the current transaction log; otherwise, the work carried out since the last transaction log backup

will be permanently lost.

The current transaction log can only be backed up, if the disks on which the transaction log

resides is undamaged and the disk on which the Microsoft SQL Server executables reside is

undamaged.

To back up the current transaction log, proceed as follows:

• Insert a new tape into the tape device.

• Open a Query Window in the SQL Server Management Studio and enter the following

transact-SQL statement:

- BACKUP LOG <SID> to <backup_device> WITH NO_TRUNCATE, FORMAT

• Execute the statement.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SAP Log Volume Crash

Replace RAID system




<SID>

<SID>

Procedure and

escalation plan <SID>LOG1 <SID>LOG1

Apply differential

backups

<SID>

The transaction log files of the SAP database normally reside in a RAID1 system for increased

security reasons. If one disk crashes, the mirrored disk can be used to bring the database up

again. If both disks crash, the SAP database would be marked suspect and a restore is

necessary.

If the transaction log is not available anymore, the current transaction log cannot be backed up.

The data between the last transaction log backup and the crash of the RAID1 system is

therefore lost.

If the SAP log volume crashes, proceed as follows:

• Replace disks in the RAID1 system. The disks must be formatted and assigned the same

drive letters as the old ones.

• Restore the database by applying the most current database backup.



• Restore the transaction log by applying all transaction logs created after the most current

database backup or the most current differential backup.



escalation plan.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SAP Executable Volume Crash

Reload lost files from

latest Windows Backup

Reboot Primary Windows

Restore msdb (and

master) Database

Check Restore Operation

Procedure and

escalation PlanReplace disks and install

auxiliary Windows

msdb

SAP, SQL

Server

and Windows

executables

master

If the disk with all other files except the SAP data and transaction log files crashes, the

Windows operating system, SAP executables, Microsoft SQL Server executables, and the msdb

and master databases are lost. The operating system including the SAP system and Microsoft

SQL Server cannot start.

If the executable volume crashes, proceed as follows:

• Replace disks. The disks must be formatted and assigned the same drive letters as the old

ones.

• Install an auxiliary Windows operating system.

• Restore all lost files using the latest Windows backup. In this scenario, the SAP data and

transaction log files are not affected as they reside on different volumes. Do not reload these

files from the Windows backup.

• Reboot Windows with the restored (primary) Windows system.

• Restore the msdb database using the latest backup.

• You may also have to restore the master database if its contents were changed, for example,

when Microsoft SQL Server configuration options were changed.



escalation plan.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Restore Due To Media Failure – Summary

RAID 1 crash :

Log files lost

<SID> suspect

Replace crashed disk(s), synchronize RAID

SQL Server Restore of database and transaction logs

Automatic recovery

OK Some data lost! OK OK OK

Windows Restore of EXEs;

not log file(s)!

RAID 5 crash:

Data files lost

<SID> suspect

System crash:

Data + EXEs lost

SQL Server down

Exe disk crash:

EXEs lost

SQL Server down

One disk

crash

Shut down SQL Server

SQL Server restore msdb (+ master)

Back up log

<SID> with

no_truncate

If a hard disk containing a database data file in a RAID5 system crashes, the situation is not

serious unless the whole RAID5 system goes down, in which case the data files in the file

system are lost and must be restored.

When both RAID1 hard disks containing the transaction log files crash, a whole database

restore must also be performed. In this type of situation, you are likely to experience some data

loss because the current transaction log cannot be backed up.

If the volume containing the executables of Microsoft SQL Server, the SAP system, and

Microsoft Windows crashes, only these executables must be restored using Windows Restore.

To bring the job history to a current state, you should perform an SQL Server restore of

database msdb. The content of the master database rarely changes. If after a Windows restore

the content of the master database is not current, perform a database restore of the master

database.

After checking the restore, restart Microft SQL Server, which then executes an automatic

recovery to roll back uncommitted transactions.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Restore Due to Logical Error

<SID>


Possible

error

situations

External factors

User errors

Hardware

Move

Physical

error

When a database corruption is detected, the problem must be analyzed further to determine the

extent and cause of the damage. The optimal method of restoring the physical consistency

depends on the following considerations:

• Type of object affected, for example, an index or table

• Location of the object, for example, in database <SID>

• Extent of the damage

Open a problem message in the SAP Service Marketplace (service.sap.com) and have a support

engineer analyze the error to find the most effective solution.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SAP Database Corruption

Back up recent

transaction log




Procedure and

escalation plan

<SID>

<SID>

<SID>

Apply differential

backups

<SID>

To eliminate a corruption on the SAP database, a database restore may be necessary. In this

scenario, you do not need to recreate the RAID5 system because the data files stored there are

not damaged.

Perform the following steps:

• Immediately back up the current transaction log before shutting down Microsoft SQL

Server.

• Restore the database by applying the most current database backup that is successfully

checked for not containing corruptions.



• Restore the transaction log by applying all transaction logs written since the most current

database backup or differential backup.



escalation plan.

Database corruptions are handled in more detail in the “Regular Maintenance and Error

Handling” unit.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Restore Due to User Error


Possible

error

situations

External factors

Hardware

Move

Logical

errors

Physical

error

If a user executes a transaction that changed some data incorrectly or a faulty transport has been

imported, you might want to restore the database to a recovery point just before the incorrect

data entry. Depending on what has happened, there are different ways of solving the problem.

To cancel incorrect changes such as the accidental deletion of a table, perform a point-in-time

recovery.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Point-in-Time Recovery – Principles

Time

Transaction log

backup

08:00

09:00

10:00

Database backups

Sunday Monday Tuesday Wednesday Thursday Friday

Go back to the state as recorded on Wednesday at 09:30 a.m.

A point-in-time recovery enables you to reset a database to a specific date and time. Use this

method when you need to return the database to an earlier state, due to user error.

During a point-in-time recovery, all transactions completed after a given point in time are rolled

back.

In this example, we can assume that the transaction log was backed up every hour, at 8:00 a.m.,

9:00 a.m., and 10:00 a.m. To return to Wednesday's 9:30 a.m. state, you need the transaction

log backups from Wednesday 9:00 a.m. and 10:00 a.m., since these contain the transactions

executed before 10:00 a.m. All transactions that were not completed by the specified time are

rolled back.

By viewing the header information of each log backup, you can quickly identify which log

backup contains the time to which you want to restore the database. You then need only apply

the log up to that point.

Note: Under the bulk-logged recovery model, if a log backup contains bulk-logged changes,

point-in-time recovery is not possible to a point within that backup; the database must be

recovered to the end of a transaction log backup. Recovery models are outlined in the

“Database Backup” unit.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Snapshots

Source database Snapshot database

Snapshot database is

empty

All queries use the

pages from the source

database

11

Source database Snapshot database

As pages are updated in

the source database, the

original pages are copied

to the snapshot

22

Using Microsoft SQL Server, backups and restores can be used to create a copy of your

database for test purposes. But the time that it takes to perform the backup and restore can be

quite long depending on the size of the database. If you need to create a copy of your database

in a limited time, database snapshots are useful.

A database snapshot is a read-only, static view of a database (the source database). Multiple

snapshots can exist on a source database and always reside on the same server instance as the

database. Each database snapshot is transactionally consistent with the source database as of the

moment of the snapshot's creation. A snapshot persists until it is explicitly dropped by the

database owner.

Database snapshots can be used for reporting purposes. Also, in the event of a user error on a

source database, you can revert the source database to the state it was in when the snapshot was

created. Data loss is confined to updates to the database since the snapshot's creation.

When you create a database snapshot, a ghost copy of each data file of the source database is

created. The files do not contain any data at all. Basically, the database snapshot is simply an

empty shell, to start with. All queries to the snapshot database use the data from the source

database (1).

The database pages that are about to change in the source database are copied to the snapshot

database. Then the pages are updated in the source database. So the snapshot now contains the

original copy of the changed data (2). Any query on the database snapshot, which accesses the

data in the changed pages in the main database, will use the locally copied pages. Hence, the

data seen by the query will be from the time when the snapshot was created.

For more details, see SQL Server Books Online.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Restore Due to External Factors and Hardware Move

Hardware Move(to a newer hardware)


damage)

PRIMARY

SAP, SQL

Server

and Windows

executables

Possible

error

situationsUser errors Logical

errors

Physical

error

<SID>DATA3

<SID>DATA2

<SID>DATA1<SID>LOG1

If the system crashes due to external factors, the whole file system is lost and has to be set up

again. The same procedure has to be followed when your SAP environment moves to new

hardware or you want to create a system copy.

• Set up all hardware including RAID systems and tape device.

• Install Microsoft Windows.

• Restore Microsoft SQL Server and the SAP system.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Complete System Setup from Backups

Reload executables from

latest Windows backup

Reboot primary Windows

Restore msdb (and

master) database


Procedure and

escalation plan

Replace hardware and

install auxiliary Windows


Restore transaction logs <SID>

Apply differential

backups

msdb

SAP, SQL

Server

and Windows

executables

master

<SID>

<SID>

If your whole system crashes, proceed as follows:

• Replace hardware.

It is best to format and assign the disks to the same drive letters as the old ones.

• Install an auxiliary Windows operating system.

• Restore all executables using the latest Windows backup.

Microsoft SQL Server restore operation recreates lost data files.

- Note: The data and log files do not have to be reloaded from the Windows backup as this

is too time consuming.

• Reboot Windows with the restored (primary) Windows system and restart Microsoft SQL

Server.

The <SID> database will be marked suspect.

• Restore the master and msdb database using the latest backup.

• Restore the SAP database and apply all proceeding differential backups (if available) and

transaction logs from the latest backups.



escalation plan.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Homogeneous System Copy

Determine file structure of

source database PRD

Create directory structure

on target server QAS

Detach the source

database PRD

Check the system copy

Procedure plan

Install SAP NetWeaver on

new hardware

Reattach database to

target database QAS

Post Processing using SAP

Tools

The example given describes a possible procedure of copying a Microsoft SQL Server database

to new hardware using the Microsoft SQL Server stored procedures sp_detach_db and

sp_attach_db. In the example given, the productive SAP system database PRD is copied to the

quality assurance system database QAS. Note: Alternately, you can also restore the database as

described earlier.

The following steps have to be performed:

• Install a complete SAP NetWeaver system on a new hardware.

• Determine the file structure of the source database using transact-SQL command sp_helpfile.

• In the target system QAS, create the same directory structure for the data and log files of

SQL Server. The target database name can differ from the initial database name. Directory

and file names should correspond to the SAP naming conventions. The directories

QASDATA and QASLOG must be created. Sufficient place must be available for the

respective files.

• Detach the source database. The transact-SQL command sp_detach_db separates a database

from the SQL Server. This corresponds to a deletion of the database without eliminating the

respective files.

• Copy the data and log files on the target machine into the corresponding target directories. If

required, rename the files.

• …

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


• …

• Reattach the target database using transact-SQL command sp_attach_db. Since location and

names of the files have changed, all database files have to be specified.

• For the post processing of the copy, you can use SAP Tools for SQL Server (see SAP Note

683447).

• After the system copy, check the new system.

These steps must be described in detail in a separate document explaining your procedure.

See SQL Server Books Online for a detailed syntax of the named transact-SQL commands and

SAP Note 151603 for a detailed description on this procedure.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Master Database Not Available

Restore master database


Procedure and

escalation plan

Reload master files

from latest Windows backupRebuild master database

master

SAP, SQL

Server

and Windows

executables

If the database master is corrupted, you may need to restore the database master. However, you

do not need to recreate the data files because they are not damaged. In this scenario, Microsoft

SQL Server cannot start because all the necessary information it reads is from the master

database. You must therefore restore database master from the latest Microsoft Windows

backup to create a functioning master database.

Perform the following steps:

• Restore the master.mdf and mastlog.ldf files from the latest Microsoft Windows backup.

• Restore the master database from the latest Microsoft SQL Server backup to get the current

state of the master database.


If a current Microsoft Windows backup of database master is not available, master can be

rebuilt using setup.exe. When master has been rebuilt, a current backup of master must be

restored to create the SAP database, the backup devices, and Microsoft SQL Server logins.

Before you rebuild your database master, consult a Microsoft SQL Server support engineer.


escalation plan.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

” Restore from database

” Restore from device

” Restore to a point in time

Restore Methods

Restoring a database backup returns the database to the same state it was in when the backup

was created. Restoring a transaction log backup reapplies all completed transactions that are in

the transaction log backup to the database. Microsoft SQL Server reads through the transaction

log, rolling forward all the transactions on the transaction log. When Microsoft SQL Server

reaches the end of the transaction log, it has recreated the exact state of the database at the time

the backup operation ended. The restore operation then rolls back all transactions that were

incomplete when the backup operation started.

The database is offline for the duration of the restore. Before any portion of the database can

come online, all data must be recovered to a consistent point.

The next section introduces the different restore methods and their tools:

• Restore from database

• Restore from device

• Restore to a point in time

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Restore from Database

General page

Options page

Microsoft SQL Server stores entries for each backup in msdb tables backupset and backupfile.

For a restore from database, the backup history in these msdb records are used.

To restore from database, proceed as follows:

• In the SQL Server Management Studio select your database, right-click and choose Tasks →

Restore → Database… . In the general page, select the database to restore from the list box.

This list contains only databases that have been backed up according to the msdb backup

history. The latest database backup and subsequent transaction log backups are already

selected if the default Most recent possible is selected. Select the following in the options

page:

- Overwrite the existing database – Specifies that the restore operation should overwrite

any existing databases and their related files, even if another database or file already

exists with the same name. Do not select this option after a restore due to media failure.

- Prompt before restoring each backup – If one tape device is used, you have to switch

tapes after restoring each backup.

- Leave database ready to use by rolling back uncommitted transactions – Additional

transaction logs cannot be restored i.f all transaction logs are restored during this

procedure.

• Confirm your entries.

…

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


…

During a database restore, Microsoft SQL Server automatically recreates the database and its

associated files by copying data from the backup into the database. To change original file

locations, enter a new name under Restore as in the Options page. The default is the original

file name.

The advantage of working with this method is that you do not have to find the latest backup.

Note: The system administrator restoring the database backup must be the only person

currently using the database that is to be restored.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Changing Tapes

AKK

AKK

RL09S

ID09S

22

33

44

11

If one tape device is used, make sure the right tape is in the tape device. Identify the tape by its

tape label. If you are unsure about its content, issue a RESTORE HEADERONLY FROM

<device> or use the SQL Server Management Studio to display the media header.

After a full database backup is restored (1), a window appears asking you to insert the new tape

and to continue with the restore (2). Note that this window only appears if option Prompt

before restoring each backup has been set. Switch the tape and confirm (3) to restore the

transaction log backup(s). Once the restore is complete, a confirmation appears (4).

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Restore from Device

If the msdb is not available, the backup history is lost. In this case, you must restore the

database from the backup device or restore the msdb first, before you use restore from database.

When using restore from device, in the SQL Server Management Studio select From device,

then select the device. The header of the chosen backup device, for example, R3DUMP0 for the

tape device, is then read. To display what has been stored on this device, choose Contents.

Confirm your entries. When the database backup has been successfully imported, use the same

procedure to import the transaction log backups in the order in which they were backed up.

The advantage of using the restore from device method is that you can restore the database even

after losing the backup history.

You can restore a database from a device or from database using a query window and transact-

SQL statement RESTORE. For details, see SQL Server Books Online.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Restoring a Database to a Point in Time

You may want to restore your database to a particular point in time before the point of a failure.

For example, if a transaction changed some data incorrectly, you might want to restore the

database to a recovery point just before the incorrect data entry. Any restore that specifies the

recovery point for the database is known as a point-in-time restore.

Use the SQL Server Management Studio, select your database, right-click and choose Tasks →

Restore → Database…. Select To a Point in Time in the general page. In the dialog box, enter

the time to which you wish to restore and confirm your entry.

Point-in-time restore can also be executed through the transact-SQL statement RESTORE

[DATABASE | LOG] and the option STOPAT.

Point-in-time restore is relevant only for databases using the full or bulk-logged recovery

models. Note that under the bulk-logged recovery model, if a log backup contains bulk-logged

changes, point-in-time recovery is not possible to a point within that backup; the database must

be recovered to the end of a transaction log backup.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

” Restore from single database and transaction log

backups

” Restore from supplementary differential backups

” Restore from a parallel database backup

” Restore from a two-step disk backup

” Bring a standby server online

” Force service from an asynchronous database mirror

Restore Strategies

The method you choose to restore your SAP database depends on the type of error and on your

chosen backup or high availability strategy.

This section explains restore strategies, which depend on the different backup strategies

introduced in the “Database Backup” unit.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Restore from Single Database and Transaction Log Backups

Full backup Full backup

Sun, 1 Mon, 2 Tue, 3 Wed, 4 Thur, 5 Fri, 6

Full backup

ID03S

RL04

S

Log backups Log backups

11

22

Log backups

To restore an SAP database from a single database backup and subsequent transaction log

backups, perform the following steps:

• If possible, use the NO_TRUNCATE option to back up the current transaction log to a new

separate disk backup device.

• Set the SAP database to single-user mode.

• Restore the most current database backup (1) and all subsequent transaction log backups (2)

by choosing one of the restore methods:

- Restore from database

- Restore from device

• Select Leave the database non-operational, and do not roll back the uncommitted

transactions. Additional transaction logs can be restored. (RESTORE WITH

NORECOVERY).

• Apply the current transaction log that you recently backed up. Select the option, Leave the

database ready for use by rolling back the uncommitted transactions. Additional transaction

logs cannot be restored. (RESTORE WITH RECOVERY). If this option is set, no more

transaction logs can be applied.

• The database is not recovered until the current transaction log has been applied. This

prevents any transactions from being partially rolled back. Transactions can only be rolled

back at the end of the last restore operation, when the current log has been applied.


I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Restore from Differential Backups

Differential


Differential

ID01S

R+03

S

RL04

S

Log backups Log backups Log backups

11

22

33

Full backup

To restore an SAP database using supplementary differential backups, perform the following

steps:




• Restore the last database backup created (1).

• Restore the last differential backup created since the database backup was created (2).

• Apply all transaction log backups, in sequence, created after the last differential backup was

created, finishing with the transaction log backup created in the first step (3).

• Perform the restore using one of the restore methods:




I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Restore from Parallel Backups

Full backup


Full backup

ID03P

Log backups Log backupsLog backups

ID03P

RL04

S

11

22

Full backup

To restore an SAP database from a parallel database backup and subsequent transaction log

backups, perform the following steps:




• Perform a restore using one of the restore methods:



• Put the tapes into the tape devices. Restore the latest database backup (1) and apply all

subsequent transaction log backups including the one performed in the first step (2).


I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Restore from Two-Step Disk Backups

DISK_DEV2

DISK_DEV1

11

22


Full backup Full backup

Log backups Log backupsLog backups

Full backup

To restore an SAP database from a two-step disk backup, perform the following steps:




• If the disk where the last database backup has been performed has also crashed, provide

additional disk space for applying the latest Microsoft Windows backup. Perform a restore

as explained in the previous slides by using one of the restore methods:



• Restore the latest database backup (1) and apply all subsequent transaction log backups

including the one performed in the first step (2).


I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Bringing the Standby Server Online

Secondary serverPrimary server

DISK_DEV1

PRDPRD

DISK_DEV2

Immediate Transaction

Log Backup of active

Transaction log of PRD

to DISK_DEV2

msdb

master

PRD

msdb

master

PRD

11

22

RESTORE DATABASE PRD WITH RECOVERY

SAPPRD SQLQuery1.sql33

When you fail over from your primary database to a secondary database, it is unlikely that the

primary and secondary databases are fully synchronized. Some transaction log backups created on the primary server may not have been copied yet or applied to the secondary server. Also, changes to the databases on the primary server may have occurred since the last transaction log backup. Therefore, you should synchronize the primary database with the standby database before using the secondary database, if possible.

To synchronize the primary database with the standby database and bring the standby server online, follow these steps:

• If possible, create a backup of the active transaction log on the primary server (1).

• Apply to the secondary server, any unapplied transaction log backups, including the one performed in step 1, created on the primary server (2). You can do this manually, or use the restore job on the secondary server to apply the backups. Applying the backup of the active transaction log to the secondary server allows users to work with an exact copy of the primary database immediately prior to failure. Any uncommitted transactions are permanently lost.

• Recover the database on the secondary server (3). This makes the database available for users to modify.

If the primary server is undamaged, as in the case of planned maintenance or upgrades, you can back up the active transaction log with NORECOVERY. Using NORECOVERY will leave the database in the restoring state and allow you to update the primary server with transaction log backups from the secondary server. Then, you can switch back to the primary server without creating a full backup of the secondary server.

Note: Make sure you have tested this scenario on a test system and you have documented the steps.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Forced Service from an Asynchronous Database Mirror

SAP NetWeaver

Application Server

PRD PRDPRD

Transaction

log

PRD

Transaction

log

Primary

Database

Server

Secondary

Database

Server

ALTER DATABASE PRD SET PARTNER

FORCE_SERVICE_ALLOW_DATA_LOSS

SAPPRD SQLQuery1.sql

Transmit to Mirror

In an asynchronous database mirroring scenario, if the principal server fails while the mirror

server is available, the database administrator can make the database available right away by

forcing service to the mirror database (with possible data loss). Forcing service reassigns the

principal role to the mirror server, which becomes the principal server and makes the database

available.

• Caution: Forcing service can cause data loss. This is because the partners cannot

communicate with each other and, therefore, cannot guarantee that the two databases are

synchronized.

To force service in a database mirroring session, perform these steps:

• Connect to the mirror server.

• Issue the following statement where <database_name> is the mirrored database:

- ALTER DATABASE <database_name> SET PARTNER

- FORCE_SERVICE_ALLOW_DATA_LOSS

• The mirror server immediately transitions to principal server, and mirroring is suspended.

Note: Make sure you have tested this scenario on a test system and you have documented the

steps.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Checking the Restore

The backup and restore history is stored in the msdb database. To find the history, choose the

CCMS Monitoring Tool (transaction DB12), then click Restoration History.

If time permits, run some DBCC consistency checks on the newly restored database.

• Note: These checks are not absolutely required because a consistency check should have

been executed each month and should have guaranteed that the backup on the backup media

is consistent.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Restore Database: Unit Overview Diagram

Database Restore

Lesson 1: Restore a User Database

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Restore a User Database: Lesson Objectives


” Detect a hardware problem

” Determine the correct restore strategy to be used to

bring the database back to its original state

” Restore a user database from a previously

performed backup

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Restore a User Database: Business Example

” Your productive SAP system is suddenly

unavailable. The Microsoft SQL Server error log

reports a hardware error. Your SAP database has

crashed. As a database administrator, you need to

bring up the database without data loss as soon as

possible.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Restore a User Database: Lesson Summary


” Detect a hardware problem

” Determine the correct restore strategy to be used to

bring the database back to its original state

” Restore a user database from a previously

performed backup

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Restore: Unit Summary


” Perform a database restore using Microsoft SQL

Server tools

” Perform a complete system setup

” Describe the different restore methods and

scenarios

” Check the restore

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


Exercises

Unit: Database Restore

Topic: Restore a User Database


• Detect a hardware problem

• Determine the correct restore strategy to be used to bring the database

back to its original state

• Restore a user database from a previously performed backup

Your productive SAP system is suddenly unavailable. The Microsoft

SQL Server error log reports a hardware error. Your SAP database has

crashed. As a database administrator, you need to bring up the database

without data loss as soon as possible.

1 Restore a user database after a media failure

1-1 In this exercise you will restore the T## database using the backups you created in

the previous exercise. Make sure that you have a valid database and transaction log

backup of the T## database.

Execute stored procedure crash_me in the master database of your SQL Server

instance T##, where ## is the group you have been assigned to.

Afterwards, check whether the T## database is available.

1-2 Check the file system to see whether the data files T##Data1.mdf, T##Data2.ndf,

and T##Log1.ldf are located in the directory F:\T##\.

Which step do you have to perform immediately before you start with the database

restore?

1-3 Restore the T## database by choosing one of the restore methods introduced in this

unit.

Which method do you choose?

Which options do you set in the Restore Database window?

1-4 Check the restore operation.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


Solutions

Unit: Database Restore

Topic: Restore a User Database

1 Restore a user database after a media failure.

1-1 In this exercise you will restore the Txx database using the backups you created in

the previous exercise. Make sure that you have a valid database and transaction log

backup of the Txx database.

Execute stored procedure crash_me in the master database of your SQL Server

instance Txx, where xx is the group you have been assigned to. Close all

connections to the Txx database. To do so open a Query Window.

1-2 Use the Explorer to check whether the files are available.

Normally, you should back up the current transaction log immediately before you

start to restore the database. To do this use Transact SQL statement:

backup log Txx to R3DUMP3 with no_truncate

The following error occurs:

Server: Msg 911, Level 16, State 1, Line 1

Could not locate entry in sysdatabases for database ‘Txx'. No entry found with that

name. Make sure that the name is entered correctly.

Server: Msg 3013, Level 16, State 1, Line 1

BACKUP LOG is terminating abnormally.

1-3 To restore the Txx database, mark folder Database, use the right-mouse button and

choose Restore Database … in the SQL Server Management Studio. In the General

page type Txx in To database. Then choose From database Txx. The backup

history should show one database backup and one succeeding transaction log

backup. Leave them all marked.

In the Options page, select:

Overwrite the existing database

Prompt before restoring each backup

Leave the database ready for use by rolling back uncommitted transactions.

Additional transaction logs cannot be restored

Press button OK. A message box is shown for each backup set. A correct restore

operation returns the message:

The restore of database ‘Txx‘ completed successfully.

1-4 Open a Query Window and perform

DBCC CHECKDB (Txx) with NO_INFOMSGS.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Regular Maintenance and Error Handling

Contents:

Error Handling

Space Management

Data Consistency

Parameter and Profile Maintenance

SAP CCMS Monitors

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Regular Maintenance and Error Handling: Unit Objectives


” Handle common errors

” Monitor database and transaction log growth

” Extend the database

” Perform regular administrative tasks

” Work with the SAP CCMS Monitors

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Regular Maintenance and Error Handling: Course Overview Diagram








Unit 8 Conclusion

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

” Your company has set up the CCMS Alert Monitor to

efficiently display alerts of the Microsoft SQL Server

system. The IT department must be trained in how

to monitor the alerts and how to handle and react to

certain errors and actions.

Regular Maintenance and Error Handling: Business Example

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

CCMS Alert Monitor

It is vital to regularly monitor the availability, performance, correctness and security of your SAP

system. The SAP system contains various tools for monitoring and performance analysis. These tools

include a central monitoring architecture, which performs continual system monitoring of all hardware

and software components. It is implemented in the CCMS Monitor Sets (transaction RZ20). In the SAP

Easy Access menu, choose Tools → CCMS → Control/Monitoring → CCMS Monitor Sets.

SAP provides a preconfigured collection of monitors, which are integrated in the CCMS Monitor Sets

and which can be used immediately after the installation of your SAP system. Each monitor collection

combines an area of interest such as the SAP SQL Server Monitor, which is shown in the figure.

For information about the use, layout and maintenance of the CCMS Monitor Sets, consider the course

ADM100 – SAP Web AS Administration I.

For more information, see the System Monitoring Area and Alert Handling in the SAP Service

Marketplace at service.sap.com under quicklink /systemmanagment and SAP Note 420213.

For details on the CCMS Alert Monitor for SQL Server, see also SAP Note 171120.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

” Space Management

” Performance

” Backup/Restore

” SAP Consistency

” Health

Categories of Information

Information of alerts for Microsoft SQL Server in the monitoring tree are grouped in the following main

categories:

• Space Management

• Performance

• Backup/Restore

• SAP Consistency

• Health

Alerts for the SQL Server indicate when defined threshold values have been exceeded. Existing

threshold values reflect SAP recommendations, however, they can be adjusted to meet individual system

requirements.

The categories Performance and Backup/Restore were already discussed in previous units.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Space Management

Autogrow

Current Sizes

Free Space

Status information and alerts related to the disk space on the database server are displayed for the <SID

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Monitoring Database Growth – DB02

2

1

3

4 56

78

9

10

11

1312

Database growth must be monitored regularly using the Database Allocation Monitor (transaction

DB02). As the database grows, you may consider adding more disk space.

The main screen of the Database Allocation Monitor shows the amount of space used by the SAP

database (1) and its transaction log (2).

The DB space history button (3) displays a history of the growth of the database. Performance data

collected during the job SAP_COLLECTOR_FOR_PERFMONITOR (report RSCOLL00) is stored to

table MONI once a day and evaluated for this display.

The Files section lists the database and log files used. Ensure that the log files and database files reside

on separate disks (4). For data files, the PRIMARY filegroup is displayed (5). The Growth column

displays the increment by which the file can grow (6). This increment should be at least 100 MB and the

free space on the disk, displayed in the Free disk column (7), should be large enough to hold at least two

increments. The initial size of the file is displayed under Size (MB) (8). The used portion of this file is

displayed under Used (MB) (9). A file can grow to an unrestricted or to a limited size. This information

is displayed under Limit (10).

The last section displays the number and sizes of tables, indexes and stored procedures in the given

schema (11). Note that the reserved size for tables and indexes is shown. To view the sizes of all

schemas, click Total for all schemas (12).

If your database

> and the tempdb database. For each physical database file, the autogrowth option, the current sizes, and

the free space are displayed.

The values are refreshed every 8 hours.

If you double-click on the values, the Database Allocation Monitor (transaction DB02) is displayed.

grows fast, you might want to find out which table is responsible for the growth. Choose Space Statistics

(13) and choose Top n growing tables.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Free Space

To display the allocated size of a file, use the Disk Usage report in the Microsoft SQL Server

Management Studio. The space used for data and the transaction log is shown.

When SQL Server is unable to allocate space for a database object, the following message appears:

„ Server: Msg 1105, Level 17, State 2, Procedure <procedure>, Line 10 Could not allocate space for

object '<object>' in database '<SID>' because the 'PRIMARY' filegroup is full.

When this occurs, the current transaction aborts. SAP system activity cannot continue. You should

monitor database growth regularly and expand the database early enough to prevent this type of error.

The information returned by transact-SQL command DBCC SQLPERF(LOGSPACE) can be used to

monitor the amount of log space used and indicates when to back up the transaction log.

System stored procedure sp_spaceused computes the amount of disk space used for data and indexes.

When updateusage is specified, SQL Server scans the data pages in the database and makes any

necessary corrections to the sys.allocation_units and sys.partitions catalog views regarding the storage

space used by each table. This process can take some time to run on large tables or databases. There are

some situations, for example, after an index is dropped, when allocation information for the table may

not be current. In this case, the DBCC UPDATEUSAGE command can be run separately.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Proportional Fill Strategy

Database files

PRDDATA1.mdf

PRDDATA2.ndf

PRDDATA3.ndf

Used

Free

9000 MB

8000 MB

3000 MB

1000 MB

2000 MB

500 MB

Free space in the three files are in the ratio 2:4:1

New incoming data of 100 MB size would be distributed approximately as follows:

2 extents to the PRDDATA1.mdf ~ 29 MB4 extents to the PRDDATA2.ndf ~ 57 MB1 extent to the PRDDATA3.ndf ~ 14 MB

Microsoft SQL Server uses a proportional fill strategy across all files within filegroup PRIMARY,

writing an amount of data proportional to the free space and to the file size in the file (see the “SQL

Server Architecture” unit). As a result all the files in a filegroup will run full at approximately the same

time. This strategy ensures that I/O operations are distributed more evenly over the database files thus

preventing hotspots on specific files and partitions.

For example, if PRDDATA1.mdf has 1000 MB free, PRDDATA2.ndf has 2000 MB free and

PRDDATA3.ndf has 500 MB free, two extents for a new objects are allocated from PRDDATA1.mdf,

four extents for a new objects from PRDDATA12.ndf, and 1 extent from PRDDATA3.ndf. This way all

three files become full at about the same time and simple striping is achieved.

The algorithm of allocating new extents also takes into consideration how large a data file is and

whether there is free space in already allocated extents.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Equal Distributed I/OUnequal distributed I/O

Proportional Fill Strategy (2)

Volume F:\

Volume E:\

Used Free

DATA1.mdf

DATA2.ndf

DATA3.ndf

Volume G:\

MARA

INSERT

Volume F:\

Volume E:\

DATA1.mdf

DATA2.ndf

DATA3.ndf

Volume G:\

MARAMARC

MARC INSERT

Unequal distributed I/O Equal Distributed I/O

In the scenario above, Microsoft SQL Server will only allocate new extents in file PRDDATA3.ndf

because both other files do not have enough free space. Assuming that every data file resides on an

individual physical disk, then the disk that holds file PRDDATA3.ndf will be overloaded with new

incoming data. High I/O wait times would be seen. INSERT operations would be significantly slow. For

details on wait statistics and SQL Server I/O statistics, see the “Performance Management and Tuning”

unit.

When a new data file is added, all INSERT operations will go to the newly added data file, unless you

try to distribute the free space. The following slides outline the recommended actions to avoid unequal

distributed I/O operations.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Automatic File Growth

Expand first file by 100 MB

If the database is full, the proportional fill mechanism is no longer used. Microsoft SQL Server will then

automatically expand one file at a time, provided that the file is set to grow automatically. If enough

space is available on the volume used for the SAP data files, the file is expanded by one increment as

specified in the Autogrowth column of the database properties page in the SQL Server Management

Studio.

Insert operations fill the expanded file first, before using another file. When using only one volume, in

most cases, this mechanism does not affect performance. If more than one volume is used, insert

operations will not be distributed equally across the volumes. Any performance improvement that would

have been achieved by distributing insert operations equally across all volumes is therefore lost.

Each file can have a maximum size specified. If a maximum size is not specified, the file can continue

to grow until it has used all available space on the volume.

Ensure that the free space on the volume is at least twice the increment by which the file grows. If less

space is available, you should consider purchasing additional disk space.

Note: Files should normally be expanded manually, and only grow automatically in unusual situations.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Extending the Database – Process Diagram

Database must be extended

Can

volume be

extended?Add new disk to

volume

Add new

volume

Move one old file

to new volume

Yes No

+

Expand files and

set all files

to autogrow

PRIMARY

<SID>DATA1

<SID>DATA2

<SID>DATA3

Expand files on old

and new volume

and set all files

to autogrow

PRIMARY

<SID>DATA1

PRIMARY

<SID>DATA1

<SID>DATA2

SAP recommends that you set the database files to grow automatically. Normally, you should expand

files manually, and allow them to grow automatically only in exceptional situations, for example, if the

database administrator is unable to react before more space is needed. If files are expanded

automatically in production operation, system performance can be affected.

Once disk space is exhausted, you must extend the database.

If the volume containing the data files can be extended, you can simply add a new disk to the volume.

Increase the size of all files equally and leave them set to autogrow.

Alternatively, you can extend the database by adding a new volume, as described later.

Information about the database files is stored in table sys.database_files in each database. Table

sys.master_files contains a row per file of a database as stored in the master database. In addition to your

backup activities, keep a record of this information about the location of files on paper. You may need

the information if a failure occurs and a whole system restore is required. Stored procedure sp_helpfile

returns the physical names and attributes of files associated with the current database.

Note: It is absolutely necessary to do a full database backup of your <SID> database and the master

database after every change in database structure. In addition, you have to manually implement structure

changes on your secondary server in case of a log shipping or a database mirroring scenario.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Expanding a Database File

If the volume can be extended, data files must be expanded manually.

To expand a file, use the SQL Server Management Studio. There you can specify the increase in space

allocated to a particular file. If all other files have no free space left, all the insert operations will use the

new space on the expanded file. You should therefore expand all files equally and use almost all the disk

space.

Keep extra space on the disk in reserve, and ensure that files are set to grow automatically by an

increment of at least 100 MB.

Alternatively, you can use the transact-SQL statement ALTER DATABASE to expand a file. See SQL

Server Books Online for details.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Extending the Database on a New Volume

SAP DB data filesRAID5 <SID>DATA3

PRIMARY

PRIMARY

RAID5 SAP DB data files

1

2

2

<SID>DATA3

<SID>DATA1 <SID>DATA2

SAP recommends that you store the SAP database data files in a RAID5 or RAID0+1 system. A RAID

system can grow up to a limited size. If a database grows beyond this limit and the RAID system cannot

be further expanded, a new RAID array must be set up.

If you use an additional volume to extend your database, one file on the existing volume must be moved

to the new volume (1) to free up space on the old volume. Expand all files on both volumes (2), or

create new files if there is only one file per volume. Leave some reserve space to let the files grow

automatically. Microsoft SQL Server continues to distribute the insert operations proportionally over all

new space, and the I/O load is equally distributed across the two volumes.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Moving a Database File

AKK msdbmaster

• Back up databases

• Detach databases

• Move data file(s)

• Attach databases

• Back up databases

• Implement structure change on secondary server

SQL Server Management Studio

SQL Server Management Studio

AKK msdbmaster

Secondary

Database

Server

A database file can be moved to a different volume in order to distribute I/O operations evenly over the

existing volume. To move a database file to a new volume:

• Ensure that a recent backup of the database is available and verified.

• Detach the database.

• Move one database file to the new volume.

• Attach the database specifying the new location of the moved file and check the new database

structure.

• Ensure that a backup of the database is performed and verified afterwards.

• Implement the same structure changes on your secondary server in case you use a log shipping or

database mirroring scenario.

Detaching a database removes the database from SQL Server, but leaves the data and transaction log

files in the database intact. To detach a database from the server, use stored procedure sp_detach_db or

use the SQL Server Management Studio. To do so, select the database, right-click and choose Tasks →

Detach …

• Caution: Before detaching a database, make sure to prevent UPDATE STATISTICS from running on

all tables on the database.

Make sure the database is not used while it is being detached from the server, that is, there must be

no connection open to the database. Also the database must not be used in a mirroring session when

detaching it.

…

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


…

Move the file to a new volume and reattach it using stored procedure sp_attach_db or using the SQL

Server Management Studio. To do so, select folder Databases, right-click and choose Attach… When

attaching a database, specify the physical location of the primary file and the file being moved, along

with the new location. Because the primary file contains the information needed to find the other files

comprising the database, you need only specify the location of the file that has changed location. Check

the new database structure by running the stored procedure sp_helpfile, which returns the physical

names and attributes of files associated with the current database.

To learn how to move a database file to a new disk, see also the SAP Online Help and SQL Server

Books Online.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Adding a Database File

You can also use additional data and transaction log files to extend a database.

Use the SQL Server Management Studio to add a new file. Specify the size of the file, the maximum

size to which the file should grow, the increment by which the file is to grow each time (default = 1

MB), and the filegroup to which the file belongs. In the SAP environment, filegroup PRIMARY is used.

When you add a new file, use the SAP naming conventions.

When adding a new data file, keep extra space on the disk in reserve, and set the files to grow

automatically in increments of at least 100 MB.

You can also use the transact-SQL statement ALTER DATABASE. For more details, see SQL Server

Books Online.

Note: Data files, which are added, are immediately used by the database. To ensure the proportional-fill

strategy, Microsoft SQL Server determines at startup time the free size of each file and computes a size

by which the database will grow on every file. A newly created empty data file will grow faster at the

beginning than all other data files.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Monitoring Transaction Log Growth

Performance

History

Database Allocation Monitor

2

43

1

The transaction log grows if data in the database is changed. As the transaction log grows, the first log

file fills, then the second, and so on, using a fill-and-go strategy.

In the SAP environment, there is usually only one log file. The size of this log file must be determined

carefully. Watch the growth of the transaction log using the Database Allocation Monitor (transaction

DB02). Observe how the transaction log fills during exceptional workload, for example, during batch

input or an upgrade.

To monitor transaction log growth, start ST04 and choose Detailed Analysis Menu → Performance

History, and then choose DB space tab. These values are refreshed every 2 hours. To display one value

per day, use transaction DB02 and choose DB space history.

To display the amount of space used by the transaction log, use command DBCC SQLPERF(logspace).

The Database Allocation Monitor displays the following:

• File name

• Location of file

• Space allocated for the transaction log files

• Log size (1)

• Log free size (2)

If automatic growth is configured for this log file, column Growth (3) displays the increment by which

the transaction log can grow. The increment should be 50% of the file size, and the free space on the

disk should be enough to handle at least one increment. Free disk column (4) displays the amount of

free space on the disk.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database

Transaction Log Full





insert update begin4 rollback chkp insert delete drop


update begin5 commit3 insert delete chkp insert commit4


<SID>

Msg 9002,

The transaction

Log for database

‘<dbname>‘

is full

SAP Application Servers

SAP Work processes

SQL Server

If the transaction log is full, Microsoft SQL Server writes the following error message to the error log

file and interrupts the current transaction:

• Msg 9002, Level 17, State 2, Procedure <procedure>, Line <line>

The transaction log for database ‘<dbname>' is full. To find out why space in the log cannot be

reused, see the log_reuse_wait_desc column in sys.databases

A similar message is written to the SAP system log. All uncommitted changes are then rolled back. Data

can only be displayed, but no changes are possible. No ABAP short dump is generated, because an

ABAP short dump is written to the database. The ABAP runtime error overview (transaction ST22)

displays empty patterns with the error SNAP_NO_NEW_ENTRY .

A full transaction log can have the following causes:

• The space available for the transaction log is too small and the auto-growth increment is too large or

autogrow is disabled.

• The transaction log backup has failed or is executed too seldom.

• Lengthy or extensive transactions have been executed that modify a lot of data, for example,

reorganizing or creating indexes and bulk load in full recovery mode.

• An open transaction prevents the transaction log from being truncated.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Respond to a Full Transaction Log

” Back up the transaction log

” Increase the transaction log manually

” Create an additional transaction log file on another drive

” Change the recovery model

” Terminate long-running transactions

If the transaction log becomes full, the appropriate action depends on your situation. There are several

ways to respond to a full transaction log:

• Back up the transaction log to a tape or disk device: In almost all cases it is advisable to back up

the transaction log immediately using the DBA Planning Calendar (Transaction DB13). Use the

same tape for this extra backup as used for all regularly planned transaction log backups. Append the

backup to the existing backups on the tape. Do not specify the option Initialize. Remember that a

transaction log backup truncates the inactive portion of the log and makes space for new transaction

logging. See also the “Database Backup” unit..

• Increase the transaction log manually: One likely cause of the transaction log filling up is a long-

running transaction. If there is enough space on the drive, increase the transaction log manually to

create more space for log records to be logged.

• Create an additional log file on another drive: If no additional space is available on the drive

where the transaction log resides, you may also create an additional transaction log file on another

drive. This might be helpful when you temporarily need more transaction log space for exceptional

cases, for example, during batch input or an upgrade

• Change the recovery model: Check if a bulk-logged operation such as the creation of an index

caused error 9002. If so, set recovery model to bulk-logged for the run of this operation.

• Terminate long-running transactions: A long-running transaction prevents truncation of

transaction log space, which happens as a result of taking a transaction log backup. To look for such

transactions, use DBCC OPENTRAN. You may have to use the KILL statement to terminate long

running transactions. See SQL Server Books Online for details on DBCC OPENTRAN and KILL.

With a good backup strategy, errors like this should not occur. To keep the log from filling up again,

start taking log backups more frequently.

See also SAP note 421644.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

” Tables, Views and Indexes missing on the database

SAP Consistency

Objects that are defined in the SAP ABAP/4 dictionary but not on the database are displayed in this

category.

The values are refreshed once a day.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database and ABAP/4 Dictionary Check

TATOPX-1

ABAP/4 Dictionary objects that were not found in the database are displayed in the Database Allocation

Monitor (transaction DB02) by choosing Checks → Database ↔ ABAP/4 Dictionary.

Indexes that exist in the SAP ABAP/4 dictionary but not on the database can be created by selecting the

index and clicking Create on DB.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

” Microsoft SQL Server startup parameters

” Error situations

Health

The health of your SAP system can be judged by monitoring the effectiveness of parameter settings and

watching out for common errors.

The message attributes under Startup Parameters show

• if the SQL Server configuration options run values match the set values

• what trace flags are in use

• if the SQL Server memory setting matches SAP recommendations

• if crucial database options are set

Note: These values are updated only at SAP system startup.

The Errors attributes show a count of the Disk I/O and Network Packet errors that SQL Server has

encountered.

Both nodes have the same thresholds. If more than 2 errors exist, yellow is displayed. If more than 4

errors exist, red is displayed. These values are refreshed every 4 minutes.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

More SQL Server Configuration Options

0affinity mask

1show advanced options0user connections1xp_cmdshell

0recovery interval (min)0priority boost4096network packet size (B)0min server memory (MB)1024min memory per query (KB)28media retention0max worker threads2147483647max server memory (MB)1max degree of parallelism0locks0lightweight pooling0index create memory (KB)0fill factor (%)0default language5cost threshold for parallelism0c2 audit mode0awe enabled0allow updates0affinity I/O mask

ValueParameter name

The CCMS Alert Monitor shows a red alert when Microsoft SQL Server configuration options have

been set, but are not active, for example, running and configured values are not equal. See the “SQL

Server Architecture” unit for details.

To check SQL Server configuration options, use transaction ST04 and choose Detail Analysis Menu →

SQL Server Parameters.

A value 0 for SQL Server configuration options locks, max worker threads, index create memory (KB),

and user connections indicates that memory is dynamically allocated for these objects as required. The

amount of memory available for the data and procedure cache decreases if the number of these objects

increases. Max worker threads is determined at startup.

Microsoft SQL Server can execute one query using more than one CPU. This is known as parallel

execution. Microsoft SQL Server executes queries using only one CPU until the estimated execution

time is below the value (in seconds) of cost threshold for parallelism. A value of 0 for cost threshold for

parallelism means that no queries are executed in parallel. This parameter is ignored if only 1 CPU is

available to Microsoft SQL Server or if max degree of parallelism is set to 1. The value max degree of

parallelism shows the number of CPUs Microsoft SQL Server can use for parallel statement execution

(0 = all available CPUs, 1 = no parallel executions).

See SQL Server Books Online for a detailed description on all SQL Server configuration options and

SAP Note 879941 for current recommendations.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Error Handling

Check for

error messages in:

SAP System Log

SQL Server Agent error log in

path X:\Microsoft SQL

Server\MSSQL.1\MSSQL\LOG

SQL Server error log in path

X:\Microsoft SQL

Server\MSSQL.1\MSSQL\LOG

dev-trace files

Event Viewer

!! ii??

ABAP runtime

errors

When a problem occurs, begin by checking the following:

• SAP system log

Use transaction SM21.

• SQL Server error log

Use the Database Monitor (transaction ST04) or the SQL Server Management Studio. Alternatively,

you can view the log files located in directory X:\Microsoft SQL Server\MSSQL.1\MSSQL\LOG.

• SQL Server Agent error log

Use the Database Monitor (transaction ST04) or the Enterprise Manager. Alternatively, you can view

the log files located in directory X:\Microsoft SQL Server\MSSQL.1\MSSQL\LOG.

• Developer trace files

Use transaction ST11 to display all messages written by the SAP work processes. To limit the

messages displayed on the database or the database interface, choose Display Components.

• ABAP runtime errors

Use transaction ST22.

• Event Viewer

Choose Start → Settings → ��ҏ→ Administrative Tools → Event Viewer.

Search for related SAP Notes on the SAP Help Portal at help.sap.com.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

SQL Server Error Log Messages

” You may encounter the following SQL Server errors:

Database file full (Error 1105)

Transaction log full (Error 9002)

Consistency errors (Errors 601, 605, 644, 823, 2511, 8928, 8944,

8952, 8976, and so on)

Deadlock (Error 1205 and so on)

Network errors (Error 11 and so on)

Errors 1105 and 9002 indicate that either a data file or the log file has run out of space.

Microsoft SQL Server as a Relational Database Management System is responsible for the physical

consistency of the database. There is a physical inconsistency (database corruption) if there are errors in

internal structures (page pointer, allocation, and so on) in the database. You can suspect this if there are

frequent short dumps in the SAP system, in particular if the following SQL Server error messages

appear: SQL Error 601, 605, 644, 823, 2511, 8928, 8944, 8952, 8976. See SAP Note 142731 for details.

SQL Server error 1205 indicates a deadlock on a certain table. Known deadlocks are listed according to

the table affected in SAP Note 565710.

Short dumps of the type DBIF_RSQL_SQL_ERROR, as evidenced in ST22, may be observed in a

badly configured SQL Server system. The details of the short dumps will indicate SQL error 11 and/or

SQL error 0. See SAP Note 392892 for details.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Inconsistencies

” A physical inconsistency exists if errors occur in internal

structures (page pointer, allocation and so on) of the database.

Consistent index Corrupted index

An inconsistency of internal data is also referred to as database corruption.

?

Hardware problems, such as a defective hard disk controller, may cause inconsistencies in the database.

These inconsistencies may only be detected when a table or index affected by the inconsistency is first

accessed, or during a consistency check. To prevent problem escalation and possible loss of data, you

must identify errors early.

SAP recommends scheduling a consistency check at least once a month, precisely once in a backup

cycle. This ensures that the backups made during that backup cycle do not contain any inconsistencies.

See also the “Database Backup” unit.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Consistency Check

Job 'SAP CCMS Check Database BSK [20060511202732-4-202732]' :

Step 1, 'Step1' : Began Executing 2006-05-11 20:27:34

DBCC CHECKDB (BSK) started at May 11 2006 8:27PM with Logfile:

C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\CCMS_CHECK_DB_HIST_2006.txt

[SQLSTATE 01000]

Microsoft SQL Server 2005 - 9.00.2047.00 (Intel X86) Apr 14 2006 01:12:25

Copyright (c) 1988-2005 Microsoft Corporation

Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 1)

DBCC CHECKDB (BSK) finished at May 11 2006 8:37PM

May 11 2006 8:36PM spid129

DBCC CHECKDB (BSK) WITH no_infomsgs executed by NT AUTHORITY\SYSTEM

found 0 errors and repaired 0 errors. Elapsed time: 0 hours 8 minutes 49 seconds.

The Database Console Command (DBCC) commands can be used to perform validation operations on a

database, table, index, catalog, filegroup, or allocation of database pages. The DBCC CHECKDB

command is a system administration tool that verifies pointers internal to a database and its structure.

DBCC CHECKDB is very I/O intensive and should not be run during normal operation.

Run periodic checks to ensure the physical consistency of your data. Use the DBA Planning Calendar to

schedule a database consistency check at least once a month during a period of low workload, for

example, on the weekend. This job executes transact-SQL statement DBCC CHECKDB WITH

NO_INFOMSGS on the SAP database.

Check the run status of the consistency checks using the DBA Planning Calendar. If the job is

highlighted in red, check for further errors in the SQL Server error log. A file that reports all errors

found is written to X:\Program Files\Microsoft SQL

Server\MSSQL.1\MSSQL\CCMS_CHECK_DB_HIST_<year>.txt. Open a message immediately and

provide the results found in the SQL Server error log and in this file.

If the run status is green, no inconsistencies were found. The SQL Server error log displays messages:

• DBCC CHECKDB (<SID>) started at ... with log file: X:\ Program Files\Microsoft SQL

Server\MSSQL.1\ MSSQL\ CCMS_CHECK_DB_HIST<year>.txt.

• DBCC CHECKDB (<SID>) executed by <user> found 0 errors and repaired 0 errors.

See SAP Note 142731 for details.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Allocation Monitor: Consistency Check

To perform a database consistency check, you can also use the Database Allocation Monitor (transaction

DB02). Choose DBCC checkdb.

• Note: Do not run a consistency check on the database while production work is carried out in the

system.

To check the integrity of all the pages and structures that make up the table or indexed view, use

transact-SQL command DBCC CHECKTABLE. In transaction DB02 choose Detail Analysis → Check

Table to execute this command on the specified table.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Database Option Settings

The CCMS Alert Monitor also checks for the setting of options on the SAP database:

• CHECKSUM: Calculates a checksum over the contents of the whole page and stores the value in the

page header when a page is written to disk. When the page is read from disk, the checksum is

recomputed and compared to the checksum value stored in the page header. If the values do not

match, an error is reported to both the Microsoft SQL Server error log and the Microsoft Windows

event log. A checksum failure indicates an I/O problem.

• TORN_PAGE_DETECTION: Saves a specific bit for each 512-byte sector in the 8-kilobyte (KB)

database page and stored in the database page header when the page is written to disk. When the

page is read from disk, the torn bits stored in the page header are compared to the actual page sector

information. Unmatched values indicate that only part of the page was written to disk. In this

situation, an error is reported to both the Microsoft SQL Server error log and the Microsoft Windows

event log.

If neither of these options are set, a red alert is displayed.

To change these options, use the ALTER DATABASE transact-SQL command with the PAGE_VERIFY

option. Alternatively, use the Properties page of a database in the SQL Server Management Studio.

System catalog view sys.databases stores the settings of these options.

For more details, refer to SQL Server Books Online.

On an SAP system, which has been upgraded from Microsoft SQL Server 2000 to Microsoft SQL

Server 2005, the TORN_PAGE_DETECTION option is set. SAP then recommends changing the option

to CHECKSUM. On a newly installed SAP system on Microsoft SQL Server 2005, option CHECKSUM

is enabled by default.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Dedicated Administration Connection (DAC)

sp_configure 'remote admin connections', 1;

GO

RECONFIGURE;

GO

Microsoft SQL Server 2005 provides a special diagnostic connection for administrators when standard

connections to the server are not possible. It allows an administrator to access Microsoft SQL Server to

execute diagnostic queries and troubleshoot problems even when Microsoft SQL Server is not

responding to standard connection requests.

This dedicated administrator connection (DAC) is available and supported as follows:

• Through the command-line interface, sqlcmd, using a special administrator switch (-A)

• By adding the prefix admin: to the instance name when connecting to a Microsoft SQL Server

instance using the SQL Server Management Studio; for example, admin:<instance_name>,<port>.

By default, the connection is only allowed from a client running on the server. Network connections are

only permitted if the remote admin connections configuration option is set. The “SQL Server

Architecture” unit explains how to set SQL Server configuration options.

The dedicated administrator connection is used for analyzing Microsoft SQL Server problems in rare

circumstances. The access to some system base table is dedicated to the dedicated administrator

connection. Access these tables only when advised by an SAP or Microsoft support engineer.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Monitor Database and Transaction Log Growth: Unit Overview Diagram

Lesson 2: Extend the Database on a New Volume


Lesson 1: Handle a Full Transaction Log

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Handle a Full Transaction Log: Lesson Objectives


” Handle a full transaction log

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Handle a Full Transaction Log: Business Example

” SAP users complain about broken connections to

the database and ABAP short dumps. As a database

administrator, you analyze the situation and detect

that the transaction log ran full. You immediately

solve the problem.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Handle a Full Transaction Log: Lesson Summary


” Handle a full transaction log

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Extend the Database on a New Volume: Unit Overview Diagram


Lesson 2: Extend the Database on a New Volume

Lesson 1: Handle a Full Transaction Log

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Extend the Database on a New Volume: Lesson Objectives


” Extend the database on a new volume

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Extend the Database on a New Volume: Business Example

” The IT department of your company monitors the

growth of your SAP database and detects that it will

run out of space in a few weeks. You decide to

extend the database on a new volume.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Extend the Database on a New Volume: Lesson Summary


” Extend the database on a new volume

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


SAP AG 2006

Regular Maintenance and Error Handling: Unit Summary


” Handle common errors

” Monitor database and transaction log growth

” Extend the database

” Perform regular administrative tasks

” Work with the SAP CCMS Monitors

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


Exercises

Unit: Regular Maintenance and Error Handling

Topic: Handle a Full Transaction Log and a Full Database


• Monitor the growth of the transaction log

• Handle a full transaction log

SAP users complain about broken connections to the database and ABAP

shortdumps. As a database administrator, you analyze the situation and

detect that the transaction log ran full. You immediately solve the

problem.

1-1 Transaction log full

1-1-1 Open a Query Window and select the T## database, where ## is the group number

you have been assigned to. Execute the stored procedure fill_log. This stored

procedure will fill the transaction log by adding rows to the stores table.

Monitor the growth of the transaction log.

What error message is displayed when the transaction log is full?

Where else can you see the error message?

1-1-2 Why did the transaction log not grow dynamically?

Check the properties of the transaction log and its file.

1-1-3 What can be done to resolve the situation?

Are the transaction log file properties set up correctly? If not, change them.

1-1-4 Display the log used space again, and check the correctness of the transaction log

backup.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y



Topic: Extend a Database on a New Volume


• Extend a database on a new volume

The IT department of your company monitors the growth of your SAP

database and detects that it will run out of space in a few weeks. You

decide to extend the database on a new volume.

1-2 Database full, and extending the database on a new volume

1-2-1 Set the recovery model to simple on the T## database.

Open a Query Window and select the T## database. Enter the command fill_db and

execute it. This stored procedure will fill the database by adding rows into database

table stores.

Monitor the growth of the database. Execute fill_db again and check the growth.

What do you observe?

1-2-2 What error message is displayed when the database is full?

1-2-3 Extend the T## database on a new volume by 4 MB. Choose E:\ as the new

location.

Which steps do you have to perform?

How can you extend the database and equally distribute the load across the two

volumes?

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


Solutions


Topic: Handle a Full Transaction Log

1-1 Transaction log full

1-1-1 Monitor the growth of the transaction log of the Txx database during the execution

of stored procedure fill_log.

In the SQL Server Management Studio expand SQL Server Instance Txx and the

Databases folder, then mark database Txx. Select report Disk Usage to display the

space usage of database Txx. Selecting the refresh button refreshes the display.

The Query Windows displays the following message:

Msg 9002, Level 17, State 2, Procedure <procedure>, Line <line>

The transaction log for database ‘<dbname>' is full. To find out why space in the

log cannot be reused, see the log_reuse_wait_desc column in sys.databases

Use command DBCC SQLPERF(LOGSPACE) to display the log used space. It

displays a rate of about 100%.

Error message 9002 is displayed in the SQL Server error log and in the Event

Viewer.

1-1-2 The properties of the Txx database can be displayed with the SQL Server

Management Studio. Select database Txx, right mouse-click, choose Properties and

the Files page. The log file is displayed, with its allocated size and the file

properties. The transaction log file should be set to grow automatically. But the file

growth is restricted to 2 MB.

1-1-3 Back up the transaction log of the Txx database. Use the SQL Server Management

Studio. Make sure to append the backup to the existing backup on backup device

R3DUMP3. See the exercises in Unit4: Database Backup.

If the backups succeeded, a message is returned:

The backup of database ‘<Txx>’ completed successfully.

The transaction log file of the SAP database should grow by at least 100 MB and

there should be enough space left on the disk, on which it resides. Let the

transaction log file of the Txx database grow to at least 3 MB. Change the

properties in the SQL Server Management Studio.

1-1-4 Use command DBCC SQLPERF(LOGSPACE) to display the log used space.

I n

t e

r n

a l U

s e

S

A P

P

a r

t n

e r

O

n l y

I n t e

r n a

l U s

e S

A P

P a

r t n e

r O n

l y


1-2 Database full, and extending the database on a new volume

1-2-1 Go to the Properties window of the Txx database and set the recovery model to

simple. This is done in the Options page. Choose OK.

The transaction log of the Txx database will now be truncated every time a

checkpoint occurs.

Monitor the growth of database Txx during the execution of stored procedure

fill_db. In the SQL server Management Studio, expand the SQL Server instance

Txx and the Databases folder, then mark database Txx. Select report Disk

Usage to display the space usage of database Txx. Selecting the refresh button

refreshes the display.

After a few executions of fill_db you see that the first data file is expanded

automatically. All insert operations will now take place in this first data file. As

soon as this data file is full the second file is expanded and insert operations

take place in this file. The proportional fill strategy is no longer used.

1-2-2 When the database is full, the Query Window displays the following message:

Server: Msg 1105, Level 17, State 2, Procedure <procedure>, Line 10 Could

not allocate space for object 'dbo.testtable' in database '<Txx>' because the

'PRIMARY' filegroup is full.

The SQL Server error log shows the same error message. Transaction DB02

shows the sizes of the data files and the used sizes of 4MB each.

1-2-3 The goal of extending the database is to distribute future insert operations

equally across the two volumes. Therefore the database has to be extended on

both volumes. Perform the following steps:

Close all connections to database test and detach the test database from the

server, using the transact-SQL command

sp_detach_db ‘Txx’, ‘true’

Move database data file F:\Txx\TxxData2.ndf to E:\Txx.

Re-attach database test using transact-SQL command

sp_attach_db ‘Txx’, ‘F:\Txx\TxxData1.mdf’, ‘E:\Txx\TxxData2.ndf’

Execute sp_helpfile in the test database to check the result.

Extend both data files by 2 MB each. Use the SQL Server Management Studio

or transact-SQL commands. Make sure that you change the maximum file size

the data files are allowed to grow as well.

Execute the stored procedure fill_db again to observe how the database

allocated new space proportionally on both files.

Documents

Copy Tadm53 o Adm520 en Col62 Nopw