DEV Community: Michael

Managing the Event Scheduler in GBase 8a

Michael — Mon, 04 May 2026 13:46:00 +0000

The event scheduler (event_scheduler) is the built‑in daemon thread in GBase 8a that runs timed events — think of it as your cron inside the database. It's on by default, and you must have it enabled if you plan to create any scheduled tasks. Here's how to check, start, and stop it in your gbase database.

Checking the Scheduler Status

SHOW VARIABLES LIKE '%event_scheduler%';

If the output shows ON, the scheduler is active and monitoring events.

Enabling the Event Scheduler

Via SQL

SET GLOBAL event_scheduler = ON;
-- or using the session variable syntax
SET @@global.event_scheduler = ON;
-- 1 also means ON
SET GLOBAL event_scheduler = 1;

Via Configuration File

Add the following line under the [gbased] section in gbase_8a_gcluster.cnf:

event_scheduler = 1    # or ON

After enabling, run SHOW PROCESSLIST — you'll see a thread with User: event_scheduler and State: Waiting for event lock, confirming the scheduler is alive.

Disabling the Event Scheduler

Via SQL

SET GLOBAL event_scheduler = OFF;
SET @@global.event_scheduler = 0;
-- 0 and OFF are equivalent

Via Configuration File

In gbase_8a_gbase.cnf, set:

event_scheduler = 0    # or OFF / DISABLED

The scheduler thread disappears from the process list immediately, and all recurring or one‑time events will no longer fire.

Controlling the event scheduler lets you safely pause automation during maintenance windows and resume it when the system is stable — a simple but essential tuning knob for anyone managing a GBASE MPP cluster.

GBase 8a QUALIFY Clause: Filtering Window Functions the Smart Way

Michael — Mon, 04 May 2026 12:37:00 +0000

When you use window functions in SQL, you can't filter their results directly in a WHERE or HAVING clause — that's a well‑known limitation across many databases. GBase 8a, the China‑domestically developed MPP database from GBASE, solves this elegantly with the QUALIFY clause. Let's break down how it works, what it can do, and where you need to be careful.

Sample Table

DROP TABLE IF EXISTS emp;
CREATE TABLE emp (
    id INT,
    name VARCHAR(30) NOT NULL,
    gender VARCHAR(30) NOT NULL,
    sex INT NOT NULL,
    salary INT NOT NULL,
    dept_id INT NOT NULL
);
INSERT INTO emp VALUES(1,'Xiang Yu','Marshal',1,9000,1);
INSERT INTO emp VALUES(2,'Guan Yu','General',1,4000,2);
INSERT INTO emp VALUES(3,'Zhang Fei','Vice General',1,3000,2);
INSERT INTO emp VALUES(4,'Tang Seng','Leader',1,800,3);
INSERT INTO emp VALUES(5,'Wukong','Guard',1,700,3);
INSERT INTO emp VALUES(6,'Liu Bang','Marshal',1,6000,1);

Why QUALIFY Exists

Suppose you want to select the employee with the lowest salary in each department. You'd typically use ROW_NUMBER() and then filter on the result. Without QUALIFY, you have to wrap the query in a subquery:

-- Traditional subquery approach
SELECT * FROM (
    SELECT id, name, dept_id, salary,
           ROW_NUMBER() OVER(PARTITION BY dept_id ORDER BY salary) rwn
    FROM emp
) sub WHERE rwn = 1;

With QUALIFY, it's a single flat query:

SELECT id, name, dept_id, salary,
       ROW_NUMBER() OVER(PARTITION BY dept_id ORDER BY salary) rwn
FROM emp
QUALIFY ROW_NUMBER() OVER(PARTITION BY dept_id ORDER BY salary) = 1;

Versatility of QUALIFY

1. Filtering on a Window Function

SELECT ..., ROW_NUMBER() OVER(...) rwn FROM emp QUALIFY rwn = 1;

2. Filtering on Regular Columns or Functions

You can mix window functions and plain conditions:

SELECT ..., ROW_NUMBER() OVER(...) rwn FROM emp QUALIFY dept_id = 1;
SELECT ..., ROW_NUMBER() OVER(...) rwn FROM emp QUALIFY SUBSTR(dept_id,1,1)='1';

3. Using Column Aliases

QUALIFY recognizes column aliases defined in the SELECT list:

SELECT id, name, dept_id AS f, ROW_NUMBER() OVER(...) rwn FROM emp QUALIFY rwn = 1;
SELECT id, name, dept_id AS f, ROW_NUMBER() OVER(...) rwn FROM emp QUALIFY f = 1;

If you'd like WHERE and HAVING to also accept such aliases, enable:

SET _t_gcluster_support_alias_dependent = 1;

Restrictions and Gotchas

