Forem: Michael

Modifying Cluster Parameters in GBase 8a: Instant vs. Permanent

Michael — Sun, 17 May 2026 14:46:00 +0000

Changing system parameters like gcluster_rebalancing_concurrent_count in GBase 8a can be done in two ways — one gives you instant effect with a catch, the other is permanent but requires a restart. Here's how both work in a gbase database.

Two Approaches at a Glance

Method	How	When It Takes Effect	Persistence	Best For
Config file	Edit `.cnf` / `.conf` files	After restarting the module	Permanent	All parameters, especially read-only ones
SET GLOBAL	`SET GLOBAL param = value;`	New sessions immediately	Lost on restart	Dynamic, tuneable parameters
SET SESSION	`SET [SESSION] param = value;`	Current session only	Session ends	Debugging or one-off queries

Example: Adjusting Rebalance Concurrency

The parameter gcluster_rebalancing_concurrent_count controls how many tables can be rebalanced in parallel. It's a performance tuning knob that supports dynamic change.

Method 1: SET GLOBAL (Immediate, for Quick Tuning)

SET GLOBAL gcluster_rebalancing_concurrent_count = 5;
-- Verify in a new session
SHOW GLOBAL VARIABLES LIKE 'gcluster_rebalancing_concurrent_count';

New rebalance tasks will use the updated count instantly. Already running tasks are unaffected.

Method 2: Config File (Permanent)

Edit the gcluster config file at $GCLUSTER_BASE/config/gbase_8a_gcluster.cnf, find or add:

gcluster_rebalancing_concurrent_count = 5

Then restart the module:

gcluster_services gcluster restart

After restart, this value becomes the new default. Any SET GLOBAL changes made before the restart will be replaced by the config file value.

Key Points

Read‑only parameters (e.g., security settings) can only be changed in config files and require a restart.
Parameter prefixes tell you which file to edit: gcluster_ → gbase_8a_gcluster.cnf, gbase_ → gbase_8a_gbase.cnf.
Always verify with SHOW GLOBAL VARIABLES and SHOW VARIABLES to confirm the effective value at global and session levels.

Recommended Workflow

Scenario	Method	Why
Online tuning, instant effect	`SET GLOBAL`	No restart, quick validation
Make permanent, standardize config	Config file + restart	Survives restarts
Temporary debug	`SET SESSION`	Minimal scope, safe
Read‑only parameter change	Config file + restart	Only option

For performance parameters, the best practice is: test with SET GLOBAL first, then persist the winning value in the config file, and restart during a maintenance window to make it stick. This gives you both agility and long‑term stability in your gbase database.

How to Troubleshoot Performance Degradation in GBase 8a

Michael — Sun, 17 May 2026 13:40:00 +0000

When queries start slowing down in your gbase database cluster, a structured approach helps identify the root cause quickly. Work through these six areas, from cluster health to deep log analysis.

Step 1: Check Overall Cluster Health

Start with the cluster status command:

gcadmin showcluster vc <vc_name>

CLUSTER STATE must be ACTIVE. If not, the metadata service (GCware) is likely having issues and the cluster may be locked.
VIRTUAL CLUSTER MODE should be NORMAL. If it's READONLY or RECOVERY, slow performance is expected.
Confirm that gbased, gcluster, and syncserver on each node show OPEN. A CLOSE or OFFLINE status means the node is out of service, shifting load to the remaining nodes.

Step 2: Analyze Resource Usage and Contention

Resource contention is the most frequent cause of sudden performance drops in a gbase database.

Check resource pool load:

  SHOW RESOURCE POOL USAGE ON COORDINATORS WHERE vc_name='<vc_name>';

Watch for cpu_usage_percent near 100%, active_task hitting the max_activetask limit, and mem_usage_mb close to max_memory.

Look for rejected or queued tasks:

  SHOW RESOURCE POOL EVENTS WHERE vc_name='<vc_name>' AND event_time > DATE_SUB(NOW(), INTERVAL 1 HOUR);

A spike in WAITING or REJECTED events proves resource contention.

System-level metrics: SSH into nodes and use top, free -m, iostat to check CPU, memory, and disk I/O. Pay special attention to swap usage.

Step 3: Find the Slow Queries

A single heavy query can impact the whole cluster.

