Donnerstag, 29. März 2012

SSIS 2012 Toolbox ist leer

Die neue, auf Visual Studio 2010 basierende Entwicklungsumgebung für SQL Server 2012 Integration Services ist wirklich angenehm. Aber es gibt eine Merkwürdigkeit, die mich einige Zeit gekostet hat:

Wenn Sie (versehentlich oder mit Absicht) die Toolbox entfernen, dann konnten Sie bisher die Toolbox über das Menü "View" - "Toolbox" wieder sichtbar machen. Versuchen Sie dies jedoch mit der neuen Entwicklungsumgebung, gibt es eine Überraschung: Die Toolbox ist leer!

Überraschung: Die Toolbox ist leer!

Und nun? Es gibt eine neue Schaltfläche, die an einer völlig ungewohnten Stelle angebracht ist, nämlich rechts neben den Registerkarten über der Fläche des Editors:

Die neue Schaltfläche für die Toolbox ist rot eingekreist.

Die Schaltfläche heißt "SSIS Toolbox" und bringt tatsächlich die gewünschte Toolbox zur Anzeige. Da muss man erst einmal drauf kommen, dass SSIS eine ganz andere Toolbox hat als die anderen Projekttypen und dann noch, dass die Funktion zum Anzeigen sich an so einer seltsamen Stelle befindet. Ich hoffe noch darauf, dass dies mit einem Service Pack behoben wird.

Mittwoch, 21. März 2012

Namensänderung: VertiPaq heißt jetzt xVelocity

Mit PowerPivot für Excel hat Microsoft 2009 eine neue Engine für die Analyse sehr großer Datenmengen veröffentlicht. Diese lädt idealerweise alle Datensätze in den Hauptspeicher, was aufgrund der hohen Komprimierung auch bei Milliarden von Datensätzen mit gängiger PC-Hardware machbar ist. Spaltenbasierte Indexe sind neben der Komprimierung das zweite wichtige Merkmal dieser Technologie.
Mit SQL Server 2012 hat diese Engine an drei Stellen Einzug im Server gehalten:
  • Spaltenbasierte Indexe in der relationalen Datenbank
  • PowerPivot für SharePoint auf Basis der Analysis Services
  • BISM Tabular (die tabulare Variante von Analysis Services, welche nun neben der bisherigen multidimensionalen Variante existiert)
Der Name dieser Engine war bisher VertiPaq. Wie das Produktteam für Analysis Services und PowerPivot kürzlich mitteilte, hat sie einen neuen Namen erhalten: "xVelocity in-memory analytics engine". Die drei oben erwähnten Einsatzbereiche der Engine werden auch als xVelocity Familie bezeichnet.

Ob es in Redmont eine Feier anlässlich der erneuten Taufe gab?

Zum Blogbeitrag der SSAS Produktgruppe

Dienstag, 13. März 2012

Konsistenzprüfungen mit CHECKDB auslagern?

Als Administrator von SQL Server Datenbanken sind Sie für einen stabilen Betrieb verantwortlich. Was bedeutet das konkret? Sichern, Indexpflege und Konsistenzprüfung.

Das Problem:
Inzwischen gibt es in vielen Unternehmen sehr große Datenbanken (mehrere 100GB) und die Konsistenzprüfung mit dem Befehl DBCC CHECKDB kann schon mal mehrere Stunden dauern. Da diese Prüfung recht viel I/O erzeugt und einiges an CPU-Leistung braucht, spüren die Anwender diese Prüfung, wenn sie während des laufenden Betriebs durchgeführt wird. Gerade bei kleinen Wartungsfenstern stellt sich dann die Frage, ob die Konsistenzprüfung nicht auf eine andere Maschine als die Produktionsmaschine ausgelagert werden kann.

Folgende Überlegungen hierzu:
Sie betreiben einen Standby-Server, auf den mittels Protokollversand immer die Änderungen der Produktivdatenbank im STANDBY Modus übertragen werden. Damit ist die Datenbank für lesende Zugriffe verfügbar. Wäre es nicht möglich, gegen diese sekundäre Datenbank die Konsistenzchecks laufen zu lassen und so die Produktionsmaschine zu entlasten?
Das Problem an diesem Vorgehen ist, dass Sie damit Fehler des I/O Subsystems auf dem Produktivserver nicht erkennen können. Sie stellen lediglich sicher, dass die sekundäre Datenbank konsistent ist.
Aus dem gleichen Grund liefert auch ein Konsistenzcheck einer gespiegelten Datenbank keine Aussage über den Zustand der primären Datenbank. Gleiches gilt für die neuen Verfügbarkeitsgruppen des SQL Server 2012.
Es gibt nur einen Weg, die Konsistenzprüfung einer Datenbank auf einen anderen Server auszulagern:
Stellen Sie dort eine Vollsicherung der zu prüfenden Datenbank wieder her und führen Sie dort DBCC CHECKDB aus. Bei der Vollsicherung werden die Speicherseiten inklusive aller möglichen Fehler erfasst und mit diesen Fehlern auch wiederhergestellt.

Fazit:
Führen Sie Konsistenzprüfungen immer gegen die Produktionsdatenbank durch. Alternativ können Sie die Konsistenzprüfung gegen eine Datenbank durchführen, die aus einer Vollsicherung wiederhergestellt wurde.

Wichtig:
Führen Sie auf jeden Fall regelmäßig Konsistenzprüfungen durch, um Fehler des I/O Subsystems rechtzeitig zu erkennen und beheben zu können!