Glorf IT

Jeff Smith hat in seinem Weblog ein paar Datumsfunktionen bereitgestellt, die man nutzen kann. Sie sind komplett in TSQL geschrieben und liefern alles, was man so braucht, wenn man mit Datümern im SQL-Server arbeiten will.

In den ersten Betas des SQL-Servers-2005 gab es endlich die Datentypen DATE und TIME. Leider waren sie in .Net implementiert. Als sich langsam heraus kristalisierte, dass .Net mehr Performance kostet als MS lieb war, vielen sie der Schere zum Opfer. Natürlich kann man sich leicht selber DATE- und TIME-Typen schreiben, oder die originalen von MS nehmen (ich bin sicher sie stehen irgendwo im Netz rum), aber dann muss man halt die CLR in die Datenbank importieren. Wenn man sowieso vor hat .Net zu verwenden, dann sollte man sich den Gefallen tun und die Datentypen inkl. der benötigten Funktionen gleich mit rein zu nehmen.

Wenn man das liebt nicht will, dann sind die Funktionen von Jeff Smith eine sehr gute Alternative. Ich habe keine Performance-Messungen gemacht, aber der Code sieht für mich sehr sauber aus.

Hier ist der komplette Artikel "Essential SQL Server Date and Time Functions".

Bei "The Code Project" wurde letzte Woche ein interessantes Projekt veröffentlicht: Mittels DotNet-Methoden werden BLOB-Daten ("Binary Large OBject") komprimiert gespeichert: Mit Hilfe der Funktionen fn_compress und fn_decompress werden die BLOBs geschrumpft oder aufgepustet.

Ich finde die Idee sehr interessant, aber habe auch Bedenken.
Das ist eine gute Möglichkeit den Leistungsumfang von SQL mittels CLR zu erweitern und eine Aufgabe zentral zu erledigen. Andererseits kostet das wertvolle CPU-Zeit am Server. Wenn man sehr keine und dumme Clients hat, dann ist das sicher trotzdem ein gute Wahl. Wenn ich normale PCs als Clients habe, dann lohnt es sich sicher die Daten schon vor der Übertragung zu komprimieren. Dann schont es Bandbreite im Netz und die CPU des Servers wird geschont.

Wenn man es schon so machen will, dann würde ich die Lösung erweitern: Man kann einen neuen Datentyp schaffen, der die Komprimierung und Dekomprimierung ohne explizitem Befehl erledigt. Dazu muss man lediglich die Methoden zur Serialisierung bzw. dem Lesen der Daten entsprechend programmieren.

Details stehen im Artikel "Using CLR integration to compress BLOBs/CLOBs in SQL Server 2005".

Selbst wenn man sich die neue DevStudio-Edition "DBPro" (inkl. der netten Werkzeuge) nicht leisten mag/kann und einem die 180-Tage-Testversion zu groß ist, dann muss man nicht auf die Funktion TableDiff verzichten.

Dieses kleine Programm kommt mit dem SQL-Server-2005 mit und ist eigentlich für die Replikation gedacht. Es steht unter ":\Programme\Microsoft SQL Server\90\COM\tablediff.exe" zur Verfügung. Damit kann man den Inhalt einer Tabelle intelligent von einer DB in die andere kopieren.

Es bietet auch die Möglichkeit, einen echten Diff zwischen zwei Tabellen durchzuführen, auch zwischen 2000 und 2005. Im folgenden Beispiel habe ich der Übersichtlichkeit halber die Befehlszeile umgebrochen:

"C:\Programme\Microsoft SQL Server\90\COM\tablediff.exe"
-sourceserver "MyBigPC\MyYukon" -sourcedatabase "Northwind"
-sourceschema "dbo" -sourcetable "Orders"
-sourceuser sa -sourcepassword samplepwd
-destinationserver "MyBigPC\MyLittleSQL" -destinationdatabase "Northwind"
-destinationschema "dbo" -destinationtable "Orders"
-destinationuser sa -destinationpassword samplepwd
-f
Microsoft (R) SQL Server Replication Diff Tool
Copyright (C) 1988-2005 Microsoft Corporation. All rights reserved.

Table [Northwind].[dbo].[Orders] on MyBigPC\MyYukon and Table [Northwind].[dbo].[Orders] on MyBigPC\MyLittleSQL are identical.
The requested operation took 0,46875 seconds.

Wenn ein Unterschied besteht, dann sieht der Output so aus:

