In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-31 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >
Share
Shulou(Shulou.com)06/01 Report--
Note 1:
TypicallyDBWR has to free up some buffers when you want to read something from the disk.During this process there are chances that you will be waiting for your local buffer (i.e blocks dirtied/invalidated by your session) to be written to disk. Duringthis time the waits are shown as local write waits.
When you want to read data from this disk, DBDW has to empty some buffer. In the process, you may encounter waiting for your local buffer to write to disk (such as dirty blocks, invalid blocks).
Note 2:
Basically 'localwrite' wait happens (as the name indicates) when the session is waiting for itslocal (means writes pending because of its own operation) write operation.This could happen typically if the underlying disc has some serious problems (one of the member disk crash in RAID-05-for example, or a controllerfailure). That is why I might have said 'you never see this wait in the databases. You may see this during (rarely) Truncating a largetable while most of the buffers of that table in cache. During TRUNCATEs thesession has to a local checkpoint and during this process, thesession may waitfor 'local write' wait.
Basically 'localwrite' wait means that the session is waiting for its own write operation. It happens when there is a serious problem with the disk (such as a disk crash in RAID 5, or a disk controller error), which rarely happens in a normal system. When TRUNCATE a large table and the table is in the cache, the session must perform a local checkpoint, which will wait for local session wait.
In the MOS documentation:
Truncates Taking Too Long... [ID334822.1]
The waiting event was mentioned.
1 Cause:
Processes that involve temporary tablesbeing truncated and repopulated in multiple, concurrent batch streams maypresent this situation.
This can happen when it comes to temporary tables being truncate and repopulate in the form of concurrent multiplexing.
The underlying problem is we have to writethe object's dirty buffers to disk prior to actually truncating or dropping theobject. This ensures instance recoverability and avoids a stuck recovery. Itseems at first glance perfectly reasonable to simply truncate a temporarytable, then repopulate for another usage. And then to do the temporarypoplulate/truncate operations in concurrent batches to increase throughput.
However, in reality the concurrenttruncates get bogged down as dbwr gets busy flushing those dirty block buffersfrom the buffer cache. You will see huge CI enqueue waits. The multipletruncate operations in concurrent streams absolutely kill throughput. This isspecially critical with large buffers.
2 Solution:
In9.2.0.5 and higher, it may also help to make sure a "temp" table that is frequently truncated have storage defined so that itoccupies one extent. But this workaround is only available as long as theextent is no more than 50% the size of the buffer cache. In non-RACenvironments the table still has to be smaller than 50% of the buffercache, but it allows the table to have up to 5 extents before falling backto the old algorithm.
Another example (from internet):
A data warehouse system, which appears in the AWR report with a high waiting time of LOCAL WRITE WAIT and Eq:RO Fast Object Reuse. The parsing-related statement is TRUNCATE, an intermediate table. The meaning of the RO queue can be retrieved from the V$LOCK_TYPE.
SQL > SELECT DESCRIPTION FROM V$LOCK_TYPE WHERE TYPE='RO'
DESCRIPTION
Coordinates flushing of multiple objects
Literally means to coordinate the emptying of multiple objects. Analysis and application, the statement occurs in the ETL process, the main steps are to fill the intermediate table, modify the intermediate table, TRUNCATE intermediate table. There are more processes of this process in the scheduler.
In TRUNCATE and DROP TABLE, ORACLE must invalidate or refresh all the data blocks of the object in DATA BUFFER to disk. The step is to request a RO queue lock at this time, find the block of the object in the buffer, and invalidate it or refresh it to disk, and then release the RO lock. If multiple processes TRUNCATE concurrently, there will be competition on the RO queue, such as waiting for the event Eq: RO fast object reuse. If TRUNCATE waits for related blocks to be flushed to disk, it is represented as waiting time local write wait.
There are two reasons for this problem: 1 I TRUNCATE O slow 2 parallel.
This problem can not be solved by increasing the BUFFER CACHE. The larger the BUFFER CACHE, the longer it takes to search for related data blocks.
The method of treatment
1 you can use a tablespace with a non-default block size for this type of intermediate table and set buffers of different block sizes in CACHE BUFFER. Reduce the time to search related data blocks and reduce competition.
2 to ensure the efficiency of DBWn writing.
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.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.