Performance bei Triggern auf Views und von verbundenen Servern

ukulele

Datenbank-Guru
Beiträge
5.141
Also ich gebe zu Perofrmance-Analyse fällt mir schwer und meine Erfahrung ist begrenzt. Dennoch habe ich ein für mein Verständnis einfaches Szenario:

Server1 ist ein Produktivsystem und dient mir als Datenquelle. Die Datenbank ist riesig und die Dokumentation ist mir nicht zugänglich, ich kann hier nur Daten lesen und mich freuen oder auch nicht.

Server2 hat Views auf diese Daten. Leider sind die Daten natürlich nicht direkt so wie ich sie gerne hätte aber ich denke die Komplexität der View ist schwer zu reduzieren. Eine View mit Schema-Binding und Index ist leider aufgrund des Remote-Querys nicht möglich, soweit meine Infos.

Die Daten aus der View sollen im Auswertungsystem (Server2) manuell verändert werden können. Dazu werden wenige Spalten in einer eigenen Tabelle abgebildet und 1:1 in der View verknüpft. Liegt in der Tabelle ein Eintrag vor (derzeit nur 3 zum testen) sorgt ein CASE dafür das der Wert aus der Ergänzungstabelle in der Spalte erscheint. Jetzt habe ich auf der View einen Instead-of-Trigger erstellt damit Inserts und Updates gegen die View in die Ergänzungstabelle geschrieben werden. Soweit funktioniert das eigentlich gut nur irgendwie behäbig.

Wenn ich jetzt ein ganz schlichtes Update gegen die View mache dann sorgt der Trigger dafür das das Update eigentlich gegen die Ergänzungstabelle ausgeführt wird, als Datenquelle dient die Systemtabelle INSERTED, also die Daten wie sie der Trigger während des Updates kennt. Auf die View macht der Trigger kein Query, nur auf INSERTED. Nach meinem Verständnis muss die View als solche nicht abgefragt werden. Der MS "Ausführungsplan" sieht das aber anders, hier stehen zwei dicke Clustered Index Scans gegen die View, das ganze dauert ca. 4 Sekounden. Das gleiche Update direkt gegen die Tabelle ist blitzschnell.

Hat jemand eine Idee?
 
Werbung:
Zurück
Oben