Table [Northwind].[dbo].[Orders] on MyBigPC\MyYukon and Table [Northwind].[dbo].
[MyOrders] on MyBigPC\MyLittleSQL have 26 differences.
Fix SQL written to DIFFIX.633029232857656250.sql.
Err OrderID Col
Src. Only 11052
Src. Only 11053
Src. Only 11054
Src. Only 11055
Src. Only 11056
Src. Only 11057
Src. Only 11058
Src. Only 11059
Src. Only 11060
Src. Only 11061
Src. Only 11062
Src. Only 11063
Src. Only 11064
Src. Only 11065
Src. Only 11066
Src. Only 11067
Src. Only 11068
Src. Only 11069
Src. Only 11070
Src. Only 11071
Src. Only 11072
Src. Only 11073
Src. Only 11074
Src. Only 11075
Src. Only 11076
Src. Only 11077
The requested operation took 0,296875 seconds.

Und in der "Fix-Datei" steht dann (gekürzt):

-- Host: MyBigPC\MyLittleSQL
– Database: [Northwind]
– Table: [dbo].[Orders]
SET IDENTITY_INSERT [dbo].[Orders] ON
INSERT INTO [dbo].[Orders] ([CustomerID],[EmployeeID],[Freight],[OrderDate],[OrderID],[RequiredDate],[ShipAddress],[ShipCity],[ShipCountry],[ShipName],[ShippedDate],[ShipPostalCode],[ShipRegion],[ShipVia]) VALUES ('HANAR',3,67,2600,'1998-04-27 00:00:00.000',11052,'1998-05-25 00:00:00.000','Rua do Paço, 67','Rio de Janeiro','Brazil','Hanari Carnes','1998-05-01 00:00:00.000','05454-876','RJ',1)
INSERT INTO [dbo].[Orders] ([CustomerID],[EmployeeID],[Freight],[OrderDate],[OrderID],[RequiredDate],[ShipAddress],[ShipCity],[ShipCountry],[ShipName],[ShippedDate],[ShipPostalCode],[ShipRegion],[ShipVia]) VALUES ('PICCO',2,53,0500,'1998-04-27 00:00:00.000',11053,'1998-05-25 00:00:00.000','Geislweg 14','Salzburg','Austria','Piccolo und mehr','1998-04-29 00:00:00.000','5020',NULL,2)
…
INSERT INTO [dbo].[Orders] ([CustomerID],[EmployeeID],[Freight],[OrderDate],[OrderID],[RequiredDate],[ShipAddress],[ShipCity],[ShipCountry],[ShipName],[ShippedDate],[ShipPostalCode],[ShipRegion],[ShipVia]) VALUES ('RATTC',1,8,5300,'1998-05-06 00:00:00.000',11077,'1998-06-03 00:00:00.000','2817 Milton Dr.','Albuquerque','USA','Rattlesnake Canyon Grocery',NULL,'87110','NM',2)
SET IDENTITY_INSERT [dbo].[Orders] OFF


Wenn man auch Unterschiede in den Datensätzen ("auf Spaltenebene") sehen will, dann ist die Option "-c" interessant.

Nützlich, oder?

Alle, die mitgemacht haben wurde gestern benachrichtigt, dass die Ergebnisse des OLAP Survey 6 verfügbar sind. Man kann sich dort gegen Angabe der persönlichen Daten eine "Preview" schicken lassen. Die volle Version kostet fast 3,5KiloDollar. Bei BARC kostet die deutsche Fassung der deutschen Ergebnisse "nur" 1,7 KiloEuro.
😐

In der mir zugesandten Summary gibt es viele interessante Dinge. Beispielsweise, dass der Anteil der Windows-Plattfomen unverändert hoch ist (etwa 84%), die Unix/Linux-Systeme (etwa 14%) und andere weiterhin abgeschlagen rumdümpeln.
Die Datenquellen für OLAP-Systeme sind in der Regel weiterhin Oracle oder Microsoft-Systeme. Allerdings hat Microsoft erstmals die Nase vorn: mit 48,1% zu 46,8%.

Falls sich mal einer Eurer Kunden ziert Geld für die Datensicherung auszugeben, dann könnt Ihr ihm unter die Nase reiben, dass Gewerbetreibende verpflichtet sind für eine funktionierende Datensicherung zu sorgen, sonst handeln sie fahrlässig. Die genauen Formulierungen aus einem Urteil zu einem Datenverlust bei Computer-Reparatur des OLG Hamm (Urteil vom 01. Dezember 2003, 13 U 133/03) sind ausnahmsweise auch für mich Nichtjuristen verständlich und IMHO gut zu verallgemeinern:

