oracle数据表分区，truncate或drop后会导致索引失效，除了重建索引有没有更好的快速解决方法？

Posted 2023-04-11

有一个办法，就是在每个分区建立同样的索引，而不是建全局索引，这样，当把分区truncate或者drop的时候，只是把那个分区的索引也给删掉了，而不影响其他分区 参考技术A 加update indexes可以让索引不失效
alter table tableName truncate partition partitionName update indexes

drop没试过，不知道可不可以 参考技术B 重建索引很麻烦吗？追问

不能每一个月都重建一次，这样很影响到现场作业的

追答

你前面提到truncate或drop后会导致索引失效， 每个月能truncate或drop一次表分区，重建一次索引问题也不太大吧。
前面那位提到的分区表分别建索引的办法，可以一试。

12c RMAN 表级恢复

Oracle数据库备份主要分为逻辑和物理备份。各有优缺点。在之前的版本中，

利用物理备份来恢复表和分区是不行的。只能用逻辑恢复。这种情况在12c中得到了改变，

可以在truncate或drop表的情况下从RMAN备份将表或分区恢复到某个时间点或SCN和log sequence.

 

以下情况不能恢复

1)Tables and table partitions belonging to SYS schema cannot be recovered.
2)Tables and table partitions from SYSTEM and SYSAUX tablespaces cannot be recovered.
3)Single table partitions can be recovered only if your Oracle Database version is Oracle Database 11g Release 1 or later.
4)Tables and table partitions on standby databases cannot be recovered.Tables with named NOT NULL constraints cannot be recovered with the REMAP option.

恢复的条件：

1)The target database must be in read-write mode.
2)The target database must be in ARCHIVELOG mode.
3)You must have RMAN backups of the tables or table partitions as they existed at the point in time to which you want recover these objects.
4)To recover single table partitions, the COMPATIBLE initialization parameter for target database must be set to 11.1.0 or higher

 

官方文档：

http://docs.oracle.com/database/121/BRADV/rcmresind.htm#BRADV686

 

实战：

1.创建表

SQL> conn lei/[email protected]
SQL> create tablespace zhixintbs datafile ‘/u01/oracle/oradata/zhixin/zhixintbs.dbf‘ size 500m autoextend on;
Tablespace created.
SQL> create table test_c tablespace zhixintbs as select * from dba_objects;
Table created.
SQL> select count(*) from test_c;
  COUNT(*)
----------
     90940

 

2.备份数据库

 恢复前提是要有有效的备份，必须执行一次全备。为了恢复PDB中的表，你需要CDB的undo，SYSTEM,SYSAUX表空间的备份

和PDB的SYSTEM,SYSAUX的备份。

 如果在表空间tbs1里表的索引或分区包含在表空间TBS2，只有tbs2表空间也恢复集中，你才可以

这个表。为了恢复表，这个表所有依赖的对象必须在恢复集中。。

 

 RMAN可以恢复多个表/分区，而且不影响以及存在的对象。你可以恢复到备份之后的任意时间点。

RMAN恢复表/分区适合下面情况：

 

1).You need to recover a very small number of tables to a particular point in time. In this situation, 
TSPITR is not the most effective solution because it moves all the objects in the tablespace to a specified point in time.
2).You need to recover tables that have been logically corrupted or have been dropped and purged.
3).Flashback Table is not possible because the desired point-in-time is older than available undo.
4).You want to recover data that is lost after a DDL operation modified the structure of tables. 
Using Flashback Table is not possible because a DDL was run on the tables between the desired point in time and the current time. 
Flashback Table cannot rewind tables through structural changes such as a truncate table operation.

--恢复流程：

1)确定要恢复的表/分区所需的备份集

2)在恢复表/分区的过程中，一个辅助数据库会临时设置为某个时间点

3)利用数据泵将所需表/分区导出到一个dumpfile

4)你可以从原数据库导入表/分区(可选)

5)在恢复过程中进行重命名操作(可选)

--备份数据库

