Aufgabe: Einrichten eines SQL Wartungsplanes (Maintenance Plan) auf einem SQL Server, den man von der Arbeitsstation aus z.B. via einer Internet-Verbindung erreichen kann.

1. Lösungsversuch: Verbindung erstellen mit dem Management Studio von der Arbeitsstation aus mit dem öffentlichen Namen des SQL Servers und der entsprechenden Instanz -> Der Wartungsplan lässt sich problemlos einrichten, jedoch funktioniert dieser nur, wenn der SQL Server den verwendeten öffentlichen Namen ebenfalls auflösen kann! Der Grund liegt in der erstellen Server Verbindung für localhost innerhalb des Wartungsplanes,  hier steht nun der öffentliche Namen drinn und dieser lässt sich nicht so einfach ändern. Man kann den Wartungsplan exportieren und mit dem Visual Studio bearbeiten und dann neu importieren.

In der Regel ist es einfacher und schneller den Wartungsplan neu zu erstellen, nur diesmal mit

2. Remote Desktop Verbindung zu dem SQL Server erstellen und dann "lokal" auf dem Server mit dem Management Studio den Wartungsplan erstellen, dann klappts auf anhieb!

Der Version Control Agent 2.2.0.820 bietet die Möglichket mehrere HP Updates für die Installation zu selektieren und die Installation so in einem Arbeitsgang auszuführen. Wirklich eine sehr nützliche Erweiterung. Leider aber fehlen die Checkboxen ab und zu nach dem Update des Agenten.

Die Lösung des Problems ist relativ simple:

1. Kopieren Sie den Ordner "xls.en" aus dem Verzeichnis "C:\hp\hpsmh\data\cgi-bin\vcagent\" eines Servers, bei dem die Checkboxen angezeigt werden auf den lokalen Server

2. Starten Sie den "HP Version Control Agent" Dienst neu

Nun sollten die Checkboxen angezeigt werden und Sie können die restlichen Updates einfach und bequem installieren.

Nach der Installation des Adobe Flash Players 10.0 können auf einem Terminal Server 2003 nur Administratoren Flash-Inhalte betrachten. Alle anderen Benutzer erhalten eine Meldung, dass das Flash-Player Plug-in nicht installiert sei.

Das Problem konnte ich einfach lösen, indem die Zugriffsrechte in der Registry angepasst wurden:

1. Starten von Registry Editor (regedit) und navigieren zu folgendem Key:
   für 32 Bit Systeme: HKCR\CLSID\{D27CDB6E-AE6D-11cf-96B8-444553540000} 
   für 64 Bit Systeme: HKCR\Wow6432Node\CLSID\{D27CDB6E-AE6D-11cf-96B8-444553540000})
2. Lese-Berechtigungen für Everyone auf diesem Schlüssel und alle Unter-Objekten erteilen
3. Die gleichen Schritte müssen für den zweiten Schlüssel wiederholt werden
    HKCR\CLSID\{D27CDB70-AE6D-11cf-96B8-444553540000}  bzw.  HKCR\Wow6432Node\CLSID\{D27CDB70-AE6D-11cf-96B8-444553540000}

That's it!

Ein Problem, mit welchem schon mancher SQL-Admin Bekanntschaft gemacht hat und viel schlimmer noch, viele nicht einmal wissen, dass sich auf ihrem SQL Server eine solche Zeitbombe "ausbreitet". Das Transaktions-Protokoll des SQL Server wächst laufend weiter, obwohl täglich eine vollständige Datenbanksicherung durchgeführt wird!
Schuld daran ist nicht etwa der Microsoft SQL Server, sondern eine weitverbreitete Konfigurations-Kombination:

• Die Datenbank wird mit dem Wiederherstellungsmodell (Recovery Model) FULL oder BULK LOGGED betrieben (s. DB-Optionen)
  
  
• Die Wachstumseigenschaften des Transaktionsprotokolls sind auf automatisch wachsen, und dies unbeschränkt
  
  
• Täglich wird eine vollständige Datenbanksicherung ausgeführt, in der Regel mit dem Wartungsplan (was nicht falsch ist!)

Der SQL Server wird nun angewiesen, alle Transaktionen im Protokoll zu speichern. Der Speicherplatz innerhalb des Protokolls wird erst wieder zum Überschreiben freigegeben, nachdem diese gesichert wurden. Eine vollständige Datenbanksicherung erstellt eine Kopie der Datenbank und speichert zudem alle Transaktionen, welche während des Zeitraums der Sicherung ausgeführt wurden in die Sicherungsdatei. Transaktionen, welche vor dem Sicherungstart ausgführt wurden, sind daher nur im aktuellen Protokoll enthalten und in keiner Sicherung, weshalb dieser Speicherplatz nicht überschireben werden darf. Erst wenn eine Transaktionsprotokoll-Sicherung ausgeführt wird, werden alle Transaktionen aus dem Log gesichert und der Platz steht für neue Transaktionsaufzeichnungen zur Verfügung.

Wenn eine Datenbank also mit dem Recovery Model FULL bzw. Bulk Logged betrieben wird, so ist zwingend eine regelmässige (in der Regel mehrmals täglich) Transaktionsprotokoll-Sicherung erforderlich!

Microsoft SQL Server 2008 bietet mit Policy Based Management wertvolle Hilfsmittel, um sich vor solchen Konstellationen bei der Konfiguration zu schützen. Dazu mehr in meinem nächsten Blog.