Deutsch

Ausführen von SQL Server 2008 in einer HyperVUmgebung Best Practices und Überlegungen zur Leistung

AlexeiK — Mon, 03 May 2010 10:30:00 GMT

Autoren: Lindsey Allen, Mike Ruthruff, Prem Mehra

Technische Lektoren: Cindy Gross, Burzin Patel, Denny Lee, Michael Thomassy, Sanjay Mishra, Savitha Padmanabhan, Tony Voellm, Bob Ward

Veröffentlicht: Oktober 2008

Betrifft: SQL Server 2008

Zusammenfassung:

Hyper-V in Windows Server 2008 stellt eine leistungsfähige Virtualisierungstechnologie dar, mit der die IT-Abteilungen von Unternehmen Server mit geringer Auslastung konsolidieren, die Gesamtbetriebskosten senken und gleichzeitig die Quality of Service aufrechterhalten und verbessern können. In diesem Dokument werden auf Grundlage von Testszenarien für grundlegende Anwendungen von SQL Server Best Practices für die Ausführung von SQL Server in einer Windows Hyper-V-Umgebung vorgestellt.

Die zehn wichtigsten bewährten Methoden zur Erstellung eines großen skalierbaren relationalen Data Warehouse

AlexeiK — Mon, 03 May 2010 10:01:00 GMT

Mitwirkende: Stuart Ozer mit Prem Mehra und Kevin Cox

Technische Lektoren: Lubor Kollar, Thomas Kejser, Denny Lee, Jimmy May, Michael Redman, Sanjay Mishra

Das Erstellen eines großen skalierbaren relationalen Data Warehouse ist eine komplexe Aufgabe. In diesem Artikel werden einige Entwurfsmethoden beschrieben, die bei der Konzeption eines effizienten und umfassenden relationalen Data Warehouse mit SQL Server hilfreich sind. Für die meisten umfassenden Data Warehouses wird Tabellen- und Indexpartitionierung verwendet. Daher drehen sich hier viele Empfehlungen um das Thema Partitionierung. Der Großteil der Tipps basiert auf Erfahrungen, die beim Erstellen von umfassenden Data Warehouses mit SQL Server 2005 gesammelt wurden.

Erwägung große Faktentabellen zu partitionieren

Ziehen Sie in Erwägung, Faktentabellen mit einer Größe zwischen 50 und 100 GB (oder größer) zu partitionieren.
Partitionierung kann die Verwaltung erleichtern und sorgt oftmals auch für Leistungszuwächse.

Schnellere und granulare Indexwartung
Flexiblere Sicherungs- und Wiederherstellungsoptionen
Schnelleres Laden und Löschen von Daten

Schnellere Abfragen, wenn diese auf eine Einzelpartition beschränkt sind
Normalerweise wird die Faktentabelle auf dem Datumsschlüssel partitioniert.
Ermöglicht flexible Fenster.
Ermöglicht das Löschen von Partitionen.

Erstellung eines gruppierten (clustered) Index auf dem Datumsschlüssel der Faktentabelle
Dadurchi werden effiziente Abfragen unterstützt, um Cubes aufzufüllen oder einen historischen Datenslice abzurufen.

Wenn Sie Daten in einem Batchfenster laden, verwenden Sie für den gruppierten (clustered) Index in der Faktentabelle die Optionen "ALLOW_ROW_LOCKS = OFF" und "ALLOW_PAGE_LOCKS = OFF". Dadurch werden Tabellenscanvorgänge während der Abfragezeit beschleunigt, und ein Übermaß an Sperraktivitäten bei umfangreichen Updates wird vermieden.
Erstellen von nicht-gruppierten (nonclustered) Indizes für jeden Fremdschlüssel. Dadurch werden Abfragen ermittelt, um Zeilen auf Basis eines selektiven Dimensionsprädikats zu extrahieren. Verwenden Sie Dateigruppen für verwaltungsbezogene Anforderungen wie Sicherung und Wiederherstellung, partielle Datenbankverfügbarkeit usw.

Wählen Sie die Partitionsaufteilung sorgfältig aus.

Die meisten Kunden verwenden Monat, Quartal oder Jahr.
Effiziente Löschvorgänge werden durch Löschen von einer vollständingen Partition ermöglicht.
Es ist schneller zunächst eine komplette Partition vollständig zu laden.

Partitionen für Tage sind für tägliche Ladevorgänge sind unter Umständen eine empfehlenswerte Option.
Beachten Sie dabei, dass eine Tabelle maximal 1.000 Partitionen enthalten kann.

Die Partitionsaufteilung wirkt sich auf Abfrageparallelismus aus.

Für SQL Server 2005:

Abfragen, die eine einzelne Partition betreffen, können bis zu MAXDOP (maximaler Parallelismusgrad) parallelisiert werden.
Bei Abfragen, die mehrere Partitionen betreffen, wird pro Partition ein Thread bis zu MAXDOP verwendet.

Für SQL Server 2008:

Parallele Threads werden bis zu MAXDOP proportional auf die Scanpartitionen verteilt. Es können acuh mehrere Threads pro Partition verwendet werden, wenn mehrere Partitionen gescannt werden müssen.

Verwenden Sie keinen Partitionsentwurf, bei dem nur zwei oder drei Partitionen von häufigen Abfragen betroffen sind, wenn Sie MAXDOP-Parallelität benötigen (dabei wird MAXDOP = 4 oder größer angenommen).

Korrekter Entwurf von Dimensionstabellen

Verwenden Sie für alle Dimensionen mit Ausnahme der Datumsdimension einen ganzzahligen Ersatzschlüssel. Verwenden Sie die kleinstmögliche ganze Zahl für die Dimensionsersatzschlüssel. Dadurch behalten die Faktentabellen eine überschaubare Größe.
Verwenden Sie einen aussagekräftigen ganzzahligen Datumsschlüssel, der vom DATETIME-Datentyp abgeleitet werden kann (z. B.: 20060215).

Verwenden Sie für die Datumsdimension keinen Ersatzschlüssel.
Einfach zu verfassende Abfragen, bei denen eine WHERE-Klausel in dieser Spalte verwendet wird. Dies ermöglicht Partitionslöschungen der Faktentabelle.

Erstellen Sie einen gruppierten Index für den Ersatzschlüssel jeder Dimensionstabelle, und erstellen Sie einen nicht gruppierten Index für den Geschäftsschlüssel (möglicherweise kombiniert mit einem Gültigkeitsdatum für Zeilen), um bei Ladevorgängen Ersatzschlüsselsuchen zu unterstützen.
Erstellen Sie nicht gruppierte Indizes für andere häufig durchsuchte Dimensionsspalten.
Partitionieren Sie keine Dimensionstabellen.
Erzwingen Sie keine Fremdschlüsselbeziehungen zwischen den Fakten- und Dimensionstabellen, um schnelleres Laden von Daten zu ermöglichen. Sie können Fremdschlüsseleinschränkungen mit NOCHECK erstellen, um die Beziehungen zu dokumentieren, ohne sie jedoch zu erzwingen. Gewährleisten Sie Datenintegrität mit Transformationssuchvorgängen, oder führen Sie die Datenintegritätsprüfungen an der Datenquelle aus.

Erstellen von effektiven Abfragen für das Löschen von Partitionen

Platzieren Sie ein Abfrageprädikat (WHERE-Bedingung) nach Möglichkeit immer direkt auf dem Partitionierungsschlüssel (Datumsdimensionsschlüssel) der Faktentabelle.

Verwalten von Daten mithilfe der Methode für flexible Fenster

Verwalten Sie ein Gleitfenster für Zeit, um Onlinezugriffe auf die Faktentabellen zu erleichtern. Laden Sie die neuesten Daten, und entladen Sie die ältesten.
Achten Sie darauf, dass sich leere Partitionen immer an beiden Enden des Partitionsbereichs befinden, um zu gewährleisten, dass die Partitionsaufteilung (vor dem Laden neuer Daten) und die Partitionszusammenführung (nach dem Entladen alter Daten) keine Datenverschiebung zur Folge hat.
Teilen Sie aufgefüllte Partitionen nicht auf, bzw. führen Sie diese nicht zusammen. Das Aufteilen oder Zusammenführen von aufgefüllten Partitionen kann sich als äußerst ineffizient erweisen, da dadurch unter Umständen die Generierung von Protokollen um das Vierfache ansteigt und auch tiefgreifende Sperrungen vorgenommen werden.
Erstellen Sie die Stagingtabelle für Ladevorgänge in der gleichen Dateigruppe wie die Partition, die geladen wird.
Erstellen Sie die Stagingtabelle für Entladevorgänge in der gleichen Dateigruppe wie die Partition, die gelöscht wird.
Der geringste Zeitaufwand entsteht, wenn Sie jeweils die neueste vollständige Partition laden. Dies ist jedoch nur möglich, wenn die Partitionsgröße der Datenladefrequenz entspricht (Beispiel: Sie verwenden eine Partition pro Tag und laden einmal täglich Daten).
Wenn die Partitionsgröße nicht der Datenladefrequenz entspricht, laden Sie die aktuellste Partition inkrementell.
Verschiedene Optionen für das Laden von Massendaten in eine partitionierte Tabelle werden im Whitepaper http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/loading_bulk_data_partitioned_table.mspx erörtert.
Entladen Sie immer jeweils eine Partition.

Effizientes Laden der ursprünglichen Daten

Verwenden Sie beim ersten Laden von Daten das Wiederherstellungsmodell SIMPLE oder BULK LOGGED.
Erstellen Sie die partitionierte Faktentabelle mit dem gruppierten Index.
Erstellen Sie nicht indizierte Stagingtabellen für jede Partition, und trennen Sie Quelldatendateien, um jede Partition aufzufüllen.
Füllen Sie die Stagingtabellen parallel auf.

Verwenden Sie mehrere der folgenden Tasks: BULK INSERT, BCP oder SSIS.

Erstellen Sie parallel auszuführende Ladeskripts, deren Zahl der der CPUs entspricht, falls kein E/A-Engpass vorliegt. Wenn die E/A-Bandbreite beschränkt ist, verwenden Sie eine geringere Anzahl von Skripts parallel.
Verwenden Sie beim Ladevorgang die Batchgröße 0.
Verwenden Sie beim Ladevorgang die Commitgröße 0.
Verwenden Sie TABLOCK.
Verwenden Sie BULK INSERT, wenn es sich bei den Quellen um Flatfiles auf dem gleichen Server handelt. Verwenden Sie BCP oder SSIS, wenn Daten von Remotecomputern verschoben werden.

