SQL Server bị rò rỉ giao dịch

9

Tôi có một cơ sở dữ liệu được khoảng 50 khách hàng truy cập thông qua TDS qua TCP mà dường như không giải phóng không gian nhật ký. Số lượng các quy trình nằm trong khoảng 50 dự kiến và một số trong số chúng tồn tại khá lâu (> 120 ngày).

Cơ sở dữ liệu hiện có 40 gb trong không gian nhật ký (nó chỉ có 14 gb dữ liệu), 39 gb miễn phí. Do giới hạn không gian trên ổ đĩa, tôi muốn thu nhỏ lại thành thứ gì đó hợp lý hơn (10gb-ish). Khi tôi thực thi DBCC SHRINKFILE('db_log', 10000), nó trả về một lỗi mà phần cuối của nhật ký đang được sử dụng.

Để truy cập miễn phí vào cuối nhật ký, tôi đã cố gắng đặt cơ sở dữ liệu ở chế độ người dùng duy nhất với các mục sau:

ALTER DATABASE db SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
ALTER DATABASE db SET MULTI_USER
GO

nhưng tập lệnh đang trả về thông báo sau được lặp lại hàng trăm lần:

Nonqualified transactions are being rolled back. Estimated rollback completion: 100%.

Điều đó khiến tôi tin rằng ở đâu đó, tôi sẽ để lại một số giao dịch không được cam kết. Tôi không biết về bất kỳ quy trình nào có thể cố tình mở nhiều giao dịch này cùng một lúc, vì vậy tôi nghĩ rằng chúng phải tích lũy theo thời gian, không bao giờ bị đóng.

Câu hỏi: Làm cách nào để xác định quy trình hoặc tập lệnh vi phạm hoặc tại sao nhật ký không được phát hành?

sys.dm_tran_active_transactionsđang hiển thị 18 giao dịch hợp lý với mục đích dễ hiểu. sp_whochỉ hiển thị các quá trình tôi nhận thức được.

Phiên bản máy chủ SQL:

Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) 
Apr  2 2010 15:48:46 
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

Phiên bản máy chủ:

Windows Server 2008 R2 x64 - Trung tâm dữ liệu 4 vCPUs, bộ nhớ 16GB, Truyền qua đĩa để lấy dữ liệu và nhật ký, đĩa hệ điều hành là VHD

trên Hyper-V (Trung tâm dữ liệu Windows Server 2008 R2 SP1 x64) Intel X5650 kép (6 lõi, 12 luồng ở tốc độ 2.67GHz) bộ nhớ 72 GB

Hypervisor chỉ có ba VM và không hiển thị sử dụng tài nguyên cao. SQL Server VM hiển thị ~ 40% CPU khi tải và 99% lần truy cập bộ đệm.

sql-server

— Mitch
nguồn

Tôi không phải là một dba sql nhưng bạn đã sao lưu log? serverfault.com/questions/54958/

@rene, Có, tôi nên đã đề cập đến điều đó, nhưng cơ sở dữ liệu có một bản sao lưu đầy đủ được thực hiện hàng ngày và sao lưu nhật ký cứ sau sáu giờ.

Xin chào Mitch, có lẽ không liên quan đến vấn đề này, nhưng sẽ không ngạc nhiên nếu điều này có trách nhiệm. Phiên bản của bạn là RTM (Phát hành để Sản xuất). Microsoft, giống như hầu hết các nhà cung cấp phần mềm khác sẽ đẩy mạnh phát hành bản phát hành lớn tiếp theo với một số lỗi nhỏ trong sản phẩm. [link] microsoft.com/en-us/doad/details.aspx?id=44271 Đây là liên kết đến Gói dịch vụ mới nhất cho SQL 2008 R2. Tốt nhất để giữ cho máy chủ của bạn cập nhật để bảo mật, sửa lỗi và lý do hiệu suất.

— Damagedoods

4

Có một lệnh SQL sẽ hiển thị các giao dịch MỞ. (DBCC OPENTRAN)

