Seit vergangenem Mittwoch Abend (06.08.2008) häuften sich die Blog Meldungen, dass SQL Server 2008 nun ready-to-manufacturing (RTM) ist. Dies freut uns natürlich, da wir uns schon seit über einem Jahr als fleissige Tester engagieren. Im MSDN können die 2008er Versionen schon heruntergeladen werden, in die offiziellen Verkaufsregale werden die Produkte wohl im September kommen.
Unsere Erfahrungen mit SQL Server 2008 geben wir Ihnen gerne in Form von TechnoCircles weiter. Diese eintägigen Seminare bringen Ihnen sämtliche neuen Features näher und wir sagen Ihnen auch, wie sie einsetzbar sind. Die ersten Durchführungen finden Anfang September statt! Wir freuen uns, Sie bei uns zu begrüssen :)
Mehr Infos zum TechnoCircle SQL Server 2008 für DBAs/IT Pros: http://www.trivadis.com/shop/technologien/microsoft/seminare/sql-server-2008-was-ist-neu-und-relevant-fuer-dbas-und-it-professionals-m-sql08-dba.html
Mehr Infos zum TechnoCircle SQL Server 2008 für Applikationsentwickler: http://www.trivadis.com/shop/technologien/microsoft/seminare/sql-server-2008-die-essentiellen-neuerungen-fuer-entwickler-m-sql08-dev.html
Mehr Infos zum TechnoCircle SQL Server 2008 für BI-Spezialisten: http://www.trivadis.com/shop/technologien/microsoft/seminare/sql-server-2008-das-herz-einer-modernen-business-intelligence-plattform-m-sql08-bi.html
Unter http://edge.technet.com/Media/Trivadis-and-SQL-Server-2008-Customer-story/ finden Sie auch ein Video, welches kurz die Erfahrungen von uns mit SQL Server 2008 aufzeigt, viel Spass damit :)
Bei einer Installation von SQL Server 2005 x64 bin ich auf ein interessantes Problem gestossen.
Bei der Überprüfung des Systems bekam ich eine Warnung das nur ASP.NET 32 bit aber nicht ASP.NET 64 bit registriert ist, obwohl ich .NET 2.0 x64 manuell installiert habe. Reporting Services benötigt aber zwingend ASP.NET 2.0 x64. Nun war ich nicht in der Lage Reporting Services zu installieren.
Das Problem war leider nicht zu beheben, indem ich im IIS die entsprechende x64 isapi dll von .NET 2.0 als Web Service Extension eingebunden habe.
Eine detaillierte Beschreibung wie das Problem doch zu lösen ist, ist hier verfügbar:
http://support.microsoft.com/kb/894435/en-us im Abschnitt ASP.NET 2.0, 64-bit version
Die Ursache war, dass .NET 1.1 auf dem Server installiert war, welches das Enable32bitAppOnWin64 Flag auf 1 gesetzt hat. .NET 1.1 ist nicht in einer x64 bit Variante verfügbar. Dies verhinderte die korrekte Registrierung von ASP.Net 2.0 x64.
Ich hoffe, das hilft den einen oder anderen wenn dasselbe Problem auftaucht.
Das Cumulative Update Package 8 für SQL Server 2005 SP2 behebt nicht nur eine grosse Liste an Bugs, sondern schliesst auch gleich eine Sicherheitslücke.
Seit dem 15. Juli 2008 ist das CU8 unter http://support.microsoft.com/kb/951217/en-us beschrieben und kann dort auch angefordert werden. Das erste Security-Bulletin zum SQL Server seit Juli 2003 beschreibt unter http://www.microsoft.com/technet/security/bulletin/ms08-040.mspx die Risiken und weist darauf hin, dass schon mittels CU7 das Problem behoben wird. Wichtig ist, dass auch für den SQL Native Client ein Update verfügbar ist, welches im gleichen Zuge eingespielt werden sollte. Das gemeldete Sicherheits-Loch tritt ebenfalls bei SQL Server 2000 mit SP4 auf! Auch dafür ist ein Hotfix erhältlich: http://www.microsoft.com/downloads/details.aspx?familyid=8316BC5E-8C2D-4710-8ACC-B815CCC81CD4&displaylang=en. Dieses sollte aber nicht einfach installiert werden, sondern wir empfehlen dringendst, vorgängig Tests auf nicht kritischen Systemen durchzuführen.
SQL Server 2000 SP4 ist übrigens seit dem 8. April 2008 aus dem Mainstream Support. Die Zeit für ein Upgrade auf SQL Server 2005 ist sicher gut ;-)
Sind Sie interessiert welcher RAID Level
für welche Anwendungen geeignet ist?
Sind Sie nicht ganz sicher was der Unterschied zwischen RAID Level 1+0 und 0+1
ist?
Schauen Sie mal bei http://www.raid.com/04_00.html
vorbei. In der Titelleiste finden Sie der Link zu raid.edu.
·
Da finden Sie detaillierte Informationen über
die verschiedenen RAID Level:
- Vorteile
- Nachteile
- Geeignet für welche Anwendungen
- Animationen mit der Funktionsweise
Für SQL Server empfehlen wir grundsätzlich
folgende Modelle. Natürlich müsse für jede Umgebung oder Applikation deren
Anforderungen genau abgeklärt werden. Desweiteren müssen bei speziellen
Performance Anforderungen unbedingt Tests durchgeführt werden um die
Konfiguration zu verifizieren:
|
OS
(C:\):
|
RAID 1
|
Benötigt
Ausfallsicherheit mit guter Performance
|
|
SQL
Server Programme:
|
RAID 1
|
Benötigt
Ausfallsicherheit mit guter Performance
|
|
System DB’s:
|
RAID 1
|
Benötigt
Ausfallsicherheit mit guter Performance
|
|
Temp DB:
|
RAID 0+1 (RAID
1)
|
Benötigt höchste
Schreib- und Lese- Performance mit Ausfallsicherheit.
|
|
User DB’s:
|
RAID 1+0 oder
RAID 5 (RAID 1)
|
Je nach Art der
Applikation wird eher eine höhere Schreib-, eine höhere Lese-Performance oder
50/50 benötigt. RAID 5 wenn Lese-Performance wichtiger ist. RAID 1+0 wenn
Schreibperformance wichtiger ist. Wenn 50/50 ist RAID 1+0 eher als RAID 5
geeignet.
|
|
User
Transaction Log’s:
|
RAID 0+1 oder
RAID 1
|
Benötigt hohe-höchste
Schreib- und Lese-Performance.
|
|
Zusätzlich
Index Filegruppen (Optional)
|
RAID 0+1
|
Benötigt höchste
Schreib-Lese-Performance
|
In Klammern
stehen die Empfehlungen falls RAID 0+1 oder 1+0 nicht zur Verfügung stehen.
Gerne helfen wir Ihnen beim Design der für Sie
am besten geeigneten Konfiguration.
Seit Anfang Mai 2008 ist die Finale Version einer Sammlung von Tools um
die Arbeit mit dem SSMS zu erleichtern verfügbar. Die Sammlung ist hier zu
finden: http://www.ssmstoolspack.com/
Es sind drei Versionen zu haben:
Eine für das SSMS für SQL Server 2005 sowie für das SSMS für SQL Server
2005 Express. Diese beinhalten u.a. das zusammenführen eines Code-Blocks und
das dadurch mögliche zusammenklappen dieses Blocks.
Die Version für SQL Server 2008 funktioniert auf der CTP6 und RC0 leider
noch nicht. Der Entwickler wird sich um das Problem kümmern, konnte mir aber
nicht sagen bis wann.
Das Tools Pack beinhaltet:
- Umsetzen
von Schlüsselwörtern in Grossschreibschrift. Die Liste der Schlüsselwörter
ist selbst definierbar.
- Ein
Script auf multiplen Datenbanken ausführen
- Ein Execution Plan als Bild in die Zwischenablage
- Suche
im Ergebnissatz und in Execution Plan
- Aus
einer bestehenden Tabelle ein Batch File erstellen der der ganze Inhalt in
eine Zieltabelle einfügen kann
- History
über die abgesetzten Statements. Dies kann in ein XML File wie auch in
eine Tabelle (oder beides) abgelegt werden. Ein Tool zum anzeigen der
History ist mitgeliefert
- Code-Blöcke
zusammenfassen und mit Kommentaren versehen
- Vordefinierte
T-SQL Scripts auf Objekte aus dem Kontext-Menu im Object-Explorer
ausführen
- Stored
Procedures erstellen die DML Operationen auf Tabellen maskieren (CRDU:
Create, Read, Update, DELETE)
- Ein
Template erstellen der bei jedem neuen Query Window benutzt wird (z.B.
BEGIN TRANS
COMMIT)
ACHTUNG: Per Default ist hier
BEGIN TRANS ROLLBACK drin. Dies sollte angepasst werden um unliebsame
Effekte zu vermeiden.
Download
und Installation
Der Download ist sehr klein (knapp 600kB). Nach entpacken des Setup.exe
und des dazugehörigen msi-Files, kann das Setup ausgeführt werden. Beim
nächsten Start des SSMS erscheint ein neues Menu (SSMS Tools). Dort können alle
Tools konfiguriert werden.
Konfiguration
Die Konfiguration ist per Tools getrennt. Die Optionen sind weitgehend
selbsterklärend. Auf der Webseite unter Features (http://www.ssmstoolspack.com/Features.aspx)
sind die einzelnen Tools erklärt.
Das einzige Tool welches zusätzlichen Konfigurationsaufwand benötigt ist
die Query Execution History (Im Menu mit SQL Query Action Logger aufgeführt).
Wie bei allen anderen Tools wird über den Submenupunkt „Options“ die
Konfiguration durchgeführt. Bei diesem Tool gibt es zwei Optionen:
- Log in
ein XML File (per Default eingeschaltet auf C:\SSMSToolsPack\)
- Log in
eine Tabelle (per Default ausgeschaltet)
Um in eine Tabelle zu loggen muss der Status auf Enabled gesetzt werden
und der Connection String zur Datenbank angegeben werden. Im Bild ist zu sehen
dass das Log lokal in die msdb geschrieben wird.
![]()
Nun muss noch das CREATE TABLE Statement in ein Query Window kopiert und
ausgeführt werden.
Zu beachten ist dass der Benutzer sowohl auf das Log File wie auch in
der ActionLoggerHistory Tabelle Schreibrechte benötigt. Das ist, insbesondere
wenn man die msdb benutzt und man nicht sysadmin der Instanz ist, nicht
selbstverständlich.
Nun werden alle Aktionen im SSMS in das XML File und in der Tabelle geloggt.
Das Log kann über das SSMS ToolsPack Menu unter SQL Query Action
Logger\Log Action History betrachtet werden oder direkt über die angegebene
Tabelle ausgegeben werden.
Nutzen der
Tools
Die meisten Tools sind sehr nützlich. Vor allem die Query History und
die Möglichkeit vordefinierte Scripts direkt auf Objekte im Object Explorer
auszuführen kann die Arbeit um einiges erleichtern.
Die Möglichkeit den Inhalt einer gesamten Tabelle als INSERT Script
abzubilden, birgt Möglichkeiten wie auch Risiken. Man kann die Anzahl der
INSERT Statements in einer Transaktion konfigurieren. Das Script gruppiert
diese Zeilen einfach mit BEGIN TRANSACTION und COMMIT inkl. einer einfachen
Fehlerbehandlung.
Wenn mehrere zehn oder hunderttausend Zeilen so abgearbeitet werden, belastet
dies das Transaction Log stark. Da kann man sich überlegen das ganze über ein
ROWSET als Massen-Transaktion im Bulk-Logged Recovery Model abzubilden.
Insgesamt erleichtern diese Plug-Ins die Arbeit so weit dass diese
Sammlung sehr empfehlenswert für DBA’s oder Entwickler wird. Die Möglichkeit
die Custom Scripts selbst zu erweitern und diese nur bei bestimmten Objekten im
Object Explorer zuzulassen, ist eins der Highlights dieses
ToolsPack’s.
Allerdings werden gewisse Features (z.B. Regions erstellen um diese
zusammenklappen zu können) im Visual Studio für SQL Server 2008 bereits
integriert sein.
Boot ab SAN, vielerorts ein Begriff der aufschrecken lässt, wenn es sich beim OS um Windows Server handelt. Hardware Hersteller geben unterschiedliche Meinungen preis was das angeht. Probleme mit Pagefile usw. werden meistens genannt. Doch Windows Server ist fähig ab SAN zu booten. Dazu gibt es auch ein sehr gutes Whitepaper von Microsoft, welches im Anhang dieses Blogeintrags zu finden ist.
Wieso überhaupt Boot ab SAN? Es gibt einige Vorteile, wenn keine lokalen Disks mehr vorhanden sind:
- Es wird weniger Strom an den Servern (meistens Blades) benötigt, wenn keine lokalen Disks betrieben werden
- Weniger Ausfälle, da das Storage auf dem SAN redundanter ausgelegt ist
- Einfacheres Disaster Recovery durch SAN SnapShots
- Replikationsmöglichkeiten an einen remote Standort
- Meistens sogar schnellere Ladezeiten
- Es wird weniger Diskspace verbraten. Ein durchschnittliches BootImage benötigt bestimmt nicht mehr als 20GB, meistens sind, wenn überhaupt, nur noch 72GB Harddisks für neue Server verfügbar
Alles in allem wird hier also der Konsolidierungsgedanke stark unterstützt und es kommen noch weitere Vorteile im Bereich Backup/Recovery zum tragen.
Nun spricht aber nicht alles für den Einsatz dieser Technologie. Auch ich musste einige Stolpersteine überqueren bis alles einwandfrei lief:
- Hardware Deployment ist erheblich komplizierter und erfordert eine 100% korrekte Konfiguration
- Der Boot Prozess ist ebenfalls komplizierter
- Wenn ein Fehler auf dem SAN auftritt, können die Server nicht mal mehr gebootet werden um allenfalls SQL Server Backups lokal zurück zu spielen
- Umfangreicheres Troubleshooting notwendig bei Problemen
Bei der Umgebung auf welche ich einen Windows Server 2003 Cluster mit SQL Server aufsetzen durfte war alles einwandfrei konfiguriert und der Cluster liess sich anfänglich ohne Probleme aufsetzen. Als ich dann aber die Shared Disks in der SQL Server Resource Group konfigurieren wollte, welche ich fürs SQL Server Setup vorbereitete, war das Auswahlfenster immer leer. Als erstes hatten wir nicht den Punkt Boot ab SAN im Visier, sondern überprüften sämtliche andere Konfigurationen, landeten schlussendlich dann aber trotzdem wieder bei diesem Thema. Denn bei dieser Konfiguration dürfen grundsätzlich Bootpartition, Pagefilepartition und shared Storage nicht über den gleichen Controller angesteuert werden resp. nicht auf der gleichen Storagefabric liegen. Das Whitepaper im Anhang gibt diesbezüglich ebenfalls Auskunft. Was mich aber stutzig machte, ist dass die Quorumdisk einwandfrei konfiguriert werden konnte. Nach einiger Zeit stiess ich auf den Microsoft Knowledgebase Artikel 886569 "How to add a registry value to a Windows Server 2003-based computer that you start from a SAN so that the startup disk, the pagefile disks, and the cluster disks are all on the same SAN fabric" (http://support.microsoft.com/kb/886569/en-us), welcher tatsächlich das Problem löste und wir unsere Disks erfolgreich bereitstellen konnten.
Falls jemand ebenfalls Erfahrung mit dieser oder ähnlicher Konfiguration gemacht hat, würden mich Ihre Meinungen sehr interessieren...
Viel Spass beim booten ab SAN!
Ein Mal kam ein Kollege bei mir vorbei und schilderte folgendes Problem:
Es gibt eine Datenbank, auf welche sowohl intern als auch von einer 3rd – Party – Applikation zugegriffen wird. Leider ist die Applikation etwas fehlerhaft programmiert, was dazu führt, dass sie während ihrer Aktivitäten mehrere Tabellen in den exklusiven Zugriff nimmt. Wenn man nun gleichzeitig eine interne Abfrage startet, kommt es zu sehr langen, scheinbar unerklärlichen Wartezeiten oder gar Deadlocks.
Der Kollege hat mich in dieser Angelegenheit um Hilfe gebeten, um eine interne, per SQL Agent – Job angestoßene, Abfrage fehlerfrei oder mit zumindest erklärbaren Meldungen ausführen zu lassen.
Zum Glück haben wir festgestellt, dass die 3rd – Party – Applikation nicht permanent auf die Datenbank zugreift. Als Lösung habe ich dann ein kurzes Skript implementiert, welches prüft, ob ein bestimmter Prozess läuft (also z. B. unser „Blockierer“) und wenn das der Fall ist, wird erst Mal eine kurze Pause eingelegt. Danach wird die Prüfung wiederholt und so weiter, bis die maximale Anzahl Wiederholungen erreicht ist. Wenn der „Blockierer“ noch da ist, dann wird eine Fehlermeldung generiert. Jetzt mussten wir nur noch den betroffenen SQL Agent – Job aufmachen und unser Skript als den ganz ersten Schritt hinzufügen. Dadurch hatten wir schon unsere Lösung: beim Starten des Jobs wurde erst Mal unser „WaitForProcess“ – Skript gestartet, das folgendes macht:
- Entweder wartet, bis der „Blockierer“ nicht mit dem Server verbunden ist, und die Ausführung des Jobs mit dem nächsten Schritt (der betroffenen Abfrage) fortsetzt.
Oder einen Fehler generiert, wenn die Blockierung zu lange dauert, und dadurch die Jobausführung mit einer verständlichen Meldung abbricht.
Nun einige Hinweise zur Implementierung. Das Skript ist recht allgemein geworden und kann überall eingesetzt werden, zum Beispiel auch als Teil einer gespeicherten Routine. Die Prüfung erfolgt in einer Schleife durch Analyse der Tabelle „sysprocesses“. Dabei werden, um die Überwachung des „Blockierers“ genau einzuschränken, die Namen der Datenbank, des Hosts und des verwendeten Logins geprüft. Anschließendes Warten erfolgt durch die Verwendung eines „waitfor delay“ – T-SQL – Befehls.
Das komplette Skript kann man im Anhang an diesen Beitrag finden. Für einen konkreten Einsatz müssen die Variablen @TargetDBName, @HostName und @LoginName am Anfang des Skriptes gesetzt werden, ggf. auch die Variable @MaxRuns (die die Anzahl der Warteschleifen begrenzt).
Bestimmt hat schon mancher DBA das folgende Problem gehabt: Eine 3rd – Party – Applikation erstellt immer mehr Verbindungen und gibt diese nicht immer alle frei, so dass irgendwann interne Connection – Pools überlaufen oder es werden so viel offene Verbindungen erstellt, dass der SQL Server immer schlechtere Performance aufweist.
Es gibt eigentlich keine eingebauten oder mit SQL Server mitgelieferten Tools, welche die Fähigkeit besitzen, die Anzahl der Verbindungen bestimmter Applikationen über Zeit zu verfolgen und dies ggf. in einer tabelarischen Form zu präsentieren um die Daten später z. B. mit Excel auszuwerten.
Ein solches Tool kann mit internen Mitteln schnell und einfach gebaut werden.
Der 1. Schritt ist, eine Datenbank zu erstellen, in welche wir die Daten ablegen werden. Am einfachsten macht man dies auf dem gleichen Server, auf welchem der Trace laufen soll. Nennen wir diese Datenbank „MagicTrace“.
Der 2. Schritt ist, die notwendigen Datenstrukturen in der neuen Datenbank zu erstellen. Gemäß der Aufgabenstellung, brauchen wir eine Lookup - Tabelle für die Namen der verfolgten Applikationen (tlkpProgram) und eine Tabelle für die Zeitachse der Messungen (quasi die Dimensionstabelle, tblTime). Für die gemessenen Verbindungen benötigen wir die Fakt – Tabelle (tblMeasure), die sowohl auf Programme als Zeitachse über Fremdschlüssel verweist. Das Listing der Datenbankstruktur ist in der angehängten Datei „magic_trace_data.sql“ enthalten.
Im 3. Schritt müssen wir nun die Applikationslogik einspielen. Sie ist in der Datei „magic_trace_code.sql“ enthalten und besteht aus zwei Routinen: usp_checkpoint für die Analyse des gegenwärtigen Verbindungszustandes anhand der Systemtabelle „sysprocesses“ und usp_stats für die Anzeige der gesammelten Daten in denormalisierter, lesbarer, tabelarischer Form.
Nun muss man nur die Namen der gewünschten Applikationen, für die die Daten gesammelt werden sollen, in die Tabelle tlkpProgram eintragen (der korrekte Name kann aus der Systemtabelle „master..sysprocesses“, Feld „program_name“ ermittelt werden). Danach sollte man nur den Befehl „execute MagicTrace.dbo.usp_checkpoint“ in regelmäßigen Abständen ausführen (z. B. mit Hilfe eines SQL Server – Jobs, s. Anhang „MT-Job.sql“).
Die aufgerufene Routine ermittelt zunächst den aktuellen Zeitpunkt als Dimension, und als Fakten sammelt „select count(*)“ – Werte für alle Applikationen, deren Namen in tlkpProgram auffindbar sind.
Der Speicherbedarf für die Messungen ist sehr klein, da die Daten komplett normalisiert gespeichert werden. Im Prinzip werden für jede Messung „netto“ beansprucht: einmalig in der Dimensionstabelle 12 Bytes und in der Fakttabelle pro Applikation 20 Bytes, plus entspr. Overhead. Dadurch lassen sich über sehr lange Zeit die Daten in kleinen Zeitabständen sammeln, ohne dass man sich Sorgen um Speicherplatz machen muss.
Die Analyse kann jeder Zeit mit einem Aufruf von „execute MagicTrace.dbo.usp_stats“ gemacht werden. Dabei wird eine Tabelle präsentiert, die als 1. Spalte den Zeitstempel hat, und die sonstigen Spalten die Namen der betroffenen Anwendungen tragen. Dies wird u. a. dadurch erreicht, dass das Ergebnis als eine temporäre Tabelle dynamisch (mittels „alter table … add“) zusammengestellt wird. Wenn man möchte, kann man jetzt den Aufruf als externe Datenquelle in Excel anbinden und schöne und übersichtliche Grafiken erstellen.
Seit SQL Server 2005 ist es nicht mehr möglich die System Datenbanken mit rebuildm.exe wieder herzustellen. Dazu muss die setup.exe mit den entsprechenden Parametern und Schaltern verwendet werden.
In SQL Server 2008 RC0 gibt BOL nicht optimal Auskunt (Verweist auf einen Schalter /REBUILDDATABASES der von der setup Routine nicht erkannt wird).
Hier die korrekte Syntaxt die alle System Datenbanken (master, model, msdb) wieder im Ursprungszustand erstellt:
Setup.exe /q /ACTION=rebuilddatabase /INSTANCENAME=InstanceName
/SQLSYSADMINACCOUNTS="Builtin\Administrators" /SAPWD="VerryStrongPW"
Es ist zu beachten, dass die bestehenden Datenbanken überschrieben werden. Sollen aktuelle Objekte wieder hergestellt werden können, so müssen valide Backups der System Datenbanken vorhanden sein, die nach dem neu erstellen der System Datenbanken wieder hergestellt werden können.
Wird das in SQL Server 2005 neu vorhandene Feature Service Broker verwendet kann es sein, dass folgenden Symptome auftauchen:
- MSDB wächst massiv an aber es werden keine Tabellen mit der Anzahl Rows ausgewiesen die der Filegrösse entsprechen würden. Die Datenbank Files lassen sich trotzdem nicht shrinken.
DBCC SHRINKFILE (msdbdata, 1) zeigt keine Wirkung
- wurden in einer Datenbank Service Broker Queues erstellt und diese korrekterweise in einer Data Filegroup erstellt wächst die Primary Filegroup trotzdem massiv an
Beispeil einer Queue Definition in eine User File Group:
CREATE QUEUE [dbo].[AuditQueue]
WITH STATUS = ON , RETENTION = OFF ,
ACTIVATION ( STATUS = ON , PROCEDURE_NAME = [dbo].[ReadAuditQueue] , MAX_QUEUE_READERS = 1 , EXECUTE AS N'dbo' )
ON [AuditDB01]
Das Primary Database File lässt sich auch hier nicht durch shrinken verkleinern.
Es ist dann zu prüfen, welche Queues vorhanden sind und wie diese konfiguriert sind. Insbesondere kann im SQL Server Errorlog überprüft werden, ob Hinweise auf ein nicht korrektes funktionieren der Queue bzw. dessen Abarbeitung vorhanden sind. Die Queue ist bei Fehlern zu stoppen bzw. zu entfernen und später, nach dem "Clean-Up" wieder neu aufzubauen.
Ist die Queue oder sind die Queues gestoppt so sollte auch das Wachstum der entsprechenden Datenbanken stoppen. Nun kann überprüft werden, ob in der sys.transmission_queue, der betroffenen Datenbank, oder der User Service Broker Queue, Einträge vorhanden sind die noch nicht verarbeitet wurden. Dies geschieht mit dem Statement:
SELECT COUNT(*) FROM sys.transmission_queue
oder am Beispiel einer User Queue mit dem Namen AuditQueue
SELECT COUNT(*) FROM AuditQueue Sind nun in der sys.transmission_queue Einträge vorhanden, muss entschieden werden ob diese noch gebraucht werden oder ob die Queue geleert werden kann. Meist wird der Service Broker dazu verwendet, dass Informationen möglichst zeitgleich verarbeitet werden. Somit wird es in den meisten Fällen so sein, dass die Queue geleert werden kann um ein Wiederherstellen der Service Broker Queues zu ermöglichen.
Die Queues können wie folgt geleert werden:
DECLARE @conversation uniqueidentifier
WHILE exists (SELECT 1 conversation_handle FROM sys.transmission_queue)
BEGIN
SET @conversation = (SELECT TOP 1 conversation_handle FROM sys.transmission_queue)
END conversation @conversation WITH CLEANUP
END
Dadurch werden die offenen Einträge beendet und die Daten aus den System Tabellen entfernt. Nach dem Durchlauf des Statements kann der Aufräumvorgang in den Systemtabellen noch weitere Zeit in Anspruch nehmen.
Sind dann alle Einträge entfernt, dann können auch die betroffenen Datenbank Files durch shrink verkleinert werden.
Empfehlung:
Bei der Verwendung von Service Broker Funktionen ist die Überwachung der betroffenen Datenbank Files unbedingt nötig.
Dass SQL Server 2005 Backups auch auf einen Netzwerk Share ablegen kann ist ja bekannt. Was ist aber wenn der Zielserver ein UNIX/Linux Server ist, der nur NFS anbietet?
Trotz Samba wird es das sicher noch geben. Ich hatte vor kurzem einen solchen Fall bei einem Kunden mit Linux.
Im Folgenden führe ich hier ein paar Punkte auf die zu beachten sind.
- Der SQL Agent Service muss mit einem (Domänen) User Account ausgeführt werden, nicht mit Builtin-Accounts wie LOCAL SYSTEM, o.ä.
- Auf dem Zielserver muss ein Account mit den identischen Namen und einem identischen Passwort existieren wie der SQL Server Agent Service Account.
- Der Account auf dem Zielserver muss entsprechende Berechtigungen auf das Zielverzeichnis haben
- Falls nötig, muss der SQL Server auf dem NFS Server eingetragen werden das er verbinden kann
Sobald dies eingerichtet ist muss auf dem SQL Server ein NFS Client installiert werden. In meinem Fall habe ich die Services for UNIX von Microsoft installiert (http://www.microsoft.com/downloads/details.aspx?familyid=896C9688-601B-44F1-81A4-02878FF11778&displaylang=en). Da reicht es den NFS Client und die User Name Mapping Komponenten zu installieren:
Mehr ist nicht nötig.
Nun muss ermittelt werden ob es einen NIS Server gibt, der die Linux Accounts zentral managed, oder ob die User Verwaltung lokal gemacht wird.
In meinem Fall war kein NIS Server verfügbar. Der NFS Server arbeitete nur mit lokalen passwd und group files.
Nach Beendigung der Installation müssen die folgenden Schritte ausgeführt werden bevor ein Backup möglich ist. Diese Schritte mappen den SQL Server Agent Service Account zum Linux Account:
- Die passwd und group files müssen vom Linux Server zum SQL Server kopiert werden (z.B. in C:\WINDOWS\system32\drivers\etc)
Es reicht die Zeilen zu kopieren die die relevanten User und Gruppeninformationen enthalten (SQL Agent Account und dazugehörige Gruppe) - Öffnen Sie das Services for UNIX Admninistration Tool
- Wechseln Sie zu User Name Mapping im linken Fenster
- Wählen Sie Use Password & Group files und fügen Sie die zwei kopierten Files (passwd & group) in die darunterliegenden Felder
- Wechseln Sie zu Maps (Ganz oben in Fenster)
- Windows Domain Name auswählen und die aktuelle Domain anklicken
- Klicken Sie auf Show User Maps
- Klicken Sie auf List Windows Users und auf List UNIX Users
- Wählen sie den entsprechenden Windows und UNIX User aus denListen und klicken Sie auf Add
- Widerholen Sie diesen Schritt für jeden Benutzer der gemappt werden soll
- Klicken Sie auf Show Group Maps und mappen Sie die nötigen Gruppen (z.B. Windows Users Gruppe -> UNIX Users Gruppe)
- Klicken Sie auf Apply (ganz oben im Fenster)
- Falls gewünscht können die Mappings über Map Maintenance/Backup your Mapping Configuration gesichert werden. Die Ziel-Datei muss aber schon existieren.
Nun kann der Backup-Job so eingerichtet werden dass das Ziel für das Backup via UNC Pfad zum NFS Share erfolgt.
Es könnten Probleme auftauchen falls dem SQL Server nicht erlaubt ist auf dem NFS Server via NFS zuzugreifen. Ihr UNIX/Linux Admin kann Ihnen da bestimmt weiterhelfen.
Diese Konfiguration bringt mit sich dass es nicht mehr möglich ist über das GUI ein Restore auszuführen. Das GUI benutzt die Anmeldeinformationen des aktuellen Benutzers um auf das File System zuzugreifen. Dies schlägt fehl.
Was auf jeden Fall funktioniert ist eine Datenbank über den RESTORE Statement wiederherzustellen. Es muss nur der UNC Pfad zum NFS Server als Quelle angegeben werden.
Seit dem 17. April ist das Cumulative Update Package 7 (CU7) für den SQL Server 2005 mit Service Pack 2 verfügbar. Unter http://support.microsoft.com/kb/949095/en-us sind sämtliche Verbesserungen aufgelistet. Diese betreffen hauptsächlich den Bereich Analysis Server und adressieren da einige Probleme im Zusammenhang mit Performance.
Das Cumulative Update Package 6 (CU6), welches Mitte Februar erschienen ist und unter http://support.microsoft.com/kb/946608/en-us beschrieben wird, wurde schon fast übersehen ;-) Bei unseren Kunden ist aktuell am meisten das CU5 im Einsatz (Buildlevel 3215), welches sehr stabil auch im Clusterumfeld läuft.
Es stellt sich nun die Frage, ob diese Cumulative Updates immer eingespielt werden sollen? Natürlich heisst auch hier die Antwort: it depends ;-)
Läuft das System stabil und wird kein vorhandener Bug durch ein CU adressiert, soll nicht upgedatet werden. Gerade in grösseren Umgebungen empfehlen wir, auf einem einheitlichen Level zu fahren und nicht sämtliche Versionen zu mixen. Nach unserer Meinung ist es aber definitiv notwendig, nach SP2 mindestens das CU3 (Build 3186) nach zu installieren. Service Pack 2 alleine birgt viele Probleme und Risiken.
Wann kommt denn das Service Pack 3 für SQL Server 2005? Gemunkelt wird vieles, vom Release im Juni bis zum gemeinsamen Release mit SQL Server 2008. Lassen wir uns überraschen...
Wer wissen möchte, auf welchem Stand seine SQL Server sind, gibt es hier eine schöne Übersicht aller Builds von SQL Server 7 bis 2008: http://sqlserverbuilds.blogspot.com/
Nach der Installation des Cumulative Hotfix Package 5 für Service Pack 2
http://support.microsoft.com/kb/943656/en-us
vom SQL Server 2005 kann es sein, dass das Update als "failed" markiert wird. Der SQL Server läuft aber danach wieder einwandfrei.
Im Management Studio steht sogar der aktuelle Patchlevel der Instance auf 9.00.3215 ?!
Was allerdings sehr irritiert, ist die Tatsache, dass wir nun eine neue DB haben:
"temp_MS_AgentSigningCertificate_database" ??
Nach diesen erfolglosen einspielen des Patches werden u.a Jobs, welche nicht SysAdmins
gehören oder angelegt worden sind, nicht mehr sichtbar sein.
Der Grund dafür dürfte sein, dass die Permissions der MSDB nicht mehr korrekt gesetzt werden können, trotz aller vermeintlicher richtigen Einstellungen.
Wieso ist denn überhaupt diese Datenbank vorhanden und für was wird sie benötigt?
Die genannte Datenbank "temp_MS_AgentSigningCertificate_database" kann während des Updateprozesses nicht gelöscht werden. Sie wird, wie der Name schon vermuten lässt, nur vorübergehend gebraucht, nämlich um während des Upgrades die Sicherheits-Zertifikate aus der master Datenbank zu speichern.
Einige Nachforschungen deuten auf mehrere mögliche Ursachen.
Folgende Punkte sind zu prüfen:
1. Wie ist die "Database Default Location"?Gehen Sie in das Management Studio, Server Properties | Database Settings | und prüfen Sie die Database Default Locations für Daten- und Log- Dateien. Hier sollten gültige Pfadangaben stehen.
2. Wie ist der Installationspfad der SQL Server Instanz?
Es gibt bekannte Problem beim Einspielen von Service Packs oder Fixes, wenn der Installationspfad der Instanz spezielle Zeichen enthält, wie etwa ein Komma, Semikolon etc. Wenn das zutrifft, wird es schwierig, was eine nachträgliche Korrektur anbetrifft.
Folgende Fehlermeldung kann dem Installations-Summary-Log entnommen werden:
"MSP Error: 29537 SQL Server Setup has encountered the following problem: [Microsoft][SQL Native Client][SQL Server]Service Broker message delivery is not enabled in this database. Use the ALTER DATABASE statement to enable Service Broker message delivery.. To continue, correct the problem, and then run SQL Server Setup again"
Die Lösung des Problemes ist wie folgt:
Auf der entsprechenden Instance in der MSDB zuerst der Broker Service einschalten
USE MSDB
GO
ALTER DATABASE MSDB SET ENABLE_BROKER
GO
Falls das länger als 1sec dauert, soll zuerst der Agent-Service restarted werden.
Danach kann das Cumulative Hotfix Package 5 für Service Pack 2
http://support.microsoft.com/kb/943656/en-us ohne weitere Probleme fehlerfrei installiert werden.
Auch in St. Gallen sind am letzten Tech@Night Anlass zum Thema SQL Server 2008 noch Fragen aufgetaucht, welche ich wie versprochen in meinem Blog nochmals zusammenfasse.
Wird SQL Server 2008 Flow-Field Technologie unterstützen, welche vorallem im Navision Umfeld genutzt wird?
- Bis jetzt ist nichts bekannt, dass die Flow-Field Technologie in SQL Server 2008 implementiert wird. Eine Anfrage meinerseits an Microsoft ist noch offen. Sollte sich dieser Status ändern, werde ich dies selbstverständlich in diesem Blog beschreiben.
Ist eine Side-by-Side Installation mit SQL Server 2000 möglich?
- Bezüglich Installation und Upgrade gelten für die aktuelle CTP folgende Einschränkungen:
- Upgrade From SQL Server 7.0 ist nicht supported.
- Installation side-by-side mit SQL Server 2000 ist nicht supported.
- Upgrade von SQL Server 2000 MSDE ist nicht supported.
- Upgrade von SQL Server 2000 (64-bit)ist nicht supported.
- SQL Server Reporting Services können nicht side-by-side in 32-bit und 64-bit cross-platform Szenarien installiert werden.
- SQL Server Integration Services können nicht side-by-side in 32-bit and 64-bit cross-platform Szenarien installiert werden.
- Upgrades werden geblocked wenn folgendes zutrifft:
- SQL Server 2000 tiefer als SP4.
- SQL Server 2005 tiefer als SP2.
Können mit Daten, welche mit dem Spatial Datentyp abgespeichert wurden auch Berechnungen angestellt werden?
- Ja, die Daten können für Kalkulationen verwendet werden. Ich möchte diesbezüglich auf einen Blogeintrag von Rob Fairley verweisen, welcher SQL Server MVP in Australien ist: http://msmvps.com/blogs/robfarley/archive/2008/01/08/querying-distances-using-spatial-data-types-in-sql-2008.aspx
Am 07.02.08 findet die letzte Veranstaltung dieser Reihe in Luzern statt.
Anmeldung: http://www.microsoft.com/switzerland/partner/de/trainings/techatnight/default.mspx
Die Folien zum Anlass stehen unter http://www.microsoft.com/switzerland/partner/de/trainings/archiv/atnight.mspx zum Download bereit...
Herzlichen Dank nochmals all denen, welche den Microsoft Tech@Night Anlass zum Thema SQL Server 2008 am 17. Januar in Zürich besucht haben.
Wie versprochen kommt hier ein kurzes Wrap-Up zu Fragen, die im Verlaufe des Abends aufgetaucht sind:
Gibt es ein Standardablaufdatum für Zertifikate?
- Ja, das Zertifikat, welches ich in der Demo gezeigt habe für die Transparente Datenbankverschlüsselung läuft exakt 1 Jahr nach Erstellung ab, wenn beim Kreieren kein Expiry Date mit angegeben wird!
Was ist http.sys exakt, auf welches SQL Server Reporting Services neu aufsetzt?
- http.sys resp. die HTTP Server API von Windows Server lässt Programme über HTTP kommunizieren, ohne IIS verwenden zu "müssen". Mehr Infos hierzu sind auch im TechNet zu finden: http://msdn2.microsoft.com/en-us/library/aa364510(VS.85).aspx
Wieso wird beim DATE Datatype die Uhrzeit mit 00:00:00.000 mitangezeigt?
- Gemäss Books Online sollte dies definitiv nicht so sein sondern der DATE Datatype sollte nur YYYY-MM-DD ausgeben. Der "Bug" ist reportet, wie auch das Syntaxhighlighting welches für dies Datentypen noch fehlt.
Weitere Daten der Tech@Nights SQL Server 2008:
24.01.08 St. Gallen
07.02.08 Luzern
Anmeldung: http://www.microsoft.com/switzerland/partner/de/trainings/techatnight/default.mspx
Sollten weitere Fragen aufgetaucht sein, freue ich mich über Kommentare auf diesen Blogeintrag ;-)
Die Folien zum Anlass stehen unter http://www.microsoft.com/switzerland/partner/de/trainings/archiv/atnight.mspx zum Download bereit...
Mehr Beiträge
Nächste Seite »