blog.atwork.at

news and infos about microsoft, technology, cloud and more

System Center Advisor einrichten Teil 2

Nach dem Entfernen der Beta-Version von Atlanta in Teil 1 nun zum spannenderen Teil: Die Installation von System Center Advisor Gateway und Agents auf den zu überwachenden Maschinen. Wie die Beta-Version ist auch der Release Candidate des System Center Advisor ein freier Download. Mit SC Advisor können x86 und x64 Versionen von Windows Server 2008 (und später) und Microsoft SQL Server 2008 (und später) überwacht werden - für andere Systeme ist SC Advisor (derzeit) nicht vorgesehen. Als ersten Schritt zur Einrichtung besuchen Sie die SC Advisor Website https://www.systemcenteradvisor.com/ und legen Sie dort mit "Create account" (mit Ihrer Windows Live ID) ein neues Konto an. Folgen Sie den Schritten, bis Sie zur Silverlight-Verwaltungsoberfläche "Alert Dashboard" gelangen: Zunächst wird einmal in der Section "Servers" links ein neuer Server hinzugefügt: Nun folgt eine Dialogbox mit zwei Downloads:  1. ein Zertifikat für den Account und das Gateway und 2. das Setup-Programm. Zertifikat und Setup-Programm AdvisorSetup.exe (etwa 30MB) werden nun downgeloadet und auf der Ziel-Maschine installiert. Hinweise für die Automatisierung: Deploy System Center Advisor und  Install the Gateway and Agent from the Command Line. Auch wichtig: Für das Gateway müssen die Ports 80 und 443 offen sein, siehe Firewall Information for System Center Advisor. Ok, nun wird das Setup ausgeführt: Bestätigen Sie das Lizenzabkommen und bestätigen Sie den Installationspfad: Mein Server ist mit dem Internet verbunden und soll sowohl Gateway (eines pro Netzwerk) und Agent (für diese Maschine) sein. Wenn weitere Maschinen überwacht werden sollen, wird dort nur mehr der Agent installiert. Wenn die Rolle "Gateway" ausgewählt wird, muss nun auch das heruntergeladene Zertifikat angegeben werden: In meiner Umgebung ist kein Proxy erforderlich und für Testzwecke - es ist immerhin ein RC - lasse ich alle Maschinen für das Gateway zu. Weiter. Tipp: In Authorize Agents to Access the Gateway wird beschrieben, wie im Computer Management nur autorisierte Agents zugelassen werden können. Nun informiert mich das Setup über die auf meiner Zielmaschine erforderliche Komponente  SC Operations Manager 2007 R2 Agent (eine Voraussetzung für SC Advisor) - netterweise bietet das Setup gleich an, diesen zu installieren. Hat funktioniert, jetzt kann endlich der SC Advisor Agent installiert werden: Here we go. Finish: Hinweis: Für Tuning und mögliche Probleme bei der Installation siehe Teil 3 - Troubleshooting! Wenn alles geklappt hat, erscheinen in der Verwaltungsoberfläche mit Refresh (rechts) das Gateway und der Agent: Hinweis: Das initiale Übermitteln der Daten aus dem Agent kann übrigens einige Stunden dauern, also nicht nervös werden... So, die Hauptarbeit ist getan. Nun muss nur noch auf allen weiteren Maschinen ebenfalls der Agent installiert werden. Der Setup-Prozess unterscheidet sich nur in der Rolle "Agent" (ohne Gateway) und logischerweise Angabe des Gateways. Der Setup-Wizard fragt dann nach der Adresse des Gateways - also der Maschine mit dem Gateway-Service (in meinem Beispiel SP5.atwork.local), das sieht dann so aus: Voila: Refresh und die zweite Maschine ist mit System Center Advisor verbunden. Feine Sache. Dann warten wir mal auf die gesammelten Daten dieser überwachten Maschinen...!

System Center Advisor einrichten Teil 1

