Home IT Linux Windows Database Network Programming Server Mobile  
           
  Home \ Database \ DataGuard the MRP can not start to analyze and solve problems     - MySQL Data Types (Database)

- CentOS 6.x and CentOS7 installation RPMforge (Linux)

- Java interface (Programming)

- GDB remote connections RX Probe online debug program (Programming)

- In the case of using cgroups Ubuntu 14.04 and Docker (Linux)

- Btrfs file system repair techniques (Linux)

- Spring Data JPA call a stored procedure examples (Programming)

- Hadoop new and old version of the difference in the size of the InputSplit (Server)

- Linux5.8 installed phpMyAdmin was unable to issue related php-mcrypt (Database)

- Java development environment to build under Ubuntu (Linux)

- CentOS 6.4 compiler installed MySQL 5.6.14 (Database)

- CentOS How quickly customize kernel binary RPM package (Linux)

- Oracle database online redo logs are several methods of recovery of deleted (Database)

- Linux operating system security settings initial understanding (Linux)

- C # socket udp broadcast (Programming)

- Kafka cluster deployment (Server)

- Linux - Common process the command (Linux)

- Spacewalk Linux system configuration and installation (Linux)

- Comparison of one-time transaction and CTE insert data (Database)

- MySQL function: group_concat () function (Database)

 
         
  DataGuard the MRP can not start to analyze and solve problems
     
  Add Date : 2017-04-13      
         
       
         
  Own hand set dataguard environment, because some days not used, the results of a sudden whim ready to start together to learn about, suddenly found knocking at the command recover managed standby database disconnect from session after the command runs correctly, but the background was reported ora error .

Sat Jun 27 23:16:39 2015
Recovery Slave PR00 previously exited with exception 1157
 Errors in file /u02/dg11g/diag/rdbms/dg11g/DG11G/trace/DG11G_mrp0_6514.trc:
 ORA-01157: can not identify / lock data file 7 - see DBWR trace file
 ORA-01110: data file 7: '/u02/dg11g/oradata/DG11G/test_new01.dbf'
MRP0: Background Media Recovery process shutdown (DG11G)
 Sat Jun 27 23:16:39 2015
 Completed: ALTER DATABASE RECOVER managed standby database disconnect from session
 RFS [162]: Opened log for thread 1 sequence 171 dbid 1028247664 branch 880742847
 RFS [161]: Opened log for thread 1 sequence 173 dbid 1028247664 branch 880742847
 RFS [160]: Opened log for thread 1 sequence 172 dbid 1028247664 branch 880742847
Through the above, we can see the log, MRP data recovery process is done in the time reported ora-01157 error ora
But still there is no problem RFS, RFS mainly from the main library to transfer the archive, you can see the normal transmission from the main library archive log, sequence # number is 171,173,172 archive logs are transferred to the standby database.

 Actually, this problem did not cause much concern, think it might be an archive which does not use lead, but found MRP are they not take. So, although the transfer is completed archiving, but less than or application data changes by the library.
 View v $ archive_gap no records, indicating no archive log apply when a problem occurs.

 Let's look at some of the detail information ora problem, suggesting that at the local data file 7 reported ora-01157 error.
Errors in file /u02/dg11g/diag/rdbms/dg11g/DG11G/trace/DG11G_mrp0_6514.trc:
ORA-01157: can not identify / lock data file 7 - see DBWR trace file
ORA-01110: data file 7: '/u02/dg11g/oradata/DG11G/test_new01.dbf'
From the official description of this issue, it seems that the data file is out of the question.
$ Oerr ora 01157
 01157, 00000, "can not 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.
Because this environment is frustrating not know how many times, repeatedly switching, repeated tests, I do not remember what the special operation resulted in this issue. So the question had to be re-analyzed.
 First, look for a moment /u02/dg11g/oradata/DG11G/test_new01.dbf this document, found in the file system does not even exist.
 However, in the data dictionary information, but there is, sql statement is, you can return the corresponding records.
select name, file # from v $ datafile where file # = 7;