[[email protected] ~]# su - oracle
[[email protected] ~]$ rman target /
Recovery Manager: Release 12.1.0.2.0 - Production on Thu Sep 8 01:58:11 2016
Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.
connected to target database: ZXKJ (DBID=1929263251)
RMAN>backup database;
Starting backup at 2016:09:08 19:58:16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=261 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
······略
channel ORA_DISK_1: finished piece 1 at 2016:09:08 19:59:14
piece handle=/u01/oracle/fast_recovery_area/ZXKJ_S/3A3486B9DE751C7CE053B501A8C094BC/backupset/2016_09_08/o1_mf_nnndf_TAG20160908T015817_cx0ocd0b_.bkp tag=TAG20160908T015817 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:07
Finished backup at 2016:09:08 19:59:15
Starting Control File and SPFILE Autobackup at 2016:09:08 19:59:15
piece handle=/u01/oracle/fast_recovery_area/ZXKJ_S/autobackup/2016_09_08/o1_mf_s_921981555_cx0ocnbz_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 2016:09:08 19:59:16

 

3.查看drop之前的scn

SQL> select current_scn from v$database;
CURRENT_SCN
-----------
    5810317

4.drop掉表

 

SQL> conn lei/[email protected]        
Connected.
SQL> drop table test_c;
Table dropped.
SQL> select count(*) from test_c;
select count(*) from test_c
                     *
ERROR at line 1:
ORA-00942: table or view does not exist

5.尝试恢复

恢复一定要指定AUXILIARY DESTINATION和TIME,SCN,SEQUENCE中一个

AUXILIARY DESTINATION：RMAN在恢复过程中用到的一个辅助数据库

RMAN target /
target database Password: 
connected to target database: ZXKJ (DBID=1929263251)

 

这里遇到个奇葩的问题就是指定时间点还原的时候报错,找了半天也没发现哪边有问题。

run{
RECOVER TABLE lei.test_c
UNTIL TIME "to_char(‘20160908 18:29:13‘,‘yyyymmdd hh24:mi:ss‘)"
AUXILIARY DESTINATION ‘/u01/oracle‘;
}
Starting recover at 2016:09:0819:05:35
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 09/08/2016 20:00:35
ORA-00907: missing right parenthesis

只能这样了,一小时之前。或者用SCN

run{
RECOVER TABLE lei.test_c
UNTIL TIME ‘sysdate - 1/24‘
AUXILIARY DESTINATION ‘/tmp/oracle/recover‘;
}

5.1创建恢复目录

[[email protected] ZXKJ_P]# mkdir /home/oracle/recover
[[email protected] ZXKJ_P]# chown oracle:oinstall /home/oracle/recover

5.2恢复表

run{
RECOVER TABLE lei.test_c of pluggable database zhixin
UNTIL SCN 5810317
AUXILIARY DESTINATION ‘/home/oracle/recover‘
datapump destination ‘/home/oracle/recover‘;
}
Starting recover at 2016:09:0820:06:16
using channel ORA_DISK_1
RMAN-05026: WARNING: presuming following set of tablespaces applies to specified Point-in-Time
List of tablespaces expected to have UNDO segments
Tablespace SYSTEM
Tablespace UNDOTBS1
Creating automatic instance, with SID=‘sfdv‘
initialization parameters used for automatic instance:
db_name=ZXKJ
db_unique_name=sfdv_pitr_zhixin_ZXKJ
compatible=12.1.0.2.0
db_block_size=8192
db_files=200
diagnostic_dest=/u01/oracle
_system_trig_enabled=FALSE
sga_target=1504M
processes=200
db_create_file_dest=/u01/oracle
log_archive_dest_1=‘location=/u01/oracle‘
enable_pluggable_database=true
_clone_one_pdb_recovery=true
#No auxiliary parameter file used
.......
auxiliary instance file /home/oracle/recover/ZXKJ_P/datafile/o1_mf_sysaux_cx36k1xq_.dbf deleted
auxiliary instance file /home/oracle/recover/ZXKJ_P/datafile/o1_mf_undotbs1_cx36k1yc_.dbf deleted
auxiliary instance file /home/oracle/recover/ZXKJ_P/datafile/o1_mf_system_cx36k1yb_.dbf deleted
auxiliary instance file /home/oracle/recover/ZXKJ_P/controlfile/o1_mf_cx36jw5r_.ctl deleted
auxiliary instance file tspitr_dhEo_52195.dmp deleted
Finished recover at 2016:09:0901:07:

恢复完成

 

 在这个过程中，会新建一个auxiliary  instance,然后在auxiliary instance上做全库恢复，再通过datapump工具导出和导入，整个过程和TSPITR很相似.

 

5.3 验证数据

SQL> select count(*) from test_c;
  COUNT(*)
----------
     90940

表又回来了。

 

转：http://www.cndba.cn/Expect-le/article/250