If I get a ticket that says, "We had an outage a couple of hours ago," I'm lucky. Most of the time a ticket will say, "Let's evaluate this outage we had a month ago." Even with a tool like Foglight, that becomes significantly more difficult. The tools are very granular but the farther in time you go, the less granular they become. That's just common sense to save on storage. Once you lose the granularity, some of the intermittent issues might be lost.

That is why I always tell folks that if something happens or they're suspicious of something, "Before you file a formal request give me a heads-up on it right away." If I look at it quickly, I might be able to pinpoint the exact root cause. If we wait for the formal workload to escalate to me, the answer could be much less accurate. A lot of times it requires a lot of domain knowledge to be able to ascertain if it's related to the infrastructure, the syntax, or both, or just some weird thing that we usually attribute to hiccups with the cloud.

There's a companion product called Quest Spotlight that has some functionality in common with Foglight. But I'm glad that they will never really collapse into one. I believe this has been their strategy for at least for the past five years. Spotlight is something that I have used longer than Foglight because it's a cheaper tool. I wouldn't say less sophisticated, but it's targeting less senior people. In other words, it's very easy to navigate and could be used by executives and people who are not necessarily IT-savvy. Whereas Foglight is a lot more in-depth and requires significant expertise to derive the information you're looking for.

I often find that an initial estimate about the root cause is wrong. You're not working with a static environment, especially if you have mixed workloads such as online transaction processing with a lot of in and out, as well as decision support systems where you have a long query reporting. They're not easily separable these days. People just assume a database is supposed to do both. While it does do both, it's hard to fine-tune it for both. One is a race car and the other is a truck. How do you make a race car haul a lot of loads and how do you make a truck super nimble and fast? So you're constantly adjusting things.

Sometimes I have to go back and look at the baseline. The answer might be that it's Tuesday, and on Tuesday we usually have a bigger workload. Sometimes the answer is that nothing is going on, it's just the nature of the best.

I have to be able to separate the tool's capabilities from the inconsistency in performance due to the fact that a lot of stuff is going on and things are not always consistent. It's not always easy to pinpoint what is really causing an issue, but Foglight certainly helps to identify actual resource contention.

The solution helps in both ways because you're able to look at the baseline and see that on Tuesday this spike is acceptable. But you can also look at what it is about Tuesday that is causing us to run so much slower.

I've been hearing for the past 10 years that my job is obsolete and that AI is going to take over. At first, I was nervous about that. Now, I'm just laughing because, with every year and more functionality, it is becoming much harder to make tuning decisions. SQL Server claims to have auto tuning but it's very limited in scope. Any experienced engineer will tell you that when SQL Server comes up with any kind of advisories or any kind of suggestions on the index build, you have to take it with a grain of salt because its view is very limited. There are a tremendous number of dimensions you need to be able to evaluate. I feel we're still far away from a self-healing, self-tuning system.

We have had a lot of stability issues since we brought in Foglight to Lowe's. From the stability standpoint, Foglight really has to work and improve.

I know that Foglight is capable of monitoring OS parameters as well as cloud DB instances, but we're not really using those features. We're just using Foglight to monitor the DB infra, purely from the database metric standpoint.

The time it saves us when it comes to a root cause analysis differs from case to case. There are instances where the metrics that we are monitoring on the DB servers have really helped us to narrow down the root cause. For example, it could be an ORA-600 error which is causing our Oracle database server to have a performance issue. If that's the case, Foglight raises an alert and sends an email to the DB team. As a result, they may disable that particular alert or look into the alert. They may end up opening a case with Oracle.

The version that I'm using is not the latest version, so there might have been some improvement, but the OS monitoring is a bit lacking, and the high-availability option is a bit complicated to set up and it doesn't work all the time. 

The solution does allow OS monitoring, but that capability in the version we are using is not as efficient as the database monitoring. So we only use a limited number of functions when it comes to OS monitoring. Our version is 5.9.7. I hear that the newer version, 6.1, has better features and integration with OS monitoring, but we haven't started using 6.1 yet.

We use the solution's ability to proactively alert us to long-running queries, but we have not found it to be very useful. It's not because of the product. It just gives us a lot of alerts. The problem is that there is no cut-and-dry way to monitor long-running queries. Some queries would be expected to finish within five seconds, while other queries are expected to run for minutes or even hours. As far as I know, there's no easy way to set different thresholds for multiple queries. As a result, even though we use those alerts, we typically only look at them when a user reports an issue.

For Oracle, even though I imagined Foglight would be very useful, we do not use it as much because Oracle has its own built-in capabilities. Oracle has its own diagnostic pack, which gives you a very accurate performance snapshot within the last however many minutes you need. And most Oracle DBAs are already familiar with that feature. We tend to use the built-in Oracle features and we do not use Foglight's features that much on Oracle. It's not because the Foglight features are not good, it's just that Oracle already has built-in features to monitor ongoing issues on a very accurate basis.

