如何在脱机模式下载新的Oracle Cloud Control 12c的Agent软件

从OEM 12c开始,agent无法直接通过互联网可以下载,而需要在Self Update (自行更新)下载。但通常在生产环境中部署的OEM,出于安全考虑是没法直接连接互联网的。那么问题就来了,如果OEM是安装在Linux平台下,那么即只有对应平台的Agent软件。如果想要监管AIX或者HP-UNIX平台呢?本文就是为了解决此问题,如何在脱机模式中仍然使用self-update和补丁管理特性。

其他版本的下载可参考:http://www.oracle.com/technetwork/oem/grid-control/downloads/agentsoft-090381.html

1、首先,在OEM中通过“Setup(设置)”>“Extensibility(可扩展性)”>“ Self Update (自行更新)”。进入“ Self Update (自行更新)”配置页,查看“Connection Mode(连接模式)”的显示结果,必须是设置为”Offline”模式。

如下图:

OEM2

OEM1

2、返回“Self Update(自行更新)”配置页,点击“ Check Updates(检查更新)”,此时弹出“ Check updates in offline mode(在脱机模式中检查更新)”提示框,根据提示框,到可与Internet连接的主机上,先下载更新目录:

OEM3

比如:https://updates.oracle.com/Orion/Download/download_patch/p9348486_112000_Generic.zip

根据Use the following link to download the latest updates catalog 提供的网址,下载相应的文件后上传至OEM主机。

3、我们将使用emcli工具来导入catalog,emcli工具本身就已经安装在Manager Cloud Control server中的。如果没法正常使用,可以采用以下方式来安装emcli工具:

  1. 下载和安装最新的Java 1.6.x
  2. 下载emclikit.jar https://emcc_host:emcc_port/em/faces/core-emcli-emcliDownload
  3. 安装:java -jar emcliadvancedkit.jar -install_dir=<em_cli_home_dir>
  4. 配置:/u01/app/oracle/emcli/emcli setup -url=https://192.168.56.241:7802/em/ -username=SYSMAN

使用以下命令,登陆emcli并导入catalog:

4、再次检查“ Self Update (自行更新)”配置页:

EMCC01

此时可以看到,虽然仍然是在Offline模式下,但是已更新catalog内容,可以看到Agent Software有50个Available Updates。

5、点击”Agent Software “,进入agnet列表,选择所需的agent,然后点击”Download”:

EMCC02

然后使用emcli导入agent软件:

6、再次检查“ Self Update (自行更新)”配置页,可以看到新的agent已经下载完毕: EMCC03 点击”Apply”使之可以给部署使用。此时会有一个后台作业呗创建,在几秒之后,可以看到状态被改变为”applied”。EMCC04

此时我们就可以开始部署此平台。
参考文档:

http://docs.oracle.com/cd/E24628_01/install.121/e22624/install_agent.htm#EMBSC292

记一次控制文件恢复异常处理

在一次需要采用RMAN恢复一个新建的测试库时,发现控制文件无法正常恢复,特此记录本次处理过程如下。

环境介绍:
Source DB: 2-Node Oracle Database 11g R2 RAC On AIX (11.2.0.4 with ASM)
Target DB: Single Instance Database 11g R2 On AIX (11.2.0.4 with ASM)

问题描述:

使用RMAN恢复控制文件的时候,产生以上报错。

解决思路:
1、ASM磁盘组权限问题,Oracle用户未加asmadmin权限

2、确定ASM磁盘已经被挂载

3、如果是ASM磁盘组权限问题,需重启主机

上述确认无误后,重启主机

控制文件恢复成功

12c New Feature:Temporary Undo

背景:

本文是学习12c新特性的笔记,主要来源于官方文档和OU教材汇总而成。

什么是临时undo?

Temporary Undo是12c的新特性,如下图所示:

Temporary Undo verview

临时表广泛的被用作于为暂存中间结果分配区域,这是因为改变哪些表是比用非临时表快很多的。性能提升主要是因为实际上修改临时表没有redo条目直接产生。然而,在临时表(和索引)上操作的undo任然记录到redo log。临时表的undo,在该临时对象的其生命期的一致性读和事务回滚是有用的。超出此范围的undo是多余的。因此它在redo流中不需要持续。举例来说,事务恢复只是丢弃临时对象的undo。

从12c开始,可以通过把临时表的事务产生的undo,直接在临时表空间中存储独立undo流,来避免在redo流中记录undo。

注意:临时undo segment是会话私有的。它存储属于相应会话的临时表改变的undo

