đề thi quản trị cơ sở dữ liệu phân tán 10

hiện trên cùng một máy tính nếu các yêu cầu nhiệm vụ không đòi hỏi các máy tính riêng rẽ. Truy vấn có thể vận hành hqua hơn vì chúng có thể truy nhập cục bộ hay các ban sao ở gần  Cập

CHƯƠNG V: PHỤC HỒI SỰ CỐ (số tiết 5 )

CHƯƠNG V: PHỤC HỒI SỰ CỐ

5 1 Sự cố trong CSDL phân tán

Vấn đề-hậu quả/các loại sự cố/phân loại

Các loại sự cố

Từ 79-84 là thống kê của một số hãng về sự cố.

DO LƯỜNG HIGH AVAILABILITY MEASUREMENTS

There are three types of metrics to measure high availability:

THE MEAN TIME TO RECOVERY (MTTR)

It measures the average time to recover/restore a system after each failure

THE MEAN TIME BETWEEN FAILURES (MTBF)

It measures frequency of system failure occurs It is generally more applicable to hardware

availability metrics

TOTAL UPTIME IN A YEAR (%)

It measures the percentage of time the system is up and available in a year The table below

shows the percent of system uptime in a year from a 5 minutes downtime to a 2 days downtime

CÁC NGUYÊN NHÂN LỖI (CAUSE OF DOWNTIME)

There are two types of downtime: (Bất thường và có kế hoạch)

• Accidentally drops, truncates a table

• Accidentally delete, update rows in a table

• Accidentally delete a data file or drop a tablespace

• Disasters

• War, terrorism

• Earthquake, flood, fire or hurricane

• No power for a long period

• Server crush, malfunction of hardware

Sự cố phương tiện- Kiến trúc đầy đủ (flush: fetch: )

Trong cách tiếp cận client-server với xử lý và dữ liệu phân tán, cả tài nguyên xử

lý và dữ liệu được trải trên nhiều site Khả năng xử lý của 1 server có thể rộng từ một trạm đến 1 máy tính lớn

Vì cách tiếp cận mô hình client-server cung cấp tính linh hoạt cho việc sử dụng tiềm năng phù hợp nhiệm vụ, nên phần mềm client và server thậm chí có thể thực

Database Database

hiện trên cùng một máy tính nếu các yêu cầu nhiệm vụ không đòi hỏi các máy tính riêng rẽ.

 Truy vấn có thể vận hành hqua hơn vì chúng có thể truy nhập cục

bộ hay các ban sao ở gần

 Cập nhật chậm hơn vì mọi bản sao phải được cập nhật

• Xác suất mà hệ thống không sự cố trong một thời gian cho trước

• Thường dùng để mô tả hệ thống không bị sửa chữa hay thao tác làm việc găng ở đâu

-Tính sẵn sàng

• Phần thời gian mà hệ thống gặp đặc tả của nó

• Xác suất hệ thống làm việc trong thời gian t đã cho

- Failure: Sự chuyển hướng một hệ thống khỏi mô tả đã đặc tả của nó

- Erronous State: Trạng thái của hệ thống trong đó tồn tại các hoàn cảnh việc

xử lý hơn nữa theo thuật toán thông thường dẫn đến sự cố không định trước.

- Errors: Một phần trạng thái làm việc không đúng

- Faults: Lỗi trạng thái nội tại của các thành phần hệ thống hay thiết kê hệ thống.

Fault to Failure

 How Failure Affects Recovery (Sự cố ảnh hưởng đến khôi phục như thế nào)

– Thoát bất kỳ giao dịch nào bị ảnh hưởng bởi sự cố.

– Lập cờ của site khi sự cố.

– Kiểm tra thường kỳ xem liệu site đã được khôi phục chưa

– Khi khởi tạo lại, site phải khởi tạo thủ tục phục hồi.

– Sau khi phục hồi cục bộ, site phải cập nhật các bản sao của nó đẻ tạo sự nhất quán cho phần còn lại của hệ thống.

– Nếu xuất hiện mạng phân chia, DDBMS phải đảm bảo điều đó sẽ thiết lập lại.

 Distributed Recovery Protocols(Cac giao thức phục hồi phân tán)