The biggest thing I've learned from using it is the reduction in effort that is required to do my job. Don't tell my boss that.

My advice is "buy it." You won't know until you use it. I've been a DBA for 22 years and it really is an awesome tool.

We use Foglight to display the most intensive database queries, but it's on a per-server, per-instance basis. We haven't created a dashboard for that, although we probably should. I can drill down into a server and I can tell you, from top to bottom, which queries are the most expensive. It could help us to improve query efficiency but we don't use it that way. We have vendor-supported applications and they're responsible for that. So that's not our focal point.

Overall, it really is a good tool. I think it's the best on the market.

It's a great product. It's probably one of the best in this class and people should not hesitate getting on board with the product. I have found it's very useful for my DBAs.

There are certain situations where you actually need professional services, rather than going in there and getting yourself mired up in something that you can't fix yourself. You should really consider the use of professional services before you get involved in problems that you can't fix yourself.

Don't be afraid of the interface, because you can't break anything. Click on absolutely anything and everything you can find. That's how I learned it. I took a good two or three weeks, once we did implement this. Anytime I could click on something, I was clicking on it just to see where it was going to take me. I would jot some notes down to tell me, "This took me here, that took me there." Don't be afraid to click on something.

If my mouse will click on it, then I'll click on it. If anything, it's going to give me some information that I might not have had before. And if it leads me down a dead end road, I just back out of it. In that situation it may be because it's information that is either over my head, or it's information that's not needed. But I'm not afraid to click on anything because Foglight is there to help me. It's like tapping somebody on the shoulder and saying, "Hey, what's going on in here?"

When you purchase it you will get a liaison. I would recommend touching base with them as often as you can. The forums for Quest have also come a long way since 2016. Back then, they were barely existent, but they've come a long way. Use the forums. Don't be afraid to ask questions. There's no such thing as a stupid question because if you're asking, then you know somebody else has asked it.

Sometimes we'll use Foglight to drill down and see what's causing an issue. If things are baseline normal for us and we've already eliminated the database as being an issue, then we have to look at the server team, the network team, and even web support to see if they are alright. We really don't use it to track server activity other than CPU usage, memory usage, and the like. When we drill down, even though we've eliminated the database as the source of the issue, we use Foglight because sometimes it will show that we're getting some CXPACKET issues, which tells us it might be a network issue. So we do look at some of the other aspects of it, after eliminating the database as the issue, to troubleshoot.

The solution also has the capability to monitor a variety of aspects, such as the OS, hybrid clouds, and hardware across different platforms, but we really don't use that because we have a server team that does so. It monitors the system utilization. Of course, we can see if there's a load somewhere or if memory is being excessively hit. If the disk is busy, we might look at that and tell the storage team that they might want to look at their disk drives. Is there a problem going on with the storage state? Or the server team might look at the servers and say, "Yeah, the servers are being excessively hit." It's a good catch-all, but we can only make suggestions with Foglight when it comes to anything outside of the databases. When it is inside of the databases, Foglight gives us a wealth of information that we can take to the table and say, "This is what we found to be the problem, and this is what we think should be the solution."

In terms of using it to proactively alert us to long-running queries, we're getting into that frame of mind. We have it available, but a lot of our developers have created their own little pieces of code that check things on their side, to alert them, and those are not necessarily run through Foglight. We do use the alarms a little bit for checking on our availability groups to see if a failover has happened because we may not be aware of it. We also have alerts set up for databases that might not be backed up recently. We use that almost daily. Overall, we don't use the alarm part of it as much as we should, but we're getting there.

If you've got the time for it, the time to focus on databases in general, then Foglight is definitely worth the expense because of the information that it can provide for you.

The biggest lesson I have learned from using this solution is that it's worth it. It enables you to pin down troubleshooting within 30 minutes to an hour, whereas before, you'd be pouring over reports or data from queries for days. That's huge. The CIO has told me that since we've started using Foglight, we've actually gotten ahead of some of these issues and we're actually being proactive instead of reactive.

We're in it all day, every day. I and at least two other DBAs are in it regularly, as well as some AppDev team members that we're trying to get to use it. We've got other database wannabes that are using it and our systems admins use it as well. Overall, there are 10 to 15 users. In the IT department, it is used pretty extensively.

There aren't a lot of tools that I've tried to integrate it with. I'm in the process, when I have the time, of integrating it with ServiceNow.

Foglight allows you to go in, modify, or create custom rules. As a user of Foglight, when you create rules and dashboards, it is important to document them. If you are not careful about coming up with proper naming standards and documentation for anything custom that you create on top of what comes out-of-the-box, then when you have staff turnover over time and you are trying to go back and understand how things were configured, it becomes challenging.

Each environment is different. Different companies have different use cases. Understand your requirements and your use case. That is the key prior to jumping into implementing any product.

I would rate this solution as a nine out of 10.

Overall, I rate the solution a nine out of ten.

It will not fix nothing, you still have to be on expert level