Giới thiệu về khôi phục cơ sở dữ liệu DB2 9 Các kịch bản phục hồi Amol D. Barsagade, Cố vấn Cơ sở dữ liệu, IBM Tóm tắt: Một chiến lược cố gắng và kiểm thử sao lưu và phục hồi là thiết yếu trong việc ngăn ngừa mất dữ liệu. Một cơ sở dữ liệu có thể gặp bất kỳ vấn đề nào, gồm bị ngắt nguồn điện đột xuất, hỏng hóc về phương tiện lưu trữ, và các sự cố của ứng dụng. Mỗi việc này có thể gây ra một sự cố về cơ sở dữ liệu và mỗi sự cố đòi hỏi một hành động phục hồi khác nhau. Hướng dẫn này giới thiệu các khả năng sao lưu và phục hồi trong IBM® DB2® for Linux®, UNIX® và Windows®. Ngoài ra, nó còn trình bày một cách tiếp cận từng bước, chỉ ra cách phục hồi dữ liệu ở các kịch bản sự cố khác nhau. Trước khi bạn bắt đầu Về hướng dẫn này Các tổ chức hỗ trợ toàn cầu dựa trên dịch vụ và sự hài lòng của khách hàng. Như vậy, việc bảo vệ trước các sự cố là một thách thức lớn đối với người quản trị cơ sở dữ liệu. Trong các môi trường làm việc 24/24 giờ, 7 ngày 1 tuần hoặc môi trường sản xuất, nơi các cơ sở dữ liệu có sứ mệnh thiết yếu, bất kỳ mất mát dữ liệu nào cũng đều là không thể chấp nhận. Do đó, vấn đề sống còn là phải hiểu được các tuỳ chọn phục hồi dữ liệu khác nhau do một hệ quản trị cơ sở dữ liệu đưa ra (DBMS) cũng như phải có một kế hoạch phục hồi dữ liệu ngay để thực hiện chúng. Mục tiêu Hướng dẫn này đưa ra các tuỳ chọn phục hồi DB2 9 đa dạng và gồm các chủ đề sau:  Ghi log cơ sở dữ liệu.  Cách thay đổi hình thức ghi log cơ sở dữ liệu.  Các thực hành tốt nhất để giữ an toàn cơ sở dữ liệu dữ liệu.  Cách phục hồi toàn bộ cơ sở dữ liệu sau một sự cố.  Cách phục hồi khi một vùng chứa không gian bảng bị mất hoặc hỏng.  Cách phục hồi một bảng mà bị lấy mất do ngẫu nhiên.  Cách phục hồi đến một thời điểm. Ghi log Cơ sở dữ liệu Các cơ sở dữ liệu DB2 hỗ trợ hai hình thức ghi log cơ sở dữ liệu khác nhau: Circular (Quay vòng) và Archival (Lưu trữ). Khi một cơ sở dữ liệu mới được tạo ra, kiểu ghi log quay vòng là mặc định. Nếu việc nhu cầu kinh doanh đòi hỏi cao hơn, bạn có thể thay đổi hình thức ghi log từ vòng tròn sang lưu trữ. Tóm tắt về log giao dịch trong DB2 Một giao dịch là một đơn vị logic của công việc. Mỗi giao dịch có các bản ghi log tương ứng được lưu lại trong tệp log giao dịch. Mỗi giao dịch có một mục tương ứng trong cái được gọi là Redo Log (Log Làm lại). Các mục Log Làm lại được viết cho tệp log hoạt động hiện tại. Khi tệp log hoạt động đã đầy, nó được đánh dấu là không sẵn có, để dùng nữa, vào lúc đó DB2 tạo ra tệp log tiếp theo, theo thứ tự tệp log hoạt động và tiếp tục viết các mục ghi log vào nó. Quy trình xử lý vòng tròn được lặp lại khi tệp log hoạt động hiện tại đã đầy. Khi các giao dịch hoàn tất (một lệnh COMMIT hoặc ROLLBACK được chạy), các mục đăng nhập tương ứng được giải phóng, do chúng không còn cần phục hồi cơ sở dữ liệu. DB2 luôn cố gắng ghi các mục log vào bộ các tệp log sơ cấp, nghĩa là, các tệp log mà tự động được phân bổ vào lúc kích hoạt cơ sở dữ liệu. Nếu có một tình trạng phát sinh khi một giao dịch đã sử dụng hết tất cả các tệp log sơ cấp (tất cả các tệp log sơ cấp được đánh dấu là chưa sẵn sàng), sau đó bộ quản trị cơ sở dữ liệu phân bổ một tệp log phụ. Ngay sau khi tệp đã đầy, bộ quản trị cơ sở dữ liệu kiểm tra tệp log sơ cấp lần nữa để xem có đúng tình trạng của chúng là chưa sẵn sàng hay không. Nếu đúng như vậy, một tệp log phụ khác được phân bổ và các lối vào được ghi vào đó. Quy trình này tiếp tục cho đến khi tất cả các tệp log thứ cấp được phân bổ và đầy. Nếu không sẵn có tệp log sơ cấp nào để ghi các mục làm lại, và số lượng tối đa các tệp log thứ cấp đã được phân bổ rồi, thì một ứng dụng nhận được thông báo lỗi sau đây. SQL0964C Log giao dịch cho cơ sở dữ liệu đã đầy. Hy vọng là bạn từng gặp phải lỗi này. Tuy nhiên, nếu gặp, bạn phải tăng thêm số các tệp log sơ cấp và thứ cấp (hoặc kích thước của chúng) khi cần thiết. Một cách lý tưởng, các tệp log sơ cấp phải lớn hoặc nhiều đủ để chứa cả giao dịch lớn nhất. Việc phân bổ các tệp log thứ cấp là tốn kém do nó được thực hiện vào lúc đang chạy, vì vậy bạn phải giảm thiểu số lượng các tệp log thứ cấp mà cần được phân bổ trong thời gian tải làm việc của bạn là lớn nhất. Để cập nhật số lượng các tệp log sơ cấp hoặc thứ cấp, bạn có thể chạy các lệnh sau đây:  UPDATE DB CFG FOR db_name USING LOGPRIMARY value  UPDATE DB CFG FOR db_name USING LOGSECOND value Ghi chú: Nếu vấn đề này xảy ra, bạn phải tìm hiểu tại sao toàn bộ không gian log bị đầy. Hẳn là do một truy vấn thoát ra ngoài hoặc lỗi của một người sử dụng, do đó việc tăng số lượng hoặc kích thước các tệp log có thể chỉ là che giấu vấn đề. Ví dụ, giả sử một người sử dụng chạy một lệnh DELETE FROM tab1 và TAB1 là một bảng rất lớn. Trong khi lệnh này trông rất vô hại, mỗi bản ghi log đã xoá được tạo ra trên từng hàng, vậy có thể dễ dàng lấp đầy không gian log nếu nó không được lập cấu hình để xử lý. Ghi log quay vòng Khi hình thức ghi log quay vòng có hiệu lực, dữ liệu giao dịch được viết cho các tệp log sơ cấp theo kiểu quay vòng. Khi tất cả các bản ghi lưu trong một tệp log riêng không cần phục hồi nữa, tệp log đó được xử lý là dùng lại được và nó có thể lại trở thành tệp log hoạt động sau này. Điều này có nghĩa là ở cách ghi log quay vòng, nội dung của một tệp log cuối cùng lại bị ghi đè lên bằng lối vào log mới. Do nột dung của tệp log bị ghi đè lên, bạn chỉ có thể phục hồi một cơ sở dữ liệu ở mức sao lưu cơ sở dữ liệu đầy đủ lần cuối. Bạn không thể tiến hành phục hồi theo một điểm thời gian định trước bằng cách ghi log quay vòng. Ghi log lưu trữ Như với cách ghi log quay vòng, các lối vào của log làm lại được viết lên các tệp log sơ cấp. Tuy nhiên, không như kiểu ghi log quay vòng, các tệp log này không bao giờ được sử dụng lại. Khi tất cả các bản ghi lưu lại trong một tệp log riêng không cần phục hồi nữa, tệp log đó được đánh dấu là không hoạt động chứ không phải là không sử dụng lại được. Điều này có nghĩa là nội dung của nó không bao giờ bị ghi đè. Khi tệp log sơ cấp đầu tiên đã đầy, một tệp log sơ cấp mới được phân bổ để số lượng theo cấu hình của các tệp log sơ cấp (tham số cơ sở dữ liệu LOGPRIMARY) là luôn có thể. Tất cả các lối vào liên quan đến một giao dịch đơn lẻ phải khớp với không gian log động. Trong trường hợp mà một giao dịch dài đòi hỏi nhiều không gian log hơn mà có thể được cung cấp trong các tệp log sơ cấp, các tệp log thứ cấp có thể được phân bổ và sử dụng. Theo hình thức log lưu trữ, bạn có thể phục hồi một cơ sở dữ liệu đến một thời điểm đặc biệt bằng cách sử dụng một kết hợp giữa sao lưu các ảnh cơ sở dữ liệu và các tệp log. Quá trình này được mô tả sau đây chi tiết hơn. Cách thay đổi hình thức ghi log Khi một cơ sở dữ liệu DB2 mới được tạo ra, hình thức ghi log quay vòng là mặc định. Nếu bạn muốn thay đổi hình thức từ quay vòng thành lưu trữ, bạn có thể thực hiện các bước sau đây: 1. Tạo một thư mục trên một đĩa (chẳng hạn như e:\db_name\archive) nơi có đủ không gian đĩa để lưu lại các tệp log được lưu trữ. Như một thực hành tốt nhất, hãy giữ điểm đích tệp log được lưu trữ của bạn tách biệt khỏi điểm đích tệp log hoạt động. 2. Chấm dứt kết nối đến cơ sở dữ liệu: o TERMINATE 3. Cập nhật điểm đích tệp log được lưu trữ. (Việc quy định một đường dẫn cho các tệp log được lưu trữ có tác dụng thay đổi hình thức log lưu trữ). o UPDATE DB CFG FOR db_name USING LOGARCHMETH1 "Disk:e:\db_name\archive" 4. Kết nối lại đến cơ sở dữ liệu: o CONNECT TO db_name 5. Kết nối thất bại và bạn nhận được thông báo sau: SQL1116N Một kết nối đến hoặc kích hoạt của cơ sở dữ liệu db_name không thực hiện được do việc sao lưu đang chờ xử lý: SQLSTATE=57019 Việc này xảy ra vì hình thức ghi log cơ sở dữ liệu được thay đổi từ quay vòng sang lưu trữ và một việc sao lưu cơ sở dữ liệu đầy đủ phải được tiến hành. Một việc sao lưu được tiến hành khi cơ sở dữ liệu đang ghi log quay vòng là không đủ khi chuyển đổi các hình thức ghi log và một sao lưu mới phải được tiến hành. 6. Thực hiện sao lưu cơ sở dữ liệu đầy đủ bằng cách sử dụng một lệnh như sau đây: o BACKUP DATABASE db_name TO d:\db_name\backup 7. Thử kết nối đến cơ sở dữ liệu một lần nữa. Lần này nó sẽ thành công. o CONNECT TO db_name Các thực hành tốt nhất để giữ cho dữ liệu an toàn Đây là một vài thực hành tốt nhất để giữ an toàn cho dữ liệu của bạn: 1. Giữ cơ sở dữ liệu của bạn ở dạng log lưu trữ để trong trường hợp có sự cố bạn có thể phục hồi lại cơ sở dữ liệu đến một thời điểm riêng. 2. Tiến hành thường xuyên các việc sao lưu cơ sở dữ liệu đầy đủ và sao lưu tăng dần (full and incremental database backups). Các đòi hỏi về nghiệp vụ cuối cùng thì cũng yêu cầu viết lịch biểu và tần suất thực hiện sao lưu. 3. Lúc nào cũng giữ một bản sao rập khuôn hoặc bản dự phòng cơ sở dữ liệu nếu đó là cơ sở dữ liệu thiết yếu. 4. Giữ các tệp log hoạt động và log lưu trữ tại các địa chỉ khác nhau, với mỗi địa chỉ có đủ không gian đĩa. 5. Đảm bảo tham số cơ sở dữ liệu BLK_LOG_DSK_FUL được đặt ở giá trị YES bằng cách sử dụng lệnh sau đây: o UPDATE DB CFG FOR db_name USING BLK_LOG_DSK_FUL YES Việc đặt BLK_LOG_DSK_FUL là YES làm cho các ứng dụng bị treo khi DB2 gặp phải một lỗi vì hệ thống tệp đang giữ các tệp log đã đầy. Việc này cho phép bạn giải quyết được lỗi và cho phép việc chạy các giao dịch được hoàn tất. Bạn có thể giải quyết một lỗi đĩa log bị đầy bằng cách chuyển các tệp log cũ lên hệ thống tệp khác hoặc bằng cách mở rộng hệ thống tệp. Các kịch bản phục hồi Điều quan trọng là phải hiểu được cách các sự cố có thể xảy ra và cách phục hồi chúng. Các phần sau đây mô phỏng các kiểu sự cố khác nhau và trình bày một loạt các bước mà có thể được làm theo để phục hồi từ chúng. Kịch bản 1. Toàn bộ cơ sở dữ liệu vô tình bị mất hoặc bị hỏng Kịch bản này chỉ ra cách phục hồi từ một cơ sở dữ liệu hỏng hoàn toàn. Tình trạng này có thể xảy ra nếu cơ sở dữ liệu vô tình bị mất hoặc bị hư hỏng hoặc không bền vững do một lỗi thủ công hoặc do hư hỏng phần cứng. Trong các trường hợp như thế này, bạn có thể phục hồi cơ sở dữ liệu hoàn toàn bằng cách áp dụng sao lưu cơ sở dữ liệu đầy đủ lần cuối. Kịch bản này dựa trên cấu hình hiển thị trong Bảng 1. Bảng 1. Cấu hình hệ thống sử dụng trong kịch bản phục hồi 1 Thành phần Mô tả Hệ điều hành Windows XP Service Pack 2 / RHEL 4.0 Bản DB2 và cấp độ DB2 UDB Enterprise Server Edition (ESE) V8.2.6 fixpak 13 / DB2 V9.1 ESE fixpak 1 Tên cơ sở dữ liệu TESTDB1 Bước 1. Thực hiện sao lưu cơ sở dữ liệu đầy đủ Để thực hiện sao lưu bên ngoài cơ sở dữ liệu đầy đủ, các lệnh sau đây có thể được chạy:  TERMINATE  FORCE APPLICATION ALL  BACKUP DATABASE testdb1 TO c:\testdb1\backup Phải chắc chắn để ý đến định danh được tạo ra trong tên tệp sao lưu. Nó trông tương tự như: 20060411154219. Định danh này đơn giản chỉ là nhãn thời gian của ảnh sao lưu và cần đến trong quá trình khôi phục. Bước 2. Mô phỏng một sự cố Để mô phỏng một kịch bản sự cố, mất hoàn toàn cơ sở dữ liệu:  TERMINATE  FORCE APPLICATION ALL  DROP DATABASE testdb1 Bây giờ, thử kết nối đến cơ sở dữ liệu:  CONNECT TO testdb1 Lỗi sau đây được báo lên, nó báo cho biết cơ sở dữ liệu không còn ở đó: Error: SQL1013N Không thể tìm thấy tên bí danh cơ sở dữ liệu hoặc tên cơ sở dữ liệu “testdb1”. Bước 3. Tạo một cơ sở dữ liệu mới Để bắt đầu quá trình phục hồi, tạo một cơ sở dữ liệu mới có cùng tên của cơ sở dữ liệu bị mất:  CREATE DATABASE testdb1 Bảo đảm cơ sở dữ liệu được tạo ra và được vào danh mục chính xác bằng cách quan sát nội dung của thư mục cơ sở dữ liệu:  LIST DB DIRECTORY Bước 4. Khôi phục cơ sở dữ liệu Khôi phục ảnh sao lưu cơ sở dữ liệu. Trong ví dụ này, bạn khôi phục một ảnh sao lưu với nhãn thời gian 20060411154219:  RESTORE DATABASE testdb1 FROM c:\testdb1\backup TAKEN AT 20060411154219 INTO testdb1 [...]... báo sau đây được trả về: SQL2523W: Khôi phục một cơ sở dữ liệu hiện tại khác với cơ sở dữ liệu trên ảnh sao lưu Cơ sở dữ liệu đích sẽ bị ghi đè bởi phiên bản sao lưu Các log khôi phục cuộn tiến liên kết với cơ sở dữ liệu đích sẽ bị ghi đè Gõ Y để tiếp tục Việc này khôi phục sao lưu cơ sở dữ liệu qua cơ sở dữ liệu vừa được tạo ra từ bước trước Một khi ảnh đã được khôi phục, cơ sở dữ liệu là bền vững đến... sau: Cảnh báo SQL 2539W! Khôi phục một cơ sở dữ liệu hiện hành giống như cơ sở dữ liệu ảnh sao lưu Các tệp cơ sở dữ liệu sẽ bị xoá Bạn có muốn tiếp tục không? (Y/N) Gõ nhập Y để tiếp tục Bước 6 Cuộn tiến cơ sở dữ liệu Sau khi khôi phục cơ sở dữ liệu, thử kết nối đến cơ sở dữ liệu:  CONNECT TO testdb1 Thông báo sau đây được trả về: SQL 111N Một kết nối đến hoặc kích hoạt cơ sở dữ liệu không thể thực... trả về: Error: SQL0204N “Administrator.TAB1” là một tên chưa được xác định Bước 4 Khôi phục cơ sở dữ liệu Để khôi phục bảng bị mất, khôi phục lại sao lưu cơ sở dữ liệu đã thực hiện, sau đó chạy phép cuộn tiến:  TERMINATE  FORCE APPLICATION ALL  RESTORE DATABASE testdb1 FROM c:\testdb1\backup TAKEN AT 20070314144204 INTO testdb1 Thông điệp cảnh báo sau đây được trả về: Cảnh báo SQL2539W! Khôi phục. .. đến cơ sở dữ liệu Thử kết nối đến cơ sở dữ liệu:  CONNECT TO testdb1 Thông báo lỗi sau đây có thể được trả về: SQL1117N Một kết nối đến hoặc kích hoạt của cơ sở dữ liệu “testdb1” không thể thực hiện được vì Đang chờ Cuộn tiến (Roll-Forward Pending) SQLSTATE=570 19 Điều này có thể xảy ra vì việc kiểm tra sự bền vững phải xảy ra bằng cách sử dụng một số tệp log Chạy lệnh sau đây để đưa cơ sở dữ liệu. .. nào và đưa cơ sở dữ liệu đến trạng thái bền vững Kịch bản 3 Một bảng vô tình bị lược bỏ Trong một số môi trường cơ sở dữ liệu với hàng nghìn bảng, đôi khi một bảng bị lược bỏ do nhầm lẫn Trong kịch bản này, bạn xem cách phục hồi một bảng mà vô tình bị mất Để có thể thực hiện kiểu phục hồi này, cơ sở dữ liệu của bạn phải được cấu hình để ghi log lưu trữ và phải sẵn có một ảnh sao lưu cơ sở dữ liệu đầy... dụng để DB2 áp dụng tất cả các tệp log sẵn có sau khi sao lưu được thực hiện Bước 7 Kiểm tra tệp dữ liệu được xuất Sau khi cuộn tiến cơ sở dữ liệu hoàn tất, kiểm tra đường dẫn mà bạn đã quy định trong lệnh ROLLFORWARD Bạn phải thấy tệp.TXT mà bạn có thể mở và kiểm tra lại xem dữ liệu chứa trong nó có giống với dữ liệu (đã cam kết), đã có mặt trước khi bảng vô tình bị bỏ Bước 8 Kết nối với cơ sở dữ liệu. .. nó và dữ liệu của chúng trở nên không thể truy cập được Để phục hồi lại từ kịch bản này, bạn phải có một ảnh sao lưu cơ sở dữ liệu đầy đủ và cơ sở dữ liệu phải được cấu hình ghi log lưu trữ Kịch bản này dựa trên cấu hình hệ thống trình bày trong Bảng 4 Bảng 4 Cấu hình hệ thống sử dụng trong kịch bản phục hồi 4 Thành phần Mô tả Hệ điều hành Windows XP Service Pack 2 / RHEL 4.0 Bản DB2 và cấp DB2 UDB... bước tiếp theo là cuộn tiến về trước cơ sở dữ liệu bằng cách sử dụng sao lưu ID của bảng bị lược bỏ, để dữ liệu của bảng có thể xuất được Trước khi cuộn tiến, đảm bảo có một thư mục để lưu lại dữ liệu được xuất, ví dụ: c:\testdb1\exporttab1 Sử dụng lệnh sau để cuộn tiến cơ sở dữ liệu:  ROLLFORWARD DATABASE testdb1 TO END OF LOGS AND STOP RECOVER DROPPED TABLE 000000000000 892 700050108 TO c:\testdb1\exporttab1... thấy trong Bảng 3 Bảng 3 Cấu hình hệ thống sử dụng trong kịch bản phục hồi 3 Thành phần Mô tả Hệ điều hành Windows XP Service Pack 2 / RHEL 4.0 Bản DB2 và cấp DB2 UDB Enterprise Server Edition (ESE) 8.2.6 fixpak 13 / độ DB2 9. 1 ESE fixpak 1 Tên cơ sở dữ liệu TESTDB1 Tên không gian bảng Tên bảng TS1 TAB1 Bước 1 Thực hiện sao lưu cơ sở dữ liệu đầy đủ  TERMINATE  FORCE APPLICATION ALL  BACKUP DATABASE... Cảnh báo SQL2539W! Khôi phục một cơ sở dữ liệu hiện tại giống cơ sở dữ liệu ảnh sao lưu Các tệp cơ sở dữ liệu sẽ bị xoá Bạn có muốn tiếp tục không? (Y/N) Gõ Y để hoàn tất lệnh Bước 5 Lấy ra định danh đối tượng của bảng bị mất Sử dụng lệnh sau đây để lấy ra định danh đối tượng của bảng vô tình bị mất:  LIST HISTORY DROPPED TABLE ALL FOR DATABASE testdb1 Thông tin được trả về, như ví dụ trong Liệt kê 1, . SQL2523W: Khôi phục một cơ sở dữ liệu hiện tại khác với cơ sở dữ liệu trên ảnh sao lưu. Cơ sở dữ liệu đích sẽ bị ghi đè bởi phiên bản sao lưu. Các log khôi phục cuộn tiến liên kết với cơ sở dữ liệu. chọn phục hồi DB2 9 đa dạng và gồm các chủ đề sau:  Ghi log cơ sở dữ liệu.  Cách thay đổi hình thức ghi log cơ sở dữ liệu.  Các thực hành tốt nhất để giữ an toàn cơ sở dữ liệu dữ liệu. . thời điểm. Ghi log Cơ sở dữ liệu Các cơ sở dữ liệu DB2 hỗ trợ hai hình thức ghi log cơ sở dữ liệu khác nhau: Circular (Quay vòng) và Archival (Lưu trữ). Khi một cơ sở dữ liệu mới được tạo ra,