SQL/MX 3.6 Select for update feature

SELECT for UPDATE feature in
NonStop SQL/MX 3.6
Frans Jongma,
Hewlett Packard Enterprise
Advanced Technology Center
NonStop Enterprise Division
Version 1.0
Date: August 2018
Introduction
In order to prevent multiple transactions from updating the same data, Relational Database
Management Systems use locks, typically row locks, to ensure data integrity. Locking data
however, may affect concurrency, because read transactions that require to see only committed
data may need to wait for rows to be released. Database systems that implement the ANSI
isolation levels SERIALIZABLE, REPEATABLE READ, READ COMMITTED and READ
UNCOMMITTED access allow programmers to select the most feasible way to access data and
reduce contention. Another way to improve concurrency is by implementing Multi-Version
Concurrency Control (MVCC). NonStop SQL/MX is an example of the ANSI model, Oracle®
and PostgreSQL are examples of the MVCC method where multiple versions of the same row
exist in the database. (See the paper called "Database consistency in NonStop SQL/MX" for a
detailed description of the differences between Oracle and NonStop SQL/MX. Note however,
that the new SELECT FOR UPDATE feature addresses many of the issues described in that
paper).
Developers who are used to MVCC may find that, unless they change the way the application
locks data, response times may increase because the application spends time to wait for rows
to be released.
NonStop SQL/MX release 3.6 implements SELECT FOR UPDATE. It is a major step in the
Database Compatibility effort, and an additional way to increase concurrency while using the
ANSI isolation method.
Background
Oracle and other databases that use multi-version concurrency control or MVCC, do not allow
"dirty", uncommitted, data to be read. A SELECT will always return committed data, even if the

NonStop Advanced Technology Center
SELECT for UPDATE feature in NonStop SQL/MX 3.6 -2-
row is currently being changed by another transaction. For example, Oracle retrieves a previous
version from the UNDO log while other implementations might keep multiple versions of the
data in the database tables which need to be removed at some time. This means that if a
transaction wants to modify or delete rows that it has just read, it needs to need explicitly lock
the most recent version of those rows. The DML statement "SELECT … FROM <table… > FOR
UPDATE" will try to place a lock on the current version of the row and will wait for any
transaction that holds a write lock to release it.
In the ANSI model, the REPEATABLE READ or SERIALIZABLE access options allow a
transaction to place an exclusive lock on a row until the transaction commits. These reads may
however place more locks than are actually required for the updates: for example, they may
also prevent other transactions from inserting new data into the table.
The SQL/MX SELECT FOR UPDATE feature
NonStop SQL/MX release 3.6 implements SELECT FOR UPDATE. It is a major step in the
Database Compatibility effort, and an additional way to increase concurrency while using the
ANSI isolation method.
SELECT FOR UPDATE will read the data in READ COMMITTED access, and
only rows that match the selection predicates will then be locked exclusively
until the end of the transaction.
Considerations for the FOR UPDATE clause
The feature must be enabled using the DC_MODE or DC_SELECT_FOR_UPDATE CQDs.
This clause is different from the embedded SQL FOR UPDATE clause in a DECLARE
CURSOR statement, which is merely an indicator that the cursor can be updated.
Please see Considerations for FOR UPDATE clause in the SQL/MX 3.6 reference manual on
pages 430-431.
Use cases for SELECT FOR UPDATE
There is a requirement to update the employees that have a current salary of 2500. The rows
need to be retrieved and locked before taking further actions. This sections show how this is
done in SQL/MX before the new feature and how it is done using SELECT FOR UPDATE. The
examples use a simple employee database.

