Subject | Re: What do I need to do to keep my DB good and running smoothly |
---|---|
Author | beeps |
Post date | 2002-09-27T02:41:35Z |
Dear Fingerman,
Im a Newbie with Firebird, and very much lots of reading & learning
to be done, just like to asked if it is okei to run Firebird (im
using FirebirdCS-0.9-4p1) running under Mandrake 8.2 and with a dual
P-III Processors.
Here is my Pc status.
CPU0 states: 0.1% user, 0.0% system, 0.0% nice, 99.1% idle
CPU1 states: 0.0% user, 0.0% system, 0.0% nice, 100.0% idle
Mem: 1029660K av, 1016188K used, 13472K free, 0K shrd,
5708K buff
Swap: 409576K av, 0K used, 409576K free
897772K cached
I hope anyone could find time to answer my inquiry.
Thank you very much!
Regards,
beeps-
Im a Newbie with Firebird, and very much lots of reading & learning
to be done, just like to asked if it is okei to run Firebird (im
using FirebirdCS-0.9-4p1) running under Mandrake 8.2 and with a dual
P-III Processors.
Here is my Pc status.
CPU0 states: 0.1% user, 0.0% system, 0.0% nice, 99.1% idle
CPU1 states: 0.0% user, 0.0% system, 0.0% nice, 100.0% idle
Mem: 1029660K av, 1016188K used, 13472K free, 0K shrd,
5708K buff
Swap: 409576K av, 0K used, 409576K free
897772K cached
I hope anyone could find time to answer my inquiry.
Thank you very much!
Regards,
beeps-
--- In ib-support@y..., Frank Ingermann <frank@f...> wrote:
> Hi Set/Jason,
>
> Svein Erling Tysvaer wrote:
> > Hi Jason!
> >
> > At 07:47 02.09.2002 +0200, you wrote:
> >
> >>I am new to Firebird and I just wanted to know, what do I have to
do to keep
> >>my database running fast and smoothly.
> >
> >
> > This isn't all too difficult, unless you are dealing with huge
tables and
> > demanding users who expect their queries to work instantly
without any
> > tuning. Just make sure that no transactions are running for too
long (watch
> > the gap between the oldest active transaction and the next
transaction) and
> > examine the plan of your queries before you actually execute
them. I'm not
> > certain if it is still an issue, but formerly it was necessary to
make sure
> > IB just ran on one processor if run on a Windows machine with
several
> > processors (there was some utility called IB_Affinity available
to help
> > you).
>
> no, this is no longer an issue in FB1 - one multi-cpu systems, you
can set a
> bit mask in the ibconfig file. quote from the UsingFirebird.pdf
found on the
> IBPhoenix CD:
>
> <quote>
> cpu_affinity
> With Firebird SuperServer on Windows, there is a problem with
Windows
> continually swapping the server
> process back and forth between processors on SMP machines. This
ruins
> performance. Until now, to set
> ibserver's affinity to a single CPU, it was necessary to run the
server as an
> application and to run a utility
> (IB_Affinity.exe) on top of the running server program.
>
> This new configuration parameter can be added to ibconfig to remove
the need for
> any external program to
> change CPU affinity on an SMP Windows system.
>
> CPU_AFFINITY takes one integer, the CPU mask.
>
> Example:
> CPU_AFFINITY 1
> only runs on the first CPU (CPU 0).
> CPU_AFFINITY 2
> only runs on the second CPU (CPU 1).
> CPU_AFFINITY 3
> runs on both first and second CPU.
>
> This setting will take effect when the service starts up.
> This parameter has no effect in Windows9x or ME, as it uses an NT
API call. W9x
> flavors DO NOT
> take advantage of multiple processors.
>
> </quote>
>
> > Then of course, you should make sure that you have
defined "sensible"
> > indexes, where "sensible" is a word open for discussions. And if
you come
> > from the world of desktop databases, forget the word "table" and
start
> > thinking datasets and client/server when writing programs.
> >
> > Welcome to us all!
> > Set
>
> a few more hints here:
> - if you're running FB on WinME or WinXP, better name your .gdb's
as .fdb
> (look at http://www.fingerman.de/fbshellext.htm under "Windows
ME/XP warning"
> for more details)
>
> - make sure no process (i.e. OS Backup Software) tries to copy your
GDB/FDB file
> while users are connected. this can corrupt your database.
>
> - from time to time it is a good idea to backup the db and restore
it *to a
> different location*. this is just to make sure the backup/restore
really works
> (it always did for me). As the restored db is written from scratch,
it is
> usually smaller than the original and "fragmentation" in the db is
cleaned up
> which should increase performance. So when you find the restored db
ok, you can
> copy it to the original location (shutdown the original db before
this).
>
> - relax :-) FB is the most stable database i've ever worked with -
if you follow
> the very few rules above, you shouldn't have any trouble.
>
> regards & welcome Jason!,
> fingerman
>
> --
> --------------------------------------------------------------------
-----
> when parsers parse, and compilers compile, then why don't objects
object?
>
> fingerbirdy - fingerman's door to Firebird
> http://www.fingerbird.de