No BLOB or LONG BLOB columns in the QUALIFY condition, for either windowed or plain filters.
A window function must be present somewhere in the query — either in the SELECT list or inside the QUALIFY clause itself. A plain QUALIFY without any window function is illegal:

   -- Wrong
   SELECT id, name, dept_id FROM emp QUALIFY dept_id = 1;
   -- Correct
   SELECT id, name, dept_id, ROW_NUMBER() OVER(...) rwn FROM emp QUALIFY dept_id = 1;

Strict GROUP BY alignment – When GROUP BY is present, columns in the window function's PARTITION BY / ORDER BY must match the GROUP BY columns exactly:

   -- Acceptable: window function only references dept_id
   SELECT dept_id, COUNT(*) FROM emp GROUP BY dept_id
   QUALIFY ROW_NUMBER() OVER(PARTITION BY dept_id ORDER BY id) = 1;

Cannot coexist with HAVING – A query may use either QUALIFY or HAVING, not both.
WHERE comes before QUALIFY – If both are present, WHERE must appear first:

   SELECT ... FROM emp WHERE dept_id = 1 QUALIFY id = 1;

Window functions cannot be used with IN / NOT IN subqueries – The following are invalid:

   QUALIFY rwn IN (SELECT a FROM t1);           -- error
   QUALIFY ROW_NUMBER() OVER(...) IN (SELECT a FROM t1); -- error

However, you can still use subqueries with regular columns inside QUALIFY:

   QUALIFY dept_id IN (SELECT a FROM t1);       -- OK

OR combined with IN subqueries is not allowed – Conditions like rwn=1 OR dept_id IN (...) are rejected. But AND with IN subqueries, OR with equality subqueries, or OR with static lists are fine:

   -- OK
   QUALIFY rwn=1 AND dept_id IN (SELECT ...);
   QUALIFY rwn=1 OR dept_id = (SELECT ...);
   QUALIFY rwn=1 OR dept_id IN (1,2);

Wrap‑Up

The QUALIFY clause makes window‑function filtering natural and removes one layer of nesting from many analytical queries in your gbase database. Just keep the restrictions above in mind, and you'll write cleaner, faster SQL with GBASE's GBase 8a.

Expanding a GBase 8a Cluster: Adding a GNode in Practice

Michael — Mon, 04 May 2026 11:36:00 +0000

As data grows, you'll likely need to add nodes to your existing GBase 8a MPP cluster without downtime. This hands‑on guide walks through the full process of adding a composite GNode to a running GBASE cluster.

Prerequisites

Existing cluster: A healthy GBase 8a cluster
New node: A server with a static IP address configured
Network: All nodes must be able to communicate with each other

Step‑by‑Step

Step 1: Stop the Cluster

Stop services on all existing nodes to guarantee data consistency during the expansion:

gcadmin all stop

Step 2: Configure the New Node's Network

Set up a static IP on the new machine and verify connectivity:

ping 172.16.5.172

Step 3: Set Up the System Environment

On the new node, perform the following:

Create the gbase user and group
Tune system and kernel parameters
Run the SetSysEnv.py environment script
Configure passwordless SSH

Step 4: Edit the Installation Config

Update demo.options with the new node's details:

NEW_NODE_IP=172.16.5.178
NODE_ROLE=gnode
CLUSTER_NAME=my_gcluster

Accept the license agreement and confirm the target node when prompted by the installer.

Step 5: Install and Join the Cluster

Once the software deployment completes automatically, add the node to the cluster:

# Register the node
gcadmin addNode --host=172.16.5.178 --role=gnode

# Verify the node status
gcadmin show cluster

Important Reminders

Backup first: Always back up data before expanding.
Version match: Ensure the new node runs the same software version as the cluster.
Resource planning: Allocate storage and memory appropriately.
Network latency: Keep latency between new and existing nodes within acceptable limits.

Verification

After the expansion, confirm everything is healthy:

# Cluster status
gcadmin all status

# Node connectivity
gcadmin show nodes

# Data distribution
gbase -e "show distribution"

Following these steps, you'll have a smoothly scaled out gbase database cluster — ready to absorb continued data growth with GBASE's distributed engine.

GBase 8s: How DELIMIDENT Controls Case Sensitivity

Michael — Mon, 04 May 2026 10:22:31 +0000

By default, identifiers in GBase 8s are case‑insensitive: uppercase letters are silently treated as lowercase. Setting the environment variable DELIMIDENT=Y changes how double‑quoted identifiers behave, enabling case‑sensitive table and column names. Here's a demonstration and a deep dive into the option, as used in a gbase database.

Testing Case Sensitivity

With DELIMIDENT=y exported, execute the following statements:

export DELIMIDENT=y
dbaccess testdb <<!
-- Uppercase table name, double-quoted
CREATE TABLE "Tab04"(id INT, name VARCHAR(20));
INSERT INTO "Tab04" VALUES(1, 'T DA XIE');

