Please be aware that the content in SAP SQL Anywhere Forum will be migrated to the SAP Community in June and this forum will be retired.

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?

asked 28 Apr '12, 16:02

ithowto's gravatar image

ithowto
1111
accept rate: 0%

edited 30 Apr '12, 08:57

Volker%20Barth's gravatar image

Volker Barth
40.2k361550822

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.

(30 Apr '12, 02:46) Martin

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.

permanent link

answered 28 Apr '12, 17:42

John%20Smirnios's gravatar image

John Smirnios
12.0k396166
accept rate: 37%

(30 Apr '12, 02:45) Martin
Replies hidden

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.

(30 Apr '12, 10:04) John Smirnios

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-In-SQL-Anywhere-11.htm

permanent link

answered 29 Apr '12, 10:25

Frum%20Dude's gravatar image

Frum Dude
136339
accept rate: 0%

2

"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.

(30 Apr '12, 10:34) Breck Carter
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×36
×26
×21

question asked: 28 Apr '12, 16:02

question was seen: 5,097 times

last updated: 30 Apr '12, 10:34