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 n
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%
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 em
I think you are running at the wrong direction.
Why are you wanting to cache those data? Are your having performance problems?
The only way I know you can do what you want is create a exclusive connection
(By the way: Classic Server) to the FB server and ONLY execute select
statements in those
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 scope
I'm Sorry!
We use a component to do backup, not gbak and I mistake the options when
writing my question.
Actually we make a backup with garbage collect - no -g swith.
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 installat
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 chan
Dont do thing harder than they are.
Just stop Firebird Server, WinRAR/WinZIP the database file into MULTIPLE
PARTS (Google it) and then UNZIP in your pc!
I have a database with 50 Gb of images in the pc client and I want to send
this information to firebird server, but the transmition is taki
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 englis
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
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
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
perform
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] Fo
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]
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 co
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 març
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 e
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 a
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]
wrote:
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 FI
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: firebird-supp
We also shutdown our database using gfix. We never have a database corruption
because this.
BUT we do not kill any fb_inet_server.exe instance. For us, gfix always be
enough to shutdown all active users – even when using IBExpert.
De: firebird-support@yahoogroups.com [mailto:firebird-supp
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” (w
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 'CREATE
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]
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: firebird-support@yahoogro
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 relate
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
Pa
30 matches
Mail list logo
