Hibernate ORM and Oracle Database Administration

LISTENER.ORA is the server-side configuration file that contains network parameters for the Oracle Net Listener, including the listener address, port, service names, and protocol settings. INIT.ORA contains database initialization parameters, SQLNET.ORA is for client-side SQL*Net configuration, and TNSNAMES.ORA is a client-side file for database service name resolution. The listener.ora file is specifically responsible for defining how the listener accepts network connections.

TNSPING is faster than standard PING because TNSPING only checks if the listener is reachable and can respond to TNS (Transparent Network Substrate) requests - it doesn't connect to the database instance or verify database availability. Standard PING operates at the TCP/IP network layer and checks basic network connectivity, while TNSPING operates at the Oracle application layer and is specifically optimized for Oracle Net Services. The TNSPING check is lighter weight as it bypasses instance connection and verification.

When the Oracle listener is shut down, existing database connections remain unaffected because the listener's role is ONLY to initiate new connections - it doesn't maintain or manage existing connections. Once a connection is established, communication occurs directly between the client and the database instance. The connections won't close immediately, won't close when transactions complete, and will continue operating normally. Only new connection attempts will fail until the listener is restarted.

To use SQLPLUS to connect to a remote Oracle database, you need a TNS (Transparent Network Substrate) entry on the CLIENT side (where SQLPLUS executable resides), not the server side. The TNS entry in tnsnames.ora on the client machine tells SQLPLUS how to reach the remote database - the host, port, service name, and protocol. Without this client-side TNS entry, SQLPLUS doesn't know where to connect. The server's TNS configuration is irrelevant for the client connection attempt.

When SQLPLUS and the database reside on the same server, you don't need a TNS entry. You can connect using the BEQ protocol (bequeath/local connection) with syntax like 'sqlplus / as sysdba' or 'sqlplus username/password'. The BEQ protocol uses inter-process communication directly without going through the network listener or TNS. TNS entries are only required for remote connections across the network. Local connections bypass the TNS layer entirely.

The statement is false. Enterprise users in Oracle DO require database accounts and schema creation in each database they need to access. Enterprise User Security (EUS) provides centralized user management across databases, but each database must still have a schema/user account mapped to the enterprise user. The enterprise user is authenticated centrally (often through LDAP/directory), but authorization (schema access, privileges) requires database-level schema objects. There's no magic way to bypass the need for database accounts entirely.

The statement is false. Even if a user is IDENTIFIED EXTERNALLY (OS authentication), they cannot connect with 'sqlplus -S / as SYSDBA' without being explicitly granted SYSDBA privileges. The '/' syntax allows OS-authenticated users to connect, but only if they have a corresponding database account with appropriate privileges. A user identified externally still needs proper SYSDBA grant to use 'as SYSDBA'. Without this grant, the connection attempt will fail regardless of OS authentication.

In Oracle security model, the statement is false. User authentication is WHO you are (verifying identity via passwords, certificates, OS auth), while Schema authorization is WHAT you can do (privileges, roles, permissions to access objects). The original statement reverses these - it claims User is authentication (correct) but Schema is authorization (incorrect - schemas are containers for database objects, not authorization mechanisms). Authorization is managed through grants, roles, and privileges, not schemas themselves.

The ORAPWD utility is an Oracle-supplied command-line tool used to create and manage the database password file, which is required for authenticating administrative users (like SYSDBA) over a network.

The REMOTE_LOGIN_PASSWORDFILE parameter in Oracle can have three values: NONE (no password file, OS authentication only), EXCLUSIVE (password file used by one database instance for privileged users), and SHARED (password file shared by multiple databases). 'All the Above' is correct because all three values are valid settings. NONE disables password file authentication, EXCLUSIVE is the default and recommended setting for single databases, and SHARED allows multiple databases to share the same password file (less secure, used in specific RAC or consolidated scenarios).

In Oracle database authentication, OS Authentication typically takes precedence over Password File Authentication. When a user is authenticated at the OS level and connects to the database, Oracle recognizes and trusts that OS authentication first. Password file authentication is primarily used for remote DBA authentication when SYSDBA privileges are needed remotely.

In Oracle databases, the dynamic performance view V$parameter displays information about the initialization parameters that are currently in effect for the instance. V$database and V$instance show database and instance metadata instead.

USER_SYS_PRIVS shows the system privileges granted specifically to the current user. ALL_SYS_PRIVS would show all system privileges in the database (not filtered for the user). The ROLE_PRIVS views are for role privileges, not system privileges. For user U01 checking their own system privileges, USER_SYS_PRIVS is correct.

The hibernate.cfg.xml configuration file's primary purpose is to set up the Hibernate environment - database connection parameters (driver class, URL, credentials), dialect, connection pool settings, and other runtime configurations. Option B refers to Spring bean management, Option C is incorrect (you need this file), and Option D describes mapping, not configuration.

The SessionFactory is responsible for creating Session instances. It reads the configuration from hibernate.cfg.xml during initialization and provides a thread-safe factory for creating Sessions. The Session itself is created by SessionFactory, not the other way around. ApplicationContext is a Spring concept.

The correct Hibernate API to create a SessionFactory is: new Configuration().configure().buildSessionFactory(). The configure() method reads hibernate.cfg.xml, and buildSessionFactory() constructs the SessionFactory. Option A is incomplete (no buildSessionFactory), Option C has a wrong method name, and Option D is incorrect.

In Hibernate XML mapping files (.hbm.xml), the root element is . All class, property, and other mapping definitions are nested within this element. The other options are not valid Hibernate mapping elements.

Hibernate provides built-in ID generation strategies called generators. Commonly used generators include increment (generates identifiers incrementally), identity (uses database identity column), sequence (uses database sequence), hilo (high/low algorithm), and uuid (generates UUIDs). The other options contain either incorrect names or mix of unrelated terms.

In Hibernate, the Configuration class (org.hibernate.cfg.Configuration) represents the complete set of object-relational mappings between Java types and SQL database tables. It is responsible for reading configuration files (hibernate.cfg.xml or hibernate.properties) and mapping files, creating the SessionFactory. The other options either use incorrect package names or incorrectly add '.Session' suffix.