Beispiel Tabelle

Calc als Column

=SUMX(FILTER(TX;[TID]<=EARLIER([TID])&&[Account]=EARLIER([Account]));[Value])

Calc als Measure

MRunTotal:=IF( COUNTROWS( VALUES( TX[TID]) ) = 1;
 CALCULATE( SUM( TX[Value] );
 Filter(All(TX);TX[TID]<=VALUES(TX[TID]));
 Filter(All(TX);TX[Account]=VALUES(TX[Account]))
 ))

Sample Excel Datei

http://sdrv.ms/P6x9lJ

http://www.microsoft.com/en-us/download/details.aspx?id=29063

Viele Spass

Markus Thomanek

Viele Grüße

Markus Thomanek

In meiner beliebten Reihe „Fragen von Kunden“ gibt es heute mal einige Gerüchte zu SQL Server, die von Wettbewerbern genannt werden um den Kunden zu verunsichern. Ich bin schon ziemlich erstaunt, welche Informationsdefizite bestehen…

Zu den Gerüchten:

1. Der SQL Server kann keine vernünftigen Locks (Sperren) durchführen. Er lockt (sperrt) immer seitenweise, was dazu führt, dass man unvorhersehbares Laufzeitverhalten erzeugt.

Tja, SQL Server 6.5 hat noch ganze Seiten gesperrt…

Seit SQL Server 7.0 gibt es Row Level Locking. Allerdings wählt SQL Server bei großen Mengen von Datenänderungen auch manchmal Page (Seite) oder gar Table Locks, da dies Hauptspeicher und vor allem die Zeit zum Setzen und Entfernen der Locks spart. Hier ist SQL Server deutlich effizienter als andere Datenbanksysteme. Wem dieses Verhalten nicht gefällt, der kann einen ROWLOCK Table Hint in den Abfragen verwenden oder Page Locks für einen Index mit der Index Option ALLOW_PAGE_LOCKS = { ON | OFF } deaktivieren. Bei manchen Vorgängen, insbesondere DDL-Statements wie ALTER TABLE ist allerdings ein Table Lock unumgänglich, das ist in anderen Datenbanken auch so.

2. SQL Server verwendet pessimistisches Locking. Dadurch blockieren Leser Schreiber und umgekehrt und die Parallelität wird gesenkt

Ausschließlich pessimistisches Locking wurde bis SQL Server 2000 verwendet…

Seit SQL Server 2005 hat der Kunde die Wahl, ob er optimistisches oder pessimistisches Locking verwenden will, wobei pessimistisches nach wie vor der Standard ist.

Worum geht es? Nehmen wir an, Transaktion A will einen Datensatz schreiben, Transaktion B denselben Datensatz lesen (bei Row Level Locking). Beide Transaktionen sind noch nicht abgeschlossen. Klar ist, dass Transaktion B auf keinen Fall den noch nicht committeten neu geschriebenen Wert lesen darf (Dirty Read), denn es kann ja sein, dass Transaktion A zurückgerollt wird. Nun hat die Datenbankengine zwei Möglichkeiten:

Pessimistisches Locking: Wenn der Datensatz von Transaktion B geschrieben wird setzt die Engine einen exklusiven Lock auf den Datensatz. Transaktion B will vor dem Lesen einen Shared Lock haben, bekommt den aber wegen dem exklusiven Lock erst nach Abschluss von Transaktion A.

Optimistisches Locking: Bis zum Abschluss der Transaktion A wird neben den geänderten Daten auch die alte, committete Version des Datensatzes gehalten (in tempdb). Dadurch kann Transaktion B die alte Version der Daten lesen und es ist kein Shared Lock notwendig. Das entspricht zum Beispiel dem Verhalten in Oracle (Oracle verwendet die Begriffe pessimistisch und optimistisch allerdings ein wenig anders, da es die hier angegebene erste Variante gar nicht gibt). Optimistisches Locking können Sie in SQL Server mit READ_COMMITTED_SNAPSHOT oder TRANSACTION ISOLATION LEVEL SNAPSHOT (mit leicht unterschiedlichem Verhalten) verwenden. Mehr dazu hier: http://msdn.microsoft.com/en-us/library/ms179599.aspx

