Đầu tiên cần lấy Báo cáo AWR trong Oracle (Đọc thêm: Cách lấy AWR Report trong Oracle Database), nhiệm vụ tiếp theo là Phân tích Báo cáo AWR trong Oracle. Bằng cách Đọc Báo cáo AWR, bạn có thể dễ dàng giải quyết các vấn đề như Cơ sở dữ liệu chậm, sự kiện chờ nhiều, Truy vấn chậm và nhiều vấn đề khác. Mặc dù Đây là một báo cáo dài, khó hiểu nhưng có rất nhiều giá trị từ báo cáo này do vậy việc Phân tích hoặc Đọc phần liên quan của Báo cáo AWR có thể giúp xác định nguyên nhân, khắc phục, phòng ngừa sự cố một cách dễ dàng và nhanh chóng.Tôi cũng khuyên bạn nên đọc ADDM Report trước tiên (lấy khoảng thời gian tương đường AWR Report), nó sẽ cung cấp root cause cho bạn, từ đó bạn sẽ tập trung đọc thêm vào AWR Report.
AWR là viết tắt của Automatically workload repository, Mặc dù có thể có nhiều loại vấn đề về hiệu suất cơ sở dữ liệu, nhưng khi toàn bộ cơ sở dữ liệu chậm, thì có hai khả năng:
1. Vấn đề với OS cơ sở dữ liệu. OS Watcher là công cụ tốt nhất để bắt đầu, một số đơn vị dùng Polestar, Zabbix,...
2. Nếu vấn đề về hiệu suất/hiệu năng (performance) Cơ sở dữ liệu, thì Báo cáo AWR là nơi để xem xét.
Trong trường hợp nếu một truy vấn (query) cụ thể không hoạt động tốt, tôi khuyên bạn nên xem xét kế hoạch thực thi (explan plan) của truy vấn đảm bảo cost thấp (chú ý partition, index), số liệu thống kê của bảng, v.v. Trong trường hợp này AWR sẽ không giúp được gì nhiều.
Như vậy bạn cần nhớ các từ khóa OS+AWR+Plan+Statistic nhé.
Các khuyến nghi trước khi nhận Báo cáo AWR.
1. Thu thập Nhiều Báo cáo AWR: Luôn luôn tốt khi có hai Báo cáo AWR, một cho thời gian tốt (khi cơ sở dữ liệu hoạt động tốt), thứ hai khi hiệu suất kém. Bằng cách này, DBA có thể dễ dàng so sánh báo cáo tốt và xấu để tìm ra nguyên nhân.
2. Bám vào thời gian cụ thể: "Cơ sở dữ liệu hoạt động chậm" sẽ không giúp giải quyết các vấn đề về tốc độ nữa. Chúng ta phải có một thời gian cụ thể như ngày hôm qua Cơ sở dữ liệu đã chậm ở mức 1 giờ chiều và tiếp tục cho đến 4 giờ chiều. Tại đây, DBA sẽ lấy báo cáo trong ba giờ này để phân tích, chứ các câu "hình như hôm nay database hơi chậm", "cảm giác database không mượt lắm" sẽ khó xác định.
3.Chia Báo cáo AWR Lớn thành Báo cáo Nhỏ hơn : Thay vì có một báo cáo trong thời gian dài như một báo cáo trong 4 giờ. tốt hơn là có bốn báo cáo mỗi báo cáo trong một giờ, thậm chí 30 phút. Điều này sẽ giúp cô lập vấn đề dễ dàng hơn.
Trong trường hợp RAC: Tạo một báo cáo cho mỗi instance. Khi bạn đã tạo báo cáo AWR. Bây giờ, đã đến lúc phân tích báo cáo. Vì, báo cáo AWR là một báo cáo rất lớn và rất nhiều thông tin để xem xét AWR cũng phụ thuộc vào từng vấn đề. Ở đây, tôi liệt kê các lĩnh vực phổ biến nhất để DBA xem xét để đưa ra bức tranh rõ ràng về vấn đề.
LẤY AWR TỪ TOOL TOAD
Vào menu Database --> Monitor --> ADDM/AWR Report (OEM)
Các bước phân tích báo cáo AWR
Database details (Chi tiết cơ sở dữ liệu)
Sau khi nhận được báo cáo AWR, Đây là phần đầu tiên và trên cùng của báo cáo. Trong phần này, hãy kiểm tra chéo cơ sở dữ liệu và phiên bản và phiên bản cơ sở dữ liệu với Cơ sở dữ liệu có vấn đề về hiệu suất. Báo cáo này cũng hiển thị RAC = YES nếu đó là cơ sở dữ liệu RAC.
Host Configuration (Cấu hình máy chủ):
Điều này sẽ cung cấp cho bạn tên, CUP nền tảng, socket và RAM, v.v. Điều quan trọng cần lưu ý là số core trong hệ thống. Trong ví dụ này có 24 Cores, mỗi core 2 socket nên có vCPU là 48
Snap Shot Detail (Chi tiết ảnh chụp nhanh):
Đây là chi tiết về ảnh chụp nhanh được chụp, thời gian bắt đầu chụp nhanh và thời gian kết thúc. Sự khác biệt giữa chúng là "Đã trôi qua" ("Elapsed"). Đây là một thuật ngữ mới "DB Time"
DB Time = Thời gian phiên (session) sử dụng trong cơ sở dữ liệu.
DB Time = Thời gian CPU (CPU Time) + Thời gian chờ không tính IDLE (Wait Time)
Bạn có thể thấy, thời gian DB rất lớn so với thời gian Elapse, điều này không đáng lo ngại. Kiểm tra xem bạn đã thực hiện một báo cáo về thời gian có vấn đề về hiệu năng hay chưa. Nếu có, hãy lấy báo cáo trong thời gian đó để xác định vấn đề về hiệu năng.
Tiếp theo là Cache Sizes, chỉ là chi tiết về các thành phần SGA.
Report Summary
Load Profile (Tải hồ sơ DB):
Dưới đây là một vài số liệu thống kê quan trọng để DBA xem xét. Đầu tiên là "DB CPU (s)" trên giây. Trước đó, hãy hiểu cách hoạt động của DB CUP. Giả sử bạn có 48 vCPU vào hệ thống. Vì vậy, mỗi giây, bạn có 48 giây để làm việc trên CPU.
Vì vậy, nếu "DB CPU (s)" "Per Second" trong báo cáo này > số core trong phần Host Configuration (# 2) có nghĩa là DB bị ràng buộc bởi CPU và cần nhiều CPU hơn hoặc cần phải kiểm tra thêm rằng điều này luôn luôn xảy ra hay chỉ trong một số thời điểm. Theo kinh nghiệm của tôi, có rất ít trường hợp gặp phải điều này.
Trong trường hợp này, máy có 48 core và DB CPU "Per Second" là 0.6. Vì vậy, không gặp vấn đề gì về CPU, CPU vẫn đáp ứng tốt và còn free nhiều.
Chỉ số tiếp theo để xem là Parses hay Hard Parses. Nếu tỷ lệ (ratio) hard parse là cao, điều này có nghĩa là Cơ sở dữ liệu đang thực hiện hard parse nhiều, tốn nhiều thời gian, làm câu lệnh chạy chậm. Vì vậy, cần phải xem xét các tham số như cursor_sharing sử dụng bind biến....
DB Time (s): Tổng thời gian mà oracle đã dành để thực hiện các lệnh SQL/PL-SQL của người dùng cơ sở dữ liệu. Lưu ý rằng không bao gồm các background process.
DB CPU (s): Tổng thời gian CPU dành cho các lệnh SQL/PL-SQL của người dùng. Tương tự như DB time, không bao gồm background process. Giá trị tính bằng micro giây
Redo size
Ví dụ: bảng trên cho thấy rằng mỗi giây tạo ra khoảng 1,769,860 byte dữ liệu redo cùng với khoảng 430,060 byte mỗi giao dịch
Logic reads: Consistent Gets+ DB blocks Gets = Logical reads
Block changes: Số block được sửa đổi trong khoảng thời gian lấy mẫu
Physical Reads: Số lần đọc vật lý được thực hiện
Physical Writes: Số lần ghi vật lý được thực hiện
User calls: Số lượng truy vấn (lời gọi) của người dùng
Parses: Tổng số lần parse (gồm hard parse và soft parse)
Hard parse: Các parse yêu cầu một parse mới của câu lệnh SQL. Gồm cả latch và vùng shared pool
Soft parse: Các Soft parse không được liệt kê nhưng có nguồn gốc bằng cách trừ của parse cho hard parse. Soft parse sử dụng lại hard parse trước đó; do đó nó dùng ít tài nguyên hơn, SQL nhanh hơn chút.
W/A MB Processed: Số lần sort mỗi giây và theo giao dịch
Logons: Số lần đăng nhập mỗi giây và theo giao dịch
Số lần thực thi (Executes): Số lần thực thi mỗi giây và theo giao dịch, đây là tham số khá quan trọng để đánh giá tải của DB
Số giao dịch (Transactions): Số giao dịch nào mỗi giây
Hồ sơ tải (Load Profile) cung cấp cái nhìn nhanh về một số thống kê hoạt động cụ thể. Bạn có thể so sánh các thống kê này với báo cáo ảnh snapshot baseline để xác định xem hoạt động cơ sở dữ liệu có khác biệt hay không. Giá trị cho những thống kê này được trình bày ở hai định dạng. Đầu tiên là giá trị mỗi giây (ví dụ: số redo được tạo mỗi giây) và thứ hai là giá trị trên mỗi giao dịch (ví dụ: 430,060 byte của redo được tạo cho mỗi giao dịch).
Thống kê được trình bày trong hồ sơ tải bao gồm:
- Redo size - Một chỉ báo về hoạt động DML/DDL mà cơ sở dữ liệu đã thực hiện.
- Logical và Physical read - Một phép đo về số lượng IO (Vật lý và logic) mà cơ sở dữ liệu đang thực hiện.
- Lời gọi của người dùng (User calls) - Cho biết có bao nhiêu lời gọi của người dùng đã xảy ra trong khoảng thời gian lấy mẫu. Giá trị này có thể cung cấp cho bạn một số dấu hiệu nếu việc sử dụng đã tăng lên.
- Parses and hard parses - Cung cấp chỉ báo về hiệu quả của việc tái sử dụng câu lệnh SQL mà không phải phân tích từ đầu.
- Sắp xếp (W/A MB Processed) - Con số này cho bạn biết mức độ sử dụng sắp xếp đang diễn ra trong cơ sở dữ liệu.
- Log đăng nhập (logons) - Cho biết có bao nhiêu lần đăng nhập xảy ra trong khoảng thời gian lấy mẫu.
- Số lần thực thi (Executes) - Cho biết có bao nhiêu câu lệnh SQL được thực thi trong khoảng thời gian lấy mẫu.
- Giao dịch (Transactions) - Cho biết có bao nhiêu giao dịch đã xảy ra trong khoảng thời gian lấy mẫu.
- Ngoài ra, phần hồ sơ tải cung cấp tỷ lệ phần trăm block đã được thay đổi trên mỗi lần đọc, tỷ lệ phần trăm lệnh gọi đệ quy đã xảy ra, phần trăm giao dịch được rollback và số row được sắp xếp cho mỗi thao tác sắp xếp.
Ví dụ khác các bạn tự phân tích nhé:
Tỷ lệ phần trăm hiệu quả Instance (Instance Efficiency Percentages):
(Với mục tiêu là 100%, đây là các tỷ lệ cấp cao cho hoạt động trong SGA)
--> Tốt cho các chỉ số, không phát sinh gì
Ta lấy 1 báo cáo khác để phân tích:
Trong các thống kê này, bạn phải nhìn vào "% Non-Parse CPU". Nếu giá trị này gần 100% có nghĩa là hầu hết tài nguyên CPU được sử dụng cho các hoạt động khác ngoài phân tích cú pháp, điều này tốt cho tình trạng cơ sở dữ liệu; tức là nếu chỉ số này < 99% thì cần cân nhắc xem xét tiêu chí parse của CSDL (vùng shared pool bé quá, cursor_sharing đặt chưa tối ưu,..).
Buffer Nowait %: 99.99% là tốt
Buffer Hit %: 99.73% là tốt
Library Hit %: 94.52% chưa tốt, nếu instance mới bật lên thì có thể chấp nhận được.
Execute to Parse % và Parse CPU to Parse Elapsd %:
Nếu giá trị thấp như trong trường hợp Execute to Parse % là 92.60 và Parse CPU to Parse Elapsd % là 91.68 ở trên có nghĩa là có thể có vấn đề về parsing. Bạn có thể cần xem xét các vấn đề code theo bind biến hoặc vấn đề shared pool size.
Redo NoWait%:
Thông thường số liệu thống kê này là 99 hoặc lớn hơn, nếu < 99% cần tối ưu redo
In-memory Sort %:
Điều này có thể cho bạn biết mức độ hiệu quả của bạn sort_area_size, hash_area_size hoặc pga_aggrigate_target. Nếu bạn không có đủ kích thước của các tham số sắp xếp, hash và pga, thì phần trăm sắp xếp trong bộ nhớ của bạn sẽ giảm xuống, các câu lệnh liên quan đến sort sẽ chậm đi.
Soft parse %:
Với 56.05% cho phân tích cú pháp mềm có nghĩa là khoảng 43,95% (100-soft parse) đang xảy ra đối với hard parse. Bạn có thể muốn xem xét các vấn đề bind biến.
Latch Hit%: Phải gần bằng 100 là tốt, giá trị hiện tại là 97.82%
% Non-Parse CPU:
Hầu hết các câu lệnh của chúng tôi đã được parse nên chúng tôi không thực hiện parse lại. Quá trình parse lại chiếm tỷ lệ cao trên CPU và nên tránh.
Top 10 Timed Foreground Events (top 10 event):
Đây là phần quan trọng nhất trong báo cáo AWR. Nó hiển thị các sự kiện chờ đợi hàng đầu và có thể nhanh chóng hiển thị tắc nghẽn cơ sở dữ liệu ở đâu (được coi như tấm bản đồ để xác định điểm nghẽn)
(Đánh giá nhanh Instance này gặp event về I/O (I/O vật lý, IO câu lệnh, online log, concurrency) cần xem kỹ vấn đề I/O, xem kỹ SQL I/O nhiều)
Các bước đọc như sau:
- Trước hết hãy kiểm tra nhóm wait (wait class) nếu wait class là User I/O, System I/O, Others, v.v. điều này có thể ổn nhưng nếu wait class có giá trị "Concurrency" thì có thể có một số vấn đề nghiêm trọng.
- Tiếp theo để xem Time(s) cho biết số lần DB đã chờ trong nhóm này
- Sau đó là chờ trung bình (Avg wait, tính bằng mili giây). Nếu Thời gian cao nhưng Chờ trung bình (mili giây) thấp thì bạn có thể bỏ qua điều này. Nếu cả hai đều cao là Time(s) cao hoặc Chờ trung bình (mili giây) cao thì điều này phải được check kỹ thêm.
Trong ảnh chụp màn hình ở trên, hầu hết tài nguyên được sử dụng bởi I/O (wait class là User I/O, Configuration do log switch checkpoint, commit, concurency,..), tập trung vào I/O ở các mục sau: tăng số đường quang đến SAN, thêm LUN của ASM Diskgroup, SAN SSD cho dữ liệu quan trọng, hay ruy cập, với SQL By Physical Read, Segment lớn cần dọn dẹp, tái cấu trúc...
Phần này cung cấp thông tin chi tiết về các sự kiện mà cơ sở dữ liệu Oracle đang sử dụng phần lớn thời gian (xem % DB Time). Mỗi sự kiện chờ được liệt kê (Event), cùng với số lần chờ (waits), thời gian đã chờ (Total Wait Time, tính bằng giây), thời gian chờ trung bình cho mỗi sự kiện (Wait Avg, tính bằng micro giây) và wait class liên quan.
Nếu bạn tắt tham số thống kê, thì Time(s) sẽ không xuất hiện. Phân tích wait có thể có hàng triệu lần wait nhưng nếu xảy ra trong một giây hoặc lâu hơn thì cần chú ý. Vì vậy, Time(s) là thành phần rất quan trọng.
Vì vậy, có một số kiểu wait khác nhau. Bạn có thể thấy các thời gian wait khác nhau trên báo cáo AWR của mình. Vì vậy, chúng ta hãy cùng tìm hiểu về những wait phổ biến nhất:
df file type waits:
Chờ khi đọc datafile
db file sequential read: Là wait đến từ phía vật lý của cơ sở dữ liệu, nó liên quan đến tình trạng thiếu bộ nhớ và sử dụng index không chuẩn, đọc tuần tự là một index theo sau bởi bảng được đọc bởi vì nó đang thực hiện tra cứu index cho biết chính xác block nào cần truy cập.
db file scattered read:
gây ra do quá trình quét toàn bộ bảng có thể do không có index hoặc không có sẵn statistic
direct Path writes:
Bạn sẽ không thấy chúng trừ khi bạn đang thực hiện một số thao tác bổ sung dữ liệu hoặc tải dữ liệu
direct Path reads:
Có thể xảy ra nếu bạn đang thực hiện query song song
db file parallel writes / read:
Nếu bạn đang thực hiện nhiều hoạt động partition thì hãy chờ, nó có thể là một bảng partition hoặc index partition
db file single write:
Nếu bạn thấy sự kiện này thì có lẽ bạn có rất nhiều data file trong cơ sở dữ liệu của mình.
direct path read temp or direct path write temp:
Sự kiện chờ này hiển thị hoạt động của Temp file (sắp xếp, hash, bảng tạm thời, bitmap), kiểm tra tham số pga hoặc tham số sort area hoặc hash area. Bạn có thể muốn tăng thêm CPU của máy chủ, CPU của Instance và Memory.
log file switch (checkpoint not complete)
Do online redolog nhỏ quá nên bị nghẽn, làm câu lệnh DML/DDL chạy chậm, cần tăng size redo log và thêm group
Ví dụ khác:
Instance gặp event log fiel sync (tunning online redo log) và xem lại code vì concurency quá nhiều.
Ví dụ khác: DB CPU 46% DB Time, I/O 33% --> Tập trung vào SQL by Physical Reads và SQL by CPU
Ví dụ khác:
Khi xem báo cáo AWR, nơi tốt để bắt đầu là phần "op 5 Timed Foreground Events", gần đầu báo cáo. Điều này cung cấp cho bạn các dấu hiệu về các tắc nghẽn trong hệ thống trong khoảng thời gian lấy mẫu này.
Khi bạn đã xác định được các sự kiện hàng đầu, hãy đi sâu để xem SQL và PL / SQL nào đang sử dụng phần lớn các tài nguyên đó. Trên phần "Main Report", hãy nhấp vào liên kết "SQL Statistics".
Trên phần "SQL Statistics", nhấp vào "SQL ordered by ??" liên quan đến sự kiện chờ đợi mà bạn đã xác định trong phần "Top 5 Timed Foreground Events". Trong trường hợp này, "DB CPU" là sự kiện hàng đầu, vì vậy ta vào liên kết "SQL ordered by CPU Time" trước
Sau đó, bạn được trình bày với SQL và PL / SQL đang sử dụng hầu hết các tài nguyên được chỉ định trong khoảng thời gian mẫu. Sau đó, bạn có thể cố gắng tối ưu các lệnh có %Total cao (chỉ chiếm 3-5 câu top)
Lặp lại quá trình này cho các sự kiện hàng đầu khác.
Wait Classes by Total Wait Time
Wait User I/O chiếm 46.2% DB Time, System I/O chiếm 14.7%, tức là I/O chiếm 60.9% (khá lớn), ngoài ra là Concurency chiếm 10.3% (lock dữ liệu), Cluster 15.5%, Configuration 25.0%
Host CPU
Tài nguyên CPU có %Idle 98% (free 98%), rất lớn.
Instance CPU
%DB Time waiting for CPU là 0% (rất tốt)
IO Profile
Memory Statistics
30.83% mem dùng cho SGA và PGA
Cache Sizes
Buffer Cache là 62G
Shared Pool Statistics
Wait Events Statistics
Time Model Statistics (Số liệu thống kê Mô hình Thời gian)
Đây là phần giải thích chi tiết về mức độ sử dụng tài nguyên hệ thống. Số liệu thống kê được sắp xếp theo Time (s), % of DB Time.
Một kết quả cần chú ý % of DB Time là > 100%, tại sao lại thế?
Lý do đây là thời gian tích lũy, tức là Trong trường hợp này, thời gian thực thi SQL chiếm 93.26% thời gian DB, bao gồm các phần phụ như thời gian phân tích cú pháp (parse), thời gian harde parse, v.v. Vì vậy, nếu bạn thấy thời gian hard parse sẽ chiếm nhiều hơn % . Vì vậy, hãy kiểm tra thêm,...DBA cần chú ý chỉ số chiếm% DB time bất thường.
Operating System Statistics (Thống kê Hệ điều hành):
Đây là thông tin liên quan đến Hệ điều hành, trạng thái tải trên Hệ thống hiển thị ở đây.
Báo cáo này cho thấy, hệ thống không hoạt động 97-99%% (%idle) tại thời điểm báo cáo được thực hiện, Vì vậy, không có vấn đề gì về tài nguyên hệ thống. Nhưng nếu, bạn thấy %user hoặc %sys cao dẫn đến %idle thấp. Check ngay những gì đang gây ra điều này. OS Watcher/công cụ giám sát OS tương đương là công cụ có thể giúp chúng ta.
Foreground Wait Class
User I/O chiếm 45.91% DB Time
Foreground Wait Events
Background Wait Events (Sự kiện chờ background): Phần này có liên quan đến các sự kiện chờ trong background process
Wait Events Histagram (Sự kiện chờ):
Wait Event Histogram Detail (64 msec to 2 sec)
Wait Event Histogram Detail (4 sec to 2 min)
Wait Event Histogram Detail (4 min to 1 hr)
Service Statistics (Thống kê dịch vụ):
Phần thống kê dịch vụ cung cấp thông tin về cách các dịch vụ cụ thể được cấu hình trong cơ sở dữ liệu đang hoạt động.
Service Wait Class Stats
Tiếp theo, phần rất quan trọng của báo cáo AWR cho DBA là Thống kê SQL (SQL Statistic). Trong đó có tất cả các chi tiết truy vấn sql được thực thi trong khoảng thời gian báo cáo.
SQL Statistics (Top SQL)
Có 2 tiêu chí chúng ta cần chú ý: Tập trung theo nguyên lý 20-80 (20% câu lệnh chiếm nhiều tải, khi tối ưu xong sẽ đem lại 80% kết quả hoặc hơn):
- Total: Những câu lệnh top theo các tiêu chí chúng ta lấy ra để tối ưu, cũng chỉ 3-5 câu thôi
- Những câu lệnh chiếm nhiều tài nguyên theo Elapsed Time, CPU Time,...(cột đầu tiên) + tiêu chí mỗi lần thực thi chiếm nhiều tải không.
(Note: Phần tối ưu này là công việc liên tục hàng tháng/tuần để DB luôn chạy mượt do ứng dụng của chúng ta thay đổi, cập nhật thường xuyên nên sẽ thường xuyên xuất hiện các câu lệnh kém hoặc chạy 2-3 năm mới phát sinh hiệu năng giảm, chậm)
SQL Ordered by Elapsed Time (SQL được sắp xếp theo thời gian chạy)
Bao gồm các câu lệnh SQL mất nhiều thời gian thực thi trong quá trình xử lý hãy tìm SQL có số lần thực thi ít (Executins) và thời gian thực hiện cho mỗi lần lâu (Elapsed Time per Exec(s)) và SQL này có thể là câu lệnh để chúng ta tối ưu.
Trong báo cáo này, chúng ta sẽ lần lượt thực hiện:
- Tối ưu lần lượt các câu chiếm % Total lớn lần lượt là 29.70%, 11.17%, 6.31%, 4.64%, 4.52%; đặc biệt là 2 câu chiếm % lớn đầu tiên
+ Câu đầu tiên chạy 16 lần,mỗi lần 3.480s (gần 1h) chiếm 29.70%, %IO là 82.16%, cần tối ưu đầu tiên
+ Câu thứ 2 có thời gian thực hiện rất cao 20,954.42s, chiếm %Toal 11.17% nhưng không được thực thi (=0) do chưa chạy xong. Vì vậy, bạn phải kiểm tra, tối ưu câu này sớm.
+ Tiếp tục câu thứ 3, 4,... tối ư
Chúng ta tối ưu tầm 3-5 câu là đủ và hoạt động này cần liên tục tối ưu định kỳ hàng tháng, hàng tuần để nghiệp vụ chạy mượt, hiệu năng cao.
SQL ordered by CPU Time (SQL được sắp xếp theo thời gian CPU):
Bao gồm các câu lệnh SQL tiêu tốn đáng kể thời gian CPU trong quá trình xử lý.
Tối ưu câu đầu tiên chiếm 84.32%, câu này executions=0 (đang chạy dở trong lúc mình lấy mẫu) sẽ đem lại > 95% hiệu quả về CPU, các câu còn lại rỗi rãi thì làm vì không nhiều hiệu quả.
1 ví dụ khác: với truy vấn SQL được liệt kê trên chiếm tải cao theo tiêu chí sử dụng CPU. 2 câu đầu tiên có %Toal là 40.22 và 34.71%, executions cũng rất lớn là 40.132 và 40.132 do vậy chúng ta tối ưu 2 câu này xong sẽ giảm tải đáng kể hiệu năng. Sau khi 2 câu đó tối ưu xong mới tối ưu câu thứ 3, thứ 4,...
SQL ordered by User I/O Wait Time
Tối ưu 2 câu đầu tiên chiếm %Total là 52.83% và 22.03% là sẽ giải quyết được vấn đề.
SQL Ordered by Gets (SQL được sắp xếp theo thứ tự của Gets): Các SQL này thực hiện một số lượng cao các lần đọc logic trong khi truy xuất dữ liệu.
Tối ưu 2 câu đầu tiên chiếm %Toal là 82.06%, và 9.89%
SQL Ordered by Reads (SQL được sắp xếp theo thứ tự đọc): Các SQL này thực hiện một số lượng lớn các lần đọc đĩa vật lý trong khi truy xuất dữ liệu.
Tối ưu 5 câu đầu tiên
SQL ordered by Physical Reads (UnOptimized)
Tối ưu 5 câu đầu tiên
SQL ordered by Executions
Tối ưu 4 câu đầu tiên
SQL Ordered by Parse Calls (SQL được sắp xếp theo thứ tự cuộc gọi phân tích cú pháp): Các SQL này trải qua một số lượng lớn các hoạt động phân tích lại.
Tối ưu 3 câu đầu tiên
SQL Ordered by Sharable Memory (SQL được sắp xếp theo bộ nhớ chia sẻ): Bao gồm các con trỏ câu lệnh SQL tiêu thụ một lượng lớn bộ nhớ nhóm chia sẻ SGA.
Tối ưu câu đầu tiên
SQL Ordered by Version Count (SQL được sắp xếp theo số lượng phiên bản SQL): Các SQL này có một số lượng lớn các phiên bản trong nhóm chia sẻ vì một số lý do.
SQL ordered by Cluster Wait Time
Tối ưu 5 câu đầu tiên
Ngoài ra còn các tiêu chí khác cũng cần lưu ý:
Complete List of SQL Text: Chi tiết các câu lệnh SQL, PL/SQL
Instance Activity Stats (Thống kê Hoạt động Instance): Phần này chứa thông tin thống kê mô tả cách cơ sở dữ liệu hoạt động trong khoảng thời gian chụp nhanh:
- Key Instance Activity Stats
- Other Instance Activity Stats
- Instance Activity Stats - Absolute Values
- Instance Activity Stats - Thread Activity
(1 tiếng switch 6.66 lần, hơi cao, cần theo dõi, 3-4 lần là khuyến nghị)
Phần I/O: Phần này hiển thị tất cả hoạt động I/O quan trọng đối với Instance và hiển thị hoạt động I/O theo tablespace, tệp dữ liệu (data file) và bao gồm thống kê vùng đệm (buffer pool).
- IOStat by Function summary: Chú ý trường Avg Tm (ms)
- IOStat by Filetype summary
- IOStat by Function/Filetype summary: Chú ý trường Avg Tm (ms), lý tưởng là <2-10ms, hiện tại lên đến gần 300ms là quá chậm
- Tablespace IO Stats: Chú ý trường Av Rd(ms) và Av Writes(ms) , lý tưởng là <10ms, hiện tại lên đến gần 300ms là quá chậm
- File IO Stats: Chú ý trường Av Rd(ms) và Av Buf Wt(ms), Buffer Waits (ít là tốt), lý tưởng là <10ms, hiện tại lên đến gần 300ms là quá chậm
Buffer Pool Statistics
- Buffer Pool Statistics
- Checkpoint Activity
Phần tư vấn (Advisory Statistics)
Phần này hiển thị chi tiết về các lời khuyên cho vùng đệm, vùng chia sẻ, SGA, PGA và vùng Java.
- Instance Recovery Stats
- MTTR Advisory
- Buffer Pool Advisory
- PGA Aggr Summary
- PGA Aggr Target Stats
- PGA Aggr Target Histogram
- PGA Memory Advisory
- Shared Pool Advisory
- SGA Target Advisory
- Streams Pool Advisory
- Java Pool Advisory
Chi tiết:
Instance Recovery Stats
MTTR Advisory: Thi thoảng 1 số báo cáo không có dữ liệu
Buffer Pool Advisory
Hiện tại được cấp tự động là 62GB, càng to càng tốt vì đỡ phải đọc từ datafile (physical read)
PGA Aggr Summary
PGA Aggr Target Stats
PGA start được cấp 1,978M, end được cấu 1,809M
PGA Aggr Target Histogram
PGA Memory Advisory: PGA 25GB là tối ưu, có tăng PGA > 25GB cũng không hiệu quả hơn.
Shared Pool Advisory: không cần quan tâm do SGA tự động câp phát tốt từ Oracle DB 11g
Hiện tại đang được tự động cấp phát là 11GB, đã tối ưu
SGA Target Advisory: Như hình dưới đặt 76GB cho SGA với DB Time(s) là 6,126,510 và Est Phisical Reads là 183,859,478; giá trị tối ưu SGA là 130GB khi đó DB Time (s) là 5,645,600 và Est Physical Reads là 107,300,391; có tăng lên SGA > 130GB hiệu năng DB cũng không tốt hơn.
Streams Pool Advisory: Ko cần quan tâm
Java Pool Advisory: Không cần quan tâm
Wait Statistics
Buffer Wait Statistics (Thống kê chờ bộ đệm): Phần quan trọng này hiển thị thống kê số lần chờ bộ đệm.
Enqueue Activity: Phần quan trọng này cho thấy cách hoạt động của enqueue trong cơ sở dữ liệu. Hàng đợi là cấu trúc bên trong đặc biệt cung cấp khả năng truy cập đồng thời vào các tài nguyên cơ sở dữ liệu khác nhau.
Undo Statistics
Undo Segment Summary (Tóm tắt undo segment): Phần này cung cấp tóm tắt về undo segment được sử dụng bởi cơ sở dữ liệu.
Undo Segment Stats (Thống kê Undo Segment): Phần này hiển thị thông tin lịch sử chi tiết về hoạt động undo data.
Latch Statistics
- Latch Activity
- Latch Sleep Breakdown
- Latch Miss Sources
- Mutex Sleep Summary
- Parent Latch Statistics
- Child Latch Statistics
Latch Activity (Hoạt động chốt): Phần này hiển thị chi tiết về thống kê chốt. Các chốt là một cơ chế tuần tự hóa nhẹ được sử dụng để truy cập đơn luồng vào các cấu trúc nội bộ của Oracle.
- Latch Sleep Breakdown
- Latch Miss Sources
- Parent Latch Statistics
- Child Latch Statistics
Latch Sleep Breakdown
Latch Miss Sources
Mutex Sleep Summary
Parent Latch Statistics: Ít quan tâm
Child Latch Statistics: Ít quan tâm
Segment Statistics:
Phần báo cáo này cung cấp chi tiết về các segment "nóng" bằng cách sử dụng các tiêu chí sau:
- Segments by Logical Reads: Bao gồm các top segment có số lần đọc logic cao.
- Segments by Physical Reads: Bao gồm các top segment có số lần đọc vật lý đĩa cao.
- Segments by Physical Read Requests: Bao gồm các top segment có số lần đọc vật lý cao
- Segments by UnOptimized Reads: Bao gồm các top segment có số lần đọc chưa tối ưu cao
- Segments by Optimized Reads: Bao gồm các top segment có số lần đọc đã tối ưu cao
- Segments by Direct Physical Reads: Bao gồm các top segment có số lần đọc vật lý trực tiếp cao
- Segments by Physical Writes: Bao gồm các top segment có số lần ghi vật lý cao
- Segments by Physical Write Requests: Bao gồm các top segment có số lần yêu cầu ghi vật lý cao
- Segments by Direct Physical Writes: Bao gồm các top segment có số lần ghi vật lý trực tiếp
- Segments by Table Scans: Bao gồm các top segment có số lần quét bảng cao
- Segments by DB Blocks Changes: Bao gồm các top segment có số lần thay đổi block cao
- Segments by Row Lock Waits: Bao gồm các top segment có số lượng lớn row lock trên dữ liệu của chúng.
- Segments by ITL Waits: Bao gồm các top segment có sự tranh chấp lớn về Danh sách giao dịch quan tâm (ITL). Sự xung đột về ITL có thể được giảm bớt bằng cách tăng thông số lưu trữ INITRANS của bảng.
- Segments by Buffer Busy Waits: Bao gồm top segment này có số lượng bộ đệm chờ lớn nhất do block dữ liệu của chúng gây ra.
- Segments by Global Cache Buffer Busy: Bao gồm các top segment có số lần bận ở buffer cache cao
- Segments by CR Blocks Received
- Segments by Current Blocks Received
Segments by Logical Reads
Xem xét cấu trúc lại object đầu tiên do chiếm 88.64%, các object bên dưới cần rà soát xem đã chuẩn chưa.
Segments by Physical Reads
Chú ý object đầu tiên, các object bên dưới cần rà soát xem đã chuẩn chưa.
Segments by Physical Read Requests
Segments by UnOptimized Reads
Segments by Optimized Reads
Segments by Direct Physical Reads
Segments by Physical Writes
Các obecjt thứ 1,2, 3 chiếm %Total nhiều cần rà soát, tối ưu
Segments by Physical Write Requests
Các obecjt thứ 1,2, 3 chiếm %Total nhiều cần rà soát, tối ưu
Segments by Direct Physical Writes
Object đầu tiên chiếm %Total là 48% cần xem xét đầu tiên
Segments by Table Scans
Segments by DB Blocks Changes
5 object trên cần xem xét
Segments by Row Lock Waits
5 object trên cần xem xét
Segments by ITL Waits
5 object trên cần xem xét
Segments by Buffer Busy Waits
Object đầu tiên chiếm 85.13% cần tối ưu trước
Segments by Global Cache Buffer Busy
5 object trên cần xem xét
Segments by CR Blocks Received
Object đầu tiên cần xem xét tối ưu trước
Segments by Current Blocks Received
5 object trên cần xem xét
Dictionary Cache Statistics
- Dictionary Cache Stats
- Dictionary Cache Stats (RAC)
Dictionary Cache Stats (Thống kê Dictionary Cache): Phần này trình bày chi tiết về cách bộ đệm từ điển dữ liệu đang hoạt động.
Library Cache Statistics
- Library Cache Activity
- Library Cache Activity (RAC)
Library Cache Activity (Hoạt động trong bộ đệm thư viện): Bao gồm thống kê bộ đệm thư viện mô tả cách quản lý các đối tượng thư viện được chia sẻ bởi Oracle.
Library Cache Activity (RAC)
Memory Statistics
- Memory Dynamic Components
- Memory Resize Operations Summary
- Memory Resize Ops
- Process Memory Summary
- SGA Memory Summary
- SGA breakdown difference
(Phần này cung cấp thông tin tóm tắt về các vùng SGA khác nhau)
Memory Dynamic Components
Memory Resize Operations Summary: Ít quan tâm
Memory Resize Ops: Ít quan tâm
Process Memory Summary
SGA Memory Summary
SGA breakdown difference
Streams Statistics: Ít quan tâm
- Streams CPU/IO Usage
- Streams Capture
- Streams Capture Rate
- Streams Apply
- Streams Apply Rate
- Buffered Queues
- Buffered Queue Subscribers
- Rule Set
- Persistent Queues
- Persistent Queues Rate
- Persistent Queue Subscribers
Shared Server Statistics
- Shared Servers Activity
- Shared Servers Rates
- Shared Servers Utilization
- Shared Servers Common Queue
- Shared Servers Dispatchers
init.ora Parameter
Phần này hiển thị init.ora ban đầu các tham số cho ví dụ trong khoảng thời gian chụp nhanh.
Hy vọng hữu ích cho bạn.
- init.ora Parameters
- init.ora Multi-Valued Parameters
init.ora Parameters
init.ora Multi-Valued Parameters
RAC Statistics
- RAC Report Summary
- Global Messaging Statistics
- Global CR Served Stats
- Global CURRENT Served Stats
- Global Cache Transfer Stats
- Interconnect Stats
- Dynamic Remastering Statistics
RAC Report Summary
Chi tiết:
Interconnect Stats
- Interconnect Latency Stats: Chú ý cột Avg Latency 8K msg nếu >5ms là rất chậm, RAC sẽ kém hiệu quả
- Interconnect Throughput by Client
- Interconnect Device Stats
-- Thay đổi chu kỳ snapshot từ 60 phút xuống 30 phútSQL> EXEC dbms_workload_repository.modify_snapshot_settings(interval=>30);PL/SQL procedure successfully completed. SQL> EXEC dbms_workload_repository.modify_snapshot_settings(retention=>64800);
Workload Repository Views
V$ACTIVE_SESSION_HISTORY - Hiển thị active session history (ASH), mẫu lấy theo từng giây
V$METRIC - Hiển thị thông tin metric.
V$METRICNAME - Hiển thị the metrics kết hợp với group
V$METRIC_HISTORY - Hiển thị lịch sử metric
V$METRICGROUP - Hiển thị mọi metrics group
DBA_HIST_ACTIVE_SESS_HISTORY - Hiển thị lịch sử của active session history.
DBA_HIST_BASELINE - Hiển thị thông tin baseline.
DBA_HIST_DATABASE_INSTANCE - Hiển thị thông tin môi trường database.
DBA_HIST_SNAPSHOT - Hiển thị thông tin snapshot.
DBA_HIST_SQL_PLAN - Hiển thị SQL execution plans.
DBA_HIST_WR_CONTROL - Hiển thị thiết lập AWR.
Có thể lấy báo cáo từ SQL Developer:
=============================
* KHOÁ HỌC ORACLE DATABASE A-Z ENTERPRISE trực tiếp từ tôi giúp bạn bước đầu trở thành những chuyên gia DBA, đủ kinh nghiệm đi thi chứng chỉ OA/OCP, đặc biệt là rất nhiều kinh nghiệm, bí kíp thực chiến trên các hệ thống Core tại VN chỉ sau 1 khoá học.* CÁCH ĐĂNG KÝ: Gõ (.) hoặc để lại số điện thoại hoặc inbox https://m.me/tranvanbinh.vn hoặc Hotline/Zalo 090.29.12.888
* Chi tiết tham khảo:
https://bit.ly/oaz_w
=============================
KẾT NỐI VỚI CHUYÊN GIA TRẦN VĂN BÌNH:
📧 Mail: binhoracle@gmail.com
☎️ Mobile: 0902912888
⚡️ Skype: tranbinh48ca
👨 Facebook: https://www.facebook.com/BinhOracleMaster
👨 Inbox Messenger: https://m.me/101036604657441 (profile)
👨 Fanpage: https://www.facebook.com/tranvanbinh.vn
👨 Inbox Fanpage: https://m.me/tranvanbinh.vn
👨👩 Group FB: https://www.facebook.com/groups/DBAVietNam
👨 Website: https://www.tranvanbinh.vn
👨 Blogger: https://tranvanbinhmaster.blogspot.com
🎬 Youtube: http://bit.ly/ytb_binhoraclemaster
👨 Tiktok: https://www.tiktok.com/@binhoraclemaster?lang=vi
👨 Linkin: https://www.linkedin.com/in/binhoracle
👨 Twitter: https://twitter.com/binhoracle
👨 Địa chỉ: Tòa nhà Sun Square - 21 Lê Đức Thọ - Phường Mỹ Đình 1 - Quận Nam Từ Liêm - TP.Hà Nội
=============================
học oracle database, Tự học Oracle, Tài liệu Oracle 12c tiếng Việt, Hướng dẫn sử dụng Oracle Database, Oracle SQL cơ bản, Oracle SQL là gì, Khóa học Oracle Hà Nội, Học chứng chỉ Oracle ở đầu, Khóa học Oracle online,khóa học pl/sql, học dba, học dba ở việt nam, khóa học dba, khóa học dba sql, tài liệu học dba oracle, Khóa học Oracle online, học oracle sql, học oracle ở đâu tphcm, học oracle bắt đầu từ đâu, học oracle ở hà nội, oracle database tutorial, oracle database 12c, oracle database là gì, oracle database 11g, oracle download, oracle database 19c, oracle dba tutorial, oracle tunning, sql tunning , oracle 12c, oracle multitenant, Container Databases (CDB), Pluggable Databases (PDB), oracle cloud, oracle security, oracle fga, audit_trail, oracle dataguard, oracle goldengate, mview, oracle exadata, oracle oca, oracle ocp, oracle ocm , oracle weblogic, middleware, hoc solaris, hoc linux, hoc aix, unix, securecrt, xshell, mobaxterm, putty
