Subject Re: [firebird-support] Re: Firebird 1.0.3, How to drop file from multifile database?
Author Helen Borrie
At 06:14 PM 16/10/2003 +0000, you wrote:
>Helen,
> I ran the backup and it hickup'd again.
>Yesterday I created a multifile database, 41 files each file
>containing 40000 pages, each page 16K, use all space.

>I noticed that the last page was almost to 640MB

What do you mean by this? The last *file*?

>so I made 10 more files this am
>through IB_SQL.exe using ALTER DATABASE AD FILE '.....42.gdb' LENGTH
>40000;

What are you trying to achieve? Why are you setting up such small
files? Even Windows 98 can take a 2Gb file.

Let's say your database is 27 Gb and growing. Let's be conservative and
say that the server is running on NT4, NTFS. Max file size is 4 Gb. So,
to accommodate your current db, you need 7 files + maybe one more if growth
is really fast or if your normal state of things is to be retaining a lot
of garbage.


>and then noticing that my backup last night didn't go off, I
>ran the backup which erased my good backup.

Did you intend for one backup to overwrite another? (still scratching head...)

> I was wondering if I could tell the database to drop the files I
>added, since I haven't added anything new to the database and get on
>with things?

Only by backing up with gbak and then recreating without specifying
multiple files.

Notice I said "recreating" - use the -C[reate] switch and restore using a
different name. Don't use the -R[eplace] switch - that replaces the
database.

Why are you doing this? I hope it's not live data you are messing
with. You seem to be playing with fire here.

I don't think you understood my first posting, which makes me suspect you
don't understand what gbak does. I think that the error you got was
because you were trying to run gbak on a secondary file. Gbak was looking
for page 0 (the header page for the whole database), which it will find in
the PRIMARY file. The error told you "expecting page 0, found 640001" -
meaning that was the first page it found - hence the conclusion that you
asked it to gbak a secondary file.

Gbak isn't a filecopy program. It dissects the entire database, first
saving the metadata and then saving all the data as compressed streams of
text. It doesn't save the indexes. Only the server can find all the data
in the database, which are located by searching inventory pages. The map
to all of the inventory pages is in the primary file. All of the secondary
files must be in their proper locations, iow, wherever the create or alter
database statement told them to be - with full path specs for each file.

When you [re]C[reate] the database, gbak builds the whole database from
scratch and builds new indexes. Unless you specified the -g switch in the
backup, the new database is garbage-free. If you had a lot of garbage, the
new database will therefore be significantly smaller than the old one.

Hmm, nuff said for now. I might be totally misunderstanding what you're
doing here.

heLen