前言

这是发生在真实的模拟环境中，也意味着在实际的生产环境中存在这种问题的可能性。即在我们尝试标准的unprovisioning API去清除一个不用的Tenant (代表客户) Container资源(包括对应的数据库HDI-shared实例，以前对应的应用以及该应用所需要的其它资源）时，并不能完全清理掉。

如果我们检查BTP下对应于目标微服务的HANA实例列表，在删除失败的那个实例下边，会看到类似于下边的这种错误：

遇以这种情况，使用常规手段，基本上是不太可能清理掉的，并且目标Tenant在这之后，变得不可用。

解决方法：

我们可以尝试使用HANA Cloud中的一些权限临时授权，调用相关Container函数进行手动清除。

-- 先授予相应的权限
CREATE LOCAL TEMPORARY COLUMN TABLE #PRIVILEGES LIKE _SYS_DI.TT_API_PRIVILEGES;
INSERT INTO #PRIVILEGES (PRINCIPAL_NAME, PRIVILEGE_NAME, OBJECT_NAME) SELECT 'DBADMIN', PRIVILEGE_NAME, OBJECT_NAME FROM _SYS_DI.T_DEFAULT_CONTAINER_GROUP_ADMIN_PRIVILEGES;
CALL _SYS_DI.GRANT_CONTAINER_GROUP_API_PRIVILEGES('BROKER_CG', #PRIVILEGES, _SYS_DI.T_NO_PARAMETERS, ?, ?, ?); 
DROP TABLE #PRIVILEGES;

-- 然后用下边的脚本去删除对应的container
CREATE LOCAL TEMPORARY COLUMN TABLE #DROP_CONTAINER_PARAMETERS LIKE _SYS_DI.TT_PARAMETERS;
INSERT INTO #DROP_CONTAINER_PARAMETERS ( KEY, VALUE ) VALUES ( 'ignore_work', 'true' );
INSERT INTO #DROP_CONTAINER_PARAMETERS ( KEY, VALUE ) VALUES ( 'ignore_deployed', 'true' );
INSERT INTO #DROP_CONTAINER_PARAMETERS ( KEY, VALUE ) VALUES ( 'ignore_errors', 'true' );
CALL _SYS_DI#BROKER_CG.DROP_CONTAINER('<container id>', #DROP_CONTAINER_PARAMETERS, ?, ?, ?);
DROP TABLE #DROP_CONTAINER_PARAMETERS; 

上边的<container id>对应的就是无法删除的schema对象，专用于目标tenant。

关键的调用：

CALL _SYS_DI.GRANT_CONTAINER_GROUP_API_PRIVILEGES('BROKER_CG', #PRIVILEGES, _SYS_DI.T_NO_PARAMETERS, ?, ?, ?);

这一步就是要把'DBADMIN'授予_SYS_DI.T_DEFAULT_CONTAINER_GROUP_ADMIN_PRIVILEGES这个权限。因为普通的grant语句无法完成此任务。只能通过临时表添加记录的方式进行整体授权。

最关键的动作就是后来的：_SYS_DI#BROKER_CG.DROP_CONTAINER，它要求忽略三个错误警告，最后要吧彻底删除目标container。

小结：

HANA Cloud对各类用户的安全性要求极高，设定了非常多的角色和User Group。这在实际使用过程中，是需要十分注意的。dbadmin这个用户和HDI Admin是完全分离的。同时，它也不能直接访问Container (或叫目标schema)下的数据库对象。

后续我会花点时间整理出如何将目标Container对应的schema中的对象访问权限授予指定用户，步骤比较繁杂，使用起来也需要非常小心谨慎。