In this article, I have shown how to use the power of automation to help identify the risk of having card data stored in the database. Identifying this risk is essential to helping maintain the trust of your clientele and protecting your companies most valuable asset – the data!
This article shows how to audit the logon events for SQL Server 2012 and beyond through the use of XEvents.
When looking for an easy method to audit Index changes, one of the first technologies to try really should be Extended Events (xevents).
This article shows a method to audit for index changes. The weak link in a solution such as this really boils down to the requirement that the solution needs to be in place before the index change occurs.
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.
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.
As a Database Administrator, something that should be part of your database audit is monitoring the growth of files. That means tracking when the log file grows and tracking when the data file(s) grow(s).
Knowing when an event occurred within the database environment is a very important thing. Being able to act quickly when certain events occur is equally as important. Sometimes, we may not find out about an event for a few days or weeks and then we are asked to figure out the who, when, why and how of the event. Hopefully there was enough foresight in place to plan for such a request to travel back in time.