Database is unable to spawn SQL server processes ( _SQLSRV2 )

Database is unable to spawn SQL server processes ( _SQLSRV2 )
JDBC / ODBC connections fail.
Database log file shows entries similar to the following:
 

Database has a high -B value.
Database has a high -L value.

ABL client-server connections work as expected.

The SQL engine in Progress 9.1D and later requires a shared memory segment because it is now multi-threaded. When an SQL server opens an additional memory segment, the request for an additional shared memory space exceeds the Windows 2 GB limit for a 32-bit process.

On 32-bit Windows, the shared memory limit for a process is 2GB. This 2GB of virtual address space (also known as VAS) is mapped by the operating system to the physical memory and the paging file if needed, for each running process. When an user process is initiated, it will use its allocated VAS for its execution segment, data, loaded dlls, memory mapped files (which is the way how the shared memory is accessed), stack, heap etc.  All of this must fit within the process' VAS which is limited on Windows 32-bit to 2GB.

Moreover there are loaded dlls, allocated stack, heap, open files, and various other memory structures allocated from within its executable, or from within functions residing in its dlls, which leaves even less space remaining for attaching the database shared memory segments.  When there is no enough space in process' VAS, and the client tries to connect as self-service to the database server, failure to attach the shared memory segment will result in error 1720 with the error code 0.

There are many Progress parameters that contribute to the size of the shared memory structure when a session is started. The largest contributor is the Buffer Pool (-B, -B2) x database blocksize.

The client process on Windows may have limited ability to connect to between 1.4 gig and 1.7 gig of shared memory. This is partially dependent on the Progress OpenEdge version as changes to later versions like 10.1B change the internal allocations of structures in shared memory and these changes have a result of limiting the maximum size of shared memory a client process can attach to approximately 1.4 gig of shared memory. Early clients may be able to attach to up to 1.7 gig of shared memory.

Option #1  Switch to 64-bit OpenEdge / Windows.

From OpenEdge 10.2B onward, a 64-bit Windows edition of OpenEdge is available. A 64-bit process can access more than 2GB of shared memory.

Option #2  Reduce shared-memory

Reduce the -B and / or -L database startup parameters to an acceptable limit, so the process does not exceed 2 GB of shared memory.

From OpenEdge 10.1C, it is possible to adjust some database parameters (including -B and -L) when the database is online. It would be possible to start the database with a low -B / -L setting, and then increase it incrementally to determine the optimum values.

OpenEdge 10.1B introduced Improved shared memory segment allocation enhancements where a new database configuration parameter, -shmsegsize, allows the shared-memory segment size to be set explicitly, where it was previously hard-coded to 128MB. For 32-bit systems, this means a 32-bit database can address fewer but larger shared segments (up to the size allowed by the operating system). When not specified this parameter is calculated. When the required memory exceeds 1GB, it is advisable to use a lower -shmsegsize to satisfy the requirement and this may then allow the extra shared memory segment for the SQL engine to fit in the Virtual Address Space.
 

Progress Articles:

What is proutil <dbname> -C  increaseto?   
32-bit client fails to connect self-service to one or more databases error 1720   
What is the default -shmsegsize value used when allocating shared memory segments?