Chuẩn bị kỳ thi số 731 lấy chứng chỉ DBA (Quản trị cơ sở dữ liệu) DB2 9, Phần 6: Tính sẵn sàng cao: Sao lưu và phục hồi pptx

Chuẩn bị kỳ thi số 731 lấy chứng chỉ DBA (Quản trị cơ sở dữ liệu) DB2 9,
Phần 6: Tính sẵn sàng cao: Sao lưu và phục hồi
Sylvia Qi, Kiểm định chức năng, IBM Toronto Lab
Рауль Ф. Чонг (Raul F. Chong), Chuyên gia, IBM Toronto Lab，IBM
Tóm tắt: Hướng dẫn này bàn về các chủ đề sao lưu và phục hồi cơ sở dữ liệu. Nó
giải thích các phương pháp khác nhau về phục hồi cơ sở dữ liệu và ghi lưu lại (ghi
log) và làm thế nào để sử dụng các lệnh BACKUP (Sao lưu), RESTORE (Khôi
phục lại), ROLLFORWARD (Khôi phục tiếp) và RECOVER (Phục hồi). Nó cũng
bao gồm các lệnh DATABASE REBUILD (Xây dựng lại cơ sở dữ liệu) mới. Đây
là phần đầu tiên của một cuộc thảo luận với hai phần về tính sẵn sàng cao; Phần 7
trình bày việc nhân bản dữ liệu, chia tách và việc khắc phục sự cố có tính sẵn sàng
cao. Đây là hướng dẫn thứ sáu trong một loạt bài gồm bảy hướng dẫn để giúp bạn
chuẩn bị cho kỳ thi 731 về Quản trị Cơ sở dữ liệu DB2® 9 cho Linux®, UNIX®,
và Windows™.
Trước khi bạn bắt đầu
Đây là hướng dẫn thứ sáu trong một loạt bài gồm có bảy hướng dẫn mà bạn có thể
sử dụng để trợ giúp chuẩn bị cho kỳ thi cấp chứng chỉ về Quản trị Cơ sở dữ liệu
DB2 9 cho Linux, UNIX và Windows DB2® 9. Hướng dẫn này, kết hợp với Phần
7, Tính sẵn sàng cao: việc nhân bản dữ liệu, chia tách và việc khắc phục sự cố,
trình bày các mục tiêu trong phần này của kỳ thi mang tên "Tính sẵn sàng cao".
Về loạt hướng dẫn này
Nếu bạn đang chuẩn bị tham dự kỳ thi 731 lấy chứng chỉ DBA DB2, bạn đã đến
đúng chỗ một hướng dẫn tự học, giả định thế. Loạt bài gồm bảy hướng dẫn
chuẩn bị lấy chứng chỉ DB2 này trình bày các khái niệm chính mà bạn cần phải
biết cho kỳ thi này. Hãy làm bài tập ở nhà của bạn ở đây để làm giảm bớt những
căng thẳng trong ngày thi.


Về hướng dẫn này
Hướng dẫn này bàn về các chủ đề sao lưu và phục hồi cơ sở dữ liệu. Nó giải thích
các phương pháp khác nhau về phục hồi cơ sở dữ liệu và ghi log và làm thế nào để

sử dụng các lệnh BACKUP, RESTORE, ROLLFORWARD và RECOVER. Nó
cũng bao gồm các phép DATABASE REBUILD mới. Đây là hướng dẫn thứ sáu
trong một loạt bài gồm bảy hướng dẫn để giúp bạn chuẩn bị cho kỳ thi DB2 V9
cho Linux, UNIX và Windows; (Quản trị Cơ sở dữ liệu DB2 9 cho Linux, UNIX
và Windows) (kỳ thi 731). Các tài liệu trong hướng dẫn này chủ yếu trình bày các
mục tiêu tại Phần 6 của kỳ thi này, "Tính sẵn sàng cao". Bạn có thể xem các mục
tiêu này tại: Các chủ đề về tính
sẵn sàng cao còn lại được trình bày trong Phần 7, Tính sẵn sàng cao: nhân bản dữ
liệu có phân tách và khắc phục sự cố có tính sẵn sàng cao (HADR- high
availability disaster recovery).


Các mục tiêu
Sau khi hoàn thành hướng dẫn này, bạn sẽ có thể:
 Hiểu được các phương pháp phục hồi có sẵn với DB2.
 Hiểu được các bản ghi giao dịch (log giao dịch) và các kiểu bản ghi khác có
