Glorf IT

Wenn man eine Datenbank mittels des "SQL Server Management Studios" anhängt, dann bekommt man bereits vor dem eigentlichen Anhängen an der Oberfläche angezeigt, aus wie vielen Dateien die Datenbank besteht und wo die Dateien zuletzt lagen. Nun gibt es aber Anwendungen, die für Endanwender gedacht ist, die mit der Bedienung des Management-Studios durchaus überfordert sein könnten.

Wenn man das Anhängen – z.B. nach einer Rücksicherung aus einer Datei-Vollsicherung – nicht den Anwender manuell durchführen lassen will, sondern automatisch aus der eigenen Anwendung, dann muss man auch irgendwie an diese Infos ran kommen.

Zu diesem Zweck bietet Microsoft die undokumentiere DBCC-Funktion "checkprimaryfile". Damit kann man sich die wichtigsten Infos herausholen ohne die Datenbank vorher anhängen zu müssen.

Ist die Datei tatsächlich eine MDF-Datei?

dbcc checkprimaryfile ('C:\temp\Test_data.mdf', 0)
Mit der Option "0" überprüft "checkprimaryfile", ob die Datei eine MDF-Datei ist: "0" heißt "Nein", "1" heißt "ja". Beispiel:

Welche Version hat die Datenbank?

dbcc checkprimaryfile ('C:\temp\Test_data.mdf', 2)
Mit der Option "2" ermittelt "checkprimaryfile" die Version, den Namen und die Default-Collation der Datenbank:

Das ist deswegen relevant, weil man an einen SQL-Server-2005 keine 2008er Datenbank anhängen kann. Umgekehrt zwar schon, aber dann ist das fortan eine 2008er Datenbank. Die Versionen sind folgende:

Aus welchen Dateien besteht die Datenbank?

dbcc checkprimaryfile ('C:\temp\Test_data.mdf', 3)
Mit der Option "3" ermittelt "checkprimaryfile" die Liste der Datenbank-Dateien und gibt an, wo die Dateien zuletzt lagen als sie noch angehängt waren:

Im Beispiel sieht man, dass die Datenbank-Dateien zuletzt im Verzeichnis "C:\Programme\Microsoft SQL Server\MSSQL10.SQL2008SE\MSSQL\DATA\" lagen. Jetzt stehen sie im Verzeichnis "C:\temp". Daher muss man die Dateien zum Anhängen entweder wieder an den Ursprungsort verschieben oder beim Anhängen die neuen Pfade aller Dateien angeben.

Details zu den Datenbank-Dateien

dbcc checkprimaryfile ('C:\temp\Test_data.mdf', 1)
Mit der Option "1" wird die Datenbank wird kurzzeitig angehängt, Details zu den Dateien analysiert und dann wieder getrennt. Das geht freilich nur, wenn die Log und Secobdary-Files unter dem Pfad ansprechbar sind unter dem sie in der MDF-Datei stehen.

Dazu kann man die Datenbank auch gleich selber anhängen und dann angehängt lassen.

Risiken und Nebenwirkungen

Diese DBCC-Funktion ist undokumentiert und daher in zukünftigen Versionen möglicherweise nicht mehr lauffähig oder bringt andere Ausgaben. Ich fand leider nirgends Angaben zu der Funktion. Daher fand ich obige Angaben durch Ausprobieren raus. Sie können daher falsch sein. Interessanterweise klappten die Optionen 0,2,3 auch wenn ich an einem SQL-Server-2005 eine 2008er Datenbank analysierte. Die Option 1 nicht, weil da die Datenbank angehängt werden soll.

Nächsten Dienstag, am 7.4.2009, findet in Nürnberg wieder der nächste Vortrag der SQL-PAS Franken statt. Wer schon mal etwas von Azure gehört hat und sich fragt, wie man da DAten speichert und liest, der sollte sich mit den "SQL Data Services" (SDS) beschäftigen. Und genau das machen wir an dem Abend.

Dariusz Parys (Microsoft) erweist uns die Ehre. Es ist "Technology Evangelist" bei Microsoft und daher immer mit den neuesten Microsoft-Technologien beschäftigt. Er ist vor allem bekannt durch seine praxisnahen und visionären Workshops. Das sagt er selber über den Vortrag:

Mit Windows Azure besteht die Möglichkeit Daten im Internet abzulegen. Mittels der Azure Cloud Storages und der SQL Data Services können Daten auf unterschiedliche Art und Weise bearbeitet und behandelt werden. In diesem Vortrag werden beide Komponenten erklärt und mit ein paar Demos anschaulich visualisiert.

Gastgeber ist wieder die plus-IT GmbH im Eurocom Center (Lina-Ammon-Str. 3, Gebäude 3 / 3. Stock, 90471 Nürnberg).

