Glorf IT

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?