指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00308: 无法打开归档日志
'D:\DIABLOORACLE\PRODUCT\10.2.0\DB_1\RDBMS\ARC01155_0800012331.001'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
ORA-00308: 无法打开归档日志
'D:\DIABLOORACLE\PRODUCT\10.2.0\DB_1\RDBMS\ARC01155_0800012331.001'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
SQL> select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
------------------------
47277859
ORA-02449:.由于唯一/主键被其他外键引用
可以1.禁用该约束
查找该约束: select * from user_constraints c where c.table_name='TABLE_NAME';
该条记录
alter table TABLE_NAME disable constraint CONSTRAINT_NAME CASCADE;
2.删除表的时候，级联删除约束
drop table dept cascade constraints;
一般选用归档模式下进行恢复:
SQL> RECOVER DATABASE UNTIL CANCEL;
完成介质恢复。
SQL> ALTER DATABASE OPEN RESETLOGS;
数据库已更改。
recover database until time '2013-07-04 14:17:01';
recover datafile 5; (更改 674013 (用于线程 1) 在序列 #6 中)
SQL> recover database until time '2011-07-11 06:01:02';
ORA-00283: 恢复会话因错误而取消
ORA-19907: 恢复时间或 SCN 不属于已恢复的原型
startup force mount;
SQL> recover database until change 47277859;
完成介质恢复。
SQL> alter database open resetlogs;
数据库已更改。
SQL> select group#,status from v$log;
GROUP# STATUS
---------- ----------------
1 CURRENT
2 UNUSED
3 UNUSED
SQL> select count(*) from v$archived_log;
COUNT(*)
----------
25
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
47285280
BBED工具 并不是个新东东
****************************************************************************************************************
oracle 数据库文件损坏无法启动
startup pfile=D:\DiabloOracle\product\10.2.0\db_1\database\INITdia.ORA;(*.undo_management='AUTO' 改为*.undo_management='manual')
D:\DIABLOORACLE\PRODUCT\10.2.0\DB_1\DATABASE\SPFILEDIA.ORA
ora-01033:oracle initialization or shutdown in progress 解决方法
今天使用Oracle遇到了这个问题ora-01033:oracle initialization or shutdown in progress，经过分析研究终于解决了，记下来。
首先：问题的产生原因，出现这个错误是因为我将\oracle\product\10.1.0\oradata\oral下的一个文件删除掉后出现的。
利用sql语句语句创建表空间时弄错了，就一时心急把创建的文件删除了。结果问题就出来了。sysdba可以登录，但是在使用中就出现“数据库未打开,仅允许在固定表/视图中查询”，而normal用户无法登录使用，出现ORA-01033: ORACLE initialization or shutdown in progress 的错误。
分析：这个错误的原因应该是Oracle在启动后，用户登录时是要将方案中原有配置信息装载进入，装载过程中配置中有文件未找到，所以就报出错误。
解决过程：
C:\Documents and Settings\DHai>sqlplus /nolog
SQL*Plus: Release 10.1.0.2.0 - Production on 星期一 9月 28 14:35:38 2009
Copyright (c) 1982, 2004, Oracle. All rights reserved.
SQL> connect sys/123 as sysdba;
已连接。
SQL> shutdown immediate
ORA-01109: 数据库未打开
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup mount;
ORACLE 例程已经启动。
Total System Global Area 171966464 bytes
Fixed Size 787988 bytes
Variable Size 145750508 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes
数据库装载完毕。
SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-01589: 要打开数据库则必须使用 RESETLOGS 或 NORESETLOGS 选项
SQL> alter database open resetlogs;
alter database open resetlogs
*
第 1 行出现错误:
ORA-01172: 线程 1 的恢复停止在块 105 (在文件 2 中)
ORA-01151: 如果需要, 请使用介质恢复以恢复块和还原备份
第 1 行出现错误:
ORA-01172: 线程 1 的恢复停止在块 105 (在文件 2 中)
ORA-01151: 如果需要, 请使用介质恢复以恢复块和还原备份
先查看2号文件是什么文件：
select file#,name from v$datafile where file#=2;
第 1 行出现错误:
ORA-01139: RESETLOGS 选项仅在不完全数据库恢复后有效
alter database flashback on
*
第 1 行出现错误:
ORA-38706: 无法启用 FLASHBACK DATABASE 事件记录。
ORA-38709: 尚未启用恢复区。
SQL> show parameter DB_RECOVERY_FILE_DEST
NAME TYPE VALUE
------------------------------------ ----------- --------------------db_recovery_file_dest string
db_recovery_file_dest_size big integer 0
SQL> show parameter retention
NAME TYPE VALUE
------------------------------------ ----------- -------------
db_flashback_retention_target integer 1440
undo_retention integer 900
SQL> alter system set db_recovery_file_dest_size=2g;
系统已更改。
SQL> alter system set db_recovery_file_dest='D:\DiabloOracle\product\10.2.0\flash_recovery_area';
系统已更改。
SQL> show parameter db_recovery_file_dest;
NAME TYPE VALUE
------------------------------------ ----------- --------------------db_recovery_file_dest string
D:\DiabloOracle\product\10.2.0\flash_recovery_area
db_recovery_file_dest_size big integer 2G
SQL> alter database flashback on;
数据库已更改。
SQL> alter database datafile 6 offline drop;
数据库已更改。
SQL> alter database open resetlogs;
数据库已更改。
SQL> alter database datafile 6 offline drop;
数据库已更改。
SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-01531: 例程已打开数据库
SQL>shutdown immediate
提示：数据库已经关闭
已经卸载数据库
ORACLE 例程已经关闭
SQL> startup mount;
ORACLE 例程已经启动。
Total System Global Area 171966464 bytes
Fixed Size 787988 bytes
Variable Size 145750508 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes
数据库装载完毕。
到此，问题解决了。
Oracle 数据库 undotbs01.dbf文件损坏修复
前一段时间解决了一个ORA-1122错误，正好本机的数据库环境由于Windows的自动重起，导致数据库无法打开，出现错误信息也是ORA-1122。
这次出现错误的表空间是UNDO表空间。
上一篇介绍了利用备份进行恢复的方法，这篇尝试重建UNDO表空间的方法。
UNDO表空间的ORA-1122错误解决（一）：http://yangtingkun.itpub.net/post/468/455691
UNDO表空间的ORA-1122错误解决（二）：http://yangtingkun.itpub.net/post/468/455743
上一篇文章中尝试使用隐含参数_offline_rollback_segments来打开数据库，这里还可以选择将UNDO表空间的数据文件直接删除，然后使用_corrupted_rollback_segments参数来打开数据库，整个过程于上一篇介绍的方法类似。
SQL> STARTUP MOUNT
ORACLE例程已经启动。
Total System Global Area 76619308 bytes
Fixed Size 454188 bytes
Variable Size 50331648 bytes
Database Buffers 25165824 bytes
Redo Buffers 667648 bytes
数据库装载完毕。
SQL> ALTER DATABASE OPEN;
ALTER DATABASE OPEN
*
ERROR位于第1行:
ORA-01122:数据库文件2验证失败
ORA-01110:数据文件2: 'D:\DIABLOORACLE\DATABASE\DIA\UNDOTBS01.DBF'
ORA-01200: 25600的实际文件大小小于26880块的正确大小
下面尝试使用_corrupted_rollback_segments打开数据库，使用_offline_rollback_segments参数时，Oracle还会尝试进行数据块的延迟清除，而对于_corrupted_rollback_segments来说，Oracle假设事务已经回滚，而不会进行其他的检查。一般UNDO表空间丢失或损害的时候可以尝试使用这个隐含参数：
D:\DIABLOORACLE\DATABASE\DIA\SYSTEM01.DBF
SQL> ALTER DATABASE DATAFILE 'D:\DIABLOORACLE\DATABASE\DIA\UNDOTBS01.DBF' OFFLINE DROP;
数据库已更改。
下面创建初始化参数PFILE：
SQL> SHUTDOWN IMMEDIATE
ORA-01109:数据库未打开
已经卸载数据库。
ORACLE例程已经关闭。
SQL> CREATE PFILE='D:\INITTEST.ORA' FROM SPFILE;
文件已创建。
手工添加下面的初始化参数：
*.undo_management='MANUAL'
_corrupted_rollback_segments=(_SYSSMU1$,_SYSSMU2$,_SYSSMU3$,_SYSSMU4$,_SYSSMU5$,_SYSSMU6$,_SYSSMU7$,_SYSSMU8$,_SYSSMU9$,_SYSSMU10$)
可以通过上一篇文章中给出的方法打开数据库查询DBA_ROLLBACK_SEGS视图来获取回滚段列表。
对于没有启动的数据库，可以通过linux操作系统命令strings从system表空间的数据文件中获取回滚段信息。
对于windows环境下的Oracle，可以将数据文件通过ftp，拷贝到linux系统中，然后执行strings命令：
strings system01.dbf | grep _SYSSMU
下面利用修改后的PFILE打开数据库：
SQL> STARTUP PFILE=D:\INITTEST.ORA
ORACLE例程已经启动。
Total System Global Area 76619308 bytes
Fixed Size 454188 bytes
Variable Size 50331648 bytes
Database Buffers 25165824 bytes
Redo Buffers 667648 bytes
数据库装载完毕。
数据库已经打开。
下面的处理方法就和上一篇文章中介绍的比较类似了，先删除回滚段，然后删除回滚表空间，然后建立新的UNDO表空间：
SQL> SELECT SEGMENT_NAME, OWNER, TABLESPACE_NAME, STATUS
2 FROM DBA_ROLLBACK_SEGS;
SEGMENT_NAME OWNER TABLESPACE_NAME STATUS
--------------- ------ -------------------- ----------------
SYSTEM SYS SYSTEM ONLINE
_SYSSMU1$ PUBLIC UNDOTBS1 NEEDS RECOVERY
_SYSSMU2$ PUBLIC UNDOTBS1 NEEDS RECOVERY
_SYSSMU3$ PUBLIC UNDOTBS1 NEEDS RECOVERY
_SYSSMU4$ PUBLIC UNDOTBS1 NEEDS RECOVERY
_SYSSMU5$ PUBLIC UNDOTBS1 NEEDS RECOVERY
_SYSSMU6$ PUBLIC UNDOTBS1 NEEDS RECOVERY
_SYSSMU7$ PUBLIC UNDOTBS1 NEEDS RECOVERY
_SYSSMU8$ PUBLIC UNDOTBS1 NEEDS RECOVERY
_SYSSMU9$ PUBLIC UNDOTBS1 NEEDS RECOVERY
_SYSSMU10$ PUBLIC UNDOTBS1 NEEDS RECOVERY
已选择11行。
SQL> DROP ROLLBACK SEGMENT "_SYSSMU1$";
回退段已删除。
SQL> DROP ROLLBACK SEGMENT "_SYSSMU2$";
回退段已删除。
SQL> DROP ROLLBACK SEGMENT "_SYSSMU3$";
回退段已删除。
SQL> DROP ROLLBACK SEGMENT "_SYSSMU4$";
回退段已删除。
SQL> DROP ROLLBACK SEGMENT "_SYSSMU5$";
回退段已删除。
SQL> DROP ROLLBACK SEGMENT "_SYSSMU6$";
回退段已删除。
SQL> DROP ROLLBACK SEGMENT "_SYSSMU7$";
回退段已删除。
SQL> DROP ROLLBACK SEGMENT "_SYSSMU8$";
回退段已删除。
SQL> DROP ROLLBACK SEGMENT "_SYSSMU9$";
回退段已删除。
SQL> DROP ROLLBACK SEGMENT "_SYSSMU10$";
回退段已删除。
SQL> DROP TABLESPACE UNDOTBS1 INCLUDING CONTENTS AND DATAFILES;
表空间已丢弃。
SQL> CREATE TABLESPACE UNDOTBS1 DATAFILE 'D:\DIABLOORACLE\DATABASE\DIA\UNDOTBS1.DBF' SIZE 200M;
表空间已创建。
SQL> SELECT COUNT(*) FROM YANGTK.T;
COUNT(*)
----------
1273614
SQL> SHUTDOWN IMMEDIATE
数据库已经关闭。
已经卸载数据库。
ORACLE例程已经关闭。
SQL> STARTUP
ORACLE例程已经启动。
Total System Global Area 76619308 bytes
Fixed Size 454188 bytes
Variable Size 50331648 bytes
Database Buffers 25165824 bytes
Redo Buffers 667648 bytes
数据库装载完毕。
数据库已经打开。
和上一篇文章中的方法一样，Oracle将需要回滚的数据当作已经提交的数据，为了避免随后出现不可预测的问题，在重起数据库去掉隐藏参数后，应该导出数据，并建立新库，将源数据导入。
1.redo.log损坏，或者UNDO 表空间损坏，数据库肯定会DOWN.
2:创建pifle,修改pfile undo_management=manual
3:startup pfile='....'
4:open以后，create spfile from pfile
5:修改undo_management=auto
6:重启
解决思路：将UNDO_MANAGEMENT修改为manul，下次启动数据库时，则系统使用的是system表空间的回滚段（rollback segment）。
1、 ---undo表空间出错的情况，将该表空间名字修改为一个错误的名字。则下次启动使用spfile时，会因为无法找到该表空间而报错。
----SQL> alter system set undo_tablespace=undotbs11 scope=spfile;
System altered.
2、重启数据库实例，果然出现了错误
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 285212672 bytes
Fixed Size 1218992 bytes
Variable Size 121636432 bytes
Database Buffers 159383552 bytes
Redo Buffers 2973696 bytes
Database mounted.
ORA-01092: ORACLE instance terminated. Disconnection forced
3、这种情况下，由于数据库无法变成open状态，因此是无法打开spfile的，我们只能通过pfile来打开数据库。
3.1、新建pfile
SQL> create pfile from spfile;
File created.
3.2、编辑pfile，我们将undo_management的值由AUTO修改为manual。
[oracle@localhost dbs]$ cd $ORACLE_HOME/dbs
[oracle@localhost dbs]$ vi initorcl.ora
*.undo_management='AUTO' à *.undo_management='manual'
4、下面，我们采用pfile来启动数据库：
SQL> shutdown immediate
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux Error: 2: No such file or directory
#######################################
运行以下报ORA-01589:
startup pfile=/opt/ora10g/product/10.2.0/db_1/dbs/initorcl.ora
#############################
SQL> shutdown immediate;
ORA-01109: database未打开
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup
ORACLE 例程已经启动。
Total System Global Area 135338868 bytes
Fixed Size 453492 bytes
Variable Size 109051904 bytes
Database Buffers 25165824 bytes
Redo Buffers 667648 bytes
数据库装载完毕。
ORA-01589: 要打开数据库则必须使用 RESETLOGS 或 NORESETLOGS 选项
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR 位于第 1 行:
ORA-01113: 文件 1 需要介质恢复
ORA-01110: 数据文件 1: 'D:/ORACLE/ORADATA/ORCL/SYSTEM01.DBF'
SQL> recover database using backup controlfile;
ORA-00279: 更改 1254931418 (在 06/09/2011 01:12:51 生成) 对于线程 1 是必需的
ORA-00289: 建议: D:/ORACLE/ORA92/RDBMS/ARC00001.001
ORA-00280: 更改 1254931418 对于线程 1 是按序列 # 1 进行的
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
d:/oracle/oradata/eygle/redo01.log
ORA-00308: 无法打开存档日志 'd:/oracle/oradata/eygle/redo01.log'
ORA-27041: 无法打开文件
OSD-04002: Ξ???？？?
O/S-Error: (OS 3) ？？？????？???？?????
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
d:/oracle/oradata/orcl/redo01.log
ORA-00339: 归档日志未包含任何重做
ORA-00334: 归档日志: 'D:/ORACLE/ORADATA/ORCL/REDO01.LOG'
SQL> recover database using backup controlfile;
ORA-00279: 更改 1254931418 (在 06/09/2011 01:12:51 生成) 对于线程 1 是必需的
ORA-00289: 建议: D:/ORACLE/ORA92/RDBMS/ARC00001.001
ORA-00280: 更改 1254931418 对于线程 1 是按序列 # 1 进行的
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
d:/oracle/oradata/orcl/redo02.log
ORA-00339: 归档日志未包含任何重做
ORA-00334: 归档日志: 'D:/ORACLE/ORADATA/ORCL/REDO02.LOG'
SQL> recover database using backup controlfile;
ORA-00279: 更改 1254931418 (在 06/09/2011 01:12:51 生成) 对于线程 1 是必需的
ORA-00289: 建议: D:/ORACLE/ORA92/RDBMS/ARC00001.001
ORA-00280: 更改 1254931418 对于线程 1 是按序列 # 1 进行的
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
d:/oracle/oradata/orcl/redo03.log
已应用的日志。
完成介质恢复。
SQL> alter database open resetlogs;
数据库已更改。
#######################################
SQL> startup pfile=/opt/ora10g/product/10.2.0/db_1/dbs/initorcl.ora
ORACLE instance started.
Total System Global Area 285212672 bytes
Fixed Size 1218992 bytes
Variable Size 121636432 bytes
Database Buffers 159383552 bytes
Redo Buffers 2973696 bytes
Database mounted.
Database opened.
SQL>
5、现在数据库实例打开了，我们再创建spfile，让数据库下次启动时，自动读取spfile。
SQL> show parameter spfile
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
spfile string
SQL> create spfile from pfile;
File created.
SQL> startup force
ORACLE instance started.
Total System Global Area 285212672 bytes
Fixed Size 1218992 bytes
Variable Size 121636432 bytes
Database Buffers 159383552 bytes
Redo Buffers 2973696 bytes
Database mounted.
Database opened.
SQL> show parameter spfile
NAME TYPE VALUE
-------------- --------------------- --------------------------------------------------------------
spfile string /opt/ora10g/product/10.2.0/db_1/dbs/spfileorcl.ora
6、现在我们再将相应的参数修改回去，系统表空间的资源是有限的，我们最好不要使用回滚段。(修改系统表空间)
SQL> show parameter undo
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_management string MANUAL
undo_retention integer 900
undo_tablespace string UNDOTBS11
SQL> alter system set undo_management=auto scope=spfile;
System altered.
SQL> alter system set undo_tablespace=UNDOTBS1 scope=spfile;
System altered.
删除数据文件:
归档模式下用，
ALTER DATABASE DATAFILE '/u02/oracle/rbdb1/stuff01.dbf' OFFLINE;
alter database datafile 'file_name' offline 和 offline drop 没有什么区别。 因为offline 之后多需要进行recover 才可以online。
非归档模式下用，
SQL> alter database datafile 'D:\DIABLOORACLE\DATABASE\DIA\UNDOTBS1.DBF' offline
for drop;
数据库已更改。
SQL> alter database datafile 1 offline for drop;
数据库已更改。
SQL> startup force
ORACLE instance started.
Total System Global Area 285212672 bytes
Fixed Size 1218992 bytes
Variable Size 125830736 bytes
Database Buffers 155189248 bytes
Redo Buffers 2973696 bytes
Database mounted.
Database opened.
SQL> show parameter undo
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_management string AUTO
undo_retention integer 900
undo_tablespace string UNDOTBS1
非归档模式下恢复利用offline drop命令误删除的数据文件 ----------------------------
非归档模式下，联机日志并不归档。可能大多数的网友一直以来都会有这样的模糊认识。数据库作recover时，只能利用归档日志和current redo log联机日志。实际上所有的联机日志都是可以用的。此文介绍在非档模式下,恢复利用offline drop命令误删除的数据文件。offline drop命令相当于把一个数据文件至于离线状态，并且需要恢复或再也不使用此数据文件了。所在，在OS级别并不是删除数据文件的意思。但是要在非档模式下恢复此数据文件的前提是，联机日志中自数据文件创建以来的所有联机日志都没有被覆盖。下面是整个实验过程,并且注意，在整个恢复的过程中注意从视图中获得的数据文件状态的变化:
SQL> archive log list;
Database log mode No Archive Mode Automatic archival Disabled Archive destination c:\arc Oldest online log sequence 7 Current log sequence 9
SQL> set linesize 200
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------- 1 1 8 52428800 1 YES INACTIVE 730667 2008:01:15 08:57:55 2 1 9 52428800 1 NO CURRENT 755863 2008:01:15 11:49:53 3 1 7 52428800 1 YES INACTIVE 696036 2008:01:14 12:30:46
SQL>
SQL> alter tablespace users add datafile 'D:\DIABLOORACLE\DATABASE\DIABLOBIGTIDE.DBF' size 5M;
Tablespace altered.
SQL> alter system switch logfile; System altered.
SQL>select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------- 1 1 8 52428800 1 YES INACTIVE 730667 2008:01:15 08:57:55 2 1 9 52428800 1 NO ACTIVE 755863 2008:01:15 11:49:53 3 1 10 52428800 1 NO CURRENT 768362 2008:01:18 15:19:46 在操作系统层删除6号数据文件后，对6号数据文件作offline drop操作
SQL> alter database datafile 'C:\ORADATA\TEST\TEST\users03.dbf' offline drop; Database altered. SQL> 查看数据文件状态,当对数据文件执行offline drop 命令后，数据文件状态变为recover
SQL> select file#,status,name from v$datafile order by 3;
FILE# STATUS NAME ---------- ------- ------------------------------------------------------------------------ 3 ONLINE C:\ORADATA\TEST\TEST\SYSAUX01.DBF 1 SYSTEM C:\ORADATA\TEST\TEST\SYSTEM01.DBF 5 ONLINE C:\ORADATA\TEST\TEST\TBS_UNDO_01.DBF 4 ONLINE C:\ORADATA\TEST\TEST\USERS01.DBF 2 ONLINE C:\ORADATA\TEST\TEST\USERS02.DBF 6 RECOVER C:\ORADATA\TEST\TEST\USERS03.DBF
SQL> 根据控制文件中的信息，重新创建6号数据文件
SQL> alter database create datafile 6;
Database altered. 在执行完创建命令后，数据文件状态仍然为recover,此时数据文件中只有非常简单的信息
SQL> select file#,status,name from v$datafile order by 3;
FILE# STATUS NAME ---------- ------- ------------------------------------------------------------------------ 3 ONLINE C:\ORADATA\TEST\TEST\SYSAUX01.DBF 1 SYSTEM C:\ORADATA\TEST\TEST\SYSTEM01.DBF 5 ONLINE C:\ORADATA\TEST\TEST\TBS_UNDO_01.DBF 4 ONLINE C:\ORADATA\TEST\TEST\USERS01.DBF 2 ONLINE C:\ORADATA\TEST\TEST\USERS02.DBF 6 RECOVER C:\ORADATA\TEST\TEST\USERS03.DBF 因为联机日志还未被覆盖，尽管处于非归档模式，仍然可以对6号数据文件作恢复
SQL> recover datafile 6;
Media recovery complete.
SQL> 数据文件状态变为offline
SQL> select file#,status,name from v$datafile order by 3;
FILE# STATUS NAME --------- ------- ------------------------------------------------------- 3 ONLINE C:\ORADATA\TEST\TEST\SYSAUX01.DBF 1 SYSTEM C:\ORADATA\TEST\TEST\SYSTEM01.DBF 5 ONLINE C:\ORADATA\TEST\TEST\TBS_UNDO_01.DBF 4 ONLINE C:\ORADATA\TEST\TEST\USERS01.DBF 2 ONLINE C:\ORADATA\TEST\TEST\USERS02.DBF 6 OFFLINE C:\ORADATA\TEST\TEST\USERS03.DBF 在对数据文件作online操作后，数据文件恢复正常
SQL> alter database datafile 6 online;
第 1 行出现错误:
ORA-01190: 控制文件或数据文件 5 来自最后一个 RESETLOGS 之前
ORA-01110: 数据文件 5: 'D:\DIABLOORACLE\DATABASE\DIA\DIABLOBIGTIDE'
别慌。你该感到幸运。能到mount，数据文件没丢，还有，能遇到错误。下面，我提供一种完全恢复的做法，你可以参考一下：
1）去控制文件哪里，把file 5的scn取来
select file#，checkpoint_change# from v$datafile where file#=5;
这个scn是完全恢复的终点:终点scn
再把file 5的文件头的scn给拿来
select file#，checkpoint_change# from v$datafile_header where file#=5；
这个scn是完全恢复的起点：起点scn
2）此时，oracle要打开的必要条件是这两个scn要一致。但必然的，你查出来的肯定不一样。如果你有归档的话，会比较幸运。因为，从起点到终点，这些scn被放在归档日志里。接下来你要做的就是，确定这个起点scn落在哪个归档日志（组）里。你可以借助视图v$archived_log。
select sequence#，first_change#,next_change#
from v$archived_log
where 起点scn>=first_change# and 起点scn<=next_change#；
3）通过上面的，你会知道，要从那个归档日志开始，即：前滚的起点。那么你到底需要多少归档日志呢？这时，你可以再次借助v$archived_log来帮你。
select sequence#,first_change#,next_change#
from v$archived_log
where sequence#>=你第二步确定的序列号；
4）现在，你可以开始完全恢复。
recover datafile 5；
Database altered.
SQL> select file#,status,name from v$datafile order by 3;
FILE# STATUS NAME ---------- ------- ---------------------------------------------- 3 ONLINE C:\ORADATA\TEST\TEST\SYSAUX01.DBF 1 SYSTEM C:\ORADATA\TEST\TEST\SYSTEM01.DBF 5 ONLINE C:\ORADATA\TEST\TEST\TBS_UNDO_01.DBF 4 ONLINE C:\ORADATA\TEST\TEST\USERS01.DBF 2 ONLINE C:\ORADATA\TEST\TEST\USERS02.DBF 6 ONLINE C:\ORADATA\TEST\TEST\USERS03.DBF 从上面恢复的整个过程可以看出，尽管数据库处于非归档模式，只要数据文件创建以来的联机日志还没有被覆盖，数据文件就可以恢复出来。
数据库恢复
shutdown immediate;
2) 复制所有数据文件备份。
SQL> @f:\sql\recover.sql
SQL> select file#,change# from v$recover_file;
FILE# CHANGE#
---------- ----------
1 2558251
2 2558251
3 2558251
4 2558251
5 2558251
6 2558251
已选择6行。
----当复制数据文件备份时，必须确保备份文件的scn值小于要恢复到的scn值。
2558251 < 2559954 !
SQL> select max(first_change#) fchange from v$log_history where sequence#=23;
FCHANGE
----------
2559954
sqlplus /nolog;
connect bigtide2012/123456 as sysdba;
archive log list; (非存档模式)
select * from v$log;
recover datafile 5; (更改 674013 (用于线程 1) 在序列 #6 中)
alter database open resetlog;
startup mount;
recover database until time '2013-07-04 14:17:01';
recover database until cancel;
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
auto
recover database until cancel;
alter database open resetlogs;
****************************************************************************************************************************
数据文件归档
Oracle表空间的实际数据文件丢失的恢复，我们假设Oracle数据库其处于归档模式。我们在数据库里重建一个Oracle表空间，一共有3个相关的数据文件。各10M，表空间内有一张23M的表。
- SQL> select count(*) from ldy.t1;
- COUNT(*)
- 605136
- SQL> col segment_name for a20
- SQL> col tablespace_name for a20
- SQL> select segment_name,tablespace_name,bytes/1024/1024 mb from dba_segments where owner='LDY';
- SEGMENT_NAME TABLESPACE_NAME MB
- T1 LDY 23
关闭数据库，将Oracle表空间的其中一个数据文件删除，启动后报错：
- SQL> startup
Oracle例程已经启动。
- Total System Global Area 612368384 bytes
- Fixed Size 1250428 bytes
- Variable Size 230689668 bytes
- Database Buffers 373293056 bytes
- Redo Buffers 7135232 bytes
数据库装载完毕。
ORA-01157: 无法标识/锁定数据文件 6 - 请参阅 DBWR 跟踪文件
ORA-01110: 数据文件 6: 'E:\ORACLE\ORADATA\LDY01.DBF'
此时数据库为mount状态。
- SQL> select open_mode from v$database;
- OPEN_MODE
- MOUNTED
增加回该数据文件。
- SQL>alter database create datafile 'E:\ORACLE\ORADATA\LDY01.DBF';
数据库已更改。
介质恢复。
- SQL>recover datafile 6;
完成介质恢复。
数据库打开，正常查询。
- SQL> alter database open;
数据库已更改。
- SQL> select count(*) from ldy.t1;
- COUNT(*)
- 605136
以上的相关内容就是对@Oracle表空间的数据文件丢失的恢复的介绍，望你能有所收获。
改变归档模式
简单介绍如何启用和关闭数据库的归档模式。
1.shutdown normal或shutdown immediate关闭数据库
[oracle@jumper oracle]$ sqlplus "/ as sysdba"
SQL*Plus: Release 9.2.0.4.0 - Production on Sat Oct 15 15:48:36 2005
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
2.启动数据库到mount状态
SQL> startup mount;
ORACLE instance started.
Total System Global Area 101782828 bytes
Fixed Size 451884 bytes
Variable Size 37748736 bytes
Database Buffers 62914560 bytes
Redo Buffers 667648 bytes
Database mounted.
SQL> alter database datafile 5 offline drop;
数据库已更改。
3.启用或停止归档模式
如果要启用归档模式，此处使用
alter database archivelog 命令。
SQL> alter database archivelog;
Database altered.
SQL> alter database open;
Database altered.
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /opt/oracle/oradata/conner/archive
Oldest online log sequence 148
Next log sequence to archive 151
Current log sequence 151
如果需要停止归档模式，此处使用：
alter database noarchivelog 命令。
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 101782828 bytes
Fixed Size 451884 bytes
Variable Size 37748736 bytes
Database Buffers 62914560 bytes
Redo Buffers 667648 bytes
Database mounted.
SQL> alter database noarchivelog;
archive log start
alter database archivelog;
Database altered.
SQL> alter database open;
Database altered.
SQL> archive log list;
Database log mode No Archive Mode
Automatic archival Enabled
Archive destination /opt/oracle/oradata/conner/archive
Oldest online log sequence 149
Current log sequence 152
4.修改相应的初始化参数
Oracle10g之前，你还需要修改初始化参数使数据库处于自动归档模式。
在pfile/spfile中设置如下参数：
log_archive_start = true
重启数据库此参数生效，此时数据库处于自动归档模式。
也可以在数据库启动过程中，手工执行：
archive log start
使数据库启用自动归档，但是重启后数据库仍然处于手工归档模式。
从Oracle10g开始，log_archive_start参数已经废除，
******************************************
archive log list
5）执行了resetlogs之后，建议进行数据库的全备份。
SQL> archive log list
数据库日志模式 存档模式
自动存档 启用
存档终点 D:\DiabloOracle\product\10.2.0\db_1\RDBMS
最早的联机日志序列 1
下一个存档日志序列 1
当前日志序列 1
SQL> alter database begin backup;
数据库已更改。
SQL> @D:\diablo.sql
SQL> alter database end backup;
数据库已更改。
SQL> alter database backup controlfile to 'd:\diablo.ctl' reuse;
数据库已更改。
SQL> alter system archive log current;
系统已更改。
结束语： 做这个实验做了好几次都没成功，当执行第三步时，先输入cancel 提示，取消介质恢复。输入auto后，数据库才利用归档日志进行恢复。关于这一点，我有点不清楚了，既然是基于cancel的，为什么还要输入auto呢？请哪位看官给个解答。谢谢了
5 'D:\DIABLOORACLE\DATABASE\DIA\DIABLOBIGTIDE'
7 D:\DIABLOORACLE\DATABASE\DIA\EAS_D_BIGTIDEKD_STANDARD
8 D:\DIABLOORACLE\DATABASE\DIA\DIABLO_D_BIGTIDE
9 D:\DIABLOORACLE\DATABASE\DIA\EAS_D_BIGTIDE_STANDARD
10 D:\DIABLOORACLE\DATABASE\DIA\EAS_D_SONG_STANDARD
11 D:\DIABLOORACLE\DATABASE\DIA\EAS_D_BTEAS_STANDARD
ALTER DATABASE datafile 8 online;
ALTER DATABASE datafile 9 online;
ALTER DATABASE datafile 10 online;
ALTER DATABASE datafile 11 online;
alter database open resetlogs;
SELECT file#,STATUS FROM v$datafile;
ORA-01190: 控制文件或数据文件 5 来自最后一个 RESETLOGS 之前
DIABLO_T_BIGTIDE.DBF
DIABLOBIGTIDE.DBF
EAS_D_BTLX_STANDARD.DBF
EAS_T_BIGTIDE_STANDARD.DBF
EAS_T_BIGTIDEKD_STANDARD.DBF
EAS_T_BTEAS_STANDARD.DBF
EAS_T_BTLX_STANDARD.DBF
EAS_T_SONG_STANDARD.DBF
*****************************************************************************
oracle数据恢复：只有数据文件的情况下；
状况描述：当Oracle的控制文件丢失或损坏，但数据文件完好时，可以通过重建控制文件的方式对数据库实例进行恢复。恢复方法如下：
一、备份数据文件
一、安装Oracle，安装过程中不要创建数据库。
二、安装好后，用DBCA（Database ConfigurationAssistant）创建与丢失的实例相同名称的实例。创建实例时数据库名和实例名要和丢失前的一致。数据文件与控制文件的信息可以从（admin\xxxx\bdump\alert_xxxx.log）文件找到，其中xxxx为数据库名，参照这个文件里的CREATECONTROLFILE语句段。还要注意创建实例时的归档模式及非归档模式，如果admin\zhxt\bdump\alert_xxxx.log文件中的CREATECONTROLFILE 那一行最后是NOARCHIVELOG，则为非归档模式，如为ARCHIVELOG，则为归档模式，没有则保持没有
三、关闭Oracle（我的方法，在服务里将ＯＲＡＣＬＥ的有关服务改为手动，重启机子），用备份出来的数据文件覆盖新建的数据文件，并将新生成的控制文件及重做日志文件删除。
四、启动Oracle有监听（在服务里将ＯＲＡＣＬＥ有关的服务开启）
五、用sys用户连接到oracle
Sqlplus /nolog
SQL>conn sys/sys as sysdba;
六、关闭数据库
SQL> shutdown immediate;
七、起动数据库，但不挂载数据文件
SQL> startup nomount;
八、重建控制文件，重建控制文件的脚本可以从admin\xxxx\bdump\alert_xxxx.log）文件找到，搜索 CREATECONTROLFILE 语句，如果存在多处这样的语句，则使用最后的。
控制文件的脚本类似如下语句：
CREATE CONTROLFILE REUSE DATABASE "zhxt" NORESETLOGS NOARCHIVELOG
-- SET STANDBY TO MAXIMIZE PERFORMANCE
MAXLOGFILES 50
MAXLOGMEMBERS 5
MAXDATAFILES 100
MAXINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
GROUP 1 'E:\ORADATA\zhxt\REDO01.LOG' SIZE 100M,
GROUP 2 'E:\ORADATA\zhxt\REDO02.LOG' SIZE 100M,
GROUP 3 'E:\ORADATA\zhxt\REDO03.LOG' SIZE 100M
-- STANDBY LOGFILE
DATAFILE
'E:\ORADATA\zhxt\RKXT.ORA',
'E:\ORADATA\zhxt\SYSTEM01.DBF',
'E:\ORADATA\zhxt\TOOLS01.DBF',
'E:\ORADATA\zhxt\TYZHXTTBS.ORA',
'E:\ORADATA\zhxt\UNDOTBS01.DBF',
'E:\ORADATA\zhxt\USERS01.DBF',
CHARACTER SET ZHS16GBK
这一语句有几个地方需要修改：
1、 因为重做日志文件已丢失，所以要将第一句的，NORESETLOGS 改为 RESETLOGS
2、 LOGFILE段的几个重做日志文件指定为实际希望的位置
3、 DATAFILE段的数据文件改为数据文件实际的位置，注意这里不要包括临时表空间用到的文件，否则会出错。
执行修改后的脚本。如果提示控制文件创建完成，则可以进行下一步操作。
结果系统报错:
ORA-01503: CREATE CONTROLFILE ??
ORA-01160: ???? data file
ORA-01110: ???? : 'D:\oracle\oradata\cicdb\TEMP01.DBF'
则需要将重建日志文件中DATAFILE段中TEMP01这行删除，因为它是临时表空间，可以在创建后用alterdatabase语句加上。再次执行重建控制文件的脚本。
九、创建控制文件成功后，执行以下语句打开数据库，加上RESETLOGS参数是为了重新生成重做日志文件。
SQL> alter database open RESETLOGS;
如果出现以下错误：
alter database open resetlogs
*
第 1 行出现错误:
ORA-01194: 文件 1 需要更多的恢复来保持一致性
ORA-01110: 数据文件 1:
'D:ORACLEPRODUCT10.2.0ORADATAORACLE10GSYSTEM01.DBF'
解决方法如下：
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: 'F:SUNSYSTEM01.DBF'
SQL> set wrap off
SQL> set lin 300
SQL> select * from v$recover_file;
FILE# ONLINE ONLINE_ ERROR CHANGE# TIME
---------- ------- ---------------------------------------------------------------------------------- ----------
1 ONLINE ONLINE 476049 08-JAN-08
2 ONLINE ONLINE 476049 08-JAN-08
3 ONLINE ONLINE 476049 08-JAN-08
4 ONLINE ONLINE 476049 08-JAN-08
SQL> recover database until cancel;
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 476049 generated at 01/08/2008 19:13:19 needed forthread 1
ORA-00289: suggestion :F:ORACLEFLASH_RECOVERY_AREASUNARCHIVELOG2008_01_08O1_MF_1_18_%U_.ARC
ORA-00280: change 476049 for thread 1 is in sequence #18
Specify log: {=suggested | filename | AUTO | CANCEL}
ORA-00308: cannot open archived log'F:ORACLEFLASH_RECOVERY_AREASUNARCHIVELOG2008_01_08O1_MF_1_18_%
U_.ARC'
ORA-27041: unable to open file
OSD-04002: ????????????
O/S-Error: (OS 2) ??????????????????????
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get errorbelow
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: 'F:SUNSYSTEM01.DBF'
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 476049 generated at 01/08/2008 19:13:19 needed forthread 1
ORA-00289: suggestion :F:ORACLEFLASH_RECOVERY_AREASUNARCHIVELOG2008_01_08O1_MF_1_18_%U_.ARC
ORA-00280: change 476049 for thread 1 is in sequence #18
Specify log: {=suggested | filename | AUTO | CANCEL}
E:oracleoradatasunsunredo01.log
ORA-00310: archived log contains sequence 17; sequence 18 required
ORA-00334: archived log: 'E:ORACLEORADATASUNSUNREDO01.LOG'
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get errorbelow
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: 'F:SUNSYSTEM01.DBF'
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 476049 generated at 01/08/2008 19:13:19 needed forthread 1
ORA-00289: suggestion :F:ORACLEFLASH_RECOVERY_AREASUNARCHIVELOG2008_01_08O1_MF_1_18_%U_.ARC
ORA-00280: change 476049 for thread 1 is in sequence #18
Specify log: {=suggested | filename | AUTO | CANCEL}
E:oracleoradatasunsunredo02.log
Log applied.
Media recovery complete.
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
SQL> alter database open resetlogs;
Database altered.
SQL>
十、将临时表空间加入到实例上
SQL> alter tablespace TEMP add tempfile 'E:\oradata\zhxt\TEMP01.DBF'reuse;
十一、退出sqlplus，重启oracle，测试是否成功
如何更改Oracle的默认监听端口（1521）
Oracle 的默认监听端口为1521，你可以方便的依照下列步骤修改为其他端口：
[oracle@dbserver2 admin]$ cd $ORACLE_HOME/network/admin
[oracle@dbserver2 admin]$ vi listener.ora
修改这个文档中的1521端口为你需要的端口your port
[oracle@dbserver2 admin]$ lsnrctl stop
[oracle@dbserver2 admin]$ lsnrctl start
这时虽然用sqlplus能连上，但用程序是连不上的，在ＣＭＤ下，netstat -an 查看时，1521端口是未开启的
解决方法如下（实际上是第三种，用手动启动数据库监听就ＯＫ了）：
程序报错：Io 异常: The Network Adapter could not establish the connection
这个异常的出现一般与数据库和你的PC的设置有关
这种异常的出现大致上有下面几种：
1。IP错误。
在设置URL时错误，例如：jdbc:oracle:thin:@192.168.0.36:1521:sharp
数据库服务器不正确：ping 服务器IP是否正确。不正确，将URL更改为正确
端口号错误：一般不会错误。
进行一下操作：在DOS上键入sqlplus，检查oracle是否开启
一却正常，执行下面第2步。
2。防火墙
如果机器上安装有放火墙，可能是服务器端口号屏蔽而造成的。关闭防火墙后，尝试重新连接。
仍然不行，执行第3步。
3。数据库监听未启动 修改PC上注册表中的ImagePath值。
以下是以现在主流的数据库ORACLE为例
重新手动启动数据库监听：
1：开始 → 运行→ 输入CMD→ 进入DOS命令提示界面
d:>lsnrctl
LSNRCTL> status
或者
LSNRCTL> start
至此，完全搞定
********************************************************************
一、有数据文件、控制文件和日志文件的备份1.服务器重装了操作系统，oracle也重装了。
如果重装的oracle和以前损坏的数据库是一模一样的结构，那么此时的恢复是比较简单的。
1）删除掉新建数据库的所有数据文件、控制文件和日志文件。Copy原数据库的数据文件、控制文件和日志文件到对应目录下。
2）
Cmd>sqlplus /nolog
Sql>conn as sysdba
用户名：system
密码：（此处密码为新创建数据库的密码）
Sql>shutdown immediate
Sql>startup nomount
Sql>alter database mount
此时看数据库是不是能mount起来，有时会提示没有口令文件PWDdemo.ora文件找不到。查看对应的目录（database下）会发现该文件是存在的。此时需要注意，该口令文件是新安装数据库后创建实例时生成的口令文件，不是以前所用数据库的口令文件，而现在，我们是用以前数据库的控制文件和数据文件来打开以前的数据库，所以此时需要重新创建一个口令文件。
Sql>shutdown immediate
Sql>host orapwd file=c：\oracle9i\database\PWDdemo.ora password=oracle
Entries=10 （放在database 目录下）
Sql>startup nomount
Sql>alter database mount
Sql>alter database open
打开数据库
2.如果新数据库的安装目录和原有数据库的目录不一样，那么此时可以重建控制文件来打开数据库。
因为原控制文件中记录的数据文件地址和现有的数据文件位置不一样。此时和下面第二中情况一样。当然，此时也可以创建和原数据库一样的目录结构（前提是要记得原数据库的目录结构），需要注意的就是参数文件中记录的控制文件位置和控制文件中记录的数据文件位置。
说明：我们需要清楚数据库在打开的三个阶段中，需要读取的文件
Sql>startup nomount （此时读取参数文件）
Sql>alter database mount （根据参数文件中记录的控制文件地址，去读取控制文件）
Sql>alter database open （根据控制文件中记录的数据文件地址，读取数据文件，打开数据库）
1015
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
