Subject | Re: [ib-support] Max. DatabaseSize 64-Bit I/O |
---|---|
Author | Jason Chapman (JAC2) |
Post date | 2003-01-22T21:07:39Z |
We were putting scanned documents into the database. Basically we had a
holding database where every document would be registered and the image
stored temporarily. When these documents became readonly (the image never
changed, but index info did), they were moved to a read only database (the
image was moved, the index info was duplicated). The buffer database was
110GB pre spaced to stop fragmentation, the read only databases were allowed
to get to 20GB before moving onto another database. The projection was 5 GB
per week 64bit IO was going to make things a lot easier by negating the need
for secondary files.
After the servers got to 180GB of concurrently open DB it would hang (slow
to an almost hang).
In conclusion I think that it is reasonable to have > 100GB databases for
price data / statistical data / doc imaging etc.
JAC.
"Lester Caine" <lester@...> wrote in message
news:3E2D18DB.5010208@......
holding database where every document would be registered and the image
stored temporarily. When these documents became readonly (the image never
changed, but index info did), they were moved to a read only database (the
image was moved, the index info was duplicated). The buffer database was
110GB pre spaced to stop fragmentation, the read only databases were allowed
to get to 20GB before moving onto another database. The projection was 5 GB
per week 64bit IO was going to make things a lot easier by negating the need
for secondary files.
After the servers got to 180GB of concurrently open DB it would hang (slow
to an almost hang).
In conclusion I think that it is reasonable to have > 100GB databases for
price data / statistical data / doc imaging etc.
JAC.
"Lester Caine" <lester@...> wrote in message
news:3E2D18DB.5010208@......
> > Three years (and two days) ago Bill Karwin wrote "InterBase'stheoretical
> > maximum is 32TB I believe." I don't know whether that has been increasedSo
> > since, but I would be very surprised if Firebird had reduced that size.
> > yes, in theory you can have more than 980GB in a database. Though Ihaven't
> > heard of anyone who has actually tried it...
>
> As an aside - why would someone want so much information
> locked in the one file.
>
> Yes Firebird ( and others ) can handle that ammount of data,
> but should we not be looking at improvements to Firebird
> that help to reduce the size of a single file ( or file
> set), and as a result simplyify the backup problem. Perhaps
> flat databases did have some advantages. One of the things I
> do is - in essence - but the blob information in external
> files. Then only the opdated files need backing up.
>
> This is probably a thought for the developers list, but the
> idea of managing 32Tb of data sent a shiver...
>
> --
> Lester Caine
> -----------------------------
> L.S.Caine Electronic Services
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>