Bạn hiện đang ngoại tuyến, hãy chờ internet để kết nối lại

INF: Sự hiểu biết và giải quyết vấn đề chặn SQL Server

QUAN TRỌNG: Bài viết này được dịch bằng phần mềm dịch máy của Microsoft chứ không phải do con người dịch. Microsoft cung cấp các bài viết do con người dịch và cả các bài viết do máy dịch để bạn có thể truy cập vào tất cả các bài viết trong Cơ sở Kiến thức của chúng tôi bằng ngôn ngữ của bạn. Tuy nhiên, bài viết do máy dịch không phải lúc nào cũng hoàn hảo. Loại bài viết này có thể chứa các sai sót về từ vựng, cú pháp hoặc ngữ pháp, giống như một người nước ngoài có thể mắc sai sót khi nói ngôn ngữ của bạn. Microsoft không chịu trách nhiệm về bất kỳ sự thiếu chính xác, sai sót hoặc thiệt hại nào do việc dịch sai nội dung hoặc do hoạt động sử dụng của khách hàng gây ra. Microsoft cũng thường xuyên cập nhật phần mềm dịch máy này.

Nhấp chuột vào đây để xem bản tiếng Anh của bài viết này:224453
TÓM TẮT
Trong bài này, thuật ngữ "kết nối" đề cập đến một đơn đăng nhập vào phiên của cơ sở dữ liệu. Mỗi kết nối xuất hiện như một phiên ID (dịch vụ SPID). Mỗi người trong số những SPID thường được gọi là một xử lý, mặc dù nó không phải là một bối cảnh quá trình riêng biệt trong ý nghĩa thông thường. Thay vào đó, mỗi dịch vụ SPID bao gồm các máy chủ tài nguyên và dữ liệu cấu trúc cần thiết để phục vụ các yêu cầu của một kết nối duy nhất từ một khách hàng nhất định. Một ứng dụng khách hàng duy nhất có thể có một hoặc nhiều kết nối. Từ các quan điểm của SQL Server, không có sự khác nhau giữa các kết nối nhiều từ một ứng dụng khách hàng duy nhất trên một máy tính khách hàng duy nhất và nhiều các kết nối từ nhiều khách hàng ứng dụng hoặc nhiều khách hàng máy tính. Một trong những kết nối có thể chặn kết nối khác, bất kể của cho dù họ xông lên từ cùng một ứng dụng hoặc các ứng dụng riêng biệt trên hai khách hàng khác nhau máy vi tính.
THÔNG TIN THÊM
Chặn là một đặc tính không thể tránh khỏi của bất kỳ quan hệ cơ sở dữ liệu quản lý (RDBMS) với hệ thống khóa dựa trên concurrency. Ngày SQL Server, chặn xảy ra khi một trong những dịch vụ SPID giữ một ổ khóa trên một nguồn tài nguyên cụ thể và một lần thứ hai Dịch vụ SPID nỗ lực để thu được một loại khóa xung đột trên cùng một tài nguyên. Thông thường, khung thời gian mà dịch vụ SPID đầu tiên khóa tài nguyên là rất nhỏ. Khi nó phát hành các khóa, kết nối thứ hai là miễn phí để thu được của nó sở hữu ổ khóa trên các nguồn tài nguyên và tiếp tục xử lý. Đây là hành vi bình thường và có thể xảy ra nhiều lần trong suốt quá trình một ngày với không có hiệu lực đáng chú ý ngày hiệu năng hệ thống.

Bối cảnh thời gian thực hiện và giao dịch của một truy vấn xác định bao lâu các ổ khóa được tổ chức và, do đó, tác động của họ ngày khác truy vấn. Nếu truy vấn không được thực hiện trong một giao dịch (và không có gợi ý khóa được sử dụng), ổ khóa cho chọn phát biểu chỉ sẽ được tổ chức vào một nguồn lực lúc thời gian nó thực sự được đọc, không phải trong suốt thời gian của các truy vấn. Cho CHÈN, Cập Nhật, và xoá bỏ báo cáo, các ổ khóa được tổ chức trong thời gian các truy vấn, cả cho sự đồng bộ dữ liệu và cho phép truy vấn để được quay ngược lại Nếu cần thiết.

Cho truy vấn thực hiện trong một giao dịch, trong suốt thời gian mà các ổ khóa được tổ chức được xác định bởi các loại truy vấn, những mức độ sự cô lập của giao dịch, và có hoặc không khóa gợi ý được sử dụng trong các truy vấn. Cho một mô tả khóa, khóa gợi ý, và sự cô lập của giao dịch mức, xem các chủ đề sau trong SQL Server sách trực tuyến:
  • Khóa trong cơ sở dữ liệu
  • Customizing khóa và hàng Versioning
  • Khóa chế độ
  • Khóa khả năng tương thích
  • Hàng Versioning dựa trên mức độ sự cô lập trong cơ sở dữ liệu
  • Việc kiểm soát các giao dịch (cơ sở dữ liệu)
Khi khóa và chặn tăng đến điểm nơi có một ảnh hưởng bất lợi cho hiệu năng hệ thống, nó là thường do một trong các lý do sau đây:
  • Một dịch vụ SPID giữ ổ khóa trên một tập hợp các nguồn lực cho một mở rộng khoảng thời gian trước khi phát hành chúng. Loại chặn giải quyết chính nó theo thời gian, nhưng có thể gây ra sự xuống cấp hiệu suất.
  • Một dịch vụ SPID giữ ổ khóa trên một tập hợp các nguồn lực và không bao giờ phát hành họ. Loại chặn không giải quyết chính nó và ngăn chặn truy cập vào các ảnh hưởng đến nguồn tài nguyên vô thời hạn.
Trong kịch bản đầu tiên ở trên, chặn vấn đề giải quyết riêng của mình theo thời gian vì dịch vụ SPID bản phát hành các âu thuyền. Tuy nhiên, tình hình có thể rất chất lỏng như khác nhau SPID gây ra chặn về tài nguyên khác nhau theo thời gian, tạo một mục tiêu di động. Vì lý do này, các tình huống có thể được khó khăn để gỡ rối bằng cách sử dụng quản lý SQL máy chủ doanh nghiệp hoặc cá nhân truy vấn SQL. Các tình hình thứ hai kết quả trong một nhà nước thống nhất mà có thể dễ dàng hơn để chẩn đoán.

Tập hợp chặn thông tin

