使用trace文件重建控制文件时的只读表空间处理

使用trace文件重建控制文件的时候会经常忽略其中只读表空间，这种方式重建后的只读表空间的其实在置成读写的时候会出现类似
ORA-01135: file 6 accessed for DML/query is offline
ORA-01111: name for data file 6 is unknown - rename to correct file
ORA-01110: data file 6: "/u01/app/Oracle/product/10.2.1/db_1/dbs/MISSING00006"
的错误，大体分类一下：
当存在read only表空间时，重建控制文件分两种情况：
1、重建controlfile的脚本中包含read only所对应的datafile，datafile不需要rename。
2、重建controlfile的脚本中不包含read only所对应的datafile；重建controlfile之后需要rename datafile到正确的位置。

测试环境：Oracle 10G database：PROD

演示：
1，查看表空间状态
注意此时oltp表空间是read only状态。
SYS@PROD>select tablespace_name,STATUS from dba_tablespaces;

TABLESPACE_NAME                STATUS
------------------------------ ---------
SYSTEM                         ONLINE
UNDOTBS                        ONLINE
SYSAUX                         ONLINE
TEMP01                         ONLINE
TEMP02                         ONLINE
USERS                          ONLINE
TOOLS                          ONLINE
OLTP                           READ ONLY
MSSM                           ONLINE
9 rows selected.

2，备份控制文件到trace
SYS@PROD>alter database backup controlfile to trace;
Database altered.

3，开始重建控制文件过程：（停库=>nomount状态=>执行trace重建脚本）
SYS@PROD>shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.

SYS@PROD>startup nomount;
ORACLE instance started.
Total System Global Area 314572800 bytes
Fixed Size                  1219184 bytes
Variable Size             100664720 bytes
Database Buffers          209715200 bytes
Redo Buffers                2973696 bytes

4，此处模拟删除唯一的控制文件
SYS@PROD>show parameter control_files
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
control_files                        string      /u01/app/oracle/oradata/PROD/d
                                                 isk1/control1.ctl

PROD@rhel1$ rm disk1/control1.ctl

5，执行trace脚本
1）如果打开备份产生的trace文件我们可以在后面看到控制文件的重建语句（仔细研究trace文件可以发现很多关于控制文件的重要信息）
产生的trace文件位于$ORACLE_BASE/admin/$ORACLE_SID/udump/目录下，如果不知道是哪个文件可以使用如下语句查找：

select
d.value||"/"||lower（rtrim（i.instance, chr（0）））||"_ora_"||p.spid||".trc" trace_file_name
from
（ select p.spid
    from sys.v$mystat m,sys.v$session s,sys.v$process p
    where m.statistic# = 1 and s.sid = m.sid and p.addr = s.paddr） p,
（ select t.instance from sys.v$thread t,sys.v$parameter v
    where v.name = "thread" and （v.value = 0 or t.thread# = to_number（v.value））） i,
（ select value from sys.v$parameter where name = "user_dump_dest"） d ;
返回：
TRACE_FILE_NAME
--------------------------------------------------------------------------------
/u01/app/oracle/admin/PROD/udump/prod_ora_13341.trc
或这使用下列方法获取pid
select a.spid from
v$process a,v$session b
where a.addr=b.paddr and b.username = "SYS";
返回：
SPID
------------
13341
2）找到trace文件中的这段：
===========================================================
CREATE CONTROLFILE REUSE DATABASE "PROD" NORESETLOGS ARCHIVELOG
    MAXLOGFILES 30
    MAXLOGMEMBERS 5
    MAXDATAFILES 100
    MAXINSTANCES 1
    MAXLOGHISTORY 292
LOGFILE
GROUP 1 （
    "/u01/app/oracle/oradata/PROD/disk1/redo01.log",
    "/u01/app/oracle/oradata/PROD/disk2/redo01_b.log"
） SIZE 100M,
GROUP 2 （
    "/u01/app/oracle/oradata/PROD/disk1/redo02.log",
    "/u01/app/oracle/oradata/PROD/disk2/redo02_b.log"
） SIZE 100M,
GROUP 3 （
    "/u01/app/oracle/oradata/PROD/disk1/redo03.log",
    "/u01/app/oracle/oradata/PROD/disk2/redo03_b.log"
） SIZE 100M
-- STANDBY LOGFILE
DATAFILE
"/u01/app/oracle/oradata/PROD/disk1/system01.dbf",
"/u01/app/oracle/oradata/PROD/disk1/undotbs01.dbf",
"/u01/app/oracle/oradata/PROD/disk1/sysaux01.dbf",
"/u01/app/oracle/oradata/PROD/disk1/users_01.dbf",
"/u01/app/oracle/oradata/PROD/disk1/tools_01.dbf",
"/u01/app/oracle/oradata/PROD/disk1/mssm_01.dbf"
CHARACTER SET US7ASCII；
===========================================================
==注意此时的trace文件中没有只读表空间的信息，如果在这个脚本的datafile后面加上oltp的正确位置名就没有rename的过程了。

3）保存成脚本恢复使用：
PROD@rhel1 /home/oracle$ vi con.sql

使用命令行手工建立Oracle 11gR2数据库安装Oracle数据库软件遭遇诡异的HotSpot Virtual Machine Error : 11报错相关资讯 trace

Oracle 使用TRACE进行SQL性能分析（09/23/2014 18:46:47）

本文评论查看全部评论（0）