Glorf IT

Notiz an mich selber:

Für die "Visual Studio Team Edition for Database Professionals" (DBPro) gibt es Forum mit reger Beteiligung der Entwickler. Dort kann man erst mal Fragen stellen und muss nicht gleich Mails an Gert Drapers Himself schreiben!

Richard Waymire hat ein Security-Whitepaper für das "Visual Studio Team Edition for Database Professionals (aka Datadude)" veröffentlicht. Demnächst kommt es wohl auch in die MSDN.

Ich persönlich fand die Lektüre etwas dröge. Aber es richtet sich vermutlich an die internen IT-Sicherheitsabteilungen, um Klarheit zu schaffen, was wann genau passiert bzw. erlaubt werden muss. Genau aus diesem Anlass könnte es gut passieren, dass ich es mal dienstlich brauche…

Wer das neue "Visual Studio Team Edition for Database Professionals" (DBPro) testen will, kann sich dazu einfach die 180-Tage-Testversion der "Visual Studio Team Suite" bei Microsoft runterladen. Der Download ist etwa 3,2 GBytes schwer.

Weitere Links zum DBPro hier.

Hurra! Seit heute steht die Version 1.0 der "Visual Studio Team Edition for Database Professionals" in der MSDN zum Download bereit!

Man kann entweder die komplette DVD runter laden (sofern man eine MSDN-Subscription hat) (etwa 3 GB) oder falls man die "Visual Studio Team Suite" installiert hat, einfach die kostenlose x-Tage-Testversion installieren (20MB). Die Installation erkennt, dass man eine volle Lizenz hat und installiert damit auch die volle Version.

Es ist kein Upgrade der Projekte vor CTP6 möglich, man muss dann ein neues Projekt anlegen und die Files "en bloc" importieren. Mein mit CTP7 angelegtes Projekt wurde beim Öffnen automatisch von einem Wizzard transformiert. Danach ging alles wie vorher. Naja, vermutlich besser, aber ich hatte nicht so viel Zeit um die Feinheiten auszuprobieren.

Ich finde es spannend, was Gerd Drapers zur Entstehung schreibt:

It truly feels great to build a product from incubation to release within a year! 10358 check-ins; 315 daily builds; 7 CTP's; 19 developers, 14 testers; 4 program managers; 3 managers and one "DataDude" is what it took to get here. It has been a fun ride, but it ain't over, the "DataDude" is far from being done, there are many exciting new things coming your way. So please keep the feedback coming, we have and will continue to incorporate your feedback and requests in to the product, because we build this product only for you!

aus Data Dude : v1.0 RTM

Hier gibt es übrigens jede Menge Links zu dem Thema:
Database Professional Team Center

Im Microsoft TechNet gibt es übrigens eine Seite mit
Best Practices zum SQL-Server, bislang vorwiegend zur Performanceanalyse. Das ist eine Seite mit einer kleinen Sammlung an Links auf

Whitepapers, z.B.:

• Tom Davidsons Klassiker: SQL Server 2005 Performance Tuning using Waits and Queues – Ein Muss für jeder angehenden Tuning-Fachmann
• DBCC SHOWCONTIG Improvements and Comparison between SQL Server 2000 and SQL Server 2005 – Die Fragmentierung einer Tabelle untersuchen

SQL-Code-Snipets, z.B.:

• List Rarely-Used Indexes – Welche Indexe kosten Pflegeaufwand, aber bringen nichts?
• List Recompiled Statements – Damit kann man sich anzeigen lassen, welche Statements erneut kompiliert werden mussten. Gerade wenn man viele "kleine" Statements hat, dann bekommt die für einen Recompile benötigte Zeit starkes Gewicht.
• List Real Time Tempdb Task Usage – Damit kann man sich die aktuelle TempDB-Nutzung ansehen. Besonders nützlich, wenn man das eine ganze Zeit in einer Schleife abfragt und die Ergebnisse speichert.

und noch ein paar andere Dinge.

Insgesamt gesehen ist das schon mal ein Anfang. Mal abwarten wie sich das entwickelt…

