BC505 Database Administration OracleBC505

Release 4.6C 22.01.2002

0

SAP AG 1999

BC505 Database Administration Oracle

BC505R/3 Release 4.6B 50034335

BC505R/3 Release 4.6B 50034335

Database Administration OracleDatabase Administration Oracle

0.2

SAP AG 1999

Copyright 2001 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.

Copyright

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®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®,

AS/400®, OS/390®, and OS/400® are registered trademarks of IBM Corporation. ORACLE® is a registered trademark of ORACLE Corporation. INFORMIX®-OnLine for SAP and INFORMIX® Dynamic ServerTM are registered trademarks of 

Informix Software Incorporated. UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group. 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. SAP, SAP Logo, R/2, RIVA, R/3, ABAP, SAP ArchiveLink, SAP Business Workflow, WebFlow, 

SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies.

1

SAP AG 1999

SAP Basis Administration Training 4.6

Expert Competence

DatabaseAdministration Training

Core Competence

BC305 3 daysAdvanced R/3 System Administration

MBC30 2 daysR/3-Technical Implementation and Operation Management

Technical Core Competence

BCtcc* 5 days

BC325 3 days

Software Logistics

BC315 3 days

Workload Analysis

BC535 3 daysDatabase AdministrationDB2 UDB

BC530 5 daysDatabase AdministrationDB2/390

Corresponding R/3 Basis Knowledge Product and/or SAP Expert Knowledge Book

BC505 3 daysDatabaseAdministration Oracle

DatabaseAdministration Informix

BC511 5 days

DatabaseAdministration SAP DB

BC515 2 days

BC520 3 daysDatabase AdministrationMS SQL Server

*Technical Core Competence Versions

BC310 Windows NT / OracleBC312 Windows NT / SAP DBBC314 Windows NT MS SQL ServerBC317 (Windows NT / UNIX) / DB2BC360 UNIX / OracleBC361 UNIX / InformixBC362 UNIX / SAP DBBC370 IBM AS400BC390 IBM /390

**BC350 Workplace (combined with MY301)

BC350** 3 days

TCC Workplace

BC555 2 days

LiveCache Administration

BC525 3 daysDatabase AdministrationDB2/400MY301 2 days

Workplace

(C) SAP AG BC505 1

2

SAP AG 1999http://sapnet.sap.com/TechNet

SAP‘s Knowledge Transfer Model

KnowledgeProducts

Technical Certifications

http://sapnet.sap.com/pa

Expert Knowledge Book Series

http://sapnet.sap.com/Books SAP AG 1999 fi lename ( author) / 2

Database Administrat ionSAP DB

BC515 2 days

Core Competence Expert Competence

BC305 3 daysAdvanced R/3 System Administratio n

*Technical Core Competence Versions

BC310 Windows NT / OracleBC314 Windows NT MS SQL ServerBC317 (Windows NT / UNIX) / DB2BC360 UNIX / OracleBC362 UNIX / SAP DB

MBC30 2 daysR/3-Technical Imp lementation an d Ope ration Management

Technical Core Competence

BCtcc* 5 days

Corresponding R/3 Basis Knowledge Product

BC505 3 daysDatabase Administrat ionORACLE

BC325 3 days

Sof twa re Logis tics

BC520 3 daysDatabase Administrat ionMS SQL Server

SAP Basis Administration Training 4.6

BC535 3 daysDatabase Administrat ionDB2 UDB

SAP AG KTM mySAP.com for Techn. Impl., IT Cons., Sys. Integration UH / 7

Technical Optimi zation of Pricing

EWA10 (SD) 2 days

Technical Optimi zation of Due List Processing

including Scheduling

EWA11 (SD) 2 days

Technical Optimi zationof Batch Determination

EWA13 (SD) 2 days

Technical Optimi zation of Credit Management

EWA14 (SD) 2 days

Technical Optimi zation of Text Determination

EWA15 (SD) 1 day

Technical Optimi zation of Product Selection

EWA16 (SD) 1 day

Technical Optimi zation of Partner Determination

EWA17 (SD) 1 day

Technical Optimization of Backflushi ng of Production Orders

EWA12 (PP) 2 days

Technical Optimization of the Availabili ty Check

EWC10 (SD/PP) 2 days

Technical Optimization of MRP Run and

Long Term Planning

EWA20 (PP) 2 days

Technical Optimi zation of Profitability Analysis

EWA18 (CO) 2 days

Technical Optimi zationof Calculation of Production Orders

EWC13 (PP/CO) 2 days

Technical OptimizationShipping and

Warehouse Management

EWC16 (SD) 2 days

Empowering Workshops - Application and CrossApplication

IBU specificand GlobalWorkshops

Technical Optimization of Configuration

of Variants

EWC11 (SD/PP) 2 days

Empowering Workshops

Technical Training and Workshopshttp://sapnet.sap.com/EducationServices

http://sapnet.sap.com/BasisKnProd

SAP GoingLive Check http://sapnet.sap.com/GoingLiveCheck

SAP EarlyWatch Service http://sapnet.sap.com/EarlyWatch

SAP EarlyWatchAlert http://sapnet.sap.com/EWA

SAP Consulting Services http://sapnet.sap.com/ConsultingServices

TeamSAP Support http://sapnet.sap.com/TeamSAPsupport

(C) SAP AG BC505 1

3

SAP AG 1999

Course Overview

(C) SAP AG BC505 1

3.2

SAP AG 1999

Course Prerequisites - Target Group - Duration

Prerequisites:

SAP050 basis technology

Technical core competence BC310 or BC360 (depending on the operating system used)

Profound knowledge of the operating system and the Oracle database

Target group:

Project teams

System administrators

Database administrators

Duration:

Three days

(C) SAP AG BC505 2

3.3

SAP AG 1999

This course will enable you to:

Define, perform, and monitor an appropriate database backup strategy

Monitor and administrate your R/3 Oracle system by using the:

R/3 database monitors

Database administration tools offered by SAP

Identify performance problems by monitoring the R/3 System

Course Goals

(C) SAP AG BC505 3

3.4

SAP AG 1999

Unit 6 Advanced Backup Techniques

Unit 7 Storage Management

Unit 8 Performance Monitoring

Unit 9 Top 10 Problems

Unit 1 Database Overview

Unit 2 Backup Strategy and Tape Management

Unit 3 Scheduling, Performing and Monitoring Backups

Unit 4 Restore and Recovery

Unit 5 Backup Strategies Using RMAN

Course Overview

Conclusion

Course Content

(C) SAP AG BC505 4

4

SAP AG 1999

Database Overview

1 Database Overview 6 Advanced Backup Techniques

2 Backup Strategy and Tape Management

7 Storage Management

3 Scheduling, Performing,and Monitoring Backups

8 Performance Monitoring

4 Restore and Recovery 9 Top 10 Problems

5 Backup Strategies Using RMAN

(C) SAP AG BC505 1

4.2

SAP AG 1999

Database Overview

Contents Database components Oracle Process architecture Net8 Basics Database administration tools

ObjectivesAt the end of this unit, you will be able to: Describe the different Oracle processes and their functions Explain the role of Net8 Name the important database administration tasks

This course is designed to be operating system platform-independent. If you are using Windows NT, you must substitute certain terms and notations. Oracle on the Windows NT operation system uses the Windows NT implementation of threads.

Windows NT threads are comparable to processes in a UNIX environment. In most cases, you can substitute the UNIX term process by the NT term thread. However, all Oracle processes (except the Oracle listener) form one Oracle process in the Windows NT environment. This process is started as a service called OracleService<SID>. To enable network communication, the Oracle listener process in the NT implementation of the Oracle database is started as a service called OracleTNSListener.

The directory separator sign used here is the “/” sign. For Windows NT, the “\” sign is used. The current value of a UNIX environment variable is obtained using $VARIABLE_NAME. For

Windows NT, the syntax %VARIABLE_NAME% is used to obtain the value of a variable. For Oracle on UNIX, the naming convention for the listener controller program is lsnrctl. For

Oracle on NT, the naming convention depends on the release:Oracle 8.0: lsnrctl80 Oracle 8.1 and above: lsnrctl

When you have completed this training unit you will have refreshed your knowledge about the architecture of the Oracle database.

(C) SAP AG BC505 2

4.3

SAP AG 1999

Processes

Memory area

Database files

WP Reconnect:rsdb/reco_trials = 3rsdb/reco_sleep_time = 5

RDBMS

Controlfiles Data files

Online redo log files

Offline redolog files

Profile

SGASGA Database buffer pool Database buffer pool

Shared pool Shared pool

Redo log bufferRedo log bufferShared SQL Area

Configurable(init<SID>.ora)

Row cache

Shared processes

AR

CH

AR

CH

CK

PT

CK

PT

LG

WR

LG

WR

DB

WR

DB

WR

PM

ON

PM

ON

SM

ON

SM

ONOracle listener processOracle listener process

R/3 work processes

Sh

ado

wS

had

ow

Sh

ado

wS

had

ow

Sh

ado

wS

had

ow

1:1

Review: Oracle Overview

When an Oracle database instance is started, several processes are created. The groups of processes are distinguished as follows: Dedicated shadow processes are created when a new user session on the database is established Shared processes perform the various tasks that are required for the database management system

to function Database data is stored in 8 KB blocks in data files on disk. To accelerate read and write access to

data, these data blocks are cached in the database buffer pool in main memory. Modifications to database data are logged in the online redo log files. This procedure ensures data

security. To ensure fail-safe database operation, without using additional operating system utilities, the control files and the online redo log files of the database system should be mirrored.

The Oracle database management system holds the executable SQL statements in the Shared SQL Area, which is part of the shared pool.

Each R/3 work process: Connects to the database as one database user, SAPR3 Handles database requests for the different R/3 System users Communicates with a corresponding shadow process on the database Can reconnect to the database

(C) SAP AG BC505 3

4.4

SAP AG 1999

R/3 in a Windows NT Environment

OS User OS Group Database User Database Privileges

<SID>adm ORA_<SID>_DBA INTERNAL (SYS), Full database administration OPS$<SID>adm

SAPService<SID> ORA_<SID>_OPER OPS$SAPService<SID> Restricted database administration

R/3 in a Windows NT Environment

OS User OS Group Database User Database Privileges

<SID>adm ORA_<SID>_DBA INTERNAL (SYS), Full database administration OPS$<SID>adm

SAPService<SID> ORA_<SID>_OPER OPS$SAPService<SID> Restricted database administration

R/3 in a UNIX Environment

OS User OS Group Database User Database Privileges

ora<SID> dba, oper INTERNAL (SYS) Full database administration

<SID>adm oper OPS$<SID>adm Restricted database administration

R/3 in a UNIX Environment

OS User OS Group Database User Database Privileges

ora<SID> dba, oper INTERNAL (SYS) Full database administration

<SID>adm oper OPS$<SID>adm Restricted database administration

Profile init<SID>.oraOS_AUTHENT_PREFIX=OPS$

Privileges required for SAPDBAbackground actions such as backup, check, -checkopt,-analyze, -next

Restricted database administration

Access to tables required for R/3 database administration

Privileges required for SAPDBAbackground actions such as backup, check, -checkopt,-analyze, -next

Restricted database administration

Access to tables required for R/3 database administration

Security: Operating System and Database Users

To ensure the security of your R/3 System, you must consider the security of the operating system and database users. Operating system users have certain privileges for accessing files and executing programs. Database users have different privileges for changing tables and indexes.

Oracle mechanisms move the entire database security mechanism to the operating system level. If the user OPS$<user_name> is defined as identified externally at the database level, the operating system user <user_name> can connect to the database without authentication.

The following OS and database users are available for Oracle administration in an R/3 System: UNIX: ora<SID> (no OPS$ user), <SID>adm, and OPS$<SID>adm Windows NT: <SID>adm, OPS$<SID>adm and SAPService<SID>, OPS$SAPService<SID>

The following OS groups are important in an Oracle database environment (see also Appendix): dba (NT: ORA_<SID>_DBA): OS users of this group can connect to Oracle using CONNECT

INTERNAL with full database administration privileges oper (NT: ORA_<SID>_OPER): OS users of this group can connect to Oracle using CONNECT

INTERNAL with restricted database privileges, such as startup or shutdown database The database administration tool SAPDBA requires the restricted database administration privileges

available in the group oper. SAPDBA only has access to the tables required for performing R/3 database administration in the background. These privileges are assigned during R/3 installation or upgrade.

(C) SAP AG BC505 4

4.5

SAP AG 1999

OracleOracle

R/3 workprocess

R/3 application server

Database server

TableSAPUSER

Get password for user SAPR3 from table SAPUSER

Disconnect user OPS$Connect as user SAPR3

OPS$ user:UNIX: OPS$<SID>admNT: OPS$SAPService<SID>

init<SID>.ora parameterREMOTE_OS_AUTHENT = TRUE

Connect as user OPS$

Security: SAPR3 Password

The following mechanism is used by an R/3 work process to connect to the database as user SAPR3: A connection to the database is made as user OPS$ (UNIX: OPS$<SID>adm, NT:

OPS$SAPService<SID>) with very few privileges. User OPS$ is the owner of table SAPUSER. From this table, the password for user SAPR3 is

retrieved and the database session for user OPS$ is terminated. The work process now connects as user SAPR3 with the password from table SAPUSER.

To allow R/3 work processes to connect over the network using the OPS$ mechanism, the init<SID>.ora parameter REMOTE_OS_AUTHENT must be set to TRUE. This allows remote OS authentication for OS users with an OPS$ user on any computer in the network in which the database is accessible.

To change the password of user SAPR3, perform the following:For UNIX: Use program SAPDBA to perform the required actionsFor NT: Connect to Oracle as user OPS$SAPService<SID>, and: Change the password entry for user SAPR3 in table SAPUSER Change the password of user SAPR3

As of version 4.5B, user SAPR3 is stored with an encrypted password in table SAPUSER.

(C) SAP AG BC505 5

4.6

SAP AG 1999

Net8Net8

TCP/IPTCP/IP

R/3 work process

R/3 work process

R/3 work process

R/3 application server

ShadowShadow

tnsnames.orasqlnet.ora

ShadowShadow

ShadowShadowShadowShadow

R/3 work process

Net8 Net8 IPCIPC

tnsnames.orasqlnet.ora

listener.ora

Database server

OracleOracleListenerListener

NET8 Basics

If an R/3 instance is running on a server other than the database server, R/3 work processes and their dedicated shadow processes communicate over a network. As communication protocol, TCP/IP is used. The work processes of an R/3 instance configured on the database server use the IPC protocol to communicate with dedicated shadow processes running on the same server.

For Net8 to accept connections on the database server, the listener must be running. The Oracle utility lsnrctl is used to start and stop the listener and to check the status of Net8 connections. In a UNIX environment, the process tnslsnr is started. On NT, the service "OracleTNSListener" is started.

Three operating system files are used in a NET8 configuration. You can find these files in the ORACLE_HOME subdirectory network/admin (NT: net80\admin) on each application server and on the database server: tnsnames.ora: Contains a list of service names for all databases that can be accessed in the

network sqlnet.ora: Contains client side default domain information and optional diagnostic parameters

used for client tracing and logging listener.ora :Only used on a database server machine. Contains Oracle system IDs for which the

listener can receive connections, and various control parameters used by program lsnrctl The default R/3 System profile should contain the entry dbs/ora/tnsname = <SID>

(C) SAP AG BC505 6

4.7

SAP AG 1999

BankBank

Database Administration Tools

LiveR/3 System

SAPDBA

T.D.

To fix the problem, use the monitoring tools and database administration tools

provided by SAP

ST04DB02

DB24

RZ20

SAPDBA

Poor performance

To improve performance and to minimize system downtime, you must monitor the Oracle database daily. The Computing Center Management System provides the following monitors: The Database Performance Monitor (transaction ST04) displays an overview of the load and

configuration of the database management system and the database. The Tables and Indexes Monitor (transaction DB02) displays an overview of the storage behavior

of the database and the status of the database objects. The DBA Operations Monitor (transaction DB24) provides you with a central point from which

you can check the status and logs of all database operations, including backup monitoring, updates of the optimizer statistics, and dba checks.

The Database Alert Monitor (can be started from transaction RZ20) is a tool you can use to monitor all the preset alerts for different areas of the database.

(C) SAP AG BC505 7

4.8

SAP AG 1999

Database Performance Monitoring (ST04)

Shared SQL

quality

Shared SQL

quality

Oracle data

buffer quality

Oracle data

buffer quality

User calls

statistics

User calls

statistics

Reset Since reset Since DB start Detail analysis menu Previous days Summary

Data buffer

Shared Pool

Calls

Log buffer

Database QAS Database summary Day, Time 08/19/1999 16.57:46DB Server TWDFMX04 Start up at 08/19/1999 16.59:42Release 8.0.5.1.1 Elapsed since start (s) 86,284

Size kbQuality %

Size kb

reloads/pins %

DD-Cache quality %

pinratio %SQL Area getratio %

User callscommitsrollbacks

103,424

Redo log buffer quality

Redo log buffer quality

145,920

64.8 90 94

0.046

99.3

236,764 3,072 171

Size kbEntriesAllocation retriesAlloc fault rate %Redo log wait sLog files (in use)

Recursive callsParsesUser/Recursive callsReads/User calls

ReadsPhysical reads

writesBuffer busy waitsBuffer wait time s

36,204,681 246,629 10,641

61 1

328 71,969

1 0.0 0

8 (6)

From the R/3 main screen, choose Tools Administration Monitor Performance Database Activity (or use transaction ST04).

The main screen of the SAP/Oracle Database Monitor shows the most important indicators of Oracle database performance, such as data buffer, shared pool buffer, user calls, and table scans/table fetch.

The Detail analysis menu takes you to the detailed level of performance related analysis. Here, you can analyze database activity from the point of view of, for example, Oracle sessions, file system requests, and SQL requests to the database.

You can also view the Oracle alert file, monitor any changes to the parameter file for Oracle, and monitor database lock-waits.

The monitor takes a snapshot of the system at a freely selectable reference point (usually at database start). You can use the following to change this reference point: Reset sets the reference point to the current point in time Since DB start sets the reference point to the time of the database start Since reset sets the reference point back to the last reset point

(C) SAP AG BC505 8

4.9

SAP AG 1999

Database Space Monitoring (DB02)

Overall check for

the database

Overall check for

the database

Check at tablespace

level

Check at tablespace

level

Check at object

level

Check at object

level

Tables and Indexes

Tablespaces

Database system

Total numberTotal size/kb

More than 1 extent

Missing in database

Missing in R/3 DDICSpace-critical objects

Tables Indexes Detailed analysis

Missing indexes

Space critical objects

Space statistics

Space statistics

Current sizes

Freespace statistics

Total number

Total size/kb

Total free/kb

Minimum free/kb

Max. autoextensible/kb

Database

NameDate/time of this analysis

Refresh Checks Space statistics

19,299

7,026,064

1,351

0

0

0

22,449

3,783,600

1,851

0

0

0

27

18,090,848

7,083,096

4,040

AutoExtend off

39%

ORACLE

QAS

08/12/1999 13:42:05

From the R/3 main screen, choose Tools Administration Monitor Performance Database Tables / Indexes. Alternatively, use transaction DB02.

In the section Database system check, you can refresh the statistics, look at the database history (Space Statistics), or check the storage parameters for tablespace and tables/indexes. You can also check for the optimizer statistic runs.

In the Tablespaces section, options are available for analyzing tablespaces. You can view a complete list of tablespaces with details of, for example, size, freespace, used space, number of objects, and number of extents. You can trace the growth of a tablespace over a particular time period, and track changes to size, extents, and so on.

The Tables and indexes section displays the objects in this tablespace. The sizes of the objects (in kilobytes and blocks) are displayed, and the number of used extents and the value defined for the object for MAXEXTENTS are also displayed. In this section, you can monitor indexes that are defined in the ABAP Dictionary but are missing in the database (missing indexes) or indexes that are created in the database but are unknown to the ABAP Dictionary.

(C) SAP AG BC505 9

4.10

SAP AG 1999

DBA Operations Monitor (DB24)

Overview of all, running and

finished operations on database

Overview of all, running and

finished operations on database

Click to display errors only

Click to display errors only

Click to display all operations

Click to display all operations

Click to display warning only

Click to display warning only

Displays specific database operations

chosen by the corresponding push button on the toolbar

Displays specific database operations

chosen by the corresponding push button on the toolbar

All Running Finished

Total

Warning

Error

Overview

Backup/recovery Performance Memory structure Check sessions ConfigurationAll database operations

Setup

Status TimeDate FID Object Runtime Program Description

Refresh every

Delete after

View: the last

10 seconds

111 days

10 days

OK OK OK

WarningWarning

ErrorError

Total Total

COMPLETED

COMPLETED

COMPLETED

COMPLETED

COMPLETED

COMPLETED

COMPLETED

COMPLETED

COMPLETED

COMPLETED

COMPLETED

24.08.19 ...

24.08.19 ...

24.08.19 ...

22.08.19 ...

22.08.19 ...

21.08.19 ...

20.08.19 ...

20.08.19 ...

17.08.19 ...

17.08.19 ...

17.08.19 ...

23:08: ...

16:24: ...

16:06: ...

10:35: ...

02:01: ...

02:01: ...

13:09: ...

10:20: ...

19:22: ...

15:30: ...

14:40: ...

anf

anf

svd

svd

svd

svd

svd

svd

svd

aly

opt

database

database

database log

database log

database log

database log

database log

database log

database log

DBSTATCO

PSAP%

01:49:46

00:09:34

00:14:07

00:17:44

00:02:02

00:10:24

02:14:46

00:08:04

00:13:06

00:01:41

00:05:00

BRBACKUP

BRBACKUP

BRARCHIVE

BRARCHIVE

BRARCHIVE

BRARCHIVE

BRARCHIVE

BRARCHIVE

BRARCHIVE

SAPDBA

SAPDBA

whole online database backup using backint

whole online database backup using backint

first backup and deletion of archivelogs

first backup and deletion of archivelogs

first backup and deletion of archivelogs

first backup and deletion of archivelogs

first backup and deletion of archivelogs

first backup and deletion of archivelogs

first backup and deletion of archivelogs

check need of new db-optimizer-statistics

create / refresh db-optimizer statistics

8

3

0

11

0

0

0

0

3

8

0

11

Double-click hereto see more details

Use the DBA operations monitor for online monitoring of database operations. You can also monitor the runtime and the remaining time of operations that are running. The DBA operations monitor provides historical as well as current (online) information about the following database operations: Backup/recovery (for example, backing up or recovering the database) Performance (for example, checking, creating, updating and deleting database statistics) The memory structure (for example, space information for database objects, reorganizing database

objects, or extending and deleting database objects). Database checks (for example, checking the database for critical situations) Configuration (for example, configuring database parameters)

To call the DBA operations monitor, choose Tools CCMS DB administration Operations monitor. Alternatively, use transaction DB24.

To display specific database operations (for example, backup/recovery operations), choose the corresponding button.

To automatically refresh the display of database operations, choose Setup Auto-refresh Activate. To set the time interval for the refresh, choose Setup Auto-refresh Time Interval.

For details about operations (for example, the remaining time for the operation, or the directory and name of the log file), double-click the table entry, or select the table entry and choose Display details on the application toolbar.

(C) SAP AG BC505 10

4.11

SAP AG 1999

DBA Alert Monitor (RZ20)

You can monitor :

Tablespaces

Performance

Backups

Database connections

SQL statements

R/3 System log

Database host operating

system

Pre-defined template for Oracle database monitor in RZ20

space management

performance

backup/restore

R/3 consistency

health

