Tag: SQL 2008 R2

Darstellung herausgefilterter Zeit-Kategorien

Arno Cebulla

Ein typisches Verhalten in Reporting-Services ist es, dass Daten, die mit Parametern herausgefiltert werden, auch im Bericht nicht dargestellt werden. Beispiel: In diesem Chart werden die Umsätze für ein Jahr dargestellt: 

 Wenn nun nur noch die Monate Januar-April im Month-Parameter ausgewählt werden, erscheint folgendes Chart:

 

Die Daten werden per MDX aus einem Cube gelesen und im Dataset mit einem Subselect oder in der WHERE-Bedingung gefiltert:

SELECT

 {[Measures].[Sales Amount]} ON 0,

 NON EMPTY

 {([Date].[Calendar].[Date].ALLMEMBERS )} ON 1

 FROM

 (SELECT ( STRTOSET(@DateCalendarYear, CONSTRAINED) ) ON 0

 FROM

 (SELECT ( STRTOSET(@DateMonthofYear, CONSTRAINED) ) ON 0

 FROM [Adventure Works]))

Der Kunde wünscht nun, dass die übrigen Monate aber dennoch (mit dem Wert 0) angezeigt werden sollen. Hierfür gibt es zum einen die Möglichkeit, dieses bereits im MDX-Query zu lösen. Dies geschieht über einen String-Vergleich in einem IIF-Block. Leider ist diese Methode recht unperformant.

Ein besseres Ergebnis kann man mit dieser Methode erzielen, vorausgesetzt man verwendet SQL Server ab Version 2008 R2:

Im Dataset werden zunächst alle Daten für das Jahr geholt:

SELECT

 {[Measures].[Sales Amount]} ON 0,

 NON EMPTY

 {([Date].[Calendar].[Date].ALLMEMBERS )} ON 1

 FROM

 (SELECT ( STRTOSET(@DateCalendarYear, CONSTRAINED) ) ON 0

 FROM [Adventure Works])

Dann wird ein zweites Dataset „GueltigeMonate“ erstellt, in dem die Monate anhand des Parameters gefiltert werden:

WITH

MEMBER [Measures].[ParameterCaption] AS [Date].[Month of Year].CURRENTMEMBER.MEMBER_CAPTION

MEMBER [Measures].[ParameterValue] AS [Date].[Month of Year].CURRENTMEMBER.UNIQUENAME

MEMBER [Measures].[ParameterLevel] AS [Date].[Month of Year].CURRENTMEMBER.LEVEL.ORDINAL

SELECT

{[Measures].[ParameterCaption], [Measures].[ParameterValue], [Measures].[ParameterLevel]} ON COLUMNS ,

[Date].[Month of Year].ALLMEMBERS ON ROWS

FROM

(SELECT STRTOSET(@Monate,CONSTRAINED) ON 0

FROM [Adventure Works])

Nun müssen beide Datasets miteinander verbunden werden. Hierzu werden die Eigenschaften der Serie geöffnet:

Im Feld für die Daten (Value) wird nun der Lookup gegen das Dataset „GueltigeMonate“  hergestellt. Hierfür wird die Funktion „Lookup“ benötigt. Die Syntax sieht so aus:

=IIF(LEFT(Fields!Month.Value,LEN(Fields!Month.Value)-5)=

LOOKUP(LEFT(Fields!Month.Value,LEN(Fields!Month.Value)-5), Fields!ParameterCaption.Value,Fields!ParameterCaption.Value,”GueltigeMonate”),

Sum(Fields!Sales_Amount.Value),0)

Diese Syntax bewirkt folgendes:

Wenn der Monatsname im Haupt-Dataset gleich einem Monatsnamen ist, der im gefilterten Monats-Dataset vorhanden ist, so wird der Wert angezeigt, ansonsten wird die Zahl 0 angezeigt.

Wenn nun im Bericht die gleiche Selektion wie am Anfang beschreiben durchgeführt wird, ergibt sich das gewünschte Bild: 

Die Anzeige-Geschwindigkeit konnte mit der Lookup-Methode gegenüber der Behandlung im Query halbiert werden. In einem der nächsten Blog-einträge werde ich die Lookup-Funktion dann nochmal näher beleuchten.

  • Share/Bookmark

Backup Strategie und Transaction Log

Daniel Snellen

Bereits bei der Erstellung eines DWH sollte man sich auch Gedanken über die richtige Backup Strategie machen, da diese sonst auch schnell vergessen werden kann.

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.

image

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.

  • Share/Bookmark

Microsoft® SQL Server® 2008 R2 Best Practices Analyzer verfügbar

Daniel Snellen

Seit dem 18.06.2010 steht jetzt auch der SQL Server 2008 R2 Best Practices Analyzer (BPA) zum Download auf der Microsoft Webseite bereit.

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0fd439d7-4bff-4df7-a52f-9a1be8725591

Der SQL Server 2008 R2 BPA ist ein Diagnosetool, welches den SQL Server anhand von Best Practices analysiert und einen Bericht ausgibt, in dem auf mögliche Konfigurationsfehlern oder Fehlenden Updates hinweist.

Der BPA gibt auch genaue Hinweise wie die möglichen Probleme gelöst werden können.

  • Share/Bookmark

  • Kategorien

  • Copyright © 1996-2011 ORAYLIS Blog. All rights reserved.