Pay back to #sqlfamily community – T-SQL Tuesday #102

Riley Major invited us to this months TSQL2sDay – we should write about „Giving back to the community“ and some shall write about how they plan to start or people like me – who already started giving back – shall write about how we’re actually doing. So let me try to tell you my story about stepping out of the dark and getting into the #sqlfamily …

The lone Geek

My journey started about 6 years ago as I thought to myself that there must be a way to become stronger and get deeper knowledge about SQL server is able to. Also get around some problems with getting such specific training for an affordable effort/budget. I just wanted to know this „magic“ and started to google a little bit and came across some buzzwords which showed me a direction… which leads me to my registration at PASS Germany.

My first visit at the local PASS user group lasted for more than half a year but somewhen I did it 😉 After that, I visited the user group meetings on a regular base and then I heard about a community event called SQL Saturday… That’s where I wanted to be part of to strengthen my knowledge about SQL Server as a participant but never thought about changing to a speaker because I was so impressed with the knowledge, presentation and speaking…

PASS-DE - The Lone Geek

So I just joined several community events as SQL Saturdays, PASSCamp, SQLKonferenz and SQLGrillen from the easy side => as a participant. But somewhen it made „click“ in my head and I thought „Hey, if I’m already on-site why not helping and getting more in touch with those great guys/speakers?“ so I decide to write an email to Oliver Engels (Twitter) and Tillmann Eitelberg (Twitter) if I might volunteer during SQL Saturday Rheinland and “ Hurray they accepted…“

Become a First-Timer

So I started my „career“ as a volunteer on SQL Saturday Rheinland 2016 with filling bags, preparing booths and session rooms … which had made a lot of fun! I got in touch with more very friendly people of the German PASS chapter. #communityrocks

After a few weeks – also joined SQLGrillen – I made a decision for my own to submit a session for next year’s SQL Saturday and try some more opportunities to speak… in October 2016 I participated also as a volunteer at SQL Saturday Munich where I already felt the love of the #sqlfamily! It was so much fun being part of it and getting known by more and more people. So I also spoke to a Microsoft guy (Jan Schenk) who was responsible for my efforts creating the #Azure Meetup in Hamburg which I started in November 2016.

In 2017 was my first step out of the dark 😉 I was picked to speak twice at SQL Saturday Rheinland and once at SQLGrillen – my very first talks at a public event outside of my regional user group. I was very honoured, so much fun and it was a pleasure to be with such great SQL persons from all around the world. After those events, I can’t stop it and raised my goals for 2018 and further events. (Like speaking at an international event or a non-german user group)

Why? What do I get back from the community?

As I had written above there is so much fun and pleasure and more important to learn from all of the so great community people. For some people it might a good marketing effect to be within the community but why not… they sharing their knowledge with you and making it possible that such events can be organised. Ok, there might be one point… if their session is more about their own products or company and not the topic… that’s not fair!

For me the main part is sharing my knowledge and being part of that #sqlfamily… getting known to all the other, helping other to encourage to do their first presentation or organizing a user group. I love what I am doing! And if I’m able to help just one person to find his/her own way or solution… it makes me happy. 

Communitytreffen SQLGrillen 2017 - German and European #sqlfamily

Azure SQL Database Migration – Teil 2 – Data Migration Assistant

In meiner Serie zur Datenbank Migration vom on-premise SQL Server zur Azure SQL Database kommt heute der zweite Teil, die Migration mit dem „Data Migration Assistant„. Diese Migration ist relativ einfach, wenn man sich ein wenig vorbereitet hat und seine Datenbank-Struktur ein wenig kennt. Aber für einen „normalen“ Datenbank-Administrator sollte dieser Weg überhaupt kein Problem darstellen, da es sich ebenfalls um einen geführten Weg handelt und gut beschrieben ist. Meinen Teil zur Beschreibung der Vorgehensweise möchte ich mit diesem Beitrag leisten, vielleicht hilft meine Dokumentation in Wort und Bild jemanden bei der Datenbank-Migration.

Strukturen und Daten
einzeln
migrieren

Natürlich sollte man sich auch hier die gleichen grundlegenden Gedanken über die anzuwendende Strategie vor der Migration machen, darauf gehe ich hier aber nicht weiter ein und verweise dafür nur auf meinen vorherigen Blogbeitrag => Azure SQL Database Migration – Teil 1

