În PostgreSQL există un așa-numit MVCC (Multiversion Concurrency Control), care asigură că fiecare tranzacție vede propriile date, iar tranzacțiile de citire a datelor nu blochează niciodată tranzacțiile de introducere a datelor. iar înregistrarea nu blochează citirea.
Pentru aceasta, atunci când executați comenzile SQL UPDATE și DELETE, ștergerea și modificarea efectivă a liniei nu apare imediat. De fapt, atunci când UPDATE este executat, o nouă versiune a șirului este creată de fiecare dată, dar vechea versiune continuă să existe. Și cu DELETE, versiunea liniei este marcată doar ca eliminată printr-o anumită tranzacție, dar nu este ștearsă.
În cele din urmă, nu există nici o tranzacție live care ar putea vedea conținutul șirului. În acest caz, șirul poate fi șters și locul său este marcat ca fiind disponibil pentru utilizare la introducerea rândurilor. Acesta este ceea ce face VACUUM.
Comanda VACUUM are două opțiuni: normal și FULL.
Opțiunea obișnuită marchează liniile pentru utilizare ulterioară, dar nu returnează spațiul ocupat în sistemul de operare, cu excepția cazurilor extreme în care una sau mai multe pagini de la sfârșitul spațiului tabelului sunt complet libere:
Cel mai frecvent utilizat este VACUUM. și VACUUM FULL poate fi apelat după o anumită procedură, care actualizează foarte activ datele. În PostgreSQL, există un daemon standard care rulează periodic operația VACUUM. când acest lucru devine necesar.
MVCC se bazează pe capacitatea de a compara ID-ul (XID) al unei versiuni de tranzacție care a inserat un rând cu XID-ul tranzacției curente. Șirul în care XID-ul tranzacției care l-a introdus, mai mult decât XID-ul tranzacției curente a fost inserat în viitor și, prin urmare, nu ar trebui să fie vizibil din tranzacția curentă. Pentru ID-urile de tranzacție, se utilizează 32 de biți, astfel încât atunci când se efectuează un număr suficient de mare de tranzacții (mai mult de patru miliarde), va apărea așa numitul cod de tranzacție. adică ID-ul tranzacției va fi din nou 0 și brusc toate tranzacțiile care au fost în trecut vor fi în viitor, ceea ce va face vizibile schimbările.
Pentru a evita modificarea codului tranzacției, trebuie să executați întotdeauna VACUUM pentru fiecare bază de date cel puțin o dată la 2 miliarde de tranzacții.
Cum remediază comanda VACUUM problema? În PostgreSQL există o tranzacție specială XID FrozenXID. Acest XID nu respectă regulile obișnuite de comparare a ID-urilor și este întotdeauna considerat mai vechi decât orice XID normal. XID-urile comune nu sunt comparate ca numere prime, ci ca cele ciclice. Pentru fiecare XID, există două miliarde XID-uri care sunt mai vechi și două miliarde XID-uri, care sunt mai noi, adică spațiul XID este închis într-un inel. După crearea unui șir cu ceva XID obișnuit, șirul devine "în trecut" pentru două miliarde de tranzacții ulterioare, indiferent de numărul din XID-ul lor. Dacă această linie există încă după două miliarde de tranzacții, atunci se întâmplă să se întâmple în viitor. Pentru a preveni acest lucru, versiunile vechi ale liniilor XID trebuie să fie setate la FrozenXID înainte de a ajunge la piatra de hotar de 2 miliarde de tranzacții. După atribuirea acestui XID special, acestea vor fi "în trecut" pentru toate tranzacțiile obișnuite și, prin urmare, vor fi corecte până la ștergere, indiferent cât timp este nevoie. Alocarea FrozenXID se face prin comanda VACUUM. de aceea este atât de important încât este efectuată periodic.
Mai multe intrări din această categorie:
Articole similare
Trimiteți-le prietenilor: