For how many years have you been working
with physical servers that are starving your database of the memory
necessary to deploy important new performance features such as the Result
Cache, Memoptimize Pool, In-Memory Aggregation, In-Memory Column Store, and
Full Database Caching? Too long? Contact me to learn how to improve all
queries ... not just some queries.
To quote the Oracle New Features doc:
"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."
Row-level policies for ADO are not supported for in-database archiving. Partition-level ADO and compression are supported if partitioned on the ORA_ARCHIVE_STATE column.
-- no information on the second hidden column created during the alter table has been published by Oracle to date.
Disable a table previously enabled for ROW ARCHIVAL storage
ALTER TABLE <table_name> NO ROW ARCHIVAL;
ALTER TABLE alter2row_archival NO ROW ARCHIVAL;
SELECT column_name, hidden_column
WHERE table_name = 'ALTER2ROW_ARCHIVAL';
By Enabling IDA in conjunction with partitioning it is theoretically possible to automatically compress partitioned rows.
At least that is the theory based on what I've read in the docs ... but as you can see it does not work the way I expected: More research to do.