Sử dụng phương pháp định tên trong thời điểm để khôi phục trở lại Database bằng kỹ thuật Flashback.

Posted: April 10, 2008 in HowTo, Oracle, Tips
Tags: ,

Nguồn: ITGateVN


Tính năng Flashback recovery là một trong những tính năng mới của phiên bản Oracle 10g (gird), bài dịch sau đây từ tạp chí thường niên của Oracle sẽ giúp chúng ta có cái nhìn tổng quát về tính năng này.
Jane, trưởng nhóm DBA tại ngân hàng Acme Bank, hôm nay tiếp 3 vị khách mời. Paul, người đầu tiên, trưởng phòng bảo đảm chất lượng, đội ngũ của Paul tạo ra một số các kịch bản cho công việc, ở mỗi kịch bản, họ phải đưa dữ liệu thử cùng một lúc, sau đó, chạy kiểm tra chúng, cái họ cần là sửa lại dữ liệu và đưa chúng trở lại trạng thái ban đầu trước khi kiểm thử.

Vị khách thứ hai là Tom, giám đốc một chi nhánh. Tom có trách nhiệm đối với một số các gói tiến trình trao đổi lợi nhuận qua lại từ một chi nhánh của ngân hàng. Nếu như một trong số đó bị lỗi, tiến trình cập nhập sẽ bị ngưng lại và phải bắt đầu lại từ đầu

Vị khách thứ ba là Harry, quản lý kinh doanh của đơn vị phát triển chương trình ứng dụng cho một hãng thứ ba. Hary cập nhập dữ liệu từ chi nhánh, sửa lại cấu trúc Database, và hơn thế nữa, đó là một phần trong tiến trình nâng cấp chương trình ứng dụng. Hầu hết các phần nâng cấp đều chạy ổn định, tuy nhiên, khi một tiến trình nâng cấp bị lỗi, mọi thứ sẽ trở nên mất kiểm soát. Đội của Harry phải mất một thời gian tương đối lâu để khôi phục lại.

Paul, Tom và Hary đều yêu cầu Jane giúp họ thực hiện các tiến trình này một cách hiệu quả, Jane đảm bảo rằng cô đã có cách giải quyết. Rất may mắn, Acme đang sử dụng Oracle Database 10g Release 2, và nó có thể “khôi phục” lại Database tới một thời điểm đã được định danh trước đó.

Cài đặt

Jane và các vị khách ngồi xuống, cô nói với tất cả họ về việc làm sao có thể “quay lại” và phục hồi lại Database tại thời điểm biết trước đó bằng một câu lệnh đơn giản: Flashback recovery. Trong Oracle Database 10g Release 2, Jane nói, chức năng này đã được cải thiện một cách đặc biệt với khả năng định danh một thời điểm chỉ rõ tại thời gian nào đó, và nó được gọi bằng một thuật ngữ : “Restore time”. Sử dụng phương pháp này, cả Paul, Tom và Harry (hoặc những DBA có quyền quản trị) có thể đánh dấu và khôi phục lại Database tại thời điểm logic nào đó.

Jane bắt đầu mô tả trên một Database thử nghiệm. Cô lưu ý, Database này phải được chạy ở chế độ Archivelog và tính năng Flashback phải được kích hoạt. Đầu tiên, cô tắt – shut down Database và mở chúng lên ở chế độ mounted….

Mã:
SQL> Shutdown immediate;
SQL> Startup mount;

Sau đó, cô đưa Database chạy ở chế độ Archivelog

Mã:
SQL> Alter database archivelog;

Để kích hoạt tính năng flashback, đầu tiên Jane đưa 2 tham số cho Database…

Mã:
SQL> Alter system set db_recovery_file_dest_size = 2G;
SQL> Alter system set db_recovery_file_dest = ‘/u02/flashbackarea/acmeprd’;

Ở chế độ flashback này, Database sẽ tự tạo các file log cho flashback – flashback log file, sẽ ghi lại các hình ảnh cũ của dữ liệu sau khi có sự thay đổi. Các file này được lưu giữ trong địa chỉ được chỉ ra ở tham số db_recovery_file_dest, kích cỡ (hay dung lượng) sẽ được chỉ ra ở tham số db_recovery_file_dest_size, trong trường hợp này là 2GB.

Jane kích hoạt tính năng flashback….

Mã:
SQL> Alter database flashback on;

Tiếp đó, cô “mở” Database:

Mã:
SQL> Alter database open;

Kiểm tra tình trạng của chế độ archive và flashback…

Mã:
SQL> Select flashback_on, log_mode
From V$database;

Nếu kết quả hiện ra như sau:

Mã:
FLASHBACK_ON         LOG_MODE
————           ———-
YES               ARCHIVELOG