-- Lowercase table name, double-quoted
CREATE TABLE "tab04" (id INT, name VARCHAR(20));
INSERT INTO "tab04" VALUES(1, 't xiao xie');

-- Without double quotes, this collides with the lowercase one (error 310)
CREATE TABLE tab04 (id INT, name VARCHAR(20));  -- fails
!

Query the system catalog to confirm both tables exist:

SELECT tabname FROM systables WHERE tabname LIKE '%ab04%';
-- Returns tab04 and Tab04 (displayed without quotes, but distinguished)

Query behavior:

Unquoted or lowercase‑quoted references all go to the lowercase table tab04:

  SELECT * FROM Tab04;     -- → tab04
  SELECT * FROM tab04;     -- → tab04
  SELECT * FROM "tab04";   -- → tab04

Only an exactly matching double‑quoted uppercase name reaches the uppercase table:

  SELECT * FROM "Tab04";   -- → Tab04

After unsetting DELIMIDENT:

unset DELIMIDENT
dbaccess -e testdb <<!
SELECT * FROM Tab04;       -- → tab04 (still works)
SELECT * FROM tab04;       -- → tab04
SELECT * FROM "tab04";     -- error 201
SELECT * FROM "Tab04";     -- error 201
!

Double‑quote wrapping becomes illegal, so the uppercase table becomes completely unreachable.

Understanding the DELIMIDENT Variable

DELIMIDENT controls whether double quotes enclose an SQL identifier or a plain string. It accepts three configurations:

y (default for OLE DB, .NET) Single quotes '...' denote string literals; double quotes "..." denote SQL identifiers, which become case‑sensitive.
n (default for ESQL/C, JDBC, ODBC) Both single and double quotes denote string literals. Double‑quoted identifiers are not allowed (error 201). One exception: you can use single quotes to qualify an owner name.
Not set The behavior follows the driver‑specific default (e.g., ESQL/C assumes n).

GBase 8s does not offer a way to achieve case‑sensitive identifiers without double quotes. DELIMIDENT=y is the only mechanism, and it requires the identifier to be written exactly as it was created — a small price for clarity in a gbase database.

Going forward, if your application needs to preserve case in table or column names, always set DELIMIDENT=y and standardize on double‑quoted identifiers. This keeps your GBASE environment predictable and avoids silent data‑access mistakes.

Managing Permissions in GBase 8s: From Database-Level to Object-Level Access Control

Michael — Sun, 03 May 2026 15:46:00 +0000

GBase 8s, the China‑domestically developed OLTP database from GBASE, enforces security through two layers of permissions: database‑level and object‑level. Understanding how to grant, revoke, and inspect these privileges is fundamental for every DBA and developer working with a gbase database.

1. Database‑Level Privileges

Database‑level privileges control whether a user can connect and administer a database. They come in three tiers:

CONNECT: The lowest level. Users can run SELECT, INSERT, UPDATE, DELETE, create views and temporary tables.
RESOURCE: Includes all CONNECT privileges, plus the ability to create tables, indexes, and alter/drop their own tables.
DBA: The highest level. Inherits all RESOURCE privileges and can grant or revoke any database‑level privilege to other users, and operate on all database objects.

Grant and Revoke Syntax

GRANT CONNECT TO 'username';
GRANT RESOURCE TO 'username';
GRANT DBA TO 'username';

REVOKE CONNECT FROM 'username';
REVOKE RESOURCE FROM 'username';
REVOKE DBA FROM 'username';

When DBA or RESOURCE is revoked, the user is automatically downgraded to CONNECT. Revoking CONNECT entirely removes the user's access to that database.

Viewing Database‑Level Privileges

Query the sysusers system table; the usertype column shows: C = CONNECT, R = RESOURCE, D = DBA, G = Role, U = Default Role.

SELECT usertype FROM sysusers WHERE username = 'username';

Example: Privilege Escalation and Downgrade

GRANT DBA TO user_i_02;
REVOKE DBA FROM user_i_02;   -- user automatically becomes CONNECT
REVOKE CONNECT FROM user_i_02; -- access removed

2. Object‑Level Privileges (Tables, Views, Routines)

Object privileges grant fine‑grained control. The main permissions are:

Privilege	Applies To	Description
SELECT	Tables, Views	Query data
INSERT	Tables, Views	Insert rows
UPDATE	Tables, Views	Update rows
DELETE	Tables, Views	Delete rows
INDEX	Tables	Create indexes (requires at least RESOURCE)
ALTER	Tables	Modify structure (requires RESOURCE or above)
REFERENCES	Tables	Create foreign key constraints
EXECUTE	Routines	Run stored procedures/functions
ALL	All	All of the above

Important: A CONNECT user cannot use INDEX, ALTER, or REFERENCES even if those privileges are explicitly granted — a RESOURCE level or higher is required.