Để chống lại những khó khăn trong xử lý sự cố chặn vấn đề, một người quản trị cơ sở dữ liệu có thể sử dụng tập lệnh SQL liên tục giám sát bang khóa và chặn trên máy chủ SQL. Các script có thể cung cấp ảnh chụp nhanh của trường hợp cụ thể theo thời gian, dẫn đến một bức tranh tổng thể của các vấn đề. Cho một mô tả làm thế nào để giám sát chặn với tập lệnh SQL, xem các bài viết sau trong cơ sở kiến thức Microsoft:
271509 Làm thế nào để giám sát chặn trong SQL Server 2005 và trong SQL Server 2000
Các kịch bản trong bài viết này sẽ thực hiện các tác vụ dưới đây. Nếu có thể, phương pháp cho việc thu thập thông tin này từ SQL Server Management Studio được đưa ra.
  1. Xác định dịch vụ SPID (Session ID) ở đầu của dãy núi chặn và các lệnh SQL.
    Thêm vào bằng cách sử dụng các kịch bản trong bài viết cơ sở kiến thức đã đề cập, bạn có thể nhận biết người đứng đầu của chuỗi chặn bằng cách sử dụng các tính năng được cung cấp thông qua SQL Server Management Studio. Để thực hiện việc này, sử dụng một trong các phương pháp sau:
    • Nhấp chuột phải vào đối tượng máy chủ, mở rộng Báo cáo, mở rộng Báo cáo tiêu chuẩn, và sau đó nhấp vào Hoạt động-chặn tất cả các giao dịch. Báo cáo này cho thấy các giao dịch ở phần đầu của chặn chuỗi. Nếu bạn mở rộng các giao dịch, báo cáo sẽ cho thấy các giao dịch đang bị chặn bởi các giao dịch đầu. Báo cáo này cũng sẽ hiển thị các "chặn SQL Statement" và "Bị chặn SQL Statement."
    • Sử dụng DBCC INPUTBUFFER (<spid>) để tìm các báo cáo trước đó đã được gửi của một dịch vụ SPID.</spid>
  2. Tìm thấy các giao dịch làm tổ cấp và quá trình trạng thái của dịch vụ SPID chặn.
    Các giao dịch làm tổ cấp của một dịch vụ SPID có sẵn trong các @@ TRANCOUNT biến toàn cầu. Tuy nhiên, nó có thể được xác định từ bên ngoài các Dịch vụ SPID bởi câu các sysprocesses bảng như sau:

    SELECT open_tran FROM master.sys.sysprocesses WHERE SPID=<blocking SPID number>go						
    Giá trị trả lại là giá trị @@ TRANCOUNT cho dịch vụ SPID. Điều này cho thấy giao dịch làm tổ cấp cho dịch vụ SPID chặn, mà lần lượt có thể giải thích tại sao nó đang nắm giữ ổ khóa. Ví dụ, nếu giá trị lớn hơn 0, các Dịch vụ SPID là ở giữa của một giao dịch (trong trường hợp nó là dự kiến rằng nó» giữ lại một số ổ khóa nó đã mua, tùy thuộc vào sự cô lập của giao dịch cấp).

    Bạn cũng có thể kiểm tra xem nếu bất kỳ lâu dài mở giao dịch tồn tại trong cơ sở dữ liệu bằng cách sử dụng DBCC OPENTRANdatabase_name.

Thu thập thông tin water Profiler SQL Server

Ngoài các thông tin trên, nó là thường cần thiết để nắm bắt một Profiler dấu vết của các hoạt động trên máy chủ để triệt để điều tra một chặn vấn đề trên máy chủ SQL. Nếu một dịch vụ SPID thực hiện nhiều phát biểu trong một giao dịch, chỉ statementthat cuối cùng đã được gửi sẽ hiển thị trong các báo cáo, bộ đệm đầu vào hoặc đầu ra màn hình hoạt động. Tuy nhiên, một trong các lệnh trước đó có thể là lý do ổ khóa vẫn còn đang được tổ chức. Một dấu vết Profiler sẽ cho phép bạn xem tất cả các lệnh thực thi bởi một dịch vụ SPID trong giao dịch hiện tại. Các bước sau giúp bạn thiết lập SQL Server Profiler để nắm bắt một dấu vết.
  1. Mở SQL Server Profiler.
  2. Trên các Tệp trình đơn, điểm đến Mới, và sau đó nhấp vào Dấu vết.
  3. Trên các Tổng quát tab, chỉ định một tên dấu vết và tên tệp để nắm bắt dữ liệu đến.

    Quan trọng Tệp dấu vết nên được ghi vào một đĩa nhanh địa phương hoặc được chia sẻ. Tránh truy tìm đến một ổ đĩa hoặc mạng chậm. Cũng chắc chắn rằng máy chủ quá trình water dữ liệu được chọn.
  4. Trên các Lựa chọn các sự kiện tab, nhấn vào đây để chọn các Hiển thị tất cả các sự kiện và các Hiển thị tất cả các cột hộp kiểm.
  5. Trên các Lựa chọn các sự kiện tab, thêm các loại sự kiện được liệt kê trong bảng 1 vào dấu vết của bạn.

    Ngoài ra, bạn có thể bao gồm các loại sự kiện bổ sung được liệt kê trong bảng 2 cho biết thêm thông tin. Nếu bạn đang chạy trong một môi trường sản xuất âm lượng cao, bạn có thể quyết định sử dụng chỉ là những sự kiện trong bảng 1, vì chúng đã được thường đủ để gỡ rối các vấn đề nhất chặn. Bao gồm các sự kiện bổ sung trong bảng 2 có thể làm cho nó dễ dàng hơn để nhanh chóng xác định nguồn gốc của vấn đề (hoặc những sự kiện này có thể cần thiết để xác định các tuyên bố thủ phạm trong thủ tục multi-statement). Tuy nhiên, bao gồm các sự kiện trong bảng 2 sẽ cũng thêm vào tải trên hệ thống và tăng kích thước đầu ra dấu vết.
Bảng 1: Sự kiện loại
Tiêu đềSự kiện
Lỗi và cảnh báoNgoại lệ
Lỗi và cảnh báoSự chú ý
Kiểm toán bảo mậtĐăng nhập kiểm toán
Kiểm toán bảo mậtKiểm toán Logout
SessionsKết nối hiện có
Thủ tục được lưu trữRPC: bắt đầu
TSQLSQL:BatchStarting

Bảng 2: Các loại sự kiện bổ sung
Tiêu đềSự kiện
Các giao dịchDTCTransaction
Các giao dịchSQLTransaction
Thủ tục được lưu trữRPC: hoàn thành
TSQLSQL:BatchCompleted
Thủ tục được lưu trữSP:StmtStarting
Thủ tục được lưu trữSP:StmtCompleted

Để biết thêm chi tiết về việc sử dụng SQL Server Profiler, xin vui lòng xem SQL Server Sách trực tuyến.

Việc xác định và giải quyết chung chặn kịch bản