sẵn.
 Hiểu được các kiểu của các phương pháp ghi log có thể được sử dụng
 Thực hiện các lệnh BACKUP.
 Thực hiện các lệnh RESTORE.
 Thực hiện các lệnh ROLLFORWARD.
 Thực hiện các lệnh RECOVER.
 Thực hiện các lệnh DATABASE REBUILD.
 Hiểu biết về các vấn đề tạo lại chỉ mục.


Các điều kiện cần trước
Để hiểu tài liệu được trình bày trong hướng dẫn này, bạn cần hiểu rõ về:
 Môi trường DB2 (các tệp cấu hình của trình quản lý cơ sở dữ liệu, các tệp
cấu hình cơ sở dữ liệu, các biến đăng ký DB2, v.v).

 Sử dụng bộ xử lý dòng lệnh và các công cụ giao diện đồ họa (GUI) DB2 để
gọi các lệnh DB2.
 Các đối tượng DB2 khác nhau, chẳng hạn như các vùng bộ đệm, các không
gian bảng (tablespaces), các bảng và các chỉ mục.
 Các lệnh SQL cơ bản có thể được thực hiện trên một cơ sở dữ liệu (các câu
lệnh SQL UPDATE, INSERT, DELETE và SELECT)
Bạn cũng nên quen với các thuật ngữ sau đây:
 Đối tượng: Bất kỳ thứ gì trong một cơ sở dữ liệu có thể được tạo ra hoặc
được thao tác với SQL (ví dụ các bảng, các khung nhìn, các chỉ mục, các
gói).
 Bảng: Một cấu trúc logic được sử dụng để trình bày dữ liệu dưới dạng một
tập các hàng không theo thứ tự với một số cột cố định. Mỗi cột có chứa một
tập giá trị, mỗi giá trị có cùng một kiểu dữ liệu (hoặc kiểu con của kiểu dữ
liệu của cột); các định nghĩa về các cột tạo nên cấu trúc bảng và các hàng
có chứa dữ liệu thực tế của bảng.
 Bản ghi: Biểu diễn lưu trữ của một hàng trong một bảng.
 Trường: Biểu diễn lưu trữ của một cột trong một bảng.
 Giá trị: Một mục dữ liệu cụ thể có thể được tìm thấy tại giao điểm của một
hàng và cột trong một bảng cơ sở dữ liệu.
 Structured Query Language (SQL-Ngôn ngữ truy vấn có cấu trúc)):
Một ngôn ngữ được tiêu chuẩn hóa được sử dụng để định nghĩa các đối
tượng và thao tác dữ liệu trong cơ sở dữ liệu quan hệ. (Để biết thêm về
SQL, xem hướng dẫn thứ tư trong loạt bài này).
 Trình tối ưu hóa DB2: Một thành phần của trình tiền biên dịch
(precompiler) SQL có chọn lựa một kế hoạch truy cập cho một câu lệnh
SQL của Data Manipulation Language (DML- Ngôn ngữ thao tác dữ liệu)
bằng cách mô hình hóa chi phí thực hiện một số kế hoạch truy cập khác
nhau và chọn một kế hoạch truy cập có chi phí đánh giá thấp nhất.
Để tham dự kỳ thi DBA DB2 9, bạn phải vượt qua kỳ thi 730 về Các khái niệm cơ
bản của DB2 9. Chúng tôi khuyên bạn nên tìm hiểu loạt bài hướng dẫn về các khái

niệm cơ bản của DB2 trước khi bắt đầu loạt bài này.
Mặc dù không phải tất cả các tài liệu được thảo luận trong các loạt hướng dẫn các
khái niệm cơ bản là cần thiết để hiểu về các khái niệm được mô tả trong hướng
dẫn này, bạn ít nhất nên có một kiến thức cơ bản về:
 Các sản phẩm DB2.
 Các công cụ DB2.
 Các thể hiện DB2.
 Các cơ sở dữ liệu.
 Các đối tượng cơ sở dữ liệu.


Các yêu cầu về hệ thống
Bạn không cần một bản sao của DB2 để hoàn thành hướng dẫn này. Tuy nhiên,
bạn sẽ thu được nhiều hơn bên ngoài những hướng dẫn, nếu bạn tải phiên bản
dùng thử miễn phí IBM DB2 9 để làm việc cùng với hướng dẫn này.

