Subject Re: Update: CPU Pegged on Firebird v2
Author slalom91
Thanks for the response, but I have tested all of the code as well,
sometimes the statement that is hanging finishes sub-second, others
it just sits and waits, waits, waits. It is definitely a deadlock
issue where the server is not reporting correctly, and the client is
not giving up.

--- In, Svein Erling Tysvaer
<svein.erling.tysvaer@...> wrote:
> Couldn't it simply be that the optimizer chose a different plan for
> query that you run frequently? There's been lots of changes in the
> optimizer and generally it should behave better than 1.5, but it
> difficult to find messages in this list about the optimizer
choosing a
> worse plan with 2.0 than with 1.5. If you generally have small
> with a few records and your DML is simple, then this cannot be the
> but I cannot remember to have read anything about what you actually
> that make Firebird 'max out', nor anything about what is used with
> database (events, UDFs, recursive procedures, external tables
> With tables of, say, 1 million records each, and a few joins, it
> too difficult to write a select statement that takes days to
finish. It
> will be a lot more difficult to write a statement that finishes in
> seconds on Firebird 1.5 and needs hours on Firebird 2.0, but it
> unthinkable.
> Set
> slalom91 wrote:
> > I previously posted a message indicating my v2 Firebird
> > had maxed out my CPU on Windows DB Server. To which, Helen
> > and indicated she thought it may be a version issue with a mix of
> > and 2.0. After giving this a shot (uninstalling 1.5, deleting
> > install folder, and installing 2.0) I still ran in to the same
> >
> > My next step was to move from a remote protocol to a local
> > by moving the database to the same server where the application
> > are accessing the database reside. Still no luck. By the way,
> > both these instances, local and remote, the OS was XP Pro.
> >
> > My next try was to move the database back to the remote protocol
> > again and move to a different OS. I had a Windows 2003 machine
> > I could use temporarily, so I gave this a try. Still same issue.
> >
> > Finally, I decided it must have something to do with record
> > etc. as my environment has several simulataneous users and is
also a
> > multi-threaded environment. I submitted another post asking for
> > suggestions on transaction parameters to which Ann replied and
> > suggested that I use just concurrency and take the defaults for
> > rest. Still no luck.
> >
> > My final effort was to revert back to 1.5.3 by using the 1.5.3
> > gbak.exe on a v2 installation. I was able to successfully get
> > to 1.5.3. Additionally, the DB server no longer locked up (Max
> > but I did begin receiving some of the following errors from my
> > applications: "deadlock update conflicts with concurrent update."
> >
> > I was not previously receiving these errors from my 1.5.3 server
> > before, but I also had different transaction parameters. One of
> > which was "wait."
> >
> > I have to assume after all of this the following:
> > 1. The default on 1.5.3 is "no wait."
> > 2. v2 has a bug in reporting deadlock conflicts which causes the
> > to max out on Windows platforms. I have no way of testing this
> > linux, sorry.