Glorf IT

Wer sich Umfrageergebnisse anschaut, der muss wissen, dass eine Überlegung noch weit weg ist von tatsächlichen tun. Aber wenn in einer Befragung der deutschen Oracle-Anwendergruppe (PDF) drei Viertel der Gefragten sagen, dass sie sich einen Wechsel zu einem anderen Anbieter vorstellen können, dann ist das schon ein starkes Votum. Wenn Oracle hier nicht massiv gegen steuert, dann dürfte sich deren Anteil im Markt der virtualisierten Systeme bald rapide reduzieren. Denn Virtualisierung ist schon ein so deutlicher Kosteneinsparer, dass sich auch ein Systemwechsel rentieren kann. O-Ton Heise-Online im Artikel "Oracle-Kunden missfallen Konditionen für virtualisierte Datenbanken":

Knapp 80 Prozent der Befragten verwenden VMWare zur Virtualisierung, 90 Prozent sind mit den Lizenzbestimmungen unzufrieden. Nahezu drei Viertel könnten sich vorstellen, wegen der aktuellen Lizenzbestimmungen die Datenbank eines anderen Herstellers in einer virtuellen Umgebung zu betreiben. Nach Auffassung der DOAG sind die Lizenzbedingungen von Konkurrenzprodukten wie DB2 (IBM), SQL Server (Microsoft) und Sybase (SAP) attraktiver, da bei ihnen Kosten nur für die tatsächlich von der Datenbank genutzten Cores anfallen.

Woher kommt das? Man muss pro Oracle Installation für alle physischen CPUs zahlen, selbst wenn nur wenige CPUs der VM zugeordnet sind. Man zahlt also doppelt und dreifach. Neben den extremen Kosten kommt aber auch noch der Support hinzu: nur 8% der Kunden sind mit dem Oracle-Support bei Virtualisierung zufrieden. Daher können sich 72% vorstellen den DB-Anbieter zu wechseln… Krass.

Weiterführender Link (PDF)

Nach zähem Ringen mit Microsoft (Bug oder Feature) erhielten wir vor gut zwei Monaten einen Test-Fix mit dem man unter Windows 7 tatsächlich eine korrekte VSS-Sicherung von SQL-Server-Datenbanken durchführen kann.

Als wir das Problem feststellten, konnten wir es zunächst gar nicht glauben, weil sogar mit dem guten alten NTBackup von XP eine korrekte Datensicherung von geöffneten SQL-Server-Datenbanken möglich war. Dabei spricht die Sicherungssoftware über das VSS-Framework und den SQL-Writer mit dem SQL-Server und teilt ihm mit, er möge bitte kurz den IO-Freezen, erstellt dann einen Snapshot und lässt den SQL-Server dann weiter machen.
Die Windows-7-Sicherung führt die Sicherung aber über den File-Provider durch, dabei wird der SQL-Server umgangen und einfach die geöffneten Dateien gesichert. Ursache ist, dass die Liste der VSS-Writer hart kodiert wurde und offenbar ein paar als unnötig betrachtet wurden.

Der für uns erstellte Hotfix KB2288055 ist mittlerweile public und wird wohl auch im kommenden SP1 für Windows 7 enthalten sein. Dann kann man die Liste der VSS-Writer über einen Registry-Key erweitern…

Offenbar waren wir nicht die einzigen, die das Problem entdeckten. Im Juli wurde dazu bei MS-Connect ein Wunsch eingetragen. Dass zeitgleich dazu der Fix erstellt wurde, wird dabei in den Kommentaren bis heute nicht erwähnt. Seltsam…

PS: Auf den Connect-Eintrag wurde ich heute über OPIs SQL Blog aufmerksam. Leider erlaubt er keine Kommentare, daher musste ich es mit einem eigenen Artikel und einem Trackback versuchen… Leider vergeblich. 😉

Update 20:30h: Mein Versuch eine Problemlösung bei MS-Connect einzutragen ist wohl eher blöd gelaufen. Dort kann man keine Verweise eintragen. Daher sieht mein Kommentar etwas bescheiden aus… Naja, wer weiß was ein VSS-Backup ist, der wird es wohl trotzdem lesen können. Außerdem kann ich sehen, dass es in Redmond jetzt 11:30h ist. 🙂

Nachdem ich im August bei unserem Sommerloch-Entspannungstreffen den Kopernikus-Biergarten (besser bekannt als Biergarten am Krakauer Haus) kennenlernte, geht es nun wieder mit einem Vortrag bei der SQL-PASS-Franken weiter. Diesmal geht es um das Spannungsfeld zwischen Cracker und Security:

In den letzten Monaten tritt das Thema Datenschutz und Datenmissbrauch immer stärker an die Öffentlichkeit. Maßnahmen zum Schutz der Sicherheit werden von Managern meist stillschweigend vorausgesetzt. Aber wie sehen Hacker den SQL-Server? Welche Angriffsflächen bieten sich welchen Angreifern? Der Vortrag geht auf gängige Bedrohungen ein: das Spektrum reicht von Portscans bis zu im SQL-Server eingebrachte Root-Kits. Daraus kann man ableiten wie der SQL-Server grundsätzlich abgesichert werden kann und welche Maßnahmen bei Design und Implementierung der Anwendungen beachtet werden müssen.
Wer einfache 10-Punkte-Pläne erwartet, der wird enttäuscht. Die Teilnehmer sollen vielmehr am Ende in der Lage sein eine auf Ihren Bedrohungsfall zugeschnittene Lösung zu finden.

