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

Khi các giao dịch hoàn tất một lệnh COMMIT hoặc ROLLBACK được chạy, các mục đăng nhập tương ứng được giải phóng, do chúng không còn cần phục hồi cơ sở dữ liệu.. Khi tất cả các bản ghi lư

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

Các kịch bản phục hồi

Amol D Barsagade, Cố vấn Cơ sở dữ liệu, IBM

Tóm tắt: Một chiến lược cố gắng và kiểm thử sao lưu và phục hồi là thiết yếu

trong việc ngăn ngừa mất dữ liệu Một cơ sở dữ liệu có thể gặp bất kỳ vấn đề nào, gồm bị ngắt nguồn điện đột xuất, hỏng hóc về phương tiện lưu trữ, và các sự cố của ứng dụng Mỗi việc này có thể gây ra một sự cố về cơ sở dữ liệu và mỗi sự cố đòi hỏi một hành động phục hồi khác nhau Hướng dẫn này giới thiệu các khả năng sao lưu và phục hồi trong IBM® DB2® for Linux®, UNIX® và Windows® Ngoài ra, nó còn trình bày một cách tiếp cận từng bước, chỉ ra cách phục hồi dữ liệu ở các kịch bản sự cố khác nhau

Trước khi bạn bắt đầu

(DBMS) cũng như phải có một kế hoạch phục hồi dữ liệu ngay để thực hiện

chúng

Mục tiêu

Hướng dẫn này đưa ra các tuỳ chọn phục hồi DB2 9 đa dạng và gồm các chủ đề sau:

 Ghi log cơ sở dữ liệu

 Cách thay đổi hình thức ghi log cơ sở dữ liệu

 Các thực hành tốt nhất để giữ an toàn cơ sở dữ liệu dữ liệu

 Cách phục hồi toàn bộ cơ sở dữ liệu sau một sự cố

 Cách phục hồi khi một vùng chứa không gian bảng bị mất hoặc hỏng

 Cách phục hồi một bảng mà bị lấy mất do ngẫu nhiên

 Cách phục hồi đến một thời điểm

Ghi log Cơ sở dữ liệu

Các cơ sở dữ liệu DB2 hỗ trợ hai hình thức ghi log cơ sở dữ liệu khác nhau:

Circular (Quay vòng) và Archival (Lưu trữ) Khi một cơ sở dữ liệu mới được tạo

ra, kiểu ghi log quay vòng là mặc định Nếu việc nhu cầu kinh doanh đòi hỏi cao hơn, bạn có thể thay đổi hình thức ghi log từ vòng tròn sang lưu trữ

Tóm tắt về log giao dịch trong DB2

Một giao dịch là một đơn vị logic của công việc Mỗi giao dịch có các bản ghi log tương ứng được lưu lại trong tệp log giao dịch Mỗi giao dịch có một mục tương

ứng trong cái được gọi là Redo Log (Log Làm lại) Các mục Log Làm lại được

viết cho tệp log hoạt động hiện tại Khi tệp log hoạt động đã đầy, nó được đánh

dấu là không sẵn có, để dùng nữa, vào lúc đó DB2 tạo ra tệp log tiếp theo, theo thứ

tự tệp log hoạt động và tiếp tục viết các mục ghi log vào nó Quy trình xử lý vòng tròn được lặp lại khi tệp log hoạt động hiện tại đã đầy Khi các giao dịch hoàn tất (một lệnh COMMIT hoặc ROLLBACK được chạy), các mục đăng nhập tương ứng được giải phóng, do chúng không còn cần phục hồi cơ sở dữ liệu

DB2 luôn cố gắng ghi các mục log vào bộ các tệp log sơ cấp, nghĩa là, các tệp log

mà tự động được phân bổ vào lúc kích hoạt cơ sở dữ liệu Nếu có một tình trạng phát sinh khi một giao dịch đã sử dụng hết tất cả các tệp log sơ cấp (tất cả các tệp

log sơ cấp được đánh dấu là chưa sẵn sàng), sau đó bộ quản trị cơ sở dữ liệu phân

bổ một tệp log phụ Ngay sau khi tệp đã đầy, bộ quản trị cơ sở dữ liệu kiểm tra tệp

log sơ cấp lần nữa để xem có đúng tình trạng của chúng là chưa sẵn sàng hay

