Do you have any DB connections (in actual fact transactions), that are open
for a long period of time.

Regular sweeps and regular viewing of stats to ensure the DB is self
cleaning. If you are putting very large images into a table I would be
prone to putting the Transaction number in an audit row and image row and
see how many deleted records are unable to be cleaned from the database due
to unswept data. The most common reason for this is an app (like a monitor
app) that has crashed (and not rebooted) or has a long standing transaction
still open.

Garbled I know, but there is no reason for not using FB for images, movies,
but you have to be a little careful if you churn (add and delete) the
contents of the DB continuously as non-garbage collected, deleted rows do
not release space in the DB.

JAC.


""Fabrice Aeschbacher"" <fabrice.aeschbacher@...> wrote in message
news:b9qenm+id54@......

> Hi,
>
> Firebird version: LI-V6.2.908 Firebird 1.0 (classic-64)
> OS: Linux/debian kernel 2.4.20
> Filesystem: XFS
>
> I am storing video in a database and having some trouble with very
> large db files.
> Here is my db file:
>
> # ls -l /database/
> total 8470252
> -rw-r--r-- 1 firebird firebird 9492928000 May 13 11:25 video.gdb
>
> - I cannot backup a database: gbak ends with the following error
> message: File size limit exceeded
>
> - gstat simply don't work and says: "File too large"
>
> - The effective video data stored in the db is 4,4Gb. New data records
> are continually inserted, old data records continually deleted, so
> this size does not grow. However, the size of the database is allways
> growing. Why? (each video record is a blob subtype 0 containing 10Mb
> of the video bitstream; I could easily change this value if needed).
>
> All the rest works great, I am recording 6 cameras since a week, being
> able to replay each video sequence. However, if the db is growing so
> much over the real video size, then FB is not appropriate for our
> needs, OR I'll have to store the video slices outside the DB (into
> files), which I would not prefer.
>
> Any hint on this could help.
>
> Best regards,
> Fabrice Aeschbacher
>
>
>
> 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/
>
>