Máy chủ SQL thay đổi bảng để thay đổi văn bản thành NVARCHAR (MAX) làm tăng đáng kể kích thước cơ sở dữ liệu


8

Tôi cần cập nhật cơ sở dữ liệu SQL Server có kích thước khoảng 18 GB để thay đổi số lượng TEXTcột đáng kể NVARCHAR(MAX).

Vấn đề tôi gặp phải là sau khi thực hiện tất cả các alter tablelệnh mà cơ sở dữ liệu kết thúc có kích thước gần 26GB. Tôi hiểu rằng từ đây sử dụng NVARCHAR(MAX)sẽ giúp DB phát triển chậm hơn nhưng có cách nào để tôi ngăn chặn tình trạng đầy hơi này không?


2
Ồ, đừng tạo ra cùng một câu hỏi ở đây. Chỉ cần gắn cờ nó trên SO và các mod sẽ di chuyển nó đến đây ngay lập tức :-). Bây giờ ai đó cần hợp nhất / làm sạch..v.v.
Mary

2
Là cơ sở dữ liệu lớn hơn hoặc là nhật ký rất lớn?
Aaron Bertrand

Xin lỗi, hãy hiểu ngay bây giờ ...
Aidan Lawless

Aaron, tập tin MDF lớn hơn nhiều .... lớn hơn gần 10GB
Aidan Lawless

Câu trả lời:


7

Tôi hy vọng bài viết này sẽ giúp ích cho bạn.

http://geekswithbloss.net/johnsPerfBlog/archive/2008/04/16/ntext-vs-nvarcharmax-in-sql-2005.aspx

Sự kiện chính:

  • Theo mặc định, TEXT và NTEXT lưu giá trị văn bản trong cấu trúc LOB
  • Theo mặc định, NVARCHAR (MAX) lưu trữ giá trị văn bản trong cấu trúc bảng (Trừ khi nó lớn hơn 8000 byte)
  • Khi bạn thay đổi cột từ TEXT / NTEXT thành NVARCHAR (MAX), cách lưu trữ dữ liệu không bị thay đổi, nó chỉ cập nhật siêu dữ liệu của bảng. Cấu trúc dữ liệu chỉ được thay đổi trong lần tiếp theo giá trị được thay đổi. Điều này có thể được thực hiện ngay lập tức bằng cách chạy một cái gì đó như thế này:

      update mytable set mycolumn1 = mycolumn1
  • Nếu bạn sử dụng cài đặt tùy chọn bảng mặc định cho NVARCHAR (MAX), thì dữ liệu trong bảng của bạn sẽ lớn hơn.

    - Bạn sẽ cần xem xét các cài đặt và môi trường tùy chọn bảng của mình trước khi thay đổi cài đặt thành phù hợp với nhu cầu của bạn.

  • Kích thước bảng của bạn cuối cùng sẽ co lại, nếu bạn làm theo câu lệnh bảng thay đổi của bạn với câu lệnh bảng cập nhật.

Nói tóm lại, nếu bạn chạy câu lệnh cập nhật, buộc thay đổi lưu trữ cấu trúc dữ liệu, kích thước cơ sở dữ liệu của bạn sẽ nhỏ hơn, như mong đợi.

EDIT : Như bạn đã đề cập đến văn bản và không phải là TIẾP THEO, lợi ích của bạn trong không gian sẽ ít rõ ràng hơn bạn nghĩ. NTEXT chiếm gấp đôi dung lượng như những gì TEXT làm, nhưng đồng thời, bạn nên mong đợi NVARCHAR (MAX) sẽ chiếm khoảng một nửa không gian như những gì NTEXT làm. Theo tính toán của tôi, bạn sẽ thấy ít thay đổi so với kích thước cơ sở dữ liệu ban đầu của bạn.


Tín dụng đặc biệt cho http://www.douglubey.com/


2
bạn có thể tổng hợp ở đây các sự kiện quan trọng, trong trường hợp liên kết có thể trở nên chết.
Stephane Rolland

Như đã đề cập trong các câu trả lời khác, văn bản so với NTEXT sẽ có tác động đến việc lưu trữ, nhưng không nhiều như bạn đã đề xuất.
RoKa

Cảm ơn ... Tôi đã ngừng tham gia nhiều năm nay ... Rất vui khi được ở đây.
RoKa

Cảm ơn RoKA, điều đó đã tạo ra một sự khác biệt đáng kể cho một vài bảng trong câu hỏi. Tôi sẽ khôi phục lại cơ sở dữ liệu một lần nữa và thực hiện tăng dần để thấy ảnh hưởng. Cảm ơn một lần nữa .....
Aidan Lawless

Đó là niềm vui của tôi.
RoKa

6

Có thể là một sự giám sát trong câu hỏi của bạn, nhưng bạn đang nói VĂN với NVARCHAR (tối đa) chứ không phải NTEXT với NVARCHAR (tối đa). Nếu đây là những gì bạn thực sự đang làm, bạn đang thay đổi từ ANSI sang UNICODE và bạn không nên ngạc nhiên khi nó tốn nhiều không gian hơn (các ký tự byte đơn so với các ký tự nhiều byte).


Vâng, đó là những gì tôi đang làm ... mặc dù dựa trên một số tính toán đơn giản, nó sẽ không tính đến quy mô của sự gia tăng.
Aidan Lawless

2
Bạn đã thử với đề nghị của RoKa chưa?
spaghettidba

1
@AidanLawless những tính toán này là gì? Kích thước của cơ sở dữ liệu nên tăng ít nhất bằng kích thước của trường hiện tại TEXT- việc chuyển sang unicode chiếm chính xác gấp đôi không gian lưu trữ của ANSI.
JNK

2
@JNK ... trừ khi sử dụng nén trong 2008 R2 hoặc tốt hơn, trong đó nén Unicode sẽ xử lý các ký tự ASCII được lưu trữ trong NVARCHAR như VARCHAR.
Aaron Bertrand
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.