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

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
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ụ:
o LIST TABLESPACES SHOW DETAIL
o LIST TABLES
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ả
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
Tên không gian
bảng
TS1
Các vùng chứa

trong TS1
c1.dat, c2.dat, c3.dat, c4.dat

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:
o LIST TABLESPACES SHOW DETAIL
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
bảng
TS1
Tên bảng
TAB1

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

"ADMINISTRATOR"."TAB1" resides in 1 table space(s):
00001 TS1

Comment: DROP TABLE
Start Time: 20070314142913
End Time: 20070314142913
Status: A

EID: 37
DDL: CREATE TABLE "ADMINISTRATOR"."TAB1" ( "NO" INTEGER ) IN
"TS1" ;

Cột Định danh Sao lưu (Backup ID) từ Liệt kê 1 cho thấy
000000000000892700050108 là định danh đối với bảng bị bỏ. Đây là một thông
tin quan trọng cần có để phục hồi bảng.
Bước 6. Cuộn tiến cơ sở dữ liệu
Bây giờ thì bạn đã có định danh ID đối với bảng bị lược bỏ, 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 000000000000892700050108

TO c:\testdb1\exporttab1
Tuỳ chọn END OF LOGS được sử 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 và tạo lại bảng bị lược bỏ
Sau khi kiểm chứng lại tệp xuất ra, bạn sẽ cần phải tạo lại bảng bị mất và nhập dữ
liệu vào bảng. Định nghĩa của bảng bị lược bỏ được chứa trong đầu ra của lệnh
LIST HISTORY từ bước 5. Kết nối cơ sở dữ liệu và thực hiện lệnh CREATE
TABLE:
 CONNECT TO testdb1
 CREATE TABLE "ADMINISTRATOR"."TAB1" ( "NO" INTEGER ) IN
"TS1"
Bước 9. Nhập dữ liệu
Một khi bạn tạo lại bảng, nhập dữ liệu trở lại vào nó bằng cách sử dụng một lệnh
chẳng hạn như:
 IMPORT FROM c:\testdb1\exporttab1\Node0000\data.txt OF DEL
INSERT INTO administrator.tab1
Tiện ích IMPORT nhập tất cả dữ liệu từ tệp xuất và báo cáo trở lại cho bạn về
thành công của nó (không hiển thị).
Bước 10. Kiểm tra lại dữ liệu được phục hồi
Đảm bảo rằng không có lỗi hoặc thông điệp cảnh báo trong quá trình IMPORT
(NHẬP) và rằng tất cả dữ liệu đã nhập trở lại bảng:
 SELECT * FROM tab1
Nếu mọi việc trôi chảy, tất cả dữ liệu đã chuyển đến thời điểm xảy ra sự cố lược
bỏ sẽ nằm trong bảng.

Kịch bản 4. Phục hồi đến một thời điểm
Nếu một không gian bảng bị lược bớt hoặc hỏng, các bảng được xác định trong 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 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
TS1
Tên bảng
TAB1

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
Hãy chắc chắn viết nhanh nhãn thời gian tệp ảnh sao lưu nhận được vì điều này

được yêu cầu trong quá trình khôi phục.
Bước 2. Tạo một không gian bảng mới
Tạo một không gian bảng mới có tên TS1 được sử dụng trong kịch bản sao lưu
này:
 CREATE TABLESPACE TS1 MANAGED BY DATABASE USING
(FILE 'c:\testdb1\s4\C1.dat' 1000 )
EXTENTSIZE 8 PREFETCHSIZE 24
Xác nhận không gian bảng và các vùng chứa liên kết đã được tạo ra:
 LIST TABLESPACES
 LIST TABLESPACE CONTAINERS FOR n SHOW DETAIL
với n là định danh không gian bảng hiển thị trong đầu ra LIST TABLESPACES.
Bước 3. Tạo một bảng và thực hiện một vài thao tác trên nó
Sau khi tạo ra không gian bảng, tạo một bảng có tên là TAB1 và đặt nó vào không
gian bảng. Chèn một số dữ liệu vào bảng. Để cho kịch bản thực tế hơn, chạy một
vài lệnh mà buộc DB2 chuyển đổi các tệp log động:
 CREATE TABLE tab1 (no INTEGER) IN TS1
 INSERT INTO tab1 VALUES(1)
 INSERT INTO tab1 VALUES(2)
 COMMIT
 TERMINATE
 ARCHIVE LOG FOR DATABASE testdb1
 CONNECT TO testdb1