Tài liệu Performance Improvement Methods doc

I.1The Oracle Performance Improvement MethodOracle thực hiện phương pháp giúp bạn xác định các vấn đề hiệu suất trong hệ thống Oracle của bạn.. I.1The Oracle Performance Improvement Meth

Sinh viên th c hi n: ực hiện: ện:

Lê Thanh Hùng Bùi Duy Trung

I Performance Improvement Methods

 The Oracle Performance Improvement Method

 Emergency Performance Methods

I.1The Oracle Performance Improvement Method

Oracle thực hiện phương pháp giúp bạn xác định các vấn đề hiệu suất trong hệ thống Oracle của bạn Điều này liên quan đến việc xác định tắc nghẽn và sửa chữa chúng Nó đưa ra khuyến cáo những thay đổi được thực hiện với một hệ thống chỉ sau khi bạn đã xác nhận rằng có một tắc nghẽn

I.1The Oracle Performance Improvement

Method

Các phương pháp cải thiện hiệu suất trong oracle có thể được áp dụng cho đến khi các mục đích được thực hiện hoặc không thể thực hiện được Tiến trình này được lặp lại,

và nó không tránh khỏi một số kiểm tra được thực hiện có tác động rất ít đối với hiệu suất hệ thống Rất mất thời gian

và kinh nghiệm để phát triển các kỹ năng cần thiết để xác định chính xác tắc nghẽn quan trọng một cách kịp thời.

I.1.1 Steps in The Oracle Performance

Improvement Method

1 Thực hiện kiểm tra ban đầu theo những tiêu chuẩn sau :

 Trực tiếp nhận những phản hồi từ người dùng

 Có được một tập hợp đầy đủ về hệ điều hành, cơ sở dữ

liệu, và các ứng dụng tĩnh từ hệ thống khi thực thi cả tốt lẫn xấu

 Kiểm tra độ an toàn các hệ điều hành của tất cả các

máy có liên quan đến hoạt động của người sử dụng bạn sẽ tìm thấy đầy đủ các tiện ích về phần cứng hoặc tài nguyên của hệ điều hành.

I.1.1 Steps in The Oracle Performance Improvement

Method

2 Kiểm tra 10 lỗi phổ biến nhất trong Oracle và xác định xem

nếu bât kì lỗi nào trong chúng giống như vậy thì nó có vấn đề Liệt kê những lỗi đó để sau này phân tích

3 Xây dựng mô hình khái niệm của những gì đang xảy ra trên

hệ thống bằng cách sử dụng các triệu chứng như là những đầu mối để hiểu cái gì là nguyên nhân gây ra các vấn đề thực thi.

I.1.1 Steps in The Oracle Performance

Improvement Method

4 Đề xuất hàng loạt các hành động khắc phục và dự đoán

các hành vi đến hệ thống sau đó áp dụng chúng theo thứ

tự mà ứng dụng có lợi nhất

I.1.1 Steps in The Oracle Performance

Improvement Method

5 Xác nhận thay đổi đã có hiệu quả mong muốn, và thấy

rằng hiệu suất thực hiện của người sử đụng đã được cải thiện Nếu không hãy tìm thêm tắc nghẽn và tiếp tục cải tiến các mô hình khái niệm cho đến khi hiểu biết của bạn về ứng dụng trở nên chính xác hơn

6 Lặp lại 3 bước cuối cùng cho tới khi thực hiện các

mục tiêu được đáp ứng hoặc trở thành không thể do các ràng buộc khác

 Thực hiện Automatic Database Diagnostic Monitor (ADDM) là một phần trong phương pháp cải thiện hiệu suất và thống kê phân tích để cung cấpchuẩn đoán tự động vấn đề chính về hiệu suất sư dụng ADDM là cách tiết kiệm thời gian nhất để cải thiện hiệu suất của

