blog.atwork.at

news and infos about microsoft, technology, cloud and more

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!

Microsoft Codename Atlanta – SQL Monitoring Teil Zwei

Wie Martina bereits in ”SQL going to the cloud, äh to Atlanta“ gebloggt hat folgt hier nun Praxis Teil Zwei. Zur Erinnerung an den hübschen Codenamen: Was kann “Atlanta”? Das beschreibt am besten dieser Satz: "Microsoft Atlanta is a secure configuration monitoring cloud service that helps customers reduce downtime and improve the performance of Microsoft SQL Server deployments." Sprich: Überwachung von SQL Diensten in der Cloud. Der aktuelle Status ist Beta, bin auch schon gespannt wie der Release-Name sein wird, ob der Dienst in Office 365 oder Windows Intune einfließen wird… Hier finden Sie übrigens die Atlanta System Requirements – nichts “Besonderes” (Windows 2008, SQL Server 2008, aktueller Browser, Silverlight…), aber vor der Installation prüfen! Nachdem https://www.microsoftatlanta.com/ aufgerufen wurde und mit dem eigenen Live-Konto verknüpft wurde (Teil 1), folgt die Installation von Atlanta (CTP) auf einem zu überwachenden SQL Server 2008. Nebenbei: Es sieht so aus, dass nur EIN Live Konto hinterlegt werden kann – frei nach dem Motto: Es kann nur EINEN (Administrator) geben. Tatsächlich kann es aber MEHRERE Admins geben. Die Anleitung dazu findet sich hier: Multiple user access Zur Fortsetzung: Nach Anmeldung ist unsere hübsche Silverlight-Console offen. Jetzt müssen die Clients mit Atlanta-Diensten versehen werden: Das Klicken auf “hier” (wie auch das Hinzufügen von neuen Servern “Add Server…” in der Oberfläche) bringt diesen (bereits bekannten) Dialog. So funktioniert es also: Man benötigt mindestens EIN Gateway mit Verbindung zum Internet (zum Senden der Daten an das Cloud-Service). Es können mehrere Agents über ein Gateway senden. Clever. Nun werden die erforderlichen beiden Files heruntergeladen (und auf einen Netzwerk-Share kopiert). Danach wird auf der SQL-Server 2008 Maschine “AtlantaSetup.exe” gestartet: Es folgt ein Consolen-Setup mit Auswahl, ob Agent, Gateway oder Beide Komponenten auf der Maschine installiert werden sollen (das wird dann später in der Release wohl ein grafisches Setup sein): Also installieren wir mal “3. Both”: Tja, “3. Both” funktioniert bei mir leider nicht: “Error code is 1.” Die Ursache dafür: Auf meiner SQL Maschine klappt die Installation des Atlanta-Agents nicht … weil dieser Produktiv-SQL Server mit dem DPM Agent gesichert wird – der DPM Agent verträgt sich NICHT mit Atlanta Beta Agent! Siehe hier: Microsoft Codename Atlanta Release Notes …Because of this, Atlanta is not compatible with the Operations Manager 2007 SP1 agent, which is down-level. When you install an Atlanta agent on the same computer as an Operations Manager 2007 SP1 agent, Atlanta attempts to upgrade the existing agent to the new version. However, this attempt will fail and the Atlanta agent will not work. Ok, die Recherche war es wert, eine wichtige Information! Also testen wir das mal mit einer ANDEREN SQL Server 2008 R2 Maschine (ohne DPM Agent) nochmals und versuchen hier “3. Both”…. Schaut besser aus, das grafische Setup wird gestartet: Nach Akzeptieren der Lizenzvereinbarung wird das heruntergeladene Zertifikat angegeben und Next: …bis das Setup fertig ist (Finish), Das Fenster schließt sich, das Command Prompt zeigt den Erfolg an: Fein, refreshen wir mal die Web-Anwendung. Links in der Silverlight-Anwendung auf das Icon “Servers” zeigt das Ergebnis: Die neue SQL Maschine; insgesamt: “1 agents, 1 gateway”: Achja: Der Agent funktioniert auch mit SQL Server 2008 Express – das ist meine Testmaschine für obiges Szenario! So, was zeigt Atlanta? Schauen wir mal in die Configuration: Diese zeigt Informationen über den gewählten SQL Server: Fein, das Reporting der Installation hat mal geklappt. Jetzt müssen nur noch Daten gesammelt werden… Hier einige wichtige Links zu Atlanta: https://www.microsoftatlanta.com/ – Die Atlanta Web-Oberfläche. Microsoft Codename Atlanta – Die Website zum Produkt. SQL going to the cloud, äh to Atlanta  - Teil 1: Die Anmeldung Mehr zur Installation von Agents and Gateways. Varun Dhawan's Blog: Microsoft Codename Atlanta: How to get in there… Multiple user access – How To von Sachin Agrawal (Microsoft) Microsoft Project Atlanta Discussions – das Forum. Mehr zum Betrieb dann in Teil Drei!