Der Data Migration Assistant ist ein zusätzliches Tool, welches Microsoft kostenfrei zum Download zur Verfügung stellt. Dieser Assistent bietet eine Vielzahl von Mehrwert im Vergleich zur Migration mit dem SQL Server Management Studio, da er auch Kompabilitätsprobleme erkennt und frühzeitig aufzeigen kann. In der Microsoft Dokumentation steht folgender einleitender Text als Erläuterung zum DMA:

Die Daten Migration Assistant (DMA) können Sie zum Aktualisieren auf eine moderne Datenplattform durch das Erkennen von Kompatibilitätsproblemen zu Fragen, die in der neuen Version von SQL Server und Azure SQL-Datenbank-Funktionalität auswirken können. DMA empfiehlt, Leistung und Zuverlässigkeit Verbesserungen für Ihre zielumgebung und können Sie Ihr Schema, Daten und nicht enthaltene Objekte vom Quellserver auf dem Zielserver zu verschieben.

Quelle: Microsoft Doc => https://docs.microsoft.com/de-de/sql/dma/dma-overview

erste Schritte mit dem Data Migration Assistant

Azure SQL Database Migration via Data Migration Assistant - Schritt 1 - New Connection

Die Struktur-Analyse

Das Assessment ist zwar auch in der Migration enthalten, kann aber auch vorab separat ausgeführt werden. Hierzu legt man beispielsweise zuerst ein neues Projekt an, wählt dann die zu analysierenden Optionen aus und nachdem man die Zugangsdaten des Quell-SQL Servers angeben hat, kann die Analyse starten. Entweder das Ergebnis ist in allen Prüfungen grün und man umgehend mit Migration starten oder man muss vor der Migration erst einmal überprüfen, ob man die gefundenen Probleme irgendwie beseitigen kann. Im schnlimmsten Fall können die Datenbanken nicht migriert werden. Aber bitte beachten, dass der Data Migration Assistant auch von on-premise zu on-premise migrieren kann und somit auch eine Analyse vor der Migration von zum Beispiel SQL Server 2012 auf 2016 durchführen kann.

Azure-SQL-Database-Migration-via-Data-Migration-Assistant-Analyse

Die
eigentliche Migration

Da diese Analyse aber nicht bei Auswahl der Migrationsfunktion ausgeführt wird, so sollte man doch diese Analyse vor dem Migrations-Schritt einmal durchgeführt haben. Auch hier muss man ein neues Projekt anlegen und die Quell-Umgebung definieren, um dann dem ersten „Stolperstein“ zu begegnen…

ACHTUNG !!! Bevor man mit der Migration einer on-premise SQL Datenbank zu einer Azure SQL Database beginnen kann, muss diese Ziel-Datenbank als leere Hülle auf dem Ziel-Server vorhanden sein, erst dann kann man diese als Ziel für die Migration mit dem Data Migration Assistant auswählen.

Nun kann endlich mit der Auswahl der zu analysierenden Objekte innerhalb der Datenbank begonnen werden… hier haben Sie die Qual der Wahl und müssen die zu migrierenden Objekte auswählen. In der Regel nimmt man alle Objekte innerhalb der Quell-Datenbank, bei partiellen und/oder Test-Migrationen kann man natürlich auch nur einzelne Objekte anklicken und dann migrieren. Der Data Migration Assistant erstellt dann erst einmal ein TSQL-Skript um die gesamte Datenbank-Struktur in der Ziel-Architektur herzustellen, dieses Skript kann man auch für späteren Verwendungszwecke abspeichern. Erst wenn das Datenbank Schema erfolgreich deployed wurde, wird der Button für die eigentliche Migration freigegeben und man endlich mit Migration der Daten beginnen. Über den Verlauf der einzelnen Migrationsschritte (jede Tabelle kann dabei überwacht werden bzw wird als Progressbar mit Ergebnis dargestellt) wird man fortlaufend informiert, leider auch über auftretenden Probleme, wie es bei mir der Fall war.

Auch hier ein weiterer Stolperstein (der zumindest in der Version 3.4 vorhanden ist) über den man sich natürlich Gedanken machen sollte… Meine Demo-Umgebung ist SQL Server 2017 und das Ziel ist eine Azure SQL Database, beides wird laut Webseite vom Data Migration Assistant unterstützt, dennoch erhielt ich eine Fehlermeldung, dass gewisse Assemblies nicht in der richtige Version vorliegen würden…

