This is an introductory level method demonstrating how to quickly audit database objects and principals for granted permissions.
DBAs often need to figure out who has access to what. When that need arises, it is frequently adequate to just perform a quick permissions audit.
ARITHABORT can be a short termed head scratcher. Pay close attention to what has changed in the environment. Test alternatives. And check those connection strings.
There is plenty of legislation and regulation in place these days that strongly suggest the encryption of data within a database. In SQL Server, we have the ability to comply with these regulations in a couple of different ways. This article will discuss one method for encryption.
How you use a synonym can be a huge asset or it can be a significant dampener to performance. There are benefits and uses for these nifty little things. Check them out and let us know how you have been able to put synonyms to use to benefit you.
Have you ever taken over a server that had several maintenance plans on it? Have you ever really checked who the owner of those plans is? Or, maybe you had a failing job relating to one of these maintenance plans and you changed the job owner, but did you really fix the root cause? That could be one of those things that you inherited that could be annoying but you just don’t know it yet.
I explore the question of if it is possible to reboot the server from within SQL Server or even simply shut down the entire server. Well, you can certainly bounce the server from within a TSQL script – if you have adequate permissions (or know how to elevate your permissions).
As is true in most facets of life, things tend to get stale and old. Sometimes this staleness can be visibly represented as the wrinkles on your face. Other times, as with SQL Server, it may mean that a stored procedure or view stops working.
Cannot use the special principal ‘dbo’. This error message can be misleading. This article will take you on a journey of common mis-steps along with the appropriate fix for this error.
One of my all-time favorite things in SQL Server is security. No matter what, it always seems that there is a new way to abuse permissions. When people abuse their access level or abuse the way permissions should be set in a SQL Server environment, we get the pleasure of both fixing it and then trying to educate them on why what they did was wrong and how to do it the right way.