Warum gibt es nun beide Varianten? Weil pessimistisches Locking ressourcenschonender und für Szenarien besser geeignet ist, wo meist unterschiedliche Datensätze zugegriffen werden (z.B. Lagerhaltung). Optimistisches Locking ist hingegen flexibler.

3. Der SQL Server ist fast unbezahlbar, da man keine vernünftige Lizensierung durchführen kann, die eine unbeschränkte Anzahl von Usern (z.B. im Web-Betrieb) erlaubt.

SQL Server kann man auf Prozessor (bis 2008R2) bzw. Core (ab SQL 2012) Basis lizenzieren und damit beliebig viele Benutzer supporten. Und auch die kostenlose SQL Server Express Version ist in manchen kleinen Web-Szenarien eine Option.

Bei der Gelegenheit: Auch von Oracle gibt es ja eine kostenlose Express Version (XE). Allerdings wird diese im Gegensatz zu SQL Server Express nicht gepatcht, auch nicht bei den reichlich vorhandenen Sicherheitslücken. Damit ist sie für Web-Aufgaben (und eigentlich für fast alle Aufgaben) komplett ungeeignet.

4. Der SQL-Server verwendet immer feste, nicht anpassbare Blockgrößen bei der Speicherung. Oracle kann hier zwischen 2K und 32K skalieren.

Das ist richtig, SQL Server verwendet immer 8k Datenseiten für die Speicherung. Die gesamte Datenbankengine und das IO Subsystem ist daraufhin optimiert, und auch Hersteller von Storagelösungen können sich darauf einstellen. In Oracle gibt es die Möglichkeit, die Blockgröße anzupassen, aber nur die wenigsten Kunden nutzen diese Möglichkeit. Zumal verschiedene Blockgrößen innerhalb einer Instanz zu einer Fragmentierung des Hauptspeichers führen würden – man kann nun mal nicht eine 32kB Seite in den Platz laden, der von 4 8kB Seiten freigegeben wurde, wenn dieser Platz nicht hintereinander liegt.

Die Performanceergebnisse von SQL Server geben uns hier wohl recht… Und bei größeren Datenmengen verwendet SQL Server Read Ahead mit Lesegrößen bis zu 1024 kB, um effizienter auf das Storagesystem zuzugreifen.

5. Der SQL-Server hält sich nicht an die ANSI-Standards und hierdurch ist Interoperabilität nicht gewährleistet.

Es ist zwar richtig, dass es geringe Unterschiede zwischen SQL Server und ANSI SQL gibt, aber meines Wissens gilt dies auch für jedes andere relationale Datenbank. Einige der Differenzen zwischen Oracle SQL und ANSI SQL finden sich hier: http://de.wikipedia.org/wiki/Oracle_(Datenbanksystem)#Abweichungen_vom_ANSI-SQL-Standard. Allerdings ist diese Liste bei weitem nicht vollständig. So ist zum Beispiel die Oracle SEQUENCE-Syntax nicht ANSI compliant (die von SQL Server 2012 schon).

Im Falle von SQL Server liegen die Unterschiede vor allem in Datentypen (wie TIMESTAMP), die bereits vor Verabschiedung des ANSI Standards anders verwendet wurden.

Allgemein haben allerdings alle großen Datenbanksysteme viele Features, die weit über den ANSI Standard hinausgehen. Daher ist Interoperabilität immer nur dann möglich, wenn beim Schreiben des SQL Codes ausdrücklich darauf geachtet wird, nur standardisierte Sprachkonstrukte zu nutzen.

6. Es gibt kein Äquivalent zu den PLSQL-Packages des Oracle, das ein Lifecycle-Management sowie eine Verteilungs-Strategie zulassen würde.

Da hätten wir ja eines der nicht standardkonformen Oracle-Features. In ANSI SQL gibt es kein CREATE PACKAGE…

SQL Server hat zwar keine Packages, wer möchte kann allerdings Schemas stattdessen zur Strukturierung des Codes verwenden (für die Oracle-Fraktion: in SQL Server werden Schemas anders verwendet als in Oracle. Ein Oracle-Schema entspricht mehr einer SQL Server Datenbank)

Für Lifecycle Management und Verteilungsstrategie gibt es allerdings in SQL Server deutlich bessere Varianten. Insbesondere die Möglichkeit der Integration von SQL Server Management Studio mit Quellcodeverwaltungssystemen, die neuen SQL Server Data Tools mit ihrem kompletten round trip engineering für Datenbankcode, die DAC-Pakete und die Integration mit Visual Studio Team System wären hier zu nennen…

