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

4.9.2 Conclusion
The CPU increase caused by Row Level Security occurs because DB2 must now access the
SECLABEL column in the table, evaluate the user’s SECLABEL against the SECLABEL of
the data, manage a cache of SECLABEL values, and periodically consult RACF. At a very
rough level, the performance impact of row level security can be considered in the same
ballpark as DB2 data compression with less than a 5% impact for a typical online transaction
but higher for a CPU-bound sequential scan.
However, these CPU costs are very much dependent on the complexity of the SQL, the
number and size of columns manipulated by the SQL and the number of indexes that need to
be updated. Anticipate seeing more overhead with simple queries which must touch a large
number of unique seclabels and users, so that the cache is ineffective, rather than complex
queries. A simple table space scan returning a small number of rows can potentially
experience the highest impact, even with caching.
Users who have already implemented a form of row level security in their application and want
to convert to DB2’s implementation of Row Level Security should not see a high CPU
increase. The applications probably are less complex and the SQL less complex and
expensive to run. So, the extra cost in CPU caused by Row Level Security should be
compensated by the savings in CPU resulting from a simpler application.
4.9.3 Recommendations
Row Level Security using MLS only has a small overhead compared to no row level security
at all. In addition, the MLS Row Level Security probably out performs any application
implementation which provides similar function. MLS Row Level Security also offers a more
complete or secure solution than many application implementations of row level security.
When you add MLS Row Level Security into your existing applications, or design new ones
with it, you should consider the performance impact to the application and possibly review the
physical design.
The performance of accessing tables that contain a security label can be impacted if the
SECLABEL column is not included in the indexes. The SECLABEL column is used whenever
a table with Row Level Security enabled is accessed. Access paths may change as DB2 must
now access the SECLABEL column. An index only scan may now turn into an index plus data
scan. Therefore, it is a good idea to include the SECLABEL column in your existing indexes if
your index design allows, especially when your queries are using index-only access today.
DB2 caches security labels to avoid extra calls to RACF. This caching would work best if there
are a relatively small number of security labels to be checked compared with the number of
rows accessed.
Some application processes may also need to change to accommodate write-down
processing and preserve existing SECLABEL values in the table. For example, you may need
to run multiple SQL or batch jobs against a table where you would normally run a single
execution. In this way, you preserve the SECLABEL values already in the table.
For example, if you have an SQL process to increase everyone’s salary by 10%:
UPDATE PAYROLL
SET SALARY = SALARY * 1.1
You need write-down authority to update the whole table. Unfortunately DB2 sets ALL
SECLABEL values to the one value.
198 DB2 UDB for z/OS Version 8 Performance Topics