Der Referent bin diesmal ich. Daher noch ein paar Worte zum Inhalt: Das Highlight für mich ist die Vorführung eines rudimentären SQL-Server-Root-Kits, das ins System einzuschleusen mir doch mehr Mühe machte als ich erwartet hatte. Microsoft hat zum Glück inzwischen doch schon einige Hürden aufgebaut. Der Einstieg ist die Frage was das überhaupt für Typen sind, die versuchen in unsere geschätzten Datenbanken einzudringen. Danach geht es mehr um das wie und um die Möglichkeiten die Hürden möglichst hoch zu legen. Der Schlüssel dazu sind vor allem die Anwendungen und deren Architektur.

Ich würde mich freuen, wenn recht viele kommen. Ich persönlich finde das Thema recht interessant. Es richtet sich nicht nur an Entwickler, sondern auch Administratoren und gerade auch an BIler, die nur nebenbei mit SQL Server arbeiten.

Diesmal ist der Ort neu, daher habe ich noch keine Idee, wie man da mit den Öffentlichen hin kommt. Offenbar ist Umsteigen Trumpf. Mal schauen:

Gastgeber ist die New Elements GmbH im neuem Büro (Thurn-und-Taxis-Straße 10, 90411 Nürnberg).

Der Termin ist am Dienstag, den 21.09.2010, ab 18:30 Uhr (und nicht etwa 18h, wie bei SQLPASS-Franken zu lesen).

Der Eintritt ist natürlich immer noch frei, auch Nicht-Mitglieder sind herzlich eingeladen. Bitte dennoch bei Michael Deinhard unter M.Deinhard(ät)newelements.de oder Klaus Oberdalhoff unter kob(ät)sqlpass.de anmelden, damit die Anzahl der benötigten Stühle abgeschätzt werden kann. Wenigstens drei mal musste ein Vortrag bereits wegen großen Ansturms andere Räume umziehen.

Mehr Infos hier.

Wer am 19./20.10.2010 noch nichts vor hat, der sollte sich die Agenda der SQLDays 2010 in Rosenheim mal genau anschauen. Nicht zu verwechseln mit den zeitgleich stattfindenden PowerDays/Prio-Conference in Nürnberg.

Die SQLDays beschränken sich allerdings rein auf Themen rund um Microsoft SQL-Server, was mir persönlich entgegen kommt. Die Liste der Referenten hat mich sehr erfreut, weil ich einige bekannte Namen auftauchen:
Wilfried Färber, Steffen Krause, Klaus Aschenbrenner, Markus Raatz. Auch bei den Themen wird mein Geschmack getroffen, hier meine persönlichen Highlights:

• SQL Server 2008 R2 – Was ist neu im Nicht-BI-Bereich?
• SQL Server 2008 R2: CPUs, Cores und CPU-Gruppen verwalten
• SQL Server 2008 R2 StreamInsight
• Abfrageoptimierung und Ausführungsplananalyse mit SQL Server
• Securing Analysis Services

Das Thema der Podiumsdiskussion hat mich auch schon beschäftigt: "Wo geht der SQL Server in Zukunft hin? Wie wird der SQL Server in 10 Jahren aussehen?". Microsoft würde sicher SQL Azure oder andere Schlagwörter nennen. Aber mich interessiert eher wo der SQL-Server in 10 Jahren wirklich steht. Gibt es dann nur noch In-Memory-Datenbanken? Ist BI dann mit OLTP verschmolzen, weil alles so schnell geht? Vielleicht haben die Diskussionsteilnehmer dazu gute Beiträge.

Ein Hinweis zur Agenda: Dort tauchen teilweise nur verstümmelte Session-Titel auf, die einige Fragezeichen aufwerfen. Wenn man die korrekten Titel in der Liste der Session sieht, dann ist es besser… Schade auch, dass es für die Sessions von Wilfried Färber keine Beschreibungen gibt. Wer ihn nicht kennt, sich aber für BI interessiert, der sollte ihn kennenlernen. Es lohnt sich garantiert.

Der Haken: Der Preis dürfte Überzeugungsarbeit beim Chef erfordern. Wer sich kurzfristig (bis zum 17.9.) anmeldet, kann noch 50 Euro sparen… 😉

Seit 1995 gehört es zu meinen Aufgaben die Entwickler darin zu unterstützen, wie sie bei einem Versionswechsel die Änderungen an der Datenbank zum Kunden ausrollen können. Daher las ich den Artikel "When Database Source Control Goes Bad" von Mike Mooney mit besonderem Interesse. Und es stimmt alles was er sagt.

Bei Amazon kann man sich einen ganz guten Überblick verschaffen welche Bücher zum Thema "Datenbanken" kürzlich erschienen oder demnächst erscheinen werden: Beliebte Neuveröffentlichungen in der Kategorie Datenbanken