– Một sự cố ở một site nên giữ lại các site khác treo

– Điều này được gọi là “non-blocking”

– Mọi giao dịch tổng thể nên có bộ phối hợp hay bộ quản trị giao dịch.

– Mọi site ở đó giao dịch xuất hiện được gọi là site tham gia

 Two-Phase Commit (Chuyển giao 2 pha)

– Pha bầu cử và pha quyết định

– Bộ phối hợp hỏi mọi site xem chúng đã sẵn sàng chuyển giao hay chưa Một site đơn bất kỳ có thể thoát (thoát đơn phương), nó thoát mọi site khác

– Bộ phối hợp gửi “PREPARE” Mỗi tham gia đáp ứng hoặc

“READY_COMMIT” hoặc “ABORT”

– Nếu nhận được “ABORT” , Bộ phối hợp gửi một thông điệp “GLOBAL ABORT”

– Nếu tất cả gửi “READY_COMMIT”, Bộ phối hợp gửi “GLOBAL COMMIT”

– Nếu một tham gia timeout, mặc định nó thoát

– Tại điểm này, các giao thức kết thúc hay phục hồi được thực hiện.

06 và 07 cho xử lý câu hỏi

05 cho ham băm

Dia2\dbbs\ppt\baigiang codex\ ch17

Notes05-1DSK.ppdf

CÁc hàm băm mở rộng

+ Có thể điều khiển các file đang tăng kích thước

• Với không gian tiêu tốn

• Không tổ chức lại đầy đủ

+ Không trực tiếp

(Không tệ nếu tmuc trong bộ nhớ)

+ Gấp đôi tmuc về kích thước

(Phù hợp/không phù hợp)

Băm tuyến tính

• Các lược đồ băm động khác

(a) Sử dụng các bít bậc thấp để băm (b) Các file lớn tuyến tính

• Điều khiển tương tranh(ch.9)

• Xử lý giao dịch nhiều hơn (ch.10)

• Tính nhất quán hay toàn vẹn dữ liệu:

Liệu dữ liệu có “chính xác ” và đúng trong mọi thời gian không?

• Các ràng buộc nhất quán và toàn vẹn dữ liệu:

o Các dự báo dữ liệu phải thỏa mãn

o Các vd:

 X là khóa quan hệ R

 X-> y giữ trong R

 Domain(x)={Red, Blue,Green}

 α hợp lệ cho thuộc tính x của R

 Không có người làm nào làm gấp 2 lần lương trung bình

Ví dụ- Các tài khoản ngân hàng

• Kiểm tra tài khoản * Gdich

• Lưu tài khoản - Chuyển n$ vào tkhoan để kiểm tra

- - Rút M$ từ tài khoản

• Customer

o Kết nối tài khoản : Tôi và vợ tôi

o Bạn GIAO DịCH 1:

Tôi chuyển $100 từ quỹ(Saving) để kiểm tra Điều này vận hành như thế nào?

• Lệnh Read quỹ trong giao dịch

• Lệnh READ kiểm tra trong giao dịch

• Tinh toán Quỹ và Kiểm tra mới

• Write quỹ đến bộ đệm ra

• WRITE Kiểm tra đên bộ đệm ra

Giao dịch 1 với Crash:(Tôi đã chuyển $100 từ quỹ đến Kiểm tra) Nó vận hành như thế nào?

• Lệnh READ quỹ trong giao dịch

• Lênh READ Kiểm tra trong giao dịch

• Tính toán Quỹ và Kiểm tra mới

• Trạng thái nhất quán: thỏa mãn mọi ràng buộc

• DB nhất quán: DB trong trạng thái nhất quán

Các ràng buộc(như chúng ta dùng ở đây) có thể không bắt hoàn toan đúng

VD1: Các ràng buộc giao dịch

• Khi lương được cập nhật: lương mới> lương cũ

• Khi bản ghi tài khoản bị xóa: cân đối=0

Chú ý : có thể mphong các ràng buộc đơn giản , VD

Tài khoản

Các ràng buộc(như chúng ta dùng ở đây) có thể không bắt hoàn toan đúng VD2: Csdl nên phản anh thế giới thực