Có nghĩa nó đã xác định tình trạng database đã kích hoạt tính năng Archivelog và Flashback

Restore points

Jane tiến hành công việc mô tả cách restore points bằng một ví dụ với đội ngũ QA của Paul, cô đặt tên cho một “restore point” là qa_gold

Mã:
SQL> Create restore point qa_gold;

“Với câu lệnh trên”, Jane nói, nó chỉ có từ phiên bản Oracle Database 10g Release 2. Nó tạo ra một tên của restore point này, và nó chính là 1 alias đăng ký với SCN (system change number) của Database tại thời điểm được tạo.

Jane chạy một trong những chương trình test của QA, sửa đổi dữ liệu test. Để Flashback lại Database tới điểm “restore point” vừa được tạo, Jane shutdown Database, sau đó khởi động lại tại chế độ Mounted, và đưa ra câu lệnh flashback

Mã:
SQL> Shutdown immediate;
SQL> Startup mount;
SQL> Flashback database to restore point qa_gold;

Và, Database được đưa trở lại tới điểm “restore point” có tên là qa_gold. Không cần thiết phải backup Database và thực hiện recovery point-in-time. Paul cảm thấy không thể hạnh phúc hơn được nữa.

Với Tom, Jane thực hiện hơi khác, bởi vì Tom thường chạy các gói chương trình tại một thời điểm, nên Jane đề nghị tạo ra một restore point sau khi đã chạy từng gói với một tiền tố định danh trước, ví dụ: after_branch_n, với n là Branch_id. Để theo dõi những tiến trình chạy, Tom tạo ra một table PROC chỉ có một column là Bracnh_ID, lưu trữ những id của các chi nhánh mà các gói dữ liệu sẽ chạy..

– Jane tạo một restore point và đặt tên nó là start_branch để đánh dấu việc khởi động tiến trình chạy gói dữ liệu

Mã:
SQL> Create restore point start_batch

– Cập nhập dữ liệu vào table PROC

Mã:
SQL> Update proc set bracnh_id = 1;
SQL> Commit;

– Cô tiến hành chạy file từ branch 1
– Sau khi chạy file từ branch 1, cô tạo ra một restore point

Mã:
Create restore point after_branch 1;

Công việc cứ lặp lại như thế sau khi tòan bộ gói chương trình từ các branch được chạy xong xuôi..

Jane bắt đầu mô tả việc restore lại các tiến trình chạy này nếu một file từ branch thứ 23 bị lỗi, Branch_ID này có giá trị là 23 trong table PROC..

Mã:
SQL> Select branch_id from proc;
BRANCH_ID
—————-
23

Nếu như tiến trình bị lỗi từ branch thứ 23, thì Jane sẽ rollback lại thay đổi đó từ restore point của branch thứ 22

Mã:
SQL> Shutdown immediate;
SQL> Startup mount;
SQL> Flashback Database to restore after_branch_22;
SQL> Alter database open;

Để chắc chắn rằng công việc flashback đã thành công, cô check lại table PROC một lần nữa

Mã:
SQL> Select branch_id from PROC;
BRANCH_ID
—————-
22

Giá trị của column là 22, có nghĩa branch file của một restore point đã được tạo, tất cả các thay đổi đối với Database sau khi tạo restore point đều đã được làm lại.

Đôi khi, file từ một branch bị lỗi nhưng nó lại không được biết tới sau đó, với trường hợp này, tiến trình chạy file của branch 23 đã lỗi, nhưng nó không được biết cho tới tận khi tiến trình chạy của branch thứ 29, Jane đảm bảo với Tom rằng, khi anh chạy tiến trình file của branch thứ 22, branch thứ 29 hay bất kỳ file nào giữa chúng, anh đều có thể dễ dàng rollback lại tới restore point after_branch_22.

Riêng với yêu cầu của Harry, Jane đề nghị một giải pháp tương tự như đối với Paul. Harry hoặc một DBA trong nhóm anh tạo ra một restore_point và đặt tên nó là pre_change, nếu như tiến trình chạy ứng dụng không thành công, thì cả Harry và DBA đều cần flashback Database tới restore point, và sử dụng câu lệnh flashback mà cô vừa mô tả ở trên.

Guarantee Restore Point

Paul, Tom và Harry rời văn phòng của Jave và trở về chỗ họ để kiểm tra lại giải pháp restore-point này

Vài giờ sau, Tom quay lại văn phòng của Jane với một thong báo lỗi, khi anh cố gắng flashback lại tới điểm restore-point, thì anh gặp lỗi

Mã:
ORA-38729: Not enough flashback database log data to do FLASHBACK.

Như thông báo lỗi đưa ra, ngh ĩa l à không có đủ flashback logs dành cho việc flashback lại Database tới restore-point. “Thực ra việc này rất đơn giản”, Jane giải thích, “các file logs được giữ lại tới một thời điểm được chỉ định, nằm trong tham số db_flashback_retention_target_database. Các file logs cũ không tự động bị xoá đi, size tối đa dành cho vùng flashback được xác định bằng tham số db_recovery_file_dest_size, trong trường hợp này là 2GB. Khi vùng dành cho flashback của Tom đã đầy đến 2GB, thì Oracle Database sẽ bắt buộc phải xoá bớt đi các file logs cũ, nhưng với thời gian là 1.440s nhằm tạo ra vùng trống cho các file logs mới. Do đó, khi Tom muốn thực hiện công việc flashback, nó gây ra lỗi khi các file logs cần thiết dung cho restore point đã bị hết hạn, và điều đó gây ra lỗi.

Tom hỏi Jane phải làm cách nào khắc phục, Jane nói, rất đơn giản với việc đưa them một câu lệnh đảm bảo cho việc đó…

Mã:
SQL> create restore point after_branch_22
guarantee flashback database;

“Guarantee” đảm bảo rằng ta có thể flashback lại Database tới restore point có tên là after_branch_22 và Oracle Database không đánh dấu chúng là các file logs đã hết hạn sử dụng

Quản trị

Sau khi trả lời câu hỏi của Tom, Jane gọi cho đội ngũ DBA của cô để đảm bảo rằng họ đã hiểu cách quản trị restore point. Đầu tiên, cô chỉ cho họ cáchc query để tìm ra có bao nhiêu restore point đã được tạo….

Mã:
SQL> select * from v$restore_point order by scn;

Kết quả hiện ra trong Listing 1, Jane mô tả các column, “Name là tên của restore point, SCN và Time là SCN (system change number) và thời điểm của từng restore point được tạo, Guarantee_Flashback_Database (GUA) chỉ ra restore point nào được đặt thêm phần guarantee trong lúc tạo, Storage_size chỉ ra restore point đó chiếm bao nhiêu không gian tạo, tuy nhiên với restore point được đặt thêm phần Guarantee, nó nhất thiết không phải là một số 0, và cuối cùng Database_Incarnation# chỉ ra Database incarnation nào khi tạo restore point. Nếu Database đã được flashback, và sau đó open reset logs mới, thì nó sẽ tạo ra một incarnation mới cho database

Mã:
Code Listing 1: Output of V$RESTORE_POINT
SCN        DATABASE_INCARNATION#   GUA   STORAGE_SIZE   TIME                              NAME
——–   ———————   —-  ————   ——————————-   ————
14390197   6                       NO    0              01-AUG-06 01.12.27.000000000 PM   QA_GOLD
24390219   6                       NO    0              01-AUG-06 02.13.16.000000000 PM   AFTER_BRANCH_1
34390232   6                       NO    0              01-AUG-06 03.13.34.000000000 PM   AFTER_BRANCH_2
44390243   6                       NO    0              01-AUG-06 04.13.49.000000000 PM   AFTER_BRANCH_3
54394187   7                       YES   3981312        02-AUG-06 05.35.19.000000000 AM   AFTER_BRANCH_4

Khi có những restore point nào không cần thiết, các bạn có thể xoá chúng”, Jane tiếp tục, cô đưa ra câu lệnh xoá một restore point làm ví dụ…

Mã:
SQL> drop restore point after_branch_1;

Kết luận
Sử dụng phương pháp này – restore point, DBA có thể đánh dấu vị trí nào đó tại một thời điểm nhất định, và sau đó có thể đưa Database trở về vị trí được định sẵn trong thời điểm này. Bảng 1 tổng kết một số các kịch bản khác nhau và cách sử dụng phương pháp restore point này:
1. Một số các gói chương trình không cố ý gây ra lỗi cho Database, do đó, yêu cầu phải đưa Database trở lại vị trí trước khi chạy các gói chương trình này (poin – in – time recovery): Tạo từng restore point trước khi mỗi một gói chương trình được chạy, flashback lại Database tới restore point đó

2. Schema Database triển khai hoặc nâng cấp, mà yêu cầu thay đổi những schema mở rộng hơn gây ra lỗi, kết quả là Database sẽ ở trạng thái inconsistent (không nhất quán) sẽ phải khôi phục lại (point – in – time): Tạo một restore point trước những triển khai này, sau đó, flashback lại Database tới restore point nếu chương trình triển khai xảy ra lỗi.

3. Đội ngũ QA đã cẩn thận tạo ra các dữ liệu kiểm tra, nhưng sau khi chạy, dữ liệu bị thay đổi và cần thiết phải tái tạo lại trước khi phần kiểm tra được chạy: Tạo ra một restore point trước mỗi một lần kiểm thử, Flashback lại Database tới restore point sau mỗi lần chạy kiểm tra.

site statistics

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s