Sabah 09:00. Genel müdür dünkü satışı soruyor, rapor üç gün öncesini gösteriyor. Yenileme “başarılı”, kimse e-posta almadı. Sorun nerede? Power BI’da tek bir yenileme yoktur; altı farklı şey aynı adla anılır. Doğru teşhis önce hangisinden söz ettiğini ayırmakla başlar.
Yenilemenin türleri
| Tür | Ne yapar? | Dikkat |
|---|---|---|
| Veri yenileme | Kaynaktan veriyi Import modele alır | DirectQuery ve canlı bağlantıda yoktur |
| OneDrive yenilemesi | .pbix, .xlsx, .csv dosyasıyla eşitler; yaklaşık saatte bir | Asıl kaynaktan veri çekmez |
| Sorgu önbelleği | Kapasitede sorgu sonuçlarını saklar | Her veri yenilemesi geçersiz kılar |
| Kutucuk yenileme | Pano kutucuklarını günceller | Import’ta veriyle birlikte; DirectQuery’de yaklaşık saatte bir |
| Görsel yenileme | Rapor görsellerini yeniden sorgular | Canlı bağlantı için geçerlidir |
| Şema yenileme | Sütun ekleme, silme, ad değişikliğini alır | Import, DirectQuery ve Direct Lake’te |
| Mod | Veri yenileme | “Güncel” ne demek? |
|---|---|---|
| Import | Zamanlanmış, isteğe bağlı | Son yenileme anı |
| DirectQuery | Yok | Sorgu anı; kutucuklar saatlik |
| Canlı bağlantı | Yok | Kaynak modelin tazeliği |
| Direct Lake | Çerçeveleme (framing) | Delta’nın işaret edilen sürümü; “Fabric’te anlam modeli” dersi |
Yenileme yolları
- Zamanlanmış: anlam modeli ayarları → Yenileme → Yenilemeyi zamanla. Saat dilimini bilinçli seç.
- Şimdi yenile: elle, isteğe bağlı.
- Power Automate: olaya bağlı (dosya geldi, onay verildi).
- REST API, XMLA: tablo düzeyinde, bölüm düzeyinde, kapasitede geniş denetim.
- İşlem hattı: Fabric’te veri hazır olunca (“İşlem hatları” dersi).
Sınırlar
| Pro (paylaşılan) | PPU, Premium, Fabric | |
|---|---|---|
| Zamanlanmış yenileme | Günde 8 | Günde 48 |
| API ile tetikleme | 8’e dahil | Sabit sayı yok; kapasiteye bağlı, kuyruğa girebilir |
| Şimdi yenile | 8’e dahil değil | Kapasiteye bağlı |
| Süre | 2 saat | 5 saat (XMLA ile aşılabilir) |
| Başlama | Seçilen saatten en fazla 5 dk önce, hedef 15 dk içinde; kaynak azsa 1 saate kadar gecikebilir | |
Tam yenileme bellekte modelin yaklaşık iki katını ister, çünkü sorgulara hizmet için eski kopya durur. 1 GB’ı aşan ya da saatler süren modelde “Büyük modeller” dersindeki artımlı yenilemeyi düşün. Günde 48 slotunu doldurmak iyi bir hedef değildir: veri sık değişiyor ve kaynak dayanıyorsa DirectQuery daha doğru olabilir.
Zamanlama neden kendiliğinden kapanır?
| Olay | Sonuç | Ne yapılır? |
|---|---|---|
| Art arda 4 hata ya da süresi dolmuş kimlik bilgisi | Zamanlama kapanır | Kök nedeni çöz, zamanlamayı yeniden aç. Eşik değiştirilemez. |
| 2 ay görüntülenmeme | Zamanlama duraklar, sahibe e-posta gider | Raporu aç ya da Şimdi yenile |
Hata e-postasını kişisel kutuya değil ekip listesine yönlendir; biri izne çıktığında rapor sessizce eskir.
Yenileme geçmişini okumak
Anlam modeli ayarları → Yenileme geçmişi. Tür, başlangıç, bitiş, durum ve hata iletisi burada. Teşhis sırası:
| Belirti | Kök neden | Çözüm |
|---|---|---|
| Kimlik bilgileri geçersiz | Parola değişti, OAuth süresi doldu | Veri kaynağı kimlik bilgilerini güncelle, zamanlamayı aç |
| Veri kaynağı tanımlı değil, ağ geçidi çevrim dışı | Bağlantı eşleşmemiş, makine kapalı | “On-premises data gateway” dersi |
| Sütun bulunamadı | Kaynak şeması değişti | Power Query adımını düzelt, yeniden yayımla |
| Zaman aşımı | Model büyük, katlama yok | Sütun azalt, katlamayı koru, artımlı yenileme |
| Bellek hatası | Kapasite dolu, eşzamanlı yenileme | Saatleri yay, gereksiz sütun çıkar |
| Başlangıç gecikiyor | Kapasite yük altında | Saatleri kaydır, “Kullanım ve izleme” dersi |
| “Başarılı” ama eski veri | Üst adım bitmeden çalıştı ya da kaynak eski | Olaya bağlı zincir, tazelik göstergesi |
En tehlikelisi son satırdır: yenileme başarılıdır ve veri yine eskidir. “Son yenileme” zaman damgası yanlış güven verir. Doğru sinyal, olgu tablosundaki en son iş tarihidir:
Veri Gecikmesi (gün) = DATEDIFF(CALCULATE(MAX(Satislar[Tarih]), REMOVEFILTERS()), DATE(2024, 12, 31), DAY)
Uygulama verisi 2024 sonunda bittiği için referans tarih sabit; gerçek modelde TODAY() yazılır. Eşiği sıfır yapma. Gece yenilenen modelde en son iş tarihi dündür: fark her sabah 1 çıkar, kart hep kırmızı kalır ve sürekli yanan alarma kimse bakmaz. Kabul edilen gecikmeyi işin sahibiyle konuş. Her gün satış olan ve günlük yenilenen modelde fark 1’den büyükse kırmızıya çevir. Hafta sonu satış yoksa Pazartesi farkı 3 olur: eşiği buna göre ver ya da iş günü takvimiyle say. Az satan kategoride daha geniş eşik gerekir; “Bayat Rapor” vakasında 7 gün kullanılıyor.
Tazelik Rengi = VAR Gecikme = DATEDIFF(CALCULATE(MAX(Satislar[Tarih]), REMOVEFILTERS()), DATE(2024, 12, 31), DAY) RETURN IF(Gecikme > 1, "#C0392B", "#2E7D32")
Geçmişi sayıya çevirmek
Yenileme geçmişi REST API ile alınabilir, bir tabloya yazılabilir. Elde edince “hangi model kaç kez düştü?” bir DAX sorgusu olur:
EVALUATE
VAR Gecmis =
DATATABLE("Model", STRING, "Durum", STRING, "Dakika", INTEGER, {
{"Satış", "Başarılı", 12}, {"Satış", "Başarılı", 14}, {"Satış", "Hata", 2},
{"Stok", "Başarılı", 41}, {"Stok", "Hata", 120}, {"Stok", "Hata", 120}
})
RETURN
GROUPBY(Gecmis, [Model], "Hata", SUMX(CURRENTGROUP(), IF([Durum] = "Hata", 1)), "Süre", SUMX(CURRENTGROUP(), [Dakika]))
Pro’da 120 dakikayı gören Stok modeli büyük olasılıkla süre sınırına çarpıyor. Bu tablo gerçek değil, sorgunun kalıbını göstermek için yazıldı.