PurePerformance - 011 Demystifying Database Performance Optimizations

Episode Date: August 29, 2016

Do you speak SQL? Do you know what an Execution Plan is? Are you aware that large amounts of unique queries will impact Database Server CPU and also efficiency of the Execution Plan and Data Cache? These are all learnings from this episode where Sonja Chevre (@SonjaChevre) and Harald Zeitlhofer (@HZeitlhofer) – both database experts at Dynatrace – pointed out database performance hotspots and optimizations that you many of us probably never heard about.Watch the Online Performance Clinic -Database Diagnostics Use Cases with Dynatracehttps://www.youtube.com/watch?v=pEXfqzE-WQM

It's time for Pure Performance. Get your stopwatches ready. It's time of Pure Performance. My name is Brian Wilson and with me as always is my very beautiful co-host Andy Grabner. Hello Andy. Well, thank you. Actually, I think it's the second time I have to ask you, how do you know it's going to be an exciting show? We don't know yet.

We're striving. We don't know yet. It's always exciting. That's true. To me, because it's fun to do. And by the way, you should have, I know they're still on mute, the two people that sit next to me, but we sit in the same room. And we just had a little dance here when the jingle came in and they were excited and people were moving and shaking. Would you rather me start over and say,

Hey, everybody, today we have a really boring show and we hope you don't fall asleep. Well, we'll keep expectations low and then we can overachieve. You know, that's my motto in life. Every time I have to deal with something like that, I usually feel it's going to come out the worst this way i'll usually be happy at the end and speaking of happy we had we just uh so again and i feel like we say this every time but we record these in the past so we just had our uh over here in the united states we just had our july 4th independence day celebration um i think the last episode we mentioned the whole Brexit thing. And I believe I mentioned that we were actually the first ones to exit the UK. So congratulations to us. And I

just had a nice four-day weekend. So I'm nice and refreshed. Did you all work yesterday and the day before? Or did you get that day off just because we do or something? Well, officially, I'm employed in the US, but because I flew over to Europe, I did not get the chance to enjoy a free day. No, we worked here. Oh, well, good. But it's actually not too bad because I have awesome colleagues. And I think actually, Brian, I think it's time to introduce them. What do you think?

Yeah, I guess. We'll get the show moving on. Yeah. Hey, so with me today in the room, and obviously we start with a lady. Oh. Is that sexist? No. No.

It's nice. Yeah. And a lovely French accent, Swiss French accent, I would say. Sonia. Hi. Hi, Sonia. And Sonia, to speak about that even further, you are the first female guest on our show.

Wow! So, congratulations. You'll go down in history. That's good. It's not that difficult in computer science to go down in history, but that's why I choose computer science. You know, you always get to be the first one in some of the stuff.

That's awesome. So Sonia, product manager at Dynatrace, right? Exactly. For database performance, the new feature we have introduced recently, but also for the whole test automation features in Dynatrace, for which Andy has been talking a lot and is quite pushing me on that side to continue. And, yeah, I really like it here.

And do you also, did you, didn't you also work with the APM as a service component as well? Yes, yeah, I do it also as well. So I manage our APM as a service instances. So we have about 160 Dynatrace app instances in the cloud for customers or for POCs, and I'm also responsible for that part. Cool. And then next to Sonja is Harald. Hi.

Hi, Andy. Hi, Brian. Hi, Harald. Harald, who are you? Actually he's not in lederhosen today which is those folks that have seen him perform probably remember you with

your lederhosen are probably the oldest ones that we all have I think my lederhosen was older than all of yours together I think mine was more than 100 years old. No, I haven't brought them today, so I'm dressed rather casually today. And is it true that you're not supposed to wash those either? Yeah, and you cannot wash them, really.

So they're over 100 years without ever having been washed, huh? Even the dirt is over 100 years, yeah. But they don't smell bad, right? I was just gonna wonder how they smell. No, they don't smell bad. Or you get used to it after a while.