SQL Server–Problem mit SP2 Update (sqlagent100_msdb_upgrade.sql encountered error 598)

SQL Server kann viel. So viel, dass manchmal auch Fehler zustande kommen können, wo man zunächst an nichts Böses denkt … und dann kommt es doch anders. Bei Web-Hostern äußerst beliebt ist die freie SQL Server Express Edition, die ist gratis, schlank, reicht für Web-Anwendungen meist völlig und ist dennoch ein voller SQL Server: Kurz: Eine ausgezeichnete Plattform zum Betreiben von Webseiten und kleinen Systemen. Ich habe die Anforderung eine neue Webanwendung mit kleiner SQL Datenbank auf einem Webserver einzurichten. Kein Problem (dachte ich mir), die Webanwendung war sofort am IIS7 Webserver eingetragen, jetzt nur noch die Datenbank restoren… So starte ich das SQL Management Studio der SQL Server Express Edition – aber die Anmeldung funktioniert nicht... Vielleicht ist etwas mit dem Dienst nicht in Ordnung? Ah, der SQL Dienst läuft gar nicht mehr! (Wie ist denn das passiert?) Also den SQL Dienst neu starten. Das funktioniert wie gewohnt, ok. Leider funktioniert die Verbindung zum SQL Dienst immer noch nicht! Hm, dann verbinden wir uns mal nochmals mit dem SQL Management Studio auf den nun laufenden Datenbank-Dienst. Jetzt kommt die Überraschung: Login failed … Reason: Server is in script upgrade mode. Only administrator can connect at this time. Da stimmt wohl etwas nicht... Auf ins Eventlog. Hier steht schon etwas mehr Information zum Problem mit MSSQL$SQLEXPRESS: Cannot recover the master database. SQL Server is unable to run. Restore master from a full backup, repair it, or rebuild it. For more information about how to rebuild the master database, see SQL Server Books Online.” Na toll (Muss ich jetzt wirklich die MASTER Datenbank restoren?). Und gleich darunter (Ja, weiterlesen hilft… ) Script level upgrade for database 'master' failed because upgrade step 'sqlagent100_msdb_upgrade.sql' encountered error 598, state 1, severity 25. This is a serious error condition which might interfere with regular operation and the database will be taken offline. If the error happened during upgrade of the 'master' database, it will prevent the entire SQL Server instance from starting. Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.” Aha. Es gibt also ein Problem während eines SQL Server Updates bzw. nach der Installation von SP2 (das auf der Maschine vor ein paar Tagen durchgeführt wurde), die Recherche liefert dazu auch Ergebnisse, hier einige davon: http://connect.microsoft.com/SQLServer/feedback/details/610217/sqlserver-2008-sp2-installation-failed http://www.sqldbadiaries.com/2010/12/06/server-is-in-script-upgrade-mode-only-administrator-can-connect-at-this-time/ http://datazulu.com/blog/2010/05/default.aspx Die Ursache: Die Installation des SP2 wurde durchgeführt, aber bestimmte” Scripts konnten nicht vollständig ausgeführt werden. This issue happens because the SQL Server service was stopped when the SP2 installation was in progress. Service Pack installation completes successfully but certain scripts (most of the times sqlagent100_msdb_upgrade.sql) in the Service Pack will be applied only after the SQL Server service starts the next time.” Also lautet die Empfehlung: Das abgebrochene Script fortsetzen um den SQL Dienst wieder zum Laufen zu bringen. Allerdings steht nicht dabei WIE. Mein SQL Dienst kann zwar starten, aber ich laufe immer wieder in dasselbe Problem, dass ich mich nicht anmelden kann. Ich erspare Ihnen und mir jetzt meine erfolglosen Recherche-Ergebnisse und Versuche – hier die zusammengefasste, rasche Lösung dazu: In RegEdit.exe nachsehen, wie die Datenpfade des SQL Servers lauten und zwar im Key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQLServer   In meinem Fall lauten die eingetragenen Verzeichnisse D:\SQL\Data und D:\SQL\Log. Und: Diese Verzeichnisse sind NICHT vorhanden! Das abgebrochene Script überprüft anscheinend nicht, ob die Verzeichnisse vorhanden sind und … bricht ab. Also nun die beiden Verzeichnisse physisch anlegen:   (Bzw. Prüfen Sie bitte VOR SP2 Installation, ob die SQL Daten-Verzeichnisse vorhanden sind…) Soweit so gut. Jetzt muss nur noch das Script irgendwie fortgesetzt werden. Here´s how: Nun den SQL Server Dienst (wenn er läuft: stoppen) im Single User Mode wie folgt aus der Console starten: CD "C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\Binn" sqlservr.exe -c -m -s "SQLEXPRESS" (Der Instanz-Name heißt standardmäßig SQLExpress. Infos zu den Parametern hier: Starting SQL Server in Single-User Mode) Nun startet der SQL Server Dienst und das abgebrochene Script läuft durch – ein cleverer Kerl, der SQL Server: Wenn das Script durchgelaufen ist (bei mir etwa 1 Minute), dann meldet der Dienst "Recovery is complete. … No user action is required." Nun den Dienst mit STRG+C abbrechen (wie im Screenshot), damit wird auch der SQL Dienst beendet. Und jetzt wie gewohnt den SQL Dienst neu starten.   Jipee. Der Dienst startet (wie gewohnt im Multi User Mode) und die Anmeldung im SQL Management Studio klappt wieder! Was so ein fehlendes Daten-Verzeichnis in Verbindung mit einem Update-Script bewirken kann... Bei dieser Gelegenheit ist es vielleicht eine ganz gute Idee, die (System) Datenbanken wieder mal zu sichern bzw. die Backup-Scripts laufen zu lassen - bei SQL Express Edition läuft der SQL Agent ja nicht, das muss man dann per Workaround automatisiert machen – das schreib ich mal in einem eigenen Artikel… . Ich hoffe, diese step-by-step Anleitung hilft allen DB- und System-Admins, die auch in dieses SP2-Upgrade Problem laufen! Somit hoffe ich, alle (Datenbank) Systeme laufen brav und ohne Überraschungen über die kommenden Festtage und wir SysAdmins haben geruhsame Feiertage!

