Abfragen, in meinem Fall einige Views, haben plötzlich anstatt Sekundenbruchteile, Minuten gebraucht um ein Ergebnis zurückzugeben.
Das merkwürdigste aber daran war, wenn ich eine Datenbanksicherung auf einem anderen Server (sehr viel kleineren Server) zurückgespielt habe wurden die Abfragen wie gewohnt schnell ausgeführt.

Also lag die Vermutung nahe, dass es an diesem Server liegen muss und somit habe ich folgendes Versucht:

• Ein Neustart des SQL Server (auch den ganzen Servers) – Kein Erfolg. :-(
• Festplatte des Server defragmentiert (Natürlich vorher den SQL Server Dienst beendet, damit die Datenbankdateien selbst defragmentiert werden konnten) – Kein Erfolg :-(
• Gesamt Konfiguration des Server mit einem Server der schnellere Ergebnisse geliefert hat verglichen (Alles OK) – Kein Erfolg :-(
• SQL Profiler … Nein das ist Unsinn, denn die DB (also das Backup auf einem anderen Server läuft ja bestens) – Also Arbeit gespart

Und dann bin ich auf diese Seite gestoßen und dabei auch auf den alles Entscheidenden Hinweis; die Statistiken.

Ein Aufruf der Gespeicherten Prozedur sp_updatestats hat dann den gewünschten Erfolg gehabt.

Die Abfragen geben nun wieder wie gewohnt schnelle Ergebnisse zurück.

Und falls ich damit niemand anderem helfen kann, so doch sicherlich mir selbst, wenn in einigen Monaten bei einer anderen Datenbank ein ähnliches Problem ansteht und ich dies hier schon wieder vergessen habe, und dann über meinen eigenen Blog Beitrag stolpere.

Beim stöbern in meinen SQL Skripten bin ich gerade wieder auf das hier nachfolgend aufgeführte Skript zur Ausgabe der “Größe aller Tabellen einer Datenbank” gestoßen.

Da ich sicherlich nicht der einzige bin, der diese Informationen einer Datenbank hin und wieder benötigt, veröffentliche ich hier das Skript mit der Hoffnung dass es jemand gebrauchen kann.

SET NOCOUNT ON
CREATE TABLE #TableSpace 
(
	Rows int, 
	DataSpaceUsed int, 
	IndexSpaceUsed int
)
DECLARE @TableSpace table
(
	TableName varchar(255),
	Rows int, 
	DataSpaceUsed int, 
	IndexSpaceUsed int
)
DECLARE @Rows int, @DataSpaceUsed int, @IndexSpaceUsed int
DECLARE @TableName varchar(255)
DECLARE Table_Cursor CURSOR FOR
SELECT	user_name(o.uid) + '.' + o.name AS table_name
FROM	dbo.sysobjects o, dbo.sysindexes i 
WHERE	OBJECTPROPERTY(o.id, N'IsTable') = 1 
	AND i.id = o.id 
	AND i.indid < 2 
	AND o.name NOT LIKE N'#%' 
	AND xtype = 'U'
ORDER BY 1
OPEN Table_Cursor
---------------------------------
--Set Data
FETCH NEXT FROM Table_Cursor INTO @TableName
INSERT INTO #TableSpace (Rows, DataSpaceUsed, IndexSpaceUsed)
EXEC sp_MStablespace @TableName
SELECT	@Rows = Rows, 
	@DataSpaceUsed = DataSpaceUsed,
	@IndexSpaceUsed = IndexSpaceUsed
FROM	#TableSpace
INSERT INTO @TableSpace (TableName, Rows, DataSpaceUsed, IndexSpaceUsed)
VALUES (@TableName, @Rows, @DataSpaceUsed, @IndexSpaceUsed)
DELETE FROM #TableSpace
--------------------------------
WHILE @@FETCH_STATUS = 0


    BEGIN
    	---------------------------------
    	--Set Data
    	FETCH NEXT FROM Table_Cursor INTO @TableName
    	
    	INSERT INTO #TableSpace (Rows, DataSpaceUsed, IndexSpaceUsed)
    	EXEC sp_MStablespace @TableName
    	
    	SELECT	@Rows = Rows, 
    		@DataSpaceUsed = DataSpaceUsed,
    		@IndexSpaceUsed = IndexSpaceUsed
    	FROM	#TableSpace
    	
    	INSERT INTO @TableSpace (TableName, Rows, DataSpaceUsed, IndexSpaceUsed)
    	VALUES (@TableName, @Rows, @DataSpaceUsed, @IndexSpaceUsed)
    	
    	DELETE FROM #TableSpace
    	--------------------------------
END

CLOSE Table_Cursor
DEALLOCATE Table_Cursor
DROP TABLE #TableSpace
SELECT * 
FROM @TableSpace
ORDER BY Rows DESC

Über die Herkunft dieses Skripts (ich weiß dass ich zumindest die Idee von irgendwoher hatte) bin ich mir nicht mehr sicher. Eine gerade durchgeführte Recherche im Internet hat mir auch keinen direkten Aufschluss gegeben woher ich das Skript oder die Idee dazu hatte.

Sollte also jemand die Herkunft kennen, bitte einfach per Kommentar posten.

Wer kennt das nicht, mal schnell eine Abfrage auf eine SQL Datenbank mit dem Microsoft SQL Server Management Studio gemacht, Ergebnis der Abfrage markiert und dann mit Copy / Paste das Abfrageergebnis einfach in Excel eingefügt.

Soweit geht das auch ohne Probleme. Störend dabei ist nur, dass die Spaltenüberschriften (Spaltenheader) nicht mit kopiert werden und man diese wenn man sie benötigt manuell übertragen muss.

Wenn man das Ergebnis mit Copy / Paste als Text in einen Texteditor einfügt, sind die Spaltenheader übrigens vorhanden.

Das kann aber auch in Excel so sein.

Das Microsoft SQL Server Management Studio besitzt einen Optionsschalter mit dem man dieses Verhalten steuern kann.

Der Optionsschalter befindet sich wie nachfolgend dargestellt unter Extras --> Optionen

Man muss einfach nur das Häkchen bei der Option:

Spaltenheader beim kopieren oder Speichern der Ergebnisse einschließen.

setzen und schon wird auch der Spaltenheader kopiert.

Übrigens kann man das Verhalten beim einfügen in einen Texteditor genau so steuern, nur da ist die Default Einstellung eben; das Häkchen ist gesetzt (siehe Abbildung).

Da mein Hauptgeschäft nicht in der Erstellung von SQL Abfragen liegt, kommt es immer wieder vor, dass ich nach ein und der gleichen Lösung für ein Problem immer wieder mal recherchieren muss, da ich mir die Lösungen nicht (bzw. nicht immer) merken kann.

Dieser Beitrag fällt unter diese Kategorie (Und nachdem ich es nun aufgeschrieben habe, werde ich es wohl nie mehr vergessen , na dann hätte es ja was genutzt dies hier aufzuschreiben.).

Nun aber zum eigentlichen Problem bzw. zur Lösung:

Ich weiß nicht wie oft ich schon mal schnell eine SQL Abfrage machen musste, die alle Daten anzeigt, oder löscht oder was auch sonst immer, welches entweder vor, nach oder in einem bestimmten Jahr einen Eintrag in einem datetime Feld enthält

Bei eigenen Tabellen Entwürfen häufig das Feld "Created", oder "LastChange" - ein Datenbank Feld mit dem Datentyp datetime.

Nun ist die Abfrage "Select * from  <table> where <datetimeField>  < 2007" wie in der Überschrift verwendet syntaktisch nicht falsch, also es wird kein SQL Fehler erzeugt, aber es wird auch nicht das gewünschte Ergebnis angezeigt.

So wie die Abfrage aufgebaut ist, wird das Ergebnis leer sein, da keiner der datetime Werte kleiner sein dürfte als der Wert 2007.

Die korrekte Abfrage (besser gesagt, eine korrekte Möglichkeit) dafür sieht wie folgt aus:

Select * from  <table> where DatePart(year,<datetimeField>)  <= 2007

Hier wird nun nur nach dem Jahr innerhalb des datetime Ausdrucks verglichen und der Vergleich mit 2007 ist dann richtig.

Mehr über DatePart auf MS TechNet

SQL Profis mögen mir verzeihen wenn ich bei den verwendeten Begriffen nicht immer ganz getroffen habe, aber wie gesagt, SQL Abfragen ist nicht unbedingt mein Spezialgebiet.

Immer wieder taucht die Frage auf, welchen Beschränkungen die Express Edition des SQL 2005 Server aus dem Hause Microsoft unterliegen.

Vorab gesagt: Es sind weniger Beschränkungen als es der Vorgänger die MSDE hatte.
Und vor allem wird die Express Edition nicht auf eine Anzahl gleichzeitiger Threads beschränkt wie das bei der MSDE der Fall war.

Übrigens, wenn ich hier von der Express Edition spreche, dann ist dies nicht ganz korrekt, da es zwei Versionen gibt.

• Express Edition (Hier geht's zum Download 43,1 MB)
• Express Edition with Advanced Services (Hier geht's zum Download 234 MB)

Aber nun zu den Beschränkungen:

• Anzahl unterstützter CPU's = 1
• Maximale Speichernutzung (RAM) des SQL Server's = 1 GB
• Keine direkte 64 BIT Betriebssystem Unterstützung (nur über WOW)
• Maximale Datenbankgröße (ohne Log File) = 4GB
• Mergereplikation und Transaktionsreplikation = nur Abonnenten
• Volltextsuche (nur in der Express Edition with Advanced Services)

Einen kompletten Vergleich der einzelnen Editionen findet man wenn man dem nachfolgenden Link folgt:

http://www.microsoft.com/germany/sql/editionen/default.mspx

SQL Server 2005 Express Editionen

Ich hatte gerade mal wieder so eine "Erscheinung" mit SQL Express.
Während der Entwicklung eines DotNetNuke Portals (Version 4.5.3) welches mit einer SQL Express Datenbank arbeitet, hatte ich, warum auch immer, die Datenbank mit dem SQL Server Management Studio angehängt (attached).

Ich konnte dann wunderbar meine Abfragen und Analysen mit dem Management Studio machen. Nachdem ich nun DotNetNuke aufgerufen habe, erhalte ich folgende Fehlermeldung:

Die physikalische Datei "C:\DNN_4_5_3\Website\App_Data\Database.mdf" kann nicht geöffnet werden. Betriebssystemfehler 5: "5(Zugriff verweigert)". Fehler beim Anfügen einer automatisch benannten Datenbank für die Datei C:\DNN_4_5_3\Website\App_Data\Database.mdf. Eine Datenbank mit diesem Namen ist bereits vorhanden, die angegebene Datei kann nicht geöffnet werden, oder sie befindet sich in der UNC-Freigabe.

Was war geschehen ?

SQLExpress hat als ich die Datenbank mit dem SQL Server Management Studio angehängt habe, doch tatsächlich die Dateiberechtigung der Datenbank geändert (es hat die nicht Standardberechtigungen einfach entfernt). Da aber damit DotNetNuke auf der Entwicklermaschine unter Windows XP den Maschinename\ASPNET Account verwendet um auf die Datenbank mit der User Instance zugreifen, muss dieser natürlich auch Zugriffsrechte auf die Datenbank haben (Das wird bei der Installation von DotNetNuke extra vergeben).

Nun gut, es ist sicherlich nicht so schlimm, aber im ersten Moment fehlt einem der Zusammenhang zwischen dem anhängen der Datenbank und dem Verlust von Dateirechten.

Alle, die neben der Leistungsfähigen Express Version des SQL Server 2005, auch das entsprechende Verwaltungstool zum verwalten von SQL Server 2005 Express Edition und SQL Server 2005 Express Edition with Advanced Services, benötigen, sollten sich das ebenfalls kostenlose SSMSE (Microsoft SQL Server Management Studio Express) von Microsoft besorgen.

Das Tool gibt es in einer 32 und einer 64 BIT Version.

Hier geht es direkt zur Produktseite mit den Download's

Nachdem immer wieder die Frage auftaucht, wie den die Timeout Einstellungen beim SQL 2005 Express voreingestellt sind und wie man diese anpassen kann, hier nun eine kurze Erläuterung:

Standard Timeout SQL 2005 Express

Der Default Timeout für Remoteabfragen beträgt 600 Sekunden.

Ändern des Timeout über SQL Server Management Studio (Express)

Zum Ändern des Timeout startet man die SQL Server Management Studio Konsole.

Meldet sich am Server (SQL 2005 Express) an

Positioniert die Maus über dem Server

Klickt mit der rechten Maus und Öffnet die Eigenschaften.

Nun selektieren Sie die Option  "Verbindungen"

Hier können Sie nun im Feld Timeout für Remoteabfragen den Timeout selbst einstellen.

Dann noch auf OK Klicken und fertig. Server | SQL Server

Das Transaktionsprotokoll wird größer und größer, die Festplatte droht zu platzen, was kann man tun ?.

Wenn trotz Datensicherung das Transaktionsprotokoll nicht abgeschnitten und verkleinert wird. (Voraussetzung dafür ist allerdings, dass auch in den Einstellungen automatisch verkleinern aktiviert ist), kann man mit dem nachfolgenden SQL Script das Transaktionsprotokoll der SQL 2000 Datenbank manuell verkleinern.

BACKUP LOG pubs WITH TRUNCATE_ONLY
GO
DBCC SHRINKFILE(pubs_log, 10)
GO

Im Beispiel wurde die Datenbank pubs verwendet, ersetzen Sie einfach pubs gegen Ihre Datenbank und führen diese Befehle im SQL Query Analyzer aus.