Microsoft SQL Server

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

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.:

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.:

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:

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

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.:

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 for 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:\

Weitere Links

Keywords:SQL