Ok, that's what I thought when you mentioned PAE and AWE.
So, caveat #1 is I am not an expert with Business One. However, I suspect what I'll have to say below will still apply, but if any B1 experts see this, they may certainly override what I have to say.
Caveat #2 is that 32-bit Windows or SQL Server is not supported for Business One 8.81, per the PAM. I would strongly, strongly urge you to upgrade to 64-bit.
Caveat #3 is that, although B1 8.81 is supported on Win2003 / SQL2008, this is only when both are 64-bit editions. Furthermore, SAP does not support SQL Server 2008 in 32-bit at all. SAP does (or did) support SQL Server 2005 and earlier in 32-bit editions. It is possible you might be able to make some of the older advice for SQL 2005 32-bit, or even SQL 2000 32-bit, work for you, but it would be "use at your own risk."
So, with that out of the way, as a temporary measure until you can upgrade to 64-bit, you might try the SQL 2000 advice from Note 327494 for 32-bit systems with > 16 GB of memory:
- SQL Server min and max server memory should be identical to each other, and should be set to 30% of RAM - 1 GB, or say 6000 MB in your case.
- If B1 has a PHYS_MEMSIZE profile parameter similar to a NetWeaver ABAP server, then you should probably set that to about 60% of RAM, or perhaps 15000 MB. Remember, you need to leave some memory over for the OS, and when running /PAE this is especially important as Windows needs to use some of the lower memory area just for managing the upper memory area.
- Make sure the Windows service account used to run SQL Server has the "Lock pages in memory" user right (set this with gpedit.msc on the Windows console).
The thing to remember is that all of this with AWE and PAE was always nothing more than workarounds to try to do a little better with more than 4 GB of physical RAM on 32-bit architecture, but it is no substitute for 64-bit architecture, and setting these flags will not magically make your system behave as if it's 64-bit. It's a bandaid at best. The system is "tricking" SQL Server into thinking it can use all that memory, but as the OS still only manages 2 GB at a time for applications, it is "paging" the working memory in and out of that 2 GB limit.
With respect to the memory in use by SAP, each work process can use at maximum 2 GB in a 32-bit environment, so while the work processes in total might use the 15 GB you assign in PHYS_MEMSIZE, individual processes are still highly limited.
Instead of purchasing more memory for a 32-bit system, I would invest your resources in migrating to 64-bit. It will require a reinstallation of the operating system and of SQL Server, but as far as the SAP software goes, it involves not much more than switching out the kernel with a 64-bit version. It's ridiculously simple.
Cheers,
Matt