Db2 recovery IDUG EMEA 2013

Click to edit Master title style

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

0


Agenda
•
•
•
•
•

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

1


• Backup and Restore
• Process Model
• Important files
• Misc items
• Advanced Copy Services
• Transportable Schemas

2


Backup Process Model
Tablespace A
db2bm

db2agent
db2med

Tablespace B
db2bm

db2med

Backup
Buffers

Tablespace C

db2med

db2bm

parallelism

sessions

3


Restore Process Model
TablespaceA
db2bm

db2med

TablespaceB

parallelism

TablespaceC

db2agent

db2med

db2med
db2bm

4


DB2 recovery-related system files
• 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:
•
•
•
•

Database Directory
Instance

NODE0000
SQL0000n

db2rhist.asc
db2rhist.bak
SQLOGCTL.(G)LFH.1
SQLOGCTL.(G)LFH.2

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

5


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


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
•

•

Recommendation:
•

Start with the following:
•
•

•

Depends on your storage devices

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


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 stop
8


The RECOVER Command
 RECOVER command
Combines RESTORE and ROLLFORWARD into a single step
Automatically 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 DB <dbname>
Recover a database to a particular point in time
• Note that default time specification is in local time (not GMT)
RECOVER DB <dbname>

TO 2003-12-31-04.00.00

Recover a point in time not represented in current history file
RECOVER DB <dbname> TO 1998-12-31-04.00.00
USING HISTORY FILE (/home/user/fromimage/db2rhist.asc
9


• Process Model
• Important files
• Misc items

10


Review : Manual Flash Copy Backup
•

Flashcopy backup and restore a largely manual process:

•

Backup
1.
2.
3.
4.
5.
6.

•

Identify LUN(s) associated with the database
Identify free target LUN(s) for the copy
Establish the flashcopy pair(s)
Issue DB2 SUSPEND I/O command to tell DB2 to suspend write I/Os
Issue storage commands necessary to do the actual flash copy
Issue DB2 RESUME I/O command to return DB2 to normal

Restore
1.
2.
3.

Restore/copy target LUN(s) containing backup of interest
Issue DB2INIDB command to initialize the database for rollforward recovery
Issue DB2 ROLL FORWARD command

 No history file entry
 Error prone

DB2 Database
Flash Copy
Source LUNs

Target LUNs
11


Review : Integrated ACS Copy Backup
•

Flashcopy backup/restore just like any other DB2 backup

•

Backup
1.
2.
3.
4.
5.
6.

Identify LUN(s) associated with the database
DB2 BACKUP DB sample
Identify free target LUN(s) for the copy USE SNAPSHOT

DB2 RESTORE DB sample USE SNAPSHOT
• Restore
1. Restore/copy target LUN(s) containing backup of interest
DB2 ROLLFORWARD …
2.
3.


DB2 Database
Flash Copy
Source LUNs

Target LUNs

 History file record
 Simple !
 Wide (but not exhaustive)
storage support
12

10.5


Scripted Interface for ACS Copy Backup
•

Flashcopy backup/restore just like any other DB2 backup

•

Backup
1.
2.
3.
4.
5.
6.

•

Identify LUN(s) associatedDB sample USE SNAPSHOT SCRIPT
DB2 BACKUP with the database
Identify free target LUN(s) for the copy
‘/myscript.sh’

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

1.
2.
3.

Restore/copy target LUN(s) containing backup of interest
DB2 ROLLFORWARD …

DB2 Database
Flash Copy
Source LUNs

Target LUNs

 History file record
 Simple to use !
 Wider storage support
enabled
13


Scripted Interface for Flash Copy Backup

14


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
15


ACS Differences between V 9.7 and V 10.1+
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)

16


• Process Model
• Important files
• Misc items

17


Transportable Schema
Provide 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

18


Transportable Schema con’t
Restore 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.

19


Transport Sets
doesn’t work

tablespace1

tablespace2

schema1

schema3

tablespace3

tablespace4

tablespace6

schema4

schema2
works

tablespace5

schema5
works

works

20


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


What will be transported
•
•

Tables / CGTTs / MQTs / ‘normal + stats’ Views
Generated columns
•
•
•
•

•
•

UDFs / UDTs + generated functions
Constraints
•
•
•
•

•
•
•
•
•
•
•

Expression
Identity
Row change timestamp
Row change token

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
22


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
23


Agenda
•
•
•
•
•

What is missing

24


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


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

Sun

Mon

Tue

Wed

Thu

Fri

Sat

Full TSP
Weekly

Incr
DB
Set1

Incr
DB
Set2

Incr
DB
Set3

Incr
DB
Set4

Incr
DB
Set5

Incr
DB
Set6

Sun

Full DB
Monthly

26
26


Database Recovery using Rebuild
•

Necessary Table spaces will be restored automatically based on Recovery
History data
Recovery
History File

SalesDB
SYSCATSPACE

2

SMS01
DMS01

3

Backup
Database
SALESDB

SUN

Backup
TS DMS01

MON

TUE

Backup
TS DMS02

WED

THU

DMS02

