The document discusses High Availability Disaster Recovery (HADR) in DB2. It describes how HADR uses log shipping to replicate transactions from a primary database to a standby database. HADR supports three synchronization modes - SYNC, NearSync and Async - which determine how transaction logs are replicated. The document provides steps for setting up and configuring HADR, including required database parameters. It also discusses using reorgchk and runstats utilities to check for table/index reorganization needs and update database statistics.

1. IBM Software Group
© 2005 IBM Corporation
DB2 UDB Intermediate
Day6

2. IBM Software Group
© 2005 IBM Corporation
Topics
 HADR
 Reorgchk and reorg
 Runstats
2

3. IBM Software Group
© 2005 IBM Corporation
HADR
High Availability Disaster Recovery
• The purpose oh HADR is to make sure for Business Continuity in
case of any disruptions.
• HADR is a database replication feature that provides a high
availability and disaster recovery solution.
• An HA system usually consists of a primary database and a
standby database.
• The database which is currently running is referred as Primary
database . The standby database is usually a mirror of Primary
database.
 If the primary database fails, the standby database takes over the
existing transactions and becomes the new primary database.
3

4. IBM Software Group
© 2005 IBM Corporation
Logshipping
 Log shipping is a method where transaction logs are automatically
copied from a primary database server to a standby database
server.
 Using log shipping, you can make the log files produced by the
primary database available to the secondary database and
continuously apply them.
 The ROLLFORWARD DATABASE command is used to apply log
files produced by the primary database on the standby database.
 Note that for log shipping to work, both systems must be running
the same version of DB2.
4

5. IBM Software Group
© 2005 IBM Corporation
Logshipping
5

6. IBM Software Group
© 2005 IBM Corporation6
On the standby database, set the LOGARCHMETH1 parameter to
the same value as that on the primary database. When a
ROLLFORWARD DATABASE command is issued on the standby
database, DB2 pulls the logs from this archival location and applies
them to the standby database.

7. IBM Software Group
© 2005 IBM Corporation
Overview of HADR
7

8. IBM Software Group
© 2005 IBM Corporation
HADR Setup
8

9. IBM Software Group
© 2005 IBM Corporation
HADR related dbcfg parameters
9

10. IBM Software Group
© 2005 IBM Corporation
HADR States
10

11. IBM Software Group
© 2005 IBM Corporation
HADR Synchronization Mode
 To indicate how log page shipping and writing is managed between
the primary and standby databases, a synchronization mode is
specified.
There are 3 synchronization modes for HADR
• SYNC mode
• Near Sync mode
• Async Mode
11

12. IBM Software Group
© 2005 IBM Corporation
SYNC Mode
In SYNC mode , Log writes are considered successfully only when:
 Log pages are written to log files on the primary database
 The primary database has received acknowledgement from the
standby database that log pages are successfully written to log
files on the standby database.
12

13. IBM Software Group
© 2005 IBM Corporation
SYNC
13

14. IBM Software Group
© 2005 IBM Corporation
NEARSYNC
14

15. IBM Software Group
© 2005 IBM Corporation
ASYNC
15

16. IBM Software Group
© 2005 IBM Corporation
HADR Commands Overview
HADR is managed by three simple commands:
• START HADR
• STOP HADR
• TAKEOVER HADR
 START HADR ON DATABASE database-alias [USER userid] [USING
password] AS PRIMARY | STANDBY [BY FORCE]
 STOP HADR ON DATABASE database-alias [USER userid] [USING
password]
 TAKEOVER HADR ON DATABASE database-alias [USER userid] [USING
password] [BY FORCE]
16

17. IBM Software Group
© 2005 IBM Corporation
Steps to initialize the HADR
17

18. IBM Software Group
© 2005 IBM Corporation
Sample of Standby DB parameters
18
 UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST
server2.torolab.ibm.com
 UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
 UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST
server1.torolab.ibm.com
 UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
 UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
 UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

19. IBM Software Group
© 2005 IBM Corporation
Sample of Primary db parameters
 UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST
server1.torolab.ibm.com
 UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
 UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST
server2.torolab.ibm.com
 UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
 UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
 UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on
START HADR ON DB test1 AS STANDBY
START HADR ON DB test1 AS PRIMARY
19

20. IBM Software Group
© 2005 IBM Corporation
Stopping the HADR
 STOP HADR ON DB test1
 If we want to stop HADR completely, We need to use the above
command on both server.
20

21. IBM Software Group
© 2005 IBM Corporation
Reorgchk
REORGCHK is a data maintenance utility that has an option to
retrieve current database statistics or update the database
statistics. It generates a report on the statistics with indicators
identifying tables and indexes that should be reorganized.
db2 reorgchk current statistics on table db2inst1.larsen
db2 reorg indexes all for table larsen
21

22. IBM Software Group
© 2005 IBM Corporation
Output of Reorgchk
Output of Reorgchk: (i) Table Statics (ii) Index Statics
Table statistics:
F1: 100 * OVERFLOW / CARD < 5
F2: 100 * (Effective Space Utilization of Data Pages) > 70
F3: 100 * (Required Pages / Total Pages) > 80
SCHEMA.NAME CARD OV NP FP ACTBLK TSIZE F1 F2 F3 REORG
----------------------------------------------------------------------------------------
Table: DB2INST1.LARSEN
5 0 1 1 - 165 0 - - *100 --*
----------------------------------------------------------------------------------------
22

23. IBM Software Group
© 2005 IBM Corporation
Index statistics:
F4: CLUSTERRATIO or normalized CLUSTERFACTOR > 80
F5: 100 * (Space used on leaf pages / Space available on non-empty
leaf pages) > MIN(50, (100 - PCTFREE))
F6: (100 - PCTFREE) * (Amount of space available in an index with
one less level / Amount of space required for all keys) < 100
F7: 100 * (Number of pseudo-deleted RIDs / Total number of RIDs) <
20
F8: 100 * (Number of pseudo-empty leaf pages / Total number of leaf
pages) < 20
23

24. IBM Software Group
© 2005 IBM Corporation24

25. IBM Software Group
© 2005 IBM Corporation
REORG
 If from the REORGCHK command , “*” is being found in Reorg
colums of Table or Index Statics. Then we will find that reorg is
required for the specific table or indexes.
 To reorganize the table or indexes, we are using REORG command.
 DB2 provides the option of performing this online or offline. By
default, offline REORG lets other users read the table.
 Online REORG (also called inplace REORG) does not support read
or write access to the table.
 Since data pages are rearranged, concurrent applications have to
wait for REORG to complete with the current pages.
25

26. IBM Software Group
© 2005 IBM Corporation
REORG Commands
 reorg table db2user.employee index db2user.idxemp inplace allow write
access
 reorg table db2user.employee index db2user.idxemp inplace pause
 reorg index db2user.idxemp for table db2user.employee allow write access
 reorg index db2user.idxemp for table db2user.employee cleanup only
26

27. IBM Software Group
© 2005 IBM Corporation
RUNSTATS Command
The REORG utility rearranges the data physically but does not
update the database statistics. Therefore, it is important to always
execute a RUNSTATS upon completion of a REORG.
 The RUNSTATS utility updates statistics about the physical
characteristics of a table and the associated indexes.
Characteristics include the number of records (cardinality), the
number of pages, the average record length, and so on.
27

28. IBM Software Group
© 2005 IBM Corporation
• This command collects statistics on the table db2user.employee while
letting readers and writers access the table while the statistics are being
calculated.
runstats on table db2user.employee allow write access
 This command collects statistics on the table db2user.employee, as well as
on the columns empid and empname with distribution statistics. While the
command is running, the table is only available for read-only requests.
runstats on table db2user.employee with distribution on columns ( empid,
empname ) allow read access
 The following command collects statistics on the table db2user.employee
and detailed statistics on all its indexes.
runstats on table db2user.employee and detailed indexes all
28

29. IBM Software Group
© 2005 IBM Corporation
Thank You
29