From this point of view, probably in the end removed a standby database the data file has occurred. Deleted data file for us how to evaluate it, first of all have to view the main library to view the files in the case of the main library, but in the main library in the data file and table space simply does not exist.
 Thus the problem is somewhat tricky.
If the MRP can fix problems, this problem seems to lead easily solved, if not repaired, this may dataguard not available, and may have to consider a reconstruction of a physical standby database.
 In this regard we take a conservative approach, with a hint try to look at library equipment can start to open read only state.
 But the results of these three operations so I am somewhat confused.
not open, it said it might need to restore, file recovery turned out to be system01.dbf, try to recover until cancel also unsuccessful.
idle> alter database open read only;
 alter database open read only
 *
 ERROR at line 1:
 ORA-10458: standby database requires recovery
 ORA-01196: file 1 is inconsistent due to a failed media recovery session
 ORA-01110: data file 1: '/u02/dg11g/oradata/DG11G/system01.dbf'

 idle> recover database until cancel;
 ORA-00283: recovery session canceled due to errors
 ORA-01610: recovery using the BACKUP CONTROLFILE option must be done

 idle> alter database open read only;
 alter database open read only
 *
 ERROR at line 1:
 ORA-10458: standby database requires recovery
 ORA-01196: file 1 is inconsistent due to a failed media recovery session
 ORA-01110: data file 1: '/u02/dg11g/oradata/DG11G/system01.dbf'

 

For that matter, if there is a sql statement can sharply enough to solve the problem, we have found is still there, thinking to solve the problem is to solve the problem ORA-01157 after repeated attempts, then the MRP dataguard problem can lead edge and the solution.
 Ora-01157 for this problem in the master database data file does not exist, but exist in the data dictionary prepared by the library, we can prepare a library in the data dictionary to solve the problem.
idle> alter database datafile '/u02/dg11g/oradata/DG11G/test_new01.dbf' offline drop;
 Database altered.
Then dataguard logs on the emergence from the turnaround in the background check will go to the issue of this document, just throws a warning. Warning: Datafile 7 (/u02/ora11g/oradata/TEST11G/test_new01.dbf) is offline during full database recovery and will not be recovered
Then MRP to start properly. Background started with the archive data recovery.

alter database datafile '/u02/dg11g/oradata/DG11G/test_new01.dbf' offline drop
 Completed: alter database datafile '/u02/dg11g/oradata/DG11G/test_new01.dbf' offline drop
 Sat Jun 27 23:24:08 2015
 ALTER DATABASE RECOVER managed standby database disconnect from session
 Attempt to start background Managed Standby Recovery process (DG11G)
 Sat Jun 27 23:24:08 2015
 MRP0 started with pid = 25, OS id = 8431
 MRP0: Background Managed Standby Recovery process started (DG11G)
  started logmerger process
 Sat Jun 27 23:24:13 2015
 Managed Standby Recovery not using Real Time Apply
 Parallel Media Recovery started with 2 slaves
 Warning: Datafile 7 (/u02/ora11g/oradata/TEST11G/test_new01.dbf) is offline during full database recovery and will not be recovered
 Waiting for all non-current ORLs to be archived ...
 All non-current ORLs have been archived.
Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_121_880742847.dbf
 Completed: ALTER DATABASE RECOVER managed standby database disconnect from session
 Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_122_880742847.dbf
 Sat Jun 27 23:24:31 2015
 Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_123_880742847.dbf
 Recovery deleting file # 7: '/ u02 / dg11g / oradata / DG11G / test_new01.dbf' from controlfile.
 Deleted file /u02/dg11g/oradata/DG11G/test_new01.dbf
 Recovery dropped tablespace 'TEST_NEW'
 Recovery created file /u02/dg11g/oradata/DG11G/test_new01.dbf
 Successfully added datafile 7 to media recovery
 Datafile # 7: '/u02/dg11g/oradata/DG11G/test_new01.dbf'
 Recovery deleting file # 7: '/ u02 / dg11g / oradata / DG11G / test_new01.dbf' from controlfile.
 Deleted file /u02/dg11g/oradata/DG11G/test_new01.dbf
 Recovery dropped tablespace 'TEST_NEW'
 Recovery deleting file # 7: '/ u02 / dg11g / oradata / DG11G / test_new01.dbf' from controlfile.
 Deleted file /u02/dg11g/oradata/DG11G/test_new01.dbf
 Recovery dropped tablespace 'TEST_NEW'
 Recovery deleting file # 7: '/ u02 / dg11g / oradata / DG11G / test_new01.dbf' from controlfile.
 Deleted file /u02/dg11g/oradata/DG11G/test_new01.dbf
 Recovery dropped tablespace 'TEST_NEW'