默认情况下,undo记录临时表是存储在undo表空间中,且记录到redo中,这是与undo管理永久表相同的方式。然而,你可以使用TEMP_UNDO_ENABLED初始化参数来从永久表的undo分离临时表的undo。当此参数设置为TRUE,临时表的undo调用temporary undo。
Continue reading 12c New Feature:Temporary Undo

AIX上的配置网络调优参数

验证网络调优参数设置如下表所示的值或者更高值:

Network Tuning Parameter Recommended Value
ipqmaxlen 512
rfc1323 1
sb_max 4194304
tcp_recvspace 65536
tcp_sendspace 65536
udp_recvspace 655360
备注:
推荐此参数值10倍于udp_sendspace参数。但此参数值必须小于sb_max参数值。
udp_sendspace 65536
备注:此值适用于默认数据库安装。对于生产库,此参数最小值:(DB_BLOCK_SIZE * DB_FILE_MULTIBLOCK_READ_COUNT) + 4 KB

查看这些参数的当前值,如果有必要则修改:
1、检查网络调优参数的当前值,使用以下命令:

2、如果你需要改变参数的值,然后输入以下命令来确定系统是否运行在兼容模式:

如果系统运行在兼容模式,那么输出类似于以下,表明pre520tune属性值已开启。
3、如果系统运行在兼容模式,然后按照以下步骤修改参数值:
使用以下类似命令来修改每个参数值:

例如:

上述步骤需要修改的每个参数,添加类似如下条目到/etc/rc.net文件:

添加这些行到/etc/rc.net文件,值需要系统重启生效。
4、如果系统未运行在兼容模式,那么输入类似以下命令来改变参数值:
ipqmaxlen 参数

其他参数

注意:如果修改ipqmaxlen 参数,那么你必须重启系统。
这些命令修改/etc/tunables/nextboot文件,在系统重启后属性值持续有效。

5、如果需要修改参数,而为重启系统。在修改非全局设置后,那么使用ifconfig命令来检查每块网卡属性:
例如:

对于ISNO参数tcp_sendspace,使用以下命令来设置:

 

Data Guard–物理主备库切换

近期因为工作的需要,研究了一些DG的东西,以下是:
Performing a Switchover to a Physical Standby Database的操作步骤
主要是参考官方文档和网上一些资料,整理而成。

1、减少实例

在切换之前必须把数据库减少为一个实例,即RAC的话,只留一个节点。
shutdown immediate
或(紧急时在辅助实例执行)
shutdown abort

2、首先在主库确认没有日志缺口:

SQL> select STATUS, GAP_STATUS from V$ARCHIVE_DEST_STATUS where DEST_ID = 2;
应该返回 VALID 和 NO GAP。
删除 LOG_ARCHIVE_DEST_N 参数中的所有延迟应用(delay)重做日志设置,你要确认所有变化都在备库应用,才能确保无数据丢失。
确认所有重做日志都已在备库应用,查询备库:
SQL> select NAME, VALUE, DATUM_TIME from V$DATAGUARD_STATS;
不应该返回 transport lag 或 apply lag, finish time 应该为0.

3、检查先决条件

检查完这些先决条件后,确认主库可以进行角色切换,查询主库:
SQL> select SWITCHOVER_STATUS from V$DATABASE;
如果返回 TO STANDBY 或 SESSIONS ACTIVE,那么主库就可以进行切换。
切换主库为备库命令为:
alter database commit to switchover to physical standby with session shutdown;
shutdown immediate
startup mount

4、备库切换为主库

查询备库是否可以切换为主库
select SWITCHOVER_STATUS from V$DATABASE;
如果返回 TO PRIMARY 或 SESSIONS ACTIVE,就可以切换。
如果返回 SWITCHOVER LATENT 或 SWITCHOVER PENDING,就要去检查告警日志,看有什么问题,一般是需要应用一些日志。
如果是需要应用日志的话,在备库执行如下命令:
recover standby database using backup controlfile;
在应用日志前应该是 SWITCHOVER PENDING 状态,完成应用后,会变成 TO PRIMARY 或 SESSIONS ACTIVE状态。
切换备库为主库:
alter database commit to switchover to  primary with session shutdown;
打开新主库:
alter database open;

5、在原主库(现备库)启用日志应用

如果其他物理备库被停止,也需要启用日志应用
alter database recover managed standby databse using current logfile disconnect from session;

RAC环境下SYSDATE返回错误时间

