DB2 UDB for z/OS Version 8 Performance Topics - IBM Redbooks

DB2 must call RACF for this dominance checking if the rows SECLABEL has not already
been encountered and therefore cached.
If RACF is called, studies have shown up to a 10% impact on CPU with SELECT statements
using Row Level Security. If the SECLABEL is found in the cache, this impact reduces to 2%.
For a FETCH rather than a SELECT, this can be as high as 5%. This is because the CPU time
which can be attributed to the overhead or Row Level Security consumes a larger percentage
of the total CPU time.
INSERT
If the user has write-down privilege or write-down control is not enabled, the user can set the
SECLABEL for the row to a valid security label that is not disjoint in relation to the user's
security. If the user does not specify a value for the SECLABEL, the SECLABEL of the row
becomes the same as the SECLABEL of the user. Alternatively, If the user does not have
write-down privilege and write-down control is enabled, the SECLABEL of the row becomes
the same as the SECLABEL of the user.
The cost of each INSERT statement can increase by up to 2%. This is also dependent on the
complexity of the INSERT statement, the number of columns to be INSERTed and the
number of indexes that must be updated. The extra overhead results in DB2 extracting the
user’s SECLABEL value and building the new row with this extra column.
UPDATE
If the SECLABEL of the user and the SECLABEL of the row are equivalent, the row is
updated and the value of the SECLABEL is determined by whether the user has write-down
privilege. If the user has write-down privilege or write-down control is not enabled, the user
can set the SECLABEL of the row to a valid security label that is not disjoint in relation to the
user's security. If the user does not have write-down privilege and write-down control is
enabled, the SECLABEL of the row is set to the value of the SECLABEL of the user.
Alternatively, if the SECLABEL of the user dominates the SECLABEL of the row, the result of
the UPDATE statement is determined by whether the user has write-down privilege. If the
user has write-down privilege or write-down control is not enabled, the row is updated and the
user can set the SECLABEL of the row to a valid security label that is not disjoint in relation to
the user's security. If the user does not have write-down privilege and write-down control is
enabled, the row is not updated.
Finally, if the SECLABEL of the row dominates the SECLABEL of the user, the row is not
updated.
As is the case with SELECT, RACF is not consulted unless the user’s SECLABEL is not
already cached. Therefore we see the same degree of overhead in using Row Level Security
as in the case of SELECT. We see up to a 10% performance impact if the user’s SECLABEL
is not cached and up to 2% if it is cached.
DELETE
If the SECLABEL of the user and the SECLABEL of the row are equivalent, the row is
deleted.
If the SECLABEL of the user dominates the SECLABEL of the row, the user’s write-down
privilege determines the result of the DELETE statement: If the user has write-down privilege
or write-down control is not enabled, the row is deleted. Alternatively, if the user does not have
write-down privilege and write-down control is enabled, the row is not deleted.
Finally, if the SECLABEL of the row dominates the SECLABEL of the user, the row is not
deleted.
196 DB2 UDB for z/OS Version 8 Performance Topics