Optimize Oracle In-Memory Column Store with Heat Map Analysis

Overview

In the evolving landscape of enterprise applications, particularly within complex ecosystems like Oracle PeopleSoft, the demand for real-time analytics and lightning-fast reporting has never been more critical. Traditional row-based database architectures, while excellent for Online Transaction Processing (OLTP), often struggle to deliver optimal performance for analytical queries that scan large volumes of data. This is where Oracle Database In-Memory, a game-changer introduced in Oracle 12c, steps in. It provides a dual-format architecture, maintaining the traditional row store for OLTP and introducing an innovative In-Memory Column Store (IMCS) optimized for analytical workloads.

The Oracle Database In-Memory Column Store isn't just about putting data in RAM; it's about fundamentally re-architecting how data is stored and processed for analytics. Data in the IMCS is stored in a columnar format, which is inherently more efficient for queries that access a subset of columns from a large table. Coupled with advanced compression, vector processing, and parallel execution capabilities, IMCS can deliver orders of magnitude performance improvement for analytical queries, reporting, and data warehousing tasks.

For PeopleSoft environments, which often involve extensive reporting on financial, HR, and supply chain data, IMCS offers a transformative advantage. Imagine nVision reports, BI Publisher extracts, or custom SQR reports that previously took hours, now completing in minutes or even seconds. This accelerates business decision-making, improves user experience, and reduces the load on the underlying database infrastructure.

However, simply enabling In-Memory is not enough. To maximize its benefits, a strategic approach is required to identify which database objects (tables, partitions) would most benefit from being populated into the IMCS. This is where "Heat Map Analysis" becomes an indispensable tool. Oracle's Heat Map feature automatically tracks the usage patterns of database segments, providing insights into which tables are frequently accessed, modified, and, crucially for In-Memory, queried. By combining Heat Map analysis with a deep understanding of PeopleSoft's data access patterns, DBAs and performance architects can make informed decisions, ensuring optimal resource utilization and maximum performance gains from the In-Memory Column Store.

Prerequisites

Before embarking on the journey to enable and leverage Oracle Database In-Memory, several key prerequisites must be met to ensure a smooth and successful implementation:

• Oracle Database Enterprise Edition: Oracle Database In-Memory is an option available only with the Enterprise Edition of Oracle Database. It is not available with Standard Edition or other editions.
• Oracle Database In-Memory Option: You must have purchased and licensed the Oracle Database In-Memory option. Without the appropriate license, enabling the feature is a violation of your licensing agreement.
• Oracle Database Version: Oracle Database In-Memory was introduced in Oracle 12c Release 1 (12.1.0.2). While it functions in 12cR1 and 12cR2, it has seen significant enhancements, optimizations, and new features in later releases, particularly Oracle 19c and Oracle 21c. It is highly recommended to be on at least 19c for the best experience and feature set.
• Sufficient Memory (RAM): This is perhaps the most critical hardware prerequisite. The In-Memory Column Store resides entirely in the database's System Global Area (SGA). You must allocate sufficient RAM to the SGA, specifically for the INMEMORY_SIZE parameter. A general guideline is to allocate enough memory to hold your most critical analytical tables/partitions. Ensure the operating system has enough physical memory to support the increased SGA size, as insufficient memory can lead to paging and negate performance benefits.
• 64-bit Operating System: The Oracle Database In-Memory option requires a 64-bit operating system, as it relies on accessing large amounts of memory.
• Understanding of Workloads: A clear understanding of your database's workload characteristics is vital. In-Memory is primarily beneficial for analytical queries (OLAP) that involve large scans, aggregations, and joins. It is generally not designed to accelerate single-row lookups or heavy OLTP transactions. For PeopleSoft, this means identifying tables involved in complex reporting, data extracts, and analytical processes.
• PeopleSoft Application Knowledge: Familiarity with key PeopleSoft tables and their typical usage patterns (e.g., PS_LEDGER, PS_JOB, PS_AP_VOUCHER, PS_GL_BAL_TBL for financial reporting; PS_TL_RPTD_TIME for time and labor analysis) will significantly aid in selecting candidates for the In-Memory Column Store.
• Database Administrator (DBA) Skills: Proficiency in Oracle database administration, including parameter management, SQL tuning, and monitoring, is essential for successful implementation and ongoing management.

Step-by-Step Implementation