Media Recovery Log /u02/dg11g/switchover/DG11G/archivelog/1_124_880742847.dbf
Media Recovery Log /u02/dg11g/switchover/DG11G/archivelog/1_125_880742847.dbf
 Recovery deleting file # 7: '/ u02 / dg11g / oradata / DG11G / test_new01.dbf' from controlfile.
 Deleted file /u02/dg11g/oradata/DG11G/test_new01.dbf
 Recovery dropped tablespace 'TEST_NEW'
Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_126_880742847.dbf
Sat Jun 27 23:24:49 2015
 Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_127_880742847.dbf
 Sat Jun 27 23:25:01 2015
 Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_128_880742847.dbf
 Sat Jun 27 23:25:17 2015
 Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_129_880742847.dbf
 Sat Jun 27 23:25:29 2015

More interesting is to look at the log can see that the data files are repeatedly created deleted many times. Eventually drop to terminate.
 Then I started to do a lot of archive data recovered.

Sat Jun 27 23:28:30 2015
 Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_172_880742847.dbf
 Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_173_880742847.dbf
 Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_174_880742847.dbf
 Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_175_880742847.dbf
 Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_176_880742847.dbf
 Sat Jun 27 23:28:40 2015
 Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_177_880742847.dbf
 Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_178_880742847.dbf
 Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_179_880742847.dbf
 Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_180_880742847.dbf
 Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_181_880742847.dbf
 Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_182_880742847.dbf
 Sat Jun 27 23:28:52 2015
 Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_183_880742847.dbf
 Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_184_880742847.dbf

In the main gallery view, redo the serial number 185, prepared by the library's serial number is 184.
sys @ TEST11G> select sequence #, status from v $ log;
  SEQUENCE # STATUS
 ---------- ----------------
        184 INACTIVE
        185 CURRENT
        183 INACTIVE


Background check process in the standby database in case, you can see the MRP has been recorded in the book.
idle> select process, status, sequence # from v $ managed_standby;
 PROCESS STATUS SEQUENCE #
 --------- ------------ ----------
 ARCH CONNECTED 0
 ARCH CONNECTED 0
 ARCH CONNECTED 0
 ARCH CONNECTED 0
MRP0 WAIT_FOR_LOG 186
     
         
       
         
  More:      
 
- Github inventory objects Algorithm (Linux)
- Fedora 20 users install the Mate 1.8 desktop (Linux)
- MySQL enabled SSD storage (Database)
- How to use Linux iptables tool for network sharing (Linux)
- Linux distributed message queue RocketMQ deployment and monitoring - Dual Master (Server)
- Fatal NI connect error 12170 error in Alert Log (Database)
- Python calls the API interface in several ways (Programming)
- Nonstandard IMP-00010 error processing one case (Database)
- In-depth understanding of PHP ini configuration (Server)
- Linux cd command Detailed (Linux)
- Deploy Apache Spark cluster environment in Ubuntu (Server)
- Install JDK 1.7 + Eclipse in CentOS 6.4 in (Linux)
- You can not ignore the seven Git tips (Linux)
- ld.so.conf.d profile (Linux)
- Linux Log File Browser --logrotate (Linux)
- Camouflage Nginx Web server version to prevent invasion (Linux)
- How to use the command line to obtain Freely RSS source on Linux (Linux)
- Performance comparison Fibonacci recursive and non-recursive (Programming)
- How to Install Suricata IDS on a Linux system (Server)
- Linux NFS service fixed ports and firewall configuration (Linux)
     
           
     
  CopyRight 2002-2016 newfreesoft.com, All Rights Reserved.