atwork.blog

news and infos about microsoft, technology, cloud and more

Microsoft SQL Server "Denali" in Amazon Cloud

Wenn man dem Artikel "New Deal Allows SQL to Run in Amazon Cloud" Glauben schenken kann, wird Microsoft seinen neuesten SQL Server Codename Denali in der Amazon Elastic Compute Cloud (EC2) anbieten. Laut Artikel stellt Microsoft Amazon Machine Images (AMI) zur Nutzung bereit. Die Kosten sollen von 12 bis 96 USD Cents pro Rechenstunde sein. Mal sehen!

WebMatrix 2 Beta zum Download verfügbar

Eigentlich noch recht frisch ist Microsofts Web Developer Tool WebMatrix in Erinnerung - Version 1 (akt. v7.1) wurde im Winter 2010 veröffentlicht und erfreut sich bei Web-Developern großer Beliebtheit. Nun - ganz frisch - wurde WebMatrix Version 2 Beta auf http://www.microsoft.com/web/webmatrix/betafeatures.aspx veröffentlicht (erste Infos dazu gab es schon in den ASPNET-Announcements hier). WebMatrix ist ein freies Tool für Webentwickler mit Unterstützung von ASP.NET und weiterer Script-Sprachen und enthält (nach wie vor) IIS Express zum raschen und einfachen Testen und Debuggen von Website-Projekten (inkl. eigenem Test-Zertfikat für HTTPS). Vor allem fertige, freie Software-Projekte wie DotNetNuke, Umbraco, Drupal, Blogengine.net aber auch Joomla oder WordPress Pakete können sozusagen per Mausklick installiert und ausprobiert werden. Was ist neu? Die Beta-Version von WebMatrix enthält jetzt den Package-Manager NuGet sowie zusätzliche Erweiterungen. Neu ist auch IntelliSense für .NET, PHP (!), HTML 5, CSS 3 und JavaScript - für alle Webentwickler wohl eine der wichtigsten Programmierhilfen! Die mitinstallierte SQL Server Compact Edition wurde auf die kommende SQL-Server-Version (Codenamen Denali) aktualisiert. Version 2 Beta ist noch benutzerfreundlicher geworden, so kann WebMatrix beispielsweise auch Datenbank-Logins generieren, um den Installationsprozess noch einfacher und rascher durchzuführen. WebMatrix unterstützt eine Reihe von Technologien:     Wichtig: WebMatrix 2 Beta Readme informiert über Kompatibilität und bekannte Funktionseinschränkungen in der Beta-Version. So läuft die Beta auch unter der nagelneuen Windows 8 Developer Preview Version, aber nicht mit IE10 - daher am besten vor der Installation ReadMe (list of common known issues with WebMatrix 2 Beta) durchschauen. Hier gehts zum Download und zur Liste der neuen Funktionen: http://www.microsoft.com/web/webmatrix/betafeatures.aspx Viel Spaß beim Testen!

Advanced SQL Server Performance Troubleshooting Workshop im September

Sommerzeit ist Urlaubszeit - jedenfalls für die meisten. Frisch aufgetankt beginnen die Projekte dann im September wieder zu laufen... Für SQL Administratoren und Developer möchte ich auf diese wichtigen Events hinweisen: Die SQL Server User Group Austria veranstaltet regelmäßige Treffen für SQL-IT Pros und Developer bei Microsoft in Wien, siehe auch SQL Server User Group Austria in Facebook sowie Ankündigungen hier im TechNet Blog. Im September veranstaltet SQL-Guru Klaus Aschenbrenner den Advanced SQL Server Performance Troubleshooting Workshop von 26. - 28. September in Wien. Klaus beschäftigt sich sehr intensiv mit den Bits und Bytes und der Funktionsweise des SQL Server Systems und ist anerkannter SQL Server Experte und internationaler Konferenzsprecher. Der Workshop findet übrigens auch von 12 bis 14. September in London statt, weitere Events sind geplant: csharp.at/Events.html Der Workshop befasst sich u.a. mit diesen Themen: SQL Server Performance Monitoring Methologoy Troubleshooting Locking, Blocking, Deadlocking, Latching Troubleshooting TempDb, IO sub systems, Parallel Execution Plans Advanced SQL Server Troubleshooting Techniques Crash Dump Debugging, Ring Buffer Troubleshooting, Extended Events Erfahren Sie im Workshop alle Methoden und Tools, um die Leistung Ihrer SQL Server zu steigern und Problemen vorzubeugen. Viel Spaß!

