​
Database Rule Trigger Configuration Guide

​
Rule Setup Flow

​
1. DB Instances (Required First Step)

Select which database instances this rule will monitor. Interface: Dropdown with checkboxes
  • Select All: Choose all available instances at once
  • Individual Selection: Pick specific instances
  • Impact: Your selection here determines what databases and users appear in trigger dropdowns later

​
2. Triggers (Up to 3 Maximum)

Configure conditions that will activate your rule. All triggers use AND logic - ALL must be true simultaneously.

​
Trigger Type (Required)

Choose what aspect of database activity to monitor:

​
Connection idle time

Monitors connections in “sleep” state. Operator Options:
  • Greater Than: Trigger when idle time exceeds value
  • Less Than: Trigger when idle time is below value
Value: Enter time in seconds Example: Greater Than 600 = Trigger for connections idle over 10 minutes Use Cases:
  • Free up memory from abandoned connections
  • Prevent connection pool exhaustion
  • Clean up development/test connections

​
Connection utilization

Monitors database connection pool usage as percentage (%) of maximum. Operator Options:
  • Greater Than: Trigger when usage exceeds percentage
  • Less Than: Trigger when usage falls below percentage
Value: Enter percentage (0-100) Example: Greater Than 80 = Trigger when 80% of connections are in use Use Cases:
  • Prevent “too many connections” errors
  • Proactive connection pool management
  • Emergency connection cleanup during high load

​
Query duration

Monitors how long queries have been running. Operator Options:
  • Greater Than: Trigger when runtime exceeds duration
  • Less Than: Trigger when runtime is below duration
Value: Enter time in seconds Example: Greater Than 30 = Kill queries running longer than 30 seconds Use Cases:
  • Stop running queries that slow the database
  • Enforce query timeout policies
  • Performance protection

​
Query pattern

Matches running queries against patterns using SQL LIKE syntax. Interface: Manual text entry Pattern Behavior:
  • The system is case-insensitive and automatically removes semicolons before matching
  • Use % wildcard to represent any content: select % from table_name
  • Patterns must match query structure exactly (except case and semicolons)
  • ⚠️ Critical: Rule will NOT work with different spacing/formatting such as extra spaces or different line breaks
Operator Options:
  • Like: Trigger when queries match any pattern
  • Not Like: Trigger when queries don’t match any pattern
Value: Enter SQL patterns using % (any characters) Examples:
  • Security: Like: %DROP TABLE% - Block destructive operations
  • Performance: Not Like: %limit% - Block inefficient queries
  • Compliance: Like: %SELECT * FROM salary% - Monitor sensitive data access

​
Complex Pattern Examples

Example 1: Simple Query with Wildcards Your rule query pattern: 
SELECT e.lastName, e.firstName, p.amount,pg_sleep(%)  FROM employees e JOIN customers c ON e.employeeNumber = c.salesRepEmployeeNumber JOIN payments p ON c.customerNumber = p.customerNumber WHERE p.amount < 1000 limit 1;
✅ This WILL work (case variations): 
select e.lastname, e.firstname, p.amount,pg_sleep(10)  from employees e join customers c on e.employeenumber = c.salesrepemployeenumber join payments p on c.customernumber = p.customernumber where p.amount < 1000 limit 1;
❌ This will NOT work (extra spaces): 
SELECT e.lastName,    e.firstName  , p.amount,   pg_sleep(10)  FROM employees e JOIN customers c ON e.employeeNumber = c.salesRepEmployeeNumber JOIN payments p ON c.customerNumber = p.customerNumber WHERE p.amount < 1000 limit 1;
❌ This will NOT work (line breaks): 
select e.lastname, e.firstname, p.amount,pg_sleep(10)
from employees e join customers c on e.employeenumber = c.salesrepemployeenumber
join payments p on c.customernumber = p.customernumber
where p.amount < 1000 limit 1;
Example 2: Multi-line Query with Multiple Wildcards Original Query: 
-- ORIGINAL QUERY
SELECT 
    c.[customer_id],
    c.[first_name] + ' ' + c.[last_name] AS [full_name],
    cat.[category_name],
    p.[product_name],
    p.[price],
    oi.[quantity],
    (oi.[quantity] * p.[price]) AS [line_total],
    o.[order_date],
    r.[rating],
    r.[review_text],
    CASE 
        WHEN r.[rating] >= 4 THEN 'Positive'
        WHEN r.[rating] = 3 THEN 'Neutral'
        ELSE 'Negative'
    END AS [review_sentiment]
FROM [customers] c
INNER JOIN [orders] o ON c.[customer_id] = o.[customer_id]
INNER JOIN [order_items] oi ON o.[order_id] = oi.[order_id]
INNER JOIN [products] p ON oi.[product_id] = p.[product_id]
LEFT JOIN [categories] cat ON p.[category_id] = cat.[category_id]
LEFT JOIN [reviews] r ON p.[product_id] = r.[product_id] 
    AND c.[customer_id] = r.[customer_id]
WHERE o.[order_date] >= '2023-01-01'
    AND p.[price] > 50.00
    AND c.[country] IN ('USA', 'Canada', 'UK')