某客户反馈说,在11.2.0.3的RAC下,使用sqlplus连接时查询sysdate返回的时间是正确的,但是使用PL/SQL等通过Listener方式连接的时候,则返回错误的时间。

其实造成这个问题的原因是11.2.0.2后的新特性:

11.2.0.1的时候TZ变量取决于grid和root用户的shell环境变量TZ。

但是从11.2.0.2开始,Oracle的集群(GI)开始拥有自己的时区和配置,即TZ参数存在$GRID_HOME/crs/install/s_crsconfig_<nodename>_env.txt中设置的time zone。

一般集群的时区是在安装GI时从系统获取的。经过沟通后,客户确实在前段时间更改过系统时区,至此造成的sysdate返回错误的原因就是因为当操作系统的时区发生改变时,但是GI的时区未改变。解决方:修改TZ值,重启节点。

具体修改可以参考MOS:How To Change Timezone for 11gR2 Grid Infrastructure (Doc ID 1209444.1)

RAC安装节点2执行root.sh报CRS-5005和CRS-2632错

在某客户处,AIX 6.1上安装11.2.0.3的RAC,在节点2执行root.sh时出现以下报错:

初期由于分配IP存在不确定因素,一致以为是IP导致,但是实际不是。

从正常的安装来说,OCR盘在节点1执行时已经创建成功,节点2只需要应用即可。从此思路推断,是存储问题导致安装失败。

验证节点1和节点2存储是否划盘一致:

节点1:

节点2:

果然两个节点的存储划盘是不一致的,至此问题已经很清楚,是由于存储划盘不一致导致节点2执行root.sh报CRS-5005和CRS-2632错。

行链接和行迁移

众所周知造成Oracle数据库性能低下的原因有很多,但是行链接和行迁移也很可能是其中原因之一。

 什么是行链接和行迁移?

1)该行太大,在它第一次插入时,无法放入一个数据块。

在行链接中,Oracle数据库将数据存储在为段保留的一个或多个被链接的数据块中。行链接最经常出现在大行中。例如包括包含LONG或LONG RAW数据类型列的行,或在2KB块中的VARCHAR2(4000)列,或具有大量列的行。在这些情况下出现链接行是不可避免的。

2)原先的行本来可以放入到一个数据块的,但是在更新后整体行长增加了,又没有足够可用空间来容纳更新的行。

在行迁移中,假设行可以容纳在一个新块中,Oracle数据库将会把整个行移动到一个新的数据块。原来的被迁移走的行块会包含一个指针或“转发地址”指向迁移到新块中的行。已迁移行的rowid不会改变。

3)超过255个列的行。

Oracle数据库在一个块行中只可以存储255的列。因此,如果你在具有1000个列的表中插入行,则数据库将创建4个快行,通常会链接多个块。

那么到底什么是行链接和行迁移呢?

行链接

如下图描述:向数据块中插入大行,行出入左边的块太大,所以数据库通过将第一个行块(row piece)放在左边的块,而将第二个行块(row piece)放入到右边的块中,这样就形成了行链接。

cncpt316

 

行迁移

如下图所示:左边的块包含的行被更新,但现在导致该行太大而不能放入块中。数据库将整个行移动到右边的块中,并在左边的块中保留一个指向被迁移行的指针。

cncpt306

根据上述概念总结:行链接一般发生在insert阶段(因数据块无法容纳过大数据);行迁移一般发生在update阶段(原数据块无法容纳增长的数据)

当行被链接或迁移时,检索数据所需的I/O灰增加。导致这种情况是因为Oracle数据库必须扫描更多块以检索行信息。例如,如果数据库执行一个I/O读取索引或者读取一个未迁移的表行,则需要额外的I/O才能获取迁移的数据行。

参考文档:
Chained and Migrated Rows
http://docs.oracle.com/cd/E11882_01/server.112/e40540/logical.htm#CNCPT1055

 

AWR 故障

无法获取AWR


造成无法获取AWR的原因,可能是未开启收集有关系。
确定是否开启
查询AWR当前配置信息
col SNAP_INTERVAL for a20
col RETENTION for a20
select * from dba_hist_wr_control;
      DBID SNAP_INTERVAL        RETENTION            TOPNSQL
———- ——————– ——————– ———-
2197530720 +00000 01:00:00.0    +00008 00:00:00.0    DEFAULT

检查是否启动基线
SQL> show parameter statistics_level
如果 STATISTICS_LEVEL=TYPICAL  或 ALL,则默认启用基线。