Enabling Oracle Database In-Memory

The first step is to enable the In-Memory Column Store and allocate memory for it within the SGA. This is controlled by the INMEMORY_SIZE initialization parameter.

-- 1. Check current INMEMORY_SIZE (should be 0 if not enabled)
SHOW PARAMETER INMEMORY_SIZE;

-- 2. Allocate memory for the In-Memory Column Store.
--    This example sets it to 10 Gigabytes. Adjust based on your available RAM and planned usage.
--    It's recommended to set it via SPFILE and restart the instance for it to take effect.
ALTER SYSTEM SET INMEMORY_SIZE = '10G' SCOPE=SPFILE;

-- 3. Optionally, configure other In-Memory related parameters.
--    INMEMORY_QUERY_LOW_PRIORITY_CPU_PERCENT: Controls CPU usage for background population.
ALTER SYSTEM SET INMEMORY_QUERY_LOW_PRIORITY_CPU_PERCENT = 50 SCOPE=BOTH;

--    INMEMORY_TRICKLE_REPOPULATE_SERVERS_PERCENT: Controls how many background servers repopulate data.
ALTER SYSTEM SET INMEMORY_TRICKLE_REPOPULATE_SERVERS_PERCENT = 1 SCOPE=BOTH;

--    INMEMORY_MAX_POPULATE_SERVERS: Maximum number of parallel servers for population.
ALTER SYSTEM SET INMEMORY_MAX_POPULATE_SERVERS = 4 SCOPE=BOTH;

-- 4. Restart the database instance for INMEMORY_SIZE to take effect.
--    For single instance:
SHUTDOWN IMMEDIATE;
STARTUP;

--    For Oracle RAC (on all instances):
--    srvctl stop instance -d  -i 
--    srvctl start instance -d  -i 
--    (Repeat for all instances)

-- 5. Verify that INMEMORY_SIZE is now set.
SHOW PARAMETER INMEMORY_SIZE;

-- 6. Check the In-Memory status (should show 'ENABLED')
SELECT * FROM V$IM_PARAMETER WHERE PARAMETER = 'INMEMORY_SIZE';

Once enabled, the In-Memory Column Store is available for use, but no objects are populated into it yet. The next crucial step is to identify which objects should reside in this high-performance memory area.

Identifying Candidates for In-Memory (Heat Map Analysis)

Oracle's Heat Map feature provides invaluable insights into data access patterns, helping you pinpoint tables and partitions that are frequently read or modified. This information is critical for making informed decisions about which objects to place in the In-Memory Column Store, ensuring you get the most impact for your allocated memory.

-- 1. Enable Heat Map.
--    It's recommended to enable it at the system level for comprehensive tracking.
ALTER SYSTEM SET HEAT_MAP = ON SCOPE=BOTH;

-- 2. Wait for data collection.
--    Allow your typical application workloads (e.g., PeopleSoft reporting, batch processes)
--    to run for a sufficient period (e.g., a few days to a week) to gather representative data.
--    The Heat Map data is automatically managed and flushed by the MMON background process.

-- 3. Query Heat Map views to identify frequently accessed segments.
--    We are particularly interested in segments with high read frequencies.
--    Let's look for PeopleSoft schema objects (e.g., SYSADM or specific custom schemas).

--    Example 1: Top 20 most frequently accessed segments by read count
SELECT * FROM (
    SELECT
        OWNER,
        SEGMENT_NAME,
        SEGMENT_TYPE,
        TABLESPACE_NAME,
        ACCESS_COUNT_READ AS READ_COUNT,
        ACCESS_COUNT_WRITE AS WRITE_COUNT,
        TO_CHAR(LAST_ACCESS_TIME, 'YYYY-MM-DD HH24:MI:SS') AS LAST_READ_ACCESS,
        TO_CHAR(LAST_UPDATE_TIME, 'YYYY-MM-DD HH24:MI:SS') AS LAST_WRITE_ACCESS,
        TO_CHAR(CREATION_TIME, 'YYYY-MM-DD HH24:MI:SS') AS CREATION_TIME
    FROM
        DBA_HEAT_MAP_SEGMENT
    WHERE
        OWNER LIKE 'SYSADM%' -- Focus on PeopleSoft schema
        AND SEGMENT_TYPE IN ('TABLE', 'TABLE SUBPARTITION', 'TABLE PARTITION')
    ORDER BY
        ACCESS_COUNT_READ DESC
) WHERE ROWNUM <= 20;

