Gruß,

Steffen

Nach 8 Jahren Microsoft und noch viel mehr Jahren SQL Server beginnt für mich am 10.12. eine neue Ära. Ich liebe SQL Server, ich habe immer gern für Euch die neuesten Informationen zusammen getragen, und ich mag nach wie vor Microsoft und die vielen coolen Technologien. Warum dann der Wechsel? Bei allem Guten hat mir eines häufig gefehlt: Berlin. Als ich daher ein Angebot bekommen habe, das mir mehr Berlin in einem coolen Umfeld bietet habe ich mich nach langer Überlegung entschlossen anzunehmen. Mehr dazu bald in meinem neuen privaten Blog unter http://steffenkrause.wordpress.com/ 

Der Datenbankwelt bleibe ich zu mindestens teilweise erhalten, aber dabei wird es nicht nur um SQL Server gehen. Wer mich wieder live sehen will wird Gelegenheit bekommen, ich plane, zu mindestens auf den Frankfurter Datenbanktagen und der PHP Konferenz zu sprechen, mehr wird sicherlich folgen

Ich danke Euch allen für die treue Leserschaft, die guten Kommentare und Fragen, die Zusammenarbeit, die vielen Anregungen und sogar Freundschaft in den vielen Jahren. Es war ne tolle Zeit! Später könnt Ihr mich unter http://steffenkrause.wordpress.com/ erreichen.

Gruß,
Steffen

Zu den Gerüchten:

1. Der SQL Server kann keine vernünftigen Locks (Sperren) durchführen. Er lockt (sperrt) immer seitenweise, was dazu führt, dass man unvorhersehbares Laufzeitverhalten erzeugt.

Tja, SQL Server 6.5 hat noch ganze Seiten gesperrt…

Seit SQL Server 7.0 gibt es Row Level Locking. Allerdings wählt SQL Server bei großen Mengen von Datenänderungen auch manchmal Page (Seite) oder gar Table Locks, da dies Hauptspeicher und vor allem die Zeit zum Setzen und Entfernen der Locks spart. Hier ist SQL Server deutlich effizienter als andere Datenbanksysteme. Wem dieses Verhalten nicht gefällt, der kann einen ROWLOCK Table Hint in den Abfragen verwenden oder Page Locks für einen Index mit der Index Option ALLOW_PAGE_LOCKS = { ON | OFF } deaktivieren. Bei manchen Vorgängen, insbesondere DDL-Statements wie ALTER TABLE ist allerdings ein Table Lock unumgänglich, das ist in anderen Datenbanken auch so.

2. SQL Server verwendet pessimistisches Locking. Dadurch blockieren Leser Schreiber und umgekehrt und die Parallelität wird gesenkt

Ausschließlich pessimistisches Locking wurde bis SQL Server 2000 verwendet…

Seit SQL Server 2005 hat der Kunde die Wahl, ob er optimistisches oder pessimistisches Locking verwenden will, wobei pessimistisches nach wie vor der Standard ist.

Worum geht es? Nehmen wir an, Transaktion A will einen Datensatz schreiben, Transaktion B denselben Datensatz lesen (bei Row Level Locking). Beide Transaktionen sind noch nicht abgeschlossen. Klar ist, dass Transaktion B auf keinen Fall den noch nicht committeten neu geschriebenen Wert lesen darf (Dirty Read), denn es kann ja sein, dass Transaktion A zurückgerollt wird. Nun hat die Datenbankengine zwei Möglichkeiten:

Pessimistisches Locking: Wenn der Datensatz von Transaktion B geschrieben wird setzt die Engine einen exklusiven Lock auf den Datensatz. Transaktion B will vor dem Lesen einen Shared Lock haben, bekommt den aber wegen dem exklusiven Lock erst nach Abschluss von Transaktion A.

Optimistisches Locking: Bis zum Abschluss der Transaktion A wird neben den geänderten Daten auch die alte, committete Version des Datensatzes gehalten (in tempdb). Dadurch kann Transaktion B die alte Version der Daten lesen und es ist kein Shared Lock notwendig. Das entspricht zum Beispiel dem Verhalten in Oracle (Oracle verwendet die Begriffe pessimistisch und optimistisch allerdings ein wenig anders, da es die hier angegebene erste Variante gar nicht gibt). Optimistisches Locking können Sie in SQL Server mit READ_COMMITTED_SNAPSHOT oder TRANSACTION ISOLATION LEVEL SNAPSHOT (mit leicht unterschiedlichem Verhalten) verwenden. Mehr dazu hier: http://msdn.microsoft.com/en-us/library/ms179599.aspx

