DB2 automation and recovery scenarios

(ZOS) DB2 automation and recovery scenarios

This article provides scenarios for automation and recovery of DB2 resources.
Task DB2 automation and recovery scenarios
Startup DB2 is started after RRS but before LDAP, NFS, and WebSphere Application Server for z/OS.
Shutdown Reverse of startup sequence.
Handling in-flight or indoubt transactions if there is a failure
Use the RRS panels to resolve. See z/OS VS™ Programming: Resource Recovery. The RRS panels are the preferred way to resolve DB2 indoubts because they allow us to view all resource managers that have an interest in the transaction. However, we can also use DB2 to resolve indoubts. We can issue the command:
DISPLAY THREAD(*) TYPE(INDOUBT)
to display DB2 information about the indoubt threads it knows about (if there are too many, we can go into S.LOG to view the information). This display will give you a DB2 identifier called a "nid". Copy the nid and paste it into this command:
-RECOVER INDOUBT (RRSAF) ACTION(COMMIT)
	NID(B1D379D17ED6CF900000009401010000)
where the nid is the one that you cut from the display command. We can issue this command to roll back the transaction:
-RECOVER INDOUBT (RRSAF) ACTION(ABORT)
	NID(B1D379D17ED6CF900000009401010000)
How to determine if DB2 is running Use the display command to display the DB2 address space.
What happens to WAS for z/OS if DB2 goes down? WAS for z/OS continues to run. WAS for z/OS does not require restarting in this scenario.
What happens to other subsystems if DB2 goes down? Not applicable
Where to find more information See the DB2 books at the following Internet location:http://www.ibm.com/servers/eserver/zseries/zos/
Diagnose problems (using diagnosis tools)
Automation and recovery scenarios and guidelines

Task	DB2 automation and recovery scenarios
Startup	DB2 is started after RRS but before LDAP, NFS, and WebSphere Application Server for z/OS.
Shutdown	Reverse of startup sequence.
Handling in-flight or indoubt transactions if there is a failure	Use the RRS panels to resolve. See z/OS VS™ Programming: Resource Recovery. The RRS panels are the preferred way to resolve DB2 indoubts because they allow us to view all resource managers that have an interest in the transaction. However, we can also use DB2 to resolve indoubts. We can issue the command: DISPLAY THREAD(*) TYPE(INDOUBT) to display DB2 information about the indoubt threads it knows about (if there are too many, we can go into S.LOG to view the information). This display will give you a DB2 identifier called a "nid". Copy the nid and paste it into this command: -RECOVER INDOUBT (RRSAF) ACTION(COMMIT) NID(B1D379D17ED6CF900000009401010000) where the nid is the one that you cut from the display command. We can issue this command to roll back the transaction: -RECOVER INDOUBT (RRSAF) ACTION(ABORT) NID(B1D379D17ED6CF900000009401010000)
How to determine if DB2 is running	Use the display command to display the DB2 address space.
What happens to WAS for z/OS if DB2 goes down?	WAS for z/OS continues to run. WAS for z/OS does not require restarting in this scenario.
What happens to other subsystems if DB2 goes down?	Not applicable
Where to find more information	See the DB2 books at the following Internet location:http://www.ibm.com/servers/eserver/zseries/zos/