DATABASE_CACHE_PAGESset to 10000 and use 8K pages; it means 80MB of cache per database , i.e. after connecting to 4 databases, InterBase will allocate 320MB of RAM for cache! For this reason it seems better to keep this value relatively small, and set cache size individually for each database.
Do not forget to uncomment proper line in
and restart InterBase (superserver) to take change into account.
isc_dpb_num_buffersparameter in DPB block, that is used by
isc_attach_database()function. The behavior is different for Classic and for Superserver:
Because in classic InterBase each user runs its own copy of IB server, each user has its own buffers, and thus user can set whichever value he/she wants (i.e. changing number of buffers in one process does not affect other users/processes).
In superserver IB, buffers are shared among all users; it means
ibconfigfile or built-in default)
In isql utility there are two possibilities how to change cache size at attachment level -
-c command line parameter, or by
CACHE parameter of
In fact, InterBase does not directly support
(i.e. you can't directly execute
CONNECT statement by
isql will parse its command line, and when it encounters
it will convert it to calling
It means both "
-c" command line parameter, and
CACHE parater of
statement are finally converted to
isc_dpb_num_buffers value in DPB block.
CACHE has higher priority than
-c if you use both.
-buffers1234) and stored on gdb header page. New value does not take effect immediately, but when the server opens database file (i.e. after closing all connections first). The value is preserved when doing backup/restore, but sometimes it does not work correctly, so you should verify it after restore. You can also change the value during restore (gbak
-c -buffers1234). To get rid of database wide cache setting, set the value to zero.
CREATE DATABASEcommand. E.g. when you create new database by isql and immediately check cache size, you will see that command line
-cparameter is ignored, and built-in or
ibconfigvalue will be used.
SET STAT; COMMIT;In WISQL use menu command
Session Basic Settings Display Statisticsand then execute
isc4.gdb(that must be opened during each login) shows the same effect (slow login) if you set large cache size directly in security database (by gfix), but is not influenced by large default value in