Tout d'abord, vous n'utiliseriez normalement pas DBMS_OUTPUT pour la journalisation. Il serait généralement beaucoup plus logique d'écrire les données dans une table de journal, en particulier si votre procédure de journalisation a été définie comme une transaction autonome afin que vous puissiez surveiller les données du journal pendant l'exécution de la procédure. DBMS_OUTPUT ne s'affichera qu'après la fin de l'exécution de toute la procédure, auquel cas il est généralement quelque peu inutile.
Lié à ce premier point, en s'appuyant sur DBMS_OUTPUT indiquer à l'appelant qu'il y a eu une sorte d'exception est une très mauvaise pratique. Au minimum, vous voudriez relancer l'exception qui a été levée afin d'obtenir la pile d'erreurs afin de déboguer le problème.
Deuxièmement, lorsque vous activez la sortie, vous devez spécifier la taille du tampon que DBMS_OUTPUT peut écrire à. Il semble que vous ayez déclaré que le tampon est de 20 000 octets, ce qui est la valeur par défaut si vous simplement
SQL> set serveroutput on;
Vous pouvez changer cela en spécifiant une taille mais la taille maximale est limitée à 1 000 000 octets
SQL> set serveroutput on size 1000000;
Si vous envisagez de mettre à jour 3 milliards de lignes par tranches de 1 000 lignes, ce sera un tampon beaucoup trop petit. Vous allez générer plus de 60 fois cette quantité de données avec votre code actuel. Si vous utilisez 10.2 à la fois sur le client et sur le serveur, vous devriez pouvoir allouer un tampon illimité
SQL> set serveroutput on size unlimited;
mais ce n'est pas une option dans les versions antérieures.
Enfin, êtes-vous certain de devoir recourir au PL/SQL en premier lieu ? Il semble que vous puissiez le faire plus efficacement en exécutant simplement une seule MISE À JOUR
UPDATE table_
SET id = floor( seq/ 10000000000000 )
WHERE id is null;
C'est beaucoup moins de code, beaucoup plus facile à lire et sera plus efficace que l'alternative PL/SQL. Le seul inconvénient est qu'il nécessite que votre tablespace UNDO soit suffisamment grand pour accueillir l'ANNULATION générée, mais la mise à jour d'une seule colonne de NULL à une valeur numérique non NULL ne devrait pas générer autant d'annulation.
