Problem with a PLSQL procedure

Question

Hi Guys
Here a very small stored proc.
CREATE OR REPLACE procedure PRODDATA.LECTX123 is
type x123_aat is table of PRODDATA.CLIENTS%ROWTYPE index by PLS_INTEGER;
l_x123 x123_aat;
begin
select * bulk collect into l_x123 from PRODDATA.CLIENTS;
FOR indx IN 1 .. l_x123.COUNT
LOOP
null;
END LOOP;
end;
A call to this procedure from SQL-PLUS give us a big nightmare. Paging space is 100% used and the HP-UX partition must be restarted !!!
Why memory consumption on all the systems
Global memory system is 120 GB
SGA_TARGET = SGA_MAX_SIZE = 2 GB
PGA_AGGREGATE_TARGET = 256 MB
IT's very strange.
Regards
A.G.

Answer 1

Andre-Guy wrote:
It was just a test to reproduce an initial error. That mean that, to secure my servers I need to limit ressources on Oracle background processes to avoid this. IT's a solution but I agree not the explaination of this curious behaviour. What is curious about PL/SQL doing as instructed, fetching 16 million rows and attempting to allocate sufficient memory (private process memory) to store these rows?
You can do the same with C/C++ program and a malloc() call. You could cause it by trying to load a 4GB text file into an editor on the server.
The only curious thing in this regard is not using bulk processing in PL/SQL as it is supposed to be use. Bulk fetching is not about caching data in the PGA (PL/SQL private and dedicated memory), but about reducing context switching.
As for "+limiting resources to avoid such a problem+", what about protecting the server against cartersian joins? Or badly designed SQL? Or a row-by-row processing instead of processing data sets? And so on...?
Just where do you draw the line in trying to make the server (and its resource utilisation) idiot proof? Is it not better to educate these idiots in using the server correctly? Which means that instead of the server spending time trying to protect itself, it spends time running well designed and written production code?
IMO the problem you describe is not one about server resource abuse, but ignorance. And that one fixes not by protecting the server, but by curing the ignorance. Doing bulk processing correctly is not rocket science either.