The example database
Consider a database1
with a JOBS table and an EMPLOYEES table defined as follows.
CREATE TABLE SCH.JOBS
(
JOB_ID VARCHAR2(10) CHARACTER SET ISO88591 NO
DEFAULT -- NOT NULL
, JOB_TITLE VARCHAR2(35) CHARACTER SET ISO88591 NO
DEFAULT -- NOT NULL
, MIN_SALARY NUMERIC(6, 0) DEFAULT NULL
, MAX_SALARY NUMERIC(6, 0) DEFAULT NULL
, CONSTRAINT SCH.JOBS_572372558_1881 PRIMARY KEY (JOB_ID ASC)
, CONSTRAINT SCH.JOBS_667172558_1881 CHECK (SCH.JOBS.JOB_ID IS NOT NULL AND
SCH.JOBS.JOB_TITLE IS NOT NULL)
)
;
CREATE TABLE SCH.EMPLOYEES
(
EMPLOYEE_ID NUMERIC(6, 0) NO DEFAULT -- NOT NULL
, FIRST_NAME VARCHAR2(20) CHARACTER SET ISO88591
DEFAULT NULL
, LAST_NAME VARCHAR2(25) CHARACTER SET ISO88591 NO
DEFAULT -- NOT NULL
, EMAIL VARCHAR2(25) CHARACTER SET ISO88591 NO
DEFAULT -- NOT NULL
, PHONE_NUMBER VARCHAR2(20) CHARACTER SET ISO88591
DEFAULT NULL
, HIRE_DATE DATE NO DEFAULT -- NOT NULL
, JOB_ID VARCHAR2(10) CHARACTER SET ISO88591 NO
DEFAULT -- NOT NULL
, SALARY NUMERIC(8, 2) DEFAULT NULL
, COMMISSION_PCT NUMERIC(2, 2) DEFAULT NULL
, MANAGER_ID NUMERIC(6, 0) DEFAULT NULL
, DEPARTMENT_ID NUMERIC(4, 0) DEFAULT NULL
, CONSTRAINT SCH.EMPLOYEES_168835558_1881 PRIMARY KEY (EMPLOYEE_ID ASC)
, CONSTRAINT SCH.EMPLOYEES_411435558_1881 CHECK (SCH.EMPLOYEES.EMPLOYEE_ID IS
NOT NULL AND SCH.EMPLOYEES.LAST_NAME IS NOT NULL AND SCH.EMPLOYEES.EMAIL
IS NOT NULL AND SCH.EMPLOYEES.HIRE_DATE IS NOT NULL AND
SCH.EMPLOYEES.JOB_ID IS NOT NULL)
)
;
-- The following index is a system created index --
CREATE INDEX EMP_JOB_FK ON SCH.EMPLOYEES
(
JOB_ID ASC
)
;
ALTER TABLE SCH.EMPLOYEES
ADD CONSTRAINT SCH.EMP_EMAIL_UK UNIQUE (EMAIL) DROPPABLE ;
ADD CONSTRAINT SCH.EMP_SALARY_MIN CHECK (SCH.EMPLOYEES.SALARY > 0) DROPPABLE
1 These tables are part of a larger Oracle demo schema that was used demonstrate NonStop SQL/MX
DDL compatibility. Note the use of VARCHAR2 which is another Database Compatibility feature..

;
ADD CONSTRAINT SCH.EMP_JOB_FK FOREIGN KEY (JOB_ID) REFERENCES
SCH.JOBS(JOB_ID) DROPPABLE ;
Example without using the new feature
Without the feature, the ANSI isolation levels must be used to make sure the resulting rows are
locked.
>>BEGIN WORK;
--- SQL operation complete.
>>SELECT EMPLOYEE_ID, SALARY, EMAIL,HIRE_DATE, JOB_ID FROM EMPLOYEES WHERE SALARY =
2500 FOR SERIALIZABLE ACCESS IN EXCLUSIVE MODE;
EMPLOYEE_ID SALARY EMAIL HIRE_DATE JOB_ID
----------- ------------ ------------------------- ---------- ----------
119 2500.00 KCOLMENA 2007-08-10 PU_CLERK
131 2500.00 JAMRLOW 2005-02-16 ST_CLERK
140 2500.00 JPATEL 2006-04-06 ST_CLERK
144 2500.00 PVARGAS 2006-07-09 ST_CLERK
182 2500.00 MSULLIVA 2007-06-21 SH_CLERK
191 2500.00 RPERKINS 2007-12-19 SH_CLERK
--- 6 row(s) selected.
Only 6 rows qualify, however, all rows of the table are now locked, because the query uses a
serial scan through the table and because of the SERIALIZABLE access option, all rows need
to be locked exclusively.
Using FUP to list the locks shows that exclusive locks are place on every row2
.
-LISTLOCKS 'SCHEMA FRANS3_6.SCH', DETAIL
$HD0000.ZSDFJ004.LT7QRG00
ANSI NAME FRANS3_6.SCH.EMPLOYEES
LOCK REQUESTER KEY
TYPE STATE ID LEN KEY/RECORD ADDRESS
F GI TSEK(1).1.860023 LOCK STATE = LK^IX
R G TSEK(1).1.860023 4 ?0 ?0 ?0 ?137 LOCK STATE = LK^X
R G TSEK(1).1.860023 4 ?0 ?0 ?0 "w" LOCK STATE = LK^X
R G TSEK(1).1.860023 4 ?0 ?0 ?0 "q" LOCK STATE = LK^X
…
… Omitted 100 additional locks …
2 The first line that FUP shows is a FILE (F) INTENT (I) lock that just prevents other transactions from
obtaining a table-lock. The other locks of type R are row locks.

