For det første ville du normalt ikke bruge DBMS_OUTPUT til logning. Det ville generelt give langt mere mening at skrive dataene til en logtabel, især hvis din logningsprocedure var defineret som en autonom transaktion, så du kunne overvåge logdataene, mens proceduren kørte. DBMS_OUTPUT vil først blive vist, efter at hele proceduren er afsluttet, hvorefter den generelt er noget meningsløs.
Relateret til det første punkt, afhængig af DBMS_OUTPUT at indikere over for den, der ringer, at der har været en form for undtagelse, er en meget dårlig praksis. Som et minimum vil du gerne re-raise den undtagelse, der blev kastet, så du ville få fejlstakken for at fejlfinde problemet.
For det andet, når du aktiverer output, skal du angive størrelsen på bufferen, som DBMS_OUTPUT kan skrive til. Det ser ud til, at du har erklæret bufferen til at være 20.000 bytes, hvilket er standard, hvis du blot
SQL> set serveroutput on;
Du kan ændre det ved at angive en størrelse, men den maksimale størrelse er begrænset til 1.000.000 bytes
SQL> set serveroutput on size 1000000;
Hvis du planlægger at opdatere 3 milliarder rækker i 1000 rækkestykker, vil det være en alt for lille buffer. Du kommer til at generere mere end 60 gange så meget data med din nuværende kode. Hvis du bruger 10.2 både på klienten og på serveren, bør du være i stand til at allokere en ubegrænset buffer
SQL> set serveroutput on size unlimited;
men det er ikke en mulighed i tidligere udgivelser.
Er du endelig sikker på, at du skal ty til PL/SQL i første omgang? Det ser ud til, at du kunne gøre dette mere effektivt ved blot at udføre en enkelt OPDATERING
UPDATE table_
SET id = floor( seq/ 10000000000000 )
WHERE id is null;
Det er meget mindre kode, meget nemmere at læse og vil være mere effektivt end PL/SQL-alternativet. Den eneste ulempe er, at det kræver, at dit UNDO tablespace er stort nok til at rumme den UNDO, der genereres, men opdatering af en enkelt kolonne fra NULL til en ikke-NULL numerisk værdi burde ikke generere så meget UNDO.