Dropping a member or cluster caching facility entails running the db2iupdt command. This topology change might require a database backup, depending on whether or not the database is recoverable.
In a recoverable database, if you change the member topology (for example, dropping a member), you must take either an incremental or full offline database backup before you can access the database. (This event is considered a change to the life of the database topology.) Otherwise, if you attempt to access the database before taking an offline backup, the database is placed in a backup pending state.
In a nonrecoverable database, if you change the member topology, you do not need to take an offline backup before you can access the database. However, the database is recoverable only to the point in time when you took the last backup image, and uses the same topology as when the image was produced. If you do not take an offline backup and attempt to access the database, the database is not placed in a backup pending state..
You can drop multiple members without having to take a backup after each change. For example, if you drop three members, you need to take a backup only after you have completed all drop operations. However, if you add two members and then drop a member, you must take a backup before you can perform any additional member topology changes.
Restrictions
After a member is dropped, its entry is kept in the diagnostic directory.
DB2DIR/instance/db2iupdt -drop -m test1 db2sdin1
Then,
to remove the DB2 installation
from the test1 host, run the following command from the test1 host: DB2DIR/install/db2_deinstall -a
Perform either an incremental or full offline database backup that reflects the current topology of yourDB2 pureScale cluster.