ORA-04068: Midday Hotfix Broke 30% of Checkouts

ORA-04068 looks like a random glitch: some sessions fail, others don't, and a retry works. It isn't random. It fires exactly once in every session that had already used a package before someone recompiled it. ORA-04063 is its louder sibling: the package didn't compile, so every caller fails until it does. This guide explains what package state is, why a deploy discards it, how to tell the two errors apart from the error stack, and the deployment patterns that keep both out of your incident channel.

Why Oracle Discards Package State (And Why It's Not a Bug)

A PL/SQL package can hold session state: variables, constants and cursors declared at package level, in the spec or the body. Each session gets its own private copy the first time it touches the package, and that copy lives until the session ends. When the package is recompiled, Oracle can't map the old state onto the new code, so it throws the state away. The next call from any session that already held state raises ORA-04068, and the stack usually adds ORA-04061, ORA-04065 or ORA-06508 underneath. Two details matter in production. First, it fires exactly once per affected session: the next call re-initialises the package and works. Second, it does not roll back your transaction. Only the failing call errors out; earlier uncommitted DML is still pending until your code commits or rolls back. Sessions that never touched the package, and packages with no package-level state at all, are unaffected. That's why it looks random.

-- io.thecodeforge — Database tutorial
-- A package with session state: g_calls lives in each session's memory
CREATE OR REPLACE PACKAGE order_pkg AS
  PROCEDURE place_order(p_amount NUMBER);
END order_pkg;
/
CREATE OR REPLACE PACKAGE BODY order_pkg AS
  g_calls PLS_INTEGER := 0;   -- package-level variable = session state
  PROCEDURE place_order(p_amount NUMBER) IS
  BEGIN
    g_calls := g_calls + 1;
    DBMS_OUTPUT.PUT_LINE('Order ' || p_amount || ' (call ' || g_calls || ')');
  END;
END order_pkg;
/

-- Session 1
EXEC order_pkg.place_order(100);

-- Session 2 recompiles the body (a deploy):
--   ALTER PACKAGE order_pkg COMPILE BODY;

-- Session 1 again: first call fails, second works
EXEC order_pkg.place_order(200);
EXEC order_pkg.place_order(200);

ORA-04063: When Your Package Won't Even Compile

ORA-04063 means the object you called is INVALID: it has compilation errors, so Oracle refuses to run it. It names the object but not the line. It usually appears after a deployment in which something the package depends on changed: a column was renamed or dropped, a referenced package's spec changed, or a grant was revoked. Oracle marks the dependent package INVALID and tries to recompile it on the next call. If that compile fails, every caller gets ORA-04063. Unlike ORA-04068, retrying never helps. The fix is always: read the compile errors, fix the cause, recompile. Remember that the cause is often not in the package's own code, but in an object it depends on.

-- io.thecodeforge — Database tutorial
-- The ORDERS table no longer has an AMOUNT column (renamed to TOTAL)
CREATE OR REPLACE PACKAGE BODY order_pkg AS
  PROCEDURE place_order(p_amount NUMBER) IS
  BEGIN
    INSERT INTO orders (order_id, amount) VALUES (order_seq.NEXTVAL, p_amount);
  END;
END order_pkg;
/

-- Every caller now fails
EXEC order_pkg.place_order(100);

-- Read the real error
SHOW ERRORS PACKAGE BODY order_pkg

-- Fix the code (amount -> total), then recompile
ALTER PACKAGE order_pkg COMPILE BODY;

The Deployment Pattern Behind Most ORA-04068

Almost every ORA-04068 incident has the same shape: a stateful package is recompiled while a connection pool is holding long-lived sessions that have already used it. Each of those sessions fails exactly once, spread over the next few minutes as the pool hands them out. Note that a recompile doesn't only come from your own deploy. Changing anything the package depends on, such as a table, a view or another package's spec, invalidates it, and Oracle recompiles it automatically on the next call. There are three reliable fixes. You can deploy in a window and recycle the pool, so no session carries old state. You can remove package-level state from hot packages, so there's nothing to discard. Or you can use Edition-Based Redefinition (EBR), where new code goes into a new edition: sessions already connected keep using the old edition, and new sessions pick up the new one. EBR is available in every Oracle edition, but it needs schema preparation: editions enabled for the owner, and editioning views over the tables.

-- io.thecodeforge — Database tutorial
-- One-time setup (as a DBA): allow the app owner to have editioned objects
ALTER USER app ENABLE EDITIONS;

-- Each release: create a new edition and compile the new code there
CREATE EDITION rel_42 AS CHILD OF ora$base;
ALTER SESSION SET EDITION = rel_42;

CREATE OR REPLACE PACKAGE BODY app.order_pkg AS
  -- new version
  ...
END order_pkg;
/

-- Make the new edition the default for NEW sessions.
-- Sessions already connected keep running the old code: no ORA-04068.
ALTER DATABASE DEFAULT EDITION = rel_42;

How to Handle ORA-04068 in Application Code

You can't stop someone else's deploy from discarding state, but you can make the application shrug it off. Because ORA-04068 fires only once per session, a single retry of the same call on the same connection succeeds: that first failure is what re-initialises the package. Retry only on error code 4068, and only once. If the retry fails too, something else is wrong, such as ORA-04063, and you should surface it. Think about the transaction. The failed call didn't roll anything back, so retrying just that call inside the same transaction is safe. If your framework rolls back on any SQLException, retry the whole unit of work instead. The retry has one limit: after a retry the package state starts fresh. If your logic depended on values cached in package variables earlier in the session, they're gone, which is another reason to keep hot packages stateless.

// io.thecodeforge — Database tutorial
import java.sql.*;

public class OrderService {
    private final Connection conn;

    public OrderService(Connection conn) {
        this.conn = conn;
    }

    public void placeOrder(int amount) throws SQLException {
        int retries = 1;
        while (true) {
            try (CallableStatement stmt = conn.prepareCall("{call order_pkg.place_order(?)}")) {
                stmt.setInt(1, amount);
                stmt.execute();
                return; // success
            } catch (SQLException e) {
                // ORA-04068: existing state of packages has been discarded
                if (e.getErrorCode() == 4068 && retries-- > 0) {
                    // Retry once: package state will be reinitialized
                    continue;
                }
                throw e;
            }
        }
    }
}

Diagnosing ORA-04063: It's Not Always Your Package

When ORA-04063 names a package that you didn't touch, look at what it depends on. If any object it references changes or becomes invalid, the package is invalidated too, and the failure cascades up the dependency chain. Start with the errors of the named object in USER_ERRORS. They usually name the real culprit: a missing column, a changed function signature, or a missing grant. Then list INVALID objects and their dependencies. To recompile, don't write a loop of ALTER statements. Package bodies need ALTER PACKAGE ... COMPILE BODY, and getting the order right by hand is error-prone. Use UTL_RECOMP or DBMS_UTILITY.COMPILE_SCHEMA, which compile in dependency order. Be aware that recompiling stateful packages will itself cause ORA-04068 in live sessions, so do it in the same deploy window.

-- io.thecodeforge — Database tutorial
-- What is invalid right now?
SELECT object_name, object_type, last_ddl_time
FROM   user_objects
WHERE  status = 'INVALID'
ORDER  BY last_ddl_time DESC;

-- The real compile errors
SELECT name, type, line, position, text
FROM   user_errors
ORDER  BY name, type, sequence;

-- What does ORDER_PKG depend on?
SELECT referenced_name, referenced_type
FROM   user_dependencies
WHERE  name = 'ORDER_PKG';

-- Recompile only invalid objects, in dependency order
EXEC DBMS_UTILITY.COMPILE_SCHEMA(schema => USER, compile_all => FALSE);

Make Hot Packages Stateless (and Where SERIALLY_REUSABLE Fits)

The most durable fix is to give ORA-04068 nothing to discard. A package with no package-level variables, constants or cursors has no session state, and recompiling it doesn't raise ORA-04068 in other sessions. Move cached values into a function that queries the source, into an application context (SYS_CONTEXT), or into a table. Pass anything else as parameters. PRAGMA SERIALLY_REUSABLE is the other option. It keeps package state only for the duration of one server call, so there's nothing long-lived to invalidate. The cost is that variables reset on every call, and serially reusable packages can't be called from SQL statements. Use it for genuinely call-scoped state, not as a blanket fix.

-- io.thecodeforge — Database tutorial
-- BEFORE: cached in a package variable -> ORA-04068 after every deploy
CREATE OR REPLACE PACKAGE BODY tax_pkg AS
  g_region VARCHAR2(10);   -- session state
  FUNCTION region RETURN VARCHAR2 IS
  BEGIN
    IF g_region IS NULL THEN
      SELECT region INTO g_region FROM app_config;
    END IF;
    RETURN g_region;
  END;
END tax_pkg;
/

-- AFTER: no package-level state; recompiles no longer hit live sessions
CREATE OR REPLACE PACKAGE BODY tax_pkg AS
  FUNCTION region RETURN VARCHAR2 RESULT_CACHE IS
    l_region VARCHAR2(10);
  BEGIN
    SELECT region INTO l_region FROM app_config;
    RETURN l_region;
  END;
END tax_pkg;
/