Microsoft hat einen Product Guide zum aktuellen CTP3 Release des im kommenden Jahres erscheinenden SQL Server (Denali) veröffentlicht.

Das 456 MB große Paket kann im Microsoft Download Center heruntergeladen werden. 
In diesem Paket sind unterschiedlichste Materialien enthalten, die dem interessierten Anwender die wesentlichen Neuerungen näher bringen.

Die folgenden Materialien sind in dem Paket enthalten:

• 14 Datenblätter zum CTP3 Release
• 8 PowerPoint Präsentationen
• 5 Whitepaper
• 44 Links zu Online-Videos inklusive 26 Präsentationen von der US-TechEd 2011
• 6 durchklickbare Demos
• 26 Links zu Online-Dokumentationen
• 13 Hands-On Lab Preview Dokumente
• 13 selbstlaufende Demos

Nach dem das Paket heruntergeladen und entpackt wurde befinden sich im Zielverzeichnis mehrere Dateien und Unterordner. Um den Product Guide zu starten, muss die Datei STARTHERE.CMD ausgeführt werden. Es öffnet sich dann der definierte Standard-Browser mit der Startseite des Product Guides. Über die Startseite lassen sich dann alle angebotenen Ressourcen auswählen.

Download des Product Guides:
http://www.microsoft.com/download/en/details.aspx?id=27069

Download SQL Server Code Name “Denali” CTP3:
http://www.microsoft.com/betaexperience/pd/SQLDCTP3CTA/enus/default.aspx

Das Servicepack hat die Versionsnummer 10.50.2500.0.

Zu den Neuerungen gehören:

• Dynamic Management Views for increased supportability
• ForceSeek for improved querying performance
• Data-tier Application Component Framework (DAC Fx) for improved database upgrade
• Disk space control for PowerPivot

Weitere Info befinden sich auf der Download Seite von Microsoft.

Am 29.09.2010 hat Microsoft das Servicepack 2 für den SQL Server 2008 veröffentlicht.
Der SQL Server hat nach dem Einspielen des SP die Version 10.00.4000.00.

Auf dieser Webseite kann das Servicepack heruntergeladen werden:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=8fbfc1de-d25e-4790-88b5-7dda1f1d4e17&displaylang=en

Dieses SP ist für folgende Versionen geeignet:

• Microsoft SQL Server 2008 Standard
• Microsoft SQL Server 2008 Standard Edition for Small Business
• Microsoft SQL Server 2008 Developer
• Microsoft SQL Server 2008 Enterprise
• Microsoft SQL Server 2008 Express
• Microsoft SQL Server 2008 Express with Advanced Services
• Microsoft SQL Server 2008 Web
• Microsoft SQL Server 2008 Workgroup
• Microsoft SQL Server 2008 Analysis Services
• Microsoft SQL Server 2008 Reporting Services

Die Release Notes finden Sie hier:
http://social.technet.microsoft.com/wiki/contents/articles/microsoft-sql-server-2008-sp2-release-notes.aspx

Ein falsches bzw. nicht konfiguriertes Backup kann dazu führen, dass das Transaction Log die Festplatte vollständig  beschreibt und die betroffene Datenbank nicht mehr verfügbar ist. 
Aus diesem Grund werde ich hier den Zusammenhang zwischen den Transaction Log und dem Recovery Model der Datenbank beschreiben.

Funktion des Transaktion Log

Das Transaktion Log dient zur Ausfallsicherheit. Abhängig vom Recovery Model verhält sich das Transaction Log unterschiedlich.
Zuerst werde ich die allgemeine Funktion des Transaktion Log beschreiben, später im Abschnitt Recovery Model werde ich dann auf die Besonderheiten eingehen.

Das Transaction Log tritt nur bei Schreibvorgängen in Aktion, z.B. insert, update usw.

Nehmen wir eine Insert Transaktion.
Diese Transaktion wird vom SQL Server angenommen. Bevor er diese in die Datenbank übernimmt, wird sie in den Arbeitsspeicher (RAM) und in das Transaction Log geschrieben.
Dieser Vorgang geschieht gleichzeitig und hat das Ziel die Wartezeit für den Benutzer/Prozess zu reduzieren.

Sollte nun z.B. ein Stromausfall eintreten, bevor die Transaktion in die Datenbank übernommen wurde, wäre der Inhalt im RAM verloren und die Datenbank inkonsistent.