Bằng cách kiểm tra các thông tin trên, bạn có thể xác định nguyên nhân hầu hết chặn vấn đề. Phần còn lại của bài viết này là một cuộc thảo luận làm thế nào để sử dụng thông tin này để xác định và giải quyết một số kịch bản chặn phổ biến. Thảo luận này giả định bạn đã sử dụng các tập lệnh chặn trong bài viết 271509 tham (chiếu trước đó) để nắm bắt thông tin về SPID chặn và đã thực hiện một dấu vết Profiler với các sự kiện được mô tả ở trên.

Xem các tập lệnh chặn đầu ra

Kiểm tra các sys.sysprocesses đầu ra để xác định những người đứng đầu của chuỗi chặn
Nếu bạn không nêu rõ nhanh chế độ cho các tập lệnh chặn, sẽ có một phần có tiêu đề "SPID ở phần đầu của chặn chuỗi" mà danh sách các SPID đang chặn khác SPID trong đầu ra kịch bản.
SPIDs at the head of blocking chains
Nếu bạn chỉ định các tùy chọn nhanh, bạn vẫn có thể xác định các chặn đứng đầu bằng cách xem xét các sys.sysprocesses đầu ra và theo hệ thống phân cấp của dịch vụ SPID được báo cáo trong cột bị chặn.
Kiểm tra các sys.sysprocesses đầu ra cho thông tin về SPID ở đầu của dãy núi chặn.
Nó là quan trọng để đánh giá như sau sys.sysprocesses các lĩnh vực:

Trạng thái

Cột này cho thấy các tình trạng của một dịch vụ SPID cụ thể. Thông thường, một ngủ tình trạng cho thấy rằng dịch vụ SPID đã hoàn thành thực hiện và chờ đợi cho các ứng dụng để gửi một truy vấn hay lô. Một Runnable, chạy, hoặc sos_scheduler_yield tình trạng cho thấy rằng dịch vụ SPID hiện đang xử lý một truy vấn. Các Bảng sau cho giải thích ngắn gọn về tình trạng khác nhau các giá trị.
Trạng tháiÝ nghĩa
NềnDịch vụ SPID chạy một nền nhiệm vụ, chẳng hạn như bế tắc phát hiện.
NgủDịch vụ SPID không hiện đang thực hiện. Điều này thường chỉ ra rằng dịch vụ SPID đang chờ lệnh từ các ứng dụng.
ChạyDịch vụ SPID hiện đang chạy trên một trình lên lịch.
RunnableDịch vụ SPID là trong hàng đợi runnable một trình lên lịch và chờ đợi để có được lập lịch thời gian.
Sos_scheduler_yieldDịch vụ SPID chạy, nhưng nó đã mang lại tự nguyện của nó thời gian lát trên trình lập lịch biểu cho phép dịch vụ SPID khác để có được lập lịch thời gian.
Đình chỉDịch vụ SPID chờ đợi cho một sự kiện, chẳng hạn như một khóa hoặc một chốt.
Quay ngược lạiDịch vụ SPID là trong cuộn ngược của một giao dịch.
DefwakeupChỉ ra rằng dịch vụ SPID chờ đợi cho một nguồn tài nguyên đó là trong quá trình đang được giải thoát. Lĩnh vực waitresource nên chỉ ra các nguồn tài nguyên trong câu hỏi.

Open_tran

Lĩnh vực này sẽ cho bạn biết các giao dịch làm tổ cấp của dịch vụ SPID. Nếu giá trị này là lớn hơn 0, dịch vụ SPID là trong phạm vi một giao dịch mở và có thể giữ ổ khóa được mua lại bởi bất kỳ tuyên bố trong vòng giao dịch.

Lastwaittype, waittype và waittime

Các lastwaittype lĩnh vực là một chuỗi đại diện của các waittype lĩnh vực này, mà là một cột dành riêng nội bộ nhị phân. Nếu waittype là 0x0000, dịch vụ SPID không phải hiện đang chờ đợi bất cứ điều gì và các lastwaittype giá trị chỉ ra cuối cùng waittype rằng dịch vụ SPID đã có. Nếu waittype không phải là zero, các lastwaittype giá trị chỉ ra hiện nay waittype của dịch vụ SPID.

Cho một mô tả ngắn gọn về sự khác nhau lastwaittypewaittype các giá trị, xem các bài viết sau đây trong Microsoft Kiến thức cơ bản:
822101 Mô tả của waittype và lastwaittype cột trong bảng master.dbo.sysprocesses trong SQL Server 2000 và SQL Server 2005
Để biết thêm thông tin về sys.dm_os_wait_stats, thấy SQL Server sách trực tuyến.

Các waittime giá trị có thể được sử dụng để xác định nếu dịch vụ SPID là làm cho tiến bộ. Khi một truy vấn đối với các sys.sysprocesses bảng trả về một giá trị trong các waittime cột đó là ít hơn các waittime giá trị từ một truy vấn trước đó của sys.sysprocesses, điều này chỉ ra rằng trước khi khóa được mua lại và phát hành và bây giờ chờ đợi trên một ổ khóa mới (giả sử không waittime). Điều này có thể được kiểm chứng bằng cách so sánh các waitresource giữa sys.sysprocesses đầu ra.

Waitresource

Lĩnh vực này chỉ ra các nguồn tài nguyên rằng một dịch vụ SPID chờ đợi. Bảng sau đây liệt kê phổ biến waitresource định dạng và ý nghĩa của họ:
Tài nguyênĐịnh dạngVí dụ
BảngDatabaseID:ObjectID:IndexIDTHẺ: 5:261575970:1
Trong trường hợp này, cơ sở dữ liệu ID 5 là các quán rượu mẫu cơ sở dữ liệu và đối tượng ID 261575970 là các tiêu đề bảng và 1 là chỉ mục tập hợp.
TrangDatabaseID:FileID:PageIDTRANG: 5:1:104
Trong trường hợp này, cơ sở dữ liệu ID 5 là quán rượu, tệp ID 1 là các tập tin dữ liệu chính, và trang 104 là một trang thuộc về các tiêu đề bảng.

Để xác định các id đối tượng mà trang thuộc về, sử dụng lệnh DBCC trang (dbid, fileid, pageid, output_option), và xem xét m_objId. Ví dụ:
DBCC TRACEON ( 3604 )DBCC PAGE ( 5 , 1 , 104 , 3 )
KeyDatabaseID:Hobt_id (giá trị băm cho chỉ số khóa)KEY: 5:72057594044284928 (3300a4f361aa)

