Why You Must Clean Data, Distribution, and Nodedatamap Before Removing a VC

In GBase 8a, deleting a Virtual Cluster (VC) without first clearing its data, distribution maps, and nodedatamap entries is blocked — or worse, causes metadata corruption. This strict sequence is mandatory and enforced by the resource management model and tight metadata coupling inside a gbase database.

The Three Items You Must Remove

Required Cleanup	What It Is	Relationship to the VC	Consequence of Skipping
User Data	All actual rows stored in databases and tables created within the VC.	The very purpose of the VC — holding data.	Orphaned data that consumes storage but cannot be accessed or managed via SQL. A storage leak.
Distribution Map	Core metadata defining how data segments are spread across Data Nodes. Each VC can have up to two distribution maps.	The "blueprint" of the VC's physical data layout and high‑availability design.	Stale metadata occupying system tables and pointing to a missing VC, causing conflicts or confusion when creating new VCs.
Nodedatamap	Records in gbase.nodedatamap that map hash values, segment IDs, node IDs, and distribution IDs. This is the routing index the SQL engine uses to locate rows.	The "navigation map" for query routing.	Invalid route entries that degrade query performance or cause routing errors, potentially destabilising the cluster.

The Correct Deletion Sequence

The order reflects dependency layers that must be unwound one by one:

1. Drop user data — DROP DATABASE or DROP TABLE everything inside the VC.
2. Drop distribution maps — gcadmin rmdistribution <ID> vc <vc_name>, after verifying no tables are still using them.
3. Flush nodedatamap — The system cleans related entries automatically, or you can run refreshnodedatamap drop manually.
4. Remove the VC — gcadmin rmvc <vc_name>. At this point the VC is an empty shell and can be safely deleted.

What Happens If You Try to Delete a VC Directly

• Using gcadmin rmvc without cleanup: The command checks whether the VC is empty and will fail with an error if data or distribution maps remain.
• Forcibly removing Data Nodes from the VC: This is extremely dangerous. If the node held the only replica of a segment, data is lost permanently. The cluster state may become INCONSISTENT or FAILURE, requiring a complex and potentially incomplete recovery.

Think of a VC as a leased apartment: the data is the furniture, the distribution map is the floor plan, and the nodedatamap is the building's resident directory. The right way to move out is to empty the rooms, shred the blueprints, update the directory, and then cancel the lease. Demolishing the apartment while it's still occupied and listed only causes chaos.

Following this cleanup sequence isn't a recommendation — it's a mandatory safety procedure that protects metadata consistency and data safety in your GBASE cluster.