Is there any sort of feminine outfit counterpart to the lederhosen, or is that just the traditional thing, it's only on the male side? It's a traditional dirndl that just the traditional thing it's only on the male side of traditional yeah it's a it's a it's a dress like the one you see in munich for the for the oktoberfest you know so the ladies that that haul the beers around these are they're dressed in the end or the one that you see in the sound of music exactly so harald just a quick introduction besides being Harald, the later guy, what else is your topic? I work at Dynatrace here in the innovation lab.

And yeah, one of my topics is databases because I have a long background in database design, development, performance tuning. And, yeah, from database performance tuning to database performance monitoring, actually that's a very good company. And, Harold, have you ever been a DBA? No, I have not been a DBA. So I have worked a lot with databases, but only from the application side and from the tuning side, actually. But I have worked closely together with DBAs, but I personally never had the role of a DBA. And I only ask because every time I've seen you and or heard you, you sound very upbeat and friendly, which, you know, not to disparage any DBAs out there, but they typically kind of seem to be a lot more quiet and to themselves. So you don't really fit the DBA

role, which, you know, the preconception. So I was just didn't know if you were one that broke the mold or you just never were one. Okay, so we have that confirmed now. So I think the reason why we brought you on the show, both of you, is because recently we've been doing a lot of work around actually database performance monitoring management. We have seen databases being a potential performance problem for many, many years in the applications that we analyzed.

So, Sonja, you wrote two blog posts, one on SQL and one on Oracle performance band values. I mean, you have a lot. It's actually pretty cool. So if you go, listeners, go to blog.dynatrace.com and then search for probably Oracle performance and SQL Server performance. Yeah, yeah. Just database performance would show up also, yeah.

And I thought you covered some interesting topics around the, help me out with the compilation of queries. Yeah, yeah. So actually when talking with our customers and researching the whole topic about database performance, we always heard from customers, yeah, you know, can't you do something for the database? Because, you know, the database is slow and we don't know what's the issue because we are the developer. But we need some information to understand what is going on with the database.

And while researching that whole topic, we realized that one of the cause for database performance problem was the developer. But the developer was not realizing the effect its code had on the database and on the whole performance. So we started to investigate this use case. And the bind variables use case is something that's really, really interesting. It's actually when, as a developer, you write some code, you have basically two ways to send a SQL queries to the database. So you can either just write the queries and maybe you have some data that you get from a search form, like you search for a destination when you're booking a travel, a trip, and then you can just get that parameter, concatenate it with the

string and then send the queries to the database. If you do it like that, you will always send the new queries to the database. Every time the database engine will receive this query, it will have to look at it, make sure, okay, the syntax, the semantic works. And then for that specific query, the database engine will have to generate an execution

plan. Do you know what the execution plan is? Well, I just learned it in one of the webinars that Harold gave because we just did a performance clinic on database performance monitoring. So I know now, but I'm not sure. I mean, Harold, obviously, you know, because you talked about it. Brian, do you know what an execution plan is? I know I've seen them. If I were to explain it to somebody, I'm not sure I'd get it right. But I know it's basically looking at, it's breaking apart the query. And I know when we look at the execution plans that come back,

it'll tell you how much kind of work had to be done on each level, how many rows would be done by a certain include or not include, but the different select statements and, you know, the different components. But to be able to explain it well, no, I can't explain it very good. So why don't we, Sonia, why don't you explain it or Sonia or Harold, why don't you explain it for everybody else? Let's hear Harold's explanation because I didn't listen to the webinar this afternoon, so now I'm curious how he explained it. Actually, you'll get a lot more information about it. The execution plan is something that even in the time before we had tools like we now have with Dynatrace where we have this cool integration, the execution plan was always the thing we started looking at because when we have complex queries, especially with a lot of tables involved, different types of joins, different sub-queries, then the execution plan not only shows how many rows for a certain table have to be processed, but it also shows how the entire query is processed

so what is the the driving table what subset of data is chosen first to select rows from the next table what type of join is done here there are joints that are more expensive cheaper joints so but depending on on data content and depending on uh ways of of creating code here we can use one or the other or the optimizer in the database chooses to use one or the other we see whether an index is used. We can also see what other possible indexes there would be to use. And depending on table statistics, so information about how data is distributed in the table, this creates a certain number of costs for a certain join, for a certain index. And based on that, the optimizer selects the way to execute that query. Now, you can imagine that this is quite a time-intensive process.