Windows Small Business Server 2011 Standard ist RTM

Ja, es ist schon fast da: Bald kommt das Christkind und kurz danach: Der neue Windows Small Business Server 2011 Standard Edition gemeinsam mit Windows Small Business Server 2011 Premium Add-on. Das schreibt Curtis Lee, Director, Server and Cloud Marketing, im SBS Blog Windows Small Business Server 2011 Standard Releases to Manufacturing. Das Microsoft Produkt-Team ist in der Finalisierungs-Phase, ab Jänner 2011 wird SBS 2011 verfügbar sein: “…We are finalizing international versions, delivering the product to distribution channels and handing it off to our OEM partners so that they can begin pre-installing the software on new servers. Starting in early January, you will find SBS 2011 Standard and Premium Add-On in volume licensing, and from mid-January you will be able to download a trial copy from our website…” SBS 2011 ist die Lösung für KMUs bis zu 75 Benutzern und beinhaltet die neuesten Versionen von Microsoft Windows Server 2008 R2, Exchange Server 2010 SP1 und SharePoint Foundation Services 2010 (siehe auch Next Generation Small Business Server Aurora – Preview verfügbar). Das Premium Add-on beinhaltet die letzte Microsoft SQL Server 2008 R2 Version und bietet Hyper-V und Remote Desktop Services der Windows Server 2008 R2 Standard Version. Es wird einen Migration Path zum Update von früheren SBS-Versionen geben (erfahrungsgemäß zu mindestens supported für die letzte Version SBS 2008) um Ihren Kunden den Umstieg möglichst rasch und einfach anzubieten “…including ease of migration from earlier versions…”. Hier geht´s zur SBS next version Website und hier zu einer zweiseitigen SBS 2011 Broschüre. Freuet Euch, SBS 2011 kommt baaald!

SQL Server 2008 SP2 ist verfügbar