1
Backup
TS DMS01

FRI

Database
Fails !
SAT

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

27
27


Database Recovery - Rebuild from TS Backups
•

Database Recovery using multiple Table space backups
Recovery
History File

SalesDB
SYSCATSPACE

2

Backup
TS DMS02
DMS01

SUN

3

TUE

DMS01

DMS02

1

Backup
TS SMS01
SYSCATSPACE

MON

SMS01

Backup
TS DMS02
DMS01

WED

THU

Backup
TS DMS01

FRI

Database
Fails !
SAT

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

28
28


Database Partial Copy using REBUILD
•

Can Create a Database copy with a subset of table spaces
SalesDB

SalesDB
SYSCATSPACE

2

DMS01

1.

OR

DMS01

DMS02

1

Backup
Database
SALESDB

SUN

SYSCATSPACE

SMS01

Backup
TS DMS01

MON

TUE

Backup
TS DMS02

WED

THU

Backup
TS DMS01

FRI

Copy for
testing
SAT

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

29
29


Database Rebuild using one TS Backup image
•

Can Create a partial Database copy from one Table space Backup
SalesDB

SalesDB
SYSCATSPACE

DMS01
Backup
Database
SALESDB

SUN

SYSCATSPACE

SMS01
DMS02

DMS01

1
Backup

Backup
TS DMS01

MON

TUE

TS DMS01
SYSCATSPACE

Backup
TS DMS02

WED

THU

FRI

Copy for
testing
SAT

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

30
30


Table space point in time recovery using REBUILD
•

Can Restore Catalogs and Selected Table space to PIT
SalesDB

SalesDB
SYSCATSPACE

2

SMS01
DMS01

1.

Tuesday
DMS01

DMS02

1

Backup
Database
SALESDB

SUN

SYSCATSPACE

Backup
TS DMS01

MON

TUE

Backup
TS DMS02

WED

THU

Backup
TS DMS01

FRI

SAT

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

31
31


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


Scenario for Backup:
• Log archiving enabled, to TSM:
db2 update db cfg for salesdb using LOGARCHMETH1 TSM

• Incremental backup
db2 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 week
db2 "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)

33


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
Recovery
History File

SalesDB
SYSCATSPACE

DMS01

Backup
Database
SALESDB

3
Backup
TS DMS01

2

SUN

SMS01

MON

TUE

Backup
TS DMS02

WED

THU

DMS02

1
Backup
TS DMS01

FRI

Database
Fails !
SAT

34


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 tsm
replace 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”

35


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
Tuesday
SalesDB

SalesDB
SYSCATSPACE

2

DMS01

SYSCATSPACE

SMS01
DMS01

DMS02

DMS02

1

Backup
Database
SALESDB

SUN

SMS01

Backup
TS DMS01

MON

TUE

Backup
TS DMS02

WED

THU

Backup
TS DMS01

FRI

SAT

36


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 tsm
replace 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

37


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
Tuesday
SalesDB

SalesDB
SYSCATSPACE

2

DMS01

SYSCATSPACE

SMS01
DMS01

DMS02

DMS02

1

Backup
Database
SALESDB

SUN

SMS01

Backup
TS DMS01

MON

TUE

Backup
TS DMS02

WED

THU

Backup
TS DMS01

FRI

SAT

DMSO1 is
logically corrupt

38


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

39


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
Recovery
History File

SalesDB
SYSCATSPACE

2

DMS01

3

Backup
Database
SALESDB

SUN

SMS01

Backup
TS DMS01

MON

TUE

Backup
TS DMS02

WED

THU

DMS02

1
Backup
TS DMS01

FRI

Database
Fails !
SAT

40


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 status
Result:
3 TBS pending S0000000.LOG-S0000003.LOG 2010-03-2907.42.44.000000 Local
note: 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"
41


Agenda
•
•
•
•
•

Overflow Bucket 

42


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


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

44


Sample Low End Backup Schedule
Sun

Mon

Full
DB

Tue

Full
DB

•
•

Wed

Thu

Fri

Full
DB

Sat

Sun

Full
DB

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

4545


Typical Mid Range Configuration

DB2 Server Environment
Disk Storage
CPU

•
•
•
•
•
•

IBM

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
TSM Server and Tape Library

IBM

CPU

Tape
46


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
47


Sample Mid Range Backup Schedule
Sun

Full
DB

•
•

Mon

Incr
DB
Set1

Tue

Wed

Thu

Incr
DB
Set2

Fri

Incr
DB
Set3

Sat

Sun

Full
DB

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

4848


Typical High End Configuration

DB2 Server Environment
IBM

• 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

CPU

Disk Storage

TSM Server Environment
Tape Library
CPU
IB M

49


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
50


Sample High End Backup Schedule
Sun

Mon

Tue

Wed

Thu

Fri

Sat

Full TSP
Weekly

Incr
DB
Set1

Incr
DB
Set2

Incr
DB
Set3

Incr
DB
Set4

Incr
DB
Set5

Incr
DB
Set6

•
•

Sun

Full DB
Monthly

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

5151


