今天帮一个朋友看一个pl/sql的问题，他已经钻到一个死胡同里列，可能明眼人一看就知道哪里有问题，但是当局者迷，所以我抽空看了一下这个pl/sql块。
pl/sql的内容大体如下：
declare
TYPE new_type IS TABLE OF VARCHAR2(30) ;
v_tab new_type:=new_type('DBIMISHLS','ICU','INFOCAST','INFOCAST_V2','MSG','NMS','TS_CONFIG','TS_DOC','TS_PATIENT','TS_WARD');
position varchar2(1000);
v_sql_user varchar2(4000);
v_sql_tablespace varchar2(4000);
v_res_tablespace varchar2(4000);
v_res_user varchar2(4000);
begin
select substr(file_name,1,29) into position from  dba_data_files where rownum=1;
for i in 1..v_tab.count loop
    v_sql_tablespace:='create tablespace '||v_tab(i)||' datafile '||''''||position||v_tab(i)||'01.dbf'||''''||' size 1G autoextend on;'；
---EXECUTE immediate v_sql_tablespace into v_res_tablespace;
    dbms_output.put_line(v_sql_tablespace)；
    end loop;
end;
当然简单调试了一下就可以了，看起来语法就没有任何问题了。其实是几个结束符的问题。
当然语句的问题改好了。为了保险起见，我得测试一下，刚好手头没有测试环境了，生产环境不能尝试，所以就在备库中进行了测试，发现是一台11gR2的备库。
运行的时候结果提示dba_data_files不存在
SQL> desc dba_data_files
ERROR:
ORA-04043: object dba_data_files does not exist
这个时候才意识到备库是在mount阶段。
然后把备库启动到open阶段，自动开启了read only with apply，这个时候运行那个Pl/sql还是有问题，这就奇怪了。
看报错是指到dba_data_files了，手工desc了一下，发现确实访问不了，这个时候就有些奇怪了。怎么会访问不了了，难道是备库有问题。
这个数据字典的信息不存在那就严重了。
SQL> desc dba_data_files
ERROR:
ORA-04043: object dba_data_files does not exist
这个测试做得我有点心虚，赶紧找了另外几套环境做比对，都没有问题。所以我初步怀疑，可能是碰到一个bug了。
当然有了基本的思路之后，查看mos，马上就锁定一篇文章
ORA-4043 On DBA_* Views If They Are Described In Mount Stage (Doc ID 296235.1)
确实有这么一个bug,2365821
如果在数据库mount阶段尝试使用desc访问dba_相关的数据字典，在open阶段就会抛出上面的错误信息。
当然解决方法也很简单，一个就是flush shared pool,另外一个就是重启。
当然在备库我还是愿意在线修复。
SQL> Alter system flush shared_pool;
System altered.
SQL> desc dba_data_files
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 FILE_NAME                                          VARCHAR2(513)
 FILE_ID                                            NUMBER
 TABLESPACE_NAME                                    VARCHAR2(30)
 BYTES                                              NUMBER
 BLOCKS                                             NUMBER
 STATUS                                             VARCHAR2(9)
 RELATIVE_FNO                                       NUMBER
 AUTOEXTENSIBLE                                     VARCHAR2(3)
 MAXBYTES                                           NUMBER
 MAXBLOCKS                                          NUMBER
 INCREMENT_BY                                       NUMBER
 USER_BYTES                                         NUMBER
 USER_BLOCKS                                        NUMBER
 ONLINE_STATUS                                      VARCHAR2(7)
所以这个问题的分析就告一段落。所以这些细节真是很折磨人，最近和bug比较有缘，总是有意无意会碰到。