không Nếu đúng như vậy, một tệp log phụ khác được phân bổ và các lối vào được ghi vào đó Quy trình này tiếp tục cho đến khi tất cả các tệp log thứ cấp được phân

bổ và đầy Nếu không sẵn có tệp log sơ cấp nào để ghi các mục làm lại, và số lượng tối đa các tệp log thứ cấp đã được phân bổ rồi, thì một ứng dụng nhận được thông báo lỗi sau đây

SQL0964C Log giao dịch cho cơ sở dữ liệu đã đầy

Hy vọng là bạn từng gặp phải lỗi này Tuy nhiên, nếu gặp, bạn phải tăng thêm số các tệp log sơ cấp và thứ cấp (hoặc kích thước của chúng) khi cần thiết Một cách

lý tưởng, các tệp log sơ cấp phải lớn hoặc nhiều đủ để chứa cả giao dịch lớn nhất Việc phân bổ các tệp log thứ cấp là tốn kém do nó được thực hiện vào lúc đang chạy, vì vậy bạn phải giảm thiểu số lượng các tệp log thứ cấp mà cần được phân

bổ trong thời gian tải làm việc của bạn là lớn nhất Để cập nhật số lượng các tệp log sơ cấp hoặc thứ cấp, bạn có thể chạy các lệnh sau đây:

Ghi chú: Nếu vấn đề này xảy ra, bạn phải tìm hiểu tại sao toàn bộ không gian log

bị đầy Hẳn là do một truy vấn thoát ra ngoài hoặc lỗi của một người sử dụng, do

đó việc tăng số lượng hoặc kích thước các tệp log có thể chỉ là che giấu vấn đề Ví

dụ, giả sử một người sử dụng chạy một lệnh DELETE FROM tab1 và TAB1 là một bảng rất lớn Trong khi lệnh này trông rất vô hại, mỗi bản ghi log đã xoá được tạo ra trên từng hàng, vậy có thể dễ dàng lấp đầy không gian log nếu nó không được lập cấu hình để xử lý

Ghi log quay vòng

Khi hình thức ghi log quay vòng có hiệu lực, dữ liệu giao dịch được viết cho các tệp log sơ cấp theo kiểu quay vòng Khi tất cả các bản ghi lưu trong một tệp log

riêng không cần phục hồi nữa, tệp log đó được xử lý là dùng lại được và nó có thể

lại trở thành tệp log hoạt động sau này Điều này có nghĩa là ở cách ghi log quay vòng, nội dung của một tệp log cuối cùng lại bị ghi đè lên bằng lối vào log mới

Do nột dung của tệp log bị ghi đè lên, bạn chỉ có thể phục hồi một cơ sở dữ liệu ở mức sao lưu cơ sở dữ liệu đầy đủ lần cuối Bạn không thể tiến hành phục hồi theo một điểm thời gian định trước bằng cách ghi log quay vòng

Ghi log lưu trữ

Như với cách ghi log quay vòng, các lối vào của log làm lại được viết lên các tệp log sơ cấp Tuy nhiên, không như kiểu ghi log quay vòng, các tệp log này không bao giờ được sử dụng lại Khi tất cả các bản ghi lưu lại trong một tệp log riêng

không cần phục hồi nữa, tệp log đó được đánh dấu là không hoạt động chứ không phải là không sử dụng lại được Điều này có nghĩa là nội dung của nó không bao

giờ bị ghi đè Khi tệp log sơ cấp đầu tiên đã đầy, một tệp log sơ cấp mới được phân bổ để số lượng theo cấu hình của các tệp log sơ cấp (tham số cơ sở dữ liệu LOGPRIMARY) là luôn có thể

Tất cả các lối vào liên quan đến một giao dịch đơn lẻ phải khớp với không gian log động Trong trường hợp mà một giao dịch dài đòi hỏi nhiều không gian log hơn mà có thể được cung cấp trong các tệp log sơ cấp, các tệp log thứ cấp có thể được phân bổ và sử dụng Theo hình thức log lưu trữ, bạn có thể phục hồi một cơ

sở dữ liệu đến một thời điểm đặc biệt bằng cách sử dụng một kết hợp giữa sao lưu các ảnh cơ sở dữ liệu và các tệp log Quá trình này được mô tả sau đây chi tiết hơn

