In diesem Post reparieren wir die Berichterstellung eines Microsoft System Center Data Protection Managers 2007. Hier die Konfiguration der Maschine:

• Microsoft Windows Server 2008
• Microsoft System Center Data Protection Manager
• Microsoft Internet Information Server 7 (IIS7)
• Microsoft SQL Server Express

Bei Klick auf die Berichterstellung erscheint die folgende Fehlermeldung:

IIS-Konnektivitäts-Fehlermeldung vom SQL Server Services-Server

“Aufgrund von IIS-Konnektivitätsproblemen konnte keine Verbindung mit dem SQL Server Reporting Services-Server hergestellt werden.

Starten Sie auf dem Computer, auf dem die DPM-Datenbank erstellt wurde, den WWW-Publishingdienst neu. Klicken Sie im Menü ‘Verwaltung’ auf ‘Dienste’. Klicken Sie mit der rechten Maustaste auf ‘WWW-Publishingdienst’, und klicken Sie dann auf ‘Starten’.
ID: 3013″

Diese Fehlermeldung enthält die Anweisung, den WWW-Publishingdienst neu zu starten. Das funktioniert allerdings nicht. Im Video unten finden Sie die Fehleranalyse und Durchführung, aus Platzgründen finden Sie hier nur den Lösungsweg.

Die Lösung

Die Lösung des Problems liegt im IIS 7 begraben.

	Starten Sie den Internetinformationsdienste Manger
	Überprüfen Sie dann das Verzeichnis des SQL Server Report Services Server, um den Pfad dorthin zu bestimmen. Befindet er sich unterhalb der Default-Website dann lautet er in etwa so: http://localhost/ReportServer$MS$DPM2007$
	Nehmen Sie dann den im vorherigen Schritt bestimmten Pfad und geben Sie ihn im Internet-Explorer des Servers ein. Sie erhalten daraufhin die links erscheinende Fehlermeldung.
	In den Handlerzuordnungen verstecken sich die Ausführungsberechtigungen, die sich im IIS6 noch auf dem Reiter Basisverzeichnis befanden. Klicken Sie also Handlerzuordnungen an.
	Dann sehen Sie eine Übersicht über die erlaubten bzw. verweigerten Ausführungsberechtigungen.
	Dort klicken Sie dann rechts im Menü auf Featureberechtigungen bearbeiten…
	Sie sehen, dass die Ausführungs- bzw. Featureberechtigungen fehlen
	Setzen Sie sie alle (Lesen, Skript und Ausführen)
	Nachdem Sie die Report-Server Website im Internet-Explorer aktualisiert haben (Taste F5 drücken), sollten Sie nun die folgende Fehlermeldung sehen: “Die dem Benutzer ‘Domäne\Benutzer’ erteilten Berechtigungen reichen zum Ausführen des Vorgangs nicht aus. (rsAccessDenied)” Diese Fehlermeldung ist ok, da Sie in der Regel mit dem Benutzerkonto, mit dem Sie angemeldet sind, keinen Zugriff auf die SQL Server Datenbank haben. Wenn Sie diese Meldung sehen, funktionieren die Reporting Services wieder korrekt.
	Wechseln Sie in der DPM-Verwaltungskonsole auf den Reiter Verwaltung und dann wieder zurück zu Berichterstellung und Sie sehen das Bild links. (Sie können natürlich auch einen anderen Reiter wählen, ich hatte Verwaltung nur vorgeschlagen, weil er direkt neben der Berichterstellung liegt und man so die Maus nicht unnütz lang bewegen muss )

Im folgenden Video sehen Sie die Vorgehensweise, wie ich bei der Fehleranalyse vorgegangen bin.

www.youtube.com/watch?v=Q5oXarVPODI

Hinterlassen Sie einen Kommentar, wie Ihnen der Artikel gefallen hat, ob Sie selbst dies oder ein ähnliches Problem hatten, ob Sie einen weiteren Lösungsweg kennen, etc. Wir schauen uns das denn gemeinsam an. Ich freue mich auf das Gespräch mit Ihnen.

