Oracle 1Z0-078 key terms

Shared memory region allocated at instance startup that holds the buffer cache, shared pool, redo log buffer, and other structures used by all server processes connected to the instance.

Private memory area allocated for each server process, holding session-specific data such as sort areas, hash join work areas, and cursor state. Its size is governed by PGA_AGGREGATE_TARGET or PGA_AGGREGATE_LIMIT.

Portion of the SGA that caches data blocks read from disk. Buffer states include free, pinned, clean, and dirty; dirty buffers are written by DBWn to make room or at checkpoints.

SGA region holding the library cache of parsed SQL and PL/SQL, the row cache of dictionary data, and control structures. Its size is influenced by SHARED_POOL_SIZE and the automatic shared memory advisor.

Component of the shared pool that stores parsed SQL statements, PL/SQL code, and execution plans. Reuse requires identical text, so literal SQL causes hard parsing and contention on library cache latches.

Background process that writes dirty buffers from the buffer cache to data files. Multiple writers (DBW0 through DBW9 and DBWa through DBWj) can be configured to spread write workload.

Background process that writes redo records from the redo log buffer to the online redo log files. It writes on commit, when the buffer is one-third full, or when a write threshold is reached.

Background process that updates data file headers and the control file with checkpoint position information, signaling that all blocks up to a system change number are consistent on disk.

Monotonically increasing logical timestamp used internally to order changes and define consistency points. Recovery and flashback operations rely on SCN ranges to determine which changes to apply or undo.

File in a redo log group that records all changes made to the database. Groups are written in a circular fashion; a group cannot be reused until its changes are archived in ARCHIVELOG mode.

Copy of a filled online redo log file preserved by the archiver process (ARCn). Archived logs are essential for media recovery and for recovering from a lost or damaged data file.

Database mode in which filled online redo log files are archived before reuse. It enables media recovery, online backups, and Data Guard standby databases; NOARCHIVELOG mode risks data loss.

Oracle's native backup and recovery utility that manages backup sets, image copies, and archived logs, tracks them in a recovery catalog or control file, and performs block-level corruption checks.

RMAN output format containing one or more data files, archived logs, or control files in a proprietary compressed format. Only RMAN can restore from backup sets; individual files cannot be copied out directly.

Byte-for-byte copy of a data file, archived log, or control file produced by RMAN. Unlike a backup set, it is usable by external tools and can be rolled forward during incremental updates.

RMAN backup that captures only blocks changed since a prior backup. Level 0 backs up all blocks, while level 1 backs up changes since the last level 0 or level 1 backup.

Feature that maintains a bitmap file recording which data file blocks have changed since the last backup, allowing RMAN to read only changed blocks and speeding up incremental backups.

Optional schema of backup metadata stored in a separate database. It retains history longer than the control file and enables restore scripts and reporting across multiple target databases.

Small binary file recording the database name, data file and redo log locations, checkpoint positions, and RMAN metadata when no catalog is used. It must be multiplexed because it is critical for startup.

Disk location defined by DB_RECOVERY_FILE_DEST where Oracle manages archived logs, RMAN backups, control file autobackups, and flashback logs. DB_RECOVERY_FILE_DEST_SIZE enforces a hard space quota.

Technology that returns the entire database to an earlier point in time by applying flashback logs, without restoring files. Requires ARCHIVELOG mode and a fast recovery area.

Feature that reads data as it existed at an earlier SCN or timestamp using undo data, letting you view past rows or recover from logical errors without a full restore.

Built-in repository of performance statistics captured at regular snapshots. AWR reports compare snapshots to show top wait events, SQL, and segment activity; it requires the Diagnostics and Tuning Pack license.

In-memory and persisted sampling of active session state each second, showing which sessions wait on what. ASH data enables drill-down into transient problems that snapshots alone would miss.

Self-diagnostic engine that analyzes AWR snapshots to identify root causes of performance problems and estimate the benefit of fixing each, ranked by impact on database time.

A condition for which a session is not consuming CPU, such as db file sequential read or log file sync. Wait time and count identify where sessions lose time during an interval.

Total time spent by all sessions in the database, including CPU time and wait time. It is the denominator used by ADDM and AWR to express the impact of a finding as a percentage.

Full parse of a SQL statement requiring syntax and semantic checks, optimization, and creation of an execution plan. Excessive hard parsing stresses the shared pool and consumes CPU.

Placeholder in SQL whose value is supplied at execution time, allowing one parsed statement to be reused for many values. This reduces hard parsing and library cache contention.

Component that chooses an execution plan by estimating costs from table, index, and column statistics. Accurate optimizer statistics are essential; stale statistics often cause poor plans.

Metadata describing data distribution, including table row counts, index clustering factor, column histograms, and null counts. They are gathered by DBMS_STATS and drive costing decisions.

Ordered set of operations, such as table access, join, and sort steps, that the optimizer chooses to execute a statement. It is displayed with DBMS_XPLAN or EXPLAIN PLAN.

Logical storage container made of one or more data files. Objects are created in tablespaces, which can be dictionary-managed or locally managed with automatic segment space management.

Tablespace whose free and used extents are tracked in a bitmap inside the tablespace itself rather than in the data dictionary, avoiding recursive space management and reducing contention.

Contiguous set of data blocks allocated as one unit within a segment. Extent size is controlled by the tablespace's uniform or autoallocate policy and affects space waste.

Database object that consumes storage, such as a table, index, or undo segment, and is made of extents. Segment space is managed by automatic segment space management in modern tablespaces.

Tablespace holding undo records used to roll back transactions, provide read consistency, and support flashback features. UNDO_MANAGEMENT=AUTO and UNDO_RETENTION govern its behavior.

Guarantee that a query sees data as of a single point in time, using undo to reconstruct older block versions. It prevents dirty reads and non-repeatable reads within a statement.

Multitenant architecture database that contains a root container, a seed, and one or more pluggable databases. It shares one instance and one set of background processes across all containers.

Self-contained set of data files and metadata that appears as a separate database to applications while sharing the CDB instance. PDBs can be unplugged, cloned, and relocated.

The CDB$ROOT container that holds common metadata, common users, and Oracle-supplied objects. Administrative tasks performed here can affect all pluggable databases in the container database.

Database user defined in the root container whose identity is shared across all containers. It can connect to any PDB to which it has been granted privileges, unlike a local user.

Server-side utility (expdp and impdp) that moves data and metadata through dump files and a master process. It supports remapping, filtering, parallelism, and network-mode transfers.

Method of moving a set of tablespaces between databases by copying data files and exporting only metadata. It is much faster than row-by-row movement for large data volumes.

Database object mapping a logical name to an operating system path. Data Pump and external tables use it because the server, not the client, reads and writes the files.

Disaster recovery solution that maintains a synchronized standby database by shipping and applying redo. It supports physical and logical standbys and role transitions such as switchover and failover.

Record of database activity stored in the database (DBMS_AUDIT_MGMT tables) or in operating system files. Unified auditing consolidates these sources into a single view.

Auditing framework that captures all audit records, including SYS activity, into a unified trail. Policies are created with CREATE AUDIT POLICY and enabled per user or globally.

Policy-based auditing that records access to specific columns or rows when a condition is met. It captures the SQL text and the user responsible, unlike coarse statement-level auditing.

Named set of password and resource limits assigned to users, such as password verification function, failed login attempts, and session idle time. Profiles enforce security policy at login.