Warum gibt es nun beide Varianten? Weil pessimistisches Locking ressourcenschonender und für Szenarien besser geeignet ist, wo meist unterschiedliche Datensätze zugegriffen werden (z.B. Lagerhaltung). Optimistisches Locking ist hingegen flexibler.

3. Der SQL Server ist fast unbezahlbar, da man keine vernünftige Lizensierung durchführen kann, die eine unbeschränkte Anzahl von Usern (z.B. im Web-Betrieb) erlaubt.

SQL Server kann man auf Prozessor (bis 2008R2) bzw. Core (ab SQL 2012) Basis lizenzieren und damit beliebig viele Benutzer supporten. Und auch die kostenlose SQL Server Express Version ist in manchen kleinen Web-Szenarien eine Option.

Bei der Gelegenheit: Auch von Oracle gibt es ja eine kostenlose Express Version (XE). Allerdings wird diese im Gegensatz zu SQL Server Express nicht gepatcht, auch nicht bei den reichlich vorhandenen Sicherheitslücken. Damit ist sie für Web-Aufgaben (und eigentlich für fast alle Aufgaben) komplett ungeeignet.

4. Der SQL-Server verwendet immer feste, nicht anpassbare Blockgrößen bei der Speicherung. Oracle kann hier zwischen 2K und 32K skalieren.

Das ist richtig, SQL Server verwendet immer 8k Datenseiten für die Speicherung. Die gesamte Datenbankengine und das IO Subsystem ist daraufhin optimiert, und auch Hersteller von Storagelösungen können sich darauf einstellen. In Oracle gibt es die Möglichkeit, die Blockgröße anzupassen, aber nur die wenigsten Kunden nutzen diese Möglichkeit. Zumal verschiedene Blockgrößen innerhalb einer Instanz zu einer Fragmentierung des Hauptspeichers führen würden – man kann nun mal nicht eine 32kB Seite in den Platz laden, der von 4 8kB Seiten freigegeben wurde, wenn dieser Platz nicht hintereinander liegt.

Die Performanceergebnisse von SQL Server geben uns hier wohl recht… Und bei größeren Datenmengen verwendet SQL Server Read Ahead mit Lesegrößen bis zu 1024 kB, um effizienter auf das Storagesystem zuzugreifen.

5. Der SQL-Server hält sich nicht an die ANSI-Standards und hierdurch ist Interoperabilität nicht gewährleistet.

Es ist zwar richtig, dass es geringe Unterschiede zwischen SQL Server und ANSI SQL gibt, aber meines Wissens gilt dies auch für jedes andere relationale Datenbank. Einige der Differenzen zwischen Oracle SQL und ANSI SQL finden sich hier: http://de.wikipedia.org/wiki/Oracle_(Datenbanksystem)#Abweichungen_vom_ANSI-SQL-Standard. Allerdings ist diese Liste bei weitem nicht vollständig. So ist zum Beispiel die Oracle SEQUENCE-Syntax nicht ANSI compliant (die von SQL Server 2012 schon).

Im Falle von SQL Server liegen die Unterschiede vor allem in Datentypen (wie TIMESTAMP), die bereits vor Verabschiedung des ANSI Standards anders verwendet wurden.

Allgemein haben allerdings alle großen Datenbanksysteme viele Features, die weit über den ANSI Standard hinausgehen. Daher ist Interoperabilität immer nur dann möglich, wenn beim Schreiben des SQL Codes ausdrücklich darauf geachtet wird, nur standardisierte Sprachkonstrukte zu nutzen.

6. Es gibt kein Äquivalent zu den PLSQL-Packages des Oracle, das ein Lifecycle-Management sowie eine Verteilungs-Strategie zulassen würde.

Da hätten wir ja eines der nicht standardkonformen Oracle-Features. In ANSI SQL gibt es kein CREATE PACKAGE…

SQL Server hat zwar keine Packages, wer möchte kann allerdings Schemas stattdessen zur Strukturierung des Codes verwenden (für die Oracle-Fraktion: in SQL Server werden Schemas anders verwendet als in Oracle. Ein Oracle-Schema entspricht mehr einer SQL Server Datenbank)

Für Lifecycle Management und Verteilungsstrategie gibt es allerdings in SQL Server deutlich bessere Varianten. Insbesondere die Möglichkeit der Integration von SQL Server Management Studio mit Quellcodeverwaltungssystemen, die neuen SQL Server Data Tools mit ihrem kompletten round trip engineering für Datenbankcode, die DAC-Pakete und die Integration mit Visual Studio Team System wären hier zu nennen…

