Dưới đây là một số sự kiện đợi Oracle phổ biến mà mọi người nên biết.
Chờ sự kiện
Bạn có thể tìm thấy phiên sự kiện nào đang đợi nó bằng cách làm theo truy vấn
select event from V$session_wait where sid=&1
Tôi đang cố gắng giải thích một số sự kiện chờ phổ biến của Oracle, nguyên nhân và cách giải quyết
enqueue
Quá trình này đang chờ trên một enqueue oracle (một khóa bạn có thể thấy trong v $ lock). Điều này thường xảy ra khi một người dùng đang cố gắng cập nhật một hàng trong bảng hiện đang được cập nhật bởi một người dùng khác. Các trình chặn có thể được tìm ra bằng cách sử dụng truy vấn sau
select * from dba_waiters
mã pin bộ nhớ cache thư viện
Quá trình muốn ghim một đối tượng trong bộ nhớ trong bộ đệm thư viện để kiểm tra, đảm bảo không có quá trình nào khác có thể cập nhật đối tượng cùng một lúc. Điều này xảy ra khi bạn đang biên dịch hoặc phân tích cú pháp một đối tượng PL / SQL hoặc một dạng xem. Tránh biên dịch đối tượng PL / SQL hoặc chế độ xem oracle ở thời gian sử dụng cao để tránh sự kiện chờ đợi này
khóa tải bộ đệm thư viện
Quá trình này đang chờ cơ hội tải một đối tượng hoặc một phần của đối tượng vào bộ đệm thư viện. (Chỉ một quy trình có thể tải một đối tượng hoặc một phần của đối tượng tại một thời điểm.)
chốt miễn phí
Quá trình này đang đợi một chốt được giữ bởi một quá trình khác. (Sự kiện chờ đợi này không áp dụng cho các quy trình đang quay trong khi chờ chốt; khi một quy trình đang quay, nó sẽ không chờ.). Chốt là thiết bị tuần tự hóa nhẹ được sử dụng để điều phối quyền truy cập của nhiều người dùng vào cấu trúc dữ liệu, đối tượng được chia sẻ, và tệp.
Chốt là khóa được thiết kế để giữ trong khoảng thời gian cực ngắn, chẳng hạn như thời gian cần thiết để sửa đổi cấu trúc dữ liệu trong bộ nhớ. Chúng được sử dụng để bảo vệ một số cấu trúc bộ nhớ nhất định, chẳng hạn như bộ đệm đệm khối cơ sở dữ liệu hoặc bộ đệm thư viện trong nhóm chia sẻ.
Các chốt của Oracle thường được yêu cầu nội bộ ở chế độ "sẵn sàng chờ". Điều này có nghĩa là nếu chốt không có sẵn, phiên yêu cầu sẽ ngủ trong một khoảng thời gian ngắn và thử hoạt động lại sau đó. Các chốt khác có thể được yêu cầu ở chế độ 'ngay lập tức', có khái niệm tương tự như CHỌN ĐỂ CẬP NHẬT KHÔNG CHỜ ĐỢI, có nghĩa là quá trình sẽ thực hiện một việc khác, chẳng hạn như cố gắng lấy một chốt anh chị em tương đương có thể miễn phí, chứ không phải là ngồi và đợi cho đến khi có chốt này. Vì nhiều yêu cầu có thể đang chờ chốt cùng một lúc, nên bạn có thể thấy một số quy trình chờ lâu hơn các quy trình khác.
Các chốt được chỉ định khá ngẫu nhiên, dựa trên sự may mắn của lượt rút thăm, nếu bạn muốn. Phiên nào yêu cầu chốt ngay sau khi phát hành sẽ lấy được. Không có hàng người phục vụ chốt chỉ là một đám đông người phục vụ liên tục thử lại.
đệm chờ bận
Quá trình này muốn truy cập một khối dữ liệu hiện không có trong bộ nhớ, nhưng một quá trình khác đã đưa ra yêu cầu I / O để đọc khối đó vào bộ nhớ. (Quá trình này đang đợi quá trình khác kết thúc để đưa khối vào bộ nhớ.). Các khối nóng có thể được tìm thấy bằng cách sử dụng chế độ xem V $ BH
tệp db đã đọc rải rác
Quá trình đã đưa ra yêu cầu I / O để đọc một loạt các khối liền nhau từ tệp dữ liệu vào bộ đệm ẩn bộ đệm và đang chờ thao tác hoàn tất. Điều này thường xảy ra trong quá trình quét toàn bộ bảng hoặc quét toàn bộ chỉ mục.
Chúng ta nên kiểm tra xem truy vấn có nên sử dụng quét toàn bộ bảng hay không. Đảm bảo số liệu thống kê của trình tối ưu hóa Oracle được cập nhật. Sử dụng tính năng Cắt tỉa phân vùng để giảm số lượng khối được truy cập
Nếu truy vấn đang chạy tốt trong một thời gian đột nhiên đồng hồ nhiều thời gian trên sự kiện đọc phân tán tệp db và không có thay đổi mã, bạn có thể muốn kiểm tra xem liệu một hoặc nhiều chỉ mục đã bị loại bỏ hoặc trở nên không sử dụng được.
đọc tuần tự tệp db
Quy trình đã đưa ra yêu cầu I / O để đọc một khối từ tệp dữ liệu vào bộ đệm ẩn bộ đệm và đang chờ thao tác hoàn tất. Điều này thường xảy ra trong quá trình tra cứu chỉ mục hoặc tìm nạp từ bảng tiên tri bằng ROWID khi khối dữ liệu bắt buộc chưa có trong bộ nhớ. Đừng để bị nhầm lẫn bởi cái tên khó hiểu của sự kiện chờ đợi này!
Chúng ta nên kiểm tra xem các chỉ mục phù hợp có đang được sử dụng hay không. Chỉ mục sai có thể làm cho truy vấn hoạt động kém. Hãy đảm bảo số liệu thống kê của trình tối ưu hóa được cập nhật.
đọc song song tệp db
Quá trình đã đưa ra nhiều yêu cầu I / O song song để đọc các khối từ tệp dữ liệu vào bộ nhớ và đang đợi tất cả các yêu cầu hoàn tất. Tài liệu cho biết sự kiện chờ đợi này chỉ xảy ra trong quá trình khôi phục, nhưng trên thực tế, nó cũng xảy ra trong hoạt động thường xuyên khi một quá trình gộp nhiều yêu cầu I / O khối đơn lẻ lại với nhau và phát hành chúng song song. (Bất chấp tên gọi, bạn sẽ không thấy sự kiện chờ này trong khi truy vấn song song hoặc DML song song. Trong những trường hợp đó, các sự kiện chờ với PX trong tên của chúng sẽ xảy ra.)
ghi song song tệp db
Quá trình, thường là DBWR, đã đưa ra nhiều yêu cầu I / O song song để ghi các khối bẩn từ bộ đệm ẩn vào đĩa và đang đợi tất cả các yêu cầu hoàn tất.
đọc đường dẫn trực tiếp, ghi đường dẫn trực tiếp
Quá trình đã đưa ra các yêu cầu I / O không đồng bộ bỏ qua bộ đệm đệm và đang đợi chúng hoàn tất. Những sự kiện chờ đợi này thường liên quan đến việc sắp xếp các phân đoạn.
Các câu lệnh SQL với các hàm yêu cầu sắp xếp, chẳng hạn như ORDER BY, GROUP BY, UNION, DISTINCT và ROLLUP, sắp xếp ghi chạy vào vùng bảng tạm thời khi kích thước đầu vào lớn hơn vùng làm việc trong PGA
Đảm bảo số liệu thống kê của trình tối ưu hóa được cập nhật dữ liệu và truy vấn đang sử dụng bảng điều khiển phù hợp. Kiểm tra xem liệu các cột của chỉ mục tổng hợp có thể được sắp xếp lại để phù hợp với mệnh đề ORDER BY hay không để tránh sắp xếp hoàn toàn.
Đảm bảo giá trị thích hợp PGA_AGGREGATE_TARGET được đặt. Nếu có thể, hãy sử dụng UNION ALL thay vì UNION.
Chốt nhóm chia sẻ
Chốt nhóm chia sẻ được sử dụng để bảo vệ các hoạt động quan trọng khi cấp phát và giải phóng bộ nhớ trong nhóm chia sẻ. Nội dung cho nhóm chia sẻ và chốt bộ nhớ cache của thư viện chủ yếu là do quá trình phân tích cú pháp khó quá mức. Phân tích cú pháp cứng áp dụng cho các con trỏ và con trỏ mới đã cũ và phải được thực thi lại
Chi phí phân tích cú pháp một câu lệnh SQL mới đắt cả về yêu cầu CPU và số lần bộ đệm thư viện và nhóm chia sẻ chốt có thể cần được mua và phát hành.
Loại bỏ SQL theo nghĩa đen cũng hữu ích để tránh chốt nhóm chia sẻ
kiểm soát đọc tuần tự tệp
Quá trình này đang đợi các khối được đọc từ một tệp điều khiển. Điều này thường xảy ra
- tạo bản sao lưu các tệp điều khiển
- chia sẻ thông tin (giữa các phiên bản) từ tệp điều khiển
- đọc các khối khác từ các tệp điều khiển
- đọc khối tiêu đề
Nếu đây là sự kiện chờ đợi lớn, điều đó có nghĩa là vị trí tệp điều khiển cần được thay đổi thành vị trí đĩa nhanh hơn
điều khiển ghi song song tệp
Quy trình đã đưa ra nhiều yêu cầu I / O song song để ghi khối vào tất cả các tệp điều khiển và đang đợi tất cả quá trình ghi hoàn tất.
không gian đệm nhật ký
Quá trình này đang đợi dung lượng khả dụng trong bộ đệm nhật ký (Dung lượng chỉ khả dụng sau khi LGWR đã ghi nội dung hiện tại của bộ đệm nhật ký vào đĩa.) Điều này thường xảy ra khi các ứng dụng tạo ra quá trình làm lại nhanh hơn LGWR có thể ghi nó vào đĩa.
Điều này cũng có thể xảy ra nếu I / O to disk nơi chứa nhật ký làm lại chậm
Không nên chờ đợi không gian bộ đệm nhật ký như vậy trong cơ sở dữ liệu. Hãy cân nhắc làm cho bộ đệm nhật ký lớn hơn nếu nó nhỏ hoặc xem xét di chuyển các tệp nhật ký sang các đĩa nhanh hơn, chẳng hạn như đĩa sọc.
Select event, total_waits, total_timeouts, time_waited, average_wait
from v$system_event
where event = 'log buffer space';
Select sid, event, seconds_in_wait, state
from v$session_wait
where event = 'log buffer space';
Select name, value
from v$sysstat
where name in ('redo log space requests');
Pct_buff_alloc_retries phải bằng 0 hoặc nhỏ hơn 0,01 (<1%). Nếu nó lớn hơn, hãy xem xét việc làm cho bộ đệm nhật ký lớn hơn. Nếu lớn hơn, hãy cân nhắc chuyển các tệp nhật ký sang các đĩa nhanh hơn, chẳng hạn như đĩa sọc.
Select v1.value as redo_buff_alloc_retries, v2.value as redo_entries, trunc(v1.value/v2.value,4) as pct_buff_alloc_retries from v$sysstat v1, v$sysstat v2 where v1.name = 'redo buffer allocation retries' and v2.name = 'redo entries';
đọc tuần tự tệp nhật ký
Quá trình này đang đợi các khối được đọc từ đăng nhập làm lại trực tuyến vào bộ nhớ. Điều này chủ yếu xảy ra khi khởi động phiên bản và khi quá trình ARCH lưu trữ các bản ghi làm lại trực tuyến đầy đủ.
ghi song song tệp nhật ký
Quá trình này đang đợi các khối được ghi cho tất cả các thành viên đăng nhập làm lại trực tuyến trong một nhóm. LGWR thường là quá trình duy nhất để xem sự kiện chờ đợi này. Nó sẽ đợi cho đến khi tất cả các khối được viết cho tất cả các thành viên.
đồng bộ hóa tệp nhật ký
Quá trình này đang đợi LGWR hoàn tất việc xóa bộ đệm nhật ký vào đĩa. Điều này xảy ra khi người dùng thực hiện một giao dịch. (Một giao dịch không được coi là đã cam kết cho đến khi tất cả các thao tác làm lại để khôi phục giao dịch đã được ghi thành công vào đĩa.)
Quá trình LGWR chậm có thể dẫn đến các lần chờ đồng bộ hóa tệp nhật ký khiến người dùng gặp phải thời gian chờ trong khi cam kết hoặc khôi phục. Các sự kiện chờ đồng bộ hóa tệp nhật ký và ghi song song tệp nhật ký có liên quan với nhau và phải được xử lý đồng thời.
Chúng tôi phải cố gắng phân bổ các bản ghi làm lại vào đĩa hiệu suất cao (đĩa trạng thái rắn). Ngoài ra, chúng ta nên cố gắng giảm tải cho LGWR bằng cách giảm các cam kết trong các ứng dụng.
Phần sao lưu nóng thủ công cũng có thể gây ra căng thẳng trong hệ thống bằng cách tạo ra nhiều thứ phải làm lại, Vì vậy, hãy tránh điều đó trong thời gian cao điểm
Đôi khi LGWR đang thiếu tài nguyên CPU. Nếu máy chủ rất bận, thì LGWR cũng có thể thiếu CPU. Điều này sẽ dẫn đến phản hồi chậm hơn từ LGWR, tăng thời gian chờ ‘đồng bộ hóa tệp nhật ký’. Rốt cuộc, các cuộc gọi hệ thống và lệnh gọi I / O này phải sử dụng CPU. Trong trường hợp này, 'đồng bộ hóa tệp nhật ký' là một triệu chứng phụ và việc giải quyết nguyên nhân gốc rễ dẫn đến việc sử dụng CPU cao sẽ làm giảm thời gian chờ "đồng bộ hóa tệp nhật ký".
Do vấn đề hết bộ nhớ, LGWR cũng có thể bị loại bỏ. Điều này cũng có thể dẫn đến phản hồi chậm hơn từ LGWR.
hoàn tác phần mở rộng về phân đoạn
Phiên đang chờ một phân đoạn hoàn tác được kéo dài hoặc thu hẹp.
viết các lần đợi hoàn chỉnh
Phiên đang đợi một bộ đệm được yêu cầu được ghi vào đĩa; bộ đệm không thể được sử dụng trong khi nó đang được ghi.
Latch:chuỗi bộ đệm bộ nhớ cache
Các chốt của chuỗi bộ đệm bộ đệm được sử dụng để bảo vệ danh sách bộ đệm trong bộ đệm đệm. Các chốt này được sử dụng khi tìm kiếm, thêm hoặc xóa bộ đệm khỏi bộ đệm đệm.
Các khối trong bộ đệm ẩn được đặt trên danh sách được liên kết (chuỗi bộ đệm bộ đệm) treo trên bảng băm. Chuỗi băm mà một khối được đặt dựa trên DBA và CLASS của khối. Mỗi chuỗi băm được bảo vệ bởi một chốt con duy nhất. Các quy trình cần có chốt liên quan để cho phép chúng quét chuỗi băm để tìm bộ đệm để danh sách được liên kết không thay đổi bên dưới chúng.
Sự tranh cãi về chốt này thường có nghĩa là có một khối đang bị tranh chấp lớn (được gọi là khối nóng).
Để xác định chuỗi bộ đệm được truy cập nhiều và do đó là khối cạnh tranh, hãy xem thống kê chốt cho các chốt của chuỗi bộ đệm bộ đệm bằng cách sử dụng chế độ xem V $ LATCH_CHILDREN. Nếu có một bộ đệm bộ đệm cụ thể chuỗi chốt con có nhiều NHẬN, BỎ LỠ và SLEEPS hơn khi so sánh với các chốt con khác, thì đây là đối tượng tranh cử cho chốt con.
Chốt này có địa chỉ bộ nhớ, được xác định bởi cột ADDR.
SELECT addr, sleeps FROM v$latch_children c, v$latchname n WHERE n.name='cache buffers chains' and c.latch#=n.latch# and sleeps > 100 ORDER BY sleeps /
Sử dụng giá trị trong cột ADDR được kết hợp với dạng xem V $ BH để xác định các khối được bảo vệ bởi chốt này. Ví dụ:với địa chỉ (V $ LATCH_CHILDREN.ADDR) của một chốt có nhiều tranh chấp, điều này sẽ truy vấn tệp và số khối:
SELECT file#, dbablk, class, state, TCH FROM X$BH WHERE HLADDR='address of latch';
X $ BH.TCH là số lần chạm cho bộ đệm. Giá trị cao của X $ BH.TCH biểu thị một khối nóng.
Nhiều khối được bảo vệ bởi mỗi chốt. Một trong những bộ đệm này có thể sẽ là khối nóng. Bất kỳ khối nào có giá trị TCH cao là một khối nóng tiềm năng. Thực hiện truy vấn này một số lần và xác định khối luôn xuất hiện trong đầu ra.
Sau khi bạn đã xác định được khối nóng, hãy truy vấn DBA_EXTENTS bằng cách sử dụng số tệp và số khối để xác định phân đoạn.
Thông tin quan trọng về sự kiện chờ
Chế độ xem v $ session_wait hiển thị thông tin về các sự kiện chờ mà các phiên hoạt động hiện đang chờ. Sau đây là mô tả của dạng xem này và nó chứa một số cột rất hữu ích, đặc biệt là các tham chiếu P1 và P2 đến các đối tượng được liên kết với các sự kiện chờ.
desc v$session_wait Name Null? Type --------------------------- -------- ------------ SID NUMBER SEQ# NUMBER EVENT VARCHAR2(64) P1TEXT VARCHAR2(64) P1 NUMBER P1RAW RAW(4) P2TEXT VARCHAR2(64) P2 NUMBER P2RAW RAW(4) P3TEXT VARCHAR2(64) P3 NUMBER P3RAW RAW(4) WAIT_CLASS_ID NUMBER WAIT_CLASS# NUMBER WAIT_CLASS VARCHAR2(64) WAIT_TIME NUMBER SECONDS_IN_WAIT NUMBER STATE VARCHAR2(19)
Sử dụng v $ session_wait, có thể dễ dàng diễn giải từng tham số sự kiện chờ bằng cách sử dụng các cột văn bản mô tả tương ứng cho tham số đó. Ngoài ra, các cột lớp chờ đã được thêm vào để các sự kiện chờ khác nhau có thể được nhóm vào các lĩnh vực xử lý liên quan như mạng, ứng dụng, nhàn rỗi, đồng thời, v.v.
Các cột này cũng được thêm vào bảng v $ phiên từ 10g trở đi . Vì vậy, bạn chỉ có thể sử dụng v $ session để tìm tất cả các chi tiết
Mỗi sự kiện chờ chứa các tham số khác cung cấp thông tin bổ sung về sự kiện.
Cách tìm thông tin về sự kiện chờ và tham số của nó
The meaning of each wait event corresponds know by querying the V$EVENT_NAME p1, p2, p3 of col name format a25; col p1 format a10; col p2 format a10; col p3 format a10; SELECT NAME, PARAMETER1 P1, PARAMETER2 P2, PARAMETER3 P3 FROM V$EVENT_NAME WHERE NAME = '&event_name';
Ví dụ như chúng tôi đã lấy
Các giá trị đầu vào của event_name:tệp db được đọc phân tán
Giá trị gốc của 3:WHERE NAME =‘&event_name A’
Giá trị mới 3:WHERE NAME =‘tệp db được đọc phân tán’
Tên P1 P2 P3
tệp db tập tin đọc rải rác # khối # khối
tệp #:số tệp dữ liệu
Khối #:số khối bắt đầu
khối:để đọc số của khối dữ liệu
Bây giờ chúng ta hãy xem thông tin trên có thể giúp chúng ta nắm bắt nhiều thứ khác nhau như thế nào
Giả sử một phiên cụ thể chờ đợi sự kiện đợi bộ đệm bận, đối tượng cơ sở dữ liệu gây ra sự kiện chờ này có thể dễ dàng được xác định:
select username, event, p1, p2 from v$session_wait where sid = 4563;
Đầu ra của truy vấn này cho một phiên cụ thể với SID 4563 có thể trông giống như sau:
USERNAME EVENT SID P1 P2 ---------- ----------------- --- -- --- APPS buffer busy waits 4563 11 545
Cột P1 và P2 cho phép DBA xác định số tệp và khối đã gây ra sự kiện chờ đợi này. Truy vấn bên dưới truy xuất tên đối tượng sở hữu khối dữ liệu 155, giá trị P2 ở trên:
SQL> select segment_name,segment_type from dba_extents where file_id = 11 and 45 between block_id and block_id + blocks – 1;
Khả năng phân tích và sửa các sự kiện chờ trong Cơ sở dữ liệu Oracle là rất quan trọng trong bất kỳ dự án điều chỉnh nào. Phần lớn hoạt động trong cơ sở dữ liệu liên quan đến việc đọc dữ liệu, do đó, loại điều chỉnh này có thể có tác động tích cực, rất lớn đến hiệu suất.
Lưu ý:Khi thực hiện phân tích thời gian chờ, điều quan trọng cần nhớ là tất cả cơ sở dữ liệu Oracle đều trải qua các sự kiện chờ và sự hiện diện của các lần chờ không phải lúc nào cũng chỉ ra một vấn đề. Trên thực tế, tất cả các cơ sở dữ liệu được điều chỉnh tốt đều có một số điểm nghẽn.
chúng ta cũng có thể sử dụng sự kiện 10046 để theo dõi sự kiện chờ của phiên
Cũng đã đọc
Tài liệu Oracle
v $ active_session_history
Giải thích Kế hoạch trong Oracle