AWR开头显示:

WARNING: Since the DB Time is less than one second, there was minimal foreground activity in the snapshot period. Some of the percentage values will be invalid.
alter system set control_management_pack_access=”DIAGNOSTIC+TUNING” scope=both;
SQL> show parameter control_management_pack_access
NAME                                 TYPE        VALUE
———————————— ———– ——————————
control_management_pack_access       string      NONE
SQL> alter system set control_management_pack_access=”DIAGNOSTIC+TUNING” scope=both;
System altered.
SQL> show parameter control_management_pack_access
NAME                                 TYPE        VALUE
———————————— ———– ——————————
control_management_pack_access       string      DIAGNOSTIC+TUNING
由于默认是每小时才生产一份AWR数据,所以等待一个小时或更长时间后在看看。

在分析数据库性能的时候,突然发现awr不完整,
重新生成AWR,发现如下错误:
ERROR:
ORA-06502: PL/SQL: numeric or value error: character string buffer too small
ORA-06512: at “SYS.DBMS_WORKLOAD_REPOSITORY”, line 919
ORA-06512: at line 1
–数据库版本
SQL> SELECT * FROM V$VERSION;

BANNER
——————————————————————————
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production
PL/SQL Release 11.2.0.3.0 – Production
CORE    11.2.0.3.0      Production
TNS for IBM/AIX RISC System/6000: Version 11.2.0.3.0 – Production
NLSRTL Version 11.2.0.3.0 – Production

–设置errorstack
alter session set events ‘6502 trace name errorstack level 12’;
—获取trace name
oradebug setmypid
oradebug tracefile_name
分析错误:
—– Error Stack Dump —–
ORA-06502: PL/SQL: numeric or value error: character string buffer too small
—– Current SQL Statement for this session (sql_id=572fbaj0fdw2b) —–
select output from table(dbms_workload_repository.awr_report_html( :dbid,
                                                            :inst_num,
                                                            :bid, :eid,
                                                            :rpt_options ))
—– PL/SQL Stack —–
—– PL/SQL Call Stack —–
  object      line  object
  handle    number  name
7000011f4948398       919  package body SYS.DBMS_WORKLOAD_REPOSITORY
700001222708fd0         1  anonymous block
—– Call Stack Trace —–
calling              call     entry                argument values in hex
location             type     point                (? means dubious value)
——————– ——– ——————– —————————-
skdstdst()+40        bl       107c66680            FFFFFFFFFFF0320 ? 000000001 ?
                                                   00000000C ? 000000000 ?
                                                   000000000 ? 000000001 ?
                                                   00000000C ? 000000000 ?
ksedst1()+112        call     skdstdst()           FFFFFFFFFFF03F8 ? 000002004 ?
                                                   110A5E8C0 ? 10A6D12F4 ?
                                                   10A6D0848 ? FFFFFFFFFFF0720 ?
                                                   FFFFFFFFFFF0500 ? 110A5E8C0 ?
ksedst()+40          call     ksedst1()            10A6D12E8 ? 7000000000282 ?
                                                   10A6D12BC ? B000000000000 ?
                                                   10A6D0848 ? 000000000 ?
                                                   E800000000 ? 1974B073CFBD6 ?
dbkedDefDump()+1516  call     ksedst()             000000000 ? 000000000 ?
                                                   000000000 ? 000000000 ?
                                                   000000003 ? 00000FA50 ?
                                                   000000000 ? 000000000 ?
ksedmp()+72          call     dbkedDefDump()       C06471240 ? 000000000 ?
                                                   10ABE01D8 ? 110D5AC08 ?
                                                   10ABE01D8 ? 110A5E8C0 ?
……
这是11.2.0.3上的bug,已经在12.1和11.2.0.3.3上修复
Bug 13527323 : AWR REPORT GENERATION COULD FAIL WITH ORA-6502 WITH MULTIBYTE CHARS IN SQL TEXT
Bug 13527323 – ORA-6502 generating HTML AWR report using awrrpt.sql in Multibyte characterset database (文档 ID 13527323.8)
解决方法:
1、(未验证)
update WRH$_SQLTEXT set sql_text = SUBSTR(sql_text, 1, 1000);
commit;
2、(推荐)升级到11.2.0.3.3以上版本

Oracle中的回收站(Recycle Bin)