Cách thay đổi hình thức ghi log

Khi một cơ sở dữ liệu DB2 mới được tạo ra, hình thức ghi log quay vòng là mặc định Nếu bạn muốn thay đổi hình thức từ quay vòng thành lưu trữ, bạn có thể thực hiện các bước sau đây:

1 Tạo một thư mục trên một đĩa (chẳng hạn như e:\db_name\archive) nơi có

đủ không gian đĩa để lưu lại các tệp log được lưu trữ Như một thực hành tốt nhất, hãy giữ điểm đích tệp log được lưu trữ của bạn tách biệt khỏi điểm đích tệp log hoạt động

2 Chấm dứt kết nối đến cơ sở dữ liệu:

3 Cập nhật điểm đích tệp log được lưu trữ (Việc quy định một đường dẫn cho các tệp log được lưu trữ có tác dụng thay đổi hình thức log lưu trữ)

"Disk:e:\db_name\archive"

4 Kết nối lại đến cơ sở dữ liệu:

5 Kết nối thất bại và bạn nhận được thông báo sau:

SQL1116N Một kết nối đến hoặc kích hoạt của cơ sở dữ liệu db_name không thực hiện được do việc sao lưu đang chờ xử lý:

SQLSTATE=57019

Việc này xảy ra vì hình thức ghi log cơ sở dữ liệu được thay đổi từ quay vòng sang lưu trữ và một việc sao lưu cơ sở dữ liệu đầy đủ phải được tiến hành Một việc sao lưu được tiến hành khi cơ sở dữ liệu đang ghi log quay vòng là không đủ khi chuyển đổi các hình thức ghi log và một sao lưu mới phải được tiến hành

6 Thực hiện sao lưu cơ sở dữ liệu đầy đủ bằng cách sử dụng một lệnh như sau đây:

o BACKUP DATABASE db_name TO d:\db_name\backup

7 Thử kết nối đến cơ sở dữ liệu một lần nữa Lần này nó sẽ thành công

Các thực hành tốt nhất để giữ cho dữ liệu an toàn

Đây là một vài thực hành tốt nhất để giữ an toàn cho dữ liệu của bạn:

1 Giữ cơ sở dữ liệu của bạn ở dạng log lưu trữ để trong trường hợp có sự cố bạn có thể phục hồi lại cơ sở dữ liệu đến một thời điểm riêng

2 Tiến hành thường xuyên các việc sao lưu cơ sở dữ liệu đầy đủ và sao lưu tăng dần (full and incremental database backups) Các đòi hỏi về nghiệp vụ cuối cùng thì cũng yêu cầu viết lịch biểu và tần suất thực hiện sao lưu

3 Lúc nào cũng giữ một bản sao rập khuôn hoặc bản dự phòng cơ sở dữ liệu nếu đó là cơ sở dữ liệu thiết yếu

4 Giữ các tệp log hoạt động và log lưu trữ tại các địa chỉ khác nhau, với mỗi địa chỉ có đủ không gian đĩa

5 Đảm bảo tham số cơ sở dữ liệu BLK_LOG_DSK_FUL được đặt ở giá trị

YES bằng cách sử dụng lệnh sau đây:

o UPDATE DB CFG FOR db_name USING BLK_LOG_DSK_FUL

YES

Việc đặt BLK_LOG_DSK_FUL là YES làm cho các ứng dụng bị treo khi DB2 gặp phải một lỗi vì hệ thống tệp đang giữ các tệp log đã đầy Việc này cho phép bạn giải quyết được lỗi và cho phép việc chạy các giao dịch được hoàn tất Bạn có thể giải quyết một lỗi đĩa log bị đầy bằng cách chuyển các tệp log cũ lên hệ thống tệp khác hoặc bằng cách mở rộng hệ thống tệp

Các kịch bản phục hồi

Điều quan trọng là phải hiểu được cách các sự cố có thể xảy ra và cách phục hồi chúng Các phần sau đây mô phỏng các kiểu sự cố khác nhau và trình bày một loạt các bước mà có thể được làm theo để phục hồi từ chúng

Kịch bản 1 Toàn bộ cơ sở dữ liệu vô tình bị mất hoặc bị hỏng

