11

2

3

4

5

See the example later in the presentation

6

Additional info on the HADR simulator, including where to get it, in a later slide.

7

When buffer is large, you may notice that the throughput reported by the primary is higher than that from the standby. This is because primary considers send done when send() call returns (data is copied to TCP send buffer, but may not have reached standby). While standby counts data as received only when it actually gets the data. So the standby side number is more accurate. "Large" here is relative to total amount of data shipped. In the below 1MB buffer example, 289 MB of data was sent in 60 seconds (at 4.8 MB/sec), so 1MB is relatively very small and should not cause much discrepancy in primary and standby numbers. When buffer is large, you can use longer test runs to increase total amount of data shipped to make the buffer relatively small.

8

db2logscan usage: db2logscan [options] <logFile1> <logFile2> ... <logFileN>

-interval <n> Sample logging rate every <n> seconds. 0 for sampling once perlog file. Default 60.

-checksum Check page checkSum of input files. Detault no check.-infoLevel <s> Logging information display level. Incremental levels are:

rate: Show logging rate. Default level.file: Show meta data of each file.flush: Show each flush.page: Show each page.record: Show each record.

-transLevel <s> Transaction information display level. Incremental levels are:summary: Just a summary at end of run. Default level.open: Show open tranactions at end of run.all: Show start and end of each transaction during the run.

-f <file> Read file names from <file>, one per line.-retrieve <cmd> Run "<cmd> fileName" before opening a file to retrieve the file

from archive, etc.

9

10

11

12

The operations on the critical path are

Sending log records

Receiving log records

Writing log records to disk

Replaying log records

13

14

15

16

17

18

19

20

21

22

23

See a later slide for more info on the log scanner and the hadr calculator.

24

25

26

27

Superasync vs Log Spooling:

Superasync mode

Eliminates back pressure on the primary

Useful network is slow

Log spooling

Allows receipt of log records regardless of log replay on the standby

Useful with standby is slow

Can be used with any sync mode

Both features can be combined if required

Slow network and a slow standby

28

29

30

31

Use the database monitor to determine whether the LOGBUFSZ parameter is optimal or not by looking at the following:

Log pages read = 0

Log pages written = 12644

In general, an ideal value would be zero log pages read while seeing a good number of log pages written. When there are too many log pages read, it means a bigger LOGBUFSZ is needed.

32

Info on the log scanner in a later slide.

33

34

See http://www.ibm.com/developerworks/data/library/techarticle/dm-0708naqvi/index.html?ca=dat- for a review of parsing the STMM log.

35

36

37

38

39

Changes to monitoring HDAR in v10.5

New behavior to existing fieldsWhen HADR_SPOOL_LIMIT is AUTOMATIC (new value in Kepler), the STANDBY_SPOOL_LIMIT monitor field will return the computed spool size in unit of pages, rather than some special value that represents AUTOMATICIf a member has never connected to the remote db, remote info such as MEMBER, HOST, INST is unknown. Before some of the info might have been returned as blanks or 0. Now we return NULL.

New monitoring fieldsHEARTBEAT_MISSED (available in fp1)

Number of heartbeat messages not received on time on this log stream, accumulated since database startup on the local member Used with HEARTBEAT_EXPECTED to determine network health

HEARTBEAT_EXPECTED (available in fp1)Number of heartbeat messages expected on this log stream, accumulated since database startup on the local memberUsed with HEARTBEAT_MISSED to determine network health

STANDBY_SPOOL_PERCENTPercentage of spool space used, relative to configured spool limit

STANDBY_ERROR_TIMEThe most recent time when standby encountered a major error

HADR_FLAGSASSISTED_REMOTE_CATCHUPASSISTED_MEMBER_ACTIVE STANDBY_LOG_RETRIEVAL STANDBY_RECV_BLOCKED STANDBY_LOG_DEVICE_FULL STANDBY_REPLAY_NOT_ON_PREFERRED

Positive number = member ID

-1 = current member

-2 = all members

40

41

42

43

To configure data studio alerts:

In the web console, select Open > Alerts and click Health Alerts Configuration.

Select a database for which to view and edit the configurable alert parameters.

Enable or disable database health monitoring for the database. To display alert information for the database in the Health Summary and Alert List, database health monitoring must be enabled. Enable health monitoring by selecting the Monitor database health check box.Note: When you add a database connection, health monitoring is turned on by default. Disable health monitoring by clearing the Monitor database health check box.

Set the refresh rate for the database. The refresh rate controls how often the database is checked for conditions that might trigger alerts.

Configure alerts for the database.

Select an alert type and click Edit.

If prompted, sign in with a database user ID that has permission to manage alerts on the database.

Enable or disable the alert for the database, and configure the critical and warning thresholds for the alert type.

44

45

46

47

48

49

50

51

52

53

5454