--    Example 2: Segments with high read activity and low write activity (ideal for In-Memory)
SELECT
    OWNER,
    SEGMENT_NAME,
    SEGMENT_TYPE,
    TABLESPACE_NAME,
    ACCESS_COUNT_READ AS READ_COUNT,
    ACCESS_COUNT_WRITE AS WRITE_COUNT,
    ROUND(ACCESS_COUNT_READ / (ACCESS_COUNT_READ + ACCESS_COUNT_WRITE) * 100, 2) AS READ_PERCENTAGE
FROM
    DBA_HEAT_MAP_SEGMENT
WHERE
    OWNER LIKE 'SYSADM%'
    AND SEGMENT_TYPE IN ('TABLE', 'TABLE SUBPARTITION', 'TABLE PARTITION')
    AND ACCESS_COUNT_READ > 0
    AND (ACCESS_COUNT_READ + ACCESS_COUNT_WRITE) > 0 -- Avoid division by zero
ORDER BY
    READ_PERCENTAGE DESC, ACCESS_COUNT_READ DESC
FETCH FIRST 20 ROWS ONLY;

--    Example 3: Identify specific PeopleSoft tables known for reporting.
--    Check their access patterns.
SELECT
    OWNER,
    SEGMENT_NAME,
    ACCESS_COUNT_READ AS READ_COUNT,
    ACCESS_COUNT_WRITE AS WRITE_COUNT,
    TO_CHAR(LAST_ACCESS_TIME, 'YYYY-MM-DD HH24:MI:SS') AS LAST_READ_ACCESS
FROM
    DBA_HEAT_MAP_SEGMENT
WHERE
    OWNER = 'SYSADM'
    AND SEGMENT_NAME IN ('PS_LEDGER', 'PS_AP_VOUCHER', 'PS_JOB', 'PS_GL_BAL_TBL', 'PS_HR_EE_ADDR')
ORDER BY ACCESS_COUNT_READ DESC;

-- 4. Interpreting Heat Map Results:
--    - High ACCESS_COUNT_READ: These are strong candidates.
--    - Low ACCESS_COUNT_WRITE: Objects with fewer writes are generally better, as writes
--      require updating both the row store and potentially the IMCS. However, IMCS handles DML efficiently.
--    - LAST_ACCESS_TIME: Indicates recent activity.
--    - Consider table size: Large tables with many columns and frequent analytical queries are prime candidates.
--    - PeopleSoft context: Focus on core transaction tables used in reporting, summary tables,
--      and configuration tables that are frequently joined.

-- 5. Managing Heat Map data (optional)
--    To flush the current Heat Map data to disk (usually done automatically):
--    EXEC DBMS_HEAT_MAP.FLUSH_HEAT_MAP_DATA();

--    To reset Heat Map statistics for a specific segment (e.g., after an application change):
--    EXEC DBMS_HEAT_MAP.RESET_HEAT_MAP_DATA(owner => 'SYSADM', segment_name => 'PS_LEDGER');

Based on the Heat Map analysis and your knowledge of PeopleSoft's analytical requirements, you can now prioritize which tables or partitions to populate into the In-Memory Column Store.

Populating Objects into the In-Memory Column Store

Once you've identified your target objects, you can instruct the database to populate them into the In-Memory Column Store. This is done using the INMEMORY clause with ALTER TABLE statements.

-- 1. Add a table to the In-Memory Column Store with default compression.
--    The table will be populated asynchronously when first queried or explicitly via DBMS_INMEMORY.
ALTER TABLE SYSADM.PS_LEDGER INMEMORY;

-- 2. Add a table with specific compression and priority.
--    MEMCOMPRESS FOR QUERY HIGH: Good balance between compression and query performance.
--    MEMCOMPRESS FOR CAPACITY HIGH: Highest compression, potentially slower query performance.
--    MEMCOMPRESS FOR CAPACITY LOW: Less compression, faster DML.
--    PRIORITY: Influences the order in which objects are populated into IMCS.
--      - NONE (default): Populated on first access or when space allows.
--      - LOW, MEDIUM, HIGH, CRITICAL: Higher priority objects are populated sooner.
ALTER TABLE SYSADM.PS_AP_VOUCHER INMEMORY MEMCOMPRESS FOR QUERY HIGH PRIORITY CRITICAL;

