Wie finde ich heraus, welche SQL Server Version installiert ist?

Zu wissen, mit welcher Version des SQL Servers du es zu tun hast, ist immer gut. Wenn du interaktiv mit dem SSMS arbeitest, findest du die Version in der Statuszeile des Abfragefensters. Innerhalb deiner eigenen Applikation kannst du die Version mit einem SELECT-Statement abfragen:

SELECT @@Version

Microsoft SQL Server 2000 – 8.00.2039 (Intel X86)
     May 3 2005 23:18:38
     Copyright (c) 1988-2003 Microsoft Corporation
     Developer Edition on Windows NT 5.0 (Build 2195: Service Pack 4)

oder für SQL Server 2000 und 2005:

SELECT SERVERPROPERTY(‘productversion’), SERVERPROPERTY (‘productlevel’), SERVERPROPERTY (‘edition’)
8.00.2039 SP4 Developer Edition

Die einzelnen Productversion habe ich in der folgenden Tabelle zusammengefasst:

SQL Server 2008
Katmay November CTP (CTP 5) (November 18, 2007)	10.00.1075.23
Katmay July CTP ( CTP 4) (July 31, 2007)	10.00.1049.14
June 2007 CTP Release (Katmai)	10.00.1019
SQL Server 2005
Cumulative Update Package 3 for SP2 (August 23, 2007)	9.00.3186
Cumulative Update Package 2 for SP2 (June 22, 2007)	9.00.3175
Critical Update SP2 (March 6, 2007)	9.00.3050
SP2 (February 16, 2007)	9.00.3042
SP2 CTP (November 6, 2006)	9.00.3027
Cumulative hotfix package (July 13, 2006)	9.00.2153
SP1 (April 19, 2006)	9.00.2047
RTM (November 7, 2005)	9.00.1399.06
September 2005 CTP Release	9.00.1314
June 2005 CTP Release	9.00.1187
April 2005 CTP Release	9.00.1116
December 2004 CTP Release	9.00.981
Beta 2	9.00.852
Beta 1	9.00.608
SQL Server 2000
SP4	8.00.2039
SP3a	8.00.760
SP3	8.00.760
SP2	8.00.534
SP1	8.00.384
RTM	8.00.194
SQL Server 7.0
SP4	7.00.1063
SP3	7.00.961
SP2	7.00.842
SP1	7.00.699
RTM	7.00.623
SQL Server 6.5
SP5a Update	6.50.479
SP5a	6.50.416
SP5	6.50.415
SP4	6.50.281
SP3	6.50.258
SP2	6.50.240
SP1	6.50.213
RTM	6.50.201

Katmai zum Vierten

Seit dem 31. July ist der CTP 4 (oder auch CTP July genannt) von Katmai allgemein verfügbar. Du bekommst ihn unter http://connect.microsoft.com/sqlserver/, benötigst hierfür aber eine Windows Live ID. Sowohl Beispielcodes als auch die Beispiel-DB AdventureWorks ist nicht Bestandteil des Downloads; du kriegst dies aber ebenfalls online unter http://codeplex.com/SqlServerSamples.