Rule Pattern (to catch any date, price, and country variations): 
SELECT 
    c.[customer_id],
    c.[first_name] + ' ' + c.[last_name] AS [full_name],
    cat.[category_name],
    p.[product_name],
    p.[price],
    oi.[quantity],
    (oi.[quantity] * p.[price]) AS [line_total],
    o.[order_date],
    r.[rating],
    r.[review_text],
    CASE 
        WHEN r.[rating] >= 4 THEN 'Positive'
        WHEN r.[rating] = 3 THEN 'Neutral'
        ELSE 'Negative'
    END AS [review_sentiment]
FROM [customers] c
INNER JOIN [orders] o ON c.[customer_id] = o.[customer_id]
INNER JOIN [order_items] oi ON o.[order_id] = oi.[order_id]
INNER JOIN [products] p ON oi.[product_id] = p.[product_id]
LEFT JOIN [categories] cat ON p.[category_id] = cat.[category_id]
LEFT JOIN [reviews] r ON p.[product_id] = r.[product_id] 
    AND c.[customer_id] = r.[customer_id]
WHERE o.[order_date] >= %
    AND p.[price] > %
    AND c.[country] IN (%)
Key Points:
  • Exact line break formatting preserved between original and pattern
  • Multiple wildcards (%) used for flexible matching on dates, prices, and countries
  • Comments preserved to maintain exact structure
  • All spacing and indentation must match exactly
❌ Reverse case - if original query HAS line breaks, rule pattern WITHOUT line breaks will also NOT work:
  • Original query (with line breaks): Won’t match a single-line pattern
  • Rule pattern (single line): Won’t catch queries that have line breaks
  • Solution: Pattern formatting must match the actual query formatting exactly

​
Best Practices for Copy-Paste Query Patterns

Recommended Sources (ensures exact spacing and formatting):
  • Copy query from Rapydo Application (Query workspace | Dashboard slowest reports)
  • Copy from Query Logs/Monitoring:
    • Database query logs
    • Application logs
    • Query monitoring tools (Rapydo)
    • Database audit trails
Why This Matters: This ensures the exact spacing and formatting that will actually be executed, preventing pattern matching failures due to formatting differences.

​
DB name

Triggers based on which database is being accessed. Interface: Dropdown (shows databases from selected instances only)
  • Search Function: Find specific databases quickly
  • Select All: Choose all databases that are in the dropdown
Operator Options:
  • In: Trigger for activity on specified databases
  • Not In: Trigger for activity NOT on specified databases
Examples:
  • Production protection: In “production_db” - Apply strict rules to production
  • Development monitoring: Not In “dev_db,test_db” - Monitor non-dev access

​
User

Triggers based on which database user is running processes. Interface: Dropdown (shows users from selected instances only)
  • Search Function: Find specific users quickly
  • Select All: Choose all users that are in the dropdown
  • Shared Indicators: Shows users shared across instances
Operator Options:
  • In: Trigger for processes from specified users
  • Not In: Trigger for processes NOT from specified users
Examples:
  • Admin monitoring: In “admin,dba,root” - Enhanced monitoring for privileged users
  • Service account limits: In “app_user,backup_user” - Control service account activity

​
Ip

Triggers based on source IP address of database connections. Interface: Manual text entry Multiple IPs: Use comma separation: 192.168.1.100,10.0.0.5 (no spaces) Operator Options:
  • In: Trigger for processes from specified IPs
  • Not In: Trigger for processes NOT from specified IPs
Value: Enter IP addresses Examples:
  • Security monitoring: In “192.168.1.100” - Watch specific suspicious IP
  • External access: Not In “10.0.0.0/8” - Monitor external connections
  • Office restriction: In “203.0.113.0/24” - Limit to office network

​
Custom script

The custom script trigger allows you to write any SQL query that returns results. If the query returns data, the rule is considered “triggered” and the associated action will be executed. Interface: Manual text entry Value: Enter SQL query that returns data when condition is met Use Cases:
  • Complex business rules requiring multiple conditions
  • Integration with external monitoring systems
  • Custom performance metrics
  • Time-based rules (business hours, maintenance windows)

​
3. Actions

Choose what happens when trigger conditions are met:

​
Connection Management

  • Kill connection: Terminate the specific connections matching the trigger criteria. Uses pg_terminate_backend for PostgreSQL and CALL mysql.rds_kill for MySQL.
  • Kill idle connections: Terminate idle connections when connection utilization exceeds threshold. Includes rate limit per cycle.
  • Kill query: Difference from Kill Connection: Terminates only the running query, keeps the connection alive. Uses pg_cancel_backend for PostgreSQL and CALL mysql.rds_kill_query for MySQL.

​
Traffic Control

  • Rate limit: Limit the amount of concurrent operations for matching the trigger criteria
  • No action: Monitor only (log events & email - without taking action)

​
Analysis

  • RCA: Analyzes slow queries and provides root cause analysis by email.
  • Custom script: SQL statement(s) executed when rule triggers

​
4. Notifications

Toggle: Active/Inactive Email: Enter notification email address Send email notifications if configured

​
Multiple Trigger Logic (Important)

AND Relationship: All triggers must be true simultaneously Example:
  • Trigger 1: Connection idle time > 300 seconds
  • Trigger 2: User In “test_user,dev_user”
  • Trigger 3: IP In “192.168.1.100”
Result: Only triggers for connections that are idle over 5 minutes AND from test/dev users AND from IP 192.168.1.100 - all at the same time.