A Fine Slice Of SQL Server
Patrick Gruenauer decides to continue:
Error handling is an important part of scripting and automation, and PowerShell provides robust tools for managing errors efficiently. One of the key features for error management in PowerShell is the
ErrorActionparameter. This blog post will dive into theErrorActionparameter, explaining its usage and providing practical examples to illustrate its usage.
Read on to see the five available options and a pair of examples.
Leave a CommentRam Ghadiyaram adds some error handling logic:
In PySpark, processing massive datasets across distributed clusters is powerful but comes with challenges. A single bad record, missing file, or network glitch can crash an entire job, wasting compute resources and leaving you with stack traces that have many lines.
Spark’s lazy evaluation, where transformations don’t execute until an action is triggered, makes errors harder to catch early, and debugging them can feel like very, very difficult.
Read on for five patterns that can help with error handling in PySpark.
Leave a CommentBrent Ozar has a public service announcement:
In Azure SQL DB, you set max degrees of parallelism at the database level. You right-click on the database, go into properties, and set the MAXDOP number.
I say “you” because it really is “you” – this is on you, bucko. Microsoft’s magical self-tuning database doesn’t do this for you.
And where this backfires, badly, is that Azure SQL DB has much, much lower caps on the maximum number of worker threads your database can consume before it gets cut off.
Click through to see what kind of error message you get and just how low these limits are.
Leave a CommentGilbert Quevauvilliers goes around looking for trouble:
In the past when there has been an error when loading data into the semantic model, there can be times when clicking on the View errors can either take a very long time to show those errors. Or in some cases it never shows you the error.
In this blog post I am going to show you an alternative way to quickly find the errors.
The column quality data preview option is absolutely worth keeping on at all times.
Leave a CommentAndy Brownsword looks at the two ways to bubble up an error in SQL Server:
I don’t use
RAISERRORoften – I usually forget which severity code to use. After looking at a sprinkling of them recently I decided it was time for a refresher, so come along for the ride.If you check out the online documentation it states that “New applications should use THROW instead”. It also sounds like its used to raise ‘RROR’s (whatever they are?). Neither are quite the whole story though. Let’s get into it.
My general rule of thumb is that I tend to use THROW most of the time, but RAISERROR in loops so that I can print out how far along in the process something is, as there is no WITH NOWAIT equivalent to THROW. Andy mentions using THROW; without additional parameters, and that’s very helpful when you want to maintain the original error message rather than wrapping your own around it. It’s not quite as useful as a re-throw in a language like C#, where you keep stack trace information, but helps with troubleshooting.
As for not doubling the letter if it is the last letter of the first word and first letter of the second word (raise error or help protect), it was the fashion at the time, like wearing a yellow onion on your belt. I suppose the intent was to prevent typos or make it look slightly better, but I’ve never been a fan.
Leave a CommentGarry Bargsley makes a connection:
Oh no.. my number one troubleshooting tool is not usable. Time to fire up a command prompt and connect via DAC, right?
Well, not so fast.
During a recent technical interview, I was introduced to a clever workaround that lets you connect to a distressed SQL Server using SSMS, even when it seems unresponsive.
Read on to see how you can connect without SSMS performing a bunch of background queries to retrieve data that end up using tempdb, and then resolve the issue.
Leave a CommentRick Dobson lays out some common issues:
Most SQL bulk insert and SQL Server openrowset tutorials skip file access issues that can stop imports cold. Both the bulk insert statement and openrowset function rely on the SQL Server service account to read a source file. The SQL Server service account must have read permission on the file or its folder. It is also convenient to have read & execute as well as list folder content permissions. Also, non-standard source file locations (e.g., C:\Users\Public\Downloads) may not grant default read access to the SQL Server service account – always verify before use.
Click through for several recommendations, links to additional resources, and a few scripts along the way.
Comments closedEitan Blumin troubleshoots an odd issue:
A customer reported that running
DBCC CHECKTABLEon several different tables kept failing with the exact same error:Msg 845, Sev 17: Time-out occurred while waiting for buffer latch type 4 for page (1:27527325), database ID 10. Msg 1823, Sev 17: A database snapshot cannot be created because it failed to start. Msg 7928, Sev 17: The database snapshot for online checks could not be created.
Read on to learn more about Eitan’s troubleshooting process, what the cause of the issue was, and the fixes (both the immediate and complete ones) needed to resolve the issue.
Comments closedAndy Brownsword does a bit of logging:
When creating SQL Agent jobs to execute SSIS packages we can choose the level of logging to be captured. Different settings are more beneficial under the right circumstances so it’s important to understand the differences to make the right decision.
These settings control the internal logging done by SSIS. This is out of the box and freely available, so why not use it effectively.
The real trick is that if you swallow all of the exceptions and errors, everybody will just assume your code is working perfectly and boom, problem solved. Or you could read Andy’s post and get actual information. Whatever works for you, I suppose.
Comments closedSean Gallardy has a public service announcement:
There’s been a resurgence of people pointing out dumps occurring in SQL Server when using linked servers with the ACE drivers. It’s been on the MCM email list, forums, SQL Server Feedback site, everywhere, and it’s basically the same response every time… ACE drivers were not made to be used as linked server drivers in SQL Server.
To be fair, how could the company that produces Access and Excel possibly be in contact with the company that produces SQL Server and create a driver that works well?
I have used the ACE drivers for PolyBase, though that was for fairly light-duty work and thus I haven’t seen any dumps. But I guess if you want a higher-quality driver, go with someone like CData.
Comments closed