Tempp.ldf của tôi rất lớn (45gb), nếu tôi phải làm gì thì sao?

Tôi đã cài đặt SQL 2005 và tệp templog.ldf của tôi tiếp tục phát triển để tiêu thụ hết dung lượng trống trên ổ đĩa. Đôi khi nó sẽ dừng lại với một vài mb miễn phí nhưng đôi khi nó đi xa hơn, đây là ổ đĩa c tôi nghĩ rằng hành vi này có thể liên quan đến một số vấn đề khác mà tôi đã gặp.

Câu hỏi của tôi là, tôi nên làm gì, tôi có thể chuyển nhật ký sang ổ đĩa khác nhưng tôi có lý do để cho rằng nó sẽ không làm điều tương tự ở đó. Tôi giả định rằng hành vi này có thể là kết quả của một thứ gì đó tôi có thể thay đổi và 45gb là kích thước bất thường để nhật ký tempdb có được. Chúng tôi sử dụng rất nhiều bảng tạm thời và các hàm có giá trị bảng trong mã của chúng tôi để có nhiều phạm vi sử dụng tempdb, tôi có thể hiểu cơ sở dữ liệu tempdb đang phát triển nhưng không hiểu lý do cho sự tăng trưởng của templog.

Cho đến nay, tôi đã chạy DBCC OPENTRAN ('tempdb') để xem liệu có bất kỳ giao dịch cũ nào được treo xung quanh không, chúng không. Tôi đã đọc về cách thu nhỏ tempdb và đã thực hiện điều này một vài lần, nhưng tôi thực sự tự hỏi liệu tôi có thể làm gì để ngăn chặn điều này xảy ra ở nơi đầu tiên hoặc biết thêm chi tiết về lý do tại sao nó có thể phát triển quá nhiều trong nơi đầu tiên

== EDITS ==

1) tempdb đang sử dụng mô hình khôi phục đơn giản

2) Sự tăng trưởng của templog xảy ra trong một vài giờ vào buổi sáng khi chúng tôi có một số truy vấn theo lịch trình đang chạy, về cơ bản là một báo cáo hết giờ làm việc cho ngày hôm trước. Kích thước của tập tin tăng trưởng đều đặn trong thời gian này. Chúng tôi kiểm soát có bao nhiêu báo cáo đồng thời đang chạy cùng một lúc, tăng số lượng báo cáo đồng thời làm tăng tốc độ tăng nhật ký.

Kiểm tra các truy vấn báo cáo của bạn. Bạn có cái nào có DISTINCT trong chúng không? Có ai trong số họ có một tham gia cartesian?

Có bất kỳ truy vấn báo cáo truy cập các máy chủ được liên kết như là thành viên của một tham gia? Nếu vậy điều này có thể làm cho nhật ký và cơ sở dữ liệu tempdb phát triển.

Khi các báo cáo đang chạy vào buổi sáng, có ai trong số họ bị sập không?

Chúng tôi đã có một vấn đề tương tự, sau khi đã đưa ra cuộc gọi PSS với Microsoft và điều tra sâu về vấn đề chúng tôi đã khoanh vùng vào nguyên nhân và giải quyết có thể sau đây.

Nguyên nhân:

Nguyên nhân có thể xảy ra cho các triệu chứng là do đĩa / lun mà cơ sở dữ liệu người dùng được đặt có vấn đề phản hồi I / O nghiêm trọng; điều này khiến cho điểm kiểm tra tự động trên cơ sở dữ liệu người dùng mất rất nhiều thời gian để hoàn thành.

Bây giờ, điểm kiểm tra trên tempdb chỉ xảy ra khi nhật ký tempdb đã đầy 70% và nó cũng có mức độ ưu tiên thấp hơn điểm kiểm tra cơ sở dữ liệu người dùng. Vì vậy, hiệu quả khi điểm kiểm tra tự động trên cơ sở dữ liệu người dùng được phát hành và đang cố gắng hoàn thành, do việc sử dụng tempdb nặng nề khiến tệp nhật ký tempdb bị đầy nhanh chóng; ở mức sử dụng nhật ký 70%, điểm kiểm tra tempdb xảy ra nhưng được xếp hàng phía sau điểm kiểm tra cơ sở dữ liệu người dùng.

Trong thời gian cần thiết để điểm kiểm tra cơ sở dữ liệu người dùng hoàn thành tệp nhật ký tempdb tiếp tục được lấp đầy và nếu autogrow được đặt, tệp nhật ký sẽ phát triển khi cần thêm dung lượng. Đây là lý do các tập tin nhật ký tiếp tục phát triển.

Tóm lại, nguyên nhân gốc có thể nhất cho các triệu chứng bạn mô tả là do phản hồi I / O kém từ các đĩa / lun dành cho người dùng và / hoặc tệp nhật ký / cơ sở dữ liệu tempdb của bạn.

Giải pháp:

Chúng tôi đã khắc phục sự cố trong khi chúng tôi sắp xếp hệ thống con I / O bằng cách thiết lập cảnh báo phát ra khi tệp nhật ký tempdb đầy đủ 75% và trong phản hồi đã thực thi một công việc buộc "CHECKPOINT" thủ công (được ưu tiên hơn hệ thống tự động điểm kiểm tra), xóa nhật ký tempdb ngăn không cho nó tự động phát triển vô thời hạn. Nó vẫn là một ý tưởng tốt để rời khỏi tệp nhật ký tự động phát triển cho bất kỳ tình huống khác. Ngoài ra, tôi thực sự khuyên bạn nên xem xét giảm kích thước tệp nhật ký tempdb thành một cái gì đó có ý nghĩa theo môi trường của bạn sau khi bạn sửa lỗi.

Hi vọng điêu nay co ich.

Mô hình khôi phục được đặt thành gì trên db temp? Nếu nó không được đặt thành Đơn giản, thì hãy đặt thành Đơn giản. Điều này sẽ giữ cho nó phát triển. Nếu nó đã được đặt thành Đơn giản thì tôi sẽ nói rằng có một vấn đề tiềm ẩn cần được giải quyết và mọi nỗ lực thu nhỏ tệp chỉ đơn thuần là xử lý các triệu chứng của vấn đề chứ không phải nguyên nhân gốc rễ.

Tôi đã dành vài giờ qua để đọc và ghi chú về điều này

http://technet.microsoft.com/en-gb/l Library / cc966545.aspx

Có rất nhiều chi tiết trong đó và đề xuất cho các vấn đề chụp rắc rối. Có vẻ như trừ khi tempdb của bạn đang mở rộng và không bao giờ ngừng phát triển, có lẽ nó chỉ chiếm dung lượng mà nó cần và nên được định cấu hình để có kích thước đó ban đầu. Có một phần về ước tính không gian cần thiết cho tempdb của bạn cũng như theo dõi những gì có thể chiếm không gian trong tempdb. Do đó, điều đầu tiên tôi sẽ làm là chuyển tempdb sang một ổ đĩa lớn hơn và xem điều gì sẽ xảy ra từ đó.

Có một phần có tiêu đề 'Không gian cần thiết để ghi nhật ký tempdb' cho biết các tính năng nào sử dụng nhật ký, có một phần trước đó có chi tiết thay thế các tính năng sử dụng tempdb.

Phần có tiêu đề 'Giám sát I / O' có một vài ý tưởng về bộ đếm hiệu suất để xem, hãy xem nhanh máy chủ của tôi đặt những thứ này trong lãnh thổ mà bạn có lẽ đã mắc phải. Tôi sẽ theo dõi những thứ này một lúc và xem mọi thứ như thế nào. Tệp nhật ký tempdb cũng thực sự sử dụng ít hơn 50%, phù hợp với ý tưởng mà nó đã mở rộng khi tải sáng nay và đã giữ lại không gian đó kể từ đó.

Tôi sẽ đi trước trên cơ sở rằng kích thước mà nó phát triển là kích thước cần thiết, theo dõi kích thước này trong tương lai và đảm bảo có chỗ cho sự tăng trưởng trên bất kỳ ổ đĩa nào. Theo đề xuất của một số người ở đây, tôi sẽ xem xét những gì đang thực thi khi nhật ký tạm thời mở rộng và xem liệu có bất cứ điều gì có thể được điều chỉnh trong đó không. Tôi cũng sẽ theo dõi các quầy hiệu suất io đó để xem có gì cần xử lý không.

Có thêm một phần thú vị nữa có tiêu đề 'Nâng cấp lên SQL Server 2005' chỉ ra rằng tempdb được sử dụng cho nhiều thứ hơn trong năm 2005 hơn 2000 (cả các tính năng mới và các tính năng hiện có trước đây không sử dụng tempdb). Tôi mới chỉ nâng cấp lên năm 2005 nên đây có thể là một phần lý do khiến điều này đột nhiên trở thành một vấn đề. Tôi không nhớ đã thấy điều này ở bất cứ nơi nào khác có liên quan đến việc nâng cấp lên năm 2005, điều này hơi khó khăn.

Điều này rất có thể gây ra bởi một truy vấn Cross Join ngoài tầm kiểm soát. Đặt cược tốt nhất của bạn là sử dụng Profiler để tìm nó và sau đó sửa nó.

Một cách khác để tìm thấy nó là hạn chế kích thước của tệp nhật ký TempDB và sau đó chờ xem truy vấn nào không thành công. Tuy nhiên, tôi cá rằng nó đã thất bại và không ai nói với bạn.

Nếu bạn khởi động lại công cụ SQL, tệp sẽ được đặt thành kích thước ban đầu. Bạn nên đặt kích thước tối đa cho tất cả các tệp autogrow của mình.

Một số truy vấn SQL hoặc Proc được lưu trữ đang làm điều xấu - điều duy nhất bạn có thể làm là cấu hình tempdb để bắt sự kiện "Cơ sở dữ liệu: Nhật ký tệp tự động phát triển" và khi điều đó xảy ra, hãy sử dụng trình lược tả và truy vấn đối với các bảng như sys Processes để tìm quá trình xấu là gì

Thật không may, đó là công việc thám tử lỗi thời để theo dõi quá trình lừa đảo.

Bạn đã thử thay đổi kích thước (các) tệp nhật ký tempdb bằng DBCC SHRINKFILE () chưa? Nếu vậy, mất bao lâu để có được từ [giá trị rất nhỏ] đến 45 GB trở lên?