June 2015 - Posts

I've got an opportunity for a SQL Developer for a project based in London but with most being done at home.

If you've got the drive to work independently with some input from me and have core skills in SSDT and SSIS then this could be for you.

I'm looking for someone that's worked in an automated CI/CD build environment and understands the benefit of this and is be able to set it up for ssdt and SSIS.

Ideally you'll have C# and powershell skills as well.

The work will be partly in London but also home working.

And the best part is you get to work with me, some of the time J (not sure whats worse working with me some of the time or all of the time).

If you're interested then tweet me @simon_sabin drop me a line at simon [ at ] sabin.io

Posted by simonsabin | with no comments

I started off learning Oracle many moons ago and laughed at this SQL Server thing when I attended a training course and found it didn't do this and that. But the one thing that stood out was tooling.

For the Oracle world everything was command line, or something that I can't remember the name of that was java based, slow and generally awful.

SQL Server had Query Analyser and awesome query tool, it was so lightweight. Enterprise manager an mmc plugin (ok this wasn't amazing but was good)

It also had SQL Profiler. This was just amazing, and looking at the world now with the focus on insights into application performance, error logs etc this really was way ahead of its time.

With it you could see all the queries hitting the database, their duration, the amount of IO, CPU it was awesome and has been the number one tool in any SQL developers toolkit ever since.

Well with SQL 2016 you get a new tool that not only Tells you what queries have hit but importantly how they've been compiled differently.

Probably the most common problem that I encounter that is not down to human error is that of SQL using a bad query plan.

I did talk about this back at SQLbits V http://sqlbits.com/Sessions/Event5/When_a_query_plan_goes_wrong its largely down to the optimiser estimating something wrong. The analogy is estimating the distance from your house to the other side of the world and coming up with 10m and so you decide to walk because using the car would be madness. Its going to take you a long time to get there. That's what happens SQL can pick a plan that is super optimal and super quick for a few rows but if the estimate is wrong that super plan becomes super slow.

The issue is that the optimiser may suddenly flip from one plan to another without warning. This largely happens when a plan is evicted from a cache and a new plan is written based on estimates that are wrong.

The query store will show you, for a specific query, the plans that have been used and the difference in performance. But not only show you it will let you say, always use this plan, that's the safe plan.

So make sure that you go and try the trial as this will solve many problems that you will encounter.


Posted by simonsabin | with no comments

Update 12 Jun 2016

I do love the capability that a saas offering gives you as a provider and a consumer. As a provider you can monitor your service and deliver a fix easily without deploying any new code to the customer. As a customer you get fixes in a much quicker cadence and without the hassles of upgrading software.

I especially love the attitude of the VSO team to getting features and bug fixes release. The bug detailed below is now fixed, thats super quick, well done

I'm really excited about the changes here and coming to Visual Studio Online(VSO) with regards to build and deployment. Once completed the process will be much more a kin to the friendly process that you get with other tools such as Team city.

As part of this the team have blogged about the ability to run tests as part of your CI build process. http://blogs.msdn.com/b/visualstudioalm/archive/2015/05/29/testing-in-continuous-integration-and-continuous-deployment-workflows.aspx

Full on release pipelines with approval etc aren't available yet but you can do a huge amount with the current vNext build process in VSO.

The part that is highlighted in the blog post is the ability to run tests on machines ala the Lab management in MTM. To get this to work you have to add machines to you project that will be the target of the testing.

Unfortunately if you have your VSO account connected to Azure active directory and you log in with a Microsoft account, not an azure active directory account then the machines dialog may not work.

To get it to work you need to be logged in as an Azure Active Directory account.

You can check to see if your VSO account is connected to an AAD by going to .visualstudio.com/_admin/_home/settings">.visualstudio.com/_admin/_home/settings">https://<account>.visualstudio.com/_admin/_home/settings (change <account> to your account name).

At the bottom it will say whether the account is connected.

I've been told there is a fix in the pipeline, which judging by past performance means it shouldn't be too far away.

Posted by simonsabin | with no comments