Trong trường hợp này, cơ sở dữ liệu ID 5 là quán rượu, Hobt_ID 72057594044284928 tương ứng với các nhóm index_id 2 cho đối tượng id 261575970)tiêu đề bảng). Sử dụng dạng xem danh mục sys.partitions liên kết hobt_id để một cụ thể chỉ số id và đối tượng id. Không có không có cách nào để unhash chỉ số chủ chốt băm một giá trị cụ thể chỉ số chủ chốt.
HàngDatabaseID:FileID:PageID:Slot(row)THOÁT: 5:1:104:3

Trong trường hợp này, cơ sở dữ liệu ID 5 là quán rượu, tệp ID 1 là các tập tin dữ liệu chính, trang 104 là một trang thuộc về tiêu đề bảng và khe 3 cho thấy vị trí của hàng trên trang.
Biên dịchDatabaseID:ObjectID [[biên dịch]]TAB: 5:834102012 [[biên dịch]] điều này không phải là một bảng khóa, nhưng thay vào đó là một ổ khóa biên dịch trên một thủ tục được lưu trữ. Cơ sở dữ liệu ID 5 quán rượu, đối tượng ID 834102012 thủ tục được lưu trữ usp_myprocedure. Xem kho tàng kiến thức bài 263889 cho thêm thông tin về chặn gây ra bởi biên dịch ổ khóa.
Cột khác

Còn lại sys.sysprocesses cột có thể cung cấp cái nhìn sâu sắc vào gốc rễ của một vấn đề là tốt. Tính hữu dụng của họ khác nhau tùy thuộc vào hoàn cảnh của vấn đề. Cho Ví dụ, bạn có thể xác định nếu vấn đề xảy ra chỉ từ một số khách hàng (hostname), trên một số mạng thư viện (net_library), khi những đợt cuối Gửi bởi một dịch vụ SPID là (last_batch), vv.
Kiểm tra kết xuất DBCC INPUTBUFFER.
Cho bất kỳ dịch vụ SPID ở phần đầu của một chuỗi chặn hoặc với một không waittype, các tập lệnh chặn sẽ thực hiện DBCC INPUTBUFFER để xác định các truy vấn hiện tại cho rằng dịch vụ SPID.

Trong nhiều trường hợp, đây là các truy vấn đó gây ra các ổ khóa mà đang chặn người dùng khác sẽ được tổ chức. Tuy nhiên, nếu dịch vụ SPID là trong vòng một giao dịch, các ổ khóa có thể được mua lại bởi một truy vấn trước đó bị hành quyết, không phải là một hiện tại. Vì vậy, bạn cũng nên xem ra Profiler cho dịch vụ SPID, không chỉ inputbuffer.

Chú ý Bởi vì các tập lệnh chặn bao gồm nhiều bước, nó là có thể một dịch vụ SPID có thể xuất hiện trong phần đầu tiên là người đứng đầu một chặn chuỗi, nhưng theo thời gian truy vấn DBCC INPUTBUFFER được thi hành, nó không còn chặn và INPUTBUFFER không bị bắt. Điều này chỉ ra rằng các chặn việc giải quyết chính nó cho dịch vụ SPID đó và nó có thể hoặc có thể không có một vấn đề. Tại đây điểm, bạn có thể hoặc là dùng phiên bản nhanh chóng của các tập lệnh chặn để cố gắng đảm bảo bạn nắm bắt inputbuffer trước khi nó xóa (dù không vẫn không có đảm bảo), hoặc xem dữ liệu hồ sơ từ đó khung thời gian để xác định những gì truy vấn dịch vụ SPID thực hiện.

Xem dữ liệu hồ sơ

Xem dữ liệu hồ sơ hiệu quả là rất có giá trị trong giải quyết các vấn đề chặn. Điều quan trọng nhất để nhận ra là bạn làm không phải nhìn vào tất cả mọi thứ bạn bắt; được chọn lọc. Cung cấp hồ sơ khả năng để giúp bạn có hiệu quả xem các dữ liệu được quay. Trong các Thuộc tính hộp thoại (trên các Tệp trình đơn, nhấp vào Thuộc tính), Profiler cho phép bạn để giới hạn các dữ liệu được hiển thị bằng cách loại bỏ dữ liệu cột hoặc sự kiện, nhóm (phân loại) bởi dữ liệu cột và áp dụng các bộ lọc. Bạn có thể tìm kiếm dấu vết toàn bộ hoặc chỉ có một cột cụ thể cho cụ thể các giá trị (trên các Chỉnh sửa trình đơn, nhấp vào Tìm). Bạn cũng có thể lưu dữ liệu hồ sơ vào một bảng SQL Server (ngày các Tệp trình đơn, điểm đến Löu laøm và sau đó nhấp vào Bảng) và chạy truy vấn SQL chống lại nó.

Hãy cẩn thận rằng bạn thực hiện lọc chỉ vào một tập tin đã lưu trước đó water. Nếu bạn thực hiện các bước trên một dấu vết của hoạt động, bạn nguy cơ mất dữ liệu đã bị bắt vì vết đã được bắt đầu. Lưu một hoạt động theo dõi vào một tập tin hoặc bảng đầu tiên (trên các Tệp trình đơn, nhấp vào Löu laøm) và sau đó mở lại nó (trên các Tệp trình đơn, nhấp vào Mở) trước khi tiếp tục. Khi làm việc trên một tập tin đã lưu water, các lọc không loại vĩnh viễn bỏ dữ liệu đang được lọc ra, nó chỉ không không hiển thị tất cả các dữ liệu. Bạn có thể thêm và loại bỏ các sự kiện và dữ liệu cột như cần thiết để giúp tập trung tìm kiếm của bạn.

Điều gì để tìm:
  • Những gì lệnh có dịch vụ SPID ở phần đầu của một chuỗi chặn thực hiện trong giao dịch hiện tại?
    Lọc dữ liệu dấu vết cho một dịch vụ SPID đặc biệt là ở phần đầu của một chuỗi chặn (trên các Tệp trình đơn, nhấp vào Thuộc tính; sau đó vào các Các bộ lọc ghi thẻ rõ giá trị dịch vụ SPID). Bạn có thể sau đó kiểm tra các lệnh nó đã thực hiện trước khi đến thời điểm nó chặn khác SPID. Nếu bạn bao gồm các Các sự kiện giao dịch, họ có thể dễ dàng xác định khi một giao dịch đã được bắt đầu. Nếu không, bạn có thể tìm kiếm các Văn bản cột để bắt đầu, tiết kiệm, cam kết hoặc quay ngược lại giao dịch hoạt động kinh doanh. Sử dụng các open_tran giá trị từ các sysprocesses bảng để đảm bảo rằng bạn nắm bắt tất cả các sự kiện giao dịch. Hiểu biết các lệnh hành quyết và bối cảnh giao dịch sẽ cho phép bạn xác định lý do tại sao một dịch vụ SPID đang nắm giữ ổ khóa.

    Hãy nhớ rằng, bạn có thể loại bỏ các sự kiện và dữ liệu cột. Thay vì của nhìn vào cả hai bắt đầu và hoàn thành các sự kiện, chọn một. Nếu SPID chặn không thủ tục được lưu trữ, loại bỏ cácSP: bắt đầu hoặc SP: hoàn thành các sự kiện; các SQLBatchRPC sự kiện sẽ hiển thị các cuộc gọi thủ tục. Chỉ xem các sự kiện SP khi bạn cần phải thấy rằng mức độ chi tiết.
  • Trong suốt thời gian của các truy vấn cho SPID lúc đầu là gì của chặn chuỗi?
    Nếu bạn bao gồm các sự kiện đã hoàn thành ở trên, các Thời gian cột sẽ hiển thị thời gian thực hiện truy vấn. Điều này có thể giúp bạn xác định dài chạy truy vấn đang gây ra chặn. Để xác định lý do tại sao các truy vấn thực hiện từ từ, xem các CPU, Đọc, và Viết cột, cũng như các Thực hiện kế hoạch sự kiện.