Der normale Weg, eine Microsoft SQL Server-Datenbank zu verkleinern ist über das Microsoft SQL Server Management Studio bzw. über den Befehl DBCC SHRINKDATABASE.
Doch was ist, wenn die Datei der Datenbank nicht kleiner wird? Was ist, wenn die Datenbank anzeigt, dass nur noch ein paar Megabyte Speicherplatz frei sind, obwohl Sie jede Menge Datensätze aus der Datenbank gelöscht haben?
Das ist mir mit einer Datenbank passiert. Inhalt: ca. 40 Mio. Datensätze, Größe: ca. 12 GB. Nachdem ich ca. 34 Mio. Datensätze gelöscht habe, zeigte die Datenbank über das SQL Server Management Studio an, dass gerade einmal 12 MB freier Speicher verfügbar war. DBCC SHRINKFILE oder DBCC SHRINKDATABASE haben keine Dateiverkleinerung erreicht. Die Größe blieb bei 12 GB.

Warum?

SQL Server schreibt die Daten in die Datenbank und erstellt sogenannte Seiten für die Indizes. Eine Seite hat eine bestimmte Größe. Ist eine Seite mit einer bestimmten Anzahl an Index-Einträgen gefüllt, dann wird eine neue Seite erstellt, auf die dann die nächsten Index-Daten geschrieben werden. So viel grob gesagt zur Technik.
Die Indizes in meiner Datenbank waren also auf viele Seiten verteilt, und diese Seiten wiederum in der gesamten Datei. DBCC SHRINKFILE und DBCC SHRINKDATABASE können zwar Speicher in der Datei reorganisieren, allerdings nichts gegen die Fragmentation der Seiten tun.

Die Lösung

Um die Seiten zu reorganisieren müssen Sie die Indizes in der Datenbank neu aufbauen und können danach die Befehle DBCC SHRINKFILE oder DBCC DBCC SHRINKDATABASE  ausführen.

2 Möglichkeiten

Hierfür haben Sie 2 Möglichkeiten zur Verfügung.

1. Über ein Skript
2. Über das Microsoft SQL Server Management Studio

Das Skript

Das Skript, das Sie für die Ausführung der Reorganisation benötigen, finden Sie als Nächstes in diesem Post. Die Ausführung über das Microsoft SQL Server Management Studio finden Sie als Videotutorial in diesem Post.
Das folgende Skript führt die Reorganisation der Indizes in der Datenbank aus und sorgt für eine Füllung der Seiten zu 90%.

USE DatenbankName -- Geben Sie den Namen der Datenbank an, deren
                  -- Indizes neu aufgebaut werden sollen

DECLARE @TableName varchar(255)
DECLARE TableCursor CURSOR FOR
SELECT table_name FROM information_schema.tables
WHERE table_type = 'base table'

OPEN TableCursor

FETCH NEXT FROM TableCursor INTO @TableName
WHILE @@FETCH_STATUS = 0
BEGIN
DBCC DBREINDEX(@TableName,' ',90)
FETCH NEXT FROM TableCursor INTO @TableName
END

CLOSE TableCursor

DEALLOCATE TableCursor

Da mit DBCC DBREINDEX immer nur einzelne Tabellen bearbeitet werden können, geht dieses Skript jede Tabelle einzeln durch.

Die Reorganisation via Microsoft SQL Server Management Studio

www.youtube.com/watch?v=n6Y1hlqrflU

Nach der Ausführung der Reorganisation funktioniert dann auch der DBCC SHRINKDATABASE Befehl:

use DatenbankName
go
dbcc shrinkdatabase    (DatenbankName, NOTRUNCATE)
go
dbcc shrinkdatabase    (DatenbankName, TRUNCATEONLY)

Danach war die Datenbank von 12 GB auf 2 GB geschrumpft.

Achtung!

Die Ausführung von DBCC DBREINDEX ist ein Offline-Vorgang, d.h. die Tabelle wird für die Zeit der Ausführung gesperrt und Benutzer können nicht darauf zugreifen. Deshalb empfehle ich, diesen Vorgang außerhalb der normalen Betriebszeiten auszuführen.

Wenn Sie Anregungen zu der Anleitung haben oder Kommentare, so zögern Sie nicht, hier zu kommentieren. Ich freue mich über Ihr Feedback.

Es kann passieren, dass Sie das Transaktionsprotokoll einer Microsoft SQL Server Datenbank nicht verkleinern können (wohl die Anzahl der Einträge, nicht aber die Dateigröße).
Der folgende Code verkleinert das Transaktionsprotokoll bis zur kleinsten möglichen Größe:

USE DatabaseName
GO
DBCC SHRINKFILE(<TransactionLogName>, 1)
BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLY
DBCC SHRINKFILE(<TransactionLogName>, 1)
GO

