Giới thiệu về khôi phục cơ sở dữ liệu DB2 9

Chia sẻ: Nguyen Nhi | Ngày: | Loại File: PDF | Số trang:29

Thêm vào BST

Báo xấu

93
lượt xem 13
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Giới thiệu về khôi phục cơ sở dữ liệu DB2 9

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: TERMINATE o
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ữ). UPDATE DB CFG FOR db_name USING LOGARCHMETH1 o "Disk:e:\db_name\archive" 4. Kết nối lại đến cơ sở dữ liệu: CONNECT TO db_name o 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:
BACKUP DATABASE db_name TO d:\db_name\backup o 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. CONNECT TO db_name o 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:
UPDATE DB CFG FOR db_name USING BLK_LOG_DSK_FUL o 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à DB2 UDB Enterprise Server Edition (ESE) V8.2.6 fixpak 13 / DB2 V9.1 ESE fixpak 1 cấp độ Tên cơ sở dữ TESTDB1 liệu 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
Thông điệp cảnh 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 điểm mà sao lưu được thực hiện. Bước 5. Kết nối đế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=57019. Đ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 sang trạng thái bền vững: ROLLFORWARD DATABASE testdb1 COMPLETE  Thử kết nối cơ sở dữ liệu một lần nữa: CONNECT TO testdb1  Bước 6. Xác thực cơ sở dữ liệu và các đối tượng
Kiểm tra lại xem các đối tượng tồn tại trước đây còn ở đó và sẵn sàng để dùng không, ví dụ: LIST TABLESPACES SHOW DETAIL o LIST TABLES o Các lệnh trước đó sẽ báo cáo rằng tất cả các không gian bảng ở trạng thái bình thường và rằng các vùng chứa có thể truy cập được. Tất cả các bảng cũng phải ở đó với bộ dữ liệu đã có mặt vào lúc thực hiện sao lưu. Kịch bản 2. Một vùng chứa không gian bảng vô tình bị mất hoặc hỏng Kịch bản này thể hiện cách phục hồi từ một tình trạng khi một hoặc nhiều vùng chứa không gian bảng mất hoặc bị hỏng. Tình trạng này có thể phát sinh do lỗi của người (chẳng hạn như một người sử dụng xoá một thư mục hoặc tệp) hoặc vì một vấn đề hỏng tệp dữ liệu. Kịch bản này dựa trên cấu hình trình bày trong Bảng 2. Bảng 2. Cấu hình hệ thống sử dụng trong kịch bản phục hồi 2 Thành phần M ô tả Windows XP Service Pack 2 / RHEL 4.0 Hệ điều hành 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 Tên không gian TS1 bảng Các vùng chứa c1.dat, c2.dat, c3.dat, c4.dat trong TS1 Bước 1. Kiểm kê lại tất cả các không gian bảng được xác định CONNECT TO testdb1  LIST TABLESPACES SHOW DETAIL  Bước 2. Kiểm kê lại tất cả các thông tin v ùng chứa không gian bảng LIST TABLESPACE CONTAINERS FOR 1 SHOW DETAIL Lưu ý rằng  “1” trong lệnh trên đây là định danh không gian bảng đối với không gian bảng TS1 trong môi trường này. Nó thu được do kết quả của lệnh LIST TABLESPACES SHOW DETAIL trước đó. Lệnh này sẽ cần được lặp lại đối với mỗi định danh không gian bảng được sử dụng. Bước 3. Sao lưu không gian bảng TERMINATE 
FORCE APPLICATION ALL  BACKUP DATABASE testdb1 TABLESPACE ts1 TO  c:\testdb1\backup\ts1 Như bạn đã biết, kịch bản này giả định rằng bạn đã thực hiện sao lưu các không gian bảng thiết yếu nhất cho mục đích phục hồi. Bước 4. Mô phỏng một sự cố không gian bảng Mô phỏng thủ công trường hợp trong đó tệp vùng chứa không gian bảng bị một người sử dụng vô ý xoá nhầm: DEL C:\TESTDB1\TS1\C1.DAT  DEL C:\TESTDB1\TS1\C2.DAT  DEL C:\TESTDB1\TS1\C3.DAT  Sau này, khi bạn kết nối cơ sở dữ liệu và thử thực hiện các thao tác mà phụ thuộc vào không gian bảng TS1, một lỗi sẽ được trả về. Ví dụ: CONNECT TO testdb1  CREATE TABLE tab1(c1 INTEGER) IN ts1  trả về thông báo lỗi sau đây: SQL0290N Không được phép truy cập không gian bảng. Bạn cũng có thể kiểm tra tình trạng không gian bảng bằng cách chạy lệnh sau đây: LIST TABLESPACES SHOW DETAIL o
Sau khi các vùng chứa bị xoá, lệnh trên đây chỉ ra tình trạng của TS1 là 0x400, có nghĩa là nó đang ở trạng thái offline và không thể truy cập được. Do ba vùng chứa đã bị xoá, không gian bảng không còn giữ nguyên trạng thái bình thường nữa (0x000). Nếu bạn chạy lại lệnh LIST TABLESPACE CONTAINERS bạn có thể kiểm tra lại các vùng chứa nào bị mất hoặc không sẵn có nữa: LIST TABLESPACE CONTAINERS FOR 1 SHOW DETAIL  Trong các kết quả, tình trạng Accessible sẽ chỉ No đối với các vùng chứa C1, C2, và C3. Bước 6. Khôi phục ảnh sao lưu không gian bảng Để khôi phục ảnh sao lưu, chạy các lệnh sau đây: TERMINATE  RESTORE DATABASE testdb1 TABLESPACE (ts1) FROM  C:\TESTDB1\BACKUP\TS1 Bước 7. Kiểm tra tình trạng không gian bảng Phải chắc chắn rằng các vùng chứa là có thể truy cập được: LIST TABLESPACES SHOW DETAIL  LIST TABLESPACE CONTAINERS FOR 1 SHOW DETAIL  Nếu khôi phục thành công, tình trạng của không gian bảng TS1 sẽ là bình thường (0x000) và tất cả các vùng chứa phải có thể truy cập được.
Bước 8. Kiểm tra lại khôi phục thành công CREATE TABLE tab1(no INTEGER) IN ts1  Ghi chú: Bạn có thể gặp phải một tình huống là sau khi khôi phục không gian bảng, sau đó cần phải có động tác phục hồi nữa. Việc n ày có thể xảy ra nếu có bất kỳ thay đổi tệp log nào mà chưa được áp dụng để làm cho cơ sở dữ liệu bền vững. Trong trường hợp này, chỉ cần chạy một trong các lệnh sau đây để hoàn tất phục hồi: ROLLFORWARD DATABASE testdb1 COMPLETE  HOẶC ROLLFORWARD DATABASE testdb1 TO END OF LOGS AND STOP  Các lệnh trên đây áp dụng cho bất kỳ tệp log còn lại 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 đủ. Để một bảng bị mất có thể phục hồi được, không gian bảng mà bảng nằm trong đó phải có tuỳ chọn DROPPED TABLE RECOVERY được bật. Việc này có thể được đặt trong khi tạo không gian bảng, hoặc bằng cách dẫn ra lệnh ALTER
TABLESPACE. Tuỳ chọn DROPPED TABLE RECOVERY dùng riêng cho không gian bảng và chỉ cho không gian bảng bình thường. Kịch bản này dựa trên cấu hình hệ thống 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 TS1 bảng TAB1 Tên bảng Bước 1. Thực hiện sao lưu cơ sở dữ liệu đầy đủ TERMINATE  FORCE APPLICATION ALL 
BACKUP DATABASE testdb1 TO c:\testdb1\backup  Phải chắc chắn để ý đến nhãn thời gian của ảnh sao lưu. Bước 2. Kết nối đến cơ sở dữ liệu và thực hiện các thao tác tạo bản ghi log CONNECT TO testdb1  CREATE TABLE tab1(no INTEGER) IN ts1  TERMINATE  ARCHIVE LOG FOR DATABASE testdb1  CONNECT TO testdb1  INSERT INTO tab1 VALUES(1)  INSERT INTO tab1 VALUES(2)  INSERT INTO tab1 VALUES(3)  COMMIT  TERMINATE  ARCHIVE LOG FOR DATABASE testdb1  CONNECT TO testdb1  INSERT INTO tab1 VALUES(4)  INSERT INTO tab1 VALUES(5)  COMMIT 
TERMINATE  ARCHIVE LOG FOR DATABASE testdb1  CONNECT TO testdb1  SELECT * FROM tab1 /* check the 5 committed values from TAB */  Bước 3. Mô phỏng việc bị mất bảng do sự cố DROP TABLE tab1  COMMIT  SELECT * FROM tab1  Thông báo lỗi sau đây sẽ đượ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 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, có thể được sao chép thành một tệp văn bản để tham khảo sau này. Liệt kê 1. Thông tin trả về từ lệnh LIST HISTORY Op Obi Timestamp Sequence Type Dev Earliest Log Current Log Backup ID -- --- ------------------ ---- --- ------------ ------------ ----------------------------- D T 20070314142913 000000000000892700050108 ------------------------------------------------------------------------------------------