Başarısız bir zamanlanmış yenileme, BI’a olan güveni kaybetmenin en sessiz yoludur: rapor yine açılır, sadece rakamlar dünkü — ya da geçen haftaki — rakamlardır. Biri fark ettiğinde, sahibi genellikle günlerdir hata e-postalarını görmezden geliyordur. Bu rehber en sık gördüğümüz hata nedenlerini, her birinin nasıl doğrulanacağını ve tek bir model’in ötesinde izlemenin nasıl görünmesi gerektiğini listeler.
Kanıt nerede duruyor?
Her semantic model bir yenileme geçmişi tutar (model ayarları → Yenileme geçmişi veya Get Refresh History REST API’si); deneme başına durum, süre ve hata içeriğiyle birlikte. Hata bildirimleri yalnızca model sahibine gider — tenant genelindeki hataların fark edilmemesinin sebebi tam olarak budur.
Olağan şüpheliler
- Süresi dolmuş veya bozulmuş kimlik bilgileri. OAuth token’ları düşer, servis hesabı parolaları döner, insanlar ayrılır. Hata metni kimlik bilgisi, authentication veya AAD’den söz eder. Çözüm: veri kaynağında kimlik bilgilerini yeniden girin — ve kaynak destekliyorsa kişisel hesap yerine service principal tercih edin.
- Gateway sorunları. Şirket içi kaynaklar için: gateway kapalı, güncel değil veya veri kaynağı tanımı eksik. Gateway kümesinin durum sayfasını ve güncelleme sıklığını kontrol edin; tek düğümlü bir gateway, yenileme için tek hata noktasıdır.
- Zaman aşımları. Yenilemeler paylaşımlı kapasitede yaklaşık 2, Premium/Fabric kapasitesinde 5 saatle sınırlıdır. Tavana yaklaşan model’lerin artımlı yenilemeye, query folding kontrolüne veya daha az yüksek kardinaliteli sütuna ihtiyacı vardır.
- Bellek ve kapasite baskısı. Adanmış kapasitelerde, eşzamanlı yenilemeler ve interaktif yük SKU’nun belleğini aştığında bir yenileme tahliye edilebilir. Belirtisi: yoğun saatlerde kümelenen aralıklı hatalar. Zamanlamaları yayın veya kapasiteyi doğru boyutlandırın.
- Zamanlama yığılmaları ve limitler. Paylaşımlı kapasite model başına günde 8, Premium/Fabric 48 zamanlanmış yenilemeye izin verir — ve tam 08:00’de yenilenen onlarca model, tek tek limitine çarpmasa bile aynı işlem gücü için yarışır.
Tek model’in ötesinde izleme
Yenileme geçmişini model model kontrol etmek birkaç workspace’i aştığında ölçeklenmez. Sağlıklı tenant’lar şunları tek yerde takip eder: zaman içinde başarı oranı, en sık hata veren model’ler, her birinin en son ne zaman başarısız olduğu ve hatanın neden sınıfı — çünkü on adet “kimlik bilgisi süresi doldu” hatası on değil, bir sorundur. PGR Sonar’ın Yenileme Sağlığı sayfası bunu tenant genelinde yapar; uygun planlarda AI teşhisi her sabahki hataları olası nedene göre gruplar ve somut bir çözüm önerir — böylece kırmızı bir duvar yerine kısa bir listeyle uyanırsınız.