High Availability, Durability, and Disaster Recovery for ...
C14-High availability disaster recovery and performance.dmm
54
1 1
Transcript of C14-High availability disaster recovery and performance.dmm
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
