不能直接给运维用户update或delete权限，因其可绕过his系统直接修改数据，引发诊疗错乱、收费异常、等保失败或医疗纠纷；运维应仅负责数据库稳定性，通过角色隔离、白名单授权、定期扫描高危权限及审批化脚本执行来保障权责分离。
为什么不能直接给运维用户 UPDATE 或 DELETE 权限
因为一旦授予 UPDATE、DELETE 等对象权限，该用户就能绕过业务系统（如HIS）直接改数据，轻则导致诊疗记录错乱、收费不一致，重则触发等保审计失败或医疗纠纷。医院Oracle 19C环境里，运维人员应只负责数据库层稳定性，不触碰业务逻辑数据——这是权责分离的硬边界。
用角色隔离 + 对象权限白名单控制访问范围
核心思路：不给运维用户直接授表权限，而是通过中间角色做“权限闸门”，且只开放明确需要的只读或管理类操作。
- 创建专用运维角色：
CREATE ROLE dba_maint_role; - 仅授予必要系统权限：
GRANT SELECT ANY TABLE, ALTER SYSTEM, ALTER DATABASE, FLASHBACK ANY TABLE TO dba_maint_role;（注意不含UPDATE ANY TABLE） - 对业务表显式禁止写入：不执行
GRANT UPDATE ON his.patients TO ...这类语句；若已有误授，立即用REVOKE UPDATE ON his.patients FROM dba_maint_role;撤回 - 业务表默认归属
HIS用户（schema），运维用户登录后查his.patients只能靠SELECT，且需提前被授予该权限——这点必须人工审批、逐表确认
检查谁有跨 schema 修改权限（防漏网之鱼）
运维账号若被意外授予 UPDATE ANY TABLE 或 DBA 角色，等于开了后门。必须定期扫描：
- 查高危系统权限：
SELECT GRANTEE, PRIVILEGE FROM DBA_SYS_PRIVS WHERE PRIVILEGE IN ('UPDATE ANY TABLE', 'DELETE ANY TABLE', 'INSERT ANY TABLE'); - 查是否拥有
DBA角色：SELECT GRANTEE FROM DBA_ROLE_PRIVS WHERE GRANTED_ROLE = 'DBA' AND GRANTEE NOT IN ('SYS', 'SYSTEM'); - 查跨 schema 的对象授权：
SELECT OWNER, TABLE_NAME, GRANTEE, PRIVILEGE FROM DBA_TAB_PRIVS WHERE PRIVILEGE IN ('UPDATE', 'DELETE', 'INSERT') AND OWNER NOT IN ('DBA_MAINT', 'PUBLIC');
这些结果必须人工复核，尤其注意外包DBA账号、历史遗留测试账号。
归档/收缩等大操作必须走脚本+审批流程，而非交互式SQL
像清理3亿行审计表、收缩表空间这类动作，本质是批量 DELETE 或 MOVE，但绝不能让运维在SQL*Plus里手敲 DELETE FROM audit_log WHERE ...。风险在于：没加WHERE条件、事务过大锁库、未开启归档日志保护。
- 所有此类操作封装为带校验的PL/SQL脚本，例如：
EXEC pkg_maint.purge_audit_by_month('2025-06');，内部自动加WHERE、分批提交、记录日志 - 脚本部署在专用维护schema（如
MAINT），运维用户仅被授予执行该包的EXECUTE权限，无权查看或修改包体 - 执行前必须触发审批流（如OA工单号写入注释），且脚本开头强制校验当前时间、归档模式、闪回状态
真正难的不是语法，而是把“能做什么”固化进角色、脚本和流程里——权限放开一秒钟，数据就可能不可逆地错乱。