Grant and Revoke Syntax

-- Table/View privileges
GRANT SELECT, INSERT, UPDATE ON table_name TO user/role;

-- Column‑level privilege
GRANT SELECT (col1, col2) ON table_name TO user;

-- Fragment‑level privilege (for expression‑fragmented tables)
GRANT FRAGMENT INSERT ON table_name (part1, part2) TO user;

-- Routine privilege
GRANT EXECUTE ON procedure_name TO user;

-- Revoke
REVOKE SELECT ON table_name FROM user;

-- WITH GRANT OPTION: allows the grantee to grant the same privilege to others
GRANT SELECT ON table_name TO user WITH GRANT OPTION;

-- AS GRANTOR: specify the grantor; only that grantor can later revoke
GRANT SELECT ON table_name TO user AS grantor_name;

Inspecting Object Privileges

-- Table/View privileges (tabauth codes: s=SELECT, u=UPDATE, i=INSERT, d=DELETE, x=INDEX, a=ALTER, r=REFERENCES)
SELECT a.grantor, a.grantee, b.tabname, a.tabauth
FROM systabauth a
JOIN systables b ON a.tabid = b.tabid
WHERE b.tabname = 'table_name';

-- Column privileges
SELECT a.grantor, a.grantee, b.tabname, a.colno, a.colauth
FROM syscolauth a
JOIN systables b ON a.tabid = b.tabid
WHERE b.tabname = 'table_name';

-- Routine privileges
SELECT b.*
FROM sysprocedures a
JOIN sysprocauth b ON a.procid = b.procid
WHERE a.procname = 'proc_name';

Privilege letters appear uppercase in systabauth.tabauth when granted with WITH GRANT OPTION (meaning transferable), and lowercase otherwise.

3. The Public User

GBase 8s has a built‑in public user. Every database user's effective privileges = public privileges + their own. By default, public has SELECT, INSERT, UPDATE, DELETE, and INDEX on all tables. DBAs can tighten security by revoking defaults:

REVOKE ALL ON table_name FROM PUBLIC;

Combining database‑level and object‑level permissions gives you a powerful, layered security model. Mastering these commands will help you lock down your gbase database environment while keeping development and operations running smoothly.

End-to-End: Hadoop Deployment and Data Loading into GBase 8a

Michael — Sun, 03 May 2026 15:13:00 +0000

This post walks through setting up a distributed Hadoop cluster from scratch and loading data from HDFS into GBase 8a, GBASE's China-domestically developed MPP database. The full pipeline covers environment prep, config tweaks, cluster verification, and the final load command.

1. Environment Setup

Hadoop User and SSH

Create a hadoop user on all nodes and configure passwordless SSH.

Environment Variables

Add Java and Hadoop paths to ~/.bash_profile on every node:

export JAVA_HOME=/home/hadoop/hadoop/jdk1.8.0_333
export HADOOP_HOME=/data1/hadoop/hadoop-3.4.2
export PATH=$PATH:$JAVA_HOME/bin:$HADOOP_HOME/bin:$HADOOP_HOME/sbin
...

/etc/hosts

All nodes — including the GBase 8a cluster — must be able to resolve hostnames:

192.168.28.201 hadoopnode1
192.168.28.202 hadoopnode2
192.168.28.203 hadoopnode3

2. Hadoop Configuration

All config files live under ${HADOOP_HOME}/etc/hadoop/.

core-site.xml — Default FS and temp directory

<property>
  <name>fs.defaultFS</name>
  <value>hdfs://hadoopnode1:9000</value>
</property>
<property>
  <name>hadoop.tmp.dir</name>
  <value>file:/data1/hadoop/data/tmp</value>
</property>

hdfs-site.xml — Storage directories and replication

<property>
  <name>dfs.namenode.name.dir</name>
  <value>file:/data1/hadoop/data/namenode</value>
</property>
<property>
  <name>dfs.datanode.data.dir</name>
  <value>file:/data1/hadoop/data/data</value>
</property>
<property>
  <name>dfs.replication</name>
  <value>3</value>
</property>

mapred-site.xml — Yarn as the execution framework

<property>
  <name>mapreduce.framework.name</name>
  <value>yarn</value>
</property>

workers — DataNode list

hadoopnode1
hadoopnode2
hadoopnode3

Push the configs to all nodes with scp.

3. Start and Verify the Cluster

Format the NameNode: hdfs namenode -format
Start everything: start-all.sh
Check with jps — you should see NameNode, DataNode, ResourceManager, and NodeManagers across the three nodes.

4. HDFS Smoke Test

hdfs dfs -mkdir -p /mytest
echo "1234567" > hdfs_put_test.txt
hdfs dfs -put /home/hadoop/hdfs_put_test.txt /mytest
hadoop fs -ls hdfs://hadoopnode1:9000/mytest/hdfs_put_test.txt

