Subject | Re: [Firebird-general] big time firebird |
---|---|
Author | Dalton Calford |
Post date | 2004-05-12T15:48:50Z |
Fred Pratt wrote:
online, with data increasing by 4-5 GB a month, our databases are large.
There are a few points to be made.
1.) no single table can survive the 40GB(approx) mark with current
versions of IB/FB. (Vulcan may eliminate this with 64 bit file
structures) You let the table grow too big, and it will corrupt your
database. (this may be a index issue, have not tried a large table
without a index)
2.) Too many transactions and your transaction counter will wrap,
causing all sorts of grief. So backup and restores are valuable.
3.) Alot of data items can be split between natural breakpoints (dates,
both physical and accounting or some other method) and your client
application or middle ware can look across multiple databases for the data.
4.) Proper hardware design can improve performance, but good schema
design is critical, and the ability to specify table/index placement is
not really an issue, but tempory file placement is.
best regards
Dalton
>I have followed this group pretty closely and have not seen a reference to aWe have large databases. With the need to keep 7 years worth of data
>Firebird database larger than 15GB (and that was my own). Are there larger
>ones out there?
>
>
>
online, with data increasing by 4-5 GB a month, our databases are large.
There are a few points to be made.
1.) no single table can survive the 40GB(approx) mark with current
versions of IB/FB. (Vulcan may eliminate this with 64 bit file
structures) You let the table grow too big, and it will corrupt your
database. (this may be a index issue, have not tried a large table
without a index)
2.) Too many transactions and your transaction counter will wrap,
causing all sorts of grief. So backup and restores are valuable.
3.) Alot of data items can be split between natural breakpoints (dates,
both physical and accounting or some other method) and your client
application or middle ware can look across multiple databases for the data.
4.) Proper hardware design can improve performance, but good schema
design is critical, and the ability to specify table/index placement is
not really an issue, but tempory file placement is.
best regards
Dalton