The following sections describe the new compression and archiving features for Oracle Database 12c Release 1 (12.1).
1.3.1 Archiving
The following sections describe archiving features.
1.3.1.1 Database Hardening: Enable Flashback Data Archive (FDA) for
Security-Related Application Tables
This features extends the Flashback Data Archive (FDA) feature to provide full history on security sensitive tables of an application. This feature provides a single command to enable FDA on all the designated tables for an application and addresses the need for strong auditing for these tables. This feature also allows the administrator to make all security tables in an application read-only with a single command.
Database hardening makes it easy to track history for all security-related tables in an application and to make those tables read-only as needed, without the need for writing scripts to loop through all the tables or other manual operations. Extending Flashback Data Archive support for tables grouped together by application makes it easy to track all the changes made to those tables and to access the history using Oracle Flashback Query.
See Also:
Oracle Database SQL Tuning Guide for details
See Also:
Compression and Archiving
1.3.1.2 Flashback Data Archive Improvements
Several improvements have been made to Flashback Data Archive (FDA). They are:
■ User-context tracking
The metadata information for tracking transactions including the user context is now tracked making it easier to determine which user made which changes to a table.
■ Hybrid Columnar Compression (HCC)
FDA can now be fully utilized on HCC compressed tables on Exadata and other Oracle storage platforms.
■ Import and export of history
Support for importing user-generated history into FDA tables has been added. Customers who have been maintaining history using some other mechanism, such as triggers, can now import that history into FDA.
1.3.2 General
The following section describes a new Flashback Data Archive feature.
1.3.2.1 Optimization for Flashback Data Archive History Tables
When using Flashback Data Archive to track changes on tables, you can now enable optimization of the corresponding history tables using the OPTIMIZE DATA clause when creating a Flashback Data Archive.
Optimization of Flashback Data Archive history tables will provide better storage efficiency and better performance for flashback queries on the change history without additional intervention needed by the DBA.
1.3.3 Information Lifecycle Management
The following sections describe Information Lifecycle Management (ILM) features.
1.3.3.1 Automatic Data Optimization (ADO)
This feature provides declarative syntax for specifying Information Lifecycle Management (ILM) policies at the row, segment, and table level.
Database administrators can use this feature to automate the movement of data between different tiers of storage and between different levels of compression. This capability depends on the Heat Map feature which tracks access at the row level (aggregated to block-level statistics) and at the segment level.
See Also:
Oracle Database Development Guide for details
See Also:
Oracle Database Development Guide for details
See Also:
Compression and Archiving
1.3.3.2 EXECUTE_ILM Procedure
This feature provides a PL/SQL procedure to enforce ADO policies immediately or after a short time delay.
It is sometimes necessary to move data as quickly as possible from one tier to another, or from one compression level to another. The EXECUTE_ILM procedure provides the ability to do so, regardless of any previously scheduled ADO policies.
1.3.3.3 Heat Map
The Heat Map tracks modifications for individual rows (aggregated to the block level) and modifications and queries at the partition or table level.
Users can implement automated policy-driven data movement and data compression based on the information tracked in the Heat Map using the new ADO feature or using their own tools and scripts.
1.3.3.4 PL/SQL Interface for Managing ADO Policies
This feature provides a PL/SQL interface for managing ADO policies, including functions such as scheduling, priority and resource management.
Some customers need to implement complex Information Lifecycle Management (ILM) scenarios, by controlling when their ADO policies are actively moving data, and how much system resources are consumed with data movement operations. This feature provides the ability to manage ILM activities so that they do not negatively impact important production workloads.
1.3.3.5 Row-Level Compression Tiering
This feature provides the ability to specify ADO policies to implement compression at the row level within each table in a database. Compression is implemented when all rows in a database block qualify based on the policy being evaluated.
In combination with automatic segment-level compression tiering, this feature provides database administrators with fine-grained control over how the data in their database is stored and managed.
1.3.3.6 Segment-Level Compression Tiering
This feature provides the ability to specify ADO policies to implement compression at the segment level within each table in a database.
In combination with automatic row-level compression tiering, this feature provides database administrators with fine-grained control over how the data in their database is stored and managed.
See Also:
Oracle Database VLDB and Partitioning Guide for details
See Also:
Oracle Database VLDB and Partitioning Guide for details
See Also:
Oracle Database VLDB and Partitioning Guide for details
See Also:
Compression and Archiving
1.3.3.7 In-Database Archiving
In-Database Archiving allows users and applications to set the archive state for individual rows. Rows that have been marked as archived will not be visible unless the session is enabled to see archived data.
With In-Database Archiving, more data can be stored in production databases for a longer period of time without compromising application performance. In addition, archived data can be aggressively compressed to help improve query and backup performance. Updates to archived data can be deferred during application upgrades, greatly improving the performance of upgrades.
1.3.4 SecureFiles Enhancements
The following sections describe SecureFiles enhancements.
1.3.4.1 Enable PDML Operations on SecureFiles
Limitations have been removed in this release with regard to Parallel DML (PDML) support for SecureFiles LOBs.
This feature allows SecureFiles to leverage the performance and scalability benefits of the PDML features of Oracle Database.
1.3.4.2 Oracle Data Pump: Support SecureFiles LOB as Default
The impdp command line has a new parameter (and the PL/SQL DBMS_DATAPUMP package has a new option) that tells Oracle Data Pump to create all LOBs as
SecureFiles LOBs. By default, beginning with Oracle Database 12c Release 1 (12.1), all LOB columns are created as SecureFiles LOBs. However, Oracle Data Pump re-creates tables exactly as they existed in the exported database, so if a LOB column was a BasicFile LOB in the exported database, Oracle Data Pump attempts to re-create it as a BasicFile LOB in the imported database.
This feature allows the user to force creation of LOBs as SecureFiles LOBs and to migrate to the latest more performant feature.
1.3.4.3 SecureFiles is the Default for LOB Storage
In this release, SecureFiles is now the default for LOB storage when the compatible initialization parameter is set to 12.1 or higher.
The SecureFiles feature provides optimal performance for storing unstructured data in the database. Making SecureFiles the default for unstructured data helps ensure that
See Also:
Oracle Database VLDB and Partitioning Guide for details
See Also:
Oracle Database VLDB and Partitioning Guide for details
See Also:
Oracle Database SecureFiles and Large Objects Developer's Guide for
details
See Also:
Database Overall
the database is delivering the best performance possible when managing unstructured data.