Wie andere Datenbanksysteme auch unterliegt SQL Server einer ständigen Weiterentwicklung, um das geeignete Datenbanksystem zu finden sollte man immer über die aktuellen Möglichkeiten informiert sein. Ich hoffe ich konnte mit diesen Beispielen zeigen wie wichtig dies ist.

Zum Abschluss noch ein paar Links zum Thema SQL Server Mythen:

• http://blogs.msdn.com/b/euanga/archive/2006/01/19/514479.aspx
• http://www.simple-talk.com/community/blogs/tony_davis/archive/2007/06/27/32975.aspx
• http://www.sqlskills.com/blogs/paul/CommonSQLServerMyths.pdf

Gruß,
Steffen

Diese Demo habe ich nun als Videos aufgenommen.

Im ersten Teil zeige ich die Installation eines 4-Knoten-Clusters auf Basis von Windows Server 2008 R2 SP1, wobei zwei von den vier Knoten Zugriff auf ein iSCSI SAN haben (und die anderen beiden nicht)

Im zweiten Teil  baue ich einen 2-Knoten SQL Server Failover-Cluster auf und teste ihn

Im dritten Teil baue ich aus dem SQL Server Failover Cluster und den anderen beiden Windows Cluster Konten eine AlwaysOn Availability Group auf, richte Read Only Routing ein und teste das ganze.

Die Videos finden sich hier:

Gruß,
Steffen

Gegenüber der letzten CTP-Version gibt es einige wesentliche Verbesserungen

• Die Hochverfügbarkeitslösung AlwaysOn ist nun Feature Complete. Es können bis zu 5 Replikas (1 Primäre schreibbare, 2 synchrone sekundäre, 2 asynchrone sekundäre) eingerichtet werden. Lesbare Secondaries und Backup von den Secondaries sind unterstützt. Letzteres kann man sogar über den Assistenten einrichten:
  
  
• In Power View kann jetzt eine “Mappe” aus unterschiedlichen Views angelegt werden
• Ebenso gibt es in Power View jetzt eine Druckfunktion und einen PowerPoint Export:
  
  
• Der Resource Governor hat einige neue Funktionen für große Umgebungen, wie detailliertere CPU Kontrolle und Resource Pool Affinity
• Change Data Capture von Oracle ist nun möglich
• SQL Management Studio unterstützt Snapshot Backups von SQL Azure

Die offizielle Information findet sich im Dataplatform Insider Blog

Der Download ist hier (für Deutsch einfach auf deutsch umstellen). Die Release Notes finden sich auch dort. Wichtig sind vor allem die OS-Patches für AlwaysOn Availability Groups!

Hier ist der Download für PowerPivot für Excel

Gruß,
Steffen

• Running SQL Server 2008 in a Hyper-V Environment - Best Practices and Performance Recommendations
  • Deutsche Übersetzung: Ausführen von SQL Server 2008 in einer Hyper­V­Umgebung Best Practices und Überlegungen zur Leistung
• High Performance SQL Server Workloads on Hyper-V
• Onboarding SQL Server Private Cloud Environment
• Running SQL Server with Hyper-V Dynamic Memory - Best Practices and Considerations

Für diejenigen, die nicht die Zeit haben um sich die Whitepaper durchzulesen möchte ich hier die wichtigsten Fakten (ohne Anspruch auf Vollständigkeit) einmal zusammenstellen

Installation

• Dies betrifft Neuinstallationen in die Konsolidierungsumgebung, nicht die Migration von vorhandenen Umgebungen
• Für Private Cloud/Konsolidierungsumgebungen ist es empfohlen, SQL Server VMs aus VM-Templates zu erstellen
• SQL Server unterstützt sysprep zum Erstellen des Templates erst seit Version SQL Server 2008 R2
• Man muss für sysprep genau nach Anleitung vorgehen. Die Installation erfolgt in 2 Schritten: Vorbereiten (danach sysprep und Template erstellen) und abschließen. Dokumentation: http://msdn.microsoft.com/de-de/library/ee210754.aspx
• Stellen Sie unbedingt sicher, dass die Hyper-V Integrationskomponenten (bzw. das Äquivalent für die verwendete Virtualisierungsumgebung) in der jeweils aktuellen Version installiert sind, verwenden Sie keine emulierten Geräte

Migration

• Um festzustellen, welche SQL Server Instanzen in die virtuelle Umgebung migriert werden können verwendet man am einfachsten das MAP Toolkit Demo von mir hier