Sẽ không xem xét:

• Viết các giao dịch đúng như thế nào

• Viết các csdl đúng như thế nào

• Kiểm tra và sửa ràng buộc

Nghĩa là các giải pháp được nghiên cứu ở đây không cần biết các ràng buộc.

Chương 8: Khôi phục

Thứ tự đầu tiên của business: Mô hình Sự cố

Sự kiện -> Yêu cầu

Không yêu cầu -> Chờ đợi

Không chờ đợi

Mô hình sự cố của chúng ta

Các sự kiện chờ đợi: xem các tài liệu sản phẩm

Các sự kiện không chờ đợi:

Hệ thống sự cố

• Mất bộ nhớ

• Dừng CPU, thiết lập lại

Có nghĩa là : mọi vấn đề còn lại!

Bổ sung các kiểm tra mức thấp+ dư thừa để tăng mô hình xác suất giữ

VD: Nhân bản bộ nhớ đĩa (bộ nhớ ổn định)+ parity bộ nhớ + kiểm tra CPU

Thứ tự thứ hai của business:

Phân cấp bộ nhớ

Các thao tác

• Input(x) : khối với x -> bộ nhớ

• Output(x): khối với x-> đĩa

• Read(x,t): thực hiện input(x) nếu cần t nhận giá trị của x trong khối

• Write(x,t): thực hiện input(x) nếu cần giá trị của x trong khối nhận t

Vấn đề cơ bản: giao dịch không kết thúc

• Một giải pháp: nhật ký undo(bdoi trung gian)

Nhật ký undo (bdoi trung gian)

Một “sự phức tạp”

• Nhật ký được ghi đầu tiên vào bộ nhớ

• Không được ghi vào đĩa trên mỗi hoạt động

•

Ở ĐÂU?

= =

CH17 OHIO

PHụC HồI NANG CAO: NHUNG DAC DIEM CấU HÌNH

n Support for high-concurrency locking techniques, such as those used for B+ tree concurrency control, which release locks early

-l Supports “logical undo”

n Recovery based on “repeating history”, whereby recovery executes exactly the same actions as normal processing

l including redo of log records of incomplete transactions, followed by subsequent undo

l Key benefits

 supports logical undo

 easier to understand/show correctness

PHụC HồI TRươC: NHậT KÝ UNDO LOGIC

n Operations like B+-tree insertions and deletions release locks early

l They cannot be undone by restoring old values (physical undo), since once a lock is released, other transactions may have updated the B+- tree.

l Instead, insertions (resp deletions) are undone by executing a

deletion (resp insertion) operation (known as logical undo)

n For such operations, undo log records should contain the undo operation to

 delete of tuple, to undo insert of tuple

– allows early lock release on space allocation information

 subtract amount deposited, to undo deposit

– allows early lock release on bank balance PHụC HồI NANG CAO:REDO VAT LY

n Redo information is logged physically (that is, new value for each write) even for operations with logical undo

l Logical redo is very complicated since database state on disk may not

be “operation consistent” when recovery starts

l Physical redo logging does not conflict with early lock release

PHNC: NHậT KÝ THAO TÁC

n Operation logging is done as follows:

1 When operation starts, log <Ti, Oj, operation-begin> Here Oj is a unique identifier of the operation instance.

2 While operation is executing, normal log records with physical redo and physical undo information are logged

3 When operation completes, <Ti, Oj, operation-end, U> is logged,

where U contains information needed to perform a logical undo

<T1, O1, operation-end, (delete I9, K5, RID7)>

n If crash/rollback occurs before operation completes:

l the operation-end log record is not found, and

l the physical undo information is used to undo operation.

n If crash/rollback occurs after the operation completes:

l the operation-end log record is found, and in this case

l logical undo is performed using U; the physical undo information for

the operation is ignored.

n Redo of operation (after crash) still uses physical redo information.

PHụC HồI NÂNG CAO :Txn ROLLBACK

Việc ROLLBACK của giao dịch Ti được thực hiện như sau:

n Scan the log backwards

1 If a log record <Ti, X, V1, V2> is found, perform the undo and log a

special redo-only log record <Ti, X, V1>.

