IBM DB2 for SAP 环境备份与恢复实战指南

5星 · 超过95%的资源需积分: 10 59 浏览量更新于2024-07-31 收藏 1.8MB PDF 举报

"这篇文档是关于在SAP环境中DB2 LUW（Linux、UNIX和Windows版）数据库备份与恢复的实用指南，版本1.4，由IBM SAP DB2卓越中心编写，作者包括Olaf Depper、Edgardo G. Koenig、Hans-Jürgen Moldowan和Thomas Rech。" 在SAP系统中，数据库是业务的核心，存储着所有关键的业务数据和执行应用服务器的代码。因此，确保有一个高效且安全的数据库备份和恢复策略至关重要。这份文档的目的是提供对SAP系统中基于DB2 for Linux, UNIX, and Windows的数据库备份和恢复过程的深入理解。文档首先概述了备份和恢复的基本概念，强调了为何需要详细掌握这些流程。它将作为一系列文档的一部分，旨在涵盖与IBM DB2与SAP NetWeaver应用程序相关的备份和恢复关键主题。这个系列的目标是平衡快速入门和高级主题，以满足不同层次读者的需求。在DB2 LUW的备份与恢复过程中，可能会涉及以下几个关键技术点： 1. **全量备份**：这是最基本的备份类型，涉及复制整个数据库到一个或多个备份文件中，通常在数据库关闭时进行，以确保一致性。 2. **增量备份**：仅备份自上次全量或增量备份以来发生变化的数据，可以显著减少备份所需的时间和存储空间。 3. **日志备份**：备份数据库的日志文件，用于在恢复时重播事务，以达到一致性的状态。 4. **热备份**：在数据库运行时进行的备份，需要特定的数据库支持，以确保备份的完整性和一致性。 5. **冷备份**：在数据库关闭状态下进行的备份，更适用于非关键业务系统或维护窗口期间。 6. **快照备份**：某些操作系统和存储解决方案提供的功能，可以创建数据库的即时副本。 7. **恢复计划**：定义了在数据丢失或系统故障后的恢复步骤，包括确定恢复点目标（RPO）和恢复时间目标（RTO）。 8. **备份策略**：包括备份频率、保留期限和备份介质管理，需要根据业务需求和风险评估来定制。 9. **测试恢复**：定期进行恢复演练以验证备份的有效性，并确保在真实情况下的恢复能力。 10. **归档和存储**：备份数据的安全存储和管理，包括使用磁带库、网络附加存储(NAS)、云存储等。 11. **备份工具**：如IBM Tivoli Storage Manager (TSM)等，帮助自动化备份过程并简化管理。 12. **灾难恢复计划**：详述在重大故障或灾难事件中恢复整个SAP环境的步骤。了解和实施这些技术点对于保障SAP系统的持续运行和数据安全性至关重要。通过深入学习本系列文档，读者能够构建和优化适应其特定环境的DB2备份和恢复策略。

DB2 for Linux, UNIX and Windows Backup and Recovery – Introduction

setting either both or one of the configuration parameters LOGARCHMETH1 and LOGARCHMETH2

to a value other than OFF.

For a recoverable database, the DB2 engine archives a log file as soon as it is full or explicitly

archived. However, this log file might still contain information that could be required for crash recovery.

Therefore, the log file stays in the log directory as long as it is required for a crash recovery. From a

DB2 database point of view, these log files are considered to be ‘active’.

Once a log file has been archived successfully by the DB2 log manager and it does not contain any

open transactions (and is therefore not required any more for a crash recovery), the log file is

considered to be ‘archived’. Archived log files are usually not deleted by the database. Instead, when

a new log file is required, the DB2 database will rename the oldest archived log file and use it again.

The DB2 database will rename a log file instead of allocating a new file to reduce I/O operations.

Archived logs are not renamed immediately once they have been copied to the archive. For that

reason it is common to see old log files in the log directory when no new active log files are required.

Note: You should never move log files from the log directory manually while the database is online.

The DB2 system automatically allocates and removes of log files. If you delete an active log file, the

DB2 instance shuts down the database. The database cannot be restarted anymore and has to be

restored.

The following figure provides an (incomplete) overview of the DB2 logging mechanism with the log

