Microsoft SQL Server

Ich bin definitiv kein SQL-Spezialist aber jeder Administrator sollte durchaus auch über den Tellerrand hinaus schauen und das Potential anderer Produkte können.

Free ebook: Introducing Microsoft SQL Server 2012
http://download.microsoft.com/download/F/F/6/FF62CAE0-CE38-4228-9025-FBF729312698/Microsoft_Press_eBook_Introducing_Microsoft_SQL_Server_2012_PDF.pdf

Nein, diese Seite beschäftigt sich nicht mit der Frage, ob Exchange nicht auch seine Daten in einem SQL-Server ablegen kann. Auch wenn das Gerücht immer wieder durch die Newsgroups und Newsticker geistern, so ist aktuell nichts davon wahr. Früher konnte man dies noch fachlich argumentieren, dass SQL eher für strukturierte Daten ist, die gleich große Felder belegen, während Mails sehr schlecht in einer Tabelle gespeichert werden können. Nun können aber SQL-Server mittlerweile auch ganz gut mit "Blobs" (großen binären Feldinhalten) umgehen und die Frage wurde immer wieder gestellt.

Warum Exchange nicht auf SQL aufbauen sollte !

Q: What about SQL? Will Exchange ever move away from ESE?
A: The future is ESE. ESE sounds "easy", SQL squeals like a pig. [Comment trademarked by an Exchange engineer; he knows who he is. We won't embarrass him here]
http://thoughtsofanidlemind.wordpress.com/2011/10/18/exchange-panel-session-at-tec-2011/

Abgesehen von der flapsigen Antwort gibt es auch eine jede Menge technische Aspekte, warum Maildaten in einer SQL-Datenbank denkbar schlecht aufgehoben sind. SQL organisiert seine Daten in Tabellen. Exchange nutzt ebenfalls Tabellen, aber dabei ist jeder Ordner eine eigene Tabelle. Im Gegensatz zu SQL, wo Tabellen eigentlich statisch sind, legt Exchange dynamische neue Tabellen an und löscht diese auch wieder. Die einzelnen Tabellen bleiben damit klein und Änderungen in der Tabelle (z.B. wenn eine neue Mail einsortiert werden muss) betreffen nur diesen Teil. Das Datenbankmodell in SQL würde sicher eher so aussehen, dass es entweder pro Mailbox oder sogar insgesamt nur eine Tabelle für die Nachrichten geben würde und vielleicht eine zweite Tabelle für Anlagen, eine weitere für Ansichten etc. In so einem Fall müssen bei einer neuen Mail aber sehr viel größere Indizes aktualisiert werden. Die IO-Last nimmt sehr stark zu. Angeblich hat Microsoft sogar einmal Exchange auf SQL laufen lassen (letztlich muss man ja nur die ESE.DLL umschreiben). Aber die IO-Last war wohl ein vielfaches höher. Vergleichen Sie mal die Reduzierung der IO-Last von Exchange 2000 über 2003 auf 2007 und nun noch mal zu 2010. Ziel ist es möglichst wenig Änderungen auf den Disks ablegen zu müssen. Und dazu sind kleinere Datentöpfe einfach besser als große Tabellen, die im Bereich einer Buchhaltung oder Warenverwaltung etc. Natürlich ihre Daseinsberechtigungen haben. Argumente gegen Exchange auf SQL wären z.B.:

  • Lizenzfragen
    Das SQL-Team möchte natürlich die Früchte ihrer Arbeit erhalten, um weiter zu entwickeln. Sicher gibt es auch SQL Compact, SQL Express etc., aber ich stellte es mir sehr schwer vor, wenn jedes Exchange-Postfach noch eine SQL-Cal oder zumindest eine SQL-Lizenz benötigt. Bei vollwertigen Sharepoint Servern ist das ja heute so.
  • Datenschutz
    Irgend welche Programmierer würden natürlich versuchen, direkt an die SQL-Tabellen zu gehen. Technisch ist das nicht zu verhindern und es wird unmöglich sein, zwischen Exchange und eigenen Skripten zu unterscheiden. Auch wenn Microsoft das Datenmodell nicht offen legt, wäre es wohl eher einfach, zumindest die Mailtexte und Anlagen zu extrahieren. Das darf nicht sein.
  • Verwaltung
    Mal ehrlich. Welcher Exchange Admin hat sich wirklich schon mal mit der Datenbank auseinander gesetzt? Sie wird installiert und läuft. Maximal werden man die Pfade schnell verschoben aber Tuning etc. wird schön Exchange überlassen, welcher das auch ganz gut selbst macht. Wollen Sie als Messaging Administrator wirklich auch noch SQL-Know-How aufbauen müssen?
  • Versionsabhängigkeiten
    SQL ist ein sehr erfolgreiches Produkt, welches aber eine Plattformtechnologie darstellt, auf der Dritthersteller gerne aufsetzen. Wäre Exchange auch nur eine SQL-Anwendung, dann wären die Begehrlichkeiten sicher groß, SQL um Funktionen zu erweitern, die Exchange zu gute kommen, aber anderen Anwendungen nicht benötigen. Diese Extrawürste müssten aber dennoch getestet und supported werden. Und welche "Version" von SQL soll Exchange denn voraussetzen ?. Wollen Sie wirklich Exchange und andere Anwendungen auf dem gleichen SQL-Server betreiben
  • 3rd PartyAddOns, Backup
    Zuletzt würde so ein grundlegender Wechsel natürlich auch Drittprodukte betreffen, die vermutlich ganz neu geschrieben werden müssten. Was machen denn die Symantecs, Ontracks etc, die heute aus einem Datenbankbackup schon einzelne Mails extrahieren können.
  • Verfügbarkeit
    Bis Exchange 2003 war das Clusterkonzept mit SQL 2000 vergleichbar. Aber was Microsoft mit Exchange 2007 LCR, CCR, SCR auf die Beine gestellt und mit Exchange 2010 DAGs weiter geführt hat, ist schon eine große Erleichterung für große Firmen. SQL kann zwar auch "replizieren" und Clustern aber nicht in dem umfang wie Exchange 2010
  • IO-Belastung

Vielleicht ist es einfach die gewünschte unabhängigkeit von den beiden großen Entwicklungsabteilungen voneinander Ich denke, dass Exchange weiter mit der Jet-Engine (Jet Blue), die sie bitte nicht mit Access (Jet Red) verwechseln dürfen, laufen wird.

Exchange und SQL als Team

Beim Betrieb von Exchange Servern fallen Betriebsdaten, an die nicht nur sicher verwahrt sondern eventuell auch ausgewertet werden müssen. So eine Auswertung kann sich über die Daten von mehreren Tagen oder Wochen erstrecken oder auch kurzfristige Informationen der letzten Minuten erfordern. Exchange schreibt sehr viele Daten mit, die in einer echten Datenbank sicher besser aufgehoben sind, z.B.:

  • IIS Logs
    Alle Zugriff auf OWA aber auch RPC over HTTP und ActiveSync erfolgen per HTTP. Mit Exchange 200 werden noch viel mehr Dienste per HTTP angesprochen. All diese Zugriff protokolliert der IIS in entsprechenden Protokolldateien mit. Eine Umstellung auf SQL ist sehr einfach möglich
  • Nachrichtentracking
    Auch das Exchange Messagetracking protokolliert für jede übertragene Nachricht entsprechende Informationen in den Dateien. Diese können zwar nicht direkt in SQL umgeleitet werden, aber Sie können dies z.B. importieren lassen, um dann Auswertungen zu erstellen
  • SMTP-Logs
    Neben dem Messagetracking schreibt auch der SMTP-Server bei entsprechende Konfiguration entsprechende Protokolldateien. die auch in SQL landen können. Zwar sind die Informationen zum Teil redundant zum Messagetracking aber aus diesen Daten können Sie ableiten, welche Clients sich z.B. mit ihrem Exchange Server verbinden und authentifiziert Mails versenden. Diese Daten sind sicher für Provider und Hoster durchaus interessant. Erlauben Sie doch einen Rückschluss auf das Anwenderverhalten.
  • POP3/IMAP4-Logs
    Auch für Hoster sind die Zugriffe auf das Postfach zum Lesen und Abholen von Nachrichten interessant, um Nutzungsstatistiken zu erhalten. Gerade da beim IMAP4 die Mails nicht vom Server abgeholt werden, ist hier die Frage nach der Nutzung und entsprechenden Belastung des Servers und der Netzwerkverbindung wichtig.

Protokolldateien haben aber die zwei gravierenden Nachteile, dass Sie als Textdateien nur sehr schwer auszuwerten sind und zudem ihren Exchange Server mit Daten auffüllen. Weiterhin haben Sie keine Funktion zur Konsolidierung, d.h. schon wenn sie zwei Frontend Server betreiben, müssten Sie genau genommen die Zugriffe von beiden Systemen zusammenführen. Zudem sind die Protokolldateien nicht immer aktuell, sondern werden mit etwas Verzögerungen geschrieben und ein Zugriff auf eine gerade aktive Protokolldatei kann eventuell den Dienst bei seinem Schreibvorgang stören.

Ich denke das sind alles Gründe, die die Ablage solcher Informationen in einer Datenbank nicht nur sinnvoll sondern geradezu gefordert erscheinen lassen.

Mit Datenbanken und ins besondere mit SQL werden Sie aber auch in Berührung kommen, wenn Sie folgende Produkte einsetzen:

  • MOM2005
    Zur Überwachung des Servers sammelt auch MOM Betriebsdaten und speichert diese in einer Datenbank
  • Sharepoint
    Als Ablösung der öffentlichen Ordner und zusätzliche Plattform für gemeinsame Daten und die Zusammenarbeit ist Sharepoint eine perfekte Plattform um neben Exchange zu existieren und in Outlook und das Intranet eingebunden zu werden.
  • WSUS
    Als kostenfreie Patchmanagementlösungen verwaltet auch der WSUS-Server seine Daten in einer SQL-Datenbank.
  • Sonstige Programme
    Vielleicht nutzt auch ihr Verwaltung des Virenscanners oder Datensicherung (z.B. BackupExec) schon lange eine SQL-Datenbank.

Alle Produkte nutzen einen SQL-Server oder die kleine Version (MSDE, WMSDE oder Express) als Datenspeicher. Sie sehen also, dass SQL überall schon drin steckt und Sie sich diesem Produkt gar nicht entziehen können. Und sie sollten SQL-Server auch nicht ignorieren.

SQL Server und SQL Express

Nun bekommen Sie SQL nicht ganz geschenkt, denn abhängig von ihrem Einsatzbereich gibt es mehrere Versionen und Varianten des SQL-Servers, die verschiedenen Einschränkungen unterliegen. Bei SQL2000 wurde zwischen der Standard, der Enterprise und der Desktop-Edition unterschieden. die Desktopvariante erlaubte nur eine Datenbank bis 2 Gigabyte und war daher, wie der Name schon sagt, eher für den Desktop oder kleine Datenbanken (z.B. Aufträge von Backupprodukten) geeignet. Dafür war sie kostenfrei. Dann gab es eine WMSDE-Version, die Microsoft als erweiterte MSDE für eigene Anwendungen genutzt hat. Sie hatte nicht mehr das Limit auf 2 GB Datenbanken aber war nur für Microsoft Produkte (WSUS etc.) nutzbar.

Die SQL Standardversion und noch mehr die Enterprise Version hingegen musste lizenziert werden und konnte mehrerer CPus, viel Speicher und ab er Enterprise Version auch im Cluster betrieben werden. Hierzu konnten dann auch die SQL-Reporting Services installiert werden, die später beschrieben werden.

Seit der Version SQL 2005 Version hat sich das Produktportfolio rund um Exchange erweitert. Es gibt nun

  • SQL Express (Kostenfrei)
    Diese Express Version kann jeder für eigene Entwicklungen nutzen, Sie sie aber beschränkt auf eine CPu, hat ein Hauptspeicherlimit und ein Datenbanklimit von 4 GB. Es gibt noch einige andere unterschiede zu den kostenpflichtigen Vollprodukten. Bitte informieren Sie sich. Zudem gibt es eine SQL Express "Advanced" Version, in der weitere Komponenten enthalten sind (250 Megabyte)
  • SQL Compact
    http://www.microsoft.com/Sqlserver/2008/en/us/compact.aspx
    Eine frei verteilbare SQL-Version die kein eigener Dienst ist, sondern im Adressraum des eigenen Programms läuft und sich daher besonders für kleinere Anwendungen eignet, die bislang Access-Datenbanken oder andere Dateiformate genutzt haben.
  • Visual SQL Developer Express (Kostenfrei)
    Analog zu den Programmen Visual Basic Express, Visual C# Express und anderen gibt es auch eine EntwicklungsUmgebung für SQL von Microsoft kostenfrei zum Download
  • SQL Reporting Services (Kostenfrei)
    Dazu gibt es die Reporting Services mittlerweile auch für die Express Version kostenfrei
  • SQL Standard und SQL Enterprise
    Dies beiden Lizenzprodukte sind die beiden großen Brüder von SQL Express und bieten z.B. Replication, Clustering, Multi CPu-Support und einiges mehr, den den Einsatz in einem unternehmen sinnvoll werden lassen.

Auch wenn Sie vielleicht von der Vielfalt erschlagen sind, so sind alle SQL-Server im Grunde genommen identisch, was die Entwicklung stark vereinfacht. Sie können eine Lösung auf einer kleinen Express-Version entwickeln und prüfen und wenn absehbar ist, dass die Leistung nicht ausreicht, können Sie die Lösung einfach portieren. Einschränkungen der SQL-Versionen sind z.B.:

  • Maximal 1 GB Hauptspeichernutzung
  • Maximal 4 GB Datenbankgröße
  • Keine Hochverfügbarkeit
  • Keine Volltextsuche

Für große und kritische Daten sind die Express Varianten daher nur bedingt geeignet aber immerhin ein guter Anfang und für Administrative Zwecke und Auswertungen meist sogar ausreichend.

SQL 2005 Express (mit SP2)
http://go.microsoft.com/?linkid=6294104

Service Pack 2 für Microsoft SQL Server 2005
http://go.microsoft.com/?linkid=6294103

Microsoft® SQL Server® 2008 Management Studio Express
http://www.microsoft.com/downloads/details.aspx?FamilyID=08e52ac2-1d62-45f6-9a4a-4b76a8564a2b&DisplayLang=de

SQL 2005 Webcasts
SQL Server Express Launch Special, Teil 1 (Level 100)
http://www.Microsoft.com/germany/technet/webcasts/eventdetail.aspx?EventID=1032298293
SQL Server Express Launch Special, Teil 2 (Level 200)
http://www.Microsoft.com/germany/technet/webcasts/eventdetail.aspx?EventID=1032298294

SQL Reporting Services

Musste man bei SQL 2000 noch einen Enterprise Server installieren um auch die Reporting Services nutzen zu können, so sind diese mittlerweile auch bei SQL 2005 SP1 enthalten. Und mit etwas Programmierkenntnis können Sie damit wunderbare Berichte basierend auf Inhalten in der Daten erstellen.

Unterstützung durch Net at Work:
Wenn Sie eine Demonstration der Reporting Services oder ein Gespräch bezüglich des Nutzens in ihrem unternehmen wünschen, dann sollten Sie das Gespräch mit Net at Work suchen. Wir nutzen die Reporting Services intern z.B. für Berichte, die ihre Daten zum einen aus Microsoft CRM und aus Microsoft Navision holen und zueinander in Beziehung setzen.

Wenn ich dazu kommen, dann sollten schon sehr bald die ersten "Tools" auch von mir diese neue Plattform nutzen.

SQL-Express und Zugang

Die Installation von SQL Express läuft in vielen Produkten "einfach so im Hintergrund" mit ab. Damit damit keine Hintertüren oder Sicherheitslöcher aktiviert werden, ist z.B. SQL-Express per Default so eingestellt, dass nur die Integrierte Anmeldung mit NT-Konten möglich ist und nur lokale Administratoren zugreifen können. Zudem sind die Verbindungen nur auf "Shared Memory" und damit auf lokale Prozesse beschränkt. Soll dies geändert werden, dann gibt es nur für die Verbindung eine entsprechende GuI. Alles andere ist Kommandozeile, Regedit und mehr. Hier meine kleine Spickliste:

Verbindung über LAN auf den Server zulassen

Die SQL-Express Instanz erlaubt per Default nur "lokale Verbindung" über den Kanal "Shared Memory". Möchte man auch über das LAN zugreifen, müssen die entsprechenden Protokolle erst frei gegeben werden. Das geht über die GuI.

Verbindung von einem Client zulassen

Auch der SQL-Client ist bei einer Express-Installation per Default erst mal nur für Shared Memory konfiguriert. Auch hier muss entsprechend Named Pipe oder TCP aktiviert werden.

Anmeldung per SQL Auth erlauben

Per Default wird nur die Windows-Anmeldung unterstützt. Zum Aktivieren der SQL-Anmeldung (um z.B.: per SA zu arbeiten), muss man die Registry bemühen. Es gibt gleich drei mögliche Pfade, an denen der Wert "Loginmode" hinterlegt sein kann

HKEY_LOCAL_MACHINE\Software\Microsoft\MSSqlserver\MSSqlServer\
HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\<Instanzname>\MSSQLServer\
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.1\MSSQLServer

LoginMode:DWORD = 1  (Integrierte Anmeldung)
LoginMode:DWORD = 2  (Integrierte Anmeldung und SQL Anmeldung)

Auf einem 64bit Server liegt der Wert wieder an anderer Stelle. Am besten suchen Sie nach "LoginMode"

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SQL Server\MSSQL.1\MSSQLServer]
"LoginMode"=dword:00000002

