Maximize Use of Available RAM by 32-bit SQL Anywhere 12.0 on 64-bit Server

[Former Member]

I have a product that uses the 32-bit OEM Version of Sybase Anywhere 12.0

I have dedicated 64-bit Servers, Both Windows and Linux Available, with extensive amounts of ram to host the 32-bit Sybase Anywhere 12.0 Server.

Is there anything I can do to make use of the large amounts of Physical RAM despite only having the 32-bit Version of Sybase?

[MCMartin]

Check if the 64bit components are installed, if so you can use them against the same database base file and your 32 bit clients can access the 64 bit server without any extra effort.

[johnsmirnios]

On Windows, the 32-bit database server using a regular cache will have access to almost 4GB of memory. I believe the same is true of Linux.

On Windows, you can also use an AWE cache to take advantage of more memory. See http://dcx.sybase.com/index.html#1201/en/dbadmin/cw-database-dbserver.html*d5e12045

AWE is not available on Linux.

-john.

[MCMartin]

see http://blogs.msdn.com/b/slavao/archive/2005/04/29/413425.aspx for AWE on 64 Bit OS

[johnsmirnios]

Interesting article and shows that the physical memory allocation API added for AWE can still be useful on 64-bit platforms.

In ithowto's case, I'm merely suggesting that if he is stuck using a 32-bit engine then AWE will allow access to more than 4GB of memory. The 64-bit server is definitely the way to go if it can be done. A 64-bit server would definitely be preferable.

[Former Member]

The obvious question is why are you running a 32-bit Sybase on a 64-bit server.

I have installed 64-bit ASA on half a dozen different servers, and it works very well.

Finally, as a software engineer, even on a 32-bit platform, if the application is built "right", you shouldn't be needing such a big cache ...

Last but not least, check out the 'in memory' option ...

http://www.databasejournal.com/features/sybase/article.php/10899_3781101_2/Top-10-Cool-New-Features-...

[Breck_Carter]

"if the application is built "right", you shouldn't be needing such a big cache"... it's hard to imagine how to build software "right" to avoid benefitting from large amounts of DBMS RAM cache. Perhaps by using cursor fetch loops for everything, with tiny rows processed one-by-one on the client side, perhaps with client-side joins and other tricks to prevent the DBMS from using large amounts of cache to process queries? If so, watch for skyrocketing CPU requirements and slow performance as both the client and server components struggle to handle billions of tiny client-server requests rather than take advantage of the query engine's ability to use huge amounts of RAM cache to efficiently process sophisticated queries.