Dynamic Memory

• SQL Server unterstützt Hyper-V 2008 R2 SP1 Dynamic Memory
• Das SQL Server Dienstkonto sollte unbedingt das Recht “Lock Pages in memory” haben
• Die Summe der “Startup Memory” Einstellungen aller VMs, die potentiell (auch nach einem ungeplanten Failover) auf einem Host laufen können muss kleiner sein als der physikalische Speicher des Hosts
• Wenn möglich sollte vor einer (geplanten) Live Migration einer SQL VM der Hauptspeicher von SQL Server mittels sp_configure ‘max server memory’ reduziert werden. Nicht vergessen, diese Einstellung nach der Live Migration wieder zu zurückzunehmen!
• Über “Memory Weight” kann man die Priorität der VMs bei der Hauptspeicherzuteilung einstellen

Storage

• Alle Best Practices für SQL Server Storage gelten auch für virtualisierte Umgebungen. Siehe mein Webcast SQL Server Storage Performanceanalyse
• Daher für Lastsysteme: Daten und Logs auf getrennte LUNs, hinter denen getrennte Platten liegen
• Auf keinen Fall dynamische Disks für Daten und Logs
• Entweder Passthrough Disks oder VHDs fester Größe verwenden

CPU

• Virtualisierung erhöht leicht den CPU-Bedarf von SQL Server. Da Hyper-V maximal vier virtuelle CPUs pro VM unterstützt bedeutet das, dass nur Lasten, die weniger als 4 volle CPU-Cores benötigen virtualisiert werden sollten.
• Wenn CPUs overcommitted werden (also der Summe aller VMs mehr virtuelle CPUs zugewiesen werden als der Server physische CPU-Kerne hat) so erhöht sich der CPU-Bedarf durch die Virtualisierung weiter. Daher sollte bei Lastsysteme Overcommitment vermieden werden. Das gilt insbesondere, wenn die verwendeten Prozessoren keine Second Level Address Translation (SLAT) unterstützen
• Netzwerk-intensive Lasten erhöhen ebenfalls den CPU-Bedarf

Hochverfügbarkeit

• Sowohl Host-Clustering (mit Live Migration) als auch Guest Clustering (Windows/SQL Cluster in VMs) ist mit Hyper-V unterstütz (zu VMWare siehe unten). Beides kann für höchste Flexibilität und Ausfallsicherheit kombiniert werden.
• Ebenso ist Database Mirroring und Log Shipping auch im virtualisieren Betrieb unterstützt

Lizenzierung

• SQL Server Enterprise bzw. Datacenter können in Virtualisierungsszenarien durch die erweiterten Virtualisierungsrechte deutlich Kosten sparen
• Details dazu auf der SQL Server Lizenzierungs-Seite

VMWare (und andere)

• Grundsätzlich ist VMWare (und andere Hypervisor) als Virtualisierungsumgebung supportet, solange die konkrete VMWare Version mit dem SVVP validiert ist. Details: http://support.microsoft.com/kb/956893/en-us
• Soll statt Hyper-V VMWare eingesetzt werden so muss man sich die Limitationen von ESX, insbesondere in Zusammenhang mit Clustern klar machen. So vMotion nicht in Kombination mit Windows Clustering unterstützt. Man muss sich also zwischen Host Clustering (vMotion) und Guest Clustering (SQL Server/Windows Server Cluster) entscheiden. Das ist nicht gut, denn die beiden Technologien schützen gegen unterschiedliche Arten von Ausfällen. Ebenso ist iSCSI nicht unterstützt.
  Quelle: http://www.vmware.com/pdf/vsphere4/r41/vsp_41_mscs.pdf Seite 11

Gruß,
Steffen

• 14 Product Datasheets
• 8 PowerPoint Präsentationen
• 5 Technische Whitepaper
• 13 Hands-On Lab Preview Dokumente
• 6 Click-Through Demos
• 13 automatisch ablaufende Demos
• 26 Links zu Online-Dokumentationen
• 44 Links zu Online-Videos einschließlich 26 Präsentationen von der US-TechEd 2011

Der Download des Product Guide findet sich hier

Gruß,
Steffen

Die semantische Suche ist eine Erweiterung der Volltextsuche, die extra für volltextindizierte Spalten aktiviert wird. Das geht in T-SQL (durch Angabe einer Sprach-ID und des Schlüsselworts Statistical_Semantics an der volltextindizierten Spalte) oder in der grafischen Volltextindex-Oberfläche:

