SQL Practice Logo

SQLPractice Online

Oracle: PL/SQL Basics: Performance

Module: Database-Specific Features

**1. Compiled and Cached**: PL/SQL is compiled on first execution and cached. Subsequent executions use cached version (3-5x faster than ad-hoc SQL).

**2. Reduced Network Traffic**: One procedure call instead of multiple SQL statements. Example: 10 SQL statements = 10 round trips (1000ms), 1 procedure call = 1 round trip (100ms).

**3. Bulk Operations vs Cursors**: Cursors process row-by-row (10-100x slower). Use FORALL and BULK COLLECT for array processing (covered in Advanced PL/SQL).

**4. Functions in SQL**: Functions called from SQL are executed for each row. For 1M rows, function called 1M times. Use inline expressions when possible.

**5. Exception Handling Overhead**: Exception handling has minimal overhead when no exceptions occur. However, raising exceptions is expensive (use for exceptional cases, not flow control).

**6. Context Switches**: Each switch between PL/SQL and SQL engine has overhead. Minimize switches by using bulk operations and set-based SQL.

PL/SQL compiled and cached - 3-5x faster than ad-hoc SQL

Reduce network round trips - one procedure call instead of multiple SQL statements

Avoid cursors when possible - use bulk operations (FORALL, BULK COLLECT) for 10-100x better performance

Functions in SQL executed per row - for 1M rows, function called 1M times, use inline expressions when possible

Use RETURNING clause to get generated values - avoids extra SELECT query

Minimize context switches between PL/SQL and SQL - batch operations together

Exception handling has minimal overhead when no exceptions - use for exceptional cases, not flow control

SELECT INTO without exception handling - raises NO_DATA_FOUND or TOO_MANY_ROWS, always handle

Not using %TYPE for variables - type mismatches when table columns change

Using cursors for data processing - 10-100x slower than bulk operations

Functions with side effects (DML) - functions should be pure (no INSERT/UPDATE/DELETE)

Not committing or rolling back in procedures - leaves transactions open

Ignoring SQL%ROWCOUNT - check rows affected by DML to verify success

Using WHEN OTHERS without RAISE - swallows errors silently

Declaring too many variables - use only what you need