如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]
问题描述：
====================
每当Oracle试图访问数据文件来执行DML语句，但发现该文件脱机时会发出一个ORA-01135：
ORA-01135: “file %s accessed for DML/query is offline”
Cause: Attempted to access a data file that is offline 原因：试图访问一个脱机的数据文件
Action: Bring the data file back online 操作：将数据文件恢复联机
ORA-01135 错误通常伴随着ORA-01110。
解决方案描述：
=====================
解决ORA-1135的第一步是找出为什么数据文件脱机：
– 你或其他有ALTER DATABASE 权限的用户可能使其脱机。
在这种情况下，参见方案I解决方案。
– Oracle 可能由于I/O错误或损坏使数据文件脱机。
参见方案II解决方案。
如果你不能确定数据文件脱机的原因，则检查此实例的alert.log文件。它会显示任何使数据文件脱机的语句。如果没有找到，搜索最近引用数据文件的ORA-01110条目或任何被报告的I / O错误。如果你发现任一情况，
– 这些错误是否仅指向数据文件？
如果是这样，请参阅方案II的解决方案。
-如果错误指向其它数据文件，这些文件是否在同一磁盘？
在相同的磁盘控制器下？
如果它们在同一磁盘，有可能是该磁盘的问题。如果它们在不同的磁盘相同的控制器下，你可能有一个坏的控制器。查看方案II的解决方案。
- 数据文件被手动脱机
————————————-
在这种情况下，你可以恢复数据文件并使它重新联机，或如果恢复不可行，重建数据文件所属的表空间。后者通常是在数据库处于NOARCHIVELOG模式且你脱机drop了数据文件。如果这适用于你的情况，仅当被应用于文件的更改在联机日志的范围之内，你才能成功恢复数据文件。
具体操作步骤如下：
- 如果数据库宕机，将其mount。
- 如果数据库在mount point，联机数据文件。
ALTER DATABASE DATAFILE ‘<full_path_file_name>’ ONLINE;
- 发出以下查询：
SELECT V1.GROUP#, MEMBER, SEQUENCE#, FIRST_CHANGE#
FROM V$LOG V1, V$LOGFILE V2
WHERE V1.GROUP# = V2.GROUP# ;
这将列出所有的联机重做日志文件以及它们各自的序列和第一个更改号。
- 如果数据库处于NOARCHIVELOG模式，发出查询：
SELECT FILE#, CHANGE# FROM V$RECOVER_FILE;
如果CHANGE＃大于你日志的最小FIRST_CHANGE＃GREATER，数据文件可以被恢复。只要记住，所有被应用的日志将是联机日志，并进入第5步。
如果CHANGE＃小于你日志的最小FIRST_CHANGE＃，该文件不能被恢复。此时你的选择将是还原最近的完整备份（因而会失去之后的对数据库的所有更改），或重建脱机数据文件所属的表空间 。关于后一个方法的进一步细节， 根据数据文件所属的表空间，参阅该条目的解决方案参考之一：
表空间 参考
———- ———
- 恢复数据文件：
RECOVER DATAFILE ‘<full_path_file_name>’
- 确认系统提示的每个日志，直到收到消息”Media recovery complete”。如果系统提示一个不存在的归档日志，Oracle可能需要一个或多个联机日志来继续恢复。将ORA-00280信息中引用的序列号与你的联机日志序列号比较。然后输入重做组成员之一的全路径名，其序列号与请求的相同。继续输入请求的联机日志，直到收到消息”Media recovery complete”。
- 如果数据库在mount point，打开它。
如果此时你获得ORA-00704, ORA-00604, 和ORA-00955，只要进行一个shutdown abort，之后启动。
- 如果你尚未联机文件，现在就这么做。
ALTER DATABASE DATAFILE ‘<full_path_file_name>’ ONLINE;
- 数据文件被Oracle脱机
—————————————
如果Oracle自己脱机了文件，最有可能是由于I / O错误试图访问数据文件。
使用裸设备和异步I / O时，一些问题在早期7.0 版本被报告。
and async I/O. Such problems may cause datafiles to go offline automatically.
If that is your case, the workaround is to turn async I/O OFF in the init.ora
file for this instance. 这样的问题可能会导致数据文件自动脱机。如果你遇到这种情况，解决办法是在该实例中的init.ora文件中将异步I / O 关闭。
PERFORMING HARDWARE CHECKS IS ESSENTIAL. If hardware problems are not fixed,
trying to solve the problem at the database level will be useless. Run
operating system level utilities and diagnostic tools that check for the
sanity of disks, controllers, and the I/O subsystem. Pay special attention to
the disk where the datafile referenced in the ORA-01135 resides. Your system
administrator should be able to assist you in this task. Such diagnostics
should be done in parallel with the steps recommended here, if feasible, or as
soon as possible thereafter. 执行硬件检查是必要的。如果硬件问题未被修复，试图在数据库级别解决问题是无用的。运行操作系统级别工具和诊断工具，检查磁盘，控制器和I / O子系统的健康。特别注意在ORA-01135中被引用的数据文件所在的磁盘。你的系统管理员应该能够帮助你完成这一任务。如果可行的话，这样的诊断应与这里建议的步骤并行完成，或在其后尽快完成。
在该方案中的步骤有：
- 如果数据文件在SYSTEM表空间中，或者数据库处于NOARCHIVELOG模式，关闭数据库。进入第3步。
如果shutdown immediate失败，进行shutdown abort。
- 如果数据库在ARCHIVELOG模式下，你仍应该关闭数据库，除非它对于保持数据库打开是必要的。
- 尝试将数据文件复制到另一个磁盘（可以的话，最好由另一个控制器管理）。
- 如果复制失败，即使重试，必须必须考虑数据文件丢失。接下来的操作取决于丢失文件所属的表空间。参阅以下解决方案参考PR条目，根据不同类型的表空间，获得如何继续操作的说明。
重要信息：虽然进行下面的参考条目时，
记住如果你是从备份中恢复数据文件，你需要 将其放在另一个磁盘，最好在不同的控制器下，并在Oracle中重命名它（见Note:115424.1了解详细信息）。不论你重建了什么表空间，确保其数据文件在另一个磁盘中创建，最好在不同的控制器下。
表空间 参考
———- ———
- 如果数据库宕机，mount它。
- 在Oracle中重命名数据文件。
ALTER DATABASE RENAME FILE ‘<old_full_path_file_name>’
TO ‘<new_full_path_file_name>’;
- 如果数据库在mount point，使数据文件联机。
ALTER DATABASE DATAFILE ‘<full_path_file_name>’ ONLINE;
- 对数据文件执行媒体恢复。
RECOVER DATAFILE ‘<full_path_file_name>’;
- 如果数据库被mount，打开它。如果你尚未联机文件，立即进行。
ALTER DATABASE DATAFILE ‘<full_path_file_name>’ ONLINE;
说明：
============
什么导致了ORA-01135？
————————-
一个ORA-01135 通常由以下情况导致：
– 对一个被手动脱机或由于I/O错误被Oracle脱机的数据文件执行DML语句。
– 一个回滚段数据文件由于其中的活跃事务脱机。
– 在7.1.5之前，drop一个有参照完整性约束的表空间或禁用一个外键约束时，bug:222852 可能导致ORA-01135 。
参考:
===========
Note: 184327.1 Common Causes and Solutions on ORA-1157 Error Found in Backup & Recovery
Note: 1013221.6 RECOVERING FROM A LOST DATAFILE IN A ROLLBACK TABLESPACE
Note: 115424.1 HOW TO RENAME OR MOVE DATAFILES AND LOGFILES
已知Bug：
===========
Bug 9469178 – Querying V$DATABASE raises ORA-1135 when a datafile header is corrupt (affects RMAN)
在RMAN 执行还原时，如果一个数据文件头损坏，发生ORA-1135。
例如：
RMAN-03002: failure of restore command at 03/11/2010 18:42:26
ORA-01135: file 4 accessed for DML/query is offline
ORA-01110: data file 4: ‘/home/ora11201/…/users01.dbf’
RMAN-06010: error while looking up datafile: 4
影响版本11.2.0.1 和11.2.0.2
在12.1.0.1 和11.2.0.3中修正
详细信息参见以下文档：
Bug 9469178 – Querying V$DATABASE raises ORA-1135 when a datafile header is corrupt (affects RMAN) (Note: 9469178.8)
Bug 8367917 ORA-1135 in a Recovery with a plugged in offline datafile
“ORA-01135: file accessed for DML/query is offline”
can be produced in a recovery for an offlined plugged in datafile
(TTS / Transportable Tablespace was used).
影响版本10.2.0.4
在10.2.0.5 和11.2.0.1中修正
详细信息参见以下文档：
Bug 8367917 – ORA-1135 in a Recovery with a plugged in offline datafile (Note: 8367917.8)
Bug 222852 : CANNOT DROP TABLESPACE WHEN USING REFERENTIAL INTEGRITY
Fixed Ver: 7.1.5
—
搜索字：
=============
ORA-1135 ORA-1110 ORA-280 ORA-704 ORA-604 ORA-955
Leave a Reply