För det första skulle du normalt inte använda DBMS_OUTPUT för loggning. Det skulle generellt vara mycket mer meningsfullt att skriva data till en loggtabell, särskilt om din loggningsprocedur definierades som en autonom transaktion så att du kunde övervaka loggdata medan proceduren kördes. DBMS_OUTPUT kommer bara att visas efter att hela proceduren har körts klart och då är det i allmänhet något meningslöst.
Relaterat till den första punkten, beroende på DBMS_OUTPUT att indikera för den som ringer att det har funnits något slags undantag är en mycket dålig praxis. Som ett minimum skulle du vilja höja undantaget som kastades igen så att du får felstacken för att felsöka problemet.
För det andra, när du aktiverar utdata måste du ange storleken på bufferten som DBMS_OUTPUT kan skriva till. Det verkar som att du har deklarerat bufferten till 20 000 byte, vilket är standard om du bara
SQL> set serveroutput on;
Du kan ändra det genom att ange en storlek men den maximala storleken är begränsad till 1 000 000 byte
SQL> set serveroutput on size 1000000;
Om du planerar att uppdatera 3 miljarder rader i 1000 radbitar, kommer det att bli en alldeles för liten buffert. Du kommer att generera mer än 60 gånger så mycket data med din nuvarande kod. Om du använder 10.2 både på klienten och på servern bör du kunna allokera en obegränsad buffert
SQL> set serveroutput on size unlimited;
men det är inte ett alternativ i tidigare utgåvor.
Slutligen, är du säker på att du måste ta till PL/SQL i första hand? Det verkar som att du kan göra detta mer effektivt genom att helt enkelt köra en enda UPPDATERING
UPDATE table_
SET id = floor( seq/ 10000000000000 )
WHERE id is null;
Det är mycket mindre kod, mycket lättare att läsa och kommer att vara effektivare än PL/SQL-alternativet. Den enda nackdelen är att det kräver att ditt UNDO-tabellutrymme är tillräckligt stort för att rymma UNDO som genereras, men att uppdatera en enda kolumn från NULL till ett icke-NULL-numeriskt värde borde inte generera så mycket UNDO.