It is a good idea to backup and restore the database to recreate them with the
new OSD.
This will improve performance and MAYBE this can solve your problem.
De: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com]
Enviada em: quarta-feira, 29 de outubro de 2014 11:05
Ann, about the third problem:
“The third problem is two records in a referencing table lack mates in the
referenced table, despite a referential constraint. I have no idea how that
happened, but it should be reasonably easy to fix in your database.
”
I saw this happen two times, it is
You can create a computed index for this:
CREATE INDEX idxname ON mytable COMPUTED BY (lowercase(mymemo))
Hope this help you.
De: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com]
Enviada em: sexta-feira, 5 de setembro de 2014 08:51
Para:
Maybe this can help:
SELECT st.mon$statement_id as Statement ID,
st.mon$attachment_id as Attachment ID,
st.mon$transaction_id Transaction ID,
case
when st.mon$state = 0 then 'IDLE'
when st.mon$state = 1 then 'ACTIVE'
end as State,
FB
De: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com]
Enviada em: segunda-feira, 18 de agosto de 2014 16:47
Para: firebird-support@yahoogroups.com
Assunto: Re: [firebird-support] object is in use
Hello Carlos.
Thanks.
I am using IBExpert to run an
Also, FB 2.5.0 has problems with this. If you use this version upgrade to
2.5.1 or above.
De: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com]
Enviada em: segunda-feira, 18 de agosto de 2014 16:47
Para: firebird-support@yahoogroups.com
Assunto: Re: [firebird-support]
Maybe you dont have a HDD cached controller.
Run a program like Crystal Disk Mark in the old computer and in the new
computer. If the performance of new computer is terrible you must change your
physical hard disk controller.
I had this problem with a Dell server that is a “internet server”
Large gap is not caused by lack of auto sweep. It is bad system design.
As you is not the system programmer, you can shut down all connections to the
database during lunch time, then you can let users enter in your system again.
After shutting down, run a manual sweep (gfix –sweep). If you see
what I'm doing right now. Its the only way to keep them going.
I shut them down at lunch, run a sweep, then when they get back in, things are
much faster.
-Josh
On Tue, May 13, 2014 at 8:35 AM, 'Fabiano - Desenvolvimento SCI'
fabi...@sci10.com.br [firebird-support] firebird-support
Your problem is:
PLAN JOIN (SP NATURAL, A INDEX (ADVOCATE_))
Wish means a full table scan on SUPPROG. It is strange, because you have the
index
USV_SUPPROG_ADVOCATE_CODE ON field ADVOCATE_CODE
Try this:
select * from
(
select a.User_ID
from Advocate
where a.USER_ID=37
) as
Maybe.
Try update all index statistics. MAYBE it helps.
In last case MAYBE a backup/restore can help too… (or drop and recreate those
indexes)
De: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com]
Enviada em: terça-feira, 13 de maio de 2014 17:15
Para:
It is only used in read only databases do decrease de size of a database for
less space purpose.
Do not use this in a production database, the overall performance will drop.
De: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com]
Em nome de jakef...@yahoo.com
Enviada
Try ran Windows 7 memory test (press F8 while booting). If it detects your
memory is corrupted the only thing to do is replace your physical memory.
De: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com]
Em nome de korkl...@yahoo.it
Enviada em: quarta-feira, 12 de
The right thing to do to avoid this kind of corruption is make diary backups
and ensure you can restore them!
If you can't backup or not restore the entire database (including
reactivating all foreign keys) you must stop immediately and try to fix the
database.
I think you ran this database
I belive!
We use 20011.
When we raised to 20011 performance is much better and memory consume is a
little bit more.
I think FB developers must increase a lot the default value, specially with
upcoming FB 2.5.3
De: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com]
Strange thing is min hash length 358 and mutex wait only 0.1%!
De: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com]
Em nome de Alexey Kovyazin
Enviada em: quinta-feira, 20 de fevereiro de 2014 14:02
Para: firebird-support@yahoogroups.com
Assunto: [firebird-support]
How you solved your problem?
De: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] Em nome de Hugo Eyng
Enviada em: terça-feira, 21 de janeiro de 2014 10:24
Para: firebird-support@yahoogroups.com
Assunto: Re: [firebird-support] Very very very slow FB 2.5.2 64bit
OK! We will help!
De: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] Em nome de LtColRDSChauhan
Enviada em: terça-feira, 14 de janeiro de 2014 11:26
Para: firebird-support@yahoogroups.com
Assunto: [firebird-support] Migrate to Firebird 2.5.2 Win 32 from Firebird
3.0
I read somewhere that you must include Threads in your uses clause to
ensure multithread memory allocation!
Google for it (USD, DELPHI, FIREBIRD, THREAD, USES).
MAYBE your random problem is when 2 concurrent users uses your UDF function
and try to allocate/dispose memory.
Sorry my bad
Maybe you are confusing yourself:
The problem now is that Super Server is not usi ng the full (SMP)
processing power of the hardware, than slowing things down
So, we need to get back to Firebird 2.1 Classic but could not figure out
how to do that (tried some options without success).
So, you
Hello Paul, I will take a look in your post latter.
The problem is exactly the same.
I discovered something:
In my case, I ran a command in QUERY A (is an auto generated stupid code):
Select * from my_table
With QUERY A opened, I run my report over the my_table table.
Then, I change my
Embedded is used as a local database for a single system.
IF you can connect more than once you will have a BIG database corruption,
read the embedded documentation.
You must use the regular Firebird installation -
Classic/SuperClassic/Superserver.
You can run an automatic Firebird
Hello folks!
I'm Brazilian so sorry about some mistakes in the text below.
We have a new (~2 years old) system developed using Firebird 2.5.1 Classic.
We use Delphi XE2 + Datasnap with a strict transaction control, only 3 or 4
places on the application server control de entire transaction
Do you use Classic or SuperServer? Version?
How many cached pages? If you use Classic try increasing page buffers to 2000
and try again.
Let me know the results, thanks.
De: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com]
Em nome de chmere...@gmail.com
Enviada
Hi list!
We have a customer with a poor performance today. I take a look and discover
that the HDD is very busy, then I run a fb_lock_print of that database and
it shows:
Mutex wait: 37.6%
Hash slots: 1009, Hash lengths (min/avg/max): 74/ 98/ 128
Terrible
Something weird occuring now:
Exactly now, I have 120 connections to the database. NO ONE is actually
using or using the database for nothing, just connected (0% of use of all 16
processors, no HDD usage
)
So, I get another fb_lock_print and it shows:
Mutex wait: 20.3%
26 matches
Mail list logo