2010-09-07 31 views
6

Chúng tôi sử dụng ODP.NET để thực hiện truy vấn trên cơ sở dữ liệu Oracle và bình thường nó hoạt động tốt. Có một cơ sở dữ liệu cụ thể, và một khung nhìn cụ thể trong cơ sở dữ liệu đó, mặc dù, chúng ta không thể hoàn thành một truy vấn trên từ .NET. Ví dụ:Truy vấn Oracle chậm (hoặc không thành công) từ ứng dụng .NET nhưng nhanh chóng từ Nhà phát triển SQL

SELECT some_varchar_field FROM the_view WHERE ROWNUM < 5; 

Nếu tôi thực hiện truy vấn này từ bên trong nhà phát triển Oracle SQL, nó kết thúc sau chưa đầy một giây. Nếu tôi thực hiện một truy vấn giống hệt từ ứng dụng .NET của chúng tôi bằng ODP.NET, nó sẽ bị treo và cuối cùng tạo ra một lỗi "liên hệ bị mất kết nối ORA-03135: kết nối". Tôi nghĩ rằng hạn chế nó chỉ là một vài hàng loại bỏ khả năng rằng nó là vấn đề FetchSize.

Có các truy vấn khác mà tôi có thể thực hiện thành công, nhưng chúng chậm hơn so với chương trình của chúng tôi so với từ nhà phát triển SQL. Một lần nữa, tôi nhận ra SQL Developer chỉ nhận được dữ liệu cho 50 hàng đầu tiên ban đầu, nhưng tôi nghĩ rằng điều kiện ROWNUM lấy nó ra khỏi phương trình.

Điều gì có thể khác về kết nối hoặc lệnh mà Oracle SQL Developer đang sử dụng so với ứng dụng mà chúng tôi đang sử dụng có thể gây ra sự khác biệt về tốc độ?

Thật không may, tôi không có quyền truy cập vào máy chủ (ngoài việc chạy truy vấn Oracle chống lại nó).

Cảm ơn bạn.

CẬP NHẬT: Tôi đã thử cùng một truy vấn với nhà cung cấp Oracle của Microsoft và nó thực thi rất nhanh. Thật không may, nhà cung cấp đó không được chấp nhận nên đây không phải là giải pháp lâu dài.

Trả lời

9

Không có gì liên quan đến nhà cung cấp ODP.NET. Vấn đề là thư viện chúng tôi sử dụng để tạo kết nối cho chúng tôi (tất nhiên, không được Oracle SQL Developer sử dụng và tôi không sử dụng khi tôi cố gắng cung cấp Microsoft) luôn thực hiện các câu sau trước khi thực hiện bất kỳ điều gì:

ALTER SESSION SET NLS_COMP = LINGUISTIC 
ALTER SESSION SET NLS_SORT = BINARY_CI 

Điều này khiến Oracle phân biệt chữ hoa chữ thường. Nhưng, chúng cũng làm cho tất cả các chỉ mục thông thường trở nên vô dụng. Bởi vì chúng tôi đang truy vấn từ Chế độ xem, nó đã được sắp xếp. Và bởi vì chúng tôi không sở hữu cơ sở dữ liệu, chúng tôi không thể làm cho các chỉ mục ngôn ngữ để khắc phục vấn đề hiệu suất.

Cung cấp cách để không thực hiện các câu lệnh trong trường hợp (hiếm) này đã khắc phục được sự cố.

+0

Trong phụ lục này câu trả lời rất hữu ích, tôi thấy rằng chạy ALTER SESSION SET NLS_COMP = BINARY; ALTER SESSION SET NLS_SORT = BINARY; đặt phiên trở lại cài đặt mặc định của nó. Chắc chắn, nó bật độ nhạy trường hợp, nhưng đó không phải là xấu như truy vấn chậm. –

+0

Làm cách nào bạn thấy rằng thư viện bạn đang sử dụng đang thực thi các câu lệnh đó? Tôi đang có một kịch bản tương tự: ngay lập tức trong Oracle Sql Developer nhưng một vài giây từ ứng dụng. Kiểm tra chính xác cùng một kịch bản trên Sql Server thực sự là nhanh hơn. Có lẽ tôi đang thiếu một số cấu hình quan trọng. –

