Después de que se haya ejecutado la instrucción UPDATE, los efectos de la declaración serán visibles para el resto de la transacción (y si se confirma, para otras transacciones). ¿En qué orden Oracle lo hará físicamente, es un implementación detalle (de manera similar cómo el orden del resultado SELECT no está garantizado a menos que especifique ORDER BY).
En la mayoría de los casos, este pedido no le importa al cliente. Un caso donde podría ser es evitar interbloqueos con otra transacción que está actualizando el conjunto de filas superpuestas. ACTUALIZAR bloqueará la fila que se está actualizando hasta el final de la transacción, por lo que si dos transacciones intentan bloquear las mismas filas, pero en orden diferente, puede producirse un punto muerto.
La forma estándar de evitar interbloqueos es bloquear siempre en un orden bien definido. Por desgracia, UPDATE no tiene la cláusula ORDER BY, pero se puede hacer esto:
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SELECT ... WHERE condition ORDER BY ... FOR UPDATE;
UPDATE ... WHERE condition;
COMMIT;
Dónde condition es igual para ambos estados. El nivel de aislamiento serializable es necesario para WHERE para ver siempre el mismo conjunto de filas en ambas sentencias.
O, en PL/SQL se podría hacer algo como esto:
DECLARE
CURSOR CUR IS SELECT * FROM YOUR_TABLE WHERE condition ORDER BY ... FOR UPDATE;
BEGIN
FOR LOCKED_ROW IN CUR LOOP
UPDATE YOUR_TABLE SET ... WHERE CURRENT OF CUR;
END LOOP;
END;
/
Lógicamente, se realizan simultáneamente. En la práctica, no lo hacen, pero no podrás ver la diferencia. Se vuelve más interesante si lo hace 'ACTUALIZAR Tabla1 SET Index = Índice + 1 WHERE Índice ENTRE 1 Y 5'. –