db2udb_the_basics day 6

IBM Software Group

© 2005 IBM Corporation

DB2 UDB Intermediate

Day6

IBM Software Group


Topics

HADR Reorgchk and reorg Runstats

2

IBM Software Group


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

IBM Software Group


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

IBM Software Group


Logshipping

5

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.

IBM Software Group


Overview of HADR

7

IBM Software Group


HADR Setup

8

IBM Software Group


HADR related dbcfg parameters

9

IBM Software Group


HADR States

10

IBM Software Group


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

IBM Software Group


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

IBM Software Group


SYNC

13

IBM Software Group


NEARSYNC

14

IBM Software Group


ASYNC

15

IBM Software Group


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

IBM Software Group


Steps to initialize the HADR

17

IBM Software Group


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

IBM Software Group


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

IBM Software Group


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

IBM Software Group


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

IBM Software Group


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

IBM Software Group


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

IBM Software Group


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

IBM Software Group


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

IBM Software Group


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

IBM Software Group


• 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

IBM Software Group


Thank You

29

db2udb_the_basics day 6

Documents