Kịch bản này chỉ ra cách phục hồi từ một cơ sở dữ liệu hỏng hoàn toàn Tình trạng này có thể xảy ra nếu cơ sở dữ liệu vô tình bị mất hoặc bị hư hỏng hoặc không bền vững do một lỗi thủ công hoặc do hư hỏng phần cứng Trong các trường hợp như thế này, bạn có thể phục hồi cơ sở dữ liệu hoàn toàn bằng cách áp dụng sao lưu cơ

sở dữ liệu đầy đủ lần cuối Kịch bản này dựa trên cấu hình hiển thị trong Bảng 1

Bảng 1 Cấu hình hệ thống sử dụng trong kịch bản phục hồi 1

Hệ điều hành Windows XP Service Pack 2 / RHEL 4.0

Bước 1 Thực hiện sao lưu cơ sở dữ liệu đầy đủ

Để thực hiện sao lưu bên ngoài cơ sở dữ liệu đầy đủ, các lệnh sau đây có thể được chạy:

Phải chắc chắn để ý đến định danh được tạo ra trong tên tệp sao lưu Nó trông

tương tự như: 20060411154219 Định danh này đơn giản chỉ là nhãn thời gian của

ảnh sao lưu và cần đến trong quá trình khôi phục

Bước 2 Mô phỏng một sự cố

Để mô phỏng một kịch bản sự cố, mất hoàn toàn cơ sở dữ liệu:

 FORCE APPLICATION ALL

Bây giờ, thử kết nối đến cơ sở dữ liệu:

Lỗi sau đây được báo lên, nó báo cho biết cơ sở dữ liệu không còn ở đó:

Error: SQL1013N Không thể tìm thấy tên bí danh cơ sở dữ liệu hoặc tên cơ

sở dữ liệu “testdb1”

Bước 3 Tạo một cơ sở dữ liệu mới

Để bắt đầu quá trình phục hồi, tạo một cơ sở dữ liệu mới có cùng tên của cơ sở dữ liệu bị mất:

Bảo đảm cơ sở dữ liệu được tạo ra và được vào danh mục chính xác bằng cách quan sát nội dung của thư mục cơ sở dữ liệu:

Bước 4 Khôi phục cơ sở dữ liệu

Khôi phục ảnh sao lưu cơ sở dữ liệu Trong ví dụ này, bạn khôi phục một ảnh sao

lưu với nhãn thời gian 20060411154219:

20060411154219 INTO testdb1

Thông điệp cảnh báo sau đây được trả về:

SQL2523W: Khôi phục một cơ sở dữ liệu hiện tại khác với cơ sở dữ liệu trên ảnh sao lưu Cơ sở dữ liệu đích sẽ bị ghi đè bởi phiên bản sao lưu Các log khôi phục cuộn tiến liên kết với cơ sở dữ liệu đích sẽ bị ghi đè

Gõ Y để tiếp tục Việc này khôi phục sao lưu cơ sở dữ liệu qua cơ sở dữ liệu vừa

được tạo ra từ bước trước Một khi ảnh đã được khôi phục, cơ sở dữ liệu là bền vững đến điểm mà sao lưu được thực hiện

Bước 5 Kết nối đến cơ sở dữ liệu

Thử kết nối đến cơ sở dữ liệu:

Thông báo lỗi sau đây có thể được trả về:

SQL1117N Một kết nối đến hoặc kích hoạt của cơ sở dữ liệu “testdb1” không thể thực hiện được vì Đang chờ Cuộn tiến (Roll-Forward Pending)

SQLSTATE=57019

Điều này có thể xảy ra vì việc kiểm tra sự bền vững phải xảy ra bằng cách sử dụng một số tệp log Chạy lệnh sau đây để đưa cơ sở dữ liệu sang trạng thái bền vững:

Thử kết nối cơ sở dữ liệu một lần nữa:

Bước 6 Xác thực cơ sở dữ liệu và các đối tượng

Kiểm tra lại xem các đối tượng tồn tại trước đây còn ở đó và sẵn sàng để dùng không, ví dụ:

Kịch bản 2 Một vùng chứa không gian bảng vô tình bị mất hoặc hỏng