Phân loại kịch bản chặn phổ biến

Bảng dưới đây các bản đồ triệu chứng phổ biến để có thể xảy ra nguyên nhân của họ. Số chỉ ra trong các Kịch bản cột tương ứng với một số trong những "thường chặn Kịch bản và nghị quyết"phần của bài viết này dưới đây. Các Waittype, Open_Tran, và Trạng thái cột tham khaûo sysprocesses thông tin. Các Giải quyết? cột chỉ ra hoặc không chặn sẽ giải quyết trên của nó riêng.

Kịch bảnWaittypeOpen_TranTrạng tháiGiải quyết?Khác Hiện tượng
1Non-zero>= 0RunnableCó, khi kết thúc truy vấn.Physical_IO, CPU và/hoặc Memusage cột sẽ tăng lên theo thời gian. Thời gian cho truy vấn sẽ cao khi hoàn thành.
20x0000> 0ngủKhông nhưng dịch vụ SPID có thể sẽ bị giết.Một tín hiệu sự quan tâm có thể được nhìn thấy trong hồ sơ dấu vết cho dịch vụ SPID này, chỉ một thời gian chờ truy vấn hoặc hủy bỏ đã xảy ra.
30x0000> = 0RunnableKhông. Sẽ không giải quyết cho đến khi khách hàng fetches tất cả các hàng hoặc đóng kết nối. Có thể dịch vụ SPID bị giết, nhưng nó có thể mất đến 30 giây.Nếu open_tran = 0, và dịch vụ SPID giữ ổ khóa trong khi sự cô lập của giao dịch đô thị này có mức độ mặc định (đọc COMMMITTED), đây là một nguyên nhân có khả năng.
4Thay đổi> = 0RunnableKhông. Sẽ không giải quyết cho đến khi khách hàng hủy bỏ truy vấn hoặc đóng các kết nối. Có thể SPID bị giết, nhưng có thể mất đến 30 giây.Các tên miền máy chủ cột trong sysprocesses cho dịch vụ SPID ở phần đầu của một chuỗi chặn sẽ giống như một trong dịch vụ SPID nó ngăn chặn.
50x0000> 0quay ngược lạiCó.Một sự chú ý tín hiệu có thể được nhìn thấy trong dấu vết Profiler cho dịch vụ SPID này, chỉ ra một thời gian chờ truy vấn hoặc hủy bỏ đã xảy ra, hoặc chỉ đơn giản là một tuyên bố quay ngược lại đã Ban hành.
60x0000> 0ngủCuối cùng. Khi Windows NT sẽ xác định phiên giao dịch là không có hoạt động lâu hơn, SQL Server kết nối sẽ được chia.Các last_batch giá trị sản xuất sysprocesses là nhiều sớm hơn thời gian hiện nay.

Phổ biến chặn kịch bản và nghị quyết

