yoklateknik mülakat

Veritabanı Pg Mvcc Vacuum Mülakat Soruları

75 doğrulanmış Veritabanı Pg Mvcc Vacuum mülakat sorusu — cevaplarıyla çöz, açıklamalarıyla öğren, gerçek simülasyonda kendini test et.

Gerçek simülasyonu dene →

Örnek sorular

Pg Mvcc VacuumZorluk 1
Verilen: CREATE TABLE t(id int, v int); INSERT INTO t VALUES (1,10); UPDATE t SET v = 20 WHERE id = 1; UPDATE çalıştığında disk üzerindeki orijinal satır sürümüne gerçekte ne olur?
  • aYeni bir satır sürümü eklenir ve orijinal satır ölü tuple olarak işaretlenir.
  • bOrijinal satırın baytları yeni değerle yerinde üzerine yazılır.
  • cOrijinal satır hemen silinir ve disk alanı serbest bırakılır.
  • dDeğişiklik yalnızca WAL'a uygulanır, tabloya hiç yazılmaz.
Açıklama:PostgreSQL'in MVCC modeli heap satırının yerinde üzerine yazılmasına asla izin vermez. UPDATE tamamen yeni bir satır sürümü ekler ve eski sürümün xmax'ını işaretleyerek onu, sonraki bir VACUUM alanını geri kazanana kadar tabloda kalan bir ölü tuple'a çevirir.
Pg Mvcc VacuumZorluk 1
İki INSERT'ten hemen sonra taze bir tablodan alınan gerçek çıktı:
 xmin  | xmax | ctid  | id 
-------+------+-------+----
 12260 |    0 | (0,1) |  1 
 12260 |    0 | (0,2) |  2 

Bu satırlar için xmax = 0 olması neyi gösterir?
  • aSatırlar silindi ama silen transaction henüz commit olmadı.
  • bSatırlar hiçbir transaction tarafından silinmemiş veya güncellenmemiş.
  • cSatırlar bozulmuş ve REINDEX gerektiriyor.
  • dTabloda primary key tanımlı değil.
Açıklama:xmax, bir satır sürümünü silen ya da güncelleyerek geçersiz kılan transaction'ın id'sini tutar. 0 değeri hiç ayarlanmadığı anlamına gelir; yani satır hâlâ güncel ve canlı sürümdür — herhangi bir DELETE veya UPDATE tarafından dokunulmamıştır.
Pg Mvcc VacuumZorluk 2
Aynı satırdan gerçek, doğrulanmış önce/sonra durumu:
Önce: xmin=12260, ctid=(0,1). UPDATE accounts SET balance = balance + 50 WHERE id = 1; sonrası: xmin=12261, ctid=(0,3). Sadece balance sütunu değiştiği hâlde ctid neden değişti?
  • actid, PostgreSQL'in güvenlik için her SELECT'te yeniden atadığı rastgele bir değerdir.
  • bctid yalnızca bir foreign key'in referans verdiği sütun güncellendiğinde değişir.
  • cctid satırın fiziksel adresidir; UPDATE onu her zaman yeni bir konuma yazar.
  • dctid primary key değerinden türetilir, bu yüzden id ile ilgili sütunlar güncellenince değişir.
Açıklama:ctid, bir satır sürümünün fiziksel (sayfa, offset) adresidir; kararlı bir mantıksal tanımlayıcı değildir. UPDATE yerinde düzenleme yapmak yerine her zaman tamamen yeni bir tuple oluşturduğu için, bu yeni tuple yeni bir fiziksel konuma yerleşir; dolayısıyla hangi sütun değişmiş olursa olsun ctid eskisinden farklı olmak zorundadır.
Pg Mvcc VacuumZorluk 2
PostgreSQL'de genel olarak "tablo bloat'ı (şişmesi)" ne anlama gelir?
  • aPostgreSQL'in tablo oluşturulurken önceden ayırdığı ekstra alan.
  • bTOAST ile satır-içi (inline) depolama arasındaki sıkıştırılmış boyut farkı.
  • cshared_buffers'ın bir tablonun sayfalarını önbelleklemek için kullandığı bellek.
  • dVACUUM'un henüz geri kazanmadığı ölü tuple ve sayfa alanının kapladığı disk alanı.
Açıklama:Bloat, UPDATE ve DELETE'lerden kaynaklanan ölü tuple'ların ve tablonun sayfaları içinde henüz geri kazanılmamış/yeniden kullanılmamış boş alanın birikmesidir; bu da tablonun disk üzerindeki boyutunu, içerdiği canlı verinin normalde gerektireceğinden daha büyük hâle getirir.
Pg Mvcc VacuumZorluk 2
VACUUM ile VACUUM FULL arasında disk kullanımı açısından temel pratik fark nedir?
  • aVACUUM, boşalan alanı dosya içinde yeniden kullanır; VACUUM FULL tabloyu yeniden yazıp dosyayı küçültür.
  • bVACUUM yalnızca index'ler üzerinde çalışır, VACUUM FULL ise yalnızca tablo heap'i üzerinde çalışır.
  • cVACUUM tablonun tamamen yeniden yazılmasını gerektirir, VACUUM FULL ise yalnızca istatistikleri günceller.
  • dVACUUM FULL, VACUUM'un eş anlamlısıdır; FULL anahtar kelimesi yalnızca log ayrıntı düzeyini değiştirir.
Açıklama:Düz VACUUM, ölü tuple'ların alanını aynı tablo dosyası içinde gelecekteki insert/update'ler tarafından yeniden kullanılabilir hâle getirir ama genelde dosyanın disk üzerindeki boyutunu değiştirmez. VACUUM FULL ise tablonun yeni, derli toplu bir kopyasını oluşturur; bu sayede disk üzerindeki dosyayı gerçekten küçültüp alanı OS'a iade edebilir.
Pg Mvcc VacuumZorluk 3
Yoğun bir production tablosunda VACUUM FULL accounts; çalıştırıyorsun. O çalışırken başka bir session düz bir SELECT * FROM accounts; çalıştırıyor. Benzer bir tabloda VACUUM FULL sırasında yapılan gerçek bir pg_locks kontrolü mode = AccessExclusiveLock, granted = t gösterdi. Eş zamanlı SELECT'e ne olur?
  • aSELECT hemen çalışır, çünkü VACUUM FULL yalnızca tablonun index'leri üzerinde kilit alır, heap üzerinde değil.
  • bSELECT bloklanır ve bekler, çünkü VACUUM FULL bir ACCESS EXCLUSIVE kilit tutar.
  • cSELECT eski veriyi kullanarak hemen çalışır, çünkü MVCC okuyucuların VACUUM FULL'un tuttuğu kilidi atlamasına izin verir.
  • dSELECT beklemek yerine hemen bir hatayla başarısız olur.
Açıklama:AccessExclusiveLock, PostgreSQL'deki en güçlü kilit modudur ve düz bir SELECT'in ihtiyaç duyduğu AccessShareLock dahil diğer tüm kilit modlarıyla çakışır. Bu yüzden VACUUM FULL tabloyu yeniden yazarken, eş zamanlı herhangi bir SELECT kilit serbest kalana kadar bekler.

2475 soruluk Veritabanı bankasında kendini sına.

Mülakata başla