-- 3. Add a partitioned table or specific partitions to In-Memory.
--    For a partitioned table, you can specify the INMEMORY clause at the table level
--    to include all partitions, or at the partition/subpartition level for granular control.
ALTER TABLE SYSADM.PS_GL_BAL_TBL INMEMORY MEMCOMPRESS FOR CAPACITY HIGH; -- All partitions
ALTER TABLE SYSADM.PS_GL_BAL_TBL MODIFY PARTITION P2023_Q1 INMEMORY MEMCOMPRESS FOR QUERY LOW; -- Specific partition

-- 4. Remove a table from the In-Memory Column Store.
ALTER TABLE SYSADM.PS_LEDGER NO INMEMORY;

-- 5. Force population of an object into the In-Memory Column Store immediately.
--    This is useful for critical objects that you want available immediately after database startup
--    or after adding them to In-Memory.
EXEC DBMS_INMEMORY.POPULATE(schema_name => 'SYSADM', object_name => 'PS_AP_VOUCHER', force => TRUE);

--    To populate all objects marked INMEMORY in a schema:
EXEC DBMS_INMEMORY.POPULATE(schema_name => 'SYSADM', force => TRUE);

--    To populate all objects marked INMEMORY in the entire database:
EXEC DBMS_INMEMORY.POPULATE(force => TRUE);

-- 6. Check the In-Memory status of tables.
SELECT
    OWNER,
    TABLE_NAME,
    INMEMORY,
    INMEMORY_COMPRESSION,
    INMEMORY_PRIORITY,
    INMEMORY_DISTRIBUTE,
    INMEMORY_DUPLICATE
FROM
    ALL_TABLES
WHERE
    OWNER = 'SYSADM'
    AND INMEMORY = 'ENABLED';

Remember to select compression levels judiciously. For PeopleSoft reporting, MEMCOMPRESS FOR QUERY HIGH often provides the best balance between memory savings and query performance, while MEMCOMPRESS FOR CAPACITY HIGH is suitable for very large, less frequently queried archival data.

Monitoring In-Memory Performance and Usage

After enabling and populating objects, continuous monitoring is essential to ensure you are achieving the desired performance benefits and that your In-Memory Column Store is optimally utilized.

-- 1. Check the overall In-Memory Column Store memory usage.
SELECT
    POOL,
    ALLOCATED_BYTES,
    USED_BYTES,
    UNUSED_BYTES,
    POPULATE_BYTES,
    REPOPULATE_BYTES
FROM
    V$IM_MEMORY_CS;

-- 2. View details of objects currently in the In-Memory Column Store.
SELECT
    OWNER,
    SEGMENT_NAME,
    TABLESPACE_NAME,
    PARTITION_NAME,
    BYTES_ALLOCATED AS ALLOC_MB,
    BYTES_USED AS USED_MB,
    POPULATE_STATUS, -- 'COMPLETED', 'STARTED', 'OUT OF MEMORY', 'DUPLICATE'
    COMPRESSION_RATIO,
    INMEMORY_PRIORITY,
    INMEMORY_COMPRESSION,
    CON_ID
FROM
    V$IM_SEGMENTS
WHERE
    OWNER = 'SYSADM'
ORDER BY POPULATE_STATUS, BYTES_ALLOCATED DESC;

-- 3. Monitor In-Memory query performance.
--    V$IM_SCAN_INFO provides statistics on In-Memory scans.
SELECT
    STAT_NAME,
    VALUE
FROM
    V$IM_SCAN_INFO
WHERE
    STAT_NAME LIKE 'IM %'
ORDER BY STAT_NAME;

--    Key statistics to look for:
--    - 'IM scans (fast full)': Number of fast full scans using IMCS.
--    - 'IM bytes processed': Total bytes processed by IMCS.
--    - 'IM CUs created': Number of Compression Units (CUs) created.
--    - 'IM CUs scanned': Number of CUs scanned during queries.

-- 4. Check for In-Memory related alerts and errors.
--    Review the alert log and V$DIAG_INFO for any messages related to In-Memory.
--    Examples: ORA-00845 (INMEMORY_SIZE too large for SGA_TARGET/MAX_SGA_SIZE),
--    ORA-12000 (In-Memory option not licensed).