什么是Recycle Bin
回收站(Recycle Bin)实际上是包含删除对象信息的数据字典表。删除表和其他相关对象,比如索引、约束和嵌套表,实际上没有被真的删除,还是继续占用空间。直到被从回收站中purged出去,才能从数据库释放相关的表空间的空间。
每个用户可以拥有自己的回收站,当然除非用户拥有SYSDBA权限,否则默认都只可以访问用户所属的回收站。
可以通过下列语句,查看在回收站中自己的对象:
select * from recyclebin;
特别需要注意的是:在sys下drop的表是不记录recyclebin的。

 

闪回删除和回收站的关系
recyclebin1
使用Flashback Table命令,可以在无需使用时间点恢复的情况下,还原drop table语句的结果。
由初始化参数REECYCLEBIN用于控制闪回删除功能是打开(on)还是关闭(off)。如果是off,则删除的表不会进入回收站。如果是on,则删除的表将进入回收站,并且可能可以恢复(取决于是否还被保留)。默认情况下,不管10g和11g中。RECYCLEBIN设置为ON。

 

recyclebin2
如果不启用回收站,则删除表时,与该表及其从属对象关联的空间会立即变为可回收。
如果启用了回收站,则删除表时,与该表及其从属对象管理的空间不会立即变为可回收。即使该空间确实显示在dba_free_space中。相反,会在回收站中引用删除的对象,这些对象仍属于其各自的所有者。在空间不紧张时,绝不会把回收站对象使用的快乐自动回收。从而可以尽可能长的期限内恢复回收站的对象。

 

回收站中对象的命名
将删除的表“移动”到回收站时,将使用系统生成的名称对该表机器关联对象和约束条件进行重命名。
这样做的好处是避免以下情况:
用户删除表后,又用相同的名重建,又再删除。
两个用户使用相同的表名,但又都删除这些表。
重命名惯例如下:BIN$unique_id$version。
其中unique_id是该对象的全局唯一标识符,包含26个字符,用于在所有数据库之间的唯一的标识回收站名称。
而version是数据库分配的版本号。

 

回收站:自动回收空间
recyclebin3
只要回收站对象使用的空间没有被回收,就可以使用闪回删除功能恢复这些对象。
下面是回收站对象的回收策略:
显式发出purge命令时执行手动清理
空间不足时执行自动清除:对象在回收站中时,DBA_FREE_SPACE也会报告其对应的空间,因为这些空间是可以自动回收的。然后按以下顺序使用特定表空间中的空闲空间:
1.与回收站对象不对应的空闲空间
2.与回收站对象对应的空闲空间。在这种情况下,将使用先进先出(FIFO)算法自动将回收站对象从回收站清理
3.自动分配的空闲空间。

 

回收站管理

启停回收站
停用回收站
ALTER SESSION SET recyclebin = OFF;
ALTER SYSTEM SET recyclebin = OFF SCOPE = SPFILE;
启用回收站
ALTER SESSION SET recyclebin = ON;
ALTER SYSTEM SET recyclebin = ON SCOPE = SPFILE;
注意:上述操作都需要重启数据库生效。

 

查看和查询回收站中的对象
试图 描述
USER_RECYCLEBIN 用户查看回收站中自身删除的对象,也可用通过同义词recyclebin查看。
DBA_RECYCLEBIN 管理员查看回收站中所有的删除对象。

 

查看回收站中中的对象
select original_name, object_name, ts_name, droptime from dba_recyclebin
SQL> show recyclebin  –不显示索引
ORIGINAL NAME    RECYCLEBIN NAME                OBJECT TYPE  DROP TIME
—————- —————————— ———— ——————-
PP               BIN$9dV9fqwIE+TgQwEAAH/i4w==$0 TABLE        2014-03-31:00:30:15
PP               BIN$9dV9fqwHE+TgQwEAAH/i4w==$0 TABLE        2014-03-31:00:16:25
PP               BIN$9dV9fqwGE+TgQwEAAH/i4w==$0 TABLE        2014-03-30:23:21:34
查询回收站中的对象,但是必须要用””指定正确回收站中的对象名
SQL> select * from “BIN$9dV9fqwGE+TgQwEAAH/i4w==$0”;

 

