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

The performance impact of Row Level Security on DELETE is therefore very similar to the
performance impact on UPDATE.
Utilities
You need a valid SECLABEL and additional authorizations to run certain LOAD, UNLOAD,
and REORG TABLESPACE jobs on tables that have multilevel security enabled. All other
utilities check only for authorization to operate on the table space; they do not check for
row-level authorization and are therefore not impacted. Offline utilities such as DSN1COPY
and DSN1PRNT do not impose Row Level Security and are also not impacted.
At the time of writing this book, no actual performance studies have been undertaken to
quantify the impact of Row Level Security on utilities. However, we can make some comment
as to what performance impact may occur. As always the performance overhead on utilities
varies greatly, depending on how many columns are in the table and how complex the
definitions of the columns are. A utility processing more columns and performing more
complex data conversion sees less impact using Row Level Security because any impact of
SECLABEL processing is diluted. However, the CPU overhead of using Row Level Security
may be significant when you are processing a large number of rows with few columns in each
row. As always, your mileage will vary.
Executing a LOAD RESUME utility against a table space containing tables with Row Level
Security requires that the user is identified to RACF and has a valid SECLABEL. LOAD
RESUME adheres to the same rules as INSERT. Without write-down authorization, the
SECLABEL in the table is set to the SECLABEL associated with the user ID executing the
LOAD RESUME utility. With write-down, any valid security label that is not disjoint in relation
to the user's security can be specified. So, the performance impact of Row Level Security on
LOAD RESUME is similar, but slightly higher than that of INSERTs.
LOAD REPLACE deletes all rows in a table space. Therefore, write-down authority is
required. If the user ID associated with the job that is running the LOAD REPLACE utility does
not have write-down privilege, and write-down is in effect, an error message is issued.
Executing the UNLOAD or REORG UNLOAD EXTERNAL utility against tables with Row
Level Security requires that the user associated with the job is identified to RACF, and have a
valid SECLABEL. For each row unloaded from those tables, if the user SECLABEL dominates
the data SECLABEL, then the row is unloaded. If the user’s SECLABEL does not dominate
the data SECLABEL, the row is not unloaded and no error is returned. The performance
impact is therefore similar to that of SELECT.
The UNLOAD utility has a sampling option where you can specify a percentage of rows to be
unloaded. The sampling filter operates only on the rows you are allowed to access, so it is not
possible for an unauthorized user to calculate the total size of the table using the UNLOAD
utility. However, the RUNSTATS utility, which also has a sampling function, does not invoke
Row Level Security. RUNSTATS also updates the DB2 catalog with column distribution
statistics and column values. We therefore recommend that if you are planning to implement
MLS Row Level Security to protect your data, you should also review who has access to your
DB2 catalog tables.
Executing REORG... DISCARD on tables with Row Level Security requires that the user is
identified to RACF and has a valid SECLABEL. REORG with the DISCARD option adheres to
the same rules as the SQL DELETE statement. For each row unloaded from those tables, if
the row qualifies to be discarded, the user SECLABEL is compared to the data SECLABEL.
We would therefore evaluate the performance impact to be slightly higher than that of
DELETEs.
Chapter 4. DB2 subsystem performance 197