手順バッファオーバーフロー

まず、通常はDBMS_OUTPUTを使用しません。ロギング用。特にロギングプロシージャが自律型トランザクションとして定義されている場合は、プロシージャの実行中にログデータを監視できるように、データをログテーブルに書き込む方が一般的にはるかに理にかなっています。 DBMS_OUTPUT プロシージャ全体の実行が終了した後にのみ表示されます。その時点では、通常、多少意味がありません。

その最初のポイントに関連して、DBMS_OUTPUTに依存していますある種の例外があったことを発信者に示すことは、非常に悪い習慣です。少なくとも、スローされた例外を再発生させて、問題をデバッグするためにエラースタックを取得する必要があります。

次に、出力を有効にするときは、DBMS_OUTPUTするバッファのサイズを指定する必要があります。書くことができます。バッファを20,000バイトとして宣言したようです。これは、単純に

の場合のデフォルトです。

SQL> set serveroutput on;

サイズを指定することで変更できますが、最大サイズは1,000,000バイトに制限されています

SQL> set serveroutput on size 1000000;

1000行のチャンクで30億行を更新することを計画している場合、バッファーは小さすぎます。現在のコードでは、その60倍以上の量のデータを生成します。クライアントとサーバーの両方で10.2を使用している場合は、無制限のバッファーを割り当てることができるはずです

SQL> set serveroutput on size unlimited;

ただし、これは以前のリリースではオプションではありません。

最後に、そもそもPL / SQLに頼る必要があると確信していますか？単一のUPDATEを実行するだけで、これをより効率的に実行できるようです

UPDATE table_
   SET id = floor( seq/ 10000000000000 )
 WHERE id is null;

これは、コードがはるかに少なく、読みやすく、PL/SQLの代替手段よりも効率的です。唯一の欠点は、UNDOテーブルスペースが生成されるUNDOを収容するのに十分な大きさである必要があることですが、単一の列をNULLからNULL以外の数値に更新しても、それほど多くのUNDOは生成されないはずです。