From the manual: (
http://download.sybase.com/pdfdocs/awg0704e/dbrfen7.pdf )

=====
-ch

"This option limits the cache that the database server can take during
automatic cache growth. By default the upper limit is approximately the
lower of 256 Mb and 90% of the physical memory of the machine."
=====

That's the default behaviour for not specifying the switch. If you want
the database server to try and automatically grow the cache size to
"more" than that value, then yes, you should set this switch
appropriately as well:

dbsrv7 -c 75P -ch 75P ...

Regards,

Deepali wrote:
--
Jeff Albion, Sybase iAnywhere

iAnywhere Developer Community :
http://www.sybase.com/developer/libr...ere-techcorner
iAnywhere Documentation : http://www.ianywhere.com/developer/product_manuals
SQL Anywhere Patches and EBFs :
http://downloads.sybase.com/swd/summ...&timeframe =0
Report a Bug/Open a Case : http://case-express.sybase.com/cx/

Hi Deepali,

Deepali wrote:
The "dependency" is basically internal to the server - depending on free
resources, the optimizer will pick different joining strategies when
executing queries. (e.g. if there isn't a large amount of memory, we may
pick a less 'memory-intensive' algorithm that's slightly slower to do a
table join as opposed to a more 'memory-intensive' operation that may be
a little faster). However, you should be aware that consuming more
resources for the database server may affect other applications running
on the system. Many of our customers will use a 'dedicated server' for
just running the database, but not all do.

This is good!

I believe this may be an inaccurate error message. It probably should
also read 'Not enough memory' or possibly 'Database file is in use' (if
you tried to start two servers with the same database file).

Also, what is "E:"? Is it a local drive? Please note that you should not
run database files over an NFS share ("Windows Share") due to the
requirements for write-ordering and write-through that the database
server requires: http://www.sybase.com/detail?id=1034790

Note there are two switches acting on these two servers - "-c" (initial
cache size) and "-ch" (maximum cache size). "-c" is what we will try to
initially allocate, and "-ch" is what we reserve at the operating system
level to "use up at a later time if required".

From your screenshot, I can see that there are two database servers now
running (re: the icons in the system tray). The point is that if one
database server tries to allocate 75% of the total RAM, another server
will not be able to allocate all of the same amount (particularly in the
constrained memory environment of 512MB - note that there is only "5MB"
of memory space left according to the server).

In production I assume you only run a single server, correct? Try
shutting down the first server before trying to start additional servers.

Regards,

--
Jeff Albion, Sybase iAnywhere

iAnywhere Developer Community :
http://www.sybase.com/developer/libr...ere-techcorner
iAnywhere Documentation : http://www.ianywhere.com/developer/product_manuals
SQL Anywhere Patches and EBFs :
http://downloads.sybase.com/swd/summ...&timeframe =0
Report a Bug/Open a Case : http://case-express.sybase.com/cx/

Hi Jeff...
Thank you for your reply....
Jeff.. E: is a local drive.
When I set initial cache size as 75p all the max, min cache
size are set to the same value.I changed cache size in
server service properties window in parameters for the
executable file dbsrv7.Earlier it was 1300 mb, now I changed
it to 75P and the value now is 392824. If its in KB, then
isn't that 1300 mb is greater than 392824Kb which is 0.39
Mb although I see a performance gain with this step as the
report which was earlier taking around 45mins-1 hour now
started up in 20 mins.

Yes, in production there is only one server and one
database.
How can I reverse the cache allocated to one and increase it
for the other if there are two.

Jeff.. should I also rebuild the db to have more performance
gains...
Thanks.. Deepali

Hi Deepali,

Deepali wrote:
I believe this is true for -cl:

"This option sets a lower limits to the cache. The default minimum cache
size is the initial cache size."

And true for -ch where "75%" is greater than 256M:

"This option limits the cache that the database server can take during
automatic cache growth. By default the "upper limit is approximately
the lower of 256 Mb and 90% of the physical memory of the machine."

How did you specify the "1300 MB" on the command-line? If the server is
performing 'better' with what should be a smaller cache, then I'm
guessing this was not specified correctly.

Also, 392824K = 392.8M, not 0.39M.

I'm glad to hear that your query is already running slightly faster.

You have to shut down both database servers and reconfigure them with
new "-c" switches.

Possibly - although, this is another 'magic bullet' approach to
performance gains. Rebuilding only gives us a chance to create more
"bushy" indexes and arrange the rows on pages in as compact a form as
possible (which may save on I/O requests). But, performing additional
work on the database will eventually degrade this arrangement and is not
a long-term solution.

It's likely that the application's queries need to be diagnosed and
tuned to see substantial performance improvements.

Regards,

--
Jeff Albion, Sybase iAnywhere

iAnywhere Developer Community :
http://www.sybase.com/developer/libr...ere-techcorner
iAnywhere Documentation : http://www.ianywhere.com/developer/product_manuals
SQL Anywhere Patches and EBFs :
http://downloads.sybase.com/swd/summ...&timeframe =0
Report a Bug/Open a Case : http://case-express.sybase.com/cx/