Các kịch bản được liệt kê dưới đây sẽ có các đặc tính được liệt kê trong bảng ở trên. Phần này cung cấp thêm chi tiết khi áp dụng, cũng như các đường dẫn đến độ phân giải.
  1. Chặn do thường chạy truy vấn với một thời gian dài thực hiện

    Ðộ phân giải:
    Các giải pháp cho loại hình chặn vấn đề này là để tìm kiếm cách để tối ưu hóa các truy vấn. Trên thực tế, lớp chặn vấn đề này có thể chỉ là một vấn đề hiệu suất, và yêu cầu bạn phải theo đuổi nó như vậy. Để có thông tin ngày xử lý sự cố một truy vấn cụ thể chạy chậm, xem bài viết cơ sở kiến thức Microsoft sau:
    243589 Làm thế nào để khắc phục sự cố truy vấn chậm-chạy SQL Server 7.0 hoặc trên phiên bản mới nhất
    Cho hiệu suất tổng thể ứng dụng xử lý sự cố, xem bài viết cơ sở kiến thức sau:
    224587 Làm thế nào để: Gỡ rối ứng dụng hiệu suất với SQL Server
    Để biết thêm chi tiết, xem các Hiệu suất giám sát và điều chỉnh các chủ đề làm thế nào để SQL Server 2008 sách trực tuyến chủ đề trên MSDN Web site sau: Nếu bạn có một truy vấn dài chạy là chặn người dùng khác và có thể không tối ưu hóa, xem xét việc di chuyển nó từ một OLTP môi trường để một hệ thống hỗ trợ quyết định.
  2. Chặn gây ra bởi một dịch vụ SPID ngủ mà đã mất theo dõi của giao dịch làm tổ cấp

    Loại chặn thường có thể được xác định bởi một dịch vụ SPID đó ngủ, hoặc đang chờ một lệnh, được nêu ra mà giao dịch làm tổ cấp (@@ TRANCOUNT, open_tran từ sysprocesses) là lớn hơn 0. Điều này có thể xảy ra nếu các ứng dụng kinh nghiệm một thời gian chờ truy vấn, hoặc các vấn đề một hủy bỏ mà không có cũng phát hành các yêu cầu số ROLLBACK và/hoặc cam kết báo cáo. Khi nhận được một dịch vụ SPID một thời gian chờ truy vấn hoặc hủy bỏ, nó sẽ chấm dứt truy vấn hiện tại và hàng loạt, nhưng không tự động cuộn ngược hoặc cam kết giao dịch. Ứng dụng này chịu trách nhiệm về điều này, như SQL Server không thể giả định rằng một giao dịch toàn bộ phải được cuộn ngược lại chỉ đơn giản là nhờ một truy vấn duy nhất đang được hủy bỏ. Truy vấn thời gian chờ hoặc hủy bỏ sẽ xuất hiện như một sự kiện tín hiệu sự chú ý cho dịch vụ SPID trong các Profiler water.

    Để chứng minh điều này, vấn đề truy vấn đơn giản sau đây từ truy vấn Analyzer:

    BEGIN TRAN SELECT * FROM SYSOBJECTS S1, SYSOBJECTS S2-- Issue this after canceling querySELECT @@TRANCOUNTROLLBACK TRAN						
    Trong khi các truy vấn thực hiện, nhấp vào màu đỏ Hủy bỏ nút. Sau khi truy vấn được hủy bỏ, chọn @@ TRANCOUNT chỉ ra rằng giao dịch làm tổ cấp là một trong. Điều này đã là xóa bỏ một hoặc một bản Cập Nhật truy vấn, hoặc có HOLDLOCK được sử dụng trên những lựa chọn, tất cả các ổ khóa được mua sẽ vẫn được tổ chức. Ngay cả với các truy vấn ở trên, nếu một truy vấn đã mua lại và tổ chức khóa trước đó trong các giao dịch, họ sẽ vẫn được tổ chức khi các bên trên CHỌN đã bị hủy bỏ.

    Nghị quyết:

    • Các ứng dụng phải đúng cách quản lý giao dịch làm tổ cấp, hoặc họ có thể gây ra một vấn đề chặn sau việc hủy bỏ các truy vấn theo cách này. Điều này có thể được thực hiện trong một trong một số cách:
      1. Trong xử lý lỗi của ứng dụng khách hàng, gửi một nếu @@ TRANCOUNT > 0 ROLLBACK trần sau bất kỳ lỗi, ngay cả khi các ứng dụng khách không tin một giao dịch là mở. Điều này là cần thiết, bởi vì một thủ tục được lưu trữ gọi là trong lô có thể đã bắt đầu một giao dịch mà không có kiến thức ứng dụng khách. Lưu ý rằng một số điều kiện, chẳng hạn như truy vấn, huỷ ngăn các thủ tục thi công qua các báo cáo hiện tại, vì vậy ngay cả khi các thủ tục có logic để kiểm tra nếu @@ LỖI <> 0 và abort giao dịch, mã quay ngược lại này sẽ không thực hiện trong trường hợp này.
      2. Sử dụng đặt XACT_ABORT ON cho kết nối, hoặc trong bất kỳ lưu trữ thủ tục mà bắt đầu giao dịch và không làm sạch lên sau một lỗi. Trong trường hợp của một lỗi thời gian chạy, thiết đặt này sẽ hủy bỏ bất kỳ mở các giao dịch và kiểm soát trở lại cho khách hàng. Lưu ý rằng T-SQL phát biểu sau những tuyên bố đã gây ra lỗi sẽ không được thực thi.
      3. Nếu kết nối chia tài nguyên đang được sử dụng trong một ứng dụng đó sẽ mở ra kết nối và chạy một số truy vấn trước khi phát hành kết nối quay lại hồ bơi, chẳng hạn như một ứng dụng dựa trên Web, tạm thời vô hiệu hoá kết nối tổng hợp có thể giúp làm giảm bớt vấn đề cho đến khi ứng dụng khách được cải tiến để xử lý các lỗi một cách thích hợp. Bởi vô hiệu hoá kết nối tổng hợp, phát hành kết nối sẽ gây ra một vật lý đăng xuất của kết nối máy chủ SQL, dẫn đến máy chủ lăn trở lại bất kỳ mở các giao dịch.
      4. Nếu kết nối tổng hợp được kích hoạt và các máy chủ đích là SQL Server 2000, nâng cấp máy tính khách hàng để MDAC 2,6 hoặc mới hơn có thể mang lại lợi ích. Phiên bản này của các thành phần MDAC thêm mã trình điều khiển ODBC và OLE DB nhà cung cấp để cho kết nối sẽ được "đặt lại" trước khi nó được tái sử dụng. Cuộc gọi này để sp_reset_connection hủy bỏ bất kỳ máy chủ khởi xướng các giao dịch (DTC giao dịch khởi xướng bởi các ứng dụng khách hàng không bị ảnh hưởng), đặt lại cơ sở dữ liệu mặc định, đặt tùy chọn và vv. Chú ý rằng kết nối không được đặt lại cho đến khi nó được tái sử dụng từ hồ bơi kết nối, do đó, nó có thể là một người sử dụng có thể mở một giao dịch và sau đó phát hành các kết nối đến hồ bơi kết nối, nhưng nó có thể không được tái sử dụng cho một số giây, trong thời gian giao dịch sẽ vẫn mở. Nếu kết nối là không được tái sử dụng, giao dịch sẽ được hủy bỏ khi kết nối lần và được lấy ra từ các hồ bơi kết nối. Vì vậy, nó là tối ưu cho khách hàng ứng dụng để hủy bỏ giao dịch của họ xử lý lỗi hoặc sử dụng đặt XACT_ABORT ON để tránh chậm trễ tiềm năng này.
    • Trên thực tế, lớp chặn vấn đề này cũng có thể một vấn đề hiệu suất, và yêu cầu bạn phải theo đuổi nó như vậy. Nếu truy vấn thời gian thực hiện có thể được giảm bớt, thời gian chờ truy vấn hoặc hủy bỏ sẽ không xảy ra. Nó là quan trọng là các ứng dụng có thể xử lý thời gian chờ hoặc hủy bỏ kịch bản nên họ phát sinh, nhưng bạn cũng có thể hưởng lợi từ cách kiểm tra các hiệu suất của các truy vấn.
  3. Chặn gây ra bởi một dịch vụ SPID mà ứng dụng khách hàng tương ứng không lấy tất cả các kết quả hàng hoàn thành

    Sau khi gửi một truy vấn đến máy chủ, tất cả các ứng dụng ngay lập tức phải lấy tất cả các kết quả hàng để hoàn thành. Nếu một ứng dụng nào không lấy tất cả các kết quả hàng, ổ khóa có thể được trái trên bàn, chặn khác người sử dụng. Nếu bạn đang sử dụng một ứng dụng mà minh bạch nộp SQL báo cáo đến máy chủ, các ứng dụng phải lấy tất cả các kết quả hàng. Nếu nó không (và nếu nó không thể được cấu hình để làm như thế), bạn có thể không có khả năng giải quyết chặn vấn đề. Để tránh vấn đề này, bạn có thể hạn chế hoạt động kém cư xử các ứng dụng để báo cáo một hoặc quyết định hỗ trợ cơ sở dữ liệu.

    Ðộ phân giải:

    Ứng dụng phải được tái bằng văn bản để lấy tất cả các hàng của kết quả để hoàn thành.
  4. Chặn gây ra bởi một bế tắc phân phối của khách hàng/máy chủ

    Không giống như một bế tắc thông thường, một bế tắc phân phối không phải là phát hiện bằng cách sử dụng trình quản lý khóa RDBMS. Điều này là do thực tế là duy nhất của các nguồn lực tham gia vào bế tắc là một khóa SQL Server. Các phía bên kia của bế tắc là ở mức độ ứng dụng khách hàng, qua đó SQL Hệ phục vụ đã không kiểm soát. Sau đây là hai ví dụ về làm thế nào điều này có thể xảy ra, và những cách có thể ứng dụng có thể tránh nó.

    1. Khách hàng/máy chủ phân phối bế tắc với một khách hàng duy nhất Chủ đề
      Nếu khách hàng có nhiều mở các kết nối, và một chủ đề duy nhất của thực hiện, bế tắc phân phối sau đây có thể xảy ra. Cho ngắn gọn, cụm từ "dbproc" được sử dụng ở đây nói đến cấu trúc kết nối khách hàng.

       SPID1------blocked on lock------->SPID2  /\                         (waiting to write results           |                           back to client)  |                                 |  |                                 |                      Server side  | ================================|==================================  |     <-- single thread -->       |                      Client side  |                                 \/  dbproc1   <-------------------   dbproc2 (waiting to fetch             (effectively blocked on dbproc1, awaiting  next row)                     single thread of execution to run)								
      Trong trường hợp hiển thị ở trên, một chủ đề ứng dụng khách hàng duy nhất có hai kết nối mở. Nó không đồng bộ nộp một hoạt động SQL ngày dbproc1. Điều này có nghĩa là nó không phải chờ vào các cuộc gọi trở lại trước khi tiếp tục. Các ứng dụng sau đó nộp một SQL thao tác trên dbproc2, và đang chờ các kết quả để bắt đầu xử lý dữ liệu trở lại. Khi dữ liệu khởi động trở lại (cho dù dbproc đầu tiên đáp ứng--giả định đây là dbproc1), nó xử lý để hoàn thành tất cả các dữ liệu trở lại vào đó dbproc. Nó fetches kết quả từ dbproc1 cho đến khi SPID1 bị chặn trên một khóa được tổ chức bởi SPID2 (bởi vì hai truy vấn đang chạy không đồng bộ trên máy chủ). Tại thời điểm này, dbproc1 sẽ chờ vô thời hạn cho nhiều dữ liệu. SPID2 không bị chặn trên một ổ khóa, nhưng cố gắng gửi dữ liệu cho các khách hàng, dbproc2. Tuy nhiên, dbproc2 có hiệu quả bị chặn trên dbproc1 ở lớp ứng dụng như sợi chỉ duy nhất thực hiện cho các ứng dụng đang dùng bởi dbproc1. Điều này kết quả trong một bế tắc rằng máy chủ SQL không thể phát hiện hoặc giải quyết bởi vì chỉ có một trong các nguồn tài nguyên liên quan là một SQL Tài nguyên máy chủ.
    2. Khách hàng/máy chủ phân phối bế tắc với một Thread trên mỗi Kết nối

      Thậm chí nếu một thread riêng biệt tồn tại cho từng kết nối ngày khách hàng, một biến thể của này bế tắc phân phối thể xảy vẫn ra như được hiển thị bởi sau đây.

      SPID1------blocked on lock-------->SPID2  /\                         (waiting on net write)        Server side  |                                 |  |                                 |  | INSERT                          |SELECT  | ================================|==================================  |     <-- thread per dbproc -->   |                      Client side  |                                 \/  dbproc1   <-----data row-------   dbproc2 (waiting on                     (blocked on dbproc1, waiting for it  insert)                         to read the row from its buffer)								
      Trường hợp này là tương tự với ví dụ A, ngoại trừ dbproc2 và SPID2 chạy một tuyên bố chọn với ý định thực hiện hàng tại một thời gian chế biến và bàn giao mỗi hàng thông qua một bộ đệm để dbproc1 cho một CHÈN, Cập Nhật, hoặc xóa tuyên bố vào cùng một bảng. Cuối cùng, SPID1 (biểu diễn INSERT, UPDATE, hoặc xóa) sẽ trở thành bị chặn trên một khóa được tổ chức bởi SPID2 (thực hiện những lựa chọn). SPID2 viết liên tiếp kết quả để dbproc2 khách hàng. Dbproc2 sau đó cố gắng để vượt qua dòng trong một bộ đệm để dbproc1, nhưng thấy dbproc1 là bận rộn (nó bị chặn chờ đợi ngày SPID1 để kết thúc CHÈN hiện tại, đó là bị chặn trên SPID2). Tại thời điểm này, dbproc2 bị chặn tại lớp ứng dụng bởi dbproc1 mà dịch vụ SPID (SPID1) ở cấp độ cơ sở dữ liệu bị chặn SPID2. Một lần nữa, Điều này kết quả trong một bế tắc mà SQL Server không thể phát hiện hoặc giải quyết bởi vì chỉ là một trong các nguồn tài nguyên liên quan là một nguồn tài nguyên máy chủ SQL.
    Cả hai ví dụ a và b là cơ bản các vấn đề mà các nhà phát triển ứng dụng phải được nhận thức của. Họ phải mã các ứng dụng để xử lý những trường hợp một cách thích hợp.

    Nghị quyết:

    Hai giải pháp đáng tin cậy là sử dụng hoặc là một truy vấn thời gian chờ hoặc kết nối bị ràng buộc.

    • Thời gian chờ truy vấn
      Khi một thời gian chờ truy vấn đã cung cấp, nếu bế tắc phân phối diễn ra, nó sẽ bị hỏng khi sau đó thời gian chờ sẽ xảy ra. Xem thư viện DB hoặc tài liệu ODBC cho biết thêm thông tin về cách sử dụng một thời gian chờ truy vấn.
    • Ràng buộc các kết nối
      Tính năng này cho phép một khách hàng có nhiều kết nối để ràng buộc chúng vào một không gian của giao dịch duy nhất, vì vậy các kết nối không chặn lẫn nhau. Để biết thêm thông tin, hãy xem sử dụng" Ràng buộc các kết nối"chủ đề trong SQL Server 7.0 sách trực tuyến.
  5. Chặn gây ra bởi một dịch vụ SPID trong một "vàng", hoặc quay ngược lại, nhà nước

    Một sửa đổi dữ liệu truy vấn đó đã chết, hoặc hủy bỏ bên ngoài của một người dùng xác định giao dịch, sẽ được quay ngược lại. Điều này cũng có thể xảy ra như là một tác dụng phụ của khởi động các khách hàng máy tính lại và phiên họp mạng của nó ngắt kết nối. Tương tự như vậy, một truy vấn chọn là nạn nhân bế tắc sẽ được quay ngược Quay lại. Một sửa đổi dữ liệu truy vấn thường không thể được cuộn ngược lại bất kỳ nhanh hơn các thay đổi ban đầu được áp dụng. Ví dụ, nếu một xóa, CHÈN hoặc Cập Nhật tuyên bố đã chạy cho một giờ, nó có thể mất ít nhất một giờ để cuộn Quay lại. Đây là hành vi mong đợi, bởi vì những thay đổi được thực hiện phải hoàn toàn ngược lại, hoặc giao dịch và vật lý toàn vẹn trong cơ sở dữ liệu sẽ bị tổn hại. Bởi vì điều này phải xảy ra, SQL Server đánh dấu dịch vụ SPID trong một "vàng" hoặc quay ngược lại nhà nước (có nghĩa là nó không thể bị giết hoặc được chọn như một bế tắc nạn nhân). Điều này thường có thể được xác định bằng cách quan sát đầu ra của sp_who, mà có thể chỉ ra lệnh quay ngược lại. Các Trạng thái cột của sys.sysprocesses sẽ chỉ ra một tình trạng quay ngược lại, cũng sẽ xuất hiện trong sp_who sản lượng hoặc trong SQL Server Management Studio hoạt động màn hình.
    Ðộ phân giải:

    Bạn phải chờ đợi cho dịch vụ SPID để kết thúc lăn trở lại các những thay đổi đã được thực hiện.

    Nếu máy chủ đóng cửa trong midst của thao tác này, cơ sở dữ liệu sẽ trong chế độ phục hồi sau khi khởi động lại, và nó sẽ không thể tiếp cận cho đến khi tất cả các mở các giao dịch được thực hiện. Khởi động phục hồi mất cơ bản cùng một lượng thời gian cho mỗi giao dịch như thời gian chạy phục hồi, và cơ sở dữ liệu là không thể tiếp cận trong giai đoạn này. Vì vậy, buộc máy chủ xuống để sửa chữa một dịch vụ SPID trong trạng thái quay ngược lại sẽ thường xuyên phản tác.

    Để tránh tình trạng này, không thực hiện việc lớn lô INSERT, UPDATE, hoặc xóa các hoạt động trong thời gian bận rộn giờ trên hệ thống OLTP. Nếu có thể, thực hiện các hoạt động trong giai đoạn hoạt động thấp.
  6. Chặn gây ra bởi một kết nối mồ côi

    Nếu các bẫy ứng dụng khách hàng hoặc khách hàng trạm làm việc được khởi động lại, các phiên họp mạng phục vụ có thể không ngay lập tức bị hủy bỏ một số điều kiện. Từ quan điểm của máy chủ, các khách hàng vẫn thể hiện tại, và bất cứ ổ khóa có được thể vẫn giữ lại. Để biết thêm thông tin, hãy bấm vào số bài viết sau để xem bài viết trong Cơ sở Kiến thức Microsoft:
    137983Làm thế nào để khắc phục sự cố kết nối mồ côi trong SQL Server

    Ðộ phân giải:

    Nếu ứng dụng khách đã ngắt kết nối mà không cần một cách thích hợp làm sạch lên tài nguyên của nó, bạn có thể chấm dứt dịch vụ SPID bằng cách sử dụng lệnh KILL. Lệnh KILL mất giá trị dịch vụ SPID như đầu vào. Ví dụ, giết SPID 9, chỉ đơn giản là vấn đề lệnh sau:

    KILL 9						

    Chú ý Lệnh KILL có thể mất đến 30 giây để hoàn thành, do khoảng thời gian giữa kiểm tra cho lệnh KILL.