5. Loading Data into GBase 8a

Once the table exists in your gbase database, a single LOAD DATA INFILE command pulls the data from HDFS:

LOAD DATA INFILE 'hdfs://hadoop:hadoop@hadoopnode1:9870/mytest/hdfs_put_test.txt'
INTO TABLE hdfs_load_test
DATA_FORMAT 3;

Result: Loaded 1 records, confirming the full path from HDFS to GBase 8a works end‑to‑end. This integration pattern is great for batch ETL workflows in independently controlled data platforms.

Optimizing GBase 8s JDBC with the OPTOFC Parameter

Michael — Sun, 03 May 2026 14:15:00 +0000

OPTOFC (optimize-OPEN-FETCH-CLOSE) is a JDBC option in GBASE's GBase 8s that reduces network round trips when executing SELECT statements with PreparedStatement. This post explains how it works and demonstrates the real performance gain with benchmarks.

When OPTOFC Takes Effect

The optimization kicks in only when all of the following are true:

The statement is a PreparedStatement instance.
The query is a SELECT.
The ResultSet type is TYPE_FORWARD_ONLY.
The concurrency mode is CONCUR_READ_ONLY.

What It Does

Merges OPEN and FETCH messages — Normally these are two separate network requests. With OPTOFC, they are sent together, saving one round trip. (Without variable‑length columns the driver may already merge them; with variable‑length columns you must enable OPTOFC=1 to force the merge.)
Auto‑closes the cursor — If all rows are fetched from the server, the server closes the cursor automatically. The subsequent ResultSet.close() call then avoids an extra network request.

How to Enable It

Add OPTOFC=1 to the JDBC URL:

jdbc:gbasedbt-sqli://192.168.226.180:12888/testdb:OPTOFC=1

Performance Benchmarks

The tests ran the same SELECT * query 1,000 times inside a loop. Two tables were used: t1(name varchar(10)) (variable‑length) and t2(name char(10)) (fixed‑length).

Example 1 — Fixed‑length column (char)

Without OPTOFC: 2,822 ms
With OPTOFC=1: 1,697 ms — ~40% faster

Example 2 — Variable‑length column (varchar)

Without OPTOFC: 2,276 ms (base is lower because OPEN/FETCH are merged by default for varchar)
With OPTOFC=1: 1,679 ms — still about 26% faster

Example 3 — When it does NOT work (TYPE_SCROLL_INSENSITIVE)

The URL included OPTOFC=1 but the ResultSet type was set to TYPE_SCROLL_INSENSITIVE, breaking condition 3. Execution time stayed at 2,848 ms — identical to the unoptimized path.

Key Takeaway

OPTOFC=1 delivers a measurable speedup for forward‑only, read‑only SELECT queries, especially when variable‑length columns are involved. It's a simple URL change with no code modifications required, making it a low‑effort win for many gbase database applications.

If you're using GBase 8s in a JDBC workload, check your ResultSet types and connection strings — you might be leaving free performance on the table.

GBase 8a Statistics Tables: Understanding gc_stats_table and gc_stats_column

Michael — Sun, 03 May 2026 13:13:50 +0000

The query optimizer in GBase 8a, the China‑domestically developed MPP database from GBASE, relies heavily on statistics to choose efficient execution plans. Those statistics live in two system tables: gclusterdb.gc_stats_table for table‑level row counts, and gclusterdb.gc_stats_column for column‑level distributions. Let's break down what they store, how the numbers are calculated, and which parameters matter most.

1. Table‑Level Stats: gc_stats_table

This table holds the estimated row count and the last collection timestamp for each table.

SELECT * FROM gc_stats_table WHERE db = 'tpch1t';

Sample output:

db	table_name	tuples	timestamp
tpch1t	lineitem	5999989709	2023-12-29 11:37:05
tpch1t	orders	1500000000	2023-12-29 11:47:35
tpch1t	part	200000000	2023-12-29 11:49:58
...	...	...	...

The tuples column guides cost estimation and join ordering across the gbase database.

2. Column‑Level Stats: gc_stats_column

Column statistics are stored in gclusterdb.gc_stats_column with the following schema:

DESC gclusterdb.gc_stats_column;

Column	Type	Description
db	varchar(64)	Database name
table_name	varchar(64)	Table name
column_name	varchar(64)	Column name
null_frac	float	Fraction of null values
avg_width	int(11)	Average width (variable‑length types only)
n_distinct	float	Distinct count (positive) or ratio (negative)
mcv_vals	varchar(10922)	Most common values list
mcv_freqs	varchar(10922)	Frequencies of those values
histogram	varchar(10922)	Histogram boundaries (numeric columns)

How the Key Columns Are Computed

