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.
One probably seldom thinks of the SQL Agent jobs scheduled on the SQL Server instance – unless they fail. What if the job failed because something was changed in the job? Maybe you knew about the change, maybe you didn’t.
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.
One of the things that should seem very commonplace to a data professional is the effort to become a lazy DBA. A lazy DBA is not a bad thing. It just means the DBA works hard to automate the repetitive mundane tasks that may be tedious and/or time consuming.
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.
It isn’t very often that one would consider a short circuit to be a desired outcome. In SQL Server we have a cool exception to that rule – Extended Events (XE).
Thanks to Extended Events (XE), we have access to a guide of sorts that will help us better understand if our shiny new tool (automatic tuning) is operating as desired.
There are many useful targets within SQL Server’s Extended Events. Of all of the targets, the most daunting is probably the Event Tracing for Windows (ETW) target. The ETW target represents doing something that is new for most DBAs which means spending a lot of time trying to learn the technology and figure out the little nuances and the difficulties that it can present.
It is well known and understood that SQL Server requires a substantial amount of memory. SQL Server will also try to consume as much memory as possible from the available system memory – if you let it. Sometimes, there will be some contention / pressure with the memory.