Frank Kalis

Von Zeit zu Zeit kann die Neuerstellung eines Clustered Index signifikante Performancesteigerung bewirken. Doch was passiert eigentlich während solch einer Operation?...

Ganze Geschichte »

Ja. Einen Shrink Vorgang kann man jederzeit risikolos abbrechen.

Stark vereinfacht gesagt befindet sich ein Login auf Server-Ebene und erlaubt die Verbindung zu SQL Server, während sich ein User auf Datenbank-Ebene befindet und den Zugriff auf die Datenbank erlaubt.

Um es gleich vorwegzunehmen: Dies ist eines der Bücher, denen man die Professionalität und Routine seines Autors auf angenehme Weise anmerkt. Kein überflüssiges Drumherum Gerede, sondern kurz und präzise werden die angesprochenen Themen abgehandelt. Man erhält stets die Informationen, die notwendig sind, um eine Aufgabe durchzuführen. Kurz, man nimmt dem Autor ab, daß er weiß wovon er spricht.

Ganze Geschichte »

Mit dem Erscheinen einer neuen Version einer Software kommen naturgemäß auch viele neue und/oder aktualisierte Bücher zu dieser Software auf den Markt. Der potentielle Käufer hat dann die Qual der Wahl sich zwischen den verschiedenen Büchern für Entwickler, Administratoren oder Anwendern entscheiden zu müssen. Dies wird zusätzlich noch erschwert durch den Umstand, daß die diversen Autoren eine unterschiedliche Auffassung davon haben, was denn so für einen Entwickler oder Administrator von Interesse sei.

Ganze Geschichte »

Das vorliegende Buch versteht sich selbst als Buch, das "Lösungsszenarien und Praxisbeispiele für alle wichtigen Aspekte des SQL Server 2005" präsentiert. Diese werden anhand eines fiktiven Unternehmens dargestellt, daß von Excel auf SQL Server 2005 migriert und nun im Begriff ist, die Möglichkeiten des SQL Servers 2005 auszuloten.

Ganze Geschichte »

Zweiter Beitrag in der "Best Practice" Serie. Gleichzeitig ein Thema, wo große Unsicherheit herrscht. Aber gerade DBA's sollten das Konzept des Transaktionsprotokolls unbedingt verstehen.

Dieser Beitrag geht auf ein Posting von Jonathan van Houtte zurück, das er freundlicherweise für diesen Zweck hier noch einmal überarbeitet hat. Jonathan hat gebeten, darauf aufmerksam zu machen, daß das Thema nicht komplett ist. Trotzdem ist es jetzt schon sehr ausführlich.

Empfehlungen für Log Files für OLTP Datenbanken:

1: OLTP Produktionsdatenbanken sollten so gut wie nie die Datenbankoption "trunc. log on chkpt." verwenden. 
Die einzigen Vorteile dieser Einstellung sind:

• daß man sich keine Gedanken über die Wartung (Backup) des Transaktionsprotokolls zu machen braucht
• daß die "Gefahr", kein Speicherplatz mehr zur Verfügung zu haben, weniger wahrscheinlich wird

Nachteile dieser Einstellung sind

• Schlechtere Performance aufgrund des laufenden Truncate Prozesses
• keine Point in time Wiederherstellungsmöglichkeit
• keine Möglichkeit, den Zustand bis zum Zeitpunkt des Fehlers wiederherzustellen

Trifft man die Entscheidung, daß eine Wiederherstellung des letzten vollständigen oder differentiellen Backup's ausreichend ist, dann gibt man Erfahrung zugunsten von Bequemlichkeit auf.

2: Wird das Transaktionsprotokoll nicht gesondert gesichert, kann es auch nicht verkleinert werden. Ein vollständiges oder differentielles Backup verkleinert nicht das Transaktionsprotokoll.

3: Transaktionsprotokoll Backup's sind losgelöst von anderen Backup's und können unabhängig davon wiederhergestellt werden. Angenommen, Sie führen ein vollständiges Backup jede Nacht durch und sichern das Transaktionsprotokoll zweimal im Laufe des Tages. Finden Sie jetzt heraus, daß das letzte nächtliche Backup korrupt ist, können Sie das aus der Nacht zuvor wiederherstellen (WITH NORECOVERY!) und anschliessend die Log Backup's wiederherstellen, um einen möglichst aktuellen Stand zu erreichen.