Use GDOM’s “Slow SQL” feature if available.
Identify long-running queries currently executing:

  SELECT * FROM information_schema.processlist 
  WHERE COMMAND = 'EXECUTING' AND TIME > 60 
  ORDER BY TIME DESC LIMIT 10;

Check the STATE column (e.g., Sending data, Sorting result) and the SQL text in INFO.

Inspect slow query logs at $GCLUSTER_HOME/log/gcluster/express.log and $GBASE_HOME/gnode/log/gbase/express.log.
Check for lock contention:

  gcadmin showlock

Look for locks held for an unusually long time.

Step 4: Examine Data Distribution and Storage

Storage-level issues can degrade performance significantly.

Data skew causes uneven load across nodes.

  SELECT table_name, node_ip, SUM(segment_size) 
  FROM information_schema.cluster_table_segments 
  WHERE table_schema='<db_name>' 
  GROUP BY table_name, node_ip 
  ORDER BY SUM(segment_size) DESC;

If one node holds a disproportionately large amount of data, adjust the distribution key.

Disk usage: Disk usage above 80% severely impacts performance.

  df -h /opt/gbase

Table fragmentation: Frequent inserts/deletes can cause fragmentation. Check through GDOM health reports or system tables.

Step 5: Inspect Network and Hardware

Infrastructure problems can mimic database performance issues.

