SQL Server PowerShell ? Lohnt es sich überhaupt damit zu beschäftigen ?

-

Diese Frage wurde mir in den letzten Tagen häufig gestellt, als es sich herumgesprochen hat, dass ich auf dem SQLSaturday #313 einen Crashkurs PowerShell für SQL Server Administratoren halte.

Und warum gerade ich? In den letzten Jahren bin ich ja eher nicht durch das Thema Administration in der Öffentlichkeit aufgefallen. Bin doch eher der BI Entwickler, welcher durch konsequente Nutzung der Möglichkeiten vieles im BI Projekt als auch im späteren Betrieb automatisiert.

Da PowerShell vereinfacht gesagt eine Shell ist, mit welcher das .NET Framework sehr komfortabel genutzt werden kann, bin ich wieder voll im Spiel und gefühlt ist meine SQLSat Session quasi die Fortsetzung vieler meiner Community-Projekte und Vorträge in denen ich mit .NET Bibliotheken gearbeitet habe.

Nur warum PowerShell für den SQL Server? “Wir” haben doch T-SQL und eine Menge an Komfortfunktionen rund um den Betrieb eines SQL Servers.

Da schaut es bei den Kollegen für Exchange Server oder SharePoint Farmen schon ganz anders aus. Die können sich mittlerweile ohne PowerShell gefühlt keinen Meter bewegen. Viele Funktionen sind, so wurde mir zugetragen, auch NUR noch über PowerShell erreichbar. Daher ist in diesen Communities das Thema auch wesentlich populärer als bei “uns”.

Also, wozu braucht nun ein SQL Administrator PowerShell?

Brauchen zurzeit noch nicht zwingend, dennoch ist es schon äußerst nützlich und zwar immer dann, wenn etwas automatisiert werden soll, was außerhalb des SQL Servers liegt. Oder wenn einfach mal der SQL Server Dienst selbst an der Reihe ist.

Neben meinem Community Leben beschäftige ich mich sehr intensiv mit Administration. Meine Kollegen bei der PSG verantworten große und komplexe SQL Server Umgebungen, welche zum Teil auch global und rund um die Uhr genutzt werden. Da ist das Thema Standardisierung und Automatisierung sehr wichtig, um einen konstant robusten Betrieb zu ermöglichen. Und der Betrieb betrifft häufig auch das Betriebssystem, Storage-Systeme, AD-Gruppen, Virtualisierung etc. pp. Vieles ließe sich sehr wahrscheinlich mit ein wenig Kreativität nativ in T-SQL lösen (und ich hätte einen Wahnsinnsspaß mir das auszudenken), nur hat sich um die SQL Server Welt herum im Microsoft Eco-System PowerShell als das Allzweckwerkzeug für viele Aufgabenstellungen entwickelt.

Und dann, dann ist da noch die Cloud. Ja, die Cloud. Und so richtig sinnvoll werden Szenarien in der Cloud erst, wenn der Grad an Automatisierung sehr hoch ist. Ich weiß, dass bei dem Thema noch viele Mitglieder aus der Community zusammenzucken und ein leises “das wird nie bis zu mir kommen…” von sich geben. Dennoch stelle ich in der Zusammenarbeit mit Microsoft fest, dass immer mehr Kunden die Einsatzmöglichkeiten von Azure prüfen oder gar schon am implementieren sind. Und auch hier ist eine Automatisierung der Provisionierung von Cloud Diensten am einfachsten mit PowerShell zu erreichen.

PowerShell soll kein Ersatz für das administrative T-SQL sein und vieles lässt sich auch sehr gut wenn nicht sogar einfacher damit abbilden. Dennoch ist PowerShell eine gute Ergänzung für die tägliche Arbeit und ermöglicht neue einfachere Lösungen.

Gebt PowerShell eine Chance, schaut Euch die grundlegenden Konzepte an und entscheidet dann.

Popular posts from this blog

SQL Server In-Memory OLTP – Isolation Level Beispiele

-
Image
Wie schon mal von mir erwähnt, erlebe ich bei den Teilnehmern meiner SQL Server In-Memory OLTP Workshops die meisten Schwierigkeiten bei der Verwendung der “neuen” Isolation Level. Zwar klingen für viele Entwickler die Level SNAPSHOT, REPEATABLE READ und SERIALIZABLE vertraut, nur schon bei den SQL Server “disk-based” Tabellen haben die wenigsten diese aktiv genutzt. Standard ist häufig READ COMMITED und das ist auch gut so. Die Tatsache, dass In-Memory OLTP aber ohne Sperren auskommt, fühlt sich für die meisten Entwickler erstmal befremdlich an. Zwar haben wohl die meisten Interessierten schon mal die Microsoft PowerPoints mit einer Erklärung des Version Stores gesehen und sich gefreut, wie schön da Versionen von Zeilen nebeneinander koexistieren können. Nur wie sieht das in der Praxis für den Entwickler aus? Der deutsche Begriff für die Technologie In-Memory OLTP “Arbeitsspeicheroptimierung” trifft es irgendwie nicht ganz. Zwar wird der Arbeitsspeicher wesentlich optimierter gen
Read more

MERGE in T-SQL – Der unbekannte Befehl im BI Projekt für ELT

-
Image
Wenn ich Diskussionen über die Entscheidung für eine ETL oder ELT Architektur führe oder auch nur moderiere, dann bringe ich als ein mögliches Beispiel für eine ELT Architektur gerne die Verwendung des MERGE Befehls. Nur wenige scheinen diesen Befehl bisher aktiv zu nutzen, dabei ist er schon seit SQL Server 2008 dabei und gehört auch zum SQL:2008 Standard! Was macht nun der Befehl MERGE? Laut den BOL das hier: “Führt Einfüge-, Aktualisierungs- oder Löschvorgänge in einer Zieltabelle anhand der Ergebnisse eines Joins mit einer Quelltabelle aus. Sie können z. B. zwei Tabellen synchronisieren, indem Sie Zeilen in einer Tabelle anhand von Unterschieden, die in der anderen Tabelle gefunden wurden, einfügen, aktualisieren oder löschen.” Und damit ist er perfekt geeignet für den Ladeprozess von Dimensionen in Data Warehouse/BI Projekten. Denn dort benötigen wir ja sowohl ein INSERT als auch ein UPDATE für unsere Geschäftsobjekte in den Dimensionen. Ok, und ganz selten mal ein DELETE,
Read more

PSG Performance Driven Development für den SQL Server

-
In den letzten Monaten wurde ich häufig danach gefragt, was denn dieses Performance Driven Development (PSG PDD) eigentlich sei? Und welche Technologien wir damit meinen? In erster Linie verstehen wir unter der Performance Driven Development Methode weniger einen Technologie Ansatz, als vielmehr einen Rahmen an Maßnahmen, damit das Thema Performance im Laufe einer Software Entwicklung den Stellenwert er- und behält, welcher bei Projektstart als notwendig erachtet wurde. Entstanden ist die Idee zu der Methode u.a. aus dem Feedback unserer Schulungskunden. Es wurde uns zwar attestiert, dass die Teilnehmer unserer Workshops und Schulungen einen deutlichen Knowhow Fortschritt machen würden, dennoch wäre es für den einzelnen Entwickler immer wieder schwierig sei neues Wissen auch so einzusetzen, dass die Projekte bzw. Produkte davon wirklich partizipieren. Der Alltag von Entwicklern sei ja stark getrieben durch ein agiles geprägtes Umfeld und Stakeholder, für die diese grundlegenden t
Read more