Should SQL 2005's BPool Reservation Size Vary With -g Startup Parameter?

Hello, all

We are trying to work out a memory problem associated with a SQLCLR procedure we have developed.

This procedure will run properly on a SQLExpress box, but fails with an Insufficient Memory error (701) when run on our 32-bit enterprise edition server on W2K3 Enterprise Server. The server has 3.25 GB of RAM, and does *not* have the /3GB switch enabled; AWE is *not* enabled on SQL Server.

I initially suspected the problem was due to the idiosyncracies of how the BPool is allocated on SqlExpress and its 1GB buffer pool limitation, giving a 1GB MemToLeave region for SQLCLR allocations -- substantially larger than the default available on the server with it's default 256MB allocation (+128MB for thread stacks). That seemed to explain why a memory problem might not manifest itself on the client, but would on the server. I then altered the server to include an explicit "-g" parameter at startup, reserving 512MB for MemToLeave, but the query still fails with the same memory errors. I've tried values as high as 1GB (-g1024), but none have worked Our DBA has installed a recent hotfix associated with certain memory errors, to no avail.

It appears that the server will max out the CLR allocations at 102MB, regardless of the presence of the -g parameter. Could it be that the MemToLeave region really is that severely fragmented? There are still log messages indicating failures to reserve virtual memory...

One thing I notice is that the buffer's VM Reserved value never seems to change regardless of the value of the "-g" option. I would expect to see it decrease by the amount specified as reserved, eg -g 768 should leave, for example, something like 1.2GB VM Reserved for buffer pool allocation, but it doesn't. That tells me I'm not really establishing a larger MemToLeave area. Is this expectation incorrect?

Bottom line, we don't know why this procedure is running on the server, but not in SqlExpress. It is a procedure that connects to a remote Oracle database and collects about 14,000 records, but dies after sending about 7,000 or so records when run on the server. Again, the same query running against the same code on a SqlExpress box works perfectly.

Any thoughts or suggestions welcomed and greatly appreciated.

David