解决Oracle ORA-1157

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

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

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

 

适用于

企业版数据库
本文内容适用于所有平台。

目标

本文主要是列出产生ORA-1157错误的常见原因和解决办法。

 

范围

本文针对Oracle支持和oracle数据库管理员。

 

详情

Oracle Error: ORA-1157

一个ORA-01157错误产生当Oracle尝试访问一个文件，但是文件没有找到或者文件被锁了。
错误描述:

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.

ORA-01157错误通常后跟ORA-01110和可能的Oracle操作系统层错误，如ORA-07360。一个DBWR跟踪文件在BACKGROUND_DUMP_DEST目录中生成。

例如，在Solaris平台，会看到这样的错误： 

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

From the DBWR trace file:

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常见的原因和解决方法

注：在本说明我们指的是“备份”，但如果你有一个有效的物理备用数据库，你也可以使用备用数据库数据文件来恢复主数据库。

1、数据文件是存在的，但是oracle没有发现

这个数据文件可能在操作系统层面上被重命名了，被移动到另一个目录下或磁盘驱动器无论是有意还是无意的。。
这种情况，还原和恢复这个数据文件或移动这个数据文件到原始的位置或改成原理的名字。
 

2、数据文件不存在或无法被Oracle使用。数据文件已物理删除或损坏达到数据库甲无法识别它的程度。
例如，这个数据文件被截断或者覆盖了，在这种情况下，ORA-27046会伴随着ORA-1157错误。

例如:

ORA-27046: 文件的大小不是逻辑块大小的整数倍
在这种情况下，有两种选择:

A   重建这个数据文件所在的表空间.

这个选项最适合用在user,index,temporary 表空间。

此外，还建议在undo表空间，如果数据库已经完全关闭，因此没有活跃的交易在这个表空间的回滚段里。
如果表空间是SYSTEM表空间，那么这相当于再造或重建数据库。
这种方法最适合于临时表空间（因为它们不包含重要数据），也可用于为user表空间和index表空间。
这种方法在最近的有效的导出的对象所在的表空间也是有帮助的，或在表空间中的表可以通过运行一个脚本或重新填充数据，通过SQL* Loader的加载数据等。

涉及的步骤如下：
1. 如果数据库是关闭的，先mount数据库

STARTUP MOUNT;

2. 把这个数据文件设置成Offline drop.

ALTER DATABASE DATAFILE 'full_path_file_name' OFFLINE DROP;

3.如果数据库是 mount的, 打开它.

ALTER DATABASE OPEN;

4. 删除表空间.

DROP TABLESPACE tablespace_name INCLUDING CONTENTS;
 

注：用户可以到这一步停止了，如果在数据库里不想再要这个表空间的话。

5. 重建这个表空间.

CREATE TABLESPACE tablespace_name DATAFILE 'datafile_full_path_name' SIZE required_size;

6.重建之前在这个表空间里的所有对象。

这可以通过使用创建脚本重建在该表空间中的对象，或使用该表空间的对象的最近导出的有效转储数据。

 

B. 恢复数据文件使用正常的恢复程序

这个选择最适合read only的表空间和无法重建的users，index表空间

如果表空间是undo表空间，这种方法适用于库没有关闭干净的。（也就是说，数据库突然中断或者数据库已经崩溃了）
如果表空间是SYSTEM，那么这是推荐的方法，如果有备份和归档日志是可用的。如果数据库是
NOARCHIVELOG模式，那么你只能用联机重做日志恢复需要的变化。

在许多情况下，重新创建表空间是不可能的或者太费力。该解决方案是从备份中恢复丢失的数据文件和做介质恢复。

如果数据库处于NOARCHIVELOG模式，则只能在在线日志的范围之内的数据恢复。

这种方法将是READ ONLY表空间最理想的方法。如果表空间在备份之后没有切换为读写，那么恢复数据时只要还原一下表空间的备份就行了。

步骤如下：
1.从备份中还原丢失的文件
2.如果数据库是关闭的，mount 它. 

STARTUP MOUNT;