Các khái niệm phục hồi cơ sở dữ liệu
Các kịch bản phục hồi
Bạn không bao giờ biết khi nào có một thiên tai hoặc hỏng hóc lại rơi vào hệ thống
của mình. Tốt nhất là phải chuẩn bị và bảo vệ dữ liệu của bạn không chỉ nhờ yếu
tố bên ngoài, mà còn với những người dùng nội bộ, những người có thể vô tình
làm hỏng cơ sở dữ liệu của bạn bằng các thông tin không chính xác
Bạn có sao lưu cơ sở dữ liệu của bạn không? Bạn sẽ có thể phục hồi tất cả các giao
dịch đã được thực hiện cho đến giây cuối cùng không?
Để giảm thiểu việc mất dữ liệu của bạn, bạn cần phải có một chiến lược phục hồi,
đảm bảo rằng nó hoạt động và thực hiện chắc chắn. Một số kịch bản phục hồi mà
bạn nên xem xét là:
Sự cố mất điện hệ thống
Một sự cố hư hỏng nguồn, lỗi phần cứng, lỗi phần mềm có thể làm cho cơ
sở dữ liệu của bạn ở trong trạng thái không phù hợp.

Giao dịch thất bại
Người dùng có thể vô tình làm hỏng cơ sở dữ liệu của bạn bằng cách sửa
đổi nó với các dữ liệu sai.
Lỗi phương tiện
Nếu ổ đĩa của bạn trở nên không sử dụng được, bạn có thể mất tất cả hay
một phần dữ liệu.
Thiên tai
Phòng máy ở đó có đặt hệ thống của bạn có thể bị hư hỏng do cháy, lũ lụt
hoặc thiên tai tương tự khác.


Các chiến lược phục hồi
Để lập kế hoạch chiến lược phục hồi của bạn, bạn nên tự hỏi mình một số câu hỏi:
 Dữ liệu của bạn có thể được nạp lại từ các nguồn khác không?
 Làm thế nào để bạn không bị mất dữ liệu?
 Mất bao nhiêu lâu để bạn có thể phục hồi cơ sở dữ liệu?
 Các nguồn tài nguyên lưu trữ nào có sẵn để lưu trữ các bản sao lưu và các
tệp log?


Các giao dịch
Một đơn vị công việc (UOW), cũng được gọi là một giao dịch, bao gồm một hoặc
nhiều câu lệnh SQL được kết thúc bằng một câu lệnh COMMIT hoặc
ROLLBACK. Tất cả các câu lệnh trong UOW này đang được coi là một đơn vị, để
đảm bảo tính nhất quán của dữ liệu. Ví dụ, một khách hàng đang cố gắng để
chuyển 100$ từ một tài khoản tiết kiệm đến một tài khoản dùng séc. UOW trong
trường hợp này sẽ như sau:
DELETE 100 dollars from SAVINGS account
INSERT 100 dollars to CHECKING account
COMMIT

Nếu các câu lệnh này đã không được thực hiện trọn vẹn như một đơn vị, bạn có
thể tưởng tượng điều gì sẽ xảy ra khi có một lỗi phần cứng sau câu lệnh DELETE
nhưng trước câu lệnh INSERT Khách hàng sẽ mất 100$! Khi các câu lệnh được
coi là một đơn vị, tuy nhiên, điều này sẽ không bao giờ xảy ra. DB2 sẽ biết đơn vị
này đã không hoàn thành cam kết (COMMIT), và do đó nó sẽ khôi phục
ROLLBACK tất cả những thay đổi được các câu lệnh trước thực hiện và trả về các
hàng bị ảnh hưởng về trạng thái mà chúng đã có trước khi bắt đầu giao dịch.
Không có câu lệnh nào được sử dụng để nhận biết khởi đầu của một giao dịch.
Câu lệnh tiếp theo sau một COMMIT hoặc ROLLBACK sẽ bắt đầu một giao dịch
mới.


Các kiểu phục hồi
Chúng ta hãy làm quen với các kiểu của các khái niệm phục hồi. DB2 cho phép
các kiểu phục hồi sau:
Phục hồi sự cố
Bảo vệ một cơ sở dữ liệu khỏi trạng thái không phù hợp bằng cách hủy bỏ
(phục hồi) các giao dịch chưa được cam kết. Xem xét lại ví dụ trong bảng
trước đó. Nếu đã mất nguồn trước câu lệnh COMMIT, các lệnh DB2 tiếp
theo được khởi động lại và cơ sở dữ liệu được truy cập, DB2 đầu tiên sẽ
khôi phục ROLLBACK câu lệnh INSERT và sau đó là câu lệnh DELETE.
(Thứ tự trong đó các câu lệnh được phục hồi là ngược với thứ tự trong đó
chúng được thực hiện ban đầu).
Phục hồi phiên bản
Cho phép để khôi phục lại một phiên bản trước của một cơ sở dữ liệu bằng
cách sử dụng ảnh sao lưu do lệnh BACKUP tạo nên. Cơ sở dữ liệu được
khôi phục lại sẽ chứa các thông tin về trạng thái mà nó đã có khi lệnh
BACKUP đã được thi hành. Nếu hoạt động nữa được thực hiện trên cơ sở
dữ liệu sau khi sao lưu này đã được thực hiện, thông tin này sẽ bị mất.

