>>Text, binary, it's all the same to gbak. Try the -g suggestion - if gbak is >>cleaning out garbage, it's slow. > >But, surely, the garbage has to be cleaned out sooner or later, and doing it >in a backup run is the cheapest way to do it, >as every record is being visited anyway? (Compared to, say, doing a COUNT(*) >to clean garbage, which will visit records it >doesn't need to, or, worst of all, letting the cost land at random on >whichever poor sod next does a query on the table >with the garbage.)
Hi Tim! The original question was: >Why does it takes so much time to backup / restore (gbak) this table ? >(because the BLOB field). >Do I have any options to speed up the process ? If the original database should not be replaced by the restored version, then it is of course sensible to clear garbage. However, I suggested trying this switch since this could be an alternative way to discover whether the problem was (mainly) related to poor transaction handling and not the blob itself. I'm actually surprised that Tiberiu notices a problem at all, a table containing 3000 rows and blobs of up to 400 characters should be peanuts for Firebird. Set