Damit das klappt muss allerdings zuerst die semantische Suche konfiguriert werden. Dazu wird zuerst die semantische Sprachstatistik-Datenbank installiert, indem man das Paket SemanticLanguageDatabase.msi vom Installationsmedium entpackt und die entpackte Datenbank an den Server anhängt. Danach muss die Datenbank noch mittels sp_fulltext_semantic_register_language_statistics_db registriert werden. Wie das geht findet sich hier.

Die unterstützten Sprachen kann man dann mit

select * from sys.fulltext_semantic_languages

herausfinden. Deutsch ist dabei. Die eigentlichen semantischen Daten in dieser Datenbank sind übrigens als Internal Tables abgelegt und somit nicht direkt für ein SELECT zugänglich.

Danach kann man wie oben angegeben den Volltextindex mit semantischer Suche erstellen. Ich habe das auf der Filetable gemacht, deren Erstellung ich in diesem Artikel beschrieben habe. Es muss aber keine Filetable sein, jede volltextindizierte Spalte einer Tabelle funktioniert. Zu beachten ist, dass die semantische Suche einen Volltextindex deutlich vergrößert und auch die Erstellungszeit erhöht. Daher sollte man semantische Suche nur aktivieren, wenn man sie auch wirklich verwenden will. Außerdem muss natürlich die Volltextindizierung für die in der Tabelle vorhandenen Dokumenttypen vorbereitet sein: Die entsprechenden IFilter müssen installiert sein, deren Verwendung aktiviert usw.

Schlüsselwörter finden

Nun kann man zum Beispiel für ein Dokument herausfinden, was die statistisch wichtigen Schlüsselwörter in diesem Dokument sind. Das geht über die Funktion SEMANTICKEYPHRASETABLE:

DECLARE @DocID hierarchyid

 

SELECT @DocID = path_locator from MeineFiletable where name = 'ADS.pptx';

 

--Key Phrases

SELECT TOP(10) KEYP_TBL.keyphrase

FROM SEMANTICKEYPHRASETABLE

    ( MeineFiletable,

      file_stream,

      @DocID

    ) AS KEYP_TBL

ORDER BY KEYP_TBL.score DESC;

keyphrase

sql

azure

verwaltung

technet

durch

datacenter

tds

isv

unternehmen

arten

Offensichtlich habe ich hier also über SQL Azure gesprochen.

Anders herum kann man auch herausfinden, in welchen Dokumenten es um Azure geht indem man die Dokumente nach Signifikanz der Phrase „Azure“ sortieren lässt:

SELECT TOP (5) DOC_TBL.path_locator.ToString() Locator, DOC_TBL.name

FROM MeineFiletable AS DOC_TBL

    INNER JOIN SEMANTICKEYPHRASETABLE

    ( MeineFiletable,

      file_stream

    ) AS KEYP_TBL

ON DOC_TBL.path_locator = KEYP_TBL.document_key

WHERE KEYP_TBL.keyphrase = 'azure'

ORDER BY KEYP_TBL.Score DESC;

 

Locator	name
/163317661833190.115726554008670.1866003634/ 218988078402337.61914970700195.3199820884/	DatabaseProAzureReporting.docx
/235419278667080.230118955961229.3763918334/ 95176762753143.43209610854162.380882874/	Webcast SQL Azure und die Microsoft Cloud Plattform.pptx
/235419278667080.230118955961229.3763918334/ 195400071903089.254316101152370.2453146947/	Webcast SQL Azure Überblick.pptx
/235419278667080.230118955961229.3763918334/ 204734086686021.60759175188448.1218421407/	SQL Azure und die Microsoft Cloud Plattform.pptx
/163317661833190.115726554008670.1866003634/ 148065100657714.221322731028740.4247534163/	SQL Azure CeBIT.pptx

Ähnliche Dokumente finden

Der andere Anwendungsfall für die statistische semantische Suche ist es, ähnliche Dokumente zu finden. Das geht über die Funktion SEMANTICSIMILARITYTABLE. Details zur Ähnlichkeit erhält man über SEMANTICSIMILARITYDETAILSTABLE. Eine einfache Abfrage “Welche Dokumente sind diesem ähnlich“ funktioniert so:

SELECT   mft.name, sst.score 

FROM SEMANTICSIMILARITYTABLE

  ( MeineFiletable,

    file_stream,

    @DocID

  ) AS sst

INNER JOIN MeineFiletable mft

  ON path_locator = matched_document_key 

ORDER BY score DESC

