Đầu tiên cần lấy Báo cáo AWR trong Oracle (Đọc thêm: Cách lấy AWR Report từ dòng lệnh 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.
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 đề.
Các bước phân tích 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 đề.
Các bước phân tích báo cáo AWR
1. Report Header (tiêu đề báo cáo):
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ó 12 CUP trong Cores.
Snap Shot Detail (Chi tiết ảnh chụp nhanh):
Đ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ó 12 CUP trong Cores.
Đâ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.
2. 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ó 12 core vào hệ thống. Vì vậy, mỗi giây, bạn có 12 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ó 12 core và DB CPU "Per Second" là 6,8. 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 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.
2. 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ó 12 core vào hệ thống. Vì vậy, mỗi giây, bạn có 12 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ó 12 core và DB CPU "Per Second" là 6,8. 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 3,705,084 byte dữ liệu redo cùng với khoảng 3,156,413.2 byte mỗi giao dịch
Ví dụ: bảng trên cho thấy rằng mỗi giây tạo ra khoảng 3,705,084 byte dữ liệu redo cùng với khoảng 3,156,413.2 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
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ụ: 1,024 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:
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ụ: 1,024 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ới mục tiêu là 100%, đây là các tỷ lệ cấp cao cho hoạt động trong SGA)
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 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.
4. Top 5 Timed Foreground Events (top 5 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)
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 DB CPU = 46.62% thời gian DB.
Hãy lấy một ví dụ, Trong sự kiện nào là "log file switch (checkpoint not complete)" có Waits cao, Times(s) lớn và các giá trị lớn trong Avg wait (mili giây) và Wait Class là Configuration. Vì vậy, ở đây bạn phải điều tra và giải quyết việc log file switch (checkpoint not complete).
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ê, cùng với số lần chờ , thời gian đã chờ (tính bằng giây), thời gian chờ trung bình cho mỗi sự kiện (tính bằng micro giây) và wait class liên quan.
Rất quan trọng để xem xét phần này. 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 điề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 thảo luận 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
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.
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ới 12c là Top 10 Foreground Wait Events by Total Wait Time, ví dụ:
Instance gặp event log fiel sync (tunning online redo log) và xem lại code vì concurency quá nhiều.
Hoặc ví dụ khác:
5. Wait Events Statistics Section (Phần thống kê sự kiện chờ): Phần này hiển thị phân tích các sự kiện chờ chính trong cơ sở dữ liệu bao gồm các sự kiện chờ cơ sở dữ liệu foreground và background cũng như thống kê mô hình thời gian, hệ điều hành, dịch vụ và lớp chờ (wait class).
6. Wait Events (Sự kiện chờ): Phần báo cáo AWR này cung cấp thông tin chi tiết hơn về sự kiện chờ cho các tiến trình của người dùng foreground, bao gồm 5 sự kiện chờ hàng đầu và nhiều sự kiện chờ khác đã xảy ra trong khoảng thời gian snapshot.
7. 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
8. 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ế?
Đâ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.
9. 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 87.48% (%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 là công cụ có thể giúp chúng ta.
Chúng ta sẽ tìm hiểu một vài trong số chúng, Để hiểu, hãy phân tích các báo cáo này như thế nào. Hãy bắt đầu với
10. 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.
11. Thống kê SQL (SQL Statistics): Top câu lệnh SQL theo các tiêu chí
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ý.
Trong báo cáo này, 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 để khắc phục sự cố hoặc tối ưu hóa. Trong báo cáo trên, bạn có thể thấy truy vấn đầu tiên có thời gian thực hiện tối đa 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 thêm.
Một tiêu chí nữa là %Total thì không có sự khác biệt nhiều, cao nhất là 9.58% ở câu đầu, 7.78% câu 2, 7.78% câu 3,... bạn tối ưu 3-5 câu đầu tiên đó, ngoiaf ra câu chạy nhiều với 225,686 lần xem xét tối ưu nếu có thể.
Chúng ta lấy ví dụ khác về SQL orderd by Elapsed Time
Trong ví dụ này chúng ta có thể thấy 2 câu lệnh đầu tiên chiếm %Total lần lượt là 19.94% và 18.32% do đó cần ưu tiên tối ưu trước, sau đó mới đến các câu thứ 3 (chiếm %Total 6.3 chạy 1 lần),...
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ý.
Trong báo cáo này, các 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,...
Chú ý khi tìm kiếm các truy vấn sử dụng CPU cao nhất, nếu truy vấn hiển thị các lần thực thi là 0, điều này không có nghĩa là truy vấn không thực thi. Nó có thể giống trường hợp như trong các truy vấn SQL được sắp xếp theo thời gian đã thực hiệ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.
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.
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.
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.
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.
11 tiêu chí trên hay dùng, ngoài ra còn các tiêu chí khác:
12. 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.
- Thống kê Hoạt động Instance (Giá trị Tuyệt đối): Phần này chứa các thống kê có giá trị tuyệt đối không bắt nguồn từ ảnh chụp nhanh kết thúc và bắt đầu.
- Thống kê hoạt động Instance (Hoạt động chủ đề): Phần báo cáo này báo cáo thống kê hoạt động chuyển đổi nhật ký.
13. 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).
- Số liệu thống kê IO của tablespace
- Thống kê IO của File
- Thống kê Buffer pool
14. Phần tư vấn (Advisor Section): 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.
- Buffer Pool Advisory
- PGA Aggr Summary
- PGA Aggr Target Stats
- 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
- 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
- Shared Pool Advisory
- Java Pool Advisory
15. 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.
16. 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.
17. 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.
18. 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 segment.
19. 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
20. Segment Section (Phần segment): 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 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 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ự tranh cãi 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.
21. 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.
22. 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.
23. Tóm tắt bộ nhớ SGA: Phần này cung cấp thông tin tóm tắt về các vùng SGA khác nhau.
24. init.ora Tham số: 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.
* 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 weblogic, middleware, hoc solaris, hoc linux, hoc aix, unix, oracle oca, oracle ocp, oracle ocm
Không có nhận xét nào:
Đăng nhận xét