Erstellen Sie einen gruppierten Index für jede Stagingtabelle, und erstellen Sie anschließend entsprechende CHECK-Einschränkungen.
Verschieben Sie alle Partitionen per SWITCH-Anweisung in die partitionierte Tabelle.
Erstellen Sie nicht gruppierte Indizes für die partitionierte Tabelle.
Es besteht die Möglichkeit, eine Datenmenge von 1 TB in weniger als einer Stunde auf einen Server mit 64 CPUs zu laden, wenn das SAN einen Durchsatz von 14 GB/s ermöglicht (nicht indizierte Tabelle). Weitere Informationen finden Sie im SQLCAT-Blogeintrag unter http://blogs.msdn.com/sqlcat/archive/2006/05/19/602142.aspx.

Effizientes Löschen von alten Daten

Verwenden Sie nach Möglichkeit Partitionswechsel.
So löschen Sie Millionen von Zeilen aus nicht partitionierten indizierten Tabellen

Verwenden Sie nicht "DELETE FROM ...WHERE ..."

Schwerwiegende Sperrungs- und Protokollierungsprobleme
Langes Rollback bei Abbruch des Löschvorgangs

Es ist normalerweise schneller

INSERTvon Datensätzen, die in einer nicht indizierten Tabelle behalten werden sollen
Erstellen von Indizes für die Tabelle
Umbenennen der neuen Tabelle, um die ursprüngliche Tabelle zu ersetzen

Als Alternative können Löschvorgänge durch wiederholtes Ausführen des folgenden Befehls in einer Schleife schrittweise ausgeführt werden:

DELETE TOP (1000) ... ;

COMMIT

Eine andere Möglichkeit besteht darin, die Zeile so zu aktualisieren, dass sie als gelöscht markiert wird, und sie später zu einem unkritischen Zeitpunkt zu löschen.

Manuelles Verwalten von Statistiken

Statistiken für partitionierte Tabellen werden allgemein für die gesamte Tabelle verwaltet.
Führen Sie nach dem Laden von neuen Daten eine manuelle Aktualisierung der Statistiken durch.
Führen Sie nach dem erneuten Erstellen eines Indexes für eine Partition eine manuelle Aktualisierung der Statistik durch.
Wenn Sie Statistiken regelmäßig nach periodischen Ladevorgängen aktualisieren, können die automatischen Statistiken für die Tabelle deaktiviert werden.
Dies ist wichtig für das Optimieren von Abfragen, die ggf. nur die neuesten Daten lesen müssen.
Durch Aktualisieren der Statistik für kleine Dimensionstabellen nach inkrementellen Ladevorgängen wird die die Leistung ebenfalls verbessert. Verwenden Sie die FULLSCAN-Option für die Aktualisierungsstatistik für Dimensionstabellen, um genauere Abfragepläne zu erhalten.

Planen von effizienten Sicherungsstrategien

Das Sichern der gesamten Datenbank kann für eine sehr große Datenbank viel Zeit in Anspruch nehmen.

Beispielsweise kann das Sichern einer Datenbank mit einer Größe von 2 TB auf einem RAID-5-Datenträger mit einer Zehnerspindel in einem SAN bis zu zwei Stunden in Anspruch nehmen (bei einer Rate von 275 MB/s).

Das Sichern von Momentaufnahmen mithilfe der SAN-Technologie ist eine sehr gute Möglichkeit.
Verringern Sie das Volumen von regelmäßig zu sichernden Daten.

Die Dateigruppen für die historischen Partitionen können als schreibgeschützt markiert werden.
Führen Sie eine Dateigruppensicherung aus, wenn eine Dateigruppe einen Schreibschutz erhält.
Führen Sie regelmäßige Sicherungen nur für die Lese-/Schreibdateigruppen aus.

Hinweis: Wiederherstellungen der schreibgeschützten Dateigruppen können nicht parallel ausgeführt werden.

, Datentypen, Data Warehouse, Datenbank, Entwurf, Index, Spiegelung, Optimierung, Partitionen, Leistung, Präzision, Verarbeitung, Abfragen, Skalierbarkeit, Sicherheit, Reporting Services, Integrationsdienste

Die zehn wichtigsten SQL Server 2008-Funktionen für Datenbankadministratoren (DBA)

AlexeiK — Mon, 03 May 2010 09:48:00 GMT

Autor: Mike Weiner

Mitwirkender: Burzin Patel

Lektoren: Lubor Kollar, Kevin Cox, Bill Emmert, Greg Husemeier, Paul Burpo, Joseph Sack, Denny Lee, Sanjay Mishra, Lindsey Allen, Mark Souza

Microsoft SQL Server 2008 bietet eine Reihe von Verbesserungen und neuen Funktionen und basiert dabei auf früheren Versionen. Unter anderem fallen die Belange Verwaltung, Datenbankwartung, Verwaltbarkeit, Verfügbarkeit, Sicherheit und Leistung in die Zuständigkeit des Datenbankadministrators. In diesem Artikel werden die zehn wichtigsten Features von SQL Server 2008 vorgestellt (in alphabetischer Reihenfolge), die Datenbankadministratoren bei der Erfüllung ihrer Aufgaben unterstützen. Neben einer kurzen Beschreibung jedes Features wird erläutert, wie das betreffende Feature optimal genutzt werden kann. Zusätzlich werden einige wichtige Aspekte zur Verwendung erörtert.

Aktivitätsmonitor

Beim Behandeln von Leistungsproblemen oder beim Überwachen eines Servers in Echtzeit führt der Datenbankadministrator in der Regel einige Skripts aus oder überprüft eine Reihe von Quellen, um allgemeine Informationen zu den ausgeführten Prozessen zu sammeln und das Problem zu bestimmen. SQL Server 2008-Aktivitätsmonitor konsolidiert die Informationen durch eine grafische Darstellung von aktiven und kürzlich ausgeführten Prozessen. Die Anzeige bietet dem Datenbankadministrator eine allgemeine Ansicht und die Möglichkeit, einen Drilldown auf Prozesse auszuführen und Wartestatistiken anzuzeigen, um Probleme zu erkennen und zu beheben.

Klicken Sie zum Öffnen des Aktivitätsmonitors mit der rechten Maustaste im Objekt-Explorer auf den registrierten Servernamen, und klicken Sie anschließend auf Aktivitätsmonitor, oder verwenden Sie das standardmäßige Symbolleistensymbol in SQL Server Management Studio. Im Aktivitätsmonitor steht dem Datenbankadministrator ein Übersichtsabschnitt zur Verfügung, der Ausgaben generiert, die mit dem Windows Task-Manager und Drilldownkomponenten vergleichbar sind, um bestimmte Prozesse, Ressourcenwartevorgänge, Dateidaten-E/As und aktuelle aufwendige Abfragen zu betrachten (siehe Abbildung 1).

Abbildung 1: Anzeigen der SQL Server 2008-Aktivitätsmonitoransicht über Management Studio

HINWEIS: Sie können durch Klicken auf den Aktivitätsmonitor mit der rechten Maustaste auf eine Aktualisierungsintervalleinstellung zugreifen. Wenn der Wert auf einen niedrigen Schwellenwert (unter zehn Sekunden) festgelegt wird, kann in einem Produktionssystem mit hohem Volumen die allgemeine Systemleistung beeinträchtigt werden.

Mit dem Aktivitätsmonitor können Datenbankadministratoren die folgenden Aufgaben ausführen:

· Den Aktivitätsmonitor per Rechtsklick anhalten und fortsetzen. Dadurch kann der Datenbankadministrator einen bestimmten Zeitpunkt zur späteren Prüfung „speichern“, ohne dass er aktualisiert oder überschrieben wird. Seien Sie jedoch vorsichtig, da die Daten beim manuellen Aktualisieren, Erweitern oder Minimieren eines Abschnitts aktualisiert werden.

· Klicken Sie mit der rechten Maustaste auf ein Zeilenelement, um den vollständigen Abfragetext oder den grafischen Ausführungsplan über kürzlich ausgeführte aufwendige Abfragen anzuzeigen.

· Führen Sie eine Profiler-Ablaufverfolgung aus, oder beenden Sie einen Prozess in der Prozessansicht. Zu Profiler-Ereignissen zählen die Ereignisse RPC:Completed, SQL:BatchStarting und SQL:BatchCompleted sowie Audit Login und Audit Logout.

Der Aktivitätsmonitor bietet zudem die Möglichkeit, Aktivitäten in einer beliebigen SQL Server 2005-Instanz (lokal oder remote) zu überwachen, die in SQL Server Management Studio registriert ist.

[SQL Server] Audit

Durch die Möglichkeit, Ereignisse zu überwachen und zu protokollieren – zum Beispiel, welcher Benutzer auf Objekte zugreift und welche Zeitänderungen aufgetreten sind – kann der Datenbankadministrator Kompatibilitätsstandards für behördliche oder organisationsweit geltende Sicherheitsanforderungen erfüllen. Einblicke in die Ereignisse, die in der Umgebung auftreten, können dem Datenbankadministrator zudem das Erstellen eines Risikominimierungsplans zur Gewährleistung der Umgebungssicherheit erleichtern.

In SQL Server 2008 (nur Enterprise Edition und Developer Edition) können der Datenbankadministrator und andere Benutzer mithilfe der von SQL Server Audit bereitgestellten Automatisierung Überwachungen von verschiedenen Server- und Datenbankkomponenten aktivieren, speichern und anzeigen. Das Feature ermöglicht Überwachungen mit einer Genauigkeit, die der Server- und/oder Datenbankebene entspricht.

Unter anderem sind folgende Überwachungsaktionsgruppen auf Serverebene verfügbar:

· FAILED_LOGIN_GROUP: Verfolgt fehlerhafte Anmeldungen nach.

· BACKUP_RESTORE_GROUP: Zeigt an, wann eine Datenbank gesichert oder wiederhergestellt wurde.

· DATABASE_CHANGE_GROUP: Überwacht das Erstellen, Ändern oder Löschen einer Datenbank.

Überwachungsaktionsgruppen auf Datenbankebene:

· DATABASE_OBJECT_ACCESS_GROUP: Wird ausgelöst, wenn eine CREATE-, ALTER- oder DROP-Anweisung für Datenbankobjekte ausgeführt wird.

· DATABASE_OBJECT_PERMISSION_CHANGE_GROUP: Wird ausgelöst, wenn GRANT, REVOKE oder DENY für Datenbankobjekte verwendet wird.