Heute wurde ich durch einen Blogeintrag im Sqlservercode-Weblog auf die Datenbank-Option AUTO_UPDATE_STATISTICS_ASYNC aufmerksam. Dort wird aus den Books Online zitiert:

In SQL Server 2005, the database option AUTO_UPDATE_STATISTICS_ASYNC provides asynchronous statistics updating. When this option is set to ON, queries do not wait for the statistics to be updated before compiling. Instead, the out-of-date statistics are put on a queue for updating by a worker thread in a background process. The query and any other concurrent queries compile immediately by using the existing out-of-date statistics. Because there is no delay for updated statistics, query response times are predictable; however, the out-of-date statistics may cause the query optimizer to choose a less-efficient query plan.

Das ist interessant für Datenbanken deren Inhalte sich häufig ändert, z.B. regelmäßig viele Datensätze eingegeben oder gelöscht werden. Ich kann mich durchaus an mehrere Fälle in der Vergangenheit erinnern in denen unregelmäßig die Ausführung von Statements viel länger dauerte als es erklärbar war. Im Nachhinein deutet vieles daraufhin, dass da die Statistiken nicht mehr aktuell waren und vor der Zusammenstellung des Zugriffsplans aktualisiert werden mussten. Das wird mir aber erst jetzt klar.

Statistiken werden für jeden Index angelegt, man kann sie manuell anlegen (auch für indexierte Views) und manchmal werden sie automatisch angelegt, wenn zu wenige Indexes auf der Tabelle liegen. Das Verhalten kann also jeden treffen. Die Option einzuschalten ist aber nur dann sinnvoll, wenn auch ein Zugriffsplan basierend auf veralteten Statistiken noch eine akzeptable Performance bietet. Ich würde vermuten, dass dies bei sinnvoll vergebenen "clustered indexes" meist der Fall ist und die "dicksten" Abfragen den Clustred-Index verwenden. Da muss man aber jeweils genauer hinsehen.

Generell begeistert mich der Gedanke, dass der SQL-Server-2005 diese zeitaufwändige Aktion dann macht, wenn er gerade wenig zu tun hat. Aber logischerweise bringt die Option nur dann einen Vorteil, wenn die (mehrfache) Ausführung eines Statements mit einem "alten" Zugriffsplan immer noch schneller ist als die Aktualisierung der Statistik(en) und die anschließende (mehrfache) Ausführung des Statements.

Auf dem Weblog von Camerons einem Entwickler des Database-Professionals-Plugin für das DevStudio finden sich genau zu dem Thema jede Menge nützliche Informationen.

Beispielsweise warum es mir auch nach dem xten Anlauf nicht gelang das CTP7 zu installieren: Man braucht die "Visual Studio Team Suite ( VSTS )", ich habe aber nur die "Visual Studio Team Edition für Software Developer". 🙁

In order to ready ourselves for RTM, CTP7 will now require a retail version of Visual Studio Team Suite ( VSTS ) or the trial version of VSTS ( found here ). Why is this? That is how our evaluation process will work once released. If a customer is looking to evaluate VSTS or any role based product in the suite, they are required to download the VSTS trial bits. We are very close to releasing the product, so we are essentially providing you access to CTP7 in evaluation mode.

Außerdem kann man dort nachlesen, dass das RTM am 30.11.2006 herauskommt…

Wer sich für SQL interessiert und den Blog "Joe Celko – The SQL Apprentice" noch nicht kennt, hat etwas verpasst. Hier sammeln Fans von Joe Celko dessen Antworten auf Fragen in Newsgroups. Joe ist einer der SQL-Gurus, er saß/sitzt im SQL-Standardisierungsgremium, und beteiligt sich "schon immer" sehr rege in SQL-Foren. Früher habe ich mir in der Firma nur deswegen einen CompuServe-Zugang verschafft, damit ich "seine Newsgroup" lesen konnte.

In dem Artikel "sql statement" geht es um die interne Arbeitsweise von SQL-Statements. Wenn man über seine bissigen Kommentare lachen kann, wird man es genießen. Seine Antwort auf eine Frage inkl. Code-Sample beginnt so:

Well, your names are a nightmare that violate common sense and ISO-11179 rules, but for now, you do not understand how a SELECT (GROUP BY in particular) work:

