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

4.9.1 Performance
We can implement RACF external security with MLS at the DB2 object level to control access
to databases, table spaces, tables, views, indexes, storage groups, buffer pools, plans,
packages, stored procedures, and more. This is done by implementing the DB2 and RACF
security exit DSNX@XAC. See the DB2 UDB for z/OS Version 8 Administration Guide,
SC18-7413-01, and the DB2 UDB for z/OS Version 8 RACF Access Control Module Guide,
SC18-7433, for discussions regarding how to implement RACF External Security for DB2.
At the time of writing this book, there have been no performance studies conducted
comparing RACF External Security for DB2 objects, (either with or without using MLS), with
DB2 native security. However, we consider the impact of DB2 External Security over DB2
native security (GRANT and REVOKE) insignificant.
We can also implement RACF MLS security with row level granularity, as is described here.
These performance studies explore the performance impact of DB2 Row Level Security
where there was no RACF external security at all, only DB2 native security. No application
changes were made and there was no “application” row level security implemented (for
example via views). Obviously, if you wish to change your application to remove any
application-implemented row level security techniques and implement DB2 Row Level
Security, your application probably becomes less complex and therefore less CPU intensive.
Any CPU overhead caused by DB2 Row Level Security should be offset by these savings.
A user or thread has only one SECLABEL “active” at any one time. When rows are accessed,
DB2 checks the thread’s, or user’s SECLABEL value with each new SECLABEL value from
the rows being accessed. To avoid going to RACF for each and every row accessed, DB2
caches all the SECLABEL values that have been checked, both successfully or
unsuccessfully. The cache is maintained per thread and is flushed on commit and rollback.
So, if immediate changes are required in the security policy, then long-running applications
which have not committed or rolled back may need to be canceled.
In a general sense, you can think of DB2 evaluating SECLABEL values in the same way as
DB2 evaluating Stage 1 predicates, only in that DB2 attempts to perform SECLABEL
checking as a Stage 1 activity. During access path selection, the DB2 optimizer does not
consider the task of evaluating the SECLABELs the same way as it would any Stage 1
predicates. This is similar to resolving referential constraints. However, the need to evaluate
SECLABEL values can impact SQL access paths. For example, Index Only access may now
be regressed to an Index plus data access (to retrieve each row’s SECLABEL value), if the
index being selected does not also contain the SECLABEL column. Row Level Security can
therefore have a significant impact on your application performance by changing access
paths.
The overhead of Row Level Security in DB2 is recorded as Accounting class 2 CPU time and
varies depending on the complexity of your SQL, how many rows your query needs to “touch”
during Stage 1 processing, and how many different SECLABEL values you have in your table.
The more complex the query, the less impact Row Level Security has on CPU. This is
because the overhead of Row Level Security is diluted with more CPU intensive queries.
Therefore, your mileage will vary!
SELECT
The user's SECLABEL is compared to the data SECLABEL of each row to be selected, also
for the rows that do not qualify. If the SECLABEL of the user dominates the SECLABEL of the
row, DB2 returns the row. If the SECLABEL of the user does not dominate the SECLABEL of
the row, DB2 does not return the data from that row, and DB2 does not generate an error.
Chapter 4. DB2 subsystem performance 195