ACHTUNG!!!

Bei SQL Server 2008 wird nur noch der Shrinkfile-Befehl benötigt, der Backup-Befehl ist überflüssig, zumal “WITH TRUNCATE_ONLY” nicht mehr funktioniert.

LoadTraceFileToTable ist eine T-SQL Stored Procedure für den Microsoft SQL Server 2005. Wie auch der SQL Server Profiler generiert auch LoadTraceFileToTable eine neue Trace Tabelle von einem Trace File. Aber anders als der SQL Server Profiler bläht LoadTraceFileToTable die master oder user Datenbank nicht unnötig auf, da die Tabelle erst nach dem Profiling-Prozess angelegt wird.

Ich habe es immer vorgezogen, die Daten aus einem Trace File (.trc) zu Analysezwecken in eine Datenbanktabelle zu importieren. So ist es für mich einfacher, die Daten zu analysieren, da es ein Leichtes ist, auf der Datenbank ein paar Abfragen laufen zu lassen. Also habe ich die Stored Procedure LoadTraceFileToTable geschrieben. Mit dieser Stored Procedure kann ich ein beliebiges Trace-Ergebnis aus einem Trace-File in eine Trace Tabelle importieren, Abfragen auf dieser ausführen und nachher wieder löschen, ohne dass mir die Original-Daten verloren gehen.

Die LoadTraceFileToTable Stored Procedure soll den SQL Server Profiler nicht ersetzen sondern eher komplettieren. Denn auch der SQL Server Profiler kann Trace Tabellen aus Trace Files erzeugen. LoadTraceFileToTable hat einen entscheidenden Vorteil gegenüber SQL Server Profiler: während des Traces kann die Tabelle schnell Millionen von Zeilen füllen und somit die master oder user Datenbank vergrößern. LoadTraceFileToTable legt die Tabelle nach dem Trace an, so dass diese Systemdatenbanken nicht unnütz vergrößert werden.

Die LoadTraceFileToTable Stored Procedure (siehe Listing 1) konstruiert eine dynamische T-SQL Abfrage. Genauer gesagt erstellt sie einen SELECT INTO Befehl, der die ::fn_trace_gettable System Funktion benutzt. Diese Funktion transformiert eine Trace Datei in eine Tabelle. Die LoadTraceFile ToTable Stored Procedure fügt ebenfalls eine bigint Identity Spalte hinzu.

Die LoadTraceFileToTable Stored Procedure wurde zur Benutzung auf dem SQL Server 2005 geschrieben. Sie benötigt 2 Parameter: 1. den Pfad- und Dateinamen der Trace Datei und 2. den Namen der Tabelle, die angelegt und in die die Daten importiert werden sollen. Der Name der Zieltabelle muss im Format Datenbank.Schema.Tabellenname angegeben werden.

Wenn Sie z.B. die Datei C:\ELI_TRACE.trc in die Zieltabelle AdventureWorks.dbo.trc_04052007 importieren wollen, würden Sie den folgenden Code ausführen:

EXEC LoadTraceFileToTable
@traceFileName = ‘C:ELI_TRACE.trc’,
@newTraceTableName = ‘AdventureWorks.dbo.trc_04052007’

Bevor Sie diesen Befehl ausführen, sollten Sie sicherstellen, dass die folgenden Voraussetzungen erfüllt sind, da sie von der Stored Procedure nicht abgetestet werden:

1. Die Trace Datei muss vor der Ausführung der Stored Procedure bereits existieren
2. Der Trace File Parameter muss den vollen Pfadnamen beinhalten
3. Der Tabellennamen Parameter muss im Format Datenbank.Schema.Tabellenname angegeben werden
4. Die Trace Tabelle darf in der Datenbank nicht existieren
5. Der SELECT INTO Befehl muss auf dem Server ausführbar sein (z.B. sollte die SELECT INTO/Bulk Copy Option aktiviert sein)

--Listing 1: The LoadTraceFileToTable Stored Procedure

CREATE PROCEDURE LoadTraceFileToTable
 (@traceFileName varchar(200),
 @newTraceTableName sysname)
AS
BEGIN
 DECLARE @tsqlStmt varchar(400)
 SET NOCOUNT ON
 SET @tsqlStmt =