Microsoft Codename Atlanta wurde zu System Center Advisor. Aktuell liegt das Online-Monitoring Tool als Release Candidate vor (siehe Microsoft Atlanta wird zu System Center Advisor). System Center Advisor läuft auf x86 und x64 Windows Server 2008 (und später) und kann eben diese Maschinen und Microsoft SQL Server 2008 (und später) überwachen. Die Verwaltungsoberfläche läuft - wie auch beispielsweise Windows Azure - in einer Silverlight 4.0 Website in der Microsoft Cloud. In diesem Beitrag geht es in zwei Teilen darum, die Beta-Version von Atlanta von bestehenden Maschinen zu entfernen und danach die aktuellen Services von System Center Advisor einzurichten. Wenn Sie eine Vorversion (TAP oder Beta) von System Center Advisor (zuvor Microsoft Codename Atlanta) auf einer Maschine installiert hatten, so folgen Sie dieser kurzen Anleitung (siehe auch Upgrade from a Pre-Release Version of System Center Advisor). Wichtig: Das Beta Gateway und der Beta Agent soll NICHT (wie wohl erwartet) in "Systemsteuerung\Programme\Programme und Funktionen" deinstalliert werden: - Sondern stattdessen muss uninstall.exe im Programme-Verzeichnis in Microsoft Atlanta ausgeführt werden! Hier nun einfach den Schritten folgen (wie man es von einer Beta-Version erwartet im Console-Modus): Bis zum Ende. Hiermit verschwindet auch das installierte Programm in der Systemsteuerung. Es bleibt dann nur mehr C:\Program Files\Microsoft Atlanta und Uninstall.exe übrig - dieses sollte dann einfach manuell gelöscht werden (siehe auch Uninstall a Gateway or Agent). Das wars. Bestehende Atlanta Konten bleiben bestehen und sind funktionell. In Teil 2 werden Release Candidate Gateway und Agents neu installiert!

CSAD - CSS SQL Azure Diagnostics Tool

Frisch für alle SQL Azure Anwender: Im Blog mit dem unglaublich kurzen Namen "Official team Web Log for Microsoft Customer Service and Support (CSS) SQL Support"  (ok, die Kurzform ist CSS SQL Server Engineers) wurde ein neues Tool veröffentlicht, das CSS SQL Azure Diagnostics tool. Auch dafür gibt es - Microsoft-konform - eine Abkürzung: CSAD Evan Basalik hat die Applikation CSAD entwickelt - da die Tools PSSDiag und SQLDiag gegen SQL Azure nicht funktionieren - um rasch eine Zusammenfassung der wesentlichen Daten einer SQL-Datenbank als Report zu erhalten - vor allem zum Troubleshooting von SQL Azure Performance-Problemen. CSAD liest ALLE Information aus den public Dynamic Management Views (DMVs) (diese funktionieren grundsätzlich genauso gegen einen lokalen SQL Server). Der direkte Download von CSAD (CSS SQL Azure Diagnostics) ist hier zu finden http://csssqlazure.blob.core.windows.net/csssqlazuredeploy/publish.htm. CSAD prüft automatisch beim Starten gegen den BLOB-Storage, ob eine neue Version vorliegt. Ich musste dieses Tool natürlich gleich testen - funktioniert auf Anhieb, hier mein Beispiel: Mein Report umfasst 4 Seiten. Das Tool zeigt : Top 10 CPU consumers (queries that are consuming the most CPU) Top 10 Durations (longest running queries) Top 10 Logical I/O (logical I/O consuming queries) Top 10 Physical I/O (physical I/O consuming queries) Sehr fein ist auch der integrierte Export nach Excel, PDF und Word. SQL Azure Benutzer: Anschauen & Ausprobieren!

IE9 Compat Inspector

Rascher Hinweis auf ein nützliches, neues Tool: Der IE9 Compat Inspector http://bit.ly/compat_inspector überprüft eine Webseite im Betrieb darauf, ob sie beim Zugriff durch den IE9 Darstellungsprobleme hat. Compat Inspector ist ein JavaScript-basierendes Werkzeug, das die jeweilige Webseite während der Laufzeit analyisiert. Die Verwendung ist einfach: Fügen Sie dieses Script VOR allen anderen Scripts in jede zu testende Seite ein: <script src="http://ie.microsoft.com/testdrive/HTML5/CompatInspector/inspector.js"></script> Wenn die Seite angesurft wird, erscheint damit in der rechten oberen Ecke der IE9 Compat Inspector: Natürlich gleich getestet: Bei einem anderen Browser als IE9 folgt übrigens ein Hinweis - es zeigt sich aber meist trotzdem. Beim Klick auf einen Button im Compat Inspector folgen Informationen dazu - im besten Fall sieht das wie in diesem Screenshot leer aus. In den "Tests" und "Verifiers" können die zu prüfenden Events und Methoden an- und ausgeschalten werden: Kurzum: IE9 Compat Inspector aus dem MSDN ist ein kleines, praktisches Tool, das Website-Admins mit wenig Aufwand helfen kann, die IE9 Kompatibilität zu prüfen.

