Oracle ORA-1157 故障排除 ORA-01157: 无法标识/锁定数据文件 - 请参阅 DBWR 跟踪文件

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

 

 

ORA-01157: 无法标识/锁定数据文件  - 请参阅 DBWR 跟踪文件

 

 

ORA-01157 oerr ora 1157
01157, 00000, "cannot identify/lock data file %s - see DBWR trace file"
// *Cause:  The background process was either unable to find one of the data 
//         files or failed to lock it because the file was already in use.
//         The database will prohibit access to this file but other files will
//         be unaffected. However the first instance to open the database will
//         need to access all online data files. Accompanying error from the
//         operating system describes why the file could not be identified.
// *Action: Have operating system make file available to database. Then either
//         open the database or do ALTER SYSTEM CHECK DATAFILES.

 

适用于：

Oracle数据库的Enterprise Manager
本文信息适用于任何平台。

目的

本文旨在列出ORA-1157错误的常见原因和解决方案。

范围

本文针对Oracle Support和Oracle 数据库管理员。

详细信息

Oracle Error: ORA-1157

每当Oracle尝试访问一个文件但无法找到或锁住时，发生ORA-01157。
错误说明：

01157, 00000, “cannot identify/lock data file %s – see DBWR trace file”

原因：后台进程要么无法找到数据文件之一，要么由于该文件已在使用而无法将其锁定。数据库将禁止访问该文件，但其他文件将不受影响。然而，打开数据库的第一个实例将需要访问所有在线数据文件。操作系统伴随的错误描述了为什么文件无法被识别。

 

操作：通过操作系统使文件可用于数据库。然后可以打开数据库或者ALTER SYSTEM CHECK DATAFILES。

ORA-01157错误通常伴随ORA-01110，同时可能有Oracle操作系统层错误，如ORA-07360。

DBWR background_dump_dest 目录中生成一个DBWR跟踪文件。
例如，在Solaris平台上，以下错误会显示：

ORA-01157: cannot identify/lock data file 19 – see DBWR trace file
ORA-01110: data file 19: ‘/app/Oracle/oradata/users02.dbf’

在DBWR 跟踪文件中：

ORA-01157: cannot identify/lock data file 19 – see DBWR trace file
ORA-01110: data file 19: ‘/app/Oracle/oradata/users02.dbf’
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3

ORA-1157常见问题和解决方案

注: 在本文中我们使用了”backups” ，但如果你有一个有效物理备用数据库，你也能使用备用数据库的数据文件来恢复主数据库。

1. 1.  数据文件存在，但Oracle无法找到它。数据文件可能在操作系统级别被重命名，有意或无意地移到另一个目录或磁盘驱动。

   在这种情况下，还原并恢复数据文件或将数据文件移到到它原来的名称。

   数据文件不存在或无法由Oracle使用。数据文件已经被物理删除或损坏到Oracle无法识别它的程度。

   例如，数据文件可能会被truncate或覆盖，在这种情况下ORA-27046 会伴随ORA-1157 错误。

   例如：

ORA-27046: file size is not a multiple of logical block size

在这个情况下，用户有两个选择：

A   重建数据文件所属的表空间。
该选择适用于USERS，INDEX，TEMPORARY 表空间。

如果数据库被干净关闭，同样建议对UNDO表空间使用，从而使该表空间的回滚段中没有活跃事务。

如果表空间是SYSTEM 表空间，则这相当于重建recreating or rebuilding 数据库。

该方法最适用于临时表空间（因为它们不包含重要数据），但也可用于USERS和INDEXES表空间。

在表空间中有相对较新的对象导出时，或可以通过运行脚本或程序，使用SQL*Loader加载数据等重新填充该表空间的表时，本方法会有帮助。

相关步骤为：

1. 如果数据库宕机，mount 它。

STARTUP MOUNT;

2. 脱机drop 数据文件。

ALTER DATABASE DATAFILE ‘full_path_file_name’ OFFLINE DROP;

3. 如果数据库在mount状态，打开它。

ALTER DATABASE OPEN;

4. Drop 用户表空间。

DROP TABLESPACE tablespace_name INCLUDING CONTENTS;

注：如果用户不再需要在数据库中的表空间，他们可以停止这个步骤。

5. 重建表空间。

CREATE TABLESPACE tablespace_name DATAFILE ‘datafile_full_path_name’ SIZE required_size;