manager (db2logmgr) as the core database engine component.

Figure 1-3: The DB2 Log Manager

The DB2 engine writes and reads from the log files located in the log directory of the database. Once

a log file is full, the DB2 log manager process (db2logmgr) controls the archive process of the log file

to the different possible locations. In case that a tape drive is defined as the archive target location, an

additional DB2 process, the DB2 tape manager (db2tapemgr), is spawned. The DB2 log manager

stores information about all archive operations in the history file of the database. It is possible to define

a fail over archive location that is used in case the standard archive location is temporarily unavailable.

If the database engine requires access to an archived log file, for example, as part of a recovery, the

DB2 log manager retrieves the log files from the archive location.

For more details on how to configure the DB2 logging, see chapter 2 “Log File Management – Details”.

DB2 for Linux, UNIX and Windows Backup and Recovery – Introduction

1.3 Backup Architecture

The DB2 backup utility reads the content of table spaces and writes this data to the backup media.

The utility does not copy complete table spaces or, to be more precise, the table space container files

to the backup media. Instead, the backup utility saves the content of table spaces. In addition to the

table space data, a DB2 backup automatically saves all the configuration files that are located in the

database directory as part of the backup image. The log files that are required to recover the database

to the earliest consistent point can also be included in the backup image. By default, log files are

included in online backups as of DB2 Version 9.5 and higher.

A DB2 backup command, for example, ‘BACKUP DB WGN ONLINE USE TSM’ reads the pages out of

the table spaces and sends them to the defined target, in our example IBM Tivoli

Storage Manager.

The command also saves the database configuration files and the log files that are required to recover

the database.

Besides Tivoli Storage Manager, the DB2 database system supports backups to disk and tape. In

addition, the DB2 backup utility provides interfaces that are used by vendor backup solutions like EMC

NetWorker

or HP OpenView Storage Data Protector

. For example, the DB2 command ‘BACKUP DB

WGN LOAD <vendor library>’ reads the pages out of the table spaces and sends them to the vendor

library together with the database configuration files. Since in this case the backup is an offline

backup, no log files are included in the backup image.

A special option of the DB2 BACKUP command is to use the ‘SNAPSHOT’ keyword. In this case, the

DB2 backup utility uses storage capabilities to create a backup image on disk level. The default

behavior for a snapshot backup is an offline database backup of all database paths, for example, all

table space containers, the database path, and the log paths. Although this is an offline backup, the

log files are included in this case. Unlike the other backup target options, this offline backup does not

read the data out of the table spaces. Instead disk images are created.

Since a snapshot backup differs somehow from the ‘classic’ backup to tape, disk or another backup

solution it will not be covered in this paper. For more information about snapshot backups in an SAP

environment, see the Whitepaper “Setup and Configuration of the DB2 Snapshot Backup with IBM N-

Series Storage” available in the SAP Developer Network at:

http://sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/0019590b-658d-2b10-24bd-9c6882b2b009

Getting back to the type of backups covered in this paper, some more details about the process model

of a backup and its main influencing factors need to be described. You can call the backup command

with several parameters that specify, for example, the number and size of buffers, the degree of

parallelism, the number of sessions to open and whether the backup image should be compressed or

not. These parameters are described in chapter 3 “Backup and Recovery – Details”. For now we

concentrate on some parameters that are important to understand the backup concept.

The following picture describes the data flow and the participating components when you perform a

DB2 backup.

剩余39页未读，继续阅读

swj_1120

粉丝: 1
资源: 9

IBM DB2 for SAP 环境备份与恢复实战指南

High Availability and Disaster Recovery Options for DB2 on LUW

DB2_Best Practices Guide_for Day-to-Day_Database Backup and Recovery Operations

DB2 LUW to UDB400 v3

The Latest in Advanced Performance Diagnostics for DB2 LUW

The DB2Night Show #216 Db2 LUW Problem Determination Class

IBM InfoSphere CDC for DB2 LUW 中文文档

DB2 9 for LUW Advanced Performance and Tuning

IBM Optim PerformanceManager for DB2 for LUW

DB2 for LUW Advanced Database Administration for Experts

LUW DB2 v11新特性

最新资源