ClusterEyeClusterEye
Demo Talep Et
← Rollere göre
DBA EKİPLERİ İÇİN

Yavaşlamayı kanıtıyla açıklayın.

DB time ayrıştırması, plan ve index analizi, nesne bağımlılıkları ve yedek görünürlüğü — tek platformda.

Demo talep edinSandbox'ı gezin
DB Time ve sorgu analizi ekranı

Hangi sorunları çözer

Hangi sorgu veritabanı zamanını harcıyor?

Performans →

Hangi index eksik, eklenirse ne değişir?

Sorgu zekâsı →

Bir tabloyu değiştirmeden önce ona hangi sorguların bağlı olduğu bilinmiyor.

Bağımlılık grafiği →

Bunu yapan özellikler

PERFORMANCE

Wait events ve sorgu performansı

Aktif oturumları 5–15 sn'de bir (istenirse 1 sn) örnekleyin; hangi sorgu, kullanıcı veya host'un veritabanı zamanı harcadığını tek tıkla inceleyin.

  • Sorgu, wait, veritabanı, kullanıcı, program, host bazında DB time
  • 30 gün detay, 400 gün saatlik DB time
1 sn
isteğe bağlı örnekleme
30 gün
detay
400 gün
saatlik DB time
Özellik sayfasında →
AI

Yapay zeka ile sorgu optimizasyonu

Yavaş sorguları yakalamak yetmez — ClusterEye onları otomatik açıklar, planları analiz eder ve indeks önerileri üretir — PostgreSQL'de HypoPG ile doğrulanır.

  • EXPLAIN plan görselleştirme + maliyet analizi
  • Index ve istatistik önerileri (PostgreSQL, MongoDB, MSSQL)
  • Sorgu fingerprint ile pattern bazlı toplama
EXPLAIN
plan analizi
HypoPG
index doğrulama
AI
öneri motoru
Özellik sayfasında →
GRAPH

Bu tabloya dokunursam ne kırılır?

Database Context Graph, izlenen sorgular ile dokundukları objeleri sürekli eşleştirir. Bir tabloyu açtığınızda onu okuyan ve yazan sorguları, her birinin 24 saatlik yükünü ve erişim biçimini (seek mi, tam tarama mı) görürsünüz — şema değişikliğinden önce "bunu kim kullanıyor?" sorusunu tahmine bırakmazsınız. Ters yönü de doğrudur: bir sorgudan hangi tablolara, index'lere ve planlara bağlı olduğuna inersiniz.

  • Obje etkisi: "Bu tabloyu düşürmek 10 sorguyu etkiler — 4'ü yazıyor" uyarısı, diyagram ve tablo görünümüyle
  • Kenarlar dürüst: okuma/yazma ayrımı, plandan mı yoksa sorgu metninden mi çıkarıldığı, geçmişte kalmış bağımlılıklar ayrı işaretlenir
  • Sorgudan objeye: bir statement'ın beklediği wait'ler, planları, dokunduğu tablolar ve komşu sorgular tek çekmecede
  • PostgreSQL, SQL Server, Oracle, MySQL, ClickHouse ve MongoDB
  • "Grafiğin bilemeyecekleri" bölümü: izlenmeyen statement'lar ve henüz çalışmamış kod açıkça yazılır
6
motor
24 sa
yük penceresi
plan / metin
kenar kaynağı
Özellik sayfasında →
BACKUP

Yedek görünürlüğü ve restore tatbikatı

SQL Server yedek geçmişi, Oracle RMAN ve PostgreSQL WAL arşivini izleyin; Fleet ile yönetilen PostgreSQL'de zamanlanmış restore tatbikatları yedeğin döndüğünü kanıtlar.

  • Ayrı bir host'a zamanlanmış restore tatbikatı (PostgreSQL/pgBackRest)
  • Fleet PostgreSQL için PITR
  • MSSQL, Oracle RMAN ve WAL arşiv sağlığı
PITR
geri yükleme
tatbikat
zamanlanmış
pgBackRest
+ XtraBackup
Özellik sayfasında →

Ekibinizin ortamında görün.

Sizin motorlarınız ve sizin sorularınızla bir demo.

Demo talep edinTeklif isteyin