Planning to upgrade/migrate requires a fair amount of prep work. Some of that prep work involves auditing your server for any users that may still be using the instance.
1 DBA's Professional Blog
Planning to upgrade/migrate requires a fair amount of prep work. Some of that prep work involves auditing your server for any users that may still be using the instance.
If you are being serious in your role, then the amount of times you grant permissions to the public role should either be a) never, b) when you want to have a data breach, or c) you are testing in a sandbox to improve your skills.
A powerful little expression in SQL Server is the CASE statement. The CASE statement has the ability to “transform” data per business rules to help better understand the data in a given query. In the simplest form, the CASE statement is a statement that evaluates a list of conditions (in order) and returns the first matching result expressions.
The defaults in the msdb database are about what is missing. It’s missing quite a few things that could be critical to your environment.
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.