6. 重建表空间中以前存在的对象。

这可以通过使用该表空间中对象的创建脚本或使用该表空间对象可用的最近export dump来完成。

B. 使用正常恢复过程恢复数据文件。

本选择最适用于READ ONLY表空间，以及重建不可行的USERS，INDEX 表空间。

如果表空间类型是UNDO，则此方法用于数据库未被干净关闭的情况。
（即，使用了shutdown abort或数据库崩溃）

如果表空间是SYSTEM，且有可用的备份和归档日志，则这是建议的方法。如果数据库在NOARCHIVELOG模式，那么仅当所需的更改出现在ONLINE重做日志中时才能恢复。

很多情况下，重新创建用户表空间是不可能的或者太费力。那么解决办法是从备份中还原丢失的数据文件并对其进行媒体恢复。如果数据库处于NOARCHIVELOG模式，则仅当被应用于数据文件的重做在联机日志的范围内，才能成功恢复数据文件。

这种方法对于READ ONLY表空间是理想的。如果在备份后表没有切换为READ-WRITE，且在备份时表空间是READ ONLY，则恢复仅还原该表空间的备份。

步骤如下：

1. 从备份中还原丢失的文件。

2.如果数据库宕机down，mount它。

STARTUP MOUNT;

3. 发出以下查询：

SELECT V1.GROUP#, MEMBER, SEQUENCE#,
FIRST_CHANGE#
FROM V$LOG V1, V$LOGFILE V2
WHERE V1.GROUP# = V2.GROUP# ;

这将列出所有的联机重做日志文件以及它们各自的序列和第一个更改号。

4. 如果数据库在NOARCHIVELOG 模式，发出查询：

SELECT FILE#, CHANGE# FROM V$RECOVER_FILE;

如果CHANGE#大于你日志的最小FIRST_CHANGE# ，则可以恢复数据文件。记住所有被应用的日志会是联机日志，进入第5步。

如果CHANGE＃小于你日志的最小FIRST_CHANGE#，则无法恢复文件。此时你的选择是还原最新的完全备份（从而失去所有那时起对数据库的所有更改），或者如在方案a中说明，重建表空间。

5. 恢复数据文件：

RECOVER DATAFILE ‘full_path_file_name’ ;

6. 确认系统提示的每个日志，直到你收到信息“Media Recovery Complete”。如果系统提示你一个不存在的归档日志，Oracle可能需要一个或多个联机日志继续恢复。将ORA-280信息中引用的序列号与你的联机日志序列号相比较。然后输入其序列号与所请求的序列号匹配的重做组成员之一的全路径名。继续输入请求的联机日志，直到收到信息“Media Recovery Complete”。

7. 如果数据库在mount point，打开它。

操作系统(OS) 临时文件丢失：

当使用有临时文件的临时表空间时，OS级别临时文件丢失会导致ORA-1157。由于Oracle不checkpoint临时文件，即使丢失临时文件仍可以打开数据库。

这个情况下的解决方法是drop逻辑临时文件并添加新的。

例如：

select * from dba_objects order by object_name;
select * from dba_objects order by object_name;
*
ERROR at line 1:

ORA-01157: cannot identify/lock data file 1026 – see DBWR trace file
ORA-01110: data file 1026: ‘/Oracle/oradata/temp2_01.tmp’

解决方案:

alter database tempfile ‘/Oracle/oradata/temp2_01.tmp’ drop;

select tablespace_name, file_name from dba_temp_files;

alter tablespace temp2 add tempfile ‘/Oracle/oradata/temp2_01.tmp’ size 5m;

 

ORA-1157 由于OS 问题/第三方软件

1. 当尝试通过vxfddstat或其他应用访问Quick I/O 文件，得到错误信息类似于”Cannot open file”。Oracle可能返回错误信息类似于：

ORA-01157: cannot identify data file 1 – file not found
ORA-01110: data file 1: ‘/u01/Oracle/oradata/system01.dbf’

在这个情况下用户需要联系Veritas support。要访问它们的支持网站，浏览网页：

http://support.veritas.com/

Click on: ‘Product Listing’
Click on: ‘File System for UNIX’
输入’Oracle’ 并点击’Search’ 从它们的Knowledge Base查看相关信息。

2. 如果内核参数nflock设置不够高，可能在HP上得到该错误。这可能组织Oracle锁定所需的数据文件。出于相同原因，重建控制文件可能失败显示ORA-27041 和ORA-1157。

