Database Administration

A .Incorrect syntax and view (pdb_spfile$ is not a valid view; PDB_SPFILE$ exists but lacks value$). B .From CDB root, V$PARAMETER shows all parameters, not PDB-specific ones. C .pdb_spfiles is not a valid view; PDB_SPFILE$ exists but requires scoping to a PDB. D .True. From the PDB, V$PARAMETER shows parameters specifi c to that PDB, including inherited and PDB-modified values, with ISPDB_MODIFIABLE indicatin g alterability.

B .True. Without SCOPE, ALTER SYSTEM defaults to BOTH (memory and SPFILE); PFILE isn’t updated unless manually recreated.

Dynamic service registration allows a database to automatically register its services with a listener without manual configuration in LISTENER.ORA. Let’s analyze each option: A . The definition for LISTENER_1 requires a CONNECT_DATA section to enable dynamic service registration. False. The CONNECT_DATA section is part of a client-side TN SNAMES.ORA entry for connecting to a service, not for listener registration. Dynamic registrati on is handled by the database’s LREG (Listener Registration) process, which uses the LOCAL_LISTENER paramet er to locate the listener’s address (e.g., host1.abc.com:1521). No CONNECT_DATA is needed in the listener address definition itself. This option confuses client connection syntax with listener conf iguration. Mechanics:The listener address in TNSNAMES.ORA (LISTENER_1) is sufficient for LREG to find and register with it, as long as the listener is running at that address. B . LISTENER_1 must also be defined in the LISTENER.ORA file to enable dynamic service registration. False. Dynamic registration doesn’t require the listener to be explicitly defined in LISTENER.ORA. The LOCAL_LISTENER parameter pointing to LISTENER_1 (resolved via TNSNAMES.ORA) tells LREG where to register services. If the listener is running on host1.abc.com: 1521, LREG will find it without a LISTENER.ORA entry. However, LISTENER.ORA is needed tostartthe listener process, but that’s separate from dynamic registration. Practical Note:If LISTENER.ORA isn’t configured, a default listener might run on port 1521, but the question implies LISTENER_1 is operational. C . The LREG process registers services dynamically with the LISTENER_1 listener. True. In Oracle 23ai, the LREG background process (replacing P MON’s registration role in earlier versions) dynamically registers database services with listene rs specified by LOCAL_LISTENER. Here, LOCAL_LISTENER=LISTENER_1 resolves to host1.abc.com:1521 via TNSN AMES.ORA. LREG periodically sends service information (e.g., service na mes, instance details) to the listener, enabling clients to connect without static configuration. Mechanics:LREG uses the TNS alias (LISTENER_1) to locate the listener’s IP and port, registers services like orcl or orclpdb, and updates the listener’s service table. This happens automatically every 60 seconds or on significant events (e.g., instance startup). D . Dynamic service registration cannot be used for this database instance. False. The setup (LOCAL_LISTENER set and a valid TNSNAMES.ORA entry) explicitly supports dynamic registration. No blockers (e.g., REGISTRATION_EXCLUDED_LISTENE RS) are mentioned, so LREG can function normally. E . There are two listeners named LISTENER and LISTENER_1 running simultaneously using port 1521 on the same host as the database in LISTENERS. False. The question mentions only LISTENER_1 in the SPFILE and TNSNAMES.ORA. There’s no evidence of a second listener (LISTENER) or a LISTENERS configuration (possibly a typo). Two listen ers can’t share the same port (1521) on the same host due to port confl icts unless explicitly configured with different IPs, which isn’t indicated here.

A .False. Recovery happens on startup, not shutdown. B .False. TRANSACTIONAL waits for commits or rollbacks, then disconnects. C .True. New connections are blocked during shutdown. D .True. Inactive sessions persist until shutdown completes. E .True. Active transactions can commit before disconnection.

A .False. No checkpoint occurs with ABORT. B .False. Instance recovery, not media recovery, is needed. C .True. Crash recovery rolls back uncommitted changes on startup. D .False. Files aren’t closed cleanly with ABORT. E .True. Shutdown doesn’t roll back; recovery does.

A .False. One instance can’t mount multiple DBs without multitenant. B .True. RAC allows multiple instances to share one DB. C .False. Same as A; not possible without CDB. D .True. An instance can start in NOMOUNT with no DB. E .True. Standard single-instance configuration.

A .False. STOP_JOB=IMMEDIATE halts the job, not backgrounds it. B .False. You can monitor before stopping or after restarting. C .True. Before stopping, you can reattach with expdp attach=exp_db_full. D .True. STOP_JOB=IMMEDIATE terminates the job instantly.

A .True. Background processes (e.g., PMON) start. B .False. Consistency checks require MOUNT. C .False. Control files open in MOUNT. D .True. SGA is allocated at startup. E .False. SYS access requires OPEN.

A .False. Session limits don’t tie to password changes. B .False. CPU limits don’t lock accounts. C .False. No direct “logged - in days” parameter. D .True. PASSWORD_REUSE_MAX=UNLIMITED prevents reuse. E .True. PASSWORD_LOCK_TIME sets inactivity lockout .

A .True. CREATE SPFILE FROM PFILE works when idle. B .False. Includes dynamic parameters too. C .True. CREATE PFILE FROM SPFILE generates a PFILE. D .False. A PFILE can start the instance if no SPFILE exists. E .True. Dynamic parameters (e.g., DB_CACHE_SIZE) are modifiable.

A .False. EXCLUDE=index skips all indexes, not re -creates them. B .False. TABLE_EXISTS_ACTION=replace drops and re -creates tables. C .True. EXCLUDE=index omits all indexes from import. D .True. replace drops and re -creates existing tables. E .False. Skips all indexes, not just overlapping ones.

A .False. External tables are read-only; no DELETE. B .False. Require OPEN state, unlike V$ views. C .False. No UPDATE support; read-only. D .True. Queryable like regular tables without loading. E .True. Data Pump can unload query results to files.