Wie immer ist der Eintritt frei, auch Nicht-Mitglieder sind herzlich eingeladen. Weil es bei dem Thema und Referenten garantiert sehr, sehr voll wird, bitte bei Klaus Oberdalhoff unter kob(ät)sqlpass.de anmelden, damit er weiß, ob die Stühle reichen. Wer zu spät kommt oder sich nicht anmeldet, muss eben stehen… 😉

Offenbar war bis vor kurzer Zeit die Sektorgröße von Festplatten so fix auf 512 Bytes, dass Microsoft keinen Gedanken daran verschwendete, dass es auch andere Sektorgrößen geben kann. Zur Erinnerung: ein Sektor bestimmt die Größe des Datenblockes, der von der Festplatte bzw. vom Medium gelesen wird. Das wird gerne mit der Cluster-Größe verwechselt, die durch das Dateisystem (und damit durch die Formatierung) festgelegt wird.

Microsoft hat das Schreiben des Transaktionslogs derartig auf Performance optimiert, dass sie in den Datei-Header die Clustergröße schreiben mit der die Datenbank angelegt wurde. Wenn ich nun einen neuen Server anschaffe, dessen Plattensystem (z.B. SAN) eine größere Sektor-Größe hat, z.B. 1024 Bytes, dann kann die Datenbank vom SQL-Server dort weder angehängt werden, noch können alte Datensicherungen dort eingespielt werden. Ganz schön lästig, wenn man das nach einem Systemausfall mit dem neuen Server erst merkt.

Microsoft schreibt das im Artikel "SQL Server I/O Basics, Chapter 2" so:

SQL Server is not designed to dynamically upgrade the database to the larger sector sizes. SQL Server disallows restoring or attaching a database on a system with a larger sector size; it generates an error message and prevents the restore or attach operation. Enabling a database to function by using a smaller formatted sector size than the actual sector size violates the WAL protocol because the sector size variation guarantees the log records will not be correctly aligned with the physical sector size and log records will be rewritten.

Diese Info bezieht sich auf die Versionen 2000 und 2005. Weiß jemand, ob der SQL-Server-2008 damit inzwischen zurecht kommt? Als Lösung für die eigenen Systemdatenbanken erzeugt Microsoft sie auf Festplatten mit der Sektorgröße 4K. Wenn die auf eine Platte mit kleineren Sektoren kopiert werden, dann geht das nämlich, falls die kleinere Sektorgröße ein Teiler der großen ist.

Was könnte es für Anlässe geben, dass die Sektor-Größe anders ist?

• Moderne SANs sind hier konfigurierbar,
• manche RAIDs sind konfigurierbar,
• für Solid-State-Disks bieten sich andere Sektorgrößen an und
• für USB-Sticks auch.

Wir suchen gerade nach einer Lösung, wie man die Daten in so einer Datenbank noch retten kann, wenn das alte System nicht mehr zur Verfügung steht (also kein Kopieren von A nach B möglich ist). Hat jemand eine Idee? Oder hat jemand schon mal Erfahrungen mit diesem Feature gemacht?

Heute machte mich Klaus auf die Seite "SQL Server Data Mining" aufmerksam. Hier werden alle möglichen Informationen von Microsoft zur Verfügung gestellt.

This site has been designed by the SQL Server Data Mining team to provide the SQL Server community with access to and information about our exciting data mining features.

Ich finde die Sammlung schon ziemlich beeindruckend, aber es könnte noch übersichtlicher sein. Man muss schon etwas buddeln bis man die Dinge findet, die man sucht. Besonders gut gefällt mir die Sammlung mit Artikel und "Whitepapers".

Es ist ja schon ein paar Tage her, dass Microsoft die neue Version der "Visual Studio Team Database Edition" freigab, dennoch wird sie meiner Erfahrung nach nur von einem eingeschworenen Haufen eingesetzt. Eigentlich komisch, weil sie doch jetzt jeder nutzen kann, der eine Lizenz für die Developer-Edition hat.

Deswegen gibt es jetzt im MSDN-Magazine den interessanten Artikel "Datenbankentwicklung: Einführung in neue Features in VSTS Database Edition GDR" als kleine Werbung zu lesen.

Zufällig fand ich gerade in nettes Dokument, in dem mal übersichtlich alle Fragen zum Lizenzmodell des "SQL Server 2008 Enterprise Edition" erklärt werden…

Hier ist der Download (PDF).

Kennt jemand die Pendants zu den anderen Editionen?

Als wir auf den Microsoft SQL-Server umstiegen, empfand ich es als großen Fortschritt, dass man bei einem Backup ein Passwort angeben kann. Nur wer das Backup kennt, der kann die DB anhängen. Leider wird genau das Feature nach dem SQL-Server-2008 abgeschafft. So steht es jedenfalls in den Books Online:

This feature will be removed in the next version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature.

