Tôi nhận được cuộc gọi từ ai đó rằng họ gặp lỗi TNS-12519 trong ứng dụng của họ. Chắc chắn, những thông báo đó cũng nằm trong tệp listener.log.
TNS-12519: TNS:no appropriate service handler found
Đối với những người không quen với lỗi này, nó thường có nghĩa là một trong hai điều. Tên dịch vụ không được đăng ký với trình nghe hoặc cơ sở dữ liệu đã đạt đến số lượng quy trình tối đa. Đối với trường hợp thứ hai, điều xảy ra là Người nghe biết rằng cơ sở dữ liệu không thể chấp nhận bất kỳ quy trình mới nào, vì vậy, nó có thể nói tên dịch vụ nằm ngoài dịch vụ. Một “trạng thái lsnrctl” nhanh chóng cho tôi biết rằng tên dịch vụ đã được đăng ký chính xác. Vì vậy nó phải là cái sau. Sau đó, tôi đưa ra truy vấn sau và xác nhận những nghi ngờ của mình.
SQL> select resource_name,current_utilization,max_utilization 2 from v$resource_limit where resource_name='processes';
RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION --------------- ------------------- --------------- processes 299 300
Đảm bảo đủ. Tôi đã đạt đến quy trình tối đa, được xác định trong SPFILE của tôi là 300. Tôi đã tăng thông số lên 600 và trả lại phiên bản. Chúng tôi lại gặp lỗi với số lượng quy trình tăng gấp đôi. Rõ ràng là tôi cần phải tìm hiểu sâu hơn về vấn đề này.
Đối với một số thông tin cơ bản và đối với một số thứ sẽ quan trọng sau này, điều quan trọng là phải biết rằng cơ sở dữ liệu này hỗ trợ các nỗ lực kiểm tra tự động của chúng tôi. Chúng tôi có một bộ khai thác thử nghiệm thực hiện ứng dụng sản xuất chính của chúng tôi. Bộ thử nghiệm này khởi chạy ứng dụng, kết nối với cơ sở dữ liệu, nhấn một vài nút và chọn một vài mục menu rồi ngắt kết nối.
Tôi đã kiểm tra tệp listener.log để xem các yêu cầu kết nối đến từ đâu. Những yêu cầu này đến từ một máy chủ ứng dụng giả mạo, không phải bộ thử nghiệm của chúng tôi. Tôi biết có điều gì đó không ổn vì chúng tôi chưa khởi động bộ thử nghiệm và chúng tôi đang gặp lỗi. Chúng tôi đã sửa máy chủ ứng dụng và tôi không thấy lỗi quay lại. Sau đó, chúng tôi kích hoạt bộ thử nghiệm và một thời gian sau, các lỗi TNS-12519 đã quay trở lại. Hmmm… Tôi nghĩ rằng tôi đã tìm ra thủ phạm. Nhưng hãy kiểm tra việc sử dụng quy trình của chúng tôi.
SQL> select resource_name,current_utilization,max_utilization 2 from v$resource_limit where resource_name='processes';
RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION --------------- ------------------- --------------- processes 89 157
Vì vậy, tôi hiện đang thấy 89 quy trình với mức sử dụng tối đa là 157. Tôi không ở đâu gần giới hạn mới là 600 của mình. Vậy điều gì mang lại? Tôi đã mất một lúc để tìm ra vấn đề là gì. Tên dịch vụ đã được đăng ký chính xác và tôi không ở gần giới hạn của mình. MOS NOTE 552765.1 nói về cách Người nghe nhận được lỗi TNS-12519. Trước đây, tôi đã thấy nguyên nhân phổ biến nhất. Đã đạt đến TIẾN TRÌNH TỐI ĐA. Nhưng không phải lúc này Vậy điều gì mang lại?
Sau khi điều tra, tôi đã tìm thấy câu trả lời của mình trong nhật ký của người nghe. Nhưng nó không rõ ràng như một số thông báo lỗi lớn. Lần đầu tiên xảy ra lỗi TNS-12519 là lúc 9:38 sáng. Tôi đã tìm “service_update” trong nhật ký người nghe và thấy những mục này.
25-JUN-2015 09:17:08 * service_update * orcl * 0 25-JUN-2015 09:17:26 * service_update * orcl * 0 25-JUN-2015 09:17:29 * service_update * orcl * 0 25-JUN-2015 09:17:44 * service_update * orcl * 0 25-JUN-2015 09:17:50 * service_update * orcl * 0 25-JUN-2015 09:17:53 * service_update * orcl * 0 25-JUN-2015 09:18:56 * service_update * orcl * 0 25-JUN-2015 09:18:59 * service_update * orcl * 0 25-JUN-2015 09:19:50 * service_update * orcl * 0 25-JUN-2015 09:20:11 * service_update * orcl * 0 25-JUN-2015 09:21:27 * service_update * orcl * 0 25-JUN-2015 09:22:09 * service_update * orcl * 0 25-JUN-2015 09:24:05 * service_update * orcl * 0 25-JUN-2015 09:27:53 * service_update * orcl * 0 25-JUN-2015 09:29:32 * service_update * orcl * 0 25-JUN-2015 09:34:07 * service_update * orcl * 0 25-JUN-2015 09:41:45 * service_update * orcl * 0
Lưu ý rằng bản cập nhật dịch vụ này diễn ra thường xuyên vào lúc 9:17 và 9:18, tuy nhiên thời gian giữa các lần cập nhật dịch vụ ngày càng lâu hơn. Lưu ý rằng có 8 phút 38 giây giữa các bản cập nhật dịch vụ khi kết thúc (9:34 đến 9:41). Tại sao điều này lại quan trọng?
Đây là cơ sở dữ liệu Oracle 11.2.0.4. Đối với 11.2 trở về trước, PMON chịu trách nhiệm dọn dẹp sau các quy trình và chuyển thông tin cho Người nghe. Khi khởi động cơ sở dữ liệu, PMON cố gắng đăng ký các dịch vụ với Listener. Một điều khác mà PMON làm là cho Listener biết có bao nhiêu quy trình tối đa có thể được phục vụ. Trong trường hợp này, PMON nói với người nghe rằng nó có thể có tới 600 quy trình. PMON còn làm được nhiều hơn thế, nhưng với mục đích của cuộc thảo luận này, thế là đủ.
Một điều quan trọng cần biết là Người nghe không bao giờ biết có bao nhiêu quy trình hiện đang được kết nối. Nó chỉ biết có bao nhiêu yêu cầu kết nối mà nó đã giúp nhà môi giới. Listener không bao giờ biết nếu các tiến trình ngắt kết nối với cơ sở dữ liệu. Service_update ở trên là nơi PMON cho Người nghe biết có bao nhiêu quy trình đang thực sự được sử dụng. Vì vậy, vào lúc 9:34:07, bản cập nhật dịch vụ PMON cho Người nghe biết rằng có 145 quy trình đang được sử dụng. Trình nghe hiện đã được cập nhật. Khi có một yêu cầu kết nối mới, Trình xử lý sẽ tăng điều này lên thành 146 quy trình. Giữa các bản cập nhật dịch vụ, Người nghe hoàn toàn không biết rằng 1 hoặc nhiều quy trình có thể đã bị chấm dứt, bình thường hoặc bất thường. Nó tiếp tục tăng số lượng quy trình của mình cho đến khi cập nhật dịch vụ tiếp theo khi Người nghe nhận được tài khoản chính xác về số lượng quy trình được tạo ra.
Vì vậy, chúng tôi có khoảng cách 8,5 phút giữa các bản cập nhật dịch vụ. Tại sao PMON mất quá nhiều thời gian để quay lại với Trình nghe? Đầu mối cho điều đó cũng nằm trong listener.log. Tôi đã loại bỏ mọi thứ khỏi nhật ký trước ngày cập nhật dịch vụ 9:34 và sau khi cập nhật dịch vụ 9:41. Từ đó, thật dễ dàng để tìm “(CONNECT_DATA =” trong những gì còn lại và chuyển sang “wc -l” để đếm số dòng.
Trong khoảng thời gian 8,5 phút này, tôi đã có hơn 450 yêu cầu kết nối mới! Tuy nhiên, hầu hết các kết nối mới đó đã chấm dứt bằng chứng là V $ RESOURCE_LIMIT cho tôi thấy rằng tôi đã có tối đa 150. PMON quá bận rộn để dọn dẹp ứng dụng thoát khỏi các kết nối cơ sở dữ liệu của nó nên nó đã bị trễ lớn trước khi cập nhật Trình xử lý. Theo như Người nghe có liên quan, 150 kết nối hiện tại cộng với 450 kết nối mới có nghĩa là nó đã đạt đến giới hạn 600.
PMON có thể mất tới 10 phút để quay lại Trình nghe với bản cập nhật dịch vụ tiếp theo. Dọn dẹp sau khi phiên thoát khỏi phiên bản có mức độ ưu tiên cao hơn so với cập nhật dịch vụ cho Trình xử lý. Vào thời điểm 10 phút, PMON đặt ưu tiên hàng đầu cập nhật dịch vụ nếu trước đó chưa thực hiện cập nhật dịch vụ trong khoảng thời gian đó.
Hãy nhớ rằng đây là cơ sở dữ liệu để hỗ trợ kiểm tra tự động. Chúng tôi phải sống với nhiều hoạt động kết nối / ngắt kết nối này bởi vì chúng tôi có một robot tự động thử nghiệm ứng dụng của chúng tôi theo kiểu cháy nhanh. Chúng tôi không muốn thay đổi cách ứng dụng hoạt động vì nó hoạt động rất tốt khi được chạy bởi một người dùng. Bộ thử nghiệm tự động của chúng tôi đang thực thi ứng dụng khác với những gì nó được thiết kế để làm. Nhưng chúng tôi muốn sử dụng ứng dụng như được viết để có khả năng phát hiện lỗi trước khi các thay đổi mã bắt đầu được sản xuất.
Hiện tại, tôi đã tăng thông số PROCESSES lên một giá trị mà chúng tôi sẽ không bao giờ đạt được. Tất cả điều này để Người nghe không thể đạt đến giới hạn trong bộ đếm nội bộ của nó. Càng nhiều TIẾN TRÌNH, càng cần nhiều bộ nhớ trong SGA để hỗ trợ con số cao hơn đó. Nhưng cơ sở dữ liệu này có thể xử lý nó.
Nếu có ai biết cách để cập nhật dịch vụ diễn ra trong cửa sổ 5 phút, vui lòng cho tôi biết. Không có bất kỳ thông số tài liệu nào để kiểm soát hành vi này và tôi cũng không thể tìm thấy thông số không có tài liệu.
Cuối cùng, sự cố này nằm trong một trong cơ sở dữ liệu 11.2.0.4 của tôi. Oracle 12c thay đổi kiến trúc một chút. Quy trình nền Đăng ký người nghe (LREG) mới xử lý công việc mà PMON đã từng làm. Tôi chưa có hệ thống nào để kiểm tra, nhưng tôi cá rằng LREG sẽ không gặp vấn đề tương tự ở 12c mà PMON sẽ trưng bày ở đây vào 11g vì LREG sẽ không phải xử lý các nhiệm vụ dọn dẹp mà PMON thực hiện. MOS Note 1592184.1 cho thấy rằng LREG sẽ thực hiện cập nhật dịch vụ.
Cập nhật:Kể từ khi tôi viết bài này, tôi đã có cơ hội nâng cấp cơ sở dữ liệu lên 12c với quy trình LREG mới của nó. Với việc LREG xử lý các bản cập nhật dịch vụ của Người nghe, chúng tôi đã thấy sự cố biến mất. Ngay cả trong thời gian hoạt động phiên nhiều, đặc biệt là kết nối và ngắt kết nối, LREG đã thực hiện các bản cập nhật dịch vụ thường xuyên mà PMON sẽ không thể thực hiện thường xuyên.