Ganz frisch! Das SQL Server 2008 Service Pack 2 (Version 10.00.4000.00) kann seit heute aus dem Microsoft Download Center downgeloadet werden: Microsoft SQL Server 2008 Service Pack 2. Für die Express-Editions gibt es einen eigenen Download: Microsoft SQL Server 2008 SP2 Express Edition Service Pack 2 Was ist Neu in SP2? SQL Server Utility – Ein Verwaltungstool zur konsolidierten Ansicht von Ressourcen und Gesundheit” aus verschiedenen SQL-Instanzen Data-tier Application (DAC) – Verwaltung von Daten in Multi-Tier Applikationen – Für nähere Hinweise lesen Sie diesen Artikel oder fragen Sie den Developer Ihres Vertrauens ;-) Reporting Services in SharePoint Integrated Mode – Verbesserungen der Reporting Services, in Tablix, Chart und Gauge Datenregionen, neue Datenquellen-Typen und Report Builder 2.0. SQL Server 2008 SP2 Report Server können in SharePoint 2010 und 2007 integriert werden. List of the bugs that are fixed in SQL Server 2008 Service Pack 2 (KB2285068) Mehr zum SQL Server und zum SP2: Microsoft Download Center - Microsoft SQL Server 2008 Service Pack 2 TechNet Wiki - Microsoft SQL Server 2008 SP2 Release Notes TechNet Microsoft SQL Server 2008 Home MSDN Microsoft SQL Server 2008 Empfehlenswert vor der Installation ist der Microsoft SQL Server 2008 SP2 Upgrade Advisor! Voraussetzung für SP2: SQL Server ;-), NET Framework 3.5 SP1, SQL Server Native Client, Unterstützungsdateien für SQL Server-Setup, Microsoft Windows Installer 4.5. (für x86 und x64) und zw. 110 und 396MB Festplattenplatz für den Download und etwa 675MB für die Installation. Happy testing and upgrading!

Tabellen in SQL Server vergleichen – Tablediff.exe

