@yahoogroups.com]
Sent: 31 October 2015 17:58
To: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] High CPU use after restore
Hi
First of all thanks for help on the way. After a lot of work (and waiting for
restore,backups indexing...) I found out that it actually was as
Hi
First of all thanks for help on the way. After a lot of work (and waiting
for restore,backups indexing...) I found out that it actually was as simple
as an index that was inactive. The index must have been disabled during my
first backup/restore as I am sure I did not do this myself.
The index
Hi again
The comment about "at least rebuild indexes" does that mean that I can
expect this to work or do I risk that I still need to backup/restore?
Best regards
jardar
On Thu, Oct 29, 2015 at 9:52 AM, Mark Rotteveel m...@lawinegevaar.nl
[firebird-support] wrote:
>
>
> On Thu, 29 Oct 2015 07
On Thu, 29 Oct 2015 07:43:29 +0100, "Jardar Maatje
jardar.maa...@nds.nortek.no [firebird-support]"
wrote:
> Hi again,
>
> Sounds like a reasonable cause for the problem. So now is my question,
what
> is the best way to upgrade.
> My current setup is as follows:
> I have two databases, one for raw
On Wed, 28 Oct 2015 23:59:59 +0100, "setysvar setys...@gmail.com
[firebird-support]" wrote:
> http://tracker.firebirdsql.org/browse/CORE-4601 is a report of a 60-time
> improvement (from half a minute to half a second) with Firebird
> 2.5.2/2.5.3 and Jaybird 2.2.5/2.1.6 when changing from blob t
Hi again,
Sounds like a reasonable cause for the problem. So now is my question, what
is the best way to upgrade.
My current setup is as follows:
I have two databases, one for raw data (RAW), and the second one for
decoded data (MAIN). I need to keep the RAW db with as high availability as
possibl
Den 28.10.2015 20:56, skrev Jardar Maatje jardar.maa...@nds.nortek.no
[firebird-support]:
Hi again
A bit more details. I found the query the slows this down and it is a
query that includes blob data. If I adjust the query to cast the blob
to varchar first the query executes 30 timers faster.
Hi again
A bit more details. I found the query the slows this down and it is a query
that includes blob data. If I adjust the query to cast the blob to varchar
first the query executes 30 timers faster. I will try to change my queries
to fix this.
However I still wonder why this suddenly became a
Hi again
Thanks for the feedback. I will try and investigate further based on your
feedback. So far I have updated the index statistics and the seems to make
minor improvements. I thought the indexes was recreated (and thus the
statistics) when it was restored.
Regarding the .GDB i doubt this as
Hei Jardar, I have never even heard of Nortek before!
>We have DB of about 40GB where transaction counter exceeded max and we
had to backup and restore to get the db back up an running.
>However after doing this we have had trouble where the DB consumes 25%
CPU (100% on one core). This typical
Hi
We have DB of about 40GB where transaction counter exceeded max and we had
to backup and restore to get the db back up an running. However after doing
this we have had trouble where the DB consumes 25% CPU (100% on one core).
This typically happens when accessing the DB from IIS web pages with
13 matches
Mail list logo