Here is how a SELECT works in SQL … at least in theory. Real products will optimize things, but the code has to produce the same results.

Man lernt immer wieder dazu… Besonders, wenn man mal in Handbüchern stöbert…

Am SQL Server 2000 (und vorher) ist es völlig "legales" SQL, wenn ich Folgendes schreibe:

select: Orderid, Employeeid, CustomerID
from: northwind.dbo.orders
where: CustomerID like 'A%'

Am SQL Server 2005 wurde diese Syntax jetzt verboten. Ich würde fast vermuten, dass es sich dabei nicht um ein beabsichtigtes Feature gehandelt hat.
Es erinnert mich eher an die Syntax-Kuriositäten von neulich.

Im ersten Teil der Serie “Vorschläge zur Datensicherung mit SQL-Server” habe ich ein paar Dinge zum Umfeld und zum Verständnis geschrieben. Im zweiten Teil beschrieb ich das Vorgehen beim Offline-Backup, im dritten die Online-Vollsicherung. In diesem Teil gehe ich auf die differentielle bzw. inkrementelle Online-Sicherung ein. Dabei wird im laufenden Betrieb nur der geänderte Inhalt der Datenbank mit Bordmitteln des SQL-Servers gesichert.

Ablauf

• Datenbank-Prüfung
• Datenbank-Sicherung
• Archivierung der Sicherungsdateien

Datenbank-Prüfung

Hier gilt genau das gleiche wie bei den Sicherungsarten: Immer schön brav kontrollieren, ob ein Fehler entdeckt wurde. Man kann sich ja auch eine Mail schreiben lassen, wenn ein Problem entdeckt wurde. Das ist aber eine andere Geschichte…

Datenbank-Sicherung

Mit dem Backup-Befehl wird nur der geänderte Inhalt der Datenbank gesichert. Dazu wird der Inhalt von benutzten Seiten in die Sicherungsdatei rausgeschrieben. Im Gegensatz zur Vollsicherung, werden aber wirklich nur die geänderten Seiten gesichert. Hat sich auf einer Datenbankseite nur ein Bit geändert, dann wird dennoch die komplette Seite gesichert.

• Bei der inkrementellen Sicherung werden alle Seiten geschrieben, die sich seit der letzten Sicherung geändert haben. Dabei ist es irrelevant, ob das eine inkrementelle oder volle Sicherung war. Jedesmal entsteht so etwa gleichgroße Sicherungsdatei. Sie müssen alle archiviert werden.
• Bei der differentiellen Sicherung werden alle Seiten gesichert, die sich seit der letzten Vollsicherung geändert haben. Bei der nachfolgenden Sicherung werden also auch die Seiten gesichert, die schon vorher differentiell gesichert wurden. Nach einiger Zeit wird der zu sichernde Teil der Datenbank immer größer, in manchen Fällen ist es auch schon wieder fast eine Komplettsicherung.

Der Ablauf sollte in beiden Fällen so sein, dass regelmäßig Vollsicherungen durchgeführt werden (z.B. am Wochenende) und dazwischen in kleineren Abständen die differentielle bzw. inkrementelle Online-Sicherung (also z.B. jeden Werktag).

Die Verfahren unterscheiden sich beim Vorgehen der Rücksicherung:

• inkrementelle Sicherung: Zunächst muss die letzte Vollsicherung zurückgesichert werden und dann jede einzelne inkrementelle Sicherung, die seitdem gemacht wurde, in der richtigen Reihenfolge. Das ist recht mühsam und erfordert gute Nerven, außerdem sollte das kein Laie machen müssen.
• differentielle Sicherung: Auch hier wird zuerst die letzte Vollsicherung eingespielt und dann die letzte differentielle Sicherung. Das ist also erheblich schneller und einfacher als die Rücksicherung der inkrementellen Sicherung.

Archivierung der Sicherungsdateien

Nach der Sicherung müssen die entstandenen Sicherungsdateien noch auf ein dauerhaftes Medium archiviert werden. Auch hier ist darauf zu achten, dass die Archivierung erst nach dem Ende der SQL-Server-Sicherung beginnt.