Wie andere Datenbanksysteme auch unterliegt SQL Server einer ständigen Weiterentwicklung, um das geeignete Datenbanksystem zu finden sollte man immer über die aktuellen Möglichkeiten informiert sein. Ich hoffe ich konnte mit diesen Beispielen zeigen wie wichtig dies ist.

Zum Abschluss noch ein paar Links zum Thema SQL Server Mythen:

• http://blogs.msdn.com/b/euanga/archive/2006/01/19/514479.aspx
• http://www.simple-talk.com/community/blogs/tony_davis/archive/2007/06/27/32975.aspx
• http://www.sqlskills.com/blogs/paul/CommonSQLServerMyths.pdf

Gruß,
Steffen

Grundsätzlich steht als DDL DAX zur Verfügung, allerdings ist man limitiert durch die Architektur und die Sprachkonstrukte. Der Periodenvergleich fordert verschiedene Flexibilitäten:

1. dynamische Bestimmung des Measures
2. dynamische Bestimmung des Zeitraums
1. daraus resultierend dynamische Bestimmung der Ebene in der Zeithierarchie

Die Dynamisierung des Measures kann durch Hinzufügen einer weiteren Tabelle und einer kleinen Berechnungformel erledigt werden. Nehmen wir an das die Measures "Revenue" und "Quantity" zur Verfügung stehen, dann sieht die Tabelle folgendermaßen aus:

DynMeasure
 Revenue
 Quantity 

die zugehörige Funktion wie folgt:

 CP:=IF(COUNTROWS( VALUES(DynMeasure[DynMeasure]))=1;
 SWITCH(Values(DynMeasure[DynMeasure])
 ;"Revenue";[Revenue Sum]
 ;"Quantity";[Quantity]
 )) 

Wählt man nun anstatt "Revenue" oder/und "Quantity" als direktes Measure "CP" und fügt die Dimension DynMeasure dem Pivot hinzu, lässt sich über einen Filter auf DynMeasure bestimmen welche Measures angezeigt werden. Das Verhalten ist somit ähnlich einer Implementierung in der nur das Measure "Value/Wert" existiert.

Um die Zeitintelligenz hinzuzufügen kann auf einige implementierte Funktionen zurückgegriffen werden. Jedoch fehlt die Möglichkeit zur Bestimmung der Ebene in einer Dimension. Als Hilfskonstrukt kann für die Zeit folgende Funktion dienen:

MD:=ROUNDDOWN( COUNTROWS( DATESBETWEEN('Date'[Date]; FIRSTDATE('Date'[Date]); LASTDATE('Date'[Date])))/30;0)

Die einzelnen Periodenberechnungen können direkt im Summationsbereich der Tabelle hinterlegt werden:

 PY:=[CP](SAMEPERIODLASTYEAR('Date'[Date]))
 PQ:=[CP](PREVIOUSQUARTER('Date'[Date]))
 PM:=[CP](PREVIOUSMONTH('Date'[Date])) 
 PD:=[CP](PREVIOUSDAY('Date'[Date])) 

Da ich in der Regel unterjährig auswerte, bevorzuge ich SAMEPERIODLASTYEAR anstatt PREVIOUSYEAR, da somit der selbe Zeitraum im Vorjahr gewählt wird, anstatt das gesamte Jahr. Die Berechnungen ziehen schon dynamisch das jeweils von mir gewählte Measure an. Alternativ kann auch mit Parallelperiod gearbeitet werden, jedoch gibt es dort keine Entsprechung zu PreviousDay.

Um diese Berechnungen nun auch dynamisieren kann folgende Formel verwendet werden:

PP:=SWITCH([MD];12;[PY];3;[PQ];1;[PM];0;[PD])

Zur Auswertung im Pivot werden das Measure "CP" und "PP" hinzugefügt, mit einem Slicer kann einfach das Ein- bzw. Ausblenden von Measures realisiert werden.

Eine Verwendung von switch bzw. if Statements sollte in jedem Fall einer Performanceüberprüfung unterzogen werden, so das ggf. der Komfort der Dynamisierung angepasst werden muss.

Diese Demo habe ich nun als Videos aufgenommen.