Bereits in einem meiner früheren Blogs habe ich dir empfohlen, Katmai in einer Virtual PC/Server Umgebung zu installieren. Irgendwie scheint Microsoft meinen Beitrag gelesen zu haben . Seit Ende August kannst du bei Microsoft ein solches Image runterladen (http://www.microsoft.com/downloads/details.aspx?FamilyID=6a39affa-db6e-48a9-82e4-4efd6705f4a6&DisplayLang=en). Der Download ist in vier Dateien von Total ca. 2.3 GB aufgeteilt. Entgegen den von Microsoft beschriebenen Requirements benötigst du nicht zwingend einen Virtual Server 2005 R2; bei mir läuft das ganze auch auf einem Virtual PC 2007 (DELL Laptop mit Vista).

Ach ja: Suchst du das Passwort für den Windows Server 2003? Das ist im Readme der Evaluation Edition versteckt: Evaluation1.

Viel Spass beim entdecken der neuen Features! Viellichts kommst du wieder mal hierhin zurück und postest deine Erfahrungen als Kommentar zu diesem Beitrag?

Gregorianischer Kalender zum zweiten

Bereits in einem früheren Blog habe ich über das Speichern eines Datums in der DB gesprochen. Mit dem Erscheinen der nächsten SQL Server Version (Codename Katmai) möchte ich dieses Thema nochmals aufnehmen, hat sich diesbezüglich doch einiges getan. Konkret, der SQL Server kennt neue Datentypen rund um Datum und Uhrzeit:

Data type		Format		Range			Accuracy	Storage size (bytes)	User-defined fractional second precision	Time zone offset
time		hh:mm:ss[.nnnnnnn]		00:00:00.0000000 through 23:59:59.9999999			100 nanoseconds	3 to 5	yes	no
date		YYYY-MM-DD		00001-01-01 through 9999-12-31			1 day	3	no	no
smalldatetime		YYYY-MM-DD hh:mm:ss		1900-01-01 through 2079-06-06			1 minute	4	no	no
datetime		YYYY-MM-DD hh:mm:ss[.nnn]		1753-01-01 through 9999-12-31			0.333 second	8	no	no
datetime2		YYYY-MM-DD hh:mm:ss[.nnnnnnn]		0001-01-01 00:00:00.0000000 through 9999-12-31 23:59:59.9999999			100 nanoseconds	6 to 8	yes	no
datetimeoffset		YYYY-MM-DD hh:mm:ss[.nnnnnnn] [+|-]hh:mm		00001-01-01 00:00:00.0000000 through 9999-12-31 23:59:59.9999999 (in UTC)			100 nanoseconds	8 to 10	yes	yes

Die Datentypen datetime und smalldatetime kennen wir bereits vom SQL Server 2005 her; hier hat sich nichts geändert. Diese Datentypen sind 100%-ig Kompatibel zur Implementation im SQL Server 2005. Die vier weiteren Datentypen time, date, datetime2 und datetimeoffset sind neu hinzugekommen. User-defined fractional second precision gibt an, ob du die Anzahl Nachkommastellen der Sekunde selber definieren kannst (im Bereich von 0 – 7). Time zone offset gibt an, ob in diesem Datentyp Information zur Zeitzone (inklusive Sommerzeit) abgelegt werden kann.

Wie bis anhin so folgen auch weiterhin alle Datumsangaben dem Gregorianischen Kalender. Eins irritiert mich aber schon: Der Gregorianische Kalender wurde erst im 16. Jahrhundert von Papst Gregor XIII eingeführt. Was passiert also mit den Daten vor dieser Zeit? Immerhin gehen die neuen Datentypen bis zum Jahr 1 zurück. Naja, sobald ich dahinter gekommen bin wie das funktioniert, schreibe ich einen kleinen Update zu diesem Blog J. Vielleicht hast du mir ein eine Erklärung oder auch nur einen kleinen Tipp? Merci!

Mein neuer Favorit ist ganz klar datetimeoffset. Damit kann ich praktisch alles machen: Zeitstempel für Logeinträge einer global verteilten Applikation verwalten (hierfür benötige ich die Zeitzonen), ein Geschichtsbuch ab Jesu Geburt schreiben (hierfür benötige ich Jahrzahlen ab 1) oder auch (vielleicht) die nächste Rangliste für den 100m Sprint an der Weltklasse Zürich (bis die auch die Tausendstelsekunde auswerten geht es bestimmt nicht mehr lange J und dann brauche ich die höhere Genauigkeit bei der Zeit). Soviel fürs erste. Viel Spass beim weiter entdecken der neuen Features von Katmai.

ACHTUNG: Alle hier gemachten Angaben basieren auf SQL Server 2008 CTP July und können bis zum Erscheinen der endgültigen Version noch ändern.

Noch mehr Statistik – noch mehr Performance

Im Blogg von dieser Woche habe ich ja bereits ein paar Tipps zu Performance Steigerung mittels Index Statistiken gegeben – heute gehe ich noch einen Schritt weiter. Statistiken zu erstellen kann eine ganz aufwendige Sache sein, insbesondere wenn die Tabelle Millionen und mehr von Zeilen hat. Dies ist auch der Grund, warum der SQL Server per Default das Histogramm lediglich auf einem Subset aller Zeilen (Sample) bildet. Die Grösse des Samples bestimmt der SQL Server selbständig. Wenn du denkst, dass du smarter als der SQL Server bist, kannst du aber auch hier wiederum von Hand eingreifen:

UPDATE STATISTICS Person.Address IX_Address_AddressLine1_AddressLine2_City_StateProvinceID_PostalCode WITH SAMPLE 1 PERCENT
UPDATE STATISTICS Person.Address IX_Address_AddressLine1_AddressLine2_City_StateProvinceID_PostalCode WITH SAMPLE 1000 ROWS
UPDATE STATISTICS Person.Address IX_Address_AddressLine1_AddressLine2_City_StateProvinceID_PostalCode WITH FULLSCAN

FULLSCAN entspricht dabei einem SAMPLE 100 PERCENT.

Wie gesagt, ein Update der Statistik kann ganz schön lange dauern. Ein Query, das auf eine out-of-date Statistik stösst, muss warten bis diese Statistik aktualisiert wurde; erst dann kann das Query compiliert und ein Resultset zurückgegeben werden. Das kann zu unvorhersehbar langen Antwortzeiten führen, welchen auf Clientseite schon mal zu einem Timeout führen können. Um dem zu entgehen, kennt der SQL Server die DB Option, die Statistik asynchron zu aktualisieren:

ALTER DATABASE AdventureWorks
  SET AUTO_UPDATE_STATISTICS_ASYNC ON

In diesem Falle wir die Statistik im Hintergrund aktualisiert. Queries welche in der Zwischenzeit diese Statistik benötigen werden nicht blockiert sondern verwenden die veraltete Statistik.

Wäre es nicht toll, wenn dir der SQL Server erzählen würde, welche Indizes er gerne hätte um noch effizienter arbeiten zu können? Genau hierfür gibt es eine Dynamic Management View:

SELECT object_name(object_id, database_id) as ‘Object’
      ,equality_columns
      ,inequality_columns
      ,included_columns
FROM sys.dm_db_missing_index_details

Das Resultat kann etwa wie folgt aussehen:

Object	equality_columns	inequality_columns	included_columns
Address	[ModifiedDate]	NULL	NULL

Mit dieser Information kannst du deinen fehlenden Index leicht bilden:

CREATE INDEX NewIndex
  ON <Object>(<equality_columns>,<inequality_columns>)
  INCLUDE (<included_columns>)
  WITH DROP_EXISTING

Oder konkret:

CREATE INDEX Adress_ModDate_Index
  ON Address(ModifiedDate)
  WITH DROP_EXISTING

Aber Achtung: Diese Daten sind nur solange durch die Dynamic Management View verfügbar, bis du den SQL Server neu startest oder aber an der zugrunde liegenden Tabelle eine Schema Änderung vornimmst.

Mit aktuellen Statistiken zu mehr Performance

Nein, natürlich meine ich mit Statistiken nicht etwa das Statistische Jahrbuch der Schweiz, sondern viel mehr SQL Servers eigene Index Statistik. Index Statistiken beschreiben die Verteilung von Werten in einer Spalte. Der Query Optimizer nutzt diese statistischen Daten um den optimalen Query Plan zu bestimmen, in dem er die Zugriffskosten für die Benutzung eines bestimmten Index schätzt. Mit Hilfe von DBCC kannst du dir zum Beispiel das Histogramm der Verteilung der Werte anschauen:

DBCC SHOW_STATISTICS (‘Person.Address’,‘IX_Address_AddressLine1_AddressLine2_City_StateProvinceID_PostalCode’) WITH HISTOGRAM

Du kannst dir das Histogramm natürlich auch mit Excel grafisch darstellen lassen; das sieht dann so aus:

Wann immer du dir einen Index anlegst, legt SQL Server parallel dazu auch eine entsprechende Statistik an. Wenn sich die dem Index zugrunde liegende Daten ändern, kann sich natürlich auch das Histogramm dazu ändern. Dies kann dazu führen, dass der Query Optimizer lediglich einen Suboptimalen Query Plan erstellt, was selbstreden auf die Performance geht. SQL Server wird daher die Statistik automatisch updaten, d.h. neu berechnen, wann immer sich 20% der Zeilen – aber mindestens 500 Zeilen – der entsprechenden Tabelle geändert haben. Ob die Statistik noch aktuell ist, siehst du zum Beispiel im Actual Execution Plan: wenn Actual Number of Rows stark von Estimated Number of Rowas abweicht, dann dürfte die Statistik nicht mehr viel wert sein. In diesem Falle kannst du den Update der Statistik forcieren:

UPDATE STATISTICS Person.Address

Da der SQL Server die Statistiken sowohl selber anlegt als auch selber up-to-date hält, sollte in der Regel das Histogramm aber kaum je unbrauchbar sein – wenn da nicht noch all diese Optionen wären. Sowohl das automatische Anlegen als auch Updaten der Statistiken kannst du nämlich unterbinden. Das kann mal für grosse BULK Operationen interessant sein; sollte aber wirklich die ganz grosse Ausnahme sein. Mit folgenden Kommandos kannst du in das Verhalten der automatischen Statistik eingreifen:

• sp_autostats: Tabllen und Index weites ein-/ausschalten von AUTO UPDATE
• STATISTICS_NORECOMPUTE Klausel in einem CREATE INDEX Statement
• NORECOMPUTE Klausel in einem UPDATE STATISTICS oder CREATE STATISTICS Statement
• AUTO_CREATE_STATISTICS und AUTO_UPDATE_STATISTICS Datenbank Option (änderbar via ALTER DATABASE)

Nochmals: Überlege es dir gut, ob du wirklich einzelnen Statistiken nicht automatisch up-to-date halten willst oder für einzelne Indizes überhaupt gar keine Statistik willst. Was in Ausnahmefällen mal für eine Statistik gelten kann wird aber kaum je generell für alle Statistiken gelten. Also Hände weg von den Datenbank weiten Optionen zur Ausschaltung der automatischen Statistiken! Die Performance wird es dir danken!