DBAs: Guardians of the Data Assets
In this post, I'm going to talk about some of the business knowledge that DBAs need to save themselves from some painful decisions and situations. I'll explain why DBAs are the true guardians of the corporate data assets and why it's a mistake to ignore the business side of the data. Finally, I'm going to wrap it up with some examples of how SQL Sentry can help in these areas.
DBAs might believe that the database is their only responsibility—after all the title is database administrator. Some of their most important jobs are certainly database-specific (creating backups, testing backups, restoring databases successfully, securing databases, performing the right maintenance, etc.). However, there's much more to know and care about to be successful and meet the demands of the business.
DBAs should know about the entire system and how it interacts with the database. The overall architecture and individual components are all important to understand. They should understand what a checkpoint is, how SPIDs are assigned, how the plan cache is used and what is in it, how and when tempdb comes into play, and so many more things. Check out this SQL Server Internals & Architecture webinar from Kevin Kline for crash course to get you started.
Many IT functions are focused around the data. The system admins are responsible for the hardware, network admins are providing the gateway and keeping system connected, the SAN admins are dealing with the storage hardware and related responsibilities, and the DBAs are the guardians of the asset that everyone is using those other components for. All the parts are important, but most are a vehicle for end-users to get what they are actually after: the data.
As guardians of the data assets, DBAs must know about the data and how the business is using it.
- Who cares if a particular application is down?
- Who needs to be notified?
- How much does the downtime cost the company?
- How does that compare to the uptime costs?
- Use this information to make a case for the right High-Availability Disaster Recovery (HADR) solution
- How does that compare to the uptime costs?
- What are the busy cycles?
- Are there off-hours when it is convenient to do nightly database maintenance and jobs?
- What about long-term busy cycles?
- For example, you can't roll out a project during the most critical business times, which might last for months (e.g. tax season), weeks (e.g. holiday shopping season), days (e.g. specific events and holidays).
It's critical to know your baseline performance so you can learn what to expect and identify when something is wrong or in need of some attention to keep the business running. SentryOne SQL Sentry has built-in baselines for quickly comparing your current performance to the previous day, week, month, quarter, or year. You can also create custom baselines to meet your specific needs. Learn more with the Performance Analysis Baselines article. I have another blog post about how you can use Power BI to compare multiple SQL Sentry baselines.
Once you discover that CPU usage or disk latency is increasing from your baseline, you can take a closer look. Is this a gradual increase over time (indicating that an upgrade might be due to meet growing business needs), or is this a one-off spike that needs immediate investigation? SQL Sentry helps you jump into that investigative mode to find the cause.
For example, from the performance analysis dashboard (shown above), you can highlight a period of time with a spike, then use the jump to feature to jump into the Top SQL to locate the query causing the spike. From there, you can see the query and plan history, and learn about trends. Next, jump into the event calendar to see what else is running at that time, or maybe to processes to find a non-SQL server cause for a CPU spike. See the SQL Sentry Overview article for more details on discovering root cause with these features.
SQL Sentry provides a clean and intuitive way to visualize activity on your server through an event calendar. Not only can you see the jobs, Top SQL events, blocking, deadlocks, SQL Agent alerts, and other things, you can use event chains to create a workflow for them. Instead of jobs competing with one another for resources and bogging down the system, they can run in the order than you define. No more guessing that a job should take 15 minutes, only to kick off another job before the first one completes.
Advisory conditions have many uses, including letting you know when a system is offline, so you can send the right alerts to the people who need to know about a particular server. Some of them are used for knowing when system metrics hit a certain threshold or are used in combination with baselines to determine when performance is abnormal for your specific system. You can create your own from scratch using advanced logic (if needed) or customize the provided advisory conditions to better suit your business.
Storage forecasting uses machine learning to predict when you will need more space. Why wait until the space is low and make a last-minute decision, possibly at a poor time for the business, when you can plan ahead, make a better researched purchase, and schedule an upgrade at the best time?