Phục hồi khôi phục tiếp
Mở rộng việc phục hồi phiên bản bằng cách sử dụng toàn bộ các bản sao
lưu cơ sở dữ liệu cùng với các tệp log. Một bản sao lưu phải được khôi
phục lại đầu tiên để được sử dụng như nền; sau đó các log được được sử
dụng dựa trên nền này. Thủ tục này sẽ cho phép khôi phục lại của một cơ
sở dữ liệu hoặc một vùng các bảng đến một điểm cụ thể. Phục hồi khôi
phục tiếp (rollforward) đòi hỏi phải kích hoạt việc ghi lưu trữ. Việc ghi log
được thảo luận trong Các kiểu ghi log.
Các bản ghi (log) DB2
Các log giao dịch DB2 rất quan trọng cho việc phục hồi. Chúng theo dõi các thay
đổi được thực hiện với các đối tượng cơ sở dữ liệu và dữ liệu. Log có thể được lưu
trữ trong các tệp hoặc trong các thiết bị thô. Đối với các ví dụ dưới đây, chúng ta
sẽ sử dụng các tệp. Để đảm bảo tính nguyên vẹn dữ liệu, DB2 sử dụng một sơ đồ
ghi viết-trước, trong đó nó viết vào các log trước khi viết (gửi ra ngoài) các thay
đổi vào cơ sở dữ liệu trên đĩa. Hình dưới đây cho thấy sơ đồ này.

Trong hình này có bốn câu lệnh SQL đã được thực hiện. Các câu lệnh đã được lưu
trữ nhanh trong bộ nhớ tạm và các trang dữ liệu đã được lấy ra từ cơ sở dữ liệu
đưa vào vùng đệm. Khi các câu lệnh SQL được thực hiện, trước tiên các thay đổi
được ghi lại trong bộ đệm bản ghi và sau đó được viết vào các tệp log. Trong ví dụ
này, các phiên bản mới của các trang dữ liệu chưa được gửi ra bên ngoài đến cơ sở
dữ liệu. Điều này được thực hiện bình thường khi không gian vùng bộ đệm cần
thiết hoặc được thực hiện không đồng bộ vì các lý do hiệu năng.
Các tệp log sơ cấp và thứ cấp
Các tệp log sơ cấp ngay lập tức được cấp phát trên kết nối cơ sở dữ liệu đầu tiên
hoặc vào thời gian kích hoạt cơ sở dữ liệu. Các tệp log thứ cấp được cấp phát
động một tệp một lần khi cần thiết.
Có một số tham số cấu hình cơ sở dữ liệu liên quan đến việc ghi log. Một số trong
chúng là:
Tham số Sử dụng

LOGPRIMARY

Cho biết số lượng các tệp log sơ cấp được cấp phát.
LOGSECOND
Cho biết số lượng lớn nhất các tệp log thứ cấp có thể
được cấp phát.
LOGFILSIZ
Được dùng để chỉ rõ kích thước của một tệp log (bằng số
các trang 4KB).

Chúng ta hãy xem xét một ví dụ. Hãy tưởng tượng bạn có các giá trị sau trong tệp
cấu hình cơ sở dữ liệu của bạn:
Log file size (4 KB) (LOGFILSIZ) = 1000
Number of primary log files (LOGPRIMARY) = 3
Number of secondary log files (LOGSECOND) = 2
Path to log files = C:\mylogs\

Ngay sau khi kết nối lần đầu vào cơ sở dữ liệu được thiết lập, ba tệp log sơ cấp,
mỗi tệp có 1000 trang 4 KB, được cấp phát. Nếu bạn xem trong thư mục
C:\mylogs, bạn sẽ thấy ba tệp:
Directory of C:\MYLOGS\

06/04/2006 06:17 PM 4,104,192 S0000000.LOG
06/04/2006 06:17 PM 4,104,192 S0000001.LOG
06/04/2006 06:17 PM 4,104,192 S0000002.LOG
3 File(s) 12,312,576 bytes


Bây giờ, giả sử không có hoạt động nào trong cơ sở dữ liệu của bạn và bạn quyết
định thực hiện giao dịch sau nhằm chèn một triệu bản ghi:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);

INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