Name	Score
Webcast SQL Azure Überblick.pptx	0,6667337
SQL Azure CeBIT.pptx	0,6150579
sqldays 2010 SQL Server 2008 R2 NonBI.pptx	0,3872314
SQL Server 2005 - Webcast - 2005-09-28 - Schutz sensitiver Daten.ppt	0,3602501
Was ist SQL Server Express 2008 R2.pptx	0,3286014

Will man dann den Grund für die Ähnlichkeit finden so joint man über SEMANTICSIMILARITYDETAILSTABLE:

DECLARE @DocIDMatch hierarchyid

 

SELECT @DocIDMatch = path_locator

FROM MeineFiletable

WHERE name = 'SQL Server 2005 - Webcast - 2005-09-28 - Schutz sensitiver Daten.ppt';

 

SELECT TOP(20) V4.keyphrase, V4.score

FROM SEMANTICSIMILARITYDETAILSTABLE

  ( MeineFiletable,

    file_stream,

    @DocID,

    file_stream,

    @DocIDMatch

  ) AS V4

ORDER BY V4.score DESC;

keyphrase	score
sql	0,6196678
technet	0,4326765
server	0,3456945
verschlüsselung	0,3421064
durch	0,3254796
schlüssel	0,3249941
wird	0,2818047
datum	0,2744119
zertifikat	0,2636287
public	0,2460675
arten	0,2402729
kosten	0,2268401
master	0,2166911
passwort	0,2148199
zum	0,2144909
microsoft	0,2132909
authentifizierung	0,2127908
symmetrisch	0,21237
immer	0,2091359
gmbh	0,2083207

Offensichtlich geht es also in beiden Präsentationen um mein Lieblingsthema Verschlüsselung…

In Summe kann die neue semantische Suche in SQL Server „Denali“ sehr umfassend beim Verständnis von Dokumentbeständen und der inhaltlichen Suche darin helfen und so die meisten dokumentorientierten Datenbankanwendungen deutlich aufwerten.

Die Dokumentation zur semantischen Suche findet sich hier, der Download der Denali CTP3 hier

Gruß,
Steffen

Die Neuerungen in SQL Server “Denali” gliedern sich unter drei wesentlichen Themen

• “Mission Critical Confidence” bedeutet, dass SQL Server “Denali” Performance und Verfügbarkeit für die größten geschäftskritischen Anwendungen bei niedrigen Betriebskosten bietet. Dazu gehört das Erreichen der benötigten 9en mit AlwaysOn oder hochperformante Data Warehouse Abfragen mit Columnstore Indizes
• “Breakthrough Insights” bezieht sich auf die vielen Neuerungen, die die Marktführerschaft im BI-Bereich (z.B. laut Gartner Magic Quadrant BI Platform, Jan. 2011) ausbauen. Dazu gehört die interaktive webbasierte Datenanalyse mit Project “Crescent” oder die Sicherung der Datenqualität mit Data Quality Services
• “Cloud on your Terms” bedeutet schließlich, dass der Kunde freie Wahl hat, inwieweit er in die Cloud gehen will: von der klassischen On-Premise Lösung über Private Cloud bis zur Public Cloud mit SQL Azure ist alles auf der Basis von SQL Server Technologie unterstützt. Mit “Juneau” und den Verbesserungen bei den DAC Paketen ist auch eine einheitliche Entwicklung über alle Szenarien möglich.

Gegenüber der ersten CTP von November 2010 gibt es eine Vielzahl von Neuerungen, hier die Details:

Relationale Datenbank

• Columnstore Indizes. Darüber habe ich hier schon geschrieben. Dieser neue spaltenbasierte Indextyp beschleunigt Data Warehouse Abfragen erheblich
• FileTable ermöglicht den Zugriff auf SQL Server Filestream Daten direkt über das Dateisystem
• Semantische Suche ermöglicht Volltextabfragen nach Ähnlichkeit (“Gib mir Dokumente, die diesem hier ähnlich sind”, “Sage mir, worin sich diese zwei Dokumente ähneln”)
• Bis zu 15000 Partitionen pro Tabelle
• Höhere Performance und mehr Funktionalität (Circular Arc, gesamte Erde) für geografische Datentypen
• Performanceverbesserungen bei Filestream und Volltextsuche
• Unterstützung von Windows Server Core
• Neue Entwicklungsumgebung Project “Juneau” – ermögliche einheitliche Entwicklung für SQL Server, BI und SQL Azure
• Sicherheitsverbesserungen: Benutzerdefinierte Serverrollen, verbessertes Auditing, Standardschema für Windows-Gruppen
• Powershell 2.0, Implementation als PowerShell Modul statt als Minishell, PowerShell für Analysis Services und PowerPivot für SharePoint
• LocalDB für SQL Server Express
• Database Recovery Advisor macht komplexe Restore-Vorgänge (wie Point in Time Recovery) einfacher
• AlwaysOn Verbesserungen gegenüber der ersten CTP (müssen teilweise noch über Trace Flag 9532 freigeschaltet werden da dieser Teil der CTP noch nicht “Production ready” ist)
  • bis zu 1 primäre und 4 sekundäre Repliken, davon bis zu insgesamt drei synchrone
  • Failover: automatisch, geplant manuell, erzwungen manuell
  • Backups von sekundären Repliken
  • Unterstützung von Filestream, FileTable, RBS sowie viele andere Verbesserungen

