Home > Articles > Data > Oracle

6 Reasons to Migrate Your Oracle Databases Twice as Fast to Release

  • Print
  • + Share This
Oracle Database is the terminal release for Oracle 11g R2, and extended support for that release ends as of December 2015. Yet many Oracle shops haven't accelerated their pace to transition to Oracle Database 12c R1. Oracle ACE Director Jim Czuprynski, author of Oracle Database 12c New Features, Part 1 LiveLessons, explains why Oracle DBAs should redouble their upgrade efforts to take advantage of six key feature sets available in Oracle Database
From the author of

Oracle Database 12c Release 1 has been generally available since July 2014, but in my conversations with my fellow DBAs and colleagues, I'm surprised at the relatively low initial adoption rates—especially when version has added even more feature sets that offer the capability of significantly improving database application performance, DBA productivity, and physical disk space utilization. To bring everyone up to speed, this article provides a brief summary of just six key features that have the potential to rock a DBA's world with Oracle

Reason 1: When in Doubt, Do It in Memory

Oracle offers one of the most significant performance improvement features in its history: the in-memory column store (IMCS). IMCS makes it possible to cache data from a table or table partition in a totally different columnar format that's optimal for analytics or data warehousing queries, while still retaining that data in standard row-major format in the database buffer cache for normal DML processing. My simple tests have shown performance improvement on queries in the range of 10X to 100X—without changing a single line of SQL code.

Oracle also offers in-memory joins to quickly process result sets between multiple tables, even if not all the tables are resident within the IMCS. And for data warehousing queries that leverage star transformation, Oracle can increase their speed dramatically via its new in-memory aggregation features.

Reason 2: SQL That (Almost) Tunes Itself

Starting in Oracle, the Oracle query optimizer is more sophisticated than ever before. The optimizer now can choose a different sub-plan for a query—switching between, say, a hash join and a nested-loop join method, without having to reparse its execution plan. This new dynamic plan feature works by buffering a query's execution statistics at key points in the execution plan and then deciding which method is most appropriate while the query is still executing.

If a query can't take advantage of dynamic plans because something other than the join method would need to change (say, the order in which row sets are joined), Oracle offers another feature called automatic re-optimization (ARO) that kicks in during the second and subsequent executions of the query. The optimizer retains special directives within the shared pool that tells the database to take alternate action for performance improvement (for example, when the query's first execution showed wildly divergent actual statistics versus the estimated optimizer statistics in the data dictionary), ARO may instruct it to gather more accurate statistics to fine-tune the execution plan.

ARO and dynamic plans thus offer the optimizer a feedback loop mechanism to constantly improve a query's performance. Even better, the discoveries that the optimizer has made are retained within the data dictionary as SQL plan directives (SPDs). SPDs don't apply to specific SQL statements or execution plans; rather, they describe the best methods to perform certain types of operations against row sources. So when the optimizer has discovered several alternative ways to join together row sources or leverage different optimizer statistics when filtering data, the lessons learned are retained as SPDs for other queries that access these same row sources.

Finally, the Oracle 12.1 optimizer can leverage the lessons it has learned while processing queries to recommend gathering extended statistics for specific tables and row sources. For example, if a query against a table is constantly grouping and aggregating data within a particular set of columns, the optimizer can recommend that extended statistics be gathered on those columns; the next time that similar statements are executed against that row source, the optimizer can make a more intelligent decision using those extended statistics.

Reason 3: Partitioning and Indexing Improvements

It's no secret that the onset of Big Data and the Internet of Things has accelerated the growth rates of data collection within IT organizations while demanding nearly real-time access to all this data. This new reality requires Oracle DBAs to manage their data warehouses ever more effectively, with limited downtime. Oracle acknowledges this reality with significant upgrades to partition maintenance procedures; it's now possible to perform several ADD, SPLIT, MERGE, DROP, or TRUNCATE partition operations simultaneously via a single command instead of performing each operation serially.

Oracle 12.1 now also permits the migration of a datafile between different storage tiers—say, from non-ASM to ASM, or from Exadata storage to ZFS storage—without having to take the datafile offline, while still permitting DML operations during the migration. This same functionality extends to partition-level migration operations; it's possible to move partitions between different storage tiers, or even change a partition's compression level, while still permitting DML against the partitions involved.

