Networking

A .False. “Logging out to the abc database” is nonsensical; abc is a script, not a database. B .False. SQL*Plus finds abc.sql in the current directory by default; a full path isn’t required unless it’s elsewhere. C .False. The first @ specifies the TNS alias (orcl), the second runs the script (@abc); this is valid syntax. D & E.True (identical options). The command connects to orcl via TNSNAMES.ORA, authenticates HR, and executes abc.sql. Mechanics:sqlplus hr/hr@orcl resolves orcl to a listener address, connects, and@abc runs the scrip t post-login.

A .False. LREG handles registration in 23ai, not PMON. B .False. CKPT (Checkpoint) process updates the control file. C .True. PMON cleans up after failed processes (e.g., releases locks). D .True. PMON rolls back uncommitted transactions of failed processes. E .False. SMON (System Monitor) manages temporary segment cleanup.

A .False. lsnrctl can start a default listener without listener.ora. B .True. EMCC provides centralized Net Services configuration. C .False. NetCA can run standalone, not just during installation. D .True. Net Manager configures local naming (e.g., TNSNAMES.ORA). E .False. Net Manager is local, not centralized like EMCC.

A .False. Dispatchers are for shared servers, not dedicated. B .False. Dedicated processes die with the session. C .True. Direct client-server communication occurs. D .False. No dispatchers in dedicated mode. E .True. Listener spawns for local/remote clients. F .True. Local logins (e.g., sqlplus/) bypass the listener.

A .False. Links can connect to non-Oracle DBs via gateways. B .False. No such user requirement; authentication is separate. C .False. Any user with CREATE PUBLIC DATABASE LINK ca n create one. D .True. Links enable remote schema access (e.g., SELECT * FROM emp@remote). E .False. Public links allow access, but privileges on remote objects are needed.

Database links enable cross-database queries in Oracle. Let’s analyze each option with extensive detail: A . A public database link can be created only by SYS. False. Any user with the CREATE PUBLIC DATABASE LINK privilege (n ot just SYS) can create a public link (e.g., CREATE PUBLIC DATABASE LINK remote_db CONNECT TO scott IDENTIFIED BY tiger USING 'orcl'). While SYS typically has this privilege, it’s not exclusive to SYS. Mechanics:Privilege is granted via GRANT CREATE PUBLIC DATABASE LINK TO user;. Public links are accessible to all users in the local DB. Why Incorrect:Overly restrictive; Oracle’s security model allows delegation. B . A database link can be created only between two Oracle databases. False. Database links can connect to non-Oracle databases using Oracle Heterogeneous Services o r gateways (e.g., ODBC or JDBC drivers), such as linking to SQL Serv er. Example: CREATE DATABASE LINK mssql_link USING 'hsodbc';. Mechanics:Requires configuration of hs_ parameters in init.ora and a gateway listener. Historical Note:Heterogeneous links were introduced in 8i, expanded in 23ai for cloud integration. C . A database link created in a database allows a c onnection from that database's instance to the target database's instance, but not vice versa. True. A database link is unidirectional; it enables queries fro m the local instance to the remote instance (e.g., SELECT * FROM emp@remote_db), but the remote instance can’t use it to query back unless a separate link is created there. Mechanics:Stored in DBA_DB_LINKS, the link defines a one-way connection via a TNS alias or connect string. Practical Use:Ensures controlled access; bidirectional ac cess requires explicit configuration. Edge Case:Loops are prevented unless explicitly designed with mu tual links. D . A public database link can be used by a user connected to the local database instance to connect to any schema in the remote database instance. False. Public links allow all local users to use them, but access to remote schemas depends on the link’s credentials (e.g., CONNECT TO scott) and the user’s remo te privileges. “Any schema” overstates it; access is limited to what the link’s user can see. Why Incorrect:Misrepresents privilege scope; remote schema access isn’t universal. E . Private database link creation requires the same u ser to exist in both the local and the remote databases. False. A private link (e.g., CREATE DATABASE LINK my_linkCON NECT TO scott IDENTIFIED BY tiger USING 'orcl') requires the remote user (scott) to exist, but the local creator (e.g., HR) need not matc h. The link is owned locally and authenticated remotely. Mechanics:Only the CREATE DATABASE LINK privilege is needed locally.

A .False. Net Manager is local, not centralized. B .False. NetCA can run standalone. C .True. EMCC manages service names centrally. D .True. EMCC configures listeners on managed targets. E .False. lsnrctl starts a default listener if no listener.ora exists. F .True. Net Manager configures local tnsnames.ora.

A .True. Dispatchers return responses to clients. B .False. Dispatchers manage queues, not write directly. C .False. Responses are connection-specific, not broadcast. D .True. Dispatchers receive client requests. E .False. Queues are common, not per-connection. F.True. Dispatchers monitor the response queue.

A .False. ORCL is a TNS alias, not necessarily the DB name. B .True. Must map to a connect descriptor (e.g., HOST=... PORT=1531) in tnsnames.ora. C .False. It’s not the server name but a network alias. D .False. Client-side tnsnames.ora is used, not server-side. E .False. SERVICE_NAMES is server-side, not client-side.

A .False. Connect Time Failover doesn’t need TAF; TAF is for runtime failover. B .False. Source Routing doesn’t mandate encryption. C .True. Needs multiple addresses (e.g., (ADDRESS_LIST=...)) for failover. D .False. Load balancing works with tnsnames.ora, no name server required. E .True. Balances connections across shared server dispatchers.