Data Quality Services

• Das ist eine neue Komponente von SQL Server, die die Datenqualität durch Verfahren wie Data Clensing und Data Matching entscheidend verbessern kann. DQS kann eigenständig oder innerhalb eines SSIS Datenflusses ausgeführt werden

BI Development Studio

• Beruht jetzt auf Visual Studio 2010

Integration Services

• Der größte Teil der Neuerungen in SSIS war bereits in der CTP1 vorhanden (SSIS Server, Projektverwaltung, Parameter)
• Es gibt in der neuen CTP eine Vielzahl von Detailverbesserungen, wie Tutorials in BIDS, besser strukturierte .dtsx-Dateien für Vergleichstools, Standardberichte in SQL Server Management Studio für SSIS, verschiedene Stored Procedures für die Performanceanalyse

Analysis Services

• Die größte Neuerung ist ein neuer, spaltenbasierter Speichermodus basierend auf der VertiPaq Engine (die zuerst mit PowerPivot eingeführt wurde). Eine Analysis Services Instanz verwendet entweder das tabellarische oder das multidimensionale Modell, das wird bei der Installation der Instanz festgelegt.
• Daneben gibt es auch Verbesserungen für das multidimensionale Modell, insbesondere eine skalierbarere String-Speicherung und die Unterstützung von Tabellen mit mehr als 2 Milliarden Zeilen
• Für PowerPivot gibt es einige neue DAX-Funktionen sowie Erweiterungen bei der Administrationsschnittstelle in SharePoint

Reporting Services

• Project “Crescent” ist ein neues, hochgradig interaktives Datenanalyse-Werkzeug, mit dem Fachanwender rein webbasiert (Silverlight) per Drag & Drop eigene Analysen erstellen können – und das in Schön! In der aktuellen CTP3 kann Crescent nur auf tabellarischen Analysis Services Modellen aufsetzen
• Der SharePoint Mode von Reporting Services (und damit auch “Crescent”) ist jetzt als SharePoint Shared Service implementiert. Das verbessert sowohl die Verwaltung als auch die Skalierbarkeit von Reporting Services im SharePoint Mode. Auch Claims Authentication wird (abhängig von der Datenquelle) damit unterstützt.
• Mit den neuen Data Alerts können Endbenutzer sich über wichtige Änderungen in Berichten informieren lassen, z.B. wenn eine bestimmte Zahl in einem Bericht einen Schwellwert über- oder unterschreitet
• Der Word- und der Excel-Renderer geben die Berichte jetzt im Office 2007/2010 Format aus (xlsx/docx). Das ermöglicht das Rendern größerer Berichte insbesondere nach Excel. Ein Export in die alten Formate (xls/doc) ist ebenfalls noch möglich, muss aber in rsreportserver.config aktiviert werden.

Master Data Services

• Es gibt eine neue Excel-Oberfläche zur Verwaltung der Stammdaten
• Integration mit Data Quality Services
• Neues Benutzerinterface
• Installation ist Teil der SQL Server Installation

Wie man sieht gibt es also viel zu testen!

Hier meine Denali-Ressourcen

• SQL Server “Denali” CTP 1 verfügbar–was ist neu?
• FileTable in SQL Server “Denali”–Dateizugriff auf SQL Server Filestream Daten von jeder Anwendung
• Columnstore Indizes in SQL Server “Denali”
• Volltextfeatures in SQL Server “Denali” Teil 1: Eigenschaftssuche und NEAR

Und schließlich die Downloads und anderen Informationen:

• Produktseite
• Download Denali CTP
• Release Notes
• Dokumentation
• Feedback/Bugs zur Denali CTP bitte auf Connect melden

Gruß,
Steffen

