In Sybase, everything of interest (data, indexes, metadata) is stored on pages.
The size of the page is defined by @@maxpagesize (number of bytes on a page). [For SAP/SID dataservers I believe @@maxpagesize is defined as 16K.]
While all pages are stored on disk, some of the pages are also stored in a chunk of memory referred to as a 'data cache'. Sybase has a default cache named 'default data cache'; the DBA can define additional data caches (additional data caches are typically created for performance reasons).
All operations (insert, delete, update, select, update stats, create index, reorgs, etc) on data (and index) pages are performed against pages in memory; in other words, all pages that the dataserver needs to touch must reside in a data cache (ie, memory).
If a desired page does not exist in a data cache (ie, memory), Sybase must submit a request to the OS to read a page from disk. When the page is returned by the OS, Sybase must make room for the page by removing some other page from the data cache (ie, memory).
The cache hit ratio gives us an idea of how often Sybase found a page already in cache. The higher the cache hit ratio the more pages Sybase found already in cache (ie, less time Sybase has to wait for pages to be retrieved from disk). The lower the cache hit ratio the fewer pages Sybase found in cache (ie, the more time Sybase has to spend waiting for pages to be retrieved from disk).
Keep in mind that your cache hit ratio can go up and down based on the type of activity going on at any one period in time.
Tuning your dataserver to improve your cache hit ratio can get a bit involved since there are slew of issues that need to be taken into account ... amount of memory available, size of the data cache(s), number of partitions in the data cache, page size, table/index structures, query plans and the associated access plans, and on and on and on ...
Generally speaking, low cache hit ratios can occur:
1 - immediately after the dataserver is rebooted; this is because upon bootup the data cache is empty, so it can take awhile for user activity to pull pages from disk; while it is possible for the DBA to create some SQL scripts to pre-load the cache after a dataserver reboot, this requires a good bit of understanding about the actual data records that need to be pulled into cache (from disk)
2 - some large queries (eg, a report that SELECTs a large volume of data) may pull 'old' data from disk thus pushing 'newer' data out of cache; the cache hit ratio can fall during this query due to having to pull a lot of older pages from disk; you'll also see a low cache hit ratio afterwards as normal user activity now has to re-pull the newer pages off of disk and back into memory; the issue here is that most Sybase dataservers don't have access to enough memory to hold the entire database in memory (think 10's and 100's of GBs of memory versus TBs of data), so queries that go looking for old/less-used data may force new/more-often-used pages from cache
3 - some maintenance operations (eg, create index, update stats, reorgs) may need to pull large volumes of old/less-used data from disk; as with example #2, this type of operation may show up as a reduced cache hit ratio due to having to pull large volumes of pages from disk to support said operation, and of course follow-on user activity will see a reduced cache hit ratio as they have to wait to pull newer pages from disk back into memory