在dump目录中跟踪文件中可能有更多错误，如：

ORA-27086: skgfglk: unable to lock file – already in use

或

ORA-01157: cannot identify/lock data file 263 – see DBWR trace file
ORA-0110: data file 263: ‘/u01/Oracle/mndata4/veax01.dbf’
ORA-27041: unable to open file
HP-UX Error: 23: File table overflow
Additional information: 2

或

ORA-07445: exception encountered: core dump [%s] [%s] [%s] [%s] [%s] [%s]
ORA-01110: data file %s: ‘%s’
ORA-01242: data file suffered media failure: database in NOARCHIVELOG mode
ORA-01115: IO error reading block from file %s (block # %s)
ORA-27041: unable to open file
HP-UX Error: 23: File table overflow
Additional information: 3

要解决这些问题，增加在HP上的相关内核参数。建议的设置为：

nproc 4096 Max Number of Processes
nfile 63488 Max Number of Open Files
nflocks 4096 Max Number of File Locks

参见OS Installation Guide获取更多关于这些参数的信息。

要解决在Solaris上ORA-27041 ‘File table overflow’，以下系统设置解决：

/etc/system parameters
set vxfs:vxfs_ninode=692416
set ncsize=519312

请注意，调整这些参数在Oracle Support范围外。

欲了解更多信息请参考sunsolve.sun.com中可用的Sun文档（76671），这解释了ncsize调整。

而且，调整vxfs:vxfs_ninode是VERITAS特有的，请直接发布问题到Veritas。

3. 如果Oracle要求的数据文件由某些进程锁定，有可能得到ORA-1157，例如备份软件可能锁定进行备份的文件。

在 MS 窗口上，用户可能得到以下错误：

ORA-01157: signalled during alter database open
ORA-01157: can not identify datafile
ORA-01110: data file 10: ‘u01/Oracle/oradata/index01.dbf’
ORA-27047: Unable to read header of file
OSD-04006: Read file failure
Error 33: process can not access file

操作系统错误33是error_lock_violation，表示该数据文件的一部分被另一个NT进程锁定。

或

ORA-1157 – cannot identify datafile – file not found
ORA-1110 – datafile 11 ‘u01/Oracle/oradata/index02.dbf’
ORA-9202 – sfifi: error identifying file
OSD-4006(OS 203) – The System could not find the environment option that was entered
其他可能在警报日志中显示的错误组合包括：

ORA-1115 – IO error reading block from file %s (block # %s)
ORA-1110 – datafile 11 ‘u01/Oracle/oradata/index02.dbf’
ORA-9206 – sfrfb: error reading from file
OSD-4006(OS 203) – The System Could not find the environment option that was entered
或

ORA-1242 – data file suffered media failure: database in NOARCHIVELOG mode
ORA-1114 – IO error writing block to file <name> block #
ORA-9205 – sfqio: error reading or writing to disk
OSD-4016(OS 33) – The process cannot access the file because another process has locked a portion of the file.
此外，以下错误会显示：

KCF: write/open error dba=0x703473d block=0x3473d online=1
file=7 E:\Oracle\data\grec\crecind2.dbf
error=9211 txt: ‘OSD-4008 : WriteFile error (OS 203) – The System Could not find the environment option that was entered
在一些情况中，警报日志也可能显示错误如：

Instance terminating due to error 1110.
Instance terminated by background process PID=XXX

或

background process TERMINATING INSTANCE DUE TO ERROR 472

ORA 472 – PMON process terminated with error

Microsoft Windows event viewer中也可能报告以下事件：

23 Error ReadFile() failure.
25 Error WriteFile() failure.

如果这是一个冷备份，需要等到备份完成然后重启数据库，或结束备份并启动数据库。

或者，解决方案是配置备份软件，这样它不锁住打开文件。

参见BACKUP软件文档获取如何操作的信息。

例如，需要对Seagate Backup Exec Software配置’Read and Not lock’ 选项来进行联机备份。

这也适用于一些Unix平台。
例如，IBM AIX ADSM备份工具在成功运作之前可能失败，从而维持Oracle数据文件上的锁。

这种情况下的解决方法是手动清理在数据文件上的锁。

i. 运行$ ps -ef | grep <SID&gt；- 查找在一个数据文件上存在的进程

ii. 在进程id执行$ kill -9

4. 如果使用在Windows上的File Manager将Oracle数据文件复制到一个目录可能发生ORA-1157。
如果文件名大于通常的8.3格式，这就是真的。
即，文件大于8个字符通常名称或有大于三个字符的扩展名。

当使用Windows 95/98复制文件，而不使用File Manager时避免了问题。如果文件有长文件名（例如： 大于标准8.3文件名规范），File Manager会使用8.3文件名重命名文件。

要保留常文件名，应该使用Explorer来复制文件。如果已经使用了File Manager且文件的名称中有一个tilde (~) ，需要将文件重命名为原始名称。

5. 当使用NETWORK 应用时可能生成ORA-1157。网络应用为特定操作获取数据文件上的锁。
这些锁可能由于实例或主机失败而被Network Appliance保留。在这些情况下，锁必须通过系统管理员从Network Appliance中手动释放。

这里使用的命令是：

As root on the netapp, from the prompt:

rc_toggle_basic

sm_mon -l <hostname>

在以上命令中被引用的主机名应为Oracle实例运行的主机的名称。

6. 如果作为另一个用户还原Oracle文件可能生成ORA-1157。

在还原一个数据文件并发出recover datafile后，错误ORA-1157 （cannot identify datafile – file not found）会发生。它似乎并未识别被还原的数据文件，尽管：

– 数据文件在OS存在。
– select * from v$datafile 显示数据文件的正确路径。
– “alter system check datafiles” 成功。
– backup control file to trace 显示数据文件的完整路径是正确的。

在这种情况下，这可能是OS级别的权限问题。

检查数据文件的权限。当数据文件被还原，它可能是被除Oracle（如root）外的其他用户完成的。
在这种情况下，文件对Oracle可见，但无法访问。Oracle无法读或写入数据文件，因为它不拥有文件。
将所有者权限更改为Oracle用户会使restore datafile命令成功。

ORA-1157 – 其他可能性

1. 损坏控制文件可能导致ORA-1157在一些控制文件损坏的极端情况下，用户能得到ORA-1157 。

   导致这些错误的一种损坏类型是在控制文件中文件名后有一个trailing blank。通过检查使用’ALTER DATABASE BACKUP CONTROLFILE TO TRACE’命令生成的控制文件的文本版本可以看到这个。
   （跟踪文件会被放置于user_dump_dest初始化参数指定的位置。）

   例如：
   ——–

   ‘/home/d/Oracle/oradata/ecn/rdx01.dbf ‘ — corrupt
   ‘/home/d/Oracle/oradata/ecn/rdx02.dbf’ — non-corrupt

   在这些情况下，解决方案是通过更改init.ora中的CONTROL_FILES参数来排除损坏的控制文件，尝试使用其他控制文件副本（如果它们未损坏）) 。如果所有控制文件损坏，则可以重建控制文件。
   也可以使其他’unexpected’ 控制字符嵌入控制文件中。

   例如：

   “^J” 可能显示在数据文件名中。

   以上解决方案也可用于这个情况。

   2. 在设置了备用数据库后，查看主数据库中是否添加了任何表空间/数据文件。

   如果是这样，在备用数据库上手动创建数据文件。当文件存在，恢复可以继续。如果数据文件未在备用站点被手动创建。

   例如：

   重做不会创建一个新的数据文件。启动mount的create datafile命令是：

   alter database create datafile ‘datafile_full_path_name’;

   3. RMAN 还原会在警报日志中生成 ‘fake’ ORA-1157 错误

   在RMAN还原操作期间，可能在警报日志中遇到以下错误：

ORA-01157: cannot identify/lock data file N – see DBWR trace file
ORA-01110: data file N: ‘filename’
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory

如果RMAN正在还原在还原操作之前被从磁盘中删除的数据文件，会发生该问题。

这些错误（在每个受影响的数据文件多次生成）可能是DBA关系和疑惑的。然而，它们是完全在预期中的，除了监控警报日志的大小（和归档，如果需要的话），都没有什么可担心的。

4. 新安装的seed数据库生成ORA-1157。

如果使用了seed数据库，Oracle会将数据文件从CD复制到磁盘并尝试启动数据库。当如果数据文件在CD中损坏，即如果CD 损坏，可能导致ORA-1157 错误。

这个的解决方法是使用新的CB集或使用手动创建脚本创建数据库。