Shulou(Shulou.com)05/31 Report--

This article mainly introduces "os thread startup waiting for fault analysis in oracle". In daily operation, I believe many people have doubts about os thread startup waiting for fault analysis in oracle. The editor consulted all kinds of data and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts of "os thread startup waiting for fault analysis in oracle". Next, please follow the editor to study!

This is a fault that has been encountered before and has plagued many of us for a long time. The reason why the problem can not be solved for a long time is due to the vagueness of the concept. Os thread startup is a wait for Concurrency in an oracle wait event, and there are actually very few explanations related to it. From a variety of fault phenomena and literal meaning, the parallel allocation is to start the application process to os, but in the normal system, this action is very fast. In our high-pressure database environment, os has response problems, which stimulates the waiting for the event. Recently, in order to sort out my previous knowledge, I will record it.

The following is an excerpt from the explanation of the network:

Know more about "os thread startup"'os thread startup' takes significant amount of time in 'create index parallel'.All slaves are allocated one by one in serial.SQL tracing on foreground, there is one' os thread startup' wait per slave, each wait takes 100ms. -> Mayneed investigationWhen there are 512 slaves,'os thread startup' wait take 50 seconds before the slaves start to do any job.Resolution is to set * .parallel_min_servers=512 to pre-allocated 512 slaves per instance duirng instancestartup, or to run PCIX twice and ignore the first run

[failure phenomenon]

1. There are os thread startup waits in the database, accompanied by a large number of DFS lock handle,log file sync,latch free waiting to accumulate.

two。 First of all, there is an exception waiting for the node database to be blocked to a certain extent, the system resources are consumed massively, and the host hang lives.

3. Another node database is affected by the previous node database, there are a large number of gc waiting events, but abnormal waiting accumulates to a certain extent, there is DFS lock handle waiting, a large amount of system resources are consumed, the host hang lives.

[analysis and processing ideas]

1. Database wait:

From the dba_hist_active_sess_history analysis, the database appeared os thread startup, and then began to cause a large number of log file sync,latch free waiting and DFS lock handle blocking. And the source of blockage is os thread startup.

Excerpt:

Node 1 summarizes by wait events according to the point in time:

28-JUL-16 04.22.16.187 PM PX Deq: Slave Session Stats 1

28-JUL-16 04.22.16.187 PM control file sequential read 1

28-JUL-16 04.22.16.187 PM os thread startup 1

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.