• Skip to main content
  • Skip to primary sidebar

DallasDBAs.com

SQL Server Database Consulting

  • Services
    • SQL Server Health Check
    • Fractional DBA
  • Pocket DBA®
  • Blog
    • Speaking
  • Testimonials
  • Contact
  • About

Kevin3NF

Poll: What is Most Important to You?

July 26, 2024 by Kevin3NF Leave a Comment

What is the most important aspect of your SQL Server?

 

Pick up to 3

View Results

Loading ... Loading ...

Filed Under: Uncategorized

Degrees and Trade Schools

May 8, 2024 by Kevin3NF Leave a Comment

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

Filed Under: Career, EntryLevel Tagged With: syndicated

3rd Party Applications Have Issues

May 2, 2024 by Kevin3NF Leave a Comment

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

Filed Under: Index, Performance, SQL Tagged With: syndicated

Set-Based vs Row-Based Database Code

December 1, 2023 by Kevin3NF Leave a Comment

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:

  1. Set-Based Code:
    • Operations on Sets: Set-based code focuses on performing operations on entire sets of data rather than individual rows. This is aligned with the relational nature of databases, where data is stored in tables.
    • Declarative: Set-based code is often more declarative, meaning you specify what you want to achieve without explicitly instructing how to do it. SQL is designed to work with sets of data, and set-based operations leverage this design.
    • Performance: Set-based operations are generally more efficient because they allow the database engine to optimize the query execution plan. The database engine can decide the most efficient way to retrieve and process the data.
  2. Row-Based Code:
    • Operations on Individual Rows: Row-based code, on the other hand, involves operations that are performed on individual rows one at a time. This style of coding is more procedural and might resemble how you would approach data manipulation in a programming language like a procedural language (e.g., C# or Java).
    • Imperative: Row-based code is often more imperative, specifying the step-by-step instructions to achieve a particular result. It may involve using cursors or loops to iterate through individual rows.
    • Performance Concerns: Row-based operations can be less efficient, especially when dealing with large datasets, as they might lead to more I/O operations and additional processing overhead.

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!

Kevin

Follow @Dallas_DBAs

Filed Under: Performance, TSQL Tagged With: syndicated

Database Concerns – A Poll!

October 25, 2023 by Kevin3NF Leave a Comment

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:

Pick up to 3

View Results

Loading ... Loading ...

 

Thanks for reading!

Kevin

Follow @Dallas_DBAs

Filed Under: Uncategorized Tagged With: SQL, syndicated

SQL Server Backups are Not a High-Availability Solution

October 17, 2023 by Kevin3NF Leave a Comment

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!

Kevin3NF

Follow @Dallas_DBAs

Filed Under: backup, HADR, SQL Tagged With: syndicated

  • « Go to Previous Page
  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Go to page 4
  • Go to page 5
  • Go to page 6
  • Interim pages omitted …
  • Go to page 40
  • Go to Next Page »

Primary Sidebar

Search

Sign up for blogs, DBA availability and more!

Home Blog About Privacy Policy
  • Home-draft
  • Blog
  • About Us

Copyright © 2025 · WordPress · Log in

 

Loading Comments...