Requirements for HADR
environments
To take advantage of HADR, you must have
two dedicated servers available: one for the
primary database and one for the standby
database. Furthermore, both servers must
adhere to a set of very specific requirements
(see sidebar, “Server setup checklist”).
Setting up HADR
Setting up an HADR environment is fairly
straightforward. First, ensure that the systems
to be used as primary and standby servers are
identical and that a TCP/IP connection exists
between them. Then follow these steps:
1. Determinethehostname,hostIPaddress,
and the service name or port number
for both the primary and the standby database server. If a server has multiple net work
interfaces, ensure that the HADR host
name or IP address maps to the intended
interface. You will need to allocate separate
c
HADR ports for each protected database—
these cannot be the same as the ports that
have been allocated to the DB2 instance.
The host name can map to only one
IP address.
2. Create the standby database by restoring
a backup image or initializing a split mirror
copy of the database that will serve as the
primary database on the standby server.
When using the RESTORE DATABASE command
to create the standby database from a
backup image, IBM recommends that the
REPLACE HISTORY FILE option be specified.
Avoid use of the TABLESPACE, INTO, REDIRECT,
and WITHOUT ROLLING FORWARD options.
When using the db2inidb utility to
reate the standby database from a split
mirror copy, use the AS STANDBY option (to
initialize the split mirror image as a clone);
the AS SNAPSHOT and AS MIRROR options
should be avoided. The RELOCATE USING
option can be specified to change one or
d
more of these configuration attributes:
instance name, log path, and database path.
However, you must not change the database
name or the table space container paths.
Once you have created the standby
atabase, do not use the ROLLFORWARD
DATABASE command as a recovery option.
The results of performing a roll-forward
recovery operation could differ slightly
from replaying the logs on the standby
database using HADR. If the primary and
standby databases are not identical when
HADR is started, an error will occur.
3. Assign appropriate values to the HADR
configuration parameters for both the
primary and the standby database. After
the standby database has been created,
but before HADR is started, set the
HADR-specific configuration parameters shown in Table 1 for both the
primary and the standby database. You
can choose your level of protection from
WHAT GETS REPLICATED?
Operations replicated under HADR:
Execution of Data Definition Language }
(DDL) statements (CREATE, ALTER, DROP)
Execution of Data Manipulation Language }
(DML) statements (INSERT, UPDATE,
DELETE)
Buffer pool operations }
Table space operations, as well as }
storage-related operations performed
on automatic storage databases
(ALTER DATABASE)
Online reorganization }
Offline reorganization }
Changes to metadata (system catalog }
information) for stored procedures and
user-defined functions (UDFs)
Operations not replicated under HADR:
Stored procedure and UDF object and }
library files
Non-logged operations, such as changes }
to database configuration parameters and
to the recovery history file
SERVER SETUP CHECKLIST
Here’s a checklist of HADR setup items that
shouldn’t be missed:
Hardware
Server: The servers hosting the primary and
standby databases should be as similar as
possible, from the vendor to the architecture
Memory: Ideally, identical amounts of memory
should be available to support replayed buffer
pool operations
Network: A TCP/IP interface is required between
the HADR host systems, connected over a high-speed, high-capacity network
Software
Operating system: Identical versions on both
servers, including patch level
DB2 software: Identical bit size ( 32 or 64)
and version—during rolling upgrades, the
modification level of the database system for the
standby database can be higher than that of the
primary database for a short while; always apply
fix packs to the standby database system first
Database configuration
Single-partition databases with identical names }
Identical storage space allocated for }
transaction log files; raw devices are not
supported
Archival logging on current primary }
database only
Table space properties, such as table space }
name, table space type (DMS, SMS, or
Automatic Storage), page size, size, container
path, container size, and container type
(raw device, file, or directory), must be
identical on both databases
Before adding containers to existing table }
spaces by executing the ALTER TABLESPACE
statement against the primary database,
table space containers involved with such
statements must exist on both systems
Automatic storage databases are supported; }
any storage paths specified with ALTER
DATABASE statements must exist on both
the primary and the standby server