Arbeiten Sie viel mit SQL-Datenbanken? Dann kennen Sie (oder hatten Sie) sicher die Anforderung, Daten aus einer Datenbank (gescriptet) in eine andere Datenbank zu transferieren und dabei nur die Änderungen zu übertragen. Das lässt sich mit mehreren Methoden bewerkstelligen, je nach Anforderung, Know How und technischer Umgebung – vom SSIS Import-Tool über selbst scripten bis hin zu kostenpflichtigen Tools und Backup und Restore oder DB-Mirroring (dazu später mal mehr in einem eigenen Artikel). Ich hatte vor kurzem einen solchen Fall. Die Quell-Datenbank ist viele GB groß und es sollten nur Inhalte aus einer Tabelle in eine andere Test-Datenbank übertragen werden. In der Quell-Tabelle wurden Datensätze aktualisiert, gelöscht und hinzugefügt. In der Ziel-Tabelle in einer zweiten Datenbank sind manche Datensätze bereits vorhanden und sollen durch die Quell-Tabelle aktualisiert werden. Und das Ganze Aktualisieren (weils ja eine Testdatenbank ist, die sich immer wieder ändert) soll oftmals durchgeführt werden können. Also am besten irgendwie scripten… Fesch. Wie sag ichs meinem Computer – sprich SQL Server? Genau dafür gibt es seit SQL Server 2005 ein kleines Kommandozeilen-Tool – das allerdings wenig bekannt (wie das mit vielen Command Line-Tools so der Fall ist) und sehr praktisch ist: TableDiff The tablediff utility is used to compare the data in two tables for non-convergence, and is particularly useful for troubleshooting non-convergence in a replication topology.” Das klingt mal interessant. Und TableDiff macht auch genau das: Es vergleicht Tabellen und kann auch ein Script mit den Unterschieden der Tabelleninhalte erstellen um die Änderungen auf einem Zielsystem sofort ausführen zu können. Es synchronisiert” allerdings nicht die Unterschiede aus beiden Tabellen, sondern nur in eine Richtung – wie in der Grafik oben. In meiner Anforderung ist TableDiff super-fein, denn das kleine Script (im Vergleich zur mehreren GB großen Datenbank) kann auch sehr rasch erzeugt und auf das Zielsystem transportiert und ausgeführt werden, ohne irgendwelche erforderlichen Verbindungen oder Konfigurationen – also straight forward”. Also, wo findet man TableDiff.exe? Bei SQL Server 2008 hier: C:\Program Files\Microsoft SQL Server\100\COM Der Pfad zu TableDiff.exe in SQL Server 2005 lautet übrigens Program Files\Microsoft SQL Server\90\COM”. Wie funktioniert es und wie sieht der Aufruf aus? tablediff.exe -sourceserver server1 -sourcedatabase db1 -sourcetable table1 -destinationserver server1 -destinationdatabase db2 -destinationtable table2 Hinweis: Um explizite Credentials zum SQL Server anzugeben sind diese Parameter erforderlich: -sourceuser <SourceLogin> -sourcepassword <SourcePassword> bzw. -destinationuser <DestinationLogin> -destinationpassword <DestinationPassword> Hinweis: To compare tables, you need SELECT ALL permissions on the table objects being compared.” und ..To use the -et option, you must be a member of the db_owner fixed database role…” D.h. am besten einen dbowner o.ä. für das Tool verwenden, dann gibts keinerlei Einschränkungen. Wenn die beiden Tabellen-Schemata nicht übereinstimmen, folgt ein Hinweis: Table [db1].[dbo].[table1] on SERVER1 and Table [db2].[dbo].[table2] on SERVER1 have different schemas and cannot be compared. Eine weitere Voraussetzung: Die Tabellen müssen eine eindeutige ID-Spalte besitzen: The replication table difference tool requires the comparison tables/views to have either a primary key, identity, rowguid or unique key column. So, nun zu meinem Fall-Beispiel: Ich habe auf der SQL-Maschine DAISY” zwei Datenbanken db1” und db2” und hier jeweils eine Tabelle WEB_Node”. Die Änderungen (Inhalte) von WEB_Node” sollen aus db1” in db2” transportiert werden – hier sind Webinhalte gespeichert, die in die Testdatenbank transferiert werden sollen. So sieht mein kleines Script C:\Temp\SQL\doit.cmd aus: cd "C:\Program Files\Microsoft SQL Server\100\COM" tablediff -sourceserver "DAISY" -sourcedatabase "db1" -sourcetable "WEB_Node" -destinationserver "DAISY" -destinationdatabase "db2" -destinationtable "WEB_Node" -et Diff -f C:\Temp\SQL\diff.sql pause Damit wir auch sehen, WAS die Unterschiede sind, fügen wir zum Statement -et Diff” hinzu – damit werden die Unterschiede in eine temporäre Tabelle Diff” geschrieben und können daraus ausgegeben werden. Und noch besser: -f <pfad><sqlfile> erzeugt ein T-SQL-File, das die Änderungen scriptet! Damit können die Änderungen ganz leicht am Zielsystem ausgeführt” werden – voila! Auch ganz praktisch: Um mal rasch einen Überblick zu erhalten, sind die Parameter -c -q gut, z.B.: Table [db1].[dbo].[WEB_Node] on DAISY and Table [db2].[dbo].[WEB_Node] on DAISY have different row counts. Table [db1].[dbo].[WEB_Node] on DAISY has 123 rows. Table [db2].[dbo].[WEB_Node] on DAISY has 101 rows. The requested operation took 0,0950095 seconds. So, lassen wir es mal (ohne –c –q) laufen: Naja, da sind schon einige Unterschiede vorhanden. Das erzeugte File diff.sql sieht dann in meinem Fall so aus: Das File ist laang, am Ende folgen dann die neuen Datensätze (INSERTS). Achja, eines sollte ich noch im Script anpassen: Dass die Änderungen in die richtige” Datenbank geschrieben werden – bei mir in db2” – der Hinweis steht zwar im Script, aber nur als Kommentar. Also am Beginn ergänzen: use db2 go So, F5 (Run) drücken – here we go. Voller Spannung erwarte ich, dass SQL Server nun die ganze Arbeit erledigt … FAIL! Es gibt einen Converting error” beim Umwandeln von Datentypen. Erste Analyse: Das erste INSERT Command will in ein Feld vom Typ smalldatetime einen Datumswert als String N'Null' (also kein Datum vorhanden) einfügen… Dass das nicht klappen kann erscheint logisch. Also im Script mit Suchen und Ersetzen workaround-en: Ersetze alle Vorkommen von N‘NULL’ durch NULL: Alles ersetzen. Achja und noch ein zweiter Stolperstein: Das verwendete Datumsformat N'2010-08-12 10:38:00' war auf meinem SQL Ziel-System auch noch ein Problem. Also auch zu Beginn das Datumsformat setzen: set dateformat ymd; RUN! Jipee, es funktioniert jetzt brav, frei nach dem Motto Kaum macht mans richtig, gehts…”. Noch ein Tipp: Der zusätzlichen Parameter –strict kann auch bei der Fehleranalyse helfen (Source and destination schema are strictly compared). Das Scripten eines NULL-Datum ist mein einziger Wehrmutstropfen am coolen tablediff-Tool: Einen Parameter zum Ändern des N’NULL’ Verhaltens habe ich bislang nicht gefunden. Vielleicht hat ja ein Leser einen Tipp? Nun gut, aber der Workaround mit Search & Replace tuts auch – wenn man es weiß. ;-) Noch ein Tipp zum Vergleichen von GROSSEN Tabellen: Der Parameter -bf <number_of_statements> schränkt die Anzahl der Befehle auf die angegebene Anzahl ein und erzeugt danach ein neues, weiteres File. Damit sind große Update-Scripts durchführbar und bearbeitbar. Weitere Links zu tablediff: http://msdn.microsoft.com/en-us/library/ms162843.aspx - tablediff Utility http://msdn.microsoft.com/en-us/library/ms147919.aspx - How to: Compare Replicated Tables for Differences (Replication Programming) http://technet.microsoft.com/en-us/library/cc917696.aspx - Top 10 Hidden Gems in SQL Server 2005 http://www.databasejournal.com/features/mssql/article.php/3594926/SQL-Server-2005-TableDiff-Utility.htm - SQL Server 2005 TableDiff Utility http://sqlserverpedia.com/blog/sql-server-2005/where-do-i-find-the-tablediffexe-tool-and-what-is-it/ - Where do I find the table.diff.exe tool and what is it? http://www.mssqltips.com/tip.asp?tip=1073 - SQL Server 2005 tablediff command line utility Meine Empfehlung: TableDiff ist ein äußerst hilfreiches Tool zum automatisierten (bzw. mit dem Search & Replace Workaround halbautomatisierten) Abgleich von Tabellen und kann DB-Admins viel Zeit und Arbeit abnehmen!

