Poor Database Performance Post-Migration

[MUSIC PLAYING] [WHISTLING] I think the big things are configuration mismatches. So differences in settings between the old and the new systems that can lead to suboptimal performance. Indexing issues. They're not properly built or rebuilt or optimized in the new environment, and that's going to affect the queries. The actual SQL statements. And there's a number of different things that really need to be looked at. The hardware differences, the software differences, the network latency and even things like the schema changes. All of these things can start to show their effects in a negative way. The last few things are the query optimization and the resource allocation. So queries may need to be reoptimized as they reach their new destination. Sometimes they even need to be refactored. And the new environment will oftentimes lead to a new execution plan for that query. So it all needs to be observable. And then the resource allocation, as we talked about just a few moments ago-- How much time-- --leading to expense. How much time you would you give that a period for tuning in? It's iterative. It depends, but it's certainly iterative. And I would say that for any single SQL statement, it could be hours and sometimes even days in terms of troubleshooting. If it's-- let's just say it's a performance issue, Mike, and you have-- you're trying to fight a fire, then it usually is minutes and sometimes hours in terms of the resolution. Yeah. Because your system can only be down so much. And obviously there are ways that organizations keep their systems highly available. On the flip side of that is the pre-production environment. How much tuning is involved in a rapid pace continuous delivery towards production? And that could be days, sometimes even weeks. And with good optimization, let's say that your SQL statement took you several days to build. Just think how many days it's going to take you to optimize that query. So it's just that-- Could be three or four-fold. I'm just thinking about the overall time frame of the migration. Should we build in like a 20% period of time post migration, 20% of the entire project. You should be looking at tuning over time, as in like there could have five or six statements. All these different levers we have for tuning, and we should give ourselves that much time for it to stabilize and resolve these configuration misconfigurations, additional memory, indexing, schema, execution plan analysis. And like I feel like it should have-- it shouldn't just be one week. It feels like it should be a prolonged period of time. Yeah, I think the way I would look at it is that perhaps knowing that it is iterative, knowing that that behavior should remain continuous. If you have this sort of ethos around code quality, then perhaps it's budgeted into the project. Or perhaps it's baked in somewhere. I'm trying to use a more simplified term to say that. It's really, it's just built in. So for example, if you have this culture, right, as you move through your system development life cycle for optimization, then you're going to start to make some budget for this in terms of time. As far as you move into a new environment. The way I understand your question is, yes, certainly you should plan for there to be some period of time where there's going to be some optimizations that take place. So, because when I think of it as like a child. And I know this is a very loose analogy, but that growing up that needs to take place and there's a lot of settling down that needs to happen when an application arrives in its new environment. Certainly it's data. There's a lot of growing pains. Yeah. To take your analogy. A lot of growing pains and then the queries. What you find are the it's the noisy aspects of the business. The noisy users in the business, and the real noisy data starts to rear its head in those-- in that initial phase. And with monitoring, you're allowing yourself to observe all of that and then allow for that iterative process that takes place. Because only when you get into real world production environment workloads, when you start to see the complexity and the so-called disturbance in the force when it comes to performance, right? But it's really challenging because development teams oftentimes don't have all the tools, skills, or even the time to perform all the simulations that are necessary.