Das Transaction Log stellt in diesem Fall die Ausfallsicherheit für den Arbeitsspeicher da.
Solange eine Transaction nicht in die Datenbank übernommen wurde, ist diese im Log auch noch als “aktiv” gekennzeichnet.
Sollte z.B. nach dem Stromausfall der Server wieder starten, erkennt der SQL Server, dass es noch nicht abgeschlossene Transaktionen im Log gibt und überführt diese zuerst in die Datenbank bevor diese wieder erreichbar ist.

Im Normalbetrieb werden die im Arbeitsspeicher abgelegten Transaktionen sobald wie möglich in die Datenbank übernommen; je nach Auslastung des SQL Servers kann es jedoch auch einige Zeit dauern.
Eine genaue Zeitangabe kann jedoch nicht gemacht werden.

Sobald eine Transaktion in die Datenbank übernommen wurde, wird diese aus dem Arbeitsspeicher gelöscht und im Transaction Log als “übernommen” markiert.

wird der SQL Server geplant beendet, so werden zunächst alle Transaktionen in die Datenbank übernommen und anschließend der Dienst beendet.

Wie nun mit den “fertigen” Transaktionen im Log weiter verfahren wird, das ist abhängig vom Recovery Model.

Recovery Model

Der MS SQL Server kennt drei Recovery Modele Simple, Full und Bulk-logged standardmäßig ist bei allen neuen Datenbanken Full eingestellt. Diese Einstellung für neue Datenbaken kann angepasst werden indem das Recovery Model der model-Datenbank geändert wird.
Diese Datenbank dient als Vorlage für alle neuen Datenbanken.

Die Einstellung des Recovery Model kann jederzeit auch im laufenden Betrieb geändert werden, beachten Sie jedoch, dass diese Änderung auch Auswirkung auf Ihre Backup Strategie hat und pro Datenbank eingestellt wird.

Simple

Diese Model ist, wie der Name schon sagt, das einfachste. Sobald eine Transaktion in die Datenbank übernommen und im Log quittiert wurde, wird diese auch im Log gelöscht.
Das bedeutet auch, dass das Log nur einen geringen Speicherplatz Festplatten benötigt.

Wenn für eine Datenbank gar kein Backup eingerichtet werden soll, muss für diese Datenbank das Recovery Model Simple ausgewählt werden, weil ansonsten das Transaction Log die Festplatte vollschreibt und der SQL Dienst gestoppt wird.

Full

Im Gegensatz zu “Simple” werden die Transaktionen nach erfolgreicher Übernahme in die Datenbank nicht gelöscht, sondern nur quittiert.
Das Transaction Log wird nur durch ein Transaction Log Backup gelöscht.

D.h., in diesem Model sollte immer ein Datenbank- und Transaction Log Backup durchgeführt werden, damit die Festplatten nicht vollgeschrieben werden.

Dieses Model hat einen großen Vorteil: Es kann zur minutengenauen Wiederherstellung der Datenbank z.B. bei einem Festplattenausfall, Fehlfunktion sowie Falscheingabe genutzt werden.
Hierfür ist jedoch notwendig, dass die Transaction Logs häufig gesichert werden. Man kann sagen, je geringer der Datenverlust sein darf, desto häufiger muss das Transaction Log gesichert werden. Um die Wiederherstellungszeit gering zu halten, sollte jedoch mindestens einmal Täglich eine Datenbanksicherung durchgeführt werden.

Bulk-logged

Das “Bulk-logged” Model ist fast identisch mit “Full”. Es unterscheidete sich nur insofern, dass Bulk Insert nur minimal protokoliert werden, so dass diese nicht einzeln wieder hergestellt werden können.

Backup Strategie

Für die richtige Backup Strategie gibt es leider keine “Out of the Box” Lösung, weil jede Datenbank andere Anforderungen hat.
Auch kein Backup zumachen kann eine Strategie sein.

Wichtig ist nur, dass das Recovery Model entsprechend an die Strategie angepasst wird.

Aus diesem Grund muss der Speicherort der Master DB Dateien im “SQL Server Configuration Manager” angepasst werden.

Als erstes muss der SQL Server Dienst beendet werden.
Als nächstes müssen die Dateien der Master DB in das neue Verzeichnis kopiert werden.
Nun öffnet man die Eigenschaften der gewünschten SQL Server Instanz

Der Speicherort der Master DB ist in den Startup Parameters definiert.

-dC:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\
master.mdf;-eC:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\
LOG\ERRORLOG;-lC:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\
DATA\mastlog.ldf

-d Gibt die Datendatei an.

-l  Gibt die Logdatei an.

