Thomas,
> While the restore process is pretty much I/O bound,
While that is true for desktop PCs with HDDs (not SSDs) or server without a
cached RAID controllers, but it is certainly not true as a blanket statement.
There is plenty of room for more throughput.
> Another option might be to res
03.01.2012 20:37, Leyne, Sean wrote:
> As for the FKs, I see the tool as being a some which needs to have the
> maximum performance.
If you are going to move whole database at once - yes. Fortunately, in most
cases it is
not necessary.
--
SY, SD.
---
>>> The problem is not downtime is how much downtime. Backup and restore is
>>> so much downtime.
>>
>> There are a couple of possible solutions which would reduce the downtime;
>> - a new backup/restore tool which would use multiple readers/writers to
>> minimize execution time,
>
> Here we're ta
> 03.01.2012 18:51, Leyne, Sean wrote:
> > - a "data port" utility which would allow for data to be ported from a live
> database to a new database while live is active but would need a finalization
> step where the live database is shutdown to apply the final data changes and
> add FK constraint
Ann,
> > - a new backup/restore tool which would use multiple readers/writers
> > to minimize execution time,
>
> Here we're talking about a logical backup that can be used to restart
> transaction numbers. Record numbers are based loosely on record storage
> location. Since a logical backup/re
Sean,
>
>> The problem is not downtime is how much downtime. Backup and restore is
>> so much downtime.
>
> There are a couple of possible solutions which would reduce the downtime;
> - a new backup/restore tool which would use multiple readers/writers to
> minimize execution time,
Here we're tal
Jesus
> > Single server without downtime is a myth anyway.
> The problem is not downtime is how much downtime. Backup and restore is
> so much downtime.
If that is the case, how much downtime is acceptable?
There are a couple of possible solutions which would reduce the downtime;
- a new backu
Dmitry,
> Trunk is the ongoing development branch (formerly known as HEAD in CVS),
> i.e. transaction IDs are already unsigned long in FB 3.0.
Although this would mean a further ODS change as well as an increase in
overhead associated with all rows, perhaps the ODS size should be increased
from
On 12/29/11 22:05, Leyne, Sean wrote:
>> The reason for signed type here was (at least visible reason) very simple
>> - into some functions using same parameter might
>> be passed transaction number (positive value) and something else (negative
>> value). I.e. negative sign meant 'this is not tr
29.12.2011 22:05, Leyne, Sean wrote:
>
>> This change was done in trunk.
>
> To be clear, you have a code-branch that uses ULONG for transaction ID?
Trunk is the ongoing development branch (formerly known as HEAD in CVS),
i.e. transaction IDs are already unsigned long in FB 3.0.
Dmitry
---
> Actually, there is at least one other "special" value for transaction ids.
> Zero is
> always the system transaction.
The "system transaction"
I seem to have forgotten about that item.
> Maybe it's time to look at all the small integers as well.
Agreed.
Mike Nordell and I had tried
Sean,
> Alex wrote:
>> - into some functions using same parameter might
>> be passed transaction number (positive value) and something else (negative
>> value). I.e. negative sign meant 'this is not transaction' and function
>> behaved
>> according to it.
>
> And some people have complained ab
> Heavy loaded systems should use clusters. That's all. While one node is on
> maintenance,
> others do all work. These systems need clusters anyway for high availability
> and/or load
> balancing. One can't be serious running critical systems on a single server.
>
I don't agree with you. Y
29.12.2011 20:41, Jesus Garcia wrote:
> Would not be better, instead of that, If transaction id is equal To 0, no
> transaction, else transaction.
There is transaction number zero.
> As now there is a problem with transactionid and heavy loaded systems, that
> could solve in a little the pro
> This change was done in trunk. The reason for signed type here was (at
> least visible reason) very simple - into some functions using same
> parameter might be passed transaction number (positive value) and
> something else (negative value). I.e. negative sign meant 'this is not
> transaction'
Alex,
> > The "simple" solution is to change the datatype of Transaction related
> variables from SLONG* to ULONG. The reality of this solution is,
> unfortunately, far uglier given the testing required to confirm that all
> references have been changed.
> >
> >
> > Sean
> >
> >
> > * for the life
On 12/28/11 22:51, Leyne, Sean wrote:
>> It is feasible to roll over the transaction ID without putting the database
>> offline? i.e. when ID is close to limit, reset it to 0 from the code?
> In theory there is a "simple" code change which would provide you another 6
> months breathing room.
>
>
> It is feasible to roll over the transaction ID without putting the database
> offline? i.e. when ID is close to limit, reset it to 0 from the code?
In theory there is a "simple" code change which would provide you another 6
months breathing room.
But there is no permanent solution which is cu
Dimitry,
> 27.12.2011 19:17, Leyne, Sean wrote:
> > That type of solution is not what I would define as a cluster.
>
>As you wish. But the rest of world consider this kind of system to be
> called
> "a shared-nothing cluster".
You are correct! "a shared-nothing cluster" is a type of cluste
Dimitry,
> 25.12.2011 1:00, Leyne, Sean wrote:
> > A cluster won't help, since all databases would see the same number of
> transactions, the number of which is the problem.
>
>No, if several transactions during transfer between nodes are merged into
> one.
>Besides, there is no need for
25.12.2011 1:00, Leyne, Sean wrote:
> A cluster won't help, since all databases would see the same number of
> transactions, the number of which is the problem.
No, if several transactions during transfer between nodes are merged into
one.
Besides, there is no need for all nodes to start f
among Firebird Developers
Subject: Re: [Firebird-devel] Firebird Transaction ID limit solution - Email
found in subject
24.12.2011 1:37, Yi Lu wrote:
> 1.I wonder if anyone now has a proper solution to this issue, without
> requireing shutting down the system.
Set up cluster. While one node
22 matches
Mail list logo