null_frac: null rows / sampled rows.
avg_width: Applies only to variable‑length columns (VARCHAR, etc.) — computed as SELECT AVG(LENGTH(c1)) FROM table.
n_distinct: If positive, it represents COUNT(DISTINCT c1). If negative, it's the ratio COUNT(DISTINCT c1) / COUNT(*), used when the ratio exceeds 10%.
mcv_vals & mcv_freqs: The most frequent values and their frequencies, limited to the number specified by gcluster_statistics_target (default 25). Queries: SELECT v, COUNT(col)/COUNT(*) FROM table GROUP BY v ORDER BY COUNT(*) DESC LIMIT 25.
histogram: Equi‑height histogram boundaries, only for numeric types. The number of bins equals gcluster_statistics_target. Algorithm:
1. bucket_size = COUNT(*) / gcluster_statistics_target;
2. After sorting values, record the minimum of every bucket_size‑th row to define left‑closed, right‑open intervals.

3. Important Parameters

gcluster_statistics_sampling_threshold: Tables with fewer rows are scanned entirely; larger tables are sampled randomly.
gcluster_statistics_target: Controls the number of MCV entries and histogram bins; the default is usually fine.
gcluster_analyze_relative_error: Desired relative error for statistical approximations.

By understanding these two statistics tables and their parameters, you can better evaluate query plans and keep your gbase database performing well — a must‑have skill for any DBA working with GBASE's analytical engine.

Inside GBase 8a Data Consistency: ddlevent, dmlevent, dmlstorageevent

Michael — Sat, 02 May 2026 15:40:00 +0000

In a GBase 8a distributed cluster, data consistency between primary and standby nodes is critical for service stability. Three event types — ddlevent, dmlevent, and dmlstorageevent — act as the core messengers for synchronization and recovery. Together with the gcrecover process, they form a layered assurance system. This article analyzes their roles, triggers, and collaborative logic.

1. Core Positioning: Essential Differences

All three events are triggered by the GBase 8a kernel to record differences between primary and standby nodes, but they focus on entirely different inconsistency scenarios and processing priorities:

Event Type	Core Purpose	Inconsistency Focus	Data Carrier
ddlevent	Metadata sync & repair	Table structure, indexes, partition differences	DDL operation logs
dmlevent	Business data sync & repair	Row data differences from INSERT/UPDATE/DELETE	DML operation records
dmlstorageevent	Storage-level emergency repair	Storage anomalies dmlevent cannot fix	Data/metadata file repair instructions

2. Trigger Mechanism: Layered and Progressive

Event triggering follows a progressive principle: handle regular data differences first, then extreme storage failures.

dmlevent: DML-Induced Data Differences

The most frequently triggered event, addressing business data inconsistency:

Log sync delays or network jitter causing standby data lag;
Standby node coming back online after temporary disconnection;
Row-level data hash mismatches during primary-standby validation.

After triggering, it records the full DML operation context, which gcrecover replays on the standby.

ddlevent: DDL-Induced Metadata Differences

Handles structural differences from DDL. Its priority is higher than dmlevent — metadata inconsistency prevents DML execution:

Standby metadata not synced after ALTER TABLE or CREATE INDEX;
Corrupted standby metadata files;
Metadata differences after cluster expansion.

dmlstorageevent: The Last Line of Defense

Automatically triggers when dmlevent fails, addressing storage-layer faults:

Standby table physical files corrupted or deleted;
Standby metadata files unreadable;
Data block checksum failures during dmlevent replay.

Once triggered, the system skips regular DML replay and performs storage-level repair, such as full sync of table files from the primary.

3. Collaborative Logic: How gcrecover Schedules Events

gcrecover is the executor. Its scheduling logic has three steps:

Collection and Sorting: Events are sorted by ddlevent first > timestamp ascending;
Differentiated Repair:
- ddlevent: Replay DDL on standby, or pull complete metadata files from primary;
- dmlevent: Locate target rows by primary key and execute corresponding DML;
- dmlstorageevent: Validate storage status; if tables are missing, perform a full sync; if files are corrupted, perform file-level repair;
Result Feedback: Failed events enter a retry queue. After 3 failed retries, an alert is triggered.

4. Operational Practice: Monitoring and Diagnosis

1. Check the Event Queue

SELECT event_type, event_status, create_time, target_table 
FROM gbase.gcluster_event_queue 
WHERE event_status = 'PENDING';

2. Identify Failure Causes

SELECT error_msg, event_content 
FROM gbase.gcluster_event_queue 
WHERE event_status = 'FAILED' AND event_type = 'dmlstorageevent';

Common failures: full standby disk, network interruption, insufficient table permissions.

3. Manually Trigger Event Repair

CALL gbase.gcrecover_event_process('ddlevent');

5. Key Takeaways