Wie dargelegt, gehört es im gewerblichen Anwenderbereich heute zu den vorauszusetzenden Selbstverständlichkeiten, dass eine zuverlässige, zeitnahe und umfassende Datenroutine die Sicherung gewährleistet. Vor einem objektiv datengefährdenden Eingriff muss sich der Werkunternehmer zwar danach erkundigen und gegebenenfalls darüber vergewissern, ob die vom Anwender vorgenommene Datensicherung dem aktuellen Stand entspricht. Zusätzliche Überprüfungspflichten bestehen jedoch nur dann, wenn ernsthafte Zweifel vorliegen, dass die Datensicherung nicht ordnungsgemäß erfolgt ist oder das Sicherungssystem nicht funktioniert (OLG Karlsruhe NJW 1996, 2000; OLG Köln NJW-RR 1997, 558; 1994, 1262; BGH NJW 1996, 2924; Senat in OLGR 2000, 195).

Die Hervorhebungen (oben und unten) sind von mir. In dem Fall hat ein beauftragter EDV-Fachmann eine Reparatur vorgenommen und sich vorher erkundigt, ob es eine aktuelle Datensicherung gibt (für den Fall, dass etwas schief geht). Das wurde bejaht, aber wie sich später herausstellte, gab es zwar keine Datensicherung, aber Datenverluste traten trotzdem auf. Deswegen wollte der Beklagte dem Installateur die Bezahlung kürzen. Das Gericht hat die Sache aber sehr eindeutig geklärt.
Hier noch eine Passage in der der Beklagte sein Fett weg bekommt:

Die Sicherung hätte täglich erfolgen müsse, die Vollsicherung mindestens einmal wöchentlich. Das ist unstreitig nicht geschehen. Aus den Bekundungen des Zeugen N hat der Sachverständige zu Recht entnommen, dass die Sicherung von Daten im Betrieb der Beklagten schon grob fahrlässig (blauäugig) vernachlässigt wurde. […] Unter diesen Voraussetzungen hat sich die Beklagte den Schaden allein zuzurechnen, selbst wenn der Klägerin eine Pflichtverletzung im Sinne der Wahrnehmung von Controllpflichten vorzuwerfen wäre (vgl. BGH NJW-RR 1991, 1240).

Den kompletten Text gibt es bei aufrecht.de

Ergänzend dazu finde ich auch den Artikel "Urteil: Datensicherung ein Muss" bei rechtsanwalt.com interessant.

Das sind zwar schon olle Kamellen, aber neulich schrieb ich: "Wer nicht sichert, hat schon fast verloren." Das wollte ich mal näher begründen…

Erstaunlicherweise hat die Presse das Thema SQL-Server und Vista bisher nicht aufgegriffen. Das jetzt ausgerechnet "money.cnn.com" die Fährte aufnimmt, weil sie ernsthafte Einbrüche der Marktanteile für den SQL-Server erwarten!? Der Grund liegt daran, dass MS immer noch keine Version anbieten kann, die unter Vista läuft. Derartige Infos seitens der Presse habe ich (so kurz vor erscheinen des rettenden SP2 für SQL2005) nicht mehr erwartet.

Süffisant beschreiben sie, wie MS sich von IBM vorführen ließ:

Microsoft has effectively just handed its chief rivals an early holiday present. […]

This, of course, is exactly the opposite of what Microsoft should be doing if it hopes to outsell Oracle and IBM in the database business. Microsoft should have released a Vista-compatible version of SQL Server as early as a year ago. That way, corporate customers would have had plenty of time to test it in time for Vista's release.

Instead, IBM has beaten Microsoft to the punch. Last week IBM released a desktop version of its competing database management software, called DB2 9 Express-C, that's compatible with Vista.

Die lange Fassung steht unter "Microsoft's Vista isn't compatible with SQL Server".

Ich persönlich finde ja den dickeren Hammer, dass die MSDE, die ja noch mehrere Jahre von MS unterstützt wird, nicht unter Vista lauffähig ist. Die Unterstützung gilt halt nur für alte Betriebssysteme.

Unrealistische Erwartungen an die Selbstheilkräfte der Hardware

Gestern erlebten wir leider wieder einen von den Fällen in denen eine völlig defekte Datenbank eines Kunden an uns geschickt wurde, damit wir sie analysieren und retten was zu retten ist. Genau der Kunde hatte aber schon mal Datenbanken an uns geschickt. Mit nur geringen Datenverlusten konnten damals wieder konsistente Datenbestände restauriert werden. Seinerzeit wurde ihm mitgeteilt, dass seine Hardware ein Problem hat und sein EDV-Händler/-Betreuer das untersuchen und lösen soll, vermutlich ein Problem mit Festplatte und/oder Raid-Controller. Das passierte aber nicht…
Nun hat es eine Datenbank von ihm besonders schlimm erwischt. Reparaturversuch erfolglos. Datensicherung: Fehlanzeige.
Was soll man dazu sagen?

