Excellent! One of the best teaching videos: structured, well organized, clear. Sir, work on more topics and I can assure you as an instructor you would be one of the best!
whats the latency of moving databases out of latency pool or increasing service tier of it. How to deal with noisy neighbour problem and how to mitigate the risk of kicking out the noisy neighbour from the pool without disruption or latency ?
Increasing a service tier can vary depending on if the current underlying VM has the resources to allocate to your instance, or if it needs to be moved to a different instance. However the downtime is minimal as some of this work involved with potentially moving to a new VM happens in the background while your current instance continues to run, and then we will do, in essence a DNS change, at the end. Moving databases into a new elastic pool is a relatively seamless experience. Within elastic pools, your can limit the amount a vCores that a database can consume from that pool helping to put guardrails around noisy neighbors.
Understood. That’s why it’s important to set up good monitoring and alerting procedures so you can identify things like that and take appropriate action!
Excellent! One of the best teaching videos: structured, well organized, clear. Sir, work on more topics and I can assure you as an instructor you would be one of the best!
Thank you sir. I appreciate that! More content coming soon!!!
Briliant explanation. A million thanks
Glad it was helpful!
Best and easiest way to explain the Elastic Pool.
Glad it helped!
Very well explained
Glad it was helpful!
Great video.
Thank you!!
Excellent video
Thank you!!
great explanation
Glad it was helpful!
whats the latency of moving databases out of latency pool or increasing service tier of it. How to deal with noisy neighbour problem and how to mitigate the risk of kicking out the noisy neighbour from the pool without disruption or latency ?
Increasing a service tier can vary depending on if the current underlying VM has the resources to allocate to your instance, or if it needs to be moved to a different instance. However the downtime is minimal as some of this work involved with potentially moving to a new VM happens in the background while your current instance continues to run, and then we will do, in essence a DNS change, at the end. Moving databases into a new elastic pool is a relatively seamless experience. Within elastic pools, your can limit the amount a vCores that a database can consume from that pool helping to put guardrails around noisy neighbors.
@@DataBar my main concern is kicking out the noisy neighbour from the elastic pool to a dedicated azure SQL instance
Understood. That’s why it’s important to set up good monitoring and alerting procedures so you can identify things like that and take appropriate action!