System Center Advisor einrichten Teil 3-Troubleshooting

Das Entfernen von Atlanta-Diensten (Teil 1) und Installieren des SC Advisor RC (Teil 2) funktioniert ja recht einfach. Üblicherweise läuft der Setup-Prozess ganz nach dem Motto Next-Next-Finish und reportet dann in die Cloud-Dienste. Dennoch gab es auch in meiner Installation einen Stolperstein: Das Installieren des Gateways auf dem vorgesehenen Rechner hat nicht funktioniert und das Setup verweigerte die Installation. Bevor ich zur Lösung (bzw. zum Workaround) komme, hier die Situation und der Weg der Analyse: Es sollte im Setup das Gateway installiert werden: Kurz vor dem Ende der Installation folgte jedoch ein Fehler beim Konfigurieren des Gateways: "Setup encountered an error configuring the gateway." Setup führt dann ein Rollback aus - und deinstalliert alles. Der Neustart (zuvor wurden die Atlanta-Dienst auf dieser Maschine deinstalliert) und das neuerliche Aufrufen des Setups brachte das erwartete Ergebnis: Keine Änderung. Der Assistent ist ja sehr einfach - und bietet andrerseits aber auch keinerlei tiefgreifende Einstellungsmöglichkeiten. Also: Wo den Fehler suchen? Als alter Windows Hase ist natürlich das Eventlog die erste Anlaufstelle: Ja, hier steht der Fehler - allerdings ohne konkreten Hinweis (es sei denn, man kann mit einer ewig langen Hex-Zahl etwas anfangen...). Gut. Also befragt man die Suchmaschine(n) seiner Wahl. Die Suche nach "System Center Advisor" "Setup encountered an error configuring the gateway" lieferte bei mir allerdings - raten Sie mal - keine Treffer. Erst beim Entfernen der Quotes kamen ein paar Ergebnisse - von anderen Systemen. Allerdings bin ich dennoch auf eine sehr wichtige Seite zu SC Advisor gestoßen: Advisor Deployment Troubleshooting Hier findet sich u.a. die grundsätzliche Empfehlung, in das Installations-Logfile zu sehen - immer eine gute Idee! Um den temporären Installationspfad rasch herauszubekommen, empfiehlt es sich, die %temp%-Variable des Betriebssystems auszulesen: Und dann in dieses Verzeichnis zu wechseln. In meinem Fall: C:\Users\Administrator\AppData\Local\Temp\2 Dann öffnen wir mal das Logfile AdvisorSetupMSILog_6344*.txt und schauen uns hier ein wenig um und ... suchen nach "error". In meinen Fall war es zum Glück einfach herauszufinden, und zwar in dieser Zeile ziemlich am Ende des Logs: MSI (c) (30:18) [13:28:12:044]: Windows Installer installed the product. Product Name: Microsoft System Center Advisor. Product Version: 1.0.1376.0. Product Language: 1033. Manufacturer: Microsoft Corporation. Installation success or error status: 1603. Product Language: 1033 steht für "Englisch". Deutsch hat den Code 1031. Ahja. Ich habe die Installation auf einem deutschen Windows Server 2008 R2 versucht. Das wird wohl das Problem des Setups gewesen sein - ok, es ist auch noch ein Release Candidate (erstaunlich, denn die Beta hat auf dieser Maschine funktioniert, aber neue Version neuer Build...). Kurzum: Die Installation des SC Advisor Gateways auf einem englischen Windows Server hat dann bestens funktioniert! In meinem Testszenario läuft nun das Gateway auf einem englischen Server und die restlichen zu überwachenden Maschinen können auch deutsch sein - beim Agent ist das kein Problem - gelöst. Alternativ könnte man sich natürlich noch weiter spielen, aber für eine RC-Version ist das für mich so ok. Nachdem dieses Problem gelöst war, lief das Setup und die Kommunikation einwandfrei. Apropos einwandfrei: Es gibt noch einige Tipps zur Konfiguration des SC Advisors, ich habe die wichtigsten hier zusammengefasst: Das Gateway kann auch später installiert werden: Manage Gateway Registration Gateway und Agent können auch im Nachhinein über Registry Settings in HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCenterAdvisor\Gateway konfiguriert (und fein-getuned) werden, siehe Configure the Gateway and Agent. Hinweise für die Automatisierung: Deploy System Center Advisor Praktisch: Install the Gateway and Agent from the Command Line Firewall: Für das Gateway müssen die Ports 80 und 443 offen sein, siehe Firewall Information for System Center Advisor In diesem Sinne wünsche ich gutes Gelingen beim Installieren, Konfigurieren und Testen des System Center Advisors!

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!