The pipeline failed to query metadata for table
xyz

Could not load file or assembly ‚Microsoft.SqlServer.Types, Version=13.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91‘ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) 

Could not load file or assembly ‚Microsoft.SqlServer.Types, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91‘ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Azure SQL Database Migration via Data Migration Assistant

Nachdem ich dann aber das aktuelle Microsoft System CLR Types für SQL Server 2016 und 2017 nachträglich bzw zusätzlich auf meiner Testumgebung installiert hatte und ich die Migration erneut gestartet habe, lief die Migration der Daten erfolgreich durch. 😉

Azure SQL Database Migration via Data Migration Assistant - erfolgreiche Migration aller Daten

Wer jetzt genau hinschaut, kann feststellen, dass ich beim zweiten Migrationslauf nicht alle Objekte (67 statt 71) ausgewählt habe, denn es waren bereits Tabellen erfolgreich migriert worden, so dass es nicht notwendig war alles neu zu machen (ausserdem wollte ich das mal testen 😉 )

Fazit zur Migration mit dem Data Migration Assistant

Durch die Möglichkeit der vorherigen Analyse und somit dem Aufzeigen von bestehenden Problemen und der Möglichkeit nur einzelne Objekte zu migrieren, kann ich diese Vorgehensweise nur empfehlen. Allerdings muss man auch sagen, dass diese Variante der Migration nichts für kurze Ausfallzeiten ist, nur für die ersten Test-Migrationen… die endgültigen Produktions-Migration würde ich mit anderen Varianten der Migration durchführen wollen, dazu aber in weiteren Folgen dieser Serie mehr. 😉

Azure SQL Database Migration – Teil 1 – SQL Server Management Studio

Heute möchte ich auf die einfache und schnelle Möglichkeit eingehen, wie man mit vorhandenem Wissen und vorhandenen Tools (hier dem SQL Server Management Studio) eine Datenbank mit wenigen Klicks nach Azure migrieren kann. Immer mehr Unternehmen möchten Ihre Daten in die Cloud auslagern, um die on-premise Kosten zu reduzieren und flexibler auf Anforderungen reagieren zu können. Hierzu müssen die Datenbanken in die Cloud migriert werden, was auf unterschiedlichste Art und Weise zu realisieren ist. In diesem Blogbeitrag gehe ich nicht auf die Einschränkungen und Vorbedingungen einer Migration ein, es soll hier nur um die reine Migration gehen. Heute im ersten Teil der Serie „Azure SQL Database Migration“ um die Migration einer on-premise SQL Server Datenbank in eine Azure SQL Database mit dem SQL Server Management Studio (SSMS).

Wege der Datenbank Migration in die Cloud

Erst einmal muss man klären, wie lang die maximale Ausfallzeit sein darf… also wie lange man maximal für die Migration brauchen darf, denn davon ist abhängig welche Methode man wählt. Natürlich ist es auch wichtig zu beachten wie groß eine Datenbank ist, ob man diese in einem Zug migrieren kann oder nicht. Hier in meinem Beispiel geht es um die „Adventureworks“-Datenbank mit gerade einmal 272 MB, aber es gibt auch Applikationen bzw deren Datenbanken die eine Größe von mehr als 1 TB erreichen, da sollte jedem klar sein, dass man ein Backup-File von ~200MB schneller in die Cloud kopiert hat als ~800GB… da muss man sich andere Gedanken machen. Hier nun einige gängige Methoden:

  • Backup/Restore
    • mittels SSMS (TSQL/GUI)
    • mittels Powershell
  • Azure Migration Assistant
  • Azure Database Migration Service
  • Transaktions-Replikation

Je nach Anforderung an die Datenbank und das mögliche Zeitfenster sollte man hieraus wählen. Hier starte ich mit der Azure SQL Database Migration aber im SQL Server Management Studio über die grafische Oberfläche was vielen DBAs geläufig sein sollte. Über die Auswahl der zu migrierenden Datenbank (rechte Maus) das Kontextmenü öffnen und über „Tasks > Deploy Database to Microsoft Azure SQL Database“ den Assistenten öffnen.