Other transactions that require committed access to these rows will wait until
they time out, default 60 seconds, and return with error 73: row locked.
Transactions that use READ UNCOMMITTED access will still be able to see
these rows.Example using the new SELECT FOR UPDATE feature
Because the FOR UPDATE clause is already used in cursor selects to update the “current of
cursor” row, the new feature must be explicitly enabled using a control query default (CQD). The
CQD is called DC_SELECT_FOR_UPDATE and its value must be set to 1.
>>CQD DC_SELECT_FOR_UPDATE '1'; -- Allow the new feature to work
>>BEGIN WORK;
>>SELECT EMPLOYEE_ID, SALARY, EMAIL,HIRE_DATE, JOB_ID FROM EMPLOYEES WHERE SALARY =
2500 FOR UPDATE;
----------- ------------ ------------------------- ---------- ----------
119 2500.00 KCOLMENA 2007-08-10 PU_CLERK
131 2500.00 JAMRLOW 2005-02-16 ST_CLERK
140 2500.00 JPATEL 2006-04-06 ST_CLERK
144 2500.00 PVARGAS 2006-07-09 ST_CLERK
The FUP Listlocks display is now a lot smaller: only 6 rows are locked exclusively.
-LISTLOCKS 'SCHEMA FRANS3_6.SCH', DETAIL
LOCK REQUESTER KEY
R G TSEK(1).1.860027 4 ?0 ?0 ?0 ?140 LOCK STATE = LK^UX
R G TSEK(1).1.860027 4 ?0 ?0 ?0 "w" LOCK STATE = LK^UX
-

Now, only transactions that try to read these rows with READ COMMITTED or higher isolation
will encounter these locks. This is an example how the SELECT FOR UPDATE feature can
greatly improve concurrency of transactions.
Selecting and locking rows from multiple tables
But what if there are more tables involved? Consider the following example, where we select
employees with JOB_ID ‘SH_CLERK’ who earn the minimum salary of that job.
>>SELECT EMPLOYEE_ID, SALARY, EMAIL,HIRE_DATE, E.JOB_ID
+>FROM EMPLOYEES E, JOBS J
+>WHERE
+> E.JOB_ID = J.JOB_ID
+>AND J.JOB_ID = 'SH_CLERK'
+>AND SALARY = MIN_SALARY
+>FOR UPDATE OF E.SALARY
+>;
----------- ------------ ------------------------- ---------- ----------
~> fup "LISTLOCKS 'SCHEMA FRANS3_6.SCH', DETAIL"
LOCK REQUESTER KEY
Again, only two qualifying rows from the employees table are locked. With SERIALIZABLE
access however, the row in the JOBS table would have been locked in addition to all the rows in
the EMPLOYEES table.
The number of rows that are locked depends on the chosen execution plan regardless whether
SELECT FOR UDATE or SERIALIZABLE access is used. The next section provides more
details on how the execution plan influences the amount of locking that takes place.

