Migrating the fun out of it

For almost a decade I have helped enterprises move their data into Azure. Whether it is an Oracle to SQL Migration, a APS lift and shift to Synapse or Redshift to Fabric, I have seen a lot of projects on data migration.

And all of them followed the same structure. Everyone starts confident, agile teams are in place, kickoff meetings are planned and there is a firm belief that this migration is going to help the company forward. But suddenly things will change, architects are doubting the build fast/fail fast philosophy, more data must be ingested. And while we are migrating anyway let's add some new functionality as well. But testing is becoming a lot more complicated. Developers are stuck in processes and the business is not seeing any added value soon. And on top of all that things appear to be a lot more expensive.

In this session I have accumulated all the good and bad things I have seen in all these years and share them with you. To give you a head start into your future cloud data project. If you don't want to make the same mistake everybody else is making you need to be in this session.

Help me troubleshoot like a pro

Imagine you are in the office in the weekend. This week you are responsible to patch a handful of database servers to the next service pack. But after the required reboot one of the servers will no start up. Everything you try from restarting, rolling back to attaching new disks does not help. After troubleshooting all night your manager calls in Microsoft support. An engineer comes onsite, looks at the error log, runs one or two commands and your database is back online.

Sounds frustrating doesn't it? In this session I will share my secrets and how I solved numerous incidents as a Premier Field Engineer at Microsoft Services. But more important, tell you why most database administrators or developers seem to fail at successful troubleshooting major issues.

Get a handle on your CI/CD process

Getting features delivered fast is a no-brainer in todays cloud, agile and fast paced online world. But delivering features in a SaaS online application is relatively easy compared to database changes. Of course there a tools to assist you but most of then focus on the technical side of things.

In this session I will demonstrate the concept of CI/CD in general and specific to databases. The focus will not be on the tools but on the concepts. And why some things will work while other might give you unpredicted results. Thinking about your model, how to apply changes, how to handle datatype changes can help you in a smoother transition when it comes to databases deployments.

You will walk away with a lot more conceptual tools and trades to take you database solution into the future.

Having fun with clustering

If you run an on-prem high availability or disaster solution chances are you are using Windows Failover Clustering. In my days as a database administrator I never found any reason to dive deeper into this technology. Neither did I want to. Until I picked up a course on designing large distributed systems. With that knowledge I took a closer look at what I knew about SQL Server and Failover Clustering.

I learned that there is more to it then meets the eye and you can do some nifty things when you know where to look. But you don't have to stop at Windows Failover Clustering. What if you took this concept and roll your own code?

In this session I will guide you through the concept of clustering, how this is applied in Windows and what actually happens when you create a clustered instance. You will walk away with a bit more knowledge on Failover Clustering and hopefully get inspired about additional options you have.

Your first steps inside the storage engine

When you work with SQL Server you probably know a thing or two about indexes. The difference between clustered and non-clustered. May you have heard about b-tree structures and now a thing or two about pages and extents.

But do you really know what is inside SQL Server? How data is stored? And maybe more interesting, why data is stored this way. And how is this done with other systems like Oracle, Postgres and Mongo? And how are data types inside your application related to SQL data types.

In this session I will guide you through the world of pages and how data is stored. What is the difference between varchar and nvarchar? Or how are dates stored? And, how does this relate to collations or codepages. Your backend api might use json in UTF-8 format, yet SQL Server might use a completely different format. I will show you how this works and help you to get a little bit more understanding of the storage engine.

If you are interested in getting to know just a little bit more about how data is stored on disk this session is for you.

Help me start up my database

Have you ever been on call during weekends to find that your SQL Server won't start up after a service pack? Or came in the office in the morning and as soon as you stepped through people starting shouting at you because their application stopped working?

In this session I will walk you trough some real customer cases I worked on in the past 10 years. And specifically restore cases where the database or instance failed to come online. I will show you the error, the suspected issue according to the customer making the call and walk you through how to troubleshoot and find the actual issue.

After this session you will walk away with just that bit more knowledge to confidently restore your database or instance when needed.

This session is very demo heavy and depending on the available session length can have more or less demos. The recommended session length is 60-75 minutes. However, anything from 45-90 minutes is possible.