And CPU. And there's lots of CPU. And CPU-intensive. Yeah. And CPU. And CPU. So actually, this parsing process, as we call it in the database language, is the process that takes most of the time. To find the right execution plan. Because, you know, when you send a SQL statement, you're just saying, please give, you're just describing the results you're expected to have. And the execution plan kind of translate that into the physical steps that the database engine has to do to retrieve the data. And this process to create the execution plan, the parsing, as Harry just said, is really, really expensive. And the problem is if you as a developer sends

every time a new query to the database without using band variables or parameter, as they're called in SQL Server.NET language, then every time the database engine will have to generate a new execution plan. So although you will keep sending the same similar queries, but just, oh, I want the list of travel journey for Paris, now I want for Los Angeles.

Now I want it for New York. Every time the database engine will have to generate a new execution plan. And this will cause a lot of performance issue into the database. I went to a workshop by Oracle. And that was an Oracle performance workshop really designed for DBA to really understand database performance. They spend the first two hours explaining that concept to the DBA, that they have to work with the developer, understand the queries that are being sent,

because not using bad variables or parameterized queries can change orders of magnitude in use. So it's not just making it one second quicker, it's making it 10 times, 100 times quicker, the whole database, because it's not so much under pressure to generate the execution plan.

And I remember the example, Harry, that you brought at the clinic we had earlier, the webinar, I think it was also you covered that in your blog, obviously, where you really saw CPU going through the roof on a database server because there were individual statements hitting the database server. The database server had to parse them, reparse them all the time. So basically a lot of parsing is a lot of CPU.

Yes, that's what requires CPU because all of the other stuff, the execution of the statement is just reading data from the tables. This is IO. Yeah, and then I think what was really nice, what you had in your blog, and you mentioned it today, Harry, the optimized version of that application, how positive impact it had on the resource consumption on the database server, therefore allowing the database server to be much faster

and actually other applications, obviously, to consume that. And I think what was also very cool, I'm not sure if you mentioned it today in the clinic, but in your blog you talked about also the caching. If you have a lot of individual database statements, not do they need to be parsed all the time so that the execution plan is created, but the execution will also have to be cached.

Yeah, that's a special case with SQL Server is that there is only one cache with SQL Server and this cache is split between the execution plan cache and the cache for the data. You know, usually in database, IO is what? Also cost time. So usually you want the data that you usually need to be already in the RAM,

not having to fetch it from the disk. And this cache with SQL Server is split between those execution plan and the data cache. And if you have lots of different SQL statements because you're not using those parameters and have to store the execution plan in the cache, the cache for the execution plan will expand and you will have less space available for caching the data that you need to read. So it will again have a negative impact on your database. And I think that's really interesting because as a developer, you won't realize it.

You know, you develop, you have your own database locally or development where there's not much going on, and then it goes to production and then everything is slow. And it looks for you as a developer as the database is the issue, you know? But actually, it's your code. Brian, I was going to say, this sounds, you know, a lot of all the stuff that you're talking about really sounds like it's, you know, again, my experience with DBAs. Although they should be, you know, it's, Sonia, you said at the Oracle event, they were explaining why this is important for the DBAs to be aware of. But it's important to note that I think in a lot of cases, the DBAs are looking at the overall health and performance of the database. They're not looking at the details of the queries and these other kind of components.

And that's supposed to be left to the developers. But whether or not the developers are looking at that is the big question. You can kind of think about it as the DBAs are the air traffic controllers at an airport. They're the ones making sure that the airport is running smooth, everything's getting out in time, and that the airport has capacity to handle all the flights. But the individual airlines are the applications, and the loading and unloading of the planes or the actual code are the queries here.