http://msdn.microsoft.com/en-us/l Library / ms182792.aspx

Hiển thị thông tin về giao dịch hoạt động lâu đời nhất và các giao dịch nhân rộng được phân phối và không phân phối lâu đời nhất, nếu có, trong cơ sở dữ liệu được chỉ định. Kết quả chỉ được hiển thị nếu có một giao dịch đang hoạt động hoặc nếu cơ sở dữ liệu chứa thông tin sao chép

— Richard Vivian
nguồn

4

Vì lý do nào, dường như không có gì giữ tệp nhật ký mở. Bằng cách chạy nhiều bản sao lưu nhật ký (> 10), phần cuối của nhật ký đã được giải phóng và việc thu hẹp có thể xảy ra. Không chắc tại sao ... nhưng nó đã hoạt động.

backup log db to disk = '\\l-backup1\drop\2012-12-23_db_log.bak' with stats = 1
go 15
dbcc shrinkfile('db_log', 10240)
go

— Mitch
nguồn

3

Nếu tôi hiểu chính xác câu hỏi của bạn, bạn có nhật ký giao dịch 40Gb với 39Gb miễn phí không? Nhật ký là một cấu trúc tròn, được tạo thành từ các tệp nhật ký ảo nhỏ hơn. Mỗi khi một VLF đầy, SQL bắt đầu sử dụng VLF tiếp theo. (Không nhất thiết phải theo thứ tự như các VLF có trong tệp). Khi bạn thu nhỏ tệp nhật ký, nó sẽ giải phóng không gian trống từ END của nhật ký. Nếu phần hoạt động của nhật ký ở cuối, không có khoảng trống nào có thể được giải phóng, nếu nó ở giữa ở đâu đó thì bạn chỉ có thể lấy lại một số khoảng trống. DBCC LOGINFO sẽ hiển thị cho bạn tất cả các VLF trong nhật ký và trạng thái hiển thị rằng VLF hiện có chứa bất kỳ nhật ký hoạt động nào. Tôi tin rằng trạng thái 2 đang hoạt động và 0 không hoạt động. Tôi chắc chắn google có thể cung cấp thêm thông tin nếu cần.

Nếu vấn đề của bạn chỉ là phần hoạt động hiện đang ở cuối thì đặt cược tốt nhất của bạn chỉ là đợi cho đến khi nó cuộn tròn để bắt đầu lại, sau đó thu nhỏ nhật ký. Điều này có thể mất một lượng thời gian đáng ngạc nhiên, hãy kiên nhẫn. Nó sẽ đến đó.
Cũng nên nhớ rằng nếu BẤT K part phần nào của VLF hiện đang hoạt động thì toàn bộ VLF sẽ được giữ hoạt động.

Tuy nhiên, bạn nên theo dõi kích thước của tệp nhật ký, nếu nó bất ngờ phát triển trở lại thì bạn sẽ cần thực hiện một số điều tra về nguyên nhân. Bạn nên tránh việc thu hẹp tệp nhật ký không cần thiết, khi phát triển lại, nó có thể làm chậm hiệu suất.

Thông tin thêm về các VLF có thể được tìm thấy trong bài đăng trên blog của Kimberly Tripps tại đây .

— pipTheGeek
nguồn

cảm ơn bạn đã ra DBCC LOGINFOlệnh, tôi đã không biết về điều đó. Điều đó đang được nói, tôi nhận thức được cấu trúc của nhật ký và không xem xét việc thu nhỏ tệp một cách không cần thiết. Như đã đề cập, chúng tôi chỉ thường xuyên sử dụng khoảng 1gb nhật ký trong cấu trúc sao lưu hiện tại của mình và tôi muốn lấy lại một số dung lượng trống. Vấn đề là không gian nhật ký ở cuối nhật ký không được phát hành ngay cả sau vài tuần chờ đợi. Trong thời gian đó, cơ sở dữ liệu đã có nhiều bản sao lưu đầy đủ và đăng nhập khiến tôi tin rằng một cái gì đó đang ngăn chặn vòng tròn tự nhiên.