Menu
▾
▴
firebird-devel
|
From: Jesus G. <je...@gm...> - 2011-12-29 21:15:31
|
> 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. You generalize, and is not allways good. From your POV what is not serious is having an "enterprise database" with that serious and important restriction. I have not readed until your posts that for heavy loaded systems is necessary one cluster of firebird, and what is worse, who don't use them is not serious. Replication is not easy with firebird, and is not native in the engine. There is so many problems with replication depending on the features of firebird used. Is different use firebird for store data in tables than programming business logic in database and use user restrictions, triggers, etc. I do not use any other rdbms, but is there the same problem with postgre, Oracle, sqlserver, informix, db2, etc.? Don't misinterpret my words, i love firebird. Jesus |
|
From: Kjell R. <kje...@da...> - 2012-01-01 10:34:08
|
Den 2011-12-31 15:08 skrev Dmitry Yemanov såhär: > 31.12.2011 17:57, Alexander Peshkov wrote: > >> This will make each version of the record (not the record- but EACH >> version of it) 4 bytes longer. > Not strictly necessary. We could use a variable-length encoding for txn > ids longer than 32 bits and mark such records with a new flag. It would > add zero storage/performance overhead for all the current applications > but allow longer txn ids for the slightly bigger cost. It would increase > the code complexity though. Are there unused flag bits available in the current record format, that could be used for this purpose? Or how are such flag bits encoded? Kjell -- -------------------------------------- Kjell Rilbe DataDIA AB E-post: kj...@da... Telefon: 08-761 06 55 Mobil: 0733-44 24 64 |
|
From: Dmitry Y. <fir...@ya...> - 2012-01-01 11:50:17
|
01.01.2012 14:34, Kjell Rilbe wrote: > Are there unused flag bits available in the current record format, that > could be used for this purpose? Or how are such flag bits encoded? We have 7 or 8 bits (out of 16) currently available. Dmitry |
|
From: Ann H. <aha...@ni...> - 2012-01-03 03:53:35
|
> > 1. hdr_oldest_transaction, hdr)oldest_active, hdr_next_transaction on > header_page structure should be SINT64 on file ods.h. > 2. fld_trans_id should have dtype_int64 and size should be sizeof(SINT64) on Why signed? Ann > |
|
From: Yi Lu <yl...@ra...> - 2012-01-03 15:09:26
|
We have read that negative transaction IDs are used to indicate an invalid transaction. Thus, we have decided to continue with the signed approach to prevent logic problems. -- View this message in context: http://firebird.1100200.n4.nabble.com/Firebird-Transaction-ID-limit-solution-tp4230210p4257208.html Sent from the firebird-devel mailing list archive at Nabble.com. |
|
From: Jesus G. <je...@gm...> - 2012-01-01 12:51:53
|
> > We have 7 or 8 bits (out of 16) currently available. > > > Dmitry Is not better use 64 bits integer?. In the near future computers speed, hdd speeds, etc. will increase, and transaction id of 64 bits overhead will affect less and less to performance. Jesus |
|
From: Dmitry Y. <fir...@ya...> - 2012-01-01 13:06:12
|
01.01.2012 16:48, Jesus Garcia wrote: > > Is not better use 64 bits integer?. In the near future computers speed, hdd speeds, etc. will increase, and transaction id of 64 bits overhead will affect less and less to performance. Disk speed was always the issue, it doesn't increase that fast as CPU/memory speed. So the on-disk size always matters quite a lot. Dmitry |
|
From: Dimitry S. <sd...@ib...> - 2012-01-01 13:10:25
|
01.01.2012 14:06, Dmitry Yemanov wrote: > Disk speed was always the issue, it doesn't increase that fast as > CPU/memory speed. So the on-disk size always matters quite a lot. CPU speed also has stopped growing. -- SY, SD. |
|
From: Jesús G. <je...@gm...> - 2012-01-01 16:31:11
|
> > CPU speed also has stopped growing. > You are right, speed has stopped but performance has increased. Jesus |
|
From: Jesús G. <je...@gm...> - 2012-01-01 17:11:46
|
> > Disk speed was always the issue, it doesn't increase that fast as > CPU/memory speed. So the on-disk size always matters quite a lot. > > > Dmitry I think the question is if it is neccesary and good for Firebird, and if the pros of having transactions id of 64bits are better that the cons of not having it. From my POV using 32 bits id is an important restriction in the engine, and i would prefer not having it. The flag option is good because only the databases that need high transactions numbers pay for their use, but as you wrote, the engine code become more complicated. My customer with highest transactions number would work, by the moment, for 7/8 years without stop, but i would sleep better if i have not to worry about that, and if i have not have to explain that restriction to my customer, what can make think that firebird is not so good as i tell him. Firebird 3 is growing, and now may be the moment to change it. FB 3 will live for years and Systems require more and more. I used Firebird 1 years ago, but now our clients with more work load wouldn't work with that version. Is there any measurement of the real impact of the change? Jesus |
|
From: Adriano d. S. F. <adr...@gm...> - 2012-01-01 17:22:51
|
On 01-01-2012 15:11, Jesús García wrote: > > I think the question is if it is neccesary and good for Firebird, and if the pros of having transactions id of 64bits are better that the cons of not having it. From my POV using 32 bits id is an important restriction in the engine, and i would prefer not having it. > This is the wrong way to deal with the problem IMO. Let something like sweep consolidate old transactions in only one, concurrently with user operations. In that way, there will be in the database header the number of the first transaction. The last possible transaction is (first - 1). When needed, 'first' is increased, so as last. Nobody needs more than 4 billions active transactions concurrently. Adriano |
|
From: james <ja...@ma...> - 2012-01-01 19:49:35
|
>Nobody needs more than 4 billions active transactions concurrently. But that's not what you'll get, because you can complete transactions and get a hol, as it were. Can a process grab a transaction id and hold onto it 'for ever' without messing up the system in other ways that preventing the reclaim of ids? Have to say, I can't see a good reason to use 32 bit ids. While physical disk seek speeds are not increasing, many disks can go rather fast and so long as you don't seek IO of larger amounts of data isn't too costly. I guess the biggest effect is to reduce the effective cache size in caching disk ontrollers. And 'disks' certainly are getting much, much faster as we see SSD takeup. |
|
From: Dimitry S. <sd...@ib...> - 2012-01-01 22:26:44
|
01.01.2012 21:31, Kjell Rilbe wrote: > So far, these are the suggestions I've seen Hey, how about my suggestion leave everything as is and perform backup-restore cycle on demand?.. Pros: - No overhead. - No additional disk space. - No code change. Cons: - DBA with brain is required. -- SY, SD. |
|
From: Kjell R. <kje...@da...> - 2012-01-01 22:43:54
|
Den 2012-01-01 23:25 skrev Dimitry Sibiryakov såhär: > 01.01.2012 21:31, Kjell Rilbe wrote: >> So far, these are the suggestions I've seen > Hey, how about my suggestion leave everything as is and perform backup-restore cycle on > demand?.. > > Pros: > - No overhead. > - No additional disk space. > - No code change. > Cons: > - DBA with brain is required. Yes, of course! But you're forgetting this: Con: - If the no downtime is acceptable, it requires special measures to be able to keep the system running during a backup-restore cycle, e.g. cluster. Personally I don't know much about clustering or FB replication, so I can't really say if this is a big problem or not. But from what I've read in this thread it is not without problems. And I think we can live without the sarcasm inherent in your con. Kjell -- -------------------------------------- Kjell Rilbe DataDIA AB E-post: kj...@da... Telefon: 08-761 06 55 Mobil: 0733-44 24 64 |
|
From: Lester C. <le...@ls...> - 2012-01-01 22:48:09
|
Dimitry Sibiryakov wrote: > 01.01.2012 21:31, Kjell Rilbe wrote: >> > So far, these are the suggestions I've seen > Hey, how about my suggestion leave everything as is and perform backup-restore cycle on > demand?.. > > Pros: > - No overhead. > - No additional disk space. > - No code change. > Cons: > - DBA with brain is required. ... Requires a downtime? Which can be substantial Unless the configuration can be set up to allow updates applied following the backup-restore cycle to be reapplied? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php |
|
From: Kjell R. <kje...@da...> - 2012-01-02 05:14:24
|
Den 2012-01-01 23:47 skrev Lester Caine såhär: > Dimitry Sibiryakov wrote: >> 01.01.2012 21:31, Kjell Rilbe wrote: >>>> So far, these are the suggestions I've seen >> Hey, how about my suggestion leave everything as is and perform backup-restore cycle on >> demand?.. >> >> Pros: >> - No overhead. >> - No additional disk space. >> - No code change. >> Cons: >> - DBA with brain is required. > ... Requires a downtime? Which can be substantial > Unless the configuration can be set up to allow updates applied following the > backup-restore cycle to be reapplied? Interesting proposition in its own right. :-) I'm thinking that nbackup does something along those lines, but on the page level. Would it be very difficult to implement something similar but on the record level? Avoiding downtime during backup/restore might be a more common requirement than the 64 bit txn id issue. Kjell -- -------------------------------------- Kjell Rilbe DataDIA AB E-post: kj...@da... Telefon: 08-761 06 55 Mobil: 0733-44 24 64 |
|
From: Dimitry S. <sd...@ib...> - 2012-01-02 10:10:34
|
01.01.2012 23:43, Kjell Rilbe wrote: > Den 2012-01-01 23:25 skrev Dimitry Sibiryakov såhär: >> 01.01.2012 21:31, Kjell Rilbe wrote: >>> So far, these are the suggestions I've seen >> Hey, how about my suggestion leave everything as is and perform backup-restore cycle on >> demand?.. >> >> Pros: >> - No overhead. >> - No additional disk space. >> - No code change. >> Cons: >> - DBA with brain is required. > Yes, of course! But you're forgetting this: > Con: > - If the no downtime is acceptable, it requires special measures to be > able to keep the system running during a backup-restore cycle, e.g. cluster. Single server without downtime is a myth anyway. And 24/365 systems cannot live without DBA in any case. -- SY, SD. |
|
From: Jesus G. <je...@gm...> - 2012-01-02 13:49:49
|
> > Single server without downtime is a myth anyway. The problem is not downtime is how much downtime. Backup and restore is so much downtime. Jesus |
|
From: Dimitry S. <sd...@ib...> - 2012-01-02 14:51:41
|
02.01.2012 14:46, Jesus Garcia wrote: > he problem is not downtime is how much downtime. Backup and restore is so much downtime. Not more downtime that simple restore after complete server destruction by flood or plane crash. -- SY, SD. |
|
From: Mark R. <ma...@la...> - 2012-01-02 15:10:28
|
On 2-1-2012 15:50, Dimitry Sibiryakov wrote: > 02.01.2012 14:46, Jesus Garcia wrote: >> he problem is not downtime is how much downtime. Backup and restore is so much downtime. > > Not more downtime that simple restore after complete server destruction by flood or > plane crash. Could you stop with the absurd comparisons? One is normal maintenance and the other is (extreme) disaster recovery which are in no way comparable. Mark -- Mark Rotteveel |
|
From: Lester C. <le...@ls...> - 2012-01-02 15:53:17
|
Mark Rotteveel wrote: >> 02.01.2012 14:46, Jesus Garcia wrote: >>> >> he problem is not downtime is how much downtime. Backup and restore is so much downtime. >> > >> > Not more downtime that simple restore after complete server destruction by flood or >> > plane crash. > Could you stop with the absurd comparisons? One is normal maintenance > and the other is (extreme) disaster recovery which are in no way comparable. And if you have a decent recovery setup, then you simply switch to a remote backup machine, which allows as much time as you like for repairs! Taking users offline for a period of time is simply not practical in a lot of cases, so we need to be able to manage how things are handled during any maintenance cycle. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php |
|
From: Dimitry S. <sd...@ib...> - 2012-01-02 15:44:19
|
02.01.2012 16:10, Mark Rotteveel wrote: > Could you stop with the absurd comparisons? One is normal maintenance > and the other is (extreme) disaster recovery which are in no way comparable. But downtime is downtime. Customers don't care about its reason, do they?.. -- SY, SD. |
|
From: Mark R. <ma...@la...> - 2012-01-02 15:53:35
|
On 2-1-2012 16:43, Dimitry Sibiryakov wrote: > 02.01.2012 16:10, Mark Rotteveel wrote: >> Could you stop with the absurd comparisons? One is normal maintenance >> and the other is (extreme) disaster recovery which are in no way comparable. > > But downtime is downtime. Customers don't care about its reason, do they?.. I think in general, customers are more forgiving if the downtime is caused by a disaster then if it is caused by long-running maintenance. Mark -- Mark Rotteveel |
|
From: Lester C. <le...@ls...> - 2012-01-02 16:40:54
|
Dimitry Sibiryakov wrote: >> Could you stop with the absurd comparisons? One is normal maintenance >> > and the other is (extreme) disaster recovery which are in no way comparable. > But downtime is downtime. Customers don't care about its reason, do they?.. In my own cases, ANY downtime during office hours is unacceptable, so any failure that brings the whole system down would result in penalties! Organised downtime is possible on many sites, but some sites are running 24/7, So we maintain data in a manor that the system will work with elements down, but the database operation must be maintained. Firebird has been running reliably for many years on these sites, when other services HAVE crashed, to the extent that services have been moving onto our framework due simply to it's reliability :) Customers care very much about downtime ... especially if it HAS to happen simply for maintenance reasons. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php |
|
From: Dimitry S. <sd...@ib...> - 2012-01-02 16:54:25
|
02.01.2012 17:40, Lester Caine wrote: > In my own cases, ANY downtime during office hours is unacceptable, so any > failure that brings the whole system down would result in penalties! Organised > downtime is possible on many sites, but some sites are running 24/7, So we > maintain data in a manor that the system will work with elements down, but the > database operation must be maintained. Firebird has been running reliably for > many years on these sites, when other services HAVE crashed, to the extent that > services have been moving onto our framework due simply to it's reliability:) > > Customers care very much about downtime ... especially if it HAS to happen > simply for maintenance reasons. But maintenance doesn't inevitable cause downtime. Maintenance of one piece of a system can't stop whole system if other pieces will do all the job. This is the main idea behind RAID1-6, for example. What's wrong with your system if it cannot work without only one part of it?.. -- SY, SD. PS: For me it is rather strange to talk about so basic principles of reliability here... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X