hệ thống

 trình phân tích ADDM sẽ thực hiện mỗi khi hình ảnh AWR được lấy và kết quả được lưu trong cơ sở dữ liệu Bạn có thể xem kết quả của trình phân tích sử dụng using Oracle Enterprise Manager hoặc bằng một báo cáo trong một phiên SQL*Plus

 Hầu hết những trường hợp đầu ra ADDM là nơi đầu tiên mà một DBA xem khi có thông báo về vấn đề hiệu suất ADDM cung cấp những lợi ích sau :

 Báo cáo tự động thực hiện chuẩn đoán mỗi giờ trong chế độ mặc định

 Sự chuẩn đoán dựa vào thâm niên (decades) chuyên môn trong vấn đề hiệu chỉnh

 Số lượng time-based của vấn đề tác động đến và khuyến cáo về lợi ích

 Nhận ra chính nguyên nhân, không phải dấu hiệu

 Khuyến cáo để xử lý nguyên nhân chính của vấn đề

 Nhận ra những vùng xung quanh không có vấn đề của hệ thống

 Tối thiểu hóa hệ thống là trên hết trong suốt quá trình chuẩn đoán

 Kết quả trình phân tích ADDM được hiển thị như là một tập FINDING

 Mỗi FINDING của ADDM có thể giống 1 trong 3 loại sau

 Problem : môt tả nguyên nhân chính về vấn đề hiệu suất trong CSDL

 Symptom : chứa những thông tin thương dẫn đến một hoặc nhiều vấn đề

 Information : báo cáo những vùng xung quanh không có vấn đề của

hệ thống

FINDING 1: 31% impact (7798 seconds)

-SQL statements were not shared due to the usage of literals This resulted in

additional hard parses which were consuming significant database time.

RECOMMENDATION 1: Application Analysis, 31% benefit (7798 seconds) ACTION: Investigate application logic for possible use of bind variables

instead of literals Alternatively, you may set the parameter

"cursor_sharing" to "force".

RATIONALE: SQL statements with PLAN_HASH_VALUE 3106087033 were found to be using literals Look in V$SQL for examples of such SQL statements

10 lỗi được tìm thấy trong hệ thống

Oracle

1 Quản lý kết nối không tốt

cho mỗi lần CSDL tương tác Vấn đề này thường xuyên xảy ra trên ứng dụng server

2 . Tình trạng sử dụng của Cursors và Shared Pool

tương tự Nếu những biến phụ thuộc không được sử dụng thì sẽ rất khó khăn cho sự phân tích các câu lệnh SQL

10 lỗi được tìm thấy trong hệ thống

từ một ứng dụng trực tuyến mà kéo dài hơn 1 phút

trọng nên cần phải có biện pháp cải tiến hiệu suất

10 lỗi được tìm thấy trong hệ thống Oracle

4 Sử dụng các chuẩn khởi tạo tham số

Việc thực hiện này dựa vào các giả thiết chưa chính xác

Đa số những hệ thống đều cho thực hiện khi thiết lập các thông số cơ bản Đặc biệt các số liệu liên quan đến SPIN_COUNT là then chốt và các tính năng tối ưu hóa việc cung cấp tài liệu có thể gây nhiều vấn đề mà có thể phải xem xét lại

5 Lỗi đường dẫn

Nhiều nơi sắp xếp CSDL của họ chưa tối ưu Nhiều nơi xác định số lượng đĩa không chính xác, vì họ cấu hình đĩa bằng không gian đĩa chứ ko phải theo đường truyền I/O

10 lỗi được tìm thấy trong hệ thống

Oracle

6 Cài đặt Redo Log

 Nhiều trang web hoạt động với quá ít redo logs, những redo logs quá nhỏ, chúng làm cho hệ thống kiểm tra những điểm để tiếp tục tải cao trên bộ nhớ cache và hệ thống I/O, nếu có quá ít redo logs, thì không thể giữ được lưu trữ và cơ sở dữ liệu sẽ chờ quá trình lưu trữ để bắt kịp

10 lỗi được tìm thấy trong hệ thống

Oracle

7 Sự xuất ra của khối dữ liệu trong bộ nhớ cache do thiếu danh sách trống, danh sách nhóm trống ,khe cắm giao dịch (INITRANS), hoặc thiếu các phân đoạn rollback Điều này đặc biệt phổ biến trên ứng dụng INSERT-heavy, trong các ứng dụng có kích thước khối lớn trên 8K, hoặc trong các ứng dụng với số lượng lớn người dùng đang hoạt động và vài phân đoạn rollback Sử dụng tự động phân đoạn-không gian quản lý (ASSM) để tự động hoàn tác quản lý và giải quyết vấn đề này

10 lỗi được tìm thấy trong hệ thống

Oracle

8 Việc quét các bảng một cách đầy đủ và lâu dài hoặc các hoạt động tương tác trực tuyến có thể cho biết thiết kế giao dịch kém, thiếu các danh mục, hoặc tối

ưu hóa SQL kém Quét bảng lâu dài thực ra là I / O chuyên sâu và không thay đổi

10 lỗi được tìm thấy trong hệ thống

Oracle