TechEd Europe moves to...

Waren Sie auf einer der letzten Microsoft TechEd Konferenzen? Wenn ja, dann haben Sie wahrscheinlich auch vor kurzem eine E-Mail "Save the date for the next Tech·Ed Europe" erhalten! Microsoft ändert den Modus der TechEd: Dieses Jahr wird es keine TechEd geben (ja, es gab vorab diesbezügliche Gerüchte, nun ist es fix). Die nächste TechEd Europe #tee2012 wird in der Woche von 25. bis 29. Juni 2012 abgehalten. Und der Konferenzort wandert 2012 von Berlin nach Amsterdam! Für die meisten TechEd Teilnehmer wird es mit dem neuen Modus viele Für und Wider geben, aber eines steht für mich fest: Amsterdam im Juni wird wettermäßig bestimmt besser als Berlin im November - auch wenn das Wetter bei Konferenzen nicht unbedingt wichtig ist, so male ich in meinem Geiste bereits Bilder vom abendlichen Bier an den Grachten. Als diesjährige TechEd-Alternative bietet Microsoft übrigens die Teilnahme an der TechEd 2011 North America in Atlanta, Georgia, von 16. bis 19. Mai, an und bietet für die europäischen Teilnehmer einen Rabatt von 200 US$ an - für Schnellentschlossene. Alle Inhalte der TechEd 2010 sind übrigens auch auf für jedermann auf Tech·Ed Europe 2010 Online abrufbar! CU there?!

Freuen Sie sich auf die Microsoft Big>Days 2011!

Sie sind schon fast da: Die Big>Days 2011 starten kommenden Dienstag, am 22. März in Bregenz, gefolgt von Donnerstag, 24.3. in Linz und in der Woche darauf wieder Dienstag, den 29.3. in Wien und letztendlich wieder am Donnerstag, 31.3. in Graz. Gestern fanden die letzten Probe-Sessions ("Rehearsal") statt, nachdem die ganze letzte Woche bereits Dynamics, IT-Pro und die Developer Sessions vorgetragen und geprüft wurden. So viel können wir vorab schon verraten: Es wird spannend! Die diesjährigen Big>Days stehen ganz im Zeichen der Cloud und werden Ihnen - egal ob das Thema Cloud Computing für Sie neu ist, oder ob Sie bereits Cloud-Profi sind - viele interessante Perspektiven und Technologien aufzeigen. Sehen Sie Sich vor Ihrem Besuch die Agenda an und planen Sie Ihre Besuche wohl, bei so vielen interessanten Themen! Hier ein Schnappschuss nach einer erfolgreichen Rehearsal-Woche. Eine wichtige Frage, die aufgekommen ist, war: Wie konjugiert man eigentlich "Rehearsal"? Ich rehearsal, du rehearsalst, er/sie/es rehearsalt, wir rehearsalen...? Martina Grom, David Schwingenschuh, Toni Pohl, darunter Max Knor - ein Teil des Rehearsal-Teams. Viele Microsoft Product Manager haben es sich auch nicht nehmen lassen, "ihre" Produkt-Sessions selbst anzuhören und auf Herz und Nieren zu prüfen. Nachdem Martina ja bereits ein wenig über die IT-Pro Themen verraten hat (Big>Days 2011: lassen Sie sich diesen geprüften Content nicht entgehen!), hier ein kleiner Ausblick von meiner Seite zu den Developer-Sessions: Es erwarten Sie viele Tipps & Tricks zu Windows Azure (von Architektur und Fabric Controller bis zu Web und Worker Roles), zu den Speichermodellen und viiiieeeel Performance Tipps bis zu Parallel Computing und warum man es (unbedingt) einsetzen sollte (PLINQ, DegreeOfParallelism sowie generelle Infos zu ScaleUp, ScaleOut, Sharding usw.). Für mich standen vor allem die praktischen Hinweise der Azure-Profis im Vordergrund. Wann sollte man am besten welches Modell und welche Technologie einsetzen bis hin zu den verwendeten Tools, Funktionen wie Swap VIP, die neue VMRole und den Einsatz von Legacy Code (COM, andere Programmiersprachen wie PHP, etc.) und wie man eigene Applikationen am besten in Windows Azure migrieren kann. Und zum Abschluss gibt es auch noch Windows Phone 7 mit praktischen Tipps, wie Sie Ihre App in den Windows Marketplace bekommen und eine geniale Session über ASP.NET MVC, das nagelneue Razor, gewürzt mit ein wenig jQuery sowie eine Session über das ebenso brandneue Visual Studio Light Switch und natürlich SharePoint Development mit Office 365. Nutzen Sie die Big>Days, um Gebrauchsszenarien für Entwickler, IT-Pros und Anwender zu erfahren und Ihre persönliche Cloud-Revolution zusammenzustellen. Microsoft und die Microsoft-Partner werden Sie dabei gerne unterstützen - von der Ausbildung, Planung und Implementierung bis zum Betrieb Ihrer eigenen Cloud-Lösungen! CU there!

