SQL Server 2005 Sự cố DB lớn

Các tệp DB của tôi đang phát triển rất nhanh (nhà thiết kế không phải là tôi và chỉ cần một báo cáo hàng tuần làm tăng 7 GB). Và cuối cùng, tôi không có đủ dung lượng trong đĩa. Và số tuần không báo cáo đếm lên.

Tôi có một số tùy chọn để thực hiện nhưng cần đề xuất của bạn:

1. Thu hẹp cơ sở dữ liệu (thu hẹp có cung cấp không gian cho HĐH không?)

2. Tháo và đính kèm DB từ một ổ đĩa ngoài hoặc lưu trữ mạng. (Lưu trữ mạng có được SQL Server 2005 hỗ trợ không?)

3. Thay đổi cấu hình RAID từ 1 đến 5 để tăng gấp đôi kích thước đĩa. (đây là tùy chọn an toàn nhất nhưng cũng nguy hiểm khi thay đổi cấu hình RAID.)

Cảm ơn những câu trả lời tuyệt vời và hữu ích liên quan đến câu hỏi của tôi. Tôi đã kiểm tra tệp nhật ký và 99% dung lượng không được sử dụng. Vì vậy, tôi thu nhỏ nó. Vì DB chỉ được sử dụng khi chúng tôi cần một số báo cáo (theo yêu cầu đúng hạn, không phải lúc nào cũng cần truy cập vào db) Tôi nghĩ rằng hiệu suất sẽ không phải là vấn đề đối với tôi.

Thu hẹp cơ sở dữ liệu sẽ cho phép bạn trả lại một số không gian cho O / S, nhưng không gian đó có chi phí hiệu năng khi hoạt động thu nhỏ phân đoạn cơ sở dữ liệu. Bạn có thể khắc phục điều này bằng cách xây dựng lại các chỉ mục của mình, nhưng điều đó thường khiến không gian được thu hồi. Và các ý tưởng cho rằng thu nhỏ sẽ là một giải pháp là sai, bởi vì bạn không tự giải quyết vấn đề tăng trưởng, bạn chỉ đang cố gắng băng bó vết thương ở ngực.

Đặt các tệp của bạn trên các đĩa có thể mở rộng dễ dàng là cách tốt nhất của bạn. Bộ nhớ ngoài hoạt động tốt (hoặc SAN, nếu có thể). Bạn không thể sử dụng đường dẫn UNC cho các tệp cơ sở dữ liệu của mình, nhưng bạn có thể sử dụng DFS để gắn ổ đĩa và trỏ đến vị trí mạng và mọi thứ sẽ hoạt động tốt.

HTH

Nếu bạn có một kế hoạch sao lưu có liên quan, tệp nhật ký của bạn sẽ không tăng lên vô thời hạn. Bạn có thể sẽ thấy rằng không gian bên trong nó chủ yếu không được phân bổ - vì các khối trang trong nhật ký được sao lưu (tất nhiên tùy thuộc vào mô hình sao lưu / khôi phục của bạn, hãy đọc các tùy chọn đó nếu bạn không quen thuộc với chúng) miễn phí để được sử dụng lại sau nhưng không được phát hành cho hệ điều hành. Lần tới khi quy trình lớn của bạn chạy, gây ra nhiều lần chèn / cập nhật và do đó cần một vài Gb không gian nhật ký MSSQL sẽ không cần thêm dung lượng từ HĐH vì nó chỉ có thể sử dụng các khối đã được phân bổ cho tệp nhật ký nhưng hiện không giữ bất cứ điều gì không thể được viết qua.

Nếu bạn đang thấy GBytes tăng trưởng thêm trong các tệp nhật ký của mình mỗi khi tiến trình hàng tuần được chạy thì bạn cần kiểm tra gói sao lưu của mình vì điều đó có nghĩa là SQLServer không thấy các trang nhật ký có thể tái sử dụng vì chế độ sao lưu của bạn không đúng với dữ liệu và hoạt động (hoặc có thể đơn giản như bạn không thường xuyên sao lưu dự phòng).