Microsoft Atlanta wird zu System Center Advisor

Nach dem angekündigten Update von Microsoft Atlanta (siehe SQL going to the cloud, äh to Atlanta) präsentiert sich das Online-Tool im Status "Beta" nun als neue Marke "System Center Advisor" und ist liegt jetzt schon in der Version "Release Candidate" vor. Die neue URL lautet www.systemcenteradvisor.com. Was ist neu? Nun, eine ganze Menge! System Center Advisor kann jetzt neben SQL Server Instanzen auch Windows Server 2008 Maschinen, Hyper-V Hosts und Active Directory analysieren und überwachen! Morgen wird übrigens Windows InTune veröffentlicht, welches die Überwachung von Client-Maschinen in der Cloud ermöglicht - übrigens auch ein Tipp für alle Big>Days 2011 Teilnehmer: InTune ansehen! System Center Advisor kann also als (eine von vielen) Ergänzung für die Windows Server Maschinen gesehen werden. Neu ist auch der Multi-User Support: Verschiedene Windows Live Konten können zu einem Firmen-Konto zugeordnet werden und es gibt nun E-Mail Notifikationen (das haben wir ja schon beim letzten Mal hier bemerkt), um wöchentliche E-Mails mit Zusammenfassungen des Health Status und Warnungen mitzubekommen. Das Bearbeiten von Warnung wurde verbessert: "Advisor now detects when you have addressed the issue that generated an alert and automatically resolves the associated alert." Letztlich unterstützt System Center Advisor jetzt auch SQL Server Clustering und informiert über Aktiv-Passiv Rollenwechsel. Eine Liste aller Neuerungen finden Sie hier: What's New in This Release of System Center Advisor? Für alle Beta-Tester: Bestehende Atlanta Konten bleiben bestehen und sind funktionell. Die Agents auf den überwachten Servern müssen allerdings - ob der neuen Datensammlungsfunktionen - neu installiert werden. Upgrade from a Pre-Release Version of System Center Advisor informiert über den Prozess eines Upgrades. Ich freue mich über das neue Online Tool in der Cloud, das mir helfen wird, meine Windows Server 2008 und meine Hyper-V Instanzen und Workloads zu überwachen! Wir werden jetzt einmal unsere bestehende Maschinen mit den Beta-Agents aktualisieren um Ihnen bald einen Praxisbericht hier zu veröffentlichen!

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.

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.

Neu: Web Platform Installer 3.0

