DGora-1578 error caused by notopenforceloggning

The DGora-1578 error caused by notopenforceloggning was reported the day before yesterday, the deployment implementation company xx production center input database a set of DG, but in the past, one of the primary was a test machine before I N. I remember that I installed the 11.2g03 minor version in the form of loneliness. There is nothing to do with this. It may be some time ago, because the project

Due to not open force loggning caused by DG ora-1578 error the day before yesterday, the deployment implementation company xx production center entry library a set of DG, but before, here, one of the primary is a test machine before I was N. I remember that I installed version 11.2g 03 in the form of loneliness. There is nothing to do with this. It may be some time ago, because the project

DG ora-1578 error caused by not open force loggning

The day before yesterday, the deployment and implementation company xx production center entered a set of DG databases, but before that, one of the primary was a test machine before I N. I remember that I installed version 11.2g 03 in the form of loneliness. This is nothing. Some time ago, because the project and department manager Suddenly imported the formal data, it became the company's official database for production. For this reason, I am so excited that I will not talk about it in advance. In this way, my test machine became a production machine, and I forgot what operations the main machine was doing because N was just a slave machine.

I went to work on Monday. I didn't remotely check the performance of this xx production center database and set anything because of other issues that need to be handled. This is also the case during the morning peak.

In the afternoon, suddenly, RTX blinks the busy avatar, Y's. Click it, the testing department, the quality check department, the ETL department, and the xx data production department are shouting. How can we not connect to it? I also hurry to remotely look at this xx server, Y, ORA-04031 error?

Errors in file/u01/app/oracle/diag/rdbms/xxxdb_p/gtadb/trace/gtadb_ora_29163.trc (incident = 4220 ):
ORA-04031: unable to allocate 56 bytes of shared memory ("streams pool", "unknown object", "streams pool", "fixed allocation callback ")
Incident details in:/u01/app/oracle/diag/rdbms/xxxdb_p/gtadb/incident/incdir_4220/gtadb_ora_29163_i421_trc
Thu Dec 26 18:29:08 2013
Dumping diagnostic data in directory = [cdmp_20131226182908], requested by (instance = 1, osid = 29163), summary = [incident = 4220].
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Error ORA-4031 occured during Initialization of Bufq KUPC $ C_1_20131225143407
Starting background process QMNC
Thu Dec 26 18:29:09 2013
QMNC started with pid = 37, OS id = 29200

Check how much memory is allocated to the database:

NAME TYPE VALUE
-----------------------------------------------------------------------------
Lock_sga boolean FALSE
Pre_page_sga boolean FALSE
Sga_max_size big integer 512 M
Sga_target big integer 512 M

NAME TYPE VALUE
-----------------------------------------------------------------------------
Pga_aggregate_target big integer 5904 M

Check out dev/shm shared memory:

Tmpfs 9.8G 0 9.8G 0%/dev/shm

Then the system looks at the physical memory and swap:

Total used free shared buffers cached
Mem: 12299044 12233492 65552 0 15948 11230976
-/+ Buffers/cache: 986568 11312476
Swap: 25165812 76372 25089440

Top-13:28:07 up 1 day, 5 users, load average: 14.78, 16.62, 17.17
Task: 314 total, 8 running, 306 sleeping, 0 stopped, 0 zombie
Cpu (s): 64.5% us, 1.7% sy, 0.0% ni, 8.3% id, 25.4% wa, 0.0% hi, 0.0% si, 0.0% st
Mem: 12299044 k total, 12230484 k used, 68560 k free, 16032 k buffers
Swap: 25165812 k total, 76372 k used, 25089440 k free, 11230472 k cached

CPU: Cpu (s): 97.8% us, 2.1% sy, 0.0% ni, 0.0% id, 0.1% wa, 0.0% hi, 0.0% si, 0.0% st I also used:

Seeing this situation, I knew that I could not log on through the system login, or Y. A data synchronization software of the company was originally in real-time data synchronization, And the cpu was large, this synchronization software, although also through the oracle log analysis of the data, through its own proprietary column value changes to achieve data synchronization, but also a large amount of select count (*) tab operation.

Temporarily using alter system flush shared_pool; or not! Still cannot log on! Finally, killing unnecessary service processes does not work. In the end, I hate to stop listening. Manage login, or not, by executing alter system flush shared_pool; Make sure that this ora-04031 is wrong. Finally, I killed the oracle process and shut down the database! (I'm in a bad mood. What should I do if I don't get started? Fortunately, on the weekend evening, I have prepared control files and archive them ).

Adjust the memory size, restart it, and connect to OK. Despite a small complaint, the department manager. Nothing else! The connection is normal and can be started. The RTX notification is available. Check the time. It takes only 5 minutes, without causing a major impact.

