Q: Bir mühendis, veritabanı yazma almaya devam ederken veri dizinini düz bir recursive kopya ile yedekliyor; hiçbir snapshot ya da koordinasyon yok. Temel risk nedir?

Doğru cevap: Kopya iç tutarsız olabilir ve geçerli bir duruma restore edilemeyebilir. Canlı kopya, veri değişmeye devam ederken dosyaları bir zaman aralığında okur; dosya A ile dosya B farklı anları yansıtabilir — başlamayı reddedebilecek ya da yarı-uygulanmış transaction içeren yırtık, tutarsız bir görüntü. Güvenli physical backup, consistent snapshot ya da motorun backup modunu kullanır. Kopya ne bloklanır (b), ne geçerliliği garantidir (a), ne de şifrelenir (d).

Q: Çok büyük, yüksek trafikli bir orders tablosunda, böyle düz bir şema değişikliğini production'da çalıştırmak neden riskli olabilir?

Doğru cevap: Bazı değişiklikler tabloyu kilitler ya da uzun sürer; yazmayı (ve bazı DDL'lerde okumayı) bloklayıp downtime'a yol açar. Büyük ve yoğun bir tabloda index oluşturmak gibi bir işlem lock tutabilir ve sorguları durduracak kadar uzun sürebilir; bu yüzden ekipler bunu düşük trafikli pencerelere alır ya da online/concurrent varyantları kullanır. Veriyi bozmaz (a), DROP INDEX ile geri alınabilir (c) ve tabloyu RAM'e yüklemeyi gerektirmez (d).

Q: Her Pazar bir full backup, Pazartesi–Cumartesi her gece bir differential backup alıyorsun. Veritabanını Çarşamba geceki haline restore etmek için hangi backup'lara ihtiyacın var?

Doğru cevap: Yalnızca Pazar'ın full backup'ı ile Çarşamba gecesinin differential'ı. Differential, son full backup'tan sonra değişen her şeyi içerir; yani her gecenin differential'ı önceki günlerin değişikliklerini de kapsar — hedef gecen için yalnızca full + o bir differential yeter. Zincirdeki her differential'ı uygulamak (a) bir incremental stratejiyi tarif eder; differential tek başına (c) bir base'e sahip değildir, full tek başına (d) ise haftanın değişikliklerini kaçırır.

Q: order_items(order_id, product_id, quantity, product_name) tablosunun composite primary key'i (order_id, product_id) ve product_name yalnızca product_id'ye bağlı. Sorun ve çözümü nedir?

Doğru cevap: 2NF'i ihlal eder: product_name anahtarın bir parçasına partial dependency'dir; bir products tablosuna taşı. 2NF, anahtar olmayan her kolonun composite key'in tamamına bağlı olmasını ister. product_name yalnızca anahtarın parçası olan product_id'ye bağlıdır — partial dependency — dolayısıyla product_id ile anahtarlanan bir products tablosuna aittir. Değerler atomiktir, yani 1NF sorunu değildir (a) ve partial dependency, 3NF'in ele aldığı transitive dependency'den farklıdır (b).

Question 1

Bir veritabanını, farklı bir major versiyonda ve farklı bir CPU mimarisinde çalışan bir sunucuya taşıman gerekiyor. Genelde hangisi daha güvenli ve neden?

Accepted Answer

Doğru cevap: Logical SQL dump, çünkü taşınabilirdir ve farklı bir versiyona ya da platforma yeniden yüklenebilir. Physical backup, major versiyonlar ve mimariler arasında değişebilen motor-içi dosya formatlarını kopyalar; başka yere restore etmek kırılgandır. Logical dump ise motorun okuyabildiği SQL/veridir; versiyonlar ve platformlar arası taşımanın standart aracı tam da bu yüzden odur. Replication (b) kopyaları senkron tutar ama migration için ön koşul değildir.

Question 2

Bu iş bir yıl boyunca her gece başarıyla (exit 0) bitti ama gerçek bir kesintide restore başarısız oldu. Bu klasik durum neyi gösterir?

Accepted Answer

Doğru cevap: Yeşil bir backup işi komutun çalıştığını kanıtlar, çıktının restore edilebilir olduğunu değil. Sıfır exit code, dump komutunun çalıştığını gösterir; çıktının eksiksiz ve restore edilebilir olduğunu değil — yanlış bir flag, dışlanan bir şema ya da sessiz kesilme, sen gerçekten restore edene dek (ör. psql newdb < /backups/nightly.sql ile ayrı bir veritabanına) gizli kalır. 'Backup'ımız var'ı 'kurtarabiliriz'e ancak gerçek bir test restore çevirir. Diğer şıklar sebebi yanlış teşhis eder.

Question 3

Bir mühendis, veritabanı yazma almaya devam ederken veri dizinini düz bir recursive kopya ile yedekliyor; hiçbir snapshot ya da koordinasyon yok. Temel risk nedir?

Accepted Answer

Doğru cevap: Kopya iç tutarsız olabilir ve geçerli bir duruma restore edilemeyebilir. Canlı kopya, veri değişmeye devam ederken dosyaları bir zaman aralığında okur; dosya A ile dosya B farklı anları yansıtabilir — başlamayı reddedebilecek ya da yarı-uygulanmış transaction içeren yırtık, tutarsız bir görüntü. Güvenli physical backup, consistent snapshot ya da motorun backup modunu kullanır. Kopya ne bloklanır (b), ne geçerliliği garantidir (a), ne de şifrelenir (d).

Question 4

Çok büyük, yüksek trafikli bir orders tablosunda, böyle düz bir şema değişikliğini production'da çalıştırmak neden riskli olabilir?

Accepted Answer

Doğru cevap: Bazı değişiklikler tabloyu kilitler ya da uzun sürer; yazmayı (ve bazı DDL'lerde okumayı) bloklayıp downtime'a yol açar. Büyük ve yoğun bir tabloda index oluşturmak gibi bir işlem lock tutabilir ve sorguları durduracak kadar uzun sürebilir; bu yüzden ekipler bunu düşük trafikli pencerelere alır ya da online/concurrent varyantları kullanır. Veriyi bozmaz (a), DROP INDEX ile geri alınabilir (c) ve tabloyu RAM'e yüklemeyi gerektirmez (d).

Question 5

Her Pazar bir full backup, Pazartesi–Cumartesi her gece bir differential backup alıyorsun. Veritabanını Çarşamba geceki haline restore etmek için hangi backup'lara ihtiyacın var?

Accepted Answer

Doğru cevap: Yalnızca Pazar'ın full backup'ı ile Çarşamba gecesinin differential'ı. Differential, son full backup'tan sonra değişen her şeyi içerir; yani her gecenin differential'ı önceki günlerin değişikliklerini de kapsar — hedef gecen için yalnızca full + o bir differential yeter. Zincirdeki her differential'ı uygulamak (a) bir incremental stratejiyi tarif eder; differential tek başına (c) bir base'e sahip değildir, full tek başına (d) ise haftanın değişikliklerini kaçırır.

Question 6

order_items(order_id, product_id, quantity, product_name) tablosunun composite primary key'i (order_id, product_id) ve product_name yalnızca product_id'ye bağlı. Sorun ve çözümü nedir?

Accepted Answer

Doğru cevap: 2NF'i ihlal eder: product_name anahtarın bir parçasına partial dependency'dir; bir products tablosuna taşı. 2NF, anahtar olmayan her kolonun composite key'in tamamına bağlı olmasını ister. product_name yalnızca anahtarın parçası olan product_id'ye bağlıdır — partial dependency — dolayısıyla product_id ile anahtarlanan bir products tablosuna aittir. Değerler atomiktir, yani 1NF sorunu değildir (a) ve partial dependency, 3NF'in ele aldığı transitive dependency'den farklıdır (b).

Veritabanı Senior Mülakat Soruları

Örnek sorular

Konular

Uzmanlığa göre

Kıdeme göre

Diğer alanlar