原文:http://www.eygle.com/archives/2009/07/dataguard_ora_01111.html
在DataGuard环境中,由于备库的路径、存储、空间等问题,可能会导致文件创建失败的问题。
在正常情况下,如果配置正确,文件是能够自动创建的,出错时可能的日志如下:
Sun Jul 5 23:28:23 2009
Media Recovery Log /opt/oracle/archivelog/1_47_689973859.dbf
Media Recovery Log /opt/oracle/archivelog/1_48_689973859.dbf
Media Recovery Log /opt/oracle/archivelog/1_49_689973859.dbf
WARNING: File being created with same name as in Primary
Existing file may be overwritten
File #5 added to control file as 'UNNAMED00005'.
Originally created as:
'/opt/oracle/oradata/mmstest/test01.dbf'
Recovery was unable to create the file as:
'/opt/oracle/oradata/mmstest/test01.dbf'
Errors with log /opt/oracle/archivelog/1_49_689973859.dbf
出现此种情况,进一步的告警日志可能会报出如下错误:
Sun Jul 5 23:28:28 2009
Errors in file /opt/oracle/admin/mmstest/bdump/mmstest_mrp0_32062.trc:
ORA-19502: write error on file "/opt/oracle/oradata/mmstest/test01.dbf", blockno 1024 (blocksize=8192)
ORA-27072: File I/O error
Linux Error: 9: Bad file descriptor
Additional information: 4
Additional information: 1024
Additional information: 397312
Some recovered datafiles maybe left media fuzzy
Media recovery may continue but open resetlogs may fail
Sun Jul 5 23:28:29 2009
Errors in file /opt/oracle/admin/mmstest/bdump/mmstest_mrp0_32062.trc:
ORA-19502: write error on file "/opt/oracle/oradata/mmstest/test01.dbf", blockno 1024 (blocksize=8192)
ORA-27072: File I/O error
Linux Error: 9: Bad file descriptor
Additional information: 4
Additional information: 1024
Additional information: 397312
以及尝试recover时可能再次出现:
Mon Jul 6 01:36:30 2009
Errors in file /opt/oracle/admin/mmstest/bdump/mmstest_mrp0_32589.trc:
ORA-01111: name for data file 5 is unknown - rename to correct file
ORA-01110: data file 5: '/opt/oracle/product/10.2.0/dbs/UNNAMED00005'
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01111: name for data file 5 is unknown - rename to correct file
ORA-01110: data file 5: '/opt/oracle/product/10.2.0/dbs/UNNAMED00005'
出现这些错误时MRP进程会停止工作,恢复中断:
Mon Jul 6 01:36:30 2009
MRP0: Background Media Recovery process shutdown (mmstest)
在修正相关的问题之后,我们可以进行如下一系列的操作来恢复这些错误:
SQL> alter system set standby_file_management=manual;
System altered.
SQL> alter database create datafile
2 '/opt/oracle/product/10.2.0/dbs/UNNAMED00005' as '/opt/oracle/oradata/mmstest/test01.dbf';
Database altered.
SQL> alter system set standby_file_management=auto;
System altered.
SQL> recover managed standby database disconnect from session;
Media recovery complete.
此时备库的恢复得以继续:
Mon Jul 6 01:41:14 2009
ALTER SYSTEM SET standby_file_management='MANUAL' SCOPE=MEMORY;
Mon Jul 6 01:42:13 2009
alter database create datafile
'/opt/oracle/product/10.2.0/dbs/UNNAMED00005' as '/opt/oracle/oradata/mmstest/test01.dbf'
Mon Jul 6 01:42:14 2009
Completed: alter database create datafile
'/opt/oracle/product/10.2.0/dbs/UNNAMED00005' as '/opt/oracle/oradata/mmstest/test01.dbf'
Mon Jul 6 01:42:26 2009
ALTER SYSTEM SET standby_file_management='AUTO' SCOPE=MEMORY;
Mon Jul 6 01:42:40 2009
ALTER DATABASE RECOVER managed standby database disconnect from session
Mon Jul 6 01:42:40 2009
Attempt to start background Managed Standby Recovery process (mmstest)
MRP0 started with pid=16, OS id=32607
Mon Jul 6 01:42:41 2009
MRP0: Background Managed Standby Recovery process started (mmstest)
Managed Standby Recovery not using Real Time Apply
parallel recovery started with 3 processes
Media Recovery Log /opt/oracle/archivelog/1_49_689973859.dbf
Mon Jul 6 01:42:47 2009
Completed: ALTER DATABASE RECOVER managed standby database disconnect from session
Mon Jul 6 01:43:02 2009
Media Recovery Log /opt/oracle/archivelog/1_50_689973859.dbf
Mon Jul 6 01:43:17 2009
Media Recovery Log /opt/oracle/archivelog/1_51_689973859.dbf
Mon Jul 6 01:43:32 2009
Media Recovery Log /opt/oracle/archivelog/1_52_689973859.dbf
Mon Jul 6 01:43:45 2009
Media Recovery Log /opt/oracle/archivelog/1_53_689973859.dbf
正常情况下的配置及文件创建,其提示应该类似如下过程:
Mon Jul 6 01:53:28 2009
WARNING: File being created with same name as in Primary
Existing file may be overwritten
Recovery created file /opt/oracle/oradata/mmstest/wztest02.dbf
Successfully added datafile 7 to media recovery
Datafile #7: '/opt/oracle/oradata/mmstest/wztest02.dbf'
Media Recovery Log /opt/oracle/archivelog/1_80_689973859.dbf
在这个测试环境中,是由于空间不足导致的文件创建失败。
注意,在以上步骤中,如果standby_file_management设置为AUTO时,执行create命令会遇到如下错误:
SQL> alter database rename
2 file '/opt/oracle/product/10.2.0/dbs/UNNAMED00005' to '/opt/oracle/oradata/mmstest/test01.dbf';
alter database rename
*
ERROR at line 1:
ORA-01511: error in renaming log/data files
ORA-01275: Operation RENAME is not allowed if standby file management is automatic.
-The End-
分享到:
相关推荐
文中提到了通过命令行复制文件的方法,即使用cp命令将有效的init.ora文件复制到指定路径。操作前应确保有相应的权限,同时需要注意文件名和路径的正确性。 5. Oracle 11g和10g版本的区别:文档中提及的“oracle11...
在MOS中,可以通过搜索关键词找到对应的问题,如"zero ext4",可以找到文档ID为1487957.1的解决方案,该文档详细解释了与ext4文件系统和filesystemmio_options相关的问题。 总结来说,本文讨论了在配置Oracle ...
- **创建Broker配置文件**:通过`dgmgrl`命令行工具创建Broker配置文件。 - **注册数据库**:使用`dgmgrl`命令行工具注册主库和物理备库。 - **创建保护组**:通过`dgmgrl`创建保护组并关联主库和物理备库。 ##### ...
随后,重点讲解了Data Guard的部署步骤,涵盖源库和备库的参数设置、目录创建、监听器和tnsnames.ora文件配置、RMAN备份恢复以及最终将备库启动到recover模式的具体操作。最后,通过业务测试验证了DG配置的成功。 ...
- 确保文件夹权限与`administrator`用户一致,以便避免权限问题导致的安装失败或后续操作异常。 #### 三、Primary 主机操作步骤 1. **设置强制日志记录**: - 使用`sysdba`身份登录到Oracle数据库: ``` SQL> ...
网络配置文件(如`tnsnames.ora`、`listener.ora`)则定义了网络服务和监听器的设置,以支持远程数据库访问。 ### 其他组件 Oracle 9i还支持多种可选组件,如实时应用集群(Real Application Clusters)、智能代理...
在Oracle数据库环境中,ASM(Automatic Storage Management)是一种自动化的存储管理解决方案,它为数据库提供了一种集成的、高效的数据存储和管理方式。然而,当ASM磁盘数据丢失时,问题可能会变得非常严重,如标题...