Direct object privileges remain valid regardless of role settings. The error suggests the developer’s session no longer has the privilege. The most common cause in this scenario is a change to the user’s default or enabled roles. If the INSERT privilege was granted via a role (not directly) and that role is no longer active in the session, the error occurs. A direct grant would not be affected by table recreation or schema login issues in the way described.

An IDENTITY column (introduced in Oracle 12c) is the standard, declarative way to implement auto-incrementing columns. It automatically uses an underlying sequence. The key requirement is that the number must be usable immediately (i.e., available for foreign key references or return to the application). The sequence value is generated at row insert time and is accessible via the RETURNING clause or as part of the inserted row, fulfilling the requirement. A DEFAULT clause on a sequence also works, but the IDENTITY column is the more modern, self-documenting, and maintainable method for this specific purpose.

‘enq: TX – row lock contention’ is the specific wait event for a row-level lock contention. It means this session wants to modify a row that is currently locked (e.g., by an uncommitted UPDATE or DELETE) from another session. The proper DBA action is diagnostic and communicative, not invasive. You must identify the blocking session (using views like V$LOCK and V$SESSION), then contact the owners of the blocking process or application to resolve the transaction (commit or rollback). Killing sessions or restarting the database is a disruptive last resort, not an immediate action.

A Bigfile tablespace (BFT) consists of a single, very large datafile. The key administrative benefit is that you can resize the entire tablespace by operating on just this one datafile (e.g., using ‘ALTER TABLESPACE … AUTOEXTEND …’ or ‘ALTER DATABASE DATAFILE … RESIZE’). This simplifies space management for very large data sets compared to managing dozens or hundreds of small datafiles in a traditional Smallfile tablespace. While spreading files across disks (option B) is good for performance, the question explicitly prioritizes ease of adding space (manageability).

Aggregate functions like AVG() cannot be used in the WHERE clause. The WHERE clause filters individual rows *before* grouping occurs. To filter groups based on the result of an aggregate function, you must use the HAVING clause or filter the results of a subquery. Option 1 uses a subquery to first calculate the average per department, then filters those results in the outer query’s WHERE clause (which now operates on the column alias ‘avg_sal’). The syntactically correct version using HAVING would be: `SELECT department_id, AVG(salary) FROM employees GROUP BY department_id HAVING AVG(salary) > 8000;`

A RECOVERY WINDOW retention policy instructs RMAN to keep all backups necessary to perform point-in-time recovery (PITR) to any moment within a specified period (e.g., the last 30 days). This typically requires keeping backups longer than the window itself (like the daily backups for 7 days mentioned) plus archived redo logs. The key is that the requirement is about recovery *to any point in time*, not just the number of backup copies. Redundancy 7 would keep the last 7 backups, which might not cover a 30-day recovery window if backups are taken daily.

For system privileges (granted with ADMIN OPTION), revocation does not cascade. However, for object privileges (like SELECT on a table), the revocation **does** cascade automatically. If user SCOTT was granted SELECT ON hr.employees and then granted that same privilege to another user, revoking it from SCOTT will also revoke it from the other user. Therefore, no special clause is required in the REVOKE statement for object privileges.

Flashback Query (using the `AS OF` clause or enabled by default undo retention settings in some tools) allows a query to see the data as it was at a previous point in time. If the user’s session or tool is implicitly using Flashback Query, each execution might be reading the table as of a slightly different SCN (System Change Number), leading to different results if other sessions are committing changes to rows with ‘PENDING’ status. This is a classic example of a non-repeatable read caused by querying committed data from the past. The other options do not directly cause the same data to appear differently across sequential queries in a single session.

The High Water Mark (HWM) is the boundary between used and unused space in a segment. After a large DELETE operation, the rows are removed but the space they occupied is not automatically released back to the tablespace; the HWM remains where it was. DBA_SEGMENTS shows the total allocated space up to the HWM. Therefore, the table can appear to use a large amount of space (50GB) even though it contains very few rows. This space can be reclaimed by operations like `ALTER TABLE … MOVE` or `ALTER TABLE … SHRINK SPACE` (if row movement is enabled).

Direct object privileges remain valid regardless of role settings. The error suggests the developer’s session no longer has the privilege. The most common cause in this scenario is a change to the user’s default or enabled roles. If the INSERT privilege was granted via a role (not directly) and that role is no longer active in the session, the error occurs. A direct grant would not be affected by table recreation or schema login issues in the way described.0