Es sind auch Überwachungsaktionen wie SELECT, DELETE oder EXECUTE vorhanden. Weitere Informationen einschließlich einer vollständigen Liste der Überwachungsgruppen und Aktionen finden Sie unter SQL Server Audit-Aktionsgruppen und -Aktionen.

Überwachungsergebnisse können zum Anzeigen an ein Datei- oder Ereignisprotokoll gesendet werden (Windows-Sicherheit oder -System). Überwachungsinformationen werden mithilfe von Extended Events, einem anderen neuen Feature in SQL Server 2008, erstellt.

Mithilfe von SQL Server 2008-Überwachungen kann der Datenbankadministrator nun Fragen beantworten, die früher im Nachhinein äußerst schwierig zu klären waren, z. B. „Von wem wurde dieser Index gelöscht?“, „Wann wurde die gespeicherte Prozedur geändert?“, „Was wurde geändert, das dem Benutzer möglicherweise nicht den Zugriff auf die Tabelle ermöglicht?“ oder sogar „Wer führte die SELECT- oder UPDATE-Anweisung für die [dbo.Payroll]-Tabelle aus?“

Weitere Informationen zur Verwendung von SQL Server Audit und einige Implementierungsbeispiele finden Sie im SQL Server 2008-Kompatibilitätshandbuch.

Sicherungskomprimierung

Dieses Feature war lange Zeit ein häufig geäußerter Wunsch von Datenbankadministratoren für SQL Server. Das Warten hat nun ein Ende, und zwar genau rechtzeitig. Zahlreiche Faktoren, wie verlängerte Datenbeibehaltungsfristen und der Bedarf an höheren Kapazitäten zur physischen Datenspeicherung, sorgten in letzter Zeit für einen sprunghaften Anstieg der Datenbankgröße. Die Sicherung einer großen Datenbank kann einen beträchtlichen Zeitaufwand nach sich ziehen, und für die Sicherungsdateien muss umfassender Speicherplatz bereitgestellt werden.

Mit der SQL Server 2008-Sicherungskomprimierung wird die Sicherungsdatei beim Ausschreiben komprimiert, wobei weniger Speicherplatz, weniger Datenträger-E/A und weniger Zeit benötigt wird. In Labortests, die mit echten Kundendaten durchgeführt wurden, wurde in zahlreichen Fällen eine Verringerung der Sicherungsdateigröße um 70 bis 85 % beobachtet. Die Tests ergaben auch einen Rückgang der Sicherungs- und Wiederherstellungsdauer um 45 %. Es ist zu beachten, dass die zusätzliche Verarbeitung zu höherer Prozessorauslastung führt. Um die CPU-intensive Sicherung zu isolieren und deren Auswirkungen auf andere Prozesse zu verringern, kann ggf. ein anderes in diesem Whitepaper beschriebenes Feature verwendet werden: Ressourcenkontrolle.

Die Komprimierung wird durch Angabe der WITH COMPRESSION-Klausel im BACKUP-Befehl (weitere Informationen finden Sie unter SQL Server-Onlinedokumentation) oder durch Auswählen der Klausel auf der Seite Optionen im Dialogfeld Datenbank sichern erreicht. Damit nicht alle vorhandenen Sicherungsskripts geändert werden müssen, kann auch mit einer globalen Einstellung das Komprimieren aller auf einer Serverinstanz erstellten Sicherungen standardmäßig aktiviert werden. (Auf diese Einstellung wird mithilfe der Seite Datenbankeinstellungen des Dialogfelds Servereigenschaften oder durch Ausführen von sp_configure zugegriffen, wobei der Standardwert für die Sicherungskomprimierung auf 1 festgelegt ist.) Während die Komprimierungsoption für den Sicherungsbefehl explizit angegeben werden muss, erkennt der Wiederherstellungsbefehl automatisch, dass eine Sicherung komprimiert ist und dekomprimiert sie beim Wiederherstellungsvorgang.

Die Sicherungskomprimierung ist ein sehr nützliches Feature, mit dem der Datenbankadministrator Speicherplatz und Zeit sparen kann. Weitere Informationen zur Optimierung der Sicherungskomprimierung finden Sie im technischen Hinweis unter Leistungsoptimierung für Sicherungskomprimierung in SQL Server 2008. HINWEIS: Das Erstellen von komprimierten Sicherungen wird nur in den Editionen SQL Server 2008 Enterprise und Developer unterstützt; allerdings ermöglicht jede Edition von SQL Server 2008 die Wiederherstellung einer komprimierten Sicherung.

Zentrale Verwaltungsserver

Datenbankadministratoren sind häufig nicht nur für die Verwaltung von einer, sondern von zahlreichen SQL Server-Instanzen in der Umgebung zuständig. Durch die Möglichkeit zur Zentralisierung der Verwaltung einiger SQL Server-Instanzen von einer einzelnen Quelle aus kann der Datenbankadministrator viel Zeit und Aufwand sparen. Mithilfe der Implementierung der zentralen Verwaltungsserver, auf die über die Komponente für registrierte Server in SQL Server Management Studio zugegriffen wird, kann der Datenbankadministrator über eine einzelne Verwaltungskonsole auf Computern mit SQL Server in der Umgebung eine Reihe von Verwaltungsaufgaben ausführen.

Zentrale Verwaltungsserver ermöglichen dem Datenbankadministrator das Registrieren einer Gruppe von Servern und das Anwenden von Funktionen auf den Server (als Gruppe), z. B. die folgenden:

· Abfrageausführung für mehrere Server: Ein Skript kann nun von einer Quelle für mehrere Computer mit SQL Server ausgeführt werden und an diese Quelle zurückgegeben werden, ohne dass jeweils eine gesonderte Anmeldung an jedem Server erforderlich ist. Dies kann in Fällen außerordentlich hilfreich sein, in denen Daten aus Tabellen auf mindestens zwei Computern mit SQL Server angezeigt oder verglichen werden müssen, ohne dass eine verteilte Abfrage ausgeführt wird. Sofern die Syntax in früheren Serverversionen unterstützt wird, kann eine Abfrage vom Abfrage-Editor in SQL Server 2008 auch für SQL Server 2005- und SQL Server 2000-Instanzen ausgeführt werden. Weitere Informationen finden Sie im Teamblog zur SQL Server-Verwaltbarkeit, insbesondere unter Abfrageausführung für mehrere Server in SQL Server 2008 .

· Importieren und Auswerten von Richtlinien auf mehreren Servern: Als Teil der richtlinienbasierten Verwaltung (ein weiteres neues SQL Server 2008-Feature, das in diesem Artikel vorgestellt wird) bietet SQL Server 2008 die Möglichkeit, Richtliniendateien in bestimmte zentrale Verwaltungsservergruppen zu importieren und ermöglicht die Auswertung von Richtlinien auf allen Servern, die in der Gruppe registriert sind.

· Steuern von Diensten und Anzeigen des SQL Server-Konfigurations-Managers: Zentrale Verwaltungsserver unterstützen die Bereitstellung eines zentralen Orts, an dem Datenbankadministratoren den Dienststatus anzeigen und den Status auch ändern können, sofern sie die entsprechenden Berechtigungen besitzen.

· Importieren und Exportieren der registrierten Server: Server in zentralen Verwaltungsservern können für die Verwendung zwischen Datenbankadministratoren oder verschiedenen Installationen von SQL Server Management Studio-Instanzen exportiert und importiert werden. Dies ist eine Alternative zum Importieren bzw. Exportieren von Servern in lokale Gruppierungen in SQL Server Management Studio durch Datenbankadministratoren.

Beachten Sie, dass Berechtigungen über die Windows-Authentifizierung erzwungen werden, sodass ein Benutzer abhängig vom in der Gruppe der zentralen Verwaltungsserver registrierten Server unter Umständen unterschiedliche Rechte und Berechtigungen besitzt. Weitere Informationen finden Sie unter Verwalten mehrerer Server mithilfe von zentralen Verwaltungsservern und in einem Blog von Kimberly Tripp: SQL Server 2008 Central Management Servers-have you seen these? (möglicherweise in englischer Sprache)

Datenauflister und Verwaltungs-Data Warehouse

Leistungsoptimierung und Problembehandlung sind zeitaufwändige Aufgaben, die möglicherweise sehr gute Kenntnisse im Umgang mit SQL Server und Datenbanken erfordern. Windows-Systemmonitor (Perfmon), SQL Server Profiler und dynamische Verwaltungssichten (DMVs) waren bei einigen dieser Aufgaben hilfreich, aber oft auch aufdringlich, arbeitsaufwändig oder die abweichenden Datensammlungsmethoden konnten nur umständlich zusammengefasst und ausgewertet werden.

SQL Server 2008 stellt ein vollständig erweiterbares, auch als Datenauflister bezeichnetes Leistungsdatensammlungs- und Warehouse-Tool bereit, das aussagefähige Einblicke in die Leistungsstatistiken bietet. Im Lieferumfang des Tools sind mehrere Datensammlungsagenten, ein zentralisiertes Datenrepository zum Aufbewahren von Leistungsdaten mit der Bezeichnung Verwaltungs-Data Warehouse und mehrere Musterberichte zur Präsentation der erfassten Daten enthalten. Beim Datenauflister handelt es sich um ein skalierbares Tool, mit dem durch Verwendung einer vollständig anpassbaren Datensammlungsfrequenz Daten von mehreren Quellen, wie z. B. dynamischen Verwaltungssichten, Perfmon, Transact-SQL-Abfragen, erfasst und angepasst werden. Der Datenauflister kann dahingehend erweitert werden, dass er Daten für alle messbaren Attribute einer Anwendung erfasst.

Ein weiteres hilfreiches Feature des Verwaltungs-Data Warehouse ist die Möglichkeit der Installation auf einem beliebigen SQL Server und die anschließende Erfassung von Daten von einer oder mehreren SQL Server-Instanzen innerhalb der Umgebung. Dies kann bei der Minimierung der Auswirkungen auf die Leistung von Produktionssystemen und bei der Verbesserung der Skalierbarkeit im Hinblick auf die Überwachung und Erfassung von Daten von zahlreichen Servern helfen. Bei Labortests haben wir einen Durchsatzrückgang von etwa 4 % festgestellt, als wir die Agenten und das Verwaltungs-Data Warehouse auf einem Server ausgeführt haben, der an der Kapazitätsgrenze ausgeführt wurde (über eine OLTP-Arbeitsauslastung). Die Auswirkungen variieren je nach Erfassungsintervall (da der Test bei erweiterter Arbeitsauslastung mit 15-minütigen Abrufen in das Warehouse durchgeführt wurde) und können während Erfassung der Daten in den Intervallen sogar noch verschlimmert werden. Letztendlich sollte noch etwas Kapazität eingeplant werden, da der Prozess DCExec.exe Arbeitsspeicher- und Prozessorressourcen in Anspruch nimmt. Zusätzlich erhöhen Schreibvorgänge im Verwaltungs-Data Warehouse die E/A-Arbeitsauslastung und Speicherplatzreservierung, die für Daten- und Protokolldateien erforderlich sind.