-- BEGIN CALLOUT A
 'SELECT IDENTITY(bigInt,1,1) AS Row_Number,' +
 '* ' + ' INTO ' + RTRIM(LTRIM(@newTraceTableName)) +
 ' FROM ::fn_trace_gettable ( ' + '''' +
 @traceFileName + '''' + ',default)'
-- END CALLOUT A

 PRINT @tsqlStmt
 EXEC (@tsqlStmt)
 SET NOCOUNT OFF
END
GO

Dieser Artikel ist eine direkte Übersetzung des Artikels T-SQL Stored Procedure Creates Trace Tables from Trace Files von Eli Leiba, Senior Application DBA, Israel Electric Company, der mir freundlicherweise die Genehmigung für die Übersetzung und die Veröffentlichung des Codes gegeben hat.

This post is a direct translation of the article T-SQL Stored Procedure Creates Trace Tables from Trace Files by Eli Leiba, Senior Application DBA, Israel Electric Company, who kindly acknowledged me the right to repulish the translated version. Thank you Eli, for sharing this great code with us.

Gestern ging es noch, doch heute funktioniert das Companyweb nicht mehr. Einfach so. Ohne Grund. Niemand hat etwas verändert…

Dieses Verhalten habe ich bei einem Microsoft Server 2008 festgestellt der Sharepoint hostet und die Daten für das companyweb in einer SQL-Server 2005 Datenbank auf einem weiteren Server speichert. Da dieses Phänomen regelmäßig auftritt (meistens mittwochs oder donnerstags…), widme ich diesem Problem einen extra Post.

Dienstags rollt Microsoft neue Updates aus. Sind hierbei Updates für einen Server 2008 vorhanden, die einen Neustart erfordern, kann das beschriebene Verhalten nach dem Neustart des Servers, der die SQL-Server-Dienste hostet, auftreten. Dann werden diese nicht (immer) neu gestartet, obwohl die Startart auf “Automatisch” gesetzt ist.

Wie diese neu gestartet werden, habe ich in meinem Post “SQL Server Dienste neu starten” beschrieben.

Es kann passieren, dass der Microsoft SQL-Server 2005 nicht mehr antwortet. Diesen Fall habe ich auf einem virtuellen Microsoft Server 2008 (Hyper-V) beobachtet.
In unregelmäßigen Abständen sind die SQL Server Dienste, die eigentlich beim Systemtart automatisch gestartet werden sollen, nicht gestartet bzw. haben in der Anzeige im Server-Manager keinen Status “Gestartet”. Dies passiert meistens Mittwochs, nachdem der Server die Dienstags-Updates von Microsoft installiert und sich danach selbst neu gestartet hat.
Folgendes Video zeigt die Vorgehensweise in der GUI:
[wpvideo 9rhEljbB]

Die Befehle für die Kommandozeile wären folgende:
net start “SQL Server (Instanzname)”
net start “SQL Server Analysis Services (Instanzname)”
net start “SQL Server Browser”
net start “SQL Server Integration Services 10.0″
net start “SQL Server Reporting Services (Instanzname)”
net start “SQL Server-Agent (Instanzname)”

Wobei der Instanzname durch den Namen der SQL-Server-Instanz ausgetauscht werden muss. Die Standard-Instanz, die SQL Server installiert heißt “MSSQLSERVER”.

Mögliche Fehlermeldungen

Fehler 1069: Der Dienst konnte aufgrund einer fehlerhaften Anmeldung nicht gestartet werden.

Taucht die Fehlermeldung “Fehler 1069: Der Dienst konnte aufgrund einer fehlerhaften Anmeldung nicht gestartet werden.” auf, dann sind die SQL-Server-Accounts Opfer der Gruppenrichtlinie zur regelmäßigen Änderung des Passwortes geworden. In diesem Fall muss für jedes Benutzer-Konto für die SQL-Server-Dienste das Passwort neu gesetzt werden. Dies kann über die GUI geschehen oder mit Hilfe des folgenden Befehls an der Kommandozeile:

net user Kontoname Passwort /domain

Wobei Kontoname der Name des Benutzerkontos ist und Passwort das dementsprechende Passwort.

Wenn wieder das alte Passwort eingegeben wird, dann können die Dienste direkt neu gestartet werden. Wird ein neues verwendet, dann müssen die Dienste natürlich analog angepasst werden.

Microsoft hat hier ebenfalls einen interessanten Support-Artikel für dieses Problem: http://support.microsoft.com/kb/259733/de