db2 recovery idug emea 2013

Click to edit Master title style

0

DB2 Recovery - what is inside this magic box.Dale McInnisIBM Canada Ltd.Session Code: D11Wednesday October 16, 11:00 – 12:00| Platform: DB2 on Linux, UNIX, and Windows


1

Agenda

• What recovery options are available• Walk through examples• How to decide which option to use• What other options are available• Overflow Bucket

1


2

What recovery options are available

• Backup and Restore• Process Model• Important files• Misc items

• Advanced Copy Services• Transportable Schemas

2


3

Backup Process Model

parallelism

Tablespace A

Tablespace C

Tablespace Bdb2med

db2med

db2med

db2agentdb2bm

db2bm

BackupBuffers

sessions

db2bm


4

Restore Process Model

parallelism

TablespaceA

TablespaceC

TablespaceBdb2med

db2med

db2med

db2agentdb2bm

db2bm


5

• Recovery History File - db2rhist.asc / db2rhist.bak:• Created during Create Database command• Updated by DB2 Utility execution:

• Back up database or table space• Restore database or table space• Roll forward database or table space• Load table• Reorg table• DB2 Log file archival• Create/Alter/Rename table space• Quiesce table spaces for table• Drop Table (optional)

• Included on each DB2 backup file• db2 LIST HISTORY command

• Log Control File – SQLOGCTL.(G)LFH.1:• Used during crash recovery• Disk updated at end of each Log File• Use softmax value < 100 (% of logfilsiz) to refresh pointers more often• Included at end of each DB2 backup

Database Directory

SQL0000n

Instance

NODE0000

db2rhist.asc

SQLOGCTL.(G)LFH.1SQLOGCTL.(G)LFH.2

DB2 recovery-related system files

db2rhist.bak


6

How can I make backup run faster?

• Let the DB tune the backup parameters automonically• Can compute everything except the # of sessions / target list

• Ensure you heap size is large enough (util_heap_sz 50000)

• If backing up to a file system create multiple objects• If the target device is a raid 5 file system creating multiple backup

objects will speed up the process• Backup db sample to /mydb/backup, /mydb/backup,

/mydb/backup, …• For TSM – open multiple sessions

6


7

What about backup compression?• Compression can be used in 4 different areas

1. Table compression• Row level compression in the database• 10.1 introduced adaptive compression

2. DB2 Backup compression • compressed while backing up• Requires additional CPU resources• Avoid is backup target is a data deduplication device

3. TSM Software compression (if you have TSM)4. Storage (ie. hardware) level compression

• Depends on your storage devices

• Recommendation:• Start with the following:

• If you have table compression, you may not see a huge benefit with using db2 backup compression as well.

• If you have storage level compression, then you do may not need to enable to TSM software compression.

• Test the combinations of compression types, to see what is the best fit, it will depend on the resource usage in your environment.

7


8

Backup and Recovery are DPF enabled

• Single System View(SSV) in DPF• Configuration

• Hierarchical in nature, can be overridden on a partition level• Backup

• Single command resulting in a single point of consistency across all partitions (DPF Aware Backup)

• db2 backup db foo on all dbpartitionnums• db2 backup db foo on dbpartitionnums (0, 30)• db2 backup db foo on all dbpartitionnums except dbpartitionnums

(10, 20)

• Logs in Backup is supported in DPF

• Rollforward to end of backup simplified:

• db2 rollforward db foo to end of backup and stop8


9

The RECOVER Command RECOVER command

Combines RESTORE and ROLLFORWARD into a single stepAutomatically determines which backup image(s) and log files to use

• Using information in Recovery History file• Even when multiple logs chains exists due to past recoveries to a point in time

•Recovery history file now keeps detailed information about log chains

Can recover a multi-partition database in a single command

Examples (each applies to single- and multi-partitioned databases)Recover a database to the end of logs from best available backup

Recover a database to a particular point in time• Note that default time specification is in local time (not GMT)

Recover a point in time not represented in current history file

RECOVER DB <dbname>