And it's the same kind of situation where if they're not loading those planes fast enough and properly, there's going to be that big backup. And that's when the traffic is going to start backing up at the airport, which is when the air traffic controllers are going to get upset and everything's going to get backlogged. So the whole reason I brought that idea into mind is this is the area that the developers have to really be looking at. Database performance is not all about the DBAs. It's really about the developers looking at these impacts that they're creating. And with those explained plans, with the prepared statements, with your bind variables, whether or not you're using those or the concatenated query and the thing, this all goes into impacting the performance of the database, but also then again, impacting the performance of the code. So I'm not sure how, do you all have an idea how widespread or how well adopted,

adapted developers are and looking very deep at what's going on in the database? Is this something that they need to really, uh, on their side level up on, or is it in your experience, common practice for develop all developers, let let's say or the majority of developers to look at this stuff? I think this is something that is upcoming but so far developers do not really have a chance to see what's going on in the database. On the one hand, because they don't have these tools on their side, because these tools are used by DBAs. And yeah, you mentioned DBAs before, you know how they behave. So a DBA is a DBA. And he looks into his data and the developer typically does not have access to that. Now, with what we show here with the database agent, we show that for developers so they can have, they get an insight in what's happening in the database.

On the other hand, you were mentioning we have to create that awareness on the developer side for what's going on in the database. I think we have to start even one step before that. The developers need more awareness for what is the database actually or what can the database do. Most of the developers still consider the database as a data storage. And they see SQL as one way to send data back and forth, if at all, because a lot of developers are not even using SQL. They use these ORM layers, like Hibernate for Java, Doctrine for PHP.

So these layers have been created to make it, on the one hand, easier for developers to use the database to not need to consider SQL or how a SQL statement is created or what's sent to the database. On the other hand, we lose flexibility here because when we have complex business logic

and we are using that or we have in a Java world, object-oriented code structures here to show that business logic. On the other hand, we have a database, a relational database, and these mappers map these object point of view to a database. Then the developer has – there's no need for the developer to think about what's going on in the database here. But the queries that are created from there, sometimes, especially in complex logics, are not really optimized and creating good performance. A typical result of these layers is the N plus 1 problem where we read data and then do a loop over this data, read more data from

the database, create single statements for each detail record that we want to get from there. All of this is something that we can do in one SQL statement. So the message here is before we even start to design an application and we select these ORM layers, we have to consider carefully what libraries we can use here not only to make it convenient for developers but also to get good results in terms of performance because performance is no longer a cool thing.

Performance is definitely a requirement, not only a configuration. I think one important thing is also the configuration of how you use those ORM, like Hibernate, you can really do it in a very well way that's really optimized and you can really in a way that's horrible and will cause performance problems. So I think the key here is you should always trace your statements and really understand which are the SQL statements that are generated and what happens, how many of them, are you requesting too many rows or too many, so really the amount of data.

And that's something that needs to be proactively done, you know. Every change is you need always to look at the code, the queries that are generated, and make sure you don't run into an issue. That's also why, I mean, I run it fortunately. And to pick up that framework again has features, debug flags. We can actually log out which statements are executed. But I'm not sure if developers are using it that frequently. I think some of them do.

But, you know, we obviously try to make it a little bit easier by providing not only the visibility into the SQL statements, but then also into SQL itself or into the database. That's a cool thing. The other thing from a designer application or developer point of view is the database is not just a data storage. The database has capabilities of executing logic. So especially databases like SQL Server or Oracle are very powerful here.

We can create stored procedures there with creating procedures or packages full of functionality. And then we just need to send over one statement to execute a certain procedure. We have pre-compiled code in the database we don't need that parsing process and that's executed very fast and we can pre-select data already there and just send back the final result set so this is also something that should be considered. What, not only queries, but what part of my code is better done in the database? And maybe do that in PLC crawl and not in Java. Well, I think for that, we need better collaboration between developers and DBA.

Because right now, you always hear the DBA, he's like the grumpy guy. I don't want to go talk to him and I'm the developer, I just want to stay in my world, in my Eclipse environment, my Java and just I'm afraid of this world and they are really actually they have conflicting goals, you know, because the DBA, his goals is the DBA

should remain stable, so no changes. The developer, his goal is the most changes in its deployment feature. So these two roles kind of come into a friction, and they need somewhere to start to work together, understand each other's work, and that's the way where you can reach also better performance and better scalability when people start talking together.

You know, like DevOps. Developer versus operation. Developer versus database. It's kind of the same stuff. DevBase? Can we put the same stuff. DevBase? Yes. Do you want to put a new term called DevBase? DevBase, no.

Never heard of it. Did you invent it right now? Just right now. We have DevOps and DevBase. One thing I wanted to say is you're right. This is the big problem between developers and DBAs. But I would not see the DBA responsible for stored procedures. I would see this definitely as code and developers responsible for that. Probably the DBA needs to give some guidance and you know how to...

Do people even know how to... You know, I remember when I was at university, we studied for two semester database and we were working with Oracle. And I don't remember that we ever talked about internals of the database, about execution plan. We just, you know, learn some, okay, some SQL statement. And as soon as the result was good, then we would get the maximum number of funds. No matter how many joints, how many tables, how many data, because we never looked at what's happening behind. I worked at a lot of large projects where the developer

was the only responsible for stored procedures. The DBA was not interested in that at all. What I see, and obviously we have a trend from regular relational databases towards, as you call them, Harald, the data

stores, right? Developers sometimes maybe misuse an Oracle or SQL server or a DB2 as a data store of name-value pairs, which is obviously the upcoming, or not only upcoming, we have them, right? NoSQL databases, or as we call them, NoSQL databases. And for these, it might be much, it actually makes more sense to use these OR mappers and an object is then basically stored as a name-value pair

or a set of name-value pairs. Yes, absolutely. And one of the reasons why these data stores, these NoSQL databases are becoming more and more popular is because we have an entire document and store it in one record. And so it's very fast to write it and also to read it back.

We don't need these joins of tables as we have in a relational database. So as many developers are not really deep into SQL and not really know how to use that, it's much easier to use an easier structure. But when we hear a lot of times that these NoSQL databases are so much faster than SQL databases, this is not really true. The way we are using them makes them faster. But if we are using SQL databases the way they should be used, if we use them efficiently, then... Yeah, because it's the same way, and I think I totally agree with you. So it basically depends on how we as application developers leverage the quote-unquote data storage

in the most efficient way for our application problem. So we can do a lot of bad things even with a NoSQL database if we are doing the same things. The M plus one query problem is the same thing that can happen there too. Opening up too many connections or too small connection pools. It's basically the same problems. But I guess depending on the problem that we have and if we know how to properly use the underlying, the backend database, whether it's NoSQL or SQL, then we can build the best system

or we can totally mess it up. And that's not only true for databases. That's true for everything where we use subsystems. If you're not using them properly, then we might end up in a mess and in huge performance problems. Brian? Yeah, I was going to say I wanted to go back to something Sonja touched on before. But before I do, it almost sounds like the developer or the DBA developer relationship is almost like a parent and child relationship. You know, the

developed, the DBA being the parent and the developers kind of like the children and children run around, have fun and everything. And then the DBA is left cleaning everything up and, you know, not to pick on the DBAs, but, you know, we kind of joke about them being kind of grumpy and this and that, but I think a lot of it is because they're continually cleaning up the mess left by the developers. So I think as developers become more aware and more cognizant of what they're doing and improve their tactics, we might start seeing a lot more smiling DBAs, which would be really awesome.

I did want to come back to you. Sonia, you were talking before about the prepare statements and the bind variables. And just to get into the tool a little bit um you know can you kind of go over what the relationship is between the bind variables the prepare statements and what kind of metrics we'd be seeing maybe in the normal database views and some of the new agent views with the time spent kind of components, what to look out for, for an opt, you know, a really good running one or ones that are running poorly. What does that look like? Okay. So, so far, so we have, we have different, so we have

now the database agents for Oracle and SQL server. And of course those two words are a little bit different. So the metrics are different one for Oracle, if you look at the Oracle Health dashboard, you will see this time spent breakdown, which is one of my favorite graphs for Oracle because it shows you, okay, for the whole time that the database engine is working, where are you spending time? So obviously, you see executing SQL statement show up,

you see executing stored procedure show up, you see executing stored procedures show up, but you might also see connections showing up. So if you see that you're spending a significant amount of time onto the connection, that would indicate that you have some kind of problem with your connection pool, maybe having too many connections open at the same time. And the one for the band variables is called parsing. So as we were explaining before, we need the database engine needs some time to parse, to create the execution plan.

So you will start seeing that parsing time on the graph. And if you see on your graph parsing time showing up, that's a sign that you have statements that are not optimized. You could look at the CPU usage, because what's really nice is we have this database agent which is remote, so it doesn't need to be installed on the database. It's really collect the data remotely, but still retrieve from the database information about CPU usage.

And you will see a high CPU usage, maybe 80, maybe 90%, and that's quite high for database. So if you see those and the parsing showing up on the time spent breakdown for Oracle and high CPU usage, you should then look at your instrumented applications and the queries, the SQL queries that we have captured there. High parsing would probably mean you're not using many bind variables,

correct? Yeah. So it means there's an application sending some bad calls without bind variables to your database and in a high amount of time. So that's really something that you should improve. And for SQL, it will be the compilation,

number of compilation per second. So in SQL Server world, the parsing is called compilation, which makes really sense because it's like you get a statement and the database kind of needs to compile it into an execution plan. So in SQL world, you will need to compare the batch request per second, that's the number of queries that you are getting to your database with the number of compilation per seconds. And one of the things that experts tend to agree to is that you should have less than 10% of your queries that requires compilation.

So let's say if you have 100 batch requests per second, you should have less than 10 compilation per second. And I think you also covered this nicely in your blog post, right? I think you mentioned it. Yeah, exactly. We'll put the links to that on the page, definitely. And I only wanted to clarify that a little because Andy and I talk about the N plus one query issue quite a lot. But based on some of your blog posts and listening to some other things, it sounds like that there are some other, maybe not as common as the N plus one, but some other very popular database problems as well.

And this kind of seemed like one of them. I know in the last slide you had today at the webinar, you had a list of best practices, tips, anything that you want to mention here that strikes out? We talked about a lot of things here. encourage people to care for is, especially when we have databases with changing data, keep your table statistics up to date, because the table statistics are mainly relevant for choosing the proper index. And especially in tables where data distribution changes that could end up in the optimizer choosing the wrong index and making a statement maybe faster. Another thing is I heard a couple of times that people said, I have created indexes on all my columns and, yeah, maybe selects are fast, but the updates are so slow or inserts. Yes, definitely.

They have to be slow. Because the more indexes you have, the faster your selects might be, but the slower changing statements are, because not only the table has to be changed, but also the index has to be updated or built. So this is typically why we had, we are not talking about them that much as in previous years, you remember data warehouses. So a data warehouse was a separate database that was optimized for read access. So indexes on every single column, data already joined into destination tables where we could read tables without doing specific joints there.

So really read optimized databases versus write optimized databases for the front end. Another thing is, and that's another cool thing that we see now with the database agent when we use the live view, a lot of times we saw that slow transactions are caused by locks in the database. So a background job is running somewhere and building up whatever billings in invoice tables and doing updates there and locking these tables and whenever a process that was using that table from the front end wanted to do an update there and had to wait for a lock this sometime caused the transaction to time out because the lock was not released in time And this is a cool thing now that we also enable that for developers or operators

when they check slow transactions that they see with the live view what other sessions might log my table or what other slow queries I might have in my database from different applications maybe that are not even monitored directly by APM. But taking up my resources, my CPU, my IOM and making, again, the whole database. Yeah, because we are running on shared systems basically, right? That's what it is. I want to know what's going on.

Back to the example that Sonia gave before. So when we have our application, for instance, optimized on using bind variables, and we have whatever test application using the same database not using bind variables, okay, on the

one hand, that application is slow, but on the other hand, it consumes also our CPU and we don't have data cache available because the SQL cache for that statement consumes all the memory. And that is something that developers kind of forget, the whole view, the whole database view, because there's just application sending my queries, my application is slow, it's the database but not looking at what's really happening

and for the DBA it's really also kind of difficult because they just have their own view on the database, they know it's the uptime, they know it's working or it's not working, they have some stats but they never know what is actually the impact on the user so they never know when does it

