> > > Jerry,
> > > Interbase/Firebird looks good on paper. But there are a
> > > things to watch out for.
> > >
> > > 1) Check the Borland Interbase newsgroups for "corruption" to see if
> > > still an issue. I know from reading their newsgroups a few years back
> > > there were quite a few postings. It could of been due to inadequate
> > > hardware or some external source like a misconfigured server or power
> > > failure. There are many sites that use IB without such problems but it
> > > worth checking it out (especially how to successfully repair a damaged
> > > IB/FB database because all the tables are stored in one file).
> >Most of these problems have been fixed in Firebird.
> > > 2) Speed problems. I don't know how much data your tables will have,
> > > IB/FB has a habit of slowing down as more rows are added/deleted.
> >Really? Howcome there are many people using Firebird without speed
> It depends on the size of the tables. WIth 50k rows you're not going to
> notice it. With 50 million rows the slow down becomes apparent.
Then what are you doing? Summing all rows? Counting them? (Cause
a "count" is slow in InterBase/Firebird). Indexed searches etc should
be nearly as fast as with 50K rows.
> > >They have
> > > an automated Sweep process that cleans out the updated/deleted rows
> > > (deleted & updated rows still take up space until the database is
> > > Even so a large db will still slow down. I suspect the problem is due
> > > unbalanced indexes. The only way to fix it is to unload all your data
> > > reload it back in. Some people do it once a week.
> >That's not true. The sweep process doesn't kick in until there's actually
> >a problem with long running transactions and new transactions.
> Updated and deleted rows will remain in the table until a sweep is done.
> 100,000 rows are updated, then the old rows will remain in the table and
> the sweep cleans them out. A heavily updated table will need to be swept
> often. When sweeps fail to speed up the table, the data has to be
> and reloaded. That's not something you want to do very often if you want
> to have a 24/7 installation especially with millions of rows.
There are plenty of systems running or almost running 24/7 without
an unload/reload. The sweep process is different from the "garbage
collection" process, which is what you are describing. Perhaps that's
where I got confused when you started about sweeping. The GC
process has been improved in the recent years in Firebrid and in IB 7
as well. Also, you cannot sweep a table: if you want to sweep, you
will sweep the entire database.
> > > 3) The server CPU load will increase rapidly after the first 5 or 6
> > > In other words IB/FB requires a much faster CPU than the same number
> > > users for MySQL. It is a very CPU intensive DB server.
> >Most CPU problems are related to the above mentioned problems.
> >This isn't usually the case. IB/Fb is actually more of a disk-intensive
> >database engine, because of the ability to use very little memory.
> >However, Firebird has some new stuff (and IB does too) that allows
> >it to use more memory when available (and allowed) making it even
> IB eats up a lot of memory on large queries, something that should be
> avoided if at all possible. All queries are fetched into memory, and when
> physical memory is exhausted, IB will use the page file (in Windows) and
> swaps the physical memory out to disk. This can be *very* disk intensive.
> I've had IB 6 leave as little as 5MB of physical memory and Windows was
> pretty much dead in the water until the query was closed. (Large queries
> are necessary for report or when summarizing data.) If this has been
> improved in the latest IB/FB version, then this memory problem should be a
> non-issue. The more memory you can throw at IB, the better.
I'm surprised here. Actually, the much heard complaint about IB/Fb is that
it takes _too little_ memory and starts swapping to disk too soon. If you're
having IB eating memory, you have a different problem.
> > >There was an earlier
> > > problem with IB Super Server not running well on multiple processors
> > > actually slowed things down). I believe this has been fixed in IB
> > > 6.5. I don't know if this was fixed in FB because FB may be running IB
> > > Classic (single processor) version.
> >"Classic" is not the "single processor" version, it runs much better
> >on multiple CPUs than the "SuperServer" architecture.
> >SS still has these problems on multiple CPU machines, Classic does
> I was under the impression that Classic version could have only 1 thread
> running at one time (each connection is a separate process), it would
> other threads if they referenced the same table(s).
There's no blocking in IB/Fb. Never. Except for a transaction lock (writers
blocking other writers). In "heavy" systems, people prefer the Classic
architecture because it runs better and you can throw in additional CPUs.
> The SuperServer was was
> suppose to solve that with a separate thread for each connection, but had
> some speed issues on SMP machines (ran slower).
Yes, with SMP machines, you need to pin down the SS architecture
to a single processor, it won't work well on multiple CPUs. Firebird
still suffers from this, InterBase 7 has been improved to use multiple
> IB requires a lot more work in tweaking than say MySQL because it is a
> more sophisticated database. Properly configured it can work well, but is
> a higher maintenance database than MySQL and requires more memory and CPU.
> If the programmer needs all those bells and whistles, then IB may be the
> solution they're looking for.
I disagree here. There's not a whole lot you can tweak with IB. Ever
looked at the available configuration parameters?
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL