What advice do you have for others considering Quest Foglight for Databases?

I rate Quest Foglight for Databases 10 out of 10. I recommend a demonstration in your facilities to get an idea of its operation. They gave us a demonstration, and we quickly acquired it because we needed it. It is good to present a small demo within the facilities and have people use the product for 15 days to see its versatility. I also learned the importance of documenting what you are doing, especially the rules or advanced functions that you must be able to send alert emails. Foreign Language: (Spanish) Detecta problemas al instante, permitiéndonos responder rápidamente ante cualquier contingencia. ¿Cuánto tiempo lleva usando esta solución? He utilizado Foglight for Databases durante cuatro años. ¿Cuál es su principal caso de uso de esta solución? (Incluya detalles sobre su entorno). Utilizamos Foglight para motores de bases de datos y servidores de Google. Lo usamos en una nube privada, nuestro proveedor de nube es Google Cloud Platform. Foglight está centralizado en nuestro centro de datos, desde allí lo enviamos a diferentes sucursales y regiones del país. Comparta cómo Quest Foglight for Databases ha mejorado su organización. Si no fue así, explique por qué. Hemos estado usando Foglight durante cuatro años y nos ha permitido identificar las áreas problemáticas cuando nuestra plataforma comienza a degradarse y ver qué tipo de bloqueos existen en nuestros motores. ¿Qué características le han parecido más valiosas y por qué? La característica más valiosa es la capacidad detallada que proporciona SQL Performance Investigator. Te permite profundizar hasta el más mínimo detalle que ocurre en nuestra plataforma. Hace un seguimiento muy detallado y atómico de lo que se quiere buscar en relación al tiempo y a nuestras diferentes instancias. La capacidad de Foglight para diagnosticar y responder rápidamente a los problemas es fundamental. Detecta problemas al instante, permitiéndonos responder rápidamente ante cualquier contingencia. Es crucial porque mantiene la continuidad operativa al tiempo que evita pérdidas de conexión prolongadas y nos permite ser más proactivos antes de que la plataforma falle por completo. No sé si es en tiempo real, pero cada minuto barre toda nuestra plataforma y nos da datos. Creo que puedes reducir el tiempo. Sin embargo, eso podría consumir demasiados recursos, por lo que una vez por minuto es suficiente para nosotros. Recibo alertas por correo electrónico que clasifico como de advertencia, críticas o fatales y normalmente programo alertas para cosas que me interesan, como el uso del disco y la memoria. Lo configuré para que me notifique cuando esas cosas alcancen un umbral específico. Utilizamos las consultas intensivas a la base de datos de la solución para capturar transacciones fallidas y ver cuáles son las más costosas, como las que están sucediendo en este momento o las que paralizan el motor en caso de falla. Las notificaciones por correo electrónico son esenciales para detectar posibles problemas. Pero a veces cuando no se pueden ver todos los correos electrónicos, los usuarios también nos informan sobre cualquier desaceleración, por lo que el dashboard te informa desde la base de datos sobre la instancia que está sucediendo, qué transacciones se están ejecutando, quién la está ejecutando, etc. Afecta las operaciones de mi base de datos al ralentizar las conexiones de la aplicación. Se debe reaccionar a lo que está sucediendo, ver qué proceso está desencadenando el cuello de botella y decidir si se debe modificar el proceso o esperar un tiempo razonable para que finalice y tomar las regulaciones necesarias para mejorar la codificación. Estoy satisfecho con su capacidad para monitorear todo tipo de sistemas. Permite centralizar e incluso acelerar sistemas operativos y motores. Disponemos de un único motor y varios sistemas operativos. ¿En qué áreas se podría mejorar el producto o servicio? ¿Qué características adicionales deberían incluirse en la próxima versión? Quest debe lanzar una versión en español. Esto es fundamental porque no todos hablan inglés en América Latina. Es un producto excelente, por eso es super importante que ofrezcan la aplicación y atención al cliente en español. También te permite establecer reglas internas dentro del formulario, por lo que si todos no dominan el idioma, no podrán utilizar completamente el programa. Hoy en día, cada producto viene en diferentes idiomas. También podrían especificar mejor sus actualizaciones. Sería fantástico si existiera la opción de recibir algunos consejos sobre cómo utilizar la última versión por correo electrónico. Por ejemplo, podrían proporcionar algunos videos tutoriales para poder informarnos y decir: “Mira esto. Esto está optimizado. ¡Voy a investigarlo!". Siento que otras cosas más poderosas, como Angular UI, deberían ser importantes, pero no las estamos aprovechando. Probablemente podrían enviar pequeños consejos sobre actualizaciones en una nueva versión y nuevas modalidades. Esto sería bueno para los socios. Alternativas y consejos: ¿Utilizó anteriormente una solución diferente? De ser así, ¿por qué la cambió? Antes de elegir esta solución, ¿evaluaste otras opciones? ¿De ser así, cuáles? ¿Qué aconseja a otros sobre el costo de instalación, el precio y/o la licencia? El precio de Foglight podría ser un poco más competitivo en Chile y debería reducirse para los clientes antiguos, al menos en un 20 por ciento. A veces el precio es una limitación. Tenemos siete instancias y casi 5 millones de usuarios. Sí Quest Foglight pudiera reducir sus precios para los clientes que llevan mucho tiempo con él, podríamos tener más instancias. ¿Tiene algún comentario o consejo adicional sobre esta solución? Califico a Quest Foglight For Databases con un 10 de 10. Recomiendo una demostración en sus instalaciones para tener una idea de su funcionamiento. A nosotros nos hicieron una demostración y rápidamente lo adquirimos porque lo necesitábamos. Es bueno presentar una pequeña demostración dentro de las instalaciones y que la gente use el producto durante 15 días para ver su versatilidad. También aprendí la importancia de documentar lo que estás haciendo, especialmente las reglas o funciones avanzadas para poder enviar correos electrónicos de alerta. lable. We could scale and expand to new engines if they lower their prices. Rendimiento ¿Cuáles son sus impresiones sobre la escalabilidad de esta solución? Foglight es altamente escalable. Podríamos escalar y expandirnos a nuevos motores si bajan sus precios. ¿Cuáles son sus impresiones sobre la estabilidad de esta solución? Foglight nunca ha fallado. ¿Cuál es su retorno de la inversión? El mayor retorno es el éxito del 99,9 por ciento de Quest Foglight en mantener la continuidad operativa. Esto es importante porque nos permite tomar medidas correctivas ante la codificación mal hecha y la degradación de los motores que quedan fuera de funcionamiento en nuestros sistemas. Foglight ahorra tiempo y dinero. Los procesos complejos por los que tuvimos que pasar en el pasado están ahora todos dentro de la misma plataforma, lo que nos permite realizar una investigación rápida. Ahorramos alrededor de 500 horas al mes en comparación a como estábamos antes de implementar la plataforma. Configuración y soporte ¿La configuración inicial fue sencilla o compleja, de qué manera? La instalación no fue fácil. Lo realizó un instalador contratado por nuestros socios. Creo que ha mejorado en las últimas versiones porque parece ser un poco más transparente. La actualización anterior a 7.1 no fue tan difícil como la instalación inicial en términos de la arquitectura de los dos servidores. Ahora que hemos cambiado a SQL Server, hemos mejorado la arquitectura. Todo funcionó cuando el instalador colombiano lo implementó, pero fue difícil seguir lo que hizo y replicarlo. El despliegue duró un día. En cuanto a la estrategia, dividimos los servidores en dos: uno para los agentes y otro para la administración. Se requirió solamente a un miembro del personal para el despliegue. ¿Lo implementó a través de un equipo de proveedores o uno interno? Si se trata de un equipo de proveedores, ¿cómo calificaría su nivel de experiencia? Cuéntanos tu experiencia con el servicio y soporte al cliente. Les daría un 9 de 10. A veces tardan un poco, pero responden. ¿Cómo calificaría esta solución en una escala del 1 al 10 en cuanto a servicio y soporte? 9. Método de implementación ¿Qué modelo de implementación está utilizando para esta solución? Nube pública.

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

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.

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.

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.

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.

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.

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 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.

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.

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