I'll do you one better. I'll explain required downtime like you're 3.
You know how you have to take a nap every day? Even when you're not tired? Mommy always insists on the nap. And most days, after you get up from your nap, the house is cleaner and dinner is under way? That's because those are things Mommy can't do when you're up and in the way, either because they would be too dangerous for you (handling bleach), or because she wouldn't be able to pay attention you while doing them (ex: mowing the lawn).
So, when you take a nap, mommy gets to do things she can't do when you're in the way.
Required downtime is like forcing a toddler to nap. You get to do things you wouldn't be able to do otherwise, or that would be too risky. It can be painful to arrange (getting all the stakeholders to agree), but usually, there's a very good reason. The system can focus its attention on only one thing (your upgrade), avoid risky conflicts (access to shared resources), take shortcuts and lock whole resources (ex: databases or database tables, instead of row-level locking), etc. By reserving some resources for exclusive use, you can avoid complexe (slow) locking mechanisms.
You can also have required downtime when you know the performance of the system will be affected to such a high level that it wont be usable.
So, when you encountered required downtime, I just take the hint and go for a nap :-)
I'll do you one better. I'll explain required downtime like you're 3.
You know how you have to take a nap every day? Even when you're not tired? Mommy always insists on the nap. And most days, after you get up from your nap, the house is cleaner and dinner is under way? That's because those are things Mommy can't do when you're up and in the way, either because they would be too dangerous for you (handling bleach), or because she wouldn't be able to pay attention you while doing them (ex: mowing the lawn).
So, when you take a nap, mommy gets to do things she can't do when you're in the way.
Required downtime is like forcing a toddler to nap. You get to do things you wouldn't be able to do otherwise, or that would be too risky. It can be painful to arrange (getting all the stakeholders to agree), but usually, there's a very good reason. The system can focus its attention on only one thing (your upgrade), avoid risky conflicts (access to shared resources), take shortcuts and lock whole resources (ex: databases or database tables, instead of row-level locking), etc. By reserving some resources for exclusive use, you can avoid complexe (slow) locking mechanisms.
You can also have required downtime when you know the performance of the system will be affected to such a high level that it wont be usable.
So, when you encountered required downtime, I just take the hint and go for a nap :-)
Incredible, thank you for this.
Came here looking for the explanation of a nap. Very good!