Kịch bản này thể hiện cách phục hồi từ một tình trạng khi một hoặc nhiều vùng chứa không gian bảng mất hoặc bị hỏng Tình trạng này có thể phát sinh do lỗi của người (chẳng hạn như một người sử dụng xoá một thư mục hoặc tệp) hoặc vì một vấn đề hỏng tệp dữ liệu Kịch bản này dựa trên cấu hình trình bày trong Bảng 2

Bảng 2 Cấu hình hệ thống sử dụng trong kịch bản phục hồi 2

DB2 V9.1 ESE fixpak 1

Tên cơ sở dữ liệu TESTDB1

Tên không gian

Các vùng chứa

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

Bước 1 Kiểm kê lại tất cả các không gian bảng được xác định

Bước 2 Kiểm kê lại tất cả các thông tin vùng chứa không gian bảng

“1” trong lệnh trên đây là định danh không gian bảng đối với không gian bảng TS1 trong môi trường này Nó thu được do kết quả của lệnh LIST TABLESPACES SHOW DETAIL trước đó Lệnh này sẽ cần được lặp lại đối với mỗi định danh không gian bảng được sử dụng

Bước 3 Sao lưu không gian bảng

 FORCE APPLICATION ALL

c:\testdb1\backup\ts1

Như bạn đã biết, kịch bản này giả định rằng bạn đã thực hiện sao lưu các không gian bảng thiết yếu nhất cho mục đích phục hồi

Bước 4 Mô phỏng một sự cố không gian bảng

Mô phỏng thủ công trường hợp trong đó tệp vùng chứa không gian bảng bị một người sử dụng vô ý xoá nhầm:

trả về thông báo lỗi sau đây:

SQL0290N Không được phép truy cập không gian bảng.

Bạn cũng có thể kiểm tra tình trạng không gian bảng bằng cách chạy lệnh sau đây:

Sau khi các vùng chứa bị xoá, lệnh trên đây chỉ ra tình trạng của TS1 là 0x400, có nghĩa là nó đang ở trạng thái offline và không thể truy cập được Do ba vùng

chứa đã bị xoá, không gian bảng không còn giữ nguyên trạng thái bình thường nữa

(0x000)

Nếu bạn chạy lại lệnh LIST TABLESPACE CONTAINERS bạn có thể kiểm tra lại các vùng chứa nào bị mất hoặc không sẵn có nữa:

Trong các kết quả, tình trạng Accessible sẽ chỉ No đối với các vùng chứa C1, C2,

và C3

Bước 6 Khôi phục ảnh sao lưu không gian bảng

Để khôi phục ảnh sao lưu, chạy các lệnh sau đây:

C:\TESTDB1\BACKUP\TS1

Bước 7 Kiểm tra tình trạng không gian bảng

Phải chắc chắn rằng các vùng chứa là có thể truy cập được:

Nếu khôi phục thành công, tình trạng của không gian bảng TS1 sẽ là bình thường

(0x000) và tất cả các vùng chứa phải có thể truy cập được

Bước 8 Kiểm tra lại khôi phục thành công

Ghi chú: Bạn có thể gặp phải một tình huống là sau khi khôi phục không gian

bảng, sau đó cần phải có động tác phục hồi nữa Việc này có thể xảy ra nếu có bất

kỳ thay đổi tệp log nào mà chưa được áp dụng để làm cho cơ sở dữ liệu bền vững Trong trường hợp này, chỉ cần chạy một trong các lệnh sau đây để hoàn tất phục hồi:

HOẶC

Các lệnh trên đây áp dụng cho bất kỳ tệp log còn lại nào và đưa cơ sở dữ liệu đến trạng thái bền vững

Kịch bản 3 Một bảng vô tình bị lược bỏ

Trong một số môi trường cơ sở dữ liệu với hàng nghìn bảng, đôi khi một bảng bị lược bỏ do nhầm lẫn Trong kịch bản này, bạn xem cách phục hồi một bảng mà vô tình bị mất Để có thể thực hiện kiểu phục hồi này, cơ sở dữ liệu của bạn phải được cấu hình để ghi log lưu trữ và phải sẵn có một ảnh sao lưu cơ sở dữ liệu đầy

đủ Để một bảng bị mất có thể phục hồi được, không gian bảng mà bảng nằm trong đó phải có tuỳ chọn DROPPED TABLE RECOVERY được bật Việc này có thể được đặt trong khi tạo không gian bảng, hoặc bằng cách dẫn ra lệnh ALTER