Operational databases are growing in size for many reasons, not the least of which is the growing importance of big data and analytics projects. There is the overarching trend of more and more data being generated every
year. But also, there is the growing need to store more data for longer periods
of time due to regulatory and compliance issues. Some organizations and business have encountered the need to store certain types of data for 100 years or more (as this video and this storage project point out).
But I doubt that I really need to convince you that your databases are growing in size. Most DBAs experience the reality of data growth every day.
As data volumes expand, it impacts operational databases in
two ways:
- additional
data stresses transaction processing and can cause performance slow downs, and;
- database
administration tasks are negatively impacted.
In terms of performance, the more data in the operational
database, the less efficient transactions running against that database tend to
be. Table scans must reference more pages of data to return a result. Indexes
grow in size to support larger data volumes, causing access by the index to
degrade because there are more levels to traverse to return an answer. Such
performance impacts are causing many companies to seek solutions that offload
older data to either reference databases or to archive data stores.
The other impact, database administration complexity, causes
longer processing time and outages to perform such functions as backups,
unloads, reorganizations, recoveries, and disaster recoveries. The larger the underlying data sets for your tables and table spaces, the longer it takes to run administrative utilities for them. In many cases the lengthened outages can become unacceptable, causing companies to again seek ways to lighten up the
operational databases... or perhaps acquire next generation utility technology that understands the reality of large DB2 database objects.
But even though we want to keep all of that additional data, there is no reason that it necessarily has to be stored in operational databases that run the business. For many reasons, you probably want to separate active data from historical data.
Some companies create purge jobs for all (or many) of their tables to remove data from the production databases as it ages. This can be an acceptable approach to reduce the size of your operational databases. But it also means that the data, which you might want to keep for analytical purposes, is lost. Another approach is to archive the data. Archiving data and purging data are two different processes. When data is purged, it is removed from the operational database and discarded. But archived data is removed from the operational database and maintained in an archive data store. The archive might be a flat file, another relational table or to HDFS using Hadoop.
The bottom line is that it makes sense for us, as DBAs, to keep any eye on the size of our operational databases and take action when production workload is impacted.
