A Fine Slice Of SQL Server
Pat Wright wraps up another T-SQL Tuesday:
Thank you all for submitting to T-SQL Tuesday. I have summaries from each blog below, and I added my own comments. I’ve written about this topic in the SSC editorial that is coming out this Saturday. I’ll link back to it on this blog post, but you’ll find it here when it releases on Saturday.
Click through for posts from five participants this time around.
Leave a CommentSteve Jones shares a few stories:
Most of the time that I have had to consider risk and reward in the past relates to the effort to fix a problem. Not necessarily the time, or data loss, because those are factors that are secondary to me to the ability to get a fix in. Time can matter, but if the organization has a tolerance for time, then I can work with that.
This also goes to whether the organization is willing or likely to try to fix things, or even if they are willing to let me fix things. If not, then I am way more careful about how to approach a design decision.
Click through for those stories.
Leave a CommentAnyway, the load process at this customer had multiple steps. Truncate and then fill staging tables with the current data from various source systems. Use the data in those staging tables to update the first of the data vault tables. And then use a join between the same staging table plus the just updated data vault table, with a filter on the current date, to update all other data vault tables.
With some of the tables having more than 500 million rows and over 50 columns, this process needed some time. But that was not a problem. The load finished before the offices reopened. Usually. But not always. Sometimes, it would run a few hours longer. And nobody knew why the load would take extra time at those seemingly random moments.
Read on for the full story. It’s a sobering reminder that each environment is different, and something that worked really well in one environment may fare poorly elsewhere.
Leave a CommentRob Farley thinks about costs and benefits:
“How do you weigh the risk vs the reward of your database design decisions?” asks my old friend Pat Wright. And one of the examples he gives is around indexes. I like indexes, so let’s talk about some of the choices when you’re thinking about adding a new index. And for the sake of simplicity, a new nonclustered rowstore index.
A new index might make an expensive query be much faster. Users might feel like the application has become much snappier. But a new index is not free.
Read on for Rob’s thoughts.
Leave a CommentMarlon Ribunal summarizes a group of outages:
I expected stories about bad queries, failed deployments, storage problems, or maybe a database that decided to have a very bad day. What I got was much more interesting.
There were stories about ransomware, corrupted databases, deleted storage, power and cooling failures, an identity column reaching its limit, and even a floppy disk. A server Meltdown too.
Some of these outages lasted hours. Others lasted days or even weeks.
Click through for the list.
Comments closedSteve Jones talks about a tough week:
I was a relatively new hire, a former intern, at a large electrical utility in Virginia. I worked as a network admin at a nuclear power plant in Surrey, VA. I showed up at work on New Year’s Eve at 5:00pm. We were planning on deploying a new database server running SQL Server, along with a new application to track radiation exposure for workers. This was a mandated change to our tracking, which needed to go live at midnight. I was supposed to be a bystander, helping developers from our internal group implement the server and then take over administration for the future.
What could possibly go wrong?
Comments closedThomas Rushton whips out a story:
Anyway. Big Victorian mill-type building. First floor, document management, printing, post rooms, etc, going up. Second floor – erm… document processing? Finance? Third floor – IT, call center, network room, board room, lawyer-types. Fourth floor, just underneath that slate roof, held a smaller office full of debt recovery specialists, and the main server room.
What could possibly go wrong?
Comments closedDeb Melkin deals with disaster:
One morning, the help desk support person came over and said this one client was having performance issues. This was one of the cases where we would just reboot. It was early and there would be plenty of time for everything to be back up and running before the system was needed. So I gave the go ahead to reboot the server.
This did not go well. Read on for the rest of the story.
Comments closedAndy Yun has been a part of several outages over the years:
My very first job out of college, I worked at a small boutique internet consulting firm that did some hosting in our back office. We had a T1 line coming into our office, which was a space that was part of a strip mall actually. One summer morning, we’re at our desks doing our thing and “hey, I just lost Internet connection, anyone else?”
Click through for the conclusion of that story, as well as two other times everything went sideways. This might also be a good time to check your backups and make sure they’re working fine.
Comments closedA buddy of mine invited me to take a road trip and join him in Philadelphia, PA to take a tour of the USS New Jersey while she was in drydock for its required museum ship maintenance. Quite possibly a once in a lifetime opportunity – we wouldn’t be touring the inside of the ship, we would be walking around underneath her, on the floor of the drydock. I hit the road on Friday, and picked him up at the airport. We got dinner, unwound from our respective travels, and planned out the following day.
Click through to see what happened next.
Comments closed