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

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

Thêm vào BST

Báo xấu

114
lượt xem 7
download

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

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

Chủ đề:

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

Lưu

Nội dung Text: 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

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: 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, 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. Cho biết số lượng lớn nhất các tệp log thứ cấp có thể LOGSECOND được cấp phát. Được dùng để chỉ rõ kích thước của một tệp log (bằng số LOGFILSIZ 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: Các tệp log sẽ được giữ lại trong thư mục log hoạt động. LOGRETAIN 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ư USEREXIT 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. 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, DISK:directory_name 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. 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 TSM:[management class Storage Manger (TSM). Tham số tên của lớp quản lý là name] 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. Cũng giống như thuật toán được sử dụng trong VENDOR:library_name 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.