Every DBA strives to maintain a healthy DB2 environment every day. However, there are numerous lingering misconceptions about database health to which many organizations fall prey. These misconceptions occur because DBAs believe in, or apply, concepts that are objectively false.
Some misconceptions exist simply because they’ve been passed down from older generations. In terms of DB2, this means that best practices for older DB2 versions may no longer be best. This article examines several common misconceptions about DB2 maintenance and recovery.
“Lies, Damned Lies, and Statistics“
This is part of a phrase usually attributed to Benjamin Disraeli and popularized in the U.S. by Mark Twain. Although the origin of this statement may be questioned, its meaning is clear. It refers to the persuasive power of numbers and neatly describes how even accurate statistics can be used to bolster inaccurate arguments.
When it comes to DB2, statistics are the lifeblood of database health. But it’s important to distinguish between the two types of statistics available to us: catalog statistics and real-time statistics. Although originally intended as food for the DB2 Optimizer, historically we’ve also needed analytical RUNSTATS that updated catalog statistics to drive our maintenance processes. With the advent of real-time statistics, there’s no need to waste time and resources by running analytical RUNSTATS. It’s time to use RUNSTATS strictly for the purpose IBM intended: driving access paths for optimal performance.
Let’s dispel the delusion that using real-time statistics increases CPU costs. DB2 collects the statistics in real-time anyway, even if you aren’t using them. Experience and customer polls indicate that externalizing RTS has practically no impact on CPU. Because these statistics are collected in real-time, they’re timely and accurate.
So you have your statistics straight. They accurately reflect your database activity and you can rely on them as a basis for backups. The real-time statistics that pertain to backups include:
• COPYLASTTIME: The timestamp of the last full or incremental image copy on the table space or partition
• COPYUPDATEDPAGES: The number of distinct pages that have been updated since the last COPY
• COPYCHANGES: The number of insert, delete, and update operations since the last COPY