Microsoft SQL Server 2008 R2 Report Builder 3.0

…ist seit gestern zum im Microsoft Download Center verfügbar: Microsoft SQL Server 2008 R2 Report Builder 3.0 Microsoft SQL Server 2008 R2 Report Builder 3.0 ist eine Berichterstellungsumgebung für Geschäftsbenutzer, die in der vertrauten Microsoft Office-Umgebung arbeiten können, um Auswertungen rasch und einfach selbst zu erstellen.” Der Download ist ein stand-alone Installer und 31MB klein. Was ist neu? Nun, zum Beispiel hinterlegbare Karten (Beispiel unten), Sparklines (die Wellengrafik 2004 Verkaufsverlauf” unten) und zusätzliche Diagrammtypen. Reports werden rascher aufgebaut (cached datasets), Auswertungen sind mit dem neuen Report Builder rascher bearbeitbar und können als Datafeed ausgegeben werden. Der Link What's New in Report Builder 3.0 August CTP informiert darüber – auch wenn der Titel nicht ganz aktuell ist, sind hier die wesentlichen Funktionen aufgelistet. Erste Schritte mit Berichts-Generator 3.0 ist eine gute Startseite um die Funktionalität und Möglichkeiten des Microsoft SQL Server 2008 R2 Report Builder 3.0 kennenzulernen. Demo eines erzeugten Reports mit Karte. Mehr Infos zu Geschäftsdaten mit geografischem Hintergrund siehe Karten (Berichts-Generator 3.0). Business Intelligence für Power-User!

SQL Server 2008 R2 ist RTM

Der nächste RTM: SQL Server 2008 R2 ist fertig, schreibt Ted Kummert, Senior Vice President, Business Platform Division, im Official Microsoft Blog: SQL Server 2008 R2: Helping Customers Get More Value Out of Their Data. (Georg kann also den SQL Server 2008 R2 in seinem Artikel RTM, RTM, RTM zur Liste der neuen, fertigen Produkte hinzufügen. ;-) Der R2 Server hat übrigens Großes” vor: Verbesserungen in der Skalierbarkeit (256 CPU´s, Application and Multi-Server Management, etc.) und Business Intelligence in Verbindung mit SharePoint 2010 (RTM) und Office 2010 (RTM) als neue self-service business intelligence” sind nur einige der neuen Themen, siehe auch Download the SQL Server 2008 R2 Guide. Wann wird SQL Server 2008 R2 downloadbar sein? Laut Blog wird R2 ab 3. Mai in den Microsoft Partner Bereichen msdn und technet downloadbar sein, und ab dem 13. Mai allgemein verfügbar sein. In der Microsoft SQL Server 2008 R2 Digital Tour finden sich viele der Neuigkeiten inkl. Test Drive” im Überblick! Schauen Sie mal rein: www.sqlserverlaunch.com!