Chọn khu vực của bạn
Sử dụng tìm kiếm trên Intel.com
Bạn có thể dễ dàng tìm kiếm toàn bộ trang Intel.com qua một số cách.
- Tên thương hiệu: Core i9
- Số tài liệu: 123456
- Tên mã: Alder Lake
- Người vận hành đặc biệt: “Ice Lake”, Ice AND Lake, Ice OR Lake, Ice*
Liên kết nhanh
Bạn cũng có thể dùng thử các liên kết nhanh bên dưới để xem kết quả cho những từ khóa tìm kiếm phổ biến nhất.
- Sản phẩm
- Hỗ trợ
- Trình điều khiển & phần mềm
Các tìm kiếm gần đây
Tìm kiếm chuyên sâu
Chỉ tìm kiếm trong
Tên hiệu Mô tả ID Nội dung
Sign in to access restricted content.
- Hỗ trợ sản phẩm
- Hỗ trợ sản phẩm
- Graphics
- Processors
- Intel® NUCs
- Software
- Wireless
- Memory and Storage
- Boards and Kits
- Ethernet Products
- Intel® FPGAs
- Server Products
- Technologies
- Other Intel® Brands
- Sản Phẩm Ethernet
- Sản Phẩm Ethernet
- Sản phẩm Ethernet Intel® Killer™
- Bộ điều hợp mạng chuỗi 800 [lên đến 100GbE]
- Bộ điều hợp mạng chuỗi 700 [lên đến 40GbE]
- Mạch điều khiển chuỗi 700 [lên đến 40GbE]
- Bộ điều hợp mạng chuỗi 500 [lên đến 10GbE]
- Mạch điều khiển chuỗi 500 [lên đến 10GbE]
- Bộ điều hợp Ethernet Gigabit [lên đến 2.5GbE]
- Mạch điều khiển Ethernet Gigabit [lên đến 2.5GbE]
- Kết nối ethernet [lên đến 100GbE]
- Mạch điều khiển đa máy chủ [lên đến 100GbE]
- Phần mềm Ethernet Intel®
- Sản phẩm Ethernet kế thừa
Phiên bản trình duyệt bạn đang sử dụng không được khuyên dùng cho trang web này.
Vui lòng xem xét nâng cấp lên phiên bản mới nhất của trình duyệt bằng cách nhấp vào một trong các liên kết sau đây.
- Safari
- Chrome
- Edge
- Firefox
Bảo hành có giới hạn cho các sản phẩm Quang & Cáp Intel® Ethernet
Tài liệu
Loại nội dung Bảo hành & RMA
ID bài viết 000026529
Lần duyệt cuối 26/03/2021
ĐIỀU KHOẢN VÀ ĐIỀU KIỆN BẢO HÀNH, HỖ TRỢ VÀ DỊCH VỤ CỦA INTEL® SẢN PHẨM QUANG & CÁP INTEL® ETHERNET
Các Điều khoản và Điều kiện Bảo hành, Hỗ trợ và Dịch vụ của Intel® này [“Điều khoản và Điều kiện Dịch vụ”] chi phối các dịch vụ bảo hành và hỗ trợ do Intel
cung cấp cho người dùng cuối ban đầu [“Khách hàng”] đã mua Sản phẩm Quang & Cáp Intel® Ethernet [“Sản phẩm”] trực tiếp từ Tập đoàn Intel [“Intel”] hoặc gián tiếp từ đại lý bán lẻ hoặc nhà phân phối được ủy quyền của Intel [“Người bán được ủy quyền”]. Trừ khi có thỏa thuận khác bằng văn bản của Intel, mọi yêu cầu của Khách hàng về dịch vụ bảo hành và hỗ trợ dành cho Sản phẩm sẽ chỉ được chấp nhận theo các điều khoản và điều kiện ở đây, bất chấp mọi điều khoản hoặc điều kiện có trong hoặc được
tham chiếu đến bất kỳ đơn đặt hàng nào của Khách hàng được in sẵn hoặc đơn đặt hàng tương tự tài liệu. Ngoại trừ phạm vi được quy định trong Điều khoản và Điều kiện Dịch vụ này, thỏa thuận mua hàng của Người bán lại được Ủy quyền hoặc các điều khoản và điều kiện bán hàng, hoặc trong trường hợp không có các tài liệu đó, Điều khoản và Điều kiện Bán hàng của Intel có tại
/content/www/us/en/legal/terms-of-use.html sẽ chi phối các dịch vụ bảo hành và hỗ trợ dành cho Sản phẩm. Intel bảo lưu quyền thay đổi các điều khoản của Điều khoản và Điều kiện Bán hàng của Intel và Điều khoản và Điều kiện Dịch vụ này, bao gồm nhưng không giới hạn, quyền ngừng cung cấp các dịch vụ bảo hành và hỗ trợ cho Sản phẩm, bất kỳ lúc nào mà không cần thông báo và không phải chịu bất kỳ trách nhiệm
pháp lý nào. Các Điều khoản và Điều kiện Dịch vụ này không áp dụng cho các sản phẩm tùy chỉnh được mua trực tiếp hoặc gián tiếp từ Intel.Sản phẩm Quang & Cáp Intel® Ethernet
Thời hạn Phạm vi Bảo hành
3 năm kể từ ngày giao hàng
Thời hạn Bảo hành Mở rộng Khả dụng
Vận chuyển và đóng gói
Cập nhật phần mềm/chương trình cơ sở
Không áp dụng
CÁC ĐIỀU KHOẢN VÀ ĐIỀU KIỆN DỊCH VỤ NÀY ĐƯA RA CÁC QUYỀN PHÁP LÝ CỤ THỂ CHO KHÁCH HÀNG. KHÁCH HÀNG CŨNG CÓ THỂ CÓ CÁC QUYỀN KHÁC VÀ CÁC QUYỀN NÀY CÓ THỂ KHÁC NHAU GIỮA CÁC TIỂU BANG HOẶC GIỮA CÁC QUỐC GIA. MỘT SỐ LOẠI TRỪ HOẶC GIỚI HẠN CÁC ĐIỀU KHOẢN VÀ ĐIỀU KIỆN DỊCH VỤ NÀY CÓ THỂ KHÔNG ÁP DỤNG CHO KHÁCH HÀNG. KHÁCH HÀNG ĐƯỢC HỖ TRỢ TƯ VẤN PHÁP LUẬT NHÀ NƯỚC HOẶC QUỐC GIA ÁP
DỤNG ĐỂ XÁC ĐỊNH ĐẦY ĐỦ QUYỀN CỦA KHÁCH HÀNG.
Các sản phẩm liên quan
Bài viết này áp dụng cho các sản phẩm 90.
Các sản phẩm đã ngưng sản xuất
Cần thêm trợ giúp?
Gửi phản hồi
Kho lưu trữ khối lượng công việc tự động [AWR] của Oracle thu thập, các quy trình và duy trì số liệu thống kê hiệu suất cho mục đích phát hiện vấn đề và tự điều chỉnh. & NBSP;Báo cáo do AWR tạo ra là một báo cáo lớn và có thể mất nhiều năm kinh nghiệm để thực sự hiểu tất cả các khía cạnh của báo cáo này.Trong bài đăng này, chúng tôi sẽ cố gắng giải thích một số phần quan trọng của AWR, ý nghĩa của các phần đó và một số mẹo quan trọng.Xin lưu ý rằng việc giải thích tất cả các phần của AWR sẽ không thể thực hiện được vì vậy chúng tôi sẽ gắn bó với một số phần được sử dụng thường xuyên nhất.
Lưu ý rằng đây không phải là thông tin và mục tiêu toàn diện là giúp đưa ra một cái nhìn tổng quan về một vài phần chính cho Junior DBA như một mồi và khuyến khích họ xây dựng thêm kiến thức trong các lĩnh vực liên quan.
Để bắt đầu với chúng ta hãy đề cập đến một số mẹo quan trọng cấp cao liên quan đến AWR:
1. Thu thập nhiều báo cáo AWR: Thật có lợi khi có hai báo cáo AWR, một cho thời gian tốt và khác khi hiệu suất kém hoặc bạn có thể tạo ba báo cáo [trước/trong thời gian/sau khi báo cáo] trong vấn đề khung thời gian được trải nghiệm và so sánh nóvới khung thời gian trước và sau.: It’s beneficial to have two AWR Reports, one for the good time and other when performance is poor or you can create three reports [Before/Meantime/After reports] during the time frame problem was experienced and compare it with the time frame before and after.
2. Bám sát thời gian cụ thể: Bạn phải có thời gian cụ thể khi cơ sở dữ liệu chậm để bạn có thể chọn khung thời gian ngắn hơn để có được báo cáo chính xác hơn. You must have a specific time when Database was slow so that you can choose a shorter timeframe to get a more precise report.
3. Chia báo cáo AWR lớn thành các 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 cho & NBSP;3 giờ.Tốt hơn là có ba báo cáo trong một giờ.Điều này sẽ giúp cô lập vấn đề: Instead of having one report for long time like one report for 3 hrs. it is better to have three reports each for one hour. This will help to isolate the problem
4For RAC environment, you need to do it separately of all the instances in the RAC to see if all the instances are balanced the way they should be.
5. Sử dụng tro cũng: Sử dụng AWR để xác định các khu vực rắc rối và sau đó & nbsp;Sử dụng tro để xác nhận những khu vực đó. Use AWR to identify the troublesome areas and then use ASH to confirm those areas.
6. Tăng thời gian lưu giữ: & NBSP; Một số trường hợp bạn gặp nhiều vấn đề về hiệu suất hơn, bạn nên tăng thời gian lưu để bạn có thể có dữ liệu lịch sử để so sánh. Some instances where you get more performance issues you should increase the retention time so that you can have historical data to compare.
Các đơn vị thời gian được sử dụng trong các phần khác nhau của các báo cáo AWR
-> s -thứ hai -> cs -centisecond -thứ 100 của một giây -> ms -mili giây -1000 của một giây -> chúng tôi -micro giây -1000000 của một giây
-> cs – centisecond – 100th of a second
-> ms – millisecond – 1000th of a second
-> us – microsecond – 1000000th of a
second
Tiêu đề hàng đầu
Ý nghĩa của phần này:
Điều này chứa thông tin về cơ sở dữ liệu và môi trường.Cùng với ID và thời gian chụp nhanh.Điều quan trọng cần chú ý là cấu hình như CPU và bộ nhớ không thay đổi khi hiệu suất bị suy giảm.
& nbsp; tham số & nbsp; & nbsp;& nbsp;PARAMETER | DESCRIPTION | ANALYSIS |
& nbsp; thời gian dbDB TIME | Thời gian dành trong cơ sở dữ liệu trong thời gian trôi qua hoặc tổng thời gian được thực hiện bởi tất cả các phiên trong cơ sở dữ liệu trong thời gian ’đã qua. OR Sum of the time taken by all sessions in the database during the ‘Elapsed’ time.DB Time= CPU Time + Non IDLE wait time. Note: it does not include background processes | & nbsp; thời gian db> thời gian trôi qua sẽ có nghĩa là các phiên hoạt động đồng thời trên cơ sở dữ liệu Bạn cam tìm các phiên hoạt động trung bình trong thời gian AWR: Thời gian DB/ELAPSED & NBSP; => 1964,97/899,99 = 2,18 Vì vậy, tải cơ sở dữ liệu [phiên hoạt động trung bình] = 2.18 [Ý tưởng tương tự như tải CPU trên UNIX] Nó có nghĩa là Có thể là ~ 2 người dùng đã hoạt động trên cơ sở dữ liệu trong thời gian đã trôi qua.hoặc có thể là 4 người dùng đã hoạt động trong thời gian trôi qua/2 mỗi người hoặc có thể là 8 người dùng đã hoạt động trong thời gian trôi qua/4 mỗi người hoặc có thể là 64 người dùng đã hoạt động trong thời gian trôi qua/32 Nếu thời gian DB có giá trị cao hơn có nghĩa là hoạt động/phiên DB cao trong thời gian AWR. Báo cáo AWR rằng chúng tôi sẽ xem xét dưới đây dựa trên thời gian DB này. Điều này có nghĩa là trong mỗi phút thời gian trôi qua, có 2,2 phút làm việc trong cơ sở dữ liệu |
& nbsp; thời gian trôi quaELAPSED TIME | Thời gian thời gian mà báo cáo AWR này đã được tạo ra. | Thời gian trôi qua nên chứa thời lượng vấn đề.Chụp ảnh nhanh tay nếu được yêu cầu Take manual snapshots if required |
CPUs | Số lượng chủ đề cho mỗi lõi.Nó không phải là CPU thực tế của người Viking. | |
& nbsp; thời gian khởi động | Thời gian khởi động cơ sở dữ liệu | |
RAC | Nếu bạn có nhiều hơn một nút thì hãy lấy AWR từ tất cả các nút nếu bạn không biết các vấn đề đang xảy ra trong nút nào. |
Hồ sơ tải
Ý nghĩa của phần này:
Điều này chứa thông tin về cơ sở dữ liệu và môi trường.Cùng với ID và thời gian chụp nhanh.Điều quan trọng cần chú ý là cấu hình như CPU và bộ nhớ không thay đổi khi hiệu suất bị suy giảm.
& nbsp; tham số & nbsp; & nbsp;& nbsp;
- & nbsp; thời gian db
- Thời gian dành trong cơ sở dữ liệu trong thời gian trôi qua hoặc tổng thời gian được thực hiện bởi tất cả các phiên trong cơ sở dữ liệu trong thời gian ’đã qua.
- & nbsp; thời gian db> thời gian trôi qua sẽ có nghĩa là các phiên hoạt động đồng thời trên cơ sở dữ liệu
- Hàng mỗi loại cũng có thể được xem xét ở đây để xem các loại lớn có xảy ra không.
- Phần này có thể giúp trong thử nghiệm tải cho các bản phát hành ứng dụng.Bạn có thể so sánh phần này cho đường cơ sở cũng như tình huống tải cao.
& nbsp; tham số | & nbsp; mô tả | & nbsp; |
& nbsp; làm lại kích thước [byte]Redo Size [Bytes] | Các nguồn làm lại chính là [theo thứ tự giảm dần]: chèn, cập nhật và xóa.Để chèn và cập nhật s | Số lượng không đáng sợ lắm trong báo cáo của chúng tôi Các số liệu làm lại cao có nghĩa là rất nhiều dữ liệu mới đang được lưu vào cơ sở dữ liệu hoặc dữ liệu hiện tại đang trải qua rất nhiều thay đổi. Bạn sẽ làm gì nếu bạn thấy rằng thế hệ làm lại quá cao [và không có lý do kinh doanh cho điều đó]?Không có nhiều thực sự - vì không có SQL SQL được đặt hàng bằng cách làm lại trong báo cáo AWR. Chỉ cần giữ một mắt mở cho bất kỳ hoạt động DML đáng ngờ.Bất kỳ tuyên bố bất thường?Hoặc các tuyên bố thông thường được xử lý thông thường hơn thường xuyên?Hoặc tạo ra nhiều hàng trên mỗi lần thực hiện hơn bình thường?Ngoài ra, hãy chắc chắn để có một cái nhìn tốt trong phần Thống kê phân đoạn [các phân đoạn bằng cách viết vật lý, các phân đoạn theo thay đổi khối DB, v.v.] để xem có bất kỳ manh mối nào ở đó không. |
& NBSP; DB CPU | Đó là lượng thời gian CPU dành cho các cuộc gọi của người dùng.Giống như thời gian DB, nó không bao gồm quá trình nền.Giá trị là tính bằng micro giây | Chúng tôi có 8 lõi và vì vậy chúng tôi có khả năng sử dụng & nbsp; 8 giây thời gian CPU mỗi giây.Trong trường hợp này, DB CPU [s]: 1.9 [mỗi giây] đang báo cáo rằng hệ thống đang sử dụng 1,9 giây CPU của 8 giây tiềm năng/giây mà nó có thể sử dụng. Chúng tôi không bị ràng buộc CPU is using 1.9 seconds of CPU of the potential 8 seconds/second that it can use.We are not CPU Bound |
& nbsp; đọc logic | & nbsp; nhất quán getS + db block getS = logic reads Như một quá trình, Oracle sẽ cố gắng xem liệu dữ liệu có sẵn trong bộ đệm bộ đệm, tức là SGA không? Nếu có, thì đọc logic tăng lên 1. Để giải thích thêm một chút, nếu Oracle lấy dữ liệu trong một khối phù hợp với một thời điểm nhất định, thì một bộ đếm có tên là sự nhất quán được tăng lên 1. Nhưng nếu dữ liệu được tìm thấy trong chế độ hiện tại, nghĩa là bản sao cập nhật nhất của dữ liệu trong khối đó, vì nó ngay bây giờ hoặc hiện tại nó sẽ tăng một tên truy cập khác DB DB Block Gets. Do đó, một lần đọc logic được tính toán là = tổng số lượng nhất quán của GET GET + tổng số khối DB DB được nhận. Hai giá trị cụ thể này có thể được quan sát trong phần Số liệu thống kê hoạt động thể hiện. | & nbsp; đọc logic và vật lý kết hợp cho thấy số đo về số lượng IO, [vật lý và logic] mà cơ sở dữ liệu đang thực hiện .. Nếu đây là cao, hãy truy cập phần SQL SQL bằng cách đọc logic.Điều đó có thể giúp chỉ ra SQL nào có nhiều lần đọc logic hơn. |
& nbsp; truy vấn người dùng & nbsp; & nbsp;& nbsp; | & nbsp; số lượng truy vấn người dùng được tạo | |
& nbsp; Parses & nbsp; & nbsp;& nbsp; | Tổng số tất cả các phân tích cú pháp, cứng và mềm | |
& nbsp; phân tích cú pháp cứng | Các phân tích cú pháp yêu cầu phân tích hoàn toàn mới của câu lệnh SQL.Chúng tiêu thụ cả chốt và khu vực hồ bơi chung. | Phân tích cú pháp khó có thể chấp nhận được bao nhiêu? Nó phụ thuộc vào quá nhiều thứ, như số lượng CPU, số lượng thực thi, mức độ nhạy cảm với các tham số SQL, v.v.đề xuất một vấn đề [nếu cơ sở dữ liệu có một số lượng lớn CPU, giả sử, trên 100, các số đó sẽ được mở rộng tương ứng].Nó cũng giúp xem số lượng phân tích khó khăn là % thực thi [đặc biệt là nếu bạn ở trong vùng màu xám]. Nếu bạn nghi ngờ rằng phân tích cú pháp quá mức đang làm tổn thương hiệu suất cơ sở dữ liệu của bạn: 1] Kiểm tra phần Thống kê mô hình thời gian của Phần [thời gian phân tích khó khăn, thời gian phân tích đã trôi qua, v.v.] 2] Xem liệu có bất kỳ dấu hiệu tranh chấp bộ đệm thư viện nào trong 5 sự kiện 3] Xem nếu CPU là một vấn đề. |
& nbsp; phân tích cú pháp mềm: | Các phân tích mềm không được liệt kê nhưng có nguồn gốc từ việc trừ đi các phân tích cú pháp từ phân tích cú pháp.Một phân tích mềm tái sử dụng một phân tích cứng trước đó; do đó nó tiêu thụ ít tài nguyên hơn rất nhiều. | |
& nbsp; đọc vật lý & nbsp; & nbsp;& nbsp;Physical Reads | & nbsp; Nhưng nếu nó không tìm thấy dữ liệu trong bộ đệm bộ đệm, thì nó sẽ đọc nó từ khối vật lý và tăng số lượng đọc vật lý lên 1. Rõ ràng, bộ đệm sẽ ít tốn kém hơn so với cơ sở dữ liệu phải hoạt động mạnh hơn [và nhiều hơn nữa] để có được dữ liệu.Về cơ bản thời gian sẽ mất nếu có sẵn trong bộ đệm bộ đệm + thời gian thực sự được thực hiện để tìm hiểu từ khối vật lý. | & nbsp; nếu đây là cao, hãy truy cập phần SQL bằng cách đọc vật lý.Điều đó có thể giúp chỉ ra SQL nào có nhiều hơn & nbsp; đọc vật lý.If this is high go to section “SQL by Physical reads”. That may help in pointing which SQL is having more Physical reads. |
& nbsp; thực thi & nbsp; [sql] | & nbsp; nếu thực hiện mỗi giây trông rất lớn thì đó là một lá cờ đỏ. Ví dụ: Các số này, kết hợp với việc sử dụng CPU cao, đủ để nghi ngờ có thể có chuyển đổi ngữ cảnh là nghi ngờ chính: câu lệnh SQL chứa hàm PL/SQL, thực hiện câu lệnh SQL hàng trăm ngàn thời gian cho mỗi cuộc gọi chức năng. Nếu nó cao thì nó cũng gợi ý rằng hầu hết các tải trọng cơ sở dữ liệu đều rơi vào các câu lệnh SQL trong các thói quen PL/SQL. | |
Cuộc gọi người dùng | Số lượng cuộc gọi từ quy trình người dùng vào cơ sở dữ liệu - những thứ như phân tích cú pháp | & nbsp; Đây là một thông tin cực kỳ hữu ích, bởi vì & nbsp; & nbsp; nó đặt quy mô cho các số liệu thống kê khác [như cam kết, phân tích cú pháp cứng, v.v.]. Cụ thể, khi cơ sở dữ liệu thực hiện nhiều lần cho mỗi cuộc gọi của người dùng, đây có thể là một dấu hiệu của việc chuyển đổi ngữ cảnh quá mức [ví dụ: hàm PL/SQL trong câu lệnh SQL có tên là quá thường xuyên vì một kế hoạch xấu].Trong những trường hợp như vậy, xem xét SQL được đặt hàng bởi các vụ hành quyết, sẽ là bước tiếp theo hợp lý. |
& nbsp; đăng nhập & nbsp; & nbsp;& nbsp; | Đăng nhập - Thực sự có nghĩa là ý nghĩa của nó.Số lượng đăng nhập | Thiết lập kết nối cơ sở dữ liệu mới cũng tốn kém [và thậm chí đắt hơn trong trường hợp kiểm toán hoặc kích hoạt].Các cơn bão đăng nhập của người Viking được biết là tạo ra các vấn đề hiệu suất rất nghiêm trọng.Nếu bạn nghi ngờ rằng số lượng logons cao đang làm giảm hiệu suất của bạn, hãy kiểm tra quản lý kết nối của Google đã trôi qua thời gian trong thời gian của mô hình thời gian. |
Loại | & nbsp; Sắp xếp hoạt động tiêu thụ tài nguyên.Ngoài ra, các loại đắt tiền có thể khiến SQL của bạn thất bại vì hết không gian nhiệt độ.Tuy nhiên, cá nhân tôi hiếm khi tìm thấy số liệu thống kê sắp xếp đặc biệt hữu ích: thông thường, nếu các loại đắt tiền đang làm tổn thương hiệu suất SQL của bạn, bạn sẽ nhận thấy nó ở nơi khác trước. | |
& nbsp; thời gian db & nbsp; & nbsp;& nbsp; | & nbsp; Số lượng phiên hoạt động trung bình chỉ đơn giản là thời gian DB mỗi giây. | |
& nbsp; thay đổi khối & nbsp; | & nbsp; số lượng khối được sửa đổi trong khoảng thời gian mẫu |
Tỷ lệ phần trăm hiệu quả thể hiện
Ý nghĩa của phần này:
Quy tắc của ngón tay cái: Luôn giảm thiểu số lượng phân tích cú pháp cứng.Việc giảm này mang lại lợi ích của việc giảm thiểu chi phí CPU dành cho việc thực hiện công việc phân tích tốn kém.
Mỗi tỷ lệ ở đây sẽ đạt 100%
& nbsp; tham số | & nbsp; mô tả | & nbsp; |
Trong bộ nhớ sắp xếp % | Hiển thị %các hoạt động sắp xếp lần xảy ra trong bộ nhớ so với trong đĩa [không gian bảng tạm thời]. | Trong bộ nhớ sắp xếp thấp [ở độ cao 90 hoặc thấp hơn] cho biết các vấn đề pga_aggregate_target hoặc sort_area_size |
phân tích phân tích mềm % | Hiển thị % lần SQL trong nhóm chia sẻ được sử dụng. & NBSP; hiển thị tần suất các phiên phát hành một câu lệnh SQL đã có trong nhóm được chia sẻ và cách sử dụng phiên bản hiện có của câu lệnh đó. | Phân tích phân tích mềm là thấp cho thấy các vấn đề biến đổi và phiên bản liên kết. & NBSP; với 99,25 % cho phân tích cú pháp mềm có nghĩa là khoảng 0,75 % [100 - phân tích mềm] đang xảy ra để phân tích cú pháp cứng.Phân tích cứng thấp là tốt cho chúng ta. |
& nbsp;% CPU không phân chia | & nbsp; Oracle sử dụng CPU chủ yếu để thực thi câu lệnh nhưng không phải để phân tích cú pháp. | Nếu giá trị này gần 100% có nghĩa là hầu hết các tài nguyên CPU được sử dụng vào các hoạt động khác ngoài phân tích cú pháp, điều này tốt cho sức khỏe cơ sở dữ liệu. Hầu hết các tuyên bố của chúng tôi đã được phân tích cú pháp vì vậy chúng tôi không thực hiện được rất nhiều việc phân tích lại.RE phân tích cú pháp cao trên CPU và nên tránh. |
& nbsp; thực hiện để phân tích % | Cho thấy tần suất các câu lệnh SQL được phân tích cú pháp được sử dụng lại mà không phân tích lại. | & nbsp; Cách tính toán tỷ lệ này, nó sẽ là một con số gần 100 phần trăm khi ứng dụng thực hiện một câu lệnh SQL nhất định nhiều lần nhưng chỉ phân tích lại nó một lần. Nếu số lượng các cuộc gọi phân tích gần số lượng cuộc gọi thực thi, tỷ lệ này có xu hướng theo 0. Nếu số lượng thực thi tăng trong khi các cuộc gọi phân tích vẫn giống nhau, tỷ lệ này có xu hướng tăng lên. Khi con số này thấp, phân tích cú pháp đang tiêu thụ CPU và chia sẻ nhóm chia sẻ. |
& nbsp; phân tích cpu để phân tích lại % | Đưa ra tỷ lệ thời gian CPU dành cho các câu lệnh phân tích SQL. | Nếu giá trị thấp thì điều đó có nghĩa là có thể có một vấn đề phân tích cú pháp.Bạn có thể cần xem xét các vấn đề biến đổi liên kết hoặc vấn đề kích thước nhóm được chia sẻ.Nếu thấp, nó cũng & nbsp; có nghĩa là một số nút cổ chai có liên quan đến phân tích cú pháp.Chúng tôi sẽ bắt đầu bằng cách xem xét sự tranh chấp và tranh chấp bộ đệm thư viện trong các chốt nhóm được chia sẻ.Bạn có thể cần phải tăng nhóm chia sẻ.means some bottleneck is there related to parsing. We would start by reviewing library cache contention and contention in shared pool latches. You may need to increase the shared pool. |
& nbsp; bộ đệm đạt % | Các biện pháp được tìm thấy bao nhiêu lần một khối được yêu cầu trong bộ nhớ thay vì phải thực hiện một thao tác đọc đắt tiền trên đĩa để có được khối. | |
& nbsp; bộ đệm hiện đang%Buffer Nowait% | Cho biết % bộ đệm dữ liệu được truy cập trực tiếp mà không có bất kỳ thời gian chờ đợi. | Tỷ lệ này liên quan đến các yêu cầu mà một quy trình máy chủ tạo ra một bộ đệm cụ thể.Đây là tỷ lệ phần trăm của các yêu cầu trong đó bộ đệm được yêu cầu có sẵn ngay lập tức.Tất cả các loại bộ đệm được bao gồm trong thống kê này.Nếu tỷ lệ thấp, hãy kiểm tra phần Thống kê chờ bộ đệm của báo cáo để biết thêm chi tiết về loại khối nào được tranh cãi.Nhiều khả năng, RAM bổ sung sẽ được yêu cầu. |
& nbsp; thư viện đạt% | Hiển thị % lần SQL và PL/SQL được tìm thấy trong nhóm được chia sẻ. | & NBSP; Thư viện đạt % là tuyệt vời khi nó gần 100 %.Nếu điều này dưới 95%, chúng tôi sẽ điều tra kích thước của nhóm được chia sẻ. Trong khẩu phần này thấp thì chúng ta có thể cần phải: • Tăng tham số init Shared_pool_size.• Con trỏ_sharing có thể cần được đặt để buộc.• Shared_pool_reserved_size có thể quá nhỏ.• Chia sẻ không hiệu quả của mã SQL, PLSQL hoặc Java.• Không đủ việc sử dụng các biến liên kết |
Chốt đánh % | Hiển thị % chốt thời gian được mua mà không phải chờ đợi. | & nbsp; nếu chốt đạt % là |
Làm lại bây giờ% | Cho thấy liệu bộ đệm log làm lại có đủ kích thước hay không. |
Top 10 sự kiện chờ đợi trước bằng tổng số thời gian chờ đợi
Ý nghĩa của phần này:
Phần này rất quan trọng vì nó cho thấy những sự kiện cơ sở dữ liệu có thể tạo thành nút cổ chai cho hệ thống.
Ở đây, trước hết, kiểm tra lớp chờ nếu lớp chờ là & nbsp; người dùng I/O, I/O System I/O, & NBSP;Tiếp theo để xem là tổng thời gian chờ [giây] cho thấy DB đã chờ đợi bao nhiêu lần trong lớp này và sau đó đợi AVG [MS].Nếu tổng thời gian chờ [giây] cao nhưng chờ AVG [MS] thấp thì bạn có thể bỏ qua điều này.Nếu cả hai đều cao hoặc chờ AVG [MS] cao thì điều này phải điều tra thêm.
Lưu ý rằng có thể có những sự chờ đợi đáng kể không được liệt kê ở đây, vì vậy hãy kiểm tra phần Sự kiện chờ trước [Thống kê sự kiện] cho bất kỳ sự kiện chờ đợi thời gian nào khác.
Đối với các chờ đợi lớn nhất, hãy xem biểu đồ sự kiện chờ đợi để xác định phân phối chờ đợi.
& nbsp; tham số | & nbsp; mô tả | & nbsp; |
& NBSP; DB CPU | & NBSP; Thời gian chạy trong CPU [không bao gồm trong Run-Queue] | Ở đây 84,8 % là thời gian % dB cho sự kiện này thực sự cao! Thời gian DB là năm 1965 phút và CPU DB là [100000/60 = 1667 phút] 1667/1965 & NBSP; là 84,8% được thể hiện trong bảng trên. Chúng ta có thể tìm thấy 1] Tải CPU DB = Tổng thời gian chờ /thời gian AWR = 100.000 /[900*60] = 1,85 2] DB CPU Nâng & nbsp;% = db tải cpu/số lượng lõi = = [1,85/8] x 100 = 23% lõi máy chủ Quan trọng: Máy chủ của bạn có thể có các trường hợp cơ sở dữ liệu khác chia sẻ tài nguyên CPU, vì vậy cũng có tính đến các trường hợp đó. Ngoài ra, điều này không có nghĩa là CPU máy chủ được sử dụng 84%! |
& nbsp; tổng thời gian %db & nbsp; | & nbsp; tổng phải là khoảng 100%.Nếu đó là cách dưới 100% thì điều đó có nghĩa là các sự kiện chờ đợi không liên quan & nbsp; hoặc máy chủ bị quá tải. | |
& nbsp; enq tx - tranh chấp khóa hàng & nbsp; & nbsp;& nbsp; & nbsp; & nbsp;& nbsp; | & nbsp; đã chờ đợi các hàng bị khóa | Giá trị tham số này hiện chỉ là 0,2% tổng thời gian DB vì vậy chúng tôi không phải lo lắng nhiều về nó. Nói rằng nó có giá trị cao hơn, 10% sau đó chúng ta sẽ phải xem xét nguyên nhân gốc. Bạn sẽ phải truy cập các phân đoạn của các phân đoạn của Row Lock chờ đợi và xem những bảng nào đang bị khóa và sau đó bạn sẽ phải xem SQL_ID này được sử dụng. |
& nbsp; tệp db đọc tuần tự & nbsp; & nbsp;& nbsp; & nbsp; & nbsp;& nbsp; | & nbsp; khối I/O khối đơn Đọc tuần tự là một chỉ mục đọc theo sau là bảng đọc vì nó đang thực hiện tra cứu chỉ mục cho biết chính xác khối nào sẽ đi đến | & nbsp; cuộc gọi I/O trung bình là 2ms không cao lắm.Nếu bạn đã nói rằng ví dụ trung bình chờ rất cao 100ms hoặc 200ms, điều đó có nghĩa là đĩa của bạn chậm Các SQL của bạn có trả lại quá nhiều hàng không, có phải là phản hồi I/O khá tệ trên máy chủ, là DB không có kích thước để bộ đệm đủ bộ kết quả Bạn cần phải xem phần sau đó phần Tệp IO IO STATS trong báo cáo AWR. Sự kiện chỉ ra rằng quét chỉ mục đang diễn ra trong khi đọc dữ liệu từ bảng.Cao không.của sự kiện như vậy có thể là một nguyên nhân của các chỉ mục không chọn lọc, tức là Trình tối ưu hóa Oracle không chọn các chỉ mục thích hợp từ tập hợp các chỉ mục có sẵn.Điều này sẽ dẫn đến hoạt động IO bổ sung và sẽ góp phần chậm trễ trong việc thực hiện SQL.Nói chung là không cao.có thể cho ứng dụng được điều chỉnh đúng cách có hoạt động giao dịch cao. • Nếu có liên quan đến phạm vi chỉ mục, có thể truy cập nhiều khối hơn mức cần thiết nếu chỉ mục không chọn lọc. Buộc hoặc cho phép sử dụng chỉ mục chọn lọc hơn, chúng ta có thể truy cập cùng một dữ liệu bảng bằng cách truy cập ít khối chỉ mục hơn [vàLàm ít I/OS vật lý hơn]. • Nếu các chỉ mục bị phân mảnh, chúng ta phải truy cập nhiều khối hơn vì có ít dữ liệu chỉ mục trên mỗi khối.Trong trường hợp này, việc xây dựng lại chỉ mục sẽ nén nội dung của nó thành ít khối hơn. • Nếu chỉ mục được sử dụng có hệ số phân cụm lớn, thì phải truy cập nhiều dữ liệu bảng hơn để có được các hàng trong mỗi khối chỉ mục.Bằng cách xây dựng lại bảng với các hàng được sắp xếp theo các cột chỉ mục cụ thể, chúng tôi có thể giảm hệ số phân cụm và do đó số lượng khối dữ liệu bảng mà chúng tôi phải truy cập cho từng khối chỉ mục. |
& nbsp; tập tin nhật ký đồng bộ hóa & nbsp; & nbsp;& nbsp; | Ở đây chờ AVG [MS] là 6 không phải là số khóc.Trên 20ms, chúng tôi không xem xét số lượng tốt, hãy truy cập vào phần Thống kê hoạt động của phiên bản và xem có bao nhiêu cam kết thực sự đã xảy ra và sau đó xem ở đây rằng phần trăm cam kết phải chờ đợi. Hãy đánh giá cao các giao dịch ngắn, các cam kết thường xuyên là tài sản của ứng dụng OLTP. Above 20ms we don’t consider good numberAlso go to “Instance Activity Stats” section and see how many commits actually happened and then see here that what % of COMMITS have to wait.Remember that short transactions, frequent commits is property of OLTP Application. | |
& NBSP; Tệp DB phân tán được đọc | gây ra do quét bảng đầy đủ có thể là do & nbsp; không đủ & nbsp; chỉ mục hoặc không có hiệu quả của số liệu thống kê cập nhật | Để tránh sự kiện này, hãy xác định tất cả các bảng mà FTS đang xảy ra và tạo các chỉ mục thích hợp để Oracle sẽ thực hiện quét chỉ mục thay vì FTS.Việc quét chỉ số sẽ giúp giảm không.của các hoạt động IO. Để có được một ý tưởng về các bảng mà FTS đang diễn ra, vui lòng tham khảo các phân đoạn thống kê của Cameron -Phần này liệt kê cả hai bảng và chỉ mục mà các lần đọc vật lý đang xảy ra.Xin lưu ý rằng các bài đọc vật lý không nhất thiết có nghĩa là FTS nhưng khả năng của FTS. |
& nbsp; đồng thời, lớp học chờ | & nbsp; lớp chờ đồng thời không tốt và nếu cao thì cần phải được phân tích. | |
& nbsp; đường dẫn trực tiếp đọc temp hoặc đường dẫn trực tiếp ghi nhiệt độ | & nbsp; Sự kiện chờ đợi này hiển thị hoạt động tệp temp [Sắp xếp, băm, bảng temp, bitmap] Kiểm tra PGA & NBSP; tham số & nbsp; hoặc sắp xếp khu vực hoặc các tham số khu vực băm.Bạn có thể muốn tăng chúng check pga parameter or sort area or hash area parameters. You might want to increase them | |
& nbsp; lớp chờ, cột | & nbsp; giúp phân loại xem vấn đề có liên quan đến ứng dụng hoặc cơ sở hạ tầng hay không. | Các sự kiện chờ được phân loại rộng rãi theo các lớp chờ khác nhau: Ứng dụng quản trị Người dùng đồng thời IO Hệ thống IO Cấu hình Cấu hình IDLE Cấu hình IDLE Mạng không hoạt động |
& nbsp; bộ đệm bận chờ đợi | & nbsp; chỉ ra rằng khối cụ thể đang được sử dụng bởi nhiều quy trình.Khi quá trình đầu tiên đọc khối, các quy trình khác đã chờ đợi vì khối không được chia sẻ nhiều hơn.Kịch bản điển hình cho sự kiện này xảy ra là, khi chúng ta có quy trình hàng loạt cơ sở dữ liệu bỏ phiếu liên tục bằng cách thực hiện SQL cụ thể nhiều lần và có nhiều hơn một trường hợp song song chạy cho quy trình.Tất cả các phiên bản của quy trình sẽ cố gắng truy cập cùng các khối bộ nhớ như SQL mà chúng đang thực thi là như nhau.Đây là một trong những tình huống mà chúng tôi trải nghiệm sự kiện này. | |
& NBSP; ENQ: TX - Hàng khóa tranh chấp: | & NBSP; Tính nhất quán của dữ liệu bảo trì Oracle với sự trợ giúp của cơ chế khóa.Khi một hàng cụ thể đang được sửa đổi bởi quy trình, thông qua cập nhật/ xóa hoặc chèn hoạt động, Oracle cố gắng có được khóa trên hàng đó.Chỉ khi quá trình có được khóa, quá trình mới có thể sửa đổi hàng nếu không quy trình chờ khóa.Tình huống chờ đợi này kích hoạt sự kiện này.Khóa được phát hành bất cứ khi nào một cam kết được ban hành bởi quy trình đã có được khóa cho hàng.Khi khóa được phát hành, các quy trình đang chờ trên sự kiện này có thể có được khóa trên hàng và thực hiện thao tác DML. | |
& NBSP; ENQ: UL - Sự tranh chấp: | & nbsp; enq này chờ xảy ra khi ứng dụng khóa rõ ràng bởi & nbsp; thực thi lệnh bảng khóa. | |
& NBSP; ENQ: TM - Sự tranh chấp | & nbsp; Điều này thường xảy ra do một ràng buộc khóa nước ngoài bị thiếu trên một bảng mà một phần của hoạt động DML. |
Máy chủ CPU
Ý nghĩa của phần này:
Một mức độ cao của việc sử dụng CPU DB trong các sự kiện tiền cảnh hàng đầu [hoặc CPU CPU: %CPU bận rộn] không nhất thiết có nghĩa là CPU là một nút cổ chai.Trong ví dụ này, chúng tôi cũng có DB CPU là danh mục tiêu thụ cao nhất trong 10 sự kiện tiền cảnh hàng đầu
Nhìn vào các phần CPU và CPU của máy chủ.Những điều quan trọng để tìm kiếm là các giá trị mà%Idle Idle, trong phần CPU của máy chủ CPU và tổng số CPU CPU trong phần CPU CPU CPU.
Nếu%Idle Idle, thấp và tổng%CPU CPU cao thì trường hợp có thể có một nút cổ chai trong CPU [bị ràng buộc CPU].& nbsp; Nếu không, việc sử dụng CPU DB cao chỉ có nghĩa là cơ sở dữ liệu đang dành nhiều thời gian trong CPU [xử lý] so với I/O và các sự kiện khác.& nbsp; Trong cả hai trường hợp [CPU là nút cổ chai hay không] có thể có các SQL đắt tiền riêng lẻ với thời gian CPU cao, có thể chỉ ra mức tối ưu
Các kế hoạch thực thi, đặc biệt là nếu đi kèm & nbsp; với cao [bộ đệm] sẽ được.
Nếu bạn thấy trong trường hợp của chúng tôi, %Idle cao 74 %và %tổng số CPU chỉ là 7,45 nên CPU không phải là cổ chai trong ví dụ này.
& nbsp; tham số | & nbsp; mô tả | & nbsp; |
& nbsp; cpus | & nbsp; thực sự là chủ đề.Ở đây chúng tôi có 8 lõi và 8 luồng trên mỗi lõi để CPU = số lượng lõi x số luồng trên mỗi lõi = 8 x 8 = 64 Here we have 8 Cores and 8 Threads per Core so CPU = number of core X number of threads per core = 8 X 8 = 64 | |
& nbsp; tải trung bình | So sánh trung bình tải với lõi. Điều rất lý tưởng là tải trung bình & nbsp; nên ít hơn lõi mặc dù điều này có thể không xảy ra [bất kỳ điều gì cũng có thể không phải là vấn đề!] | |
%Idle | Có thể gây hiểu lầm vì đôi khi % IDLE của bạn có thể là 50 % nhưng máy chủ của bạn đang đói cho CPU. 50% có nghĩa là tất cả các lõi của bạn đều bận rộn.Bạn có thể có các luồng miễn phí [CPU] nhưng bạn không thể chạy hai quy trình đồng thời trên cùng một lõi. Tất cả % trong các báo cáo này được tính toán dựa trên CPU [thực sự là chủ đề] | |
Cores | Ở đây chúng tôi có 8 hệ thống lõi Chúng tôi có 8 lõi, có nghĩa là trong 60 phút, chúng tôi có 60 x 8 = 480 CPU MINSAND TOTAL Thời lượng AWR là 8 giờ 480x8 = 3840 phút CPU trong tổng số So we have 8 cores, meaning in a 60 min hour we have 60 X 8 = 480 CPU minsand total AWR duration is 8 hoursso 480X8 = 3840 CPU minutes in total |
Ví dụ CPU
Ý nghĩa của phần này:
Một mức độ cao của việc sử dụng CPU DB trong các sự kiện tiền cảnh hàng đầu [hoặc CPU CPU: %CPU bận rộn] không nhất thiết có nghĩa là CPU là một nút cổ chai.Trong ví dụ này, chúng tôi cũng có DB CPU là danh mục tiêu thụ cao nhất trong 10 sự kiện tiền cảnh hàng đầu
Nhìn vào các phần CPU và CPU của máy chủ.Những điều quan trọng để tìm kiếm là các giá trị mà%Idle Idle, trong phần CPU của máy chủ CPU và tổng số CPU CPU trong phần CPU CPU CPU.
Nếu%Idle Idle, thấp và tổng%CPU CPU cao thì trường hợp có thể có một nút cổ chai trong CPU [bị ràng buộc CPU].Mặt khác, việc sử dụng CPU DB cao chỉ có nghĩa là cơ sở dữ liệu đang dành nhiều thời gian trong CPU [xử lý] so với I/O và các sự kiện khác.Trong cả hai trường hợp [CPU là một nút cổ chai hay không] có thể có các SQL đắt tiền riêng lẻ với thời gian CPU cao, điều này có thể chỉ ra các kế hoạch thực hiện dưới mức tối ưu, đặc biệt là nếu đi kèm với cao [bộ đệm].
execution plans, especially if accompanied with high [buffer] gets.
Nếu bạn thấy trong trường hợp của chúng tôi, %Idle cao 74 %và %tổng số CPU chỉ là 7,45 nên CPU không phải là cổ chai trong ví dụ này.
Kích thước bộ nhớ cache
Ý nghĩa của phần này:
Một mức độ cao của việc sử dụng CPU DB trong các sự kiện tiền cảnh hàng đầu [hoặc CPU CPU: %CPU bận rộn] không nhất thiết có nghĩa là CPU là một nút cổ chai.Trong ví dụ này, chúng tôi cũng có DB CPU là danh mục tiêu thụ cao nhất trong 10 sự kiện tiền cảnh hàng đầu
Nhìn vào các phần CPU và CPU của máy chủ.Những điều quan trọng để tìm kiếm là các giá trị mà%Idle Idle, trong phần CPU của máy chủ CPU và tổng số CPU CPU trong phần CPU CPU CPU.
Ý nghĩa của phần này:
Một mức độ cao của việc sử dụng CPU DB trong các sự kiện tiền cảnh hàng đầu [hoặc CPU CPU: %CPU bận rộn] không nhất thiết có nghĩa là CPU là một nút cổ chai.Trong ví dụ này, chúng tôi cũng có DB CPU là danh mục tiêu thụ cao nhất trong 10 sự kiện tiền cảnh hàng đầu | Nhìn vào các phần CPU và CPU của máy chủ.Những điều quan trọng để tìm kiếm là các giá trị mà%Idle Idle, trong phần CPU của máy chủ CPU và tổng số CPU CPU trong phần CPU CPU CPU. | Nếu%Idle Idle, thấp và tổng%CPU CPU cao thì trường hợp có thể có một nút cổ chai trong CPU [bị ràng buộc CPU].Mặt khác, việc sử dụng CPU DB cao chỉ có nghĩa là cơ sở dữ liệu đang dành nhiều thời gian trong CPU [xử lý] so với I/O và các sự kiện khác.Trong cả hai trường hợp [CPU là một nút cổ chai hay không] có thể có các SQL đắt tiền riêng lẻ với thời gian CPU cao, điều này có thể chỉ ra các kế hoạch thực hiện dưới mức tối ưu, đặc biệt là nếu đi kèm với cao [bộ đệm]. | ||
Nếu bạn thấy trong trường hợp của chúng tôi, %Idle cao 74 %và %tổng số CPU chỉ là 7,45 nên CPU không phải là cổ chai trong ví dụ này. | Kích thước bộ nhớ cache | Từ Oracle 10g trở đi, máy chủ cơ sở dữ liệu thực hiện quản lý bộ nhớ tự động cho các thành phần PGA và SGA.Dựa trên tải, máy chủ cơ sở dữ liệu tiếp tục phân bổ hoặc giải quyết bộ nhớ được gán cho các thành phần khác nhau của SGA và PGA.Vì lý do này, chúng ta có thể quan sát các kích thước khác nhau cho bộ đệm bộ đệm và nhóm được chia sẻ, vào đầu hoặc cuối thời gian chụp nhanh AWR.If your usage is low [ 1 & nbsp; | & nbsp; hiển thị % SQL được thực hiện hơn 1 lần.% Nên rất gần với giá trị 100. | |
& nbsp; nếu tái sử dụng của bạn thấp [ | & nbsp; bộ nhớ cho sql w/exec> 1 | |||
& nbsp; từ không gian bộ nhớ được phân bổ cho con trỏ, hiển thị % nào đã được sử dụng bởi con trỏ hơn 1. | Thống kê mô hình thời gian | |||
& nbsp; phân tích mềm | & nbsp; có thể được nhận bằng cách trừ thời gian phân tích cú pháp từ khó phân tích |
Lớp học chờ phía trước
Ý nghĩa của phần này:
Điều này ít được sử dụng.Chờ đợi có thể có nhiều nguyên nhân có thể [trong các lớp khác nhau] tùy thuộc vào ngữ cảnh. & NBSP; Thông thường chỉ có một số ít thời gian chờ đợi, có thể được phân tích và nghiên cứu riêng biệt.
Có hơn 800 sự kiện chờ đợi riêng biệt.Oracle đã nhóm các sự kiện chờ đợi này trong 12 lớp chờ.Các lớp chờ này được chia thêm 2 loại, lớp chờ quản trị và lớp chờ ứng dụng.
Các lớp chờ này cung cấp thông tin tổng thể về việc việc chờ đợi xảy ra cho ứng dụng hay cho các sự kiện hệ thống.
& nbsp; tham số | & nbsp; mô tả | & nbsp; |
& nbsp; người dùng I/O | IO người dùng cao có nghĩa là, Từ nhóm các chỉ mục có sẵn, các chỉ số thích hợp không được sử dụng hoặc FTS đang xảy ra trên các bảng lớn với hàng triệu hàng |
Sự kiện chờ đợi tiền cảnh
Ý nghĩa của phần này:
Điều này ít được sử dụng.Chờ đợi có thể có nhiều nguyên nhân có thể [trong các lớp khác nhau] tùy thuộc vào ngữ cảnh. & NBSP; Thông thường chỉ có một số ít thời gian chờ đợi, có thể được phân tích và nghiên cứu riêng biệt.
Có hơn 800 sự kiện chờ đợi riêng biệt.Oracle đã nhóm các sự kiện chờ đợi này trong 12 lớp chờ.Các lớp chờ này được chia thêm 2 loại, lớp chờ quản trị và lớp chờ ứng dụng.
Các lớp chờ này cung cấp thông tin tổng thể về việc việc chờ đợi xảy ra cho ứng dụng hay cho các sự kiện hệ thống.
& nbsp; tham số | & nbsp; mô tả | & nbsp; |
& nbsp; người dùng I/O | IO người dùng cao có nghĩa là, | Từ nhóm các chỉ mục có sẵn, các chỉ số thích hợp không được sử dụng hoặc FTS đang xảy ra trên các bảng lớn với hàng triệu hàng Sự kiện chờ đợi tiền cảnh Chủ yếu là & nbsp; các sự kiện nhàn rỗi được liệt kê xuống cuối cùng không nên tập trung nhiều. Điều này rất hữu ích bởi vì có thể có các sự kiện chờ báo cáo tốn thời gian không xuất hiện trong các sự kiện tiền cảnh thời gian hàng đầu của nhóm. Đối với các chờ đợi lớn hơn, hãy xem biểu đồ sự kiện chờ đợi để xác định phân phối chờ đợi.Có phải chúng được phân cụm chặt chẽ xung quanh một giá trị trung bình hay có một phương sai rộng lớn của các giá trị? & NBSP; Có một số lượng lớn chờ đợi nhỏ hơn hoặc một vài sự chờ đợi lớn hơn? |
Sql*tin nhắn ròng từ máy khách & nbsp; & nbsp;& nbsp; | & nbsp; sự kiện chờ đợi không hoạt động | |
Chúng ta có thể tìm thấy số phiên không hoạt động trung bình của sự kiện chờ đợi này | Số phiên không hoạt động = Tổng thời gian chờ/ [thời gian AWR * 60] | |
= 12679570/ [900 * 60] | = 235 Phiên không hoạt động trung bình | |
Điều này không có nghĩa là các phiên người dùng như vậy nhưng số lượng kết nối đó từ nhóm kết nối máy chủ ứng dụng.Db file sequential reads | & nbsp; đường dẫn trực tiếp đọc/ghi vào tempUsually indicates memory starvation, look at the db cache analysis and for buffer busy waits along with cache latch issues. | |
& nbsp; hiển thị phân loại quá mức/băm/bảng nhiệt độ toàn cầu/hoạt động bitmap sẽ đi đến không gian bảng tạm thời của bạn.Xem lại cài đặt PGA_AGGREGATE_TARGET.Ngay cả khi có vẻ như nó đủ lớn, nếu bạn đang ghi nhiều loại nhỏ vào đĩa, điều đó có thể có nghĩa là tải người dùng của bạn đang sử dụng quá mức.Db file scattered reads | & nbsp; sql*tin nhắn ròng cho máy kháchUsually indicates excessive full table scans, look at the AWR segment statistics for tables that are fully scanned | |
& nbsp; sql*tin nhắn ròng cho khách hàng chờ đợi hầu như luôn chỉ ra sự tranh chấp mạng. | & nbsp; sql*mạng nhiều dữ liệu khác từ máy kháchLog file related waits: Look at excessive log switches, excessive commits or slow IO subsystems. |
& nbsp; nếu nó rất thấp thì nó chỉ ra rằng kích thước đơn vị dữ liệu phiên của Oracle Net có thể được đặt chính xác.
Ý nghĩa của phần này:
& NBSP; Tệp DB đọc tuần tự
& nbsp; tham số | & nbsp; mô tả | & nbsp; |
& nbsp; người dùng I/O | IO người dùng cao có nghĩa là, Từ nhóm các chỉ mục có sẵn, các chỉ số thích hợp không được sử dụng hoặc FTS đang xảy ra trên các bảng lớn với hàng triệu hàng Sự kiện chờ đợi tiền cảnh Chủ yếu là & nbsp; các sự kiện nhàn rỗi được liệt kê xuống cuối cùng không nên tập trung nhiều. Điều này rất hữu ích bởi vì có thể có các sự kiện chờ báo cáo tốn thời gian không xuất hiện trong các sự kiện tiền cảnh thời gian hàng đầu của nhóm. |
Đối với các chờ đợi lớn hơn, hãy xem biểu đồ sự kiện chờ đợi để xác định phân phối chờ đợi.Có phải chúng được phân cụm chặt chẽ xung quanh một giá trị trung bình hay có một phương sai rộng lớn của các giá trị? & NBSP; Có một số lượng lớn chờ đợi nhỏ hơn hoặc một vài sự chờ đợi lớn hơn?
Ý nghĩa của phần này:
Sql*tin nhắn ròng từ máy khách & nbsp; & nbsp;& nbsp;
& nbsp; sự kiện chờ đợi không hoạt động
Chúng ta có thể tìm thấy số phiên không hoạt động trung bình của sự kiện chờ đợi này
Số phiên không hoạt động = Tổng thời gian chờ/ [thời gian AWR * 60]
Thời gian đồng hồ quan sát của quá trình/SQL].Thời gian trôi qua cho MultiThreaded & NBSP; SQL sẽ là tổng số thời gian trôi qua cho tất cả công nhân hoặc nô lệ song song.
Lưu ý 2: & NBSP; Các phần SQL SQL thường có thể chứa cuộc gọi PL/SQL có chứa SQLS.Vì vậy, trong trường hợp này, quy trình wf_engine [thông qua thủ tục] & nbsp; cuối cùng gọi SQL B6MCN03JVFG41.Và bên trong gói này, nó đang chạy truy vấn SQL chạy trong dòng 2 được chèn vào XXINV7566_IQR, .. ..
& nbsp; tham số | & nbsp; mô tả | & nbsp; |
& nbsp; elaps mỗi [s] | & nbsp; Thời gian trôi qua tính bằng giây để thực hiện SQL. | |
& nbsp; bị bắt SQL tài khoản cho 79,1% tổng thời gian db total DB Time | & nbsp; cho thấy có bao nhiêu % SQL báo cáo AWR này có thể nắm bắt và cho chúng tôi thấy | & nbsp; hãy nhớ rằng các báo cáo AWR cho thấy những SQL đã ở trong nhóm được chia sẻ vào cuối thời gian AWR. Con số này phải có giá trị cao, điều đó có nghĩa là chúng tôi có thể nắm bắt được tất cả các SQL đã tiêu thụ thời gian DB. Nếu đây là số thấp hơn là cố gắng tạo AWR cho thời lượng snap thấp hơn để chúng tôi có thể nắm bắt được các SQL cần thiết đang tiêu thụ thời gian DB |
ExecutionsExecutions | Tổng số không.trong các lần thực hiện cho SQL trong hai giai đoạn ảnh chụp nhanh. Một điểm quan trọng, nếu đôi khi thực thi là 0, điều đó không có nghĩa là truy vấn không thực thi, đây có thể là trường hợp khi truy vấn vẫn đang thực thi và bạn đã báo cáo AWR.Đó là lý do tại sao hoàn thành truy vấn không được đưa tin trong báo cáo. An important point, if executions is 0 also sometimes, it doesn’t means query is not executing, this might be the case when query was still executing and you took AWR report. That’s why query completion was not covered in Report. | |
& NBSP; Mô -đun SQLSQL Module | Cung cấp chi tiết mô -đun đang thực hiện SQL.Tên quy trình ở cấp hệ điều hành được hiển thị dưới dạng tên mô -đun SQL. Nếu tên mô -đun bắt đầu với bất kỳ tên nào được đưa ra dưới đây, thì hãy xem xét các SQL này cho mục đích điều chỉnh vì các SQL này là SQL nội bộ của Oracle, DBMS, SQLPLUSW, Toad, RMAN, SQL, Trình quản lý doanh nghiệp, Oracle, MMON_SLAVE, EMAGENT ETC Trong danh sách XXIN1768 có hai sqlids. & NBSP; ID SQL #1 là mã PL/SQL dưới dạng trình bao bọc và mất khoảng 53k giây.SQL # 2 mất 51k giây và dường như được gọi trong SQL ID # 1, vì tên mô -đun của chúng giống nhau.Vì câu lệnh SQL#2 Insert mất gần như tất cả thời gian, vì vậy chúng tôi tập trung vào truy vấn này để điều chỉnh. | |
& nbsp; elasped thời gian | & nbsp; Thời gian trôi qua là tổng của tất cả thời gian thực hiện riêng lẻ cho SQL_ID.Vì vậy, nếu nhiều phiên thực hiện cùng một SQLS, thời gian trôi qua có thể lớn hơn khoảng thời gian của hai snap_ids. |
SQL được đặt hàng theo thời gian CPU
Ý nghĩa của phần này:
Các phần hữu ích nhất là SQL được đặt hàng theo thời gian trôi qua, thời gian CPU, được và đọc.Tất cả các phần có thể hữu ích trong việc xác định nếu một SQL cụ thể từ một mô -đun cụ thể là
Chạy trong thời gian báo cáo AWR
Tuy nhiên, trong hầu hết các trường hợp, phần này không tiết lộ nhiều thông tin hơn so với phần SQL được đặt hàng theo phần Thời gian đã qua.Tuy nhiên, nó sắp xếp theo CPU và có thể xuất ra SQLS không
Trong phần trước.
& nbsp; tham số | & nbsp; mô tả | & nbsp; |
& nbsp; elaps mỗi [s] | & nbsp; Thời gian trôi qua tính bằng giây để thực hiện SQL. Second SQL is the inside part of first PLSQL.It is accounting huge % of the DB CPU and remember that DB CPU was the top event in our AWR. |
& nbsp; bị bắt SQL tài khoản cho 79,1% tổng thời gian db
Ý nghĩa của phần này:
Các phần hữu ích nhất là SQL được đặt hàng theo thời gian trôi qua, thời gian CPU, được và đọc.Tất cả các phần có thể hữu ích trong việc xác định nếu một SQL cụ thể từ một mô -đun cụ thể là
Chạy trong thời gian báo cáo AWR
Tuy nhiên, trong hầu hết các trường hợp, phần này không tiết lộ nhiều thông tin hơn so với phần SQL được đặt hàng theo phần Thời gian đã qua.Tuy nhiên, nó sắp xếp theo CPU và có thể xuất ra SQLS không
Trong phần trước.
& nbsp; bản ghi hàng đầu trong bảng này
Báo cáo thứ nhất và thứ hai là một phần của cùng một giao dịch.SQL thứ hai là phần bên trong của PLSQL đầu tiên. Nó chiếm phần trăm lớn của CPU DB và hãy nhớ rằng DB CPU là sự kiện hàng đầu trong AWR của chúng tôi.
SQL được đặt hàng bởi GetS
Nhưng hãy nhớ rằng SQL có thể có một kế hoạch thực hiện tốt và chỉ cần làm rất nhiều việc.Vì vậy, chúng ta cần đưa vào tính đến khối lượng dữ liệu [và các tham số đang được chuyển cho truy vấn].
Bạn có thể dễ dàng xem các kế hoạch thực thi bằng cách chạy & nbsp;@awrsqrpt.sql & nbsp; và chuyển vi phạm sql_id dưới dạng tham số.
Bạn có thể tham khảo SQL SQL được đặt hàng bởi các vụ hành quyết sau khi đọc phần này.
& nbsp; tham số | & nbsp; mô tả | & nbsp; |
& nbsp; & nbsp; nhận được mỗi người thực hiện | & nbsp; có bao nhiêu khối được đọcHOW MANY BLOCKS WERE READ | & nbsp; Insert Statement in XXINV1738 MODULE & NBSP; đã được thực hiện quá cao, bạn cần phân tích SQL với một số đầu ra bổ sung như SQLT và SQLHC.has Gets per Exec that is too high, you need to analyze the SQL with some additional output such as sqlt and sqlhc. |
SQL được đặt hàng bằng cách đọc
Ý nghĩa của phần này:
Phần này báo cáo nội dung của khu vực SQL được đặt hàng theo số lượng lần đọc từ các tệp dữ liệu và có thể được sử dụng để xác định SQL gây ra các tắc nghẽn IO tiêu thụ các tài nguyên sau.
• Thời gian CPU cần thiết để tìm nạp dữ liệu không cần thiết.
• Tệp tài nguyên IO để tìm nạp dữ liệu không cần thiết.
• Tài nguyên bộ đệm để giữ dữ liệu không cần thiết.
• Thời gian CPU bổ sung để xử lý truy vấn sau khi dữ liệu được truy xuất vào bộ đệm.
• % Tổng số có thể được sử dụng để đánh giá tác động của từng tuyên bố.
Nếu chúng ta nói về thời gian chờ thì thời gian chờ đợi là thời gian chờ đợi cho các sự kiện không phải là Idle & nbsp; chờ đợi. & NBSP;Đối với khối đơn & nbsp; đọc và 'tệp db phân tán đọc' cho đa chặn & nbsp; đọc.
Khi các sự kiện chờ đợi như vậy được tìm thấy là các thành phần quan trọng của thời gian phản hồi, bước tiếp theo là tìm các câu lệnh SQL đọc nhiều khối nhất từ đĩa.Chúng tôi sẽ đề cập đến phần này sau đó.
Đây là & nbsp; là & nbsp; vật lý & nbsp; đọc & nbsp; từ đĩa
Nếu I/O Vật lý chờ đợi [ví dụ: DB Tệp đọc tuần tự, DB SCATTERED READ, ĐỌC PATH TRỰC TIẾP] tương đối cao thì phần này có thể cho biết SQL nào chịu trách nhiệm.
Phần này có thể giúp xác định SQLS chịu trách nhiệm cho I/O vật lý cao và có thể chỉ ra các kế hoạch thực thi dưới mức tối ưu & nbsp; đặc biệt nếu kế hoạch thực thi chứa toàn bộ bảng & NBSP; quét hoặc quét phạm vi chỉ số lớn [trong đó quét chỉ số chọn lọc hơn].
& nbsp; tham số | & nbsp; mô tả | & nbsp; |
& nbsp; & nbsp; nhận được mỗi người thực hiện | & nbsp; có bao nhiêu khối được đọc | |
& nbsp; Insert Statement in XXINV1738 MODULE & NBSP; đã được thực hiện quá cao, bạn cần phân tích SQL với một số đầu ra bổ sung như SQLT và SQLHC. | SQL được đặt hàng bằng cách đọc MTL_ITEM_CATEGORIES account for 51.32% and looking here the SQL_ID which is a top and having 40.18% TOTAL is using this table.Yousee here that although it has executed 73 times but reads per executions is high making it top query consuming physical i/o.In contrast query at number 4 in this table has been executed around 40k times but since reads per execution is low so number 4th query is not the top query to worry about. | |
Ý nghĩa của phần này: | Phần này báo cáo nội dung của khu vực SQL được đặt hàng theo số lượng lần đọc từ các tệp dữ liệu và có thể được sử dụng để xác định SQL gây ra các tắc nghẽn IO tiêu thụ các tài nguyên sau.Possible reasons for high Reads per Exec are use of unselective indexes require large numbers of blocks to be fetched where such blocks are not cached well in the buffer cache, index fragmentation, large Clustering Factor in index etc. |
• Thời gian CPU cần thiết để tìm nạp dữ liệu không cần thiết.
Ý nghĩa của phần này:
Phần này báo cáo nội dung của khu vực SQL được đặt hàng theo số lượng lần đọc từ các tệp dữ liệu và có thể được sử dụng để xác định SQL gây ra các tắc nghẽn IO tiêu thụ các tài nguyên sau.
• Thời gian CPU cần thiết để tìm nạp dữ liệu không cần thiết.
• Tệp tài nguyên IO để tìm nạp dữ liệu không cần thiết.
& nbsp; tham số | & nbsp; mô tả | & nbsp; |
& nbsp; & nbsp; nhận được mỗi người thực hiện | & nbsp; có bao nhiêu khối được đọc |
SQL được đặt hàng bởi các cuộc gọi phân tích
Ý nghĩa của phần này:
Phần này cho thấy số lần một câu lệnh được phân tích cú pháp so với số lần nó được thực hiện.Một đến một phân tích/thực thi có thể chỉ ra rằng:
• Các biến liên kết không được sử dụng.
• Trên RDBMS phiên bản 8172 và cao hơn tham số init.ora session_cached_cursors không được đặt trong init.ora [100 thường là giá trị bắt đầu được đề xuất].
• Nhóm được chia sẻ có thể quá nhỏ và phân tích cú pháp không được giữ lại đủ lâu cho nhiều lần thực hiện.
• init.ora con trỏ_sharing nên được thiết lập để buộc
Khi CPU CPU Parse là một thành phần quan trọng của tổng thời gian phản hồi, bước tiếp theo là tìm các câu lệnh SQL có nhiều phân tích.
AWR và StatSpack liệt kê các câu lệnh SQL như vậy trong các phần như SQL được đặt hàng bởi Parse Call Call.
Không gian bảng IO số liệu thống kê
Ý nghĩa của phần này:
Phần này cho thấy số lần một câu lệnh được phân tích cú pháp so với số lần nó được thực hiện.Một đến một phân tích/thực thi có thể chỉ ra rằng:
• Các biến liên kết không được sử dụng. | • Trên RDBMS phiên bản 8172 và cao hơn tham số init.ora session_cached_cursors không được đặt trong init.ora [100 thường là giá trị bắt đầu được đề xuất]. | • Nhóm được chia sẻ có thể quá nhỏ và phân tích cú pháp không được giữ lại đủ lâu cho nhiều lần thực hiện. |
• init.ora con trỏ_sharing nên được thiết lập để buộc | Khi CPU CPU Parse là một thành phần quan trọng của tổng thời gian phản hồi, bước tiếp theo là tìm các câu lệnh SQL có nhiều phân tích.Av Rd[ms] on the tablespace IO stats should be controlled under 10, which is ideal. But Avg read [ms] of up to 20 is acceptable for IO performance. AWR và StatSpack liệt kê các câu lệnh SQL như vậy trong các phần như SQL được đặt hàng bởi Parse Call Call. | |
Không gian bảng IO số liệu thống kê Av Buf Wt[ms | Đây là những điều hữu ích để xem không gian bảng nóng của bạn là gì.Ví dụ: có không gian bảng hệ thống là nguồn IO số một có thể cho biết bạn có các bài tập không gian bảng tạm thời không đúng như chúng được sử dụng để mặc định cho hệ thống.Có các không gian bảng tạm thời hoặc hoàn tác ở vị trí hàng đầu đã được thảo luận.Thông thường trong một hệ thống OLTP, một trong những không gian bảng chỉ mục của bạn phải ở trên cùng.Trong DWH hoặc OLAP, một không gian bảng dữ liệu phải ở trên cùng.Cũng nhìn vào các giá trị độ trễ.Đối với các hệ thống dựa trên đĩa 5.0 ms được coi là hiệu suất tốt. |
& nbsp; tham số
Ý nghĩa của phần này:
& nbsp; mô tả
& nbsp;
& nbsp; Av Rd [MS]
& nbsp; av rd [ms] trên các số liệu thống kê IO của bảng không gian bảng theo 10, điều này rất lý tưởng.Nhưng AVG đọc [MS] lên tới 20 là chấp nhận được cho hiệu suất IO.
Lưu ý: & nbsp; Khi cột trong cột đọc quá thấp, bạn có thể bỏ qua AV RD [MS].
& nbsp; & nbsp; av buf wt [ms
• Các biến liên kết không được sử dụng. | • Trên RDBMS phiên bản 8172 và cao hơn tham số init.ora session_cached_cursors không được đặt trong init.ora [100 thường là giá trị bắt đầu được đề xuất]. | • Nhóm được chia sẻ có thể quá nhỏ và phân tích cú pháp không được giữ lại đủ lâu cho nhiều lần thực hiện. |
• init.ora con trỏ_sharing nên được thiết lập để buộc | Khi CPU CPU Parse là một thành phần quan trọng của tổng thời gian phản hồi, bước tiếp theo là tìm các câu lệnh SQL có nhiều phân tích. AWR và StatSpack liệt kê các câu lệnh SQL như vậy trong các phần như SQL được đặt hàng bởi Parse Call Call. | |
& nbsp; hệ số kích thướcSize Factor | & nbsp; thay đổi ‘hệ số kích thước cho thấy & nbsp; tỷ lệ của & nbsp; kích thước đề xuất của bộ đệm bộ đệm [tăng hoặc giảm] & nbsp;với kích thước thực tế gần đúng hiện đang được sử dụng trong hàng với hệ số kích thước, = 1.0.Changing ‘Size Factor’ shows ratio of the proposed size of the buffer cache [increased or decreased] to the approximate actual size currently in use found in the row with ‘Size Factor’ = 1.0. | |
& nbsp; yếu tố đọc vật lý ước tínhEstimated Phys Read Factor | NBSP; Thay đổi 'Hệ số đọc vật lý ước tính' cho thấy & NBSP; Tỷ lệ của số lượng đọc vật lý ước tính cho kích thước được đề xuất [tăng hoặc giảm] của bộ đệm bộ đệm so với số lượng đọc vật lý được tính toán cho & NBSP;; hàng với 'hệ số đọc vật lý ước tính' = 1.0.Changing ‘Estimated Phys Read Factor’ shows ratio of the estimated number of Physical Reads for the proposed [increased or decreased] size of the buffer cache to the number of Physical Reads calculated for the current size of buffer cache found in the row with ‘Estimated Phys Read Factor’ = 1.0. | & nbsp; ở đây chúng ta có thể thấy rằng nếu chúng ta tăng bộ đệm bộ đệm từ 6 GB lên 10 GB, nó sẽ giúp chúng ta đáng kể Yếu tố này sẽ giảm từ 1 xuống 0,3. |
Tư vấn bộ nhớ PGA
Ý nghĩa của phần này:
Tương tự như tư vấn nhóm đệm, thống kê cung cấp thông tin về cách tăng hoặc giảm bộ nhớ PGA sẽ gây ra sự gia tăng hoặc giảm ESTD PGA CAHCE đạt %.
Điểm bắt đầu ở đây là hệ số kích thước của người dùng = 1.0.Điều này cung cấp phân bổ bộ nhớ hiện tại cho PGA.Trong ví dụ này, 12 GB đang được phân bổ cho PGA.Với sự phân bổ này, ESTD PGA CAHCE đạt % là 100, điều này là tốt.Do đó, ngay cả khi chúng tôi tăng PGA lên bất kỳ giá trị nào estd pga cahce đạt % won won thay đổi.Do đó, nó đã thắng được khuyến khích để tăng PGA hơn nữa.Tuy nhiên, việc giảm có thể tiết kiệm bộ nhớ mà không cần hiệu suất
Trong phần này, trước tiên bạn cần tìm hàng với giá trị cột FACT FACTR kích thước là 1.0.Cột này chỉ ra hệ số kích thước của ước tính PGA;Giá trị 1 cho biết kích thước PGA hiện tại.Giá trị ‘PGA Target EST [MB] của hàng này sẽ hiển thị kích thước PGA hiện tại của bạn: 12 GB trong ví dụ này.Các cột khác mà bạn sẽ quan tâm là ‘Estd Extra w/a MB đọc/ghi vào đĩa‘ và ‘ESTD PGA tổng thể Count.
Khi bạn đi xuống hoặc lên phần tư vấn từ hàng với ‘kích thước FACTR, = 1.0, bạn sẽ nhận được ước tính cho việc sử dụng đĩa - Cột estd thêm w/a mb đọc/ghi vào đĩa - cho các cài đặt lớn hơn hoặc nhỏ hơn của PGA_AGGREGATE_TARGET.Con số sử dụng đĩa ít hơn trong cột này, thường là tốt hơn.Giá trị thấp hơn có nghĩa là các khu vực làm việc ít hơn phải được đổ vào đĩa, tăng cường hiệu suất của phiên bản Oracle.
Câu hỏi về việc tăng hay giảm PGA_AGGRET_TARGET từ giá trị hiện tại phải luôn luôn được nghiên cứu.Câu trả lời phụ thuộc vào tổng số bộ nhớ [SGA+PGA] có thể được phân bổ cho trường hợp cơ sở dữ liệu này trên máy, tính đến nhu cầu bộ nhớ của các trường hợp cơ sở dữ liệu khác trên cùng một máy, phần mềm không phải là OS và chính HĐH.Quá nhiều bộ nhớ được phân bổ bộ nhớ chất thải và bộ nhớ quá ít gây ra các vấn đề hiệu suất có thể xảy ra trong môi trường Oracle.
& nbsp; tham số | & nbsp; mô tả | & nbsp; |
Số lượng tổng thể PGA ESTD | Hiển thị số lần các quy trình thể hiện cơ sở dữ liệu sẽ cần yêu cầu nhiều bộ nhớ PGA hơn ở cấp hệ điều hành so với số tiền được hiển thị trong giá trị EST mục tiêu PGA [MB] của hàng tương ứng.Lý tưởng nhất là trường này phải là 0 [chỉ ra rằng PGA có kích thước chính xác và không có tổng thể nào diễn ra], và đó là mục tiêu thứ hai không kém của bạn.Trong ví dụ đã cho, mục tiêu này đạt được với PGA_AGGRETATE_TARGET của thậm chí 1.536MB. Vì vậy, phân bổ PGA của chúng tôi là quá cao. |
Cố vấn nhóm chia sẻ
Ý nghĩa của phần này:
Tương tự như tư vấn nhóm đệm, thống kê cung cấp thông tin về cách tăng hoặc giảm bộ nhớ PGA sẽ gây ra sự gia tăng hoặc giảm ESTD PGA CAHCE đạt %.
Điểm bắt đầu ở đây là hệ số kích thước của người dùng = 1.0.Điều này cung cấp phân bổ bộ nhớ hiện tại cho PGA.Trong ví dụ này, 12 GB đang được phân bổ cho PGA.Với sự phân bổ này, ESTD PGA CAHCE đạt % là 100, điều này là tốt.Do đó, ngay cả khi chúng tôi tăng PGA lên bất kỳ giá trị nào estd pga cahce đạt % won won thay đổi.Do đó, nó đã thắng được khuyến khích để tăng PGA hơn nữa.Tuy nhiên, việc giảm có thể tiết kiệm bộ nhớ mà không cần hiệu suất
Trong phần này, trước tiên bạn cần tìm hàng với giá trị cột FACT FACTR kích thước là 1.0.Cột này chỉ ra hệ số kích thước của ước tính PGA;Giá trị 1 cho biết kích thước PGA hiện tại.Giá trị ‘PGA Target EST [MB] của hàng này sẽ hiển thị kích thước PGA hiện tại của bạn: 12 GB trong ví dụ này.Các cột khác mà bạn sẽ quan tâm là ‘Estd Extra w/a MB đọc/ghi vào đĩa‘ và ‘ESTD PGA tổng thể Count.
Khi bạn đi xuống hoặc lên phần tư vấn từ hàng với ‘kích thước FACTR, = 1.0, bạn sẽ nhận được ước tính cho việc sử dụng đĩa - Cột estd thêm w/a mb đọc/ghi vào đĩa - cho các cài đặt lớn hơn hoặc nhỏ hơn của PGA_AGGREGATE_TARGET.Con số sử dụng đĩa ít hơn trong cột này, thường là tốt hơn.Giá trị thấp hơn có nghĩa là các khu vực làm việc ít hơn phải được đổ vào đĩa, tăng cường hiệu suất của phiên bản Oracle.
Câu hỏi về việc tăng hay giảm PGA_AGGRET_TARGET từ giá trị hiện tại phải luôn luôn được nghiên cứu.Câu trả lời phụ thuộc vào tổng số bộ nhớ [SGA+PGA] có thể được phân bổ cho trường hợp cơ sở dữ liệu này trên máy, tính đến nhu cầu bộ nhớ của các trường hợp cơ sở dữ liệu khác trên cùng một máy, phần mềm không phải là OS và chính HĐH.Quá nhiều bộ nhớ được phân bổ bộ nhớ chất thải và bộ nhớ quá ít gây ra các vấn đề hiệu suất có thể xảy ra trong môi trường Oracle.
& nbsp; tham số | & nbsp; mô tả | & nbsp; |
Số lượng tổng thể PGA ESTD | Hiển thị số lần các quy trình thể hiện cơ sở dữ liệu sẽ cần yêu cầu nhiều bộ nhớ PGA hơn ở cấp hệ điều hành so với số tiền được hiển thị trong giá trị EST mục tiêu PGA [MB] của hàng tương ứng.Lý tưởng nhất là trường này phải là 0 [chỉ ra rằng PGA có kích thước chính xác và không có tổng thể nào diễn ra], và đó là mục tiêu thứ hai không kém của bạn.Trong ví dụ đã cho, mục tiêu này đạt được với PGA_AGGRETATE_TARGET của thậm chí 1.536MB. | Vì vậy, phân bổ PGA của chúng tôi là quá cao. |
Cố vấn nhóm chia sẻ
Ý nghĩa của phần này:
Báo cáo tư vấn mục tiêu SGA có phần tổng kết tất cả các báo cáo tư vấn được trình bày trước đây trong báo cáo AWR.Nó giúp bạn xác định tác động của việc thay đổi cài đặt của kích thước mục tiêu SGA về hiệu suất cơ sở dữ liệu tổng thể.Báo cáo sử dụng một giá trị gọi là thời gian DB làm thước đo mức tăng hoặc giảm hiệu suất so với thay đổi bộ nhớ được thực hiện.Ngoài ra, báo cáo sẽ tóm tắt ước tính các lần đọc vật lý liên quan đến cài đặt được liệt kê cho SGA.
Bắt đầu từ một yếu tố kích thước của người Viking là 1 [điều này cho thấy kích thước hiện tại của SGA].Nếu thời gian của EST EST DB giảm đáng kể khi hệ số kích thước của Cameron tăng thì tăng SGA sẽ làm giảm đáng kể các lần đọc vật lý và cải thiện hiệu suất.Nhưng ở đây trong ví dụ của chúng tôi, thời gian EST DB không giảm nhiều khi tăng SGA nên việc tăng SGA trong trường hợp của chúng tôi sẽ không có lợi.
Khi SQL yêu cầu một khối lượng truy cập dữ liệu lớn, việc tăng kích thước SGA_Target có thể làm giảm lượng I/O đĩa và cải thiện hiệu suất SQL.
Số liệu thống kê chờ đợi
Ý nghĩa của phần này:
Báo cáo thống kê chờ bộ đệm giúp bạn đi sâu vào các sự kiện chờ bộ đệm cụ thể và nơi xảy ra sự chờ đợi
Chúng tôi tập trung vào tổng thời gian chờ [s] và trong ví dụ này, giá trị này chỉ là 702 giây
Thời gian AVG [MS] cũng chỉ là 1 ms
Hoạt động enqueue
Báo cáo hoạt động Enqueue cung cấp thông tin về Enqueues [khóa Oracle cấp cao hơn] xảy ra.Cũng như các báo cáo khác, nếu bạn thấy mức độ thời gian chờ đợi cao trong các báo cáo này, bạn có thể đào sâu vào bản chất của enqueue và xác định nguyên nhân của sự chậm trễ.
Điều này có thể cung cấp thêm một số thông tin cho enqueue Waits [ví dụ: yêu cầu, thành công, thất bại], có thể đưa ra một dấu hiệu về tỷ lệ phần trăm của một enqueue phải chờ và số lượng thất bại.
Trong ví dụ của chúng tôi, hàng trên cùng đã thất bại nhưng số lượng chờ chỉ là 55 và thời gian chờ cũng không phải là số lượng cao.Vì vậy, Enqueue không phải là vấn đề chính của chúng tôi trong AWR này.
Hoàn tác tóm tắt phân khúc
Ý nghĩa của phần này:
& nbsp; tham số | & nbsp; mô tả | & nbsp; |
& nbsp; min/max tr [phút] | Đại diện cho các phút lưu giữ điều chỉnh tối thiểu và tối đa cho dữ liệu hoàn tác.Dữ liệu này sẽ giúp đặt tham số cơ sở dữ liệu hoàn tác. | & nbsp; Trong ví dụ này, tham số này có thể được đặt thành 868,4 phútIn this example this parameter can be set to 868.4 min |
& nbsp; Max QRY Len [S]Max Qry Len[s] | Đại diện cho độ dài truy vấn tối đa tính bằng giây. | & nbsp; & nbsp; Trong ví dụ này, độ dài truy vấn tối đa là 51.263 giây. In this example the max query length is 51,263 seconds. |
& nbsp; sto/ oosSTO/ OOS | Đại diện cho số lượng cho sanpshot quá cũ và ngoài không gian, xảy ra trong giai đoạn ảnh chụp nhanh. | & nbsp; Trong ví dụ này, chúng ta có thể thấy 0 lỗi xảy ra trong giai đoạn này.In this example, we can see 0 errors occurred during this period. |
Hoạt động chốt
Ý nghĩa của phần này:
Báo cáo hoạt động chốt cung cấp thông tin về cơ chế khóa cấp thấp của Oracle gọi là chốt.Từ báo cáo này & nbsp; bạn có thể xác định xem Oracle có gặp sự cố chốt hay không, và nếu vậy, các chốt nào đang gây ra số lượng lớn nhất & nbsp; số lượng tranh chấp trên hệ thống.
Có rất nhiều số liệu thống kê chốt
Bỏ lỡ, trừ khi chúng gây ra một lượng ngủ đáng kể không phải là mối quan tâm
Ngủ có thể là một vấn đề
Có thể cần nhìn vào số lượng spin nếu bạn ngủ quá nhiều
Số lượng spin [không có giấy tờ [_spin_count] dựa trên tốc độ CPU và cài đặt 2000 là vài năm trước
Nếu chốt chờ hoặc các sự kiện liên quan đến chốt khác sẽ xuất hiện, thì các chốt có thể là một vấn đề
Thông thường bộ đệm bộ đệm và chốt liên quan đến nhóm chia sẻ là các chốt chính.
& nbsp; tham số | & nbsp; mô tả | & nbsp; |
& nbsp; min/max tr [phút] | Đại diện cho các phút lưu giữ điều chỉnh tối thiểu và tối đa cho dữ liệu hoàn tác.Dữ liệu này sẽ giúp đặt tham số cơ sở dữ liệu hoàn tác. | |
& nbsp; Trong ví dụ này, tham số này có thể được đặt thành 868,4 phút | & nbsp; Max QRY Len [S] |
Đại diện cho độ dài truy vấn tối đa tính bằng giây.
Ý nghĩa của phần này:
& nbsp; & nbsp; Trong ví dụ này, độ dài truy vấn tối đa là 51.263 giây.
& nbsp; sto/ oos
Đại diện cho số lượng cho sanpshot quá cũ và ngoài không gian, xảy ra trong giai đoạn ảnh chụp nhanh.
Nếu SQL là tối ưu thì điều này có thể chỉ ra các bảng và chỉ mục nơi khối lượng công việc hoặc vứt bỏ xảy ra và vấn đề hiệu suất nằm ở đâu.Nó có thể đặc biệt hữu ích nếu không có số liệu thống kê thực tế ở nơi khác [ví dụ: số lượng hoạt động nguồn hàng [dòng chỉ số] trong dấu vết SQL hoặc không có thực tế trong báo cáo con trỏ SQLT/Display].
Các phân đoạn theo cách đọc vật lý
Ý nghĩa của phần này:
Nếu có một số lượng lớn các chờ đọc vật lý [đọc tệp db, đọc tệp db tuần tự đọc và đọc đường dẫn trực tiếp] thì phần này có thể cho biết các phân đoạn nào [bảng hoặc bảng
chỉ mục] Vấn đề xảy ra.
Điều này có thể giúp xác định các dòng kế hoạch thực hiện dưới mức tối ưu & nbsp;Nó cũng có thể giúp xác định các thay đổi đối với không gian bảng và quản lý lưu trữ sẽ cải thiện hiệu suất.
Khi các SQL cần đọc vật lý quá mức trên các phân đoạn cụ thể, phần này liệt kê chúng.Bạn cần kiểm tra xem một số SQLS đang sử dụng quét đầy đủ không cần thiết và quét phạm vi & nbsp; phạm vi.
Thống kê hiển thị chi tiết phân khúc dựa trên các lần đọc vật lý đã xảy ra.Dữ liệu được hiển thị được sắp xếp trên cột đọc vật lý của người Hồi giáo theo thứ tự giảm dần.Nó cung cấp thông tin về các phân đoạn mà nhiều bài đọc vật lý đang xảy ra.
Các truy vấn sử dụng các phân đoạn này nên được phân tích để kiểm tra xem có bất kỳ FTS nào đang xảy ra trên các phân đoạn này hay không.Trong trường hợp FTS đang diễn ra thì các chỉ mục thích hợp nên được tạo để loại bỏ FTS.Hầu hết các SQL này có thể được tìm thấy trong phần Thống kê SQL -> SQL được đặt hàng bởi các lần đọc.
Các báo cáo này có thể giúp & nbsp; bạn tìm thấy các đối tượng là các đối tượng hot hot trong cơ sở dữ liệu.Bạn có thể muốn xem lại các đối tượng và xác định lý do tại sao chúng & nbsp; là nóng và nếu có bất kỳ cơ hội điều chỉnh nào có sẵn trên các đối tượng đó [ví dụ: phân vùng] hoặc trên SQL Access & NBSP; các đối tượng đó.
Ví dụ: nếu một đối tượng được hiển thị trên báo cáo đọc vật lý, có thể là một chỉ mục là cần thiết trên đối tượng đó & nbsp;
& nbsp; tham số | & nbsp; mô tả | & nbsp; |
& nbsp; các phân khúc được nắm bắt chiếm 90,8%& nbsp;Captured Segments account for 90.8% | Số % này là quan trọng.Nó phải là giá trị cao cho thấy rằng chúng tôi đang xem xét dữ liệu chính xác. It should be high value which shows that we are looking at correct data. | |
& nbsp; bản ghi phân đoạn hàng đầu | MTL_ITEM_CATEGORIES | MTL_ITEM_C CAGETORY chiếm 51,32% tổng số lần đọc vật lý là một con số lớn.Chúng ta cần xem câu lệnh SQL nào đang sử dụng phân khúc này và có thể điều chỉnh SQL đó. Bạn sẽ phải truy cập SQL SQL được đặt hàng bởi phần đọc AWR để xem câu lệnh SQL nào đang sử dụng phân khúc này. |
Các phân đoạn bằng khóa hàng chờ đợi
Ý nghĩa của phần này:
Nếu có một số lượng lớn các chờ đọc vật lý [đọc tệp db, đọc tệp db tuần tự đọc và đọc đường dẫn trực tiếp] thì phần này có thể cho biết các phân đoạn nào [bảng hoặc bảng
chỉ mục] Vấn đề xảy ra.
Điều này có thể giúp xác định các dòng kế hoạch thực hiện dưới mức tối ưu & nbsp;Nó cũng có thể giúp xác định các thay đổi đối với không gian bảng và quản lý lưu trữ sẽ cải thiện hiệu suất.
Khi các SQL cần đọc vật lý quá mức trên các phân đoạn cụ thể, phần này liệt kê chúng.Bạn cần kiểm tra xem một số SQLS đang sử dụng quét đầy đủ không cần thiết và quét phạm vi & nbsp; phạm vi.
Thống kê hiển thị chi tiết phân khúc dựa trên các lần đọc vật lý đã xảy ra.Dữ liệu được hiển thị được sắp xếp trên cột đọc vật lý của người Hồi giáo theo thứ tự giảm dần.Nó cung cấp thông tin về các phân đoạn mà nhiều bài đọc vật lý đang xảy ra.
Ý nghĩa của phần này:
Các truy vấn sử dụng các phân đoạn này nên được phân tích để kiểm tra xem có bất kỳ FTS nào đang xảy ra trên các phân đoạn này hay không.Trong trường hợp FTS đang diễn ra thì các chỉ mục thích hợp nên được tạo để loại bỏ FTS.Hầu hết các SQL này có thể được tìm thấy trong phần Thống kê SQL -> SQL được đặt hàng bởi các lần đọc.
Các báo cáo này có thể giúp & nbsp; bạn tìm thấy các đối tượng là các đối tượng hot hot trong cơ sở dữ liệu.Bạn có thể muốn xem lại các đối tượng và xác định lý do tại sao chúng & nbsp; là nóng và nếu có bất kỳ cơ hội điều chỉnh nào có sẵn trên các đối tượng đó [ví dụ: phân vùng] hoặc trên SQL Access & NBSP; các đối tượng đó.
ITL wait happens in case total trasactions trying to update same block at the same time are greater than the ITL parameter value.
Ví dụ: nếu một đối tượng được hiển thị trên báo cáo đọc vật lý, có thể là một chỉ mục là cần thiết trên đối tượng đó & nbsp;
& nbsp; tham số
& nbsp; mô tả
Ý nghĩa của phần này:
& nbsp;
& nbsp; các phân khúc được nắm bắt chiếm 90,8%& nbsp;
Buffer bận rộn chờ đợi xảy ra khi có nhiều hơn một giao dịch cố gắng truy cập cùng một khối cùng một lúc.Trong kịch bản này, giao dịch đầu tiên có được khóa trên khối sẽ có thể tiến hành thêm trong khi giao dịch khác chờ giao dịch đầu tiên kết thúc.Nếu có nhiều hơn một trường hợp của một quá trình liên tục cơ sở dữ liệu bỏ phiếu bằng cách thực hiện cùng một SQL [để kiểm tra xem có bất kỳ hồ sơ nào có sẵn để xử lý không], cùng một khối được đọc đồng thời bởi tất cả các trường hợp của một quy trình và kết quả này trong bộ đệm bận rộn.
If there are more than one instances of a process continuously polling database by executing same SQL [to check if there are any records available for processing], same block is read concurrently by all the instances of a process and this result in Buffer Busy wait event.
Đây là một trong những bài viết trong loạt các nguyên tắc cơ bản điều chỉnh hiệu suất.Nhấp vào các liên kết bên dưới để đọc thêm bài viết từ loạt bài:
- Performance Tuning Basics 1 : Selectivity and Cardinality
- Performance Tuning Basics 2 : Parsing
- Performance Tuning Basics 3 : Parent and Child Cursors
- Performance Tuning Basics 4 : Bind Variables
- Performance Tuning Basics 5 : Trace and TKPROF – Part 1: Trace
- Performance Tuning Basics 6 : Trace and TKPROF – Part 2: Generating TKPROF
- Performance Tuning Basics 7 : Trace and TKPROF – Part 3: Analyzing TKPROF Files
- Performance Tuning Basics 8 : Trace File Analyzer [TRCA]
- Performance Tuning Basics 9 : Optimizer Mode
- Performance Tuning Basics 10 : Histograms
- Performance Tuning Basics 11 : Steps to analyze a performance problem
- Performance Tuning Basics 12 : Dynamic Performance Views
- Performance Tuning Basics 13 : Automatic Workload Repository [AWR] Basics
- Performance Tuning Basics 14 : Active Sessions History [ASH] Basics
- Performance Tuning Basics 15 : AWR Report Analysis
- Performance Tuning Basics 16 : Using SQL Tuning Health-Check Script [SQLHC]
- Tác giả
- Bài viết gần đây
Tôi là một kiến trúc sư/ứng dụng DBA của đám mây/Oracle có kinh nghiệm với hơn 15 năm kinh nghiệm DBA/Kiến trúc sư toàn thời gian.Tôi đã có được kiến thức rộng rãi về ORACLE và phần mềm phi Oracle đang chạy tại chỗ và trên đám mây và đã làm việc cho một số dự án lớn cho các công ty đa quốc gia.Tôi thích làm việc với công nghệ hàng đầu và có niềm đam mê với kiến trúc đám mây, tự động hóa, hiệu suất cơ sở dữ liệu và sự ổn định.Rất may, công việc của tôi cho phép tôi thời gian nghiên cứu các công nghệ mới [và viết về chúng].