Tackling Hollow Rate in GBase 8a: Causes and Fixes

#gbase #database #数据库

In a gbase database, the "hollow rate" is the percentage of storage occupied by logically deleted but not yet reclaimed rows. GBase 8a uses logical deletion for performance, marking rows as invalid without immediately freeing disk space. Those freed blocks cannot be reused by new inserts, leading to wasted storage and slower scans over time.

Why Hollows Appear

Logical DELETE only updates metadata, the physical data remains.
Un‑reusable space: the marked blocks are never reused, so the hollow rate keeps climbing.

Solution 1: Rebuild the Table (small to medium tables)

A simple, safe approach that migrates valid data to a new table.

-- 1. Create a new table with identical structure
CREATE TABLE db_test.t_new LIKE db_test.t_old;

-- 2. Copy all valid rows
INSERT INTO db_test.t_new SELECT * FROM db_test.t_old;

-- 3. Swap table names
RENAME TABLE db_test.t_old TO db_test.t_old_bak,
             db_test.t_new TO db_test.t_old;

-- 4. Drop the backup after verification
DROP TABLE db_test.t_old_bak;

Pros: zero complexity, data consistency can be verified in parallel.

Cons: temporarily uses extra storage; run during off‑peak hours.

Solution 2: SHRINK SPACE (large tables, online reclaim)

Built‑in command that reorganizes data at three granularities.

Seg‑level Shrink (default, most common)

ALTER TABLE db_test.t_old SHRINK SPACE;

Only processes Seg files where the invalid data ratio exceeds a threshold. Fast, low impact.

Row‑level Deep Shrink (FULL)

ALTER TABLE db_test.t_old SHRINK SPACE FULL;

Rebuilds the entire table structure for maximum space recovery. Takes longer; best performed during maintenance windows.

DC‑level Shrink (distributed clusters)

ALTER TABLE db_test.t_distributed SHRINK SPACE DC;

Coordinates space reclamation across all data nodes in a distributed GBase 8a environment.

Important:

Back up the table before shrinking.
The table is locked in shared mode (reads allowed, writes blocked).
After shrinking, run OPTIMIZE TABLE db_test.t_old; to rebuild indexes.

Prevention and Monitoring

Delete in smaller batches instead of massive single deletions.
Monitor hollow rate regularly. Trigger action when it exceeds 30%:

  SELECT table_name,
         (data_length - data_free)/data_length AS hollowness_rate
  FROM information_schema.tables
  WHERE table_schema = 'db_test' AND table_name = 't_old';

For small tables, rebuild; for large tables, use Seg‑level Shrink.

A proactive approach to hollow management keeps your gbase database storage efficient and queries fast.

DEV Community