Chúng tôi đã đề cập rằng những thay đổi cơ sở dữ liệu được ghi trong các log.
Không tăng thêm sự phức tạp của việc tính toán chính xác số lượng bộ nhớ dùng
cho việc ghi log, mà ta nghĩ về điều cần minh họa. DB2 sẽ điền vào log đầu tiên
và sẽ tiếp tục với log thứ hai và sau đó là log thứ ba. Sau khi nó kết thúc với tệp
log thứ ba, không có nhiều tệp log sơ cấp hơn (được cấp phát trước), do đó DB2 sẽ
tự động cấp phát tệp log thứ cấp đầu tiên do LOGSECOND lớn hơn không. Một
khi điều này hoàn thành, DB2 sẽ tiếp tục cấp phát tệp log thứ cấp khác và sẽ lặp
lại quá trình này cho tới một giá trị lớn nhất về các tệp log LOGSECOND. Với ví
dụ này, khi DB2 cố gắng cấp phát tệp log thứ cấp thứ ba, nó sẽ trả về một lỗi cho
biết đạt tới một điều kiện giao dịch đầy đủ. Tại thời điểm này, giao dịch sẽ được
khôi phục.


Các kiểu log
Phần này định nghĩa tóm tắt các kiểu log khác nhau. Trong phần tiếp theo, bạn sẽ
thấy chúng được sử dụng như thế nào khi chúng ta nói về kiểu ghi log. Có ba kiểu
hoặc ba trạng thái của các log giao dịch DB2:
Các log hoạt động
Một log được coi là đang hoạt động nếu một trong hai điều kiện sau đây
được đáp ứng:
 Nó chứa thông tin về giao dịch chưa được cam kết hoặc đã được
khôi phục.
 Nó chứa thông tin về giao dịch đã cam kết nhưng các thay đổi của
nó vẫn chưa được viết vào đĩa cơ sở dữ liệu (đã gửi ra bên ngoài).

Các log lưu trữ trực tuyến (Online)
Chứa thông tin về các giao dịch đã cam kết và đã gửi ra bên ngoài. Các log
như vậy được lưu giữ trong cùng thư mục giống như các log đang hoạt
động.
Các log lưu trữ không trực tuyến (Offline)
Các log lưu trữ đã được dịch chuyển từ thư mục log hoạt động đến một thư
mục khác hoặc phương tiện khác. Sự dịch chuyển này có thể được DB2
thực hiện hoặc bằng tay hoặc tự động.


Các kiểu ghi log
Có hai kiểu ghi: Ghi vòng tròn và ghi lưu trữ.
Ghi vòng tròn
Ghi vòng tròn là một chế độ ghi mặc định cho DB2. Như tên của nó ngụ ý, kiểu
ghi này sử dụng lại các log theo một chế độ vòng tròn. Ví dụ, nếu bạn đã có bốn
log sơ cấp, DB2 sẽ sử dụng chúng theo thứ tự này: Log #1, Log #2, Log #3, Log
#4, Log #1, Log #2 và v.v.
Một log có thể được tái sử dụng trong việc ghi vòng tròn miễn là nó chỉ chứa
thông tin về các giao dịch đã được cam kết và đã được gửi ra ngoài vào đĩa cơ sở
dữ liệu. Nói cách khác, nếu log đó được vẫn là một log hoạt động, nó không thể
được tái sử dụng.
Khi sử dụng ví dụ ghi vòng tròn, điều gì sẽ xảy ra nếu bạn có một giao dịch dài
hạn đã kéo dài tới năm log? Trong trường hợp này, DB2 cấp phát tệp log khác
một tệp log thứ cấp, như được mô tả trong các tệp log sơ cấp và thứ cấp. Hình
dưới đây cho thấy cách làm việc này.

Ghi lưu trữ
Khi bạn sử dụng ghi lưu trữ, bạn sẽ đang lưu trữ (duy trì) các log này. Trong khi
trong ghi vòng tròn bạn sẽ ghi đè lên các giao dịch đã được cam kết và được gửi ra
ngoài, còn với ghi lưu trữ, bạn sẽ giữ lại chúng. Ví dụ, nếu bạn đã có bốn log sơ

cấp, DB2 có thể sử dụng chúng theo thứ tự này: Log #1, Log #2, Log #3, Log #4,
(lưu trữ Log #1 nếu tất cả các giao dịch của nó được cam kết và được gửi ra
ngoài), Log #5, (archive Log #2 nếu tất cả các giao dịch của nó dịch được cam kết
và được gửi ra ngoài), Log #6, và v.v.
Như trong ví dụ này, DB2 sẽ giữ bốn tệp log sơ cấp có sẵn và sẽ không sử dụng lại
các tệp log đã được lấp đầy các giao dịch đã được cam kết và được gửi ra ngoài.
Nó sẽ không ghi đè lên các log đã trở thành các log lưu trữ. Hình dưới đây minh
họa cách làm việc này.