HTML5 oder Silverlight, das ist hier die Frage

Diese Diskussion ist in Web-Developer Kreisen spätestens seit der letzten Microsoft PDC im Herbst top-aktuell. Dazu gibt es viele Statements und Meinungen. Eine recht interessante Meinung dazu findet sich hier: The Inquisitive Coder - Davy Brion's Blog - Why We're Going With HTML(5) Instead Of Silverlight Gegen Silverlight sprechen unter anderem der "proprietäre Standard" (nur in Windows und OS X) und die fehlende mobile Lösung: Android und iOS unterstützen kein SL und werden es wahrscheinlich auch so bald nicht tun, weil kein Bedarf. Für Silverlight sprechen vor allem die Entwickler-Tools (Visual Studio, Expression Blend) und die gute Integration in die Entwicklungsumgebung. Debugging ist einfach, Security kein Thema und es gibt keine Herumfrimmelei mit Browser-Support, HTML und CSS (bye bye Firebug...). Das waren jetzt nur wenige Gründe, aber mal ein paar strategische Themen. In obigem Blog-Artikel wurden die Kategorien gewichtet und darauf basierend ein Rating erstellt. Hier liegt der Vergleich der Argumente 100% HTML5 zu 77% Silverlight. Es steht und fällt also mit der Gewichtung der einzelnen Bereiche. Natürlich muss sich jeder selbst sein eigenes Bild machen. Ich denke, beide Web-Technologien haben Vorteile und - mal ganz ehrlich: Es ist bestimmt nicht verkehrt, sich beide Technologien anzueignen und je nach Bedarf zu verwenden...

IE9 RTM kommt am 15. März

Es ist soweit! Wie das Windows Team Blog verkündet, wird der nigel-nagel-neue Internet Explorer 9 am 14. März (USA Pacific Time um 21h) veröffentlicht! A More Beautiful Web Launches on March 14th Zwölf Monate nach der ersten Platform Preview Version (bei mix10, was ich live miterleben durfte) erblickt IE9 also das Tageslicht - bei uns am 15. März um 6h Früh, da ist es mittlerweile gerade hell, in den USA ist es noch Abend - und die Launch-Party wird nach der Pressemitteilung starten. Viele der neuen Funktionen konnten bereits in der Vorgänger-Versionen getestet werden (siehe IE9 News). Meine persönlichen IE9-Highlights sind vor allem die Schnelligkeit, HTML5 sowie die vielen kleinen Verbesserungen wie Neue Tabs, Pinned Sites, neuer Developer-Modus, Tracking Protection Lists, und da gibt es noch ein paar weitere... Für alle, die zum Thema IE9 topaktuell informiert werden wollen: Siehe www.beautyoftheweb.com und folgen Sie dem IE-Team auf Twitter: www.twitter.com/ie! Ich freu mich schon auf den neuen IE9. Viel Spaß und sicheres Surfen mit IE9!

SQL Server: The transaction log for database is full

