Shulou(Shulou.com)06/01 Report--

Recently, I helped some friends deal with some Oracle problems, and also found some potential problems, which can be summed up as a reference. In order to ensure the sensitivity of the information, the description of the problem may not be consistent with the real situation, but the way the problem is handled is true.

Problem 1:Oracle repository failed to start

The problem 2:Oracle repository cannot be synchronized

Question 3: after the data file is added to the main database, the slave database MRP exits.

Problem 4: standby database data cannot be synchronized

Problem 1:Oracle repository failed to start

There is a database repository that cannot be started, which sounds like an interesting question. This is an 11g database. In fact, you can set the slave database to read only, and then open the log application. After the status changes to read only with apply, it will be fine, but there is something special about the real situation. I looked at the configuration in the environment and found that the master-slave replication relationship was gone, but although the replication relationship was gone, it was feasible to make the database read-only. As a result, I tried it all around, and finally found that it was this classmate who changed the files in the system tablespace.

Problem 2: the standby database cannot synchronize data

When I went to follow up later, I found that the problem was much better than before, and the standby database could be started normally, but now the problem is that the replication of master-slave data still failed. From the archiving parameters, we can see that the replication relationship exists, and there is no problem with network configuration. In the face of such a strange problem, my way of dealing with it is very direct. There must be some details that we have ignored somewhere. How can you quickly locate and troubleshoot the problem? DG Broker is an artifact. You can easily create a configuration for the master / slave database without any additional configuration. As a result, the reason for the problem is that the db_unique_name of the slave database is the same as that of the main database in less than 10 minutes. After modification, the problem is solved immediately. So the cause of the problem is very simple, but if you can find it quickly, there are some skills that will get twice the result with half the effort.

Question 3: after the data file is added to the main database, the slave database MRP exits.

The third problem is quite special, because there is not enough tablespace in the main database, which leads to data write blocking. After expanding the tablespace, we found that the problem came. The MRP of the standby database exited abnormally. About the abnormal exit of MRP caused by the data file, I was impressed that it was in 10.2.0.4. Drop datafile after add datafile will cause MRP exception. To be exact, this is a bug, but the problem encountered here is in 11g. It's just a data file.

The mistake is something like this:

/ opt/oradata/u01/app/oracle/diag/rdbms/xxxxx_dg/xxxx/trace/xxxx_dbw0_9328.trc:

ORA-01186: file 6 failed verification tests

ORA-01157: cannot identify/lock data file 6-see DBWR trace file

ORA-01111: name for data file 6 is unknown-rename to correct file

ORA-01110: data file 6:'/ U01 *

This No. 6 data file is newly added. After a simple analysis, you will find that it is another pit. The main parameter standby_file_management is caused by manual. You can modify the path of this file, and then turn on file management to auto. Finally, open the log application.

Alterdatabasecreatedatafile

'/ U01Applink oracleUniverse productUniverse 11.2.0UniUnixxxxxxxx'

Altersystem setstandby_file_management=auto

Alterdatabaserecover managed standby databasedisconnect fromsession using currentlogfile

Problem 4: standby database data cannot be synchronized.

This problem has the same effect as question 2, but the cause of the problem is very different. The willingness of this problem lies in the setting of flashback, that is, the archive file cannot be created properly, not because of insufficient space at the system level, but because of the insufficient size of the flashback area.

Therefore, the causes and phenomena of the problem can be summarized into four suggestions:

DG Broker is recommended for library building and synchronization relationship maintenance. Their difference is similar to automatic and manual. Why do you have to block manually if you can block automatically?

It is recommended that the file path of the repository should be consistent. It is recommended that standby_file_management be auto.

Set the flashback area of the primary and standby libraries to a large range of values as far as possible to ensure that the writing of data will not be blocked due to logical restrictions.

Omni-directional, fine-grained inspection to solve the problem in the initial stage.

Simply talking about the above problems, in fact, it is not difficult, but the real environment, the real problems, and you know the reasons for the result analysis are two different things. What's more, treat other people's problems as if they were your own, and others will take you seriously.

In principle, Baidu Google does not have an answer to the question, you can jeanrock@126.com to communicate, some questions may not be answered or because of time, there will be delays, please understand, welcome technical exchanges.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.