Hi,
> >Many Thanks. > >Jerry Apfelbaum > >Toronto > > Jerry, > Interbase/Firebird looks good on paper. But there are a couple of > things to watch out for. > > 1) Check the Borland Interbase newsgroups for "corruption" to see if it is > 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 is > 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, but > IB/FB has a habit of slowing down as more rows are added/deleted.
Really? Howcome there are many people using Firebird without speed problems?
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.
>They have > an automated Sweep process that cleans out the updated/deleted rows > (deleted & updated rows still take up space until the database is swept). > Even so a large db will still slow down. I suspect the problem is due to > unbalanced indexes. The only way to fix it is to unload all your data and > 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. If 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 unloaded 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.
> 3) The server CPU load will increase rapidly after the first 5 or 6 users. > In other words IB/FB requires a much faster CPU than the same number of > 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 faster.
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.
>There was an earlier > problem with IB Super Server not running well on multiple processors (it > actually slowed things down). I believe this has been fixed in IB version > 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 not.
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 block other threads if they referenced the same table(s). 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).
IB requires a lot more work in tweaking than say MySQL because it is a much 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.
Mike
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
