Có khôi phục cơ sở dữ liệu SQL từ bản sao lưu để xây dựng lại các chỉ mục của nó không?

10

Việc khôi phục cơ sở dữ liệu SQL từ bản sao lưu có xây dựng lại các bảng và chỉ mục của nó từ đầu không? Hoặc nó giữ nó theo thứ tự vật lý nội bộ giống như lúc nó được sao lưu?

Chúng tôi đang sử dụng SQL 2000 với bản sao lưu nén Quest Lightspeed, nếu điều đó tạo ra sự khác biệt.

sql-server restore

— BradC
nguồn

16

Câu trả lời là không, đối với bất kỳ phần mềm sao lưu nào đang được sử dụng.

Một bản sao lưu là một hoạt động vật lý, không phải là một hoạt động hợp lý. Nó đọc tất cả các phạm vi có chứa các trang được phân bổ (nghĩa là mặc dù chỉ một trang duy nhất trong phạm vi 8 trang được phân bổ, nó sẽ sao lưu toàn bộ phạm vi 64K) và thực hiện theo thứ tự vật lý.

Khôi phục là một hoạt động vật lý, không phải là một hoạt động hợp lý. Nó đặt các phạm vi ở vị trí hợp pháp của chúng trong các tệp dữ liệu.

Xây dựng lại một chỉ mục (hoặc bất cứ thứ gì giống như vậy) là một hoạt động hợp lý, phải được ghi lại. Sao lưu và khôi phục thao tác trực tiếp các tệp dữ liệu mà không cần thông qua nhóm bộ đệm, đó là một lý do tại sao điều này không thể được thực hiện. Một lý do khác không thể thực hiện được là sao lưu và khôi phục không hiểu gì về những gì có trong dữ liệu được sao lưu.

Tuy nhiên, lý do chính điều này không thể được thực hiện là do các trang di chuyển xung quanh trong quá trình khôi phục sẽ phá vỡ các con trỏ của cây b. Nếu trang A trỏ đến trang B, nhưng trang A được di chuyển theo quy trình khôi phục, trang B được cập nhật như thế nào để trỏ đến trang A? Nếu nó được cập nhật ngay lập tức, thì nó có thể bị ghi đè bởi phần còn lại của quá trình khôi phục. Nếu nó bị hoãn cập nhật, điều gì xảy ra nếu quá trình khôi phục khôi phục một số nhật ký giao dịch đã xóa trang A hoặc trang B? Nó chỉ đơn giản là không thể được thực hiện.

Dòng dưới cùng - sao lưu và khôi phục là các hoạt động vật lý không bao giờ thay đổi dữ liệu.

Hi vọng điêu nay co ich!

PS Mặc dù nó không trực tiếp giải quyết câu hỏi này, hãy xem bài viết tôi đã viết cho Tạp chí TechNet tháng 7, giải thích cách thức các bản sao lưu khác nhau hoạt động trong nội bộ: Hiểu về Sao lưu SQL Server . Tạp chí tháng 9 sẽ có phần tiếp theo trong loạt bài về sự hiểu biết khôi phục.

— Paul Randal
nguồn

2

Tôi thích thực tế rằng bạn đã giải thích rằng lập chỉ mục là một hoạt động hợp lý.

— Jim B

Ah, điều đó có ý nghĩa. Sao lưu lấy đầy đủ 64k mức độ vật lý, không phải 8k trang dữ liệu.

— BradC

Thật vô nghĩa. Các hoạt động sao lưu thường nén dữ liệu mà chúng sao lưu và đó là loại "thay đổi" mà chúng ta đang nói đến: Sau tất cả, các chỉ mục có thể được tạo lại từ các bảng, chúng là dữ liệu dư thừa (với điều kiện là lược đồ được sao lưu , tất nhiên). Lý do thực sự là sự lười biếng từ phía các nhà phát triển cơ sở dữ liệu.

— John

1

@ John Bạn đang nói gì là vô nghĩa? Nén không được đề cập ở bất cứ đâu tại đây - chỉ xây dựng lại các chỉ mục, không giống như nén (không thay đổi các trang hoặc vị trí của chúng trong cơ sở dữ liệu trong quá trình khôi phục, trong khi quá trình xây dựng lại). Việc tạo lại các chỉ mục từ đầu trong quá trình khôi phục sẽ cực kỳ chậm so với việc chỉ khôi phục chúng như là từ bản sao lưu. Tôi nghĩ rằng bạn đang hiểu nhầm một cái gì đó ở đây.

— Paul Randal

Thả và xây dựng lại các chỉ mục là một loại nén và nén có thể thay đổi bất cứ điều gì, tùy thuộc vào loại nén. Nén tổn thất trong xử lý ảnh vẫn được gọi là nén. Bất kỳ cơ chế nào thể hiện thông tin đã cho trong không gian nhỏ hơn là một hình thức nén và bỏ chỉ mục là một ví dụ nhỏ về điều đó. Thời gian xây dựng lại chậm có thể thực sự là một cuộc tranh luận thực sự, ít nhất là chống lại việc thực hiện là một nỗ lực đáng giá.