Im ersten Teil zeige ich die Installation eines 4-Knoten-Clusters auf Basis von Windows Server 2008 R2 SP1, wobei zwei von den vier Knoten Zugriff auf ein iSCSI SAN haben (und die anderen beiden nicht)

Im zweiten Teil  baue ich einen 2-Knoten SQL Server Failover-Cluster auf und teste ihn

Im dritten Teil baue ich aus dem SQL Server Failover Cluster und den anderen beiden Windows Cluster Konten eine AlwaysOn Availability Group auf, richte Read Only Routing ein und teste das ganze.

Die Videos finden sich hier:

Gruß,
Steffen

Gegenüber der letzten CTP-Version gibt es einige wesentliche Verbesserungen

• Die Hochverfügbarkeitslösung AlwaysOn ist nun Feature Complete. Es können bis zu 5 Replikas (1 Primäre schreibbare, 2 synchrone sekundäre, 2 asynchrone sekundäre) eingerichtet werden. Lesbare Secondaries und Backup von den Secondaries sind unterstützt. Letzteres kann man sogar über den Assistenten einrichten:
  
  
• In Power View kann jetzt eine “Mappe” aus unterschiedlichen Views angelegt werden
• Ebenso gibt es in Power View jetzt eine Druckfunktion und einen PowerPoint Export:
  
  
• Der Resource Governor hat einige neue Funktionen für große Umgebungen, wie detailliertere CPU Kontrolle und Resource Pool Affinity
• Change Data Capture von Oracle ist nun möglich
• SQL Management Studio unterstützt Snapshot Backups von SQL Azure

Die offizielle Information findet sich im Dataplatform Insider Blog

Der Download ist hier (für Deutsch einfach auf deutsch umstellen). Die Release Notes finden sich auch dort. Wichtig sind vor allem die OS-Patches für AlwaysOn Availability Groups!

Gruß,
Steffen

 Was versteht man unter Big Data?

Wie der Name “Big Data“ schon vermuten lässt, geht es in der Regel darum, große Datenmengen mit  hohem Durchsatz zu verarbeiten, die klassische Datenbanken und auch entsprechende Analyse Werkzeuge nur sehr eingeschränkt verarbeiten können.  Dies können z. B. Log Files, Images, Videos, Sensor Daten , Finanz oder auch Börsendaten sein. Um derartige große Datenmengen effizient verarbeiten zu können, wird bei Big Data auf den Ansatz einer Massiv Parallelen Architektur zugegriffen, die die Last auf z.B. mehrere 1000 Server verteilt.

Für Facebook und Yahoo gibt es im Zusammenhang mit  „Big Data“ z. B. folgende beeindruckende Zahlenwerte, die ich dem Hadoop Wiki entnommen habe.

• Facebook: Currently they have 2 major clusters:
• A 1100-machine cluster with 8800 cores and about 12 PB raw storage.
• A 300-machine cluster with 2400 cores and about 3 PB raw storage.
• Each (commodity) node has 8 cores and 12 TB of storage.
• Facebook’s Hadoop/Hive system ingests 15 terabytes of new data per day
• Yahoo:
• • More than 100,000 CPUs in >40,000 computers running Hadoop
  • Our biggest cluster: 4500 nodes (2*4cpu boxes w 4*1TB disk & 16GB RAM)

 Und was ist Hadoop?

Das Apache Projekt Hadoop ist ein Framework zur parallelen Datenspeicherung und -verarbeitung sehr großer Datenmengen, die verteilt in Clustern von Servern „fehlertolerant“ im lokalen Filesystem gespeichert werden. Das Design von Hadoop ermöglicht Skalierungen von einem einzelnen Server bis zu mehreren tausend Servern.  Eine umfangreiche Referenzenliste finden Sie HIER.

Das Projekt besteht primär aus den folgenden Unter-Projekten:

• Hadoop Common: The common utilities that support the other Hadoop subprojects.
• Hadoop Distributed File System (HDFS™): A distributed file system that provides high-throughput access to application data.
• Hadoop MapReduce: A software framework for distributed processing of large data sets on compute clusters.

Weitere Details zu Hadoop finden Sie auf der Hadoop Projektseite HIER.

 Was beinhaltet die Microsoft-Ankündigung?