Layered assurance: ddlevent protects structure, dmlevent protects data, dmlstorageevent protects storage;
Clear prioritization: Metadata first, regular before extreme;
Ops focus: Prioritize monitoring FAILED dmlstorageevents, which often point to hardware faults or severe metadata issues.

Understanding how these three event types work is fundamental to quickly diagnosing primary-standby inconsistencies and keeping a GBase 8a gbase database running reliably.

GBase 8a High Availability Explained: How Three-Layer Redundancy Keeps Your Data Services Running

Michael — Sat, 02 May 2026 14:27:00 +0000

For finance, retail, and other mission‑critical workloads, an analytical database must deliver continuous service. GBase 8a, the China‑domestically developed distributed analytical database from GBASE, achieves this through coordinated redundancy across its control nodes, data nodes, and the data layer — delivering second‑level failover and zero data loss. This article breaks down the implementation, key benefits, and how it stacks up against other platforms.

1. What High Availability Means for Analytical Databases

High availability (HA) focuses on limiting service interruption (MTTR) and ensuring data consistency in the face of hardware failures or network partitions. The enterprise benchmark is 99.99% availability, equivalent to no more than 53 minutes of downtime per year. For analytical databases, HA must prioritize computational continuity and shard safety rather than just transactional ACID — exactly what GBase 8a is built for.

2. The Three‑Layer HA Architecture

2.1 Control Nodes (CN): Hot Standby + Automatic Failover

Control nodes manage request distribution and result aggregation. They run in active‑standby mode:

Real‑time sync: configuration and task state replicated continuously;
Heartbeat detection: every 1 second;
Automatic switch: failure detected within 3 seconds, service taken over by the standby within 10 seconds, transparent to clients.

2.2 Data Nodes (DN): Multi‑Replication + Fault Isolation

Data nodes store and process data. Their HA relies on replication and isolation:

Multi‑replication: default 3 copies, deployable across servers / racks, no data loss from a single node failure;
Automatic isolation: failed nodes are quarantined immediately, work redistributed;
Dynamic recovery and expansion: repaired nodes rejoin via incremental sync; new nodes can be added online with automatic data rebalancing — no service interruption.

2.3 Data Layer: Logging, Backup, and Validation

The data layer ensures consistency and recoverability:

Redo Log: writes are logged before execution, enabling crash recovery;
Backup and PITR: full plus incremental backups, point‑in‑time recovery for any time;
Data validation: periodic integrity checks to detect and repair corruption caused by disk issues.

3. What Problems Does This Solve?

Service disruption: a failed data node is isolated within 5 seconds; analytical queries continue seamlessly. Traditional databases can take hours to recover.
Data loss risk: with replicas spread across rooms/machines, even extreme scenarios (e.g., UPS failure) cause zero data loss — meeting financial compliance.
Operational complexity: fully automated HA mechanisms. In one government platform, ops workload dropped by 60%, and recovery time shrank from hours to seconds.

4. How GBase 8a Compares to Other Analytical Databases

Feature	GBase 8a	Hive	Impala	Greenplum
CN HA	Hot standby, ≤10s switch	Relies on HiveServer2, ≥30s	Catalog SPOF, extra HA needed	Master‑standby, ~20s switch
DN fault tolerance	Multi‑replica + auto‑isolation	Dependent on HDFS, re‑run tasks	No built‑in replica, impacts jobs	Standby segments, manual recovery
Recovery speed	Seconds, incremental sync	Minutes, batch re‑run	Minutes, job re‑run	Minutes, full sync
Data consistency	Strong (Redo Log)	Eventual	Eventual	Strong, but recovery has risks
Ops complexity	Fully automatic, no external deps	Hadoop stack required	HDFS dependency	Needs expert team

GBase 8a’s HA stands out for its speed, stability, and simplicity — second‑level failover, multi‑layer redundancy, and automation — making it a strong fit for large‑scale enterprise deployment.

Looking ahead, as organizations increasingly rely on real‑time analytics over massive, ever‑growing datasets, a gbase database with such integrated HA capabilities will help teams meet their availability SLAs without the heavy operational burden typical of open‑source alternatives.

A Practical Guide to the ISNULL() Function in GBase 8s

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

ISNULL() is a core function in GBase 8s for handling NULL values. It works in two modes — single‑argument and double‑argument — with clean, predictable behavior.

Function Characteristics

Two‑Argument Form: `ISNULL(a, b)`

Returns the first non‑NULL value from left to right.
If a is not NULL, returns a; otherwise returns b.
If both arguments are NULL, returns an empty value.

Single‑Argument Form: `ISNULL(a)`

Returns a boolean: t or f.
Returns t if a is NULL; otherwise returns f.
Can be cast to VARCHAR and other character types.

Examples

Two‑Argument Examples

-- Expected: 12
SELECT ISNULL(12, NULL) FROM dual;

-- Expected: aa
SELECT ISNULL(NULL, 'aa') FROM dual;

