Name: Announcing SolarWinds DPA, now purpose-built for SAP HANA
Uploaded: 2026-08-06T06:16:11.327Z
Duration: 43 min 56 s
Description: Announcing SolarWinds DPA, now purpose-built for SAP HANA

Transcript for "Announcing SolarWinds DPA, now purpose-built for SAP HANA": Hello, everyone. Good morning, good afternoon, good evening, depending on where you're joining from. We will be starting in about a minute. Let's give everyone the time to, you know, join in. So, yes, let's give ourselves a minute. Meanwhile, I would love to know where everybody is joining from. So feel free to drop that in the chat below. I would love to know where where you're all joining from. I joined from Hyderabad, India in case anybody is interested. Hi, Dhananje. I love Mumbai. Lived there for a couple of years. I think we will give ourselves another I know Hyderabad is a great city. Okay. Let's give ourselves another thirty seconds, and then we start. Okay. I think we are gonna go ahead and start this webcast. Thank you for joining everyone. I will, begin now announcing SolarWinds DPA. Now purpose built for SAP HANA is the title for this webcast. We are pretty excited to share some really cool information with you. You know, we want to give you some examples on how to troubleshoot this powerful database that SAP has built. My name is Sanj, and I am a part of the product marketing team here at SolarWinds. I'm also joined by Kovic Gaba, who is part of the solutions engineering team, here at SolarWinds, and he will be undertaking the demonstration today. I'm also joined by Gavin Stockdale. He is also part of the marketing team, and he will be you will find him in the chat here in there, and he's supporting us through the webcast today. What we are going to talk about today, is a very exciting announcement of SolarWinds. But more importantly, we are really excited about the partnership we had we have with SAP to make sure that this very, powerful database can help ensure that SAP workloads are performant, available. And even when there is an issue, we can take care of these issues fairly quickly. Moving on to the next slide. Thanks. Thanks, Kavith. So on June on June 30, you know, we announced that DPA twenty twenty six dot two. So far, DPA, has supported multiple database environments, whether it is on prem or cloud databases. You know, we have also, supported proprietary databases like SQL Server or Oracle or, even open source databases like Postgres, MySQL. With this release, what we, what we're going live with is, you know, we have expanded our support for SAP HANA, leveraging the same powerful capabilities of TPA with weight based analysis, taking you from identification all the way through understanding the root cause of a database issue, you know, getting to the root cause of vector. So when there is an issue, you can identify the issue and solve for the problem. What we have, you know, also done today is extended this product we have had for well over a decade to include both on prem and cloud based, HANA databases. And today, what we're going to do is, you know, have my very talented colleague, COVID, take you through this really so you can see for yourself how you can use, database performance analyzer or DPA, to really enhance the performance. And when there is a problem in the database, making sure that you can rectify that problem very quickly. Moving on to the next slide. COVID, if you can move ahead, that would be fantastic. Yes. You know, I mentioned our partnership with SAP earlier, which we are very excited about. So, you know, Solubent has made an investment in SAP HANA working together with SAP. You know, of course, part of it is to show our commitment to our customers, to you all. But part of it is also to show SAP's commitment to their customers. You know, it doesn't really matter which database you're running, whether it's Oracle, SAP HANA, SQL Server, or something else. That database is essentially providing underlying support for your applications, especially your most critical applications. Right? So when you are talking about SAP applications, your ERP, your analytics, finance systems, your month end or your end business close. These are all critical. It is essential that the database underneath is performing well so the application doesn't slow down. Because if that application slowed slows down, you know, that that impacts your business. Right? And and, you know, we we haven't just delivered on database performance monitoring for your on prem HANA environments. With DPA, we also support your cloud environments. And, you know, something that I would like to, lay a little bit emphasis on here is, if you look at SSP strategy today and, you know, where they are heading, there is a strong push towards modern cloud environments, and platform strategies. And, you know, we at SolarWinds are also aligned to support that direction. Right? And that's why understanding SFP's, approach and working closely with them has been essential. Before, we move on, I also would like to lay, emphasis on something else because there is so much focus on moving with the cloud. Right? It is important for you to know that, DPA, which is a self hosted solution, allows you to monitor both on premises and cloud databases. And that and and that now includes SAP HANA. We also have a SaaS based database performance offering that already supports multiple databases. And, you know, we have it on our road map to add SAP HANA to that SaaS offering as well. So whether you want to wonder your databases on prem, you can do that. And if you want to monitor from the cloud and be 100% cloud based, you will have that choice too. So before we get going and to make this a little bit, engaging, we are going to have, our first poll question pop up. I'm just going to read out the poll question, but, you know, we're going to leave it on for a couple of minutes so that, you know, you can you can respond to it. And the and the question is about what environment you are in today. So WhatsApp applications are you using today? Is it ECC, s four HANA on prem, s four HANA cloud, done, and, you know, and you're planning to move to SAP. We also we will also have another poll question go up, but I think we will have that maybe after the demonstration. So, yeah, why don't we, pass it over to COVID? Or to you, COVID, and I will be going on mute now. Thanks. Thank you for a quick introduction and a brief about our partnership with SAP. So, like, San has already quoted, like, DPA now supports SAP HANA. And, before I enter into, demonstrating what is that we are doing good in the DPA platform around SAP HANA, how are we helping the database administrators, I'd just like to quickly introduce myself. So hello, everyone. Myself, Povid Ghabha. I'm based out of India. Been with SolarWinds for quite some time, and I'm a solutions architect here specializing in the database portfolio. So and that's the intent that I've come here today with. So to make DPA a buddy of yours. And when I say a buddy of yours, as a database administrator or even as a sys administrator, DPA can help you detect and resolve a lot of issues that happen across the databases that we set out out of our docs. Right? And though the star of the day is SAP, but it does not mean that SAP is only and only, the database that we support out of DPA. And that's something that starts already covered. So there are a whole lot of databases that we actually support, on top of that. Right? Now coming to the typical business story, right, wherein the day in and day out, the people who are running the business as usual operations or maybe doing day zero day one jobs, they tend to hear on everyday basis or even somewhere it's every hour basis that something is wrong. Right? Maybe it's a CPU issue. Maybe it's, application slowness. Maybe it is a report which is taking higher load time or higher time to resolve or higher item load higher time to load for yourself. And as soon as such issues actually get encountered, that's where the blame game starts. Now let's consider a case wherein there was an application slowness issue reported. Now typically, as soon as such an issue is reported, we look into three or four layers in total. Right? We start from the application team. We start from looking at the transaction response time or from real user monitoring perspective. We look at the, user experience perspective. We look at, probably the application port as well. Like, something could be wrong there. Then the application team says, no. We are fine. Our application is running absolutely fine. There is no response time issues. Nothing reported at our end. Let's move to the next bucket, which could be the infrastructure and network layer. Now networks can be user end perspective or can be the data center or cloud networks, which could actually be having some issues. That's where the network team says, no. We are good. And that's what we have been experiencing, and that's what we have seen. Most of such issues lie in the database. Right? From the database perspective, people today can monitor the KPIs, the metrics just to see how your databases are performing. But there are very less solutions in the market which can actually help you to detect the very query, which is a causal of the issue. Right? And that's where we follow the evidence. We follow where the issue actually arose and what is the evidence that any platform like DPA is stating. And on top of it, we also give an explanation of exactly what happened with that all kinds of historical analysis, and that's where we unfold the complete story behind that something's wrong statement or an issue which was reported by by teams. Right? And that's what so where that's what we start with, and that's where the business starts. Right? We look at what's happening into the platform and what's happening into the applications. We look at, if it is as simple as a high CPU utilization, then probably let's see what's going on wrong. Is there a query? Is there a database instance which is actually consuming or maybe a process running on a machine which is consuming most of the CPU out of it? And that's where we look at what database or we want to look at what the database is telling us. Right? Then probably the most common question that is raised is what has changed. Right? The answer to it that we typically hear is nothing has changed. Right? What is different? Nothing. Yesterday, things were working absolutely fine. Now today, we suddenly see a spike of CPU or maybe an application slowness. That's where product like DPA actually helps you to run that comparative analysis to tell you what is different, what has changed in the exact query pointing out to the root cause. And it's not only detecting the root cause. It can also help you to find the solution and help you to prevent it, making the approach more proactive than relying or sitting in a reactive state. That's what we accomplished, and that's what we have actually learned and, developed in the SAP HANA state. Right? Now with that, I will move, to the demo, scenarios. And that's where probably, we'll say that, typically, what we planned for is is something like and that's what we usually do. We write terrible SQL statements in our lab environments. We generate workload. Let DPA capture it, and then we talk about the story. But that's where SAP actually failed us a bit, wherein SAP HANA kept making those terrible SQL statements into something very beautiful once and making them run as usual. And that's that's the it's not like we are fighting a slow database. We are actually fighting or we are actually trying to analyze a very faster database just like SAP HANA. And that's where we see, and we were able to actually still generate some load, and that's where the complaint window started. We were able to isolate the workload behind. So the use case behind it is that there was a order entry that was happening. There was an order backup report generation, which was actually encountering issues. So what we will be able to depict from that is how we will how DP helps you to isolate the workload, show where the actual time was spent. And if there was a healthy behavior before, we can actually run that comparative analysis and see why when the system was healthy. And now if it is in a bad state, then what is the potential bottleneck behind it? And even on top of that, we can give recommendations and confirm the recovery period also. Now with that, I'll just quickly move to the demo. So this is our, lab environment. I'm just I'm assuming a bit more. Yeah. So just before I go into the use case that I depicted, I'll just cover a couple of points on DPA. So DPA is, self hosted solution, which comes with a native GUI, the one like you actually see right here. And like I said earlier and Sanjal supported, it's not only about monitoring SAP HANA instances. The beauty of DPA is it can monitor majority of the relational databases, open source databases as well. And what you gain out of it is a single pane of a glass view, wherein you can actually avail and monitor all of those databases from a single glance and pinpoint that, yes, this is the database instance, which is going on wrong. So we are moving away, and we have moved away from the siloed way of working, wherein there are different different tools, the native solutions to monitor and administrator the database instances. Right? Now coming to the use case. Right? And like I said, star of the show is SAP HANA, so we'll be concentrating on that more. So this is Alpine Manufacturing is the database instance, which was actually monitored, which was actually supporting the order backup that issue that was being reported. So just by a single click, where I land into is a chart which actually shows me last twenty days data, how my queries have been performing. So it actually shows the top 15 SQL statements, which have been experiencing higher execution period, higher wait times. And what this is, I'll just take a couple of seconds on that as well. So, basically, DPA runs the complete analysis, the monitoring and capturing metrics out of queries, database instances, etcetera, using a terminology named as weight based analytics. Now which simply means that if a query is waiting over something, which ultimately lands into that, the query is experiencing higher execution periods. Right? And it is actually blocking something or it might be as simple as, like, we started with. It can actually cause application GUI to load slow or a report execution to be slower. And that's because there is a query at the back end, which is waiting on something, and there is a wait type involved. So DPA actually looks for them, those wait types, and helps you to resolve those kinds of wait types. And that's where it resonates well with the SAP HANA database as well because there is no such concept in SAP HANA. SAP HANA being Collierville database, it actually has a concept of thread analysis. But threads in SAP HANA are nothing are actually the weights. So it's all threads. It's just a terminology, but, ultimately, it's a weight. It's a weight based analysis, which DPA is helping to resolve. Right? Now coming back to the use case. So the users reported, the order backup history as or order backup as a issue on July 14. So if I just hover on the July 14, I can see a quick spike here, and I can see all the SQL statements. These are the SQL statements which were experiencing, higher wait times than the usual ones. And if I just click on July 14, now I am into a hour by hour sampling period, right, wherein I can see how my queries, feel performing during a certain hour. And here I can see between 6AM to 6PM, which is typically my business time. I can see a lot of spikes coming in. Right? And just by hovering onto it onto each of these, I can actually look at the individual sequence statements. Now this specific issue that was reported, it was reported at 10AM. So I'll just do a flip on 10AM, and now the charts have changed. These are now horizontal bars and the vertical bars that you see. And what we see here is the top 50 SQL statements that were executed between 10AM to 11AM on July 14. And it is all sorted by kind of in a descending order wherein we can actually see all the SQL statements which have been experiencing higher wait times on the top. And by this, I can actually simply see that this is the causal of the issue. And why I'm saying that is because this query has been waiting on something. There is no job, no no work that this query has done. If I just hover onto it, I can see that total of 55% of wait time this query has been experiencing. Right? It's twenty one minutes fourteen seconds that the SQL has been waiting on, and then there is another 45% of wait time around two wait categories that are identified. Right? So, ideally, this query hasn't done anything. It has been waiting and just sitting idle. And now by some might say that, okay. Why are you or how can you claim that this is actually, waiting on or it is actually idle in nature? That's because I can identify all the wait types. And this is this typically talks about that. This is this specific query has been experiencing logs. And this actually something that we have built with contributed with collaboration with the SAP team to actually see and, depict these kinds of way types or threads they may call it as and help you with the proper documentation. So this gives me a direction now. Right? I was able to see the very specific query which was actually going on wrong or, I was able to identify or detect the causal statement. Now on top of that, if I just check the weight, it's a lock. Right now I have a direction. What I need to look at is we have something called as a blocker star. Now here in the blockers, I can actually see all the blockers that were there or included in that specific moment. And here I can simply see there is a rogue user which is actually contributing or it is the cause of this particular issue. If I simply click on details, it would take me to that very SQL statement. So I now where we land into is a SQL analysis that DPA does. And here is a SQL text, which we have been analyzing so far. And a quick note on that here as well. If you see, these are the two way types which have been encountered in which we have been seen. Right? And there are blockings that are running across it. Now if I want to run a correlation between how this query has been performing and how my, something like resources have been behaving, so on and so forth, I can actually do that as well. So DPA actually gives you the power to correlate how your metric performance is and how your query is also performing. So you can actually have get that cross stack kind of an analysis to be done, right, which actually helps you to identify the very spikes. So, obviously, we know that the query is blocking and query has been blocked by certain systems. The rogue user in this case is the causal that we were able to identify. Right? But were there any metrics spikes? Obviously, you can get alerts on top of that. But if you just want to run a visual analysis, that is also something that you can pay down of it. Right? Now I'll just quickly go back to this block of stub and just talk about the rogue user here. So I can see the rogue user, and now I have a complete direction wherein I can simply come here on the SQL or let's go to the time slice for that matter, and I can actually create a mail. Probably, let's say I'll send it to it's already written here because, obviously, I've tested it. It's why in lab environment. So, let's send a note to the SDM, of alpine.com and tell them that the order backup issue is resolved. And then probably, let's say, okay. But, there's the root cause of auto backup issue is identified, and it was the rogue user, which was blocking the SQL statements. Upon killing this session, we are we were able to resolve the issue Resolve the issue. So just a quick check and a quick email to my boss would actually keep me relaxed. Right? Obviously, because I'm a database administrator, it's my job to see, that the the database is running absolutely fine. And I'm just gonna send it across. Now my boss would be happy, and he will actually keep me happy as well. I I hope so for that. Yeah. Just just a side note. Yeah. Okay. So coming back. So, basically, we can actually, fill the session. We did all of that. Now just to make the approach more proactive. Now this is something what we did was there was an issue. A user reported an issue. We came to DPA. We checked the instance. We checked the health of the queries, and we killed the session. We identified the user. We had killed the session. We resolved the issue. That's kind of, I might say, kind of a reactive approach. Now we can make it more proactive as well, wherein we can use the alerts in the DPA platform. So we have out of the box alerts across wait states, wait times, resources, and that's one of the USP of DPA wherein we can actually help you, or it gives an option to create customer ads as well. Right? Now in this specific case, let's say let's create a wait time, alert for a DPA database user. Right? Because that's the wait type, wait time that we were, we observed. So let's keep it the execution level at ten minutes. That's absolutely fine. And let's select the database instance. So Alpine manufacturing is a database instance that we know, was the one that was experiencing the issue. So we chose that instance. But, yeah, obviously, you get an option to choose as many instances as you want as far as you are monitoring them. If you want a couple of alerts only or running on a couple of instances, all that flexibility is given to you on the platform itself. And the user here is a rogue user, which was the identified, user or the causal of the issue. And here I can say, probably even if it takes more than one second, I need an alert for myself. Right? I can just choose the email notification that it needs to be sent to all the DBAs. Now if a rogue user is actually contributing to a total wait time of even one second, I would be notified. I don't need to wait for the application users to report that was the order report or the order backup report didn't generated or probably had, had some kind of a slow slowness. Right? I can actually test this alert. And, yeah, at the moment, the rogue user is not present. So that's where the value is zero, and the status is normal. But, again, it totally depends if it is an active issue, then, yes, you will be denote denoted accordingly. I'm not gonna save it because I know, this is something that I already had it, or already have an alert created for it. Now let's go back to the, SAP instance. And now while troubleshooting, what I was able to see so we and landed into July 15. We checked 10AM. But I want a comparative analysis, and that's what we have been discussing about as well. Right? Like, how the system was performing earlier. So if I wanna do that, I can go on July 14 as well and see how my databases were performing at that specific moment. I can actually see a spike at 6AM, which, again, is a potential bottleneck. And I can run the complete analysis as I did earlier. So here also, I can come and see the SQL statement. All the blockers that are there are all the potential weights. Again, highlighting the collaboration kind of or the kind of collaboration we have done with SAP. We were able to have these documents available for yourself. So, basically, you can actually take the direction given by this kind of a document. It will definitely help you to either troubleshoot or as, Max, as it can help you to resolve some of those as well. That's the power of DPA that actually can help you, and that's what I started with. It's a buddy of a database administrator, which actually helps you to run your day in and day out jobs pretty easily. Right? Now here, if I see the specific statement, I don't see the name. I can just see the query hash. Let's just filter on this query to see what this query is. Right? Okay. Now this seems to be, probably not exactly a mistake from my side, but this is some goof up that I have done in the database, being a database administrator, wherein I can actually see a SQL statement, which I simply ran into the production DB, and it shows a spike here. Right? I can go to the I'll I'll go to the analysis. This is a SQL text that I did. Again, similar, behavior that we see here, the complete trend. But, yeah, this time, it is the DDA who was actually running a test query. Obviously, DPA would capture it. That's the DPA's job to do that, and that's where DPA captured that I moved up. I actually ran a query on a production instance. It went into a spike. It blocked something. Hopefully, they have, not actually being reported. They have no issues reported around it. That's my luck, but I need to resolve it ASAP. So what I'll do is, obviously, I'll I'll check into the the specific, weight type which was recognized. I can also run the complete analysis around. In this case, I would like to look at the plan as well. So we also capture the query plans. It's a massive query that has been written. So, obviously, we can see the complete query plan from here. Now what I have to do is I have to actually resolve this so that I can escape, honestly. So I'll just go back to the DB users, look at, yeah, like I said, it's a system based, thing that I did. Again, time slice shows me the complete drill down ten second by ten seconds. So 6AM is the query when I executed it. So I can just send a note to myself. Let's say just a reminder that I don't need to or I should not be writing the queries and running them into the database or on the production database. Reminder to not execute queries directly on the production database. Rather, have a UAT instance and do deal with it accordingly. So click send. Now a email or a reminder is sent to me just for keeping me more proactive in nature, so that I don't do such blunders again in in in, the near future. Right? Now coming back to the sequence. Right? I can actually come here. Now, obviously, I've done this goof up. I need to refrain or I need to just hide it somewhere. Right? So we do have an option, and that's where I can just simply toggle it off, remove it from the trend stack. That's one. Second, this is another query which I created. Let me remove that as well. Just saving a bit of myself. Ah, let's go to July 14 now. Let's see. Ah, see. The 6AM spike is no more there now. So I was able to save my job a bit, I might say, but at least from an escalation, I saved myself, and it saves the day for me. And, obviously, I have the reminder for myself that, yes, as a database administrator, I need to be more proactive, and I need to rethink before I execute anything because there is a platform like BPA which can detect such points. And it's not that it would actually point out issues, in in ten minutes or fifteen minutes. I have escaped into no. That's not the case. DPA is as powerful as it can go into the near to near to real time situation as well for you. And that's what I just saved myself from. Right? Yeah. I guess these are the two specific, things. I just wanted to highlight that that's the depth and the breadth of the solution of the platform that we can leverage. And like we started with, it's not that DPA is a self hosted solution. It cannot monitor cloud environments or cloud databases. It can monitor them all. It can be on premise database. It can be a cloud, be it and in the SAP terms. It can be SAP on premise, or it can be SAP HANA Cloud. We support it all. So all is supported and up to the equal breadth and depths offered. So I'll quickly move back to the presentation. And from this, obviously, what we have and I am hoping that we have learned that there are symptoms that we experience in day in and day out around the databases. Right? Where our workloads in the SAP HANA database, which are being executed day in and day out, and that's where DPA preserves the evidence. DPA actually helps you to detect that in time, in near to near time, and also helps you to run a historical analysis to see how your database has been behaving, so on and so forth. Right? And gives you the right understanding of exactly what happened in the database just to avoid that blame game. Right? It's it's very, very, tricky situation when we enter into such blame game. So if we have a powerful platform which can actually help you detect what exactly is the caution with just a couple of clicks, it is a job for everyone and saves the day. Yeah. With this, I'm gonna pass it back to Sanj. Yeah. Thanks, Kobi. That was, that was quite elaborate, and you did a fantastic job. And I would just like to, again, reiterate before we move ahead. The database performance analyzer can help you regardless of where you are. So whether you are in the middle of a migration and, you know, you're still using a legacy database supporting ECC while moving to HANA on prem, whether you're moving to HANA in the cloud, or you're already on on HANA on prem and now moving to HANA cloud. There just there's so many different migration parts and database performance analyzer or DPA can be with you at every stage. It helps you analyze where you are before you migrate. Then as you start moving, it shows you what impact that migration has had on your database performance. And when there is an issue, it helps you quickly troubleshoot. This all starts with business impact and, you know, that's how COVID started his story. HANA, is a very, fast database. Its design and architecture are powerful, but they are also more complex and, you know, that can be a bit harder to troubleshoot. That's why we have worked closely with SAP to build out this offering so you can quickly identify when and when there is an issue. What's what's important here is, that regardless of which database you're using, DPA will give you clarity, whether that's looking at weights, blocking, resource pressure, or long term trends. Being able to quickly pinpoint where the issue is has been very important to us. Now with the announcement on June 30, we are very excited, and we're also in the process of getting BPA listed on the SAP marketplace. We're going to keep working with SAP, and listening to our customers, listening to all of you. And what's exciting is we already have some very large customers using HANA support and DPA today. So, as we move move into the q and a, please reach out to us if you need any help, and reach out to SAP as well. If you have any specific requirements or needs, the best way for us to support you is to know what you're looking for and, you know, then we can help you get there. We will have another poll question go up right now. We'll give you a few minutes to, you know, to answer it, and then we will follow that up with another poll, in the chat. Okay. So, COVID, I think we can move on to the q and a now. I'm just gonna look at the I am just gonna look at the q and a section. I don't see any questions in neither the chat nor the q and a. So either we have done a really good job because people don't have any questions, Yep. or, or we haven't done well or if we have done a terrible job because people don't have any questions. So if you have any questions, you know, feel free to drop them in the chat here, the q and a, whatever whatever you're comfortable with, then, you know, we'll try to knock it out of the park here. I don't see any questions yet. Code, what about you? Do you see anything? Maybe I'm missing out on something. No. No. Nothing in chat. Neither in q and a. Okay. I think maybe, we'll wait for another okay. I think we have a question from the manager. I think, Ovid, you can take a stab at it. Yeah. Go ahead. So the question says, what are the benefits over SAP monitoring? So the the benefits, I I'd say the first and the foremost benefit now I am not a SAP pro, first of all. I'm not a SAP expert, just to clarify that. But in the sense that, let's say the first and the foremost benefit is SAP today from where I see it is has been running in siloed work. So customers and cloud partners have multiple other database platforms. Have Postgres. They have MySQL or SQL Servers, and SAP HANA could definitely be there as one of the databases that they're hosting. So the siloed way of working and the siloed observability or monitoring would be still there with them, but there is no platform which can actually give you a single pane of a glass view to manage and monitor all kinds of flat databases from a single glass. That's the first key benefit that you get over the SAP native monitoring. Right? And other is that is more, the second is from a user experience perspective. So you need to be a HANA expert, obviously, to run that thread analysis and gain the thread analysis that SAP monitoring might be able to give you. And like I said, I'm not pretty sure if the tool that you're referring to is actually doing thread analysis or not. But the the the kind of monitoring or kind of visibility that DPA gives you is purely on that thread analysis slash rate based analytics, which actually gives you a deeper visibility on how your queries have been performing. Right? And the blockings and lockings help you a lot of it. Right? So it is SAP solution manager on older versions. Yeah. So, obviously, I'm pretty sure that they these are not, it it won't be actually as comprehensive as DPA can be for you because it's it's giving you immense depth into the queries, helping you with blocking sessions. And, again, it's agentless solution. Right? It's it's all via JDBC connection. So we actually believe that DPA is a headless solution. That's what I personally say because it causes very low overhead over the monitored instances. And it's just a single account using which we just authenticate to that particular database instance and pull the metrics out of it. So even the overhead is too low. That's another benefit that you gain on top of other any other solutions, even solution one manager for that matter. Okay. Thanks, Ananje. Do we have any other questions? Feel free to drop them in the chat on the q and a, whatever makes you all comfortable. I think we will give it another minute for any questions. Meanwhile, I just wanna say that, you know, you can also sign up for more webinars on SAP HANA and DPA. And if you actually, look at some of the docs we have, linked, in the chat here, you will see that we have, blogs around this. You know, we also have a web page around this as well, and the sign up links for the webinars are presented as well. So you can check them out and sign up if you would like to. Okay. I think, poll three is closing soon, so feel free to answer that. Okay. I don't see any other questions, in the q and a. So okay. Post three has closed, by the way. Awesome. Thanks, Gavin. Are there any other questions? Feel free to drop them in the chat or the q and a. I don't see anything come up right now. Okay. Anyway, thanks, everyone. Thanks about thanks for joining us today. Actually, I think we could do one more poll before we, before we round up. Yeah. I think, Evan, you can drop that in the chat. You can drop you can, drop the poll here, and we'll give everyone a couple of minutes. But just to sort of, just to go over it, if you use SAP HANA, what is your biggest challenge with performance today? Is it slow or slow or unpredictable queries? Is it lack of visibility into root cause? Is it capacity planning and resource provisioning? Or are you spending a lot of time, troubleshooting instead of fixing? And, honestly, you can just drop your responses in the poll here or drop it in the chat as well if you would like. Meanwhile, if you have any other questions, feel free to drop them. Okay. I think we'll give you all about fifteen more seconds to take care of the poll, and I think then we will thanks, Anandje. Okay. I think we are good to close the poll now and call it a day. Thank you so much for joining everyone. It was good to have you. Have a great day. Have a great rest of the week, and see you soon. Feel free to sign up for one of the, for for one of seminars we have coming up. Thank you. Bye, everyone.