Test latency and bandwidth between nodes with ping and iperf3. An abnormal increase in sync.log size often hints at network trouble.
Check server hardware logs (RAID controllers, disk SMART). Frequent core dumps may indicate unstable hardware:

  ls -lrt /opt/gbase/gcluster/userdata/gcluster/core.* 2>/dev/null
  ls -lrt /opt/gbase/gnode/userdata/gbase/*.dump 2>/dev/null

Step 6: Dig Into Logs and Configuration

When the above steps don't pinpoint the issue, logs are your best friend.

Check system.log (service starts/stops, critical errors) and gcware.log (metadata operations). Search for ERROR, WARNING, timeout, slow.
Verify that key performance parameters haven't been changed recently, such as gbase_parallel_degree and memory settings like gbase_heap_*.

Quick Reference Checklist

Area	Key Command/Method	Likely Fix
Cluster state	`gcadmin showcluster`	Restore GCware if not `ACTIVE`
Resource contention	`SHOW RESOURCE POOL USAGE`	Adjust resource plans or scale out
Slow queries	`processlist`, `express.log`, GDOM	Optimize SQL, add indexes, adjust distribution keys
Lock contention	`gcadmin showlock`	Tune transactions, avoid long locks
Data skew	`cluster_table_segments`	Rebuild table or change distribution column
Disk space	`df -h`	Clean logs/data, expand storage
Network/hardware	`ping`, `iostat`, core dumps	Engage sysadmin

A solid performance baseline combined with regular monitoring makes troubleshooting far easier. When performance deviates, use this structured approach to quickly bring your gbase database back to full speed.

Using the table.list File for Flexible Backup in GBase 8a

Michael — Sun, 17 May 2026 12:33:00 +0000

When backing up specific tables across different databases in GBase 8a, you'll need a table.list file. This file is only required for batch table‑level backups — not for entire VCs or databases. Here's how to use it in your gbase database.

When You Need table.list

The file is mandatory only for the backup tables command. Other backup levels do not use it:

Backup Level	Command (inside gcrcman)	Requires table.list?
Cluster‑level	`backup level 0`	No
Database‑level	`backup database vc1.testdb level 0`	No
Single table	`backup table vc1.testdb.t1 level 0`	No
Batch tables	`backup tables /opt/gbase/table.list level 0`	Yes

So, if you need to selectively back up a set of tables that may span multiple databases or even multiple VCs, table.list is the tool.

Why a File Is Required

Explicit scope: Without a database boundary, the file removes any ambiguity about which tables are included.
Cross‑database and cross‑VC support: The file can list tables from different databases and VCs, which a single backup database command cannot do.
Scripting and automation: Maintaining a list of tables in a file makes it easy to version, modify, and run repeatable backups.
Atomicity and consistency: The whole backup tables job runs as one task; the file defines the complete dataset, helping to achieve a consistent point‑in‑time view.

table.list File Format

Strict rules apply:

One table per line.
Full table name format: [vcname.]dbname.tabname
- vcname: Virtual Cluster name (optional if using the default VC).
- dbname: Database name.
- tabname: Table name.
- Components are separated by a dot ..

Example content:

vc000001.test.t1
vc000001.test.t2
vc000001.test.t3
sales.customer_order   -- uses default VC
hr.employee_salary

Example: Back Up Three Tables

Create the file:

   vi /opt/gbase/backup/table.list

Contents:

   vc1.test.t1
   vc1.test.t2
   vc1.test.t3

Run the backup:

   gcrcman.py -d /opt/gbase/backup -P gbase -p your_password
   gcrcman> backup tables /opt/gbase/backup/table.list level 0

Key Points

File location: The table.list file must reside on the management node running gcrcman and be readable by the executing user.
Validation: If a listed table doesn't exist or the format is incorrect, the backup will fail.
Restore: You restore with the corresponding backup set, not the file itself. The restore command is recover tables ....
Generate automatically: You can create table.list from system tables:

  SELECT CONCAT(table_vc, '.', table_schema, '.', table_name)
  FROM information_schema.tables
  WHERE table_schema IN ('test', 'sales')
  INTO OUTFILE '/tmp/table.list'
  FIELDS TERMINATED BY '' LINES TERMINATED BY '\n';

The table.list file gives you precise control over multi‑table backups in GBASE's MPP cluster. Use it when you need to go beyond single‑database backups and tailor your data protection exactly to your needs.

Safe Node Removal vs. Failed Node Replacement in GBase 8a

Michael — Sun, 17 May 2026 11:28:17 +0000

Shrinking a cluster and replacing a failed node are two fundamental operations in GBase 8a. Both follow a “data safety first” principle, but they differ in goals, procedures, and risk profiles. Here’s how to execute each safely in your gbase database.

How to Safely Remove a Node (Scale In)

The goal is to permanently reduce the cluster size. The rule: move all data off the node first, then remove it.

Create a new Distribution: Edit gcChangeInfo.xml to list only the nodes you want to keep, run gcadmin distribution to build the new map, and execute initnodedatamap.
Run REBALANCE: Migrate data from the old Distribution to the new one. Monitor progress until it reaches 100%:

   SELECT * FROM gclusterdb.rebalancing_status;

Clean up the old Distribution: Drop the old hashmap and Distribution.
Remove the node from the cluster: Edit gcChangeInfo.xml again, this time listing only the departing node’s IP, then execute gcadmin rmnodes to turn it into a Free Node.
(Optional) Uninstall the software completely.

How to Replace a Failed Node

The goal is to maintain the same cluster size while swapping out faulty hardware. There are two modes:

Mode A: Replace with a Freenode (old and new IPs differ).
Mode B: Replace with a brand‑new node (IP must match the old one).

Key steps:

Isolate the failed node:

   gcadmin setnodestate <failed_IP> unavailable
   gcadmin rmfeventlog <failed_IP>

Create a transitional Distribution and move data off: Build a Distribution that excludes the failed node, then rebalance so data remains fully replicated elsewhere.
Execute the replacement command (unique to this operation):

   ./replace.py --host=<failed_IP> --freenode=<new_IP> --type=data --vcname=vc1 --dbaUser=gbase --overwrite

The new node joins and a fresh Distribution is generated automatically.

Second REBALANCE and cleanup: Rebalance again to bring data back onto the new node, then drop the transitional Distribution.
Remove the old node: Now empty, it can be safely deleted.

Comparison at a Glance

Dimension	Remove Node (Scale In)	Replace Failed Node
Goal	Fewer nodes, free resources	Same node count, new hardware
Data flow	One‑way: off the departing node	Two‑way: off the failed node, back onto the new one
New node required?	No	Yes
Key commands	`gcadmin distribution`, `rebalance`, `gcadmin rmnodes`	`gcadmin setnodestate`, `replace.py`, `rebalance`
Distribution changes	One new Distribution (excluding removed node)	Two: transitional (excluding failed node) and final (including new node)
REBALANCE count	1	At least 2
Node state management	Usually direct	Must set to `UNAVAILABLE` first
Risk level	Performance impact during migration	Higher — involves state transitions and potential inconsistency

Golden Rules

Always back up first.
Monitor continuously — watch rebalancing_status and cluster health.
Follow the sequence — especially for replacement: isolate → move off → replace → move back → clean up.
Schedule during off‑peak hours — both operations generate heavy I/O and network traffic.
Mind the IPs — when using a Freenode the IP changes, so update connection configs or DNS accordingly. With a brand‑new node, the IP must remain identical.

Knowing whether you’re “slimming down” or “swapping parts” lets you pick the right playbook and execute node changes safely in your gbase database.

When and Why to Run REBALANCE in GBase 8a

Michael — Sat, 16 May 2026 15:44:00 +0000

The REBALANCE command moves table data from an old distribution map to a new one, aligning physical storage with the latest data layout plan. Beyond fixing uneven data spread, any operation that changes the Distribution requires a manual REBALANCE in your gbase database.

The Core Purpose of REBALANCE

REBALANCE doesn't simply "balance data" — it migrates data to match a new Distribution. Here's the logic:

The cluster's data layout is defined by a Distribution (mapping of segments, nodes, and replicas).
When the Distribution changes (e.g., nodes added or removed), old and new Distributions coexist.
Table data remains tied to the old Distribution.
REBALANCE moves the data from the old Distribution's mapping to the new one, physically relocating rows.

Four Scenarios That Require a Manual REBALANCE

1. Scaling the Cluster (Adding or Removing Nodes)

Adding Data Nodes: Create a new Distribution that includes the new nodes, then REBALANCE shifts a portion of data onto them, rebalancing storage and compute load.
Removing Data Nodes: Create a Distribution that excludes the nodes to be removed, then REBALANCE moves all their data to the remaining nodes before the nodes can be safely taken out.

2. Node Replacement (Failure Recovery)

When replacing a failed data node, two REBALANCE operations are needed:

First REBALANCE: Create a transitional Distribution without the failed node to move its data elsewhere, preserving data completeness.
Second REBALANCE: After the replacement node joins, create a final Distribution that includes the new node and move data back, restoring the original replica layout and high availability.

3. Resource Transfer Between Virtual Clusters (VCs)

When moving node resources between two VCs, REBALANCE is required on both sides:

On VC1, shrink by creating a Distribution without the departing node, REBALANCE data out, then remove the node.
Join the node to VC2.
On VC2, expand by creating a Distribution that includes the new node, REBALANCE data in.

4. Changing Distribution Pattern or Fragment Parameters

If you need to change the distribution pattern (e.g., Pattern 1 → Pattern 2) or adjust fragment parameters (e.g., increasing replicas from 1 to 2), a new Distribution must be created and REBALANCE triggered to reorganize data under the new rules.

When REBALANCE Is NOT Needed

Altering table structure (ALTER TABLE ADD COLUMN) — no physical data movement.
Routine DML (INSERT, DELETE, UPDATE) — handled within the current Distribution.
Coordinator node scaling — affects metadata only, not user data placement.
Service restart without hardware change — Distribution remains unchanged.

REBALANCE Scenarios at a Glance

Scenario	Trigger	Prerequisite	Goal
Scale Up	More nodes	Create Distribution including new nodes	Move data onto new nodes
Scale Down	Fewer nodes	Create Distribution excluding departing nodes	Move data off departing nodes
Node Replacement	Hardware change	Create transitional Distribution without failed node	Move out, replace, move back
Resource Transfer	Node changes VC	Create old/new Distributions on source and target VCs	Migrate data between VCs
Policy Change	Pattern/replica change	Create Distribution with new parameters	Reorganize data under new rules

REBALANCE is the core command for online data reorganization in GBASE's MPP cluster. Any operational change that alters the node‑to‑segment mapping is, at heart, a Distribution change — and must be followed by a REBALANCE to synchronize the physical data. It is always triggered after a new Distribution is created and initialized, and before the old one is dropped. Mastering this command is essential for elastic scaling and advanced operations in a gbase database.

GBase 8a Cluster Modes: NORMAL, READONLY, and RECOVERY Explained

Michael — Sat, 16 May 2026 14:46:00 +0000

GBase 8a MPP Cluster provides three operating modes that control what SQL operations are allowed: NORMAL, READONLY, and RECOVERY. Administrators switch between them manually to match the current operational need — from everyday production to maintenance windows and disaster recovery.

The Three Modes at a Glance

Mode	Allowed SQL	Forbidden SQL	Purpose
NORMAL	Everything: SELECT, DML, DDL, LOAD DATA	Nothing	Day‑to‑day production with full read/write capability.
READONLY	SELECT queries only	All writes: DML, DDL, LOAD DATA	Safe maintenance window — freezes data while keeping queries running.
RECOVERY	Nothing (not even SELECT)	Everything	Extreme data protection during restore or critical repair.

When to Use Each Mode

NORMAL: Default Production Mode

The cluster serves all reads and writes. Major maintenance that could affect consistency or availability should not be performed in this mode.

READONLY: Standard Maintenance & Change Window

This is the go‑to mode for planned operations — effectively a "maintenance mode". Use it for:

Scaling up/down: Prevents concurrent writes during data redistribution.
Node replacement: The cluster can automatically or manually enter read‑only mode when swapping a failed node.
Backups: Ensures a consistent data view for logical backups.
Major application releases: Briefly freeze data while deploying.

RECOVERY: High‑Risk Repair Mode

Reserved for specific recovery scenarios and used only by senior administrators:

Restoring a cluster or VC from backups.
Disaster recovery drills.
Fixing severe logical corruption by importing external repair data.

All connections and queries are rejected in this mode — business is completely interrupted.

Viewing and Switching Modes

Check the Current Mode

gcadmin showcluster vc vc1

Look for the VIRTUAL CLUSTER MODE field in the output.

Switch Modes Manually

# Set the entire cluster to read‑only
gcadmin switchmode readonly

# Set a specific VC to recovery mode
gcadmin switchmode recovery vc vc1

# Return to normal mode
gcadmin switchmode normal

Best Practices

Mode	Frequency	Business Impact	Rule of Thumb
NORMAL	Always on	None	Production runs with full features.
READONLY	Often (maintenance)	Queries unaffected; writes paused	Switch to read‑only before any change.
RECOVERY	Rarely	Full outage	Use recovery only at the foundation level.

Always switch to READONLY before planned maintenance such as node changes or backups.
RECOVERY mode is an "operating room" — notify stakeholders and have a rollback plan.
Mode switches are fast, but schedule them during off‑peak hours when possible.

Using these three modes wisely keeps your gbase database safe and your maintenance operations smooth. It's a simple but powerful part of the GBASE cluster management toolkit.

How GBase 8a Detects and Responds to a GNode Process Crash

Michael — Sat, 16 May 2026 13:46:00 +0000

When a data node (gnode) process exits unexpectedly, GBase 8a's multi‑layer monitoring kicks in automatically. The cluster will try to restart the service, isolate the failed node, switch traffic away, and later resync the data — all without human intervention in most cases.

How Faults Are Detected

Process‑level monitoring (GCMonit) runs on every node, watching core processes like gbased and syncserver. The moment a process dies, GCMonit attempts an automatic restart according to its configuration.
Cluster‑level heartbeat (GCware) tracks every GNode's heartbeat. If heartbeats time out or stop, GCware marks the node's service state as CLOSE.

Automated Response Sequence

Automatic restart — GCMonit tries to relaunch the gbased process immediately. This first line of defense recovers from transient issues like memory spikes.
Service isolation and traffic redirection — If the restart fails, or GCware declares the node dead first, GCware sets the node status to CLOSE and notifies the GCluster coordinator. New queries are then routed exclusively to healthy nodes that hold replicas of the failed node's data. This switch is transparent to applications.
Data consistency repair — Once the node comes back (either via auto‑restart or manual recovery), GCware logs inconsistency events (DML_EVENT / DDL_EVENT). The GCrecover process picks up these events and triggers SyncServer to copy fresh data from healthy replicas to the recovered node until it is fully consistent.

When Manual Intervention Is Needed

The monitoring process itself (GCMonit or gcware_monit) crashes, breaking the auto‑restart chain.
The gbased process fails to start repeatedly due to misconfiguration, disk full, or memory exhaustion.
A majority of GCware nodes fail, locking the cluster and disabling automated recovery.
Routine checks reveal a node stuck in CLOSE or a process permanently DOWN.

Common manual commands:

# Check cluster and node status
gcadmin showcluster vc <vc_name>

# Restart all services on the failed node
gcluster_services all restart

# Inspect the error log
tail -100f /opt/gbase/gnode/log/gbase/system.log

GBase 8a’s multi‑layered automation ensures that a single gnode crash rarely causes a service disruption. In a typical gbase database deployment, the DBA’s role shifts from firefighting to monitoring edge cases where the automated machinery needs a helping hand.

Monitoring Load and Export Task Progress in GBase 8a

Michael — Sat, 16 May 2026 13:01:42 +0000

When you're moving data in and out of GBase 8a, keeping an eye on task progress is crucial. GBASE's MPP database offers great real‑time monitoring for load jobs, while export progress requires a slightly different approach. Here's how to check both.

Monitoring Load Tasks

For LOAD DATA jobs, the primary view is information_schema.load_status.

USE information_schema;
SELECT * FROM load_status;

Key columns:

STATE – current status (RUNNING, FINISHED, FAILED, etc.).
PROGRESS – percentage complete; the most intuitive indicator.
AVG_SPEED – average throughput, useful for performance analysis.
ELAPSED_TIME – time spent so far.
LOADED_SIZE / TOTAL_SIZE – data volume perspective of progress.
LOADED_RECORDS, SKIPPED_RECORDS – row‑level progress and data quality.
DB_NAME, TB_NAME, DATA_SOURCE, SQL_CMD – task context.

Once a load finishes, load_status entries are removed. For historical results, query information_schema.LOAD_RESULT (per coordinator) or CLUSTER_LOAD_RESULT (cluster‑wide). To dig into failures, use SHOW GCLUSTER LOAD LOGS <task_id> for detailed error traces.

Monitoring Export Tasks

GBase 8a doesn't provide a dedicated progress view for SELECT ... INTO OUTFILE. Instead, you rely on:

The process list:

   SELECT * FROM information_schema.processlist
   WHERE COMMAND = 'EXECUTING' AND INFO LIKE '%INTO OUTFILE%';

Check STATE (e.g., SENDING DATA) and TIME to see if the export is still running. However, there's no percentage progress available.

File size at the destination: On the server where the output file is written, run ls -lh periodically. If the file is growing, the export is still underway.

Errors for export tasks are usually reported to the client that issued the command, or you can check express.log (under $GCLUSTER_HOME/log/gcluster/). For very large exports, consider splitting the output into batches and pre‑counting rows to estimate completion.

With these tools, you can stay on top of your gbase database ETL jobs — load monitoring is comprehensive, and export monitoring, while a bit more manual, is straightforward once you know where to look.

How to Audit Only Critical Operations Like DROP TABLE in GBase 8a

Michael — Fri, 15 May 2026 08:24:00 +0000

GBase 8a’s audit log can capture virtually every SQL operation. To keep logs lean and focused on security, you can configure a policy that records only high‑risk actions — like DROP TABLE — using the CREATE AUDIT POLICY command. This post shows you exactly how to set it up in a gbase database.

What the Audit Log Can Record

The audit framework covers all major SQL categories:

DDL: CREATE, ALTER, DROP (including DROP_TABLE, DROP_DB), TRUNCATE, RENAME_USER
DML: SELECT, INSERT, DELETE, UPDATE, LOAD, MERGE
DCL & Users: GRANT, REVOKE, CREATE_USER, DROP_USER
OTHERS: any SQL not explicitly listed

Step‑by‑Step: Record Only High‑Risk Operations

1. Enable Audit Logging to a Table

SET GLOBAL log_output = 'table';
SET GLOBAL audit_log = 1;

-- Verify
SHOW VARIABLES LIKE '%audit_log%';
SHOW VARIABLES LIKE '%log_output%';

2. Create an Audit Policy (the key part)

Use CREATE AUDIT POLICY and list the exact commands you want to capture. Commands must be separated by commas with no spaces.

-- Only record DROP_TABLE, DROP_DB, TRUNCATE, DROP_USER
CREATE AUDIT POLICY audit_critical (
    enable = 'Y',
    sql_commands = 'DROP_TABLE,DROP_DB,TRUNCATE,DROP_USER'
);

3. Test and Verify

Run a forbidden operation and check the log:

DROP TABLE t1;
DROP DATABASE test_db;

SELECT start_time, user_host, sql_command, LEFT(sql_text, 100) AS sql_sample
FROM gbase.audit_log
ORDER BY start_time DESC;

If the policy is correct, you’ll see only DROP_TABLE and DROP_DB events — ordinary SELECT statements won’t appear.

4. Clean Up (Optional)

TRUNCATE SELF audit_log;

Going Further: Fine‑Grained Filtering

You can combine sql_commands with other dimensions for even tighter control:

Parameter	Description	Example
`user`	Limit to a specific user	`user='app_user'`
`hosts`	Filter by IP pattern (supports `%`, `_`)	`hosts='192.168.1.%'`
`db`	Limit to a particular database	`db='finance_db'`
`long_query_time`	Only log slow queries (seconds)	`long_query_time=10`
`status`	Capture only failed or successful ops	`status='FAILED'`

Example: record DROP_TABLE only when executed by admin from host 192.168.1.100 on the prod_db database.

CREATE AUDIT POLICY audit_admin_drop (
    enable = 'Y',
    user = 'admin',
    hosts = '192.168.1.100',
    db = 'prod_db',
    sql_commands = 'DROP_TABLE'
);

With a targeted policy like this, your gbase database keeps a tight security audit trail without drowning in unnecessary log data. It’s a simple but powerful capability every DBA should have in their toolkit.

GBase 8a Data Distribution Strategies: Hash, Random, and Replicated Tables

Michael — Fri, 15 May 2026 07:18:00 +0000

GBase 8a MPP Cluster offers three primary data distribution strategies: Hash distribution, random distribution, and replicated tables. Each determines how data is physically placed across nodes, directly impacting join and aggregation performance in a gbase database.

Strategy Overview

Strategy	Syntax	Distribution Method	Key Feature
Hash	`DISTRIBUTED BY (column)`	Rows with the same column value are mapped to the same node via hash.	Data locality — related rows are physically together, ideal for joins and grouping.
Random	Default (no keyword) or `DISTRIBUTED RANDOMLY`	Data is scattered evenly across all data nodes.	Perfect load balancing — equal data volume and compute pressure on every node.
Replicated	`REPLICATED`	A full copy of the table exists on every data node.	Global redundancy — no network transfer needed for joins.

When to Use Each Strategy

1. Hash Distribution: Large Fact Tables, Frequent Joins

Best for: Huge fact tables like orders or transaction logs that are frequently joined on a specific column (e.g., user_id) or grouped.
Why: Placing matching rows on the same node eliminates cross‑node data shuffling, delivering high‑performance local computation.
Watch out for: Data skew. Picking a low‑cardinality column (e.g., gender) can overload a few nodes. Choose a column with many unique values and even distribution.

2. Random Distribution: Standalone Large Tables or Staging Tables

Best for: Access‑pattern logs, monitoring data, or intermediate ETL tables that are mostly full‑scanned.
Why: Guarantees perfect balance across nodes, maximizing parallel I/O and CPU utilization.
Trade‑off: Joins and groupings will trigger heavy network redistribution, increasing query latency.

3. Replicated Tables: Small Dimension or Lookup Tables

Best for: Small tables (usually under a few GB) like country codes, product categories, or compact user dimensions.
Why: Every node has a full copy, so joins with any distributed table happen entirely locally — the fastest possible join.
Cost: Storage multiplies by the node count, and every insert/update/delete must be applied to all nodes. Suited for read‑mostly or read‑only tables.

Best Practice

Follow the rule: “Large fact tables → Hash, small dimension tables → Replicated, everything else → Random.” Choosing the right strategy and distribution key based on actual query patterns is essential for keeping a gbase database running at peak performance.

Verifying That a GBase 8a Resource Plan Is Active and Enforcing Limits

Michael — Fri, 15 May 2026 06:13:00 +0000

After activating a resource plan on a virtual cluster, a few quick checks will confirm it's working as expected and restricting CPU, memory, and concurrency for the target users in a gbase database.

1. Confirm the Plan Is Active

SELECT * FROM gbase.resource_config;

The activated_plan column for the target VC should show the plan name you just activated (e.g., plan_day).

2. Check User – Consumer Group Mapping

SELECT * FROM gbase.consumer_group_user;

The target user (e.g., UserLoad) must belong to the expected consumer group (e.g., group_load).

3. Check Group – Resource Pool Binding

SELECT * FROM gbase.resource_plan_directive WHERE plan_name = 'plan_day';

You should see a directive that maps the consumer group to the correct resource pool (e.g., low_pool).

4. Monitor Real‑Time Pool Usage (Core Validation)

SHOW RESOURCE POOL USAGE ON COORDINATORS 
WHERE resource_pool_name = 'low_pool' AND vc_name = 'vc1';

Key metrics:

cpu_usage_percent – should not exceed the pool’s defined percentage (e.g., 20%).
mem_usage_mb – must stay below max_memory.
active_task – must not exceed max_activetask.

5. Verify That Tasks Land in the Right Pool

SELECT * FROM information_schema.processlist 
WHERE resource_pool_name = 'low_pool' AND vc = 'vc1';

When the target user runs a query, the RESOURCE_POOL_NAME column should show low_pool.

6. Look for Enforcement Events

SHOW RESOURCE POOL EVENTS WHERE resource_pool_name = 'low_pool' AND vc_name='vc1';

If resources are oversubscribed, you'll see WAITING or REJECTED events — clear evidence the plan is enforcing limits.

7. Proactive Testing

Concurrency limit test: Set max_activetask=2 and launch 3 queries simultaneously. Use SHOW RESOURCE POOL USAGE to confirm active_task never exceeds 2, and the extra task stays in a waiting state.
CPU weight test: Run heavy queries from two users assigned to different pools (e.g., 20% vs. 80%) and watch the CPU usage ratio approach the defined weights.

Verification Checklist

Dimension	Command / Method	Expected Outcome
Plan activation	`SELECT * FROM gbase.resource_config`	`activated_plan` shows the correct plan
User‑group mapping	`SELECT * FROM gbase.consumer_group_user`	User belongs to the intended group
Group‑pool binding	`SELECT * FROM gbase.resource_plan_directive`	Directive links group to target pool
Pool usage	`SHOW RESOURCE POOL USAGE ...`	CPU/memory/task counts within limits
Task routing	`SELECT * FROM processlist ...`	Task’s `RESOURCE_POOL_NAME` is correct
Enforcement events	`SHOW RESOURCE POOL EVENTS ...`	Waiting/rejected events appear when limits are hit

Once all checks pass, you can be confident that the resource plan is fully active and enforcing the desired fine‑grained control in your gbase database.

How GBase 8a Resource Plans Bind to Time Schedules

Michael — Fri, 15 May 2026 05:04:00 +0000

Resource plans in GBase 8a (e.g., plan_day, plan_night) are not directly bound to time and do not support cron expressions. Their automated switching relies entirely on external schedulers — such as Linux crontab — that execute ACTIVE / DEACTIVE commands at the right moment.

Core Mechanism: External Trigger, Internal Execution

A resource plan is just a "policy container" — it takes effect only when activated (ACTIVE). GBase 8a has no built‑in timer, so the full automation chain is:

External scheduler (crontab, etc.) fires at the scheduled time.
A script connects to the database and runs the ACTIVE/DEACTIVE RESOURCE PLAN command.
The plan swap takes effect.

Manual Switching Commands

-- Activate the daytime plan
ACTIVE RESOURCE PLAN plan_day ON VC vc1;

-- Deactivate the current plan
DEACTIVE RESOURCE PLAN ON VC vc1;

-- Activate the nighttime plan
ACTIVE RESOURCE PLAN plan_night ON VC vc1;

Automating with Crontab

Create a switching script (e.g., switch_plan.sh):

#!/bin/bash
GC_CLI_PATH=/opt/gbase/bin/gccli
VC_NAME=vc1
USER=gbase
PASSWORD='your_password'

# Deactivate the current plan, then activate the nighttime plan
$GC_CLI_PATH -u$USER -p$PASSWORD -e "DEACTIVE RESOURCE PLAN ON VC $VC_NAME; ACTIVE RESOURCE PLAN plan_night ON VC $VC_NAME;"

Set up crontab entries:

# Activate daytime plan every day at 8:00 AM
0 8 * * * /opt/gbase/bin/gccli -ugbase -p'password' -e "ACTIVE RESOURCE PLAN plan_day ON VC vc1;"

# Switch to nighttime plan every day at 8:00 PM
0 20 * * * /home/gbase/switch_plan.sh

Make sure the executing user is allowed in /etc/cron.allow.

Why No Built‑in Cron‑Like Scheduler?

Separation of concerns: The database focuses on enforcing resource limits; external tools handle complex scheduling logic.
Flexibility: External scripts can switch plans based on load or other conditions, not just time.
Maintainability: Adjusting switch times only requires changing the external script — no database object modifications, reducing risk.

Production Recommendations

Prefer enterprise scheduling platforms (like GDOM) or job orchestration systems.
Ensure the account running the commands (e.g., gbase) has the necessary privileges.
Add logging and error alerts to your scripts so you can monitor switch events in your gbase database.

This design keeps the gbase database lean and gives you full control over when and how resource plans change.