Allow DWU to scale without interruption
The scaling disrupts the current session, and it's often not allowable in the production. Instead, it should finish off the existing session (sqls), and scale after that. That way, the scaling up or down can be done without causing the production disruption.
Thank you for voting for this feature! We are aware of this scenario and are looking into ways of supporting this. In the meantime, stay tuned for an update and please continue voting for this feature.
Please do asap!
Nathan Land commented
To further add to this it would be good if the scaling happened in the background i.e. the currently running sqls run at the lower or higher DWU's and are not interrupted at all. But once the scaling has finished all newly executed sql's will run at the new scale.
Reason is if in the above scenario the warehouse waits then scales what happens to requests while scaling. It would be great is scaling was transparent and happened in the background without the need to manage it outside the environment.
Azure DBA commented
Have submitted a few SRs due to "hung" scaling operations. Occassionally the scale doesn't proceed but allows the database to remain functional, and other times end up with an extended outage.
Frank C commented
I'm not sure if it's helpful (or if it muddies the waters), but I've found the pause/resume workaround to be helpful even without changes in scaling.
Chris Aiken commented
Often, after scaling, my database refuse to return results from large tables. This is after scaling from DWU100 to DWU 1000 (i.e. going UP in size). The fix I have found is to pause the database, wait 15-30 minutes, then resume the database. I assume this results in the database being reassigned to a new DW cluster.
Overall, I have found scaling to be a tenuous affair -- sometimes it works, sometimes it fails or leaves my database in a state where it basically no longer responds.
Hopefully this is a preview "feature" that will be fixed....