Ganz frisch: Der neue Web Platform Installer 3.0 (Version 7.1.1042.1 vom 13.01.2011) ist verfügbar! www.microsoft.com/web/downloads/platform.aspx Für alle, die Web PI noch nicht kennen: “Der kostenfrei angebotene Web Platform Installer Version 3.0 (Web PI) hilft Ihnen, immer die aktuellen Komponenten der Microsoft Web Plattform herunterzuladen und einzusetzen. Dazu gehören Internet Information Services (IIS), SQL Server Express, das .NET Framework und Visual Web Developer. Zusätzlich installieren Sie damit weit verbreitete, beliebte Open Source-, ASP.NET- und PHP-Webanwendungen.” Für Agenturen, Web Developer, IT-Administratoren und Hoster ein Must Have. Web PI 3.0 (und viel mehr) zeigen wir übrigens auch live auf der xtopia 2011! Web Platform Installer 3.0 läuft unter allen Windows Versionen ab Windows XP SP2 und ab Windows Server 2003 SP1. Der Download ist nur 92KB klein, d.h. die zu installierenden Pakete werden natürlich bei Bedarf aus dem Internet nachgeladen. www.microsoft.com/web ist übrigens ein guter Startpunkt für Web-Hoster. So sieht Web PI nach der Installation aus: Gewünschte Pakete werden einfach hinzugefügt und installiert. Nach der Installation: Simple as click! Achja, neben dem Web PI wurden eine ganze Reihe weitere Development-Produkte wie ASP.NET MVC 3, IIS Express, SQL CE 4, Web Farm Framework, Orchard und WebMatrix veröffentlicht – aber das ist eine weitere Geschichte. Viel Spaß mit der Microsoft Web Plattform und beim Ausprobieren der vielen neuen Click-and-Run Weblösungen aus dem Web Platform Installer 3!

atwork auf der xtopia 2011

Unter dem Motto „Kreativität, Inspiration, Ideen“ wird das kommende Microsoft Event xtopia 11 spannende Web-Projekte, Produkt-News sowie Geschäfts-Möglichkeiten vorstellen. auf der xtopia ist das Event für Web-Agenturen und Hoster und findet am 1. Februar 2010 in Wien statt. Der Eintritt ist frei. Wir von atwork freuen uns, auf der xtopia 11 – wie schon im Vorjahr – zwei Sessions für Sie zu präsentieren! In unseren Projekte befassen wir uns ständig mit neuen Webtechnologien und –möglichkeiten. Diese stellen wir Ihnen am Event vor: In unserem Track “HTML 5 und jQuery - das neue Flash?” für Web-Developer berichten wir über diese brandaktuellen Technologien, wie man sie einsetzt, ihre Vorzüge und demonstrieren dies anhand vieler Beispiele aus unserer Praxis. Unsere Session “Die Microsoft Web Platform aus Business Sicht” richtet sich an Entscheider und Web-Developer und zeigt, welche Vorteile Sie mit ASP.NET, SQL Server und IIS Webserver erhalten, aber auch wie Sie “fremde” Systeme auf Ihre eigene Plattform übernehmen können. Nebenbei werden wir viele Praxisbeispiele zeigen und Ihnen Informationen aus unserer jahrelangen Erfahrung in Entwicklung und Hosting liefern. Und zum Austauschen und Netzwerken ist ebenso viel Zeit! Lassen Sie sich vom innovativen Design des neuen BENE Showrooms inspirieren und besuchen Sie uns auf der xtopia 11! Melden Sie sich jetzt gleich an – die Plätze sind begrenzt! Wir freuen uns! CU there!

Microsoft Codename Atlanta - SQL Monitoring Teil Drei