Azure SQL Database Migration via SSMS

Nun muss man im ersten Fenster den Ziel Server in der Microsoft Azure Cloud angeben, sowie den neuen Datenbank-Namen, so wie einen Laufwerkspfad an dem das temporäre Backup (bacpac) abgelegt werden kann. (Achtung Größe => freier Plattenplatz). Man sieht schon, dass man zumindest einen SQL Server in Azure angelegt haben sollte, damit man hier weiter kommt. Wie man diesen Server initial anlegt, könnt ihr hier nachlesen => https://www.sql-aus-hamburg.de/einstieg-azure-sql-database-mit-powershell-teil-1/

Azure SQL Database Migration via SSMS - Bild 2 Azure SQL Database Migration via SSMS - Bild 3 Azure SQL Database Migration via SSMS - Bild 4

Die letzten drei Screenshots zeigen die vorgenommenen Einstellungen wie Azure SQL Server Connection String mit Angabe des Ziel-Datenbanknamen und der gewählten Performance-Klasse der Azure SQL Database (in meinem Beispiel Basic mit maximal 2GB) und einem Ablagepfad für das temporäre Bacpac-File, die anschließende Zusammenfassung sowie die abgearbeitenten einzelnen Schritte der Migration. Ich möchte noch den Hinweis geben, dass bei größeren Datenbank ein großer Zeitgewinn erreicht werden kann, also die Migration schneller erfolgen kann, wenn man inital ein möglichst hohes Performance-Level für die Ziel-Datenbank wählt. Dadurch erhält mein ein wesentlich bessere IO-Verhalten bzw einen höheren Durchsatz in der Datenbank und die Daten können schneller in die Datenbank geschrieben werden.

Azure SQL Database Migration via SSMS - Bild 5

Nach Abschluss der Migration (siehe oben) kann man umgehend wieder auf das eigentliche Performance-Level der Azure SQL Database gehen, damit erhält man im Azure Portal das folgende Bild, die neue Datenbank wird sichtbar mit dem Status „online“ und dem gewählten Performance-Level (hier „Basic“).

Azure SQL Database Migration via SSMS - Bild 7

Fazit nach der Azure SQL Database Migration mit dem SSMS

Die Migration über die GUI des SSMS ist einfache und schnelle Möglichkeit einzelne Datenbanken von on-premise SQL Server in die Cloud durchzuführen. Es sind nur wenige Klicks bis man eine erste Übersicht hat und nur eine geringe Anzahl an Konfigurationsparameter, die notwendig sind um mit der Migration zu starten. Die Laufzeit der Migration ist abhängig von der Größe der Datenbank und dem gewählten Ziel-Performance-Level, so dass auch hier eine Entscheidung leicht fällt. Für die Migration mehrer Datenbanken und „komplexeren“ Umgebungen ist die Methode allerdings nicht zu empfehlen, hierzu werde ich weitere Blogbeiträge schreiben.

In diesem Blogbeitrag von Chris Pietschmann zur Azure SQL Database Migration mit dem SQL Server Management Studio kann man weitere Hinweise und Informationen finden.

Migrate Between Azure SQL Database and SQL Server

Azure SQL Database – Probleme beim Löschen von Recovery Service Vault

Ich möchte euch heute von einer Erfahrung berichten, welche ich in den letzten Tagen mehrfach und wiederholt machen musste. Für meine Sessions bei der Imagine Cloud Conference und dem PASS Camp über Azure SQL Databases hatte ich einen Azure Recovery Service Vault angelegt, um dort die Backups für die Langzeit-Archivierung abzulegen. Nachdem die Sessions beendet waren, wollte ich aufräumen bzw für die nächste Session vorbereiten, hierzu wollte ich die ganze Ressource-Gruppe löschen (samt SQL Server, Azure SQL Databases und dem besagten Recovery Service Vault). Egal was ich versucht habe, der Recovery Service Vault ließ sich nicht löschen, der SQL Server mit seinen SQL Databases konnte erfolgreich gelöscht werden, der ARS Vault aber blieb hartnäckig bestehen… Die Fehlermeldung lautete sinngemäß, dass noch registrierte Server / Items vorhanden sind (Please delete any replicated items, registered servers, Hyper-V sites…), welche erst gelöscht werden müssen. In der Service-Übersicht war allerdings nichts hierzu zu finden, keine registrierten Server, keine registrierten Server oder Replicated Items, keine Größen… es konnte nichts gefunden werden, was darauf hindeutete wo sich noch etwas verbirgt.