How the execution plan affects the number of rows locked
The ANSI isolation levels SERIALIZABLE and REPEATABLE are used to place read and write
locks for the duration of a transaction during a SELECT query. The SERIALIZABLE isolation
level even prevents other transactions to insert rows to assure the same result when the query
executes a second time within the same transaction. SQL/MX has implemented REPEATABLE
access the same a SERIALIZABLE and therefore, all rows of a table may be locked for a query
that performs a full table scan.
With SELECT FOR UPDATE, the executor that runs in DP2 (the “Executor-in-DP2 or EID) only
places a lock if the row passes the executor predicate of the particular node in the query plan.
The following example illustrates this.
SELECT * FROM JOBS WHERE JOB_TITLE = 'Shipping Clerk' FOR SERIALIZABLE ACCESS IN
EXCLUSIVE MODE;
A full table scan of the JOBS table is performed, and all rows will get an exclusive lock. The next
query access the table via its primary key and will only lock the single row with the selected
value. No other row with this key value can be added, so a single row lock is sufficient..
SELECT * FROM JOBS WHERE JOB_ID = 'SH_CLERK' FOR SERIALIZABLE ACCESS IN EXCLUSIVE
MODE;
A query that uses SELECT FOR UPDATE will lock only those rows that match the WHERE
clause, not any other rows.
SELECT * FROM JOBS WHERE JOB_TITLE = 'Shipping Clerk' FOR UPDATE;
Below is the DP2 plan fragment of this query. It shows the executor predicate that is executed
by DP2 when filtering datqa that comes off the disk. The rows that pass the predicate will get a
write (exclusive) lock.
FILE_SCAN ================================= SEQ_NO 1 NO CHILDREN
TABLE_NAME ............... FRANS3_6.SCH.JOBS
REQUESTS_IN .............. 1
ROWS_OUT ................. 1
EST_OPER_COST ............ 0.01
EST_TOTAL_COST ........... 0.01
DESCRIPTION
max_card_est ........... 1
fragment_id ............ 2
parent_frag ............ 0
fragment_type .......... dp2
olt_optimization ....... not used
olt_opt_lean ........... not used
scan_type .............. full scan of table FRANS3_6.SCH.JOBS
scan_direction ......... forward
key_type ............... simple
lock_state ............. cursor
consistency_level ...... read_committed
columns_retrieved ...... 4