Damit die Änderungen aktiv werden, ist der SQL-Server Dienst und der Agent neu zu starten.

SA Kennwort setzen

Wenn das Kennwort vergessen wurde, ist ein Zurücksetzen auch relativ einfach. SQLCMD hilft ihnen dabei. By Default ist das Kennwort des Benutzers "SA" leer. Das ist kein Problem, solange die SQL-Anmeldung deaktiviert ist. Sie sollten also schleunigst das Kennwort ändern.

C:\> sqlcmd -S SQLSERVER\INSTANCE
1>sp_password @new = ’newpassword’, @loginame = ‘sa’
2>go
1>exit
C:\

Bei "Loginame" handelt es sich NICHT um einen Schreibfehler. Das ist nur ein "n"

SA Konto entsperren

Viele Fehlversuche sperren natürlich den SA.

C:\> sqlcmd -S SQLSERVER\INSTANCE
1>ALTER LOGIN sa WITH PASSWORD = ‘neuesKennwort’ uNLOCK
2>go
1>exit
C:\

SA aktivieren

Viele Fehlversuche sperren natürlich den SA. Mit folgender Sequenz lässt sich das Konto wieder entsperren

C:\> sqlcmd -S SQLSERVER\INSTANCE
1>ALTER LOGIN sa ENABLE
2>go
1>exit
C:\

  • 319930 How to connect to an instance of SQL Server Desktop Edition or of SQL Server 2005 Express Edition
  • 322336 How to verify and change the system administrator password in MSDE or SQL Server 2005 Express Edition

