Adatmódosító, vagy lekérdező logika fut ezeken?
Ezzel kapcsolatban egy probléma ugrik be, amit említettek a legutóbbi konferencián. A TIP előjeles integer-ként tárolja a tranzakció azonosítót. Ezért 2.7 milliárd tranzakció után csak gbak mentés/visszatöltés segít, ezzel lehet nullázni a TIP futó sorszámát. Egy olyan weboldalt említettek, ami ezt 3 havonta éri el. Firebird 3.0-ban ezt nem előjeles integer-re változtatják, de nem akarják 4 byte-ról 8 byte-ra emelni, mert ez egy minden rekordon megtalálható adat, és úgy gondolják, hogy túl "drága" lenne a többi felhasználónak ez az emelés.
Ha jól számolok, akkor 10 óra alatt kifutna Nálad a counter. Így vélhetően nem az FB a Neked megfelelő adatbázis-motor.
Hacsak ezek nem lekérdező select-ek és nem megoldható az, hogy egy tranzakción dolgozzon az összes. (Vagy legalábbis csoportba rendezni őket, hogy ne induljon ennyi.)
(Szerk.: ahogy fentebb írtam, a read only, read commited tranzakciók a "végtelenségig" nyitva maradhatnak, azok nem okoznak verziózást a módosuló rekordokon, de látják az összes, már commit-tal jóváhagyott új/módosult adatot.
Mi ezt alkalmazzuk, kliens-szerver alkalmazásoknál, azokon belül is ott, ahol nem fontos a snapshot-os adatlekérés.)