我想在我的Azure SQL数据库中自动化一些数据库扩展。
这可以通过以下方式轻松启动:
ALTER DATABASE [myDatabase]
MODIFY (EDITION ='Standard', SERVICE_OBJECTIVE = 'S3', MAXSIZE = 250 GB);
但该命令会立即返回,而调整大小需要10秒才能完成。
我们可以使用以下方法检查实际的当前大小,在更改之前不会更新
是
完成:
SELECT DATABASEPROPERTYEX('myDatabase', 'ServiceObjective')
所以我自然想把它和
WHILE
循环和a
WAITFOR DELAY
,以便创建一个将更改DB大小的存储过程,并且在更改完成之前不会返回。
但是,当我编写并运行该存储过程(下面的脚本)时,每次(大约在大小更改完成的同时)都会收到以下错误:
当前命令发生严重错误。如果有结果,应该丢弃。
调整大小
成功
,但我得到的是错误,而不是一个干净完成的存储过程调用。
我已经测试过的各种东西:
-
如果我将“Initiate”和“WaitLoop”部分分开,并在启动后但在完成之前在单独的连接中启动WaitLoop,那么也会出现相同的错误。
-
添加a
TRY...CATCH
块也没有帮助。
-
删除存储过程方面,直接运行代码也无法修复它
我的解释是,Resize并不像人们希望的那样透明,在调整大小完成之前创建的连接在某种意义上会被破坏。
无论确切的原因是什么,在我看来,这个存储过程根本无法实现;我必须从外部进程进行轮询——每次都打开新的连接。这不是
可怕的
解决方案,但它
是
不如将整个东西封装在一个存储过程中愉快。啊,这就是生活。
问题:
在我放弃之前
完全
…是否有人对此错误有其他解释或解决方案,从而允许单个存储过程调用更改大小,然后在sizeChange实际完成之前不返回?
初始存储过程代码(简化以消除参数化的复杂性):
CREATE PROCEDURE [trusted].[sp_ResizeAzureDbToS3AndWaitForCompletion]
AS
ALTER DATABASE [myDatabase]
MODIFY (EDITION ='Standard', SERVICE_OBJECTIVE = 'S3', MAXSIZE = 250 GB);
WHILE ((SELECT DATABASEPROPERTYEX('myDatabase', 'ServiceObjective')) != 'S3')
BEGIN
WAITFOR DELAY '00:00:05'
END
RETURN 0
