blog.atwork.at

news and know-how about microsoft, technology, cloud and more.

SQL Azure Migration Wizard v3.8

Wednesday, December 14, 2011 7:15 AM Toni Pohl
...ist ganz frisch auf codeplex eingetroffen! Mike hat gestern bereits in "Azure Dezember Enhancements und SDK Downloads" auf neue Tools für Windows Azure hingewiesen. Der SQL Azure Migration Wizard wurde ebenfalls aktualisiert: Wofür ist der Wizard? "SQL Azure Migration Wizard (SQLAzureMW) is an open source application that has been used by thousands of people to migrate their SQL database to and from SQL Azure.", siehe sqlazuremw.codeplex.com. Aktuell ist Verion 3.8 vom 13. Dezember, hier geht´s direkt zum Download. Hinweis: "SQLAzureMW and tools requires SQL Server 2008 R2 SP1 bits to run." Für alle, die SQL Azure noch nicht getestet haben, findet sich in "Erstellen einer Cloud-Anwendung mit Datenzugriff mithilfe von SQL Azure" ein 12-Minuten Video, welches die Vorgangsweise (ohne Wizard) zeigt - ein guter Einstieg. Viel Erfolg beim Migrieren der eigenen SQL Datenbanken in SQL Azure!
Azure | Cloud | Developer | Microsoft | Tools | SQL Server
mehr

SQL Server 2012 Release Candidate ist downloadbar

Friday, November 18, 2011 4:45 PM Toni Pohl
"Denali" RC0 - sprich: Microsoft SQL Server 2012 Release Candidate - ist seit heute im Microsoft Download Center verfügbar, so schreibt das SQL Server Team im SQL Server Team Blog. Die neue Version des Datenbanksystems kombiniert Business Intelligence und Data Warehousing mit der Cloud und bringt zentrale Neuerungen im Bereich Enterprise Datenbanken. Hier gehts zum Download des 4GB ISO Files. Die Bits sind in den "main languages" verfügbar. Download Microsoft SQL Server 2012 Release Candidate 0 (RC0) Weitere Neuerungen im Überblick gibt es auch auf der Microsoft SQl Server 2012 Product Homepage. Die finale Version kommt ... bald!
Developer | SQL Server | Microsoft | Cloud
mehr

Microsoft SQL Server "Denali" in Amazon Cloud

Thursday, November 3, 2011 10:45 PM Toni Pohl
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!
Cloud | Developer | SQL Server | Blog
mehr

WebMatrix 2 Beta zum Download verfügbar

Wednesday, September 28, 2011 5:45 AM Toni Pohl
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!
Developer | Microsoft | Tools | Cloud | SQL Server
mehr

Advanced SQL Server Performance Troubleshooting Workshop im September

Tuesday, July 26, 2011 5:30 PM Toni Pohl
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ß!
General | Microsoft | SQL Server | Event | Developer
mehr

System Center Advisor einrichten Teil 3-Troubleshooting

Tuesday, May 17, 2011 5:25 PM Toni Pohl
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!
Developer | Microsoft | Windows | Cloud | SQL Server | Tools
mehr

System Center Advisor einrichten Teil 2

Monday, May 16, 2011 6:35 PM Toni Pohl
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...!
Microsoft | SQL Server | Windows | Tools | Cloud | Developer
mehr

System Center Advisor einrichten Teil 1

Monday, May 16, 2011 8:05 AM Toni Pohl
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!
Cloud | Developer | Microsoft | Office365 | Windows | SQL Server | Tools
mehr

Microsoft Atlanta wird zu System Center Advisor

Wednesday, March 23, 2011 9:15 AM Toni Pohl
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!
Microsoft | Office365 | SQL Server | Windows | Tools | Cloud | Hyper-V
mehr

SQL Server: The transaction log for database is full

Tuesday, March 8, 2011 3:33 PM Toni Pohl
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.
Developer | Microsoft | SQL Server
mehr

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

Tuesday, February 22, 2011 8:25 AM Toni Pohl
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.
SQL Server | Tools | Developer
mehr

Neu: Web Platform Installer 3.0

Saturday, January 15, 2011 12:00 PM Toni Pohl
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!
Developer | Microsoft | SQL Server | Windows
mehr