If you create a table space on the
primary database and log replay fails on the standby database because
the containers are not available, the primary database does not receive
an error message stating that the log replay failed.
If
a takeover operation occurs, the new table space that you created
is not available on the new primary database. To recover from this
situation, restore the table space on the new primary database from
a backup image.
To check for log replay errors, you must monitor the db2diag.log file
and the administration notification log file on the standby database
when you are creating new table spaces.
In the following example, table space MY_TABLESPACE is restored
on database MY_DATABASE before it is used as the new primary database:
- Connect to the database MY_DATABASE:
DB2 CONNECT TO my_database
- Obtain the list of unavailable table spaces that need to be restored:
DB2 LIST TABLESPACES SHOW DETAIL
You
specify the relevant tablespace ID in step 5 of
this procedure.
- Stop HADR on the primary database:
DB2 STOP HADR ON DATABASE my_database
- Perform an online redirected restore of the tablespace:
DB2 RESTORE my_database TABLESPACE (my_tablespace) ONLINE REDIRECT
- Define the new table space containers:
DB2 SET TABLESPACE CONTAINERS FOR my_tablespace_ID IGNORE ROLLFORWARD CONTAINER OPERATIONS USING (PATH '/new_container_path/')
- Complete the restore operation:
DB2 RESTORE my_database CONTINUE
- Roll forward the database to the end of logs:
DB2 ROLLFORWARD DATABASE my_database TO END OF LOGS AND STOP TABLESPACE (my_tablespace)
- Start HADR on the primary database:
DB2 START HADR ON DATABASE my_database AS PRIMARY
DB2 10.5 for Linux, UNIX, and Windows