On Wed, 11 Feb 2004 08:03:02 +0000 (UTC), Venus Software Operations wrote:

> At 03:02 am 11/02/2004, you wrote:
>> Hardly any tuning is required, and there isn't much to tune.
>> Choose a page size that suits your data (size of database) - 4KB or 8KB
>> is fine for most situations.
>
> Okay. I guess Marathon gave me a default of 1024, can I change it to 4
> or 8K after creation of the database?

As Alan said, backup and restore with new page size.

>> Choose a buffer size (depending on architecture: CS or SS), number of
>> active databases, and available RAM (and for CS: active users).
>> With SS, start at 5000-10000 pages for cache size if this fits with RAM
>> size etc. I don't know whether the old 'truth' that one should not exceed
>> about 10.000 cache pages (which makes for about 80MB RAM with 8KB page
>> size) for a database still holds.
>
> I just got lost, sorry.

If you have a page size of 8KB and a cache of 8192 pages, you will need
64MB RAM (plus some small fixed "overhead"). If you have to databases like
this opened, you'll need twice the RAM.
With IB/5.6 (and earlier/later versions?) there was little (if anything) to
gain by increasing the cache much above 10000 pages, but YMMV.

>
>
>> Use gbak regularly, and occasionally do a restore to a new database to
>> check that backups are OK.
>
> Okay. Thanks.
>
>
>> That's it.
>> Make sure that transaction numbers advance properly (no stuck or
>> everlasting transactions) - if you have a period of inactivity (no users
>> connected) you might schedule a SWEEP to clean up transaction numbers
>> and garbage.
>
> Sorry, didn't get it.

With time you will ... - I don't know how to explain it in a simple way.
If you usually have no clients connected at night, I think you should do a
backup (gbak) followed by a sweep (gfix -sweep) - you can then run gbak
with 'garbage collection' turned off.
If there are clients connected 'always', just run gbak ('garbage
collection' is turned on by default). And occasionally watch the
statistics on the 'header page' - don't let the 'transaction gap' become
too wide. You can use IBOconsole (or a command line utility) for this.
These are lines to look for:
Oldest transaction 105
Oldest active 859
Oldest snapshot 859
Next transaction 860
The numbers shouldn't be too far apart. (After a SWEEP, the 105 moved up
to 860)

>> Check that you don't have indexes with very bad selectivity on large
>> tables. ("bad' selecticity means 'low' selectivity which in IB/Fb is
>> indicated by a high number - IIRC).
>
> I don't really plan to use indexes. There are default as created for PK.
> Are other Indexes necessary. I will be using FB through ODBC in VFP so I
> will be pulling in limited data, generally.

If your selection criteria don't include the PK you may need indexes unless
the tables are small (or if speed doesn't matter much).


--
Aage J.