SAP AG Dr. Christian Graf TechEd 2000 Hamburg

SAP AG 2000 TechED Hamburg (Dr. Christian Graf)

Dr. Christian GrafSAP AG

Managing LargeDatabases in the R/3Environment

TechEd 2000 Hamburg


TechEd 2000 Hamburg

Topics:

� Disk Layout

� Shared Memory (32/64 Bit)

� Performance Analysis / DB Tuning

� Backup Strategies


TechEd 2000 Hamburg

Disk Layoutrootdbs

psapddic

psapclu

logdbs

mirrored Dbspace

mirrored Dbspace

psapload

psapstab

psapbtab

psapuser1

physdbs

tmpdbs1

...

psappool

psapprot

psapsource

psapdoku


Standard Installation

Standard R/3 Installation with Informix 7.x

� Dbspaces / chunks randomly allocated to disks

� Attached indexes (data and indexes in the samedbspace)

� No table fragmentation

� Limitations / disadvantages� Maximum table size 32 GB (data + indexes)

� Hot spots on single disks

� Hot spots moving over time

� Runtime problems with administrative tasks(update statistics, drop/create index, oncheck)


tablestables

Traditional Solutions

Load distribution by means of:

� Individual dbspaces for specific tables

� Detached indexes

� Table fragmentationtablestables

viewsviewsinde

xes

inde

xes

inde

xes

inde

xes

tablestables

tablestables

tablestables

tablestables

tablestables


Traditional Fragmentation

Traditional fragmentation recommendation:

Each table fragment resides in its own dbspace!

Advantage:

� Table growth without ‘extent scattering’

Limitations:

� Confusing dbspace/chunk layout if used for many tables

� Difficult to achieve stable I/O balancing

� Detailed space monitoring required (many dbspaces)

� Possible waste of disk space


Data Balancing

� Fragment all growing and heavily accessed tables

� Use 1 set of fragment dbspaces for all fragmented tables(for example, psapcust1, .... psapcust<n>)

� Allocate each fragment dbspace to a different physical disk

� Use separate index dbspace(s)

� Same number of fragments for all tables

� Data distributed over all disks


stripeset

DA1

DB

DA2 DA3 DA4 DA5 DA6 DA7 DA8

stripeset

stripeset

stripeset

psapcust7

psapcust15

psapcust23

psapcust31

stripeset

stripeset

stripeset

stripeset

psapcust6

psapcust14

psapcust22

psapcust30

stripeset

stripeset

stripeset

stripeset

psapcust5

psapcust13

psapcust21

psapcust29

stripeset

stripeset

stripeset

stripeset

psapcust4

psapcust12

psapcust20

psapcust28

stripeset

stripeset

stripeset

stripeset

psapcust3

psapcust19

psapcust27

stripeset

stripeset

stripeset

stripeset

psapcust2

psapcust10

psapcust18

psapcust26

stripeset

stripeset

stripeset

stripeset

psapcust1

psapcust9

psapcust17

psapcust25

psapcust8

psapcust16

psapcust24

psapcust32

Psapbtab Psapdoku

Stripeset 2

Stripeset 3

Stripeset 1

Stripeset 4

Rootdbs (Original) Physdbs (Original) Tempdbs 1Psapindex 1

Psapclu PsapddicRootdbs (Mirror) Physdbs (Mirror) Tempdbs 2

Psapindex 2

Psapstab Psapuser1 Psapload Psapes40BLogdbs (Original) Tempdbs 3

Psapindex 3

Psappool Psapprot Psapsource Psapel40BLogdbs (Mirror) Tempdbs 4

Psapindex 4

Example

psapcust11


Advantages

� I/O load evenly distributed:� Over all disks

� Over all controllers

� No hot spots

� Exploits whole capacities of disk subsystem

� Parallel Database Query possible� Speed up administrative tasks

� Less administrative overhead� Easier monitoring

� Easy to extend *

� No waste of disk space

* as long as the box provides freespace


Important Remarks

� Excessive extent growth must be prevented� Extent growth must be monitored (limit 200 – 400)� Adapt ‘next extent’ sizes if necessary� Ensure appropriate contiguous free disk space on raw

devices

Avoid dbspace reorganization as much as possible!

� Fragmentation imposes an overhead on table accesses

� Do not fragment small tables

!


TechEd 2000 Hamburg

More Details in SAP White Paper:

‚Database Layout for SAP Installationswith Informix‘


TechEd 2000 Hamburg

Shared Memory

� 32-Bit Limits

� SHM_MAGIC for HP-UX

� 64-Bit Availability (Database/Kernel)


Shared Memory

Shared Memory 32-Bit Limits

� HP- UX 1,75 GB (Server)� SOLARIS 3,50 GB (R/3 Instance, DB)

� AIX 2,75 GB

� SINIX 1,60 GB (R/3 Instance, DB)

� Windows NT 2,50 GB (Enterprise Edition)


Shared Memory

Workaround for HP-UX 32-BitShared Memory Magic (SHMEM_MAGIC)� 1 GB memory quadrant usually used for data segments is

reserved for shared memory

� Available for HPUX 10.20 (patch needed) and 11.0

� Special R/3 kernel required (‘sapserv’)

� DB executables must be treated with ‘chatr -M’ command

� Next upgrade requires 64-bit kernel

� More details: OSS Note 106819

Only supported/recommended for 3.1I DCK kernel