Các kiểu log cho các cơ sở dữ liệu được xác định qua tham số cơ sở dữ liệu
LOGARCHMETH1. Khi LOGARCHMETH1 là OFF (mặc định), việc ghi tư liệu
không được phép và việc ghi vòng tròn được sử dụng.
Để kích hoạt tính năng ghi lưu trữ, LOGARCHMETH1 có thể lấy bất kỳ giá trị
sau:
LOGRETAIN Các tệp log sẽ được giữ lại trong thư mục log hoạt động.

USEREXIT
Việc lưu trữ và lấy ra các log đư
ợc thực hiện tự động bởi
một chương trình userexit do người dùng cung cấp,
chương trình này phải db2uext2. Chương trình này được
gọi để di chuyển các log lưu trữ trực tuyến vào một thư
mục khác với thư mục log hoạt động hoặc đến một
phương tiện khác. Nó cũng được gọi để lấy các log lưu
trữ không trực tuyến (offline) tới thư mục log hoạt động
khi chúng cần phép ROLLFORWARD. db2uext2 phải
được lưu trữ trong thư mục sqllib\bin trên Windows và
sqllib/adm trên UNIX.
DISK:directory_name
Cũng giống như thuật toán được sử dụng trong

USEREXIT. DB2 không gọi một chương trình userexit,
nhưng nó sẽ tự động lưu trữ các log từ thư mục log hoạt
động vào thư mục được chỉ định.
TSM:[management class
name]
Cũng giống như thuật toán được sử dụng trong
USEREXIT. Các log được lưu trữ trên máy chủ Tivoli
Storage Manger (TSM). Tham số tên của lớp quản lý là
tùy chọn. Nếu không được chỉ định, các lớp quản lý mặc
định được sử dụng.
VENDOR:library_name

Cũng giống như thuật toán được sử dụng trong
USEREXIT. Các log được lưu trữ bằng cách sử dụng th
ư
viện của nhà cung cấp chỉ định.

Vì các lý do tương thích với quá khứ, tệp cấu hình cơ sở dữ liệu vẫn còn bao gồm
các tham số LOGRETAIN và USEREXIT. Các tham số này đã được thay thế bởi
LOGARCHMETH1 kể từ phiên bản 8.2. Nếu bạn cập nhật các tham số
USEREXIT hoặc LOGRETAIN, LOGARCHMETH1 sẽ được tự động cập nhật và
ngược lại.
Ghi log vô hạn
Với việc ghi vòng tròn và ghi lưu trữ, không gian log có thể có khả năng được lấp
đầy bằng các log hoạt động. Với việc ghi log vô hạn được kích hoạt, DB2 sẽ lưu
trữ một log càng sớm càng tốt ngay khi nó bị đầy. Nó không chờ đợi tất cả các
giao dịch trong log được được cam kết và được gửi ra ngoài trước khi lưu trữ nó;
việc này đảm bảo rằng thư mục log hoạt động sẽ không bao giờ đầy. Ví dụ, nếu
bạn có một giao dịch dài hạn, bạn sẽ không chạy ra ngoài không gian log.
Việc ghi vô hạn không được khuyến cáo, tuy nhiên, vì nó có thể kéo dài thời gian

phục hồi sự cố khi các log hoạt động có thể cần được lấy ra từ trạm lưu trữ. Việc
ghi log vô hạn là một sản phẩm phụ của việc ghi log lưu trữ. Để kích hoạt tính
năng ghi log vô hạn:
1. Thiết lập tham số cấu hình cơ sở dữ liệu LOGSECOND là -1.
2. Kích hoạt tính năng ghi log lưu trữ.


Các chủ đề phục hồi khác
Các kiểu ghi log và các kiểu phục hồi
Bây giờ bạn đã hiểu các kiểu ghi log và các kiểu phục hồi khác nhau, điều quan
trọng cần lưu ý rằng không phải tất cả các kiểu ghi log hỗ trợ tất cả các kiểu phục
hồi. Việc ghi log vòng tròn chỉ hỗ trợ phục hồi sự cố (crash) và phiên bản, trong
khi việc ghi log lưu trữ hỗ trợ tất cả các loại phục hồi: sự cố, phiên bản và phục
hồi khôi phục tiếp.
Các cơ sở dữ liệu có thể phục hồi và không thể phục hồi
Các cơ sở dữ liệu có thể phục hồi là các cơ sở dữ liệu có thể được phục hồi bằng
cách sử dụng việc phục hồi sự cố, phiên bản hoặc phục hồi khôi phục tiếp; do đó,
việc ghi lưu trữ cần để được kích hoạt cho các cơ sở dữ liệu này. Các cơ sở dữ liệu
không thể phục hồi là những cơ sở dữ liệu không hỗ trợ phục hồi khôi phục tiếp;
như vậy, chỉ có việc ghi vòng tròn được sử dụng.