Sự tham gia của ứng dụng trong chặn vấn đề

Có thể có xu hướng tập trung vào phía máy chủ điều chỉnh và nền tảng các vấn đề khi phải đối mặt với một chặn vấn đề. Tuy nhiên, làm này thường không dẫn đến một độ phân giải, và có thể hấp thụ thời gian và năng lượng tốt hơn hướng dẫn tại kiểm tra các ứng dụng khách hàng và các truy vấn đó nộp. Không có vấn đề gì mức độ khả năng hiển thị các ứng dụng cho thấy nhiều liên quan đến cơ sở dữ liệu gọi là thực hiện, một chặn vấn đề Tuy nhiên thường xuyên yêu cả hai việc kiểm tra của SQL phát biểu chính xác gửi bởi các ứng dụng và các ứng dụng chính xác hành vi liên quan đến truy vấn hủy, quản lý kết nối, Lấy tất cả các kết quả hàng, và như vậy. Nếu công cụ phát triển không cho phép rõ ràng kiểm soát quản lý kết nối, hủy bỏ truy vấn, truy vấn timeout, kết quả Lấy, và như vậy, ngăn chặn vấn đề không thể resolvable. Tiềm năng này nên được kiểm tra chặt chẽ trước khi chọn một công cụ phát triển ứng dụng cho SQL Server, đặc biệt là cho các doanh nghiệp quan trọng OLTP môi trường.

