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

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

Sylvia Qi, Kiểm định chức năng, IBM Toronto Lab

Sylvia F. Qi làm việc tại phòng thí nghiệm Toronto của IBM trong vai trò người thử nghiệm xác minh chức năng của WebSphere Application Server (Máy chủ ứng dụng WebSphere). Trước đây, Sylvia đã làm việc trong vai trò của một kỹ sư hỗ trợ DB2 UDB Level 2 (Mức 2 của DB2 UDB) trong sáu năm. Cô có kiến thức sâu trong mọi lĩnh vực của DB2 UDB và là một nhà phát triển ứng dụng và quản trị DB2 UDB được IBM chứng nhận. Sylvia có bằng cử nhân Khoa học Máy tính của Trường Đại học McGill. Cô là một tác giả đóng góp tích cực cho developerWorks IBM. Sylvia gần đây là đồng tác giả cuốn sách Hiểu biết về DB2 - Học trực quan bằng các ví dụ



Рауль Ф. Чонг (Raul F. Chong), Chuyên gia, IBM Toronto Lab,IBM

Raul F. Chong là một người trợ giúp cộng đồng DB2 Express tại phòng thí nghiệm Toronto của IBM. Gần đây, ông nhận trách nhiệm xây dựng cộng đồng Express DB2, giúp các thành viên tương tác với nhau và đóng góp cho diễn đàn này. Raul có bằng cử nhân khoa học ngành Khoa học Máy tính của Trường Đại học Toronto và là một chuyên gia giải pháp được chứng nhận trong cả hai lĩnh vực phát triển ứng dụng và quản trị DB2. Raul đã gia nhập IBM vào năm 1997. Là một nhà tư vấn DB2 UDB, Raul đã giúp đối tác kinh doanh của IBM chuyển từ các hệ thống quản lý cơ sở dữ liệu quan hệ khác sang DB2 và các vấn đề hiệu năng của cơ sở dữ liệu và thiết kế ứng dụng. Theo một chuyên gia hỗ trợ kỹ thuật DB2, Raul đã giúp giải quyết các vấn đề DB2 trên các hệ điều hành OS/390, z/OS, Linux, UNIX và Windows. Raul cũng đã làm việc như một nhà phát triển thông tin cho nhóm Các giải pháp phát triển ứng dụng, nơi ông chịu trách nhiệm hướng dẫn CLI và tài liệu dịch vụ Web



02 10 2009

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, ROLLFORWARDRECOVER. 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: http://www-03.ibm.com/certify/tests/obj731.shtml. 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, DELETESELECT)

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.

Figure showing the interaction of the DB2 Memory, DB2 logs and a database

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
LOGPRIMARYCho biết số lượng các tệp log sơ cấp được cấp phát.
LOGSECONDCho 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 đã đượ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.

Hình ảnh về ghi lưu vòng tròn

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.

Hình ảnh về Ghi lưu trữ

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:

LOGRETAINCác tệp log sẽ được giữ lại trong thư mục log hoạt động.
USEREXITViệ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_nameCũ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_nameCũ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ố LOGRETAINUSEREXIT. 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 ảnh về nhiều giao dịch và khái niệm ghi lưu

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ữ onlineoffline 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

Dòng 2 trong ví dụ trên cho thấy rằng đây sẽ là một công việc sao lưu không gian bảng trái ngược với một việc sao lưu cơ sở dữ liệu đầy đủ. Cũng lưu ý rằng bạn có thể đặt nhiều không gian bảng trong bản sao lưu như bạn muốn. Các không gian bảng tạm thời không thể được sao lưu khi sử dụng một hoạt động sao lưu mức không gian bảng.

Điển hình là bạn thường muốn sao lưu các không gian bảng có liên quan với nhau. Ví dụ, hãy tưởng tượng bạn đang sử dụng các không gian bảng DMS, ở đó một không gian bảng được sử dụng cho các dữ liệu bảng, một không gian bảng khác cho các chỉ mục và một không gian bảng cho các LOB. Bạn nên sao lưu tất cả các không gian bảng này cùng một lúc để bạn có thông tin phù hợp. Điều này cũng đúng với các không gian bảng có chứa các bảng được định nghĩa với ràng buộc tham chiếu giữa chúng.

Các bản sao lưu tăng dần

Có hai loại các bản sao lưu tăng dần:

Tăng dần
DB2 sao lưu tất cả các dữ liệu đã thay đổi kể từ lần cuối sao lưu toàn cơ sở dữ liệu.
Gia tăng
DB2 chỉ sao lưu dữ liệu đã thay đổi kể từ sao lưu thành công cuối cùng, có nghĩa theo sự tăng lên, hay sao lưu gia tăng.

Hình ảnh sau mô tả sự khác nhau giữa các kiểu này.

Hình ảnh về sao lưu tăng dần

Trong phần trên của hình, nếu đã có một sự cố sau khi sao lưu tăng dần trong ngày thứ Sáu, bạn có thể khôi phục lại bản sao lưu đầy đủ vào Chủ nhật đầu tiên, tiếp theo bản sao lưu tăng dần đã nhận được vào ngày thứ Sáu.

Trong phần dưới của hình này, nếu đã có một sự cố sau khi sao lưu gia tăng vào ngày thứ Sáu, bạn có thể khôi phục lại bản sao lưu đầy đủ vào Chủ nhật đầu tiên bằng mỗi một trong các bản sao lưu gia tăng nhận được từ thứ Hai đến hết thứ Sáu.

Thực hiện các sao lưu với Trung tâm điều khiển

Hình bên dưới cho bạn thấy cách gọi tiện ích BACKUP từ Trung tâm điều khiển. Để thực hiện sao lưu một cơ sở dữ liệu hoặc sao lưu không gian bảng, nhấn chuột phải vào cơ sở dữ liệu bạn muốn sao lưu và chọn Backup.

Hình tiếp theo chỉ ra trình thủ thuật Backup và các tùy chọn mà bạn cần phải hoàn tất để thực hiện các tiện ích BACKUP. Chúng tôi khuyến khích bạn tự cố gắng thử nghiệm.

Quy ước đặt tên cho các tệp sao lưu

Quy ước đặt tên cho tệp sao lưu DB2 có chứa các mục sau đây:

  • Bí danh của cơ sở dữ liệu.
  • Con số cho biết kiểu sao lưu (0 cho một cơ sở dữ liệu đầy đủ, 3 cho một sao lưu không gian bảng, 4 cho một bản sao từ LOAD).
  • Tên cá thể.
  • Nút cơ sở dữ liệu (luôn luôn là NODE0000 cho một cơ sở dữ liệu phân vùng đơn).
  • Số nút danh mục (luôn luôn là CATN0000 cho một cơ sở dữ liệu phân vùng đơn).
  • Dấu thời gian của bản sao lưu.
  • Số tuần tự của file ảnh.

Hình dưới đây chỉ ra quy ước đặt tên, trong đó áp dụng cho tất cả các nền tảng.


Phục hồi cơ sở dữ liệu và phục hồi không gian bảng

Phục hồi cơ sở dữ liệu

Phần này bàn về tiện ích RESTORE, nó sử dụng một tệp sao lưu làm đầu vào và một cơ sở dữ liệu mới hoặc hiện có làm đầu ra. Mặc dù chúng ta đang thảo luận về phục hồi cơ sở dữ liệu, tiện ích mà chúng ta sẽ sử dụng được gọi là RESTORE (khôi phục lại), không phải là RECOVER (phục hồi).

Bắt buộc phải có quyền SYSADM, SYSCTRL hoặc SYSMAINT để khôi phục lại một cơ sở dữ liệu hiện có. Quyền SYSADM hoặc SYSCTRL là bắt buộc để khôi phục lại một cơ sở dữ liệu mới.

Đây là cú pháp của lệnh RESTORE:

RESTORE DATABASE source-database-alias { restore-options | CONTINUE | ABORT }
restore-options:
[USER username [USING password]]
[REBUILD WITH [ALL TABLESPACES IN DATABASE | ALL TABLESPACES IN IMAGE]
   [EXCEPT rebuild-tablespace-clause] [rebuild-tablespace-clause]
[{TABLESPACE [ONLINE] | TABLESPACE (tblspace-name [ {,tblspace-name} .. ]) [ONLINE] |
HISTORY FILE [ONLINE]}] [INCREMENTAL [AUTOMATIC | ABORT]]
[{USE {TSM | XBSA} [OPEN num-sess SESSIONS] |
FROM dir/dev [ {,dir/dev} ... ] | LOAD shared-lib
[OPEN num-sess SESSIONS]}] [TAKEN AT date-time] [TO target-directory]
[INTO target-database-alias] [NEWLOGPATH directory] [LOGS FROM directory] 
   [LOGTARGET directory]
[WITH num-buff BUFFERS] [BUFFER buffer-size]
[DLREPORT file-name] [REPLACE EXISTING] [REDIRECT] [PARALLELISM n]
[WITHOUT ROLLING FORWARD] [WITHOUT DATALINK] [WITHOUT PROMPTING]
Rebuild-tablespace-clause:
[TABLESPACE (tblspace-name [ {,tblspace-name} ... ])

Hãy xem xét một ví dụ. Để thực hiện việc khôi phục lại cơ sở dữ liệu thí dụ, sử dụng lệnh sau đây:

(1)RESTORE DATABASE sample
(2)  FROM  C:\DBBACKUP
(3)  TAKEN AT 20060314131259
(4)  WITHOUT ROLLING FORWARD
(5)  WITHOUT PROMPTING

Trong ví dụ trên,

  1. Cho biết tên tệp ảnh của cơ sở dữ liệu để khôi phục lại.
  2. Xác định vị trí mà từ đó tệp sao lưu đầu vào được đọc.
  3. Nếu có nhiều hình ảnh sao lưu trong thư mục, tùy chọn này sẽ xác định bản sao lưu cụ thể dựa vào dấu thời gian, dấu này là một phần của tên bản sao lưu.
  4. Nếu một cơ sở dữ liệu đã có việc ghi lưu trữ được kích hoạt, nó được tự động đặt trong trạng thái chờ khôi phục tiếp khi nó được khôi phục lại. Dòng này cho DB2 biết không đặt cơ sở dữ liệu trong trạng thái chờ khôi phục tiếp.
  5. Bạn sẽ không được thông báo trong khi RESTORE đang được thực hiện.

Lưu ý không có từ khóa OFFLINE trong cú pháp, vì đây là chế độ mặc định. Đối với tiện ích RESTORE, đây là chế độ duy nhất được phép cho các cơ sở dữ liệu.

Nếu các log có trong hình ảnh sao lưu, bạn có thể khôi phục lại các tệp log khi sử dùng tùy chọn LOGTARGET của lệnh RESTORE DATABASE.

Để khôi phục lại cơ sở dữ liệu SAMPLE từ một hình ảnh sao lưu đặt tại thư mục C:\DBBACKUP và khôi phục lại các tệp log vào thư mục C:\DB2\NODE0000\SQL00001\SQLOGDIR, đưa ra:

RESTORE DATABASE sample	
FROM C:\DBBACKUP
LOGTARGET C:\DB2\NODE0000\SQL00001\SQLOGDIR

Bạn cũng có thể khôi phục lại chỉ các tệp log mà không cần khôi phục lại cơ sở dữ liệu bằng cách sử dụng từ khóa LOGS:

RESTORE DATABASE sample 
LOGS FROM C:\DBBACKUP
LOGTARGET C:\DB2\NODE0000\SQL00001\SQLOGDIR

Phục hồi không gian bảng

Bạn có thể khôi phục lại không gian bảng hoặc từ một bản sao lưu cơ sở dữ liệu đầy đủ hoặc từ một bản sao lưu không gian bảng. Việc phục hồi không gian bảng cần một số kế hoạch cẩn thận, vì rất dễ sinh lỗi, làm dữ liệu của bạn đặt trong trạng thái không phù hợp.

Dưới đây là một ví dụ về một lệnh RESTORE không gian bảng:

(1)  RESTORE DATABASE sample 
(2)  TABLESPACE ( mytblspace1 ) 
(3)  ONLINE
(4)  FROM /db2tbsp/backup1, /db2tbsp/backup2

Trong ví dụ trên,

  1. Cho biết tên ảnh cơ sở dữ liệu để khôi phục lại.
  2. Chỉ ra rằng đây là một không gian bảng RESTORE và xác định tên của (các) không gian bảng để khôi phục lại.
  3. Chỉ ra rằng đây là một sự khôi phục lại trực tuyến. Đối với các không gian bảng của người sử dụng, cả việc khôi phục lại trực tuyến và không trực tuyến đều được phép. Như đã đề cập trước, đối với cơ sở dữ liệu, chỉ được phép khôi phục lại không trực tuyến.
  4. Xác định vị trí lưu tệp sao lưu đầu vào.

Các lý do cân nhắc phục hồi không gian bảng

Sau khi một không gian bảng được khôi phục lại, nó sẽ luôn luôn được đặt trong trạng thái chờ khôi phục tiếp. Để tạo ra một không gian bảng có thể truy cập được và đặt lại trạng thái này, không gian bảng phải được khôi phục ít ra là cho đến thời điểm khôi phục tiếp tối thiểu. Điểm tối thiểu này đảm bảo rằng không gian bảng và các log là phù hợp với thông tin trong danh mục của hệ thống.

Hãy xem xét ví dụ này:

  1. Hãy tưởng tượng rằng tại thời điểm t1 bạn đã nhận được một bản sao lưu cơ sở dữ liệu đầy đủ, trong đó bao gồm không gian bảng mytbls1.
  2. Vào thời điểm t2, bạn đã tạo bảng có tên myTable trong không gian bảng mytbls1. Điều này sẽ thiết lập thời điểm tối thiểu để phục hồi không gian bảng mytbs1 đến t2.
  3. Vào thời điểm t3, bạn đã quyết định khôi phục lại chỉ không gian bảng mytbls1 từ bản sao lưu cơ sở dữ liệu đầy đủ nhận được tại t1.
  4. Sau khi khôi phục lại xong, không gian bảng mytbls1 sẽ được đặt trong trạng thái chờ khôi phục tiếp. Nếu bạn đã được phép khôi phục tiếp tới thời điểm trước thời điểm tối thiểu cuối cùng, không gian bảng mytbls1 sẽ không có bảng myTable; tuy nhiên, danh mục hệ thống sẽ cho biết bảng này tồn tại trong mytbls1. Để tránh mâu thuẫn như thế, DB2 sẽ buộc bạn phải khôi phục tiếp ít nhất là đến thời điểm tối thiểu cuối cùng khi bạn khôi phục lại một không gian bảng.

Một điểm tối thiểu cuối cùng được cập nhật khi các câu lệnh DDL được chạy trên không gian bảng, hoặc trên các bảng trong không gian bảng này. Để xác định điểm tối thiểu cuối cùng để phục hồi cho một không gian bảng, bạn có thể sử dụng một trong hai phương pháp sau đây:

  • Sử dụng lệnh LIST TABLESPACES SHOW DETAIL.
  • Lấy bản chụp không gian bảng bằng lệnh GET SNAPSHOT FOR TABLESPACE ON db_name.

Không gian bảng danh mục hệ thống (SYSCATSPACE) cũng phải được khôi phục tiếp đến cuối các log và theo chế độ không trực tuyến. Chúng ta sẽ thảo luận thêm về lệnh ROLLFORWARD trong Khôi phục tiếp cơ sở dữ liệu và không gian bảng.

Thực hiện các hoạt động khôi phục lại bằng Trung tâm điều khiển

Hình bên dưới cho bạn thấy làm thế nào để gọi tiện ích RESTORE từ Trung tâm điều khiển. Để thực hiện một hoạt động khôi phục lại cơ sở dữ liệu hoặc không gian bảng, nhấn chuột phải vào cơ sở dữ liệu mà bạn muốn khôi phục lại và chọn Restore. Chúng tôi khuyến khích bạn tự thực hiện việc này.

Hình tiếp theo cho thấy một số tùy chọn mà bạn cần phải hoàn tất để thực thi tiện ích RESTORE. Chúng tôi khuyến khích bạn tự thực hiện việc này.

Khôi phục lại tăng dần

Nhớ lại rằng một bản sao lưu tăng dần là một ảnh sao lưu chỉ chứa các trang đã được cập nhật từ bản sao lưu trước. Để thực hiện việc khôi phục lại bằng cách sử dụng các bản sao lưu tăng dần, chỉ rõ tùy chọn INCREMENTAL trên lệnh RESTORE DATBASE. Thông thường một việc khôi phục lại tăng dần liên quan đến một loạt các hoạt động khôi phục lại. Mỗi ảnh sao lưu tham gia vào việc khôi phục lại phải được khôi phục lại theo thứ tự sau: cuối cùng, đầu tiên, thứ hai, thứ ba và tiếp tục như vậy lên nữa và bao gồm cả ảnh cuối cùng.

Hãy xem xét một ví dụ. Sau đây là một chiến lược sao lưu tăng dần thí dụ theo tuần cho một cơ sở dữ liệu phục hồi MYDB. Nó bao gồm một hoạt động sao lưu cơ sở dữ liệu đầy đủ hàng tuần, một hoạt động sao lưu (gia tăng) không tích lũy hàng ngày và một hoạt động sao lưu (tăng dần) tích lũy giữa tuần:

1. (Sun) backup db mydb use tsm
2. (Mon) backup db mydb online incremental delta use tsm
3. (Tue) backup db mydb online incremental delta use tsm
4. (Wed) backup db mydb online incremental use tsm
5. (Thu) backup db mydb online incremental delta use tsm
6. (Fri) backup db mydb online incremental delta use tsm
7. (Sat) backup db mydb online incremental use tsm

Để khôi phục lại cơ sở dữ liệu bằng cách sử dụng sao lưu tăng dần được tạo ra vào thứ Sáu, chúng ta cần phải đưa ra một loạt các lệnh RESTORE DATABASE để khôi phục lại từng ảnh sao lưu cần thiết, theo thứ tự này:

1. restore db mydb incremental taken at (Fri)
2. restore db mydb incremental taken at (Sun)
3. restore db mydb incremental taken at (Wed)
4. restore db mydb incremental taken at (Thu)
5. restore db mydb incremental taken at (Fri)

Như bạn thấy, quá trình này là rất dài và cũng dễ bị lỗi. Bạn cần phải biết những ảnh nào cần khôi phục lại và chúng phải được khôi phục lại theo thứ tự nào. Để làm cho quá trình này dễ dàng hơn, sử dụng tiện ích khôi phục lại tăng dần một cách tự động. Để thực hiện một việc khôi phục lại tăng dần tự động, tất cả những thứ mà bạn cần làm là xác định các ảnh sao lưu gần nhất mà bạn muốn khôi phục lại và bạn đưa ra chỉ có một lệnh RESTORE DATABASE cho nó, với tùy chọn INCREMENTAL AUTOMATIC. Tiện ích khôi phục lại sẽ giữ nguyên phần còn lại.

Tất cả các các lệnh khôi phục lại thủ công ở trên có thể được thay thế bằng một lệnh khôi phục lại tăng dần tự động:

restore db mydb incremental automatic taken at (Fri)

Khôi phục lại chuyển hướng

Chúng tôi đã đề cập trước đó rằng một tệp sao lưu bao gồm các thông tin về các không gian bảng và vùng chứa. Điều gì sẽ xảy ra nếu một thùng chứa được sử dụng để tồn tại khi bản sao lưu đã nhận được không còn tồn tại nữa? Nếu tiện ích RESTORE không thể tìm thấy thùng chứa này, bạn sẽ mắc phải một lỗi.

Bạn làm gì nếu không muốn khôi phục lại bản sao lưu tại vị trí này, nhưng ở một nơi khác, nơi các cấu hình khác được sử dụng? Một lần nữa, việc khôi phục lại bản sao lưu trong kịch bản này sẽ gây ra vấn đề.

Việc khôi phục lại chuyển hướng giải quyết các vấn đề này. Một việc khôi phục lại chuyển hướng chỉ khôi phục lại bản sao lưu theo bốn bước. Nó sẽ:

  1. Lấy thông tin về các thùng chứa và các không gian bảng được ghi trong bản sao lưu đầu vào. Điều này được thực hiện bằng cách lấy từ khóa REDIRECT như là một phần của lệnh RESTORE. Ví dụ:
    RESTORE DATABASE DB2CERT FROM C:\DBBACKUP
         INTO NEWDB REDIRECT WITHOUT ROLLING FORWARD

    Và đây là kết quả đầu ra từ các lệnh này:

    SQL1277W  A redirected restore operation is being performed.  Table space
    configuration can now be viewed and table spaces that do not use automatic
    storage can have their containers reconfigured.
    DB20000I  The RESTORE DATABASE command completed successfully.
  2. Xem lại thông tin về không gian bảng từ cơ sở dữ liệu được khôi phục lại (một phần) newdb:
    LIST TABLESPACES SHOW DETAIL
  3. Thiết lập các thùng chứa mới cho mỗi không gian bảng. Một không gian bảng có một mã nhận dạng ID, mã này có thể nhận được từ đầu ra của lệnh LIST TABLESPACES. Mã nhận dạng ID này được sử dụng như sau:
    SET TABLESPACE CONTAINERS FOR 0 USING (FILE "d:\newdb\cat0.dat" 5000)
    SET TABLESPACE CONTAINERS FOR 1 USING (FILE "d:\newdb\cat1.dat" 5000)
    ...
    SET TABLESPACE CONTAINERS FOR n USING (PATH "d:\newdb2")

    ở đây n biểu diễn một ID của một trong các không gian bảng trong bản sao lưu. Lưu ý rằng với các việc khôi phục lại chuyển hướng, bạn không thể thay đổi kiểu không gian bảng đó; nếu không gian bảng là SMS, không được thay đổi nó thành DMS.

  4. . Bắt đầu tự khôi phục lại dữ liệu vào trong thùng chứa mới bằng cách dùng từ khóa CONTINUE, như hình dưới đây:
    RESTORE DATABASE DB2CERT CONTINUE

Bây giờ bạn nhìn thấy một việc khôi phục lại chuyển hướng hoạt động như thế nào. Nó cũng có thể được dùng để thêm vào các thùng chứa cho không gian bảng SMS. Nếu bạn xem lại hướng dẫn thứ hai của loạt bài này (xem Tài nguyên), bạn sẽ thấy rằng trong nhiều trường hợp không gian bảng SMS không thể bị thay đổi để thêm một thùng chứa. Một việc khôi phục lại chuyển hướng cung cấp một cách giải quyết khác cho hạn chế này.

Thay vì thực hiện bốn bước trên bằng tay, tiện ích khôi phục lại chuyển hướng cho phép bạn tạo một kịch bản khôi phục lại chuyển hướng bằng cách ban hành lệnh RESTORE với các tùy chọn REDIRECTGENERATE SCRIPT. Khi tùy chọn GENERATE SCRIPT được sử dụng, tiện ích khôi phục lại trích ra thông tin thùng chứa từ ảnh sao lưu và tạo ra một kịch bản CLP bao gồm tất cả các thông tin thùng chứa chi tiết. Sau đó bạn có thể sửa đổi bất kỳ các đường dẫn hoặc kích thước thùng chứa nào trong kịch bản lệnh và chạy kịch bản lệnh CLP để tái tạo lại cơ sở dữ liệu với bộ các thùng chứa mới.

Ví dụ, để thực hiện một hoạt động khôi phục lại chuyển hướng của cơ sở dữ liệu DB2CERT khi sử dụng một kịch bản lệnh, hãy làm theo các bước sau:

  1. Sử dụng các tiện ích khôi phục lại để tạo ra một kịch bản lệnh khôi phục lại chuyển hướng.
    RESTORE DATABASE DB2CERT FROM C:\DBBACKUP INTO NEWDB REDIRECT GENERATE SCRIPT 
       NEWDB.CLP WITHOUT ROLLING FORWARD

    Điều này tạo ra một kịch bản lệnh khôi phục lại chuyển hướng được gọi là target-database-alias.clp. Trong trường hợp này là, newdb.clp.

    newdb.clp có tất cả các lệnh cần thiết để thực hiện một hoạt động khôi phục lại chuyển hướng. Nó cũng chứa tất cả thông tin không gian bảng. Kịch bản lệnh newdb.clp được hiển thị dưới đây.

    -- *****************************************************************************
    -- ** automatically created redirect restore script
    -- *****************************************************************************
    UPDATE COMMAND OPTIONS USING S ON Z ON NEWDB_NODE0000.out V ON;
    SET CLIENT ATTACH_DBPARTITIONNUM  0;
    SET CLIENT CONNECT_DBPARTITIONNUM 0;
    -- *****************************************************************************
    -- ** automatically created redirect restore script
    -- *****************************************************************************
    RESTORE DATABASE DB2CERT
    -- USER  username
    -- USING 'password'
    FROM 'C:\dbbackup' TAKEN AT 20060516120102
    -- ON 'D:'
    -- DBPATH ON 'target-directory'
    INTO NEWDB
    -- NEWLOGPATH 'D:\DB2\NODE0000\SQL00001\SQLOGDIR\'
    -- WITH num-buff BUFFERS
    -- BUFFER buffer-size
    -- REPLACE HISTORY FILE
    -- REPLACE EXISTING REDIRECT
    -- PARALLELISM n WITHOUT ROLLING FORWARD
    -- WITHOUT PROMPTING
    ;
    -- *****************************************************************************
    -- ** table space definition
    -- *****************************************************************************
    -- *****************************************************************************
    -- ** Tablespace name                            = SYSCATSPACE
    -- **   Tablespace ID                            = 0
    -- **   Tablespace Type                          = Database managed space
    -- **   Tablespace Content Type                  = All permanent data. Regular table
                                                                   space.
    -- **   Tablespace Page size (bytes)             = 4096
    -- **   Tablespace Extent size (pages)           = 4
    -- **   Using automatic storage                  = Yes
    -- **   Auto-resize enabled                      = Yes
    -- **   Total number of pages                    = 16384
    -- **   Number of usable pages                   = 16380
    -- **   High water mark (pages)                  = 8872
    -- *****************************************************************************
    -- *****************************************************************************
    -- ** Tablespace name                            = TEMPSPACE1
    -- **   Tablespace ID                            = 1
    -- **   Tablespace Type                          = System managed space
    -- **   Tablespace Content Type                  = System Temporary data
    -- **   Tablespace Page size (bytes)             = 4096
    -- **   Tablespace Extent size (pages)           = 32
    -- **   Using automatic storage                  = Yes
    -- **   Total number of pages                    = 1
    -- *****************************************************************************
    -- *****************************************************************************
    -- ** Tablespace name                            = USERSPACE1
    -- **   Tablespace ID                            = 2
    -- **   Tablespace Type                          = Database managed space
    -- **   Tablespace Content Type                  = All permanent data. Large table
                                                                   space.
    -- **   Tablespace Page size (bytes)             = 4096
    -- **   Tablespace Extent size (pages)           = 32 
    -- **   Using automatic storage                  = Yes
    -- **   Auto-resize enabled                      = Yes
    -- **   Total number of pages                    = 8192
    -- **   Number of usable pages                   = 8160
    -- **   High water mark (pages)                  = 1888
    -- *****************************************************************************
    -- *****************************************************************************
    -- ** Tablespace name                            = TBS1
    -- **   Tablespace ID                            = 5
    -- **   Tablespace Type                          = Database managed space
    -- **   Tablespace Content Type                  = All permanent data. Large table
                                                                   space.
    -- **   Tablespace Page size (bytes)             = 4096
    -- **   Tablespace Extent size (pages)           = 32
    -- **   Using automatic storage                  = No
    -- **   Auto-resize enabled                      = No
    -- **   Total number of pages                    = 1000
    -- **   Number of usable pages                   = 960
    -- **   High water mark (pages)                  = 96
    -- *****************************************************************************
    SET TABLESPACE CONTAINERS FOR 5
    -- IGNORE ROLLFORWARD CONTAINER OPERATIONS
    USING (
    FILE   'd:\DB2\DB2CERT\tbs1'      1000
    );
    -- ***************************************************************************** 
    -- ** start redirected restore
    -- ***************************************************************************** 
    RESTORE DATABASE NEWDB CONTINUE;
    -- *****************************************************************************
    -- ** end of file
    -- *****************************************************************************

    Dấu '--' cho biết đoạn chú thích. Lệnh SET TABLESPACE CONTAINER chỉ được tạo ra cho các không gian bảng không được thiết lập để sử dụng lưu trữ tự động. Đối với các không gian bảng đang sử dụng lưu trữ tự động, các thùng chứa của chúng được DB2 xử lý tự động, do đó không cần phải thiết lập lại chúng.

  2. Mở kịch bản lệnh khôi phục lại chuyển hướng trong một trình soạn thảo văn bản để thực hiện bất kỳ các sửa đổi nào cần thiết. Bạn có thể sửa đổi
    • Khôi phục lại các tùy chọn.
    • Bố trí và các đường dẫn của thùng chứa.
  3. Chạy kịch bản lệnh khôi phục lại chuyển hướng đã sửa đổi.
    db2 -tvf newdb.clp

    Kết quả đầu ra của kịch bản này sẽ được viết vào một tệp gọi là databasename_nodenumber.out.


Khôi phục tiếp cơ sở dữ liệu và không gian bảng

Khôi phục tiếp cơ sở dữ liệu

Lệnh ROLLFORWARD cho phép phục hồi điểm cuối cùng, nghĩa là lệnh này sẽ cho phép bạn đi qua các log DB2 và thực hiện lại hoặc không thực hiện các hoạt động ghi trong log cho tới một thời điểm xác định. Mặc dù bạn có thể khôi phục tiếp cơ sở dữ liệu hoặc không gian bảng của bạn đến bất kỳ thời điểm nào sau thời điểm tối thiểu, không có sự bảo đảm nào rằng thời gian kết thúc mà bạn chọn để khôi phục tiếp sẽ có tất cả các dữ liệu với trạng thái thích hợp.

Mặc dù lệnh QUIESCE không được thảo luận trong hướng dẫn này, nó xứng đáng được nhận xét rằng lệnh này có thể được sử dụng trong các phép cơ sở dữ liệu thường xuyên để thiết lập các điểm bền vững. Bằng cách thiết lập các điểm bền vững, bạn luôn có thể thực hiện một điểm phục hồi cho bất kỳ điểm nào trong số chúng và được bảo đảm rằng dữ liệu của bạn được đồng bộ.

Điểm bền vững, cùng với rất nhiều thông tin khác, được ghi trong tệp lược sử DB2, nó có thể được xem lại bằng lệnh LIST HISTORY.

Trong quá trình xử lý khôi phục tiếp, DB2 sẽ:

  1. Tìm tệp log cần thiết trong đường dẫn log hiện tại.
  2. Yêu cầu làm các giao dịch từ tệp log nếu log này được tìm thấy.
  3. Tìm kiếm trong đường dẫn đã chỉ ra bằng tùy chọn OVERFLOW LOG PATH và sử dụng các log ở vị trí đó nếu tệp log không tìm thấy trong đường dẫn log hiện tại.
  4. Sử dụng phương pháp xác định trong LOGARCHMETH1 để lấy ra tệp log từ đường dẫn lưu trữ nếu tệp log không tìm thấy trong đường dẫn hiện hành và tùy chọn OVERFLOW LOG PATH không được sử dụng.
  5. Yêu cầu làm lại các giao dịch, một khi log nằm trên đường dẫn log hiện tại hoặc OVERFLOW LOG PATH.

Bắt buộc phải có quyền SYSADM, SYSCTRL hoặc SYSMAINT để thực hiện lệnh ROLLFORWARD.

Cú pháp của lệnh ROLLFORWARD là:

ROLLFORWARD DATABASE database-alias [USER username [USING password]]
[TO {isotime [ON ALL DBPARTITIONNUMS] [USING LOCAL TIME | USING UTC TIME] |
END OF LOGS [On-DbPartitionNum-Clause]}] [AND {COMPLETE | STOP}] |
{COMPLETE | STOP | CANCEL | QUERY STATUS [USING LOCAL TIME | USING UTC TIME]}
[On-DbPartitionNum-Clause] [TABLESPACE ONLINE | TABLESPACE (tblspace-name
[ {,tblspace-name} ... ]) [ONLINE]] [OVERFLOW LOG PATH (log-directory
[{,log-directory ON DBPARTITIONNUM db-partition-number} ... ])] [NORETRIEVE]
[RECOVER DROPPED TABLE dropped-table-id TO export-directory]

On-DbPartitionNum-Clause:
  ON {{DBPARTITIONNUM | DBPARTITIONNUMS} (db-partition-number
  [TO  db-partition-number] , ... ) | ALL DBPARTITIONNUMS [EXCEPT
  {DBPARTITIONNUM | DBPARTITIONNUMS} (db-partition-number
  [TO db-partition-number] , ...)]}

Hãy xem xét một ví dụ. Để thực hiện một khôi phục tiếp của cơ sở dữ liệu mẫu, bạn có thể sử dụng bất kỳ một trong các câu lệnh sau đây:

(1)ROLLFORWARD DATABASE sample TO END OF LOGS AND COMPLETE
(2)ROLLFORWARD DATABASE sample TO timestamp AND COMPLETE
(3)ROLLFORWARD DATABASE sample TO timestamp USING LOCAL TIME AND COMPLETE

Từ đoạn mã trên:

  1. Trong ví dụ này, chúng ta sẽ khôi phục tiếp đến cuối của các log, nó có nghĩa là tất cả các log lưu trữ và hoạt động sẽ được chuyển dịch. Đến cuối, nó sẽ hoàn thành khôi phục tiếp và loại bỏ trạng thái chờ khôi phục tiếp bằng cách phục hồi bất kỳ giao dịch nào chưa được cam kết.
  2. Với ví dụ này, DB2 sẽ khôi phục tiếp đến thời điểm quy định. Các dấu thời gian được sử dụng phải nằm trong CUT (Coordinated Universal Time – Thời gian tham chiếu chung), mà có thể được tính bằng cách trừ đi thời gian địa phương từ múi giờ hiện tại.
  3. Ví dụ này cũng tương tự như ví dụ trước đó, nhưng dấu thời gian có thể được biểu thị theo thời gian địa phương.

Không có từ khóa OFFLINE trong cú pháp, vì đây là chế độ mặc định. Đối với lệnh ROLLFORWARD, đây là chế độ duy nhất được phép cho các cơ sở dữ liệu.

Khôi phục tiếp không gian bảng

Khôi phục tiếp không gian bảng thường có thể hoặc là trực tuyến hoặc không trực tuyến. Trường hợp ngoại lệ là không gian bảng danh mục hệ thống (SYSCATSPACE), nó có thể chỉ được khôi phục tiếp không trực tuyến.

Dưới đây là một ví dụ khôi phục tiếp không gian bảng:

ROLLFORWARD DATABASE sample 
  TO END OF LOGS AND COMPLETE
  TABLESPACE ( userspace1 ) ONLINE

Các tùy chọn trong ví dụ này đã được giải thích trong phần khôi phục tiếp cơ sở dữ liệu. Thứ mới duy nhất ở đây là tùy chọn TABLESPACE, nó chỉ rõ không gian bảng được khôi phục tiếp.

Các lý do cân nhắc khôi phục tiếp không gian bảng

Nếu biến đăng ký DB2_COLLECT_TS_REC_INFO được kích hoạt, chỉ có các tệp log cần thiết để phục hồi không gian bảng được xử lý. Lệnh ROLLFORWARD sẽ bỏ qua các tệp log không bắt buộc, để có thể tăng tốc độ thời gian phục hồi.

Tùy chọn QUERY STATUS của lệnh ROLLFORWARD có thể được sử dụng để liệt kê:

  • Các tệp log mà DB2 đã được khôi phục tiếp.
  • Tệp log lưu trữ tiếp theo cần có.
  • Dấu thời gian của giao dịch đã cam kết cuối cùng kể từ khi việc xử lý khôi phục tiếp đã bắt đầu.

Ví dụ:

ROLLFORWARD DATABASE sample QUERY STATUS USING LOCAL TIME

Sau khi một điểm không gian bảng trong phép khôi phục tiếp cuối cùng hoàn thành, không gian bảng được đưa vào trạng thái chờ sao lưu. Cần có bản bản sao lưu của không gian bảng hoặc cơ sở dữ liệu bởi vì tất cả các bản cập nhật được thực hiện cho nó giữa điểm cuối cùng có không gian bảng đã được phục hồi đến và thời gian hiện tại đã bị mất.

Thực hiện các hoạt động khôi phục tiếp với Trung tâm điều khiển

Hình dưới đây cho thấy cách gọi lệnh ROLLFORWARD từ Trung tâm điều khiển. Để thực hiện một khôi phục tiếp cơ sở dữ liệu hoặc không gian bảng, nhấn chuột phải vào cơ sở dữ liệu mà bạn muốn khôi phục tiếp và chọn Roll-forward. Chúng tôi khuyến khích bạn tự làm việc này.

Thực hiện ROLLFORWARD từ Trung tâm điều khiển #1

Hình sau đây cho thấy một số tùy chọn mà bạn cần phải hoàn tất để thực hiện lệnh ROLLFORWARD. Chúng tôi khuyến khích bạn tự làm việc này.

Xem xét lại và các ví dụ

Cho đến nay chúng ta đã thảo luận các lệnh BACKUP, RESTOREROLLFORWARD. Hình dưới đây minh họa các kiểu phục hồi khác nhau mà bây giờ bạn cần hiểu.

Đối với kịch bản này, việc ghi log vòng tròn có hiệu lực:

Tại t6 có một sự cố tắt điện đột xuất trong nhà của bạn. Tại t7, DB2 là khởi động lại và khi bạn kết nối vào cơ sở dữ liệu, việc phục hồi sự cố bắt đầu tự động (giả sử db cfg AUTORESTART là ON; nếu không bạn phải khởi động nó thủ công bằng một lệnh RESTART DATABASE. Việc phục hồi sự cố sẽ chuyển sang các log đang hoạt động và sẽ thực hiện lại các giao dịch đã cam kết. Nếu một giao dịch chưa được cam kết, nó sẽ được phục hồi (không thực hiện). Với ví dụ này, hai câu lệnh chèn vào sẽ được thực hiện lại và câu lệnh xoá sẽ không được thực hiện.

Đối với kịch bản này, việc ghi log vòng tròn có hiệu lực:

Tại t7 bạn thấy rõ dữ liệu của bạn trong tất cả các không gian bảng đã bị hỏng do một số giao dịch đã bắt đầu tại t6. Tại t8 bạn quyết định khôi phục lại từ bản sao lưu cơ sở dữ liệu đầy đủ ở thời điểm t1. Bởi vì việc ghi log vòng tròn có hiệu lực, nhiều giao dịch trong số các giao dịch đã cam kết và đã được gửi ra ngoài trong các log đã bị ghi đè. Vì vậy, các log không thể được áp dụng (lệnh ROLLFORWARD không thể chạy trong chế độ ghi log vòng tròn, do đó bạn không thể thậm chí khôi phục tiếp các log đang hoạt động). Kết luận: Rất nhiều trong số các giao dịch tốt ở t2 đến t4 sẽ bị mất.

Đối với kịch bản này, việc ghi log lưu trữ có hiệu lực:

Đây là một phần mở rộng của các kịch bản trước đó. Trong trường hợp này, các log đã được lưu giữ (các log lưu trữ ); sau khi việc khôi phục lại cơ sở dữ liệu đầy đủ được áp dụng tại t8, bạn có thể khôi phục tiếp log tại t9. Các log có thể được khôi phục tiếp từ t1 đến bất kỳ điểm cuối cùng nào, nhưng có thể là bạn không muốn đi qua t6, khi đã bắt đầu một giao dịch hỏng.

Kịch bản sau đây xem xét tất cả các khái niệm này chi tiết hơn.

Review of Backup, Restore and Rollforward

  1. Một bản sao lưu cơ sở dữ liệu không trực tuyến kết thúc tại t1.
  2. Các giao dịch hàng ngày được thực hiện tại t2.
  3. Tại t4 bạn nhận ra một trong số các các giao dịch đã làm hỏng không gian bảng Z và bạn ngừng giao dịch này. Các giao dịch khác với các không gian bảng khác vẫn tiếp tục.
  4. Chỉ đối với không gian bảng Z, bạn muốn các dữ liệu ở trạng thái mà nó đã có trước t3 (trước khi bắt đầu giao dịch xấu), như vậy:
    • Tại t5, bạn khôi phục lại không gian bảng Z từ bản sao lưu không trực tuyến đầy đủ đã nhận được tại t1.
    • Sau khi hoàn thành việc khôi phục lại, không gian bảng sẽ lại ở trạng thái chờ khôi phục tiếp.
    • Tại t6 bạn khôi phục tiếp không gian bảng lên đến t3, trước khi bắt đầu giao dịch xấu.
    • Bạn vừa mới thực hiện khôi phục tại một thời điểm đúng. Vì điều này, nên DB2 bây giờ sẽ đặt không gian bảng ở trạng thái chờ sao lưu vì lý do bền vững.
    • Tại t7 bạn sao lưu không gian bảng. Tại thời điểm này, cơ sở dữ liệu của bạn phù hợp và tất cả những người dùng và các ứng dụng có thể làm việc bình thường. Không gian bảng được khôi phục lại sẽ có một khoảng từ t3 đến t7, đó là tất cả những gì mà chúng ta dự định -- để loại bỏ các dữ liệu bị lỗi.

Tiện ích cơ sở dữ liệu phục hồi

Tiện ích cơ sở dữ liệu phục hồi kết hợp với tiện ích RESTORE và tiện ích ROLLFORWARD trong lệnh dễ sử dụng. Nó thực hiện các hoạt động khôi phục lại và khôi phục tiếp cần thiết để phục hồi một cơ sở dữ liệu theo một thời gian xác định, dựa trên thông tin được tìm thấy trong tệp lược sử phục hồi. Nó tự động chọn ảnh sao lưu phù hợp nhất để thực hiện các phép phục hồi.

Cú pháp của lệnh RECOVER DATABASE là:

RECOVER DATABASE source-database-alias TO isotime [USING LOCAL TIME]
[USER username [USING password] 
[USING HISTORY FILE history-file]
[OVERFLOW LOG PATH directory]
[RESTART]

Các ví dụ

Một cơ sở dữ liệu SAMPLE hiện tồn tại trên máy chủ phát triển của bạn. Một sự cố mất điện đêm qua đã làm hư hỏng cơ sở dữ liệu do sửa đổi sai dữ liệu. Bạn cần phải phục hồi cơ sở dữ liệu càng sớm càng tốt. Bạn có thể làm điều này bằng cách đầu tiên định vị bản sao lưu thích hợp, sau đó định vị các log DB2 cần thiết để khôi phục tiếp đến một điểm cuối cùng chỉ trước khi mất điện. Một cách dễ dàng hơn để phục hồi cơ sở dữ liệu SAMPLE là đưa ra lệnh RECOVER DB, như sau:

(1) RECOVER DB sample
(2) RECOVER DB sample TO 2006-05-21-13.50.00 USING LOCAL TIME

Trong dòng 1 ở trên, DB2 phục hồi cơ sở dữ liệu SAMPLE từ ảnh sao lưu sẵn có tốt nhất và sẽ khôi phục tiếp đến cuối các log.

Trong dòng 2, DB2 phục hồi cơ sở dữ liệu SAMPLE đến một điểm cuối cùng, 2006-05-21-13.50.00, chỉ rõ thời gian địa phương.

Nhớ lại rằng tiện ích RECOVER DATABASE dựa vào tệp lược sử phục hồi cơ sở dữ liệu để tìm ảnh sao lưu phù hợp nhất để khôi phục lại. Chúng ta đã không định rõ vị trí của tệp lược sử trong các lệnh phục hồi của chúng ta ở trên. Bởi vì cơ sở dữ liệu SAMPLE đã tồn tại trên máy chủ, DB2 có thể xác định vị tệp lược sử theo đường dẫn thư mục cơ sở dữ liệu.

Nếu cơ sở dữ liệu để được phục hồi vẫn không tồn tại, thì vị trí của tệp lược sử phải được xác định.

RECOVER DB sample TO END OF LOGS USING HISTORY FILE   
 (/home/user/oldfiles/db2rhist.asc)

Một tệp lược sử hợp lệ, có chứa các ảnh sao lưu và các log cần thiết, phải tồn tại trên máy chủ mà bạn muốn khôi phục lại. Trong lệnh của chúng ta ở trên, nếu chúng ta không có sẵn một bản sao của tệp lược sử (do chuyển đổi tệp hoặc bản sao lưu tệp lược sử), thì bằng cách nào đó ta phải trích ra lược sử từ chính ảnh sao lưu trước khi ta có thể chạy lệnh RECOVER DATABASE. Trong trường hợp này, có thể dễ dàng hơn là phục hồi cơ sở dữ liệu bằng cách chạy các lệnh tiêu chuẩn RESTOREROLL FORWARD liên tiếp.

Nếu, vì bất kỳ lý do gì, phép phục hồi bị ngắt trước khi nó thực hiện thành công, bạn có thể khởi động lại nó bằng cách chạy lại cùng lệnh. Nếu nó đã bị ngắt trong giai đoạn khôi phục tiếp, thì tiện ích phục hồi sẽ cố gắng tiếp tục phép phục hồi trước đó mà không thực hiện lại giai đoạn khôi phục lại. Nếu bạn muốn bắt buộc tiện ích khôi phục lại thực hiện lại giai đoạn phục hồi này, hãy đưa ra lệnh RECOVER DATABASE với tùy chọn RESTART để buộc tiện ích phục hồi bỏ qua bất kỳ phép phục hồi nào trước mà không thành công. Nếu tiện ích phục hồi bị ngắt trong giai đoạn phục hồi, thì nó sẽ bắt đầu lại từ đầu.

Tiện ích phục hồi không dùng các tuỳ chọn lệnh RESTORE DATABASE sau:

TABLESPACE tablespace-nameCác hoạt động khôi phục lại của không gian bảng không được hỗ trợ.
INCREMENTALCác hoạt động khôi phục lại tăng dần không được hỗ trợ.
OPEN num-sessions SESSIONSBạn không thể chỉ ra số lượng các phiên I/O được sử dụng với TSM hoặc sản phẩm của nhà cung cấp khác.
BUFFER buffer-sizeBạn không thể thiết lập kích thước của bộ đệm dùng cho phép khôi phục lại.
DLREPORT filenameBạn không thể xác định một tên tệp cho các tệp báo cáo trở thành không được liên kết.
PARALLELISM nBạn không thể xác định mức độ xử lý song song cho phép khôi phục lại.
WITHOUT PROMPTINGBạn không thể chỉ định rằng một phép khôi phục lại để chạy không cần giám sát.

Xây dựng lại cơ sở dữ liệu

Xây dựng lại một cơ sở dữ liệu là gì?

Chức năng xây dựng lại cơ sở dữ liệu được tiện ích khôi phục lại cung cấp. Nó cho phép bạn xây dựng lại một cơ sở dữ liệu nhánh mới bằng cách sử dụng một bộ các ảnh sao lưu. Bạn có thể chọn để xây dựng lại toàn bộ cơ sở dữ liệu hoặc một cơ sở dữ liệu với chỉ một tập hợp con các không gian bảng trong cơ sở dữ liệu ban đầu. Thủ tục xây dựng lại cơ sở dữ liệu tùy thuộc vào cơ sở dữ liệu có được phục hồi hay không. Chúng ta sẽ thảo luận về cả hai kịch bản trong các phần sau.

Việc xây dựng lại một cơ sở dữ liệu phục hồi bằng cách sử dụng sao lưu không gian bảng

Trong trường hợp các cơ sở dữ liệu phục hồi được, tiện ích xây dựng lại cho phép bạn xây dựng lại một toàn bộ cơ sở dữ liệu bằng cách sử dụng chỉ các bản sao lưu không gian bảng. Các bản sao lưu cơ sở dữ liệu đầy đủ không còn cần thiết nữa. Các bản sao lưu cơ sở dữ liệu đầy đủ có thể yêu cầu các cửa sổ bảo trì lớn hơn, chúng ngày càng khó khăn hơn để sắp lịch đối với công việc có khả năng sẵn sàng cao. Khả năng để xây dựng lại một cơ sở dữ liệu từ các bản sao lưu không gian bảng là sự tăng cường quan trọng đối với tính sẵn sàng và khả năng hồi phục lại.

Hãy nói rằng bạn có một cơ sở dữ liệu phục hồi được gọi là TEST. Một đêm, đã có một sự cố mất nguồn. Đĩa có cơ sở dữ liệu được lưu trữ bị hỏng. Cơ sở dữ liệu không thể truy cập được nữa và bạn muốn khôi phục lại cơ sở dữ liệu. Cơ sở dữ liệu có các không gian bảng sau đây:

  • SYSCATSPACE (các danh mục hệ thống).
  • USERSPACE1 (không gian bảng dữ liệu của người sử dụng).
  • USERSPACE2 (không gian bảng dữ liệu của người sử dụng).
  • USERSPACE3 (không gian bảng dữ liệu của người sử dụng).

Các thứ sau đây là có sẵn cho bạn:

  • Tất cả các tệp log. Vì các log được lưu trữ trên một đĩa riêng khác cơ sở dữ liệu, chúng đã không bị hỏng.
  • Bạn không có bất kỳ các bản sao lưu cơ sở dữ liệu nào, nhưng bạn có các bản sao lưu không gian bảng sau đây:
    • TEST.3.DB2.NODE0000.CATN0000.20060515135047.001 - Bản sao lưu của SYSCATSPACE và USERSPACE1
    • TEST.3.DB2.NODE0000.CATN0000.20060516135136.001 - Bản sao lưu của USERSPACE2 và USERSPACE3
    • TEST.3.DB2.NODE0000.CATN0000.20060517135208.001 - Bản sao lưu của USERSPACE3

Nếu chúng ta đã sử dụng các phương pháp khôi phục lại và khôi phục tiếp (đã thảo luận trong phần trước) để phục hồi cơ sở dữ liệu đến điểm gần đây nhất cuối cùng, chúng ta sẽ cần khôi phục lại một bản sao lưu cơ sở dữ liệu và sau đó khôi phục tiếp cơ sở dữ liệu đến cuối các log. Thật không may, trong trường hợp này, điều này là không thể bởi vì chúng ta không có một sao lưu cơ sở dữ liệu nào. Chúng ta chỉ có các bản sao lưu không gian bảng. Nếu chúng ta chạy lệnh điển hình RESTORE trên bất kỳ một trong số các bản sao lưu không gian bảng nào, chúng ta sẽ phạm phải lỗi sau:

db2 restore db test taken at 20060517135208
SQL2560N The target database is not identical to the source database for a restore 
from a table space level backup.

Với chức năng xây dựng lại cơ sở dữ liệu, chúng ta có thể xây dựng lại cơ sở dữ liệu TEST chỉ bằng các log và bản sao lưu không gian bảng. Để xây dựng lại một cơ sở dữ liệu, cần xác định tùy chọn REBUILD trong lệnh RESTORE DATABASE.

Các bước sau đây xây dựng lại cơ sở dữ liệu TEST theo điểm gần nhất.

  1. Đưa ra một lệnh RESTORE DATABASE với tùy chọn REBUILD:
    db2 restore db test rebuild with all tablespaces in database taken at 20060517135208

    Bước đầu tiên trong một quá trình xây dựng lại là xác định các ảnh đích xây dựng lại. Các ảnh đích xây dựng lại sẽ là ảnh bản sao lưu gần nhất mà bạn muốn sử dụng trong phép xây dựng lại. Nó được biết đến như là ảnh đích bởi vì nó định nghĩa cấu trúc cơ sở dữ liệu sẽ được xây dựng lại, bao gồm các không gian bảng có thể được khôi phục lại, cấu hình cơ sở dữ liệu và trình tự log. Nó có thể là bất kỳ kiểu sao lưu nào (đầy đủ, không gian bảng, tăng dần, trực tuyến hoặc không trực tuyến). Trong ví dụ này, ảnh sao lưu gần đây nhất là TEST.3.DB2.NODE0000.CATN0000.20060517135208.001; do đó chúng ta sử dụng nó như là ảnh đích của phép xây dựng lại của chúng ta .

    Sau khi lệnh này được thực hiện thành công, cấu trúc của cơ sở dữ liệu TEST được khôi phục lại. Chúng ta có thể nhận được thông tin như cấu hình cơ sở dữ liệu và lược sử của nó. Nếu chúng ta dùng lệnh LIST HISTORY (ví dụ, db2 list history all for test), chúng ta sẽ nhận được kết quả đầu ra sau:

    Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log  Backup ID
    -- --- ------------------ ---- --- ------------ ------------ --------------
     R  D  20060519121107001   F                                 20060517135208
    ---------------------------------------------------------------------------
     Contains 1 tablespace(s):
     00001 USERSPACE3
    ---------------------------------------------------------------------------
       Comment: RESTORE TEST WITH RF
    Start Time: 20060519121107
      End Time: 20060519121108
        Status: A
    ---------------------------------------------------------------------------
     EID: 7 Location:
    
    
    Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log  Backup ID
    -- --- ------------------ ---- --- ------------ ------------ --------------
     R  P  20060519121108001   F                                 20060515135047
    ---------------------------------------------------------------------------
     Contains 2 tablespace(s):
     00001 USERSPACE1
     00002 SYSCATSPACE
    ---------------------------------------------------------------------------
       Comment: RESTORE TEST WITH RF
    Start Time: 20060519121108
      End Time: 20060519121113
        Status: A
    ---------------------------------------------------------------------------
     EID: 8 Location:
    
    
    Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log  Backup ID
    -- --- ------------------ ---- --- ------------ ------------ --------------
     R  P  20060519121113001   F                                 20060516135136
    ---------------------------------------------------------------------------
     Contains 1 tablespace(s):
     00001 USERSPACE2
    ---------------------------------------------------------------------------
       Comment: RESTORE TEST WITH RF
    Start Time: 20060519121113
      End Time: 20060519121114
        Status: A
    ---------------------------------------------------------------------------
     EID: 9 Location:
    
    
    Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log  Backup ID
    -- --- ------------------ ---- --- ------------ ------------ --------------
     R  D  20060519121107      R       S0000001.LOG S0000003.LOG 20060518135208
    ---------------------------------------------------------------------------
     Contains 4 tablespace(s):
     00001 USERSPACE3
     00002 USERSPACE2
     00003 USERSPACE1
     00004 SYSCATSPACE
    ---------------------------------------------------------------------------
       Comment: REBUILD TEST WITH RF
    Start Time: 20060519121107
      End Time: 20060519121115
        Status: A
    ---------------------------------------------------------------------------
     EID: 10 Location:

    Có bốn lối vào trong kết quả đầu ra của lệnh LIST HISTORY được hiển thị ở trên. Tất cả chúng được liên quan với phép xây dựng lại.

    Lối vào đầu tiên, EID: 7, chỉ ra một phép khôi phục lại trên ảnh sao lưu 20060517135208 và không gian bảng được khôi phục lại là USERSPACE3. (Nhớ lại rằng ảnh sao lưu này chỉ chứa USERSPACE3). Tuy nhiên, chúng ta đã yêu cầu khôi phục lại tất cả các không gian bảng bằng cách sử dụng tùy chọn ALL TABLESPACES, do đó, phần còn lại của không gian bảng trong cơ sở dữ liệu cũng sẽ được khôi phục lại. Điều này được phản ánh trong phần còn lại của kết quả đầu ra LIST HISTORY.

    Sử dụng thông tin trong tệp lược sử sao lưu, tiện ích khôi phục tìm thấy các ảnh sao lưu của tất cả các không gian bảng được khôi phục lại và khôi phục lại chúng. Sau khi khôi phục lại, các không gian bảng được đặt trong trạng thái chờ khôi phục tiếp. Bạn có thể nhìn thấy dòng ghi chú trong kết quả đầu ra LIST HISTORY rằng mỗi không gian bảng được gắn cờ với 'WITH RF', cho biết có yêu cầu khôi phục tiếp sau việc khôi phục lại.

    Đối với việc khôi phục lại để hoạt động, tất cả các ảnh sao lưu phải tồn tại ở các vị trí như được lưu trữ trong tệp lược sử. Nếu không, một lỗi thu được cho biết tiện ích khôi phục lại không thể tìm thấy một ảnh cần thiết.

  2. Đưa ra một lệnh ROLLFORWARD DATABASE với tùy chọn TO END OF LOGS:
    db2 rollforward db test to end of logs

    Sau khi tất cả các không gian bảng đã được phục hồi, chúng được đặt trong trạng thái chờ khôi phục tiếp . Chúng ta cần khôi phục tiếp cơ sở dữ liệu để đưa cơ sở dữ liệu trở về một trạng thái bình thường.

    Để khôi phục tiếp một cơ sở dữ liệu trong một phép xây dựng lại, tất cả các tệp log với khung thời gian giữa các ảnh sao lưu sớm nhất và gần nhất phải sẵn sàng cho tiện ích khôi phục tiếp sử dụng. Nếu bạn muốn khôi phục tiếp đến một điểm gần nhất cuối cùng hơn là bản sao lưu cuối cùng, tất cả các tệp log được tạo ra sau khi sao lưu cũng phải có sẵn.

    Trong ví dụ của chúng ta, tất cả các log vẫn còn trong hình dạng tốt và chúng vẫn còn trong đường dẫn log do tham số cấu hình cơ sở dữ liệu LOGPATH xác định. Tiện ích khôi phục tiếp sẽ tìm thấy chúng ở đó. Đây là lý do tại sao chúng ta không cần phải chỉ rõ vị trí của các tệp log trong lệnh ROLLFORWARD. Nếu các tệp log đã được lưu trữ ở một nơi khác, thì sau đó chúng ta phải xác định vị trí của các tệp log bằng cách sử dụng tùy chọn OVERFLOW LOG PATH trong lệnh ROLLFORWARD.

  3. Đưa ra một lệnh ROLLFORWARD DATABASE với tùy chọn STOP:
    db2 rollforward db test stop

    Tại thời điểm này cơ sở dữ liệu TEST là kết nối được và tất cả các không gian bảng đang ở trạng thái bình thường (NORMAL).

Việc xây dựng lại một cơ sở dữ liệu có khả năng phục hồi bằng cách sử dụng chỉ một tập hợp con các bản sao lưu không gian bảng

Như đã được giải thích trong các ví dụ trước, các chức năng xây dựng lại cơ sở dữ liệu cho chúng ta xây dựng lại một cơ sở dữ liệu toàn bộ bằng cách chỉ sử dụng các bản sao lưu và các log không gian bảng. Điều làm cho tiện ích này mạnh mẽ đến vậy là ở chỗ chúng ta không cần phải có tất cả các bản sao lưu không gian bảng để xây dựng lại một cơ sở dữ liệu. Chúng ta có thể xây dựng lại một cơ sở dữ liệu chỉ bằng một tập hợp con của các bản sao lưu không gian bảng.

Hãy sử dụng lại ví dụ cuối cùng của chúng ta và nói rằng các dữ liệu trong USERSPACE1 và USERSPACE2 đang thực sự quan trọng với những người dùng của chúng ta. Chúng ta phải khôi phục lại hai không gian bảng càng sớm càng tốt sau sự cố mất điện. Userspace3 không quan trọng và nó là rất lớn. Nếu chúng ta khôi phục lại tất cả các không gian bảng, sẽ mất một thời gian dài. Thật là tốt nếu chúng ta có thể xây dựng lại một cơ sở dữ liệu kết nối được với chỉ USERSPACE1 và USERSPACE2 trong nó, do đó người dùng có thể sử dụng cơ sở dữ liệu ngay lập tức. Khi thời gian cho phép, chúng ta có thể khôi phục lại USERSPACE3. Các bước sau đây cho thấy việc này có thể được thực hiện như thế nào khi sử dụng tiện ích xây dựng lại cơ sở dữ liệu.

  1. Đưa ra một lệnh RESTORE DATABASE với tùy chọn REBUILD, cho biết chỉ có một tập hợp con của các không gian bảng mà bạn muốn khôi phục lại:
    db2 restore db test rebuild with tablespace (SYSCATSPACE,USERSPACE1,USERSPACE2) 
    taken at 20060516135136

    Mặc dù chúng ta chỉ muốn khôi phục lại USERSPACE1 và USERSPACE2, chúng ta cũng phải khôi phục lại SYSCATSPACE, bởi vì không gian bảng này nắm giữ tất cả thông tin hệ thống. Nếu không có nó, DB2 sẽ không biết gì về cấu trúc cơ sở dữ liệu này.

    Các ảnh đích mà chúng ta chỉ rõ trong lệnh trên là ảnh có chứa USERSPACE2 và USERSPACE3. Đây là bản sao lưu gần đây nhất có chứa các không gian bảng mà chúng ta muốn khôi phục lại. Mặc dù, ảnh 20060517135208 là bản sao lưu mới nhất của cả ba, chúng ta không thể sử dụng nó, vì nó không chứa USERSPACE1, USERSPACE2, hoặc SYSCATSPACE.

    Lệnh sau có cùng tác dụng:

    db2 restore db test rebuild with all tablespaces in database except tablespace 
       (USERSPACE3) taken at 20060516135136
  2. Đưa ra một lệnh ROLLFORWARD DATABASE với tùy chọn TO END OF LOGS:
    db2 rollforward db test to end of logs
  3. Đưa ra một lệnh ROLLFORWARD DATABASE với tùy chọn STOP:
    db2 rollforward db test stop

    Bạn có thể chọn khôi phục tiếp đến một điểm cuối cùng thay vì đến cuối các log. Điểm cuối cùng mà bạn chọn phải lớn hơn dấu thời gian của ảnh sao lưu mà bạn sử dụng trong việc khôi phục lại.

Tại thời điểm này, cơ sở dữ liệu TEST có khả năng kết nối và tất cả không gian bảng đều ở trạng thái NORMAL trừ USERSPACE3. USERSPACE3 là ở trạng thái chờ khôi phục lại (PENDING RESTORE).

Bạn có thể khôi phục lại USERSPACE3 sau này, khi sử dụng một việc khôi phục lại không gian bảng bình thường (không có tùy chọn REBUILD):

  1. Đưa ra một lệnh RESTORE DATABASE và xác định không gian bảng được khôi phục lại:
    db2 restore db test tablespace (USERSPACE3) taken at 20060517135208
  2. Đưa ra một lệnh ROLLFORWARD DATABASE với tùy chọn TO END OF LOGS và chỉ rõ không gian bảng được khôi phục tiếp:
    db2 rollforward db test to end of logs tablespace (USERSPACE3)
  3. Đưa ra một lệnh ROLLFORWARD DATABASE với tùy chọn STOP:
    db2 rollforward db test stop

Bây giờ tất cả bốn không gian bảng của cơ sở dữ liệu TEST đang ở trạng thái NORMAL.

Chỉ cần đưa ra một tập hợp con trực tuyến của không gian bảng là có ích trong một môi trường sản xuất hoặc trong một tình huống phục hồi giống như ở trên. Nó cũng có ích trong một môi trường thử nghiệm, ở đó bạn chỉ cần khôi phục lại một tập hợp con của các không gian bảng cho các bên quan tâm.

Xây dựng lại một cơ sở dữ liệu phục hồi bằng cách sử dụng ảnh sao lưu trực tuyến có chứa các tệp log

Khi xây dựng lại một cơ sở dữ liệu phục hồi, bạn có thể sử dụng hoặc các bản sao lưu cơ sở dữ liệu hoặc các bản sao lưu không gian bảng. Các phép sao lưu này cũng có thể hoặc là trực tuyến hoặc không trực tuyến.

Nếu bạn có một ảnh sao lưu trực tuyến có chứa các tệp log và bạn muốn sử dụng các log này để khôi phục tiếp cơ sở dữ liệu, bạn có thể lấy ra các log từ ảnh khi sử dụng tùy chọn LOGTARGET của lệnh RESTORE DATABASE.

Hãy tái sử dụng cơ sở dữ liệu TEST của chúng ta như một ví dụ và giả sử rằng ảnh sao lưu TEST.3.DB2.NODE0000.CATN0000.20060517135208.001 đã là ảnh sao lưu trực tuyến có các log. Để phục hồi toàn bộ cơ sở dữ liệu bằng cách sử dụng các bản sao lưu và các log không gian bảng được lưu trữ trong ảnh sao lưu:

  1. Đưa ra một lệnh RESTORE DATABASE với tùy chọn LOGTARGET. Trong thời gian khôi phục lại, các log được trích ra đến vị trí do LOGTARGET chỉ định.
    db2 restore db test rebuild with all tablespaces in database taken at 20060517135208
       logtarget /logs
  2. Đưa ra một lệnh ROLLFORWARD DATABASE với tùy chọn TO END OF LOGS và chỉ rõ vị trí của các log:
    db2 rollforward db test to end of logs overflow log path (/logs)

    Lưu ý tùy chọn OVERFLOW LOG PATH được sử dụng để chỉ rõ vị trí log.

  3. Đưa ra một lệnh ROLLFORWARD DATABASE với tùy chọn STOP:
    db2 rollforward db test stop

Việc xây dựng lại một cơ sở dữ liệu phục hồi bằng cách sử dụng ảnh sao lưu tăng dần

Các ảnh sao lưu tăng dần cũng có thể được sử dụng để xây dựng lại một cơ sở dữ liệu. Khi một ảnh tăng dần liên quan đến một quá trình xây dựng lại, theo mặc định tiện ích khôi phục lại cố gắng sử dụng phép khôi phục lại tăng dần tự động cho tất cả các ảnh tăng dần. Nếu bạn không sử dụng tùy chọn INCREMENTAL AUTOMATIC của lệnh RESTORE DATABASE, nhưng ảnh đích là một ảnh sao lưu tăng dần, tiện ích khôi phục lại sẽ đưa ra phép xây dựng lại bằng cách sử dụng phép khôi phục lại tăng dần tự động.

Nếu ảnh đích không phải là một ảnh tăng dần, nhưng một ảnh yêu cầu khác là một ảnh tăng dần, thì sau đó tiện ích khôi phục lại này cũng sẽ chắc chắn rằng những ảnh tăng dần đó được khôi phục lại bằng cách sử dụng phép khôi phục lại tăng dần tự động. Tiện ích khôi phục lại sẽ hành động theo cùng một cách cho dù bạn có chỉ định các tùy chọn INCREMENTAL AUTOMATIC hay không.

Nếu bạn chỉ rõ tùy chọn INCREMENTAL mà không có tùy chọn AUTOMATIC bạn sẽ cần phải thực hiện toàn bộ quá trình xây dựng một cách thủ công. Tiện ích khôi phục lại sẽ khôi phục lại đúng siêu dữ liệu ban đầu từ ảnh đích, vì nó sẽ là phép khôi phục lại tăng dần thủ công thông thường. Sau đó, bạn sẽ cần phải hoàn thành việc khôi phục lại ảnh đích bằng cách sử dụng chuỗi các khôi phục lại tăng dần cần thiết (xem Khôi phục lại tăng dần). Sau đó, bạn sẽ cần phải khôi phục lại những ảnh còn lại để xây dựng lại cơ sở dữ liệu. Quá trình này có thể rất nặng nề.

Chúng tôi đề nghị bạn sử dụng phép khôi phục lại tăng dần để xây dựng lại cơ sở dữ liệu của bạn. Chỉ trong trường hợp phép khôi phục lại thất bại, bạn nên cố gắng xây dựng lại một cơ sở dữ liệu bằng cách sử dụng các phương pháp thủ công.

Xây dựng lại một cơ sở dữ liệu phục hồi bằng cách sử dụng tùy chọn chuyển hướng

Kể từ khi các chức năng xây dựng lại là một phần của tiện ích khôi phục lại, bạn có thể xây dựng lại một cơ sở dữ liệu khi sử dụng phương pháp chuyển hướng, cũng như trong phép khôi phục lại chuyển hướng. Phần sau đây xây dựng lại toàn bộ cơ sở dữ liệu TEST đến điểm gần nhất cuối cùng khi sử dụng tùy chọn REDIRECT:

  1. Đưa ra một lệnh RESTORE DATABASE với tùy chọn REBUILDREDIRECT:
    db2 restore db test rebuild with all tablespaces in database taken at 20060517135208 
       redirect
  2. Đưa ra một lệnh SET TABLESPACE CONTAINERS cho mỗi không gian bảng mà bạn muốn xác định lại thùng chứa của nó. Ví dụ:
    db2 set tablespace containers for 3 using (file '/newuserspace2' 10000)
    db2 set tablespace containers for 4 using (file '/newuserspace3' 15000)
  3. Đưa ra một lệnh RESTORE DATABASE với tùy chọn CONTINUE:
    db2 restore db test continue
  4. Đưa ra một lệnh ROLLFORWARD DATABASE với tùy chọn TO END OF LOGS. (Điều này giả định tất cả các log có thể truy cập vào thư mục LogPath; nếu không, hãy sử dụng tùy chọn OVERFLOW LOG PATH để xác định đường dẫn log thay thế).
    db2 rollforward db test to end of logs
  5. Đưa ra một lệnh ROLLFORWARD DATABASE với tùy chọn STOP:
    db2 rollforward db test stop

Tại thời điểm này, cơ sở dữ liệu có khả năng kết nối và tất cả các không gian bảng đang ở trạng thái NORMAL.

Xây dựng lại cơ sở dữ liệu không phục hồi

Mọi phương pháp xây dựng lại mà chúng ta đã thảo luận cho đến nay cũng làm việc với cơ sở dữ liệu không phục hồi được. Sự khác biệt duy nhất là:

  • Nếu một cơ sở dữ liệu không phục hồi được, bạn chỉ có thể sử dụng một bản sao lưu cơ sở dữ liệu như là ảnh đích trong phép xây dựng lại, do các bản sao lưu không gian bảng không có sẵn cho cơ sở dữ liệu không phục hồi được.
  • Khi việc khôi phục lại hoàn tất, bạn có thể kết nối tới cơ sở dữ liệu ngay lập tức -- không đòi hỏi bất kỳ phép khôi phục tiếp nào. Tuy nhiên, bất kỳ không gian bảng nào không được khôi phục lại được đặt vào trạng thái chờ loại bỏ và chúng không thể được phục hồi.

Hãy xem xét một ví dụ. Giả sử chúng ta có một cơ sở dữ liệu không phục hồi được MYDB. MYDB có ba không gian bảng: SYSCATSPACE, USERSP1 và USERSP2. Một cơ sở dữ liệu sao lưu đầy đủ đã nhận được vào 20060521130000.

Để xây dựng lại cơ sở dữ liệu khi chỉ sử dụng SYSCATSPACE và USERSP1:

db2 restore db mydb rebuild with tablespace (SYSCATSPACE, USERSP1) taken at 
   20060521130000

Sau việc khôi phục lại, cơ sở dữ liệu là kết nối được. Nếu bạn đưa ra lệnh LIST TABLESPACES bạn sẽ thấy SYSCATSPACE và USERSP1 đang ở trạng thái NORMAL, trong khi ở USERSP2 ở trạng thái DROP PENDING. Bây giờ bạn có thể làm việc với hai không gian bảng đang ở trạng thái NORMAL.

Nếu bạn muốn có một bản sao lưu cơ sở dữ liệu, trước tiên bạn phải loại bỏ USERSP2 bằng cách sử dụng lệnh DROP TABLESPACE hay sao lưu sẽ không chạy.

Các hạn chế xây dựng lại cơ sở dữ liệu

Khả năng để xây dựng lại một cơ sở dữ liệu làm cho tiện ích khôi phục lại mạnh hơn. Tuy nhiên, có một vài hạn chế:

  • Một trong các không gian bảng mà bạn xây dựng lại phải là SYSCATSPACE.
  • Bạn không thể thực hiện phép xây dựng lại bằng cách sử dụng công cụ GUI của Trung tâm điều khiển. Bạn phải hoặc đưa ra lệnh bằng cách sử dụng bộ xử lý dòng lệnh (CLP) hoặc sử dụng giao diện lập trình ứng dụng tương ứng (API).
  • Tùy chọn REBUILD không thể được dùng trên ảnh đích của phiên bản trước 9.1 trừ khi ảnh đó là ảnh của một phép sao lưu cơ sở dữ liệu không trực tuyến. Nếu ảnh đích là một bản sao lưu cơ sở dữ liệu không trực tuyến, sau đó chỉ có các không gian bảng trong ảnh này có thể được sử dụng cho việc xây dựng lại. Cơ sở dữ liệu đó sẽ cần phải được di chuyển sau khi phép xây dựng lại hoàn thành thành công. Các nỗ lực để xây dựng lại bằng cách sử dụng bất kỳ ảnh đích của phiên bản trước 9.1 sẽ gây ra lỗi.
  • Tùy chọn REBUILD không thể dùng trên ảnh đích từ một hệ điều hành khác với hệ điều hành mà ta đang tiến hành khôi phục, trừ khi ảnh đích là một bản sao lưu cơ sở dữ liệu đầy đủ. Nếu ảnh đích là một bản sao lưu cơ sở dữ liệu đầy đủ, sau đó chỉ có các không gian bảng trong ảnh này mới có thể được sử dụng cho việc xây dựng lại.

Tái tạo lại chỉ mục

Xây dựng lại các chỉ mục

Nếu một cơ sở dữ liệu có sự cố về một số lý do phần cứng hoặc lý do hệ điều hành, có khả năng là một số chỉ mục có thể được đánh dấu là không hợp lệ trong giai đoạn khởi động lại cơ sở dữ liệu. Tham số cấu hình INDEXREC cho biết lúc DB2 có ý xây dựng lại các chỉ mục không hợp lệ.

INDEXREC được định nghĩa trong cả tệp quản lý cơ sở dữ liệu và tệp cấu hình cơ sở dữ liệu. Có ba giá trị cài đặt có thể cho tham số này:

  • HỆ THỐNG: Giá trị này chỉ có thể được xác định trong tệp cấu hình cơ sở dữ liệu. Khi INDEXREC được đặt tới giá trị này, DB2 sẽ tìm giá trị cài đặt INDEXREC đã xác định trong tệp cấu hình của trình quản lý cơ sở dữ liệu và sử dụng giá trị này.
  • TRUY CẬP: Các chỉ mục không hợp lệ được xây dựng lại khi chỉ số này được truy cập lần đầu tiên.
  • KHỞI ĐỘNG LẠI: Các chỉ mục không hợp lệ được xây dựng lại lúc khởi động lại một cơ sở dữ liệu.

Tóm tắt

Vậy là, đó là câu chuyện về sao lưu và phục hồi có tính sẵn sàng cao. Trong bài này bạn đã học:

  • Phục hồi các khái niệm và tầm quan trọng của việc có một kế hoạch phục hồi.
  • Một giao dịch (đơn vị công việc) là gì và làm việc với các giao dịch để bảo đảm tính toàn vẹn dữ liệu như thế nào.
  • Ba kiểu phục hồi: sự cố, phiên bản và khôi phục tiếp.

Bạn đã quen với các khái niệm log giao dịch DB2:

  • Bộ đệm log
  • Các log sơ cấp và thứ cấp.
  • Các log hoạt động, lưu trữ trực tuyến và lưu trữ không trực tuyến.
  • Các tham số cấu hình cơ sở dữ liệu: LOGPRIMARY, LOGSECONDLOGFILSIZ, trong số các tham số khác
  • Hai kiểu ghi log: Ghi log vòng tròn và ghi log lưu trữ (với kiểu ghi log lưu trữ các tham số cấu hình cơ sở dữ liệu LOGARCHMETH1 phải được kích hoạt).
  • Ghi vô hạn.
  • Cơ sở dữ liệu phục hồi được và không phục hồi được.

Bạn đã biết về các khái niệm cơ sở dữ liệu và sao lưu không gian bảng:

  • Làm thế nào để sử dụng tiện ích sao lưu.
  • Các hoạt động sao lưu tăng dần và gia tăng.
  • Làm thế nào để gọi tiện ích BACKUP từ Trung tâm điều khiển.
  • Quy ước đặt tên được sử dụng cho các tệp sao lưu.

Bạn đã biết về các khái niệm phục hồi cơ sở dữ liệu và phục hồi không gian bảng:

  • Làm thế nào để sử dụng tiện ích RESTORE.
  • Điểm tối thiểu cuối cùng.
  • Làm thế nào để gọi tiện ích RESTORE từ Trung tâm điều khiển.
  • Tiện ích QUIESCE có thể làm gì cho bạn.
  • Những tệp lược sử chứa gì.
  • Làm thế nào để thực hiện một phép khôi phục lại chuyển hướng.

Bạn đã biết về các khái niệm khôi phục tiếp cơ sở dữ liệu và không gian bảng:

  • Làm thế nào để sử dụng tiện ích ROLLFORWARD.
  • Làm thế nào để khôi phục lại đến một điểm cuối cùng khi sử dụng tiện ích ROLLFORWARD.
  • Làm thế nào để gọi tiện ích ROLLFORWARD từ Trung tâm điều khiển.
  • Làm thế nào để sử dụng tiện ích RECOVER.
  • Làm thế nào để xây dựng lại một cơ sở dữ liệu bằng cách sử dụng tiện ích RESTORE.
  • Tái tạo lại chỉ mục và tham số cấu hình INDEXREC.

Phần 7 tiếp tục với tính sẵn sàng cao và thảo luận về nhân bản dữ liệu có phân chia và khắc phục sự cố có tính sẵn sàng cao.

Theo dõi loạt bài này, đánh dấu trang, Các hướng dẫn chuẩn bị cho kỳ thi 731 DBA DB2 9.

Tài nguyên

Học tập

  • Xem các phần khác của loạt bài hướng dẫn chuẩn bị cho kỳ thi 731 DBA DB2 9.
  • Bạn có thể tìm hiểu thêm về việc quản lý DB2 từ Trung tâm Thông tin DB2 9. Hãy tìm các chủ đề sau:
    • Thiết lập máy chủ DB2 sau khi cài đặt thủ công.
    • Cấu hình truyền thông từ máy khách đến máy chủ.
    • Cấu hình truyền thông máy chủ DB2.
    • Tính sẵn sàng cao và phục hồi dữ liệu.
  • Để biết thêm thông tin về cấp chứng chỉ quản trị cơ sở dữ liệu DB2 9 cho Linux, UNIX và Windows (kỳ thi 731), hãy xem các liên kết này:
  • DB2 9 overview. Tìm thông tin về các máy chủ dữ liệu mới bao gồm công nghệ pureXML đã được cấp bằng sáng chế.
  • Trang Web thi cấp chứng chỉ. Nhấn vào số bài thi để xem thông tin thêm về các kỳ thi 730 và 731.

Lấy sản phẩm và công nghệ

  • Một phiên bản dùng thử DB2 9 có sẵn để tải về miễn phí.
  • Tải về DB2 Express-C, một phiên bản miễn phí của DB2 Express Edition (Ấn bản Express DB2) cho cộng đồng cung cấp nhiều tính năng dữ liệu lõi như DB2 Express Edition và cung cấp một cơ sở vững chắc để xây dựng và triển khai các ứng dụng.

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Information Management
ArticleID=431509
ArticleTitle=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
publish-date=10022009