关于查看dba_data_files的一个小问题(r7笔记第72天)
关于查看dba_data_files的一个小问题(r7笔记第72天)
今天帮一个朋友看一个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比较有缘，总是有意无意会碰到。