• In Zusammenarbeit mit dem Partner Hortonworks ist es geplant, Hadoop vollständig auf dem Windows Server zu  „portieren“. Ein CTP für Hadoop-Based Services, sprich eine „Hadoop Based Distribution“ für Windows Server, ist für 2012 geplant.
•  Zudem ist es geplant, Hadoop auch als Dienst in Windows Azure anzubieten. Die Verfügbarkeit eines Community Technology Preview (CTP) von Hadoop-Based Services für Windows Azure  ist für Ende 2011 geplant. Primäres Ziel ist es, Entwicklern und Anwendern die Möglichkeit zu geben, standard Hadoop Jobs  direkt in der Azure Cloud ablaufen zu lassen.  Weitere Infos finden Sie HIER.
• Darüber hinaus wurde die Verfügbarkeit von Konnektoren bekannt gegeben, die er ermöglichen, vom Connector for SQL Server und Connector for SQL Server Parallel Data Warehouse auf Hadoop zuzugreifen und damit eine einfache Integration der „Big Data“ Welt mit der bestehenden SQL Server Welt zu ermöglichen.
• Zudem ist ein Hive ODBC Driver & Hive Add-in for Excel geplant, um direkt mit Excel und PowerPivot auf Hadoop zugreifen zu können.

Weiterführende Informationen  finden Sie  auch in dem White Paper HIER., der Webseite HIER. und der Original-Ankündigung Hier.

Welche Möglichkeiten ergeben sich aus der Ankündigung?

Mit diesem Ansatz ermöglicht Microsoft den Kunden, beide Welten zusammen zu führen - die Welt der „Big Data“ und der relationalen Welt mit dem SQL Server – und  die Stärken aus beiden Welten für sich nutzbar zu machen. Die Vorteile sind u. a.:

• Steht Hadoop auf Azure zur Verfügung, hat der Kunde nahezu unbegrenzte Skalierungsmöglichkeiten und kann sehr leicht eine „BigData“ Umgebung aufbauen  und standard Hadoop Jobs  direkt in der Azure Cloud ablaufen lassen.
• Die Konnektoren ermöglichen einen leichten Zugriff auf die in Hadoop-Systemen abgelegten Daten.. Beispielsweise können Kunden die unstrukturierten Daten in Hadoop analysieren und die daraus gezogenen Erkenntnisse in ein Data-Warehouse im SQL Server nutzbar machen.
• Die neue Hadoop basierende Distribution für Windows ermöglicht eine einfachere Installation, Konfiguration und Nutzung auf der Windows Plattform. Weitere Infos finden Sie HIER.
• Anwender können mittels Hive ODBC Driver oder auch Hive Add-in for Excel mit den Microsoft Excel und auch Power Pivot for Excel  direkt auf Hadoop Daten zugreifen und individuelle Analysen durchführen. Weiter Information dazu finden Sie HIER.

 Viel Spaß mit GROßEN Daten wünscht

FSeiwerth

• Running SQL Server 2008 in a Hyper-V Environment - Best Practices and Performance Recommendations
  • Deutsche Übersetzung: Ausführen von SQL Server 2008 in einer Hyper­V­Umgebung Best Practices und Überlegungen zur Leistung
• High Performance SQL Server Workloads on Hyper-V
• Onboarding SQL Server Private Cloud Environment
• Running SQL Server with Hyper-V Dynamic Memory - Best Practices and Considerations

Für diejenigen, die nicht die Zeit haben um sich die Whitepaper durchzulesen möchte ich hier die wichtigsten Fakten (ohne Anspruch auf Vollständigkeit) einmal zusammenstellen

Installation

• Dies betrifft Neuinstallationen in die Konsolidierungsumgebung, nicht die Migration von vorhandenen Umgebungen
• Für Private Cloud/Konsolidierungsumgebungen ist es empfohlen, SQL Server VMs aus VM-Templates zu erstellen
• SQL Server unterstützt sysprep zum Erstellen des Templates erst seit Version SQL Server 2008 R2
• Man muss für sysprep genau nach Anleitung vorgehen. Die Installation erfolgt in 2 Schritten: Vorbereiten (danach sysprep und Template erstellen) und abschließen. Dokumentation: http://msdn.microsoft.com/de-de/library/ee210754.aspx
• Stellen Sie unbedingt sicher, dass die Hyper-V Integrationskomponenten (bzw. das Äquivalent für die verwendete Virtualisierungsumgebung) in der jeweils aktuellen Version installiert sind, verwenden Sie keine emulierten Geräte

