全库或者全schema导的话，全部导出

没法避免。不知道你是什么场景，为什么需要屏蔽掉编译错误

直接drop会比较好。因为truncate操作会删除表中的所有数据，但是表结构、索引、触发器、权限等仍然保留，这个过程可能会比较耗时。而drop操作则是直接删除表及其依赖的所有对象，包括数据、索引、触

1，新建一个表，内容跟之前的一样，然后drop掉原来的表，再把新建的表给重命名；导出导入也可以2，shrink或者truncate可以试一下，不确定能不能释放空间和降低HWM

表块中即使有数据，也有可能会在FREELIST上；而索引块必须为全空才能放在FREELIST上，即使索引块里面还剩下一个索引条目，不管这个块内有多少未用空间，这个块都不会当成空闲块放在FREELIST

1、regexplike(name,’[ABC]’)相当于（like‘%A%’orlike‘%B%’orlike‘%C%’）;2、测试SQL>selectfromt1;NAMEABCDSQL&g

创建对象时会在该用户的默认永久表空间中创建一个临时段你是可以查到的，这个阶段归档量会增大要注意空间问题。

shareplex，这个场景再适合不过了

建议遵循这两点：1.独立的业务库务必分开cdb，这样谁坏都不影响谁2.关联性强的库，要坏了就都不可用的库可放在一个cdb。

生产中没有太大的表，变大后都拆分，挪历史库了单表太大不好维护