SQL Backup

Wenn ihnen ihre Daten in der SQL-Datenbank wichtig sind, dann sollten sie diese natürlich auch sichern. Aber ein Backup ist auch wichtig, wenn Sie z.B. "Vollständig" als Datenmodell fahren. Dann schneidet SQL die Transaktionsprotokolle nicht ab und ihre Festplatte wird sehr schnell voll. Es gibt gleich mehrere Optionen einen SQL-Server zu sichern.

  • VSS
    SQL unterstützt "Schattenkopien". Mit dem passenden Backup können Sie die SQL-Datenbank z.B: als Teil des SystemState mit sichern.
  • SQL-Backup
    Der zweite Weg ist das in SQL eingebaute Backup, welches sie per SQLCMD, OQL oder SQL_Agent starten können
    Eine Möglichkeit ist z.B.: die Ablage des SQL-Befehls in einer SQL-Datei und dem Regelmäßigen Start per Taskplaner.
BACKUP DATABASE [DBANEM] TO DISK = N'C:\SQLBACKUP\DBNAME.BAK' WITH NOFORMAT, INIT, NAME = N'DBNAME - Full Database Backup', SKIP, NOREWIND, NOUNLOAD,STATS = 10
GO
sqlcmd.exe -S np:\\.\pipe\MICROSOFT##WID\tsql\query -i C:\SQLBACKUP\DBNAME.sql

Allerdings müssen Sie neben der Taskplanung natürlich auch noch die Überwachung mit regeln.

Weitere Links