| Subject | RE: [firebird-support] GBAK Backup Size |
|---|---|
| Author | Helen Borrie |
| Post date | 2008-07-17T01:05:31Z |
At 10:17 AM 17/07/2008, you wrote:
You can use gstat -h or (in isql) SHOW DATABASE to find out whether this is a multi-file database and, if so, what the file names of the secondary files are.
If you can establish categorically that these are single-file DBs then Windows is lying to you about the size of the file. Since Windows doesn't update this report until a read/write file is closed, the reported size could be months out of date. Firebird doesn't close a database file until/unless there are no attachments.
On the issue of unexpected database file growth, a buildup of garbage is the usual cause. One naughty application can cause it, especially on a 24/7 system, so look closely at app code that was changed around the time you first started seeing this unexpected growth. As a reality check, do the full gstat tests to have a look at the state of affairs.
But it's not an absolute that the unusually high file growth would have come about from one careless change in the client application. It's possible that GC-killing techniques are inherent in all of your application code. If you've a long history of believing what Windows tells you about the file size of an open database and you're not in the habit of periodically replacing the database file with a tested restore, it's totally possible you've always had this bloat problem.
You haven't mentioned what you see when you *restore* one of these backups. Find some diskspace somewhere on an NTFS partition and do a -Create_database restore....look at the file size of your database sans garbage; then test whether you can connect to the restored DB.
As a PS, there is no sensible reason to do a non-transportable backup in this day and age. It's so rare for people to do them "in the Firebird era" that I'd venture to express concern that an n-t backup might not even be cross-compatible between different filesystem versions on Windows partitions. Let's say I'd need evidence that it was bomb-proof before I would rely on it....
List protocol: please refrain from top-posting your replies. Trim posts rigorously AND remove your SPAM tags from the Subject. It is not just annoying: it breaks the message threading.
^ heLen
>as per my other msg, accounting all other DB files on that server still is a gig short of the FBU sizeYou have more than one issue here. Listen to Adam and Jason when they state that a backup file shouldn't be larger than the DB file itself. If you can escape from the apparent misconception that file extensions somehow "matter" to Firebird then that puts you into the mindset of searching for secondary database files - since you really are seeing backups that indicate that.
>
>we'd noticed the size increasing over time (as we backup the FBU to a secondary server)
>but never noticed the FDB staying the same size
>
>its the growth tahts got me a bit stumped
>its increased over a GB in 6 months
>
>yet the whole system has been running maybe 3 years
>
>i cant think of anything we've done to suddenly change/increase the amount of data we store on it
>normal business growth doesnt seem to match the rapid incase imo
You can use gstat -h or (in isql) SHOW DATABASE to find out whether this is a multi-file database and, if so, what the file names of the secondary files are.
If you can establish categorically that these are single-file DBs then Windows is lying to you about the size of the file. Since Windows doesn't update this report until a read/write file is closed, the reported size could be months out of date. Firebird doesn't close a database file until/unless there are no attachments.
On the issue of unexpected database file growth, a buildup of garbage is the usual cause. One naughty application can cause it, especially on a 24/7 system, so look closely at app code that was changed around the time you first started seeing this unexpected growth. As a reality check, do the full gstat tests to have a look at the state of affairs.
But it's not an absolute that the unusually high file growth would have come about from one careless change in the client application. It's possible that GC-killing techniques are inherent in all of your application code. If you've a long history of believing what Windows tells you about the file size of an open database and you're not in the habit of periodically replacing the database file with a tested restore, it's totally possible you've always had this bloat problem.
You haven't mentioned what you see when you *restore* one of these backups. Find some diskspace somewhere on an NTFS partition and do a -Create_database restore....look at the file size of your database sans garbage; then test whether you can connect to the restored DB.
As a PS, there is no sensible reason to do a non-transportable backup in this day and age. It's so rare for people to do them "in the Firebird era" that I'd venture to express concern that an n-t backup might not even be cross-compatible between different filesystem versions on Windows partitions. Let's say I'd need evidence that it was bomb-proof before I would rely on it....
List protocol: please refrain from top-posting your replies. Trim posts rigorously AND remove your SPAM tags from the Subject. It is not just annoying: it breaks the message threading.
^ heLen