Em 1/5/2012 14:51, Fabricio Araujo escreveu:
Remember Alexandre, GBAK (and Services API) are a DataPump-style backup,
diffent of NBAK (which AFAIR restores database pages instead of loginal
structure)
which makes me think: you tried that restore on a heavily fragmented
storage?
Since GBAK
Hi Roberto,
Em 19/4/2012 08:52, Tupy... nambá escreveu:
Alexandre,
At my point of view, I prefer avoid using BLOB fields. First of all, because
these kind of field are not indicated for searches of any kind (most of them
are pictures). Second,
because
normally they have very large
to agree.
Friendly, best regards,Roberto Camargo.
--- On Thu, 4/19/12, Alexandre Benson Smith ibl...@thorsoftware.com.br wrote:
From: Alexandre Benson Smith ibl...@thorsoftware.com.br
Subject: Re: [firebird-support] why Blob is so slow ?
To: firebird-support@yahoogroups.com
Date: Thursday, April 19
Em 19/4/2012 12:13, Tupy... nambá escreveu:
Hi, Alexandre,
For the sample you gave (NFE), I agree with you, because the amount of files
that will be generated will be very great and each file itself is not so big,
probably they will not become a problem. And, in this case, they are part of
Em 19/4/2012 12:28, Carlos H. Cantu escreveu:
Sorry but the discussion is going off-topic for the original
question, that is: why backup/restore of blobs are so much slower
compared to non-blobs data. I'm also curious about this.
Carlos
Firebird Performance in Detail -
MSSQL has two commands of the DBCC that allow to do defragmentation. The
defragmentation is not a garbage collection, but putting all parts of an object
(file or columns, hanging of the level - disc or DB) side by side, in a way
that the reading of data will be almost fast, because all data
On Thu, Apr 19, 2012 at 11:13 AM, Tupy... nambá anhangu...@yahoo.comwrote:
But, having many NFE (as many as the transactions), don´t you agree that
these BLOB´s will be a great source of fragmentation inside the DB ?
Err, no. It's not. I'm not 100% sure what you mean by fragmentation, but
Em 19/4/2012 13:18, Tupy... nambá escreveu:
MSSQL has two commands of the DBCC that allow to do defragmentation. The
defragmentation is not a garbage collection, but putting all parts of an
object (file or columns, hanging of the level - disc or DB) side by side, in
a way that the reading
On 19-4-2012 18:34, Tupy... nambá wrote:
Still something = doesn´t matter if you have the blob field in a separated
table. Since they are all together in a same DB file, they may cause
defragmentation, no one can ensure where at the DB file they will be written
and probably will be written
Alexandre Benson Smith wrote:
In this moment I am doing tests with Carlos Cantu and Dmitry Kuzmenko,
and the culprit so far is my machine, on their machine (both !) the
restore took 3s in mine 10 minutes !
I am testing on ext3 and ext4 partitions and I will make more tests on
another
Em 19/4/2012 16:28, Carlos H. Cantu escreveu:
LC It is a little amazing at time when some things work fast on one machine
and a
LC lot slower on another, but the sort of problem you are seeing I would
check that
LC there is not a problem with the hard disc. I've seen that sort of
Hello, Alexandre!
Thursday, April 19, 2012, 2:12:02 AM, you wrote:
ABS # time /opt/firebird/bin/gbak blob_test.fdb blob_test.fbk -user sysdba
ABS -password masterkey -t
stop using -t option, it's already by default :-)
ABS real10m8.894s
10 minutes to restore ~300mb database? incredible,
12 matches
Mail list logo