Migration

• Um festzustellen, welche SQL Server Instanzen in die virtuelle Umgebung migriert werden können verwendet man am einfachsten das MAP Toolkit Demo von mir hier

Dynamic Memory

• SQL Server unterstützt Hyper-V 2008 R2 SP1 Dynamic Memory
• Das SQL Server Dienstkonto sollte unbedingt das Recht “Lock Pages in memory” haben
• Die Summe der “Startup Memory” Einstellungen aller VMs, die potentiell (auch nach einem ungeplanten Failover) auf einem Host laufen können muss kleiner sein als der physikalische Speicher des Hosts
• Wenn möglich sollte vor einer (geplanten) Live Migration einer SQL VM der Hauptspeicher von SQL Server mittels sp_configure ‘max server memory’ reduziert werden. Nicht vergessen, diese Einstellung nach der Live Migration wieder zu zurückzunehmen!
• Über “Memory Weight” kann man die Priorität der VMs bei der Hauptspeicherzuteilung einstellen

Storage

• Alle Best Practices für SQL Server Storage gelten auch für virtualisierte Umgebungen. Siehe mein Webcast SQL Server Storage Performanceanalyse
• Daher für Lastsysteme: Daten und Logs auf getrennte LUNs, hinter denen getrennte Platten liegen
• Auf keinen Fall dynamische Disks für Daten und Logs
• Entweder Passthrough Disks oder VHDs fester Größe verwenden

CPU

• Virtualisierung erhöht leicht den CPU-Bedarf von SQL Server. Da Hyper-V maximal vier virtuelle CPUs pro VM unterstützt bedeutet das, dass nur Lasten, die weniger als 4 volle CPU-Cores benötigen virtualisiert werden sollten.
• Wenn CPUs overcommitted werden (also der Summe aller VMs mehr virtuelle CPUs zugewiesen werden als der Server physische CPU-Kerne hat) so erhöht sich der CPU-Bedarf durch die Virtualisierung weiter. Daher sollte bei Lastsysteme Overcommitment vermieden werden. Das gilt insbesondere, wenn die verwendeten Prozessoren keine Second Level Address Translation (SLAT) unterstützen
• Netzwerk-intensive Lasten erhöhen ebenfalls den CPU-Bedarf

Hochverfügbarkeit

• Sowohl Host-Clustering (mit Live Migration) als auch Guest Clustering (Windows/SQL Cluster in VMs) ist mit Hyper-V unterstütz (zu VMWare siehe unten). Beides kann für höchste Flexibilität und Ausfallsicherheit kombiniert werden.
• Ebenso ist Database Mirroring und Log Shipping auch im virtualisieren Betrieb unterstützt

Lizenzierung

• SQL Server Enterprise bzw. Datacenter können in Virtualisierungsszenarien durch die erweiterten Virtualisierungsrechte deutlich Kosten sparen
• Details dazu auf der SQL Server Lizenzierungs-Seite

VMWare (und andere)

• Grundsätzlich ist VMWare (und andere Hypervisor) als Virtualisierungsumgebung supportet, solange die konkrete VMWare Version mit dem SVVP validiert ist. Details: http://support.microsoft.com/kb/956893/en-us
• Soll statt Hyper-V VMWare eingesetzt werden so muss man sich die Limitationen von ESX, insbesondere in Zusammenhang mit Clustern klar machen. So vMotion nicht in Kombination mit Windows Clustering unterstützt. Man muss sich also zwischen Host Clustering (vMotion) und Guest Clustering (SQL Server/Windows Server Cluster) entscheiden. Das ist nicht gut, denn die beiden Technologien schützen gegen unterschiedliche Arten von Ausfällen. Ebenso ist iSCSI nicht unterstützt.
  Quelle: http://www.vmware.com/pdf/vsphere4/r41/vsp_41_mscs.pdf Seite 11

Gruß,
Steffen

• 14 Product Datasheets
• 8 PowerPoint Präsentationen
• 5 Technische Whitepaper
• 13 Hands-On Lab Preview Dokumente
• 6 Click-Through Demos
• 13 automatisch ablaufende Demos
• 26 Links zu Online-Dokumentationen
• 44 Links zu Online-Videos einschließlich 26 Präsentationen von der US-TechEd 2011

Der Download des Product Guide findet sich hier

Gruß,
Steffen