Das folgende Diagramm (Abbildung 2) zeigt einen typischen Bericht des Datenauflisters.

Abbildung 2: Anzeige eines SQL Server 2008-Berichts eines Datenauflisters

Dieser Bericht enthält Informationen zur SQL Server-Verarbeitung für den Zeitraum der Datenerfassung. Ereignisse wie Wartevorgänge, CPU, E/A, Speicherauslastung und aufwändige Abfragestatistiken werden erfasst und angezeigt. Ein Datenbankadministrator kann die Berichte außerdem detailliert betrachten, um sich auf eine bestimmte Abfrage oder einen bestimmten Vorgang zur weiteren Untersuchung sowie zur Erkennung und Behebung von Leistungsproblemen zu konzentrieren. Mit der Datensammlung, Aufbewahrung und Berichterstellung kann der Datenbankadministrator eine proaktive Überwachung der SQL Server in der Umgebung einrichten und Leistungsschwankungen im Überwachungszeitraum erkennen und bewerten. Das Datenauflister- und Verwaltungs-Data Warehouse-Feature wird in allen Versionen (außer SQL Server Express) von SQL Server 2008 unterstützt.

Datenkomprimierung

Durch die einfache Verwaltung einer Datenbank besitzen Datenbankadministratoren bessere Möglichkeiten, ihre regulären Aufgabenlisten zu erfüllen. Mit immer größeren Tabellen, Indizes und Dateien und sehr großen Datenbanken (VLDBs) wird die Verwaltung von Daten und unhandlichen Dateigrößen zu einem immer größeren Problem. Da außerdem immer mehr Daten abgefragt werden, kann der Bedarf an größeren Mengen Speicherplatz oder die Notwendigkeit physischer E/A eine große Bürde für Datenbankadministratoren und ihre Organisationen darstellen. Dies führt häufig dazu, dass Datenbankadministratoren und ihre Organisationen Server mit mehr Arbeitsspeicher und/oder E/A-Bandbreite sichern oder Leistungseinbußen in Kauf nehmen müssen.

Die in SQL Server 2008 eingeführte Datenkomprimierung bietet eine Lösung für diese Probleme. Mit diesem Feature kann ein Datenbankadministrator Tabellen, Tabellenpartitionen oder Indizes komprimieren. Dies hat einen geringeren Speicherplatzbedarf auf dem Datenträger, eine geringere Workingsetgröße des Arbeitsspeichers und reduzierte E/A zur Folge. Die Komprimierung und Dekomprimierung beeinträchtigen die CPU. Diese Auswirkungen werden jedoch in vielen Fällen durch die E/A-Einsparungen ausgeglichen. In Konfigurationen mit E/A-Engpässen können aufgrund der Komprimierung auch Leistungssteigerungen eintreten.

Bei einigen Labortests führte die Aktivierung der Datenkomprimierung zu Einsparungen von 50 - 80 % des Speicherplatzes. Diese Einsparungen variierten deutlich. Bei Daten ohne viele sich wiederholende Werte oder bei Daten, bei denen die Werte sämtliche anhand des angegebenen Datentyps zugewiesene Bytes erfordern, waren nur minimale Einsparungen erkennbar. Außerdem wurden Arbeitsauslastungen gemessen, die keine Leistungszunahmen aufwiesen. Bei Daten mit vielen numerischen Daten und sich wiederholenden Werten konnten jedoch erhebliche Speicherplatzeinsparungen und Leistungszunahmen von wenigen Prozentpunkten bis hin zu 40 - 60 % bei einigen Beispielabfragen festgestellt werden.

SQL Server 2008 unterstützt zwei Komprimierungsarten: Zeilenkomprimierung, bei der die einzelnen Spalten einer Tabelle komprimiert werden, und Seitenkomprimierung, bei der Datenseiten mithilfe der Zeilen-, Präfix- und Wörterbuchkomprimierung komprimiert werden. Der Umfang der erreichten Komprimierung hängt in hohem Maße von den Datentypen und den Daten in der Datenbank ab. Im Allgemeinen haben wir festgestellt, dass die Zeilenkomprimierung geringere Auswirkungen auf den Anwendungsdurchsatz hat, aber weniger Speicherplatz einspart. Die Seitenkomprimierung hat andererseits größere Auswirkungen auf den Anwendungsdurchsatz und die Prozessornutzung, führt jedoch zu größeren Platzeinsparungen. Bei der Seitenkomprimierung handelt es sich um eine Überordnung der Zeilenkomprimierung. Diese beinhaltet, dass die Zeilenkomprimierung auf Objekte oder Partitionen eines Objekts angewendet wird, die komprimiert werden sollen. Außerdem unterstützt SQL Server 2008 das vardecimal-Speicherformat von SQL Server 2005 SP2 nicht. Da es sich bei diesem Speicherformat jedoch um eine Unterordnung der Zeilenkomprimierung handelt, ist dieses Feature wertlos. Es wird daher aus künftigen Produktversionen entfernt.

Die Zeilen- und die Seitenkomprimierung können im Onlinemodus ohne Unterbrechung der Verfügbarkeit der Anwendung auf eine Tabelle oder einen Index angewendet werden. Eine Partition einer partitionierten Tabelle kann nicht online komprimiert oder dekomprimiert werden. Bei unseren Tests kam heraus, dass eine gemischte Vorgehensweise, bei der nur die größten Tabellen komprimiert werden, zur besten Leistung im Hinblick auf das Einsparen von Speicherplatz unter Inkaufnahme minimaler Leistungseinbußen führt. Aufgrund bestehender Anforderungen an den Speicherplatz, die dem zum Erstellen oder erneuten Erstellen eines Index erforderlichen Speicherplatz entsprechen, sollte bei der Implementierung der Komprimierung vorsichtig vorgegangen werden. Wir haben außerdem herausgefunden, dass der Bedarf an zusätzlichem Speicherplatz während des Komprimierungsvorgangs am geringsten ist, wenn von der Liste der zu komprimierenden Objekte die kleinsten Objekte zuerst komprimiert werden.

Die Datenkomprimierung kann über Transact-SQL oder den Datenkomprimierungs-Assistenten implementiert werden. Sie können die systemgespeicherte Prozedur sp_estimate_data_compression_savings verwenden, um die Auswirkungen der Komprimierung eines Objekts auf seine Größe zu bestimmen, oder den Datenkomprimierungs-Assistenten verwenden, um die geschätzten Speicherplatzeinsparungen zu berechnen. Die Datenbankkomprimierung wird nur in den SQL Server 2008-Editionen Enterprise und Developer unterstützt. Sie wird vollständig in die Datenbank implementiert und erfordert keine Änderungen an der Anwendung.

Weitere Informationen zur Verwendung der Komprimierung finden Sie unter Erstellen komprimierter Tabellen und Indizes.

Richtlinienbasierte Verwaltung

In zahlreichen Geschäftsszenarien müssen innerhalb eines bestimmten SQL Servers oder oft auch in einer Gruppe von SQL Servern bestimmte Konfigurationen verwaltet oder Richtlinien eingehalten werden. Ein Datenbankadministrator oder eine Organisation muss möglicherweise eine bestimmte Namenskonvention für alle zu erstellenden Benutzertabellen oder gespeicherten Prozeduren implementieren oder eine erforderliche Konfigurationsänderung auf zahlreichen Servern auf dieselbe Art definieren.

Die richtlinienbasierte Verwaltung bietet DBAs vielseitige Optionen zur Verwaltung ihrer Umgebung. Richtlinien können erstellt und auf ihre Einhaltung überprüft werden. Falls ein Ziel (wie z. B. ein SQL Server-Datenbankmodul, eine Datenbank, eine Tabelle oder ein Index) gegen eine Richtlinie verstößt, kann es vom Administrator automatisch neukonfiguriert werden, damit es die Richtlinie erfüllt. Außerdem sind mehrere Bewertungsmodi (viele davon automatisiert) vorhanden, mit denen der Datenbankadministrator die Einhaltung der Richtlinie prüfen und protokollieren kann. Außerdem kann er damit eine Benachrichtigung senden, wenn ein Richtlinienverstoß auftritt, und sogar einen Rollback für Änderungen durchführen, damit die Richtlinie weiter eingehalten wird. Weitere Informationen zu den Bewertungsmodi und deren Zuordnung zu Facets (ein Begriff der richtlinienbasierten Verwaltung, der auch im Blog erläutert wird) finden Sie im Blog zur richtlinienbasierten Verwaltung für SQL Server.

Die Richtlinien können exportiert und als XML-Dateien zur Bewertung und Implementierung auf mehreren Serverinstanzen importiert werden. Außerdem können in SQL Server Management Studio und in der Ansicht "Registrierte Server" Richtlinien serverübergreifend bewertet werden, falls sie unter einer lokalen Servergruppe oder einer zentralen Verwaltungsservergruppe registriert sind.

Nicht alle Funktionen der richtlinienbasierten Verwaltung können in früheren Versionen von SQL Server implementiert werden. Das Feature Berichterstellung kann jedoch in SQL Server 2005 und SQL Server 2000 verwendet werden. Weitere Informationen zur Verwaltung von Servern mithilfe der richtlinienbasierten Verwaltung finden Sie in der SQL Server-Onlinedokumentation unter Verwalten von Servern mit der richtlinienbasierten Verwaltung. Weitere Informationen über die Technologie selbst, einschließlich Beispielen, finden Sie im SQL Server 2008-Kompatibilitätshandbuch.

Vorhersagbare Leistung und Parallelität

Die versuchte Unterstützung von SQL Servern mit ständig wechselnden Arbeitsauslastungen und das Erzielen eines gewissen vorhersagbaren Leistungsniveaus (oder das Minimieren der Varianz in Plänen und der Leistung) stellen ein erhebliches Problem für viele Datenbankadministratoren dar. Unerwartete Abfrageleistungen, Planänderungen und/oder allgemeine Leistungsprobleme können aufgrund zahlreicher Faktoren auftreten, wie beispielsweise erhöhte Auslastung der Anwendungen, die unter SQL Server ausgeführt werden, oder Versionsupgrades der Datenbank. Eine vorhersagbare Leistung für Abfragen und Vorgänge, die unter SQL Server ausgeführt werden, kann die Möglichkeiten des Datenbankadministrators zum Einhalten und Verwalten der Verfügbarkeits-, Leistungs- und/oder Geschäftskontinuitätsziele (OLAs oder SLAs) enorm verbessern.