3. 执行下面的查询:

SELECT V1.GROUP#, MEMBER, SEQUENCE#,
FIRST_CHANGE#
FROM V$LOG V1, V$LOGFILE V2
WHERE V1.GROUP# = V2.GROUP# ;
这将列出所有的在线日志文件和它们的序列号，还有第一次改变号。
 

4.如果数据库是非归档模式，执行下面的查询:

SELECT FILE#, CHANGE# FROM V$RECOVER_FILE;

如果CHANGE#比FIRST_CHANGE#的最小值打，那么这个数据文件可以恢复。只需记住所有的日志都是联机日志，然后进行第5步。
如果CHANGE#比FIRST_CHANGE#的最小值小，那么这个数据文件不可以恢复。
这是你只能还原到最近的一次全备（这将丢失全备之后的所有更改）或者根据选项A重建表空间。

5. 恢复数据文件: 

RECOVER DATAFILE 'full_path_file_name' ;

6. 确认每个系统提示的日志，直到你收到消息“介质恢复完成”。如果系统提示你一个不存在的
归档日志，数据库大概需要的一个或多个在线日志的与恢复进行。比较在线日志序列号和ORA-280消息中引用的序列号。然后输入其序列号相匹配一个重做组成员之的绝对路径。继续输入的要求联机日志，直到您收到消息“媒介恢复完成”。

7. 如果数据库现在是mount状态，打开它.
操作系统的临时文件丢失：
 

当使用临时表空间的临时文件，这个临时文件在系统级别丢失了也会产生ORA-1157错误。

由于Oracle不对临时文件做检查点操作，数据库甚至可以缺少临时文件被打开。这种情况的解决办法就是删除逻辑的临时文件，并新增加一个。
例如:

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

1. When trying to access Quick I/O files with vxfddstat, or other applications, getting an error message similar to "Cannot open file".
当试图快速访问I/ O文件，vxfsstat，或其他应用程序，类似的错误消息“无法打开文件”。
Oracle返回类似如下的错误信息：

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

在这种情况下，用户需要联系Veritas支持。要访问其支持网站，请将Web浏览器：
http://support.veritas.com/

Click on: 'Product Listing'
Click on: 'File System for UNIX'
Enter 'Oracle' and click 'Search' to view relevant information from their Knowledge Base.

2.在惠普的机器上如果内核参数nflock未设置足够高可能后产生这个错误。这可能会阻止oracle以锁定所需的数据文件。重建控制文件可能会失败，ORA-27041和ORA-1157同样的原因。:

这可能会有更多的错误在dump目录下的跟踪文件：

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

OR

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

OR

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

解决这个问题，增加内核参数在惠普上。推荐的设置如下：
nproc 4096 Max Number of Processes
nfile 63488 Max Number of Open Files
nflocks 4096 Max Number of File Locks

这些参数的更多消息请参考操作系统安装指南。
解决ORA-27041错误'File table overflow'在Solaris上，下面是系统设置的解决经验：
/etc/system parameters
set vxfs:vxfs_ninode=692416
set ncsize=519312

请注意，调整这些参数是Oracle支持的范围外。欲了解更多信息请参考sunsolve.sun.com可用的Sun文档（76671），这也解释了值ncsize调整。而且，调整的VxFS：vxfs_ninode是VERITAS特有的，请直接发布问题到Veritas。

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

在 Windows系统上, 用户收到下列的错误：

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

The operating system error 33 is an error_lock_violation indicating that a portion of the data file is locked by another NT process.
操作系统错误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

在某些情况下，alter日志可能会显示如下的一些错误：
由于1110错误终止实例。
后台进程PID-XXX终止了实例。

或

background process TERMINATING INSTANCE DUE TO ERROR 472

ORA 472 - PMON process terminated with error

下面的错误也会在Windows的时间查看器里报出：
23 Error ReadFile() failure.
25 Error WriteFile() failure.

如果这是一个冷备，那么需要等待备份完成后启动数据库，或者停止备份然后启动数据库。
可替代的解决办法是设置备份软件让文件不会被锁定。

参考BACKUP 软件文档信息看如何进行设置。
例如，在Seagate Backup Exec Software上，可以设置'Read and Not lock'选项实现在线备份。

在某些linux平台上是可以实现的。

这种情况的解决办法就是手动清除数据文件上的锁。
i. Run $ ps -ef | grep <SID> - look for an existing process on a datafile

ii. Do $ kill -9 on the process id

4. 在windows系统上用文件管理器复制oracle数据文件到其他目录，如果这个数据文件的名字超过了8.3格式的话就会产生ORA-1157 错误。就是文件名称长度大于8个字符或延伸超过3个字符。

为避免这个问题，当在windows95/98上复制文件时，不要用文件管理器。如果文件的名字很长（超过标准的8.3文件名字命名规则），文件管理器会根据8.3文件名字命名规则重命名这个文件。
为了保持长文件名，应该用浏览器来复制文件。如果文件管理器已被使用和文件在文件名中有波浪号（〜），该文件需要被重新命名为原来的名称。

5.在网络应用创建某些操作是需要要求对数据文件加锁，那么也会产生ORA-1157错误。
实例或者主机的崩溃，网络应用是会保留这个锁的，在这种情况下，必须让系统管理员手动来释放锁。

命令如下:

As root on the netapp, from the prompt:

rc_toggle_basic

sm_mon -l <hostname>

上面命令里的主机名应该是正在运行实例的主机的名字。

6.不同的用户进行还原操作可能产生ORA-1157错误。

restore 数据文件之后进行recover是，产生ORA-1157错误，无法识别resore之后的数据文件，尽管这些是正常的：

- The datafile exists at the OS.
- select * from v$datafile shows the correct path for the datafile.
- "alter system check datafiles" is successful.
- backup control file to trace shows full path to datafile is correct.
 
这种情况应该是操作系统级别上的权限问题引发的。检查数据文件的权限，看恢复操作是否是由其他用户完成的，用root用户而不是oracle用户。

这种情况，文件能被Oracle用户看到，但是不能进行读写，因为这个文件不是oracle所有。

改变文件的所有权，允许oracle用户restore数据文件，命令才能成功。
 

ORA-1157 –其他可能性

1. 错误的控制文件可能引发ORA-1157
 
用户可能会得到ORA-1157错误在某些极端情况下，在控制文件损坏。一个可能导致这些错误的原因是控制文件里的文件名后面跟空白。这可以通过检查控制文件的文本版本，使用“ALTER DATABASE BACKUP CONTROLFILE TO TRACE'命令生成文本版本。（跟踪文件将被放置在由USER_DUMP_DEST初始化参数指定的位置）。
 

Example:
--------

'/home/d/Oracle/oradata/ecn/rdx01.dbf ' -- corrupt
'/home/d/Oracle/oradata/ecn/rdx02.dbf' -- non-corrupt
 

在这种情况下，用控制文件的其他副本（如果他们没坏）来解决，修改初始化参数文件init.ora里的CONTROCL_FILES参数来去除损坏了的控制文件，如果全部控制文件都坏了，那么就要重新创建控制文件，
它也可能是嵌入在控制文件中的其他“意外”控制字符。

例如:

"^J" 可能会出现在数据文件的名字里.

上述解决方案在这种情况下也是能解决的。

2. 检查在备库建好之后是否在主库上有添加表空间或数据文件。

如果数据文件没有在备库上自动创建，那么在备库上手动创建数据文件。当文件存在，恢复可以继续。
例如:

redo没有创建数据文件. 在mount状态下创建数据文件:

alter database create datafile 'datafile_full_path_name';

3. RMAN还原可以在alert.log产生“假”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. 用种子数据库新安装时报ORA-1157
如果用种子数据库，Oracle会从CD复制数据文件到磁盘并尝试启动数据库。但是如果数据文件在CD里就损坏了，就会产生ORA-1157错误。

这种问题的解决办法是用一套新的CD或者用手动创建脚本创建数据库。

 

​