4.x customers must use 64-bit kernel/DB version


Shared Memory

64-Bit Informix DB Availability

HPUX 11.0 7.30.FC7XK1

SOLARIS 2.7 7.30.FC7A

AIX 4.3.2 7.30.FC7XK

SINIX 5.44 7.30.FC10

DEC TRUE 64: 7.31.FC4A

Available for 3.1x (3.1I DCK), 4.0B, 45B, 46B, ...

Ordering 64-bit DB CDs: OSS note 115824


Shared Memory

64-Bit R/3 Kernel Availability

HPUX 11.0 4.0B, 45B, 46B

OSF/1: all kernel 64-Bit

SOLARIS: planed in 2000

AIX 4.3.2 planed in 2000

SINIX 5.44 40B, 45B, 46B

General information on SAP 64-bit strategy:http://sapnet.sap.com/dbosplatforms


TechEd 2000 Hamburg

Performance Analysis / DB Tuning


Performance Analysis / DB Tuning

General approach for performance analysis:

� Early Watch sessions

� CCMS monitoring transactions (st03, st04, db02)� Tracing long-running SQL statements using ‘st05’

� DB monitoring using ‘onstat’ tool (memory, I/O, etc.)


General DB Tuning

� I/O balancing

� Shared memory

� BUFFER size: Read: >= 96 % Write: >= 82 % (onstat -p)

� SHMVIRTSIZE: = Size of virtual portion (st04)

only one virtual segment!

� Onconfig parameter (DB and instances on different hosts):

� CPU VPs: (>2 CPU‘s: NUMCPUVPS = #CPU‘s - 1(2))

� LRU queues NUMCPUVPS + 2

� Page cleaners LRU‘s * 2 (testing required)

� Number of locks (<= 30% of total SHM)


Specific DB Tuning

� Analyze query runtimes using ‘st05’:� Identify long-running statements

Actions:� Remove ‘first_rows’ parameter from R/3 profile if exists

� Remove ‘opt_goal’ parameter from onconfig profile if exists

� Provide query plan (SQL explain [st05, dbaccess])

� Is the query plan appropriate?� Adequate access strategy (table scan, nested loop join, hash join, ..)?

� Appropriate indexes used/available?

� Specific update statistics scenario on table(s) required?

� Hint required for optimal query plan?


TechEd 2000 Hamburg

Backup Strategies


Backup Strategies

Size of R/3Databas e

ON-Bar

ON-Archive

Ontape

EBR

18GB 70GB 200G 500GB

BackupDevices

SingleDevice

Sequentia lDevices

Pa ra lle lDevices


� Backups and recoveryon dbspace level

� Sequential and parallelbackups and recovery

� Tape management

� Software compression and backup encryption

� Automatic backups(unattended operation)

� Event tracking with the sysmaster database

� Point-in-time recovery

Informix Backup Tools

Ontape ON-Archive

� Simple to use

� Sequential backups only

� No tape management

� No API to storage management systems

� All ON-Archive functions

� Simpler to use than ON-Archive

� Standardized interface (X/BSA) for storage management

systems from other vendors

� Will become ‘default’ backup tool of Informix

ON-Bar


Backup Strategies

Database sizes up to 200 GB� Use of ON-Archive/ON-Bar

� Full level-0 backup once a week during off-peak hours

� Level-1 backup during weekdays

� Level-2 backup for second half of week if required

� Automatic logical-log backup ideally to one specific tape/day

� ALARMPROGRAM technique to prevent log overflow duringload peaks (for example, batch input)

� Logical-log size: 1 - 4 GB depending on daily workload


Backup Strategies

Database sizes up to 500 GB

� Use of ON-Bar

� Take advantage of high-performance storage managers

� Parallel backup of equally sized ‘dbspacesets’

� Nearly linear scaling in multiprocessor environments

� Incremental parallel backups if required

List of supported storage managers (ON-Bar) see ‘white paper’:

‘Backup Concepts for SAP R/3 Systems on Informix IDS’


External Backup and Restore

Database sizes beyond 500 GB� Backup based on ‘split mirror’ technique

� onmode -c block/unblock:

� Synchronize disk memory

� Detach/split mirror

� Backup on mirrored disks

� Resynchronize main and mirror disk set afterwards

� Downtime: a few seconds/minutes for detaching mirror

� Enterprise storage system required that offers mirrordetaching

� Complex, but most powerful for terabyte databases

rootdbs psapstab psapbtab

Primary Disks

Mirror Disks

rootdbs psapstab psapbtab


Example

P rim a ryD a ta b a s e

S e rv e r

S e c o n d a ryD a ta b a s e

S e rv e rT a p eR o b o t

F D D I B a c k b o n e

E M C ² B o x 1

F S P -1F ile S y s te m P a rtitio n

ID S -1R AID 1 /M irro r

E M C ² B o x 2

F S P -2F ile S y s te m P a rtitio nR A ID 1 /M irro r

ID S -2 ID S -3

B C V

S R D F

S R D F

S h a re d S C S I

S e c o n d a ry S C S I c o n n e c tio n s

8xSC

SI

8xSC

SI


TechEd 2000 Hamburg

Further Information ...� White papers

� Presentations (TechED 2000)

� Supported IDS Versions

� Notes

� .....

http://sapnet.sap.com/dbainf


TechEd 2000 Hamburg

Discussion ...

Documents

SAP AG Dr. Christian Graf TechEd 2000 Hamburg