Schon schade, ich kann mir gar keinen Grund dafür denken. Zu meinem großen Erstaunen sehe ich gerade in den "Deprecated Database Engine Features in SQL Server 2008", das auch das RESTORE mit Passwort nicht mehr funktionieren wird. Wird das Passwort beim Einspielen alter Backups dann ignoriert oder kann man die dann einfach nicht mehr einspielen? Letzteres wäre schon ärgerlich…

Vermutlich würde MS jetzt argumentieren, dass das Backup-Passwort kein starker Schutz war und man mit Zugriff auf die Datei, die Datenseiten ja auch im Klartext lesen könne. Stimmt, aber für die Gelegenheitsdiebe war es eine echte Hürde… MS würde vermutlich damit trösten, dass man ja nun "transparent data encryption" verwenden könne. Dann sind ja auch die Daten im Backup verschlüsselt. Aber – Pech gehabt – das ist nur ein Feature der Enterprise-Edition.
Aber dafür kann man Backups jetzt in allen Editionen komprimieren. Bisher musst man es noch zippen und konnte enorme Platzeinsparungen erzielen.

PS: Wer gerade erst mit Datensicherungen anfängt, dem empfehle ich den Artikel "Best Practices for Backup And Restore with SQL Server 2005".

Heute war schon alleine deswegen ein guter Tag, weil mir jemand eine kluge Frage zu SQL stellte. Manche Dinge vergisst man ja wieder, aber ich weiß noch genau, wie wenig ich zu Beginn meiner Beschäftigung mit Datenbanken verstand, warum bei verschachtelten Transaktionen zwar genau so viele COMMITs wie BEGIN-TRANSACTIONs nötig sind (leuchtet ein), aber ein ROLLBACK immer bis zum Beginn der äußeren Transaktion zurück rollt… 🙂

Als ich heute einem Kollegen auf diese Frage antwortete, fand ich in "meinen" TSQL-Richtlinien neben einer etwas langweiligen Erklärung den Hinweis (sinngemäß):

Verschachtelte Transaktionen sind im günstigsten Fall wirkungslos und sollten daher nicht eingesetzt werden.

Dabei fällt mir noch etwas ganz anderes ein: Hat eigentlich schon jemand mal einen sinnvollen Einsatz für Savepoints gefunden? Unsere Anwendungen haben zwar ein paar längere Transaktionen, aber wir kämpfen dann meist mit den Nebenwirkungen, insbesondere der Lock-Escalation. Aber ich bevorzuge viele kleinere Transaktionen hintereinander… Geschmackssache?

Was man im Internet so über die kommende SQL-Server-Version mit Codenamen "Kilimanjaro" liest ist merkwürdig wenig. Ich habe mal ein paar Infos zusammengetragen, die mir zuverlässig erscheinen.

Am 6.10.2008 veröffentlichte Microsoft in einer Presseerklärung erste Infos:

• Hauptfeatures seien "self-service analysis capabilities code-named “Project Gemini”" und "self-service reporting".
• Freigabe sei im ersten Halbjahr 2010 (vorher werde es wieder ein CTP geben).

Das klingt alles sehr BI-lastig. Außerdem ein Release noch nicht mal 24 Monate nach SQL-Server 2008? Interessant finde ich die Aussage dazu im Artikel "Die nächste Version von SQL Server – Ankündigungen von der BI Konferenz:

SQL Server Kilimanjaro. Das wird die nächste Version von SQL Server. Es ist eine Zwischenrelease, die vor allem im Bereich Business Intelligence neue Funktionalitäten bringt. Das ist nicht die nächste Hauptrelease von SQL Server (die also wahrscheinlich eine Versionsnummer 11 hat und wie angekündigt 24-36 Monate nach SQL Server 2008 erscheinen wird), sondern eine Zwischenversion.

So sieht es auch Michael Otey im SQL Server Magazine:

While the marketing spin on the new release will be about customer choice, don’t forget that Microsoft plans for product releases on a major-minor cycle. Each server product gets a major release about every four years and then is followed by a minor R2 release about two years later. In the past, customers waited a long time (around five years) for products such as Windows XP and SQL Server 2005, so I can understand why Microsoft wants to shorten the release cycle. However, two years is too short, especially for an infrastructure product like SQL Server.

In einem Bericht von der Konferenz "SQL PASS 2008" wird der Vortrag von Ted Kummert beschrieben. Hier heißt es nun wieder anders:

Kilimanjaro – Keep an eye out for Kilimanjaro. This is the code name for the next release of SQL Server. It is expected to be released in 2010 or 24 to 36 months after the SQL Server 2008 release. One of the items that caught my eye was the ability to manage multiple SQL Server instances and migrate code seamlessly between the environments with a 'DAC Pack' which is a consolidated set of code.

Details zum "DAC Pack" (inkl. wirklich interessantem Film) findet man bei Neil Hutson:

Second was the Data-Tier Application Component (DAC) which combines details about the application that the developer is building and turns schema into something called a "DAC PACK" which can be offered to the Fabric Control Point to aid in the deployment of the data tier within the Managed SQL Server Fabric.

Der Film lässt leider offen, ob das auch für Updates gilt, aber ich denke mal doch. Was sollte ein Deploy, der nur auf der grünen Wiese aufsetzen kann?

Auf Ella Maschiach's BI Blog fand ich den Hinweis auf den ersten CTP1. Der Fragebogen steht noch online, aber die Anmeldefrist war bis 31.12.2008.

Komischerweise fand ich keine neueren Infos. Kennt jemand relevante Links aus diesem Jahr?

Beim gestrigen Vortrag zum Thema "Snapshot Isolation" kamen ein paar Themen zur Sprache zu denen wir nicht mehr alle Details zusammen bekamen. Hier ein paar Schnipsel zum Thema "Lock Escalation". Eine sehr gute und kompakte Sammlung von Infos findet man im Artikel "Lock Escalation in SQL2005" von Sunil Agarwal.

Eine Lock Escalation von Row-Locks auf Table-Locks wird ausgelöst, wenn

• die Zahl der gehaltenen Sperren die Schwelle von 5000 überschreitet oder
• der für Sperren genutzten Speicher 40% des aktuellen Cache überschreitet (wenn sp_configure-Option "locks" = 0) oder
• der für Sperren genutzte Speicher 40% des für Sperren konfigurierten Speichers überschreitet.

Gestern lernte ich, dass der Schwellwert von 5000 am SQL-Server-2008 konfigurierbar sei. Das klingt gut.

Zudem sprachen wir auch über Möglichkeiten, wie man gezielt verhindern kann, das die Sperren eskaliert werden. Auch das findet man im oben genannten Artikel sehr gut erklärt.

Für einen Arbeitskreis dürfte ich mir letzte Woche als Krankheitsvertretung sehr kurzfristig Gedanken zum Thema "verteilte Transaktionen in einer service-orientieren Welt" machen. An dem Tag fielen satte 6 Mitarbeiterinnen und Mitarbeiter meines Teams aus. Einige hatten nur die schnelle Krankheit (1 Tag Magen-Darm), andere waren die ganze Woche (einer sogar 2 Wochen) "disabled". Jedenfalls konnte ich an dem Tag prima üben über etwas zu reden von dem ich keine Ahnung habe… Man sagte mir, dass sei für das persönliche Weiterkommen förderlich – ich hoffe das stimmt nicht. 😉

Jedenfalls habe ich bei meiner Suche zum Thema "verteilte Transaktionen mit .net" eine kleine Linksammlung angelegt, die ich hiermit der Öffenlichkeit zur Verfügung stelle. Wenn jemand weitere Artikel zu dem Thema kennt, dann bitte ich um einen Link als Kommentar.

Die ".net Enterprise Transaction Services" bieten scheinbar genau das, was man in einer service-orientieren Welt so braucht: offenbar können hier mehrere Services auf unterschiedlichen Computern an der gleichen verteilten Transaktion teilnehmen. Stimmt das? Und wenn ja, wo ist der Haken: Performance?

Den kurzen, übersichtlichen Artikel "Managing Distributed Transactions with ADO.NET 2.0 using TransactionScope" zum Thema TransactionScope fand ich auch hilfreich.

Der Artikel "Distributed Transactions in .NET 2.0" ist zwar auch weiterführend, aber tendenziell etwas mager.

Der etwas älterere Artikel "HOW TO: Perform a Distributed Transaction with a .NET Provider by Using ServicedComponent in Visual C# .NET" von Microsoft hat mir nur bedingt weitergeholfen.

Wer sich – wie ich – nichts unter einer Modellierungssprache vorstellen kann, der findet im Artikel "The Oslo Modeling Language Specification" vielleicht erste Ansatzpunkte:

The "Oslo" Modeling Language M is a modern, declarative language for working with data. M lets users write down how they want to structure and query their data using a convenient textual syntax that is convenient to both author and read.
M does not mandate how data is stored or accessed, nor does it mandate a specific implementation technology. Rather, M was designed to allow users to write down what they want from their data without having to specify how those desires are met against a given technology or platform. That stated, M in no way prohibits implementations from providing rich declarative or imperative support for controlling how M constructs are represented and executed in a given environment.

Alternativ dazu finden sich auch im Artikel "Build Metadata-Based Applications With The “Oslo” Platform" von Chris Sells Ansatzpunkte. Aber ehrlich gesagt, habe ich es immer noch nicht richtig verstanden wo der große Gewinn liegen soll… Wahrscheinlich liegt es daran, dass ich mich erst mal rantasten muss, was denn eine "Modellierungssprache" eigentlich ist.