Sự tăng trưởng trong các tệp dữ liệu là tương tự nhau: nếu có một lượng lớn không gian trống trong các tệp thì nó sẽ được sử dụng vào lần tới khi cần thêm dung lượng thay vì yêu cầu HĐH phân bổ thêm. Một điều cần chú ý nếu dữ liệu của bạn lớn bất ngờ là lập chỉ mục quá mức - bạn có thể thấy các bảng lớn có các chỉ mục không bao giờ thực sự được sử dụng (chúng hoàn toàn không cần thiết hoặc không mang lại nhiều lợi ích cho chỉ mục khác hiện tại). Các ví dụ kinh điển về điều này là tìm mọi cột trong một bảng rộng có chỉ mục riêng (thường không phải lúc nào cũng là dấu hiệu của thiết kế bảng / chỉ mục xấu) hoặc tìm chỉ mục cho " cột1 và cột2 " và một chỉ mục cho cột1theo cách riêng của nó: trình lập kế hoạch truy vấn và người chạy sẽ có thể sử dụng chỉ mục tổng hợp cũng như chỉ mục đơn giản cho các truy vấn dựa trên cột1, do đó không cần sử dụng khoảng trắng với chỉ mục phụ. Duy trì các chỉ mục không hữu ích cũng có tác động đến hiệu suất ghi. Cuốn sách này có một vài phần đề cập đến các vấn đề về chỉ mục phổ biến nếu bạn muốn xem xét vấn đề nhiều hơn và đáng để đọc cho tất cả các nhà phát triển và DBA dù sao IMO.

Thu hẹp các tệp không cần thiết có thể dẫn đến sự phân mảnh quá mức trong các tệp, điều này có thể gây hại cho hiệu suất, vì vậy hãy cẩn thận nếu bạn đi theo tuyến đường đó.

Về việc chuyển đổi từ RAID1 sang RAID5: Tôi không khuyến nghị điều đó. RAID5 thường gặp vấn đề về hiệu năng với công việc cơ sở dữ liệu nặng ghi (có khả năng làm chậm đáng kể các quy trình khổng lồ tạo ra các mục nhập dữ liệu và nhật ký giao dịch GB GB) do việc đọc thêm trước khi đọc bất kỳ ghi lại để cập nhật- vấn đề tổng kiểm tra. Thay vì thêm một ổ đĩa để chuyển từ R1 sang R5, tôi sẽ sử dụng thêm hai ổ đĩa và sử dụng R10 - vẫn tăng gấp đôi dung lượng nhưng không có vấn đề về hiệu suất ghi (tất nhiên là giả sử có máy chủ cho hai ổ đĩa phụ !). Dù bạn có làm gì trong khu vực đó, việc chuyển đổi từ sắp xếp RAID này sang sắp xếp RAID khác có thể liên quan đến thời gian ngừng hoạt động lớn khi bạn sao lưu dữ liệu, xây dựng lại mảng, và sao chép lại dữ liệu (trừ khi bạn mua một bộ ổ đĩa hoàn toàn mới và có thể có cả mảng mới và mảng cũ chạy cùng một lúc, điều này sẽ làm giảm thời gian chết khá nhiều). Một tùy chọn khác là thêm hai ổ đĩa dưới dạng mảng RAID1 mới và sau đó sử dụng âm lượng động của Windows để trải rộng trên hai mảng này (cung cấp cho bạn kích thước của RAID10, nhưng không có một số mức tăng hiệu suất có thể lượm lặt được từ việc lột đồ). HOẶC bạn có thể giữ hai mảng riêng biệt và giữ các tệp dữ liệu trên một và các nhật ký giao dịch ở bên kia - giữ dữ liệu và nhật ký trên các trục riêng biệt theo cách này có thể cải thiện đáng kể hiệu suất của hoạt động ghi bằng cách giảm chuyển động đầu cần thiết để cập nhật cả nhật ký và tệp dữ liệu. Tùy chọn cuối cùng này cũng có thời gian ngừng hoạt động tối thiểu vì một khi ổ còn lại có thể được thực hiện "trực tiếp":

Cần phải xem những gì bảng đang phát triển rất nhanh.

Bạn có thể gặp sự cố tương tự như tôi đã gặp trong quá khứ, ngay cả khi dữ liệu bảng đã bị xóa, không gian được giải phóng bởi bảng, do đó bảng đã sử dụng / báo cáo nhiều GB, nhưng chỉ có 100.000 hàng (giải pháp của chúng tôi là xây dựng lại bảng).

