|
[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] Es ist wichtig, dass man die gewünschte Datenbank unter der Combobox "DB:" anwählt. In diesem Fall wurde die Datenbank "test1" angewählt. Der Query Analyzer ist quasi das Standard Sprachrohr zum SQL Server. Im oberen Bildschirmbereich geben Sie die T-SQL Befehle ein, führen diese entweder durch Selektion und CTRL+E oder den grünen Pfeil in der Toolbar aus. In der unteren Hälfte des Bildschirmes erhalten Sie einen Feedback. Falls der abgesetzte T-SQL Befehl Datensätze zurückgibt, werden diese in der unteren Hälfte angezeigt. Hierzu ist es manchmal nützlich zu wissen, dass es eine Option "Results in Grid" gibt, welche das Resultat statt in ein Textfile in ein Grid mit Zeilen und Spalten stellt.
Ebenso überlebensnotwendig ist der Execution Plan. Seit der Version 7.0 gibt es Ihn nun auch graphisch. Das ist, ähnlich wie bei den DTS Packages vielleicht ein wenig verspielt, aber praktisch ist es schon. Vor allem, wenn man eine wirklich komplizierte Query absetzt. Hier ein ganz einfaches Beispiel:
Dieser Execution Plan ist es, der Ihnen ehrlich und unbeschönigt sagt, ob Ihre geniale Select Anweisung nun optimiert werden kann oder nicht. Wenn Sie irgendwo "Table" Scans sehen, dann haben Sie schlechte Karten. Das bedeutet nämlich, dass alle Datensätze auf dem SQL Server einzeln durchgegangen werden. Es ist klar, dass bei einer grösser werdenden Tabelle die Antwortzeiten entsprechend grösser werden. Der ProfilerDer Profiler ist quasi der Spion, der alles aufzeichnet, was beim SQL Server wirklich ankommt. Das ist vor allem dann sehr nützlich, wenn eine Remote View "defekt" ist und wirre Fehlermeldungen resultieren. Um eine neue Trace Spur aufzusetzen, muss man sich durch den Trace Properties Dialog durcharbeiten. Es gibz dort eine Reihe von Einstellungen, um die individuellen Trace Bedürfnisse abzudecken. Vor allem auch wenn auf einem SQL Server verschiedene Programme betrieben werden während dem man einen Trace startet ist es unumgänglich, den eigenen Trace sinnvoll einzuschränken.
Data Transformation ServicesWill man mit der SQL Server 7.0 Platform seriös arbeiten, kommt man natürlich auch nicht um die DTS herum. Diese sind so leistungsfähig und vielseitig einsetzbar, dass ich an dieser Stelle nur das wichtigste aufzeigen kann. Ich denke aber, dass es einfach ist, nach einer kurzen Einführung eigene DTS Pakete entweder Wizard gesteuert zu erstellen, oder aber mit VB Script und VFP COM Komponenten anzureichern. Dadurch lassen sich nun wirklich alle nur denkbaren Daten Imports und Exports zwischen SQL Server, VFP oder irgendwelchen anderen via ODBC oder ADO zugänglichen Datenbanken und Fileformaten bewerkstelligen. Ich werde während der Session ein einfaches DTS Beispiel, sowie eines mit VB Script Erweiterungen und eines mit einer VFP 6.0 COM Komponentenerweiterung zeigen. Hat man das einmal gesehen, ist DTS tatsächlich kein Buch mehr mit sieben Siegeln, sondern eine wirklich nützlich Datentransformationsumgebung. Datenbank TransaktionenBei allen Transaktionen geht es immer wieder um dasselbe Grundproblem: Wie stelle ich sicher, dass eine Abfolge von einzelnen Operationen als ganzes, untrennbares Paket betrachtet wird. Hierbei muss sichergestellt werden, dass nicht Teile meines Gesamtpaketes erfolgreich abgeschlossen werden und andere hingegen nicht. Nur wenn alle im Paket enthaltenen Operationen erfolgreich waren, dürfen alle darin enthaltenen Operationen bestehen bleiben. Oder umgekehr formuliert: Sofern auch nur eine einzige Operation innerhalb einer gesamten Transaktion fehlgeschlagen hat, müssen alle Änderungen, welche durch irgendeine andere Operation in derselben Transaktion ausgelöst wurden, wieder rückgängig gemacht werden. Um sicher zu gehen, dass meine Transaktion möglichst sicher und erfolgreich abgeschlossen werden kann, würde es an und für sich genügen, alle Tabellen, welche innerhalb der Transaktion angesprochen werden, vor Zugriffen anderer Transaktionen und oder Datenbank Benutzer zu schützen. Wir alle wissen, wie so etwas am einfachsten zu bewerkstelligen ist: Mit einem möglichst "grobkörnigen" Locking Mechanismus, z.B. auf Stufe Tabelle mit einem "Table" Lock. Es ist klar, dass bei weniger grobkörnigen Locking Mechanismen, wie z.B. "Page" Locking oder "Record" Locking die Gefahren zunehmen, dass v.a. bei Transaktionen mit mehreren Einzeltransaktionen Konflikte entstehen, da die Daten, auf welche in der Transaktion zugegriffen werden soll, evtl. nicht verfügbar sind. In der Praxis haben wir es hier mit einem ausgewachsenen Zielkonflikt zu tun und wir haben abzuwägen, wie fein wir unsere Datensätze wirklich sperren wollen um unsere eigene Transaktion zu bevorzugen, ohne jedoch andere Transaktionen und Datenbank Benutzer zu stark einzuschränken. Dieser Zielkonflikt ist unvermeidlich. Würde er nicht existieren, bräuchte man sich in der Welt der Datenbank Transaktionen um einiges keine Gedanken zu machen. In Tat und Wahrheit ist es aber so, dass alle Datensätze, welche im Zusammenhang mit einer Transaktion verändert werden, für andere Benutzer oder Transaktionen nicht mehr, oder nur mit Einschränkungen (wie wir weiter unten noch sehen werden), zur Verfügung stehen. Deshalb ist es unausweichlich, sich mit den Mechanismen von Datenbank Transaktionen seriös auseinanderzusetzen. Soll Eigenschaften von Transaktionen: ACIDTransaktionen müssen von sich aus schon so konzipiert sein, dass möglichst wenig Konfliktpotential entsteht, wenn Sie abgearbeitet werden. Wichtig ist in diesem Zusammenhang, dass sich Transaktionen an einige Grundregeln halten. Werden diese eingehalten, so haben wir mit einer gewissen Wahrscheinlichkeit ein erfolgreiches Betreiben der Transaktionen ermöglicht. Die Abkürzung ACID steht hierbei für folgendes: AtomicAtomar: Eine Transaktion soll als unzertrennbares Atom betrachtet werden, entweder als ganzes erfolgreich, oder als ganzes nicht erfolgreich. Das Atom darf quasi nicht gespalten werden. ConsistentKonsistent: Einzelne Operationen innerhalb einer Transaktion müssen bereits konsistent sein. Sie dürfen nicht bestehende Datenbank oder Business Regeln weder explizit noch implizit verletzen. IsolatedIsoliert: Das System muss noch nicht bestätigte Veränderungen einer Transaktion vor allen anderen Transaktionen schützen. Dieses Schützen erfolgt i.d.R. durch Locking der in der Transaktion beteiligten Datensätze. DurableBeständig: Wenn eine Transaktion bestätigt wurde, dann muss die Datenbank in der Lage sein, alle vorgenommenen Veränderungen permanent zu speichern. Im Falle eines Systemausfalles müssen diese wieder hergestellt werden können. Die Locking Mechanismen des SQL ServersDer SQL Server besitzt seit der verseion 7.0 neu auch die Möglichkeit des Record Lockings. In SQL Server 6.5 gab es dies nur bedingt, d.h. nur beim Einfügen von neuen Datensätzen am Ende einer Tabelle in der letzen Daten Seite. Das Vorhandensein des Record Locking Features sollte jedoch nicht darüber hinwegtäuschen, dass es trotzdem durchaus Sinn machen kann, wenn man seitenweise lockt. Auf einer Seite sind mehrere Datensätze untergebracht und durch eine Page Lock Operation können mehrere Datensätze in Serie rascher upgedated werden als wenn dies mit einzelnen Record Locks zu erfolgen hätte. Bei einem SQL Statement kann man mit sogenannten "Locking Hints" steuern, wie granular gelockt werden soll: obiges SQL Statement würde alle Datensätze einzeln mir Record Locks abwickeln. Folgende SQL Server Locking Hints gibt es:
Der SQL Server unterscheidet zwischen "Write" Locks und "Read" Locks. Die "Write" Locks werden auch als "Exclusive" Locks bezeichnet und die "Read" Locks auch als sogenannte "Shared" Locks. Ein "Write" Lock ist mit einem anderen "Write" Lock im Konflikt, und auch mit anderen "Read" Locks. "Read" Locks hingegen sind grundsätzlich mit anderen "Read" Locks nicht im Konflikt. Es ist aber wichtig zu verstehen, dass eine Transaktion keinen "Write" Lock erhalten kann, wenn gerade ein "Read" Lock offen ist. Diese fundamentale Eigenschaft des SQL Servers stellt sicher, dass Daten, welche gerade in einer Transaktion gelesen werden, nicht gleichzeitig verändert werden können. [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ]
|
