Thank you for the very in-depth run thru.. as you may have noticed im a
complete 'noob' to firebird and any enterprise level databases.





I Was only stating the file extensions due to the previous post on the
list about it to me....

And looking at it it only affects XP with system restore on, where as we
are running win2k3



I did show database, there is only one file.



I do a restore to a secondary db server every few hours, and the sizes
remain the same.

A 3.5GB Backup file is copied over to it, and then restored using GBak,
this comes to a file of 1.5GB for the DB.

I also did a shutdown restart of the secondary server, with no change in
db file size.


I'm currently running a restore to a totally new database to see what
the outcome is.



I tried the multiply page size by number of db pages allocated and got a
figure very similar to the current size shown in explorer







From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Helen Borrie
Sent: 17 July 2008 02:06
To: firebird-support@yahoogroups.com
Subject: [***SPAM*** Score/Req: 5.4/4.0] RE: [firebird-support] GBAK
Backup Size



At 10:17 AM 17/07/2008, you wrote:

>as per my other msg, accounting all other DB files on that server still

is a gig short of the FBU size

>
>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 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.

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



Head and Registered Office:
Call Assist Ltd,
Axis Court, North Station Road,
Colchester, Essex.
CO1 1UX
Telephone +44 (0)1206 771771
Fax +44 (0)1206 364268

Registered in England and Wales.
Registered Company Number 3668383
Authorised and regulated by the Financial Services Authority

Please Note : This electronic message contains information from Call Assist Ltd which may be privileged or confidential.
The information is intended for the use of the individual(s) named above. If you are not the intended recipient be aware
that any disclosure, copying, distribution or use of the contents of this information is prohibited.
If you are not the intended recipient please delete this email. If you have received this electronic
message in error, please notify us by telephone or email immediately.

Please consider the environment before printing this email.


[Non-text portions of this message have been removed]