SQL Server 2008 stellt einige Änderungen an Features bereit, mit denen sich die Leistung besser vorhersagen lässt. In SQL Server 2008 wurden Verbesserungen an den SQL Server 2005-Planhinweisen (oder der Planfixierung) vorgenommen. Außerdem steht eine neue Option zur Kontrolle der Sperrenausweitung auf Tabellenebene zur Verfügung. Beide Verbesserungen können zu einer besser vorhersagbaren und strukturierten Interaktion zwischen der Anwendung und der Datenbank führen.

Erstens: Planhinweislisten

SQL Server 2005 ermöglichte eine höhere Stabilität und Vorhersagbarkeit der Abfrageleistung, indem es ein neues Feature mit der Bezeichnung Planhinweislisten bereitstellt, um Hinweise für Abfragen anzugeben, die nicht direkt in der Anwendung geändert werden konnten. Weitere Informationen finden Sie im Whitepaper Forcing Query Plans (möglicherweise in englischer Sprache). Obwohl es sich ume ein leistungsstarkes Feature handelt, unterstützte die USE PLAN-Abfrage nur SELECT DML-Vorgängeund war aufgrund der Empfindlichkeit der Planhinweislisten hinsichtlich der Formatierung oft umständlich zu verwenden.

SQL Server 2008 erweitert den Planhinweislisten-Mechanismus in zweierlei Hinsicht: Er unterstützt den USE PLAN-Abfragehinweis zur Abdeckung aller DML-Anweisungen (INSERT, UPDATE, DELETE, MERGE) und führt das neue Feature Planfixierung ein, das zum direkten Erstellen einer Planhinweisliste (Fixierung) für sämtliche Abfragepläne im SQL Server-Plancache wie im folgenden Beispiel verwendet werden kann.

sp_create_plan_guide_from_handle

@name = N'MyQueryPlan',

@plan_handle = @plan_handle,

@statement_start_offset = @offset;

Eine auf beliebige Art erstellte Planhinweisliste weist einen Datenbankbereich auf und wird in der Tabelle sys.plan_guides gespeichert. Planhinweislisten werden nur zur Beeinflussung des Auswahlprozesses für die Abfragepläne des Optimierers verwendet und ersetzen die Kompilierung der Abfrage in keiner Weise. Außerdem wurde die neue Funktion sys.fn_validate_plan_guide zur Prüfung vorhandener SQL Server 2005-Hinweislisten und zur Gewährleistung der Kompatibilität mit SQL Server 2008 eingeführt. Die Planfixierung ist in den SQL Server 2008-Editionen Standard, Enterprise und Developer verfügbar.

Zweitens: Sperrenausweitung

Die Sperrenausweitung hat oft zu Blockierungs- und manchmal gar zu Deadlockproblemen geführt, die der Datenbankadministrator lösen und beheben musste. Vorherige Versionen von SQL Server ermöglichten das Steuern der Sperrenausweitung (Ablaufverfolgungsflags 1211 und 1224). Dies war jedoch nur mit der Granularität der Instanzebene möglich. Während dies in einigen Anwendungen das Problem behoben hat, verursachte es in anderen schwere Fehler. Ein weiteres Problem mit dem SQL Server 2005-Sperrenausweitungsalgorithmus bestand darin, dass Sperren in partitionierten Tabellen direkt auf Tabellenebene statt auf Partitionierungsebene eskaliert wurden.

SQL Server 2008 bietet eine Lösung für beide Probleme. Eine neue Option zur Steuerung der Sperrenausweitung auf Tabellenebene wurde eingeführt. Mithilfe des Befehls ALTER TABLE kann für Optionssperren festgelegt werden, dass sie nicht eskalieren oder nur auf die Partitionsebene für partitionierte Tabellen eskalieren. Mit diesen beiden Verbesserungen werden die Skalierbarkeit und Leistung ohne negative Nebeneffekte auf andere Objekte in der Instanz optimiert. Die Sperrenausweitung wird auf Datenbankobjektebene festgelegt und erfordert keine Anwendungsänderungen. Sie wird in allen Editionen von SQL Server 2008 unterstützt.

Ressourcenkontrolle

Das Beibehalten einer konsistenten Dienstebene durch Verhindern von Runaway-Abfragen und Garantieren von Ressourcen für unternehmenswichtige Arbeitslasten ist eine Herausforderung. In der Vergangenheit gab es keine Möglichkeit, einem Satz von Abfragen eine bestimmte Anzahl an Ressourcen zuzuweisen und den Zugriff zu priorisieren. Alle Abfragen hatten denselben Zugriff auf alle verfügbaren Ressourcen.

SQL Server 2008 führt ein neues Feature mit der Bezeichnung Resourcenkontrolle ein, das bei der Behandlung dieses Problems hilft, indem es Benutzern die Unterscheidung von Arbeitsauslastungen und die Zuweisung von Ressourcen je nach Anforderung ermöglicht. Begrenzungen der Ressourcenkontrolle können in Echtzeit einfach mit minimalen Auswirkungen auf gerade ausgeführte Arbeitsauslastungen neu konfiguriert werden. Die Zuweisung der Arbeitsauslastung zu einem Ressourcenpool kann auf Verbindungsebene konfiguriert werden. Der Prozess ist für die Anwendung vollständig transparent.

Im folgenden Diagramm ist der Prozess der Ressourcenzuweisung abgebildet. In diesem Szenario werden drei Arbeitsauslastungspools (Admin-Arbeitsauslastung, OLTP-Arbeitsauslastung und Bericht-Arbeitsauslastung) konfiguriert. Dem OLTP-Arbeitsauslastungspool wird eine hohe Priorität zugewiesen. Parallel dazu werden für zwei Ressourcenpools (Admin-Pool und Anwendungspool) wie angezeigt spezifische Einschränkungen für den Arbeitsspeicher und den Prozessor (CPU) konfiguriert. Als letzter Schritt werden die Admin-Arbeitsauslastung dem Admin-Pool und die OLTP- und Bericht-Arbeitsauslastungen dem Anwendungspool zugewiesen.

Zusätzlichee Punkte, die es bei der Verwendung der Ressourcenkontrolle zu beachten gilt.

- Die Ressourcenkontrolle erfordert Anmeldeinformationen, einen Hostnamen oder Anwendungsnamen wie etwa eine Ressourcenpoolkennung. Die Verwendung eines einzelnen Logins für eine Anwendung erschwert je nach Anzahl der Clients pro Server das Erstellen von Pools.

- Die Objektgruppierung auf Datenbankebene, in der die Ressourcenkontrolle basierend auf den Datenbankobjekten erfolgt, auf die verwiesen wird, wird nicht unterstützt.

- Die Ressourcenkontrolle ermöglicht nur Ressourcenverwaltung innerhalb einer einzelnen SQL Server-Instanz. Zur Verwaltung mehrerer SQL Server-Instanzen oder -Prozesse innerhalb eines Servers von einer einzelnen Quelle aus sollte der Windows-Systemressourcenmanager verwendet werden.

- Nur Prozessor- und Arbeitsspeicherressourcen können konfiguriert werden. E/A-Ressourcen können nicht gesteuert werden.

- Dynamisch wechselnde Arbeitsauslastungen zwischen Ressourcenpools sind nach Verbindungsherstellung nicht möglich.

- Die Ressourcenkontrolle wird nur in den SQL Server 2008-Editionen Enterprise und Developer unterstützt und kann nur für das SQL Server-Datenbankmodul verwendet werden. SQL Server Analysis Services (SSAS), SQL Server Integration Services (SSIS) und SQL Server Reporting Services (SSRS) können nicht gesteuert werden.

Transparente Datenverschlüsselung (TDE; Transparent Data Encryption)

Sicherheit ist für viele Organisationen von höchster Bedeutung. Zum Sichern eines der wichtigsten Datenbestände einer Organisation, nämlich der Daten, stehen viele verschiedene Ebenen zur Verfügung. In den meisten Fällen sichern die Organisationen ihre aktiven Daten gut mithilfe physischer Sicherheit, Firewalls und genau kontrollierten Zugriffsrichtlinien. Wenn jedoch ein physisches Medium wie das Sicherungsband oder der Datenträger, auf dem sich die Daten befinden, kompromittiert wird, sind die obigen Sicherheitsmaßnahmen zwecklos, da ein Benutzer die Datenbank einfach wiederherstellen kann und dadurch vollständigen Zugriff auf die Daten erhält.

SQL Server 2008 bietet mit der transparenten Datenverschlüsselung (TDE) eine Lösung für dieses Problem. TDE führt die E/A-Verschlüsselung und -Entschlüsselung der Daten und der Protokolldateien unter Verwendung eines Verschlüsselungsschlüssels für die Datenbank (DEK; Database Encryption Key) in Echtzeit durch. Der DEK ist ein symmetrischer Schlüssel, der durch ein in der Masterdatenbank des Servers gespeichertes Zertifikat gesichert wird, oder ein asymmetrischer Schlüssel, der von einem erweiterbaren Schlüsselverwaltungs-Modul (EKM; Extensible Key Management) geschützt wird.

TDE soll "ruhende" Daten schützen. Das bedeutet, dass die in Dateien der Formate MDF, NDF und LDF gespeicherten Daten nicht mithilfe eines Hexeditors oder anderen Mitteln angezeigt werden können. Daten, die nicht ruhen, wie z. B. die Ergebnisse einer SELECT-Anweisung in SQL Server Management Studio, sind jedoch weiter für Benutzer sichtbar, die über die Rechte zum Anzeigen der Tabelle verfügen. Da TDE außerdem auf Datenbankebene implementiert wird, kann die Datenbank Indizes und Schlüssel zur Abfrageoptimierung nutzen. TDE sollte nicht mit einer Verschlüsselung auf Spaltenebene verwechselt werden. Dabei handelt es sich um eine separate Funktion, die auch eine Verschlüsselung von nicht ruhenden Daten ermöglicht.

