IN FOCUSDBFH Recovery Is an Inspection-First Operation
Rocket Enterprise Developer 12.0 DBFH recovery uses an inspection-first workflow: list stale region ownership and locks, prove the owning process is gone, then recover. Orphaned records block recovery until dbfhadmin -verify is run. [1] [2] [4]
Read the full briefing
DBFH Recovery Is an Inspection-First Operation
Scope: Rocket Enterprise Developer 12.0 for Eclipse on UNIX, Database File Handler (DBFH) region, cross-region, and datastore recovery.
When an Enterprise Server process ends abnormally, its database-backed resources may remain registered: open file handles, resource locks, or record locks might not be released. Rocket provides automated recovery, but console errors during a later startup can indicate that some resources remain unavailable. The important operational insight is that dbfhadmin recovery is not a blind “unlock everything” command—it is a staged process in which you identify stale ownership before forcing cleanup. Database Management and Recovery explains that abnormally terminated CAS processes remain registered with an In doubt status, while active registered processes show Ok.
A practical region-lock workflow is:
- List the regions and ENQ counts associated with a database server instance:
dbfhadmin -region -list -usedb:DBHOST- Narrow the inspection to one region and display its locked resources:
dbfhadmin -region -list -usedb:DBHOST -name:ESDEMO- Only after confirming the region is no longer running, release locks without process affinity:
dbfhadmin -region -recover -usedb:DBHOST -name:ESDEMOThese commands and their intended order are documented in Examples of the dbfhadmin Command Line Utility. The page explicitly warns that recovery should run only when the region has stopped. It separately cautions against resetting a region database status to “stopped” unless you are absolutely certain the process, program, or host reported as owning the region is not actually running.
Configuration is also a prerequisite. The dbfhadmin Command Line Utility requires an environment in which MFDBFH_CONFIG points to a configuration file containing data-source entries for the databases being administered. On UNIX, invoke dbfhadmin32 or dbfhadmin64 according to the working mode; an explicit -configfile option can override MFDBFH_CONFIG.
One recovery path has an additional gate. If region or cross-region recovery encounters orphaned records, message ADM0100E says no recovery is performed and directs you to run dbfhadmin -verify first. That prevents ordinary lock recovery from silently proceeding across a database-integrity problem.
Takeaway: With DBFH, list ownership first, prove the owner is gone, satisfy any -verify requirement, and only then recover or reset resources.