The durability level can be set as a server default, per session, or per transaction.

Strict durability: synchronous logging

With strict durability, transaction logging is synchronous: the transaction is written to the transaction logs as soon as the transaction is committed.

Relaxed durability: asynchronous logging

With relaxed durability, transaction logging is asynchronous: solidDB is permitted to defer the transaction write until the server is less busy, or until it can write multiple transactions together.

In a server that is not part of a HotStandby pair, using relaxed durability means that you risk losing the most recent few transactions if the server terminates abnormally. If the server is part of a HotStandby pair, a copy of the transaction is on the other server (the Secondary); even if the Primary server fails before logging the transaction, the transaction is not lost. Thus, when relaxed durability is used with HSB, relaxed durability causes little reduction in safety. On the other hand, relaxed durability can improve the performance of the system, especially in situations where the server load consists of a large number of small write transactions.

Adaptive durability

Adaptive durability applies only to HotStandby Primary servers. Adaptive durability means that if the server is in Primary Active state (sending transactions to the Secondary), it will use relaxed durability. In any other state it will use strict durability. This gives you high performance (with little loss of safety) when HSB is active, yet maintains high safety if only one server is operating. Adaptive durability is effective only when the HotStandby has been set to use a 2-safe replication: the Primary server does not tell the client that the transaction has been successfully committed until the Primary receives acknowledgement that the Secondary has the transaction.

2.6 solidDB SQL extensions

The SQL support in solidDB is comparable to any advanced SQL-based system; solidDB offers the most commonly expected features and a set of useful extensions employing solidDB-specific (nonstandard) SQL syntax. Additionally, procedural SQL extensions such as stored procedures and triggers enable moving parts of the application logic into the database. These extensions help reduce network traffic, thus improving performance.

Chapter 2. IBM solidDB details 31

2.6.1 solidDB SQL standard compliance

No commercial relational DBMS fully supports the SQL standard beyond the SQL-92 Entry Level, and solidDB is no exception. The full standards known as SQL-92, SQL-99, and SQL 2003 are too broad to be implemented in a cost-efficient manner.

solidDB supports the SQL-92 Entry Level fully and has adapted selected features from the broader standards. An example of advanced standard features is the possibility to manage table constraints dynamically by using the ALTER TABLE syntax.

In addition to standard features, solidDB also borrows suitable, nonstandard solutions from other proprietary products. Examples are as follows:

START WITH ... CONNECT BY syntax for calculating hierarchical queries

LIMIT clause for limiting the size of the result set

2.6.2Stored procedures

Stored procedures are simple programs, or procedures, that are compiled and parsed after and then stored in the database for future execution. Because stored procedures are stored and executed directly in the server, usage of stored procedures reduces network traffic and can thus improve performance. For example, complex, data-bound transactions may be run on the server itself.

You can create a procedure that contains several SQL statements or a whole transaction and execute it with a single call statement. In addition to SQL statements, 3GL type control structures can be used enabling procedural control. You can also create nested stored procedures where one procedure is executed from within another.

Stored procedures can also be used for controlling access rights and database operations. Granting execute rights on a stored procedure automatically invokes the necessary access rights to all database objects used in the procedure.

Therefore, administering database access rights may be greatly simplified by allowing access to critical data through procedures.

Stored procedures are created and called using SQL statements.

32 IBM solidDB: Delivering Data with Extreme Speed

The three calling methods for the stored procedures are local, remote and deferred stored procedures:

Local procedures are executed on a local database server.

Remote procedures are procedures that are stored on one server and called by another. Remote stored procedures are applicable only to advanced replication setups.

Deferred procedures are procedures that are called after commit has been processed.

2.6.3Triggers

A trigger is a mechanism for executing a series of SQL statements when a particular action (an INSERT, UPDATE, or DELETE) occurs. The trigger contains SQL statement that need to be executed when the trigger is invoked. Triggers are created using solidDB proprietary stored procedure syntax.

You can create one or more triggers on a table, with each trigger defined to activate on a specific INSERT, UPDATE, or DELETE command. When a user modifies data within the table, the trigger that corresponds to the command is activated.

You can use only inline SQL or stored procedures with triggers. If you use a stored procedure in the trigger, the procedure must be created with the CREATE PROCEDURE command. A procedure invoked from a trigger body can invoke other triggers.

Triggers enable you to perform the following tasks:

Implement special integrity constraints, such as checking that certain conditions are maintained, for example, to prevent users from making incorrect or inconsistent data changes.

Take action based on the value of a row before or after modification.

Transfer much of the logic processing to the back end, reducing the amount of work that your application needs to do and reducing network traffic.

2.6.4Sequences

Sequences are objects that are used to get sequence numbers in an efficient manner. Sequence objects can be used, for example, to generate primary key numbers. The advantage of using a sequence object instead of a separate table is that the sequence object is specifically fine-tuned for fast execution and requires less overhead than normal update statements.

Chapter 2. IBM solidDB details 33

By default, solidDB sequences are sparse. Being sparse means that there is no guarantee that the generated sequence numbers are consecutive (they are, however, unique). Another possibility is a dense sequence. In that case the generated sequence numbers follow each other. The penalty of dense sequences is that they are locked by the transactions incrementing them, so no two transactions can increment the same sequence in the same time. One of the transactions must wait until the other transaction commits or aborts. Sparse sequences are more performant because they are not locked by the incrementing transactions.

Sequence objects are created with the CREATE SEQUENCE or CREATE DENSE SEQUENCE statement. Sequence values can be incremented and used within SQL statements using the sequence_name.CURRVAL and sequence_name.NEXTVAL constructs. Sequences can also be used inside stored procedures.

2.6.5 Events

Event are database objects that are used to signal events in solidDB databases. Together with stored procedures, events can be used for automating administrative tasks. You can make your application use event alerts instead of polling, which uses more resources.

The events mechanism is based on one connection waiting on an event until another connection posts that event. More than one connection may wait on the same event. If multiple connections wait on the same event, all waiting connections are notified when the event is posted. A connection may also wait on multiple events, in which case it will be notified when any of those events are posted.

In addition to system events, solidDB supports also user-defined events. However, user-defined events can only be used within stored procedures; system events can also be used without stored procedures. The events are managed using SQL statements.

34 IBM solidDB: Delivering Data with Extreme Speed