Even better, maintenance of the corresponding global and local partitioned indexes can take place simultaneously, thus simplifying the often colossal and extremely complex task of partition maintenance. When it makes sense to do so, it's now possible to create local and global partitioned indexes on just a subset of table partitions that can realistically take advantage of indexing, while ignoring partitions that are either hardly ever accessed or often accessed via full scans.

Reason 4: If Your Hottest Data Is Getting Colder, ILM Will Save Space and Time

As already noted, data growth continues unabated within most IT organizations, so it's good that the trend toward ever-cheaper disk-based storage has continued as well. However, most Oracle shops still struggle with deciding when to purge "old" data that's being retained for purely regulatory reasons, or just in case that one user query might someday need to access a business transaction from the distant past. Many Oracle DBAs have locked horns with storage administrators over why their databases are consuming so much "spinning rust."

Oracle offers an eminent solution: a completely new information lifecycle management (ILM) strategy that uses heat maps to determine which data users constantly access for DML, access just for reporting, or hardly ever access at all anymore. Heat maps make it possible to decide intelligently when to migrate data—especially when it's partitioned!—to a lower-cost storage tier, or even compress data that's grown cold, for significant space savings. Oracle 12.1's new ILM policies automate these decisions so that the coldest data is migrated or compressed only after a significant change in data access patterns is detected. For example, when a particular partition hasn't been touched by a single query in over 180 days, ILM automatically migrates the partition to a different tablespace that resides on lower-cost storage, simultaneously compressing it appropriately to save even more space.

Reason 5: Faster Physical I/O Via Attribute Clustering and Zone Mapping

As the trend of "de-siloing" continues in our industry, most IT organizations have begun to transition to enterprise systems like Oracle Exadata or SPARC Supercluster for their most demanding computing and storage needs. Database application workloads thus usually can take advantage of massive numbers of CPUs and huge amounts of memory, but this often means that physical I/O remains the final performance bottleneck to be conquered. Oracle offers two new feature sets that provide speedier access to data stored on spinning disk.

An Oracle DBA can leverage attribute clustering to improve physical I/O performed against data segments, by grouping a table's row pieces into a more appropriate order on physical disk based on how the data most likely will be queried. For example, data can be ordered within a data warehousing fact table based on how the data is grouped in corresponding dimension tables, or even based on the order in which rows will be joined between the fact table and its dimension tables.

Attribute clustering thus tends to improve data compressibility because like data values will be located closer to each other—perhaps even within the same database block or extent—which usually has a positive impact on data accessed via full table scans. Thanks to this closer proximity, clustered data also tends to require fewer CPU cycles to compress. And if the DBA is fortunate enough to store data within an Exadata Database Machine or on a SPARC Supercluster, attribute clustering can take direct advantage of advanced Oracle enterprise system features such as Exadata storage indexes and zone mapping.

Zone mapping is another new feature in Oracle that focuses specifically on accurately ascertaining exactly where data is stored on I/O devices. A zone map is actually a special database object that stores the minimum and maximum values for columns most commonly used during application of filters for the corresponding selection criteria within a SQL statement. When zone mapping is deployed in concert with attribute clustering, these complementary features tend to locate data with significantly fewer physical I/Os.

Reason 6: Faster Backups, More Granular Recovery

Oracle Database 12c enhances RMAN to permit multithreaded backups of image copies. In other words, it's now possible to make an image copy backup using several parallel RMAN I/O channels, thus speeding creation of datafile image copies. Of course, an image copy that has been backed up using this methodology can also be restored using parallel I/O channels, speeding their recovery dramatically.

RMAN also now offers the capability to perform point-in-time recovery (PITR) at an individual table level. In prior releases, PITR granularity was limited to the tablespace set boundary level; in Release, any individual table or any table set (for example, ones with a parent-child relationship) can be recovered at this level with a few simple RMAN commands.

Interested in Delving Deeper into Oracle Database

If you'd like to learn more about the intricacies of these feature sets, take a look at my most recent Pearson LiveLessons series: Oracle Database 12c New Features, Part 1 is available exclusively through Safari Online and other channels. This 190-minute streaming video series offers an extremely deep dive into all of these features, including myriad code examples that are invaluable for understanding as well as implementing these features in your 12c database.

  • + Share This
  • 🔖 Save To Your Account