fast verzweifelt - verzweifelte Suche - StockSnap_27XHUPB48N - aus dem Newsletter von StockSnap

Verzweiflung breitet sich aus

Wie kann ich also nun diesen Azure Recovery Service Vault wieder löschen? Wenn es sich wenigstens um eine generische Ressourcengruppe handeln würde, aber da ich zur Abgrenzung der einzelnen Veranstaltungen bzw der Einfachheit halber alle Ressourcen einer Demo in einer Ressourcengruppe anlege, damit ich sie schneller löschen kann… hätte ich den ARS Vault entweder gerne verschoben oder eben doch ganz gelöscht… (siehe Beitragsbild ganz oben)

Folgende Fehlermeldung habe ich wiederholt bekommen:

Deletion of ARS Vault failed - Error Message

Vault cannot be deleted as there are existing resources within the vault. Please ensure there are no backup items, protected servers or backup management servers associated with this vault. Unregister the following containers associated with this vault before proceeding for deletion : Unregister all containers from the vault and then retry to delete vault

Bei der Kontrolle des Azure Recovery Services, welche Server oder Backup Items noch in dem ASR-Vault konfiguriert sind, schaute ich natürlich als erste in den entsprechenden Service nach… aber egal welche Ansicht ich auch öffnete, ich konnte keinerlei verbliebenen Backups finden.

Deletion of ARS Vault failed - Backup Details on ARS

 

Also erst einmal eine Runde googlen ob jemand anderes dieses Problem schon einmal gehabt hat… und siehe da, so ganz unbekannt ist das Problem mit dem Löschen des Azure Recovery Services nach der Nutzung mit Azure SQL Databases nicht. Felipe de Assis hatte hierzu bereits einen kleinen Beitrag und ein Skript geschrieben => https://social.msdn.microsoft.com/ Der eigentliche Grund liegt darin, dass weder Azure SQL VM Server noch Azure SQL Databases dort als aktiv gelistet werden und diese explizit mittels Powershell zu löschen sind. Ich habe das Skript nach meinen Anpassungen hier unten angehängt, so dass ihr seht was ich meine…

Login-AureRmAccount

$vault = Get-AzureRmRecoveryServicesVault -Name "WingtipDB-LongTime"
Set-AzureRmRecoveryServicesVaultContext -Vault $vault

$containers = Get-AzureRmRecoveryServicesBackupContainer -ContainerType AzureSQL -FriendlyName $vault.Name
ForEach ($container in $containers) {
 $items = Get-AzureRmRecoveryServicesBackupItem -container $container -WorkloadType AzureSQLDatabase
 ForEach ($item in $items) {
 Disable-AzureRmRecoveryServicesBackupProtection -item $item -RemoveRecoveryPoints -ea SilentlyContinue
 }
 Unregister-AzureRmRecoveryServicesBackupContainer -Container $container
}
Remove-AzureRmRecoveryServicesVault -Vault $vault

Damit ließ sich auch der Recovery Service Vault einwandfrei löschen und dann auch die Ressourcegruppe und ich hatte wieder eine saubere Test- bzw Demo-Umgebung.

TSQL Tuesday #96: Community Menschen die meinen Weg beeinflusst haben

TSQL Tuesday #96: Menschen die meinen Weg beeinflusst haben

T-SQL Tuesday ist eine wiederkehrende Blog-Serie, die von Adam Machanic (b | t) gestartet wurde, jeden Monat ist ein Blogger Gastgeber für ein Thema rund um den SQL Server und jeder kann einen Blogbeitrag zu diesem bestimmten Thema schreiben. Diesen Monat ist Ewald Cress‏ (blog | twitter) unser Gastgeber und es geht um die Menschen, die uns in unserem Leben mit den Daten in der Community beeinflusst haben.

Ich habe lange Zeit keinen Bezug zu einer Community gehabt, in meiner Jugend war ich ehrenamtlich beim Deutschen Roten Kreuz und jetzt wieder mit „euch“ unterwegs.

Wer hat mich in den letzten Jahren beeinflusst?

