Architecture and Configuration
The Architecture and Configuration domain checks that you can describe an Oracle 19c instance and database, read V$ views and the alert log, and change configuration without breaking startup. Questions combine memory sizing, background processes and parameter scope.
Instance versus database
The instance is memory plus background processes: the SGA (buffer cache, shared pool, large pool, java pool, redo log buffer, fixed SGA) and processes such as PMON, SMON, DBWn, LGWR and CKPT, plus ARCn, MMON/MMNL and RECO when needed. The database is the physical set of datafiles, control file and online redo logs; tempfiles and the password file support it but are not part of the database proper. PGA is private per server process and never part of the SGA.
Startup stages
STARTUP NOMOUNT reads the SPFILE (or PFILE) and starts the instance; MOUNT reads the control file; OPEN opens datafiles and redo logs. Recovery and many restore operations happen at MOUNT.
Parameters
ALTER SYSTEM with SCOPE=MEMORY changes the running instance only; SCOPE=SPFILE persists and needs a restart; BOTH is the default for dynamic parameters. Static parameters accept only SPFILE scope. MEMORY_TARGET enables Automatic Memory Management; SGA_TARGET alone gives Automatic Shared Memory Management. V$PARAMETER shows current values, V$SPPARAMETER the stored ones.
Worked example
With MEMORY_TARGET=2G, ALTER SYSTEM SET sga_target=3G fails with ORA-00838: the SGA target cannot exceed the memory target. The fix is to raise MEMORY_TARGET first (checking /dev/shm on Linux, otherwise ORA-00845) or to clear MEMORY_TARGET and size SGA_TARGET and PGA_AGGREGATE_TARGET manually, then restart.
Traps
SCOPE=MEMORY changes silently lost at restart; editing a PFILE while an SPFILE exists; assuming V$PARAMETER shows the SPFILE; forgetting that ALTER SYSTEM DEFERRED affects only new sessions; setting a static parameter with scope memory and expecting it to take effect.