Xem xét lại
Cho đến nay chúng ta đã trình bày một số khái niệm về việc ghi và các log cơ sở
dữ liệu. Hình sau đây tóm tắt một số khái niệm.

Hình này cho thấy một số giao dịch đang chạy trong một khoảng thời gian. Một số
giao dịch chạy đồng thời; đầu tiên chúng bắt đầu lấp đầy các bộ đệm log và sau đó
được viết vào các tệp log trên đĩa.
MINCOMMIT là một tham số tệp cấu hình cơ sở dữ liệu.

Các nội dung của bộ đệm log sẽ được viết vào các tệp log khi bộ đệm log đầy hoặc
khi một số MINCOMMIT của các cam kết được đưa ra. Các thay đổi tới các trang
dữ liệu cho các giao dịch đã cam kết sẽ được gửi ra bên ngoài (được ghi không
đồng bộ từ vùng bộ đệm vào đĩa cơ sở dữ liệu). Vì mục đích đơn giản, trong hình
mà chúng ta chỉ ra điều này xảy ra tại thời gian cam kết, nhưng thông thường điều
này không đúng như thế
Hình lục giác với nhãn hoạt động biểu diễn số lượng tệp log thời gian X là vẫn
được coi là một log hoạt động. Như bạn thấy, hình lục giác này ở trên đỉnh của
phần biểu diễn hình vuông của giao dịch D và C trong tệp log Y. Tại sao tệp log X
vẫn được coi là đang hoạt động ngay cả sau khi nó đã lấp đầy? Bởi vì nó chứa các
giao dịch vẫn chưa được cam kết và được gửi ra ngoài. Tệp log X có chứa các giao
dịch A, B và C. Chỉ có giao dịch A và B đã được cam kết (với ví dụ này và được
gửi ra ngoài ngay lập tức); giao dịch C vẫn đang chạy và cũng được viết vào tệp
log Y. Khi giao dịch C được cam kết trong tệp log Y (với ví dụ này và được gửi ra
ngoài ngay lập tức), sau đó tệp log X sẽ không còn được coi là một log hoạt động,
nhưng sẽ trở thành một log lưu trữ trực tuyến.
Sao lưu cơ sở dữ liệu và sao lưu không gian bảng
Truy cập trực tuyến so với truy cập không trực tuyến
Nếu chúng ta đang thực hiện một thao tác trực tuyến (online) (sao lưu, phục hồi,
khôi phục tiếp), chúng ta đang cho phép những người sử dụng khác truy cập vào
đối tượng cơ sở dữ liệu mà chúng ta đang làm việc cùng một lúc.
Nếu chúng ta đang thực hiện một hoạt động không trực tuyến (offline) chúng ta
không cho phép những người sử dụng bất kỳ quyền truy cập nào vào đối tượng cơ
sở dữ liệu mà chúng ta đang làm việc tại thời điểm đó.
Chúng ta sẽ sử dụng các thuật ngữ online và offline khá thường xuyên trong phần
này.
Sao lưu cơ sở dữ liệu
Một bản sao lưu cơ sở dữ liệu là một bản sao toàn bộ cơ sở dữ liệu của bạn. Ngoài
các dữ liệu, một bản sao lưu còn chứa thông tin về các không gian bảng
(tablespace), các thùng chứa (container), cấu hình cơ sở dữ liệu, tệp kiểm soát log

và tệp lược sử phục hồi. Lưu ý rằng một bản sao lưu sẽ không lưu các tệp cấu hình
của trình quản lý cơ sở dữ liệu hoặc các biến đăng ký. Chỉ có tệp cấu hình cơ sở
dữ liệu sẽ được sao lưu.
Để thực hiện một việc sao lưu, bắt buộc phải có quyền SYSADM, SYSCTRL,
hoặc SYSMAINT
Dưới đây là cú pháp của tiện ích lệnh BACKUP cho kiểu sao lưu này:
BACKUP DATABASE database-
alias [USER username [USING
password]]
[TABLESPACE (tblspace-name [ {,tblspace-name} ])]
[ONLINE]
[INCREMENTAL [DELTA]] [USE {TSM | XBSA} [OPEN
num-sess SESSIONS]
[OPTIONS {options-string | options-filename}] | TO dir/dev
[ {,dir/dev} ] | LOAD lib-name [OPEN num-sess SESSIONS]
[OPTIONS {options-string | options-filename}]]
[WITH num-buff BUFFERS] [BUFFER buffer-size]
[PARALLELISM n]
[COMPRESS [COMPRLIB lib-name [EXCLUDE]]
[COMPROPTS options-string]]
[UTIL_IMPACT_PRIORITY [priority]] [{INCLUDE |
EXCLUDE} LOGS] [WITHOUT PROMPTING]