— John

6

Một bản sao lưu SQL gốc chỉ là một bãi chứa từng trang của các tệp sao lưu, vì vậy câu trả lời là "không". Một bản sao lưu Quest lightpeed có thể sử dụng một số loại thuật toán nén nén, nhưng nó vẫn không "xây dựng lại" các tệp dữ liệu hoặc chỉ mục, sẽ tốn một lượng thời gian lớn trên cơ sở dữ liệu lớn.

— Aaron Alton
nguồn

Vâng, nhưng dù sao nó cũng phải ghi mọi trang vào đĩa. Tại sao không viết chúng theo trình tự hợp lý, thay vì theo thứ tự phân mảnh? (Có lẽ đây là câu hỏi dự phòng thay vì câu hỏi khôi phục : bản sao lưu có viết các trang theo thứ tự vật lý hay theo thứ tự logic không?)

— BradC

giả sử có một sản phẩm ghi dữ liệu theo thứ tự chỉ mục, bạn muốn bảng được lưu theo thứ tự nào? Hãy nói rằng tôi có một bảng có 3 cột sản phẩm, tên sản phẩm và giá cả. Cột nào đúng để sắp xếp để lưu các trang theo thứ tự được lập chỉ mục? BTW không có gì ngăn bạn lập chỉ mục trên toàn bộ bảng (một chỉ mục được nhóm) hoặc mỗi hàng (chỉ mục tổng hợp).

— Jim B

@Jim B: Điều đó thật dễ dàng. Các bảng sẽ được lưu theo thứ tự chỉ mục cụm. Các chỉ mục không được nhóm sẽ được lưu trữ theo thứ tự chính. Heaps sẽ được giữ theo thứ tự gốc (không được sắp xếp). (Aaron và Paul đã đề cập đến những lý do hợp lệ rằng sao lưu / khôi phục không thực hiện được điều này. Không thể tìm ra "thứ tự ưu tiên" không phải là một trong những lý do này. )

— BradC

Dữ liệu được sao lưu theo thứ tự chính xác của trang vật lý mà nó được lưu trong các tệp cơ sở dữ liệu. Khi dữ liệu được khôi phục, nó được khôi phục theo cùng thứ tự trang đã được sao lưu. SQL không di chuyển dữ liệu vì nhiều lý do. Bao gồm có thể có các vấn đề với các giao dịch khôi phục nhật ký và các vấn đề xâu chuỗi trang, chưa kể đến số lượng lớn thời gian thêm cần thiết để xáo trộn dữ liệu xung quanh trên cơ sở dữ liệu nhiều TB.

— mrdenny

2

Sao lưu được thực hiện thường xuyên và rất thường xuyên (tôi hy vọng). Vì vậy, các nhà thiết kế đã đảm bảo sao lưu nhanh nhất có thể. I / O nhanh nhất là gì? Tuần tự. Bạn đọc các khối từ đĩa theo thứ tự vật lý chính xác, bạn có hiệu suất tốt nhất.

Tại sao trên cơ sở dữ liệu nên thực hiện thao tác I / O ngẫu nhiên cồng kềnh mỗi đêm , làm hỏng các đầu của đĩa ở khắp mọi nơi? Sự khác biệt sẽ là khoảng hai bậc độ lớn. Không có khả năng đạt được trong việc này.

— kubanchot
nguồn

Tôi đồng ý với quan điểm chung của bạn, nhưng tùy thuộc vào cấu hình lưu trữ cơ bản, I / O ngẫu nhiên có thể không phải là các đơn đặt hàng có cường độ kém hơn so với I / O tuần tự (ví dụ, một ổ SAN được trải rộng trên hàng chục trục chính). Trong thực tế, nếu tệp dữ liệu bị phân mảnh trên ổ cứng, thì ngay cả I / O "tuần tự" cũng không thực sự tuần tự. Nhưng dù sao điểm của Paul vẫn ghi đè lên điều này (vấn đề với việc cập nhật con trỏ và phân mảnh đó phải là thao tác được ghi lại)

— BradC

0

Hừm. BradC, bạn đã từng làm việc với Firebird / Interbase trước đây - nơi tiện ích sao lưu / khôi phục / API chính giống với "Sao chép cơ sở dữ liệu ..." của SSMS / EM? Nếu vậy, hãy biết rằng MS SQL Server KHÔNG thích nó.

SQLServer Backup là một bãi chứa cơ sở dữ liệu được khôi phục "AS-IS" - vì vậy nó giống như một lối tắt trực tuyến dễ hiểu hơn cho hoạt động "tách bản sao-reattach ở nơi khác". Cơ sở dữ liệu được khôi phục gần như là một bản sao chính xác của tệp cơ sở dữ liệu gốc (gần như vì bạn có thể thay đổi vị trí của các tệp cơ sở dữ liệu của cơ sở dữ liệu được khôi phục) ...

— Fabricio Araujo
nguồn