-- 5. Analyze execution plans for queries.
--    Ensure that queries are actually using the In-Memory Column Store.
--    Look for operations like "TABLE ACCESS INMEMORY FULL" or "INMEMORY TABLE ACCESS FULL".
EXPLAIN PLAN FOR
SELECT
    FISCAL_YEAR,
    SUM(ACCOUNT_BALANCE)
FROM
    SYSADM.PS_LEDGER
WHERE
    LEDGER_GROUP = 'ACTUALS'
GROUP BY
    FISCAL_YEAR;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY(FORMAT => 'ALL +NOTE'));

-- 6. For Oracle RAC environments, use GV$ views to monitor across instances.
SELECT
    INST_ID,
    POOL,
    ALLOCATED_BYTES,
    USED_BYTES
FROM
    GV$IM_MEMORY_CS
ORDER BY INST_ID;

SELECT
    INST_ID,
    OWNER,
    SEGMENT_NAME,
    POPULATE_STATUS,
    COMPRESSION_RATIO
FROM
    GV$IM_SEGMENTS
WHERE
    OWNER = 'SYSADM'
ORDER BY INST_ID, POPULATE_STATUS;

Regularly reviewing these monitoring views will help you fine-tune your In-Memory configuration, identify any issues, and ensure your PeopleSoft reports and analytical queries are getting the performance boost they deserve.

Security Considerations

While Oracle Database In-Memory significantly enhances performance, it's crucial to consider its implications for database security. The IMCS doesn't introduce new security vulnerabilities inherently, but it modifies how data resides and is accessed, which warrants attention:

• Data Encryption: If your PeopleSoft data is encrypted at rest (e.g., using Transparent Data Encryption - TDE), the data remains encrypted on disk. However, when loaded into the In-Memory Column Store, it is decrypted in memory for processing. This is standard for any database operation. Ensure your memory (SGA) is adequately protected against unauthorized access or memory dumps, as decrypted data will reside there.
• Access Control: Standard Oracle database access control mechanisms (roles, privileges, VPD/OLS) continue to apply fully to data residing in the IMCS. Enabling In-Memory does not bypass existing security policies. Users can only access data in the IMCS if they have the appropriate SQL privileges on the underlying tables.
• Memory Dumps: In the event of a database crash or diagnostic memory dump, the contents of the SGA, including the In-Memory Column Store, could potentially be written to trace files. Ensure these diagnostic files are secured and access is restricted to authorized personnel only, especially in environments handling sensitive PeopleSoft data (e.g., HR, Payroll, Financials).
• Secure Configuration: Follow general Oracle database security best practices. Keep your database patched to the latest security updates. Restrict access to database servers and operating system accounts that can interact with the Oracle processes or memory.
• Auditing: Continue to implement robust auditing policies to track access and modifications to sensitive data, regardless of whether it resides in the row store or the IMCS. The In-Memory feature does not alter auditing behavior.
• Resource Control: While not strictly a security concern, ensure that the allocation of INMEMORY_SIZE does not starve other critical database components, potentially leading to instability or performance degradation that could be exploited. Proper resource management is part of a secure and stable system.

In essence, Oracle Database In-Memory operates within the existing security framework of the Oracle Database. The key is to maintain vigilance over the physical and logical security of your database environment, recognizing that sensitive data will be processed in memory.

Best Practices

To maximize the benefits of Oracle Database In-Memory for your PeopleSoft environment, consider the following best practices:

