Primero, asumo que podemos ignorar los errores de sintaxis (por ejemplo, no hay END LOOP , el dbms_output.put_line a la llamada le falta la primera comilla simple, etc.)
En cuanto a si es necesario revertir los cambios, depende.
En general, no tendría confirmaciones provisionales en un bucle. Por lo general, es una arquitectura deficiente porque es mucho más costosa en términos de E/S y tiempo transcurrido. También hace que sea mucho más difícil escribir código reiniciable. ¿Qué sucede, por ejemplo, si su SELECT ¿La declaración selecciona 10 filas, emite (y confirma) 5 actualizaciones y luego falla la sexta actualización? La única forma de poder reiniciar con la sexta fila después de haber solucionado la excepción sería tener una tabla separada donde almacenó (y actualizó) el progreso de su código. También crea problemas para cualquier código que llame a este bloque que luego tiene que manejar el caso de que la mitad del trabajo se haya realizado (y confirmado) y la otra mitad no.
En general, solo colocaría declaraciones de control de transacciones en los bloques más externos de su código. Desde un COMMIT o un ROLLBACK en un procedimiento confirma o revierte cualquier trabajo realizado en la sesión, ya sea que el procedimiento lo haya hecho o no, debe tener mucho cuidado al agregar declaraciones de control de transacciones. Por lo general, desea dejar que la persona que llama tome la decisión de confirmar o retroceder. Por supuesto, eso solo llega hasta cierto punto:eventualmente, estará en el bloque más externo que nunca será llamado desde alguna otra rutina y necesita tener un control de transacción adecuado, pero es algo que debe tener mucho cuidado. sobre si está escribiendo código que podría reutilizarse.
En este caso, dado que tiene confirmaciones provisionales, el único efecto de su ROLLBACK sería que si la primera declaración de actualización fallara, el trabajo que se había realizado en su sesión antes de llamar a este bloque se revertiría. La confirmación provisional confirmaría esos cambios anteriores si la primera declaración de actualización fue exitosa. Ese es el tipo de efecto secundario que preocupa a la gente cuando habla de por qué las confirmaciones provisionales y el control de transacciones en bloques reutilizables son problemáticos.