Nó là quan trọng chăm sóc tuyệt vời được thực hiện trong giai đoạn thiết kế và xây dựng của cơ sở dữ liệu và ứng dụng. Đặc biệt, tiêu thụ tài nguyên, mức độ cách ly, và chiều dài đường dẫn giao dịch sẽ được đánh giá cho mỗi truy vấn. Mỗi truy vấn và giao dịch phải càng nhẹ càng tốt. Tốt kỷ luật quản lý kết nối phải được thực hiện. Nếu điều này không thực hiện, nó là có thể các ứng dụng có thể xuất hiện để có hiệu suất chấp nhận được tại thấp số lượng người dùng, nhưng hiệu suất có thể làm suy giảm đáng kể số của người sử dụng quy mô trở lên.

Với đúng ứng dụng rồi truy vấn thiết kế, Microsoft SQL Server là khả năng hỗ trợ nhiều ngàn đồng thời người dùng trên một máy chủ duy nhất, với ít chặn.

Cảnh báo: Bài viết này được dịch tự động

Thuộc tính

ID Bài viết: 224453 - Xem lại Lần cuối: 09/01/2011 10:43:00 - Bản sửa đổi: 3.0

Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Standard, Microsoft SQL Server 2008 Workgroup, Microsoft SQL Server 2000 Developer Edition, Microsoft SQL Server 2000 Enterprise Edition, Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 7.0 Standard Edition, Microsoft SQL Server 2008 R2 Developer, Microsoft SQL Server 2008 R2 Enterprise, Microsoft SQL Server 2008 R2 Standard, Microsoft SQL Server 2008 R2 Workgroup

  • kbsqlsetup kbhowto kbtshoot kbexpertiseinter kbinfo kbmt KB224453 KbMtvi
Phản hồi