Mein Kollege Robert macht mich auf den Artikel "SQL Server 2008 Table Valued Parameters Performance" von Scott Zurolo aufmerksam. Hier wird eine hausgemachte Lösung mittels XML als Übergabeparameter der Lösung mittels Table Valued Parameters gegenüber gestellt. Irgendwie klar, dass die TVPs besser sind. Man muss sich kostenlos registrieren, um den Artikel lesen zu können.

Früher nutzten wir immer ganz normale Tabellen in die wir die Menge an Sätzen reinschrieben, dabei wurde für alle zusammengehörigen Sätze eine gemeinsame Set-ID vergeben. Der Stored-Procedure wurde dann diese ID als Parameter mitgegeben. Bei weniger als hundert Datensätzen ist das schnell und elegant. Bei mehr als 6000 nicht mehr praktikabel, weil dann durch den Einfügevorgang die ganze Tabelle exklusiv gesperrt wird. Hier dürften die TVPs helfen.

Sehr schön ist auch die Aufstellung bei Microsoft "Table-Valued Parameters". Hier ist auch eine Gegenüberstellung zum BULK-INSERT.

Da ich selber noch nicht mit TVPs gearbeitet habe, kann ich nicht viel beisteuern. Ich könnte mir aber denken, dass es problematisch ist, dass man einen benutzerdefinierten Datentypen (UDT) anlegen muss. Wenn man den Typ beim CREATE-PROCEDURE wie beim DECLARE "on the fly" definieren könnte, dann wäre es sicher einfacher. So aber muss man bei einer Schnittstellenänderung der Prozedur gleich den UDT mit ändern.

Über den Newsletter von Simple-Talk wurde ich auf den Artikel "Creative Solutions by Using a Number Table" von Greg Larsen aufmerksam. Den dort beschriebenen Trick mit dem Zerhacken von Strings sah ich erstmals bei Itzik Ben-Gan. Ich bin fast sicher, dass ich in einem Artikel von ihm auch den Trick mit den fehlenden Datümern las.

Ohnehin hat mir der Simple-Talk-Artikel "The Helper Table Workbench" von Robyn Page und Phil Factor aus dem Jahre 2007 noch deutlich besser gefallen als der von Greg. Er ist kompakter, erklärt aber weniger.

Daher ist der Artikel von Greg für Zielgruppe Level 200, der von Robyn für Level 400.

Der kommende Patchday bei Microsoft wird neue Rekorde aufstellen. Ob unter den 34 Patches aber einer für den SQL-Server sein würde, war zunächst mal unklar. Während auf der offiziellen Seite der SQL-Server nicht erwähnt wird, wurde er in einem Blogbeitrag des Microsoft Security Response Centers (MSRC) genannt. Hier wurde der Eintrag inzwischen aber korrigiert: nicht der SQL Server wird gepatcht, sondern MSXML. Also ist der SQL Server beim nächsten Patchday nicht dabei…

Hier der Beitrag, der für Verwirrung sorgte: TechNet Blogs > The Microsoft Security Response Center (MSRC)

Mein Kollege Mark machte mich auf das Traceflag 2537 aufmerksam: Damit kann man am Microsoft SQL Server (seit Version 2005) die Ausgabe der Funktion fn_dblog steuern: Wenn eingeschaltet, dann werden Infos aus allen Logs angezeigt, nicht nur aus dem aktiven.

DBCC TRACEON (2537)

Wofür die Funktion fn_dblog sinnvoll ist? Man kann damit den Inhalt des Transaktionslogs lesen:

SELECT [Transaction Id], [Begin Time], [UID], [SPID]
FROM ::fn_dblog (NULL, NULL)

Ein recht hübsches und ausgefallenes Beispiel beschreibt Paul Randal im Artikel "Finding out who dropped a table using the transaction log".

Es ist lange her, dass eine interne Technik eines Datenbanksystems es in die Newsticker schaffte: "SQLite beschleunigt Transaktionen durch Write-Ahead-Log". Eigentlich wollte ich nun beschreiben was ein Write-Ahead-Log ausmacht und so. Aber wie ich feststellen musste, steht das auf der SQLite-Homepage bereits gut und knapp erklärt, mit Vor- und Nachteilen. Guter Service. Mein heutiger Lesetipp.

Mein Kollege Slawomir machte mich auf die ODBC-Treiber von EasySoft aufmerksam. Die Firma bietet es buntes Sammelsurium rund um ODBC an. Hier ein paar Beispiele:

• SQL-Server ODBC-Treiber für Linux und Unix
• ODBC-Access-Treiebr für Linux und Unix
• ODBC Join Engine – Mehrere ODBC-Datenquellen in einer zusammenfassen

Wer nicht nicht wusste, dass es auch 64-Bit-ODBC-Treiber gibt, der findet dort auch ein paar Erläuterungen. ODBC wurde zwar zunächst nur für 32-Bit-Systeme konzipiert, funktioniert aber auch durchaus in 64-Bit-Software, wenn es einen entsprechenden 64-Bit-ODBC-Treiber gibt.