Eigenschaftssuche (Property Search)

Diese Funktion ermöglicht die Suche nach Dokumenteigenschaften (Titel, Autor usw.), insbesondere in Office-Dokumenten. Damit das funktioniert muss zuerst eine Search Property List angelegt werden (mit CREATE SEARCH PROPERTY LIST), die die zu suchenden Eigenschaften enthält. Dazu müssen die Eigenschaften über ihre GUID (die man z.B. aus der MSDN Dokumentation erhält) geladen werden:

ALTER SEARCH PROPERTY LIST DocumentTablePropertyList

   ADD 'Title'

   WITH ( PROPERTY_SET_GUID = 'F29F85E0-4FF9-1068-AB91-08002B27B3D9', PROPERTY_INT_ID = 2,

      PROPERTY_DESCRIPTION = 'System.Title - Title of the item.' );

Diese Search Property List wird dann einem Volltextindex zugeordnet:

ALTER FULLTEXT INDEX ON Production.Document SET SEARCH PROPERTY LIST DocumentTablePropertyList;

Außerdem müssen natürlich die IFilter für die jeweiligen Dokumenttypen installiert sein, und zwar je nach Serverversion in 32 oder 64 Bit. Die IFilter für die Office 2007/2010 Dateiformate findet man hier (nach der Installation den Server neu starten!). Darüber hinaus muss die Verwendung der IFilter in SQL Server aktiviert werden (EXEC sp_fulltext_service load_os_resources, 1)

Nach dem Hinzufügen der Eigenschaften wird der Volltextindex neu aufgebaut. Danach kann man nach Dokumenteigenschaften suchen:

SELECT Document FROM Production.Document

  WHERE CONTAINS(PROPERTY(Document,'Author'), 'Steffen');

Anpassbares NEAR

Bisher tat das Prädikat NEAR in der Volltextsuche nicht wirklich das, was man erwartet: Es definierte nämlich lediglich, dass die zwei (oder mehr) Begriffe im selben Dokument vorhanden sein müssen, keineswegs dass sie sich auch tatsächlich in einem bestimmten Abstand zueinander befinden müssen. Lediglich auf den Rang des Dokuments in der Ergebnisliste wirkte sich die Nähe der Suchbegriffe aus.

In SQL Server Denali kann man jetzt genau festlegen, wie nahe die Suchwörter sein sollen. So wird hier nach “rear” und “left” mit maximal 3 Worten dazwischen gesucht:

SELECT DocumentNode, DocumentSummary, Document

       FROM Production.Document AS DocTable INNER JOIN

       CONTAINSTABLE(Production.Document, Document, 'NEAR((left, rear), 3)' ) AS KEY_TBL

       ON DocTable.DocumentNode = KEY_TBL.[KEY];

Es ist auch möglich nach mehr als zwei Begriffen zu suchen, dann gibt die Zahl die maximale Anzahl Nicht-Suchbegriffe zwischen dem ersten und dem letzten Suchbegriff an. Die Reihenfolge der Begriffe im Dokument ist nicht wichtig, kann aber mit einem angehängten TRUE erzwungen werden: NEAR((left, rear), 3, TRUE).

Performance

Neben funktionalen Neuerungen in der Volltextsuche wurde auch stark an der Geschwindigkeit und Skalierbarkeit gearbeitet. Ziel ist es, mindestens 100 Millionen Dokumente in einem Volltextindex zu unterstützen. Meine ersten Versuche mit einer Tabelle mit 20 Millionen Zeilen und 19 Volltext-indizierten Spalten waren sehr vielversprechend: ein Satz aus 22 Abfragen hat nur 7-10 Sekunden gebraucht – auf meinem (schnellen) Laptop.

Wichtig ist dabei die Formulierung der Abfragen. Die Abfrage

SELECT '"hemoglob*"', COUNT(*) FROM ft_publications WHERE CONTAINS (*, '"hemoglob*"')

führt zu einem Join zwischen der Basistabelle und dem Volltextindex, was die Abfrage bei großen Ergebnismengen langsam macht. Die inhaltlich gleichwertige Abfrage

SELECT '"hemoglob*"', COUNT(*) FROM CONTAINSTABLE (ft_publications, *, '"hemoglob*"')

ist hingegen unabhängig von der Anzahl gefundener Dokumente schnell (auf meinem Rechner im zweistelligen Millisekundenbereich). Das gilt übrigens auch mit früheren Versionen von SQL Server

Im nächsten Artikel wird es dann um die semantische Suche gehen

Gruß,
Steffen