A Fine Slice Of SQL Server
Andy Brownsword continues learning about Apache Spark:
We recently dived into Spark and saw how DataFrames use lazy evaluation to defer execution until needed. This is useful for defining segments of logic to be reused, but if this causes large, complex calculations to execute multiple times, there may be a better way.
Read on to learn more.
Leave a CommentNOLOCK is bad and you probably shouldn’t use it, but every time I mention that publicly, the pushback just keeps coming. I don’t know why people so firmly believe that their situation couldn’t possibly be affected by bad/random data from NOLOCK.
Today’s misconception comes from a LinkedIn commenter telling me it’s safe to use if you’re doing index seeks. Hoo boy.
Click through for the proof.
Leave a CommentNikola Ilic answers a question:
After my article on Fabric Warehouse CU metering, which caused a lot of people reaching out and mentioning that it helped them understand the topic better, I decided to cover SQL database in Fabric from a similar angle too.
Imagine opening an internal application, updating a few records, and closing it two minutes later. You check consumption afterward and see that compute continued accruing.
Before blaming the application, it helps to understand what keeps the database online, and what Fabric actually measures.
Read on for that answer.
Leave a CommentA few months after a clean migration, replication between the nodes in the global primary AG in a Distributed Availability Group (DAG) just stopped. There were no new deployments, config changes, or specific warning signs prior to this. Windows patching had occurred, the servers rebooted like they usually would, and the AG never came back together.
I know for myself, one of the most frustrating phrases that gives me the sense of impending doom is “nothing changed, why is this breaking?!”. That’s exactly what was going on here.
Read on to see how an innocent-looking configuration setting can cause issues down the road.
Leave a CommentPaul Turley shares some thoughts:
When I first learned that SQL Server databases were coming to Fabric, I wasn’t entirely sure how and why we would use it. Now that I’ve had a chance to use SQL Database in Fabric, I wanted to share some of my experience and thoughts about where and how it makes sense to use it. I thought: Fabric is an analytics platform, and we primarily store data in a Lakehouse or warehouse to prep it up for reporting and analysis with Power BI. Why would I want to store data in a SQL Server database in the Fabric SaaS environment? I’ve since implemented “SQL Database for Fabric” (aka “Fabric SQL Database”) in several projects and I’m just blown away by how fast and simple it is to use. In this post, I will dig into the cost and performance and use cases where this option makes the most sense compared to other hosted implementations of the SQL Server database engine.
Click though to learn more.
Leave a Comment