What is the most important aspect of your SQL Server?
SQL Server Database Consulting
What is the most important aspect of your SQL Server?
Can we normalize a couple of things?
1 – Trade Schools. Back in the 80’s trade classes in high school and post high school were frowned upon, or looked down upon. Is that still a thing? It shouldn’t be.
I’ve had to rely on the expert skills of roofers, a plumber, HVAC experts, an electrician and auto mechanics all in the last 3 months. Every one of them was expert level in the trade as well as customer service.
2 – Not requiring degrees for non-degree level work.
Case in point, DBA work. If you have technical aptitude and a desire to learn, you can be a great DBA. I have three people on my team that came into IT as DBAs. Not the normal route, but its working just fine.
I get that degrees are a resume filter…but you miss out on amazing people that way.
Let me hear your thoughts!
–Kevin
As a SQL DBA, what do you do when a vendor application has performance problems that are code related?
Server settings don’t generally seem to be an issue.
Queries and vendor code…total hands off. I just point at code and say “There’s a great choice for optimizing in your next update!”
Indexes are the “Sticky Bits” in between client data and vendor code.
Seems like we get 30 indexes, or zero. Neither is usually right.
I get it…how do you tune an app for every possible use case for any client that may install it?
I always have my client get the official rules from the vendor. We don’t want to break an upgrade, or void a support agreement.
In some cases we’ve had to “Don’t Ask, Don’t Tell” our way into a solution with undo/redo scripts for very necessary indexes.
What do you do when tuning a 3rd party app?
— Kevin
In SQL Server, the terms “set-based” and “row-based” refer to different approaches or styles of writing SQL code to manipulate data. These styles have implications for performance, readability, and the way queries are processed. Let’s explore the differences between set-based and row-based code:
Example:
Consider an example where you want to update the prices of all products in a certain category. A set-based approach would involve a single UPDATE
statement that modifies all relevant rows at once:
UPDATE Products SET Price = Price * 1.1 WHERE CategoryID = 2;
In contrast, a row-based approach might involve using a cursor to loop through each row and update it individually, which could be less efficient:
DECLARE @ProductID INT, @Price DECIMAL; DECLARE ProductCursor CURSOR FOR SELECT ProductID, Price FROM Products WHERE CategoryID = 2; OPEN ProductCursor; FETCH NEXT FROM ProductCursor INTO @ProductID, @Price; WHILE @@FETCH_STATUS = 0 BEGIN SET @Price = @Price * 1.1; UPDATE Products SET Price = @Price WHERE ProductID = @ProductID; FETCH NEXT FROM ProductCursor INTO @ProductID, @Price; END; CLOSE ProductCursor; DEALLOCATE ProductCursor;
In general, it’s recommended to use set-based operations whenever possible in SQL Server as they are usually more efficient and better aligned with the relational database paradigm. However, there may be cases where row-based operations are necessary or more practical, such as when working with procedural code or handling complex business logic that is not easily expressed in a set-based manner.
Thanks for reading!
What are you most concerned about in your database platforms?
Please pick from the list below, and expand on your choice in the comments if you like:
Thanks for reading!
Please continue doing your backups!
Backups are Disaster Recovery, yes…but not HA.
Some will argue with this (in the comments most likely), but I broadly define “High Availability” as a system that can recover in seconds or minutes at most. Sometimes that is automatic, sometimes manual.
Backups might be quick to restore IF they are small enough and the right people are in place (not at lunch or otherwise out). But automated restores to prod just aren’t a thing.
SQL Server has this cute little marketing term called “Always On” which is nonsense. Always? Really? 9 Nines?
Always On covers both Failover Cluster Instances and Availability Groups. There are significant differences between the two. Both depend on the O/S Cluster…and they diverge a LOT from there. They are both HA.
Log Shipping (ancient tech) is great for DR and hitting your RPO number, but failover to a log shipped copy is manual.
Replication is not and never will be an HA or DR solution. Some things cannot be replicated, so they are lost if the publication database goes poof.
There are of course things outside of SQL Server that can help you hit your RPO/RTO goals. Feel free to share them.
What are you using for your HA solution?
Thanks for reading!