Unrealistische Erwartungen an die Haftung der Softwarelieferanten

Das ist leider kein Einzelfall. Besonders frustrierend sind die Fälle in denen man sich unheimlich reinhängt und stundenlang analysiert (weil der Kunde keine Datensicherung hat), aber unter dem Strich doch nichts oder nur wenig zu machen ist. Die meisten Kunden sind dankbar für die Unterstützung. Aber einige versuchen doch tatsächlich bei solchen Totalausfällen unsere Firma für deren Ausfallzeiten haftbar zu machen. Manche wollten sogar die neue Hardware über uns finanzieren…
Meist sind das diejenigen, die auch schon während der Analyse Druck machen, mehrfach anrufen oder von den Kollegen umfassende schriftliche Statusberichte fordern und somit von der Unterstützung abhalten, die sie eindringlich einfordern. Da spielt die Psychologie auch immer eine große Rolle: Schuldgefühle und Verzweiflung ergeben eine explosive Mischung. Dann muss es ganz hektisch gehen, aber dennoch akkurat und fehlerlos.
Wenn sie nur ein Bruchteil des Engagements gezeigt hätten, als es um die Einrichtung der Datensicherung ging, dann wäre ihnen viel Kummer und Leid erspart geblieben. Wer nicht sichert, hat schon fast verloren…
🙁

Das bringt mich darauf, dass ich die Serie mit Hinweisen zur Datensicherung noch nicht abgeschlossen habe. Das ist jetzt in meinem Stack wieder ganz oben.
😉

Wer es nicht erwarten kann oder professionelle Interessant hat, der kann seit gestern eine Vorabversion des SP2 für den SQL-Server-2005 ausprobieren, genauer geht es hier um den CTP3. Er ist schon recht stabil, die Freigabeversion wird wohl bald folgen.

Infos und Download-Links gibt es im Artikel "How to obtain the latest service pack for SQL Server 2005".

Die Liste der mit SP2 behobenen Probleme klingt imposant. Und das sind ja nur die dokumentierten Änderungen…
😉

Die ReadMe und das Feature-Pack (enthält das gute alte MDAC und weitere "Redistributables") werden auch zum separaten Download angeboten. Alle Download, die nur irgewas mit SQL-Server zu tun haben, findet man bei MS auf der Seite mit dem originellen Titel "Downloads für Microsoft SQL Server 2005"…

Mir gefällt am DBPro (Visual Studio Team Edition for Database Professionals) einfach unheimlich gut, dass man damit jetzt endlich auch in der Microsoft-Welt so Datenbanken entwickeln kann, wie man es mit der Software macht: offline, lokal getestet, archiv-unterstützt und im Team.

So ist es von MS gedacht:

• Man richtet pro Datenbank ein Projekt ein, dass an das Archiv (z.B. Team System) angebunden wird. Vorhandene Datenbanken können ganz leicht importiert werden.
• Man bearbeitet seine Datenbank ohne direkt in einer konkreten Datenbank rum zu wurschteln, wie man es mit dem "Enterprise-Manager" (Friede seiner Asche) oder dem "Managament-Studio" machen würde.
• Trotzdem hat man Syntax-Check und Konsistenz-Check für bspw. Stored-Procedures. Alle Fehler im Projekt werden in einer Übersicht angezeigt, vergleichbar mit dem Ergebnis eines Compilerlaufs.
• In einem "Build"-Lauf kann man sich die Skripte zur Erstellung der Datenbank "from the scratch" zusammenbauen lassen, die man entweder selber mit sqlcmd.exe einspielen kann oder
• mit einem "Deploy" gleich ausführen kann. Dann wird auf dem in den Projekt-Properties angegebenen Server die DB angelegt.
• Dann kann man alles mit den Unit-Tests für SQL testen und nötigenfalls nachbessern.
• Testdaten kann man sich dazu automatisch generieren lassen.
• Ist man fertig, dann werden alle Änderungen ins Archiv übernommen und stehen für jeden zur Verfügung.
• Um bestehende Datenbanken auf den neuen Stand zu transformieren, kann man sich Delta-Skripte erstellen lassen: zwischen zwei DBs oder zwischen zwei Ständen im Archiv oder zwischen einem Archiv-Stand und einer konkreten DB.

Einfach klasse, oder?

OK, nicht alles was glänzt ist gold und natürlich ist das eine 1.0er-Version. So habe ich auch schon ein paar Verbesserungswünsche auf der Platte, aber an dieser Richtung kommt man nicht mehr so leicht vorbei.

