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

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.
Minutes of Downtime
5
60
1440
Minutes of Uptime
525595

525540
524160
Minutes in a Year
525600
525600
525600
Total Uptime in a Year (%)
99.9990%
99.9886%
99.7260%

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)

UNPLANNED DOWNTIME
•

•

Corruptions
• Logical corruptions
• Physical corruptions
Human Errors

2880
522720
525600
99.4521%

•

• 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

PLANNED DOWNTIME
•

•

•

•

Database Maintenance
• Backup
• Upgrade/Patching
Operating System Maintenance
• Upgrade/Patching
• Periodic reboot server
Hardware Maintenance
• Adding memory and CPUs
• Replacing parts
Network Maintenance

Oracle provides four popular high availability solutions:


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

Server

fetch:

)

Server

Client

Client

Client

Client

Database

Database

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


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

Nhân bản(Replication)


Một trong những cơ chế hqua nhất trong csdl phân tán.



Tăng cường


Tính sẵn sàng




Nếu 1 site nhân bản bị down, dữ liệu có thể được truy nhập từ site
khác

Hiệu năng


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.

Ozumi
Làm sao duy trì được tính ntu và tính bền vững của giao dịch
Các định nghĩa cơ bản:

- Độ tin cậy
• Mô tả sự thành công của 1 hệ thống tuân thủ(conform) đặc tả chính
thức(authortative) nào đó các hành vi của nó

•
•

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


===
HẬU QUẢ Sự Cố


Why things fail
–

Mất thông điệp.

–

Sự cố của liên kết truyền thông .

–

Sự cố site.

–

Việc chọn giá trị time-out rất khó.
ĐÊ PHÒNG Sự Cố

PHụC HồI Sự cố






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.

–

3 PHASE COMMIT

Protocols

–

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

–

Bộ phối hợp hay tham gia có thể time out

–

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

–



Bộ phối hợp có thể sự cố trong trạng thái ktao, Chờ hay Quyết
định.



Các tham gia có thể sự cố trong trạng thái Initial, Prepared,
Aborted/Committed

Nếu tham gia mất bộ phối hợp của chúng, chúng có thể bầu lại một bộ phối
hợp mới.

–
===
===

Dia2\dbbs\ppt\baigiang ohio\Notes08-1dsk và 2dsk
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


•

Vd

Dia2\dbbs\ppt\baigiang ohio\Notes08-1dsk

(cắt hình rời xong)
PHụC HồI Sự Cố.
Nội dung
• Phục hồi crash(ch.8)

• Đ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?
Bảng EMP
Name
White
Green
Gray

Age
52
2341
1
•

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
• WRITE Quỹ đến bộ đệm ra
• CRASH
GIAO DịCH 2:
Tôi và anh cùng rút $100 từ ATM đồng thời

• Tôi
- READ quỹ của anh
- Trừ $100
- Trả $100
- WRITE cân đối mới

-

• Anh
READ quỹ của tôi
Trừ $100
Trả $100
WRITE cân đối mới

-

• Vợ tôi
READ quỹ của chúng tôi
Trừ $100
Trả $100
WRITE cân đối mới

GIAO DịCH 3:
Tôi và vợ cùng rút $100 từ ATM đồng thời
-

• Tôi
READ quỹ của chúng tôi
Trừ $100
Trả $100

WRITE cân đối mới

Định nghĩa:
•
•

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
Acct#
...
balance
Deleted?


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!
VD:
• Dữ liệu đĩa mất
• Bộ nhớ mất không có dừng CPU
• CPU implodes wiping out universe...

Mô hình này có phù hợp?
Cách tiếp cận:
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
VD Ràng buộc: A=B
T1: A <- A x 2
B <- B x 2

T1: Read(A,t); t<- t x 2
Write (A,t);
Read(B,t); t<- t x 2
Write (B,t);
Output(A);
Sự cố
Output(B);

•
•

Cần tính nguyên tử: Hoặc vân hành mọi hoạt động giao dịch hoặc
không gì cả
Một giải pháp: nhật ký undo(bdoi trung gian)
Nhật ký undo (bdoi trung gian)

T1: Read(A,t); t<- t x 2
Write (A,t);
Read(B,t); t<- t x 2
Write (B,t);
Output(A);
Output(B);

A=B


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
be executed
l Such logging is called logical undo logging, in contrast to physical
undo logging
 Operations are called logical operations
l Other examples:
 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
information.
n Example: insert of (key, record-id) pair (K5, RID7) into index I9
<T1, O1, operation-begin>
….
<T1, X, 10, K5>
<T1, Y, 45, RID7>
<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


n

n
n
n

<Ti, Oj, operation-abort>.
 Skip all preceding log records for Ti until the record
<Ti, Oj operation-begin> is found
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
Some points to note:
Cases 3 and 4 above can occur only if the database crashes while a
transaction is being rolled back.
Skipping of log records as in case 4 is important to prevent multiple rollback
of the same operation.

VD Txn ROLLBACK
n Example with a complete and an incomplete operation
n
<T1, start>
<T1, O1, operation-begin>

….
<T1, X, 10, K5>
<T1, Y, 45, RID7>
<T1, O1, operation-end, (delete I9, K5, RID7)>
<T1, O2, operation-begin>
<T1, Z, 45, 70>
ß 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 abort> log record.
l Stop scan when <Ti start> records have been found for all Ti in undolist
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

==
Dia2\dbbs\ppt\baigiang ohio\Notes08-2dsk

Notes08-2DSK.ppdf

Bàn về:
• Nhật ký redo
• 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 sự cố ptien.

Lập nhật ký redo(biến thể khác đi deferred modification)
T1: Read(A,t);t <- t x 2;write(A,t);
Read(B,t);t <- t x 2;write(B,t);
Output(A);Output(B);


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)
 Nếu Ti ⊂S thì
o Write (X,v)
o Output (X) <--???(optioned)

Khôi phục rất chậm

Bản ghi đầu tiên(1 năm) | ... | T1 đã ghi A,B-chuyển giao 1 năm trước-> vẫn cần redo sau
khi crash | ....| .....|.... | bản ghi cuối | ..CRASH..
Phục hồi rất chậm


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
....|<Ta,A,16>|....
|<T1,COMMIT> |..|Checkpoint
|...<T2,B,17> |...
|T2,COMMIT> |..
|<T3,C,21> |...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

Ti=a1a2…….ai…….an
↓


S
Giải pháp
(3)
(4)

Vận hành cac hoạt động thực sau COMMIT
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ý
có thể dập nhật ký khi nào
Nky<-ko càn ????(trước điểm dump db)<-không cần undo sau khi sự cố hệ thống
(trước điểm ????)<- ko cần redo sau khi sự cố hệ thống (trước điểm ktra )
•
•
•

===

Nhất quán dữ liệu
1 nguồn gốc các vấn đề : sự cố
o Nhật ký
o Dư thừa
Các nguồn gốc khác:
o Chia xẻ dữ liệu …..tiếp