回收站:手动回收空间
使用PURGE命令可从回收站中永久地删除对象。从回收站中清除某个对象时,会从数据库中永久地删除该对象及其从属对象。因此,将无法再使用闪回删除功能恢复从回收站中清除的对象。
下面是可能使用的一些PURGE命令:
清除指定表和索引
PURGE {TABLE <table_name>|INDEX <index_name>}
示范:
purge table “BIN$9dV9fqwGE+TgQwEAAH/i4w==$0”;
purge table table_name;
purge index index_name;
清除驻留在指定表空间中的所有对象(也可能清楚从属、驻留在其它表空间中的对象)
PURGE TABLESPACE <ts_name> [USER <user_name>]
示范:
purge tablespace test;
purge tablespace test user z;
清除属于当前用户的所有对象或者清除所有对象(dba_recyclenbin,必须具有足够的系统权限或者sysdba权限)
PURGE [USER_|DBA_]RECYCLEBIN

 

不使用回收站
drop table <table_name> [purge];
表空间中的对象不会移到回收站中,且回收站中所属该表空间的对象也会被清理。
drop tablespace <ts_name> [including contents]
从数据库中永久地删除该用户及其拥有的所有对象。且回收站中所属的已删除用户的所有对象都将被清理。
drop user <user_name> [cascade]

 

从回收站回复表
使用flashback table…to before drop语句从回收站恢复对象。你可以指点回收站中的对象名,也可以指定原始表名。
rename to子句选项可以使恢复的时候重命名。
语法:
FLASHBACK TABLE <table_name> TO BEFORE DROP
[RENAME TO <new_name>];
示范:
在恢复前,先查询,所需要的信息
SQL> show recyclebin
ORIGINAL NAME    RECYCLEBIN NAME                OBJECT TYPE  DROP TIME
—————- —————————— ———— ——————-
PP               BIN$9dV9fqwIE+TgQwEAAH/i4w==$0 TABLE        2014-03-31:00:30:15
PP               BIN$9dV9fqwHE+TgQwEAAH/i4w==$0 TABLE        2014-03-31:00:16:25
PP               BIN$9dV9fqwGE+TgQwEAAH/i4w==$0 TABLE        2014-03-30:23:21:34
或者
SQL> select object_name, original_name, createtime from recyclebin;
OBJECT_NAME                    ORIGINAL_NAME                    CREATETIME
—————————— ——————————– ——————-
BIN$9dV9fqwHE+TgQwEAAH/i4w==$0 PP                               2014-03-31:00:16:19
BIN$9dV9fqwGE+TgQwEAAH/i4w==$0 PP                               2014-03-30:23:21:28
BIN$9dV9fqwIE+TgQwEAAH/i4w==$0 PP                               2014-03-31:00:30:13
使用如下命令恢复表:
flashback table pp to before drop rename to zzz;
SQL> select object_name, original_name, createtime from recyclebin; 

OBJECT_NAME                    ORIGINAL_NAME                    CREATETIME
—————————— ——————————– ——————-
BIN$9dV9fqwHE+TgQwEAAH/i4w==$0 PP                               2014-03-31:00:16:19
BIN$9dV9fqwGE+TgQwEAAH/i4w==$0 PP                               2014-03-30:23:21:28

我们可以看出,恢复的表是最后被删除的,但是这个表不是我们实际需要的,怎么办?
还可以使用回收站中的对象名:
flashback table “BIN$9dV9fqwGE+TgQwEAAH/i4w==$0” to before drop;

 

恢复依赖对象
注意:恢复删除的表时,恢复的索引、触发器和约束条件将保留各自的回收站名称。因此,建议在闪回删除表前查询回收站和DBA_CONSTRAINTS。
1、在闪回之前,必须要先查询好表的相关信息
SQL>  select object_name, original_name, createtime from recyclebin;
OBJECT_NAME                    ORIGINAL_NAME                    CREATETIME
—————————— ——————————– ——————-
BIN$9daqMpoEFoLgQwEAAH/mBQ==$0 IDX_PPP_02                       2014-03-31:00:45:01
BIN$9daqMpoFFoLgQwEAAH/mBQ==$0 IDX_PPP_01                       2014-03-31:00:45:14
BIN$9daqMpoGFoLgQwEAAH/mBQ==$0 PP                               2014-03-31:00:44:32
2、恢复表
SQL> flashback table pp to before drop;
3、查询在回收站中恢复表对应关联对象
SQL> select index_name from user_indexes where table_name=’PP’;
INDEX_NAME
——————————
BIN$9daqMpoFFoLgQwEAAH/mBQ==$0
BIN$9daqMpoEFoLgQwEAAH/mBQ==$0
4、重命名到正确的对象名
alter index “BIN$9daqMpoFFoLgQwEAAH/mBQ==$0” rename to IDX_PPP_01;
alter index “BIN$9daqMpoEFoLgQwEAAH/mBQ==$0” rename to IDX_PPP_02;