| Subject | Re: [IBDI] Max DB-size? |
|---|---|
| Author | Charlie Caro |
| Post date | 2000-10-19T16:20:29Z |
tjemalaga@... wrote:
platform. It has an uncertified limit of 4GB on Windows NT/2000 because
of a technical oversite on our part. Based on my research there should
be no problem supporting a 4GB file but it has not gone thru testing or
certification cycles.
Some people have reported no problem using 4GB files while a few claim
to have correlated database corruption with a 4GB file. My opinion is
that those corruptions were unrelated to the database file size.
A single InterBase DATABASE can consist of multiple database FILES.
Theoretically, you can have 64K files, each file being 4GB but the real
database size is limited by the logical linear page space. Since an
internal page number is 32-bits (signed) and the current largest page
size is 8KB, the actual theoretical database limit is 8KB*2G pages or
about 1.6 terabytes.
As the database starts to grow to 100's of GB, it just isn't practical
(but it is possible) from a managebility angle to have it mapped to
hundreds of files. For example, a database file with 1,000 files would
require 1,000 file handles in Superserver (2,000 if the database is
shadowed). In Classic, 100 clients would open 100,000 file handles
(200,000 if shadowed) collectively.
The above is impractical and there will be a future project to support
64-bit file pointers. I consider this project orthogonal to the question
of automatice database file extension. One doesn't obviate the other.
importance. The code probably follows the 20/80 rule which says that 20%
of the code is executed 80% of the time. So it depends if the L2-cache
is integrated (code/data) or if there are separate caches for each.
Either way, your money would be better spent on fast disks.
Regards,
Charlie
probably true.
Regards,
Charlie
>A single InterBase database FILE has a certified limit of 2GB on every
> Hi everybody!
>
> The maximum interbase db-size seems to be 4 GB. Is this correct, and
> in that case, are there any plans of expanding this?
>
platform. It has an uncertified limit of 4GB on Windows NT/2000 because
of a technical oversite on our part. Based on my research there should
be no problem supporting a 4GB file but it has not gone thru testing or
certification cycles.
Some people have reported no problem using 4GB files while a few claim
to have correlated database corruption with a 4GB file. My opinion is
that those corruptions were unrelated to the database file size.
A single InterBase DATABASE can consist of multiple database FILES.
Theoretically, you can have 64K files, each file being 4GB but the real
database size is limited by the logical linear page space. Since an
internal page number is 32-bits (signed) and the current largest page
size is 8KB, the actual theoretical database limit is 8KB*2G pages or
about 1.6 terabytes.
As the database starts to grow to 100's of GB, it just isn't practical
(but it is possible) from a managebility angle to have it mapped to
hundreds of files. For example, a database file with 1,000 files would
require 1,000 file handles in Superserver (2,000 if the database is
shadowed). In Classic, 100 clients would open 100,000 file handles
(200,000 if shadowed) collectively.
The above is impractical and there will be a future project to support
64-bit file pointers. I consider this project orthogonal to the question
of automatice database file extension. One doesn't obviate the other.
> How big is the db-engine when loaded? In other words, how much L2-As Ann responded, the allocated data structures are of primary
> cache do I need to put the db-engine there?
>
importance. The code probably follows the 20/80 rule which says that 20%
of the code is executed 80% of the time. So it depends if the L2-cache
is integrated (code/data) or if there are separate caches for each.
Either way, your money would be better spent on fast disks.
Regards,
Charlie
> Are there any good benchmarchs between ib, ms-sql, sybase?Yes. A prototype of your application. A pat answer to your question but
>
probably true.
Regards,
Charlie