In the last couple blogs we’ve discussed both Advanced Row Compression and Hybrid Columnar Compression a bit – we will discuss them more, in greater detail, in upcoming blogs. But for now, we’re going to discuss a new topic, automating Information Lifecycle Management, which will include the data compression features we’ve already briefly discussed.
Before Oracle Database 12c, when organizations wanted to implement an ILM strategy they would have typically leveraged the Advanced Compression and Data Partitioning options to create a manual database compression and storage tiering solution – a solution which required organizations to have a fairly deep understanding of their data access and usage patterns, often across thousands of tables/partitions.
What became very clear, to these organizations after implementing a manual database compression tiering and/or storage-tiering solution, was that the ideal ILM solution was one that is automated, relying not solely upon the collective knowledge of the organization, especially given that some vital owners of that knowledge had long since changed positions or even left the organization.
But in order to automate database compression tiering and storage tiering the database has to know what the current usage levels are for the numerous tables and partitions under its management, across possibly hundreds or thousands of tables and partitions. To be effective, it is crucial that the database know where each table and/or partition is in terms of its usage, is the table/partition still being actively modified, or has it cooled down and is primarily historic/archive data now?
And then the other question, once data usage tracking was automated then what? Tracking usage is only part of the answer in terms of automating database compression tiering and storage tiering, the other part of the answer is being able to take action (and automating these actions is key) in regards to the database compression and/or storage tiering of these tables and partitions.
The answers to ILM automation are these Oracle Database features:
Heat Map automatically tracks data usage information at the row and segment levels. Data modification times are tracked at the row level and aggregated to the block level, and modification times, full table scan times, and index lookup times are tracked at the segment level. Heat Map enables a detailed view of how data is being accessed, and how access patterns are changing over time.
Automatic Data Optimization
ADO enables organizations to create policies for data compression and data movement and to implement tiering of compression and storage. Oracle Database periodically evaluates ADO policies, and uses the information collected by Heat Map to determine which operations to execute. All ADO operations are executed automatically and in the background, with no user intervention required.
But before we dive deeper into the best practices around automating database compression tiering and storage tiering we first need to understand Heat map in greater detail, and after that we’ll look at the best practices around ADO as well – so stay tuned. (or see here for more details if you just can’t wait…)
But for now the database storage optimization adventure continues in the next blog, in which we will discuss the vital role that the Heat Map feature plays in terms of automating Information Lifecycle Management, specifically, database compression and storage tiering with Oracle Database.