Re: SQL 2005 Express View's (Sichten) Verständnisfrage

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance



"Christian Winther" wrote:

Christoph Ingenhaag schrieb:

[...]
s. u.a.:
http://de.wikipedia.org/wiki/Sicht_(Datenbank)

HTH CW

P.S.: Ich mag ja altmodisch sein, aber bei den in dem o.g.
Wikipedia-Artikel verwendeten Tabellen/Row-Namen mit Sonderzeichen
rollen sich mir die Fußnägel auf ...


!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
A C H T U N G!!
Das gilt (zumindest) nicht für MS SQL Server!!
(Auch wenn es in Wikipedia steht)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

ist ein View eine Art gespeichertes
SQL-Statement, d.h., das SQL-Statement wurde bereits geparst, optimiert
und ein Ausführungsplan erstellt. Damit ist ein View kostengünstiger als
das gleichlautende SQL-Statement.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Hier die Korrektur für SQL Server:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Beim Speichern wird die View auf syntaktische Richtigkeit geparst.
Ein Ausführungsplan wird für die View NICHT erstellt.
Da die View bei Zugriff expandiert wird, also das in das verwendende
Statement "eingebaut" wird, wird erst dann ein Ausführungsplan für das
gesamte Statement erzeugt!
Eine View dient zur Abstraktion, zur Wiederverwendung, und zur
Berechtigungsteuerung. Nicht zur Performancesteigerung!
Anders bei materialisierten Views (Achtung, hier kommt es auch noch darauf
an, welche Version (Express, Workgroup, Standard, Enterprise) des SQL
Servers). verwendet wird) Hier wird die View materialisiert, also die Daten
physikalisch gespeichert. Es gibt viele Voraussetzungen, die eingehalten
werden müssen, um eine View zu materialisieren und damit SQL Server die
materialisierte View nicht doch expandiert.

Vg
Christoph

P.S. Ich kann mir auch nicht vorstellen, das in anderen RDBMS für Views
Ausführungspläne erstellt werden. Ein solcher Plan kann im Gesamtkontext der
auszuführenden Abfrage mehr als suboptimal sein.

Hallo Christoph,

die Sache mit dem gespeicherten Ausführungsplan war mir aus irgendeiner
ORACLE-Schulung in Erinnerung. Auf die Schnelle habe ich dazu nur
folgendes gefunden.

http://www.ordix.de/ORDIXNews/4_2005/db_hysterie.html

Abschnitt: Problemfall Bind-Variablen

http://www.smart-soft.co.uk/Oracle/oracle-tuning-part4-vw-use.htm

Abschnitt: Ensuring the same SQL is used throughout your application

MfG CW


Hallo Christian,

das wird auch auf so mancher SQL Server Schulung behauptet.

In den von dir gelinkten Artikeln, finde ich auf die Schnelle nur die
folgenden Unterschiede/Auffäligkeiten zu SQL Server:
SQL Server hat nur einen kostenbasierten Optimizer (ab welcher Version weiss
ich nicht).
Statistiken werden automatisch erstellt und gepflegt, wenn hiervon nicht per
Einstellung abgewichen wird.
Die Sache mit den Bind Variablen findet sich auch ähnlich beim SQL Server:
Wenn eine Stored Procedure erstmalig aufgerufen wird, wird der
Ausführungsplan anhand der übergebenen Parameter und der vorhanden
Statistiken erstellt. Wenn man erstmalig einen Parameter übergibt, dessen
Selektivität anhand der Statistik gering ist, wird im Ausführungsplan hierfür
ein Scan hinterlegt. Andersherum würde dann ein Seek (immer vorausgesetzt ein
entsprechender Index ist vorhanden) hinterlegt. Je nach Verteilung der Daten
und je nach Zweck der Prozedur kann das gut oder schlecht sein . Aktuelle
Statistiken sind also das A und O. Gleiches gilt für Prepared Statements die
autoparametrisiert wurden.
E i n e Voraussetzung bei der Wiederverwendung von Plänen von Ad Hoc
Abfragen aus dem Cache ist die exakte Zeichengleicheit der Abfragen. Wenn auf
Views zugegriffen wird, ist diese Wahrscheinlichkeit natürlich größer, als
wenn alles neu formuliert wird.
Auch hier gibt es natürlich ein Vielzahl von Optionen, Einstellungen und
Bedingungen und Eingriffsmöglichkeiten, insbesondere seit Version 2005. Füllt
ganze Bücher (hier ist die INSIDE SQL SERVER Reihe sehr zu empfehlen).
Ist hier also nur sehr, sehr grob wiedergegeben.

Aus den beiden Artikeln geht aber auch nicht hervor, das Oracle Pläne von
Views speichert.

Warum das auch suboptimal wäre kann man sich vielleicht hiermit
vergegenwärtigen und auch einfach mal ausprobieren:
Wenn der Plan einer View gespeichert würde, wäre im Plan unter anderem die
Join -order gespeichert. Wenn nun eine Abfrage auf diese View mit einem Join
zugreift, könnte der Optimizer nur noch zwischen 2 möglichen Join-orders
wählen, statt n anderen (natürlich je nach View).
Was das für Auswirkungen hätte, kann man mit SQL Server einfach nachstellen,
wenn man mit SET FORCEPLAN oder mit der OPTION(force order) den Optimizer
zwingt auf die Tabellen in der Reihenfolge zuzugreifen, wie es in der FROM
Klausel definiert ist. Je nach Beispiel kann man dramatische Änderungen in
den Kosten der Ausführungspläne feststellen. Fast ausschliesslich zum
Nachteil...
Bie Oracle gibts bestimmt sowas ähnliches...

Vg
Christoph


.

Relevant Pages