Nach “Microsoft Codename Atlanta – SQL Monitoring Teil Zwei” folgt Teil Drei. Zuvor wurde Atlanta eingerichtet (Teil 1) und eine SQL Server 2008 Maschine mit Atlanta verbunden – sprich auf jeder zu überwachenden SQL Maschine ein Agent (und ein Gateway – für alle Agents) für das Cloud Service installiert. Jetzt geht es um Bedienung und Betrieb. Die Oberfläche Microsoft Atlanta ist mit der konfigurierten Live-ID via https://beta.microsoftatlanta.com/ aufrufbar und präsentiert sich nach der Anmeldung so: Die Navigationsleiste links zeigt die Übersicht, hier die Darstellung und Kurzbeschreibung der einzelnen Menüs: Alerts: Anzeige von gemeldeten Alarmen. Configuration - Current Snapshot: Anzeige der überwachten SQL Server mit ihren Eigenschaften. Configuration - Change History: Anzeige von historischen gesammelten Daten der überwachten Computer. Servers: Anzeige und Verwaltung der verbundenen Gateways und Agents. Account – Anzeige und Verwaltung des angemeldeten, verbundenen Live-Kontos. Hinweis:  Wenn der Button “Copy to Clipboard” sichtbar ist: Dieser dient dazu (da ja eine Silverlight Applikation) die aktuell markierte Zeile (mit Tabulatoren getrennt) in die Zwischenablage zu kopieren, z.B.: Change Date    Server    Path    Class    Property    Update Value    Previous Value    28.12.2010 19:35:48    Minni3.atwork.local    /    Windows Computer    IPAddress        <no value>    Soviel zur Übersicht – noch recht überschaubar. Der Betrieb Atlanta sammelt Daten von den verbunden SQL Server 2008 Maschinen. Das kann nach der Installation einige Zeit (Stunden) dauern. Keine Sorge, wenn Sie nach der Installation die installierten Agents und Gateways sehen, dann klappt die Kommunikation und man muss nur ein bisschen warten… Die Configuration ist interessant – zeigt sie doch die Einstellungen der Windows Maschine und der einzelnen Datenbanken an, so zum Beispiel das Recovery Model, den Compatibility Level und weitere Datenbank-Eigenschaften, wie hier von der Master-Datenbank: Die Configuration History lässt nachverfolgen, wann was auf der Datenbank-Maschine passiert ist, hier wurde zum Beispiel die Datenbank AtlantaTest angelegt – und alles mitprotokolliert. Es gibt keine weiteren Details (Anklicken markiert nur die Zeile, Rechtsklick bringt das bekannte Silverlight-Menü), alle Informationen sind in einzelnen Datenzeilen verfügbar. Hier erweist sich die Suche (rechts oben) als praktische Funktion um ganz bestimmte Informationen zu finden. Der Wert von Atlanta Neben der Konfiguration zeigt Microsoft Atlanta den Mehrwert in den Alerts. Hier werden Warnungen und Empfehlungen mit Details angezeigt: Zum Beispiel KB-Updates oder anstehende Datenbank-Wartungen wie fehlende Backups, Konsistenzchecks und Ähnliches. Atlanta geht nicht soweit wie beispielsweise der SQL Database Tuning Advisor oder SQL Server 2008 R2 Best Practice Analyzer, sondern bezieht sich mehr auf die Datenbanken selbst und deren reibungsglosen Betrieb. Hier einige Alerts: Eine (neue) Datebank wurde noch nie gebackupt. Für den reibungslosen Betrieb der TempDB Datenbank sollte KB960770 eingespielt werden. In der Datenbank sollte CHECKDB ausgeführt werden… Was sehr praktisch ist: Der Tab “Solution” weist auch gleich auf die Lösung hin, in diesem letzten Beispiel ein Link zu http://support.microsoft.com/kb/2033590. Es werden keine Alerts versendet – das wäre bei der durchschnittlichen, zu erwartenden Menge an Meldungen wohl auch etwas viel. Der Admin muss also Atlanta aufrufen und die Warnungen durchsehen und entscheiden, welche davon bearbeitet werden und welche nicht. Gelöste Alerts werden in Zukunft einfach nicht mehr angezeigt, also sehr simpel. Fazit Atlanta ist ein übersichtliches, einfaches Tool um mehrere SQL Server 2008 zu überwachen. Vorsorge und optimales Tuning sind immer besser als nachträgliches Suchen und Beheben von Problemen, genau das ist der Zweck von Atlanta. IT-und Datenbank-Administratoren erhalten damit ein Hilfsmittel “in the cloud” zur Wartung von Microsoft SQL Datenbank-Servern. Derzeit ist Atlanta eine Beta-Version. Es werden wohl noch einige weitere Funktionen und Verbesserungen hinzukommen. Wenn es soweit ist, werden wir wieder darüber berichten. Bis dahin: Viel Spaß beim Ausprobieren des neuen SQL Monitorings mit Atlanta Cloud Services!