Das Verschlüsseln einer Datenbank ist ein einmaliger Prozess, der über einen Transact-SQL-Befehl oder über SQL Server Management Studio initiiert werden kann und als Hintergrund-Thread ausgeführt wird. Der Verschlüsselungs- oder Entschlüsselungsstatus wird mit der dynamischen Verwaltungssicht sys.dm_database_encryption_keys überwacht. In einem von uns durchgeführten Labortest konnten wir eine 100-GB-Datenbank mithilfe des Verschlüsselungsalgorithmus AES_128 in etwa einer Stunde verschlüsseln. Während der Aufwand bei der Verwendung von TDE hauptsächlich durch die Arbeitsauslastung der Anwendung bestimmt wird, wurde der Aufwand in einigen durchgeführten Tests mit weniger als fünf Prozent gemessen. Folgende möglichen Auswirkungen auf die Leistung müssen ebenso beachtet werden: Falls auf eine Datenbank innerhalb der Instanz TDE angewendet wurde, ist auch die tempDB-Systemdatenbank verschlüsselt. Beim Kombinieren von Funktionen muss schließlich Folgendes beachtet werden:

· Wenn die Sicherungskomprimierung zum Komprimieren einer verschlüsselten Datenbank verwendet wird, ist die Sicherungskomprimierung größer, als wenn die Datenbank nicht verschlüsselt wäre, da sich verschlüsselte Daten nicht gut komprimieren lassen.

· Das Verschlüsseln der Datenbank hat keinerlei Auswirkungen auf die Datenkomprimierung (Zeile oder Seite).

TDE ermöglicht Organisationen das Einhalten von behördlichen Bestimmungen und der Bedenken im Zusammenhang mit Datenschutz. TDE wird nur in den SQL Server 2008-Editionen Enterprise und Developer unterstützt und kann ohne Ändern der vorhandenen Anwendungen aktiviert werden. Weitere Informationen finden Sie unter Database Encryption in SQL Server 2008 Enterprise Edition (möglicherweise in englischer Sprache) oder der Diskussion im SQL Server 2008-Kompatibilitätshandbuch unter Verwenden der transparenten Datenverschlüsselung.

Zusammenfassung: SQL Server 2008 bietet Features, Verbesserungen und Funktionen zur Optimierung der Datenbankadministratorerfahrung. Neben der Liste der zehn wichtigsten Funktionen oben sind in SQL Server 2008 viele weitere Features enthalten, mit denen die Erfahrung für Datenbankadministratoren und andere Benutzer verbessert wird. Top 10-Features für andere SQL Server-Bereiche finden Sie in den anderen SQL Server 2008-Top 10-Artikeln auf dieser Website. Eine vollständige Liste der Features und detaillierte Beschreibungen finden Sie in der SQL Server-Onlinedokumentation und auf der SQL Server 2008 Overview-Website.

Die zehn besten SQL Server Integration Services-Methoden

AlexeiK — Mon, 19 Apr 2010 13:51:00 GMT

Die zehn besten SQL Server Integration Services-Methoden

Autoren: Thomas Kejser, Denny Lee

Mitwirkende: Runying Mao

Technische Lektoren: Burzin Patel, Kevin Cox, Peter Carlin, Mark Souza, Richard Tkachuk, Len Wyatt, Lindsey Allen, Prem Mehra, Nicholas Dritsas, Carl Rabeler, Kun Cheng, Stuart Ozer, Donald Farmer

Veröffentlicht: 1.10.2008
Aktualisiert: 12.12.2008

Wie viele von Ihnen haben vom Mythos gehört, dass in Microsoft® SQL Server® Integration Services (SSIS) keine Skalierung möglich ist? Die erste Gegenfrage, die wir stellen würden, lautet: „Muss Ihr System über mehr als 4,5 Millionen Verkaufstransaktionszeilen pro Sekunde skalieren?“ Bei SQL Server Integration Services handelt es sich um eine ETL-Plattform (Extrahieren, Transformieren, Laden), die sogar bei extremsten Anforderungen skalieren kann. Und wie in SSIS ETL world record performance (möglicherweise in englischer Sprache) dokumentiert, kann SQL Server Integration Services in etwa 4,5 Millionen Verkaufstransaktionen pro Sekunde verarbeiten.