-e Gibt den Pfad fürs Error Log an.

Hier kann der Pfad der Master DB Dateien jetzt auf das neue Verzeichnis, in dem die Kopien der Dateien liegen, angepasst werden.

Abschließend muss der SQL Server Dienst wieder gestartet werden.

In diesem Beispiel heißt die Datenbank DB1 und hat folgende Dateien.

Die Dateien sollen jetzt von c:\data nach x:\data verschoben werden.

1. ALTER DATABASE DB1 SET OFFLINE WITH ROLLBACK_IMMEDIATE

2. Kopiere die Datenbankdateien von C:\data nach X:\Data

3. ALTER DATABASE DB1 MODIFY FILE(NAME = DB1_Data, FILENAME = “X:\data\DB1_Data.mdf”)

4. ALTER DATABASE DB1 MODIFY FILE(NAME = DB1_Log, FILENAME = “x::\data\DB1_Log.ldf”)

5. ALTER DATABASE DB1 SET ONLINE

Wichtig: Diese Methode kann nicht auf die MASTER Datenbank angewendet werden!

In order to utilize map data in SQL Server the spatial data types and the spatial functions of the SQL Server are important. In my last post I “aggregated” detailed shapes up to a surrounding shape by using the built-in STUnion() function.

For the current post I’m using the detailed data for the German PLZ regions from my last post together with Craig Dunn’s function for aggregating shapes. The installation of these aggregate functions is pretty straight forward. After compiling the library from the source code you have to register the new aggregate in your SQL Server database. You will find all the needed information in his post.

Using this library, the aggregation of the shape becomes pretty easy. For example. The full aggregation for postal code region 42 now looks like this:

Not aggregated	Aggregated
select geom from dbo.post_pl where PLZ99 like ’42%’	select dbo.UnionAggregate(geom.MakeValid()) from dbo.post_pl where PLZ99 like ’42%’

This is much easier than the T-SQL function from my last post. I still recommend to persist the results for later use because the geo spatial operation may be more time consuming than “normal” queries.

However, there are two special topics to take care of:

1. Not all polygons may be correct (Open Geospatial Consortium type)
2. The shapes may not fit together perfectly

The first topic could result in errors when using the aggregation function above as well as the built-in T-SQL STUnion() function. This can be easily avoided using the MakeValid() function as shown in the example above. If you omit this function and remove the where-condition to get the aggregate of the full German map you will get a .Net error because of incorrect shapes.

For the second topic, take a closer look to the right picture from above. You will notice some lines within the shape. This effect becomes even more visible if we use the STBoundary() function to reduce the shape to its boundaries:

Without STBuffer()	With STBuffer()
select dbo.UnionAggregate(geom)    .STBoundary() from dbo.post_pl where PLZ99 like ’42%’	select dbo.UnionAggregate(geom)    .STBuffer(0.00001).STBoundary() from dbo.post_pl where PLZ99 like ’42%’

STBuffer() simply adds some buffer around the existing shape. This can be easily examined using the following T-SQL statement with its corresponding result:

DECLARE @s1 AS GEOMETRY = ‘POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))’
DECLARE @s2 as GEOMETRY = ‘POLYGON((1.1 0, 2.1 0, 2.1 1, 1.1 1, 1.1 0))’
select @s1.STUnion(@s2).STBoundary()

As you can see, there is a small gap between the two squares. If you don’t want to look at the coordinates, you can query the distance by using the STDistance function, for example: select @s1.STDistance(@s2). The distance is actually 0.1 units.

If we now add the STBuffer function the result looks like this:

DECLARE @s1 AS GEOMETRY = ‘POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))’
DECLARE @s2 as GEOMETRY = ‘POLYGON((1.1 0, 2.1 0, 2.1 1, 1.1 1, 1.1 0))’
select @s1.STUnion(@s2).STBuffer(0.1).STBoundary()

By actually extending the shape a little bit, the tiny gap in the middle of the shape disappears. This is why the map on the right side looks smoother than then one on the left side. You still need to be careful with the parameter for STBuffer. Higher parameters will result in a totally different shape. For example, if we use 4 as the parameter value in the example above, the shape looks like this:

Also higher values of STBuffer result in more time needed to compute the new shape. So in practice, you would try small values first or you could use the STDistance-function to compute the distance between the shapes.

As some people are surprised, the samples above are also fully functional with SQL Server 2008 because the spatial data type and functions have been introduced with SQL Server 2008. New in SQL Server 2008 R2 is the map support for Reporting Services, not the support for spatial data.