By: Allan Hirt on April 29, 2019 in SQLHAU, Training | No Comments
In honor of Star Wars Day (May 4th), all of SQLHAU’s training will be 40% off. That’s 40% off all classes – in person and online including the upcoming classes in Chicago this August. For a full list of classes, see the SQLHA Events page. Use discount code MAYTHE4TH.
Because the 4th falls on a Saturday, the flash sale will start Friday, May 3 and end at 11:59 PM on Sunday, May 5.
May the force of knowledge be with you!
By: Allan Hirt on April 26, 2019 in Consulting | No Comments
Stop me if you’ve heard this story before: company hires consultants for a “too big to fail” project, but the project goes awry. Deadlines are missed. Deliverables do not hit the mark. Lots of money is spent and to date, no real progress has been made. The consultants are fired even though they offered to fix the problem they caused … for more money. There is always risk in a “too big to fail” project. Risk can be managed and mitigated by people who know who what they are doing to deliver the project on time and (hopefully) on budget. That’s why you hired the experts at the consultancy, right?
This week, the Register reported that Hertz is suing Accenture for $32 million because Accenture allegedly could/did not deliver on what was contractually promised to Hertz. I suggest you also read the comments, as they inspired me to write this post and its follow up which will be coming in a few days.
Every time I hear a story like the Hertz one, I know deep down my job as a consultant (and a business owner) gets a little harder. I’ve been doing consulting in one form or another for about 20 years as my job title, but in reality, it’s been much longer. I’ve worked as part of small consultancies (such as SQLHA) and have been employed by some big ones you know. Consultants can get a bad reputation – sometimes for cause, other times for no rational reason. Here’s the painful truth: one bad egg often spoils it for the rest.
Existing or potential clients wants the best value and service for their consulting dollar/yen/pound/Euro. Working within budgets and keeping costs manageable is not optional. Consultants need to understand a customer’s price sensitivity/budgetary constraints. Do we want fair compensation? Yes. We’re not a charity and real expertise does not grow on trees. When consulting works, here is what happens: the consultant(s) do great work, deliver on time, fairly compensated, and customers are happy. Everybody wins.
Unfortunately, some “consultants” are better at business development and marketing than delivery. They are buzzword compliant, great schmoozers, and say all the right things. The customer gets all the right warm and fuzzy feelings to sign the contract, but as shown in the Hertz story and in some of those comments, things can and often do go awry when it’s time to work together, solve the hard problems, and deliver the solution.
Consultants Don’t Suck
More than once in my career, I have been hired to mop up the mess of another consultant and deliver what the customer should have gotten in the first place. They are skeptical of hiring anyone else because of how they got burned. Why? Clients who hire bad consultants fear that they will get very little return for the amount of money paid and no deliverables. From a people aspect, sometimes the admins and/or developers feel it is an us vs. them thing going on – the consultant is going to take their job, or worse, tell management they should be fired and are incompetent. That is a true story – I have heard that more than once where a consultant came in and said to management the staff was terrible when they were not.
To anyone who thinks that consultants are evil, understand this: there are good consultants!
A consultant’s ultimate goal is to make you successful. What success looks like will vary from project to project (examples: an assessment document, an architecure, an entire built solution, solving a perfomance or availability issue, upgrade to a new versions of <insert thing here>). The bottom line: when we ride off into the sunset, your company is better off, the administrators or developers are empowered, and goals were met or exceeded.
How to Effectively Use Consultants
When should you consider working with consultants? In my experience, here are five of the most common scenarios in our end of the world:
- Your staff has a lot on its plate. A new initiative needs to be spearheaded by folks wo have both the time and expertise to get it done by your deadline. Time is money and so is your company’s sanity—we’ll save both.
- To get a project done, there’s a skillset you do not have on staff. You need people who can augement and mentor your admins or developers not only deliver on time, but provide the knowledge transfer so that your everyone can manage things once the consultant leaves. REMEMBER, a need for knowledge transfer and training has nothing to do with how smart people are; new things take time to learn and master. Again, time is money. Sometimes it’s cheaper to hire than to have people bang around in the dark.
- You want to lean on people you trust when you have questions because they’ve been there, done that. You’ve worked with them so they know your systems, applications, and environment – , and the pitfalls thereof. Whether it is troubleshooting or just a sanity check, knowing you have people who are there for you provides peace of mind.
- In the overused buzzword bingo category, you’re looking to transform or modernize. For example, you have been mainly on premises but want to explore the public cloud or move towards hyperconverged. If your focus is SQL Server, you want people who understand SQL Server and those things (or different consultants that will work well together).
- You have upgrade/migration/patching pain and need the thorn pulled out. Sometimes it takes someone coming in from the outside to take a holistic look at what is going on.
Bringing in the right consultants is not only the difference between failure and success, but can be the spark to accelerate said success. This includes faster problem solving and enabling your team to manage as well as prevent future challenges. They understand the big picture (not just technical, but also the business and your company’s politics), yet can roll up their sleeves and get into the technical details. Good consultants have communication skills (technical and non-technical, written and verbal), mentor those they work with, bridge teams together, and may even be a good hang!
Here at SQLHA, we pride ourselves on being those consultants described in the last paragraph. Before we take on any engagement, we ensure it makes sense for both parties. We do not take on work we cannot deliver; that just leads to that dissatisfaction that Hertz experienced. We prefer to be those first call consultants who get it right and leave the customer happy from the start, but will also help remove the stress caused by someone else’s mess.
In my next post, I’ll talk about the role clients play on an engagement to ensure that the project is a success and delivers what they need. I’d love to hear your comments below since this is a hotbed topic. Do you think consultants are evil? What are your horror stories? What are some amazing things consultants have done for you or your company?
UPDATE – Here is a link to Part II.
By: Allan Hirt on April 16, 2019 in Business Continuity, Disaster Recovery, High Availability, Notre Dame | No Comments
Yesterday, a fire broke out at Notre Dame in Paris which caused major damage to the well-known landmark and religious icon. While it is certainly a tragedy, it could have been much worse. Why? There was a protocol for dealing with it. Let me explain and give a little background.
In the world of IT, we talk about the concepts of high availablity (HA) and disaster recovery (DR). Both may use similar techniques, but are very different exercises. High availablity is about surviving a smaller, more local failure with minimal to no downtime and impact. Disaster recovery is what you do when a catastrophic even occurs. Both of these fall under the auspices of business continuity. Business continuity relies on people, process, and technology, but should never be driven by a specific feature. It should be requirements-based. Without people, processes do not work – especially in the case of DR where human intervention is usually required. These concepts are universal and when they are implemented properly, work well.
In Paris, all of that all came together, According to the Twitter thread I linked above, there has been a protocol (read: process) in place since the French Revolution if fire broke out at Notre Dame: save the people first, then save the art, altar, and furniture after, finally landing on saving the structure. People cannot be replaced. Original objects cannot, and to a degree, buildings cannot even though they can be rebuilt. That protocol is about survival. Just this morning, the Guardian published an article on how the structure was being assessed for stability. Clearly the building needs to be safe for people to not only rebuild, but to ultimately use it when it is ready. The article also mentions that objects such as the Crown of Throrns have been secured and others which incurred smoke damage are being looked at by the Louvre. A massive undertaking is underway – and the work has barely even begun!
Now think about where you work and what goes on every day – solutions and their underlying applications, systems, and data power your business. Without them, things would most likely come to a grinding halt, and in a worst case scenario, make the business close their doors if they were down for a significant period of time. We live in a data-driven world. Without data, there literally is nothing. Could you process payroll without the HRIS data needed? How about processing a payment from a customer? What would happen if a record of all of your sales for the last month disappeared? I’ve seen all these scenarios (and more!) fail at companies over the years. In our data-driven world, less data is a bad thing to most companies. Data loss may happen in extreme scenarios, but the goal is to minimize or eliminate. Losing a month’s worth of data can be dealt with but you need to understand not only the technical side of the house to not lose that data, but also the non-technical aspects to devise the right solution.
I am not forgetting about people. By all means, the human aspect is important here. Make sure people are safe and sound before thinking about recovering systems. Systems also need care and feeding. They’re not going to be putting precious objects back into Notre Dame until it’s structurally sound and rebuilt, why would you bring SQL Server up if you do not have, for example, no storage or networking?
Things can change in an instant. You need to be prepared. Paris was. Whether it is an old iconic world known building and its objects, or your own systems and data, you need to account for business continuity to pick up the pieces after the proverbial dust settles. If Paris can get it right with Notre Dame, you can do it in your own environments. Contact SQLHA today to help ensure the survival of your business in the event of downtime events big or small.
By: Allan Hirt on April 1, 2019 in SQLHAU, Training | No Comments
Can you believe it is April already? I know today will be full of people trying to be witty and pull one over your eyes. This is not that at all. Later this month on April 22 and 23, I’ll be delivering SQLHAU’s SQL Server Availability Solutions in a Cloudy, Virtual World for the first time as an online, live class. It’s not only instuctional content but also features our famous labs.
Through Friday, April 12, there is a 20% discount available so you can grab one of the remaining seats. If you are looking to quickly get up to speed on modern SQL Server availability solutions, this is a class you can’t miss. Use the code APRILFOOLS at checkout.
By: Allan Hirt on March 25, 2019 in Availability Groups, Transact-SQL | No Comments
I teased this blog post a little while back at SQLBits, but I’m finally getting a chance to finish this blog post. No stale, scheduled content here – it’s always hot off the presses.
Anyway, at Bits I did a few sessions, one of which was on AG and FCI troubleshooting (I’m also doing one tomorrow night at Boston SQL). As I was putting the talk together, one of the things I came up with was around endpoints for AGs. How an endpoint is fully configured is not exposed in SSMS, but you can query SQL Server’s dynamic management views (DMVs) which is easy enough if you know what you are looking for.
I did some of the initial documentatio for Microsoft a few years ago for distributed availability groups. Since its publication, Microsoft has opened it up and anyone can suggest edits/comments via GitHub. So far so good – all of this plays into the bigger story.
Flash back to last summer. I saw this on Twitter from Glenn Berry which spawned into a whole thread (and to see the whole thread, click on the date)
When I wrote that documentation (and it was before 2018, if you care about such things), I used … gasp … a WHERE clause, not JOIN ON syntax. I’ve always written queries like that going back to the 90s. The gist of that thread was that some preferred the “newer” syntax like INNER JOIN, and subsequently, had the query changed to show that. You get the same results, but whatever. I didn’t take it personally and the thread was good natured.
Before you all start screaming at me they are right (no, they were not … more on that in a minute): yes, I’m old. Discrete math was a required course for me for my Computer Science degree. It wound up being fate that things like sets, joins, etc., became the foundation for my career. I’m not ignorant. These days I’m much more of an infrastructure guy, but I do write infrastructure-related queries (hence the AG stuff).
Pedro Lopes who is now on the SQL Server dev team wrote the blog post “T-SQL Misconceptions – JOIN ON vs. WHERE” which does a good job of explaining the “it depends” around the newer style of joins. Why link this article? Microsoft deprecated the OUTER JOIN operators in SQL Server 2008. Two other sources of information on this are here and here (the first is Ward Pond’s old technet blog, and sadly will probably go away soon). If you’re keeping score at home, WHERE clauses are not deprecated except if you’re using *= and =*). The changes people made were wholly unnecessary and as the author, the newer stuff is harder to decipher than what I originally did. They were putting their own biases onto things.
As an experiment, I wrote the endpoint DMV query in two variants: my preferred way (WHERE clause) and with the JOIN ON syntax. First up is the query execution plan for the WHERE clause. Click to make it bigger.
Figure 1. Query using a WHERE clause
Next up is the INNER JOIN
Figure 2. Query using a INNER JOIN clause
Spoiler alert: they have the same execution plan. There is no difference between
Figure 3. The actual WHERE clause
Figure 4. The actual INNER JOIN clause
From a results standpoint, you get the same output. In other words, zero difference all around.
Preferences are just that. Preferences. Don’t foist them on others. Deal?