Transaction Isolation Level - Snapshot

PostgreSQL REPEATABLE READ = SQL Server SNAPSHOT (similar transaction-level snapshot behavior).

Read Committed Snapshot Isolation - RSCI

Giriş

Açıklaması şöyle. Varsayılan RSCI OFF yani reader ve writer lock kullanır

RCSI OFF: Readers use shared locks. Readers and writers can block each other.

RCSI ON: Readers use row versions instead of shared data locks. Readers normally don't block writers, and writers normally don't block readers.

Yani

PostgreSQL READ COMMITTED = SQL Server READ COMMITTED with RCSI ON.

Transaction Isolation Level - Repeatable Read

Repeatable Read aslında Read Lock gibi. Başkaları o satırı okuyabilir ama kimse yazamaz.

Transaction Isolation Level

SQL Server Concurrency Problems

Problem	Explanation
Dirty Read	Reading uncommitted changes from another transaction.
Non-Repeatable Read	Reading the same row twice and getting different values.
Phantom Read	Repeating a query returns additional or missing rows due to concurrent inserts or deletes.
Lost Update	One transaction overwrites another transaction's update.
Write Skew	Transactions read the same state and update different rows, jointly violating a business constraint.
Read Skew	Reading related data at different times, resulting in an inconsistent combination.
Dirty Write	Overwriting data modified by another uncommitted transaction.
Deadlock	Transactions wait for each other in a circular dependency. SQL Server aborts one victim.
Livelock	A transaction repeatedly loses opportunities to proceed due to competing transactions.
Starvation	A transaction is continually denied resources or access.
Lock Escalation	SQL Server replaces many fine-grained locks with a table-level or partition-level lock.
Hot Spot	Many transactions compete for the same frequently accessed row or resource.

SQL Server Isolation Levels

Problem	Read Uncommitted	Read Committed	Repeatable Read	Snapshot	Serializable
Dirty Read	Possible	No	No	No	No
Non-Repeatable Read	Possible	Possible	No	No	No
Phantom Read	Possible	Possible	Possible	No	No
Lost Update	Possible	Possible*	Possible*	No**	No
Write Skew	Possible	Possible	Possible	Possible	No
Read Skew	Possible	Possible	Possible	No	No

Notes:

• READ COMMITTED is the default SQL Server isolation level.
• READ_COMMITTED_SNAPSHOT uses row versioning for Read Committed.
• SNAPSHOT provides transaction-level consistent reads.
• SNAPSHOT detects conflicting updates to the same row.
• SERIALIZABLE uses range locks to prevent phantom inserts and serialization anomalies.
• * Lost updates depend on the read-modify-write pattern and locking strategy.
• ** SNAPSHOT aborts one transaction when both transactions attempt conflicting updates to the same row.

VSS vs. VDI Backup

Giriş

İlk olarak burada gördüm

1.Volume Shadow Copy Service (VSS)

Sanırım Windows diskin kopyasını alıyor

2. Virtual Device Interface (VDI)

SQL Server SDK ile derlemek gerekir. SQL Server Engine veriyi kendisini VDI olarak tanıtan uygulamaya stream eder

Failover

Giriş

Açıklaması şöyle. Yani master ve replica arasındaki senkronizyon kopmuş ise replica otomatik olarak devralmaz. Elle FORCE_ALLOW_DATA_LOSS yapmak gerekir

PostgreSQL'de otomatik failover'ı açmak için replikasyonu senkron moda almak zorunda değilsiniz. Asenkron bir yapıda bile, primary çöktüğünde bir replica otomatik olarak terfi edebilir. Yani "biraz veri kaybı olabilir ama sistem kendi kendine ayağa kalksın" senaryosuna izin verir.

SQL Server tarafında ise durum farklı. Always On'da otomatik failover'ın devreye girebilmesi için replica'nın senkron modda olması ŞART. Asenkron bir replica otomatik failover hedefi olamaz. Siz veri kaybını göze alsanız bile sistem buna kendiliğinden izin vermez; ancak force allow data loss diyerek, bilinçli ve manuel bir müdahaleyle failover yapabilirsiniz.

Aradaki fark aslında bir tasarım felsefesi farkı. SQL Server "otomatik bir karar asla veri kaybına yol açmamalı, veri kaybı ancak insanın bilerek onayıyla olur" diyor. PostgreSQL ise "kayıp riskini kabul edip etmemek senin kararın, otomasyonu buna göre kur" diyor. İkisi de savunulabilir, ama aynı problemi farklı yerden çözüyorlar.

Columnstore Index

Giriş

Açıklaması şöyle

Columnstore mantığı temelinde basit: rowstore’da satır satır saklarız, columnstore’da kolon kolon. 1 milyarlık fact tablo üzerinde SUM(amount) hesaplayacaksak rowstore tüm satırı sayfaya getirir; columnstore sadece amount kolonunu okur, geri kalan kolonlar tek byte bile transfer olmaz.

Örnek şöyle

-- Ordered nonclustered columnstore (SQL Server 2025+)
CREATE NONCLUSTERED COLUMNSTORE INDEX nccsi_orders_ordered
    ON dbo.Orders (CustomerID, OrderDate, Amount)
    ORDER (OrderDate);

-- Sorgu artık OrderDate üzerinden segment elimination yapar
SELECT SUM(Amount)
FROM dbo.Orders
WHERE OrderDate >= '2025-01-01'
  AND OrderDate <  '2025-04-01';