SAP CCMS Monitor Templates (Database . . .

Database

Oracle

View: Current system status (08/12/1999 , 14:46:48

tablespacessegments

optimizerbufferscheckpoints

archivingbackup status

objects missing in the databaseunknown objects in ABAP Dictionaryinconsistent objectsother checksoptional indexes

running jobs

database files

Expert analysis , Node display off

Open alerts Properties

The alert monitor in CCMS allows you to centrally monitor different parts of the Oracle database. You can configure analysis and data collection tools for different types of alerts. Use the following menu path: Tools CCMS Control/Monitoring Alert monitor. Alternatively, use transaction RZ20. You can find the Database monitor under SAP CCMS Monitor Templates.

You can monitor, for example, the freespace left in the tablespace, table/indexes with too few allocable extents, segments approaching MAXEXTENT, and the failure of rollback segment extensions.

You can monitor the performance of the database system by looking at alerts for the optimizer, the Oracle buffer/cache area, and buffer gets of SQL statements.

You can monitor the backup status and the status of the /oracle/<SID>/saparch directory.

(C) SAP AG BC505 11

4.12

SAP AG 1999

SAPDBA (OS Level)

h - Backup databasei - Backup offline redo logsj - Restore/Recoveryk - DB check/verificationl - Show/Cleanupm - User and Securityn - SAP Online Help Log info

and more

Versionnumber

CallBRARCHIVE

SAPDBA V4.6C - SAP Database Administration

ORACLE version: 8.0.5.1.0ORACLE_SID: TCCORACLE_HOME: /oracle/TCCDATABASE: openSAPR3: 46B, 25 times connected

Databasestate

Call BRBACKUP

a - Startup/Shutdown instanceb - Instance informationc - Tablespace administrationd - Reorganizatione - Export/importf - Archive modeg - Additional functions

q - Quit

Please select ==> I

Start or stopdatabase

Start HTML help

Perform recovery

Reorganize table or data file

Add space

To start SAPDBA, run command sapdba at command line. SAPDBA includes the following components for administrating the Oracle database:

Database backup, restore and recovery Space management Database system check Database reorganization Cost-based optimization of access

You can call up the SAPDBA functions from an ASCII interface, or you can use a command option to configure and execute the functions individually. The administration tool SAPDBA for Oracle and its backup tools BRBACKUP, BRARCHIVE and BRRESTORE support the database administrator both in daily routine tasks and in less frequent, more complex tasks, such as recovering or reorganizing the database.

You can use the SAPDBA functions from the CCMS, since it meets the R/3 System’s application-specific requirements. SAPDBA is delivered as standard with the R/3 System.

If you call SAPDBA with any command options, the SAPDBA initial menu does not appear. Instead, you can perform operations that do not require interaction with the end user.

To enable SAPDBA to function properly, you must configure init<SID>.dba file. Make sure you have the latest patch installed for SAPDBA. To check SAPDBA’s patch management

concept, refer to SAP Notes 126769 and 141999.

(C) SAP AG BC505 12

4.13

SAP AG 1999

Unit Summary

Now you are able to:

Explain the basic concepts of the Oracle database

Address security issues

Explain Oracle communication over a network (NET8)

Understand which tool to use for each part of the Oracle database

The Oracle database system can be operated only when it is configured correctly. To make configuration changes, you need a basic knowledge of its components.

The connection process and database administration are the two greatest security risks. You need to know how to address these risks.

In the R/3 System environment, each individual database component is created following the standard naming convention. These conventions simplify database administration, because they are automatically used by the various R/3 database administration tools.

NET8 is used to communicate with the Oracle database over the network. To ensure that network communication functions properly, you need to know the basic configuration files and their contents.

(C) SAP AG BC505 13

4.14

SAP AG 1999

Additional Course Slides

Contents:

Appendix

(C) SAP AG BC505 14

4.15

SAP AG 1999

Oracle processesOracle processes::

Data files

Profile

Online redo log files

Offline redo log files

Database buffer pool

Redo log buffer

AR

CH

AR

CH

CK

PT

CK

PT

LG

WR

LG

WR

DB

WR

DB

WRNomount

Mount

Open

Control files

Shared pool

PM

ON

PM

ON

SM

ON

SM

ON

Oracle listener processOracle listener process

SGA

Appendix: Starting and Stopping the Database

When an Oracle database is started, it goes through 3 phases: In the No mount phase, the database instance is built up. Operating system resources are allocated

using configuration information stored in the profile init<SID>.ora. In the Mount phase, the control files of the database are evaluated. The system reads the

information about the file structure of the database. Data files and logs are not yet opened. In the Open phase, all files in the database system are opened. If required, an instance recovery is

performed immediately after opening the database. Pending database transactions are ended. You can shut down the database using one of three commands:

SHUTDOWN NORMAL: No new database logon possible. After all database user have logged off, the database is closed systematically: all files are closed, the database is dismounted, and the instance is shut down. The database is consistent after shutdown.

SHUTDOWN IMMEDIATE: Only the current commands are executed. PMON ends all sessions and performs a rollback of the open transactions. The database is then closed systematically (as for a normal shutdown). The database is consistent after shutdown. Caution: DBWR and ARCH may require up to 1 hour post-processing time.

SHUTDOWN ABORT: Emergency database shutdown. Users are not logged off, and a rollback of the open transactions is not performed. The database is not consistent after shutdown. An instance recovery is automatically performed at the next database startup.

(C) SAP AG BC505 15

4.16

SAP AG 1999

Data files

Profile

Database buffer pool

Redo log buffer

ARCHARCH

LGWRLGWR

Processes Processes andand memorymemory

Profile init<SID>.oralog_archive_start = TRUE log_archive_dest = ?/saparch/

CKPTCKPT

Control files

Online redo log files

Offline redo log files ARCHIVELOG MODE: TRUE

DBWRDBWR

Appendix: Writing Data and Log Files

An Oracle database system has three processes that write information from the Shared Global Area (SGA) to the appropriate files: During a checkpoint, the database writer (DBWR) asynchronously writes the changed blocks from

the SGA to the database data files To speed up the writing of checkpoints, the checkpoint process (CKPT) is started The logwriter (LGWR) synchronously writes the change log from the SGA redo log buffer to the

currently active online redo log file In a production database system, the database must always run in ARCHIVELOG mode and have

the archiver process (ARCH) started (init<SID>.ora: log_archive_start = TRUE). ARCH archives a completed online redo log file into an offline redo log file in the archive directory.

ARCH determines the archive directory from the init<SID>.ora parameter log_archive_dest (default: ?/saparch/) and determines the file name from the parameter log_archive_format.

Once the offline redo log file has been successfully created, the corresponding online redo log file is released to be overwritten with new log information.

If no freespace is available in the archive directory, the archiver does not archive the file. After a corresponding number of redo log switches, the database becomes "stuck". Database changes cannot be committed as long as this archiver stuck situation persists.

(C) SAP AG BC505 16

4.17

SAP AG 1999

Appendix: Storage Management Concepts

Extent

Data Block

Segment(Table/Index)

8K

200K 150K

350KData file

Tablespace

A database is divided into logical storage units called tablespaces. Tablespaces are divided into logical units of storage called segments (tables/indexes). Segments are further divided into extents, which consist of contiguous data blocks. A data block (normally 8K) is the smallest unit of I/O used by a database.

A tablespace in an Oracle database consists of one or more physical data files. A data file can be associated with only one tablespace. You can increase a tablespace in two ways: Add a data file to a tablespace. When you add another data file to an existing tablespace, you

increase the amount of disk space allocated for the corresponding tablespace. Increase the size of a data file.

Storage parameters such as INITIAL EXTENT, NEXT EXTENT and MAX EXTENT allow you to manage space allocated to a table.

For performance reasons, operating system block size should be the same as Oracle data block size.

(C) SAP AG BC505 17

4.18

SAP AG 1999

Prefix Abbreviation ExtensionPSAP <TS_name> D (data) or I (index) Physical

layer

<TS_name>.data1btabd.data1

<TS_name>.data2btabd.data2

Logicallayer

<TS_name>_1btabd_1

Tablespacename

<TS_name>_2btabd_2

PSAP<TS_name>PSAPBTABD

Directorynames

Filesnames

Prefix Tablespace name Ext. Meaning Used bySYSTEM Oracle DDIC Oracle RDBMS

PSAP ROLL Rollback segments Oracle RDBMSPSAP TEMP Sort processes Oracle RDBMSPSAP EL<Release> D or I Development environment loads R/3 BasisPSAP ES<Release> D or I Development environment sources R/3 BasisPSAP LOAD D or I Screen and report loads (ABAP) R/3 BasisPSAP SOURCE D or I Screen and report sources (ABAP) R/3 BasisPSAP DDIC D or I ABAP Dictionary R/3 BasisPSAP PROT D or I Log-like tables (for example, spool) R/3 ApplicationsPSAP CLU D or I Cluster tables R/3 ApplicationsPSAP POOL D or I Pool tables (for example, ATAB) R/3 ApplicationsPSAP STAB D or I Master data and transparent tables R/3 ApplicationsPSAP BTAB D or I Transaction data, transparent tables R/3 ApplicationsPSAP DOCU D or I Documentation, SAPscript, SAPfind R/3 ApplicationsPSAP USER1 D or I Customer tables R/3 Applications

Appendix: R/3 Naming Conventions

The Oracle database uses tablespaces. From a logical point of view, a tablespace is a container for database objects, such as tables and indexes. On disk, a tablespace consists of one or more data files. You can increase the capacity of a tablespace by adding files to it.

The R/3 naming convention for tablespace names is defined as follows: PSAP<tablespace_name><extension>.

The abbreviations in the tablespace name are part of the directory name and file name of each data file. Directories and data files are numbered.

The objects located in the tablespaces SYSTEM, PSAPROLL, and PSAPTEMP belong either to the Oracle database users SYS or SYSTEM. Do not create any objects owned by other users in these tablespaces.

The objects located in the other tablespaces belong to the R/3 database user SAPR3. R/3 System users do not have a database system user.

The R/3 System and SAP tools, such as SAPDBA, require that the naming conventions be observed. The installed system constitutes a logical unit, which you should not change. In this way, SAP can ensure that you receive fast and efficient support.

(C) SAP AG BC505 18

4.19

SAP AG 1999

Directory Contains File name examples

dbs SAP and Oracle profiles, init<SID>.ora, init<SID>.dba, init<SID>.sap

bin Oracle executables

saptrace Background (Oracle alert file)usertrace

sapdata1 Datafiles /btabd1/btabd.data1, system.data1,

. ctrl<SID>.dbf, /btabi1/btabi.data1

.

sapdata<n>

sapbackup BRBACKUP, BRRESTORE logs

saparch BRARCHIVE logs, Oracle archive dir ctrl<SID>.dbf

sapcheck SAPDBA logs (-next, -check, -analyze)

sapreorg SAPDBA logs(default),default compression directory

origlogA Online redo log files log_g101m1.dbf, log_g103m1.dbf

origlogB Online redo log files log_g102m1.dbf, log_g104m1.dbf

mirrlogA Online redo log files log_g101m2.dbf, log_g103m2.dbf

mirrlogB Online redo log files log_g102m2.dbf, log_g104m2.dbf

. . .

Profile init<SID>.oralog_archive_format = %t_%s

Appendix: Oracle Directory Structure in R/3

Directory and file names are standardized in the R/3 environment. We recommend that you use the following standards: Tablespace files reside in the sapdata<n> directories The online redo log files reside in the origlog and mirrlog directories The offline redo log files are written to the saparch directory There should be at least 3 copies of the Oracle control file on different disks The profile init<SID>.ora configures the Oracle instance, and resides in directory dbs

(NT: database) The profile init<SID>.sap configures the backup tools brbackup and brarchive, and resides in

directory dbs (NT: database) The profile init<SID>.dba configures the SAPDBA tool, and resides in directory dbs

(NT: database) The Oracle alert file is written to directory saptrace/background Trace files of the Oracle shadow processes are written to the directory saptrace/usertrace During reorganization, export datasets are written to directory sapreorg

The directories saparch, sapcheck, sapreorg, and sapbackup are used by the SAP database tools.

(C) SAP AG BC505 19

4.20

SAP AG 1999

Server site

dbs(NT:database)

binnetwork/admin

(NT: net80\admin)

ORACLE_HOMEoriglogB

mirrlogB

sapdata<n>

sapbackup

sapreorg

...

sapdata1

origlogA

mirrlogA

saparch

sapcheck

saptrace

SAPDATA_HOME

Client site

ORACLE_HOME

network/admin(NT: net80\admin)

UNIX environment variables (client site)ORA_NLS: $ORACLE_HOME/ocommon/NLS_723/admin/data ORA_NLS32: $ORACLE_HOME/ocommon/NLS_733/admin/data ORA_NLS33: $ORACLE_HOME/ocommon/NLS_805/admin/data

Appendix: Oracle Directories/Environment Variables

The Oracle database file tree structure on the database server site has two main branches: The Oracle binaries are located in the subdirectory bin of the ORACLE_HOME directory. The

environment variable ORACLE_HOME points to this directory. The ORACLE_HOME directory is also required on each server with a database client

The environment variables SAPDATA_HOME and SAPDATA<n> point to the directories containing database-specific files, such as data files, online redo log files, and offline redo log files

The operating system users <SID>adm and ora<SID> (on the database server, not used in an NT environment) require the following environment variables: ORACLE_SID = <SID> (on the database server site) DBS_ORA_TNSNAME: set to the database identifier <SID> from tnsnames.ora

In a UNIX environment, the following environment variables are set by R/3 configuration tools: ORA_NLS: $ORACLE_HOME/ocommon/NLS_723/admin/data (on each client site) ORA_NLS32 $ORACLE_HOME/ocommon/NLS_733/admin/data (on each client site) ORA_NLS33: $ORACLE_HOME/ocommon/NLS_805/admin/data (on each client site)

(C) SAP AG BC505 20

4.21

SAP AG 1999

Database Role Description

SYSDBA Can perform database administration, has privileges to access all database tables

SYSOPER Can perform database administration such as startup, shutdown, and backup, has no privileges to access database tables

SAPDBA Has privileges to access certain tables required for database administration actions performed in background (-check, -checkopt, -analyze, -next, backup)

Database Role Description

SYSDBA Can perform database administration, has privileges to access all database tables

SYSOPER Can perform database administration such as startup, shutdown, and backup, has no privileges to access database tables

SAPDBA Has privileges to access certain tables required for database administration actions performed in background (-check, -checkopt, -analyze, -next, backup)

Database User Description

SYS Database owner, can perform database administration, has privileges to access all database tables

SYSTEM Can perform database administration, has privileges to access database tables in read and write mode (but not Oracle DDIC tables)

SAPR3 Owner of database tables and indexes used by the R/3 applications,has no privileges to perform database administration

Database User Description

SYS Database owner, can perform database administration, has privileges to access all database tables

SYSTEM Can perform database administration, has privileges to access database tables in read and write mode (but not Oracle DDIC tables)

SAPR3 Owner of database tables and indexes used by the R/3 applications,has no privileges to perform database administration

Connect Request Description

INTERNAL CONNECT INTERNAL possible for OS user belonging to OS group DBA with SYSDBA privileges and for OS user belonging to OS group OPER with SYSOPER privileges

Connect Request Description

INTERNAL CONNECT INTERNAL possible for OS user belonging to OS group DBA with SYSDBA privileges and for OS user belonging to OS group OPER with SYSOPER privileges

Appendix: Database Roles and Users

The following database roles are important for performing database administration tasks in the R/3 environment: SYSDBA: Privilege to access all database objects SYSOPER: Privilege to change the operation mode of the database. No privilege granted on tables SAPDBA: Privilege to access certain tables belonging to SAPR3 that are required to perform

database administration tasks in the background The combined privileges of the SYSOPER and SAPDBA roles are sufficient to perform certain

database administration tasks in the background OS users belonging to the OS groups DBA and OPER can connect to the Oracle database using the

identification INTERNAL. They are assigned the privileges of the database roles SYSDBA or SYSOPER.

The database users are as follows: SYS: Oracle default database user for database administration, owner of the database SYSTEM: Oracle default user who can access all database tables in read and write mode when the

database is open. No privilege to change Oracle DDIC tables. SAPR3: All R/3 tables and indexes belong to this database user. Does not have privilege to

perform administrative actions on the database

(C) SAP AG BC505 21

4.22

SAP AG 1999

> lsnrctl helpThe following operations are availableAn asterisk (*) denotes a modifier or extended command:

start stop status servicesversion reload trace spawndbsnmp_start dbsnmp_stop dbsnmp_status quitexit cancel* repeat* set*show*

> lsnrctl statusConnecting to (ADDRESS=(PROTOCOL=IPC)(KEY=TCC))STATUS of the LISTENER------------------------Alias LISTENERVersion TNSLSNR for HPUX: Version 8.0.5.0.0 - ProductionStart Date 13-MAY-99 14:11:35Uptime 20 days 23 hr. 52 min. 47 secTrace Level offSecurity OFFSNMP OFFListener Parameter File /usr/sap/trans/listener.oraListener Log File /oracle/TCC/network/log/listener.logServices Summary...

TCC has 1 service handlersThe command completed successfully

Appendix: Net8 Listener

The Oracle listener is controlled by command lsnrctl. (NT: lsnrctl80) Command lsnrctl status (lsnrctl80 status) displays information such as Net8 version, listener

program start time, and the location of parameter and listener log files. To return a list of available commands, enter help at the lsnrctl command prompt.

The file listener.ora is read when the listener program is started on the database server. The configuration information specified in this file determines Net8 settings such as the network protocol to be used, host name, port, and the default tracing information.

Database server listener tracing can be enabled by setting trace level information in the file listener.ora or by turning it on through the program lsnrctl.Valid options for listener tracing are:

OFF: No tracing (default)USER: Limited level of tracing informationADMIN: Detailed trace

Use tracing for diagnostic purposes only. Do not leave tracing on indefinitely in a production system.

(C) SAP AG BC505 22

4.23

SAP AG 1999

Appendix: Alert Monitoring Tree

Problem or Error

WarningOK

No data

Monitoring attributes and current valuesMonitoring attributes and current values

Show most recent performance

values

Show most recent performance

values

Display all alerts of the selected item

Display all alerts of the selected item

Customize alerts and configure threshold

values

Customize alerts and configure threshold

values

Delete alerts from open alert list

Delete alerts from open alert list

Start analysis tool associated with the alert

Start analysis tool associated with the alert

Monitoring objectMonitoring object

Current status Display alerts Complete alerts Properties

Oracle

space management

performance

Database

View: Open alerts (08/18/1999 , 09:39:16)

optimizer

checkpoints

library cache

Expert analysis , Node display off

buffers

buffer cache

redo log buffer

[ 16 Alerts ] , 56% < 90%: Cache hit ratio below threshold

[ 25 Alerts ] , 115 < 4,000 redo entries per redo log space requests

Monitor identificationMonitor identification

Monitoring tree element (MTE)

Monitoring tree element (MTE)

Display detailed alertsDisplay detailed alerts

The Alert Monitor monitors various component of your R/3 System. Use the menu path: Tools CCMS Control/Monitoring Alert monitor. Alternatively, use transaction RZ20.

The Open Alerts view shows what has happened in the system since it was last checked. The Current status view shows the most recent values. The Display Alert shows the history of the alert values. Any problems or errors are displayed in in red. Warnings are displayed in yellow. Green means that,

according to the threshold values, there are no problems. You can use Properties to customize the threshold values for red and yellow alerts. To start the analysis tool, double-click the alert text that you want to analyze. To display details of certain type of alerts, set the checkbox next to the alert and then choose Display

detailed alerts. The Complete Alert button resets the alerts displayed on the screen.

(C) SAP AG BC505 23

4.24

SAP AG 1999

Exercises?

Solutions

Unit Actions

(C) SAP AG BC505 24

4.25Database Overview: ExercisesNo. Exercise

1 Start your local database using SAPDBA. Check if your local database is running in ARCHIVELOG mode. If it is not, use the SAPDBA to switch to ARCHIVELOG mode.

2 Check if the passwords of users SYSTEM and SYS still have their default values in your local database.

3 Change the password of user SAPR3 in your local database.

4 Use the SAPDBA menu Tablespace administration to find a list of all tablespaces on your local database. What are the names of the files on the operating system level and in which directory do they exist?

5 Log on to the R/3 System and start the database monitor. Enter values for:

5.1 Data buffer

5.2 Log buffer

5.3 Shared pool

6 List the parameter values belonging to the following objects:

6.1 The size of the shared pool

6.2 The number of blocks in the data buffer

6.3 The size of the log buffer

6.4 The size of an ORACLE block

7 Look in the V$ tables V$LOG and V$LOGFILE

7.1 Find the names of the online redo log files

7.2 Find the current log sequence number

7.3 Which online redo logs have already been backed up by the ARCHIVER?

8 Start the Tables and Indexes Monitor and access the list of all tablespaces in the R/3 System:

8.1 Which is the largest tablespace?

8.2 Which tablespace has the smallest amount of free space?

8.3 Which tablespace contains the most tables or indexes?

8.4 How many data files are there in the tablespace PSAPBTABD?

9 (Optional) In the R/3 System, find out if the R/3 database is running in ARCHIVELOG mode.

(C) SAP AG BC505 25

4.26Database Overview: SolutionsNo. Solution

1 To find the necessary information in SAPDBA, select f - Archive mode. If noarchivelog is displayed by DATABASE LOG MODE, switch to archive log mode by using a - Toggle database log mode. NOTE: SAPDBA must recycle (stop and restart) the database for this operation.

2 Call SAPDBA, and choose m - User and Security b - User information

3 Call SAPDBA, and choose m - User and Security p – Change password c – Change password. Change password of user SAPR3. Enter a new password. Confirm the new password.

4 From SAPDBA, select c - Tablespace administration h - Display all tablespaces and data files. A list of all tablespaces and the related data files from your local database is displayed.

5 From the main R/3 menu choose Tools CCMS Control/Monitoring Performance menu Database Activity. The values you need are displayed.

6 From the main R/3 menu choose Tools CCMS Control/Monitoring Performance menu Database Activity Detail analysis menu Parameter changes. Then choose Active parameters. The parameters you need are:

6.1 SHARED_POOL_SIZE

6.2 DB_BLOCK_BUFFERS

6.3 LOG_BUFFER

6.4 DB_BLOCK_SIZE

7 From the main R/3 menu choose Tools CCMS Control/Monitoring Performance menu Database Activity. Then choose Display V$Values

7.1 The names of the online redo log files are in table V$LOGFILE

7.2 The current log sequence number is the number of the redo log group with the status current in table V$LOG

7.3 If yes is displayed for Archive, then the online redo log has already been archived.

8 From the main R/3 menu, choose Tools CCMS Control/Monitoring Performance menu Database Tables/Indexes. Then choose Current sizes.

8.1 Sort by Size(kb)

8.2 Sort by Free(kb)

8.3 Sort by Tab/Ind.

8.4 Place the cursor on PSAPBTABD, and then choose Data Files. A list of data files belonging to PSAPBTABD is displayed.

9 The information is in table V$DATABASE. See exercise 5 for the menu

(C) SAP AG BC505 26

path.

(C) SAP AG BC505 27

5

SAP AG 1999

Backup Strategy and Tape Management

1 Database Overview 6 Advanced Backup Techniques

2 Backup Strategy and Tape Management

7 Storage Management

3 Scheduling, Performing,and Monitoring Backups

8 Performance Monitoring

4 Restore and Recovery 9 Top 10 Problems

5 Backup Strategies Using RMAN

(C) SAP AG BC505 1

5.2

SAP AG 1999

Backup Strategy and Tape Management

Contents Backup strategy Possible causes of data loss Tape management functions provided by the SAP database

backup tools

ObjectivesAt the end of this unit, you will be able to: Define a backup strategy that meets the needs of your

company Configure the tape management system for performing

database and offline redo log file backups Set up and manage tape pools

Once you have completed this unit, you will be able to: Define a backup strategy that meets the needs of your company Configure the tape management system for performing database and offline redo log file backups Set up and manage tape pools Perform tape initialization Describe the tape layout Describe the procedure of tape select by the tape management system

(C) SAP AG BC505 2

5.3

SAP AG 1999

A good database backup strategy prevents data loss and minimizes system downtime

External factors(Such as fire or water damage)

Physical errors(Such as hardware

failure)

DROP MARA

Logical errors(Such as a deleted

table)

Data loss

The Importance of Database Backups

Procedure andEscalation Plan

If you do not have a suitable backup strategy, external factors, physical errors, and logical errors can cause system downtime and may lead to data loss.

If data is lost due to external factors, such as water damage to your hardware, or physical errors, such as hardware failure, you must recover the database up to the point in time when the database crashed. If a full recovery is possible, only the data of uncommitted transactions before the error will be lost.

If data is lost due to logical errors, such as an unintentionally deleted table, you must recover the database up to a point in time shortly before the error occurred.

Your backup strategy must be designed according to the needs of your company. To ensure the availability of your R/3 System, your backup strategy must be carefully tested before your R/3 System goes live, and after any changes to your backup strategy.

When you set up your backup strategy, you must consider how long you can afford to shut down the R/3 System for each of the above scenarios.

To ensure that the correct actions are performed for each of the scenarios, create a document containing organizational descriptions of procedures and an escalation plan. This document must be understood by the person who performs the database restore and recovery.

You should evaluate and implement the most suitable backup type and method for your company. SAP provides tools that support different types of backups, such as full online, incremental backups with RMAN, and split mirror backups, which are discussed in the next units.

(C) SAP AG BC505 3

5.4

SAP AG 1999

Physicaldata check:

Verify backupon tape

Logicaldata check:

Verify databaseconsistency

Oracle data files

ORA-1578:Oracle data

block corrupted

Database backup

Preventing and Handling Errors

Your backup strategy should include verifying the data to be backed up as well as the data on tape. To verify the consistency of the Oracle database, perform a logical data check.

Corrupt Oracle blocks (error ORA-1578) can appear in your R/3 database as a result of operating system or hardware errors. Corrupt Oracle blocks may make a backup unusable.

The existence of these blocks only becomes evident during the next read access attempt to a table within the database. Since this particular access attempt do not occur often, and corrupt Oracle blocks are not recognized during a database backup, these corrupt blocks may remain undetected in your system for a long time.

Therefore, you should perform a logical data check at regular intervals. You can perform this check using brbackup -w use_dbv (see SAP Notes 155524 and 23345). For optimal performance, perform this check during periods of low system activity, such as weekends.

To verify the tapes used for a database backup, perform a physical data check. To check the physical correctness of the data transferred, the tapes should be read after a successful backup.

(C) SAP AG BC505 4

5.5

SAP AG 1999

You must recover the complete database to a point in time before the error

DROP MARA

Logical errors(Such as a deleted

table)

Time when logical error occurred

Time when database is stopped for recovery

Lost information

Logical error recovery

Possible Causes of Data Loss (1)

12:50 4:00

12:50 - 4:00

Logical errors can be caused by: Manually dropping database objects Manually deleting parts of a database objects, such as rows in a table Application errors

If a logical database error occurs, you must recover the complete database since the data from different tables must be consistent.

Because you must perform a point in time recovery to a point in time before the error, data changed between the time when the logical error occurred and the time the database is stopped for recovery is lost.

Depending on the table, it may be possible to restore the database to a different machine and then export the table from that machine to your production R/3 System or to read the missing table rows from the restored table. This method avoids data loss. However, this method is difficult and requires expert knowledge of the application module that uses the table.

(C) SAP AG BC505 5

5.6

SAP AG 1999

If one offline redo log file is lost, none of the files that follow it can be used

Sequence of offline redo log files:

Forward recoveryA database backup is restored and you want torecover data from offline redo log files

Lost offline redo log file

Point in time of the database error

Intact but unusable offline redo log files

Lost information

Time

Possible Causes of Data Loss (2)

When you perform a point in time recovery, you need all the offline redo log files from the point in time of the last database backup up to the point in time you want to restore to.

If a file is missing from the chain of offline redo log files, then a restore of subsequent offline redo log files is not possible. Data will be lost from the point in time of your lost offline redo log file.

Therefore, you should keep at least two copies of all offline redo log files on tape.

(C) SAP AG BC505 6

5.7

SAP AG 1999

Disaster recovery

External factors(Such as fire or water damage)

Physical errors(Such as hardware failure)

Only data saved on tape can be recovered

Only tapes stored in a safe location can be recovered

Possible Causes of Data Loss (3)

If a hardware failure occurs, such as a disk crash, you can only restore data that is stored on tape. If all of your disks or the complete hardware is lost, only the data available on tape can be recovered.

Only the offline redo log files already stored on tape can be restored. Offline redo log file information that is not stored on tape will be lost.

If data loss occurs due to external factors, such as fires or water damage, all tapes that are not stored in a safe location may be lost.

(C) SAP AG BC505 7

5.8

SAP AG 1999

Additional

Offline redo log file backup (x2)

28 days

Offline redo log file backup (x2)

Verify the database

Verify the backupOnline

Online

Verify the backupOffline

Backup Cycle Recommendations

We recommend a backup cycle of 4 weeks. A pool of tapes for database and offline redo log file backups is required. Ensure that enough tapes

are provided in each tape pool to span the entire backup cycle. We recommend having 30% more tapes than required to cover database growth and additional backups, for example after a database extension. Backup tapes can be reused at the end of a backup cycle (after 28 days).

Perform a full online backup each workday. Perform a full offline backup at least once in the cycle. You must back up the offline redo log files each workday, as well as after every online and offline

backup. Ensure that you back up the offline redo log files twice, on separate tapes, before they are deleted.

To verify a backup, check the database for logical errors and the database backups for physical errors. You must perform backup verification at least once in the backup cycle. However, we recommend that you perform it once a week.

Remove the last verified full offline backup of each cycle from the tape pool, and keep this backup in long-term storage. Replace the tapes, and initialize new ones.

Changes to the file structure of the database affect the subsequent database restore. These changes occur when a data file is added, when a data file is moved to a different location, or when a tablespace and its data files are reorganized. Perform additional backups after each database structure modification or a system upgrade. Place these additional backups in long-term storage.

(C) SAP AG BC505 8

5.9

SAP AG 1999

Media

cpio/dd

Controlfile

Datafiles

Onlineredo log files

Offlineredo log files

Oracle database

Media

BRRESTORE BRARCHIVE

cpio/ddparallel

BRBACKUP

SAP Database Backup Tools

Detail logDetail logSummary Summary

loglog

Detail logDetail logSummary Summary

loglog

In addition to the database administration tool SAPDBA, SAP provides you with the following tools for performing data backups: The program BRBACKUP backs up the data files, the control file, and the database redo log files

where necessary. The program BRARCHIVE backs up the offline redo log files of the database.

Both BRBACKUP and BRARCHIVE record the actions performed in log files. These log files can be used in the case of a database restore, and can be analyzed by the program BRRESTORE. This program can restore all files belonging to the database system from the backups.

The database backup tools support standard backups, both to disk and to tape.

(C) SAP AG BC505 9

5.10

SAP AG 1999

Objects that need to be backed up

R/3 dataComputing center data

R/3 interfaces SAP executables

Operating system Database executables

Database objects

Data files

Online redo log files

Control file

Profiles

Offline redo log files

Offline redo logfile backup

Offline redo logfile backup

Database backupDatabase backup

BRBACKUP

BRARCHIVE

BRRESTORE

Backup Objects

SAPDBA will backup all the business data, but your backup strategy must include backing up all objects. Exactly which objects these are depends on the organizational structure of your company. In the R/3 environment, the backup objects include the operating system and the files associated with R/3.

The objects that need to be backed up include: R/3 data, such as:

R/3 archiving objectsR/3 interfacesSAP executables

Computing center data, such as:The operating systemThird party programs connected to R/3

Database objects A correctly implemented database backup strategy is the only effective protection against data loss in

the database.

(C) SAP AG BC505 10

5.11

SAP AG 1999

BRBACKUP

BRARCHIVE

??Length of

backup cycle

Number of parallelbackup devices

+ 30% Reserve

Frequency of backups

Databasesize

Number and size of redolog files in a backup cycle

Tape pools

Tape Pools

To help manage your tapes, BRBACKUP and BRARCHIVE offer a tape management system that: Helps you find the tapes that are necessary to perform a backup Helps you find the appropriate tapes when you need to recover your database Provides the security that tapes are not overwritten accidentally

You must initialize one pool of tapes for BRBACKUP and another pool of tapes for BRARCHIVE. Tapes that are initialized by BRBACKUP cannot be used by BRARCHIVE, and vice versa.

The number of tapes you need for BRBACKUP depends on factors such as the length of your backup cycle, the size of your database, the number of tape devices to be used in parallel, the storage capacity of the tapes you use, and the frequency of database backup operations.

The number of tapes you need for BRARCHIVE depends on the length of your backup cycle, the storage capacity of the tapes you use, the average number and the size of the redo log files created in a backup cycle, and the frequency of offline redo log file backup operations.

In addition to the number of tapes you need based on your backup strategy, you should have a reserve of 30% more tapes in each tape pool. This is useful in the case of database growth, exceptionally high redo log volume, or if additional backups need to be performed.

(C) SAP AG BC505 11

5.12

SAP AG 1999

brbackup -i -v <tape name> or brarchive -i -v <tape name>

Initialize new tapes, non-SAP tapes, or locked tapes:

Rename non-locked tapes:

brbackup -i force or brarchive -i force

.tape.hdr0

Write the label to the tape that also contains the tape name

...volume_backup = (<SID>B01,<SID>B02...volume_archive = (<SID>A01,<SID>A02......

Profile init<SID>.sap contains the tape names:

Tape Initialization

During tape initialization, an SAP-specific label is written on the tape as the first file (.tape.hdr0). To initialize the tapes, use the following BRBACKUP or BRARCHIVE commands:

For locked tapes, or tapes that were used by another application brbackup -i force or brarchive -i force

For renaming tapes that are not lockedbrbackup -i or brarchive -i

You can also use SAPDBA to initialize tapes. You can specify the tape name that you want to initialize explicitly by using commands:

brbackup -i -v <tape name> or brarchive -i -v <tape name> respectively. If you do not specify the tape name explicitly, BRBACKUP or BRARCHIVE will automatically

select the tape names from the pool of tape names specified in the configuration file init<SID>.sap by parameters volume_backup and volume_archive.

Suggested naming conventions for your tapes are: Tapes used for BRBACKUP: <SID>B01,<SID>B02,..., <SID>BXX Tapes used for BRARCHIVE: <SID>A01,<SID>A02,..., <SID>AYY

(C) SAP AG BC505 12

5.13

SAP AG 1999

Tape labelcontents:

Tape checks: Tape name

Lock period

Use count

Tape name

Database name

Timestamp of last backup

Number of backups performed

Show tape label contents:

brbackup -i show or brarchive -i show

...expir_period = 28tape_use_count = 100...

Profile init<SID>.sap:

Tape Label Contents and Tape Checks

ErrorError

WarningWarning

The tape label contains the following information: The tape name The database name The timestamp of the last backup recorded on the tape The number of backups performed with the tape

By default, BRBACKUP and BRARCHIVE read the tape label before they start writing to a tape in order to check: The tape name If the tape is locked The number of times the tape has already been used

If the tape name is wrong or if the tape is locked, an error is reported and the tape is not used. If tape is used more often than the value set in parameter tape_use_count in file init<sid>.sap, a

warning is generated but the tape is used.

(C) SAP AG BC505 13

5.14

SAP AG 1999

BRBACKUP

Tables SDBAH and SDBAD

Logical tape locking

List of tapes used in expir_period

...C11B05,C11B06,...

Profile: init<SID>.sap...volume_backup = (C11... volume_archive = (C11......

Days1 2 28 29 30 31 32 33

C11B01 C11B02expir_period = 30expir_period = 30

Physical tape locking

.tape.hdr0

BRARCHIVE

Tape Locking

28 28 daysdays

Before writing to tape, BRBACKUP and BRARCHIVE check that the tape is not locked. To prevent tapes from being overwritten too early, ensure parameter expir_period in file init<SID>.sap is set to at least the length of your backup cycle (in days).

A tape is locked if the number of days passed since it was last used is less than value of parameter expir_period. There are two different types of locks for a tape: The physical lock is derived from the tape label. The timestamp of the last backup and the

parameter expir_ period determine if a tape can be reused. If the last backup was performed too recently, then the tape is locked physically. The timestamp is written at the beginning of a backup.

The logical lock is derived from the timestamp written to certain database tables. BRBACKUP and BRACHIVE also write information about the backup, including a timestamp, to the database tables SDBAH and SDBAD when the backup is successfully finished.

To find the tapes that can be used for the next backup, BRBACKUP connects to the database and searches tables SDBAH and SDBAD for the tapes that were used in the lock period. The tapes used cannot be used for the next backup. This is the logical lock check for database backups.

The logical lock check for the offline redo log file backups is performed by BRARCHIVE using information from the summary log. Therefore, offline redo log files can be backed up when the database is not available.

The tape from the tape name list in profile init<SID>.sap that follows the tape that was last recently used, and is not contained in the list of tapes used in the lock period, is selected for the next backup.

(C) SAP AG BC505 14

5.15

SAP AG 1999

28 days

Offline

Additional

Online

Online

Archives (2x)

Archives (2x)

Tape management active, BRBACKUP finds tape names

+Tape label check active

=Only accepts tapes with requested names and with expired lock period

C11B01 C11A01

BRBACKUPBRARCHIVE

Tables SDBAH and SDBAD

Scenario 1: Automatic Tape Selection

The SAP tools provide three procedures for selecting a tape for the backup: Automatic tape selection by BRBACKUP or BRACHIVE Manual tape selection by the operator Tape selection by an external tool

If you want BRBACKUP or BRACHIVE to select the tape(s) to be used for the next backup run automatically, you must define the parameters volume_backup and volume_archive in profile init<SID>.sap.

Each time you start a backup, BRBACKUP or BRACHIVE requests the next unlocked tape in the order defined by parameters volume_backup and volume_archive. After the last medium on the list is used, the first medium on the list is requested again. This medium must not be locked at that time.

To find out the name of the requested tape, call BRBACKUP or BRARCHIVE with the option -q. To check whether you have mounted the requested tape, call BRBACKUP or BRARCHIVE with the option -q check.

(C) SAP AG BC505 15

5.16

SAP AG 1999

C11B01 C11A01

BRBACKUPBRARCHIVE

Scenario 2: Manual Tape Selection

Tape lock expiration will be checked +

Tape management is not active=

To select any tape manually

Tape lock expiration will be checked +

Tape name is changed to the currently required tape name

=You can use this option to replace

tapes in your tape pool

Tape with label name SCRATCH

28 days

Offline

Additional

Online

Archives (2x)brbackup -v SCRATCH orbrarchive -v SCRATCH

To select the tape that is used for the backup, use option SCRATCH. Option SCRATCH can be used in two ways:

As an option for BRBACKUP or BRARCHIVE As a tape name

If a tape is initialized with the name SCRATCH, it can be used for any backup regardless of the name of the tape that is required for the current backup. The tape name is changed to the name of the tape required. Use this option to replace tapes in your tape pool.

If SCRATCH is used as an option for BRBACKUP or BRARCHIVE, that is you issue the command: brbackup -v SCRATCH or brarchive -v SCRATCH, any initialized tape with an expired lock period can be used for a data backup. However, in this case, the tape name will not be changed. You must ensure that the correct tape is inserted. This option can be used to select a tape manually, for example, for a month end backup if you do not want this backup to be performed on your tape pool tapes.

(C) SAP AG BC505 16

5.17

SAP AG 1999

C11B01 C11A01

BRBACKUPBRARCHIVE

Scenario 3: Tape Selection by an External Tool

Searchmechanism

Tape management is deactivated

but tape name is checked+

Tape label check active=

Only accepts tapes- With the specified names- With expired lock period

brbackup -v C11M01,C11M02

28 days

Offline

Additional

Online

Archives (2x)

To explicitly specify the tape(s) to be used by BRBACKUP or BRARCHIVE, use the option -v. This is useful when using a shell script or external tape management tool for determining the tapes to be used at the next backup run.

BRBACKUP and BRARCHIVE check that the tapes specified by option -v have been mounted and that they are not locked. Locked tapes are refused.

(C) SAP AG BC505 17

5.18

SAP AG 1999

Offlineredo log n

Detaillog

Summarylog

BRBACKUP:

BRARCHIVE:

.tape.hdr0init<sid>.orainit<sid>.dba

init<sid>.sap DB file 1

DB file nDetail

logSummary

logreorg.logstruct.log

reorg.logstruct.log

.tape.hdr0init<sid>.orainit<sid>.dba

init<sid>.sapOffline

redo log 1

Control file

Tape Layout

The files written to tape by BRBACKUP and BRACHIVE are: .tape.hdr0: Tape label init<SID>.ora: Database configuration file init<SID>.dba: SAPDBA configuration file init<SID>.sap: BRBACKUP and BRARCHIVE configuration file reorg<SID>.log:: Information about the creation, extension, or reorganization of a tablespace,

restoring and recovering the database (located in directory sapreorg) struct<SID>.log:: History of database structure changes (located in directory sapreorg) Detail log:: Complete output of the BRBACKUP or BRARCHIVE run (located in directories

sapbackup or saparch) Summary log back<SID>.log:: List of all backups started with BRBACKUP (located in directory

sapbackup) Summary log arch<SID>.log:: List of all offline redo log files backed up by BRARCHIVE

(located in directory saparch)

(C) SAP AG BC505 18

5.19

SAP AG 1999

Unit Summary

Now you are able to:

Configure the tape management system for running database and offline redo log backups

Set up and manage tape pools

Perform the tape initialization

Describe the procedure of tape selection by the tape management system

Describe the tape layout

The SAP backup tools offer a basic method of tape management. Used in conjunction with a suitable naming convention, tape management with SAP backup tools enables you to manage your backup media securely and in a comprehensible manner.

The tapes that are required must be initialized before the backup cycle can be implemented. It is important that you allow sufficient reserve capacity when initializing the tapes.

(C) SAP AG BC505 19

5.20

SAP AG 1999

Exercises?

Solutions

Unit Actions

(C) SAP AG BC505 20

5.21Backup Strategy and Tape Management: ExercisesNo. Exercise

Backup Strategy

1 Evaluate the following backup strategy.

Technical specifications:

The planned size of the database is roughly 100 GB

A maximum of 50 online redo log files of 20 MB are expected to be written daily

Three tape devices are available and each can write or read up to 6 GB per hour

The tapes have a capacity of 40 GB

It takes on average three minutes to apply an offline redo log file during the recovery

Strategy:

An online backup is performed every night

Three tapes are reserved for every night

The database administrator performs a backup of the offline redo log files daily, and deletes the offline redo log files from disk afterwards

1.1 Is this a good backup strategy?

1.2 Can a full restore be performed in 8½ hours?

1.3 What is the significance for an instance recovery, if the error that led to the restore and recovery operation occurred during a long background processing job without a commit?

Tape Management

2 Internal tape selection

2.1 What happens if you use command brbackup -i force -v <tape name> and enter the same tape name to re-initialize a tape that has already been initialized under that name and used before in the backup cycle?

2.2 Can you use this method to release a locked tape?

3 Compare the BRBACKUP command option SCRATCH with the tape name SCRATCH.

3.1 What happens when BRBACKUP or BRACHIVE is started using the option -v SCRATCH and a tape with an arbitrary name is used? (NOTE: tape name is not SCRATCH.)

3.2 What happens if you start the SAP utilities BRBACKUP or BRACHIVE without entering a tape name (brbackup) and insert a tape initialized with the name SCRATCH (brbackup -i -v SCRATCH)?

4 Initialize a tape for BRBACKUP.

(C) SAP AG BC505 21

5.22Backup Strategy and Tape Management: SolutionsNo. Solution

Backup Strategy

1

1.1 The problem when using this backup strategy is that only one copy of the archived redo log files is written to tape before deletion. We recommend that at least two copies are written to different backup media. The data is distributed automatically by BRBACKUP across the tape devices so that the backup can be performed in unattended mode, even if the files are not compressed.

1.2 If the data volume is distributed over the three backup media, each tape will contain approximately 33 GB. At a read rate of 6 GB per hour, a restore operation would take approximately 5½ hours. 1 GB of offline redo log files can be restored in 10 minutes. It takes approximately three minutes to apply one redo log file to the database. Therefore, it would take approximately 150 minutes to apply all offline redo log files from one day.

To restore and recover the database would take up to 8 hours and 10 minutes. However, this time does not include the time to analyze and repair the error that led to the restore. Additionally, the time of the instance recovery that is performed at system startup is not accounted for in this calculation.

Due to the times not accounted for in the calculation, it is unlikely that the full restore and recovery can be performed in 8½ hours.

1.3 An uncommitted transaction has to be rolled back during instance recovery. Therefore, the database needs more time to complete the recovery.

Tape Management

2

2.1 When a tape that is already integrated into the backup cycle is re-initialized, the label of the tape label will be reset including the information about the number of times the tape has been used. Therefore, the tape may be used more often than the recommended number of times.

2.2 A tape will remain locked with a logical lock but not with a physical lock.

The information about which tape should be used is contained only in the database tables SDBAH and SDBAD. These database tables are not reset when you re-initialize the tape with the option -i force.

However, the label of the tape is reset. Therefore, there is no date recorded on the tape when it was last recently used and no the tape is not locked with a physical lock.

3

3.1 The lock expiration of the tape is checked.

If the tape is not locked, it is used regardless of its name.

The name of the tape will not be changed.

This option can be used for an unscheduled backup or if you want to define the tape name using an external tool. When you use an external tool, for example, if you want the name to contain the correct day of the week, switch

(C) SAP AG BC505 22

off the automatic tape administration. Do not use the same tape name twice in a backup cycle, and do not use the tape name SCRATCH.

3.2 The lock expiration of the tape is checked.

If the tape is not locked, it is used.

The name of the tape is changed to the name of the tape requested from the backup cycle by BRBACKUP or BRACHIVE.

The tape name SCRATCH can be used when a tape needs to be replaced, for example when the tape_use_count is exceeded or when the tape is defective. Note that you must remove the old tape from your tape pool to ensure that tape names are unique in the pool.

4 Copy the init<SID>.sap.tape file to init<SID>.sap

brbackup –i force –v <SID>B01

(C) SAP AG BC505 23

6

SAP AG 1999

Scheduling, Performing, and Monitoring Backups

1 Database Overview 6 Advanced Backup Techniques

2 Backup Strategy and Tape Management

7 Storage Management

3 Scheduling, Performing,and Monitoring Backups

8 Performance Monitoring

4 Restore and Recovery 9 Top 10 Problems

5 Backup Strategies Using RMAN

(C) SAP AG BC505 1

6.2

SAP AG 1999

Scheduling, Performing, and Monitoring Backups

Contents Database backups Offline redo log file backups

ObjectivesAt the end of this unit, you will be able to: Schedule and perform a backup using SAP tools Monitor and verify a backup run Evaluate, implement and test the most suitable backup method

for your company

(C) SAP AG BC505 2

6.3

SAP AG 1999

BRBACKUP

Data files

BRBACKUP

Data files

Log filesLog files................

....

....

................

BRARCHIVE

Offline redolog files

BRARCHIVE

Offline redolog files

....

....

....

....

init<SID>.sapsapr3.SDBAH

sapr3.SDBAD

Log filesLog files................

........

................

DBA Planning CalendarPlanning Goto Listing Help System

MONMON TUETUE WEDWED THUTHU FRIFRI SATSAT SUNSUN

MONMON TUETUE WEDWED THUTHU FRIFRI SATSAT SUNSUN

MONMON TUETUE WEDWED THUTHU FRIFRI SATSAT SUNSUN

MONMON TUETUE WEDWED THUTHU FRIFRI SATSAT SUNSUN

BRBACKUP -t ...

or

BRARCHIVE ...

Command prompt- x

How SAP Backup Tools Work Together

A backup can be called: From CCMS in R/3 – for periodic actions. To schedule periodic backups, use the DBA Planning

Calendar (transaction DB13). In R/3, the required tapes can be determined, and the logs displayed. Using SAPDBA – for one-time actions and exceptional cases. Starting from the command prompt,

you can use SAPDBA to administer the Oracle database. With this program, backups are started interactively.

Using BRBACKUP or BRARCHIVE – for one-time actions and exceptional cases. You can call the SAP tools for database backups (BRBACKUP) and offline redo log file backups (BRARCHIVE) at the command prompt level. To schedule such backups, you can use operating system commands (UNIX: cron, NT: at).

When a backup is scheduled by CCMS, or started up by SAPDBA, these tools call BRBACKUP and/or BRARCHIVE in order to back up the files to tape or disk, and to log backup actions in database tables SDBAH and SDBAD. Each tool also backs up a summary log and a detail log per action. Default values are read from the parameter file init<SID>.sap. However, with these backup alternatives, some of the default values can be overridden. For internal tape administration, BRBACKUP determines the required tapes from tables SDBAH and SDBAD, while BRARCHIVE does so on the basis of its summary log.

(C) SAP AG BC505 3

6.4

SAP AG 1999

???

?

?

?

....

....

....

....

init<SID>.sap

compresscompress = hardware= hardwarecompress_compress_cmdcmd = “compress = “compress --b 12 b 12 --c $ > $”c $ > $”compress_compress_dirdir = /oracle/<SID>/= /oracle/<SID>/sapreorgsapreorgtape_copy_tape_copy_cmdcmd = = dddddisk_copy_disk_copy_cmdcmd = = rmanrmanexec_parallelexec_parallel = 0= 0tape_addresstape_address = /= /devdev//rmtrmt/0mn/0mntape_address_tape_address_rewrew = /= /devdev//rmtrmt/0m/0mtape_address_archtape_address_arch = /= /devdev//rmtrmt/1mn/1mntape_address_tape_address_rewrew_arch_arch = //devdev//rmtrmt/1m/1mbackup_ modebackup_ mode = all = all

backup_ typebackup_ type = online [offline] = online [offline]

volume_backupvolume_backup = = (<SID>B01, <SID>B02, ...) (<SID>B01, <SID>B02, ...) tape_ sizetape_ size = 32G= 32Gtape_use_counttape_use_count = 100= 100expirexpir_period_period = 28 = 28 backup_backup_devdev_type_type = tape= tapearchive_functionarchive_function = copy_delete_savevolume_archivevolume_archive = (<SID>A01, <SID>A02, ...) tape_size_archtape_size_arch = 6000M

Backup Profile Parameters

To choose the tape drives for the tape stations used for database or offline redo log file backups, set parameters tape_address and tape_address_rew. The optional parameters tape_address_arch and tape_address_rew_arch are used to specify one (or two) tape drives for the tape station used for offline redo log file backups. When the offline redo log file backup parameters have been set, tape_address and tape_address_rew are only used for the database backup.

The parameter tape_copy_cmd determines whether copy program cpio or dd is used to back up the data files to tape. Using dd, the required backup time can be reduced significantly. If you use dd, you must maintain the following parameters (for NT, “obs=nk” or “ibs=nk ” do not apply):dd_flags = “obs = nk bs = nk” with n 16 (for DLT, for example n = 32 or n = 64) dd_in_flags = “ibs = nk bs = nk” with n 16 (for example, dd_in_flags = “ibs = 64k bs = 64k ”)

The parameter compress_dir indicates which directory is being used with verify or software compression during a backup.

The parameters compress_cmd and exec_parallel are discussed on the slide “Hardware Compression.”

The init<SID>.sap parameters shown in smaller print are not discussed here. These profile parameters are only examples; they may differ on your system. For further parameter definitions, see the R/3 Online Documentation.

(C) SAP AG BC505 4

6.5

SAP AG 1999

BRBACKUP/BRARCHIVE

cpio/dd

Data ...

dd: Error

cpio: Error orcpio continuation

volume

Data Data

cpio/dd cpio/dd

...

BRBACKUP/BRARCHIVE

cpio/dd

Data ... Data

cpio/dd cpio/dd

...BRBACKUP:

SAP follow-up

tape

Correct

Parameter tape_size

Physical tape size

Parameter tape_size

Data

Physical tape size

Profile init<SID>.sap Parameter tape_size

Incorrect

The data volume to be backed up is determined by BRBACKUP/BRARCHIVE, and distributed among SAP tapes, using parameter tape_size. If a tape change is required, use an SAP follow-up tape (for cpio, this is called a continuation volume). The files are not split; they are backed up to tape in one piece. During an offline redo log file backup, the maximum number of offline redo log files that can fit on this tape (as defined by tape_size or tape_size_arch) is backed up. An SAP follow-up tape is not used.

If the value for tape_size is too large, the copy program (cpio or dd) may start backing up a file to tape, and may reach the physical end of the tape. The consequences depend on the copy program and the type of backup.

The copy program dd always generates an error message when it reaches the end of the tape. The error message depends on the operating system. For Windows NT, it reads Physical end of tape has been reached. For UNIX, it reads I/O Error.

During a serial database or offline redo log file backup, cpio requests a cpio (not an SAP) continuation volume. The database backup terminates successfully. Caution: Since SAP tools cannot request the cpio continuation volume directly, problems may arise during a restore from this database backup.

During a parallel database or offline redo log file backup, cpio terminates with an error message, and the backup terminates with an error.

Therefore, tape_size must be set to a value somewhat smaller than the physical tape capacity (allowing, for example, a 10% safety margin).

(C) SAP AG BC505 5

6.6

SAP AG 1999

400 MB 400 MB 400 MB 400 MB

BRBACKUP400 MB

400 MB400 MB

400 MB

compresscompress = no= no

tape_sizetape_size = 1800M= 1800M

init<SID>.sap

400 MB

400 MB

Tape station withouthardware compression

200 MB

200 MB

200 MB

200 MB

200 MB

400 MB

BRBACKUP

200 MB

200 MB

200 MB

200 MB

400 MB

400 MB

400 MB

400 MB

400 MB

400 MB

400 MB400 MB

compresscompress = hardware= hardwarecompress_compress_cmdcmd = “compress = “compress --b 12 b 12 --c $ > $”c $ > $”exec_parallelexec_parallel = 0= 0

tape_sizetape_size = 1600M= 1600M

....

............

init<SID>.sap

Tape station withhardware compression

Once per cycle:Determine compression rate

400 MB 400 MB

400 MB400 MB

Hardware Compression

For tape stations with hardware compression, parameter tape_size is set to a smaller value (as an additional safety margin, since the compression rate changes in the course of a backup cycle) than for tape stations without hardware compression. For more information on setting tape_size for different tape stations, see SAP Note 8707.

To be able to distribute files across the tapes, BRBACKUP requires information on how well the files to be saved are being compressed by the tape station. However, tape stations do not report a compression rate. You must therefore determine the compression rate once per backup cycle. Determine this rate by using SAPDBA, or by using the operating system command brbackup -k.

To determine the compression rate, for UNIX, we recommend that you set parameter compress_cmd as shown above in order to obtain more precise values. For NT, the appropriate value for compress_cmd is given in the R/3 Online Documentation.

If parameter exec_parallel has been set to 0 during compression rate determination, one process per logical volume is triggered in order to determine the compression rate. If parameter exec_parallel has been set to a value smaller than the number of logical volumes, the number of processes required to determine the compression rate is limited to the number indicated by the parameter. This reduces the CPU load on the database server.

(C) SAP AG BC505 6

6.7

SAP AG 1999

DBA Planning CalendarPlanning Goto Listing Help System

MONMON TUETUE WEDWED THUTHU FRIFRI SATSAT SUNSUN

MONMON TUETUE WEDWED THUTHU FRIFRI SATSAT SUNSUN

MONMON TUETUE WEDWED THUTHU FRIFRI SATSAT SUNSUN

MONMON TUETUE WEDWED THUTHU FRIFRI SATSAT SUNSUN

BRBACKUP -t online -d tape

-m all -c -u system

Command prompt- x

Scheduling and Performing a Normal Database Backup

tape_copy_tape_copy_cmdcmd = = dddd oror

tape_copy_tape_copy_cmdcmd == cpiocpio

................

init<SID>.sap

1 Calendar

Schedule an Action for Tue 05

18:00:00Start time

Period (weeks):

Full database offline + redo log backup

Full database offline backup

Full database online + redo log backup

Full database online backup

Redo log backup

Partial database offline backup

Partial database online backup

Check optimizer statistics

Adapt next extents

Check databaseh - Backup database

SAPDBA- x

c - Backup device type taped - Objects for backup alle - Backup type onlineg - Query only no

S - Start BRBACKUP

SAPDBA- x

If possible, schedule all periodic database backups in your backup strategy using the DBA Planning Calendar (transaction DB13). For all further database backups, use SAPDBA, or call BRBACKUP using the command prompt.

SAP recommends that you perform one online database backup each working day. Schedule this backup for periods with low system activity.

To schedule a full backup with redo backup from CCMS, the “one-run” strategy is used. This strategy is discussed at the end of this unit.

To start a database backup with SAPDBA, select h - Backup database. Here, you can temporarily override the parameters that have been preset for this backup by the parameter file (default: init<SID>.sap). The parameter file is not changed. For example, to select another type of backup such as offline or offline_force, select e - Backup type. You can then start the backup using s - Start BRBAKUP.

For purposes of internal tape administration, to determine which tapes are required for the backup parameters that are currently set, select g - Query only (select the setting with/without tape check). The query begins with S - Start BRBAKUP.

If you call BRBACKUP from the command prompt, you can temporarily override the parameters that have been preset by the parameter file (default: init<SID>.sap), by using the call parameters. The parameter file is not changed. To display the list of call parameters, use the command prompt brbackup -h | more, or check the R/3 Online Documentation.

(C) SAP AG BC505 7

6.8

SAP AG 1999

Phases of a Whole Database Backup

Save control file to diskSave control file to disk

Back up saved control fileBack up saved control file

For all tablespaces to be backed up:Begin tablespace backup modeBack up tablespace data filesEnd tablespace backup mode

For all tablespaces to be backed up:Begin tablespace backup modeBack up tablespace data filesEnd tablespace backup mode

Log file switchLog file switch

Back up control fileBack up control file

Start databaseStart database

Shut down databaseShut down database

Back up data filesBack up data files

*Back up online redo log files*Back up online redo log files

Offline*Start database*Start database

*Shut down database*Shut down database

Retrieve file names of data and online redo log files from databaseand retrieve names of control files from init<SID>.ora

Retrieve file names of data and online redo log files from databaseand retrieve names of control files from init<SID>.ora

Back up tape header, init<SID>.sap, init<SID>.dba, and init<SID>.oraBack up tape header, init<SID>.sap, init<SID>.dba, and init<SID>.ora

Back up reorg.log, struct.log, detail log, and summary logBack up reorg.log, struct.log, detail log, and summary log

Online

Some, but not all, steps of offline and online backup procedures are identical. During an offline backup, the steps marked above with an asterisk do not necessarily have to be

performed. In this way,The DB is only started if it is shut down at the start of the offline backup.The online redo log files are only backed up during a complete database backup.The DB is only shut down if it was shut down at the start of the offline backup.

During an online backup, the tablespaces are set one by one to Begin Backup Mode or End Backup Mode. Therefore, when a data file is backed up, the associated tablespace is in the backup mode. If all data files have been backed up, and all tablespaces have been reset to End Backup Mode, a log file switch is performed. During a subsequent offline redo log file backup, all offline redo log files required for consistency of the online backup can be backed up.

During an online backup, the control file cannot be backed up to tape during normal database operation. Therefore, at the start of the backup, a consistent copy of this control file is made to disk. This copy is backed up to tape after all data files have been backed up.

At the start of a backup, a tape header is written. By reading this tape header at the end of the backup, BRBACKUP checks whether the tape header was able to be written correctly to tape.

This strategy does not use RMAN (Recovery Manager).

(C) SAP AG BC505 8

6.9

SAP AG 1999

Data files compress_dir

BRBACKUP -c -w use_dbv

AB

N..

A ?Corruption

Tape readable?

Log filesLog files................

........

................

Oracle8-KB Block=

?File

length

Logical Verification of a Database Backup

Once per week.Minimum: onceper cycle

When the tape header is checked, the tape station also undergoes a minimal function check. Although problems occurring during a backup are revealed by the tape header check, these problems are not detected until the end of the next backup performed on this tape station, at the earliest. Systematic tape station errors cannot be detected in this way. To confirm tape readability, check backups regularly using the option verify or -w.

Corrupt data blocks are only detected when Oracle processes access these data blocks. A database backup may therefore contain corrupt blocks. We recommend that you check a complete database backup for corrupt data blocks once each week, or at least once each backup cycle. During a database backup, use the option -verify use_dbv or -w use_dbv to: Ensure tape readability Detect corrupt data blocks

The files are read from tape, and copied to the directory defined by the init<SID>.sap parameter compress_dir. BRBACKUP checks whether the file read from tape is the same length as the one that was backed up (file length is specified by the single backup logs). In addition, every data file is checked for corrupt data blocks, using the Oracle utility DB_VERIFY. If the BRBACKUP log reports corrupt data blocks, see SAP Note 99962.

Caution: A backup performed using verify takes at least twice as long as a backup performed without verify. You can therefore defer a verify with BRRESTORE. You can run a deferred verify on the database server or another server.

(C) SAP AG BC505 9

6.10

SAP AG 1999

Data files compress_dir

BRBACKUP -t offline -c -w

AB

N A.. ...

Checkdatabasebackup

If possible:Once each cycle

=?Offline(binary)

Physical Verification of Offline Database Backups

During a database backup with the option -verify use_dbv, BRBACKUP checks whether the backup contains corrupt data blocks. However, it does not check whether the files read from tape are identical to the corresponding files in the database. (During an online database backup, these files may also differ.)

During an offline database backup using the option -verify or -w, the restored files are compared at the binary level to the corresponding files in the database. If a database backup has been terminated using verify, and no error message has appeared, all files were readable, and were identical to the corresponding files in the database. Such a database backup takes at least twice as long as a backup performed without verify. If the required time window for the offline backup with verify is available, we recommend that you perform an offline database backup using verify once each backup cycle.

A binary verify cannot be deferred using BRRESTORE.

(C) SAP AG BC505 10

6.11

SAP AG 1999

sapr3.SDBAHsapr3.SDBAD

Log filesLog files................

........

................

DBA Planning CalendarPlanning Goto Listing Help System

MONMON TUETUE WEDWED THUTHU FRIFRI SATSAT SUNSUN

MONMON TUETUE WEDWED THUTHU FRIFRI SATSAT SUNSUN

MONMON TUETUE WEDWED THUTHU FRIFRI SATSAT SUNSUN

MONMON TUETUE WEDWED THUTHU FRIFRI SATSAT SUNSUN

cd /oracle/<SID>/sapbackup

cat back<SID>.log | more

cat b<timestamp>.and | more

Command prompt- x

L - Show/Cleanup

SAPDBA- x

a - Show log files / profiles

SAPDBA- x

e - BRBACKUP log files

SAPDBA- x

Monitoring a Database Backup

Database OperationsMonitor (DB24)

DBA Calendar(DB13)

BRBACKUP writes logs to SAP tables SDBAH and/or SDBAD, and to files in directory sapbackup. Therefore, by using SABDBA or file editors, you can check in R/3 whether the backup has been performed successfully.

In R/3, you can monitor database backups using the DBA Planning Calendar (transaction DB13). To select the compressed data from tables SDBAH and SDBAD, choose the appropriate action. You can branch to the detail logs at the operating system level.

For an overview of all database backups that have been performed, use the DBA Operations Monitor (call transaction DB24). In the DBA Operations Monitor, double-click the backup run, then choose Display action logs.

Using SAPDBA, you can display logs from database backups. Select l - Show/Cleanup, a - Show log files / profiles, e - BRBACKUP log files.

The BRBACKUP logs are at the operating system level in directory sapbackup. For every BRBACKUP action, the summary log back<SID>.log contains an entry with the date and name of the corresponding detail log. The detail logs b<time stamp>.<ext> contain a complete description of BRBACKUP activity. The file suffix <ext> depends on the BRBACKUP function selected. The summary log and detail logs can be viewed using commercial editors or operating system commands.

With the option brbackup -o dist|time[,time|dist], additional information is entered into the detail log. See also the database handbook in the R/3 Online Documentation.

Backups that have been terminated can be completed. In the unit “Advanced Backups,” see the slide “Partial Database Backups.”

(C) SAP AG BC505 11

6.12

SAP AG 1999

BRARCHIVE option -cds (copy, delete, save)Status of an offline redo log file

42

42

42

../saparch

<SID>A01<SID>A01

<SID>A02<SID>A02

ARCHIVED

DELETED

SAVED

COPIED

../saparch

<SID>A01<SID>A01

<SID>A02<SID>A02

43

42

44

46

45

<SID>A03<SID>A03

42

44

43

42

BRARCHIVE -cds

Mon Tue Wed

42

42

42

43

44

42

43

44

45

46

Offline Redo Log Files: Status and Option -cds

After a log file switch, the Oracle process ARCH copies the online redo log file that was the current redo log file before the log file switch to directory saparch. An offline redo log file generated in this way can have various statuses for BRARCHIVE. These statuses are always listed and updated in summary log arch<SID>.log after a BRARCHIVE run.

During a backup to tape, an offline redo log file, when generated, has the status ARCHIVE. (This status is not displayed until the offline redo log file is backed up for the first time.) At first save, the file status is SAVED; the second time, it is COPIED; and after deletion, it is DELETED.

During a backup to disk, an offline redo log file, when generated, has the status DISK. (Again, this status is not displayed until the offline redo log file is backed up for the first time.) A second copy is not supported. The only statuses here are DISKSAV (first save to disk) and DISKDEL (deletion after a save to disk).

Do not mix tape and disk backups. BRARCHIVE has a series of call options that determine how the offline redo log files are processed.

SAP recommends the option -cds because: (1) If an offline redo log file has the status SAVED, it is saved to tape for a second time, and subsequently deleted from disk. This procedure is repeated until no offline redo log file with status SAVED is found. Next, all offline redo log files with status ARCHIVE are backed up to tape for the first time. (2) After the backup, all offline redo log files exist at two locations: either (a) in saparch and on tape, or (b) on two different tapes. Thus, you can achieve a high fail-safe rate without drastically increasing the tape requirement.

(C) SAP AG BC505 12

6.13

SAP AG 1999

DBAPlanning CalendarPlanning Goto Listing Help System

MONMON TUETUE WEDWED THUTHU FRIFRI SATSAT SUNSUN

MONMON TUETUE WEDWED THUTHU FRIFRI SATSAT SUNSUN

MONMON TUETUE WEDWED THUTHU FRIFRI SATSAT SUNSUN

MONMON TUETUE WEDWED THUTHU FRIFRI SATSAT SUNSUN

brarchive -cds -d tape

-c -u system

Command prompt- x

1 Calendar

Schedule an Action for Tue 05

18:00:00Start time

Period (weeks):

Full database offline + redo log backup

Full database offline backup

Full database online + redo log backup

Full database online backup

Redo log backup

Partial database offline backup

Partial database online backup

Check optimizer statistics

Adapt next extents

Check database

i - Back up offline redo log files

SAPDBA- x

a - Archive function Copy, delete, andsave archive logs

c - Archive device type tape

s - Start BRARCHIVE

SAPDBA- x

Performing Offline Redo Log File Backups

DB13

To schedule all periodic offline redo log file backups that are part of your backup strategy, use the DBA Planning Calendar (transaction DB13). Back up offline redo logs every day.

You can start an offline redo log backup using SAPDBA by selecting i - Backup offline redo logs. To select another type of backup, such as Copy, delete and save offline redo logs, select a - Archive function. To start the backup, select s - Start BRARCHIVE.

If you call BRARCHIVE using the command prompt, the parameters that have been preset using the parameter file (default: init<SID>.sap) can be temporarily overridden using call options. To obtain the list of call options, see the R/3 Online Documentation.

To ensure that the tapes are readable, check backups regularly using the option -verify or -w. SAP recommends that you perform an offline redo log file backup using verify once per backup

cycle. If the time window required for the offline redo log file backup using verify is available, the tape readability check should be performed during each offline redo log file backup.

If you start BRARCHIVE by choosing -f (Fillup), all offline redo log files in saparch are initially backed up according to the selected backup function. BRARCHIVE then periodically checks newly generated offline redo logs and writes them to tape until the tape is full.

To cancel brarchive -f, use the command brarchive -f stop only. Never use ‘Ctrl + C’ or the kill command (UNIX).

(C) SAP AG BC505 13

6.14

SAP AG 1999

sapr3.SDBAHsapr3.SDBAD

Log filesLog files................

........

................

DBA Planning CalendarPlanning Goto Listing Help System

MONMON TUETUE WEDWED THUTHU FRIFRI SATSAT SUNSUN

MONMON TUETUE WEDWED THUTHU FRIFRI SATSAT SUNSUN

MONMON TUETUE WEDWED THUTHU FRIFRI SATSAT SUNSUN

MONMON TUETUE WEDWED THUTHU FRIFRI SATSAT SUNSUN

cd /oracle/<SID>/saparch

cat arch<SID>.log | more

cat a<timestamp>.cds | more

Command prompt- x

L - Show / Cleanup

SAPDBA- x

a - Show log files / profiles

SAPDBA- x

f - BRARCHIVE log files

SAPDBA- x

Monitoring Offline Redo Log File Backups

Database OperationsMonitor (DB24)

CCMS Calendar(DB13)

DB13

BRARCHIVE writes logs to SAP tables SDBAH and/or SDBAD, and to files in directory saparch. Therefore, you can check in R/3 whether the offline redo log file backup was performed successfully, by using SAPDBA or file editors.

In R/3, you can monitor offline redo log file backups using the DBA Planning Calendar (transaction DB13). To select the compressed data from tables SDBAH and SDBAD, choose the action you want. You can branch to the corresponding detail logs at the operating system level. In addition, transaction DB24 provides an overview of all executed offline redo log file backups.

Using SAPDBA, you can display logs for the offline redo log file backups. Selectl - Show/Cleanup, a - Show log files / profiles, f - BRARCHIVE log files.

The BRARCHIVE logs are located at the operating system level in directory saparch. The summary log arch<SID>.log specifies which offline redo log file was backed up using what action to which tape. The detail log a<time stamp>.<ext> contains a complete description of BRARCHIVE activity. The file suffix <ext> depends on the BRARCHIVE function selected. The summary log and detail logs can be viewed using commercial editors or the appropriate operating system commands.

With the option brarchive -o dist|time[,time|dist], additional information is entered in the detail log. For more information, see the database handbook in the R/3 Online Documentation.

(C) SAP AG BC505 14

6.15

SAP AG 1999

sapr3.SDBAHsapr3.SDBADexpirexpir_period_SAPDBA_normal_period_SAPDBA_normal = 11= 11

expirexpir_period_daily_check_period_daily_check = 5= 5

expirexpir_period_BRBACKUP_period_BRBACKUP = 30= 30

expirexpir_period_BRARCHIVE_period_BRARCHIVE = 30= 30

expirexpir_period_oracle_trace_period_oracle_trace = 1= 1

................

init<SID>.dba

delete b<timestamp>.and

Command prompt- x

Log filesLog files................

........

................

L - Show/Cleanup

SAPDBA- x

b - Cleanup log files / directories

SAPDBA- x

a - SAPDBA log files and dump directoriesb - SAPDBA daily check log files c - BRBACKUP log filesd - BRARCHIVE log files

f - ORACLE traces and audits

SAPDBA- x

Log File Cleanup

The log files of these SAP tools are written to the corresponding files at operating system level and to the backup tapes. In case of damage to the database, SAPDBA takes repair actions based on these log files.

However, you must delete log, trace, and audit files regularly, especially those that are generated by the database. If you do not do this, the file systems overflow. As a result of cryptic file names, logs that are still needed can easily be deleted accidentally. Therefore, you should not delete these files using operating system commands. To use the SAPDBA delete function, select l - Show/Cleanup and b - Cleanup log files / directories. This choice refers to logs in directories sapreorg, sapcheck (both SAPDBA logs), sapbackup (BRBACKUP), saparch (BRARCHIVE), saptrace/background, saptrace/usertrace, and <ORACLE_HOME>/rdbms/audit (all of which are Oracle). SAPDBA's default values for the minimum age of a log before deletion is permitted are derived from the SAPDBA configuration file init<SID>.dba. The parameters expir_period_* represent lower limits, from which deletion is permitted using SAPDBA. You should adapt these limits to the backup cycle used.

SAPDBA simultaneously deletes the corresponding data in data table SDBAD. The entries in header table SDBAH are retained. BRBACKUP deletes entries older than 400 days from tables SDBAH and SDBAD. (The operating system logs are not deleted.)

SAPDBA can be called in the command prompt mode using SAPDBA -cleanup. All directories are then cleaned up, according to the parameters in init<SID>.dba.

(C) SAP AG BC505 15

6.16

SAP AG 1999

Detecting an archiver stuckMonitoring the directory saparch

f - Archive mode

SAPDBA- x

c - Show all archive information

SAPDBA- x

FREE SPACE : ...SAPDBA- x

cd saparch

df -k .

Command prompt- x

../saparch

alert_<SID>.log:Thread <n> cannot allocate new log,All online logs needed archiving

________________________________________

SAPGUI- x.… .… ....

Resolving an archiver stuck

Removedummy files

and

Run BRARCHIVE

<SID>A01<SID>A01

Dummy

Freespace Problems in Directory saparch

RZ20 DB24

In the ARCHIVELOG mode, the logwriter process can override an online redo log file only if it has been backed up successfully to directory saparch, using the archiver process. Therefore, for a database in the ARCHIVELOG mode, you must make sure that the archiver process is active, and that sufficient freespace is available in saparch. You must monitor freespace daily.

To monitor the freespace in saparch, use transaction DB12. This transaction also shows an overview of the backup status of the offline redo log files. In SAPDBA, this freespace is displayed in the saparch directory under menu option f - Archive mode, c - Show all archive information. You can also check the freespace using operating system commands.

If the logwriter process attempts to switch to the next online redo log file, and this online redo log file has not been backed up by the archiver process, the database waits. This situation is called archiver stuck (see also the unit “Top 10 Problems”). A possible cause is missing freespace in saparch. The database alert log then contains error messages. To resolve the archiver stuck, the offline redo log files must be backed up to tape using the standard copy function, and then deleted from directory saparch. To do so, use SAPDBA or, if SAPDBA can no longer log on to the database, use BRARCHIVE at the command prompt level.

TIP: Place a dummy file in directory saparch. In case of an archiver stuck, the dummy file is deleted, the archiver again backs up offline redo log files, and the database keeps running for a short time. This interval is sufficient to enable you to start offline redo log file backups as usual using SAPDBA.

(C) SAP AG BC505 16

6.17

SAP AG 1999

Now you are able to:

Describe the SAP backup tools

Maintain the appropriate profile parameters

Schedule, perform, monitor, and verifydatabase backups and offline redo log file backups

Clean up the log files written during a backup

Unit Summary

(C) SAP AG BC505 17

6.18

SAP AG 1999

Further Documentation

Knowledge Product CD

SAP Database Administration Oracle

Online Documentation

Database Administration: Oracle

SAPNet

SAP Notes 19909, 8707, 33630, 99962, 23345, 100400, 13446, 128726, 127395, 126694, 106497, 121727

(C) SAP AG BC505 18

6.19

SAP AG 1999

Exercises?

Solutions

Unit Actions

(C) SAP AG BC505 19

6.20Performing Backups: ExercisesNo. Exercise

1 Database Backups

This exercise teaches you to use SAP database backup tools. The exercise refers to the play databases, and is limited to the operating system level.

1.1 Using SAPDBA, perform a backup that meets the following criteria:

Whole

Offline

To disk

Without software compression

With a binary verify

1.2 Perform a backup that meets the following criteria:

Whole

Online

To disk

Without compression

Without using verify

Use either SAPDBA or BRBACKUP in the command prompt mode.

1.3 Confirm that your backup has been performed correctly by checking the log files at the operating system level, and by using SAPDBA. Where exactly has the data been backed up?

2 Scheduling Periodic Database Backups

This exercise teaches you to use the DBA Planning Calendar in the R/3 System.

2.1 Where in R/3 can you schedule database backups periodically, and check a backup after it has been run? (Please do not schedule a backup!)

3 Backing Up Offline Redo Log Files

This exercise teaches you to use SAP backup tools for offline redo log files. The exercise refers to the play databases, and is limited to the operating system level.

3.1 Using SAPDBA, perform an offline redo log file backup that meets the following criteria:

To disk

With a verify

As an exception, use the copy function save&delete.

3.2 Confirm that your offline redo log file backup has been performed correctly by checking the log files at the operating system level, and by using SAPDBA. Where exactly has the data been backed up?

4 Optional Exercise: Logical Database Backup Check

This exercise teaches you to check a logical database backup using the Oracle tool DB_VERIFY.

(C) SAP AG BC505 20

4.1 Check the backup you performed in exercise 1.1 for logical consistency using DB_VERIFY.

(C) SAP AG BC505 21

6.21Performing Backups: SolutionsNo. Solution

1

1.1 Start SAPDBA. To get to the backup menu, choose

h - Backup database.

To start the backup, choose a - Backup function: Normal backup. Specify the backup device type by choosing

c - Backup device type: local disk.

To define which objects are to be backed up, choose

d - Objects for backup: all.

To define the backup type, choose

e - Backup type offline.

Under h - Special options, choose

b – Compress: no

c – Verification after backup: Binary (offline) or by size (online)

To start the backup run, choose

S - Start BRBACKUP.

The backup run is extended significantly by a verify. Additional disk space is not required.

1.2 Solution using SAPDBA:

Start SAPDBA. To get to the backup menu, choose

h – Backup database.

To start the backup, choose

a – Backup function: Normal backup.

To specify the backup device type, choose

c - Backup device type: local disk.

To define which objects are to be backed up, choose

d – Objects for backup: all.

To define the type of backup, choose

e - Backup type online.

Under h - Special options, choose

b – Compress: no

c – Verification after backup: no.

To start the backup run, choose S - Start BRBACKUP.

Solution using BRBACKUP:

At the operating system level, enter:brbackup -c -d disk -t online -k no

To set BRBACKUP to the non-monitored mode, use the option –c. Before performing this call, set the database user system password to manager (NOTE: This is only for the play database; do not use this setting at home). If you have not done so, you must enter the password using

[-u|-user [<user>[/<password>]].

(C) SAP AG BC505 22

1.3 The BRBACKUP logs are in subdirectory sapbackup of directory $HOME:

cd

cd sapbackup

The detail log is named b<time stamp>.<ext>, with <ext> = afd signifying full offline on disk, and <ext>=and signifying full online on disk. Using the time the log was created, select the appropriate log, and view it by entering (for example):more b<time stamp>.<ext>.

To view logs in SAPDBA, choose l - Show/Cleanup a - Show log files / profiles e - BRBACKUP log files.

The files that have been backed up are located in subdirectories of sapbackup. The names of these subdirectories are identical to the corresponding names of the detail logs (without extensions).

2

2.1 You can schedule backups periodically from within R/3 by using the DBA Planning Calendar (transaction DB13).

To make an entry, double-click a free slot (that is, day). By entering a period (for example, 1 week) and going through the weekdays, a database administrator can quickly set up a backup strategy. For every backup entry, a corresponding background job is created. To display these background jobs, call transaction SM37.

The morning after the backup, the successful backup run should also be checked using transaction DB24 or DB13 (double-click the backup action).

3

3.1 Start SAPDBA. To get to the desired menu, choose

i - Backup offline redo logs.

To select the copy function, choose

a – Archive function d - Save and delete archive logs.

To specify the backup device type, choose

c – Archive device type: local disk.

Under h - Special options, choose

c – Verification after backup: yes

To start the backup run, choose S - Start BRARCHIVE.

NOTE: The backed up offline redo log files cannot be checked at the binary level for all copy functions. For an overview of copy functions, see the R/3 online documentation.

3.2 The BRARCHIVE logs are in subdirectory saparch of directory $HOME:

cd

cd saparch

The detail log is named b<time stamp>.<ext>, with <ext> = svd signifying save & delete on disk. Using the time the log was created, select the appropriate log, and view it by entering (for example):more b<time stamp>.<ext>.

To view logs in SAPDBA, choose

l - Show/Cleanup a - Show log files / profiles f - BRBACKUP log files.

(C) SAP AG BC505 23

The files that have been backed up are located in directory sapbackup.

4

4.1 You can perform a deferred logical check of a backup to tape, using SAPDBA, by choosing

h – Backup database a – Backup function f - Verify BRBACKUP tape.

The backup you ran for exercise 1.1 was performed to disk. Such backups cannot be checked from within SAPDBA; however, they can be checked using BRRESTORE at the command prompt level.

First, determine the name of the BRBACKUP detail log from exercise 1.1.

To check the log, enterbrrestore -d disk -k no -w use_dbv –b <BRBACKUP-detail log>.

NOTE: For backups to disk, DB_VERIFY can only be used for runs without software compression.

(C) SAP AG BC505 24

7

SAP AG 1999

Restore and Recovery

1 Database Overview 6 Advanced Backup Techniques

2 Backup Strategy and Tape Management

7 Storage Management

3 Scheduling, Performing,and Monitoring Backups

8 Performance Monitoring

4 Restore and Recovery 9 Top 10 Problems

5 Backup Strategies Using RMAN

(C) SAP AG BC505 1

7.2

SAP AG 1999

Restore and Recovery

Contents Restore and recovery options using SAPDBA

SAPDBA functions and their limitations

ObjectivesAt the end of this unit, you will be able to:

Analyze the physical database structure using SAPDBA

Recover the database using the SAPDBA function

Partial Restore and Complete Recovery

Reset the database using the SAPDBA function Reset Database

Perform a point in time recovery using the SAPDBA function

Full Restore and Recovery

(C) SAP AG BC505 2

7.3

SAP AG 1999

Error types:

Statement

Process

Instance

User

Media

Database Errors

“Most importantly, be prepared for disasters. Don’t think you will never

see a failure. Every DBA will experience a database failure. I t’s just a matter of when...

Good luck.” Rama Velpuri

In an Oracle database, various kinds of errors can occur that require the database administrator (DBA) to take action. The different types of database error are: Statement errors, such as an attempt to enter incorrect data in a table. Oracle terminates the

statement with an error message, and performs a statement rollback. Process errors, such as termination of the connection between a work process and a server

process. PMON rolls back the open transaction, and releases occupied resources. Instance errors, such as when a background process fails. The next time an instance is started, a

consistent status is restored by means of automatic instance recovery. User errors, such as when a user accidentally enters the SQL statement drop table. Media errors, such as a head crash, or accidental deletion of a database file.

If user and media errors occur, the DBA must take action. This unit describes both of these error types and the appropriate repair scenarios.

To help you determine exactly when to apply Oracle tools, the SAPDBA functions and their limitations are discussed in detail in this chapter.

For further information about database errors, see the R/3 Online Documentation on database administration.

(C) SAP AG BC505 3

7.4

SAP AG 1999

Control files10

1010

38

3838

Offline and onlineredo log files11 12 37 38. . .

Data files

10

10

10

38

38

Full backup

109 36

38

Legend:Log sequence number 9

Scenarios: Introduction

In an R/3 System with an Oracle database, most data files have the status online and read/write. For a functioning, consistent database, all data files as well as the control files must therefore be synchronous – that is, they must match in terms of time.

Oracle creates synchronization data using time stamps. Time stamps are integers that are increased during certain database actions, and entered in all data and control file headers by the log writer or checkpointer process at the checkpoint.

An example of synchronization data is the log sequence number (LSN), which is increased by 1 during every log switch. At a more sophisticated level, Oracle can define synchronization on transaction level using the system change number (SCN), which is increased, for example, after the COMMIT in a change transaction, or at the checkpoint.

The scenario shown in this slide (and the following three slides) depicts a database that has been saved completely and error-free at time LSN=10. At time LSN=38, a media or user error damages the database so extensively that the database instance breaks down or the database is inconsistent. The offline and online redo log files that were created between the beginning of the backup and the occurrence of the error are available.

(C) SAP AG BC505 4

7.5

SAP AG 1999

38

3838

38

38

38

38

3838

10

38

10

Partial restore

10 11 37 38. . .

Complete recovery

39 . . .

mount open

Scenario: Partial Restore and Complete Recovery

Control files

Offline and onlineredo log files

Data files

Scenario: Because of a head crash, data has been lost during business operation. The database is inconsistent, and is no longer running properly.

A partial restore and complete recovery is performed to get the database running properly again, and to recover the database to its status just before the error occurred.

During a restore, database files are copied from the backup medium back to the disk. During a partial restore and complete recovery, only the required minimum of data is copied. The database files that are to be copied back can be combined from different backups. Because the database files are no longer synchronous after a partial restore, the database is inconsistent and will not run properly after the copy-back procedure has terminated.

To synchronize the files, the database evaluates the synchronization data that has been saved in the file headers. The database requests all offline redo log files that have accumulated since the “oldest” database file (in logical terms), in uninterrupted sequence. During a recovery, all data changes logged by these offline redo log files are replicated in the files that have been copied back. With a partial restore and complete recovery, all changes are performed again until all data files are at the same SCN (a procedure called media recovery). When the database is subsequently started up, during the instance recovery, all transactions that are not committed are taken back, using the rollback segments, which are likewise recovered. The database is now consistent, capable of running, and back to its data status just before the error occurred.

(C) SAP AG BC505 5

7.6

SAP AG 1999

Full restore

10

1010

10

10

10

9

10 11 37 38. . .

10 11 . . .

open

Scenario: Database Reset

Control files

Offline and onlineredo log files

Data files

Scenario: During an upgrade, extensive software or hardware problems have arisen. As a result, the upgrade must be terminated. The database is inconsistent, and is no longer running properly. Fortunately, a full offline backup was performed immediately before the upgrade.

A database reset is performed to get the database running properly again, and to reset the database to its status immediately before the upgrade.

The database is reset using a full restore. With a full restore, all data files as well as the older online redo log files and control files are copied back from the backup medium. Since these files must originate from the same valid offline backup, the database is consistent and ready to run after the copy-back procedure has terminated. Therefore, a recovery is not required; the database can be started up at once.

After the database startup, new offline redo log files are generated which, at the technical level, “fit” the full backup as precisely as the old offline redo log files. If an additional full restore is required, you risk making a recovery possible in two different logical directions.

A database reset always results in data loss. The data that has been generated between the full backup and the problem situation is lost. Of course, the database as such does remain consistent.

(C) SAP AG BC505 6

7.7

SAP AG 1999

10

1010

10

10

10

10 11 25. . .1 2 . . .

26 37. . .

mount Open resetlogs

24

24

25

2525

25

25

25

1

11

1

1

1

Incomplete recovery

Scenario: Point in Time Recovery

Control files

Offline and onlineredo log files

Data files

Full restore

Scenario: During an upgrade, a user accidentally enters the command drop table. As a result, the upgrade must be terminated. A full backup is available, but was not performed immediately before the upgrade process began.

A point in time recovery is performed to get the database running properly again, and to reset the database to the status at a certain point in time before the upgrade. From that point on, the data is recovered up to a certain point, for example, up to the start of the upgrade, or up to the table drop.

Initially, all data files are replaced by copies of online/offline backups, using a full restore. The termination point of the recovery determines whether the control files should also be replaced. All data files and online redo log files are entered in the control files with specified paths. The control files must reproduce this file structure at the operating system level according to the status of the structure at the end of the recovery procedure.

During the recovery phase, the changes to the dataset are performed again. Incomplete recovery refers to the end point of recovery, which can be anywhere between the end of the copied backup and the last entry in the current online redo log. The recovery end point can be defined by the redo log file sequence number, or by specifying either a point in time or an SCN.

After a point in time recovery, the database is normally opened using alter database open resetlogs, unless a complete recovery is performed. Since a recovery cannot be performed after using open resetlogs, a whole backup must be triggered immediately.

(C) SAP AG BC505 7

7.8

SAP AG 1999

How to Handle Problems

Do not make any rash decisions

Analyze the problem in detail

Create a problem-solving strategy

Before restoring any files, check:

What is causing the problem

Whether there is enough disk space to save and restore files

Whether a hardware extension is necessary

The file system and mount points

The availability of backups

The availability of offline redo log files

If a database problem occurs, you must analyze the problem and create a problem-solving strategy. To analyze the database problem, check the database alert log and the trace files belonging to the

background processes in directory $ORACLE_HOME/saptrace/background. Your problem-solving strategy depends on the answers to the following questions: What is the status

of the database – available or not available? Is this a user error or a media error? Which files are corrupted? Which file types (data files, control files, online redo log files) are affected? Is software or hardware mirroring available?

To be on the safe side (and time permitting), perform a full offline backup before the files are copied back, using BRBACKUP or operating system (OS) backup tools.

In the event of a hard disk problem, such as a head crash, hardware must be replaced. In this unit, we assume that, at the OS level, a file system has been created and mounted at the old location.

If you followed the backup cycle recommended by SAP, you will have a number of database backups and offline redo log file backups for a restore and recovery. Your problem-solving strategy will determine which backup and offline redo log files are copied back, and how they need to be applied.

Do not make any rash decisions. If you make mistakes or act carelessly, you can drastically aggravate the restore and recovery situation. The costs incurred by a consulting session provided by SAP or an SAP partner are negligible compared to the business consequences of data loss, even for a single day of production operation.

(C) SAP AG BC505 8

7.9

SAP AG 1999

Detail logs

back<SID>.log arch<SID>.log Recoveryscript

saparch

Find offlineredo log files

Restoredata files

Recoverdatabase

Restore offlineredo log files

Findbackups

CheckDatabase

Database

Partial Restore and Complete Recovery (1)

The SAPDBA function partial restore and complete recovery replaces lost data files by using appropriate backups, and subsequently recovers the restored data file status using redo log files. To be able to use this function, your online redo log files and control files must be valid. The partial restore and complete recovery procedure consists of six phases that are executed either manually or automatically, in a predetermined sequence – that is, a particular phase can only be selected after the previous one has been completed successfully (status: finished or not needed).

In the Check Database phase, the status of all files in the database (that is, the control files, online redo log files, and data files) as well as the tablespace status (online/offline; online backup mode) are checked. Check Database can be executed regularly with the database running; thus, it provides an overview of the physical status of the database.

In the Check Database phase, SAPDBA refers to entries in Oracles V$Views (such as V$DATAFILE, V$RECOVER_FILE). If an error is detected during this phase, a safe check must be performed – that is, the database must be shut down (initially using shutdown immediate; if this is unsuccessful, SAPDBA suggests shutdown abort). Next, to update the V$Views, the database is set to status mount. SAPDBA logs any recorded errors in data files in directory sapreorg with the suffix (rcv) for recovery. A safe check is a prerequisite for any subsequent restore and recovery activities.

Missing sapdata directories are not created automatically; rather, they are mount points. However, missing subdirectories are created automatically.

(C) SAP AG BC505 9

7.10

SAP AG 1999

Detail logs

back<SID>.log arch<SID>.log Recoveryscript

CheckDatabase

Find offlineredo log files

Restorebackup files

Recoverdatabase

Restore offlineredo log files

Findbackups

saparch

Database

Partial Restore and Complete Recovery (2)

In the Find Backup Files phase, backups are determined using the entries in the BRBACKUP summary log file back<SID>.log (return code 0 or 1). The associated detail logs show whether the required data files were in the backup. The data files can be compiled from various backups. To minimize the subsequent recovery time, SAPDBA always suggests the most recent backup.

In the Restore Backup Files phase, the data files are restored to their original location. If only index files are missing, SAPDBA can recreate and build up these files using Database Dictionary information.

In the Find Offline Redo Log Files phase, the offline redo log files required for a complete recovery are determined. The BRARCHIVE summary log file arch<SID>.log lists the tapes where the offline redo log files have been saved. You can choose between a first or second backup (for example, when saved, with brarchive -cds). SAPDBA takes existing online redo log files and offline redo log files in saparch into consideration. After the appropriate backups have been found for all required offline redo log files, the Find Archive Files phase ends with the status finished.

In the Restore Offline Redo Log Files phase, the offline redo log files that have been found are read (from tape) back to directory saparch.

In the Recover Database phase, SAPDBA creates recovery scripts in a subdirectory of sapreorg. Using these scripts, a control file is saved, and a recover database statement (that is, a complete recovery) is transmitted to Oracle. The SAPDBA message Recover database terminated successfully indicates that the database has been recovered completely.

(C) SAP AG BC505 10

7.11

SAP AG 1999

Partial Restore and Complete Recovery Limitations

Logs

No data or offline redolog file backups available

No BRBACKUP/BRARCHIVElogs available

Control files damaged

Online redo log files damaged

init<SID>.* No init<SID>.*files available

Problem Solutions

Perform a database resetPerform a point in time

recovery

Use the SAPDBA function Restore individual files

Restore these files from tape using commandbrrestore -n init_ora

Copy one of its mirrors

See R/3 Online Help

The SAPDBA function partial restore and complete recovery can be used to restore lost data and to handle the most frequently occurring database problems. In some cases, however, partial restore and complete recovery requires additional manual tasks, or the use of Oracle tools.

If there are no appropriate data backups, or if all offline redo log files generated since the last backup are not available, you cannot run a partial restore and complete recovery. In this case, you must perform a database reset or a point in time recovery up to the last existing offline redo log file.

If other database files are corrupted, in addition to data files, the partial restore and complete recovery function terminates and you must restart this function once the additional error has been resolved.

If the BRBACKUP/BRARCHIVE logs cannot be found, you can restore them from the last backup using the SAPDBA function Restore individual files.

If the files init<SID>.dba and init<SID>.ora cannot be found, you can restore them from tape. At the command prompt, enter brrestore -n init_ora.

If init<SID>.sap has been lost, SAP tools can no longer access the tape drive. In this case, adapt a sample init<SID>.sap (directory SAP-EXE), or use OS command cpio to restore it from the third position on a BRBACKUP or BRARCHIVE tape.

If a control file is damaged, you can copy one of its mirrors. If all the control files or online redo log files are lost, see R/3 Online Help, section DBA Oracle.

(C) SAP AG BC505 11

7.12

SAP AG 1999

Database

sapreorg

Save currentonline redo log files

and control file

Overwrite alldata files, control files,

and online redo log files

Findfull offlinebackups

Detail logs

back<SID>.log

Databasemount

Databaseopen

Database Reset Using a Full Offline Backup

When you perform a database reset, the database is reset to its previous consistent status – that is, its status at the time of a full backup. To determine the last possible full backup, SAPDBA is guided by the entries in the BRBACKUP summary log file back<SID>.log and the associated detail logs.

Resetting the database always involves data loss. Therefore, SAP recommends performing a full offline backup before resetting the database. (If the database is running properly, use SAP tools; otherwise, use operating system tools.)

The SAPDBA function Reset Database can be selected with a full offline backup (choose Restore database and startup open or Restore database and startup mount), or a full online consistent backup (choose Restore database using online consistent backups).

Depending on the function chosen, SAPDBA sets the database ether to status open (that is, no reset logs) or to status mount. If the database has status mount, you can recover data using Oracle tools, such as the Server Manager. If the database has the status open, you cannot perform a retroactive recovery. For a retroactive recovery, use Restore database and startup mount instead of Restore database and startup open.

With a database reset using a full offline backup, the data files, control files, and online redo log files are overwritten using the appropriate (taped) backups. For security reasons, these files are copied immediately to a subdirectory of sapreorg. (To enable these copies to be made, the database must have the status mount.)

(C) SAP AG BC505 12

7.13

SAP AG 1999

Recoveryscript

saparch

Database

sapreorg

Save onlineredo log files

and control file

Find Online_Cons

backups

Detail logs

back<SID>.log

Recoverdatabase

until cancel

Databaseopen

resetlogs

Database Reset Using a Consistent Online Backup

Overwrite all

Data files andcontrol files

Offlineredo log files

When you perform a database reset using a full online consistent backup, the database is reset to a consistent status from the end (point in time) of the full backup.

With a database reset using a full online consistent backup, data files, control files, and offline redo log files are overwritten by the appropriate (taped) backups. Therefore, you must save all offline redo log files in saparch using BRARCHIVE and perform a full backup before you reset the database using Online_Cons. During this process, note the messages displayed by SAPDBA.

After a full restore, during a point in time recovery (recover database using backup controlfile until cancel), only the offline redo log files created during the online consistent backup are restored and applied. No other point in time can be chosen. The database is then started using option resetlogs. The online redo log files are newly initialized or newly created. Data cannot be recovered after opening the database with the option resetlogs, therefore, you must perform a backup. None of the backups performed before the database reset using online consistent backups can be used for a partial restore and complete recovery. Note: After a successful database reset, any offline redo log files that have been restored should be deleted manually from saparch.

If SAP tools have been used, reworking is required after a database reset. Since log tables SDBAH and SDBAD are reset to an obsolete status, BRBACKUP may request tapes that have been released (in logical terms), but which are physically still locked. BRARCHIVE may not recognize the new offline redo log files as needing to be saved. For more details, see R/3 Online Help, chapter DBA Oracle.

After a successful database reset, the data files can be searched for corrupt blocks, using the Oracle tool DB_VERIFY.

(C) SAP AG BC505 13

7.14

SAP AG 1999

Find offlineredo log files

Find full offline/online backups

Detail logs

back<SID>.log arch<SID>.log

Recoveruntil?

Status:allowed?

reorg<SID>.log

Database

Input:time

Not allowed if (for example):- No backup specified- No offline redo log files found- Recovery over tablespace reorg- Backup before open resetlogs

Full Restore and Recovery (1)

With a full restore and recovery, the database is reset to a consistent status between the (end) point in time of the full backup, and the current point in time. This SAPDBA function corresponds to the point in time recovery.

A full restore and recovery usually involves data loss. Therefore, SAP recommends that you perform a full offline backup before any full restore and recovery. (If the database is running properly, use SAP tools; otherwise, use operating system tools.) In addition, all offline redo log files in saparch should be saved using BRARCHIVE.

A full restore and recovery can be performed using SAPDBA if the database can be set to status mount or open. First, a full online (or, if applicable, Online_Cons), or a full offline backup must be selected. Again, SAPDBA is guided by the BRBACKUP summary log file back<SID>.log and the corresponding detail logs. Next, enter the recovery end point. For a complete recovery, enter NOW. The offline redo log file backups required for this point in time recovery are determined using the entries in the BRARCHIVE summary log file arch<SID>.log.

Under Show Status, SAPDBA indicates whether the intended recovery is allowed (status: allowed). A recovery may be rejected if: No full backup has been specified, or the required offline redo log files have not been found The recovery to be run contains a tablespace reorganization with data files The selected backup is dated before the last time the database was opened using the option

resetlogs.

(C) SAP AG BC505 14

7.15

SAP AG 1999

Recoveryscript

saparchsapreorg

Save onlineredo log files

and control file

Recoverdatabase

(until time)

Database

Databaseopen

(resetlogs)

Overwrite allData files andcontrol files

(if necessary)Offline redo

log files

Full Restore and Recovery (2)

For security reasons, the current online redo log files and a control file are copied to a subdirectory of sapreorg. All data files are restored from the backup medium (full restore). The control files may also be restored, depending on whether a tablespace was extended at the recovery time point.

After a full restore, SAPDBA can replicate the tablespace extension in the database, using alter database add data file... Information about file specifications is contained in directory sapreorg in the SAPDBA logs struct<SID>.log and reorg<SID>.log. After a tablespace extension, or after moving data files to another location, ensure you back up the newly changed structure.

The offline redo log files required for the indicated recovery time point are restored to directory saparch. Using a recovery script, the database is recovered to the desired point in time (recover database until time xxyyzz [using backup controlfile]).

If recovery was incomplete, the database must be opened using the option resetlogs. Using the Oracle tool DB_VERIFY, the database can be searched for corrupt data blocks. In addition, SAPDBA automatically goes to the backup menu, since the database has been opened using resetlogs.

The copied offline redo log files should be deleted from directory saparch. If you have used SAP tools, reworking is required after an incomplete recovery. For more details, see R/3 Online Help, chapter DBA Oracle.

(C) SAP AG BC505 15

7.16

SAP AG 1999

Unit Summary

Now you are able to:

Analyze the physical database structure using SAPDBA

Recover the database using the SAPDBA function Partial Restore and Complete Recovery

Reset the database using the SAPDBA function Reset Database

Perform a point in time recovery using the SAPDBA function Full Restore and Recovery

(C) SAP AG BC505 16

7.17

SAP AG 1999

Further Documentation

Knowledge Product CD

SAP Database Administration Oracle

R/3 Online Help

Basis Database interface DBA Oracle

SAP TechNet

Information Media Center System Management CCMS

R. Velpuri, A. Adkoli

Oracle8 Backup and Recovery Handbook. Oracle Press, Osborne

(C) SAP AG BC505 17

7.18

SAP AG 1999

Exercises?

Solutions

Unit Actions

(C) SAP AG BC505 18

7.19Restore and Recovery: ExercisesNo. Exercise

1 Partial Restore and Complete Recovery Using SAPDBA

This exercise demonstrates database behavior after accidental loss of data, with the aim of familiarizing the participant with use of the SAPDBA function Partial restore and complete recovery, and of pointing out the limitations of this program.

1.1 Ensure that at least one valid full backup (online/offline) is available, and that your offline redo log file chain is backed up without any gaps.

1.2 Simulate a head crash by deleting the entire contents of directory sapdata3 (subdirectories protd_1, stabi_1, user1i_1).

Restore your database completely using one of the backups you performed for the unit "Scheduling, Performing, and Monitoring Backups". Use the SAPDBA function Partial restore and complete recovery.

1.3 Simulate a head crash by deleting directory sapdata2 (subdirectories proti_1, stabd_1, user1d_1, cntrl).

Restore your database completely using one of the backups you performed for the unit "Scheduling, Performing, and Monitoring Backups". Use the SAPDBA function Partial restore and complete recovery. Choose the option Partial restore and complete recovery a second time after you have eliminated the error.

(C) SAP AG BC505 19

7.20Restore and Recovery: SolutionsNo. Solution

1

1.2 Change to directory sapdata3, using cd /oracle/<SID>/sapdata3.

To confirm that only subdirectories protd_1, stabi_1, user1i_1 are located in sapdata3, enter ls –l.To delete these directories, enterrm –r protd_1, stabi_1, user1i_1.

Start SAPDBA. Under j: Restore/Recovery, choose a: Partial restore and complete recovery. To determine the function of each of the six phases, run through each of them manually and in sequence.

In the a: Check phase, the loss of data files is detected. Next, SAPDBA attempts to shut down the database, using shutdown immediate. Since a consistent data file status can no longer be achieved, this attempt fails. The DBA must subsequently confirm the shutdown abort. SAPDBA brings the database to the mount status, and detects the loss of a total of three data files.

In the b: Find Backup Files phase, under d: Select a backup run for restore, you can choose one of the backups you performed for the unit "Scheduling, Performing, and Monitoring Backups". SAPDBA automatically suggests the most recent backup. Under c: Select a backup file for restore, confirm that the backup you have chosen is being used for the restore.

After the desired data files have been successfully restored during the c: Restore Backup Files phase, the required offline redo log files are determined during the d: Find Archive Files phase.

If backups have been performed to several tapes (for example, brarchive -cds), the individual runs can be selected under e: Restore Archive files.

Recovery is started using f: Recover Database. The message Recover database terminated successfully indicates successful completion of a repair action.

1.3 Change to the Oracle home directory using cd /oracle/<SID>. Delete this directory by entering rm –r sapdata2.

As with exercise 1.2, change to the expert mode. Under j: Restore/Recovery, start the function a: Partial restore and complete recovery.

In this scenario, along with directory SAPDATA, a control file has also been lost in addition to data files. When this error occurs, the DBA must take manual action. During the check phase, Partial restore and complete recovery is aborted.

In file init<SID>.ora, check where the database expects control files, and enter:cd /oracle/<SID>/dbsmore init<SID>.ora

Check the value set for parameter controlfiles.

Using SAPDBA, shut down the database, by choosinga: Startup/Shutdown instance b: Shutdown d: Shutdown abort

Create directory sapdata2 once again (normally, this is the mount point in the

(C) SAP AG BC505 20

database system).

Shut down the database using SAPDBA with Shutdown abort. In file init<SID>.ora, confirm the location of your database control files, and their names (under parameter control_files). In directory sapdata2, create a subdirectory for the control file, and copy a mirror of the control file to this subdirectory. (NOTE: Copying a control file from one of your backups leads to an unnecessary recovery situation that can only be resolved by a full restore and full recovery, or by using Oracle commands.)

Next, the SAPDBA function partial restore and full recovery can be restarted. It then runs automatically.

In the Oracle home directory, create a new sapdata2 directory. For this directory, create a subdirectory for the control file by entering:cd /oracle/<SID>mkdir sapdata2cd sapdata2mkdir cntrl

Copy a mirrored control file <source> to the new directory.cd cntrlcp <source>

NOTE: Copying a control file from one of the backups leads to a recovery situation that can no longer be resolved using Partial restore and complete recovery.

As for exercise 1.2, in SAPDBA under j: Restore/Recovery, start the function a: Partial restore and complete recovery. The database repair is now processed as described in exercise 1.2.

(C) SAP AG BC505 21

8

SAP AG 1999

Backup Strategies Using RMAN

1 Database Overview 6 Advanced Backup Techniques

2 Backup Strategy and Tape Management

7 Storage Management

3 Scheduling, Performing,and Monitoring Backups

8 Performance Monitoring

4 Restore and Recovery 9 Top 10 Problems

5 Backup Strategies Using RMAN

(C) SAP AG BC505 1

8.2

SAP AG 1999

Contents Backup strategies using RMAN

ObjectivesAt the end of this unit, you will be able to: Explain the various backup strategies using RMAN Decide whether RMAN backup strategies fit the

needs of your company

Backup Strategies Using RMAN

RMAN (Recovery Manager) is delivered with Oracle. This chapter describes the various RMAN backup options that are available for use with SAP tools.

(C) SAP AG BC505 2

8.3

SAP AG 1999

Full Backup (Level 0) with RMAN and SAP Tools (1)

cpio/dd

brbackup

RMAN

Control files

Database files

111

222

333

level 0:

backup_modebackup_mode = full= full

tape_tape_copy_cmdcopy_cmd = cpio|dd= cpio|dd

cpio/dd

If you use SAP tools for a database backup with RMAN, you cannot perform a native backup with RMAN.

Two types of backup using RMAN can be performed: Full backup (also called level 0 backup) Incremental backup (also called level 1 backup). An incremental backup is based on the last full

backup, and will be discussed later in this chapter. For more information about full, incremental and whole backup types, see SAP Note 170013. A full backup is always performed with backup_mode = full. In a full backup, there are two ways of

writing data to tape: Backing up data with RMAN Backing up data with OS tools

If SAP tools are used, no recovery catalog is required. The backed up data files are cataloged in the control file.

With full backup with OS tools, the tape_copy_cmd parameter is set to cpio or dd and the data files are saved to tape with the command specified. After that, brbackup starts RMAN. RMAN catalogs the backed up data files to the control file as level 0 backup. A control file is then backed up to tape with the OS tool specified (cpio or dd).

(C) SAP AG BC505 3

8.4

SAP AG 1999

Full Backup (Level 0) with RMAN and SAP Tools (2)

Oracleshadowprocess

222

333RMAN

level 0:

SBT Lib

backup_modebackup_mode = full= full

tape_copy_tape_copy_cmdcmd = rman= rman

222

Control files

Database files

cpio

brbackup

111

With full backup with RMAN the tape_copy_cmd parameter is set to rman. Brbackup starts RMAN, which backs up the data files. RMAN reads all data file blocks, and only backs up those blocks that are no longer in initial status. Consequently, blocks from dropped tables are also backed up. The blocks are backed up by the Oracle shadow process direct to tape. A backup library for Oracle must therefore be installed (see SAP Note 142635). During the data file backup, RMAN catalogs the level 0 backup to the control file. After the data file backup, a control file (with all level 0 information) is saved to tape.

Advantages of backing up with RMAN: All blocks are checked for block corruption The tablespaces are not set to begin/end backup mode. Thus, usually, fewer offline redo log files

are created. Less data to be backed up

Caution: A whole or partial backup with RMAN (tape_copy_cmd=rman, backup_mode = all) is possible, but is not a level 0 backup. However, all other advantages mentioned above apply.

Full backups to disk can also be performed (backup_dev_type=disk). The parameter disk_copy_cmd is used instead of the parameter tape_copy_cmd, with the corresponding settings. The method differs only where RMAN is used: No backup library for Oracle is needed, and data files instead of savesets are saved (as is the case when using OS tools).

(C) SAP AG BC505 4

8.5

SAP AG 1999

saveset

Header

Trailer

Savesets

saveset_members = 1| 2| 3| 4 saveset_members = tsp saveset_members = all

saveset

Header

Trailer

saveset

Header

Trailer

btabd.data1

btabd.dataX

saveset

Header

Trailer

saveset

Header

Trailer

datafileA

datafileB

datafileC

datafileD

datafile1

datafileN

In a backup using RMAN, the tape layout is the same as with a backup using OS tools. The difference is that savesets are backed up instead of data files.

A saveset consists of a header, a trailer, and the blocks of at least one data file. Savesets are only used when the backup is performed with RMAN.

The init<SID>.sap parameter saveset_members determines the number of savesets. This parameter can be overridden in sapdba or by calling up brbackup.

The following settings are possible: 1, 2, 3, 4, tsp or all. For example: If saveset_members = 4, four data files are grouped together to form one saveset. In a complete

database backup, several savesets are formed, each with the data from four data files. These savesets are backed up to tape.

If saveset_members = tsp, a saveset is formed for every tablespace that is to be backed up. The saveset contains the data of all data files per tablespace.

If saveset_members = all, only one saveset is formed. This saveset contains the data of all data files.

If savesets are formed from more than one data file, RMAN reads the data in parallel from the appropriate data files. Advantage: Higher output to the tape station(s). Fast tape stations can be kept in streaming mode,

thus reducing the time required for a backup. Disadvantage: In a restore/recovery situation, if the data from one data file is needed, the complete

saveset must be read from the tape. If a disk that contains several data files is damaged, these data files must be restored from several savesets for the restore/recovery.

(C) SAP AG BC505 5

8.6

SAP AG 1999

Preparation Run

brbackup

111

222

RMAN

/dev/null

compressionrate

saveset_members = 1saveset_members = 1

saveset_members = 4saveset_members = 4

saveset 1: compressratio xsaveset 1: compressratio x

datafileAdatafileA

datafileBdatafileB

datafileCdatafileC

datafileDdatafileD

saveset 2: compressratio ysaveset 2: compressratio y

saveset_members = tspsaveset_members = tsp

saveset_members = allsaveset_members = all

333

444

data file

Start preparationrun once per cycle

Start preparationrun once per cycle

OracleshadowprocessSBT Lib

brtools

If tape stations with hardware compression, or savesets with more than one member, are used, you must perform a preparation run.

In the preparation run, brbackup starts an RMAN backup of every data file to a saveset of its own. The data is compressed by brtools, and sent to /dev/null. Therefore, no additional space on the hard disk is required. The compression rate of every saveset with one member is verified by brtools, and sent to brbackup.

At this point, brbackup determines how data files are allocated to savesets for every possible value of saveset_members, and calculates the compression rate of each saveset. The allocation cannot be controlled, and only changes (if necessary) when a further preparation run is performed. Therefore, between two preparation runs, if the saveset_members parameters are the same, the savesets contain the same data files.

If data files exist that were not included in the preparation run (for example, because a data file was added), each one of these files is put in its own saveset.

We recommend that you perform a preparation run once per backup cycle, or after major database changes, for example, reorganization, mass data transfer, or an SAP or database release upgrade.

(C) SAP AG BC505 6

8.7

SAP AG 1999

Incremental (Level 1) Backup

Level 0 backup

10

1010 25

2525

brbackup

Oracleshadowprocess

RMAN

Level 1 backup

111

222

333

level 0: # 10level 0: # 10Control files

Database files

SBT Lib

cpio/dd

10

10

10

25

25

25

Incremental backup (also known as level 1 backup) is always based on the last level 0 backup (full backup). With SAP tools, only cumulative level 1 backup is supported as incremental backup. RMAN retrieves information about the last level 0 backup from the control files. An incremental backup is always a backup of the whole database, not of individual data files.

In an incremental backup, all blocks of all data files are always read. However, only those blocks that have changed since the last level 0 backup are backed up. Therefore, if long backup runtime was caused by low throughput on the tape stations, incremental backup can reduce the backup time.

Only one saveset (ending in .INCR) is created for an incremental backup The parameter saveset_members is set to all. Since only one saveset is created, the backup must fit on one tape. Follow-up tapes cannot be used. After the incremental backup is complete, a control file is saved to tape.

If data files have been added to the database between the last level 0 backup and the level 1 backup, a level 0 backup is performed for these new data files before the level 1 backup starts. All new data is backed up to one saveset (ending in .FULL), even if the data was partially backed up.

(C) SAP AG BC505 7

8.8

SAP AG 1999

Level 1 Backup: Important Considerations (1)

Sat/Sun

Level 0backup

Level 1backup

Level 1backup

Level 1backup

Mon Tue Fri

. . .

. . .

Level 0backup

Mon Fri

Level 1backup

Level 1backup

. . .

. . .

data files data files

Partial restore and complete recoPartial restore and complete recovery with very with sapdbasapdba

recovery with offline redo log filesLevel 1 backup based on Level 0 backup

Sat/Sun

With SAP tools, only cumulative incremental backups are supported at level 1. This means that incremental backups contain all blocks that have changed since the most recent level 0 backup (in relation to the time the level 1 backup was performed).

If a restore/recovery is necessary (for example, due to a disk crash), a level 1 backup is not sufficient to repair the database. The level 0 backup of the damaged data files are always needed. These data files must be restored from the level 0 backup. Then the changed blocks from the level 1 backup (which must be based on this level 0 backup) can be imported to the data file. Now you only need to perform a recovery from the time the level 1 backup was made. If no level 1 backup is available for this level 0 backup, then you must perform a recovery based on the last available level 0 backup. This usually takes longer than using the level 1 backup as a basis.

If the latest level 0 backup is damaged, then you must use the previous level 0 backup as a basis for recovering the data file. Only level 1 backups can be used that are based on this (that is, previous) backup. The level 1 backups that are based on the damaged level 0 backup cannot be used.

(C) SAP AG BC505 8

8.9

SAP AG 1999

Level 1 Backup: Important Considerations (2)

Recommended:1 level 0 backup

per week

Strongly recommended:4 level 0 backups

per cycle(if necessary, increase

backup cycle)

As basis for alevel 1 backup

We recommend that you Perform at least one level 0 backup per week

We strongly recommend that you Ensure that each backup cycle contains four level 0 backups. If necessary, increase the backup

cycle. Otherwise, the whole backup strategy is dependent on one or two level 0 backups. If the most recent level 0 backup was not performed in the current backup cycle, a warning appears when the level 1 backup is performed. Caution: If the most recent level 0 backup was not performed in the current backup cycle, then it cannot normally be used for a restore because it has been overwritten. Therefore, if a disk error occurs, the result can be a complete loss of data.

We recommend that you verify a level 0 backup at least once per backup cycle, but preferably once a week. A delayed verification with brrestore is only possible on the database host with an open or mounted database.

(C) SAP AG BC505 9

8.10

SAP AG 1999

Recovery Using Incremental Backup with sapdba

Database

Restoredata files

Findbackups

Detail logs

back<SID>.log

CheckRecoverdatabase

Recoveryscript

saparch

Findoffline

redo log files

arch<SID>.log

Restorelevel 1backup

Detail logs

back<SID>.log

Findlevel 1

backups

Findlevel 0

backups

Restore offline redo log files

Restorelevel 0backup

A partial restore and complete recovery with level 0 and level 1 backup is only slightly different than a partial restore and complete recovery of a whole backup.

The check and repair phase is performed as normal. In the find backup phase, the level 0 backup is selected. In the restore backup phase, the data file(s)

is/are restored. In the find level 1 backup phase, a level 1 backup is selected that is based on the level 0 backup

selceted. In the restore level 1 backup, the blocks that were backed up in the level 1 backup are written to the restored data files.

The phases that follow are performed as normal.

(C) SAP AG BC505 10

8.11

SAP AG 1999

Unit Summary

Now you are able to:

Explain the various backup strategies using RMAN

Recognize the advantages and limitations of these strategies

Decide whether RMAN backup strategies fit the needs of your company

(C) SAP AG BC505 11

8.12

SAP AG 1999

Further Documentation

Knowledge Product: SAP Database Administration Oracle

R/3 Online Documentation: BC SAP Database Administration: Oracle

SAPTechNet DB Admin. Oracle Knowledge Base

SAP Note 170013

(C) SAP AG BC505 12

8.13

SAP AG 1999

Exercises?

Solutions

Unit Actions

(C) SAP AG BC505 13

8.14Backup Strategies Using RMAN: Exercises(Optional)

No. Exercise

1 Full Backup (Level 0)

In these exercises you perform a full backup with the SAP database backup tools. The exercise refers to the play databases, and is limited to the operating system level.

1.1 Maintain the standard settings for full backups in the file init<SID>.sap.

Decide whether to perform the full backup with OS tools or with RMAN and maintain the appropriate parameter. (Ensure that the backup is made to disk.)

1.2 Perform a full backup to disk with SAPDBA.

1.3 Confirm that your full backup has been performed correctly by checking the log files at the operating system level, and by using SAPDBA.

1.4 Optional: Force several log file switches (ca. 3)

2 Incremental Backup (Level 1)

2.1 Perform an incremental backup to disk with SAPDBA.

2.2 Confirm that your incremental backup has been performed correctly by checking the log files at the operating system level, and by using SAPDBA.

2.3 Which file contains the backed-up blocks?

Where can you find this file?

3 Partial Restore and Complete Recovery Using Incremental Backup with SAPDBA

3.1 Ensure that at least one valid full backup (Level 0, online/offline) is available, and that your offline redo log file chain is backed up without any gaps.

3.2 Simulate a head crash by deleting the entire contents of directory sapdata3 (subdirectories protd_1, stabi_1, user1i_1).

3.3 Repair your database using the full and incremental backups you performed in Exercises 1 and 2. Use the SAPDBA function Partial restore and complete recovery.

(C) SAP AG BC505 14

8.15Backup Strategies Using RMAN: SolutionsNo. Solution

1

1.1 Using the OS editor, in file /oracle/<SID>/dbs change the following parameters of file init<SID>.sap:

backup_mode = full

backup_dev_type = disk

disk_copy_cmd = copy

or dd or rman

1.2 Start SAPDBA. To get to the backup menu, choose

h - Backup database.

To start the backup, choose a - Backup function: Normal backup. Specify the backup device type by choosing

c - Backup device type: local disk.

To define which objects are to be backed up and which kind of backup is to be performed, choose

d - Objects for backup: full.

To define the backup type choose for example

e - Backup type online.

Under h - Special options, choose

b – Compress: no

To start the backup run, choose

S - Start BRBACKUP.

1.3 The BRBACKUP logs are in subdirectory sapbackup.cd /oracle/<SID>/sapbackup

The detail log is named b<time stamp>.<ext>, with <ext> = fnd signifying full online on disk, and <ext>=ffd signifying full offline on disk. Using the time the log was created, select the appropriate log, and view it by entering (for example)more b<time stamp>.<ext>

To view logs in SAPDBA, choose l - Show/Cleanup a - Show log files / profiles e – BRBACKUP log files.

The files that have been backed up are located in subdirectories of sapbackup. The names of these subdirectories are identical to the corresponding names of the detail logs (without extensions).

1.4 Start the Oracle server manager using: svrmgrl

Dispatch the following commands in the order shown below:

connect internal;

alter system switch logfile;

alter system switch logfile;

alter system switch logfile;

exit;

(C) SAP AG BC505 15

2

2.1 Start SAPDBA. To get to the backup menu, choose

h - Backup database.

To start the backup, choose a - Backup function: Normal backup. Specify the backup device type by choosing

c - Backup device type: local disk.

To define which objects are to be backed up and which kind of backup to perform, choose

d - Objects for backup: incr.

To define the backup type, choose for example

e – Backup type online.

Under h – Special options, choose

b – Compress: no

To start the backup run, choose

S – Start BRBACKUP.

2.2 The BRBACKUP logs are in subdirectory sapbackup.cd /oracle/<SID>/sapbackup

The detail log is named b<time stamp>.<ext>, with <ext> = ind signifying incremental online on disk, and <ext>=ifd signifying incremental offline on disk. Using the time the log was created, select the appropriate log, and view it by entering (for example)more b<time stamp>.<ext>

To view logs in SAPDBA, choose l - Show/Cleanup a - Show log files / profiles e – BRBACKUP log files.

The files that have been backed up are located in subdirectories of sapbackup. The names of these subdirectories are identical to the corresponding names of the detail logs (without extensions).

2.3 The blocks are backed up to a file named B<time stamp>.INCR. If new data files have been added to the database since the last full backup, then those blocks are backed up to a file named B<time stamp>.FULL.

The files that have been backed up are located in subdirectories of sapbackup. The names of these subdirectories are identical to the corresponding names of the detail logs (without extensions).

3

3.1 See 1.3

3.2 Change to directory sapdata3, using cd /oracle/<SID>/sapdata3.

To confirm that only subdirectories protd_1, stabi_1, user1i_1 are located in sapdata3, enter ls –l.To delete these directories, enterrm –r protd_1, stabi_1, user1i_1.

3.3 Start SAPDBA. Under j: Restore/Recovery, choose a: Partial restore and complete recovery. To determine the function of each of the eight phases, run through each of them manually and in sequence.

In the a: Check phase, the loss of data files is detected. Next, SAPDBA attempts to shut down the database, using shutdown immediate. Since a

(C) SAP AG BC505 16

consistent data file status can no longer be achieved, this attempt fails. The DBA must subsequently confirm the shutdown abort. SAPDBA brings the database to the mount status, and detects the loss of a total of three data files.

In the b: Find Backup Files phase choose S: Start finding backup files, under d: Select a backup run for restore, you can choose one of the backups you performed in Exercise 1. SAPDBA automatically suggests the most recent backup.

In the c: Select a backup file for restore phase, confirm that the backup you have chosen is being used for the restore.

In the i: Find incr. backup phase, choose S: Find appropriate incremental backup runs, under a: Select an incr. backup run for restore, you can choose one of the incremental backups you performed in Exercise 2. SAPDBA automatically suggests the most recent backup.

In the j: Restore incr. backup phase, confirm that the incremental backup you have chosen is being used for the restore.

After the desired data have been successfully restored, the required offline redo log files are determined during the d: Find Archive Files phase. Choose S: Find offline redo logs

in the e: Restore Archive files phase, confirm that the redo log files you have chosen are being used for the restore.

Recovery is started using f: Recover Database. The message Recover database terminated successfully indicates successful completion of a repair action.

(C) SAP AG BC505 17

9

SAP AG 1999

Advanced Backup Techniques

1 Database Overview 6 Advanced Backup Techniques

2 Backup Strategy and Tape Management

7 Storage Management

3 Scheduling, Performing,and Monitoring Backups

8 Performance Monitoring

4 Restore and Recovery 9 Top 10 Problems

5 Backup Strategies Using RMAN

(C) SAP AG BC505 1

9.2

SAP AG 1999

Advanced Backup Techniques

Contents Advanced Backup Techniques

ObjectivesAt the end of this unit, you will be able to:

Explain the various backup strategies supported by SAP

Decide which strategies fit your needs

(C) SAP AG BC505 2

(C) SAP AG BC505 3

9.3

SAP AG 1999

... ... Logsinit files

Tapeheader

Data files Offline redo log filesin saparch

Databasebackup

Offline redo log filebackup

brbackup -m all -c -a -cds -c

BRBACKUP and BRARCHIVE: One-Run Strategy

The advantage of the one-run strategy is that for a complete backup, BRBACKUP and BRARCHIVE are called together rather than individually. Only one tape pool (in this example volume_backup) is used. The offline redo log files are backed up to the tapes where the database files are backed up. As a result, tapes can be saved, and the administrative workload reduced.

SAP recommends that you use the one-run strategy for BRBACKUP: BRBACKUP <database backup options> -a <offline redo log backup options> With this procedure, BRBACKUP backs up all files (as usual) and then starts BRARCHIVE using the options entered after -a. BRARCHIVE first backs up the corresponding offline redo log files (as usual), and then backs up all logs (including BRBACKUP logs). When a complete backup is planned using CCMS, the recommended one-run strategy is used.

With the one-run strategy, the maximum number of offline redo log files that can be backed up is the number that can still fit on the tape after the database backup. If more offline redo log files are generated daily than can be backed up, for example because the database has grown, or the number of offline redo log files is increasing, an archiver stuck occurs. Therefore, you must regularly check whether the tape capacity is sufficient. If necessary, you should use larger tapes, an extra tape station, or another backup strategy.

The one-run strategy cannot be used to resolve an archiver stuck, since BRBACKUP attempts to connect to the database. If an archiver stuck is to be resolved using BRARCHIVE, tapes must be available in tape pool volume_archive (that is, the “emergency tape pool”).

(C) SAP AG BC505 4

(C) SAP AG BC505 5

9.4

SAP AG 1999

DDS

DDSDLT DLT

DLT

BRBACKUP

init<SID>.sapexec_parallel = 0tape_address = (dev1, dev2, dev3)archive_function = double_save_deletetape_address_arch = (dev4, dev5)

BRARCHIVE

Control files

Offline redo log filesin saparch

Parallel Tape Support

To reduce the time required for backing up and restoring the data files and offline redo log files, the SAP backup tools support the parallel use of several tape stations.

BRBACKUP uses all tape stations defined in parameter tape_address in file init<SID>.sap. Parameter exec_parallel should be set to 0, since this triggers a copy process (cpio, dd) for each tape station.

To reduce the backup time, the database files are distributed across the tape stations. For tape stations with hardware compression, the backup time does not necessarily correlate directly with the data volume. Therefore, BRBACKUP refers to the times required by previous backup runs. If time optimization would result in an additional tape change, time optimization is not performed. To keep backup times to a minimum, the total tape station capacity should be significantly larger than the total volume of data to be backed up.

BRARCHIVE supports parallel backups of offline redo log files on two separate tape stations, which is defined in parameter tape_address_arch. If this parameter is not set, BRARCHIVE uses the first two tape stations defined in tape_address. As backup options for archive_function, you can choose double_save or double_save_delete.

If data must be restored from tape to disk, BRRESTORE also uses all tape stations defined in tape_address(_arch) in parallel, which minimizes the restore time.

(C) SAP AG BC505 6

(C) SAP AG BC505 7

9.5

SAP AG 1999

System, roll, andtemp tablespace

brbackup-m all_data

Datatablespaces

Pure indextablespaces

Backing Up Data Tablespaces Only

Another method of reducing backup times is to limit backups to data tablespaces. If index tablespaces are lost, the indexes must be rebuilt using information from the Oracle Dictionary. To be able to use this procedure, the database administrator must have extensive background information.

When choosing tablespaces, BRBACKUP does not refer to tablespace naming convention; instead it evaluates Oracle tables. Therefore, BRBACKUP ensures that only those tablespaces that are either empty or only contain indexes are excluded from the backup procedure. This ensures that tablespaces SYSTEM, PSAPROLL, and (unless empty) PSAPTEMP, which are required to run the database, are always backed up as well.

You can perform a backup limited to data tablespaces by calling SAPDBA (choose d - Objects for backup, and enter all_data), or by running BRBACKUP directly (using the command prompt option -m all_data).

If index tablespaces are affected by a database failure, SAPDBA rebuilds the data files and indexes. To do this, SQL scripts that contain the index definitions using the Oracle Dictionary are generated. The missing data files are created, and the indexes built up (similarly to the reorganization of index tablespaces and data files). See also the unit “Storage Management and Monitoring.”

Note: When data files are restored, you can also limit the restore to data tablespaces. Using BRRESTORE, enter -m all_data.

(C) SAP AG BC505 8

(C) SAP AG BC505 9

9.6

SAP AG 1999

$ORACLE_HOME

.

.

.

mirrlogA

sapbackup

sapcheck

saptrace

origlogA

dbs

sapdata<n>

sapreorg

mirrlogB

saparch

origlogB

sapdata1 btabd_1

NEW_DB_HOME

.

.

.

mirrlogA

sapbackup

origlogA

dbs

sapdata<n>

mirrlogB

origlogB

sapdata1 btabd_1

init<SID>.sapnew_db_home = /oracle/NEW

brbackup-d disk_copy

Structure-Retaining Database Copy

The structure-retaining database copy is a backup to disk that retains the original directory structure. This type of backup can be used in combination with the two-step disk backup method in a normal backup cycle.

In case of a disk failure, it may suffice to remount the file system mount points. This procedure is faster than copying the files. Additional uses of the structure-retaining database copy include (a) for building up new R/3 Systems from a database copy, (b) for an Oracle standby database, or (c) for moving the file system (for example, in order to move the data files from the file system to raw devices, or vice versa).

The parameter setting for new_db_home in file init<SID>.sap defines the home directory of a database copy. This directory, in addition to directories dbs, sapdata<n>, origlogA/B, mirrlogA/B, and sapbackup, must first have been created by the database administrator. The subdirectories of these directories are created automatically during the copy process. Additional files in the database environment, such as executables and log files, are not copied during this process.

A backup to remote disks can be performed without NFS mount. Ensure the following parameters are set: backup_dev_type = stage_copy stage_copy_cmd = rcp or ftp stage_db_home = <dir_name>, where: <dir_name> is the new ORACLE home on a remote disk

BRRESTORE always writes database files back to the original directories.

(C) SAP AG BC505 10

9.7

SAP AG 1999

1. Split mirror2. Mount3. Backup4. Unmount5. Resync

brbackup-t online/offline_split

-d tape

Production server Backup server

Mirror

Split Mirror Disk Backups

Split mirror disk backups can significantly reduce backup time. At the start of a backup, the disk mirror is broken up where the data files are located, by a predefined command. The first half (that is, one mirror) is backed up from a separate server, while the “production half” is still running, without impairing performance. Next, the disk mirror is resynchronized.

A backup is performed as follows: Online. 1. Bring the tablespaces into the backup mode. 2. If your mirror system has problems with

splitting a mirror while disk writes are occurring, issue the ALTER SYSTEM SUSPEND statement. 3. Break up the mirror. 4. Issue the ALTER SYSTEM RESUME statement to resume your database. 5. Stop the backup mode in the production half. 6. Perform an online backup of the mirror. 7. Resynchronize the mirror.

Offline. 1. Stop the database. 2. Break up the mirror. 3. Start the database in the production half. 4. Perform an offline backup of the mirror. 5. Resynchronize the mirror.

The following settings in init<SID>.sap apply to the configuration of a split mirror disk backup (For Windows NT refer to SAP Note 122363 ): primary_db defines the server where the production database is running (for local disks). orig_db_home = <dir_name>, where: <dir_name> = original Oracle home directory of the

productive database (for remote disks). split_cmd contains the commands for breaking up the mirror, and for mounting the file system on

the backup server. resync_cmd has the analogous commands for unmounting and resynchronization (optional).

The configuration must enable BRBACKUP to connect from the backup server to the database. During normal operation, disk mirroring protects against database failure. If such protection is also

required during the backup procedure, an additional mirror is required for the production half.

(C) SAP AG BC505 11

9.8

SAP AG 1999

Production server

saparch

Database open

sapr3.SDBAHsapr3.SDBAD

brarchive -sd-d disk -f -w

SAP Tools and the Oracle Standby Database

Standby server

Database mounted standbyor offline for backup

Recovery

brarchive -ssd-f -m 60

brbackup-t offline_standby

saparch

ftpftp

NFSNFS

OR

An Oracle standby database consists of two database servers. The production database has the status open. During normal operation, the standby database has the status mount, and is continually applying the offline redo log files from the production server. In case of a production server failure, the standby database can be opened, and can take on the role of the production database.

The data files are saved to tape on the standby server, using either SAPDBA (choose e - Backup type, e - offline_standby) or BRBACKUP (enter -t offline_standby). These actions are logged on the production server (table entries in the database, and log files in directory sapbackup, which both servers have in common due to NFS mount).

BRARCHIVE runs on both servers: From the production server, a continual backup to disk is performed (using verify, with option -w) through NFS mount in directory saparch on the standby server. On the standby server, the backup to tape is performed.

The offline redo log files are applied on the standby database when the option -m <delay> has been entered. The optional entry delay determines whether the connection is “hot” (that is, replicated with no delay) or “warm” (that is, replicated with a delay). The latter makes it possible to stop applying offline redo log files before a user error is replicated on the standby server.

You can perform backups without NFS mount on a remote hard disk with parameter backup_dev_type = stage_standby. The parameter stage_copy_cmd should be configured properly.

Note: Several structural changes on the production database are not automatically replicated on the standby database. In this case, the recovery is stopped, and the database administrator must take action manually.

(C) SAP AG BC505 12

9.9

SAP AG 1999

BACKINT

External backup server

init<SID>.sapbrbackup

$ORACLE_HOME

.

.

.

saparch

sapdata<n>

sapdata1 btabd_1

SAPDBA

brarchive brrestore

Backup RestoreInquire

brbackup

init<SID>.utl

init<SID>.sapbackup_dev_type = util_file_onlineutil_par_file = init<SID>.utl

External Backup Tools Using BC-BRI

Backups can also be performed using external tools. Communication with SAP tools takes place through an interface defined by SAP (BC-BRI).

The backups must continue being started by SAP tools. This ensures that all actions are logged, and that backups can be monitored using the CCMS. In addition, this allows you to use the SAPDBA restore and recovery features.

For interface configuration, in file init<SID>.sap, set parameter backup_dev_type to util_file or util_file_online. (In the latter case, only the tablespace to be backed up is set to the backup mode.) The setting util_par_file refers to the configuration file init<SID>.utl, which contains parameters for the interface program BACKINT.

With R/3 Release 4.5B and higher, the Legato Storage Manager (LSM) and the implementation of the BACKINT interface is delivered free of charge by Oracle. But this is a limited version of the Legato NetWorker. The native BRBACKUP with cpio or dd, you can also use the BACKINT program from Legato for normal backups. Two methods are available for incremental backups: Using the SAP backup library, or Using the LSM backup library with BACKINT

For more information about the Legato installation, see SAP Note 142635. This note describes the installation of the SAP backup library and LSM backup library.

For an overview of certified providers, see SAPNet (Complementary Software Program).

(C) SAP AG BC505 13

9.10

SAP AG 1999

Unit Summary

Now you are able to:

List the backup strategies that are supported by SAP

Recognize the advantages and limitations of these

strategies

Decide which strategies fit your needs

(C) SAP AG BC505 14

9.11

SAP AG 1999

Further Documentation

Knowledge Product CD

SAP Database Administration Oracle

R/3 Online Documentation

BC SAP Database Administration: Oracle

SAP TechNet

DB Admin. Oracle Knowledge Base

(C) SAP AG BC505 15

9.12

SAP AG 1999

Exercises?

Solutions

Unit Actions

(C) SAP AG BC505 16

9.13Advanced Backup Techniques: Exercises(Optional)

No. Exercise

1 Consistent online backup

1.1 Perform a backup of your local database that meets the following criteria:

Complete

Online_cons

To disk

With offline redo log files backed up by BRBACKUP

1.2 Using the log files, check whether the backup was successful.

2 Partial database backup

2.1 Perform a backup of your local database that meets the following criteria:

Partial: with customer tablespaces PSAPUSER1D and PSAPUSER1I backed up

Online

To disk

2.2 Using the log files, check whether the backup was successful.

3 Optional: Backing up Data Tablespaces Only

3.1 Perform a backup of your local database that meets the following criteria:

Pure index tablespaces are excluded

Online or offline

To disk

3.2 Using the log files, check whether the backup was successful.

(C) SAP AG BC505 17

9.14Advanced Backup Techniques: SolutionsNo. Solution

1

1.1 The parameters in file init<SID>.sap should have been maintained correctly, according to the instructions given in the preceding unit.

Solution using SAPDBA: Choose

h – Backup database e – backup type c – online (consistent).

Check the setting for

c – Backup device type.

To start the backup, choose

S – Start BRBACKUP.

Solution using BRBACKUP: At the operating system level, enter brbackup –d disk –m all –t online_cons.

1.2 The detail log

b<timestamp>.and

is in directory sapbackup. In SAPDBA, choose

l – Show/Cleanup a – Show log files/profiles e – BRBACKUP log files.

2

2.1 Solution using SAPDBA: Choose

h – Backup database,

d – Objects for backup,

g – a tablespace name;

and enter PSAPUSER1D, PSAPUSER1I. Check the settings for

c – Backup device type and

e –backup type.

To start the backup, choose

S – Start BRBACKUP.

Solution using BRBACKUP: At the operating system level, enter

brbackup –d disk –m psapuser1d,psapuser1i –t online.

2.2 The detail log

b<timestamp>.pnd

is in directory sapbackup. In SAPDBA, choose

l – Show/Cleanup a – Show log files/profiles e – BRBACKUP log files.

3

3.1 Solution for SAPDBA: Choose

h – Backup database d – Objects for backup.

Enter all_data. Check the settings for

c – Backup device type and

e – backup type.

To start the backup, choose

(C) SAP AG BC505 18

S – Start BRBACKUP.

Solution for BRBACKUP: At the operating system level, enter

brbackup –d disk –m all_data –t online.

3.2 The detail log

b<timestamp>.and

is in directory sapbackup. In SAPDBA, choose

l – Show/Cleanup a – Show log files/profiles e – BRBACKUP log files.

(C) SAP AG BC505 19

10

SAP AG 1999

Storage Management

1 Database Overview 6 Advanced Backup Techniques

2 Backup Strategy and Tape Management

7 Storage Management

3 Scheduling, Performing,and Monitoring Backups

8 Performance Monitoring

4 Restore and Recovery 9 Top 10 Problems

5 Backup Strategies Using RMAN

(C) SAP AG BC505 1

10.2

SAP AG 1999

Storage Management

Contents Storage management basics

Monitoring freespace and space critical objects

Internal and external fragmentation

Reorganization

ObjectivesAt the end of this unit, you will be able to:

Adapt storage parameters of tables and indexes

Run and analyze the results of sapdba -check and sapdba -next

Determine if a reorganization should be performed

Perform a reorganization

(C) SAP AG BC505 2

10.3

SAP AG 1999

Disks

File system

Datafile1 Datafile2

. . .

Space Management: Review

8K8K8K8K

8K8K8K8K

8K8K8K8K

8K8K8K8K

8K8K8K8K

8K8K8K8K

Extent144K

Extent48K

Extent144K

Segment192K

1

InitialExtent

Segment(table/index)

Datablock

Table ABC

Table XYZ

Table DEF

Extent192K

Extent640K . . .

. . .

. . .

Extent192K

Extent224K

Extent80K

Extent256K

Datafile2Datafile2Datafile1Datafile1

Tablespace

NextExtent

2

NextExtent

Each table and index is assigned to a tablespace, which consists of one or more data files at the operating system level. All table and index data is stored in the data files of the tablespace.

Oracle stores tables and indexes in individual data blocks. In an R/3 installation, data blocks are 8 KB in size. When new storage space is required for a table or index, one or more contiguous data blocks of a data file are allocated to form an extent. If there is not enough contiguous freespace to allocate a new extent, the Oracle error message ORA-1653 (for a table) or ORA-1654 (for an index) occurs.

Oracle data objects have several storage parameters that influence growth: The first extent (initial extent) should be large enough for the expected table or index size. If an

extent of a data object becomes full during an insert or update operation, the Oracle storage management system attempts to allocate another extent in the tablespace.

An object can allocate extents up to the limit MAXEXTENTS. If the maximum number of extents for each object is reached, the error message ORA-1631 (for a table) or ORA-1632 (for an index) is displayed. If this occurs, you must increase the parameter MAXEXTENTS and check the size of the table’s NEXT parameter.

PCTFRE, PCTUSED, and PCTINCREASE are three additional storage parameters. Only change them under special circumstances and after consulting SAP for support.

(C) SAP AG BC505 3

10.4

SAP AG 1999

. . .00 11 22 33 44 55

Objects (tables/indexes) Tablespace

<tablespace>.data1

2

3

10

2 3

0

0

1

0

4

1

2

4

5

Gaps

Oracle block Internalfragmentation

Used

Free

35

1 4

Externalfragmentation

2

Space Management: Fragmentation Types

Criticalobject

Extents

Depending on the size of each data record, several data records can be stored in an 8 KB data block. For fields of indexes and for long raw fields, Oracle compresses the contents of each data record. As a result, the data records of an index or a table with one or more long raw fields will usually differ in length.

When a data record is deleted, a gap of unused storage space results within the corresponding data block. The existence of such gaps within data blocks is called internal fragmentation. Oracle can reorganize internally fragmented data blocks so that wasted storage space is re-used.

The extents, which belong to the different data objects of a tablespace, allocate storage space within data files of this tablespace. When a database object is dropped, the extents are released. Gaps of unused storage space result. The existence of one or more of these gaps is called external fragmentation of a tablespace. Newly allocated extents can only be inserted into such a gap if they are smaller than or equal to the size of the gap.

If the NEXT extent size of an object is larger than the largest free contiguous storage area of its tablespace, it is called a space critical object. The allocation of a new extent for this object will fail if you have not extended the tablespace.

(C) SAP AG BC505 4

10.5

SAP AG 1999

<Timestamp.chk> in/oracle/<SID>/sapcheck

DBA Planning CalendarR/3 xPlanning Goto Listing Help System

MONMONCheckDBCheckDB

TUETUECheckDBCheckDB

WEDWEDCheckDBCheckDB

THUTHUCheckDBCheckDB

FRIFRI SATSATCheckDBCheckDB

SUNSUNsapdbasapdba

--nextnext

MONMONCheckDBCheckDB

TUETUECheckDBCheckDB

WEDWEDCheckDBCheckDB

THUTHUCheckDBCheckDB

FRIFRI SATSATCheckDBCheckDB

SUNSUNsapdbasapdba

--nextnext

MONMONCheckDBCheckDB

TUETUECheckDBCheckDB

WEDWEDCheckDBCheckDB

THUTHUCheckDBCheckDB

FRIFRI SATSATCheckDBCheckDB

SUNSUN

MONMONCheckDBCheckDB

TUETUECheckDBCheckDB

WEDWEDCheckDBCheckDB

THUTHUCheckDBCheckDB

FRIFRI SATSATCheckDBCheckDB

SUNSUNsapdbasapdba

--nextnext

Daily Monitoring: sapdba -check

Database tableDBMSGORA

1 Calendar

Schedule an Action for Tue 05

18:00:00Start timePeriod (weeks):

Full database offline + redo log backup

Full database offline backup

Full database online + redo log backup

Full database online backup

Redo log backup

Partial database offline backup

Partial database online backup

Check optimizer statistics

Update optimizer statistics

Adapt next extents

Check database

Start immediately

Start check

Warnings

Errors

Total

Configure check Database operations monitor History StandardDatabase table

DBMSGORA

Refresh every

Delete after

View the last

Check results Settings

10 seconds inaktiv

100 days aktiv

10 days

History: All messages

6

5

11

Result Date Time Days Error type Error name Text

WEEE

08/21/1999 22:00:00 10 PROF LOG_SMALL_EN... LOG_SMALL_ENTRY_MAX_SIZE08/21/199908/21/199908/21/1999

22:00:0022:00:0022:00:00 10

1010 DBO

DBODBA

OPTALYNO_OPT_STATS

DB Operation opt never started or finished successfulDB Operation aly never started or finished successful6 INDEXE(S) DDXTF0,DDXTT0, TATAF 0, ... WITHOU

Database Check: Overview of Results

sapdba -check

DB16

Use the R/3 tool SAPDBA with the option -check to check the following: Extents of tables and indexes Tablespace filling Physical consistency of the database. That is, the consistency of the control files, redo log files,

and data files Severe error messages in the alert log init<SID>.ora parameter settings Database problems specific to the R/3 environment

Schedule SAPDBA -check to run daily during periods of low system activity, by using either the DBA Planning Calendar (transaction DB13) or by entering command sapdba -check at the command prompt.

Command sapdba -check generates a log file called <DateTime>.chk. which is written to directory ../../sapcheck. The log information is also written to the database table DBMSGORA, and can be viewed using the R/3 Database System Check Monitor (transaction DB16). This log information should be monitored after each SAPDBA -check run.

If a database or system error occurs, use command sapdba -check to check the log information. To monitor your sapdba -check run, you can also use transaction DB24.

(C) SAP AG BC505 5

10.6

SAP AG 1999

Configuration tableDBCHECKORA

Configuring sapdba -check

Type

Parameter

Object

Actv.

Condition

Description

Change Database Check Parameter

Database analysis tool (SAPDBA)

ARCHIVE_STUCK

Yes

Error

ARCHIVE STUCK - FS SPACE #1 MORE THAN #2 FULL

greater than (old 80 Percentage

Repeat period

Corrective measure

Changed by

Duration

Type

User

Time Unit

Operation

Date

Program SAPDBA: BACKUP ARCHIVE LOGS

if

DB17Number of SAPDBA check parameters

ARCHIVE_STUCKDBA E PP80> SAPDBA: BACKUP ARCH... ARCHIVE STUCK - FS SPAC...

TotalStatusProfile param.Oracle alerts

Operations

671928137

661

ActiveInaktiv

DBA

DBA

DBA

DBA

DBA

DBA

DBA

DBA

CONTROL_FILE_MISSING

CONTROL_MIRROR

CRITICAL_SEGS

DF_OFFLINE

FILE_MISMATCH

FILE_MISSING

FILE_TYPE_UNKNOWN

FS_FULL

E

E

E

E

E

E

W

W >

>

P

P

1

95

INIT<SID>.ORA

SAPDBA: TABLESPACE A...

DO A “CREATE CONTROL...

SAPDBA: RESTORE/RECO...

EXTEND FILESYSTEM OR...01 / 22 / 1999

P

E

CA...

CONTROL FILES ARE MISSI...

CONTROL FILE(S) ARE NOT...

SEGMENT(S) #1 WOULD CAU...DATAFILE(S) #1 OFFLINE

FILE TYPE DOES NOT MATC...

DATA FILES ARE MISSING

FILE TYPE ( DATAFILE , RA...

# 1 FILE SYSTEM(S) # 2 ARE...

Typ Parameter O... Actv. S.. Op... Val. U... Per... Unit Date U... C DescriptionCorrMeasure

To configure the checks performed by SAPDBA -check, choose Tools CCMS DB administration Check Configuration (transaction DB17).

The system checks are identified by an error type and name (Err Type, Parameter ID): DBA: The checks that report these errors are programmed into SAPDBA. You can change the

thresholds specified for these checks. You can activate and deactivate these checks. ORA: Oracle alert-log messages (important administrative and error messages) that the R/3

System check will report to you. You can add additional “ORA”-entries. PROF: Problems in the Oracle init<SID>.ora initialization profile. You can add additional

parameters. The columns in the configuration table DBCHECKORA mean the following:

Active: Activate (Y) or deactivate (N) the check for the problem Severity: Warning (W) or error (E). Errors require immediate attention. Check Oper, Check Val, Check Unit: The threshold value for triggering a warning are defined in

these columns. For example, Check Oper >, Check Value 80, and Check Unit P indicates that a warning or message should be triggered when the database value exceeds 80 percent.

CorrMeasure: This provides a quick, editable tip for solving the problem. If these fields are empty, first analyze the problem in detail, and then choose a measure to correct it.

(C) SAP AG BC505 6

10.7

SAP AG 1999

ADD A DATA FILE:File size depends on the estimated increase of the tablespace objects. Check for the number of data files in the database.

<tablespace>.data1

Critical object

Extents

New file<tablespace>.data2

Back up extended tablespace and control files

Tablespace Extension

RESIZE THE DATA FILE:Extend the size of the data file depending on the space available on the file system and size of critical object.

<tablespace>.data1

Critical object

Original size After Resize

OR

If the database tries to allocate another extent but finds that there is no more freespace in the corresponding tablespace, the SQL operation fails. The available storage space of a tablespace can be extended in online operation by adding another data file.

To add a data file, use the SAPDBA. Select c -Tablespace administration. Specify the name of the tablespace to be extended in the submenu a - Tablespace In the submenu f - Alter tablespace <tablespace name> add data file default recommendations for

file name and data file size are already given. Adapt them according to your requirements. Select s - Start to start the Add data file action. SAPDBA performs a check on the available

storage space in the specified file system before the data file is added. SAPDBA continues with the backup menu and asks you to back up the extended tablespace.

Backing up the extended tablespace ensures that the new state of the database can be recovered. SAPDBA stores the old version and the new version of the control file in directory sapreorg/<timestamp>. The action log <timestamp>.ext is written to directory sapreorg.

To resize a data file, use SAPDBA. Select d - Reorganization. Then select option h - Resize data file of a tablespace. Specify the name of the tablespace to be extended in the submenu a - Tablespace Select s - Start to start the resizing process. SAPDBA gives a list of data files, from which you can

select which data file you want to resize. In the submenu b - New size default recommendations for the data file size are already given. Adapt them according to your requirements and select s - Start and execute changes. SAPDBA performs a check on the available storage space in the specified file system before the data file is resized. It also writes a log file with <timestamp>.rrs name in the sapreorg directory.

(C) SAP AG BC505 7

10.8

SAP AG 1999

Table TGORA (storage parameters for R/3 tables)

Category INIT NEXT MINEXTENT MAXEXTENT0 16 40 1 3001 16 160 1 3002 16 640 1 3003 16 2560 1 3004 16 10240 1 3005 16 20480 1 3006 16 40960 1 3007 16 81920 1 3008 16 163840 1 3009 16 327680 1 300

10 16 655360 1 15011 16 1310720 1 15012 16 2621440 1 15013 16 5242880 1 15014 16 10485760 1 150

Table IGORA (storage parameters for R/3 indexes)

Category INIT NEXT MINEXTENT MAXEXTENT0 16 40 1 3001 16 80 1 3002 16 160 1 3003 16 640 1 3004 16 2560 1 3005 16 5120 1 3006 16 10240 1 3007 16 20480 1 3008 16 40960 1 3009 16 81920 1 300

10 16 163840 1 15011 16 327680 1 15012 16 655360 1 15013 16 1310720 1 15014 16 2621440 1 150

R/3 xABAP Dictionary: Display technical settings

Logical storage parameters

Name ZPROGRAM Transparent TableShort text Test Table for technical settings Last changed TND 24/08/1999 Status Active Saved

Data class APPL1 Transaction data. transparent tablesSize category 4 Data records expected: 39.000 to 3.100.000

Storage Categories of SAP Database Objects

Default values are used for INITIAL, NEXT, and MAXEXTENT when creating an SAP table or index during installation of an R/3 System. These defaults are derived from the objects category.

The category assignment for each R/3 table and index is a technical setting. You can access the technical settings of R/3 tables and indexes using the viewing (SE12) and editing (SE11) transactions for ABAP Dictionary objects.

The INITIAL, NEXT, and MAXEXTENT values used for a specific category are defined in table TGORA for R/3 tables and in IGORA for R/3 indexes. NEXT sizes range from 40 KB, for tables in category 0, to 20971520 for tables in category 14 The NEXT size for a category is either twice or four times the size of the NEXT size for the

previous category. This helps to prevent external fragmentation. The MAXEXTENT for R/3 tables and indexes is usually set to 300. If the number of extents for a

database object approaches 300, you must increase this parameter. As of Oracle release 7.3, you can set this parameter to UNLIMITED.

Uncontrolled growth of the number of extents present in the database can increase the number of displacements in the Oracle shared pool. Because it is essential to limit the growth of the extents, we do not recommend setting the MAXEXTENT to UNLIMITED for all objects. The growth of an object, such as a table, index, or rollback segment is determined by the size specified in parameter NEXT.

(C) SAP AG BC505 8

10.9

SAP AG 1999

DBA Planning CalendarR/3 xPlanning Goto Listing Help System

MONMON TUETUE WEDWED THUTHU FRIFRI SATSAT SUNSUN

sapdbasapdba--nextnext

MONMON TUETUE WEDWED THUTHU FRIFRI SATSAT SUNSUN

sapdbasapdba--nextnext

MONMON TUETUE WEDWED THUTHU FRIFRI SATSAT SUNSUN

sapdbasapdba--nextnext

MONMON TUETUE WEDWED THUTHU FRIFRI SATSAT SUNSUN

sapdbasapdba--nextnext

Example sapdba -next:

Table size: 900 MB10 % value: 90000KBCurrent NEXT: 20480KBNEXT candidate: 90000KB

Next larger TGORA value: 163840

NEXT candidate: 90000Next smaller TGORA value: 81920

Current NEXT: 20480

Technical settings:

Category 3: 2560

10485760

5242880

2621440

1310720

655360

327680

163840

81920

40960

20480

10240

2560

640

160

40

TGORAvalues (KB)

New value for NEXT: 163840

Using sapdba -next

Database tableDBMSGORA

1 Calendar

Schedule an Action for Tue 05

18:00:00Start timePeriod (weeks):

Full database offline + redo log backup

Full database offline backup

Full database online + redo log backup

Full database online backup

Redo log backup

Partial database offline backup

Partial database online backup

Check optimizer statistics

Update optimizer statistics

Adapt next extents

Check database

Start immediately

The SAPDBA option -next allows you prevent uncontrolled extent growth for all database tables and indexes. The size of parameter NEXT for all R/3 database objects is calculated according to the following algorithm: The storage space allocated for the database objects (in KB) is determined and divided by 10. This

value is compared to the current setting for NEXT. The larger of the two values, which is called the “NEXT candidate”, is used to perform the following comparisons:

The NEXT value derived from the technical settings of the object is used if it is larger than the NEXT candidate

If it is not, the next smaller value found in TGORA or IGORA is used if it differs by not more than 5 blocks from the NEXT candidate

If it does not, the next larger value found in TGORA or IGORA is used If no larger value is found in TGORA or IGORA, parameter NEXT is set to the value of the

NEXT candidate Schedule SAPDBA -next using the R/3 DBA Planning Calendar. Schedule SAPDBA -next to run at

least once a week, and after major database changes. The action log is written to file <timestamp>.nxt in the directory ../../sapcheck.

It may be the case that not enough contiguous storage space is available to allocate a new extent for tables that have an increased setting of parameter NEXT. After each SAPDBA -next run, you must check for space critical objects in the database.

(C) SAP AG BC505 9

10.10

SAP AG 1999

Daily Monitoring: Tables and Indexes

Database ORACLE Date/time of this analysis 08/24/1999 07:01:30Name TCC

Database System

RefreshRefresh ChecksChecks Space statisticsSpace statistics

Total number 27Total size/kb 12.123.016Total free/kb 3.050.320 25%Minimum free/kb 4.024Max. autoextensible/kb AutoExtend off

Tablespaces

Current sizesCurrent sizes

Freespace statisticsFreespace statistics

Space statisticsSpace statistics

Tables IndexesTotal number 13.064 15.305Total size/kb 5.915.664 2.979.432More than 1 extent 1.082 1.591Missing in database 0 1Missing in R/3 DDIC 0 0Space-critical objects 0 0

Tables and indexesDetailed analysisDetailed analysis

Space critical objectsSpace critical objects

Missing indexesMissing indexes

Space statisticsSpace statistics

Day Time M T W T F S S 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3

-------------------------------------------------------------------------------RSDBPREV 1 CX:X:X:X:X:X:X X:X:X:X:X:X:X:X:X:X:X:X:X:X:X:X:X:X:X:X:X:X:X:X

RSORATDB 1 CX:X:X:X:X:X:X : : : : : : :X: : : : : : : : : : :X: : : : :

Maintain table: TCOLL

To perform a detailed analysis of storage related issues, use the Tables and Indexes Monitor (transaction DB02).

The Tables and Indexes Monitor has three levels of resolution: Database level, Tablespace level, and the Tables and Indexes level. In any one of the generated views, double-click the line of an object to display the elements of the object. From the lowest level, that is from the Tables and Indexes level, you can access a history view for this object. Navigating to higher levels of resolution works for most of the available views.

The ABAP report RSORATDB collects the data required for the Tables and Indexes Monitor and stores it in the database table MONI. The contents of this table are evaluated when the Tables and Indexes Monitor is displayed. To refresh the values, choose Refresh.

To set the frequency of the execution of report RSORATDB (and other reports relevant for monitoring) maintain table TCOLL using transaction SM31. Also schedule job COLLECTOR_FOR_PERFORMANCEMONITOR to run hourly within your production system. For further information, see SAP Notes 12103 and 16083.

The Oracle autoextend option is supported in R/3 Release 4.5B and higher.

(C) SAP AG BC505 10

10.11

SAP AG 1999

Tables and Indexes: Important Reports

09/05/1999 10:40:26 DB_SERVERCritical table/index growth

Intervals: 08/06/1999 - 09/05/1999 Measurements: 29

Table Name Type Size(KB) NextExtSize Extents MaxExtents FirstExtent TablespaceTotal Growth (Kbyte) Total Growth defined %used (Kbyte)

ATAB~0 INDEX 72.720 10.880 160 168 68 300 56 45.936 PSAPPOOLISMENINTT~ INDEX 2.416 2.400 80 31 30 300 10 16 PSAPSTABISKAT~001 INDEX 9.960 2.080 80 89 26 300 30 2.904 PSAPSTABI

Critical growth of tables/indexes in the last 4 weeks

Table Space History

09/05/1999 10:40:26 DB_SERVERIntervals: 08/06/1999 - 09/05/1999 Measurements: 30 Scale: DayScale: Day Size (KB) Free(KB) Used (KB) %-Used Tables/Indexes ExtentsTablespace Total Chg/day Total Total Chg/day Total Chg Total Chg/day Total Chg/dayPSAPPOOLD 747.512 0 38.944 708.568 2.415 94 0 6.619 0 8.692 22PSAPPOOLI 563.200 0 97.888 465.312 1.793 82 0 6.751 0 9.296 21PSAPSTABI 921.600 0 70.288 851.312 1.909 92 0 4.404 0 6.156 10PSAPSTABD 1.013.744 0 31.024 982.720 3.384 96 0 3.325 0 4.307 8PSAPROLL 307.200 0 182.392 124.808 3.084 40 1 15 0 120 3PSAPBTABD 735.216 0 231.336 503.880 1.249 68 0 2.344 0 2.471 1PSAPBTABI 409.600 0 125.768 283.832 157 69 0 3.222 0 3.542 1PSAPSOURCED 102.400 0 69.296 33.104 6 32 0 47 0 49 0PSAPSOURCEI 102.400 0 47.520 54.880 3 53 0 54 0 60 0PSAPTEMP 307.200 0 307.192 8 36 0 0 0 0 0 0PSAPUSER1D 8.192 0 4.024 4.168 36 50 0 4 0 4 0PSAPPROTI 33.792 0 16.592 17.200 52 50 0 114 0 131 0

To display a list of objects with the strongest growth of extents or with more than 80% of MAXEXTENTS allocated, call transaction DB02, and choose Checks Check next extent size. To display a history view for a single table or index, double-click a line describing an object and choose History per weeks.

To monitor the size, free space, and usage of storage space for all tablespaces, choose Space statistics from the tablespace section. To display the history of a specific tablespace, double-click the tablespace line. Daily, weekly, and monthly histories are available.

To display a detailed analysis of the current storage usage of a table or an index, choose Detailed Analysis from the tables and indexes section, and enter a name of a table or index. You can also specify the name of a tablespace to display a list of its elements.

To analyze critical storage-related problems, choose Space critical objects. To display a list of indexes that are defined in the R/3 Data Dictionary but do not exist on the

database, choose Missing indexes in the Tables and indexes section.

(C) SAP AG BC505 11

10.12

SAP AG 1999

Detail log: 9908221023.aly ***********************************************************************

(12690 tables analyzed - sorted by empty space in descending order)TABLESPACE_NAME TABLE_NAME EMPTY(kb) NEVER_BEEN_USED(kb) USED(kb)

PSAPSTABD E071K 42032 42032 5128PSAPEL40AD D010L 31112 31112 3168PSAPPOOLD ATAB 17112 17112 58368PSAPES40AD DOKCLU 13136 13136 323448PSAPES40AD D010S 10088 10088 774848***********************************************************************CHARTS OF 20 EMPTY INDEXES - USING: VALIDATE STRUCTURE(6751 indexes analyzed. sorted by empty space within BTREE =USED_BY_BTREE - USED)TABLESPACE_NAME INDEX_NAME TOTAL(kb) USED_BY_BTREE(kb) USED(kb)

PSAPPOOLI ATAB~0 72720 72648 50563PSAPPOOLI T512T~0 7280 7200 4641PSAPPOOLI RTXTL~0 11920 10072 7745PSAPPOOLI T800Y~0 8800 8744 6726

SAPDBA Detail Log

sapdba -analyze

DB02 >> Detail Analysis

Data from DBA_SEGMENTS/DBA_INDEXESSpaceAllocated space..Kbyte 72.720

blocks...... 9.090 extents..... 168

Block structureBlocksize.........byte 8.192Pct_free.............. 10Transactions initial.. 2

maximum.. 255Header minimum....byte 159Data maximum......byte 7.230

Process freelists..... 1Freelist groups....... 1

Detailed analysis for Index ATAB~0

Analyzing Internal Fragmentation

The SAPDBA option -analyze provides information about the storage allocation for a table or an index. You can use it to determine the degree of internal fragmentation of the database object, and to analyze a single table using SAPDBA.

To display the logs of the SAPDBA actions performed to refresh the optimizer statistics, use the DBA Operation Monitor (transaction DB24). To display only the action logs of SAPDBA -analyze, choose Function IDs (function ID aly).

USED space is storage space consumed by the table or index contents. EMPTY is the difference between storage space allocated for a table and USED space.

NEVER_BEEN_USED space is storage space that has been allocated for a table but has not yet been used by the table. USED_BY_BTREE is the storage space allocated by the B*tree.

In the sapdba -analyze detail log, check for: Tables that have a large difference between EMPTY and NEVER_BEEN_USED. This difference

indicates internal fragmentation of a table. Indexes that have a large difference between USED_BY_BTREE and USED. This difference

indicates internal fragmentation of an index. The Tables and Indexes Monitor (transaction DB02) provides detailed information about tables and

indices. Call transaction DB02, choose Detailed Analysis and, in the dialog box displayed, specify the name of the object you want to analyze. Select the object and choose Detail Analysis. Block level details for that object are then displayed.

(C) SAP AG BC505 12

10.13

SAP AG 1999

Example for a table reorganization

1) Export table

2) Drop table

3) Import table

Recreate index

sapreorg

Data_1

001

2 21

Example for an index recreation

1) Drop index

2) Recreate indexPSAPTEMP

Additional storage space required

Additional storage space required

Data_1

001

2 21

Data_1

0

0

21

Data_1

01

02

Reorganization: Basics

To eliminate storage-related problems, perform a reorganization. The objects that can be reorganized include tables, indexes, and data files of the database. After a table or index is reorganized, block usage for the reorganized object is optimal. Extents can

be merged together to reduce the number of extents present in the database. Storage space required for the object can also be minimized.

When data files of a tablespace are reorganized, some data files are merged together. This means the number of data files present in the database can be minimized.

To perform a reorganization, additional storage space is required to store intermediate data. This storage space is either required in the database or in directories created for this purpose. Intermediate data can also be stored on tape. SAPDBA tries to forecast the amount of additional storage space required. When a reorganization is performed, bottlenecks can occur in the following areas: The data files of the tablespace where the reorganized object resides. Typical error: No data file

has enough freespace to hold the new larger extents or a temporary second copy of the object. The directory sapreorg. Typical error: This directory is too small to hold the export sets The tablespace PSAPTEMP. Typical error: This tablespace is too small for an index recreation

If an error occurs during a reorganization, data can be lost. If a valid and up-to-date data backup exists, the risk of data loss is minimized. After the data files of a tablespace have been reorganized successfully, you must immediately perform a backup.

(C) SAP AG BC505 13

10.14

SAP AG 1999

Disk_4

102 3

0

10

4

2

5

3

102 3

0

10

4

2

5

3

Disk_3

102 3

0

10

4

2

5

3

102 3

0

10

4

2

5

3Disk_2

102 3

0

10

4

2

5

3

102 3

0

10

4

2

5

3Disk_1

102 3

0

10

4

2

5

3

102 3

0

10

4

2

5

3

Disk "hot spots"

Dis

k ac

cess

es [

%]

Disk

Reorganization: Reasons

Detail log: 9909050715.alyCHARTS OF 20 EMPTY INDEXES - USING: VALIDATE STRUCTURE(6751 indexes analyzed. sorted by empty space within BTREE= USED_BY_BTREE - USED)TABLESPACE_NAME INDEX_NAME TOTAL(kb) USED_BY_BTREE(kb) USED(kb)

PSAPPOOLI ATAB~0 72720 72648 20563PSAPPOOLI T512T~0 7280 7200 4641PSAPPOOLI RTXTL~0 11920 10072 7745 PSAPPOOLI T800Y~0 8800 8744 6726PSAPPOOLI T52C5~0 5480 5424 3760PSAPPOOLI USOBX_C~0 4160 4032 2627

SAPDBA Detail Log

FragmentedIndexes

. . .00 11 22 33 44 55

Oracleblock

Internalfragmentation

Free

Used

Reorganizing physical data objects is costly, both in terms of time and resources, and should be performed only in exceptional cases. To minimize the need for reorganizations, monitor the database regularly.

The R/3 System is not available during a reorganization. Therefore, reorganize physical data objects for the following reasons only: Disk hot spots: Unfavorable physical distribution of tables, indexes, or data files results in non-

uniform distribution of disk accesses on available disks Heavily fragmented indexes: Fragmented indexes can affect performance. Fragmented tables will

only affect performance in special cases (check for SAP Notes indicating this problem). To avoid having to perform reorganizations:

Run sapdba -next weekly to adapt the storage parameters of all tables and indexes. This prevents database objects from allocating a high number of extents. If a table has a high number of extents, change the parameters NEXT and MAXEXTENTS. Do not perform a reorganization.

Try to estimate growth of a critical tablespace before extending it with a data file of an appropriate size. Use SAP archiving to archive obsolete data. This prevents the number of files in your database system from approaching the limit DB_FILES. If there is a high number of data files, try to increase the parameters MAXDATAFILES (number of files your OS can handle) and DB_FILES. Do not reorganize a tablespace.

(C) SAP AG BC505 14

10.15

SAP AG 1999

Moving / Renaming data files

Disk x

10

2 3

0

1

0

4

2

5

3

1 40

Disk y

10

2 3

0

1

0

4

2

5

3

1 40

Reorganization of a tablespace

Data file_1

10

2 3

0

1

0

4

2

5

3

Data file_2

76

8 9

1

5

4

10

6

11

7

Data file_2

0

Data file_1

0

0

0

Reorganization of a tablespace with data files

Data file_1

Data file_2

102 3

0

10

4 52

76

8 9

1

5

4

10 11

Data file_new

0

0

0 00

Reorganization of a single object or a list of objects

Phases Directories Create script and restart file sapreorg/<timestamp>/<timestamp>.<extension>.

Check the free space sapreorg, PSAPTEMP. Perform a reorganization PSAPROLL, objects tablespace

Phases Directories Create script and restart file sapreorg/<timestamp>/<timestamp>.<extension>.

Check the free space sapreorg, PSAPTEMP. Perform a reorganization PSAPROLL, objects tablespace

Data file_1

001

2 21

Data file_1

0

0

21

Disk "hot spots" Fragmented indexes

Internal fragmentation

Internal and external fragmentation Fragmented indexes

Disk "hot spots"

Reorganization: Phases and Types

SAPDBA reorganizations are performed in two phases: In phase one, the SQL script for the reorganization process is created in the subdirectory

<timestamp> of the working directory. The file restart.<extension> is created in this subdirectory to enable a restart of the reorganization (first eliminate the cause of the error). Reversible actions can be reset. SAPDBA checks if there is enough storage space available to perform the reorganization.

In phase two, the reorganization script is executed. (Action log name: <timestamp>.<extension>) Reorganization of a single object (table or index): Use this function to eliminate internal

fragmentation, to reduce the number of extents allocated for a table or index, and to move a table or index to another tablespace in order to eliminate a disk hot spot (extension rsi)

Reorganization of a list of objects: Use this function to reorganize a group of several objects. An ASCII file must be created in the working directory with the required list of objects. (extension rli)

Reorganization of a tablespace: Use this function to reorganize all objects belonging to this tablespace. The directory and file structure of the tablespace will remain unchanged. (extension rtc)

Reorganization of a tablespace with data files: Use this function to change the data file structure and to reorganize the objects contained in the tablespace. The number of data files existing in the database can be minimized. (extension rtd)

Moving and renaming data files: Use this function to move files to another disk. This is not classified as a reorganization because the action is performed on file level (extension rmv).

(C) SAP AG BC505 15

10.16

SAP AG 1999

Legend:++ = very good, + = good, o = average, NA = Not applicable

I = Parallel on index, T = Parallel on table. (Oracle PARALLEL clause)

P = Parallel on process level (SAPDBA creates several processes)

Reorganization of tables

Method Runtime Security Additional space R3Chop Parallel Compress Restrictions

Create table ++ ++ Objects tablespace NA T NA No tables withas select PSAPROLL LONG/RAW fields

SAPDBA unload. + + sapreorg NO P NO export < max_file_sizeSQL*loader PSAPTEMP (usually 2 Gbyte)

Oracle o + sapreorg YES P YES export/import PSAPTEMP

Reorganization of indexes

Method Runtime Security Additional space Parallel

Alter index ++ ++ Objects tablespace Irebuild PSAPTEMP

Index + + PSAPTEMP Irecreate

Reorganization: Methods

There are two methods to export and import table data. In both cases, because tables are dropped before they are recreated, data may be lost : export / import uses Oracle EXPORT and IMPORT commands. Additional storage space for the

export dump is required in directory sapreorg and in PSAPTEMP (index recreation). SAPDBA unload / load uses either the tool SAPDBA LOAD or the Oracle SQL*loader. Additional

storage space for the LOAD file is required in directory sapreorg and in PSAPTEMP (index recreation).

The following methods do not require the export and import of database data: Create table ... as select: SAPDBA first generates the table to be reorganized with the new

parameters under a new name (by adding the character #). The data is copied directly from the old table to the new. The old table is dropped and the new table is renamed. This option cannot be used for tables with LONG columns or for reorganizing tablespaces with data files. Additional storage space is required as the table temporarily exists twice in the same tablespace. Enough space must be available in PSAPROLL to hold rollback information.

Alter index / Rebuild: The index is first rebuilt in tablespace PSAPTEMP using the existing index. Then it is copied into the corresponding tablespace. The old index is dropped and the optimized index is activated. Table and index are locked during this process. Additionally required storage space can be up to twice the size of the index.

Recreate index: The index is dropped and recreated. Storage space is required in PSAPTEMP.

(C) SAP AG BC505 16

10.17

SAP AG 1999

Compress extents:Yes No

0

0 1

1 2

0

0

2 3

1 4

0 1 2 3 4

Reduce object size:Yes No

0

0 1

1 2

0

0

2 3

1 4

0

Freespace

Chop (export dump):Yes No

sapreorg2 GB2 GB

sapreorg

4 GB

Compress (export dump):Yes No

sapreorg

1 GB

2 GB

sapreorg

2 GB

2 GB

Parallel export / import (Example: 2 processes in parallel)exp_imp_degree = 2

sapreorg1

dump1

sapreorg2

dump2

Database

Process 1 Process 2

Both conditions required:exp_imp_degree = 2

and2 dump destinations

Possible?Possible?

Reorganization: Options

To define a reorganization, you can specify the following options: Compress extents = Yes. SAPDBA merges the extents occupied by the table or index to one

extent. If this option is not used, the extents are allocated using the current storage parameters of the object. Adjacent free storage fragments in the entire tablespace are merged.

Reduce object size = Yes. SAPDBA automatically tries to reduce the size of the objects (allocated storage space) during the reorganization for an export or import. To determine the actual storage space occupied, SAPDBA uses the Oracle ANALYZE command. Script generation requires a specific amount of time and locks the tables to be reorganized.

Chop = Yes. SAPDBA sends the exported data to the chop tool through a named pipe. The chop tool then splits the export data into several files. This option is only available if parameter chop_util_name is entered in the profile init<SID>.dba. This option is not available for Windows NT. If the export dump files are larger than the maximum file size (usually 2 GB) for the operating system, use this option.

Compress = Yes. The export dump is compressed using OS facilities (not for dump to tape). Parallel export/import: The export and the import are distributed to several parallel processes. The

init<SID>.sap parameter exp_imp_degree determines the maximum number of processes that are created for the reorganization. The number of directories and/or tape devices specified for the export dump files also limits the number of processes created.

Oracle PARALLEL clause: The reorganization is accelerated with the help of the Oracle PARALLEL QUERY functionality.

(C) SAP AG BC505 17

10.18

SAP AG 1999

Unit Summary

Now you are able to:

Explain the concepts of Oracle storage management

Name the problems of data storage

Monitor and avoid problem situations

Solve storage related problems efficiently

In an Oracle database, the way physical hard disk space is allocated for a table or index is controlled by the objects storage parameters. Storage parameters that are set incorrectly can lead to unwanted growth behavior.

The following R/3 System tools provide you with an effective means of preventative monitoring, and should be used to avoid uncontrolled database growth: The SAPDBA checks the database for possible storage related problems You can extend the database using the SAPDBA The SAPDBA adapts storage parameters of growing objects to optimize growth behavior The SAPDBA provides comprehensive support for the reorganization of Oracle database objects You can monitor the current status of the database using the CCMS Database Monitors (DB02,

ST04, DB24). You can limit growth of the database by archiving obsolete data. R/3 provides you with the required

archiving functionality.

(C) SAP AG BC505 18

10.19

SAP AG 1999

Exercises?

Solutions

Unit Actions

(C) SAP AG BC505 19

10.20Storage Management: ExercisesNo. Exercise

1 Use sqlplus to run the script createtab.sql, which is located in directory scripts:

Log on as user ora<SID>. If the database is not open, open it using SAPDBA. Switch to directory scripts. Start sqlplus. Log on to the database as user SAPR3 with password SAP. Start the script createtab.sql by entering the sqlplus command line @createtab.sql

2 Run sapdba –check on your database.

2.1 Check the log file of sapdba –check for messages regarding table BC505CHECK and index BC505CHECK~0.

3 Adapt the storage parameters of table BC505CHECK using SAPDBA. Ensure that the new MAXEXTENTS value is larger than number of extents currently allocated + 30%. Do not use the SAPDBA recommendation for NEXT, but set it back to the current value.

3.1 Run sapdba –check again. Explain the difference in the log files of the sapdba –check runs before and after you adapted MAXEXTENTS of table BC505CHECK.

4 Use SAPDBA to automatically adapt the NEXT extent sizes for all SAP tablespaces.

4.1 Check for problems in the sapdba –next log.

4.2 Run sapdba –check again and check for problems related to table BC505CHECK in the log file. Why should you always run sapdba –check after a sapdba –next?

5 Solve the problems found for tablespace PSAPUSER1D by adding a new data file (1 MB in size).

5.1 Solve the problems found for tablespace PSAPUSER1I by adding a new data file (200 KB in size).

5.2 Restart sapdba –check and check for problems in the sapdba –check log. Explain what happened to the entries for table BC505CHECK and index BC505CHECK~0.

6 Why is it important to run a backup after you have changed the file structure?

7 Check for internal fragmentation of tablespace PSAPUSER1D

7.1 Using “estimate sample 10 percent”

7.2 Using “compute statistics / validate structure”

7.3 Check the log files of the analyze actions. What is the difference between both methods?

8 Reorganize the index tablespace PSAPUSER1I using Alter Index Rebuild, the storage options compress extent and reduce object size, and hide the table during reorganization.

8.1 Check the log file of the reorganization.

(C) SAP AG BC505 20

9 Reorganize tablespace PSAPUSER1D including the data files, using the SAPDBA unloader / ORACLE SQL*loader, with option reduce object size, reduce data file size (accept the default).

9.1 Check the log file of the reorganization.

10 Optional: Reorganize tablespace PSAPUSER1D including the data files using the Oracle export/import, reduce object size and hide table during reorganization.

10.1 Check the log file of the reorganization.

11 Optional: Run script extent.sql from SQL*Plus to create an extent problem in tablespace PSAPUSER1D. Now execute the script extent_run.sql. Analyze the error message.

11.1 Correct the error and try to successfully complete the script extent_run.sql.

12 Optional: Run script ts_over.sql from SQL*Plus. Analyze the error message.

12.1 Solve the problem.

(C) SAP AG BC505 21

10.21Storage Management: SolutionsNo. Solution

1

2 As user ora<SID>, issue command sapdba –check.

2.1 After SAPDBA has finished, switch to directory sapcheck and look for the file <timestamp>.chk. Edit the file (using command more <check file name>, and use the spacebar to go to the next page). The following messages are displayed:

SEGMENT_MANY_EXTENTS : BC505CHECK

TABLESPACE_FULL : PSAPUSER1I(This problem will be solved later.)

3 Start SAPDBA, and choose: d – Reorganization b - Alter/show table or index storage parameters b - specify table name BC505CHECK s - Alter/show parameters b - NEXT, enter current value d – MAXEXTENTS, enter new value s – commit.

3.1 After SAPDBA has finished, switch to directory sapcheck and look for the file <timestamp>.chk. Edit the file (using command more <check file name>). The following message should no longer be displayed: SEGMENT_MANY_EXTENTS : BC505CHECK

4 Run sapdba –next PSAP%. Then run sapdba –check again.

4.1 After SAPDBA has finished, switch to directory sapcheck and look for the file <timestamp>.nxt. NEXT for BC505CHECK has been changed by sapdba –next.

4.2 BC505CHECK is now reported as a critical object because PSAPUSER1D is too small to hold a NEXT extent of this table. As sapdba –next can increase the NEXT size of tables or indexes, the larger NEXT extents may not fit into the tablespace anymore. Run sapdba –check to detect these problems.

5 Start SAPADBA and choose: c - Tablespace administration a – Tablespace, enter PSAPUSER1D f – Alter tablespace PSAPUSER1D add data file c – New size, enter 1M s – Start.

You can skip the backup action recommended by SAPDBA.

5.1 Start SAPADBA and choose c - Tablespace administration a – Tablespace, enter PSAPUSER1I f – Alter tablespace PSAPUSER1I add data file c – New size, enter 200KB s – Start

You can skip the backup action recommended by SAPDBA

5.2 As PSAPUSER1D/PSAPUSER1I are now large enough to hold a NEXT extent of BC505CHECK/ BC505CHECK~0, the critical object entries are no longer displayed.

6 You should always save the extended tablespace and the new version of the control file after the extension so that the complete recovery functionality of the SAPDBA is available (partial restore and complete recovery). To do this, you can use, for example, the SAP tool BRBACKUP. For this reason, after a tablespace extension, SAPDBA automatically branches to the backup database menu to enable you to

(C) SAP AG BC505 22

start the appropriate backup immediately.

7

7.1 Run command sapdba –analyze PSAPUSER1D -method E –option P10

7.2 Run command sapdba –analyze PSAPUSER1D -method CI

7.3 Log files are written in directory sapcheck.

The log file name of an analyze action is <timestamp>.aly.

For the estimate method, empty and never_been_used always have the same value.

For the compute statistics/validate structure method, the values for empty and never_been_used differ, as this method is more accurate.

8 Start SAPDBA and choose d – Reorganization e – Reorganize tablespace a – Tablespace, and enter PSAPUSER1I. Then choose g – Storage parameters d – Reduce object size q – return q – return h - Object handling a – Hide tables during reorg c – Rebuild indexes q – return s – Start.

After generating a script, start the script immediately using option 1.

8.1 Check the file <timestamp>.rtc in directory sapreorg.

9 Start SAPDBA and choose d – Reorganization f – Reorganize tablespace and data files a – Tablespace, and enter PSAPUSER1D. Then choose f – ORACLE exp/imp. Then choose b to toggle to Unload / load q – return g – Storage parameters d – Reduce object size q – return h – Object handling d – Reduce data file size (use 10% default) q – return s – Start.

After generating a script, start the script immediately using option 1.

9.1 Check the file <timestamp>.rtd in directory sapreorg.

10 Start SAPDBA and choose d – Reorganization f – Reorganize tablespace and data files a – Tablespace, and enter PSAPUSER1D. Then choose g - Storage parameters d – Reduce object size q – return q – return h - Object handling a – Hide tables during reorg q – return s – Start.

After generating a script, start the script immediately using option 1.

10.1 Check the file <timestamp>.rtc in directory sapreorg.

11 Change to directory /<ORACLE_HOME>/scripts, start SQLPLUS, log on as user SAPR3, and run @extent.sql. Now execute the script extent_run.sql. A MAXEXTENT problem is displayed for table BC505CHECK.

11.1 Increase parameter MAXEXTENTS for table BC505CHECK (see exercise 3).

12 Change to directory /<ORACLE_HOME>/scripts, start SQLPLUS, log on as user SAPR3, and run @ts_over.sql. Now execute the script ts_over_run.sql. A tablespace overflow will be displayed for tablespace PSAPUSER1D.

12.1 Add a data file to tablespace PSAPUSER1D (see exercise 5).

(C) SAP AG BC505 23

11

SAP AG 1999

Performance Monitoring

1 Database Overview 6 Advanced Backup Techniques

2 Backup Strategy and Tape Management

7 Storage Management

3 Scheduling, Performing,and Monitoring Backups

8 Performance Monitoring

4 Restore and Recovery 9 Top 10 Problems

5 Backup Strategies Using RMAN

(C) SAP AG BC505 1

11.2

SAP AG 1999

Performance Monitoring

Contents Cost-based optimizer Memory configuration Application design Physical and logical layout

ObjectivesAt the end of this unit, you will be able to: Identify performance problems Refresh the statistics used by the cost-based optimizer

When you have completed this unit, you will be able to: Identify performance problems by monitoring the:

Cost-based optimizerMemory configurationApplication designPhysical and logical layout

Refresh the statistics used by the cost-based optimizer

(C) SAP AG BC505 2

11.3

SAP AG 1999

Performance issuesPerformance issues Cost-based optimizerCost-based optimizer

Memory configurationMemory configuration

Application designApplication design

Physical and logical layout

Database Related Performance Issues

Poor database performance can result from problems with the cost-based optimizer, database memory configuration, application design, or the physical and logical layout.

This unit focuses on how to use R/3 to monitor and identify these performance problems.

(C) SAP AG BC505 3

11.4

SAP AG 1999

Cost-based optimizerCost-based optimizer

Modifying the standard

procedure

Modifying the standard

procedure

Refreshing the object statisticsRefreshing the

object statistics

Reasons for performance

problems

Reasons for performance

problems

Cost-Based Optimizer

The following section describes: What cost-based optimization means How to check for performance problems originating from the cost-based optimizer environment How to refresh the statistics used by the cost-based optimizer How to modify the standard procedure used for refreshing the optimizer statistics

(C) SAP AG BC505 4

11.5

SAP AG 1999

OPTIMIZEROPTIMIZER

Which is the optimal access path?Which is the optimal access path?

DatabasetableADDR

Index A

Fulltablescan

Index BSELECT * FROM ADDR SELECT * FROM ADDR

WHERE name = 'miller'WHERE name = 'miller'ANDAND pnumpnum = 123= 123

AND city = 'Houston'AND city = 'Houston'

init<SID>.oraOPTIMIZER_MODE = choose

$$$$

$$$$$$

$$$$$$$$

Possible access pathsPossible access paths

CostsCosts

Oracle Cost-Based Optimizer: Review

The cost-based optimizer determines the most effective strategy for retrieving database data. The access strategy used depends on the information in the: Queried table (or tables, for a view or join) Fields specified in the WHERE clause of the SQL statement Indexes defined for the tables queried

The cost-based optimizer computes the cost of several strategies for accessing the tables, and chooses the one that requires the smallest amount of data accesses. To calculate the cost of a strategy, the optimizer requires statistical information about the tables and indexes of the database, such as: Number of table or index rows and number of blocks allocated for the object Number of distinct values in each column of the table

The statistical information for a table or index is stored in the Data Dictionary of the database. To collect the statistical information, use the Oracle SQL command analyze table.

(C) SAP AG BC505 5

11.6

SAP AG 1999

SYSTEM

Statisticinformation

Old statistic information

No precise statistic information

Incorrect assumptions

Not using SAP-tools to refresh the statistics

Cost-Based Optimizer Performance Problems

Performance problems can occur if the cost-based optimizer uses: Old or non-existent statistic information No precise statistic information Incorrect assumptions, such as uniformly distributed data within the object

You can solve performance problems regarding old, non-existent, or no precise statistic information by: Refreshing the object statistics by using the SAP two-phase strategy Increasing the precision by modifying the SAP standard procedure

You can solve performance problems regarding incorrect optimizer assumptions by: Using optimizer hints or histograms (as of R/3 Release 4.5A). See SAP Notes 129385 and 130480 Using the rule-based optimizer access for some tables by modifying the SAP standard procedure Changing the application access to the data

Performance problems can also occur if SAP tools (SAPDBA or CCMS) are not used to refresh the object statistics. Statistic updates performed by non-SAP tools can create severe performance problems if the precision of the update is not set correctly.

(C) SAP AG BC505 6

11.7

SAP AG 1999

Phase 1

SAPDBA determines which objects in the database need refreshing

Object needs to be refreshed if:

The number of rows in the table from last the check

differ from

The actual number of rowsin the table

by more than the threshold

Table E P10 x

Control table(DBSTATC)

Object name

Option

New statisticsneeded

Method

Refreshing the Object Statistics: Phase 1

To minimize the time and system overhead necessary to refresh the cost-based optimizer statistics, SAP provides the following two-phase strategy: Phase 1: SAPDBA determines which database objects need refreshing Phase 2: SAPDBA refreshes only the objects determined in phase 1

The control table DBSTATC stores information about the objects that need to be refreshed. During phase 1, SAPDBA determines which objects need to be refreshed by the following rule: If the number of rows in a table found during the last check differs from the actual number of rows

by more than a specific threshold number, then the object needs to be refreshed. By default, the threshold number is 10% for small tables and 100% for large tables.

Rows for objects in the control table DBSTATC that need to be refreshed are either updated or new rows are created, then they are flagged as New statistics needed.

The four important columns in control table DBSTATC for phase 1 are: Object name: The name of the object that needs to be refreshed Method: The method used to analyze the object. Either C (compute) or E (estimate). Default value:

E (estimate) Option: Percentage (P<n>) or number of rows (R<n (* 1000)>) to be analyzed if method E

(estimate) is chosen. Default value: 10 percent. New statistics needed: A flag that indicates that the statistics need to be refreshed

(C) SAP AG BC505 7

11.8

SAP AG 1999

SAPBDAReads entries in the control table

(DBSTATC)Checks the flag for new statisticsneeded

Phase 2

SAPDBA refreshes the objects

Unflagged

Control table(DBSTATC)

Table E P10 x

Object name

Option

New statisticsneeded

Method

Refreshing the Object Statistics: Phase 2

Only the statistics of tables that are flagged with new statistics needed in the control table DBSTATC are refreshed during phase 2.

After the statistics are refreshed, the row remains in the control table DBSTATC, but the column New statistics needed is unflagged.

The SAP standard procedure does not create statistics for pool and cluster tables and deletes any statistics that already exist. This ensures that the rule-based optimizer access is used for pool and cluster tables. If the Oracle parameter optimizer_mode is set to Choose and no statistics exist for any database object part of an SQL statement, Oracle chooses the rule-based optimizer access instead of the cost-based optimizer access.

(C) SAP AG BC505 8

11.9

SAP AG 1999

Control table DBSTATC

DB object TODO flag …

AUFK x …

EKPO …

KNVK x …

LIPS …

MKPF …

VBUK x …

RESB x …

SAP Two-Phase Strategy

sapdba-analyze DBSTATCO

SAPDBA- x

The statistics for the database objects that are

marked in table DBSTATC are updated

PHASE 2

sapdba-checkopt PSAP%

SAPDBA- x

Database objects requiring an update of optimizer statistics are determined and marked in

table DBSTATC

PHASE 1

sapdba-statistics all

SAPDBA- xExecute both phases inone step,

once a week

ALTERNATIVELY

Only up-to-date statistical information can ensure that the Oracle cost-based optimizer chooses the optimal access path. However, gathering optimizer statistics is expensive and reduces system performance.

We recommend the following two-phase strategy: In the first phase, the SAP tools determine which tables require a statistical update. The command

sapdba -checkopt PSAP% determines which database objects contain obsolete statistics, and modifies the control table DBSTATC accordingly.

In the second phase, the statistics of the tables marked TODO in the control table DBSTATC are refreshed using command sapdba -analyze DBSTATCO.

As of R/3 Release 4.6B, you can use the command sapdba -statistics. This command runs both of the phases in parallel. That is, you do not have to schedule the second phase separately. You should schedule command sapdba -statistics to be run once a week, during periods of low system activity.

(C) SAP AG BC505 9

11.10

SAP AG 1999

Modifying the Standard Procedure

...

New Entries: Details of Created Entries

Object informationDB object BC505TS

DB object type 01

OwnerDatabase

Default settingsUse 0 Analysis method

Analysis optionActive A

Date changed

TODO settingsTODO flag x Customer

TODO date

Table view Edit Goto Selection criteria Utilities System Help

Act Short text

A Active (generating statistics)

I Ignore

P Positive (active with priority)

U Forced (statistics are constantly updated)

R Restrictive (only active for the appl. tab. monitor)

Control flag for analysis

X

E

P30

History Customer

Analysis

To modify the standard procedure used for refreshing the optimizer statistics, use the CBO Control Panel (transaction DB21).

There are two ways you can modify the standard procedure: Increase the precision of the statistics for a single table (including the index) Delete statistics for a single table (including the index)

To increase the precision, you must enter the name of the DB object, the DB object type (01 for a table), the Type of usage (O for optimizer), Active (A for active or P for active with priority), the Analysis method (E for estimate, C for compute, EH for estimate with histograms or CH for compute with histograms), and the Option (percentage (P<n>) or number of rows (R<n (* 1000)>) to be analyzed if method estimate is chosen).

For every customer defined entry in the control table DBSTATC, you must select the field Customer. If the field Customer is not selected, entries defined as Type of usage = O that are not changed for

more than 30 days are removed from control table DBSTATC automatically. You can delete statistics for a single table so that the rule-based optimizer is used. Specify the value

for Active as I (ignore) if you do not want the object to be analyzed, or specify the value as R (restrictive) to allow the object to be analyzed for space purposes.

When you modify the standard procedure, select the TODO flag so that the modifications are used the next time the statistics are refreshed.

(C) SAP AG BC505 10

11.11

SAP AG 1999

...

Database Checks

Tablespaces

Tables/Indexes

Database performance: Tables and Indexes- x

Tables and Indexes Monitor

COST-BASED OPTIMIZER Actions- xEdit System Help

Begin of action End of action Fct Object RC 22.03.1999 02:01:22 22.03.1999 02:28:12 aly DBSTATCO 0002 21.03.1999 02:01:17 21.03.1999 02:24:54 opt PSAP% 0001 15.03.1999 02:01:18 15.03.1999 02:21:09 aly DBSTATCO 0000 14.03.1999 02:01:19 14.03.1999 02:27:17 opt PSAP% 0000

Select optionsSelect options SortSort

DBA Logging Monitor

SAP Note Search

Search Criteria:

<table name>

Performance

- x

SAP Notes

Use SAP tools only to refreshUse SAP tools only to refreshR/3 table statisticsR/3 table statistics

Using R/3 to Monitor Performance Problems

For general performance problems, use the DBA Logging Monitor (transaction DB14) to check whether the statistics are up-to-date.

If a specific SQL statement causes performance problems, you must check whether: The statistics of all the tables accessed by the SQL statement are up-to-date with the correct

precision, using the Tables and Indexes Monitor (transaction DB02) There is an SAP Note related to the problem A statistical update is necessary for any of the tables accessed The rule-based optimizer would use a better access path

If no solution can be found or if you have to switch back to the rule-based optimizer, create a customer message in SAPNet using the component BC-DB-ORA.

Remember: When you refresh the statistics of R/3 tables, use SAP tools only. SAP tools ensure that the statistical update is performed using the method and option defined for the object in the control table DBSTATC. Statistical updates performed by non-SAP tools can create severe performance problems if the precision of the update is not set correctly.

(C) SAP AG BC505 11

11.12

SAP AG 1999

Memory ConfigurationMemory ConfigurationMemory Configuration

Data bufferData bufferData buffer

Shared poolShared poolShared pool

Memory Configuration

The following section describes: The Oracle memory configuration What the data buffer is used for How the size of the data buffer is determined What the shared pool is used for How the size of the shared pool is determined

(C) SAP AG BC505 12

11.13

SAP AG 1999

The data buffer functions as a cache for the database

Database

RDBMSSGASGA Data bufferData buffer

Shared pool

parsed SQLstatements andexecution path

dc information about objects

of the database

Datafiles

... SystemPSAPBTABIPSAPBTABI PSAPSTABD

Memoryarea

Shared SQL Area Row CacheR/3 work process

SELECT * FROM MARA

WHERE ...

Shadowprocess

Logical Logical readsreads

Physical readsPhysical reads

Data Buffer Utilization

A physical read must go to the disk to access the database data. When a physical read occurs, a copy of the data block is written to the data buffer and then read and analyzed by the shadow process.

A logical read does not need to go to the disk to access the database data, instead, it reads the data block from the data buffer.

Accessing the data buffer is 1000 times faster than accessing the disk. To minimize disk access, the data buffer must be tuned.

When a database update occurs, the data blocks are updated in the data buffer immediately, and written to disk at later time.

(C) SAP AG BC505 13

11.14

SAP AG 1999

ST04: Database performance analysis: Oracle database overview

??

Refresh Detailed Analysis Menu

ORACLE Monitor

Data Buffer

Shared Pool

Calls

SizeQuality

256,00097

Log buffer

ReadsPhysical reads

writes

389,42210,809

2,325

kb%

...

.........

94

Identifying the Data Buffer Hit Ratio

The hit ratio (Quality) of a database is defined as the percentage of data blocks accessed (Reads) compared with the total number of data blocks read from disk (Physical reads). The Reads are the sum of the logical and physical reads.

The hit ratio is displayed in the Database Performance Monitor (transaction ST04), and should be at least 94%.

Since the hit ratio is poor in the first few hours after startup, you should only evaluate the hit ratio after your system has been up for some time. As a general rule, wait until the number of Reads exceeds 20,000,000.

Before you increase the size of the database buffer, check for poorly qualified SQL statements. Problems in the application can cause poor hit ratios in even the largest of database buffers, for example, in the case of inefficient SQL coding, many blocks may be read into memory unnecessarily.

(C) SAP AG BC505 14

11.15

SAP AG 1999

DB_BLOCK_BUFFERSparameter in init<sid>.ora

Use the Operating System Monitorto analyze the

operating system paging statisticsbefore and after increasing

DB_BLOCK_BUFFERS

Hour Pages in Pages out Paged in Paged out/h /h [Kb/h] [Kb/h]

13 11 0 44 0 12 227 0 908 0 11 2,162 2,542 8,648 10,168 10 626 464 2,504 1,856 9 22 0 88 0 8 22 0 88 0 7 42 64 168 256 6 74 64 296 256 5 3,034 2,363 12,136 9,452 4 1,648 1,106 6,592 4,424 3 22 0 88 0 2 29 0 116 0 1 89 0 356 0 0 83 0 332 0

23 33 0 132 0 22 1,063 0 4,252 0 21 22 0 88 0 20 8,157 2,435 32,628 9,740 19 22 0 88 0 18 128 0 512 0 17 4,046 3,056 16,184 12,224 16 53 0 212 0 15 281 0 1,124 0 14 39 0 156 0

Increasing the Size of the Data Buffer

If the hit ratio is lower than 94%, consider increasing the database buffer. But before you increase the size of the database buffer, check for poorly qualified SQL statements. Problems in the application can cause poor hit ratios in even the largest of database buffers, for example, in the case of inefficient SQL coding, many blocks may be read into memory unnecessarily.

To increase the size of your database buffer, change the init<sid>.ora parameter DB_BLOCK_BUFFERS (which is specified in units of blocks). This parameter specifies the number of database blocks buffered in memory. Note: When you increase this parameter, you reduce the memory available to other processes in the system, which may cause OS paging and/or swapping to occur.

To check the OS paging use the OS Monitor (transaction ST06 ) and choose Detailed Analysis Previous Hours: Memory.

Each hardware platform has an upper limit on the total amount of shared memory that can be allocated. The sum of the fixed and variable portions (data buffer cache, shared pool, and log buffer) of the System Global Area cannot exceed this amount.

To monitor changes in any Oracle initialization parameters, use transaction DB03.

(C) SAP AG BC505 15

11.16

SAP AG 1999

The shared pool caches parsed SQL statements and Data Dictionary information from the database

Database

RDBMSSGASGA Data bufferData buffer

Shared poolShared pool

Data files

Memoryarea

Shared SQL Area Row Cache

...

R/3 work process

Shadowprocess

SELECT * FROM MARA

WHERE ... User callsUser calls

Recursive callsRecursive calls

PSAPBTABI PSAPSTABD System

Parsed SQLstatements andexecution path

dc information about objects

of the database

Identifying Usage of the Shared Pool

The shared pool consists of the: Shared SQL Area, where parsed SQL statements are cached for shared access to all shadow

processes Row Cache, which holds the Oracle Data Dictionary information, including the cost-based

optimizer statistics. Note: With the cost-based optimizer, the Row Cache will have substantially more information to hold than with the rule-based optimizer

A user call refers to a shadow process accessing the Shared SQL Area for parsed SQL statements. A recursive call refers to the Row Cache making a physical read to load Oracle Data Dictionary

objects from the system tablespace.

(C) SAP AG BC505 16

11.17

SAP AG 1999

Identifying the Efficiency of the Shared Pool

ST04: Database performance analysis: Oracle database overview

??

Refresh

ORACLE Monitor

Data Buffer

Shared Pool

Calls

Size kbDD-cache quality %

...

User calls......

128,00097...

96

18,131......

Log buffer

Recursive calls......

2,338......

User calls / Rec. calls

...pinratio %

...7.75

...2

0.03reloads/pins % 0.04

80

95

Previous DaysDetailed Analysis Menu

The ratio of user calls to recursive calls should be at least 2 to 1. The Data Dictionary cache quality should also be greater than 80%. The pin ratio should be larger or equal 95%. The ratio of reloads to pins should be at maximum 0.04. Since these ratios are poor in the first few hours after startup, you should only evaluate them after

your system has been up for some time. As a general rule, you should wait until the number of Reads exceeds 20,000,000.

Note: Creating new optimizer statistics is heavily based on recursive calls. You should therefore first make sure that creating statistics is not responsible for the values. To do this, check the history by choosing the Previous days button.

(C) SAP AG BC505 17

11.18

SAP AG 1999

SHARED_POOL_SIZEparameter in init<sid>.ora

Examine the operating system paging statistics using theOperating System Monitor

before and after increasing SHARED_POOL_SIZE

Hour Pages in Pages out Paged in Paged out/h /h [Kb/h] [Kb/h]

13 11 0 44 0 12 227 0 908 0 11 2,162 2,542 8,648 10,168 10 626 464 2,504 1,856 9 22 0 88 0 8 22 0 88 0 7 42 64 168 256 6 74 64 296 256 5 3,034 2,363 12,136 9,452 4 1,648 1,106 6,592 4,424 3 22 0 88 0 2 29 0 116 0 1 89 0 356 0 0 83 0 332 0

23 33 0 132 0 22 1,063 0 4,252 0 21 22 0 88 0 20 8,157 2,435 32,628 9,740 19 22 0 88 0 18 128 0 512 0 17 4,046 3,056 16,184 12,224 16 53 0 212 0 15 281 0 1,124 0 14 39 0 156 0

Increasing the Size of the Shared Pool

If any of these ratios are lower then the threshold mentioned, increase the size of the shared pool. There are no specific Oracle parameters for increasing the size of the Row Cache or the size of the

Shared SQL Area. By increasing the area for the entire shared pool, you also increase the amount of space available for both areas.

To increase the entire shared pool, change the init.ora parameter SHARED_POOL_SIZE (which is specified in units of bytes). Do not cause excessive operating system paging by using too much memory.

(C) SAP AG BC505 18

11.19

SAP AG 1999

Application designApplication designApplication design

Lockwait situationsLockwait situationsLockwait situations

Expensive SQL statementsExpensive SQL statementsExpensive SQL statements

Poorly qualified statementsPoorly qualified statementsPoorly qualified statements

Application Design

This section describes how to identify the following application design problems: Lockwait situations Expensive SQL statements Poorly qualified SQL statements

(C) SAP AG BC505 19

11.20

SAP AG 1999

WorkProcess 1

WorkProcess 3

WorkProcess 4

WorkProcess 2

AcquiresMARA Lock

A long period of processing

CommitUpdate MARA

Working...WAITING!Update

MARARequests

MARA LockAcquires

MARA LockCommit

Working...WAITING!Update MARA

RequestsMARA Lock

AcquiresMARA Lock

WAITING ...Update MARA

RequestsMARA Lock

MARALocked

by

WP 1 WP 2 WP 3

When a Lockwait Situation Occurs

A lockwait situation occurs when numerous work processes request a lock on the same object. In order for the RDBMS to maintain transactional consistency, the object is locked by the process that requested it first.

If a user starts a logical unit of work and updates an object, such as the most often used material number of the company, then all other users who want to update the same material must wait until the first user has committed the changes before they can get the record.

A user holding a lock will occupy an R/3 work process. Other users trying to apply the same lock must wait and at the same time occupy their own R/3 work process. As the number of lockwaits increases, fewer and fewer R/3 user requests can be processed by available R/3 work processes. In a worst-case scenario, the lock holders and waiters would equal the number of R/3 work processes, and a small number of users could cause the entire R/3 system to “freeze”.

(C) SAP AG BC505 20

11.21

SAP AG 1999

Using the Exclusive Lockwait Monitor

Object Holder (Oracle-SID, -SPID; Client-Host, -PID) Level Time (s)

Waiters (Oracle-SID, -SPID; Client-Host, -PID) Row-ID

T100 9 , 9.687 ; hs5821 , 9.681 1 21

41

30.07.1999 14:45:58 TC1 hs5821Exclusive session-lock situations

Level Time (s)

14 , 27730 ; hs5821 , 16.492 1 6

Double-click

Primary keyvalues

Oracle Session-ID 0Locked object MONILocked Row (ID) AAAA8mAALAAAAQkAAFValues:

RELID DBSRTFD TC1 snapshot1SRTF2

30.07.1999 14:59:00 TC1 hs5821Exclusive session-lock situations

Use the Exclusive Lockwait Monitor (transaction DB01) to identify exclusive lockwait situations and to display information about the: Lock holder Number of lock waiters Primary key locked

(C) SAP AG BC505 21

11.22

SAP AG 1999

Reducing Exclusive Lockwaits

Redesign the application to reduce the locking period by:

Increasing the commit frequency in the application

Not allowing a single process to hold a lock for a long period

Locking the object as late as possible

Adjust the job scheduling cycle so that lock situations do not occur

If exclusive lockwait situations occur because a user holds the lock too long, analyze the application and determine whether: More commits can be safely built into the application The lock period can be shortened by acquiring the lock later

If exclusive lockwait situations occur because many users want to access the same record in high-volume processing, you can schedule the jobs to be performed at different times.

(C) SAP AG BC505 22

11.23

SAP AG 1999

Total Reads / Buffer Gets 5 %

Identifying Expensive SQL Statements (1)

Buffer

Gets

1,272,090

1,204,074

704,074

443,694

Shared SQL Area

6.1%

Sortedby

Database Performance Monitor

??

Refresh Detailed Analysis Menu

ORACLE Monitor

Shared Pool Log buffer

ReadsPhysical reads

writes

20,853,934581,80942,325

... ...

Data Buffer

... ...Reads / User calls 7.8 20

An indicator for having expensive SQL statements in the system is the ratio of Reads to User calls. This value should be less than 20. If this value is greater than 20, you must check the SQL statements in detail.

Expensive SQL statements have a high number of Buffer gets compared to Total reads. If the ratio of Buffer gets to Total reads is greater or equal than 5%, the SQL statement is expensive. Once a statement has been identified as expensive in the Shared SQL Area, run an Explain plan on

the statement. After you have run an Explain plan on an expensive SQL statement:

Check the cost-based optimizer settings for the tables being used in the SQL statement Create a customer message in SAPNet if the statement is identified as part of the SAP code Redesign the application if the statement is identified as part of the customer code Check if the statement is poorly qualified

(C) SAP AG BC505 23

11.24

SAP AG 1999

ST04 - Detailed Analysis - SQL Request - Database Performance: Shared SQL

??

Sort Reset Since Reset Since DB Start

Detail stats.

25.05.199916:54:36 Shared Cursor Cache (last reset at 25.05.1999 15:17:55 )

Total Current Disk Reads/ Buffer Gets/ Records Records/ Bufgets/ SQLExecution Exec Reads Execution Gets Execution processed Execution record Sort

7,476 0 12,468 1.7 1,272,090 170.2 6,336 0.8 200.8 0 81 0 149,601 1,846.9 7,709,223 95,175.6 783 9.7 9,845.8 0 5 0 22,594 4,518.8 1,204,074 240,814.8 142,221 28,444.2 8.5 0 3 0 10,604 3,534.7 443,694 147,898.0 0 0.0 443,694.0 1

Number ofexecutions

Sorted by

Number ofbuffer getsper record

Identifying Expensive SQL Statements (2)

To identify expensive SQL statements, use the Database Performance Monitor (transaction ST04) and choose Detailed analysis SQL request.

Analyze the Shared SQL Area statistics collected since the last startup: The column Total Execution refers to the number of times the SQL statement was executed The column Buffer Gets refers to the total number of buffers accessed by the statement The column Bufgets/record refers to the average number of buffers accessed per record retrieved

Sort by the column Buffer Gets. Check for statements that are executed very often with a low number of Bufgets/record. These statements should be analyzed.

To identify which program an SQL statement belongs to, you can check: The WHERE-USED list in the Data Dictionary (transaction SE12) The SystemWide Work Process Overview (transaction SM66) and the Oracle Session Monitor

(transaction ST04 Detailed analysis)

(C) SAP AG BC505 24

11.25

SAP AG 1999

Total Disk Reads/ Buffer Gets/ SQL

Execution Reads Execution Gets Execution Text

Total Disk Reads/ Buffer Gets/ SQL

Execution Reads Execution Gets Execution Text

57 554 9.7 5,200,089 91,229.6 SELECT "PGMID" , "OBJECT" , " DEVCL

Specify hint:For testing only!

No change to the SAP code

SQL Statement

SELECT *

FROM"TADIR"

WHERE

"PGMID" = :A0 AND "OBJECT" = :A1 AND "DEVCLASS" = :A2 AND ROWNUM <= :A3 #

Execution Plan

SELECT STATEMENT ( Estimated Costs = 95 )

5 COUNT STOPKEY

5 TABLE ACCESS BY INDEX ROWID TADIR

INDEX RANGE SCAN TADIR^1

Explain with hintExplain with hint Optimizer traceOptimizer trace

Specify Hint

Enter the hint without the comment

signs /*+ ... */ (for the syntax of

hints see the ORACLE tuning guide)

CancelContinue

Running an Explain Plan

Double-click

To run an Explain plan for an expensive SQL statement, double-click the appropriate line in the Shared SQL Area and choose Explain.

The output of the Explain plan shows how the cost-based optimizer has decided to access the data. The option Explain with hint allows you to check a possible change in the access path using Oracle

hints, such as checking the access path chosen by the rule-based optimizer (Hint RULE). When you use a hint, only a new explain plan is created, the actual SQL statement is not changed.

For further information about Oracle hints, refer to Oracle documentation. Here are the definitions of some Explain plan output for SQL statements:

INDEX RANGE SCAN: The database retrieves a number of records using an index to limit the result set before going to the data pages

INDEX UNIQUE SCAN: The database retrieves a single row from an unique index INDEX NAME: The name of the index that the database uses for retrieving data CONCATENATION: The database unites a set of rows retrieved for the query NESTED LOOPS: The database joins one table to a second table, using the information found in

the first table to check second table, and builds a result set out of both tables TABLE ACCESS FULL: The database retrieves all rows from the table to build the result set SORT: The database sorts the data before returning it

(C) SAP AG BC505 25

11.26

SAP AG 1999

Total Buffer Bufgets/

Execution Gets Record

Total Buffer Bufgets/

Execution Gets Record

28 1,333,625 666,812.5

Table MARAFull table scan Index scan

SELECT * FROM MARA WHERE MATERIAL = 10001

Index MARA~O

Poorly Qualified SQL Statements

Poorly qualified SQL statements do not use an index correctly to access the data. If an index is used correctly, data access is more efficient.

To identify poorly qualified SQL statements, check the Shared SQL Area for expensive statements with a high number of Bufgets/record. Poorly qualified statements usually occur if: No index is associated with the table being accessed A secondary index is required for the query being performed The incorrect index is being utilized An index is being used although a full table scan would be more effective, for example, in the case

of small tables or a high number of records retrieved The index being used is defined incorrectly

If a statement is identified as a poorly qualified SQL statement because of an SAP report, create a customer message in SAPNet.

Note: Do not change the standard R/3 index design. This is considered an “expert” tuning measure. Contact SAP for support.

(C) SAP AG BC505 26

11.27

SAP AG 1999

SQL Explain Plan

No index being used

Full Table Scan

Execution Plan

SELECT STATEMENT( Estimated Costs = 59 )

TABLE ACCESS FULL MARA

Table MARA

Last statistics date 05.06.1998Number of rows 73,181Number of blocks allocated 610Number of empty blocks 9Average space 1,133Chain count 0Average row length 56

UNIQUE Index MARA_____0

Column Name #Distinct

MANDT 1MATNR 224,405

NONUNIQUE Index MARA___L

Column Name #Distinct

MANDT 1MATKL 72

Continue Show statistics

Show Indexes of Table MARA

Analyzing Poorly Qualified SQL Statements

To check if an index is being used to access data, run an Explain Plan on the SQL statement. To display the information about the index structure or the structure of the table and all indexes,

double-click the index or table name. Information is also displayed about the statistics that the cost-based optimizer used to create the access, and the date the statistics for this table was last refreshed.

(C) SAP AG BC505 27

11.28

SAP AG 1999

Physical and logical layoutI/O contention

Checkpoint not complete

Rollback statement problems

Fragmented indexes

Physical and Logical Layout

This section describes the following physical and logical layout problems: I/O contention Checkpoint not complete (for online redo log files) ORA-1555 Snapshot too old (for rollback segments) Fragmented indexes

(C) SAP AG BC505 28

11.29

SAP AG 1999

Occurs when numerous shadow processes and the database writer access the same disk at the same time

ShadowprocessShadow

processShadowprocessShadow

processShadowprocess

PSAPBTABD

PSAPSTABD PSAPPOOLD

PSAPUSER1D PSAPBTABI

PSAPSTABD

DatabasewriterDBWR

READ WRITE

I/O Contention

I/O contention refers to the high I/O wait times for processes accessing the database. When numerous Oracle shadow processes and the database writer access the same disk at the same time, I/O contention is likely to occur.

I/O contention occurs if: The application design is inefficient, due to expensive, unnecessary, or poorly qualified SQL

statements The I/O is not evenly distributed across many disks The disks are not fast enough to handle the high I/O activity Heavily accessed tables or indexes are not distributed or striped across many disks The hardware configuration is incorrect (for example, many disks and not enough controllers)

I/O contention is often caused by application design problems, therefore, check this first.

(C) SAP AG BC505 29

11.30

SAP AG 1999

I/O per path

Check for:

Average read times > 20ms

Deviations from the median value > 20%

11.08.1999 17:35:22 TC1 hs5821Statistics of physical accesses on Oracle database

Blk Reads Avg(ms) Avg(ms)

85,751127,381

26,962,690 354

333,635 93,629

178,322 248,200 22,226

Filename

/oracle/TC1/sapdata1/oracle/TC1/sapdata10/oracle/TC1/sapdata2 /oracle/TC1/sapdata3 /oracle/TC1/sapdata4 /oracle/TC1/sapdata5 /oracle/TC1/sapdata6 /oracle/TC1/sapdata7/oracle/TC1/sapdata8/oracle/TC1/sapdata9

Reads

20,346 8,358

4,277,300 96

133,641 89,761 83,173 243,981

3,478 13,764

Writes

12,056 16

3,868 43

65,120 1,060 506 221 46 30 181,332

3 1 3 5 3 4 3 5 2 1

Blk Writes

12,056 16

3,868 43

493,064 1,060

506 221 46 30

7 6 6 15 5 6 5 5 6 3

Sorted by

Identifying I/O Contention in the Database

To identify I/O contention in the database, use the Database Performance Monitor (transaction ST04) and choose Detailed analysis File system requests I/O per path.

The I/O per path allows us to identify the sapdata mount points where I/O contention is occurring. Check the Average ms columns for block reads (BLK Reads) and block writes (BLK writes), and use

these values to identify “hot disks”. If the total number of reads and writes is relatively low, there is no I/O contention. If the total number of reads and writes is high, check if the average read time is higher than 20 ms. You can also identify "hot disks" by checking for values that deviate by more than 20% from the

median value of the average read or write times. Note: Due to the various hardware configurations and disk speeds, the actual values can differ

significantly from system to system. Contact your hardware vendor for specific information. Because Oracle writes data blocks asynchronously, the average write time is not important.

However,the average write time becomes important if Oracle is not able to handle the volume anymore. You can identify this situation by checking the write complete waits and the free buffer waits in view v$system_event.

(C) SAP AG BC505 30

11.31

SAP AG 1999

Total per device

Statistics of physical accesses on Oracle database

Filename Reads Writes Blk ReadsAvgms Blk Writes Avgms

docud_1 loadi_1 poold_1poold_2protd_1roll_1

/oracle/TC1/sapdata1

es40bd_2

/oracle/TC1/sapdata10

ddicd_2docui_1system_1

/oracle/TC1/sapdata2

protd_2

/oracle/TC1/sapdata3

btabd_1clui_1

303 29

14,914 2,113 1,294 1,693

20,346

8,358

8,358

2,113 1,695

1,273,492

1,277,300

96

96

190

11 11 44 13

673 11,304

12,056

16

16

11 11

3,846

3,868

43

43

795 11

1,796 29

62,372 14,982 4,879 1,693

85,751

127,381

127,381

10,403 1,695

950,592

962,690

354

354

40,590 190

2 5 3 2 3 1

3

1

1

2 7 0

3

5

5

2 8

11 11 44 13

673 11,304

12,056

16

16

11 11

3,846

3,868

43

43

795 11

0 0 14 3 15 12

7

6

6

0 0 19

6

15

15

15 0

Solving the I/O Contention Problem

To solve the problem of I/O contention, you can: Distribute the I/O evenly on the disks available Distribute the I/O evenly on more disk (then would be necessary to hold the database files) Purchase faster disks Move “hot spot” tables or indexes to their own tablespaces on their own disks (may be striped)

To identify the tablespace and the data file that has a bottleneck, you can break down the total I/O requests per file system by choosing Total per device. The tablespace and the data file can then be moved to another physical disk in the system.

Different hardware platforms may have bottlenecks in disk controller ports, motherboards, and back planes. Refer to your hardware vendor for I/O distribution guidelines.

(C) SAP AG BC505 31

11.32

SAP AG 1999

Online redolog files

2. DBRW writes datato disks

3. Redo log writer writes to the online redo log in parallel

4. Last online redolog file is full butthe checkpoint isnot completed

Data files

Data buffer

Redo log buffer

saptrace/background

alert_<SID>.log

Checkpoint notcomplete

1. Online redo log fileswitch occurs

Checkpoint not Complete

How the error Checkpoint not Complete occurs:1. An online redo log switch occurs and the check point process tags the online redo log group being

written to until the checkpoint triggered by the online redo log switch is complete.2. A checkpoint is triggered. That means, dirty pages from the data buffer are being written to disk

by the database writer (DBWR).3. Transactions are still occurring and committing, so data is written from the redo log buffer to the

online redo logs in parallel to the checkpoint.4. Eventually, after some log switches, all the online redo logs are in use before the checkpoint

triggered has finished. No data can be flushed from the redo log buffer to an online redo log file because all online redo log files are necessary for instance recovery.

The Oracle RDBMS automatically handles this situation, no further changes are processed until the checkpoint is complete and the online redo log file can be overwritten.

The message “Checkpoint not complete” is written to the Oracle alert log alert_<SID>.log. This problem generally occurs during high database activity and during peak hours.

If the message appears frequently, increase the number of online redo log groups. Increasing the size of the online redo log files is not recommended, unless the time between the two log switches is less than three minutes.

Note: This problem should only be of concern if it occurs frequently.

(C) SAP AG BC505 32

11.33

SAP AG 1999

Reading queryPers-No. Salary

1......... 2350

2......... 4362

8......... 3040

4......... 5827

9......... 4160

Table

Rows changed and committed

Rollback Segments

Transaction T1 (Update)

Transaction T2 (Select)

Commit

4320

5770

3010

4119

Rollback segment

Overwriteor

shrink

ORA1555

The rollback segments are used by the Oracle RDBMS to: Save before images of uncommitted transactions Provide read consistency during the runtime of a query

If rows of a table are modified, the before images of the data are copied to a rollback segment. After the commit, this information is no longer needed, and the rollback segment is freed by the process.

If a table is modified between the time a query is issued and when the records are delivered by the query, the data is read from the rollback segments. However, rollback segments are overwritten or shrunk in a cycle and are not locked for queries. If a query is not finished until the rollback segment is overwritten or shrunk, the query does not receive the data.

When this occurs, Oracle issues error 1555 Snapshot too old, and the query is aborted. A short dump then occurs, and an entry in the R/3 System log is generated.

(C) SAP AG BC505 33

11.34

SAP AG 1999

Solving Rollback Segment Problems

Database buffer pool

2. Long processing time between two data fetches

Application server

Large number of buffers used on the

database server

Database buffer pool

Application server

High processing time on the

application server

Snap dump

ORA1555

ORA1555

1. Expensive query

There are two main reasons why this error occurs: Expensive queries Long processing time between the fetches

Because a SELECT does not normally read all the data at one time, long processing times between the fetches can cause error ORA-1555, even if the statement is not expensive. The next fetch is processed on the database when it is requested. Therefore, even if the statement is not expensive, the time it takes until the statement is finished is long.

To avoid error ORA-1555: Decrease the runtime of the statement, by tuning the statement causing the Snapshot too old Decrease the processing time between two fetches of an SQL statement Schedule the reports and the updates at different times If none of these tuning methods are successful, increase the number or the size of rollback

segments (preferably, increase the number) Rollback data files have the highest amount of write activity in the database. To reduce bottlenecks

in the rollback segments, distribute the I/O for the data file evenly.

(C) SAP AG BC505 34

11.35

SAP AG 1999

...... ............ ...... ...... ......

...... ......

IndexIndex

............

...... ......

......

TableTable

... ... ... ...

2

1

3 4 5 6 7 8 9

Index with a low fill level

Many buffer gets per execution although the correct index is used

Fragmented Indexes

Fragmented indexes have a low fill level. Indexes can become fragmented:

After data has been archived After many records have been deleted In highly dynamic tables

An index that is fragmented consists of empty blocks or branch and leaf pages with only a few valid entries. If an index is fragmented, a query that scans a range in the index must read many index blocks. This affects the performance of the entire database, since data or index blocks of other tables are swapped out of the buffer by the newly read index blocks that contain only a few records.

In this example, 9 index blocks and 5 data blocks are read in order to retrieve five rows of the table.

(C) SAP AG BC505 35

11.36

SAP AG 1999

Use the Tables and Indexes Monitor

Fill level

Tables and Indexes: Detailed Analysis of T100^0R/3 xDB Analysis Extents Table Columns Detailed Analysis History

14.05.1999 11:36:20 Analysis of B*-tree Data from INDEX_STATS

Storage summary Performance summaryLevels................ 3 Gets per access........ 4 Blocks allocated...... 1,315 Distinct keys.......... 517,152 Avail in tree.....byte 10,477,868 Most repeated key...... 1 Used in tree......byte 9,856,219 Rows per key........... 1 ...................% 95 without del. rows..% 94

B*-tree branch blocks B*-tree leaf blocks Branch blocks......... 4 Leaf blocks........... 1,309

entries........ 1,308 entries........... 517,152 size.......byte 19,406 size..........byte 9,836,813 size/block.byte 8,012 size/block....byte 7,980

deleted........... 6del. size.....byte 114

Analyze Index Validate Structure >Storage QualityValidate Structure > Dialog

BackgroundDialog

Identifying a Fragmented Index

To analyze the fill level of an index, use the Tables and Indexes Monitor (transaction DB02) and choose Detailed analysis.

Indexes that have a fill level less than 50% should be reorganized if they are frequently accessed. To create or refresh the index statistics, choose Analyze index Validate structure Dialog or

Background.During the runtime of the Validate structure, the related table remains locked for changes.

For further information about detecting and recreating fragmented indexes refer to the article about Reorganization in SAP TechNet.

(C) SAP AG BC505 36

11.37

SAP AG 1999

Unit Summary

Now you are able to:

Define a strategy for refreshing the statistics used by the cost-based optimizer

Identify performance problems caused by the:

Cost-based optimizer

Memory configuration

Application design

Physical and logical layout

(C) SAP AG BC505 37

11.38

SAP AG 1999

Further Documentation

SAP TechNet

Communication SAP TechNet DB Admin. Oracle

SAPNet

Information SAP Solutions SAP R/3 Basis Technology System Management CCMS - Computer Center Management System Database Management

SAP Notes 109034, 127715, 128221

(C) SAP AG BC505 38

12

SAP AG 1999

Top 10 Problems

1 Database Overview 6 Advanced Backup Techniques

2 Backup Strategy and Tape Management

7 Storage Management

3 Scheduling, Performing,and Monitoring Backups

8 Performance Monitoring

4 Restore and Recovery 9 Top 10 Problems

5 Backup Strategies Using RMAN

(C) SAP AG BC505 1

12.2

SAP AG 1999

Top 10 Problems

Contents The most frequent problems that occur when R/3 is installed on

an Oracle database

ObjectivesAt the end of this unit, you will be able to: Recognize and solve these problems Prevent these problems from occurring

This unit explains the ten problems that most frequently occur when R/3 is installed on an Oracle database.

Once you have completed this unit you will be able to: Recognize and solve these problems Prevent many of these problems from occurring, before they become problem

(C) SAP AG BC505 2

12.3

SAP AG 1999

Run SAPDBA -checkRun SAPDBA -check

Check forerror messages

in:

Check forerror messages

in:

R/3 Syslog

SAP Note Search

Oracle background process trace files

in directory:saptrace/background

Oracle background process trace files

in directory:saptrace/background

Oracle user trace filesin directory:

saptrace/usertrace

Oracle user trace filesin directory:

saptrace/usertrace

R/3 startdb.login the home directory

of user <SID>adm

R/3 startdb.login the home directory

of user <SID>adm

Oracle alert log file:saptrace/background

/alert_<SID>.log

Oracle alert log file:saptrace/background

/alert_<SID>.log

Check SAPNetfor solutions

Troubleshooting Steps

When a problem occurs, run sapdba -check and check the log file in directory sapcheck. To begin troubleshooting, you can check the R/3 System log or the following Oracle files:

The Oracle alert log file ORACLE_HOME/saptrace/background/alert_<SID>.log, which often contains further information, such as the ORA-XXXX return code that may identify the problem

The Oracle background process trace files in directory saptrace/background The Oracle user trace files in directory saptrace/usertrace The startdb.log file in the home directory of user <SID>adm, which contains error information in

the case of database instance startup failure To check the R/3 System log, use transaction SM21. You should also search for related SAP Notes in SAPNet. If you cannot find an applicable SAP

Note, create a customer message in SAPNet, and provide the SAP hotline with the following information: Syslog messages and the short dump (transaction ST22) related to the error Error messages from the Oracle alert log file Error messages from the Oracle background process and user trace files Error messages from the file startdb.log Log files of SAPDBA or BR* tools

(C) SAP AG BC505 3

12.4

SAP AG 1999

The most frequently occurring problems are:

An archiver stuck situation

The incorrect tape size on tape drives with hardware compression

A missing "end backup"

A tablespace overflow

A table or index reaching the MAXEXTENTS limit

Oracle error ORA-1555, snapshot too old

Net8 TCP/IP delay

Oracle error ORA-1578, data block corruption

Oracle error ORA-600, internal database error

Poor performance of the cost-based optimizer

Top 10 Problems

The ten most frequent problems that occur when R/3 is installed on an Oracle database are: An archiver stuck situation The incorrect tape size on tape drives with hardware compression A missing “end backup” A tablespace overflow A table or index reaching its MAXEXTENTS limit ORA-1555, snapshot too old Net8 TCP/IP delay ORA-1578, data block corruption ORA-600, internal database error Poor performance of the cost-based optimizer

(C) SAP AG BC505 4

12.5

SAP AG 1999

SAPGUI is hangingDatabase in

ARCHIVELOG mode

Archiver stuck

Offline redo logdirectory saparch

Log fileswitches

Error

ORA-255 or ORA-272

DBMS

Online redo logs

Archiver Stuck Situation

The database of a production system should always be operated in ARCHIVELOG mode with an active Archiver process.

When the database is in ARCHIVELOG mode, an online redo log file can only be reused after it has been completely archived to the offline redo log archive directory saparch. If the directory saparch is full, the online redo log files cannot be completely archived, and the database will enter the archiver stuck state. This means that no further changes are possible to the system.

If this occurs, the Oracle error message ORA-255 or ORA-272 is written to the database alert log. The following is an example of the Oracle alert log file alert_<SID>.log:

Tue May 19 10:25:11 1998ORA-00255: error archiving log 11 of thread 1, sequence # 1337ORA-00312: online log 11 thread 1:'/oracle/TC1/origlogA/log_g11m1.dbf’ORA-00312: online log 11 thread 1: '/oracle/TC1/mirrlogA/log_g11m2.dbf’ORA-00334: archived log: '/oracle/TC1/saparch/TC1arch1_1337.dbf’ORA-19502: write error on file "/oracle/TC1/saparch/TC1arch1_1337.dbf"

When an archiver stuck situation occurs, the R/3 Systems hangs, and you cannot perform transactions until the online redo log file has been completely archived to directory saparch.

(C) SAP AG BC505 5

12.6

SAP AG 1999

Monitor directory saparch

Do not deleteor move

offline redolog files

Create a "dummy file" 5 times the size of an

online redo log file

Offline redo logdirectory saparch

Reserve three times the amount of the space required for the daily offline redo log files

DatabaseAdministration

log_archive_start = truein init<SID>.ora

Avoiding an Archiver Stuck Situation

To avoid an archiver stuck situation: Reserve some disk space by creating a “dummy file” in the archive directory saparch. Make the

size of the dummy file five times the size of the offline redo log file. If saparch becomes full, remove the dummy file and run BRARCHIVE immediately.

If BRARCHIVE is scheduled to run daily, ensure that saparch has enough disk space to hold at least three times the amount of the daily offline redo log files.

Monitor how full saparch is. Check the file init<SID>.ora to see if parameter log_archive_start = true. Check if user ora<SID> has write authorization to saparch.

Warning: Do not delete or move files from the archive directory saparch.

(C) SAP AG BC505 6

12.7

SAP AG 1999

cpio or dd error: end of tape

reached

Redefine the parameter tape_sizein file init<SID>.sap

Recalculate the compression ratio once per backup cycle

Redefine the parameter tape_sizein file init<SID>.sap

Recalculate the compression ratio once per backup cycle

Error

Incorrect Tape Size (Hardware Comp. Tape Drives)

The physical tape size (tape length * write density) is specified in the parameter tape_size in the file init<SID>.sap. The physical tape size is the total volume of data that can actually be written to a volume without compression (in MB or GB).

If parameter tape_size is configured too large, cpio or dd reaches the physical end of the tape. This causes severe problems when database restoration is required.

When using tape devices with hardware compression, always leave a reserve of approximately 200 MB to take account of any errors in the calculation of the compression rate.

When hardware compression is used, BRBACKUP does not receive any information about the compression ratios for the individual files. You can obtain this information from BRBACKUP by running a dummy compression. To do this, run command brbackup -compress|-k only . Recalculate the dummy compression ratios at least once per backup cycle, and after a lot of data change activity in the database, such as release upgrades and inserting large amounts of data.

To calculate the compression ratio, use the -b 12 option of the compression command for the corresponding init<SID>.sap parameter. For example, the compression command parameter should be defined as follows: compress_cmd = "compress -b 12 -c $ > $”.

See also SAP Note 8707.

(C) SAP AG BC505 7

12.8

SAP AG 1999

Online tablespace backupORA-1149 or

ORA-1113Missing "end backup"

Restoring data filesis not necessary

alter tablespace...begin backup

...in backup mode...

alter tablespace...end backup

Use the SAPDBA to: Check which tablespaces are

in Begin backup mode Shutdown the database for

error ORA-1149 Recover the database for

error ORA-1113

Error

Missing "end backup"

If you back up a tablespace online without RMAN, the tablespace must be in begin backup mode during the backup. This ensures that the Oracle data file headers of the data files belonging to the tablespace in the online backup mode are not updated.

If a tablespace is in begin backup mode and the command shutdown immediate is issued in SAPDBA, SAPDBA puts every tablespace into end backup mode before the database is shutdown.

If a tablespace remains in begin backup mode and the command shutdown immediate is issued in svrmgrl (or command stopsap db is issued), the database returns error ORA-1149 (missing end backup).

To check which tablespaces are still in begin backup mode, use SAPDBA and choose DB Check verification DB System Check. The system then prompts the user whether SAPDBA should set the end backup automatically.

If the database crashes during an online backup, or is powered down, or is shutdown by using shutdown abort, some tablespaces may remain in the begin backup mode. In this situation, because the tablespaces are in online backup mode when you try to open the database, error ORA-1113 is returned.

For ORA-1113, you must perform a database recovery. To perform the recovery, use SAPDBA and choose Partial restore and complete recovery database.

If a missing end backup error occurs, you do not need to restore any data files. The missing end backup error does not occur if the backup is performed with RMAN.

(C) SAP AG BC505 8

12.9

SAP AG 1999

<tablespace>.data2

New disk

Add data file

Tablespace

<tablespace>.data1

File size depends on the estimated increase in the tablespace objects

Gaps

Not enoughfree space for this extent

Data objects

Insertions

Tablespace

Perform a backup after every change in file structure

ORA-1653 or ORA-1654

Error

Tablespace Overflow

Extents

If an extent of a given size is required in a tablespace, but there is not enough contiguous freespace available in the tablespace, Oracle returns error ORA-1653 (for tables) or ORA-1654 (for indexes).

The error messages are displayed in both the Syslog file and the ABAP short dump. To solve this problem, use SAPDBA to extend the tablespace with one extra data file. From the

SAPDBA, choose Tablespace administration Alter tablespace Add Data file. If you extend several tablespaces, make sure that you place the data files on different disks, otherwise there may be problems with the I/O speed of disk access.

You must perform a backup after every change in the file structure.

(C) SAP AG BC505 9

12.10

SAP AG 1999

Adjust thenext extent?Check

300543210 . . . . . .

Object

Initialextent

Next extents

MaxExtents

. . .

. . .

ORA-1631 or ORA-1632

Error

Increase MaxExtents

by 50

+

Adjust thenext extent?

Monitor the number of extents regularly

Run sapdba -next weekly Adjust the MaxExtents

parameters

MaxExtents Limit is Reached

If the number of extents allocated to an object reaches the maximum number specified in the MaxExtents storage parameter, then this object cannot request any more extents. When this maximum value is reached, Oracle reports error ORA-1631 (for tables) and ORA-1632 (for indexes). The error messages are displayed in both the Syslog file and the ABAP short dump.

To avoid this problem: Monitor the number of extents regularly Run sapdba -next once a week Adjust the MaxExtents parameters as required

To change the values of the next parameter for tables and indexes, run sapdba -next. To change the values of the MaxExtents parameter for tables and indexes, use the SAPDBA and

choose Reorganization Alter/show table or index storage parameters Alter/show parameters. If the storage parameter MaxExtents is set to unlimited, the maximum number of extents is actually

2,147,483,645. Do not change MaxExtents to unlimited for all segments in your database. Do not set the MaxExtents

to unlimited on rollback segments.

(C) SAP AG BC505 10

12.11

SAP AG 1999

Update...

Data after update

SELECT... -> fetch

ENDSELECT

Long running query

SELECT...

Long processing time

1

Overwritten rollback segment

data

Update 3 records and commit

1

23

Tables

32

ORA-1555

1

Data before update

Rollback segments

Error

ORA-1555: Snapshot Too Old

Oracle enforces statement-level read consistency. This ensures that the data returned by a single query is consistent with respect to the time when the query began. Therefore, a query never sees the data changes made by transactions that commit during the course of execution of the query. Usually, a long running query has error ORA-1555 if the data accessed by the query is updated and committed by another user or session after the query has been started.

The most common reasons for error ORA-1555 (snapshot too old) are: A long running query due to a poorly qualified data access A high processing time between fetches of the same query Incorrect rollback segment setup

A long run query can cause some activities in the ABAP program loop to take too long, even if the SQL statement is correct. For example:SELECT ...Fetch (a long running activity) ENDSELECT

Before you try to change the number or size of the rollback segments, check if the problem is caused by expensive queries, such as inefficient application design, wrong index design, or insufficient cost-based optimizer statistics. You can adjust the rollback segment setup by adding more rollback segments or making them larger.

(C) SAP AG BC505 11

12.12

SAP AG 1999

tnsnames.orasqlnet.ora

listener.oraprotocol.ora

ORACLE_HOME/network/admin

Net8 Net8 TCP/IPTCP/IP Database server

Listener process

Shadow process

Shadow process

Shadow process

Shadow process

Wait for 200ms to fill the Net8 TCP/IP packets causing

poor performance

Net8 TCP/IP packet

tnsnames.orasqlnet.ora

protocol.ora

ORACLE_HOME/network/admin

Remoteapplication server

R/3 work processes

R/3 work processes

R/3 work processes

R/3 work processes

Delay

Net8 TCP/IP Delay

Net8 is the Oracle communication layer between the client (application servers) and the database server. Locally, it uses inter process communication (IPC); remotely, it uses TCP/IP.

When you configure Net8, you can choose to open the connection with delay or no-delay for TCP/IP. By default, Oracle opens the connection in delay mode, which allows the TCP/IP implementation on the operating system to delay sending half-empty TCP packets. The wait cycle is approximately 200ms, which slows down the communication speed in R/3.

To solve this problem, perform the following steps: Download the file protocol.ora from sapservX As user ora<SID>, copy this file into the ORACLE_HOME/network/admin directory of the

database server and every application server (even though TNS_ADMIN may point to a different directory)

Give read permission for file protocol.ora to users <SID>adm and ora<SID> Restart the Net8 listener on the database server Stop and start all the application servers.

For further information, see SAP Note 72638 (Unix) and SAP Note 132937 (Windows NT).

(C) SAP AG BC505 12

12.13

SAP AG 1999

Data fileSAP Note Search

BC-DB-ORAComponent

Search Criteria:

ORA-1578

- x

Oracleblock

ORA-1578

Extents

Error

ORA-1578: Data Block Corruption

Error ORA-1578 indicates a data block corruption. Data block corruption usually occurs because of a hardware error, and in most cases, remains undetected until the corrupted information is required.

For further information, see SAP Notes 13952 and 23345 or search for latest SAP Notes about error ORA-1578.

Once the hardware problem that caused the data block corruption has been solved, you may need to restore and recover parts of the database. If an index block is corrupted, you can drop and re-create the index.

When a normal backup is performed, a corrupted data block will remain undetected. To detect data block corruption early, perform a database verification at least once in your backup cycle.

To detect the corrupted data block, do one of the following: Use command brbackup -verify|-w only_dbv|use_dbv during a normal backup, or

use the SAPDBA and choose k - DB check/verification DB verification using DB VERIFY Use profile parameter disk_copy_cmd=rman to do the backup, because RMAN automatically does

a verify when it copies the blocks.

(C) SAP AG BC505 13

12.14

SAP AG 1999

saptrace/background

alert_<SID>.log

SAP Note Search

BC-DB-ORAComponent

Search Criteria:

ORA-600

12700

- x

Mon May 11 13:45:01 1998Errors in file /oracle/BIN/rdbms/log/ora_1207.trc:ORA-00600: internal error code, arguments: [12700],[2215], [1073777814], [4], [], [], [], []

Mon May 11 13:45:01 1998Errors in file /oracle/BIN/rdbms/log/ora_1207.trc:ORA-00600: internal error code, arguments: [12700],[2215], [1073777814], [4], [], [], [], []

Create Original Message x

BC-DB-ORAComponent

Short Text

Argument

ORA-600 detected

12700

-

ORA-600

Error

ORA-600: Internal Database Error

ORA-600 indicates an internal database error. Record the first argument of the ORA-600 error message. In this example, the first argument is

12700. Search for any SAP Notes related to ORA-600 and the first argument. If no SAP Notes correspond to the particular ORA-600 problem, create a customer message in

SAPNet, and attach the related trace files, alert_<SID>.log, and R/3 Syslog. Error ORA-600 is often followed by a state dump in the trace files. These trace files are found in

directory saptrace/background or saptrace/usertrace. The alert_<SID>.log is in the directory saptrace/background.

(C) SAP AG BC505 14

12.15

SAP AG 1999

Performance Memory StructureBackup/RecoveryAll database operations

All Performance operations ( )

Influence of the Cost-Based Optimizer

Old statistic information can cause serious performance

problems

The cost-based optimizer determines the most efficient access path based on analyzed statistics for tables and indexes. Outdated or incorrect statistics can cause severe performance problems.

To prevent the cost-based optimizer using an inefficient access path that could cause performance problems, you must update the statistics regularly.

In case of general performance problems, check whether the statistics are up-to-date first. To do this, display the DB Operation Monitor (transaction DB24) and choose Performance.

(C) SAP AG BC505 15

12.16

SAP AG 1999

Unit Summary

Now you are able to:

Recognize and prevent the problems that occur most frequently when R/3 is installed on an Oracle database

(C) SAP AG BC505 16

13

SAP AG 1999

Conclusion

1 Database Overview 6 Advanced Backup Techniques

2 Backup Strategy and Tape Management

7 Storage Management

3 Scheduling, Performing,and Monitoring Backups

8 Performance Monitoring

4 Restore and Recovery 9 Top 10 Problems

5 Backup Strategies Using RMAN

(C) SAP AG BC505 1

13.2

SAP AG 1999

You are now able to:

Define, perform and monitor an appropriate backup strategy

Monitor and administrate your R/3 Oracle system by using the

R/3 database monitors

Database administration tools offered by SAP

Identify performance problems by monitoring the R/3 System

Conclusion

(C) SAP AG BC505 2

13.3

SAP AG 1999

Technical Core Competence -Knowledge Product

Online Documentation

Notes in the application area BC-DB-ORA

SAP TechNet

SAPNet

Deltakiosk in the SAPNet

Further Documentation

(C) SAP AG BC505 3

13.4

SAP AG 1999

Menu Paths

Contents:

Appendix

(C) SAP AG BC505 4

13.5Frequently Used Menu PathsTrans-action

Title Menu Path

DB01 Analyze Exclusive Lockwaits Tools Administration Monitor Performance Database Exclusive lock waits

DB02 Analyze Tables and Indexes Tools CCMS Configuration Logon groups

DB03 Parameter Changes in Database

Tools Administration Monitor Performance Database Parameter Changes

DB12 DB Backup Monitor Tools CCMS DB Administration Backup logs

DB13 DBA Planning Calendar Tools CCMS DB Administration DBA Planning Calendar

DB16 DB System Check: Monitor Tools CCMS DB Administration DB System Check Display alerts

DB17 DB System Check: Configuration

Tools CCMS DB Administration DB System Check Configuration

DB21 DB Cost-Based Optimizer: Configuration

Tools CCMS DB Administration Cost-based optimizer Configuration.

DB24 Database Operations Monitor Tools CCMS DB Administration Operations monitor

RZ20 CCMS Monitoring Tools CCMS Control/Monitoring Alert monitor

SE12 ABAP/4 Dictionary Display Use transaction SE11

SE11 ABAP/4 Dictionary Display Tools ABAP Workbench Development ABAP Dictionary

SM21 Online System Log Analysis Tools Administration Monitor System log. Or: Test System log (from the ABAP/4 Development Workbench initial screen)

SM31 Maintain Table Views System Services Table maintenance Extended table maintenance

SM66 Systemwide Work Process Overview

Tools CCMS Control/Monitoring All work processes

ST04 Select DB Activities Tools Administration Monitor Performance Database Activity

ST06 Operating System Monitor From the Performance Monitoring screen: Operating system Local Activity

ST22 ABAP Dump Analysis Tools ABAP Workbench Test Workbench Dump Analysis

(C) SAP AG BC505 5

(C) SAP AG BC505 6