4: Das erste, was Sie in einem Disaster Fall machen sollten, ist, versuchen das Transaktionsprotokoll zu sichern. DBA's, die ich unterrichte, werden darauf gedrillt.

5: Verwenden Sie SQL Server 7 und setzen die Einstellung "select into/bulkcopy" auf Wahr, um beispielsweise Daten aus einer Textdatei schnell zu laden, sollten Sie direkt danach die Einstellung wieder auf Falsch setzen, das Transaktionsprotokoll und dann die Datenbank sichern. SQL Server 2000 and höher können die Änderungen mit ihrem Bulk-Logged Recovery Model wiederherstellen. Allerdings nicht auf der einzelnen Vorgangsebene. Die Verwendung dieses Modells und Durchführung einer Bulk-Logged Operation verhindert Point in time Wiederherstellung (mit der dafür notwendigen Transaktionsprotokollsicherung) und limitiert Ihre Möglichkeiten, auf eine Korrumpierung Ihrer Datenbankdateien zu reagieren. Speichern Sie in der Datenbank unternehmenskritische dynamische Daten, sollten Sie sich genau überlegen, ob Sie die Fehlertoleranz des Full Recovery Models aufgeben zugunsten der Performance des Bulk-Logged Modells. Bedenken Sie dabei auch, daß auch SELECT INTO, CREATE INDEX, WRITETEXT und UPDATETEXT minimal protokollierte Operationen sind, genauso wie die offensichtlicheren BULK COPY und bcp.

6: Führen Sie die Transaktionsprotokollsicherung vor einem vollständigen oder differentiellen Backup durch statt danach. Sichern Sie das Transaktionsprotokoll nach der Datenbank, müssen Sie dieses Log Backup zusätzlich wiederherstellen, wenn Sie das Datenbankbackup wiederherstellen.

7: Verkleinern Sie nicht das Transaktionsprotokoll nur um des Verkleinerns willen. Die Protokolldateien sollten so dimensioniert sein, daß sie die maximale Menge an protokollierten Informationen zwischen zwei Backup Vorgängen aufnehmen können. Bestehen Sie auf der Verkleinerung, werden die Dateien vergrößert, wenn dies notwendig ist. Dies wiederum geht auf die Performance des Gesamtsystems, da Prozessorleistung für den Autogrow Vorgang benötigt wird und führt ferner zu Dateifragmentierung. (Gleiches gilt übrigens auch für Datendateien. Erwarten Sie, daß die Datenbank auf eine Größe von 20 GB anwachsen wird, sollten Sie auch diesen Speicherplatz direkt bei Erstellung der Datenbank allokieren).

8: Vergewissern Sie sich, daß Sie in einem Disasterfall in der Lage sind, eine Datenbank auf den aktuellsten Stand wiederherzustellen. Erstellen Sie eine Testdatenbank und warten diese exakt so, wie Ihre Produktionsdatenbanken. Führen Sie dann eine Notfallübung durch, indem Sie simulieren, daß die Hardware mit den Datendateien mit einem Fehler ausfällt. (Was ist das Erste, was Sie in einem solchen Fall machen? Punkt 4!). Überprüfen Sie Ihre Bandsicherungen und Wiederherstellungpläne wenigstens vierteljährlich, bzw, immer dann, wenn sich etwas in Ihrem Backup Prozess verändert. Sie können sich nur dann sicher sein, daß Ihre Backup funktionieren, wenn Sie sie ausprobieren und weiderherstellen; und sicherlich wollen Sie das nicht erst auf die harte Tour herausfinden. Üben Sie ebenso die Point in time Wiederherstellung. Ich bin dafür bekannt, die WHERE Klausel im DELETE Statement anzugeben.

9: Festplatten und andere Hardware werden irgendwann ausfallen. Die Frage ist nicht, ob, sondern, wann.

10: Sichern Sie die Datenbankdateien (mdf, ndf und ldf) erst dann, wenn Sie vorher die Datenbank mit sp_detach offline genommen haben oder den SQL Server Dienst gestoppt haben. Diese "Backup's" sind nicht verwendbar mit differentiellen oder Transaktionsprotokollbackup's. Auch wenn Sie später SQL Server verwenden, um sie zu sichern und mit No RECOVERY wiederherzustellen. Müssen Sie ein Backup Utility ohne nativen SQL Server Support verwenden, verwenden Sie SQL Server, um die Datenbanken und Transaktionsprotokolle auf Festplatte zu sichern (aber bitte auf einer separaten physikalischen Platte!) und verwenden anschließend Ihr Backup Utility, um diese Backup Dateien zu sichern. Sichern Sie auf einen anderen Server, beachten Sie bitte, daß der Service Account mit dem SQL Server oder der SQL Server Agent gestartet wird, ein Domänen User sein muß, der auch auf dem Remote Server angelegt sein muß. Zusätzlich sollte ein RESTORE VERFIYONLY angewendet werden, wenn auf einen Remote Server gesichert wird.