Nếu không có vấn đề về dữ liệu ẩn, thì bạn có thể tạo nhóm tệp mới trên một ổ đĩa khác (Storage..etc) và tạo tệp dữ liệu ở đó. Sau đó, giải pháp sẽ là tạo lại các bảng lớn và các chỉ mục của chúng trên nhóm tệp mới này.

Quan trọng nhất bây giờ là hiểu những gì / tại sao các bảng phát triển. Bạn cũng có thể thấy câu hỏi này: Có cách nào để xác định khi nào bạn nên chạy DBCC CLEANTABLE để lấy lại không gian không? cho một số thông tin liên quan đến các vấn đề không gian.

Tôi đề nghị bạn xử lý vấn đề từ một góc độ khác như đã được SQLRockstar nói ở đây . Bạn chỉ muốn khắc phục vấn đề và không tìm ra nguyên nhân của vấn đề đó là một sự chấp nhận sai vì nguyên nhân sẽ xuất hiện lại và gây ra cho bạn những rắc rối tương tự.

Những điều cần kiểm tra / làm:

1. Là cơ sở dữ liệu trong mô hình phục hồi đầy đủ? Nếu bạn đang sử dụng DB chỉ để Báo cáo thì có lẽ bạn nên kiểm duyệt thay đổi mô hình khôi phục thành Đơn giản. Trong mô hình này, SQL Server chỉ duy trì một lượng thông tin tối thiểu trong nhật ký giao dịch. SQL Server cắt ngắn nhật ký giao dịch mỗi khi cơ sở dữ liệu đạt đến điểm kiểm tra giao dịch. Cắt ngắn không bằng Shrink. Sau khi cắt bớt, tệp nhật ký sẽ có kích thước tương tự nhưng không gian bên trong sẽ được giải phóng để phát triển tiếp theo. Và tốt hơn là để nguyên như thế này, bởi vì một tệp nhật ký phát triển bổ sung sẽ gây thêm áp lực vào các đĩa mỗi khi nó cần để phát triển tệp nhật ký.

2. Nếu tệp Dữ liệu cũng đang phát triển, bạn nên xác định đối tượng nào là lớn nhất bên trong nó và nếu những đối tượng này có thể được giảm trong không gian. Nếu bạn không thiết kế nó, có thể có các chỉ mục không được sử dụng mà bạn không biết rằng có kích thước lớn?

Dưới đây là một số MÃ HỮU ÍCH để tìm hiểu điều này: Kích thước bảng và chỉ mục

Điều đầu tiên bạn cần kiểm tra là có bao nhiêu dung lượng trống trong dữ liệu và tệp nhật ký.

SELECT name AS 'FileName' , physical_name AS 'PhysicalName', size/128 AS 'TotalSizeinMB',
    size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS 'AvailableSpaceInMB', 
    CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS 'ActualSpaceUsedInMB', 
    (CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0)/(size/128)*100. as '%SpaceUsed'
    FROM sys.database_files;

Chỉ cần cố gắng thu nhỏ sẽ không giúp đỡ nếu không có không gian trống trong các tệp. Cũng xem các cài đặt tăng trưởng tự động trên các tệp dữ liệu + nhật ký. Có một số lỗi + người vô tình thiết lập một sự tăng trưởng tự động lớn và đôi khi đó là quá nhiều.

Nói chung trong các trường hợp như của bạn, tôi sẽ không khuyên bạn nên CHIA SẺ và thêm nhiều không gian hơn là cách phù hợp.

tệp dữ liệu khoảng 90 GB. tệp nhật ký khoảng 20 GB. - Olgun Kaya 19 giờ trước

Tôi thứ hai sankar.

Đừng thu hẹp cơ sở dữ liệu, nó sẽ phát triển lặp đi lặp lại và gây ra sự phân mảnh.

so sánh tệp dữ liệu 90 gb với tệp nhật ký 20 gb là quá lớn. Tại sao tệp nhật ký đã đi 20 gb kiểm tra các mô hình khôi phục và kế hoạch sao lưu.