Oracle Database In-Memory technology has been provided to everyone in the 12c version, which is a technology that "can have both fish and bear's paws". As the database version continues to upgrade, In-Memory technology also continues to evolve. In Oracle Database 21c, it has brought many surprises to everyone. Next, let's learn about the In-Memory technology enhancements in Oracle Database 21c through experiments.
Automatic In-Memory
With Automatic In-Memory technology enabled, data can be filled, deleted, and recompressed segments without user intervention. When INMEMORY_AUTOMATIC_LEVEL is set to HIGH, the database will automatically enable and fill the segment according to the usage mode of the segment. Combined with the support for selective column-level recovery and recompression, In-Memory data filling is largely self-managing. This automation helps to maximize the number of objects that can be filled into the In-Memory column store at one time.
Automatic In-Memory will automatically optimize the data in memory when the SQL workload changes , without human intervention . The working data set consists of the most frequently queried segments. Generally, for many applications, the working data set changes over time. The user must decide which segments use In-Memory technology, and often need to monitor to determine the loading and deletion of data segments, and create an ADO IM strategy. This requires the database administrator to have a comprehensive understanding of the workload.
In order to free the DBA from manual maintenance, Automatic In-Memory uses frequently updated internal statistical information to maintain the working data set in the IM column store. The Oracle database decides what kind of data to load, what kind of data to clear, and when to execute it. In a sense, IM column storage realizes "automatic driving".
When the initialization parameter INMEMORY_AUTOMATIC_LEVEL is set to HIGH, Automatic In-Memory will continuously monitor the column statistics in the IM storage and set all segments without INMEMORY attributes in advance to INMEMORY MEMCOMPRESS AUTO. The database only loads objects that it decides to belong to the working data set. This decision is based on current usage statistics. The database uses internal column statistics to identify the inactive area of IM storage, which is similar to that used by Heat Map, but does not need to set HEAT_MAP to ON. Automatic In-Memory can recompress inactive data in AUTO segments to save space. Segments whose priority is set to non-NONE will be excluded from the automatic clearing algorithm.
Next, we use an example to understand how Automatic In-Memory works and see how it automatically loads data into IM column storage and clears inactive data from it.
test analysis
First, we use the following statement to query the memory configuration of the current database, and then set INMEMORY_AUTOMATIC_LEVEL to LOW (no automatic IM management is started) , and then create a table under the HR user called emp, then insert some data, and It is put into memory.
Next, we view the IM attribute of the emp table we just created, and modify the IM attribute of HR.JOB_HISTORY, put it into IM and start compression.
Now we start the automatic IM management, just set INMEMORY_AUTOMATIC_LEVEL to HIGH. This operation must be performed on the container database. After setting, restart the database to make it take effect.
Then we check the IM status of the table below HR.
If you can't see the default enabled and set to the auto state shown in the red box above, just set it at the PDB level through the statement below, and restart the PDB.
By observing the IM status of each table under HR above, we find that the status of the COUNTRIES table is disabled. Why is it not modified together with other tables? Let's use the following statement to forcefully modify its IM attribute to see.
As you can see through the prompts, In-Memory does not support IOT tables, and COUNTRIES is an IOT table.
Next, we perform a full table scan on the table under HR.
Why is only the data of the emp table loaded into the memory, but not the data of other tables? There are two reasons for this: First, the system decides which tables should be put into memory based on the statistical values, because the statistical values are not updated in real time. Just finished the data query, the statistical values have not been updated, so the table information has not been loaded yet IM storage. Secondly, the statistical value is already up-to-date, but the system considers the data to be cold data and should not be placed in IM storage.
Aotu In-Memory at the CellMemory level
Currently, CellMemory on the Exadata unit requires inmemory_size on the RDBMS side to be> 0. This is because CellMemory requires the In-Memory option. For autonomous databases and Oracle Cloud running EE extreme performance, inmemory_size does not need to be set. This has been done in Bug 26797490. Now, we hope to introduce INMEMORY_FORCE=cellmemory_level to allow local customers to use CellMemory without setting inmemory_size.
In-Memory enhancements to external tables
For partitioned or mixed external tables, the INMEMORY clause is supported at the table and partition level. For mixed tables, the table-level INMEMORY attribute applies to all partitions, whether internal or external. This enhancement greatly expands the support for external tables in memory.
In-Memory software licensing issues
We know that In-Memory is an option for Oracle Database Enterprise Edition. Now Oracle, in order to allow our customers to enjoy the performance improvement brought by using In-Memory, to a certain extent, we use In-Memory as the database The basic features are provided to everyone. If you already use the Oracle Enterprise Edition database and the In-Memory column storage setting does not exceed 16GB, you will not need to pay the copyright fee for the In-Memory option. For the copyright-free part, there are the following restrictions on use:
1. AIM prohibited
2. The compression level can only be QUERY LOW
3. Cannot exclude columns
4. Prohibited by CELL MEMORY (Exadata feature)
In-Memory Hybrid Scan
When not all columns in a table are put into the In-Memory column store, Oracle database also supports In-Memory scanning at this time. This happens when, for the purpose of saving space, certain columns are set to NO INMEMORY. In-Memory hybrid scanning can read data from column storage and row storage at the same time, which is the same as reading from row storage completely before Data, performance is improved by several orders of magnitude.
Before Oracle Database 21c, if a query references any column with the NO INMEMORY attribute, then the query will access all data in the buffer cache. Therefore, table scans cannot use column formats, predicate pushdowns, and other In-Memory features. Starting from Oracle Database 21c, queries with INMEMORY and NO INMEMORY columns can access column storage data. In some cases, IM hybrid scanning can improve performance by several orders of magnitude. When the query has a selective filter, the performance will be maximized. In this case, IM column storage can quickly filter out most rows so that row storage only projects a small number of rows. In order to achieve optimal performance, the optimizer compares different access methods. If the optimizer selects a table scan, the storage engine will automatically determine whether the performance of the IM hybrid scan is better than the conventional row storage scan. When the following conditions are met, the optimizer will consider hybrid scans:
-
The predicate only contains the INMEMORY column.
-
The selection list contains any combination of INMEMORY and NO INMEMORY
The IM hybrid scan logically divides the work into two parts: one part deals with queries to IM column storage, and the other part deals with queries to row storage. In the execution plan, the TABLE ACCESS INMEMORY FULL (HYBRID) operation represents a hybrid scan. Please note that if runtime statistics indicate that only accessing the row store will improve performance, then the database can disable IM hybrid scanning at runtime.