Eigentlich fing alles mit dem PASSCAMP  2013 an… Ok, vielleicht schon etwas früher, als ich mich Mitte 2012 bei Twitter anmeldete und viel von einer #sqlfamily las.

Hier gilt es auf jeden Fall Brent Ozar zu erwähnen, der mich mit seinem Wissen und Blogbeiträge schon seit Jahren inspiriert und im täglichen DBA-Leben weiter bringt. Auch seine Beiträge zum Thema „Warum sollte ich einen Blog betreiben?“ zählen zu meinen immer wieder genannten Gründen. Leider habe ich ihn noch nicht persönlich treffen können, aber das kommt garantiert noch. Seine lustige Art und Weise komplizierte Dinge einem verständlich zu erklären ist einfach großartig!

Dann in 2013 war es mein Besuch beim PASSCamp und somit mein erster direkter Kontakt mit der deutschen sqlfamily aka SQLPass. Hier kann man nur die üblichen Verdächtigen aufzählen, die eigentlich immer auf solchen Veranstaltungen anwesend sind. => Oliver Engels, Tillmann Eitelberg, Kostja Klein, Niko Neugebauer und Andreas Wolter, um nur einige zu nennen… Ich fand deren Gruppendynamik genial und das ganze Miteinander… jeder kennt jeden, jeder lacht mit jedem und jeder redet mit jedem, keiner wird ausgegrenzt!

Da wollte ich mitmachen, irgendwie dazugehören… aber wie???

Henning L. @hlhr_dev Jun 2 thanks to all the speakers and specially to @sql_williamd for this great event #SQLGrillen

Also begann ich nach dieser Erfahrung mich mehr mit der PASS und deren Aktivitäten zu beschäftigen und fand unter anderem Cathrine Wilhelmsen, deren Community-Aktivitäten mich ebenfalls anspornten und aufzeigten, was ich wie anfangen muss => mehr Teilnahmen an lokalen bzw nationalen Aktivitäten der PASS. Dann kam das SQLGrillen von William Durkin und die Session von Andre Kamann über PoSh meets Ola Hallengren und das Zusammentreffen mit Andre Essing, welche mich dazu motivierte selber über meinen Schatten zu springen und als Sprecher in der PASS aufzutreten. Bei den folgenden zwei SQLSaturdays (Rheinland und München 2016) war ich dann erstmalig als Volunteer unterwegs und konnte so in die nationalen Aktivitäten der PASS Deutschland hinein schnuppern. Wie es der Zufall wollte oder das Netzwerk die Kugeln rollte, war der SQLSaturday in München der nächste Baustein in meiner „Community-Karriere“ und bescherte mir das Azure Meetup Hamburg.

In 2017 kamen dann die ersten öffentlichen Talks dazu, mal Firmenintern, mal in der PASS-RGV Hamburg, beim SQLGrillen 2017 (DANKE William) und gleich doppelt beim SQLSaturday Rheinland 2017 (Dank an Olli, Tillmann und Kostja)… all das in Verbindung mit meinen Blog- und Twitter-Aktivitäten sorgte dann dafür dass Microsoft mich mit dem MVP-Award auszeichnete.

Ich möchte auf diesem Wege also folgenden Menschen der #sqlfamily meinen Dank aussprechen:

Oliver Engels
Tillmann Eitelberg
Kostja Klein
Andre Essing
William Durkin
Andre Kamann

Ein besonderer Dank geht an Gabi Münster für die Unterstützung bei meinem ersten „großen“ öffentlichen Auftritt, im Endeffekt geht/ging es um den „Arschtritt“ um über meinen Schatten zu springen. Natürlich halfen auch viele Gespräche und Twitterkontakte mit zahlreichen anderen Community-Mitgliedern (Chrissy, Claudio, Rob, Dirk, Volker und vor allem immer wieder Conny!), um mich nun als Mitglied (zumindest der deutschen) SQLFamilie zu fühlen! VIELEN DANK! Weitere Ziele sind geplant für 2018 😉

Ein ganz besonderer Dank geht an meinen Team-Lead Thorsten Moeller, der mich immer wieder bei meinen Aktivitäten unterstützt und ein noch viel größerer Dank gilt meiner Frau, die diese Aktivitäten ebenfalls unterstützt und mir immer „den Rücken frei hält“!