Durch das Anwachsen des Datenbestandes konnte beim SQL-Server die Datenbanksicherung nicht mehr lokal erzeugt werden – der Festplattenplatz reichte schlicht nicht aus. Da die Sicherungen auf dem Server sowieso nur Zwischenstation machten und von dort auf ein externes Sicherungsmedium verschoben wurden, sollte die Sicherung direkt auf das Netzlaufwerk geschrieben werden. Leider ließen sich die Berechtigungen nicht so einrichten, dass das Schreiben auf das Netzlaufwerk gelang. Aber durch die Aktivierung der Kommando—Shell und einer Anpassung an dem Sicherungsskript gelang es dennoch.

Wenn man bei Datenbanken komplexere Verarbeitungen durchführen muss, kommt man meist um die Verwendung eines cursors nicht herum. Doch jeder, der schon mal einen cursor verwendet hat kennt bestimmt das Problem: Das Statement zum Sammeln der Daten ist geschrieben und funktioniert, die Ausführung dauert nur wenige Sekunden. Jetzt noch den cursor aufsetzen und den Durchlauf testen. Und merkwürdigerweise dauert dasselbe Statement mit einem Cursor wesentlich länger – der Faktor 100 ist hier keine Seltenheit.

declare @custid t_d_id
declare @name varchar(255)
declare @firstname varchar (255)

declare c cursor for 
	select cu.r_customerid, t_lastname, t_firstname
	from [sql-uptime-sht].uptimedata.dbo.customer cu
open c
fetch next from c into @custid, @name, @firstname
while @@fetch_status = 0 begin
	print @custid
	fetch next from c into @custid, @name, @firstname
end
close c
deallocate c

 Langsame Verarbeitung des cursors

Das liegt daran, dass der Standardcursortyp ein dynamischer cursor ist. D.h. der SQL-Server prüft die Bedingungen bei jedem fetch-Aufruf und das zieht die Performance so deutlich nach unten.

Du willst feststellen, in welchen Tabellen auf eine Tabelle per Fremdschlüssel verwiesen wird und es gibt kein Datenmodell? Du fängst an, in den Systemtabellen zu suchen und Dir ein kompliziertes Statement aufzubauen? HALT! Das musst Du nicht. Ganz einfach geht es mit

 exec sp_fkeys <TABLENAME>
Es werden alle wichtigen Informationen zu den Fremdschlüsselbeziehungen angezeigt. Tolle Sache.

Weil ich es mir nicht merken kann und immer mal wieder danach suche. Mit folgendem Codeschnipsel kann man die Version des SQL-Servers auslesen:

SELECT @@Version

Das Statement steht ab der SQL-Server Version 2005 zur Verfügung.

Jedes Mal, wenn ich es brauche, suche ich danach, deshalb hier als Gedankenstütze. Mit dem folgenden Konstrukt kann man aus drei Werten für Jahr, Monat und Tag in SQL ein gültiges Datum generieren (MS SQL Server):

select cast(rtrim(jahr * 10000 + monat * 100 + tag) as datetime) as Datum from Tabelle