2 If a <Ti, Oj, operation-end, U> record is found

 Rollback the operation logically using the undo information U.

– Updates performed during roll back are logged just like during normal operation execution

– At the end of the operation rollback, instead of logging

an operation-end record, generate a record

<Ti, Oj, operation-abort>.

 Skip all preceding log records for Ti until the record

<Ti, Oj operation-begin> is found

n Scan the log backwards (cont.):

3 If a redo-only record is found ignore it

4 If a <Ti, Oj, operation-abort> record is found:

H skip all preceding log records for Ti until the record

<Ti, Oj, operation-begin> is found.

5 Stop the scan when the record <Ti, start> is found

6 Add a <Ti, abort> record to the log

n Some points to note:

n Cases 3 and 4 above can occur only if the database crashes while a

transaction is being rolled back.

n Skipping of log records as in case 4 is important to prevent multiple rollback

of the same operation.

ß T1 Rollback begins here

<T1, Z, 45> ß redo-only log record during physical undo (of incomplete O2)

<T1, Y, , > ß Normal redo records for logical undo of O1

…

<T1, O1, operation-abort> ß What if crash occurred immediately after this?

<T1, abort>

PHụC HồI NÂNG CAO : PHụC HồI Sự Cố (CRASH)

The following actions are taken when recovering from system crash

1 (Redo phase): Scan log forward from last < checkpoint L> record till end of

log

1 Repeat history by physically redoing all updates of all transactions,

2 Create an undo-list during the scan as follows

 undo-list is set to L initially

 Whenever <Ti start> is found Ti is added to undo-list

 Whenever <Ti commit> or <Ti abort> is found, Ti is deleted

from undo-list

This brings database to state as of crash, with committed as well as

uncommitted transactions having been redone.

Now undo-list contains transactions that are incomplete, that is, have neither

committed nor been fully rolled back.

Recovery from system crash (cont.)

2 (Undo phase): Scan log backwards, performing undo on log records of

transactions found in undo-list

l Log records of transactions being rolled back are processed as

described earlier, as they are found

 Single shared scan for all transactions being undone

l When <Ti start> is found for a transaction Ti in undo-list, write a <Ti

abort> log record.

l Stop scan when <Ti start> records have been found for all Ti in

undo-list

n This undoes the effects of incomplete transactions (those with neither commit nor abort log records) Recovery is now complete.

PHụC HồI NÂNG CAO : DIEM KIểM TRA

n Checkpointing is done as follows:

1 Output all log records in memory to stable storage

2 Output to disk all modified buffer blocks

3 Output to log on stable storage a < checkpoint L> record.

n Transactions are not allowed to perform any actions while

checkpointing is in progress.

n Fuzzy checkpointing allows transactions to progress while the most time consuming parts of checkpointing are in progress

l Performed as described on next slide