Zur Optimierung Ihrer Umgebung haben wir unsere besten zehn Tipps für SQL Server 2008 Integration Services bereitgestellt. Die meisten davon gelten auch für SQL Server 2005.


				SSIS ist eine Pipeline im Arbeitsspeicher. Stellen Sie also sicher, dass alle Transformationen im Arbeitsspeicher erfolgen. Der Grund für die Bereitstellung von Integration Services als SQL Server-Feature ist das Anbieten einer flexiblen, robusten Pipeline, die Berechnungen zeilenweise und effizient durchführt und alle Daten im Arbeitsspeicher analysiert. Während die Phasen der Extraktion und des Ladens der Pipeline sich auf den Datenträger auswirken werden (lesen und schreiben), erfolgt die Transformation selbst im Arbeitsspeicher. Wenn die Transformationen zu viel Speicherplatz auf dem Datenträger einnehmen (zum Beispiel mit umfangreichen Sortiervorgängen), ist ein enormer Leistungsabfall erkennbar. Erstellen Sie Ihre Pakete zum Partitionieren und Filtern von Daten so, dass alle Transformationen im Arbeitsspeicher durchgeführt werden können. Eine gute Möglichkeit zur Kontrolle, ob alle Pakete im Arbeitsspeicher bleiben, ist die Prüfung des SSIS-Leistungsindikators Gespoolte Puffer, der einen Ausgangswert von 0 aufweist. Ein Wert größer 0 deutet darauf hin, dass das Modul die Auslagerung auf den Datenträger begonnen hat. Weitere Informationen finden Sie unter Something about SSIS Performance Counters (möglicherweise in englischer Sprache).
				Bedenken Sie bei der Kapazitätsplanung die Ressourcennutzung. SQL Server Integration Services soll große Datenmengen zeilenweise mit großer Geschwindigkeit im Arbeitsspeicher verarbeiten. Daher sollte die Ressourcennutzung bekannt sein, d. h. CPU, Arbeitsspeicher, E/A und Netzwerknutzung Ihrer Pakete. · CPU-gebunden: Versuchen Sie die Prozessorleistung für Integration Services und die gesamte Prozessorleistung von SQL Server während der Ausführung von Integration Services herauszufinden. Der letzte Punkt ist besonders wichtig, wenn sich SQL Server und SSIS auf dem selben Server befinden, da bei Ressourcenkonflikten zwischen diesen beiden der SQL Server in der Regel als Sieger hervorgeht. Dies führt zu einem Überlauf des Datenträgers von Integration Services, was die Transformationsgeschwindigkeit verlangsamt. Der wichtigste Leistungsindikator für Sie ist Prozess / Gesamtprozessorzeit (%). Messen Sie diesen Leistungsindikator für sqlservr.exe und dtexec.exe. Falls SSIS nicht bei annähernd 100% Prozessorauslastung ausgeführt werden kann, ist dies möglicherweise ein Anzeichen für: o Anwendungskonflikt: SQL Server verwendet z. B. mehr Prozessorressourcen, die dadurch nicht für SSIS verfügbar sind. o Hardwarekonflikt: Ein häufiges Szenario ist, dass Benutzer nicht über optimalen Datenträger-E/A oder nicht ausreichend Arbeitsspeicher zum Verarbeiten der Datenmenge verfügen. o Entwurfseinschränkungen: Im Entwurf des SSIS-Pakets wird die Parallelität nicht genutzt. Außerdem werden im Paket zu viele Singlethreadaufgaben verwendet. Netzwerk-gebunden: SSIS verschiebt Daten so schnell, wie diese vom Netzwerk verarbeitet werden können. Daher muss die Netzwerktopologie bekannt sein und gewährleistet werden, dass der Pfad zwischen Quelle und Ziel geringe Latenzzeiten und hohen Durchsatz bietet. Mit den folgenden Leistungsindikatoren für Netzwerke können Sie Ihre Topologie abstimmen: o Netzwerkschnittstelle / Aktuelle Bandbreite: Dieser Indikator zeigt eine Schätzung der aktuellen Bandbreite. o Netzwerkschnittstelle / Bytes gesamt / Sek.: Die Rate, mit der Bytes über Netzwerkkarten gesendet und empfangen werden. o Netzwerkschnittstelle / Übertragungen / Sek.: Zeigt an, wie viele Netzwerkübertragungen pro Sekunde auftreten. Falls sich dieser Wert 40.000 IOPS nähert, sollten Sie eine weitere NIC-Karte besorgen und den Teamvorgang zwischen den NIC-Karten verwenden. Diese Zähler erlauben das Analysieren der Nähe zur maximalen Bandbreite des Systems. Das Verstehen dieser Information ermöglicht das entsprechende Planen der Kapazität, entweder durch Verwendung von Gigabit-Netzwerkkarten,durch Erhöhen der Anzahl der NIC-Karten pro Server oder durch das Erstellen separater Netzwerkadressen spezifisch für ETL-Datenverkehr. E/A-gebunden: Falls Sie sicherstellen, dass Integration Services nur in geringem Maße Schreibvorgänge auf dem Datenträger durchführt, wird SSIS den Datenträger nur zum Lesen aus der Quelle und zum Schreiben in das Ziel aufrufen. Bei langsamem E/A kann jedoch beim Lesen und insbesondere beim Schreiben ein Engpass entstehen. Da die Abstimmung von E/A außerhalb des Umfangs dieser technischen Hinweise liegt, finden Sie weitere Informationen unter Predeployment I/O Best Practices (möglicherweise in englischer Sprache). Beachten Sie, dass E/A-Systeme nicht nur nach Größe („Ich benötige 10 TB“), sondern auch nach der dauerhaften Geschwindigkeit („Ich möchte 20.000 IOPS“) unterschieden werden. Arbeitsspeicher-gebunden: Eine wichtige Frage, die bei der Verwendung von Integration Services beantwortet werden muss: „Wie viel Arbeitsspeicher benötigt mein Paket?“ Die wichtigsten Leistungsindikatoren für Integration Services und SQL Server: o Prozess / Private Bytes (DTEXEC.exe) – Die Menge des derzeit durch Integration Services verwendeten Arbeitsspeichers. Dieser Arbeitsspeicher kann nicht gemeinsam mit anderen Vorgängen genutzt werden. o Prozess / Arbeitsseiten (DTEXEC.exe) – Die Gesamtmenge des von Integration Services zugewiesenen Arbeitsspeichers. o SQL Server: Speicher-Manager / Serverspeicher gesamt: Der gesamte von SQL Server zugewiesene Arbeitsspeicher. Da SQL Server Arbeitsspeicher mithilfe der AWE-API zuweist, ist dieser Leistungsindikator das beste Maß für den insgesamt von SQL Server verwendeten Arbeitsspeicher. Informationen zum besseren Verständnis der Arbeitsspeicherzuordnung in Server finden Sie in Slava Ok’s Weblog (möglicherweise in englischer Sprache). o Arbeitsspeicher / Seitenlesevorgänge / Sek. – Stellt den Speicherplatzmangel auf dem System dar. Steigt dieser Wert auf mehr als 500 an, besteht auf dem System Speicherplatzmangel.
				Basiszeilenquellsystem-Extraktionsgeschwindigkeit. Das Quellsystem und die Extraktionsgeschwindigkeit von diesem müssen bekannt sein. Letzten Endes kann Integration Services nur höchstens bis zur Geschwindigkeit der Quelle optimiert werden – d. h. Sie können Daten nicht schneller transformieren als lesen. Messen Sie die Geschwindigkeit des Quellsystems, indem Sie ein sehr einfaches Paket erstellen, das Daten von der Quelle mit dem Ziel „Zeilenanzahl“ liest: Führen Sie das Paket über die Befehlszeile (DTEXEC) aus, und messen Sie die Zeit für das Fertigstellen der Aufgabe. Verwenden Sie die Ausgabe des Integration Services-Protokolls, um die Zeit präzise berechnen zu können. Sie berechnen die Zeilen pro Sekunde: Zeilen / Sek. = Zeilenanzahl / Zeit_Datenfluss Dieser Wert steht für die maximale Anzahl Zeilen pro Sekunde, die Sie von der Quelle lesen können – dieser Wert ist außerdem das Maximum für die Transformationsgeschwindigkeit der Daten. Gehen Sie folgendermaßen vor, um diesen Zeilen / Sek.-Wert zu steigern: Treiber und Treiberkonfigurationen verbessern: Stellen Sie sicher, dass Sie die aktuellen Treiberkonfigurationen für Netzwerk, Datenquelle und Datenträger-E/A verwenden. Die standardmäßigen Netzwerktreiber auf dem Server sind oft nicht optimal für den Netzwerkstapel konfiguriert, was zu Leistungseinbußen bei einer großen Anzahl von Durchsatzanfragen führt. Beachten Sie, dass bei 64-Bit-Systemen beim Entwurf möglicherweise 32-Bit-Treiber geladen werden. Stellen Sie sicher, dass Sie bei der Ausführung 64-Bit-Treiber verwenden. Mehrere Verbindungen starten: Um Einschränkungen von Treibern zu überwinden, können Sie versuchen, mehrere Verbindungen zu Ihrer Datenquelle herzustellen. Wenn die Quelle mehrere gleichzeitige Verbindungen verarbeiten kann, stellen Sie möglicherweise eine Durchsatzsteigerung fest, wenn Sie mehrere Extraktionen gleichzeitig starten. Falls durch die Parallelität Probleme wegen Sperren oder Blockierungen auftreten, erwägen Sie eine Partitionierung der Quelle und lassen Sie die Pakete von verschiedenen Partitionierungen lesen, um die Last gleichmäßiger aufzuteilen. Mehrere NIC-Karten verwenden: Falls das Netzwerk Ihr Bottleneck ist und Sie bereits sichergestellt haben, dass Sie Gigabit-Netzwerkkarten und -Router verwenden, ist eine mögliche Lösung die Verwendung mehrerer NIC-Karten pro Server. Lassen Sie beim Konfigurieren mehrerer NIC-Umgebungen Vorsicht walten, weil andernfalls Netzwerkkonflikte auftreten können.
				Optimieren Sie die SQL-Datenquelle, die Transformationen zum Suchen und das Ziel. Wenn Sie SQL-Anweisungen in Integration Services (wie oben im Dialogfeld Datenzugriffsmodus angemerkt) ausführen, ob zum Lesen einer Quelle, zum Durchführen einer Suchtransformation oder zum Ändern von Tabellen, können Sie mit gewissen Standardoptimierungen die Leistung erheblich steigern: Verwenden Sie die Hinweise NOLOCK oder TABLOCK zum Entfernen des Sperrenaufwands. Wählen Sie zur Optimierung der Arbeitsspeichernutzung nur die tatsächlich benötigten Spalten aus (SELECT). Falls Sie alle Spalten einer Tabelle (d. h. SELECT * FROM) auswählen, verwenden Sie ohne Not Arbeitsspeicher und Bandbreite zum Speichern und Abrufen von nicht verwendeten Spalten. Führen Sie die datetime-Konvertierungen möglichst in den Quell- oder Zieldatenbanken durch, da dies in Integration Services teuer ist. In SQL Server 2008 Integration Services ist das neue Feature des freigegebenen Cache zum Suchen enthalten. Bei der Verwendung paralleler Pipelines (siehe die Punkte Nr. 8 und Nr. 10 unten) wird ein freigegebener Hochgeschwindigkeitscache bereitgestellt. Falls Integration Services und SQL Server auf demselben Server ausgeführt werden, verwenden Sie das SQL Server-Ziel anstelle des OLE DB-Ziels zur Verbesserung der Leistung. Commitgröße 0 ist für Heap-Massenziele am schnellsten, da nur für eine Transaktion ein Commit ausgeführt wird. Falls 0 nicht verwendet werden kann, verwenden Sie den höchstmöglichen Wert der Commitgröße, um den Aufwand für das Schreiben in mehreren Batches zu verringern. Verwenden Sie eine Commitgröße <5000, um beim Einfügen eine Sperrenausweitung zu vermeiden. Beachten Sie, dass Sie in SQL Server 2008 die Sperrenausweitung jetzt auf Objektebene aktivieren/deaktivieren können, aber gehen Sie umsichtig mit dieser Option um. Heap-Einfügungen sind in der Regel schneller als die Verwendung eines gruppierten Indexes. Das bedeutet, dass Sie Indizes löschen und neu erstellen können, falls Sie einen großen Teil der Zieltabelle ändern. Sie können die Einfügungen testen, indem Sie die Indizes beibehalten oder alle Indizes löschen und zur Prüfung neu erstellen. Verwenden Sie Partitionen und den SWITCH-Befehl dafür. Laden Sie eine Arbeitstabelle, die eine einzelne Partition enthält, und verschieben Sie sie mit dem SWITCH-Befehl in die Haupttabelle, nachdem Sie die Indizes erstellt und Einschränkungen festgelegt haben. Weitere Informationen vom SQL-Team finden Sie unter Getting Optimal Performance with Integration Services Lookups (möglicherweise in englischer Sprache).
				Optimieren Sie Ihr Netzwerk. Eine wichtige Netzwerkeigenschaft ist die Paketgröße der Verbindung. Standardmäßig ist dieser Wert auf 4096 Byte festgelegt. Ein neues Netzwerkpaket muss daher also für jeweils 4 KB Daten erstellt werden. Wie unter SqlConnection.PacketSize-Eigenschaft in der .NET Framework-Klassenbibliothek angemerkt, wird die Leistung durch Steigern der Paketgröße verbessert, da weniger Lese- und Schreibvorgänge im Netzwerk zum Übertragen eines großen Datensatzes erforderlich sind. Falls es sich bei Ihrem System von Natur aus um ein Transaktionssystem mit vielen Lese-/Schreibvorgängen kleiner Datengrößen handelt, wird durch Verringern des Werts die Leistung gesteigert. Da Integration Services zum Verschieben großer Datenmengen gedacht ist, können Sie den Netzwerkaufwand minimieren. Dies bedeutet, dass der Wert 32K (32767) die schnellste Option darstellt. Die Netzwerkpaketgröße kann zwar mithilfe von sp_configure auf Serverebene konfiguriert werden. Dies ist jedoch nicht empfehlenswert. Der Datenbankadministrator hat möglicherweise Gründe, eine andere Servereinstellung als 32K zu verwenden. Überschreiben Sie stattdessen die Servereinstellungen im Verbindungs-Manager wie unten abgebildet. Eine weitere Möglichkeit zum Abstimmen des Netzwerks ist die Verwendung der Netzwerkaffinität auf Betriebssystemebene. Bei hohen Durchsätzen können Sie die Leistung gelegentlich auch auf diese Weise verbessern. Für das Netzwerk selbst können Sie mit Netzwerkexperten zusammenarbeiten, um Großrahmen zu aktivieren und dadurch die Standardnutzlast von 1500 Byte auf 9000 Byte zu erhöhen. Durch das Aktivieren von Großrahmen wird die Anzahl der Netzwerkvorgänge weiter verringert, die zum Verschieben großer Datensätze erforderlich sind.
				Datentypen verwenden – ja, zurück zu Datentypen! – umsichtig. Von allen Punkten auf dieser Top 10-Liste ist dieser vielleicht der offensichtlichste. Dieser Punkt ist dermaßen wichtig, dass er separat hervorgehoben werden muss. Befolgen Sie die folgenden Richtlinien: Erstellen Sie möglichst begrenzte Datentypen, damit weniger Arbeitsspeicher für die Transformation zugeordnet wird. Führen Sie keine übermäßigen Umwandlungen der Datentypen durch – dadurch wird lediglich die Leistung gemindert. Stimmen Sie Ihre Datentypen auf die Quelle oder das Ziel ab, und geben Sie die erforderliche Datentypenumwandlung ausdrücklich an. Überwachen Sie Genauigkeitsprobleme bei der Verwendung der Typen money, float und decimal. Beachten Sie außerdem, dass money schneller als decimal ist und bei money weniger Probleme mit der Präzision auftreten als bei float.
				Ändern Sie den Entwurf. Für einige Aktionen ist Integration Services gut geeignet – bei anderen Aufgaben sind jedoch andere Tools effizienter. Die Auswahl Ihres Tools sollte auf Grundlage der Effizienz und des wahren Verständnisses des Problems erfolgen. Beachten Sie bei dieser Entscheidung folgende Punkte: Führen Sie in Integration Services nur Sortiervorgänge aus, wenn dies absolut erforderlich ist. Zum Durchführen einer Sortierung allokiert Integration Services den Arbeitsspeicher der gesamten Datenmenge, die transformiert werden muss. Sortieren Sie die Daten möglichst, bevor sie in die Pipeline verschoben werden. Falls Sie Daten sortieren müssen, sortieren Sie möglichst nur kleine Datensätze in der Pipeline. Verwenden Sie zum Sortieren großer Datensätze in der Datenbank statt Integration Services die SQL-Anweisung ORDER BY – markieren Sie die Ausgabe als sortiert, indem Sie die Integration Services-Pipelinemetadaten in der Datenquelle ändern. In einigen Fällen ist die Verwendung von Transact-SQL schneller als die Verarbeitung der Daten in SSIS. Als allgemeine Regel gilt, dass alle mengenbasierten Vorgänge in Transact-SQL schneller ausgeführt werden, da das Problem in eine relationale Algebraformulierung (Domäne und Tupel) umgewandelt werden kann, für deren Lösung SQL Server optimiert wurde. Außerdem wendet der SQL Server-Optimierer automatisch hohe Parallelität- und Arbeitsspeicherverwaltung auf den mengenbasierten Vorgang an – ein Vorgang, den Sie möglicherweise selbst ausführen müssen, wenn Sie Integration Services verwenden. Typische mengenbasierte Vorgänge sind: Mengenbasierte UPDATE-Anweisungen – die weitaus effizienter als zeilenweise durchgeführte OLE DB-Aufrufe sind. Aggregationsberechnungen wie GROUP BY und SUM. Diese Berechnungen erfolgen in der Regel mit Transact-SQL schneller als im Arbeitsspeicher anhand einer Pipeline. Delta-Erkennung ist die Technologie, mit der Sie vorhandene Zeilen in der Zieltabelle ändern, anstatt die Tabelle neu zu laden. Zur Durchführung der Delta-Erkennung können Sie einen Änderungserkennungsmechanismus wie die neue Change Data Capture (CDC)-Funktion in SQL Server 2008 verwenden. Falls keine derartige Funktion verfügbar ist, führen Sie die Delta-Erkennung durch, indem Sie die Quelleingabe mit der Zieltabelle vergleichen. Dies kann ein äußerst kostspieliger Vorgang werden, der die Wartung spezieller Indizes und Prüfsummen nur zu diesem Zweck erfordert. Oft ist es am schnellsten, einfach die Zieltabelle neu zu laden. Eine Faustregel besagt, dass es bei mehr als zehn Prozent Veränderung der Zieltabelle oft schneller ist, einfach die Zieltabelle neu zu laden, als die Logik der Delta-Erkennung auszuführen.
				Partitionieren Sie das Problem. Einer der Hauptaspekte der skalierbaren Berechnung ist das Partitionieren von Problemen in kleinere, besser verwaltbare Fragmente. Dies ermöglicht die einfachere Abwicklung der Größe des Problems und die Nutzung parallel ausgeführter Prozesse, um das Problem schneller zu lösen. Für ETL-Entwürfe können Sie die Quelldaten in kleinere Fragmente gleicher Größe partitionieren. Der letzte Punkt ist von Bedeutung, da Sie bei Fragmenten unterschiedlicher Größe immer warten müssen, bis der letzte Prozess beendet ist, um die Aufgabe abzuschließen. Beispiel: Wenn Sie sich das folgende Diagramm ansehen, werden Sie bemerken, dass die vier für Partitionen gleicher Größe durchgeführten Prozesse im Januar 2008 gleichzeitig beendet werden und dann im Februar 2008 gemeinsam fortgesetzt werden. Bei Partitionen unterschiedlicher Größe sind die ersten drei Prozesse abgeschlossen, müssen aber warten, bis der vierte Prozess beendet ist, was viel mehr Zeit in Anspruch nimmt. Die gesamte Ausführungszeit wird also vom größten Fragment bestimmt. Verwenden Sie zum Erstellen von Bereichen gleich großer Partitionen Zeitspannen und/oder Dimensionen (wie z. B. Geographie) als Partitionierungsmechanismus. Falls Ihr wichtigstes Ziel ein inkrementeller Wert wie etwa IDENTITY oder ein anderer ansteigender Wert ist, können Sie eine Modulo-Funktion verwenden. Falls Sie über keine guten Partitionierungsspalten verfügen, erstellen Sie einen Hashwert des Werts der Zeilen, und führen Sie die Partitionierung auf Grundlage des Hashwerts durch. Weitere Informationen zum Hashing und Partitionieren finden Sie im Whitepaper Analysis Services Distinct Count Optimization (möglicherweise in englischer Sprache). Dieses Dokument handelt zwar von Distinct Count in Analysis Services, das Vorgehen bei der Hashpartitionierung wird jedoch ebenfalls detailliert behandelt. Andere Tipps bei der Partitionierung: Verwenden Sie die Partitionierung in der Zieltabelle. Auf diese Art können Sie mehrere Versionen desselben Pakets parallel ausführen, die Daten in verschiedene Partitionen derselben Tabelle einfügen. Verwenden Sie bei der Partitionierung die SWITCH-Anweisung. Dadurch werden nicht nur parallele Ladegeschwindigkeiten gesteigert, sondern auch effiziente Datenübertragungen ermöglicht. Weitere Informationen finden Sie im Artikel Effizientes Übertragen von Daten durch Partitionswechsel in der SQL Server-Onlinedokumentation. Wie oben angedeutet, sollten Sie Ihr Paket so entwerfen, dass es einen Parameter enthält, der angibt, an welcher Partition es arbeiten soll. Auf diese Art können Sie dasselbe Paket mehrfach mit unterschiedlichen Parameter- und Partitionswerten ausführen. Dank der Parallelität wird die Aufgabe so schneller fertig gestellt. In der Befehlszeile können Sie mithilfe des Befehls „START“ mehrere Ausführungen starten. Ein schnelles Codebeispiel der Ausführung mehrerer paralleler Robocopy-Anweisungen finden Sie im technischen Hinweis Sample Robocopy Script to custom synchronize Analysis Services databases (möglicherweise in englischer Sprache). Bei den meisten modernen Servern handelt es sich um SMP-Systeme mit mehreren Kernen. Ein Entwurf mit hoher Parallelität muss verwendet werden, um eine hohe CPU-Auslastung auf einem derartigen Server zu erzielen. Dies wird durch Partitionieren des Problems und Ausführen mehrerer Prozesse erreicht. Weitere Informationen zu einer Implementierung finden Sie unter SSIS ETL world record performance (möglicherweise in englischer Sprache).
				Minimieren Sie protokollierte Vorgänge. Verwenden Sie zum Einfügen von Daten in die SQL Server-Zieldatenbank möglichst minimal protokollierte Vorgänge. Werden Daten im vollständig protokollierten Modus in die Datenbank eingefügt, wächst das Protokoll schnell an, da jede in die Tabelle eingefügte Zeile in das Protokoll aufgenommen wird. Beachten Sie beim Entwerfen von Integration Services-Paketen Folgendes: Führen Sie Ihre Datenflüsse möglichst im Massenmodus statt zeilenweise aus. Durch die Ausführung im Massenmodus wird die Anzahl der Einträge minimiert, die in der Protokolldatei hinzugefügt werden. Durch diese Verringerung wird der zugrunde liegende Datenträger-E/A für andere Einfügungen verbessert und das durch die Schreibvorgänge in das Protokoll entstandene Bottleneck minimiert. Falls Sie Löschvorgänge ausführen müssen, organisieren Sie Ihre Daten so, dass Sie für die Tabelle einen TRUNCATE-Vorgang anstelle eines DELETE-Vorgangs ausführen können. Bei letzterem Vorgang wird für jede gelöschte Zeile ein Eintrag im Protokoll erstellt. Beim ersten Vorgang werden einfach alle Daten in der Tabelle mit einem kleinen Protokolleintrag entfernt, der angibt, dass der TRUNCATE-Vorgang durchgeführt wurde. Im Gegensatz zum weit verbreiteten Glauben kann eine TRUNCATE-Anweisung Teil einer Transaktion sein. Verwenden Sie die SWITCH-Anweisung und Partitionierung. Falls Partitionen verschoben werden müssen, können Sie die SWITCH-Anweisung (zum Wechseln in eine neue Partition oder zum Austauschen der ältesten Partition) verwenden, bei der es sich um eine minimal protokollierte Anweisung handelt. Lassen Sie bei der Verwendung von DML-Anweisungen Vorsicht walten. Wenn Sie DML-Anweisungen in INSERT-Anweisungen einfügen, wird die minimale Protokollierung unterdrückt.
				Planen und verteilen Sie ordnungsgemäß. Nach der Fragmentierung des Problems in verwaltbare Größen müssen Sie überlegen, wo und wann diese Fragmente ausgeführt werden sollen. Das Ziel ist es zu vermeiden, dass eine lange ausgeführte Aufgabe die Gesamtzeit des ETL-Flusses bestimmt. Eine gute Möglichkeit zur Behandlung von Ausnahmen ist das Erstellen einer Prioritätswarteschlange für Ihr Paket und die anschließende Ausführung mehrerer Instanzen desselben Pakets (mit verschiedenen Partitionierungsparameterwerten). Bei der Warteschlange kann es sich einfach um eine SQL Server-Tabelle handeln. Jedes Paket sollte in der Ablaufsteuerung eine einfache Schleife enthalten: 1. Wählen Sie in der Warteschlange ein relevantes Fragment aus: · „Relevant“ bedeutet, dass es noch nicht verarbeitet wurde und dass alle Fragmente, von denen es abhängt, bereits ausgeführt wurden. Falls von der Warteschlange kein Element zurückgegeben wird, schließen Sie das Paket. 2. Führen Sie die erforderlichen Arbeiten am Fragment durch. 3. Markieren Sie das Fragment in der Warteschlange als „Fertig“. 4. Kehren Sie zum Anfang der Schleife zurück. Die Auswahl eines Elements in der Warteschlange und dessen Markierung als „Fertig“ (Schritte 1 und 3 oben) können beispielsweise als gespeicherte Prozedur implementiert werden. Die Warteschlange fungiert als zentraler Steuerungs- und Koordinationsmechanismus, der die Reihenfolge der Ausführung bestimmt und sicherstellt, dass nicht zwei Pakete am selben Datenfragment arbeiten. Sobald die Warteschlange vorhanden ist, können Sie einfach mehrere Kopien von DTEXEC starten, um den Parallelitätseffekt zu steigern.

Deutsch

Ausführen von SQL Server 2008 in einer Hyper­V­Umgebung Best Practices und Überlegungen zur Leistung

Die zehn wichtigsten bewährten Methoden zur Erstellung eines großen skalierbaren relationalen Data Warehouse

Die zehn wichtigsten SQL Server 2008-Funktionen für Datenbankadministratoren (DBA)

Die zehn besten SQL Server Integration Services-Methoden

Ausführen von SQL Server 2008 in einer HyperVUmgebung Best Practices und Überlegungen zur Leistung