fast_replydata_move .... used
Scan_Lock_For_Write .... Yes
key_columns ............ JOB_ID
executor_predicates .... (JOB_TITLE = 'Shipping Clerk')
begin_key .............. (JOB_ID = '<min>')
end_key ................ (JOB_ID = '<max>')
Nested joins are preferred
The executor predicates that are handled by DP2 greatly determine the number of rows that are
actually locked for update. However when tables are joined, not all join-types are equal in how
the EID receives its executor predicates.
When tables are joined using a nested join, the join predicate will be pushed down to the EID,
but when tables are joined using a hash join or a merge join, the actual join predicate is not
visible to DP2. Consider the two following examples, the first one selects the employees that
earn the minimum wage for job title Clerks (as indicated by the search argument ‘%Clerk’, the
other does the same for employees regardless of job title.
Example 1: Hash join
>>EXPLAIN OPTIONS 'f'
+>SELECT EMPLOYEE_ID, SALARY, EMAIL,HIRE_DATE, E.JOB_ID , MIN_SALARY , JOB_TITLE
+>WHERE
+> AND SALARY = MIN_SALARY
+>FOR UPDATE OF SALARY
+>;
LC RC OP OPERATOR OPT DESCRIPTION CARD
---- ---- ---- -------------------- -------- -------------------- ---------
5 . 6 root 1.90E+001
4 2 5 hybrid_hash_join 1.90E+001
3 . 4 partition_access 1.06E+002
. . 3 file_scan fr EMPLOYEES (s) 1.06E+002
. . 1 file_scan fr JOBS (s) 1.90E+001
The two tables are joined using a hybrid hash join. The JOBS table is the inner table and a hash
table of (JOB_ID, MIN_SALARY) will be built by the executor that runs inside the program. The
EMPLOYEES table is scanned and every row is matched against the hash table. The DP2
fragment for EMPLOYEES is shown below:

TABLE_NAME ............... E (FRANS3_6.SCH.EMPLOYEES)
REQUESTS_IN .............. 1
ROWS_OUT ............... 107
EST_OPER_COST ............ 0.02
EST_TOTAL_COST ........... 0.02
DESCRIPTION
max_card_est ......... 107
fragment_id ............ 3
parent_frag ............ 0
scan_type .............. full scan of table FRANS3_6.SCH.EMPLOYEES E
columns_retrieved ..... 11
key_columns ............ EMPLOYEE_ID
executor_predicates .... SALARY is not null
begin_key .............. (EMPLOYEE_ID = <min>)
end_key ................ (EMPLOYEE_ID = <max>)
The only executor predicate for employees is “SALARY is not NULL”, so all rows from
employees that have a salary will be locked for a possible update.
Example 2: Nested join
Adding an extra predicate causes the cardinality to be low and so the optimizer selects a nested
join as is shown in operation 5 below.
>>EXPLAIN OPTIONS 'f'
+>SELECT EMPLOYEE_ID, SALARY, EMAIL,HIRE_DATE, E.JOB_ID , MIN_SALARY , JOB_TITLE
+>WHERE
+> AND JOB_TITLE LIKE '%Clerk'
+>;
LC RC OP OPERATOR OPT DESCRIPTION CARD
---- ---- ---- -------------------- -------- -------------------- ---------
5 . 6 root 2.00E+000
2 4 5 nested_join 2.00E+000
. . 3 file_scan fr EMPLOYEES (s) 1.00E+000
. . 1 file_scan fr JOBS (s) 1.00E+000

Now, the EMPLOYEES table is the inner table and the DP2 fragment includes the join
predicate.
TABLE_NAME ............... E (FRANS3_6.SCH.EMPLOYEES)
REQUESTS_IN .............. 1
ROWS_OUT ................. 1
EST_OPER_COST ............ 0.01
EST_TOTAL_COST ........... 0.01
DESCRIPTION
max_card_est ......... 107
fragment_id ............ 3
parent_frag ............ 0
scan_type .............. full scan of table FRANS3_6.SCH.EMPLOYEES E
columns_retrieved ..... 11
key_columns ............ EMPLOYEE_ID
executor_predicates .... (JOB_ID = FRANS3_6.SCH.JOBS.JOB_ID) and (SALARY =
cast((FRANS3_6.SCH.JOBS.MIN_SALARY * 100) AS
NUMERIC(8,2) SIGNED))
begin_key .............. (EMPLOYEE_ID = <min>)
end_key ................ (EMPLOYEE_ID = <max>)
Because the join predicate from the nested join in operation 5 is copied down to the EID in
operation 3, only the rows in EMPLOYEES that pass the join criteria are locked.
Note 1: This example may involve multiple scans through the employee table if there are
multiple rows in the JOB table that match the WHERE clause.
Note 2: Be advised that an optimizer join hint can be used to change the join from hash to
nested. Example 1 can be written with such a hint as:
SELECT EMPLOYEE_ID, SALARY, EMAIL,HIRE_DATE, E.JOB_ID , MIN_SALARY , JOB_TITLE
+>WHERE
+>USING <<+ USE_NESTEDJOIN( E,J) >>
+>;

Further improving concurrency
Be sure you do not lock rows from tables that you do not want to update. If multiple table are
joined to form a result set, be sure to add the column names from the table(s) that need to be
locked. When no columns are specified in the FOR UPDATE OF clause, SQL/MX will lock rows
from every table in the join.
Skip over existing locks
A common technique to increase concurrency is to skip over existing locked rows. SELECT
FOR UPDATE supports the SKIP LOCKED option. When used, SQL/MX will continue reading
the data and return and lock only those that are not locked by other transactions.3
>>SELECT EMPLOYEE_ID, SALARY, EMAIL,HIRE_DATE, E.JOB_ID , MIN_SALARY , JOB_TITLE
+>WHERE
+>FOR UPDATE OF SALARY SKIP LOCKED;
NOWAIT, or return if locked
Some applications may decide not to wait for locked rows, but immediately return the locked
status to the user. In Oracle SQL the NOWAIT option can be used, this needs to be rephrased
in SQL/MX using an optimizer control hint as shown below.
>>SELECT EMPLOYEE_ID, SALARY, EMAIL,HIRE_DATE, E.JOB_ID , MIN_SALARY , JOB_TITLE
+>WHERE
+>WITH CQD IF_LOCKED 'RETURN';
*** ERROR[8551] Error 73 was returned by the file system on FRANS3_6.SCH.EMPLOYEES
(partition TSEK.$HD0000.ZSDFJ004.LT7QRG00).
Conclusion
When applications were migrated to NonStop SQL from databases that use MVCC to manage
consistence and concurrency, prior to Release 3.6, the application may have required DML
3 SKIP LOCKED is similar to existing functionality of SKIP CONFLICT ACCESS in a SELECT. However,
for compatibility reasons SELECT FOR UPDATE requires the use of SKIP LOCKED.

changes to lock rows before they could be updated or deleted. Such changes could lead to a
higher frequency of transactions waiting for locks to be releases. With the support of SELECT
FOR UPDATE, fewer DLM changes are needed and a finer granularity of exclusive locks has
been achieved. Migration to NonStop SQL has become much easier.

SQL/MX 3.6 Select for update feature

Recommended

Recommended

More Related Content

What's hot

What's hot (13)

Similar to SQL/MX 3.6 Select for update feature

Similar to SQL/MX 3.6 Select for update feature (20)

Recently uploaded

Recently uploaded (20)

SQL/MX 3.6 Select for update feature