Home
AdministeringIn addition to administering the database server, you can tune performance, replicate data, and archive data.
System administrationThese topics contain concepts, procedures, and reference information for database and database server administrators to use for managing and tuning HCL OneDB™ database servers.
Performance GuideThe HCL OneDB™ Performance Guide describes how to configure and operate your HCL OneDB™ database server to improve overall system throughput and to improve the performance of SQL queries.
Queries and the query optimizerThese topics describe query plans, explain how the database server manages query optimization, and discuss factors that you can use to influence the query plan. These topics also describe performance considerations for SPL routines, the UDR cache, and triggers.
Trigger executionA trigger is a database object that automatically executes one or more SQL statements (the triggered action) when a specified data manipulation language operation (the triggering event) occurs. You can define one or more triggers on a table to execute after a SELECT, INSERT, UPDATE or DELETE triggering event.
Performance implications for triggersIn many situations, triggers can improve performance slightly because of the reduction in the number of messages passed from the client to the database server.
SELECT triggers on tables in a table hierarchyWhen the database server executes a SELECT statement that includes a table that is involved in a table hierarchy, and the SELECT statement fires a SELECT trigger, performance might be slower if the SELECT statement that invokes the trigger involves a join, sort, or materialized view.

SELECT triggers on tables in a table hierarchy

When the database server executes a SELECT statement that includes a table that is involved in a table hierarchy, and the SELECT statement fires a SELECT trigger, performance might be slower if the SELECT statement that invokes the trigger involves a join, sort, or materialized view.

In this case, the database server does not know which columns are affected in the table hierarchy, so it can execute the query differently. The following behaviors might occur:

Key-only index scans are disabled on the table that is involved in a table hierarchy.
If the database server needs to sort data selected from a table involved in a table hierarchy, it copies all of the columns in the SELECT list to the temporary table, not just the sort columns.
If the database server uses the table included in the table hierarchy to build a hash table for a hash join with another table, it bypasses the early projection, meaning it uses all of the columns from the table to build the hash table, not just the columns in the join.
If the SELECT statement contains a materialized view (meaning a temporary table must be built for the columns in a view) that contains columns from a table involved in a table hierarchy, all columns from the table are included in the temporary table, not just the columns actually contained in the view.