Schön ist, wenn man als Datenbank-Administrator ein ruhiges Leben führen kann: Dann, wenn alle Datenbank-Wartungen gescriptet sind und automatisch laufen. So müssen nur zeitweise die Logs durchgesehen werden und die administrativen Tätigkeiten sind sehr gering (Tipp: Siehe übrigens auch Microsoft Codename Atlanta – SQL Monitoring Teil 1,  2 und  3). Allerdings kann es dennoch manchmal Situationen geben, wo eine Datenbank “steht”. Die Datenbank “steht” Das kann beispielsweise eintreten, wenn das Transaction Logfile einer Datenbank so groß wird, dass kein Platz mehr auf der Festplatte vorhanden ist – und die Datenbank nicht mehr funktioniert – zu mindestens alle Datenoperationen nicht mehr. SQL Server markiert dann die Datenbank oft als fehlerverdächtig (suspect). “Warum wächst ein Datenbank Logfile so stark?” Diese Frage haben sich schon viele Administratoren gestellt. Die Datenbank ist vielleicht winzig, aber das Logfile dazu wächst und wächst und wächst… die Analogie zur Duracell-Batterien Werbung drängt sich auf… Dazu möchte ich hier ein wenig Einblick geben und auch Lösungen liefern, vor allem, wenn Sie eine solche Fehlermeldung erhalten oder im Log finden: …failed with the following error: "The transaction log for database <dbname>' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases Aber schön der Reihe nach. Die Beteiligten Eine SQL Server Datenbank besteht immer aus (mindestens ) zwei Dateien: Einem Datenbank-File z.B. <dbname>.mdf und einem Transaction-Logfile <dbname>.ldf. Übrigens: Zusätzlich besitzt jedes File einen logischen Namen. Diese können mit select * from sys.database_files ausgelesen werden (hier z.B. “awCMS_Data” und “awCMS_Log”): Zurück zu unseren physischen Files: Das erste .mdf ist das primäre Datenbankfile. Bei großen Datenbanken kann es Sinn machten, die Daten auf mehrere Files (Filegroups) aufzuteilen – das bringt bei mehreren Laufwerken oft bessere Performance. Understanding Files and Filegroups und Files and Filegroups Architecture liefern übrigens die wichtigsten Informationen hierzu. Das Transaction Log Eine Funktion des SQL Servers ist, dass alle Datenbank-Aktionen zuerst in das Transaction-Logfile geschrieben werden und erst danach in das Datenbank-File. Die Daten aus dem Transaction Log werden erst durch eine COMMIT-Funktion in die Datenbank persistiert (dann, wenn die Datenbank-Transaktion vollständig ist). Daher stehen im Transactionlog also eigentlich nur “temporäre” Daten – eine Art Zwischenspeicher. Das Transaction Log wird in kleinere Segmente unterteilt, diese heißen “Virtual Logs”. SQL Server kümmert sich selbst um die Verwaltung des Transaction Logs. Nach dem Commit wird ein Checkpoint gesetzt und der verwendete Platz wird wieder freigegeben. Bereits gespeicherte Daten werden abgeschnitten (Truncated). Je nach Recovery Model und Größe und Auslastung der Datenbank kann die Größe des Transaction Logs allerdings wachsen (und zwar immer um ein Vielfaches eines Virtual Log Blocks). Transaktionen werden sequentiell geschrieben (siehe unten). Wenn der Platz begrenzt ist/das Ende erreicht ist, wird wieder am Anfang des Files fortgesetzt (Loop). Das Datenmodell Wichtig für den Betrieb und das Backup ist das gewählte Daten-Modell. Für jede Datenbank kann (in den Eigenschaften der Datenbank) das Recovery Model eingestellt werden, die Vorgabe ist “Full”. Diese SQL Abfrage liefert eine Übersicht über das Recovery Model aller Datenbanken: SELECT name, recovery_model_desc FROM sys.databases Ganz rasch: SIMPLE erfordert keine Log File Backups, FULL bietet höheren Schutz (Wiederherstellung) und erfordert Log File Backups. Das bedeutet, dass das Datenbank Recovery Model je nach Anforderung sorgsam gewählt werden sollte. msdn liefert in Recovery Model Overview alle Informationen hierzu. Bei Verwendung von FULL kann es also dazu kommen, dass das Transaction Log voll wird… Tipp: Damit das Transaction Log nicht die Festplatte vollschreibt, empfiehlt es sich, das Transaction Log File zu beschränken. Das funktioniert in den Datenbank-Eigenschaften durch Setzen der File-Größe. So sehen die Standard-Einstellungen aus: Und so wird die Restricted File Growth auf einen eigenen maximalen Wert gesetzt: Somit kann das Transaction Log für diese Datenbank nur bis 25MB wachsen. Beachten Sie, dass im Logfile genügend Platz für den laufenden Betrieb vorhanden ist! Hinweis: Wenn Sie Database Mirroring (mehr dazu in einem folgenden Blog-Artikel…) einsetzen, können Sie das Recovery Model SIMPLE NICHT einsetzen (sondern FULL). Tipp: Beachten Sie den Platzbedarf auch, wenn umfangreiche Datenbank-Operationen durchgeführt werden, beispielsweise wenn ein Maintenance Task alle Indizes in einer Datenbank erneuert…! Das kann leicht zu einem “Transaction Log is full” Fehler führen (so ist es auch bei einem Kunden passiert, als die Datenbank in der Nacht reorganisiert wurde - und am nächsten Tag in der Früh stand…) Transaction Log is full Wenn das Transaction Log voll ist verweigert SQL Server Abfragen und sogar Backups: Executing the query "BACKUP DATABASE..." failed with the following error: "The transaction log for database 'cms' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases BACKUP DATABASE is terminating abnormally… Was tun? Die Antwort ist zum Glück einfach: DBCC SQLPERF(logspace) zeigt, wie viel Platz IM Logfile verbraucht wird: In diesem Beispiel verwendet die Datenbank “cms” bereits 91% des verfügbaren Platzes. Ein Zeichen für einen möglichen Engpass. Wie reduziert man also die Transactions? Per BACKUP des Transaction Logs! BACKUP LOG [cms] TO DISK = N'D:\BACKUP\cms.trn' WITH NOFORMAT, INIT,  NAME = N'cms-Transaction Log  Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO So wird das Transaction Log in das Backupfile cms.trn geschrieben: Durch das Backup werden inaktive Transaktionen entfernt und das Transaction Log File somit wieder für Virtual Logs entleert. Visualisierung - Log Kontrolle Sehen wir nach dem Backup nochmals mit DBCC SQLPERF(logspace) nach: Fein, die CMS Datenbank benötigt jetzt nur mehr 21% Platz im Transaction Log File. Hat funktioniert! Weiters sehr hilfreich ist der TSQL-Befehl DBCC LOGINFO LogInfo zeigt an, welche Transactions in einer Datenbank (in einem Log File) vorhanden sind, welche committed sind (Status 0) und welche noch nicht committed sind (Status 2). Status 2 zeigt offene Transaktionen an: Die Spalte FSeqNo ist die laufende Transaktionsnummer – immer aufsteigend (sequentielles Schreiben), hier sind die Transaktionen 21990 und 21991 offen. Durch Ausführen von BACKUP LOG werden alle offenen Transaktionen geschlossen! Bei neuerlichem Ausführen danach dürfen eigentlich nur mehr neue (die letzten) Transaktionen mit Status 2 markiert sein. Wichtige Hinweise zum BACKUP Mit Full oder Bulk-Logged Recovery Mode bleiben inaktive Transaktionen im Logfile! Und zwar so lange, bis ein Checkpoint erstellt wurde und ein Backup des Transaction Logs durchgeführt wurde! Ein “Full Backup” entfernt also KEINE Transactions aus dem Transaction Log File, wie in diesem Beispiel: BACKUP DATABASE [cms] TO DISK = N'D:\Backup\cms.bak' WITH NOFORMAT, INIT, NAME = N'Vollstaendig Datenbank Sicherung', SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO Ein Transaction Log Backup gibt zuvor benutzen Platz wieder frei, verkleinert das File aber NICHT, wie in diesem Beispiel: BACKUP LOG [cms] TO DISK = N'D:\BACKUP\cms.trn' WITH NOFORMAT, INIT,  NAME = N'cms-Transaction Log  Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO Shrink File Und es geht doch: Um ein Transaction Log File zu verkleinern, verwenden Sie in der aktuellen Datenbank: SELECT name FROM sys.database_files WHERE type_desc = 'LOG' Und nun den logischen Dateinamen (in meinem Beispiel “awcms_log”) in ShrinkFile einsetzen: DBCC SHRINKFILE ('awcms_log', 1000) Setzt bzw. reduziert die physische Größe des Log Files auf 1GB. Zur Vollständigkeit: Um unbenutzten Platz in Daten-Files freizugeben kann ShrinkDatabase verwendet werden: DBCC SHRINKDATABASE ('cms', TRUNCATEONLY) Hiermit wird der freie Platz am File-Ende freigegeben, aber das File nicht reorganisiert - siehe auch DBCC SHRINKDATABASE (Transact-SQL). z.B.: Achtung:  Die Datenbank sollte NICHT auf Auto-Shrink gesetzt sein, da bei kontinuierlichem Verkleinern durch starke Defragmentierung Performance-Probleme auftreten können! AutoShrink sollte also FALSE sein, so wie hier:   Wie vorbeugen? Nachdem wir nun reagieren können, stellt sich die Frage, wie man vorbeugen kann, damit dieser Fall nicht eintritt. Gut ist, bei Verwendung von Recovery Model FULL die Datenbank komplett zu sichern und danach das Transaction Log extra zu sichern. Damit wird das Transaction Log File verkleinert und kann wieder neu befüllt werden. Tipp: Bei Bedarf (bei großen Datenbanken mit vielen Transaktionen) empfehle ich, stündliche oder minütliche Backups des Transaction Logs – das bringt auch eine gute Sicherheit, da die Datenbank so leicht zu einem beliebigen Zeitpunkt (zu jedem Zeitpunkt, wo ein Transaction Log gesichert wurde) wiederherstellbar ist. Ein Backup-Verzeichnis eines Tages könnte also sinngemäß so aussehen: cms.bak cms_1.trn cms_2.trn cms_3.trn cms_4.trn Der Vorteil: Restore zu jedem der fünf Zeitpunkte und ein kleines operatives Log File. Tipp: Unbedingt beachten, dass Transaction Log auch VOR und NACH Reorganisations-Tasks (wie Index Rebuild) durchgeführt werden sollten – vor allem, wenn die File Size mit einem eigenen Wert auf restricted gesetzt ist (oder der Festplattenplatz eng ist). Damit sollte der “Transaction Log is full” Fehler der Vergangenheit angehören und Sie das Handwerkszeug zum Beheben und Warten von Transaction Log Files besitzen. Über SQL Server Wartung gibt es noch viel zu sagen und zu berichten – stay tuned.

