GBase 8a's audit architecture relies on two key system tables: audit_log and audit_log_express. They form a "local source → centralized archive" relationship. A built‑in scheduled job automatically aggregates audit records from every node into a single cluster‑wide view, enabling both global querying and automatic data aging.

The Two Tables at a Glance

audit_log is where raw logs first land, one copy per node. audit_log_express is the consolidated warehouse for all those records.

How Data Flows Between Them

The entire flow is driven by a system‑created event called import_audit_log.

1. Automatic setup: During cluster installation or upgrade, the system creates the audit_log_express table and the import_audit_log event.
2. Daily schedule: The event runs once per day, exporting new records from gbase.audit_log on all nodes and merging them into audit_log_express.
3. Built‑in aging: audit_log_express has a lifecycle policy that automatically deletes records older than 31 days.

Multi‑VC Configuration

In a multi‑Virtual Cluster environment, you must manually bind the import_audit_log event to the correct VC. Without this step, the VC's audit logs won't be collected.

-- Find the VC ID
SHOW VCS;

-- Update the event's VC (run in the gbase database)
UPDATE gbase.event SET vc_id = 'vc00001' WHERE name = 'import_audit_log';

Operational Best Practices

• Query audit_log_express for daily audits — it's the complete, query‑friendly view without touching production nodes.
• Use TRUNCATE SELF audit_log to safely clear local logs.
• In multi‑VC setups, always verify the vc_id of import_audit_log right after deployment.

This design gives your gbase database a lightweight yet powerful audit pipeline: write locally, query globally, and age automatically. It's a solid foundation for compliance and operational visibility in any GBASE environment.