• Start Small and Iterate: Don't try to put all tables into In-Memory at once. Begin with a few critical, high-impact PeopleSoft reporting tables identified by Heat Map analysis (e.g., PS_LEDGER, PS_AP_VOUCHER, large custom reporting tables). Monitor the impact, then gradually expand.
• Prioritize Analytical Workloads: In-Memory is designed for analytical queries that perform large scans, aggregations, and complex joins. Focus on tables heavily used by PeopleSoft nVision, BI Publisher, SQR reports, and custom analytics, rather than pure OLTP tables with frequent single-row lookups.
• Leverage Heat Map Effectively: Continuously use Heat Map analysis to validate your In-Memory object selection and identify new candidates. Re-evaluate periodically, especially after PeopleSoft upgrades or significant changes in reporting requirements.
• Monitor Memory Usage: Keep a close eye on V$IM_MEMORY_CS and V$IM_SEGMENTS. Ensure that your INMEMORY_SIZE is sufficient to hold your critical objects and that you are not experiencing 'Out of Memory' conditions during population. Adjust INMEMORY_SIZE as needed.
• Choose Compression Wisely:
  • MEMCOMPRESS FOR QUERY HIGH: Good balance for most PeopleSoft analytical tables, offering significant compression with excellent query performance.
  • MEMCOMPRESS FOR CAPACITY HIGH: Use for very large, less frequently accessed archival or historical PeopleSoft data where maximum memory savings are paramount, and slightly slower query performance is acceptable.
  • MEMCOMPRESS FOR CAPACITY LOW: Consider for tables with high DML activity where you still want In-Memory benefits but need to minimize the overhead of maintaining the IMCS.
• Set Appropriate Priorities: Use the PRIORITY clause (CRITICAL, HIGH, MEDIUM, LOW, NONE) to ensure that your most important PeopleSoft tables are populated into the IMCS first, especially after database startup or instance restarts.
• Consider INMEMORY_FORCE: Set INMEMORY_FORCE=ON (or FOR ALL/FOR DML) if you want to ensure queries *always* use the In-Memory column store if available, even if the optimizer might otherwise choose the row store. Use with caution and thorough testing.
• Partitioning for Large Tables: For very large PeopleSoft tables, especially those with historical data (e.g., transaction tables partitioned by date), leverage partitioning. You can mark specific active partitions INMEMORY while leaving older, less frequently accessed partitions out of the IMCS, thus optimizing memory usage.
• RAC Considerations: In an Oracle RAC environment, objects marked INMEMORY are populated independently on each instance where they are accessed. Ensure each instance has sufficient INMEMORY_SIZE. Use INMEMORY_DISTRIBUTE (BY PARTITION, BY SUBPARTITION, FOR ALL) and INMEMORY_DUPLICATE (NO DUPLICATE, DUPLICATE, DUPLICATE ALL) clauses for optimal memory distribution and redundancy across RAC nodes.
• Test Thoroughly: Always test In-Memory changes in a non-production environment that closely mirrors your production system. Measure performance improvements for key PeopleSoft reports and queries before deploying to production.
• PeopleSoft Specific Tables to Consider:
  • PS_LEDGER (and related ledger tables)
  • PS_AP_VOUCHER, PS_PAYMENT_TBL
  • PS_JOB, PS_EMPLOYEE, PS_COMPENSATION (HR/Payroll reporting)
  • PS_GL_BAL_TBL (General Ledger balance table)
  • Large custom reporting tables, materialized views used for reporting.
  • Frequently joined lookup or configuration tables if they significantly contribute to query runtimes.

FAQ

1. Does Oracle Database In-Memory replace the need for indexes?

No, Oracle Database In-Memory does not replace indexes; rather, it complements them. Indexes are highly efficient for specific access paths like single-row lookups or small range scans. The In-Memory Column Store, on the other hand, excels at full table scans, large range scans, aggregations, and complex joins across many columns. For a typical PeopleSoft environment, OLTP transactions will still heavily rely on indexes for fast row access. In-Memory primarily benefits analytical and reporting queries that would otherwise perform full table scans or access many rows. It's about having the right tool for the right job: indexes for OLTP, In-Memory for OLAP.

2. What happens if I don't allocate enough memory for INMEMORY_SIZE?

If you set INMEMORY_SIZE to a value larger than the available physical memory or the maximum SGA size allowed by your OS or database configuration (e.g., SGA_MAX_SIZE), the database instance might fail to start, or you'll receive an ORA-00845: MEMORY_TARGET not supported on this system error if using AMM. If the allocated INMEMORY_SIZE is simply too small to hold all the objects you've marked INMEMORY, Oracle will prioritize population based on the PRIORITY clause. Less critical objects might not be fully populated, or they might be evicted if more critical objects need space. The POPULATE_STATUS column in V$IM_SEGMENTS will show 'OUT OF MEMORY' for unpopulated segments. It's crucial to monitor memory usage and adjust INMEMORY_SIZE to match your requirements and available physical RAM.

3. How does Oracle Database In-Memory interact with other performance features like Exadata Smart Scan?

Oracle Database In-Memory works synergistically with other performance