Partitionierte Sicht

[bigpoint]

Hallo Leute,

ich habe eine Partitionierte Sicht in der 10 Tabellen sich befinden,
die Tabellen haben als CHECK – Einschränkung habe ich eine Spalte (Test) als int.
Folgendes Problem:

Bei solchem select
Declare @t int
Set @t=1

Select * from table where test=@t

Geht der SQL Server aller Tabellen die sich in der Partitionierte Sicht befinden durch ;((

Bei solchem select

Select * from table where test=1

Nur die tabelle mit dem CHECK – Einschränkung gleich 1

Bitte um Hilfe und Erklärung

[Andreas Kosch]

Hallo,
das ist ein nomales Verhalten. Jede SQL-Datenbank arbeitet eine SQL-Anweisung in 4 Schritten ab:
<br>
1. Syntaxprüfung des SQL-Befehls (Parse). Der SQL-Server prüft, ob die festgelegten Formulierungsregeln eingehalten werde. Jeder Befehl wird dazu in seine Be*standteile zerlegt. Außerdem wird geprüft, ob die verwendeten Tabellen und Spalten auch tatsächlich in der Datenbank bekannt sind und ob der Benutzer auch die notwendige Rechte für diese Datenbankobjekte besitzt.
<br>
2. Der SQL-Server sucht den schnellsten Weg, um die gestellte Aufgabe abzu*arbeiten (Optimize). Dazu werden zuerst alle View-Tabellennamen und View-Spalten*namen durch die tatsächlichen Tabellenbezeichner ersetzt. Im nächsten Schritt liest der SQL-Server Daten über den Datenbankzustand aus den System*tabellen aus. Mit diesen Daten werden die möglichen Zugriffswege gesucht. Anschließend kalkuliert der SQL-Server die Ausführungszeit für jeden der möglichen Wege und wählt anschließend den schnellsten Weg aus. Der SQL-Server entscheidet selbständig, ob ein Index verwendet wird.
<br>
3. Die tatsächlich auszuführende Befehlsfolge wird in allen Einzelschritten vor*bereitet und in binärer Form abgelegt.
<br>
4. Der SQL-Befehl wird tatsächlich ausgeführt, wobei übergebene Parameter-Werte eingesetzt werden.
<br><br>
Bei einer SQL-Anweisung wie zum Beispiel <i>Select * from table where test=1</i> gibt es im Schritt 2 (Optimize) keine Unbekannten, der SQL Server kann den Ausführungsaufwand vollständig abschätzen. Bei einer SELECT-Anweisung wie <i>Select * from table where test=@t</i> ist der konkrete Parameterwert aber im Schritt 2 (Optimize) noch unbekannt, so dass der SQL Server die Vorteile anderer Zugriffspfade auf die Daten nicht bewerten kann. Im Worst Case führt zur Laufzeit der übergebene Parameterwert dazu, dass alle Datensätze betroffen sind, so dass ein Table Scan verwendet werden muss.
<br>
Um das Problem zu lösen, stehen mindestens 2 Möglichkeiten zur Verfügung:<br>
1. Über die so genannten <b>Hints</b> wird der Optimizer überstimmt, indem bereits in der SQL-Anweisung der Zugriffspfad vorgegeben wird (auch auf die Gefahr hin, dass am Ende nicht in jedem Fall ein optimales Ergebnis heraus kommt). <br>
2. Die SELECT-Anweisung wird in der WHERE-Einschränkung so erweitert, dass eine feststehende Einschränkung vorkommt, die den Optimizer "überlistet". Beispiel : <i>Select * from table where (test=@t) AND (test < 2)</i>. (das Beispiel wird so nicht weiterhelfen, es soll nur das Prinzip verdeutlichen)

[bigpoint]

Vielen Dank für die Antwort,

Sie schreiben mindestens 2 Möglichkeiten ( welche dann noch?)
Zur Möglichkeit 2
Meinen Sie hier die OPTION-Klausel ?? und wenn ja dann mit welchem Optionen
Können Sie so nett sein und ein Beispiel zu liefern

Vielen Dan

[bigpoint]

Ok ich habe rausgefunden, dass es sich um die WITH Klausel handelt.
Leider auch so komme ich nicht weiter.
Bitte um Hilf

[Andreas Kosch]

Hallo,

die verschiedenen Alternativen von OPTION (wie zum Beispiel </i>OPTION(KEEP PLAN)</i>) oder WITH (wie zum Beispiel <i>WITH (INDEX = xyz)</i>) müssen experimentell ausgeprobiert werden. Dies könnte zum Beispiel so aussehen:
<code>
SELECT *
FROM Tabelle WITH (INDEX = Tabelle_index)
WHERE CustomerID = 'OCEAN'
</code&gt

[bigpoint]

Hallo,

in meinem Fall handelt sich um so genannte CHECK – Einschrägungen, die kann ich (mein wissen nach) sowohl nicht in der OPTION Klausur auch nicht in der WITH ;(
Korrigieren Sie mich falls ich mich täusche

Gruß

bigpoin

[Andreas Kosch]

Hallo,
die beiden folgenden Abfragen werden vom MS SQL Server mit einem unterschiedlichen Ausführungsplan abgearbeitet: <br>
a) Select * from table where test=1 <br>
b) Select * from table where test=@t <br>
Ich würde daher im <i>Query Analyer</i> über <i>Abfrage | Ausführungsplan anzeigen</i> untersuchen, welcher Suchweg im Fall a) verwendet wird. Über die Alternativen OPTION bzw. WITH kann man dann versuchen, den gleichen Suchweg (Index) zu erzwingen, so dass sich auch im Fall b) die gleiche Anzeige von <i>Abfrage | Ausführungsplan anzeigen</i> wie im Fall a) ergibt

[bigpoint]

Hallo,

ja so habe ich auch gemacht im a) geht der SQL Server direkt zur die ziel Tabelle
und im fall b) durch alle zehn Tabellen durch.
Ich habe auch versucht den Fall b) so zu optimieren wie a), habe auch alle möglichen Optionen ausprobiert leider ohne Erfolg.
Ich glaube man kann den SQL Server in solchem Fall nicht optimieren.

Gruß

bigpoin