Bitte beachten Sie, dass ich in diesem Artikel nicht von einer Differenzsicherung auf Datei-Ebene spreche. Das ist ein komplett anderes Verfahren und meiner Ansicht nach beim SQL-Server nicht sinnvoll einsetzbar.

Vorteile

• Diese Methoden sind sehr schnell.
• Diese Methoden ermöglichen einen 7x24-Stunden-Betrieb.

Risiken und Nebenwirkungen

• Für diese Sicherungsmethode muss man grundlegende Kenntnisse über Datenbanksystemen haben.
• Man muss ein SQL-Server-Werkzeug verwenden (oder SQL beherrschen) und mit der "normalen" Sicherung koordinieren.
• Die Rücksicherung erfordert gute Vorbereitung und einen guten Admin.
• Ist eine der Dateien aus der inkrementelle Rücksicherung defekt, dann können auch nachfolgende Sicherungen nicht mehr eingespielt werden.

Mein persönliches Resümee:

Wenn man einen 24x7-Stundenbetrieb gewährleisten muss und die regelmäßige Vollsicherung in Kombination mit dem Full-Recovery-Mode nicht in Frage kommt, weil bspw. die Sicherungsdateien zu groß werden oder die Sicherung zu lange dauern würde, dann bleibt kaum etwas anderes übrig als die differentielle oder inkrementelle Sicherung zu verwenden. Eine Alternative stelle ich in dem nächsten Artikel mit dem VSS vor.

Die differentielle Sicherung ist dann die richtige Wahl, wenn in einem Zeitraum von etwa einer Woche immer wieder die gleichen Daten geändert werden. Dann würde Größe und Dauer der Sicherung nur langsam wachsen.
Wird hingegen in Sicherungszeitraum ein sehr großer Teil der Daten geändert, dann mutiert die differentielle Sicherung ja schon fast zu einer Komplettsicherung. In diesem Fall ist die kompliziertere inkrementelle Sicherung zu bevorzugen.

Im nächsten Artikel aus der Serie stelle ich die "Snapshot"-Sicherung vor.

Bei SqlTeam.com habe ich ein verblüffendes Beispiel für unerwartete Syntax-Ergebnisse gefunden:

SELECT 123.654,
123e6,
123d4,
'123'e4,
123'col2',
1a

Das liefert erstaunlicherweise:

So Parser liefern schon mal komische Ergebnisse. Ich habe mal versucht den LEXX und YACC zu verstehen, aber es dann recht schnell aufgegeben. Immerhin ist klar, dass der SQL-Server die Buchstaben nach den Nummern als Aliase interpretiert. Das "Wort" hört für ihn nach der Zahl auf.

Was im ersten Moment wie eine neue Idee für ein Musikportal klingt, ist in Wirklichkeit eine gute Idee zur Qualitätssicherung.
Microsoft möchte gerne automatisierte Tests mit echten Daten und echten Anwenderszenarien durchführen. Damit können sie bei zukünftigen SQL-Server-Hotfixes und -SPs einfach ein "Replay" der eingeschickten Profiler-Traces machen und sehen, ob irgendwelche Fehler auftreten. Das ist zwar für uns Kunden schon einiger Aufwand (Auswahl der Szenarien, Aufzeichnen, Testen, einschicken), aber dürfte sich auch für uns lohnen, damit wir nicht erst einen Bug anmelden müssen, wenn der SP erst mal da ist.

Details beschreibt Steffen in seinem Artikel "SQL Playback Programm – Ihre Workload als Test für zukünftige SQL Server Versionen".

Das machen wir übrigens auch seit einigen Jahren, allerdings ist das wegen des notwendigen Datenschutzes nicht ganz so einfach: Man benötigt für einen genau festgelegten Zeitraum die schriftliche Erlaubnis des Anwenders, die Rechner dürfen nicht im Firmennetz hängen, müssen in speziell gesicherten Räumen stehen, muss danach alle Kopien "erasen" (einfach Löschen reicht nicht) und muss die Datenträger zurückschicken (oder darf sie im Auftrag des Kunden gleich zur Vernichtung schicken).

Trotz des ganzen Theaters lohnt sich der Aufwand: in unseren "normalen" Tests finden wir eben doch nicht alle Probleme…