Bei der Frage eines Kollegen wie viele Tabellen pro Datenbank der SQL-Server genau erlaubt, musste ich neulich ganz schön in den Handbüchern suchen. Bei Sybase SQL-Anywhere stand es unter "Limitations", bei Microsoft nicht. Aber die Suche bei Google führte mich ratz-fatz auf die Seite im Microsoft-Handbuch unter dem Titel "Maximum Capacity Specifications" für Version 2005 und Version 2000. (Schade, dass die Suche in der MSDN nicht ansatzweise so gut ist…)

Die kurze Antwort auf obige Frage wäre übrigens: 2.147.483.647

Es gibt aber eigentlich keine genaue Grenze für Tabellen: In den internen Systemtabellen werden alle Datenbankobjekte in einer gemeinsamen Tabelle verwaltet. (Ich schätze, dass ist beim SQL-Server-2005 immer noch so, obwohl mal die Tabellen der Ressource-DB nicht sehen kann). Die ID für diese Datenbank-Objekt ist ein einfacher INT, IDs müssen positiv sein. Daher kann es nur 2.147.483.647 Objekte geben. Dazu zählen: Tabellen (sowohl System als auch User-Defined), Views, Prozeduren (auch Extended), Funktionen, Defaults, Trigger, Primärschlüssel, Fremdschlüssel, Unique-Constraints und Checks.

Wenn man sich solche Fragen stellt, dann ist man meiner Erfahrung gerade dabei eine Anwendung zu schreiben, die an einer ganz anderen Engstelle hängen bleiben kann: Potentiell wir für alle die vielen Tabellen Platz in der TempDB benötigt. Die sollte so positioniert werden, dass sie nötigenfalls ordentlich wachsen kann.

Mein Kollege Hans machte mich gestern auf das Dokument "Description of using disk drive caches with SQL Server that every database administrator should know" von Microsoft aufmerksam. Der Hintergrund sind weitgehend unbekannte oder besser ignorierte Ursachen für zerstörte Datenbanken. Tatsächlich sollte jeder Admin über die Risiken Bescheid wissen, denen man bei der Default-Konfiguration von PCs und Servern ausgesetzt ist.

Konkret geht es um die verschiedenen Caches, die so ein Datensatz durchlaufen muss, bis er endlich echt auf der Platte gesichert wurde. Treue Leser werden bei mir auch schon den einen oder anderen Hinweis dazu gelesen haben… 😉

Schön finde ich, dass hier endlich mal alle Dokument zu einem zusammengefasst werden.

PS: In der (automatischen) deutschen Übersetzung lautet der Titel übrigens "Mit SQL Server zwischenspeichert Beschreibung von Verwenden von Laufwerk dass jeder Datenbank-Administrator kennen sollte". Noch Fragen?

Das kommt darauf an. SQL an sich ist schon immer case-insensitiv, d.h. ob man die SQL-Schlüsselwörter groß oder klein schreibt ist allein eine Frage des Geschmackes oder der Konvention. Das bin ich jetzt seit 18 Jahren so gewohnt, ich finde klein praktischer. Dennoch schreibe ich in letzter Zeit auf häufigen Wunsch eines einzelnen Kollegen in meinen dienstlichen Beispielen und Musterlösungen immer alle SQL-Schlüsselwörter groß. Ich versuche es wenigstens…

Das gilt aber nicht für die Datenbank-Objekte. Hier bestimmt die Collation, die beim Anlegen der Datenbank angegeben wurde, ob die Namen der Tabellen, Views, Procedures, User, etc. case-sensitiv oder -insensitiv sind. Wurde hier eine case-sensitive Collation angegeben, dann werden die Systemtabellen mit dieser Collation angelegt. Die Folge ist, dass alle Objektnamen exakt richtig geschrieben werden müssen.
Aber selbst wenn man eine case-insensitive Collation gewählt hat, dann ist es schlau immer auf die richtige Schreibweise zu achten, damit man die Collation später mal einfach ändern kann.

Wem das zu viel Stress ist, der kann das auch einfach ignorieren und auf die Schreibweise pfeifen. Wenn er die Collation später mal ändern will, dann muss er einfach die Datenbank mit einer case-insensitiven Collation anlegen, aber dann beim Anlegen der Tabellen für jedes einzelne String-Feld (varchar, char, text, mit und ohne n) die "richtige" case-sensitive Collation angeben. Dann sind die Systemtabellen case-insensitiv, die eigenen Tabellen hingegen case-sensitiv.

Variablen und Cursornamen sind übrigens immer case-insensitiv.