Hãy xem xét một số ví dụ để xem một số tùy chọn này hoạt động như thế nào.
Để thực hiện sao lưu không trực tuyến đầy đủ cơ sở dữ liệu "mẫu" và lưu trữ các
bản sao lưu vào thư mục d:\mybackups, sử dụng lệnh sau đây:
BACKUP DATABASE sample
TO d:\mybackups

Để thực hiện sao lưu không trực tuyến đầy đủ của mẫu cơ sở dữ liệu khi sử dụng

các tùy chọn sao lưu khác, bạn có thể sử dụng lệnh sau đây:
(1) BACKUP DATABASE sample
(2) TO /db2backup/dir1, /db2backup/dir2
(3) WITH 4 BUFFERS
(4) BUFFER 4096
(5) PARALLELISM 2

Hãy xem xét lệnh trên cụ thể hơn:
1. Chỉ thị ra tên (hoặc bí danh) của cơ sở dữ liệu để sao lưu.
2. Định rõ (các) vị trí ở đó bạn muốn lưu trữ bản sao lưu.
3. Cho biết có bao nhiêu bộ đệm từ bộ nhớ có thể được sử dụng trong các hoạt
động sao lưu.Việc sử dụng nhiều hơn một bộ đệm có thể cải thiện hiệu suất
4. Cho biết kích thước của mỗi bộ đệm.
5. Xác định có bao nhiêu các luồng/các quá trình ghi/ bộ đọc của phương tiện
được sử dụng để thực hiện sao lưu.
Với phiên bản 9, chúng ta đề xuất làm việc với các giá trị mặc định cho hầu hết
các tùy chọn, khi tiện ích sao lưu có thể tự xác định cái gì tốt nhất cho hiệu năng
riêng của mình.
Không có từ khóa OFFLINE trong cú pháp, vì đây là chế độ mặc định. Để thực
hiện bản sao lưu trực tuyến (online) đầy đủ của các cơ sở dữ liệu mẫu, bạn phải
chỉ rõ từ khóa ONLINE. Các việc sao lưu trữ trực tuyến yêu cầu việc ghi lưu trữ
phải được kích hoạt cho cơ sở dữ liệu. Ví dụ dưới đây cho thấy làm thế nào để đưa
ra một hoạt động sao lưu trực tuyến.
BACKUP DATABASE sample
ONLINE
TO /dev/rdir1, /dev/rdir2

Do một hoạt động sao lưu trực tuyến cho phép những người dùng truy cập vào cơ
sở dữ liệu trong khi nó đang được sao lưu, các thay đổi do những người dùng này
thực hiện sẽ không thể được lưu trữ trong bản sao lưu. Vì vậy, một hoạt động sao

lưu trực tuyến không đủ cho việc phục hồi và các log tương ứng được thu thập
trong hoạt động sao lưu này cũng cần thiết. DB2 giúp dễ dàng thu thập log hoạt
động hiện tại khi một hoạt động sao lưu kết thúc bằng cách buộc nó đóng (và được
lưu trữ) khi việc sao lưu trực tuyến kết thúc.
Để sao lưu các log như là một phần của bản sao lưu, hãy sử dụng tùy chọn
INCLUDE LOG của lệnh BACKUP DATABASE. Điều này đảm bảo rằng ngay
cả khi bạn bị mất các log của mình, bạn vẫn có thể phục hồi đến một điểm tối
thiểu cuối cùng bằng cách sử dụng các log được bao gồm trong ảnh sao lưu. Tùy
chọn INCLUDE LOG chỉ áp dụng để sao lưu trực tuyến.
Ví dụ, để thực hiện sao lưu trực tuyến của cơ sở dữ liệu mẫu cùng với các log khi
sử dụng thư mục đích /dev/rdir1, hãy đưa ra:
BACKUP DATABASE sample
ONLINE
TO /dev/rdir1 INCLUDE LOGS



Sao lưu không gian bảng
Trong một cơ sở dữ liệu ở đó chỉ một số thay đổi không gian bảng của bạn là đáng
kể, bạn có thể chọn không sao lưu toàn bộ cơ sở dữ liệu, mà chỉ sao lưu không
gian bảng cụ thể.
Để thực hiện một việc sao lưu không gian bảng, sử dụng cú pháp sau:
(1) BACKUP DATABASE sample
(2) TABLESPACE ( syscatspace, userspace1, userspace2
)
(3) ONLINE
(4) TO /db2tbsp/backup1, /db2tbsp/backup2