-- Expected: (empty)
SELECT ISNULL(NULL, NULL) FROM dual;

-- Expected: abc (nested call)
SELECT ISNULL(ISNULL('abc', NULL), 'ef') FROM dual;

Single‑Argument Examples

-- Expected: f
SELECT ISNULL('aa') FROM dual;

-- Expected: t
SELECT ISNULL(NULL) FROM dual;

-- Note: 'null' is a string, not NULL — returns f
SELECT ISNULL('null') FROM dual;

Real‑World Scenario: Filtering NULLs in a CTE

The following query demonstrates how ISNULL() works inside Common Table Expressions (CTEs) in a gbase database.

DROP TABLE IF EXISTS t1;
CREATE TABLE t1 (
    id   INT,
    col1 INT,
    col2 INT
);
INSERT INTO t1 VALUES(1, 1, 1);
INSERT INTO t1 VALUES(2, NULL, NULL);
INSERT INTO t1 VALUES(3, 4, 4);
INSERT INTO t1 VALUES(4, 0, 0);

WITH tmp1 AS (
    SELECT id, col1, ISNULL(col1), SUM(col2) AS total_col2
    FROM t1
    GROUP BY id, col1
),
tmp2 AS (
    SELECT id, col1, ISNULL(tmp1.total_col2) AS null_col2
    FROM tmp1
    WHERE id > 1 AND ISNULL(col1) = 't'
)
SELECT dt.id, dt.col1, dt.null_col2
FROM tmp2 dt;

Expected result:

id  col1   null_col2
--  ----   ---------
2   NULL   1

ISNULL(col1) = 't' accurately filters rows where col1 is NULL, while ISNULL(total_col2) returns t when SUM over an empty set yields NULL, aiding downstream logic.

Mastering both forms of ISNULL() — as a replacement for NULLs and as a NULL detector — keeps your SQL logic in GBASE's GBase 8s cleaner and more readable.

GBase 8c High Availability with VIP: A Step-by-Step Verification Guide

Michael — Sat, 02 May 2026 13:10:50 +0000

This walkthrough demonstrates how to deploy a GBase 8c primary‑standby cluster with a virtual IP (VIP) and verify automatic failover. GBase 8c is a China‑domestically developed database from GBASE, designed for transactional workloads.

Environment

IP	Hostname	Role
10.x.x.31	gbase8c_7_31	Primary
10.x.x.35	gbase8c_7_35	Standby
10.x.x.34	-	VIP

Package: GBase8cV5_S5.0.0B28_centos7.8_x86_64.tar.gz

Pre‑Installation (Both Nodes)

Update /etc/hosts with hostname entries.
Disable firewall and SELinux.
Install dependencies: expect, bzip2.
Create user gbase with sudo privileges.
Set up passwordless SSH for both root and gbase between nodes.

Silent Installation

On the primary node, create /data/install_package, upload and extract the tarballs.
Prepare an XML cluster configuration file defining node names, IPs, directories, and CM server settings.
Run gs_preinstall as root with the XML file.
Change ownership to gbase, then run gs_install to complete deployment.
Confirm the cluster is Normal with gs_om -t status --detail. You should see one Primary and one Standby datanode.

Configuring the Virtual IP

Add a VIP resource named CM_VIP with the floating address:

   cm_ctl res --add --res_name="CM_VIP" --res_attr="resources_type=VIP,float_ip=10.x.x.34"

Bind each node to an instance of the VIP:

   cm_ctl res --edit --res_name="CM_VIP" --add_inst="res_instance_id=6001,node_id=1" --inst_attr="base_ip=10.x.x.31"
   cm_ctl res --edit --res_name="CM_VIP" --add_inst="res_instance_id=6002,node_id=2" --inst_attr="base_ip=10.x.x.35"

Set CM parameters for failover (adjust the gateway to your environment):

   cm_ctl set --param --server -k "cms_enable_failover_on2nodes=1"
   cm_ctl set --param --server -k "cms_network_isolation_timeout=10"
   cm_ctl set --param --server -k "cms_enable_db_crash_recovery=1"
   cm_ctl set --param --server -k "third_party_gateway_ip=10.x.x.1"

Restart the database. Afterwards cm_ctl show and ip a should display the VIP on the primary.

High Availability Validation

Planned Switchover

Run cm_ctl switchover -n 2 -D /data/gbasedb/database/data/dn on the primary. The standby becomes the new primary, and the VIP floats accordingly. Switch back with -n 1.

Automatic Failover

Reboot the current primary node. The standby automatically promotes to Primary; the VIP drifts to the new primary, and the cluster returns to a healthy state.

This process confirms that your GBase 8c high‑availability setup works correctly. The VIP ensures client connections automatically redirect to the current primary, keeping your gbase database available during both planned and unplanned outages.