11: Löschen oder überschreiben Sie kein Backup, solange Sie nicht wenigstens zwei voneinander unabhängige Wiederherstellungsalternativen haben (siehe Punkt 3:).

12: Logging läßt sich nicht abschalten. Es ist ein integraler Bestandteil von SQL Server und garantiert die ACID Eigenschaften des Systems.

13: Verwenden Sie einen Write-Cache Disk Controller, stellen Sie sicher, daß sein Speicher redundant ist und batteriebetrieben. Lernen Sie, wie man seinen Speicher im Falle eines Disasters wiederherstellt. Deaktivieren Sie Caching auf den Platten selbst.

14: Stellen Sie sicher, daß die Transaktionsprotokolle auf redundanten physikalischen Platten sind und nicht auf dem gleichen Array wie die Daten. RAID 1 ist ideal für Transaktionsprotokolle, da ihr typischer I/O (im Gegensatz zu den Datendateien) sequentiell ist. Haben Sie mehrere Datenbanken gleichzeitig in Benutzung, kann es sinnvoll sein, jedes Transaktionsprotokoll auf einem eigenen RAID1 Platten Paar zu haben; anderenfalls könnte auf dem sequentiellen I/O ein random I/O werden.

USE PUBS 
GO
SET NOCOUNT ON
CREATE TABLE #TableSpace
(
	Name char(20)
	,RowCnt int
	,Reserved varchar(15)
	,Data varchar(15)
	,Index_Size varchar(15)
	,Unused varchar(15)
)
DECLARE @Table sysname
DECLARE TableCur 
	CURSOR FOR
	SELECT 
		Table_Name
	FROM 
		INFORMATION_SCHEMA.Tables
	WHERE 
		Table_Type = 'BASE TABLE'
	AND 
		OBJECTPROPERTY(OBJECT_ID(Table_Name),'IsMSShipped') = 0
	OPEN TableCur FETCH NEXT FROM TableCur INTO @Table

WHILE @@FETCH_STATUS = 0
	BEGIN
		INSERT #TableSpace EXEC sp_spaceused @Table
		FETCH NEXT FROM TableCur INTO @Table
	END
CLOSE TableCur
DEALLOCATE TableCur
SELECT * FROM #TableSpace
DROP TABLE #TableSpace
SET NOCOUNT OFF

Name                 RowCnt      Reserved        Data            Index_Size      Unused          
-------------------- ----------- --------------- --------------- --------------- --------------- 
__tmpTBLCOL          131         80 KB           16 KB           8 KB            56 KB
authors              23          40 KB           8 KB            32 KB           0 KB
discounts            3           16 KB           8 KB            8 KB            0 KB
dup_authors          40          80 KB           16 KB           8 KB            56 KB
employee             43          40 KB           8 KB            32 KB           0 KB
jobs                 14          24 KB           8 KB            16 KB           0 KB
max_t                4           16 KB           8 KB            8 KB            0 KB
median               8           16 KB           8 KB            8 KB            0 KB
pub_info             8           160 KB          120 KB          16 KB           24 KB
publishers           8           24 KB           8 KB            16 KB           0 KB
roysched             86          32 KB           8 KB            24 KB           0 KB
sales                21          56 KB           8 KB            48 KB           0 KB
silly_one            0           0 KB            0 KB            0 KB            0 KB
stores               6           24 KB           8 KB            16 KB           0 KB
tableCounts          15          16 KB           8 KB            8 KB            0 KB
titleauthor          25          56 KB           8 KB            48 KB           0 KB
titles               18          40 KB           8 KB            32 KB           0 KB
Trace_Table_Name     0           0 KB            0 KB            0 KB            0 KB
vals                 127         24 KB           8 KB            16 KB           0 KB
x                    2           16 KB           8 KB            8 KB            0 KB

Danke an Jonathan van Houtte für das Originalskript.
Um sicherzustellen, dass RowCnt aktuell ist, sollte man vorher

DBCC UPDATEUSAGE(0) WITH COUNT_ROWS

ausführen.