DIEM KIểM TRA MO’`

n Fuzzy checkpointing is done as follows:

1 Temporarily stop all updates by transactions

2 Write a <checkpoint L> log record and force log to stable storage

3 Note list M of modified buffer blocks

4 Now permit transactions to proceed with their actions

5 Output to disk all modified buffer blocks in list M

H blocks should not be updated while being output

H Follow WAL: all log records pertaining to a block must be output before the block is output

6 Store a pointer to the checkpoint record in a fixed position

last_checkpoint on disk

n When recovering using a fuzzy checkpoint, start scan from the checkpoint record pointed to by last_checkpoint

l Log records before last_checkpoint have their updates reflected in database on disk, and need not be redone.

l Incomplete checkpoints, where system had crashed while performing checkpoint, are handled safely

• Nhật ký redo/undo, tại sao lại cả 2?

• Các hoạt động của thế giới thực

• Điểm kiểm tra

Các luật của nhật ký redo

(1) Với mọi hoạt động, phát sinh bản ghi redo(chứa giá trị mới)

(2) Trước khi X bị thay đổi trên đĩa(DB), mọi bản ghi nhật ký cho giao dịch thay đổi

X (bao gồm COMMIT) phải trên đĩa

(3) Dồn nhật ký tại thời điểm COMMIT

Các luật phục hồi: Lập nhật ký phục hồi

• Với mọi Ti mà <Ti, COMMIT> trong nhật ký:

o Write (X,v)

o Output (X)

Liệu điều này có đúng không?

(1) Cho S=tập các giao dịch với <Ti,COMMIT> trong nhật ký (2) Với mỗi <Ti,X,v> trong nhật ký, theo thứ bậc đi tiếp (earleast-> latest)

Giải pháp : Điểm kiểm tra (phiên bản đơn giản ) Định kỳ

(1) Không chấp nhận các giao dịch mới

(2) Chờ đến khi mọi giao dịch kết thúc

(3) Dồn mọi bản ghi nhật ký lên đĩa (nhật ký)

(4) Dồn mọi bộ đệm lên đĩa (DB)-không dập bộ đệm

(5) Viết bản ghi “điểm kiểm tra” lên đĩa(nhật ký)

(6) Tiếp tục xử lý giao dịch

VD: Làm gì lúc kphuc? Dãy các <Ti,> trước khi crash

Nhược điểm cơ bản:

• Nky ud: Ko thể đem các bản sao DB cnhat

• Nky redo: Cần phải giữ mọi khối đã biến đổi trong bộ nhớ cho đến khi com

• Cả hai: Nếu 2 gdich tdoi dlieu trong cùng khối, cthe có các hdong mâu thuẫn đặt ra

Giải pháp : nhật ký undo /redo!

Cập nhật => <Ti,Xid,new X val, Old X val> page X

Các luật

• Trang X có thể được dồn trước hay sau Ti com

• Bản ghi nhật ký được dòn trước trang cập nhật tương ứng(WAL)

• Dồn lúc COMMIT (chỉ nhật ký )

•

ĐIểm kiểm tra ko-yên tĩnh

LOG<=…bắt dầu điểm ktra active Tr:T1,T2…kthuc điểm ktra……

Cho ud ß  Các trang pool đệm bẩn

VD: ở thời điểm khôi phục làm cái gì

Undo T1(undo, a,b) lấy giá trị b cho T1, không chuyển giao T1

Các hoạt động thực tế VD dispense tiền ở ATM

S

Giải pháp

(3) Vận hành cac hoạt động thực sau COMMIT

(4) thử tạo nên idempotent

VD

Rút tiền ATM theo Giao dịch ID, thời gian và số tiền Sự cố phương tiện (mất bộ nhớ non-volatile)

Gphap: tạo các bản sao dữ liệu

VD#1: dư thừa 3 modul

• Giữ 3 bản sao trên đĩa riêng rẽ

• Output(X) -> 3 lượng ra

• Input(X)-> 3 đầu vào + vote

VD #2: Các ghi dư thừa, các đọc đơn

• Giữ N copy trên các đĩa riêng rẽ

• Output(X)-> N output

• Input(X)-> đưa vào 1 bản sao

o Nếu OK, thực hiện

o Khác đi, thử lại lần nữa Giả thiết dữ liệu xấu có thể bị phát hiện

VD #3: DB dump + Log

Nếu csdl active bị mất

• nạp lại csdl active từ backup

• thực hiện cập nhật lại dung toàn bộ redo trong nhật ký

o Với các giao dịch có cả hai bản ghi “begin_transaction” hay

“end_of_transaction” trong nhật ký, một redo riêng phần sẽ được ktao bởi LRM

o Với cac giao dịch chỉ có 1 “begin_transaction” trong nhật ký, một undo tổng thể được vận hành nhờ LRM

• Abort

• COMMIT

• Phục hồ Fix/No-Flush

• Abort

o Không trang cập nhật nào được ghi vào csdl ổn định

o Giải phóng trang được fix

• COMMIT

o Ghi 1 bản ghi “end_of_transaction” vào nhật ký

o LRM gửi 1 lệnh unfix đến bộ quản trị bộ đệm cho mọi trang đã fix

o Không có trang cập nhật nào được ghi vào csdl ổn định

o Giải phóng các trang cố dinh.

• COMMIT

o LRM công bố lênh flush cho bộ quản trị bộ đệm đối với mọi trang

được cập nhật

o LRM gửi 1 lệnh unfix đến bộ quản trị bộ đệm cho mọi trang đã

được cố định (fix) trước đó

o LRM ghi 1 bản ghi “end_of_transaction” vào nhật ký.

1/ Viết một bản ghi begin_checkpoint vào nhật ký

2/Tập hợp các dữ liệu điểm kiểm tra vào bộ nhớ ổn định

3/ Viết một bản ghi end_checkpoint vào nhật ký.

Các giao thức tin cậy phân tán

- Các giao thức chuyển giao

• Xác định các lệnh chuyển giao cho các giao dịch phân tán như thế nào

• Công bố: Đảm bảo tính ntu và bền vứng như thế nào?

- Các giao thức kết thúc

• Nếu sự cố xuất hiện, làm so có thể duy trì các site lqun làm việc bình thường

• Non-blocking: Sự xuất hiện sự cố không nên buộc các site chờ cho tới khi

sự cố được sửa để kết thúc giao dịch.

- Các giao thức phục hồi

• Khi sự cố xuất hiện, các site ở đó làm việc thế nào?

• Indipendent: site sự cố có thể xác định đầu ra của 1 giao dịch mà không

cần giành được thông tin ở xa.

- Phục hồi độc lập=> kết thúc không khóa(non-blocking)

= = = =

5 2 Dự phòng lỗi (sao lưu)

= = =

DESIGN OF FAULT TOLERANT SYSTEMS

1 Basic Concepts : Reliability Concept, Failures and faults, Reliability and failure rate, RelationBetween reliability & mean time between failure, maintainability & Availability Reliability ofSeries and parallel Systems

2 Test Generation : Fault diagnosis of digital Systems, Test generations for combinational logiccircuits – conventional methods, Random testing, transition count testing and signatureanalysis

3 Fault Tolerant Design – I : Basic concepts – static, dynamic, hybrid, and self – purgingredundancy, Sift – out Modular redundancy (SMR) ,triple modular redundancy, 5MRreconfiguration, use of error correcting codes

4 Fault Tolerant Design – II : Time redundancy, software redundancy, fail – soft operation ,examples of practical fault tolerant systems, introduction to fault tolerant design of VLSI chips

5 Self Checking Circuits : Design of totally self checking checkers , checkers using m-out of ncodes, Berger codes and low cost residue code, self – checking sequential machines,partially self – checking circuits

6 Fail safe Design : Strongly fault secure circuits, fail – safe design of sequential circuits usingpartition theory and Berger codes, totally self – checking PLA design

7 Design for testable combination logic circuits : Basic concepts of testability, controllability andobservability The Read – Muller expansion technique, level OR-AND-OR design, use ofcontrol and syndrome – testable design.

8 Testable Design of sequential Circuits : The scan – path technique, level – sensitive scandesign (LSSD) and random Accers scan technique, built – in – test, built – in – test of VLSIchips, design for autonomous self – test, design in testability into logic boards

= = =

Sao lưu và phục hồi sự cố tạo nên sự bảo vệ CSDL chống sự mất dữ liệu , tái cấu trúc dữ liệu Đạt được thông qua các phương tiện phục hồi nhiều tao tác liên quan đến , rolling forward, và rolling back một sao lưu file CSDL Chương bao gồm liên quan thiết kế chiến lược sao lưu và phục hồi :

• Giới thiệu Backup

• Giới thiệu phục hồi

• Quyết định sử dụng kỹ thuật phục hồi nào

• Vùng phục hồi flash

Introduction to Backup

Backup: sao chép dữ liệu Bản sao có thể bao gồm những phần quan trọng của CSDL như file điều khiển và file dữ liệu

Có thể có 2 loại: physical backups và logical backups

Physical backups: copy các file CSDL vật lý Có thể dùng tiện ích Recovery Manager (RMAN) logical backups: chứa các dữ liệu logic (VD, tables và stored procedures) lấy với một tiện ích Oracle và lưu dạng file nhị phân, hỗ trợ physical backups

Có 2 cách : Recovery Manager và user-managed :

Recovery Manager (RMAN) là tiện ích có thể back up, restore, và recover database files Là đặc điểm của Oracle database server và không yêu cầu cài đặt riêng

user-managed backup and recovery : Cũng có thể dùng các lệnh OS và SQL*Plus for recovery Đươc Oracle hỗ trợ đầy đủ dù RMAN được khuyến cáo dùng nhiều hơn

RMAN /user-managed có thể bổ sung saolwu vật lý với sao lưu logic bằng dùng tiện ích Export/ Import để nạp và khôi phục dữ liệu.

Phân này gồm:

• Consistent and Inconsistent Backups

• Whole Database and Partial Database Backups

• RMAN and User-Managed Backups

Sao lưu nhất quán và không nhất quán

consistent backup: file được sao lưu chứa toàn bộ sự thay đổi của cùng số thay đổi hệ thống

system change number (SCN)

inconsistent backup: : sao lưu một hay nhiều file CSDLđược thực hiện khi file mở hay đóng bất thường (không tốt)?

Tổng quan Consistent Backups

A consistent backup of a database or part of a database is a backup in which all read/write datafiles and control files are checkpointed with the same SCN

The only way to make a consistent whole database backup is to shut down the database with theNORMAL, IMMEDIATE, or TRANSACTIONAL options and make the backup while the database is closed If a database is not shut down cleanly, for example, an instance fails or you issue a SHUTDOWN ABORT statement, then the database's datafiles are always inconsistent—unless the database is a read-only database

Oracle makes the control files and datafiles consistent to the same SCN during a database

checkpoint The only tablespaces in a consistent backup that are allowed to have older SCNs are read-only and offline normal tablespaces, which are still consistent with the other datafiles in the backup because no changes have been made to them

The important point is that you can open the database after restoring a consistent whole

database backup without needing recovery because the data is already consistent: no action is required to make the data in the restored datafiles correct Hence, you can restore a year-old consistent backup of your database without performing media recovery and without Oracle performing instance recovery Of course, when you restore a consistent whole database backup without applying redo, you lose all transactions that were made since the backup was taken

A consistent whole database backup is the only valid backup option for databases operating in NOARCHIVELOG mode, because otherwise recovery is necessary for consistency In

NOARCHIVELOG mode, Oracle does not archive the redo logs, and so the required redo logs

might not exist on disk A consistent whole backup is also a valid backup option for databases operating in ARCHIVELOG mode When this type of backup is restored and archived logs are available, you have the option of either opening the database immediately and losing

transactions that were made since the backup was taken, or applying the archived logs to recover those transactions

Tổng quan Inconsistent Backups

Không chứa toàn bộ sự thay đổi ở mọi SCNs (một vài thay đổi có thể mất) Khi khôi phục đọc mọi logs redo online và archived với SCN sớm nhất(?)trong bất kỳ datafile headers file dữ liệu và

áp dụng những thay đổi này và các data file

Nếu 24/7(online backup) và chạy CSDL trong chế độ ARCHIVELOG mode Nếu vậy không cần backup toàn bộ CSDL tại một thời điểm

Oracle khuyến cáo không chạy inconsistent, backup CSDK được đóng trong NOARCHIVELOG mode Sẽ mất CSDL

Các khái niệm Archiving/ Unarchived Redo Log Files/ Backing Up the Archived Logs and the Control File

Sao lưu toàn phần và riêng phần CSDL

( Whole Database and Partial Database Backups)

This section contains the following topics:

• Whole Database Backups

• Tablespace Backups

• Datafile Backups

• Control File Backups

• Archived Redo Log Backups

Whole Database Backups

A whole database backup sao lưu mọi file dữ liệu trong CSDL và các file điều khiển Kiểu chung của sao lưu Có thể là ARCHIVELOG / NOARCHIVELOG Cần lưu ý trước sao lưu

Figure 15-1 illustrates the valid configuration options given the type of backup that is performed

Figure 15-1 Whole Database Backup Options

Description of "Figure 15-1 Whole Database Backup Options"

Cũng có thể sao lưu consistent backup / inconsistent backup

• Mọi file dữ iệu được backup Không thể khôi phục nêu các file CSDL chưa backup

• Các datafiles là read only /hay offline-normal

RMAN and User-Managed Backups

Có hai kểu backups: copy image và các tập hợp backup image copy là duplicate chính xác datafile, control file, hay archived log Có thể tạo image copies của các physical files với các tiện ích OS hay RMAN, và có thể phục hồi chúng bằng chính tiện ích này

Khác với tiện ích của OS, RMAN phù hợp các khối trong file và các bản ghi sao chép trong repository(?)

backup set là sao lưu khuôn dạng sở hữu riêng chứa một hay nhiều các fie vật lý (backup pieces) Phải dùng RMAN đẻ phục hồi backup set

RMAN with Online Backups

Vì backup online khi viết nên có thể không nhất quán nên dù RMAN / OS

Trong RMAN thì Oracle đọc lại khối dữ liệu xem khối có bị nứt không (fractured)cho tới khi được hình ảnh nhất quán dữ liệu

Khi dùng tiện ích OS để backup cần có các phương pháp để giám sát các khối nứt gãy Trước hết đặt các file trong chế độ backup bằng câu lệnh ALTER TABLESPACE BEGIN BACKUP (backuptablespace riêng ),hay ALTER DATABASE BEGIN BACKUP (với toàn bộ database) Sau khi online backup hoàn tất thì phải chạy câu lệnh ALTER TABLESPACE END BACKUP / ALTER

DATABASE END BACKUP để chuyển các tablespace khỏi chế độ backup

Khi cập nhật file vào chế độ backup,dữ liệu redo được lưu nhật ký Nó được lưu bằng tiện ích

OS

Control File Backups (Backup các file đkhiển)

Các control file rất cần thiết

Có thể dùng RMAN để backup tự động khi chạy các công việc backup Câu lệnh CONFIGURE CONTROLFILE AUTOBACKUP Tên file mặc định cho sao lưu tự động nên có thể restore ngay cả khi RMAN repository không có sẵn Rất hữu dụng trong kịch bản phục hồi thảm họa

Có thể backup bằng một số phương pháp sau:

• Lệnh RMAN: BACKUP CURRENT CONTROLFILE tạo sao lưu các file điều khiển hay tập hay sao chép các ảnh

• Lệnh SQL : ALTER DATABASE BACKUP CONTROLFILE tạo backup nhị phân các file điềukhiển

• Lệnh SQL: ALTER DATABASE BACKUP CONTROLFILE TO TRACE xuất các file điều khiểnthành file script SQL Có thể dùng script để tạo ra file điều khiển mới Cách này có nược điểm lớn: Không chứa bản ghi hay các logs redo và các bản sao lưu và copy RMAN Vì vậy binary backups được ưa thích hơn

Sao lưu log backup lưu trữ (Archived Redo Log Backups)

Archived redo logs are essential for recovering an inconsistent backup The only way to recover an inconsistent backup without archived logs is to use RMAN incremental backups To be able to recover a backup through the most recent log, every log generated between these two points must be available In other words, you cannot recover from log

100 to log 200 if log 173 is missing If log 173 is missing, then you must halt recovery at log 172 and open the database with the RESETLOGS option.

Vì log redo lưu trữ là thực chất phục hồi nên cần thường xuyên backup.Nếu cần backup

nó lên băng từ.

Có thể sao lưu log backup lưu trữ bằng các phương pháp:

• Lệnh RMAN : BACKUP ARCHIVELOG command

• Lệnh RMAN : BACKUP PLUS ARCHIVELOG command

• Tiện ích của OS

5 3 Các giải pháp

Đề cương

• Giới thiệu

• Ktruc CSDL phân tán

• Thiết kê truy vấn csdl phân tán

• Điều khiển tương tranh phân tán

• Các giao thức ttcay phân tán

o Các giao thức chuyển giao phân tán

o Các giao thức phục hồi phân tán

• Các giao thức chuyển giao

o Vận hành lệnh chuyển giao cho các giao dịch phân tán như thế nào

o Công bố: Làm sao đảm bảo tính nguyên tử và tính bền vững

• Các giao thức kết thúc

o Nếu sự cố xuất hiện, các site làm việc còn lại cư xử(deal with) với

nó như thế nào

o Không khóa(non-blocking): Sự xuất hiện sự cố không nên buộc

các site chờ cho tới khi sự cố được sửa để kết thúc giao dịch.

• Các giao thức phục hồi