SharePoint virtuell

Für alle Admins, Developer und SharePoint Experten: Für die Planung und den Betrieb von SharePoint in virtuellen Umgebungen - und das macht fast immer Sinn - gibt es viel zu wissen. Dazu möchte ich auf diese TechNet-Website hinweisen: http://technet.microsoft.com/en-us/sharepoint/ff602849.aspx Hier finden Sie Unterstützung und Lizenzierungsinformationen für die Verwendung von Server-Virtualisierungstechnologien für SharePoint. Reinschaun!

Wenn in SQL Server sogar bei varchar(max) bei 8000 Zeichen Schluss ist...

Microsofts SQL Server ist fast in jedem Microsoft (Server) Produkt drin. Und auch mein Lieblings-Produkt. So habe ich im Laufe meines Berufslebens bereits von SQL Server 6.5 bis hin zum aktuellen SQL Server 2008 R2 viel Datenbank-Wartung durchgeführt und viele Lösungen entwickelt. Hierbei lernt man viel - und auch viele Stolpersteine! So hatte ich vor kurzem die Anforderung, eine Reihe von SQL Server Reports neu zu generieren. Dazu habe ich mal vor einigen Jahren ein kleines Tool geschrieben, das eine XML Datei durchläuft und alle dort enthaltenen Reports mit bestimmten Parametern als PDF File persistiert - das soll weiterverwendet werden. Nun haben sich die Reports und deren Parameter geändert und eigentlich muss ich zum Neuaufruf nur das reports.xml File neu erstellen und das Tool (sozusagen per Knopfdruck) starten und alles sollte erledigt sein. Soweit so gut, das war die Vorgeschichte. Zum Generieren des neuen XML-Files verwende ich eine einfaches, zusammengebautes Script (das ich mir zum Glück aus dem Vorjahr gemerkt habe) direkt im SQL Server 2008 R2 SQL Management Studio. Dieses durchläuft eine gejointe Tabelle und schreibt den Output in eine Textvariable @x. Das ganze Script sieht vereinfacht etwa so aus: declare @x varchar(max) set @x = '<?xml version="1.0" encoding="ISO-8859-1"?>' + char(13) + char(10) + '<reports>' + char(13) + char(10) SELECT @x = @x + '<report>' + char(13)+char(10)+ '<name>/app/betrieb</name>' + char(13)+char(10)+ '<param>format=PDF|id=' + convert(varchar,BET_ID) + '</param>' + char(13) + char(10)+ '<path>C:\temp\betrieb_'+ right('00' + convert(varchar,(ROW_NUMBER() OVER (ORDER BY Name1))),2) + '.pdf</path>' + char(13) + char(10)+ '</report>' + char(13) + char(10) FROM Betriebe LEFT OUTER JOIN Bundeslaender ON BET_BDL_ID = Bundeslaender.BDL_ID WHERE (BetriebActive = 1) ORDER BY Bundesland, Name1 set @x = @x + '</reports>' + char(13)+char(10) print @x Der so erzeugte Text in @x wird dann einfach aus dem SQL Management Studio ausgeführt (F5) und ausgegeben, für jede Tabellenzeile (bei mir etwa 30 Reports) wird ein Abschnitt "<report>" erstellt, etwa so: Der Text in Messages wird dann per Zwischenablage in ein Textfile kopiert - bzw. wird die Ausgabe direkt in ein File geschrieben "Results to File": Funktioniert ... fast!  Der Output wird irgendwo abgeschnitten! Moment mal, unsere Variable @x ist doch vom Typ varchar(max)! Damit sind doch theoretisch bis zu 2GB Zeicheninhalt möglich. Also mal nachsehen, wie lange @x tatsächlich ist: print len(@x) ergibt sportliche 10655 Zeichen. Die Variable beinhaltet also den tatsächlichen Inhalt - nur wird der abgeschnitten... eine leise Vorahnung (eigentlich ein Rückblick) kommt auf... Seit SQL Server 2005 gibt es die Aufhebung der 8000-Zeichen Grenze bei Texten vom Datentyp Zeichen: Konkret war bis SQL Server 2000 aufgrund der internen Data Page-Größen bei 4000 Zeichen für nvarchar und bei 8000 Zeichen bei varchar Schluss. Nun kann stattdessen varchar(MAX) bis 2^31-1 Bytes (also fast 2GB) verwendet werden. Damit können ab SQL 2005 auch Zeichenkettenoperationen mit längeren Texten durchgeführt werden - ohne mühsame Workarounds mit Konvertierungsfunktionen und Datentyp TEXT. Die Ursache für das Abschneiden ist also das PRINT Statement. PRINT schneidet bei 8000 Zeichen ab! Print ist ja sehr praktisch. Nur hat Microsoft anscheinend vergessen, die neuen Grenzen ab SQL Server 2005 nachzuziehen? Natürlich dachte ich zuerst an die Optionen im SQL Management Studio, wo die Limits der Ausgabe eingestellt werden kann. Aber nein, das ist es nicht. Und ich könnte natürlich Zwischenschritte einlegen oder das Problem anders lösen ... aber nur weil Print die Ausgabe abschneidet alles umstellen?? Aber es gibt eine einfache Abhilfe: In diesem Blog-Artikel von Falafel Software von Adam Anderson wird eine kleine Stored Procedure "LongPrint" in nur insgesamt 26 Zeilen erstellt, welche einen langen String auf mehrere Teile á 4000 Zeichen vom Typ nvarchar aufteilt und schrittweise ausgibt: T-SQL: Exceeding the 8000 Byte Limit of the PRINT Statement Zur Anzeige des ganzen Scripts folgen Sie einfach dem Link oder klicken Sie auf dieses Bild: Eine einfache Lösung: 1. Einmaliges Ausführen des LongPrint() Scripts in der eigenen Datenbank und danach 2. statt im eigenen Script PRINT @x zu verwenden, einfach exec LongPrint @x angeben. So klappts mit langen Strings mit mehr als 8000 (bzw. 4000) Zeichen - ohne dass die bestehende Funktionalität umgebaut werden muss! Ein netter, kleiner Workaround bis sich Microsoft hoffentlich diesem Problem annimmt und das Limit von PRINT - vielleicht mit der nächsten SQL Server Version "Denali" (2012?) - behebt.