The primay cpu is very large. The department manager needs to deploy a standby, read/write splitting, and share the load.

After building the database, configure the database according to those memories and view the basic information: Archive, password, parameter file, listener test, and data file, log Files, backups, copies, duplicate, view slave database processes, modes, and modify logs. OK! Check the trace file. Everything works.

The trace log is suddenly taken into consideration: Why is the block broken? The newly run dg, the log is as follows:

Thu Dec 26 20:20:22 2013
Errors in file/u01/app/oracle/diag/rdbms/gtadb_s/gtadb2/trace/gtadb2_ora_16302.trc (incident = 24222 ):
A ORA-01578: ORACLE? Version .?..?. (?. Huan ?? 18 ,?.. 399904)
ORA-01110 :? Version .?. Huan 18: '/u01/app/oracle/datafile/gta_input_data_07.dbf'
ORA-26040 :? Version .?.. Inter-. NOLOGGING ?.」?. Pouring?
Thu Dec 26 20:20:25 2013
Errors in file/u01/app/oracle/diag/rdbms/gtadb_s/gtadb2/trace/gtadb2_ora_16306.trc (incident = 24223 ):
A ORA-01578: ORACLE? Version .?..?. (?. Huan ?? 17 ,?.. 410498)
ORA-01110 :? Version .?. Huan 17: '/u01/app/oracle/datafile/gta_input_data_06.dbf'
ORA-26040 :? Version .?.. Inter-. NOLOGGING ?.」?. Pouring?
Thu Dec 26 20:21:05 2013
Sweep [inc] [28066]: completed
Sweep [inc] [28065]: completed
Sweep [inc] [24223]: completed
Sweep [inc] [24222]: completed

Let's take a look at the table at. This bad block is probably developed by the developer. When creating a table, it is estimated that the index is caused by nologging. No matter what, go home and say, this time is quite tiring, make up your sleep first!

Go to work the next day and check the trace file again:

Thu Dec 26 23:00:02 2013
Errors in file/u01/app/oracle/diag/rdbms/gtadb_s/gtadb2/trace/gtadb2_ora_20463.trc (incident = 24577 ):
A ORA-01578: ORACLE? Version .?..?. (?. Huan ?? 17 ,?.. 410512)
ORA-01110 :? Version .?. Huan 17: '/u01/app/oracle/datafile/gta_input_data_06.dbf'
ORA-26040 :? Version .?.. Inter-. NOLOGGING ?.」?. Pouring?
Thu Dec 26 23:00:05 2013
Sweep [inc] [24577]: completed
Thu Dec 26 23:00:17 2013
DDE: Problem Key 'ora 1578 'was completely flood controlled (0x6)
Further messages for this problem key will be suppressed for up to 10 minutes
Thu Dec 26 23:00:24 2013
DDE: Problem Key 'ora 1578 'was completely flood controlled (0x6)
Further messages for this problem key will be suppressed for up to 10 minutes
Thu Dec 26 23:16:02 2013

Baidu reported the following error: DDE: Problem Key 'ora 1578 'was completely flood controlled (0x6), which is similar to speculation, so .....

Start:

No row is displayed through v $ archived_gap, v $ recovery_log, and v $ recover_file.

Perform a health check using dbv file,

SQL> l
1 SELECT SEGMENT_TYPE, OWNER | '.' | SEGMENT_NAME
2 FROM DBA_EXTENTS
3 WHERE FILE_ID = 17 AND 410512 BETWEEN BLOCK_ID
4 * AND BLOCK_ID + BLOCKS-1

SEGMENT_TYPE | '.' | SEGMENT_NAME
--------------------------------------------------------------------------------
INDEX. IUM46669939

It seems that it turned out to be an index, which is easy to handle. At the same time, I thought, do I forget forcelogging? When creating dg ??

So I did not hesitate to read v $ database! So I don't hesitate to execute alter database force logging on primary!

You can use user_indexes to check which table the index belongs:

SQL> select index_name, index_type, TABLE_OWNER, table_name, logging, TABLESPACE_NAME from user_indexes where index_name = 'ium46669939 ';

INDEX_NAME INDEX_TYPE TABLE_OWNER TABLE_NAME LOG TABLESPACE_NAME
------------------------------------------------------------------------------------------------------------------------------------------------------
IUM46669939 normal input TBL_ZZ_ I _PERF YES GTA_INPUT_DATA

Finally, through communication, we can see that this table is basically not operated in the morning, so we do not hesitate to rebuild indexes, force switch logs, view slave databases, OK! Solve the problem.

Of course, if it is a control file or something else, it will be more different! Regardless of bbed, aul, or dul, I think that backup is more important for DBAs!

DBAs must keep the two files up-to-date: A good resume and a recent backup! -- I think it's awesome!