Database and SQL

Oracle databases have a limit of 1000 columns per table or view. This is a hard limit in the Oracle database architecture. Option A (900) is too low, while options C (1100) and D (1050) exceed the actual limit.

The correct SQL cursor attributes in PL/SQL are: SQL%ROWCOUNT (number of rows affected), SQL%FOUND (boolean, true if at least one row affected), SQL%NOTFOUND (boolean, true if no rows affected), and SQL%ISOPEN (boolean, always false for implicit cursors). Option B incorrectly uses SQL%OPEN, and Option A incorrectly uses SQL%ISFOUND.

Decision tables require explicit condition values for each row to ensure deterministic rule evaluation. Empty cells in condition columns would create ambiguity about which rule should fire, so they are not allowed in properly formed decision tables.

Decision tables allow individual condition cells to be disabled for specific rows, meaning those conditions will not be evaluated for those particular rule rows. This provides flexibility in rule logic by allowing certain conditions to be skipped without removing the entire condition column.

In PL/SQL, %TYPE is used to declare a variable with the data type of a previously declared variable or database column. In contrast, %ROWTYPE is used to declare a record representing an entire row in a table or view.

Standard SQL itself does not have built-in structured exception handling (try/catch blocks). That functionality exists only in procedural SQL extensions like PL/SQL (Oracle) or T-SQL (SQL Server), not in core SQL.

In a PL/SQL block, only the DECLARE and EXCEPTION sections are optional. Every PL/SQL block must have BEGIN and END keywords to define the executable section. The DECLARE section (for declarations) and EXCEPTION section (for error handlers) can be omitted if not needed.

Database triggers are designed for centralized operations and ensuring related actions occur. They should not duplicate built-in constraints or other triggers. Option C describes enforcing related actions (e.g., audit logging on update). Option D describes global operations firing regardless of user.

SQL execution follows these phases: Parse (syntax/semantic validation), Bind (variable binding), Execute (query execution), and Fetch (returning results to client). 'Retrieve' is not typically listed as a separate step in standard SQL execution phases.

In OLTP (Online Transaction Processing) applications, individual SQL statements should execute very quickly - typically less than 10 milliseconds - to maintain high transaction throughput and responsiveness. Values of 50ms, 100ms, or 150ms would be considered too slow for OLTP workloads.

Using hints in SQL statements is generally not advisable because they hard-code optimization assumptions that may become outdated as data distribution changes. Hints should only be used as a last resort when the optimizer consistently makes poor choices and other tuning methods have been exhausted.

Explain Plan and Trace are the correct first steps for SQL tuning. Explain Plan shows the execution plan and access paths. Trace provides detailed execution statistics. Parse and Bind are execution phases, not tuning tools - they describe how SQL is processed, not how to analyze or improve it.

Bind variables (parameters) should always be used in SQL statements instead of concatenating values. This prevents SQL injection attacks, improves query performance through cursor sharing, and enhances security by separating code from data.

To join N tables in SQL without causing a Cartesian product, you need a minimum of N-1 join conditions. For 3 tables, N-1 equals 2 join conditions. Fewer conditions result in an unwanted cross join, while more conditions are unnecessary for a basic join structure.