Backups, database-side Java, and integrated replication need working memory for different jobs. Oracle provides specialty pools inside the system global area (SGA). These pools are shared RAM. The features and the configuration determine which consumers use them.
Oracle DBA Lesson 10 Part 1 — Memory for Specialized Workloads
Large pool: working memory for suitable large allocations
An RMAN backup reads source data, processes it through buffers, and writes the backup. A buffer is temporary working memory that holds data during that processing. In a configuration that uses RMAN I/O slaves with a suitable large-pool allocation, these shared buffers can come from the large pool. The source data files and the disk backup files are physical files. The buffers are RAM. See tuning RMAN performance.
Follow one piece of backup data. A copy is read from a data file into a working buffer, processed, then written into a backup file. The source file remains in place. Buffer allocation depends on the configured I/O method. Inspect that method before you attribute backup memory to this pool. For the disk I/O slave case, the documented DBWR_IO_SLAVES and LARGE_POOL_SIZE settings and their fallback behavior matter. See LARGE_POOL_SIZE.
Other configured consumers include shared-server session memory and certain parallel-execution message buffers. Shared-server session state can be held in the SGA so different server processes can continue that session. Shared-server deployment and routing are separate topics. See memory architecture.
Java pool: database-side Java
Oracle's database Java engine executes stored Java methods. The Java pool supports the code and data required for that database-side work. Allocation details depend on the server mode. A Java application running on another host has its own host memory. Relate this pool's demand to Java that is actually running inside the database.
Streams pool: consumers that prepare and exchange changes
For the GoldenGate 19.1 integrated-capture example, a database logmining server accesses redo and prepares logical change records. Its shared working memory comes from the Streams pool, and GoldenGate Extract receives the records for replication. The pool is RAM. Redo log files are physical storage, and Extract is a consuming process. See preparing the database for Oracle GoldenGate and STREAMS_POOL_SIZE.
Oracle Streams replication was desupported in Oracle Database 19c. The Streams pool continues to exist and supports other facilities. Match the pool to the actual configured consumer and release. This example concerns the documented integrated mode. Later GoldenGate capture variants have different memory behavior. See desupport of Oracle Streams and choosing capture and apply modes.
Read a pool inventory
In SQL*Plus:
SELECT pool, ROUND(SUM(bytes)/1024/1024,1) AS mb
FROM v$sgastat
WHERE pool IN ('large pool','java pool','streams pool')
GROUP BY pool
ORDER BY pool;V$SGASTAT contains SGA memory entries. Grouping by POOL and adding BYTES gives tracked totals for the represented pools, including entries named free memory. Dividing by 1024 twice converts bytes to mebibytes (MiB). MB is the query's column alias. See V$SGASTAT.
| Pool | MB (MiB) |
|---|---|
| java pool | 64.0 |
| large pool | 128.0 |
| streams pool | 32.0 |
An example 128 MiB allocation containing 32 MiB in use and 96 MiB free still totals 128 MiB. To examine the contributing entries:
SELECT pool, name, bytes
FROM v$sgastat
WHERE pool = 'large pool'
ORDER BY name;Interpret names, units, and workload together. If a pool has no row, investigate its configuration and its current allocation. A pool total by itself does not identify every consumer, and it does not establish that a feature is enabled.
With automatic SGA management (SGA_TARGET in effect), supported component-size settings can specify a minimum while the current allocation grows above that minimum. Read the relevant parameter and the current inventory together:
SHOW PARAMETER sga_target
SHOW PARAMETER large_pool_sizeSHOW PARAMETER is a SQL*Plus command. This inspection supports a memory inventory. See SGA_TARGET.
Recap
Specialty pools in the SGA are shared RAM. In the configured RMAN I/O-slave case, working buffers can come from the large pool, while the source and backup files stay on disk. The large pool can also hold shared-server session memory and certain parallel-execution message buffers. The Java pool supports Java executed inside the database, not every Java application on every host. For GoldenGate 19.1 integrated capture, the logmining server's shared memory comes from the Streams pool. Oracle Streams replication was desupported in 19c, and the pool still supports other facilities. A V$SGASTAT total includes free memory, so 32 MiB in use and 96 MiB free report 128 MiB. With SGA_TARGET, the current allocation can grow above a configured minimum.
No comments:
Post a Comment