Hey, everybody. Welcome to our webinar today. My name is Julie Hyman. I am the product manager for Quest Toad portfolio, basically our database management tool set. But Toad is our most popular brand there. So it's what I use to introduce myself so people know who I am. We know you guys are Toad customers, but what you may not understand is that Quest has a wide variety of solutions around database performance and database management.
And so today, I'm going to introduce Tim Fritz, who is our product manager for our Foglight product line on performance management. Tim's going to give you a little overview of what performance management can do for you with Foglight. Take it away, Tim.
All right. Thanks, Julie. Hi, everybody. Yeah, thanks for joining. Appreciate your time. And yeah, I'm going to focus on Foglight. Like Julie said, we have other performance management products at Quest, but we're going to look at Foglight. We're going to dive a little bit into Foglight to explain the 24 by 7 monitoring it does and the benefits it can bring to you. So let's dive in.
So I'll start first by speculating just a little bit about your roles. As Toad users, I'm assuming that many of you are either developers or DBAs in your organization. So I'm going to speculate about some of the challenges that you're likely facing in your jobs. And I have a little bit of knowledge of that. I was a DBA before I came to Quest. So it's been a while, but I was a DBA, so I understand that role very well and things that come up.
And all I can say is I wish I would have had Toad and Foglight when I was a DBA. Unfortunately, we did not. But I'll talk about the benefits that it brings. Before I do that, though, I'll talk about what it is, make sure that it's very clear what Foglight is and what it's made up of.
So you, as a Toad user, let's talk about DBAs a little first. So DBAs, you are using Toad probably for schema management, et cetera, all those great things that Toad does. But how do you tackle performance issues? So you might have ways in your organization that performance issues are made known to you at this point.
But one of the aspects of performance management I really, really want to go through in some detail today is the importance of understanding performance bottlenecks, so not only knowing that they're happening, but really wrapping your head around what's causing them and whether or not they really, truly are problems and then how to address them and how to get them fixed, how to find the data to help you decide what to do to fix those problems.
So and then developers, you might well be responsible for performance of SQL statements that you're writing. And if you are, at some point, if there are issues with a SQL statement, that might well come back to you for some work, for some fixing, for some tuning. DBAs, one other point I wanted to make there is from experience, I know that your job performance is probably measured, at least somewhat, on the performance of the databases that you manage.
So performance of the databases, of the workloads that run on the databases, it's a big deal. It's important to the organization. All right. The last point there, that last bullet on this slide, all of this is made more challenging for you probably because there are more databases coming along in most organizations now.
I've got two numbers sitting there-- 10% and 90%. So the first one there is at least 10% of you-- well, no. At least 50% of you are managing more than 10% of greater volume of instances than you did last year. And so the volume of instances that you're managing has grown, and that's according to some DBTA research that was done this year.
And 90% is signifying that you have probably about a 90% chance of managing more than one type of database. So platforms are growing. So new database is coming into the company. However they're coming into the company, often they're going to end up with the DBAs to support.
So environments are getting more challenging. All right. So you use Toad for certain things in your jobs, but could you use it a way to solve these problems that are listed here on this slide? Maybe code doesn't run fast enough, or slowing down over time. Well, lot of reasons that could cause that.
You're going to need a tool to help you do that. A chronic issue is a time-consumer because it keeps happening. You might have problems like that, right? Or one of the really, really difficult kind of problems to solve are those intermittent kind of problems that pop up now and then just suddenly. Well, what caused those? Why is this problem happening today?
It happened three weeks ago. Let's try to dig in and figure that out, figure out why those are happening. All right. Another challenge, you might want to locate SQL statements that are good tuning candidates. You might want to try to focus your time on those statements that are going to be worthwhile for spending that time, that are good opportunities for improvement. Let's put it that way.
You might want to find causes of blocking or deadlocks. That's a common one, database environments. Managing or writing code for multiple database platforms. I just talked about that on the previous slide. That's getting to be very, very common, and it's a challenge in many ways.
Lack of visibility of performance bottlenecks. This is a huge one, especially as environments get more complex. But just having the visibility across all your different kinds of databases that you're managing and seeing the bottlenecks quickly is really important.
How about unplanned downtime? You have any of that. I hope not, but if you do, you need to figure out how to minimize that, certainly. And the last one there is really important too. This is probably the one I hear the most from customers that I talk to is that they want to be more proactive. Just being in firefighting mode all the time is a drag on productivity. It's a drag on morale for a lot of people.
Constant firefighting mode means you're not spending time on other things that are going to help the team and help the company. And there's the pressure of trying to fix the problem quickly. So there are other ways hopefully that Foglight can help you get to the point where you're being more proactive. So that's an important one.
All right. So what is Foglight? What is this thing? So I already mentioned, it's a 24 by 7 monitor, but that's kind of simplifying it. It is a monitor. That's true. It's going to monitor your environment, and it monitors databases, of course, which we're going to focus on here today, the white text in the circle diagram here. So it monitors all sorts of databases.
There are 11 different types of databases right now that we support. We're going to add a few more soon. So we are-- think of it in this way.
We're future-proofing your environment a little bit because chances are really good that any new databases that you're going to be using in the future, we either already manage help you see performance bottlenecks on or we will, or we'll be adding them. I just mentioned, we're going to add about three more in the coming months. So we keep up on those that our customers are telling us that are critical for us to monitor and manage.
Now, I wanted to quickly explain the rest of this diagram now. So databases is a given, but we also manage and monitor hypervisors. So if you're running on a virtual machine in VMware, for example, we'll monitor the ESX host and the VMs, the VMs that the database is running on, but also the virtual machines that your application uses otherwise too.
So it might be very helpful to see a broader view of the application infrastructure to really determine and triage where the problem is happening. Is it the database, or is it somewhere else? So containers, the operating system level, we'll monitor that, et cetera.
And then another aspect of Foglight, if you so choose, you can manage the cloud costs. If you're running in the cloud, you can help-- you can optimize costs in the cloud, get rid of zombie VMs, find overprovisioned virtual machines based on the resources it's actually using.
Maybe you can reduce the size of it and use less costly cloud environments. So those are all aspects of Foglight that a lot of people aren't aware of, but they're there. They're options. They're there. So just wanted to make sure that was clear.
So Foglight. How can it help you? So let's recap some of the database-related challenges here. Lack of visibility into your database environment. Maybe a more complex data environment than it used to be. Diagnosing problems quickly. Triaging that a slowdown is actually caused by the database, like I said. And being proactive instead of reactive.
So what if you could simplify performance management? And no matter how crazy things are getting with your databases and your environment and the learning curves that come with that, let's simplify things on the monitoring side and the performance management side.
What if you could have a real-time view of performance of all the databases in your ecosystem all from the same view? And what if you could be proactive and not just in firefighting mode? So we'll talk about some of the way that you can do that.
So you can use Foglight to see your entire database's state in one view. You can quickly learn about performance bottlenecks, like I said at the top of the call. I mean, it's so important to understand the nature of a performance bottleneck, not just know that it's happening. So a lot of tools built into Foglight to help you do that, to help you gain that knowledge so that you know how to attack it and how to fix that problem so it doesn't happen again.
Both real-time and historical performance metrics are going to help you as you perform those investigations. And Foglight has reporting, robust reporting, built into it. So as you might imagine, it collects a lot of performance metrics all the time, 24 by 7. It's collecting, storing history. You have real-time and historical data.
You can use any of that data that you wish. There are some canned reports, but you can create your own reports. You can automate them. You can use them as communication tools with other teams, like with DevOps teams or with DBAs and development teams or whatever, whatever's appropriate, or an architect or whoever, whoever has an interest in knowing what's happening on the database level, performance-wise.
So you can think of use cases like that in your organization. Chances are really good, some reporting from Foglight is going to be helpful. All right. So let's step through some use cases. I want to just show you, describe for you some of the ways that our customers use Foglight now to help them in their jobs.
So the first one is managing a large database ecosystem, having one view for all your databases in the ecosystem. So here you go. This is what-- this was what it looks like in Foglight. So this is the first screenshot I'm showing you. But up at the top of the screen, you're seeing all those tiles in the red bo-- in the red rectangle up at the top.
We have several kinds of databases being monitored here. We have SQL server, Oracle. We have some open source. It also monitors Redshift, Snowflake soon, so those cloud data warehouses, NoSQL databases. So whatever you're monitoring, you can see them.
You can see all of the instances that you're man-- that you manage. You can customize this view too. You don't have to see the whole world here. You don't have to see everything your organization is using. You can focus in on those things that you care about specifically.
All right. So let's talk about alerts. Now, on the previous slide-- I'll jump back there real quick-- you see that middle column with red and orange and yellow boxes with the numbers in them. Those are the numbers of alarms that we have. Those are the live alarms that are still-- that are still applicable for that particular database instance. And red is fatal, orange is critical, and yellow is a warning.
So that's important because you're going to want to know which instances are having the worst problems. So red is worst. But in a lot of cases, the yellow ones are really important. So the warnings are things like space utilization or any other kind of alarm that is based on a metric that starts off getting bad. It just gets worse over time.
Those kind of metrics, those kind of performance KPIs, really capturing the warning severity is really important. And that's part of being proactive, learning about an issue before it affects users of applications. Let's put it that way. So Foglight's very robust that way.
All right. So let's talk about these alarms or alerts. You can find out about problems that are happening now or, like I said, problems that are starting to build. So this is what-- well, the large screenshot here is showing an alarm template. So an alarm template is the mechanism in Foglight 6.0 and higher. We're on 6-- the current version as of today, when I'm speaking, is 6.1.
And these alarm templates were developed to make it very, very easy and user-friendly to set up all the alarms for a particular domain. So the screenshot is showing SQL server as the domain. There are probably 50 alarms out of the box for SQL server. And you can use an alarm template to set the thresholds.
So some of the alarms are based on threshold values. If a threshold is exceeded, an alarm fires, and the email notification might go out to somebody. All that is configurable by you. So for your environment, you see the third alarm down there, Process CPU Utilization. 80% at the critical level, 72% at the warning level. Those might be good for you, and those might be the default settings, but you can change those if it makes sense for a particular instance or for all your SQL servers, for example.
So that's the alarm template, and you can apply those for different instances, et cetera. And each alarm-- the smaller screenshot there is just showing you an example of a detail, an alarm detail pop-up that you'll see in the UI. So yes, email notifications can go out, but obviously, you're going to be able to investigate and examine the details of an alarm in the UI, and I'll show you a couple more of those as we go.
Now, another aspect of alerting beyond the threshold level kind of alerting is our baselines. So Foglight automatically calculates the normal range of behavior for certain performance metrics on a database. And it visualizes when baselines are exceeded, so any kind of devi-- or any kind of deviation from a baseline.
So you're seeing an example of that in the screenshot on that time plot graph there with a line where there's a shaded blue area going down the middle of that graph. That's the normal range of behavior. In this case, I believe it's a workload. It's a workload metric, so basically telling you how many sessions there are connected at any given point in time.
So I can see, at a glance, that if I had a performance-- if somebody was complaining about a performance problem around 12:00, around noon, I know that, hey, at that point in time, I had about twice as much activity on my database as normal. So that might be significant. I mean, that can tell me very, very quickly that, hey, this is an important clue because now I can dive in deeper, see what was running during that time that's so unusual because it is unusual.
It's outside of baseline. It's outside of the calculated normal. So that's a very, very important and insightful tool that Foglight just automatically has a place for you.
So alarms, another aspect of alarms is, well, the last thing you want in a monitoring solution is an email storm kind of problem, so too many emails hitting you all the time. And believe me, it can be a problem with monitoring tools. Well, luckily, Foglight gives you many ways to get rid of, to eliminate or at least minimize any sort of alarms firing that you just don't care about.
And that's the problem with email storms. If you get too many emails coming at you, it's really hard to wade through them and figure out which ones are really the problems. So the first aspect of making sure that that's not happening is setting those thresholds correctly for your environment. So any kind of alarm that fires is truly a problem. It's truly exceeding a threshold. Some metric is exceeding a threshold level that is truly a problem kind of level.
All right. Here's what-- again, yeah, here's an example. IO average read time. So this is on-- think this is an Oracle database. Yep. So it's telling me some suggestions on things I might try to do. It's showing me that at the time of the alarm, it's-- yes. It's deviated from the baseline. The baseline usually is a very, very-- a very, very low number.
At the time of the alarm, it wasn't, so that tells me something. It's outside normal. All right. So anyway, that's an alarm pop-up for that particular alarm. And then I can drill in and look at the metric behind that alarm. So again, that was the average read time.
And now I've gone into the workload analytics side of Foglight to see that oh, yeah, well, average read time is-- sure enough, if I look at about 10:42 on that time plot right there, I see that yep, there was a spike in average read time. And if there was a performance problem right around that, now I've got a pretty good clue. I've got something I can dig into and dive deeper into and see, well, OK, why is average read time higher than normal?
I can also see something important to the left of that spike, and that is that, for the most part, this metric seems OK. It's not a chronic issue. I could stretch this graph over weeks if I wanted to, assuming I have the history stored in Foglight. I can see if it's been a long-term trend going up or not.
OK. So anyway, another way you can use alarms is for capacity planning, things like tablespace usage. Am I filling up my allocated space for tablespaces for data files? It's good to know. So alarms will fire when you start to creep up on filling up a tablespace.
You can also use historical alarms to tell you what the trends are looking like. So I can go back in time and look at alarms, not just the alarms that are still live on the screen on the other dashboards, but also in history. Hey, I can check and see how often that same alarm has fired and see the progression of things getting worse over time. And that can be a very important help.
And it also helps with capacity planning for things like tablespace size because you can really, really get a good feel based on history, get a good feel on how much space you're going to need to allocate to that particular tablespace in the future. All right. And here's a graph to help you see that too. So there's the growth chart, if you will, for that particular tablespace. So over time, yeah, the profile is getting bigger over time. So based on that, I can project out and see where it needs to be.
Blocking. Another very, very common issue in database management, performance management. We show you the trends of block weight, whether or not they're over the baseline, which they are here. There's been some spikes over the baseline here, as you can tell. So abnormal kind of wait times going on.
And then if I want to drill into a particular blocking scenario, I can. I can see which sessions were involved, what they were executing, what the blocks were being held on, et cetera. So either real-time blocking, I can see that, or historically, I can go back and see that.
Outages. Well, don't need to tell you how important outages are. That's critical. And Foglight is certainly going to tell you about those. Now, little bit about diving into your SQL workloads.
So the first scenario here is looking at a statement that you already know about, so maybe a statement you've been coding, you've been working on. You want to take a look at it, see how it's performing. The smaller screenshot on the left is showing you a snippet from Foglight that depicts the profile of how time has been spent over time for the SQL statement. You can see if it's-- you can see that the statement's profile is changing over time.
I mean, it's definitely different than it used to be. And so that can be a really good clue too. If it's a key SQL statement in an application, you want to figure out why it's different. You can also tune it. So I'm looking at Foglight for SQL server or Oracle here. You can take this right over to our SQL tuning tool. SQL Optimizer is a tool you might actually have with Toad, Toad Xpert or Toad developer edition as examples.
We'll have the SQL Optimizer as part of it. That's what's depicted on the right-hand side here. So take a statement over to tuning, and try to find out different ways to write it, get some index advice, et cetera.
Then finally, there are tools built in to Foglight to help you find those culprits built into the workloads that you didn't know about. These are things that you aren't aware of. So you're going to see your top 10 SQLs by CPU usage, by IO, or by elapsed time, et cetera.
You're also going to start to be able to take advantage of the tools I talked about. The screenshot on the right is showing you CPU usage deviation, an advisory, talking about what that means and well, what should I-- what should I look into deeper to get more information about that?
There is multidimensional workload analysis. And again, I'm looking at SQL server or Oracle here. But again, you can look for a user, you look for a particular SQL statement, look for a particular routine on your database and see what sort of performance profiles it has had during some time period.
And there's a comparison tool here too. This is a big benefit for SQL server and Oracle users who want to see, well, what is different between, say, this morning and yesterday morning? Performance was fine yesterday morning, not so today. What's different? What's running today that wasn't running yesterday? Or what kind of resource consumption do I have today that wasn't being consumed yesterday? So again, major, major clues that can be gained from that kind of analysis.
Change tracking. So those dots you see on the timeline, those are depicting things that have been changed in the environment, like configuration parameters. DBAs, if you change a configuration, if you're running on a virtual machine and somebody adds memory or processor, those are the kinds of changes that can have a major impact on performance. But you might not know it. You might have no idea that those changes that you've made correlate to some performance issue on the database or in the workloads.
Well, this tool here, change tracking in Foglight, will show you that. We'll correlate those events width times the performance has changed. All right. So that's what I wanted to take you through. Now, I did want to mention, before I jump off, if you haven't yet seen Foglight in action, you can click on the link on this webinar's landing page, and you can go to the Foglight virtual lab, where you can take a look. So thanks for joining today.