RECOVER DB <dbname> TO 2003-12-31-04.00.00

RECOVER DB <dbname> TO 1998-12-31-04.00.00USING HISTORY FILE (/home/user/fromimage/db2rhist.asc


10




10


11

• Flashcopy backup and restore a largely manual process:

• Backup 1. Identify LUN(s) associated with the database2. Identify free target LUN(s) for the copy3. Establish the flashcopy pair(s)4. Issue DB2 SUSPEND I/O command to tell DB2 to suspend write I/Os5. Issue storage commands necessary to do the actual flash copy6. Issue DB2 RESUME I/O command to return DB2 to normal

• Restore1. Restore/copy target LUN(s) containing backup of interest2. Issue DB2INIDB command to initialize the database for rollforward recovery3. Issue DB2 ROLL FORWARD command

No history file entry Error prone

DB2 Database

Source LUNs Target LUNs

Flash Copy

Target LUNs

Flash Copy

Review : Manual Flash Copy Backup


12

Review : Integrated ACS Copy Backup• Flashcopy backup/restore just like any other DB2 backup



DB2 Database


Flash Copy

Target LUNs

Flash Copy

DB2 BACKUP DB sample USE SNAPSHOT

DB2 RESTORE DB sample USE SNAPSHOT

DB2 ROLLFORWARD …

History file record Simple !Wide (but not exhaustive)

storage support


13

Scripted Interface for ACS Copy Backup• Flashcopy backup/restore just like any other DB2 backup



DB2 Database


Flash Copy

Target LUNs

Flash Copy

DB2 BACKUP DB sample USE SNAPSHOT SCRIPT‘/myscript.sh’

History file record Simple to use !Wider storage support

enabled

DB2 RESTORE DB sample USE SNAPSHOT SCRIPT‘/myscript.sh’ TAKEN AT <timestamp>

DB2 ROLLFORWARD …

10.510.5


14

Scripted Interface for Flash Copy Backup


15

Scripted interface for flash copy backup

• Available in DB2 10.5, DB2 9.7 FP 9 and DB2 10.1 FP3

• White Papers published or soon to be published• Introduction to the Scripted Interface • Implementation of the Scripted Interface for DB2 ACS Using

Linux LVM • Implementation of the Scripted Interface for DB2 ACS Using

IBM GPFS • Implementation of the Scripted Interface for DB2 ACS using

IBM DS4000 midrange storage system


16

ACS Differences between V 9.7 and V 10.1+

16

Feature V 9.7 V 10.1+

AIX Y(5.3 & 6.1) Y (6.1 & 7.1)

Linux Y RHEL 5 & SLES 10(nSeries/NetApp only)

Y RHEL 5&6 SLES 10&11 (all storage devices)

HPUX IA64 N Y

Solaris SPARC N Y

DS8K Y Y

XIV Y (Gen 2) Y (Gen 2 & 3)

SVC Y (2.1 – 4.3.1) Y (4.3.0 – 6.2)

ESS800 (shark) Y N

DS6K Y N

Storwize 7000 N Y

IBM N-Series Y Y (V 10.5)

NetApp Y Y (V 10.5)


17




17


18

Transportable SchemaProvide the illusion that we can restore any table space(s) into any database and the

recreate all of the logical objects based off of the physical objects in the table space(s).

Essentially Oracle’s Transportable Tablespaces feature on steroids (they only transport tables, indexes, views, RI constraints and triggers)

Interface will require the user to specify both the list of schemas to be transported as well as the list of table spaces (for now).

Restore will now do multiple operations• Restore the syscatspace and specified table spaces from the backup image• Roll them forward to a consistency point• Validate the schemas specified• Transfer ownership of the specified table spaces to the target DB• Recreate the schema in the targetDB


19

Transportable Schema con’tRestore command changes• Add “TRANSPORT INTO” option to identify this is a transport option• Add “Stage into” option to identify which staging DB to use and to not delete it once

the transport complete• Reuse the “TABLESPACE” option to identify which table spaces to transport• Add Schema list option to identify which schemas will be transported

• With this release ALL schemas in the supplied table space list must be specified• This is added for future extensibility, we do require the call to specify the set of

table spaces to transport. In the future we could drop the table space list parameter and determine it ourselves.


20

Transport Sets

tablespace4

schema4

tablespace6tablespace2 tablespace3 tablespace5tablespace1

schema3

schema5

schema1

schema2

works works works

doesn’t work


21

Example

Transport Schema 1 and Schema 2 to the target DB successfully• Restore the mydata1 and myindex1 table spaces into TARGETDB

db2 restore db originaldb tablespace (“mydata1”,”myindex1”) schema(“schema1”,”schema2”) transport into targetdb redirect

db2 set tablespace containers for 2 using (path '/targetdb/mydata1') db2 set tablespace containers for 3 using (path '/targetdb/myindex1’)db2 restore db originaldb continue

21


22

What will be transported• Tables / CGTTs / MQTs / ‘normal + stats’ Views• Generated columns

• Expression• Identity• Row change timestamp• Row change token

• UDFs / UDTs + generated functions• Constraints

• Check• Foreign key• Unique / primary• Functional dependency

• Indexes• Triggers • Sequences • Procedure – not external routine executable • Object authorizations / privileges / Security / Access control / Audit• Table Statistics + profiles / hints (plan lockdown) • Packages


23

What will NOT be transported

• Created Global variables• Aliases • Jobs• Index extensions• Hierarchical tables, typed tables, typed views• Nicknames• Structured types• methods• Servers• Wrappers• Functional mappings & templates• OLE DB External functions• sourced Procedures• XML - sysxmlstrings and sysxmlpaths collisions an issue

DPF and pureScale environments will not be supported


24

Agenda

• What recovery options are available• Walk through examples• How to decide which option to use• What other options are available• What is missing

24


25

ESE / PureScale Recovery

• Only a single copy of the database• Can exploit full, incremental or delta backups taken at

the DB or Table space level• Can use REBUILD option to restore to a new database

without recovering all of the data• Can restore only a subset of the data in the backup

image

25


26

Rebuild Partial Database Scenarios• Eliminate the need for FULL db backup• Ability to rebuild entire DB, including DPF, from set of table space backup images • Ability to bring only a portion of the DB online • Scans the history file to build the list of images to restore• Design for recovery speed NOT backup performance

26

Sun SunMon Tue Wed Thu Fri Sat

IncrDBSet1

IncrDBSet3

IncrDBSet5

Full DBMonthlyIncr

DBSet2

Full TSPWeekly

IncrDBSet4

IncrDBSet6


2727

Database Recovery using Rebuild• Necessary Table spaces will be restored automatically based on Recovery

History data

SalesDB

SMS01

BackupDatabase SALESDB

SYSCATSPACE

DMS01 DMS02

SUN MON TUE WED THU FRI SAT

BackupTS DMS01

BackupTS DMS02

BackupTS DMS01

DatabaseFails !

1. RESTORE DB SALESDB REBUILD WITH ALL TABLESPACES IN DATABASE TAKEN AT Friday(DB2 Restores Friday, Sunday and Thursday)

2. ROLLFORWARD DB SALESDB TO END OF LOGS AND STOP

Recovery History File

1

2

3


2828

Database Recovery - Rebuild from TS Backups• Database Recovery using multiple Table space backups

SalesDB

SMS01SYSCATSPACE

DMS01 DMS02


BackupTS SMS01SYSCATSPACE

BackupTS DMS02DMS01

BackupTS DMS01 Database

Fails !

1. RESTORE DB SALESDB REBUILD WITH ALL TABLESPACES IN DATABASE TAKEN AT Friday(DB2 Restores Friday, Tuesday and Thursday)



1

23

BackupTS DMS02DMS01


2929

Database Partial Copy using REBUILD• Can Create a Database copy with a subset of table spaces

SalesDB


SYSCATSPACE

DMS01


BackupTS DMS01

BackupTS DMS02

BackupTS DMS01

Copy for testing

1. RESTORE DB SALESDB REBUILD WITH TABLESPACE(SYSCATSPACE,DMS01) TAKEN AT Friday(DB2 Restores Friday, and Sunday (just SYSCATSPACE TS)

RESTORE DB SALESDB REBUILD WITH ALL TABLESPACES IN DATABASE EXCEPT TABLESPACE(SMS01,DMS02) TAKEN AT Friday


SalesDB

SYSCATSPACE

DMS01

SMS01

DMS02

1

2

OR


3030

Database Rebuild using one TS Backup image• Can Create a partial Database copy from one Table space Backup

SalesDB


SYSCATSPACE

DMS01


BackupTS DMS01

BackupTS DMS02

BackupTS DMS01SYSCATSPACE Copy for

testing

1. RESTORE DB SALESDB REBUILD WITH ALL TABLESPACES IN IMAGE TAKEN AT Friday


SalesDB

SYSCATSPACE

DMS01

SMS01

DMS02 1


3131

Table space point in time recovery using REBUILD• Can Restore Catalogs and Selected Table space to PIT

SalesDB


SYSCATSPACE

DMS01


BackupTS DMS01

BackupTS DMS02

BackupTS DMS01

1. RESTORE DB SALESDB REBUILD WITH TABLESPACE(SYSCATSPACE,DMS01) TAKEN AT Tuesday(DB2 Restores Tuesday, and Sunday (just SYSCATSPACE TS)

2. ROLLFORWARD DB SALESDB TO Tuesday AND STOP

SalesDB

SYSCATSPACE

DMS01

SMS01

DMS02

1

2

Tuesday


32

DPF Recovery

• Each partition contains • 1/nth of the data• Independent log stream• Can be recovered independently

• Minimal Recovery Time (MRT) is more complex to determine• When the "LIST TABLESPACES SHOW DETAIL" command or "GET SNAPSHOT FOR

TABLESPACES" command is executed, one of the attributes that may be displayed is the "Minimum recovery time".

• Only need to recover on the partitions that have been affected by the problem, which may be a subset of the partitions

32


33

Scenario for Backup:• Log archiving enabled, to TSM:

db2 update db cfg for salesdb using LOGARCHMETH1 TSM

• Incremental backupdb2 db2 update dbm cfg using TRACKMOD YES

• Online daily backup of the catalog partition:db2 -v "backup db salesdb on dbpartitionnums (0) online use tsm open 2 sessions util_impact_priority 33 include logs”

• Online partitioned tablespace backup – 2x per weekdb2 "backup db salesdb on dbpartitionnums (1,9) tablespace(pdts_in, pdts_ini) online use tsm open 2 sessions util_impact_priority 33 include logs“note: Rolling schedule – start with partitions (1,9), then (2,10), (3,11), (4,12)…(8,16)


34

Recovery Scenario 1: Catastrophic Failure – you lost your IO Subsystem – the entire database is lost!

• Yes, you can rebuild your entire database from all the tablespace backups!• Necessary Table spaces will be restored automatically based on Recovery

History data

SalesDB

SMS01


SYSCATSPACE

DMS01 DMS02


BackupTS DMS01

BackupTS DMS02

BackupTS DMS01

DatabaseFails !


1

2

3


35

Recovery Scenario 1: Database recovery to end of logs

• Use restore with the rebuild option:db2_all "db2 \"restore db salesdb rebuild with all tablespaces use tsmreplace existing”• Reads backup history file, and figures out which table space

backup images are needed and the corresponding logs• Issue rollforward:

db2 "rollforward db salesdb to end of logs and stop”


36

Recovery Scenario 2: Logical Corruption – something happened on Wednesday, you need to go back to Tuesday night.

• Database point in time recovery, using REBUILD• You can restore the database to a point in time, using your tablespace

images

SalesDB


SYSCATSPACE

DMS01


BackupTS DMS01

BackupTS DMS02

BackupTS DMS01

SalesDB

SYSCATSPACE

DMS01

SMS01

DMS02

1

2

Tuesday

SMS01

DMS02


37

Recovery Scenario 2: Logical Corruption - Database Recovery to Point in Time

• Use restore with the rebuild option:db2_all "db2 \"restore db salesdb rebuild with all tablespaces use tsmreplace existing”• Reads backup history file, and figures out which tablespace backup

images are needed and the corresponding logs• Issue rollforward:

db2 "rollforward db salesdb to <timestamp>”

• Must recover all database partitions to the same point in time


38

Recovery Scenario #3: Logical Corruption: User Error on Wednesday, only affects a single table space.

• Table space point in time recovery using REBUILD• Can Restore Catalogs and Selected Table space to point in time.• Need to understand MRT – Minimum Recovery Time

SalesDB


SYSCATSPACE

DMS01


BackupTS DMS01

BackupTS DMS02

BackupTS DMS01

SalesDB

DMS01

SMS01

DMS02

1

2

Tuesday

SMS01

DMS02

SYSCATSPACE

DMSO1 is logically corrupt


39

Recovery Scenario #3: Logical Corruption: User Error on Wednesday, only affects a single table space.

• A single tablespace needs to restored• From the catalog node:

• Start restore: db2_all “db2 \"restore db salesdb into tempDB rebuild with tablespace(syscatspace, dms01) use tsm taken at <tuesday date> replace existing

• Rollforward:db2 "rollforward db tempdb to <point in time> and stop tablespace(syscatspace, dms01)“

• Export the data and reload it into SALESDB


40

Recovery Scenario 4: A single disk fails, so data is corrupted only on a single logical partition.

• Partition Level Recovery To End of Logs• Necessary table partition will be restored automatically based on Recovery

History data

SalesDB

SMS01


SYSCATSPACE

DMS01 DMS02


BackupTS DMS01

BackupTS DMS02

BackupTS DMS01

DatabaseFails !


1

2

3


41

Recovery Scenario 4: A single disk fails, so data is corrupted only on a single logical partition.

• A single logical partition is corrupted (disk failure!)• The example, db partition 3 is corrupted• From the catalog node:

• Start restore: db2_all "<<+3<db2 \"restore db salesdb tablespace (dms01, dms02) online use tsm taken at 20100401143616 replace existing

• Check status:db2 rollforward db salesdb query statusResult:3 TBS pending S0000000.LOG-S0000003.LOG 2010-03-29-07.42.44.000000 Localnote: only partition 3 was restored, so only partition 3 needs to be rolled forward

• Rollforward:db2 "rollforward db salesdb to end of logs on dbpartitionnum (3) tablespace (dms01, dms02) online"


42

Agenda


42


43

Setting your goals

• RPO – recovery point objective• RTO – recovery time objective• Two goals:

• Ensure you can recover the data you need• Minimal impact to running queries - balance your backup process

across partitions

43


4444

Typical Low End Recovery Strategy

• Typically have a maintenance windows nightly

• Perform full offline DB backups every other nightly

• May or may not have a recoverable database• Typically archive logs to a disk• Purge log files automatically after 1 week

• Keep 3 generation of backups


454545

Sample Low End Backup Schedule

• Full DB backup 3-4 times a week• Retain 3 – 5 copies of the entire database


Full DB

Full DB

Full DB

Full DB


46

Typical Mid Range Configuration

• Small number of SMPs 4-16 CPUs• Fibre attached storage• Backup to tape drives over the LAN• Storage Manager (TSM) to manager tape

devices• Small tape library• Mid size database, tens or hundreds of

gigabytes in size

IBM

IBM

DB2 Server Environment

TSM Server and Tape Library

CPU

CPU Tape

Disk Storage


4747

Typical Mid Range Recovery Strategy

• Typically have a maintenance windows weekly

• Perform full offline DB backups on week-end

• May perform table space level backups nightly

• Typically have a recoverable database• Either archive logs to disk or directly to storage manager• If archiving to disk, must purge log files after set period of time

• Keep 3-5 generation of backups with associated log files


484848

Sample Mid Range Backup Schedule

• Full DB backup monthly – for long term retension• Full Tablespace images on the week-end

• Rotating through the entire set over the period of a month• Nightly table space incremental backups

• Rotating through the entire set of table spaces in a week


Full DB

IncrDBSet1

IncrDBSet2

IncrDBSet3

Full DB


49

Typical High End Configuration

• Multiple SMP servers • SAN attached storage on

intelligent drives • Exploit Storage “flash copy”

capabilities• Lan-Free backup from Flash

Copy• Tape library manager • Large database, terabytes in size

IBM

IB M

DB2 Server Environment

TSM Server Environment

CPU Disk Storage

Tape Library

CPU


5050

Typical High End Recovery Strategy

• Typically have no maintenance windows

• Perform full offline DB backups monthly if possible

• Will perform table space level backups nightly• May use incremental backup nightly and full table space on week-ends

• Typically have a recoverable database• Archive logs directly to storage manage

• Keep 3-5 generation of backups with associated log files


515151

Sample High End Backup Schedule

• Full DB backup monthly – for long term retension• Full Tablespace images on the week-end

• Rotating through the entire set over the period of a month• Nightly table space incremental backups

• Rotating through the entire set of table spaces in a week


IncrDBSet1

IncrDBSet3

IncrDBSet5

Full DBMonthlyIncr

DBSet2

Full TSPWeekly

IncrDBSet4

IncrDBSet6


52

Protecting yourself from logical corruption

• Application erroneous updates, inserts, deletions• Dropped table(s)• Deleted row(s)• Dropped table space(s)

52


53

Methods to recover from logical corruptionUtilize DB2 Backup images

• Recovery affected table space(s) and roll forward to a point in time (PIT)

• Must rollforward past last DDL statement or must also recovery the system catalog table space

• Pros• Utilizes existing backups, can also use snapshot backups

• Cons• Level of granularity is DB• Slow recovery if using traditional DB2 backup image• Complete DB outage while recovery is in progress• All transactions after the PIT must be manually reapplied

53


54

Methods to recover from logical corruptionObject level recovery via Staging DB

• Create a staging DB utilizing the “rebuild” option to restore all affected table spaces into a new DB OR use transportable tablespace into a staging DB

• Rollforward to a PIT before the erroneous operation• Can use load from cursor between source and staging DB to

recovery the affected objects• Pros

• Does not affect availability of source DB

• Cons• Requires space for the staging DB

54


55

Methods to recover from logical corruption - Object level recovery via High Performance Unload

• Pros• Utilizes existing DB2 backups to extract objects• Only targeted objects are affected

• Cons• Unable to reapply log files generated after the backup• Must reapply transactions manually

55


56

Agenda


56


57

What other options are available

• Storage based replication• Logical Replication• HADR

57


58

Pros:• Very fast local failover with DR ability as well• Protection from software, server, storage or site failure• Failover time in the range of 30 sec or less localCons:• Failover time to DR site can be in the order of tens of minutes• Must ensure all file systems required are replication

Local Cluster With Disk Mirroring to remote DR site

Primary Connection

Primary Database

DR Site

DB1’Remote Disk Mirror Technology

DB1

HA Cluster

Integration with HACMP, TSA, MSCS, Sun, Veritas, Heartbeat, etc


59

• Used for any change data capture need • High Availability and Disaster Recovery• Offload query and reporting workloads• Warehousing• Master data systems (MDM, etc)• Information Server (for DataStage, etc)

• Three technologies available • Q Replication• SQL Replication• CDC Replication

• Q Replication • High performance• High availability

IBM InfoSphere Data Replication (IIDR)

IDRR

InformationServer Warehouse

MDM

DB2

Cognos


60

DB 3

Logical Replication

Primary Connection

Multiple alternate standby servers

Site ASite B

DB1

Primary Database

Q based SQL replication to logical standby’s

DB 2

Remote Standby

Site C…

Read and / or write on standby

Pros:• Protection from software, server, storage or site failure• Failover time is “instant”• Standby can be full or subset and is full accessible (read and/or write)• Multiple standby serversCons:• More complex to setup and monitor (more flexibility) compared to HADR• Async


61

HADR Architecture

61

LogsOld

Logs

Log Writer Log Reader

Tables

IndexesLogs

Old

Logs

Log Reader

Tables

Indexes

TCPIP

DB2 Engine DB2 EnginePRIMARY SERVER STANDBY SERVER

Log Writer

HADR Shredder Replay Master

Redo SlavesRedo SlavesRedo SlavesReplay Slaves

Log Pages

Log Pages

Log Pages

Log RecordsLog Pages

Log

Records

61

HADR


62

Agenda

• What recovery options are available• Walk through examples• How to decide which option to use• What other options are available• Overflow bucket

62


63

Integrated backup support for data deduplication

• Native support for all deduplication devices• Both IBM and non-IBM devices

• Alters the format the backup image to be dedup friendly

• Starting with V 9.7 FP3

63


64

Data Deduplication Concept

A

B

C

D

B

E

FDataSource 1

C

G

E

H

I

J

KDataSource 2

J

H

L

B

K

C

EDataSource 3

D I B J

F H G E

C A L K

Unique blocks

Duplicate blocks

Target data store


65

Default backup physical format

65

Tablespace 1 Tablespace 2 Tablespace 3

Backup image output stream 1



DB2 backup db mydb use TSM open 3 sessions


66

Dedup backup physical format

66

Tablespace 1 Tablespace 2 Tablespace 3




DB2 backup db mydb use TSM open 3 sessions dedup_device


67

TSM Client Deduplication Results

67

Start End Elapsed Time Actual DB Size in bytes

Dedup Size sent to server in bytes

% Savings in bandwidth

12:22:57 AM 2:32:54 AM 2:09 1.35891E+11 1.3574E+11 0.11%

2:33:02 AM 3:04:13 AM 0:31 1.35891E+11 3501526595 97.42%

3:04:19 AM 3:34:07 AM 0:29 1.35891E+11 1439490051 98.94%

3:34:13 AM 4:03:14 AM 0:29 1.35891E+11 875452538 99.36%

4:03:20 AM 4:32:45 AM 0:29 1.35891E+11 1015678830 99.25%

Command:DB2 backup db PERF use TSM open 8 sessions dedup_deviceSettings:Util_heap_sz =50000Autonomic performance settings:Backup Buffer Size = 2465Backup # of buffers = 18Backup Parallelism = 8


68

TSM Client Deduplication Results

68

Command:DB2 backup db PERF use TSM open 8 sessions dedup_deviceSettings:Util_heap_sz = 300000Autonomic performance settings:Backup Buffer Size = 16384Backup # of buffers = 18Backup Parallelism = 8

Start End Elapsed Time Actual DB Size in bytes

Dedup Size sent to server in bytes

% Savings in bandwidth

10:22:00 PM 1:53:47 AM 3:31 1.36499E+11 1.35729E+11 0.56%1:53:55 AM 2:22:30 AM 0:28 1.36499E+11 1248387123 99.09%2:22:26 AM 2:49:39 AM 0:27 1.36499E+11 352043759 99.74%2:49:44 AM 3:17:12 AM 0:27 1.36499E+11 175945343 99.87%3:17:18 AM 3:45:32 AM 0:28 1.36499E+11 129529760 99.91%


69

AUTO_DEL_REC_OBJ : Automatic Life Cycle Mgmt• A new database configuration parameter that controls whether

the underlying logs, backups and other associated objects aredeleted when the history file is pruned

• AUTO_DEL_REC_OBJ • OFF (default, existing behavior)• ON

• When does this automatic deletion occur ?• After a successful backup• On an explicit PRUNE HISTORY AND DELETE command

• What is deleted ?• Any full database backup images which exceed both NUM_DB_BACKUPS

and REC_HIS_RETENTN db cfg parameters will be deleted• Any associated incremental backup images, load copy images, table

space backup images or log files will be deleted69


70

Best Practices – Your database design

• Leverage intelligent database design practices! • All referential tables are in the same table space, or set of table spaces.• All staging tables (for load) are in a separate table space • Active vs. In-active data – separated by table space

• Range partitioning – further identify active vs. inactive by designing ranges• Local vs. Global Indexes – if you have global indexes (ie. Prior to v9.7),

then keep those in a table space that you back up with it’s matching data table space. Rebuilding your indexes can be time consuming!

• Goal: you want to be set up to restore only what you need.

70


71

Best Practices: Backup recommendations

• Backup Images:• Online database backups • Online table space backups• Incremental backups• Compression is good *

• Use the Single System View option (v9.5 +). Let DB2 manage the backups and timestamps for you.

• Always use lan-free option to write to tape drives directly via SAN• DO NOT archive directly to tape!• configure FAILARCHPATH in case primary-log-destination becomes

unavailable• Include the log records in each backup image – it’s easier that way!• Operating System files backed up twice per week

71


72

Best Practices: Backup recommendations cont’d• Example:

• Full online table space backup of hot* and warm table spaces twice a week, include logs

• Full online database backup of catalog partition daily, logs included• Full online database backup of database partitions on quarterly or

monthly basis• Full table space backup after adding a new table space

72


73

Best Practices - Logging

• Use archive logging – not circular logs for your production environment

• Goal: ease of maintenance• Include logs in your backup image• Use TSM to handle your archiving for you

• Small transaction logs:• Reduce risk since logs contain fewer transactions• Increases the number of logs required, since large transactions

may span multiple log files, plus more overhead in system resources.

• Large transaction logs:• Increase risk since logs contain more transactions• Benefit: reduces the amount of system resources used, as less log

switching takes place• Recommendation: Start with 50 primary logs, of about 50MB each.

73


74

Best Practices - Recovery recommendations

• For table space recovery, use the restore command with the REBUILD option• Use the REBUILD option (v9.5) to get the subset of the system you

need up and running immediately• Use the log manager, not user exits• Use db2adutl to retrieve log files from tape to disk – keep ahead

of the log files you need .

74


75

Backup and Recovery • If a DB2 online backup is not feasible due to conflicts with other

utilities then consider SNAPSHOTS in DB2 9.5OR• IBM Tivoli Storage Manager for Advanced Copy Services For DB2

• http://www.ibm.com/developerworks/tivoli/library/t-acsdb2_1/index.html

• When using TSM always use Lan-Free option• Review SAP 20 TB BI Benchmark Results

• Full backup in < 7 hours• http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/W

P101012

• Best Practices for backup and recovery in ISAS• http://www.ibm.com/developerworks/data/bestpractices/isasrecov

ery/index.html

75


76

More Information

• DB2 LUW Best Practices:https://www.ibm.com/developerworks/data/bestpractices

• Best Practices: Building a Recovery Strategy for an IBM Smart Analytics System Databasehttp://www.ibm.com/developerworks/data/bestpractices/isasrecovery/index.html

• Best Practices: Multi-Temperature Data Managementhttp://www.ibm.com/developerworks/data/bestpractices/multitemperature/index.html

• Article: DB2 instance recovery for IBM Smart Analytics Systemhttp://www.ibm.com/developerworks/data/library/techarticle/dm-1010db2instancerecovery/index.html?ca=drs-


77

Thank You

MerciGrazie

GraciasObrigado

Danke

Japanese

French

Russian

GermanItalian

Spanish

Brazilian Portuguese

Arabic

Traditional Chinese

Simplified Chinese

Hindi

Tamil

Thai

Korean


78

Dale McInnisIBM Canada [email protected]: D11DB2 Recovery - what is inside this magic box.

db2 recovery idug emea 2013

Technology

db2 backup compression

backup target

backup images

backup run

backup parameters

multiple backup objects

process backup db sample

database command