TADM53 SAP NetWeaver SAP Web AS DB Operation (MS SQL Server)
TADM53
SAP NetWeaver SAP Web AS DB Operation (MS SQL Server)
THE BEST-RUN BUSINESSES RUN SAP
SAP AG SAP AG 2003 2003
6.20 2003/Q3 50065335
Copyright
Copyright 2003 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. All rights
reserved.
SAP AG 2003
Trademarks: Some software products marketed by SAP AG and its
distributors contain proprietary software components of other
software vendors. Microsoft, WINDOWS, NT, EXCEL, Word, PowerPoint
and SQL Server 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, Informix and Informix Dynamic ServerTM are trademarks of
IBM Corporation in USA 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, the
Citrix logo, ICA, Program Neighborhood, MetaFrame, WinFrame,
VideoFrame, MultiWin and other Citrix product names referenced
herein are trademarks of Citrix Systems, Inc. HTML, DHTML, XML,
XHTML 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. MarketSet and
Enterprise Buyer are jointly owned trademarks of SAP AG and
Commerce One. SAP, SAP Logo, R/2, R/3, mySAP, mySAP.com, 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.
Technology Consultant SAP NetWeaver - SAP Web AS Implementation
& Operation for [DB]
Attendance Project Team Training ADM515 (Database Administration
SAP DB)
3 days
Certification Technology Consultant SAP NetWeaver - SAP Web AS
Impl. & Oper. for SAP DB (2003) Certification Technology
Consultant SAP NetWeaver - SAP Web AS Impl. & Oper. for ORACLE
(2003) Certification Technology Consultant SAP NetWeaver - SAP Web
AS Impl. & Oper. for MS SQL Server (2003) Certification
Technology Consultant SAP NetWeaver - SAP Web AS Impl. & Oper.
for DB2 UDB (2003)
TADM51 5 days TADM10 10 days TADM12 10 daysSAP NetWeaver SAP Web
AS Implementation & Operation II SAP NetWeaver SAP Web AS DB
Operation (ORACLE)
SAP NetWeaver SAP Web AS Implementation & Operation I
Intermediate testing (no handout of certificate)
TADM53 5 daysSAP NetWeaver SAP Web AS DB Operation (MS SQL
Server)
TADM56 5 daysSAP NetWeaver SAP Web AS DB Operation (DB2 UDB)
SAP AG 2002
Course Prerequisites
EssentialTADM10 (SAP NetWeaver SAP Web AS Implementation &
Operation I) TADM12 (SAP NetWeaver SAP Web AS Implementation &
Operation II) Experience in the administration of MS SQL Server
databases
SAP AG 2002
Target Group
Target Group
Technology Consultants who are responsible for implementing and
administering SAP systems
?
Duration5 Days
?
SAP AG 2002
Course Overview
Contents:Course goals Course objectives Course content
SAP AG 2002
SAP AG
TADM53
1-1
Course Goals
At the conclusion of this course, you will be able to:
Consolidate your knowledge of database administration with
reference to CCMS database tools in SAP systems and MS SQL Server
tools Put effective data backup strategies into practice Recognize
and resolve performance bottlenecks Directly apply SAP knowledge
you have gained in the previous courses, as well as what you have
learned in this course, when you start your work as a junior
consultant Furthermore you got some first insight into the
principles of identifying expensive SQL statements.
SAP AG 2003
SAP AG
TADM53
1-2
Course Content: TADM53 (SAP NetWeaver - SAP Web AS DB Operation
(MS SQL Server))
Preface Course Overview Section I Section II Section III
Database Administration MS SQL Server SQL Cache Analysis (MS SQL
Server) Certification Description
SAP AG 2003
This SAP Consultant Education course contains different
individual courses (sections), each of which deal with a separate
topic. Each individual course (section) is subdivided into
different units.
SAP AG
TADM53
1-3
Content: Database Administration MS SQL Server
1 2 3 4 5 6 7
Introduction SQL Server Architecture How the SAP System uses SQL
Server Performance Monitoring and Tuning Database Backup Database
Restore Regular Maintenance and Error Handling
SAP AG 2003
SAP AG
TADM53
1-4
Content: SQL Cache Analysis (MS SQL Server)1 2 3 4 5 6 7 8 9 10
11 12 13 14 15 Introduction and Technical Background Introduction
to the SAP Stored Procedure Statistic How the SAP System uses SQL
Server Analyzing the Stored Procedure Statistic Identify Coding
Optimizer Statistics and Explain Plan Workflow and Reporting Index
Utilization and Operators Cost Evaluation Creating an Index Similar
Statements View Processing Joins Pooled and Clustered Tables
Expensive Statements and SAP Table Buffers
SAP AG 2003
SAP AG
TADM53
1-5
Content: Certification Description
1
Certification Description
SAP AG 2003
This SAP Consultant Education course contains different
individual courses (sections), each of which deal with a separate
topic. Each individual course (section) is subdivided into
different units.
SAP AG
TADM53
1-6
FS310 Inkasso/Exkasso Section I - ADM520
Diese Seite wird von Andrea fr euch noch erstell!
SECTION I
ADM520Database Administration MS SQL ServerTHE BEST-RUN
BUSINESSES RUN SAP
SAP AG SAP AG 2003 2003
SAP Web AS 6.20 2003/Q2 50062304
SAP AG
TADM53
2-1
Target AudienceThis course is intended for the following
audiences: Database administrators SAP system administrators
Project team members
Duration: 3 days
SAP AG 2002
User notes These training materials are not a teach-yourself
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.
SAP AG
TADM53
2-2
Course PrerequisitesRequired Knowledge: SAPTEC SAP NetWeaver:
Fundamentals of the Application Platform Working knowledge of the
MS SQL Server 2000 database and the operating system Windows NT or
Windows 2000
Recommended Knowledge: For the administration of SAP systems the
course ADM100 SAP Web AS Administration I is necessary
SAP AG 2003
SAP AG
TADM53
2-3
SQL Server Architecture
1
Introduction
2 SQL Server Architecture3 4 5 6 7 How the SAP System uses SQL
Server Performance Monitoring and Tuning Database Backup Database
Restore Regular Maintenance and Error Handling
SAP AG 2003
SAP AG
TADM53
3-1
SQL Server Architecture
ContentsArchitecture Database Server and Instances
Authentication Databases and files Database objects Logging
Locking
ObjectivesAt the end of this unit, you will be able to: Describe
the main features of the SQL Server architecture
SAP AG 2003
SAP AG
TADM53
3-2
Database Server
Database server, a process running the database system
SQL Server Windows server
Database 1
Database 2
SAP AG 2003
The term "database server" is often used to describe the
physical computer on which the database runs. For the purpose of
this explanation of SQL Server architecture, the term "database
server" will refer to the operating system process on Windows that
represents the active, programmed side of the database system. All
management of the database system is performed through and by the
server, and all communication with the database systems goes
through the 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.
SAP AG
TADM53
3-3
ServicesSQL Server Enterprise Manager - [Console P Console
Action Window View Help Tools
Console Root Microsoft SQL Servers SQL Server Group sapprod
[Windows NT] Distributed Transaction Co Destination SQL Server
Agent
R3DUMPO
}
Services viewed in the Enterprise Manager
Services viewed in Windows
Distributed Transaction .. MSSQLSERVER MSSQLServerAdHelper
SQLSERVERAGENT
Coordinates Transac Started Started
Manual Automatic Manual Automatic
Local System PRDadm Local System PRDadm
SAP AG 2003
Under 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: MSSQLServer: Database server
SQLServerAgent: Automatic task execution and SQL Server alert
handling Distributed Transaction Coordinator: distributes
transactions over multiple SQL Servers MSSQLServerAdHelper: Adds
and removes objects used to register instances of SQL Server and
ensures that the Windows account under which an SQL Server service
is running has permissions to update all of the Active Directory
objects for the instance, as well as any replication publications
and databases for that instance. To start and stop these services,
use the SQL Service Manager or the Enterprise Manager. The service
MSSQLServer can also be started remotely from another computer.
Starting SQL Server is the same as starting the service
MSSQLServer. The SQLServerAgent service must be started
automatically together with MSSQLServer.
SAP AG
TADM53
3-4
Trace Flags
Trace Flags can be set usingCommand Prompt Startup parameters in
the Enterprise Manager
SAP AG 2003
SQL Server can be started and stopped manually using the command
prompt by typing: net start mssqlserver or sqlservr, or net start
SQLServerAgent or by running SQLSERVR.EXE. By specifying the T, SQL
Server should be started with a specified trace flag in effect.
Trace flags are used to start servers with nonstandard behavior.
This way a better understanding of SQL Server or even a change in
the way SQL Server will react on specific conditions is provided.
SQL Server can also be started with trace flags using the Startup
dialog box in the Enterprise Manager.
SAP AG
TADM53
3-5
Instances of SQL Server
SQL Server default instance sapprod
MSSQLSERVR SQLSERVERAGENT
master
msdb
tempdb
model
SQL Server named instance sapprod\SQLServer
MSSQL$sapprod\SQLServer SQLAgent$sapprod\SQLServer
master
msdb
tempdb
model
Windows server
SAP AG 2003
SQL Server 2000 supports multiple instances of the SQL Server
database engine running concurrently on the same computer. Each
instance of the SQL Server database engine has its own set of
system and user databases that are not shared between instances.
There are two types of instances of SQL Server: Default 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
Query Analyzer specifies only the computer name in its request to
connect to SQL Server, a connection to the default instance of the
database engine on that computer is established. There can only be
one default instance on any computer, the default instance can be
of any version of SQL Server. Named Instances: All instances of the
database engine other than the default instance are identified by
an instance name specified during installation of the instance.
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. There can be multiple named instances
running on a computer. Only database engines from version SQL
Server 2000 can operate as a named instance.
SAP AG
TADM53
3-6
Client/Server
Workstation A Client X
Workstation B Client Y ODBC / OLE DB / DB Library TCP/IP
sockets
ODBC / OLE DB / DB Library Named pipes
TCP/IP
IPX/SPX
TCP/IP TCP/IP sockets
Named pipes ODS (Open Data Services) SQL Server
Windows server
SAP AG 2003
A database server is an application that runs as a system
process on a computer. Client tools (for example, Query Analyzer)
communicate with the database server through network protocols such
as TCP/IP or NW Link IPX/SPX Compatible Transport, the native
protocol of Novell NetWare networks. The network protocol used by
the database server determines the method used for inter-process
communication, for example, named pipes or TCP/IP sockets. These
methods are installed as net libraries (DLLs) using the program SQL
Setup. Only one net library is active on a client. To configure the
library, use the program Client Network Utility. Several
application programming interfaces (APIs) are available. For
example, OLE DB and DBLib. Other client applications can use the
ODBC interface.
SAP AG
TADM53
3-7
Processes and Threads
Thread 1
.. n Thread 2 Fiber 1 2
...
Thread N
Process
Windows server
SAP AG 2003
A process is a program that is currently being executed. Under
Windows, to keep processes separate from each other and prevent
interference, each process has its own address space. The process
is also the owner of all the program resources, such as file
handles and access tokens. Windows 2000 allows a process to manage
a 4GB range of linear addresses. An application process is able to
control the lower portion of this space (either 2GB or 3GB). The
upper portion is managed by system code for that particular
process. The basic unit of activity in Windows is the thread. 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 there is no address space
switch 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. The server
configuration lightweight pooling parameter 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. For more information on the lightweight pooling
parameter, please refer to the section SQL Server Configuration in
the Unit 6: Regular Maintenance and Error Handling.
SAP AG
TADM53
3-8
Processes and Threads (2)
Workstation A Client process X OLE DB Named pipes
Workstation B Client process Y OLE DB TCP/IP sockets
TCP/IP
IPX/SPX
TCP/IP TCP/IP sockets
Named pipes ODS (Open Data Services) Thread 1 Thread 2 Thread
3
...
Thread N
SQLSERVR process
Windows server
SAP AG 2003
SQL Server runs in an operating system process called SQLSERVR.
This operating system process contains threads for the operating
system and threads for clients logged on to the server. Every
connection between a client and SQL Server uses one of these
threads. SQL Server maintains a pool of either threads or fibers
for user connections. The maximum size of this pool is controlled
by the max worker threads server configuration parameter. One
thread can serve several connections. For more information, please
refer to the section SQL Server Configuration in the Unit 6:
Regular Maintenance and Error Handling.
SAP AG
TADM53
3-9
Special Threads
Lazy Writer Lock Manager Log Writer Checkpoint Manager
Background Task
SAP AG 2003
The Lazy Writer thread scans the data cache to write dirty pages
to disk. The Lazy Writer thread sleeps for an interval of time.
When it is restarted, it checks the size of the free buffer list.
If the free buffer list is below a certain point, the Lazy Writer
thread scans the buffer cache to write dirty pages to disk. Most of
the work writing dirty pages is done by the user threads and the
Lazy Writer thread typically finds little to do. The Lock Manager
dynamically adjusts the resources it uses for larger databases,
eliminating the need to adjust the locks server configuration
parameter manually. Details on the locking mechanism are explained
in later slides. The Log Writer records are written asynchronously
by a log writer thread, 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 on 20 data pages if they contain ghost records. These
are records which are deleted logically but not physically.
SAP AG
TADM53
3-10
Security Modes
SQL Server supports security modes for authenticationSQL Server
security Trusted security Mixed security
SAP AG 2003
SQL Server must verify that the login id supplied on each
connection request is authorized to access the database server.
This process is called authentication.authentication. SQL Server
supports three security modes for authentication: SQL Server
security: a connection to SQL Server is established through a SQL
Server login and password, e.g. using login id sa Trusted security:
a connection to SQL Server is established using the Windows user
account. When a user connects to 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 SQL Server all the Windows
accounts or groups that can connect to SQL Server. Mixed security:
Mixed security supports both, SQL Server security and trusted
security.
SAP AG
TADM53
3-11
Databases and Files
Databasesmaster msdb tempdb model
Files
.mdf
.ldf
.mdf
.ldf
.mdf
.ldf
.mdf
.ldf
SAP AG 2003
The system databases are: master holds all the system level
information for a SQL Server system. It stores all login accounts
and all system configuration parameters. model is used as the
template for all databases created on SQL Server. msdb is used by
SQL Server Agent for scheduling alerts and jobs. tempdb holds all
temporary tables and temporary stored procedures for all users
connected to SQL Server. It also fills any other temporary storage
needs such as work tables generated by SQL Server. Every time SQL
Server is started, tempdb is re-initialized. The initialization is
recorded as clearing tempdb in the error log. Northwind and pubs
are sample databases that are provided as learning tools. 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 only by one database. The primary file
(.mdf) contains the startup information and system tables for the
database and is used to store data. Every database has one primary
file. Secondary files (.ndf) hold data that does not fit in the
primary data file. Databases do not require any secondary data
files if the primary file is large enough to hold all the data in
the database. Transaction log files (.ldf) contain the log
information used to recover the database. There must be at least
one log file for each database.
SAP AG
TADM53
3-12
Files and Filegroups
Objects System tables and other user tables Transaction logRAID
5 RAID 1
Filegroups PRIMARY Log filesRAID systems
SAP AG 2003
Data files are assigned to one filegroup. A single table can use
space in several different files within the same filegroup. The
PRIMARY filegroup is created when SQL Server is installed.
SAP AG
TADM53
3-13
Automatic Growth
Database filesVolume File
+
:
...
(Autogrow ONLY for out-of-space failure)
Log files+ ....
: Free files SAP AG 2003
Database files only grow automatically in a filegroup 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. As the transaction log grows, the
first log file fills, then the second, and so on, 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.
SAP AG
TADM53
3-14
Space Allocation
Page Tables XRow 1 Row 2 Row 2 Row 3 Page 17 Row 3 8 9 Page 8
Row 1 0 1
File Extents2 3 4 5 6 7 1 2 3
10 11 12 13 14 15
16 17 18 19 20 21 22 23 8 Pages = 1 Extent
SAP AG 2003
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 8 contiguous pages, or 64KB. 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.
SAP AG
TADM53
3-15
Space Allocation (2)First extent on each file 8 contiguous pages
= 1 extent (64 KB) File header 0 PFS 1 GAM 2 SGAM 3 BCM 6 DCM 7
Boot page 8 ...
File header PFS (S)GAM BCM DCM
Contains information about the attributes of the file Page
allocation / free space availability (in %)Page Free Space
Usage of extents (free, mixed, full)(Secondary) Global
Allocation Map
Changes of extents when in Bulked_logged recovery modeBulk
Changed Map
Changes of extents since last database backupDifferential
Changed Map
Boot page
Contains information about the attributes of the databaseexists
only in the primary data file
SAP AG 2003
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, 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. This information is used for allocating
a new page or finding a page with free space available for a newly
inserted row. 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 it covers.
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. Bulk Changed Map (BCM) pages record the extents
which have been changed by bulk operations such as SELECT INTO and
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. See
also chapter 5 Database Recovery. 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. Read more about the usage of the DCM in Unit 4:
Database Backup. 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 for
example attributes which are needed for an automatic recovery. See
also Unit 5: Database Restore. SAP AG TADM53 3-16
Free Space
PRD DatabaseOwner: Date created: Size: Space available: Database
options: Number of users: prdadm 02/22/2002 05:55:54 65.000,00 MB
15.664,99 MB normal 2
MaintenanceLast database backup: Last differential backup: Last
transaction log backup: Maintenance plans: 10/22/2002 06:00:54 None
10/22/2002 10:00:54 None
Space AllocatedData: PRDdata1: PRDData2: PRDdata3: Transaction
Log space: 20000 MB 20000 MB 20000 MB 4999,99 MB Total 15655,59 MB
15888,19 MB 15823,69 MB 73,53 MB 4926,46 Used Free 4344,31 MB
4111,81 MB 4176,31 MB
SAP AG 2003
The log and data usage of a database can be displayed using the
taskpad view in the Microsoft Management Console of the Enterprise
Manager. The space used for each data file and the transaction log
is shown. In the first section the size of the database is shown as
the size of the data and the transaction log. The space available
shows the space available for logging information and for data. 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
sysindexes table regarding the storage space used by each table.
There are some situations, for example, after an index is dropped,
when the sysindexes information for the table may not be current.
This process can take some time to run on large tables or
databases. The command DBCC UPDATEUSAGE can be run separately.
SAP AG
TADM53
3-17
Database ObjectsLogical Database ObjectsName xyz abc
Tables Views Constraints Stored Procedures Indexes
System Representation
Name
xyz
abc
System Tables
Physical MemoryPages Pages Pages
SAP AG 2003
An 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.
SAP AG
TADM53
3-18
Non-clustered Index (on a table with no clustered index)Level n
Root Level 1 Intermediate nodes Page pointer Atlanta New York
Atlanta Berlin Heidelberg L.A. Level 0 Leaf nodes London
Manchesterrid nonclustered key values rid
Index Pagesindid >= 2
New York Paris Walldorf Washington
Heidelberg, Germany L.A., USA Atlanta, USA
London, United King. Manchester, United King. Paris, France
Berlin, Germany Washington, USA Walldorf, Germany
New York, USA
Data Pagesindid = 0 Rid (row identifier): - File ID, - Page
number, - Row number
SAP AG 2003
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. SQL Server has two types of indexes:
Non-clustered index Clustered index A non-clustered index is a B
tree, which is searched from the highest level to the data pages. A
search through the index requires the following page accesses: One
page for each index level, and one access on each data page(s).
This graphic displays data and index pages in a table. The search
fields are named for City and Country and contain a non-clustered
index in the field City. With a non-clustered index, index and data
pages are divided, so that you can create as many non-clustered
indexes for a table as needed. The location of a data row is
contained in each leaf level of the non-clustered index and is
identified by a record identifier (RID) comprised of the file
number, page number, and slot number of the row.
SAP AG
TADM53
3-19
Clustered IndexFrance, Paris Germany, Walldorf. USA, Atlanta
USA, key Washington
Level 1(indid=1)
Index Pages
Page pointer
Level 0(indid=0) France, Paris, Europe Germany, Berlin, Europe
Germany Heidelberg, Europe Germany, Walldorf, Europe United King.,
London, Europe United King., Manchester, Europe USA, Atlanta, North
America USA, L.A., North America USA, New York, North America USA,
Washington, North America
Data Pages
clustered key
SAP AG 2003
A clustered index dictates the physical storage order of the
data in the table. That means a table can contain only one
clustered index. All inserts made 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 called an index node. The top node of the B tree is called
the root node. The bottom nodes in the clustered index are called
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.
SAP AG
TADM53
3-20
Non-clustered Index with a Clustered IndexNon-clustered
IndexAtlanta Berlin Heidelberg L.A. London Manchester USA, Atlanta
Germany, Berlin Germany, Heidelberg USA, L.A. United King., London
United King., Manchester Atlanta New York ... Paris Walldorf
Washington New York
USA, New York France, Paris Germany, Walldorf USA,
Washingtonclustered key values
Index Index Pages Pages
clustered key values
Clustered Indexroot Level 1 (indid 1) Level 0 (indid 0) leaf
nodes
search via clustered index key (country, city)
Index Pages Data Pages
SAP AG 2003
If a table has a clustered index and a clustering key, the leaf
nodes of all non-clustered indexes use the clustering key as the
row locator rather than the physical record 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 do not occur.
SAP AG
TADM53
3-21
LoggingSQL Server Query Analyzerdetail stats.
SQL command
BEGIN TRAN UPDATE
Cache
FilesData Log
SAP AG 2003
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 command 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).
SAP AG
TADM53
3-22
CommitSQL Server Query Analyzerdetail stats.
SQL command
COMMIT TRAN
Cache .....
FilesData Log
SAP AG 2003
A transaction is ended with 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.
SAP AG
TADM53
3-23
CheckpointsSQL Server Query Analyzerdetail stats.
SQL command
CHECKPOINT
Cache .....
FilesData Log
SAP AG 2003
During a checkpoint, all dirty data and log pages in the cache
are written to the files. There are 2 kinds of checkpoints: Manual
checkpoint (transact-SQL command Checkpoint) Automatic checkpoint
SQL Server configuration parameter recovery interval controls when
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 and a checkpoint approximately every one minute for
each database. When a database is set to use the simple recovery
model, logging information from the log is erased at each automatic
checkpoint. This option is useful for databases that require many
changes, and have minimum security requirements, for example
database msdb and tempdb. If this mode is set, the restore cannot
apply the transaction logs written later than the checkpoint.
Perform a full backup immediately after disabling this option.
SAP AG
TADM53
3-24
Checkpoints: Logical Sequence NumberSQL Server Query
Analyzerdetail stats.
Boot page
SQL Server Query Analyzer ISQL/wdetail stats.
MinLSN 303
Begin Transaction Update MONI set KEY = 4711 where KEY= 0000;
Begin Transaction Commit Update MARA set MATNR = 4711 where MATNR=
0000 Insert into KUNR values (9087, Microsoft, Redmond) Select *
from KUNR where KNR = 5679
Transaction logLSN 301 LSN 302 LSN 303 LSN 304 LSN 305 Commit
Tran1 LSN 306 Checkpoint LSN 307 Begin Tran3
Begin Tran1 Update MONI Tran1
Begin Tran2 Update MARA Tran2
SAP AG 2003
During a checkpoint, the log sequence number (LSN) of the first
log record at which a system-wide recovery must start is written to
the database boot page. This LSN is called the Minimum Recovery LSN
(MinLSN) and is the lowest of the three following values: The LSN
of the checkpoint The LSN of the oldest recorded dirty data page
The LSN of the start of the oldest active transaction The portion
of the log file from the MinLSN to the end of the log is called the
active portion of the log. This is the portion of the log required
for a full recovery of the database. No part of the active log can
ever be truncated. All log truncation must be done from the parts
of the log before the MinLSN. The automatic recovery process is
explained in detail in Unit 5: Database Restore.
SAP AG
TADM53
3-25
Lock Modes
detail stats.
detail stats.
detail stats.
detail stats.
detail stats.
Select
Select
Update
Update
Select
Shared
Exclusive
....
SAP AG 2003
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: 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 two types of schema lock are: Schema stability
(Sch-S), Schema modification (Sch-M)
SAP AG
TADM53
3-26
Lock Resources
Database (single user) TablePage
Index rows
Key range
Extent Row
Data rows.... 8 pages
SAP AG 2003
SQL Server has multi-granular locking that 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 table KEY: Row lock within
an index, used to protect key ranges in serializable transactions
PAG: 8KB data or index page EXT: Extent, contiguous group of eight
data or index pages TAB: Entire table, including all data and
indexes DB: 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 locks currently in use, use the stored
procedure sp_lock or use the Current Activity View in the
Enterprise Manager.
SAP AG
TADM53
3-27
Lock Escalation
Minimize cost of lockingTransaction 1 Table Page Row Row3 Intent
exclusive (IX) 2 Intent exclusive (IX) 1 Exclusive (X) 4 5Exclusive
(X)
Coarse-grain locks
Lock escalation( large number of rows or pages -> table lock
)
Fine-grain locks
SAP AG 2003
SQL Server may dynamically escalate or deescalate 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. In this example, a transaction
requests rows from a table for update purpose. SQL Server
automatically acquires locks on those rows affected (1) and places
higher level intent locks on the pages (2) or index, that contain
those rows. The table which 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, e.g. 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, for
example, by placing page locks on the index (if enough contiguous
keys in a non-clustered index node are selected to satisfy the
query) and row locks on the data. This reduces the likelihood of
lock escalation. SQL Server rarely needs to escalate locks; the
query optimizer usually chooses the correct lock granularity at the
time the execution plan is compiled. Lock escalation thresholds are
determined dynamically by SQL Server and do not require
configuration.
SAP AG
TADM53
3-28
Transaction Isolation Level (1)Dirty read T1 update X X=7 select
X T1 select X,Y X=7,Y=2X=7 Y=2
rollback X=7 X=7 select X,YX=4
changing command
X=5 T2 Nonrepeatable read
X=5
reading command
X=7 data readX=4,Y unknown X=4
X=7 Y=2
T2
update X, delete Y
Phantom
T1
select CCMS -> Monitoring > Alert-Monitor. SAP provides a
pre-configured collection of monitors which are integrated in the
CCMS Alert Monitor and which can be used immediately after the
installation of your SAP System. Each collection combines an area
of interest such as the database monitor. The use, layout and
maintenance of the CCSM Alert Monitor has been introduced in course
ADM100 myTechnology Administration.
SAP AG
TADM53
8-3
Alerts in the MMC
SAP AG 2003
The CCMS Alert Monitor can also be viewed in the Microsoft
Management Console on each SAP Application Server.
SAP AG
TADM53
8-4
Categories of Information
Space Management Performance Backup / Restore R/3 Consistency
Health
SAP AG 2003
Information of alerts for SQL Server in the monitoring tree are
grouped in the following main categories: Space Management
Performance Backup / Restore R/3 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 are
not handled in this chapter as they were already discussed in
earlier chapters.
SAP AG
TADM53
8-5
Space ManagementAutogrow option Current sizes Free space
SAP AG 2003
Status information and alerts related to the disk space on the
database server are displayed for the and the tempdb database. For
each physical database file the autogrow option, the current sizes
and the free space is displayed. The values are refreshed every 8
hours. If you double click on the values, the Database Allocation
Monitor (transaction DB02) is displayed.
SAP AG
TADM53
8-6
Monitoring Database Growth
1 2 8 9 10 6 4 7 5
3
11 SAP AG 2003
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). Button DB space
history (3) displays a history of the growth of the database.
Performance data collected during the job
COLLECTOR_FOR_PERFORMANCE_MONITOR (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 column Growth
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 column Free disk (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. Note that the reserved size for tables and
indexes is shown. If your database grows fast, you might want to
find out which table is responsible for the growth. Choose button
Space Statistics (11) and choose Top n growing tables.
SAP AG
TADM53
8-7
Monitoring Database Growth (2)
DEV Space AllocatedData: DEVdata1: DEVdata2: DEVdata3:
Transaction Log space: 3000 MB 3000 MB 3000 MB 4999,99 MB Total
2999,99 MB 2999,99 MB 2999,99 MB 73,53 MB 4926,46 Used Free
SAP AG 2003
SQL Server uses a proportional fill strategy across all files
within filegroup PRIMARY, writing an amount of data proportional to
the free space in the file (see Unit 1: SQL Server Architecture).
As a result all the files in a filegroup tend to be filled 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. To display
the allocated size of a file, use the task pad view in the
Enterprise Manager. When SQL Server is unable to allocate space for
a database object, the following message appears: Server: Msg 1105,
Level 17, State 2, Procedure , Line 10 Could not allocate space for
object '' in database '' 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.
SAP AG
TADM53
8-8
Automatic File GrowthDEV Space AllocatedData: DEVdata1:
DEVdata2: DEVdata3: Transaction Log space: 3000 MB 3000 MB 3000 MB
4999,99 MB Total 19999,99 MB 19999,99 MB 19999,99 MB 73,53 MB
4926,46 Used Free
Expand first file by 100 MB
SAP AG 2003
If the database is full, the proportional fill mechanism is no
longer used. 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
autogrow. Insert operations fill the expanded file first, before
using another file. When using only one volume, 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.
SAP AG
TADM53
8-9
Extending the Database
Database must be extended
Add new disk to volume
Can Yes volume be extended?
No
Add new volume
Expand files and set all files to autogrow
DATA1
Move one old file to new volume
PRIMARY
+DATA1 DATA2 DATA3 DATA1 DATA2
Expand files on old and new volume and set all files to
autogrow
PRIMARY PRIMARY SAP AG 2003
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 impacted. 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. Procedures for doing this are
explained in the following slides. Information about the database
files is stored in tables sysfiles and sysfiles1. 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.
SAP AG
TADM53
8-10
Expanding a File Using the Enterprise ManagerSQL Server
Enterprise Manager Console Window Help
_ _
x x
Console Root\Microsoft SQL Server\SQL Server Group\sapprd
[Windows NT]\Databases Action View Tools 7 Items Console Root
Microsoft SQL Servers SQL Server Group sapprd [Windows NT]
Databases PRD master model msdb Northwind pubs tempdb Data
Transformation Management Security Support Services File
properties: Automatically grow file File growth In megabytes: By
percent: 100 10 northwind PRD
PRD Propertiesmaster model msdb General Transaction Log Options
Permissions Name: pubs Database files tempdb File name PRDDATA1
PRDDATA2 PRDDATA3 Location Space Allocated (MB) .
f:\PRDDATA1\PRD4D... 4000 ... f:\PRDDATA2\PRDD... 4000 ... ... f:\
PRDDATA3\PRDD... 4000 File group PRIMARY PRIMARY PRIMARY PRD
x
Maximum file size Unrestricted filegrowth Restrict filegrowth
(MB): 2001
OK
Cancel
Apply Apply
Help
SAP AG 2003
If the volume can be extended, data files on the larger volume
must be expanded manually. To expand a file, use the Enterprise
Manager. 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 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. If you don't want to extend the database by the whole new disk
space at one time, expand one file first and the next file when the
next expansion is necessary. Use these procedures only when all
files are located on one volume. Alternatively, you can use the
transact-SQL statement ALTER DATABASE to expand a file. See Books
Online for details.
SAP AG
TADM53
8-11
Extending the Database on a New Volume
2RAID5PRIMARYDATA1 DATA2 DATA3
SAP DB data fiIes
1
RAID5PRIMARY
DATA3
2
SAP DB data fiIes
SAP AG 2003
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. SQL Server
continues to distribute the insert operations proportionally over
all new space, and the IO load is equally distributed across the
two volumes.
SAP AG
TADM53
8-12
Moving a Database File
msdb
1
master
ID01S
SQL Server Query Analyzer - [Query - sappod.master.sa -
(untitled)] detail stats.
2
sp_detach_db PRD, true
C:\WINNT\System32\cmd.exe detail stats.
3
Microsoft(R) Windows NT (TM) (C) Copyright 19985-1996 Microsoft
Corp. C:\> mv F:\PRDDATA2\PRDDATA2.NDF
G:\PRDDATA2\PRDDATA2.NDF
SQL Server Query Analyzer - [Query - sappod.master.sa -
(untitled)] detail stats.
4
sp_attach_db PRD,F:\PRDDATA1\PRDDATA1.MDF,
G:\PRDDATA2\PRDDATA2.NDF SQL Server Query Analyzer - [Query -
sappod.master.sa - (untitled)] detail stats.
5 SAP AG 2003
sp_helpfile
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. (1) Detach the database. (2)
Move one database file to the new volume. (3) Attach the database
specifying the new location of the moved file. (4) Check the
database files. (5) Detaching a database removes the database from
SQL Server, but leaves the data and transaction log files in the
database intact. Use stored procedure sp_detach_db to detach a
database from the server. Specify true as second option in the
stored procedure. This prevents UPDATE STATISTICS from running on
all tables on the database before detaching. Note: The database
must not be used while it is being detached from the server, that
is, there must be no connection open to the database. Move the file
to a new volume and reattach it using stored procedure
sp_attach_db. 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 files by running the stored procedure sp_helpfile, which
returns the physical names and attributes of files associated with
the current database. See also the SAP Online Help and Books Online
on how to move a database file to a new disk.
SAP AG
TADM53
8-13
Adding a File Using the Enterprise ManagerSQL Server Enterprise
Manager Console Window Help
_ _
x x
Console Root\Microsoft SQL Server\SQL Server Group\sapprd
[Windows NT]\Databases Action View Tools 7 Items Console Root
Microsoft SQL Servers SQL Server Group sapprd [Windows NT]
Databases PRD master model msdb Northwind pubs tempdb Data
Transformation Management Security Support Services northwind
PRD
PRD Propertiesmaster model msdb General Transaction Log Options
Permissions Name: pubs Database files tempdb File name PRDDATA1
PRDDATA2 PRDDATA3 PRDDATA4 Location . ... ... ... Space Allocated
(MB) File group PRIMARY PRIMARY PRIMARY PRIMARY f:\PRDDATA1\PRDD...
2000 f:\PRDDATA2\PRDD... 2000 f:\PRDDATA3\PRDD... 2000
f:\PRDDATA4\PRDD 2000 PRD
x
File properties: Automatically grow file File growth In
megabytes: By percent: 100 10 Maximum file size Unrestricted
filegrowth Restrict filegrowth (MB): 2001
OK
Cancel
Apply Apply
Help
SAP AG 2003
You can also use additional data and transaction log files to
extend a database. When a file is added, the file is immediately
available for use by the database. Use the Enterprise Manager 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 = 10 %), 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.
See Books Online on more details.
SAP AG
TADM53
8-14
Monitoring Transaction Log Growth
1
2
3
SAP AG 2003
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. You can
monitor this at ST04 Detailed Analysis Menu Performance History
folder DB space. These values are refreshed every 2 hours.
Alternatively choose DB02 DB space history to display one value per
day. Use command DBCC SQLPERF(logspace) to display the amount of
space used by the transaction log. 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 (1) If
automatic growth is configured for this log file, column Growth (2)
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. Column Free
disk (3) displays the amount of free space on the disk.
SAP AG
TADM53
8-15
Transaction Log Full
SQL Server Msg 9002, The log file for database ' is full
1
begin1 update begin2 LSN0 delete LSN8 insert LSN1 dump LSN9 LSN2
insert LSN3 commit2 chkp LSN4 insert LSN5 insert insert LSN6 delete
begin3 LSN7 delete
2Backup
commit1 chkp LSN10
RL02A
LSN11 LSN12 rollback chkp LSN19 LSN20 delete
LSN13 LSN14 LSN15 insert delete drop
update begin4
3
LSN16 LSN17 LSN18
LSN21 LSN22 LSN23 chkp insert commit4
update begin5 commit3 insert LSN24 LSN25 LSN26
LSN27 LSN28
LSN29 LSN30 LSN31
SAP AG 2003
If the transaction log is full, SQL Server writes the following
error message to the error log file and interrupts the current
transaction: Server: Msg 9002, Level 17, State 2, Procedure , Line
12 The log file for database ' is full. Back up the transaction log
for the database to free up some log space A similar message is
written to the SAP System log. If you see this error message, back
up the transaction log immediately using the SAP 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 Unit 4: Database Backup. Do not shut down SQL
Server or the SAP System, if the transaction log is full. If you
shut down SQL Server, log entries will be lost. With a good backup
strategy, errors like this should not occur. However, the
transaction log fills up quickly during periods of an exceptionally
high workload, for example during Batch Input or an upgrade. Ensure
that at least 1.5 GB space is available in the transaction log.
SAP AG
TADM53
8-16
R/3 Consistency
Tables, Views and Indexes missing in DB
SAP AG 2003
In this category objects that are defined in the SAP ABAP/4
dictionary but not on the database are displayed. The values are
refreshed once a day.
SAP AG
TADM53
8-17
Database Allocation Monitor: ABAP/4 Dictionary
SAP AG 2003
Objects of the ABAP/4 Dictionary which were not found in the
database are displayed in the Database Allocation Monitor after
choosing button Checks Database ABAP/4 Dictionary. Indexes that
exist in the SAP ABAP/4 dictionary but not on the database can be
created by positioning the cursor on the index and click button
Create on DB.
SAP AG
TADM53
8-18
HealthSQL Server configuration parameters SQL Server and Windows
Build Numbers Errors in the SQL Server Error Log
SAP AG 2003
The health of your SAP System can be judged by monitoring the
effectiveness of parameter settings and watching out for common
errors. The most important alerts to be checked regularly are the
correct settings of the SQL Server configuration parameters, the
correct versions of SQL Server build numbers and errors in the SQL
Server Error Log.
SAP AG
TADM53
8-19
SQL Server Configuration
SQL Server Query Analyzer - [Query - sappod.master.sa -] detail
stats.name minimum maximum config_value run_value
------------- -------- ----------- ------------ --------affinity
mask -2147483648 2147483647 allow updates 0 awe enabled 0 1 1 1
32767 2147483647 2147483647 9999 100 2147483647 1 2147483647 0 1 0
0 5 -1 1033 0 0 0 0 0 0 1 0 0 5 -1 1033 0 0 0 0 0
c2 audit mode 0 cost threshold for parallelism 0 cursor
threshold -1 default fulltext language 0
default language 0 fill factor (%) index create memory (KB)
Lightweight pooling locks 0 704 0 5000
SAP AG 2003
The CCMS Alert Monitor shows a red alert when SQL Server
Parameters have been set, but are not active. To change the
configuration parameters select the server, than select Action
Properties to display the Properties window. A list of SQL Server
configuration parameters can also be retrieved by running
sp_configure in the Query Analyzer. Columns minimum and maximum
display the acceptable range of values. Column config_value
contains the active value. Column run_value contains the value that
is currently set. After changing a configuration parameter using
sp_configure, 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 SQL
Server. Before restarting SQL Server, shut down the SAP System.
SAP AG
TADM53
8-20
SQL Server does not Start
Error in parameter Error in parameter configuration
configuration
SQL Serverinitconfig: Error 2 initconfig: Error 2 (The system
cannot (The system cannot find the file find the file specified.)
specified.)
Books Online
SAP Notes
...Open a problem message Check for error messages
SAP AG 2003
If SQL Server does not start, check the SQL Server error log at
file system level. To get a detailed description of the error
message, use Books Online or the SAP Notes. Because SQL Sever sets
its resources dynamically, an incorrect setting of SQL Server
configuration parameters sometimes causes SQL Server not to start.
To start SQL Server with a minimal configuration, use the option -f
in the sqlservr command. Reconfigure the configuration options
using the sp_configure system stored procedure or the Enterprise
Manager. If the master database is not available, for example due
to a corrupt master file, SQL Server cannot start because it is
unable to read the configuration information. An error starting
with Initconfig appears in the SQL Server error log. If the problem
cannot be solved, create a problem message immediately. Enter the
SQL Server error message.
SAP AG
TADM53
8-21
Applying Service Packs2 1download the current Service Pack
README.txt README.txt
follow instructions in the readme file
3
SAP Application Server
6master msdb
Database Server SQL Server stop the SAP System and SQL
Server
perform a backup and check the installation
5install the Service Pack on the Database Server and all SAP
Application Servers
4master msdb
perform a backup if no current backup exists
SAP AG 2003
SQL Server and Windows build data is displayed in the first two
nodes under Startup parameters in the CCMS Alert Monitor. The
current service pack of SQL Server is always released by SAP. SAP
strongly recommends that the current service pack is installed
immediately when it is available. Explicit exceptions are mentioned
in SAP Notes. The exact SQL Server version appears in the first
line of the SQL error log. The version can also be found out using
the SQL command select @@version. The installation of a service
pack is described in SAP note 417089: Download the current service
pack from the Microsoft Web Server or a CD (1). A service pack
always contains a README file from Microsoft. This file contains
detailed installation instructions (2). Stop the SAP System and SQL
Server (3). SAP recommends that you perform an Windows backup of
all server files after each configuration change. The easiest way
of running a Windows backup is to reboot it from a second Windows
installed in parallel (4). Before installing the service pack, make
sure that a current backup of the master and msdb model databases
exist. Installing a service pack modifies the master and msdb
databases, making them incompatible with older versions of SQL
Server. These backups are required if you decide to reinstall SQL
Server without the service pack. Install the service pack by
opening the SETUP.BAT file (5). Install the service pack on the SAP
application server in the same way as it is installed on the
database server. Perform a Windows backup, back up the master and
msdb databases and check the installation (6).
SAP AG
TADM53
8-22
Error Handling
SAP System Log
SQL Server error log in SQL Server error log in path
X:\Microsoft SQL path X:\Microsoft SQL Server\MSSQL\LOG
Server\MSSQL\LOG
SQL Server Agent error SQL Server Agent error log in path
X:\Microsoft log in path X:\Microsoft SQL Server\MSSQL\LOG SQL
Server\MSSQL\LOG
dev-trace files
Check for error messages in: ! i ?Event Viewer SAP AG 2003
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 Enterprise Manager.
Alternatively, you can directly edit the log files located in
directory X:\Microsoft SQL Server\MSSQL\LOG. SQL Server Agent error
log Use the Database Monitor (Transaction ST04) or the Enterprise
Manager. Alternatively, you can directly edit the log files located
in directory X:\Microsoft SQL Server\MSSQL\LOG. Developer trace
files (Transaction ST11) 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 in
SAPNet.
SAP AG
TADM53
8-23
Some Errors that may Occur
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, 2513, 2540, 8928, 8944,
8952, 8976, ) Resource Problems (Error 845,) Performance Problems
(Error 8645, ) Deadlock (Error 1205, ) Locking problems (Error 601,
) Network errors (Error 11, ) SAP AG 2003
Errors 1105 and 9002 indicate that either a data file or the log
file has run out of space. What to do in such situations, has been
discussed in previous slides. 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 ...) 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. See SAP note 429561 for details on SQL Server error 845.
When SQL Server is low on memory a timeout may occur while waiting
for memory resources to execute a query. In this case SQL Server
error 8645 is shown in the SQL Server error log and an ABAP/4 short
dump occurs. See SAP note 206694 for details. SQL Server error 1205
indicates a deadlocks on a certain table. Known deadlocks are
listed according to the table affected in SAP note 565710. SQL
Server error 601 can have two different causes: either database
inconsistencies or a conflict between two database processes that
were executed at the same time. See SAP note 565708. 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.
SAP AG
TADM53
8-24
Database Consistency CheckMon 12 success Tue 13 success Wed 14
success Thu 15 success Fri 16 0:00 Sat 17 Sun 18
Mon 19 success
Tue 20 success
Wed 21 success
Thu 22 success
Fri 23 2:00 error Fri 30 0:00 DB 9:00 Log Fri 06 0:00 DB 9:00
Log
Mon 26 0:00 DB 9:00 Log Mon 02 0:00 DB 9:00 Log
Tue 27 0:00 DB 9:00 Log Tue 03 0:00 DB 9:00 Log
Wed 28 0:00 DB 9:00 Log Wed 04 0:00 DB 9:00 Log
Thu 29 0:00 DB 9:00 Log Thu 05 0:00 DB 9:00 Log
SQL Server Query Analyzer - [Query - sappod.master.sa -
(untitled)] detail stats. DBCC CHECKDB (PRD) WITH NO_INFOMSGS
SAP AG 2003
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. The Database Consistency Checker (DBCC) is a
system administration tool that verifies pointers internal to a
database and its structure. DBCC commands typically lock user
tables, indexes, and system tables whenever they are run. In
addition, they are 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 SAP 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
SAP Planning Calendar. If the job is highlighted in red, check for
further errors in the SQL Server error log. A file which reports
all errors found is written to X:\Program Files\Microsoft SQL
Server\MSSQL\CCMS_CHECK_DB_HIST_.txt. If the run status is green,
no inconsistencies were found. The SQL Server error log displays
messages: DBCC CHECKDB () started at ... with Logfile: X:\ Program
Files\Microsoft SQL Server\ MSSQL\ CCMS_CHECK_DB_HIST.TXT. DBCC
CHECKDB () executed by found 0 errors and repaired 0 errors.
SAP AG
TADM53
8-25
Database Allocation Monitor: Consistency Check
SAP AG 2003
To perform a database consistency check, you can also use the
Database Allocation Monitor (Transaction DB02). Choose button DBCC
checkdb. Do not run a consistency check on the database while
production work is carried out in the system.
SAP AG
TADM53
8-26
Database Allocation Monitor: Consistency Check on a Table
SAP AG 2003
The Database Allocation Monitor (Transaction DB02) also enables
you to perform a consistency check on a single table. Choose button
Detailed Analysis and specify the table to be checked. In the
following screen, choose button Check Table. A DBCC CHECKTABLE WITH
NO_INFOMSGS is executed on the database for the specified table.
This checks the integrity of the data, index, text, ntext, and
image pages for the specified table.
SAP AG
TADM53
8-27
Database Inconsistencies
DBCC CHECKDB(PRD) DBCC CHECKDB(PRD) executed by executed by
found X errors and found X errors and repaired 0 errors repaired 0
errors ... ...
Books Online
Job 'SAP CCMS Check Job 'SAP CCMS Check Database PRD Database
PRD [20021213174935]' :: [20021213174935]' Step 1, 'Step1' :: Began
Step 1, 'Step1' Began Executing 12/13/02 Executing 12/13/02 6:49:31
PM 6:49:31 PM ... ...
SAP Notes
Open a problem message
Check for error messages Error log messages
SAP AG 2003
If an inconsistency has been detected during the DBCC run, you
must take immediate action to prevent further error escalation and
possible data loss. Check the output of the DBCC check immediately
after each run. If an inconsistency is detected, the job scheduled
with the SAP Planning Calendar is highlighted in red. The SQL
Server error log shows the following message: DBCC CHECKDB()
executed by found X errors and repaired 0 errors Log file X:\
Program Files\Microsoft SQL Server\MSSQL\CCMS_CHECK_DB_HIST.TXT
reports all inconsistencies found. If an error occurs, create a
problem message immediately. Enter the full error text found in the
log files in the problem description. In most cases, you can
correct the inconsistency without data loss. Depending on the type
and location, you may be able to correct the error by removing an
index on a table, or by restoring the database. For a detailed
description of errors, see Books Online or SAP Notes.
SAP AG
TADM53
8-28
No Connection to SQL Server
SQL Server
Database cannot be opened Books Online
Error 1105: Could not allocate space ...
SAP Notes
Open a problem message Check for error messagesError 8651: Could
not perform the requested operation because ...
... SAP AG 2003
If the SAP System cannot connect to SQL Server, the SAP Service
Manager displays a grayed-out dispatcher symbol. Check the
developer trace files located in directory X:\usr\sap\\DVEBMGS\work
for an error description, as follows: A suspect SAP database. In
this case error Error 945: Database cannot be opened because some
of the files could not be activated appears. Similar errors occur
in the SQL Server error log and the Event Log. See Unit 5: Database
Restore. A suspect SAP database. Error 1105: Could not allocate
space for object in database because the PRIMARY filegroup is full
occurs. The status column in table sysdatabases is set to suspect
if SQL Server is unable to complete recovery on a database because
the disk drive no longer has free space. Execute stored procedure
sp_resetstatus , provide additional disk space and restart SQL
Server. See SAP note 81692 for details. Not enough memory. Error
8651: Could not perform the requested operation because the minimum
query memory is not available occurs. Change SQL server
configuration parameters as explained in Unit 3: Performance
Monitoring and Tuning. If the problem cannot be solved, create a
problem message immediately. Enter the error message shown in the
developer trace file. Books Online or the SAP Notes may contain a
detailed description of the error. SAP Note 98678 discusses
connection problems.
SAP AG
TADM53
8-29
Summary of this Unit
Now you are able to:Check for errors and solve common problems
Monitor the growth of the database and the transaction log Extend
the database: Add a disk to an existing volume Add a new volume
Expand data files Perform regular administrative tasks
SAP AG 2003
SAP AG
TADM53
8-30
Further Documentation
ADM100 myTechnology Administration SQL Server Books Online SAP
Notes Best Practices CCMS Monitoring for mySAP
SAP AG 2003
SAP AG
TADM53
8-31
Unit Actions
?
Exercises
Solutions
SAP AG 2003
SAP AG
TADM53
8-32
ExercisesUnit: Regular Maintenance and Error Handling Topic:
Space Management / Database ExtensionAt the conclusion of this
exercise, you will be able to: Monitor the growth of the database
and transaction log Handle a full transaction log Extent a database
on a new volume The customer detects that the transaction log of
his SAP database fills up rapidly and monitors its growth. As soon
as the transaction log is full, he has to resolve the situation.
The SAP database runs out of space on the volume it resides on. The
customer has to extent the database on a new volume. 1-1
Transaction log full 1-1-1 Open a Query Analyzer window and select
the test database. 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. 1-2 Database full, and
extending the database on a new volume 1-2-1 Set the recovery model
to simple on the test database. Open a Query Analyzer window and
select the test 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 test database on a new volume by 4 MB. Choose C:\temp 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? SAP AG TADM53 8-33
SolutionsUnit: Regular Maintenance and Error Handling Topic:
Space Management / Database Extension
1-1
Transaction log full 1-1-1 Monitor the growth of the transaction
log of the test database during the execution of stored procedure
fill_log. In the Enterprise Manager expand the server and the
Databases folder, then mark database test. Select the Tools Taskpad
to display the space usage of database test. Selecting the refresh
button or the F5 key refreshes the display. The Query Analyzer
displays the following message: Server: Msg 9002, Level 17, State
2, Procedure fill_log, Line 12 The log file for database 'test' is
full. Back up the transaction log for the database to free up some
log space. Use command DBCC SQLPERF(LOGSPACE) to display the log
used space. It should display a rate of about 90%. Error message
9002 is displayed in the SQL Server error log and in the Event
Viewer. 1-1-2 The properties of the test database can be displayed
with the Enterprise Manager. Select database test, right
mouse-click and choose Properties. In the Transaction Log Tab, 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. Alternatively,
you can use the SAP Database Allocation Monitor under Tools
Administration Monitor Performance Database DB02 Table/Indexes
(transaction DB02) to display the properties of all the databases
on the database server. Choose Other DB DB list and select the test
database. The column Limit displays the maximum growth. 1-1-3 Back
up the transaction log of the test database. Use either the
Enterprise Manager or the Query Analyzer. Make sure to append the
backup to the existing backups on backup medium R3DUMP3. See the
exercises in Unit4: Database Backup. 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 test database grow to at least 3 MB.
Change the properties in the Enterprise Manager. 1-1-4 Use command
DBCC SQLPERF(LOGSPACE) to display the log used space.
SAP AG
TADM53
8-34
1-2
Database full, and extending the database on a new volume 1-2-1
Go to the Properties window of the test database and set the
recovery model to simple. Choose OK. The transaction log of the
test database will now be truncated every time a checkpoint occurs.
Monitor the growth of database test during the execution of stored
procedure fill_db. In the Enterprise Manager, expand the server and
the Databases folder, then mark database test. Choose View taskpad
to display the space usage of database test. Selecting the refresh
button or the F5 key 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 Analyzer displays the following
message: Server: Msg 1105, Level 17, State 2, Procedure fill_db,
Line 15 Could not allocate space for object 'testtable' in database
'test' 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 test,
true Move database data file F:\mssql7db\MSSQL\data\TestData2.ndf
to C:\temp. Re-attach database test using transact-SQL command
sp_attach_db test, F:\mssql7db\MSSQL\\data\TestData1.mdf,
C:\temp\TestData2.ndf Execute sp_helpfile in the test database to
check the result. Extend both data files by 2 MB each. Use the
Enterprise Manager 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.
SAP AG
TADM53
8-35
FS310 Inkasso/Exkasso Section II - EWB20
Diese Seite wird von Andrea fr euch noch erstell!
SECTION II
EWB20Microsoft SQL Server SQL Cache AnalysisTHE BEST-RUN
BUSINESSES RUN SAP
SAP AG SAP AG 2003 2003
SAP R/3 Release 4.0 2002/Q2 Material Number: 5005 6776
SAP AG
TADM53
9-1
Introduction
Expensive SQL statements affect all users The SAP Stored
Procedure Statistics can be used to:Find and analyze expensive SQL
statements Identify performance issues that are not related to
hardware configuration or SQL Server parameter settings
Performance issues must be reported to the appropriate
people
SAP AG 2002
Database problems are often caused by expensive statements. An
expensive SQL statement does not only affect the user running the
ABAP program containing the statement. It affects other users as
well, since shared database resources are heavily used by expensive
statements. An analysis of the SAP Stored Procedure Statistics
shows up expensive statements. Further the statements can be
analyzed and important information for the improvement is obtained.
With the SAP Stored Procedure Statistics, you can identify
performance issues that are not related to hardware configurations
or SQL Server parameter settings. This course does not cover
hardware, and it only covers a few parameter modifications.
Performance issues must be reported to the appropriate people or
groups, such as: Developers (coding, table, and index design)
Application Designers (customizing and user requirements) SAP
(standard coding, standard index, and table design) Although
specific transactions can be analyzed using other monitoring tools,
such as SQL Trace, these tools are normally used to find specific
problems that affect a small percentage of users. These other
monitoring tools are not covered in this course.
SAP AG
TADM53
9-2
Overview
SQL Server architecture basics SAP Stored Procedure Name Cache
and Statistics SQL statement analysis Workflow and reporting
SAP AG 2002
This workshop begins with a review of the SQL Server
architecture basics, and then moves on to analyzing SQL statements
in the SAP Stored Procedure Name Cache. Several optimization
possibilities are discussed, such as: Creating, changing, and
dropping indexes Changing database view definitions Changing the
access to pooled and clustered tables Modifying Matchcodes This
workshop provides templates for recording and reporting expensive
SQL statements. These templates are to be used by the: System
administrators who are monitoring the system Developers who design
the data model and develop the programs Application department that
customizes the application Users who are processing the reports
SAP AG
TADM53
9-3
Introduction and Technical Background
Contents:MS SQL Server 7.0 architecture review Processing of SQL
statements
SAP AG 2002
Once you have completed this unit you will be able to: Describe
how SQL statements are processed by SQL Server
SAP AG
TADM53
10-1
Introduction and Technical Background Objectives
At the end of this unit you will be able to: Describe how SQL
Server processes an SQL statement
SAP AG 2002
SAP AG
TADM53
10-2
MS SQL Server: OverviewR/3 work processes
MS SQL MS SQL Server Process Server SQL processes: Threadscomm
rd sp crea Background Task Checkpoint Manager Lock Manager Lazy
Writer Log Writer Alert Engine Generic Refresher Data cache
1:n
sel sngl
unc rd
unc rd
...
Database connections: ThreadsLocks, Connections, Open
objects,
Memory area
Procedure cache
Temp. objects .
Database files
Log files Data files
.... master SAP AG 2002
msdb
tempdb
Microsoft SQL Server is a Relational Database Management System
(RDBMS). SQL Server consists of: Database server, or Microsoft SQL
Server Databases: More than one database is administered by a
database server. A SQL Server database consists of at least two
files, one log file and one data file. The SQL Server memory area
contains data structures that allocate memory in SQL Server.The
main types of objects allocated in this area are the data cache,
the procedure cache, the log cache and memory space for temporary
objects. This memory area is defined using parameters min server
memory (MB) and max server memory (MB). The SQL Server is the
ope
