数据库安全警示录1之drop user and drop tablespace规范

       对于删除用户和表空间这种极度危险的操作，必须按照规范的流程来操作。以免小失误造成大故障这就不合适了。

一、确保该用户没有会话连接到数据库

select count(*) from v$session where username=''; 

二、LOCK USER;READ ONLY TALBESPACE 

ALTER USER username ACCOUNT LOCK；
ALTER TABLESPACE tablespacename READ ONLY;

设为read only而不是直接offline的好处：
1、read only 会等当前表空间所有事物commit或者rollback以后才能成功，进一步确定该表空间上没有事物，确保数据完整性,read write的时候不需要recover;而offline会直接成功，offline之后commit的事物会在online表空间的时候做recover。
2、表空间在read only 之后的rman备份，会备份且只备份一次read only的表空间，而offline的表空间在rman备份的时候不会备份。极大缩短误操作的恢复时间。

三、offline tablespace after the read only tablespace has been backuped

ALTER TABLESPACE tablespacename offline；

select USERNAME, ACCOUNT_STATUS, DEFAULT_TABLESPACE,'ALTER TABLESPACE '||DEFAULT_TABLESPACE||' OFFLINE;'
  from dba_users
 where account_status = 'LOCKED'
   AND DEFAULT_TABLESPACE != 'USERS';

通常在offline表空间后并不马上删除，由于目前管理的业务系统的特殊性，在同一数据库的其他schema（每个schema对应一个应用系统）可能需要读取对该tablespace中的某些表的数据。等待一星期，带无任何异常。

四、drop user and drop tablespace

DROP USER username CASCADE;

select USERNAME, ACCOUNT_STATUS, 'DROP USER ' || USERNAME || ' CASCADE;'
  from dba_users
 where ACCOUNT_STATUS = 'LOCKED';

DROP TABLESPACE tablespacename INCLUDING CONTENTS AND DATAFILES;

SELECT TABLESPACE_NAME,STATUS,'DROP TABLESPACE ' || TABLESPACE_NAME ||' INCLUDING CONTENTS AND DATAFILES;'
  FROM DBA_TABLESPACES
 WHERE STATUS = 'OFFLINE';  

目前我管理的DB,每个应用系统在DB里都是单独的SCHEMA和TABLESPACE，故使用以上流程删除迁移系统数据后遗留在旧DB的TABLESPACE.