make sense to make some changes on their side. They just try to put the best resource, you know, CPU, make storage quicker, but they cannot really help on the end user performance. Cool. Well, Brian, I guess we picked the right people when we tried to find people talking about database performance issues, huh? Yeah, we sure did. It's funny, last night I was just finally

finishing season one of Silicon Valley, and this whole conversation makes me just think kind of how unsexy database is, you know, especially like towards the end of that season when they were at the TechCrunch meeting and the guy was getting all turned on by the Java code that was written. You know, that's the sexy part for developers, writing the really sexy routines and all that.

But I think developers really need to start getting into that database view for performance testers, you know, leveling up and being aware of some of this. This way, if they see an issue that they're pointing back to, the queries at least, they can have that conversation with the database folk and say, hey, have you looked at this area or what are you looking at in your database? It's something I think people need to become more aware of, as is kind of every aspect of the computing chain, right? It's a never-ending expansion of knowledge that's needed. Some of it is not as flashy

or sexy as others, but it's definitely hugely, hugely important. And I think Harold and Sonja did a great job explaining it all, and I think we have some great tools in Dynatrace itself to help with this as well. Yeah, and I want to do a shout-out to every listener. So the free trial version of Dynatrace actually comes with the database agent as well.

So you can monitor your Java, your.NET, your PHP, Node.js apps, and we give the database agent for right now Oracle SQL Server. And by the time this episode airs, we probably already have the 6.5 version available for the free trial users, which means it includes MySQL as well. So that's pretty cool. That is cool. Go online, Dynatrace, AppMont, free trial, a personal license. I think we can get the short link up there as well and give it a try

and just become more aware of how your application deals with the database. Yeah, and become aware that the database is not necessarily slow, even though we hear that a lot. Yeah, that's true. It might be only slow because of the way it works. You make it slow. And then, as you said, Brian, this is not just for databases. It's for all type of subsystems.

When they appear slow, maybe they're only slow because of the way we're using them. Exactly. Cool. Well, I would say this was awesome, wasn't it? I thought so. I thought it was an exciting episode. See, I predicted it. Yeah.

So any final words? Not final, final, like it's not the end of the day, but the end of the world. But any final remarks? We talked about blogs. Watch out for my blog. By the time this goes on air, it's probably already released about when ORM becomes your performance killer. Oh, nice.

Oh, cool. Cool. This will be airing around August 30th. So if you have any other webinars or appearances or any other appearances, and we'll make sure we put the links to the blogs up on the page. But do you all have any other webinars or appearances occurring after the August 30th? I don't know yet. It's too far out. It is. I would also like to say, hey, anyone listening, if you have any fun database stories that you've been through, we'd love to have you as a guest on the show to talk about them

or any other performance-related issues you'd like to talk about. You can just contact us either on Twitter. I almost forgot the name of that site, Twitter. You can post it to hashtag pureperformance at Dynatrace or you can email us at pureperformance at dynatrace.com. We'd love to have guests. Andy or Sonia, or can I call you Harry now? I just heard you called for the first time today.

All right, well, Harry, anything else from you all? The only thing that I really want to do is a shout out on use the latest version of Dynatrace 6.5. Why? Because we also now automatically detect several database problem patterns automatically, like the M plus 1 query problem will automatically be detected. Long running sequels, too much time in sequels. So these are automatically now detected in the new feature that we have. So some of the steps to automate it to that way you had to manually click through are not automated which makes it even easier so do we still need you

because the nickname for that feature is andy in a box right maybe that actually allows me to go on vacation at some point in time yeah nice no keep keep standing in these pure. So that means the symbol for that feature, the icon for that feature in the application is a lederhosen then? Yeah. Or a beer? You know that box when you turn something

and then the clown turns up? There could be something with you and then jumping up and a few lederhosen. Andy, you're a clown. I just realized that. At least. Andy, you're a clown. I just realized that at least. Well,

anyway. Thank you for having us. Thank you. If you have any topics in the future

to talk about, let us know. It's always good. It's always a

great channel. And, yeah. Thanks to all our listeners. Thank you. We'll see

you all next time. Bye-bye. Bye.