4

suy nghĩ trước mắt là

  1. CLOB, BLOB hoặc DÀI/DÀI RAW mà đòi hỏi rất nhiều băng thông cho chỉ một vài dòng.
  2. Dữ liệu không hợp lệ (ví dụ: có các cách để đưa ngày không hợp lệ vào trường ngày, có thể gây nhầm lẫn cho một số khách hàng)
  3. "the_table" không thực sự là một bảng mà là một cái nhìn hoặc một thứ gì đó có nguồn gốc phức tạp hoặc có Chính sách bảo mật VPD/RLS/FGAC trên đó.
  4. Loại dữ liệu kỳ lạ (Không gian hoặc Người dùng xác định).

Gợi ý

  1. Rõ ràng danh sách các cột (ví dụ SELECT a, b, c TỪ the_table ĐÂU ROWNUM < 5). Thêm từng cột một cho đến khi nó ngừng hoạt động. Điều đó giả định rằng có ít nhất một cột 'đơn giản' trong bảng.
  2. Kiểm tra phiên trong phiên $ v để xem EVENT chờ là gì. Hoặc là máy chủ DB đang đốt CPU cho SQL này, hoặc nó đang chờ đợi một cái gì đó (có thể là máy khách).
  3. Kiểm tra SQL bằng v $ sql. Có một hay nhiều con con. có một hoặc nhiều PLAN_HASH_VALUEs. Con trỏ con khác nhau có thể sử dụng các kế hoạch khác nhau. Nếu không có mệnh đề WHERE ngoài ROWNUM, điều này là khá khó xảy ra.
+0

Cũng có thể đáng để kiểm tra nhật ký cảnh báo máy chủ để xem liệu có ORA-600 để đi với ORA-03135 cho truy vấn này không? –

+0

Tôi đã cập nhật câu hỏi để trả lời câu trả lời của bạn. Ngoài ra, chỉ có các trường đơn giản (trường lớn nhất là một varchar2 (576)), và vấn đề xảy ra ngay cả khi tôi chỉ chọn một trường. Bạn đúng là nó thực sự là một View. –

0

Tôi đang sử dụng odp.net để nói chuyện với cơ sở dữ liệu hệ thống bán lẻ lớn và chúng tôi sẽ gặp phải lỗi kết nối.

Phải mất rất nhiều nỗ lực để chứng minh, nhưng nó đã trở thành một chỉ mục bị hỏng bên trong cơ sở dữ liệu Oracle mà chỉ bị truy cập bởi truy vấn của chúng tôi.Cuối cùng, DBA đã truy tìm nó đến một coredump của tiến trình chạy trên hộp Sun khi truy vấn của chúng ta đang được thực hiện. Chúng tôi đã không sử dụng bất kỳ loại gợi ý truy vấn nào, nhưng khi chúng tôi chạy cùng một truy vấn trong Toad, nó không đạt đến chỉ mục cụ thể này. lạ? < <

1

Chế độ xem thêm độ phức tạp khác. Một "cột SELECT TỪ bảng WHERE rownum < 5" có lẽ chỉ là một kế hoạch giải thích duy nhất, chọn dữ liệu từ một đối tượng cục bộ duy nhất.

Đối với một cái nhìn, bạn nên bắt đầu bằng cách nhận được văn bản xem SELECT TEXT FROM ALL_VIEWS WHERE VIEW_NAME = ...

Có rất nhiều rằng có thể khác nhau giữa một ODP.NET và một phiên SQL Developer. Tôi muốn suy nghĩ về các thông số NLS (chẳng hạn như định dạng ngày) và cài đặt bộ ký tự.

Nếu bạn có thể định vị SQL trong v $ sql, bạn có thể thực hiện DBMS_XPLAN.DISPLAY_CURSOR (sql_id) để xem các gói khác nhau và xem liệu bạn có thể xác định được sự cố không.

Các vấn đề liên quan