Protecting yourself from logical corruption
•
•
•
•

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

52


Methods to recover from logical corruption
Utilize 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


Methods to recover from logical corruption
Object 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


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


Agenda
•
•
•
•
•

Overflow Bucket 

56


• Storage based replication
• Logical Replication
• HADR

57

Local Cluster With Disk Mirroring to remote DR site

Primary Connection

HA Cluster

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

DR Site

Primary
Database

Remote Disk Mirror
Technology

DB1

DB1’

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 local
Cons:
• Failover time to DR site can be in the order of tens of minutes
• Must ensure all file systems required are replication

58


IBM InfoSphere Data Replication (IIDR)
• 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

DB2
Cognos

Information
Server

IDRR

MDM

Warehouse

59


Logical Replication

Multiple alternate standby servers

Primary Connection

Site A

…
Site C
Site B

Read
and / or
write on
standby

Primary
Database

Remote
Standby

DB 3

Q based SQL replication to
logical standby’s

DB1

DB 2

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 servers
Cons:
• More complex to setup and monitor (more flexibility) compared to HADR
• Async

60


HADR Architecture

DB2 Engine

PRIMARY SERVER

STANDBY SERVER

TCPIP
HADR

DB2 Engine

Log Pages
Log Records
HADR

Shredder

Log Pages
Log Pages

Log Writer

Tables
Indexes

61

Logs

Log Reader

Log
Records

Log Pages

Log Writer

Old
Logs

Replay Master

Logs

Log Reader

Redo Slaves
Redo Slaves
Redo Slaves
Replay Slaves

Old

Tables

Logs

Indexes

61
61


Agenda
•
•
•
•
•

Overflow bucket 

62


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


Data Deduplication Concept
A

J

B

G

H

D

C

E

L

F H G E

D

Unique blocks

C

H

B

C A L K

B

I

K

E

J

C

F

K

E

Duplicate blocks

Data
Data
Source Source
1
2

I B

J

Target data store

Data
Source
3

64


Default backup physical format
Tablespace 1

Tablespace 2

Tablespace 3

DB2 backup db mydb use TSM open 3 sessions

Backup image output stream 1

65


Dedup backup physical format
Tablespace 1

Tablespace 2

Tablespace 3

DB2 backup db mydb use TSM open 3 sessions dedup_device

66


TSM Client Deduplication Results
Command:
DB2 backup db PERF use TSM open 8 sessions dedup_device
Settings:
Util_heap_sz =50000
Autonomic performance settings:
Backup Buffer Size = 2465
Backup # of buffers = 18
Backup Parallelism = 8
Start

End

Elapsed Time

12:22:57 AM

2:32:54 AM

2:09

Actual DB Size Dedup Size
% Savings in
sent to server bandwidth
in bytes
in bytes
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%

67


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

Start

End

Elapsed Time Actual DB Size Dedup Size
sent to
in bytes
server in
bytes

% Savings in
bandwidth

10:22:00 PM
1:53:55 AM
2:22:26 AM
2:49:44 AM
3:17:18 AM

1:53:47 AM
2:22:30 AM
2:49:39 AM
3:17:12 AM
3:45:32 AM

3:31
0:28
0:27
0:27
0:28

0.56%
99.09%
99.74%
99.87%
99.91%

1.36499E+11
1.36499E+11
1.36499E+11
1.36499E+11
1.36499E+11

1.35729E+11
1248387123
352043759
175945343
129529760

68


AUTO_DEL_REC_OBJ : Automatic Life Cycle Mgmt
•

A new database configuration parameter that controls whether
the underlying logs, backups and other associated objects are
deleted 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 deleted
69


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


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


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


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


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


Backup and Recovery
• If a DB2 online backup is not feasible due to conflicts with other
utilities then consider SNAPSHOTS in DB2 9.5
OR
• IBM Tivoli Storage Manager for Advanced Copy Services For DB2
• http://www.ibm.com/developerworks/tivoli/library/tacsdb2_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


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 Database
http://www.ibm.com/developerworks/data/bestpractices/isasrecovery/
index.html

• Best Practices: Multi-Temperature Data Management
http://www.ibm.com/developerworks/data/bestpractices/multitemper
ature/index.html

• Article: DB2 instance recovery for IBM Smart Analytics
System
http://www.ibm.com/developerworks/data/library/techarticle/dm1010db2instancerecovery/index.html?ca=drs76


Thai

Hindi

Traditional Chinese

Gracias
Spanish

Russian

Thank You

Obrigado
Brazilian Portuguese

Arabic

Grazie

Danke
German

Italian

Merci
French

Tamil

Simplified Chinese

Korean

Japanese

77


Dale McInnis
IBM Canada Ltd.
dmcinnis@ca.ibm.com
Session: D11
DB2 Recovery - what is inside this magic box.

78

Db2 recovery IDUG EMEA 2013

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to Db2 recovery IDUG EMEA 2013

Similar to Db2 recovery IDUG EMEA 2013 (20)

Recently uploaded

Recently uploaded (20)

Db2 recovery IDUG EMEA 2013