Perform scale operation before copying to a new tenant ring
We have hit an issue occasionaly where a 10GB database on S0 has a scale request to S3 takes over 3 hours to complete. This is an operation that is performed daily and normally finishes in less than 15minutes.
With the database at S0, it is unusable and our customer was unable to use their database for 2 hours (normal level is S3).
Talking with support, it seems the database was in the process of being moved to a new tenant ring due to the current tenant ring not having enough space to complete the scale up operation.
It would be great if the tenant ring always left enough room to perform the scale operation, and then queue up the move to a new tenant ring due to the lack of space.
Apparently the reason it was so slow to move was because the database was only being given the S0 resources to move.