SQL/MX 2.x Installation and Management Guide (H06.10+, J06.03+)

Managing Database Applications
HP NonStop SQL/MX Installation and Management Guide—544536-007
11-3
SQL/MX and SQL/MP Differences in Recovery
Action for Read-Only Queries
It is not necessary to start a new TMF transaction. The application can incorporate
special retry logic, such as saving the key predicate of the last row returned for use in
the WHERE clause of the SELECT statement. Using this technique, the program can
reopen the cursor and continue the query from the point where the error was
encountered.
SQL/MX and SQL/MP Differences in Recovery Action for
Read-Only Queries
As noted previously, queries that update the database require a TMF transaction, and
the TMF transaction is aborted automatically by the system if the primary DP2 process
fails. This is true for NonStop SQL/MX, NonStop SQL/MP, and Enscribe. In some
situations following a failure or inaccessibility of the primary DP2 process, NonStop
SQL/MP is able to continue processing a SQL read-only query, and the application
does not need to handle the recovery.
In some of these situations, a SQL/MX application must handle the recovery of the
failure for a read-only query, as described in Recovery for Read-Only Queries on
page 11-2.
NonStop SQL/MX is designed to maximize performance and throughput for large-scale
database applications. Consequently, NonStop SQL/MX differs from NonStop SQL/MP
in these important ways:
•
For performance reasons, NonStop SQL/MX uses a no-waited interface between
the SQL/MX file system and the DP2 process, whereas NonStop SQL/MP uses a
waited interface to the DP2 process.
•
In NonStop SQL/MX, the query engine is embedded in the DP2 process directly,
whereas in NonStop SQL/MP, the query engine resides in a separate process.
To extend the recovery logic of NonStop SQL/MX for read-only queries would require
maintaining and checkpointing a large amount of context information between the DP2
process and the file system and/or between the primary and backup DP2 process. This
checkpointing recovery logic would affect the performance and throughput of NonStop
SQL/MX. Because of this, it is more efficient for the application program to handle the
recovery of some transient errors.
NonStop SQL/MX and TMF absolutely guarantee the integrity of the database following
a CPU failure, application failure, or other component failure.
Moving Programs From Development to
Production
Theoretically at least, there are two approaches to moving an application from a
development system to the production environment:
•
Moving a program with compiled modules