Subject | Re: [ib-support] Why gbak hangs without G option ? (back to old problem) |
---|---|
Author | Ann W. Harrison |
Post date | 2002-09-03T15:22:23Z |
At 10:30 PM 9/1/2002 +0200, =?iso-8859-2?Q?Bogus=B3aw_Brandys?= wrote:
got a dead record version and an index with lots of duplicates. Dead
record versions are created by updates, deletions, and transactions
that roll back.
values. I'd drop that index and all should be well again. If you
don't have an index, write back - there may be a bug. As far as I
know, multi-gigabyte databases containing primarily duplicate values
are rare and you may have found some problem.
easy to diagnose (e.g. duplicates in a unique field) unless you actually
build a database.
contain images).
2) Gbak is probably faster and the output is smaller.
zip use more sophisticated compression and get a lot more space out.
Regards,
Ann
www.ibphoenix.com
We have answers.
> > I have big database (over 2GB) with only one simple tableThe G option controls garbage collection, so my guess is that you've
> > ... Firebird 1.0 server WI-V6.2.794 version of gbak. Database is OK
> > verified with gfix -validate.... populated with almost the same data
> > in each record (about 20 records are different)
> > ... backup this database without G option hangs gbak about 800000
> > row and server memory usage grows to 125 MB.
> > but when using [the G option] all works fine.
got a dead record version and an index with lots of duplicates. Dead
record versions are created by updates, deletions, and transactions
that roll back.
> > 1 . Can this happen in good performed production database just becouse isNo.
> > huge ?
> > 2 . Is it a bug or just becouse database is bad constructed ?Unless I miss my guess, you've an index with several million duplicate
values. I'd drop that index and all should be well again. If you
don't have an index, write back - there may be a bug. As far as I
know, multi-gigabyte databases containing primarily duplicate values
are rare and you may have found some problem.
> > 3. How reliable gbak is ?Generally, it is very reliable.
> > Is there a procedure to test if backup is reliable ,No, unfortunately, there isn't. Some problems with backups really aren't
> > some of course different that just restore (this is too time consuming)
easy to diagnose (e.g. duplicates in a unique field) unless you actually
build a database.
> > 4.Which are the advantages gbak has over simple SQL copy data and metadata1) A copy to text works badly with binary data (e.g. blobs that
>?
contain images).
2) Gbak is probably faster and the output is smaller.
> > 5 .And the last (a little off topic) question about gbak : why backup isThe data portion of records is compressed in a very simple way - tar and
> > named
> > "compressed" ? I don't see any compression in backup files ,I can even
> > compress them with rar or zip to very small sizes
zip use more sophisticated compression and get a lot more space out.
Regards,
Ann
www.ibphoenix.com
We have answers.