9 Một lượng lớn của câu lệnh SQL đệ quy thực thi bởi SYS có thể cho biết các hoạt động quản lý không gian, chẳng hạn như mức độ phân bổ, quá trình diễn ra Điều này là không thay đổivà người sử dụng tác động thời gian đáp ứng Việc sử dụng quản

lý cục bộ ko gian bảng để giảm đệ quy SQL do mức

độ phân bổ

10 lỗi được tìm thấy trong hệ thống

Oracle

10 Trong nhiều trường hợp, một ứng dụng sử dụng nguồn tài nguyên quá nhiều

 Trong một tình huống khẩn cấp, 1 thành phần nào

đó của hệ thống đã bị thay đổi theo chiều hướng không tốt cho hệ thống, làm cho hệ thống vận hành không theo ý người sử dụng

định được sự thay đổi đó bắt nguồn từ đâu và phải

có biện pháp xử lý sự cố đó để hệ thống hoạt động lại một cách bình thường và đạt hiệu quả cao

 Trong nhiều trường hợp bắt buộc người kỹ sư phải nhanh nhạy trong việc phát hiện lỗi và khắc phục ngay lập tức, nếu không sẽ ảnh hưởng nghiêm trọng đến công ty

thập thông tin đầy đủ về sự cố trên và phải đảm bảo rằng nó không xảy ra lần nữa

1. Khảo sát các vấn đề thực thi và thu thập các biểu

hiện của vấn đề thực thi

 Người sử dụng phản hồi về việc hệ thống đang hoạt động không tốt như thế nào

 Phải đặt câu hỏi “ cái gì đã thay đổi khi hệ thống đã có sự ổn định?” Nếu trả lời được câu hỏi này thì có thể giải quyết được vấn đề Nhưng trả lời được câu hỏi này trong tình trạng cấp bách là điều không thể Do vậy cách hiệu quả nhất là thống kê lại quá trình truy nhập vào CSDL hoặc kiểm tra file logs trước và sau khi hệ thống bị trục trặc.

1. Khảo sát các vấn đề thực thi và thu thập các biểu

hiện của vấn đề thực thi(tt)

 Sử dụng tính năng tự động điều chỉnh để chẩn đoán và giám sát các vấn đề đã có sẵn trong hệ thống

 Ngoài ra, bạn có thể sử dụng Oracle Enterprise Manager để xác định hiệu suất tính năng SQL hàng đầu và các phiên làm việc

2 Kiểm tra việc sử dụng phần cứng của tất cả các thành phần ứng dụng

 Kiểm tra CPU, ổ cứng, việc sử dụng bộ nhớ và hiệu suất mạng của các thành phần trên hệ thống.

 Quá trình này giúp nhanh chóng xách định tầng nào xảy ra vấn đề và tìm cách giải quyết.

3 Xác định xem liệu máy chủ cơ sở dữ liệu có bị hạn chế trên CPU hay nó đc sử dụng vào việc đợi những sự kiện Nếu máy chủ cơ sở dữ liệu bị CPU hạn chế thì khảo sát theo các bước sau đây

 Những phiên làm việc tiêu thụ một số lượng lớn của CPU ở mức hệ điều hành và cơ sở dữ liệu, kiểm tra V$SESS_TIME_MODEL cho cơ sở dữ liệu sử dụng CPU.

 Những phiên làm việc hay những phát biểu thực thi nhiều bộ đệm ở cấp cơ sở dữ liệu, kiểm tra $SESSTAT

và V$SQL

3 Xác định xem liệu máy chủ cơ sở dữ liệu có bị hạn chế trên CPU hay nó đc sử dụng vào việc đợi những sự kiện Nếu máy chủ cơ sở dữ liệu bị CPU hạn chế thì khảo sát theo các bước sau đây(tt)

 Sự thiết lập sai của các thong số khởi tạo.

 Những vấn đề thuật toán như một kết quả của những sự thay đổi câu lệnh hay những sự nâng cấp của mọi thành phần

4 Áp dụng hành động khẩn cấp để ổn định hệ thống Điều này có thể liên quan đến các hành động tham gia của ngoại tuyến ứng dụng hay hạn chế khối lượng công việc có thể áp dụng cho hệ thống.

5 Xác nhận rằng hệ thống ổn định Việc thực hiện thay đổi

và hạn chế với hệ thống xác nhận rằng hệ thống bây giờ là

ổn định, và thu thập một bộ tài liệu tham khảo số liệu thống

kê cho các cơ sở dữ liệu.

Example of Conceptual Model

CEO Employee:

Former Board Member Left September 2002