Chuẩn bị cho kỳ thi 730 cơ bản về DB2 9, Phần 6: Nhất quán dữ liệu
Roger Sanders, Quản lý cao cấp, EMC
Tóm tắt: Bài viết này giới thiệu khái niệm cơ bản của tính nhất quán cơ sở dữ
liệu và các cơ chế khác nhau trong sử dụng của DB2 để cho phép làm việc trong
cả môi trường dữ liệu một người dùng và nhiều người dùng. Đây là bài viết thứ 6
trong bảy bài viết hỗ trợ bạn bắt đầu làm việc với DB2 9 trên hệ điều hành Linux,
UNIX, và Windows™ chuẩn bị cho bài thi lấy chứng chỉ 730.
Trước khi bạn bắt đầu
Về loạt bài viết này
Suy nghĩ về việc có được/đạt được chứng chỉ DB2 (Bài thi số 730)? Để đạt được
điều này bạn tiếp cận một cách chính xác theo các hướng dẫn. Đây là loạt bài gồm
bảy bài viết chuẩn bị cho cuộc thi lấy chứng chỉ DB2 loạt bài viết này giới thiệu
mọi thứ cơ bản cần thiết Các chủ đề này bạn cần phải hiểu rõ trước khi bạn làm
bài kiểm tra đầu tiên. Thậm chí kể cả khi bạn chưa có kế hoạch để có được chứng
chỉ này, thì tập hợp các bài viết này vẫn là nơi tốt để bạn tìm hiểu xem cái gì mới
khi sử dụng DB2 9.
Về bài viết này
Bài viết này sẽ chỉ dẫn cho bạn khái niệm cơ bản nhất của tính nhất quán dữ liệu
và các cơ chế khác nhau được sử dụng bởi DB2 9 trong Linux, UNIX và Windows
để thực thi được trong cả hai môi trường cơ sở dữ liệu một người và nhiều người
sử dụng.
Đây là bài viết thứ sáu trong loạt bảy bài viết bạn có thể sử dụng để chuẩn bị cho
các bài thi Cơ bản về DB2 9 (DB2 9 Fundamental). Điểm trọng yếu của bài viết
này là giới thiệu các mục tiêu chính, đó là "tính nhất quán của dữ liệu". Bạn có thể
xem các mục tiêu này tại: http://www-03.ibm.com/certify/tests/obj730.shtml. Các đối tượng
Sau khi hoàn thành bài học này, bạn có thể:
 Xác định các nhân tố ảnh hưởng đến việc thực hiện khóa
 Danh sách các đối tượng được điều khiển

Bạn không cần thiết phải có bản sao chép của DB2 9 để hoàn thành bài học này.
Tuy nhiên, bạn sẽ nhận được nhiều kết quả của bài học này hơn nếu bạn tải phiên
bản dùng thử của IBM DB2 9 để làm việc trong bài học này.

Các phiên làm việc
Tìm hiểu tính nhất quán dữ liệu
Tính nhất quán dữ liệu là gì? Cách để đưa được câu trả lời tốt nhất cho câu hỏi này
đó làm dựa vào ví dụ. Công ty bạn làm việc là một chuỗi các nhà hàng và công
việc bạn cần làm là xây dựng một cơ sở dữ liệu để có thể lưu trữ được dữ liệu cho
từng nhà hàng này. Để phiên làm việc giải quyết vấn đề này đơn giản, cơ sở dữ
liệu của bạn chứa bảng thống kê cho từng nhà hàng trong chuỗi các nhà hàng. Mỗi
khi hàng hóa được cung cấp hoặc được sử dụng bởi từng nhà hàng riêng biệt thì
bảng thống kê tương ứng của từng nhà hàng sẽ được sửa chữa tương ứng phù hợp
với thay đổi đó.
Bây giờ, khi có một số chai nước sốt cà chua được di chuyển từ một nhà hàng này
tới một nhà hàng khác. Khi đó, bảng thống kê báo cáo sẽ bị thay đổi tương ứng, số
chai nước sốt cà chua của nhà hàng ban đầu cần phải giảm bớt đi và số chai nước
sốt cà chua của nhà hàng nhận sẽ được tăng lên tương ứng. Nếu bạn chỉ giảm số
chai nước sốt cà chua của nhà hàng ban đầu mà lại không tăng được số chai nước
sốt cà chua của nhà hàng nhận trong bảng thống kê, dữ liệu sẽ trở lên mâu thuẫn -
và vì thế tổng số chai nước sốt cà chua của chuỗi nhà hàng là không được chính
xác.
Dữ liệu trong cơ sở dữ liệu có thể trở lên mâu thuẫn nếu người dùng quên thực
hiện các thao tác thay đổi cần thiết (như trong ví dụ trước), nếu hệ thống bị phá vỡ
trong khi người dùng đang thực hiện các thay đổi hoặc khi ứng dụng cơ sở dữ liệu
vì một lý do nào đó bị dừng đột ngột. Sự mâu thuẫn cũng có thể xảy ra khi các
người sử dụng truy cập đến cùng một bảng cơ sở dữ liệu tại cùng một thời gian.
Để tránh việc xảy ra mâu thuẫn dữ liệu, đặc biệt phải thận trọng khi sử dụng trong
môi trường nhiều người dùng, DB2 được thiết kế hỗ trợ để tránh sự mâu thuẫn
trong dữ liệu:

Điều quan trọng là trong khi phiên làm việc cung cấp cơ sở dữ liệu đảm bảo thì sự
thay đổi dữ liệu chỉ bị ngắt sau khi phiên làm việc được thực hiện thành công, điều
đó dẫn tới người dùng hay các ứng dụng cho phép đảm bảo rằng một dãy các xử lý
SQL được thực hiện trong mỗi phiên làm việc luôn luôn đưa ra kết quả trong cơ sở
dữ liệu xác định. Hiệu quả của các xử lý COMMIT và ROLLBACK
Chú ý rằng, các phiên làm việc thường bị ngắt khi thực thi câu lệnh SQL dạng
COMMIT hay ROLLBACK. Để hiểu rõ các câu lệnh này làm việc như thế nào,
bạn tham khảo tới ví dụ trong phần này.
Nếu theo các câu lệnh SQL được hiển thị phần sau:

Ví dụ 1. Dòng công việc đơn giản gồm ba phiên làm việc

CONNECT TO MY_DB
CREATE TABLE DEPARTMENT (DEPT_ID INTEGER NOT NULL,
DEPT_NAME VARCHAR(20))
INSERT INTO DEPARTMENT VALUES(100, 'PAYROLL')
INSERT INTO DEPARTMENT VALUES(200, 'ACCOUNTING')
COMMIT

INSERT INTO DEPARTMENT VALUES(300, 'SALES')
ROLLBACK

INSERT INTO DEPARTMENT VALUES(500, 'MARKETING')
COMMIT Kết quả, bảng DEPARTMENT được tạo ra có dạng như sau:

thể lưu giữ cơ sở dữ liệu phù hợp với giả định là có tồn tại ngay từ khi phiên làm
việc được khởi tạo. Hình 1 so sánh tác dụng của phiên làm việc thành công với các
phiên làm việc bị lỗi trước khi nó được ngắt thành công

Hình 1. So sánh sự giữa phiên làm việc thành công và không thành công
Các mức độ độc lập và thống nhất
Điều gì không thể xảy ra khi nhiều người dùng cùng truy cập đến một cơ sở dữ
liệu
Trong các môi trường một người dùng, mỗi một phiên làm việc chạy liên tục và
không xảy ra đụng độ với các phiên làm việc khác. Tuy nhiên, trong môi trường
nhiều người sử dụng các phiên làm việc có thể (và thường xuyên) xảy ra tình trạng
cùng chạy đồng thời tại một thời điểm. Trong trường hợp này, mỗi một phiên làm
việc chạy tuần tự có tiềm tàng khả năng cản trở với các phiên làm việc chạy ở chế
độ chen vào hoặc song song, điều này có nghĩa là các kết quả của chạy song song
đồng thời nhận được so với các kết quả chạy tuần tự. Khi các phiên làm việc song
song được sử dụng trong các môi trường nhiều người dùng, có bốn trường hợp hay
các điều ngoại lệ có thể xảy ra:
 Cập nhật thiếu (Lost update): Điều này xảy ra khi hai phiên làm việc
cùng đọc và sau đó cập nhật cho cùng một dữ liệu và khi đó có một trong
hai phiên làm việc cập nhật bị mất. Ví dụ: Phiên làm việc 1 và Phiên làm
việc 2 cùng đọc một dòng của dữ liệu và cả hai đều thực hiện tính toán dựa
trên dữ liệu đã đọc được. Nếu Phiên làm việc 1 thực hiện cập nhật giá trị
mới cho hàng và Phiên làm việc 2 cũng thực hiện tương tự thì thao tác xử
lý cập nhật của Phiên làm việc 1 là bị mất. Bởi vì vậy nên DB2 được thiết
kế không cho phép xảy ra trường hợp đặc biệt này.
 Đọc dư thừa (Dirty read): Điều này xảy ra khi mà phiên làm việc thực
hiện đọc dữ liệu không được xem xét. Ví dụ: Phiên làm việc 1 thay đổi

lượng lớn của sự đồng nhất (một số các phiên làm việc có thể được truy cập tới
cùng một nguồn cùng lúc). Mức đọc độc lập không xem xét cung cấp mức lớn
nhất của sự thống nhất nhưng cho phép cả ba trường hợp đặc biệt để xảy ra. Mức độc lập của đọc lặp lại
Mức độc lập của đọc lặp lại là mức độc lập giới hạn tốt nhất. Khi nó được sử
dụng, hiệu quả của một phiên làm việc là hoàn toàn độc lập từ tác dụng của phiên
làm việc đồng nhất khác: đọc dư thừa, đọc không lặp lại, và không xảy ra. Với
việc đọc lặp lại mọi hàng có thể được tham chiếu trong manner bởi phiên làm việc
thuộc quyền sở hữu và các dòng này là bị khóa trong suốt quá trình thực hiện
phiên làm việc. Với kết quả này, nếu cùng một câu lệnh SELECT được sử dụng
hai hoặc nhiều lần hơn trong cùng một phiên làm việc, tập kết quả thu được luôn
luôn là giống nhau. Hơn thế, phiên làm việc chạy ở mức độc lập này có thể khôi
phục cùng một tập các hàng nhiều lần và thực hiện xử lý các thao tác đó cho đến
khi bị ngắt bởi xử lý xác nhận thực hiện lệnh hay quay trở lại. Tuy nhiên, một
phiên làm việc khác được ngăn chặn từ việc thực hiện chèn, cập nhập hoặc xóa thì
điều này có thể ảnh hưởng đến bất kỳ hàng nào đã được truy cập thành công bởi
phiên làm việc khi mà phiên làm việc dư thừa ra. Để bảo đảm cho hành động này,
mỗi một hàng được tham chiếu đến bởi một phiên làm việc xác định được khóa lại
- không cho các hàng này được khôi phục hoặc sửa chữa tiếp. Vì thế nếu phiên
làm việc quét qua 1,000 dòng để khôi phục 10 dòng thì khóa được yêu cầu và đánh
dấu tất cả 1,000 dòng đó cho đến khi 10 dòng được khôi phục.
Làm thế nào mức độc lập đọc lặp lại làm việc được trong tình huống thế giới thực?
Vì mục đích này bạn có thể sử dụng cơ sở dữ liệu DB2 để lưu giữ các bản ghi của
khách sạn bao gồm thông tin đặt chỗ và thông tin các phòng và bạn có ứng dụng
dựa trên nền Web để cho phép các cá nhân riêng lẻ có thể đặt phòng cho những
lần đến đầu tiên một cách đơn giản. Nếu ứng dụng dành riêng của bạn chạy dưới
mức độc lập đọc lặp lại, khách hàng quét cơ sở dữ liệu để hiển thị các phòng chưa
thuê để họ đăng ký ngày thuê và đồng thời cung cấp cho bạn (người quản lý) để

dòng này được xuất hiện như các dòng ảo trong tập dữ liệu của chuỗi kết quả. Sự
thay đổi này làm cho các dòng khác của các phiên làm việc khác không thể được
xử lý cho đến khi dòng đang xử lý được thực hiện.
Mức độc lập đọc ổn định thay đổi cách đặt phòng khác sạn của bạn như thế nào?
Khi khách hàng quét cơ sở dữ liệu để xem danh sách các phòng còn trống để đặt
phòng bạn sẽ có thể thay đổi trạng thái cho bất kỳ phòng nào không có trong danh
sách của khách hàng đó. Ngược lại, các khách hàng khác sẽ không thể thực hiện
hoặc hủy bỏ việc đặt chỗ của khách hàng khác đã đặt từ đầu nếu cùng một truy
vấn giống vậy đã được chạy lần nữa. Nếu khách hàng đầu tiên thực hiện truy vấn
để tìm phòng trống để đặt phòng trong cùng một ngày thì danh sách danh sách có
thể chứa phòng đặt mới và/hoặc phòng đó không được đặt cho lần đầu tiên đăng
ký. Đặc tính này được mô tả trong Hình 3.

Hình 3. Ví dụ của mức độc lập đọc ổn định
Mức độc lập của tham khảo ổn định (Cursor)
Mức độ độc lập thao khảo ổn định là rất thú vị trong cách độc lập tác dụng của
một phiên làm việc tới các tác dụng của một phiên làm việc khác. Nó cung cấp
khả năng đọc các bản ghi thừa tuy nhiên trường hợp đọc các bản ghi không có khả
năng lặp lại và bản ghi ảo vẫn có thể có khả năng xảy ra. Điều đó bởi vì trong hầu
hết các trường hợp mức độ độc lập tham khảo ổn định chỉ khóa hàng đang được
tham chiếu bởi con trỏ soạn thảo đó là hàng được mô tả và mở bởi chính phiên
làm việc đang xử lý.
Khi một phiên làm việc sử dụng mức độc lập tham khảo ổn định để khôi phục
hàng từ bảng thông qua con trỏ khi đó không thể có phiên làm việc nào có thể cập
nhật hoặc xóa dòng mà con trỏ đang được đặt trong đó. Tuy nhiên, các phiên làm
việc khác có thể thêm hàng mới vào bảng cũng như cũng có thể cập nhật hoặc xóa
các dòng ở vị trí bên phía kia của các dòng đã được khóa - các dòng đã bị khóa


Mức độc lập của đọc không ràng buộc
Mức độc lập đọc không ràng buộc là mức độc lập cho phép ít hạn chế nhất. Trong
thực tế, khi mức độc lập này được sử dụng các hàng được khôi phục bởi phiên làm
việc chỉ được khóa nếu các phiên làm việc cố gắng làm giảm hoặc thay đổi bảng
chứa các hàng được khôi phục. Bởi vì các hàng thường không được mở khóa khi
mà mức độc lập này được sử dụng khi đó các bản ghi đọc thừa, đọc không lặp lại
và được giả lập có thể xảy ra. Vì thế, mức độc lập đọc không ràng buộc là kiểu cơ
bản được sử dụng cho các phiên làm việc cho phép truy cập các bảng chỉ đọc và
hiển thị và cho phép các phiên làm việc thực thi các lệnh SELECT để dữ liệu
không ràng buộc từ các phiên làm việc khác sẽ không có bất lợi tương ứng.
Khi đó, phiên làm việc chạy dưới mức độc lập đọc không ràng buộc có thể nhìn
thấy sự thay đổi đến các hàng bởi các phiên làm việc khác trước khi các thay đổi
này được thực hiện đầy đủ. Tuy nhiên, mỗi một phiên làm việc có thể hoặc nhìn
thấy hoặc không nhìn thấy bảng, nội dung và các chỉ số cái mà đã được làm yếu
đi; phiên làm việc sử dụng đọc không ràng buộc sẽ chỉ đọc những cái gì mà đối
tượng của nó không tồn tại lâu dài khi mà phiên làm việc thực hiện làm yếu đi
được thực hiện hoàn thành. (Có một chú ý rằng khi phiên làm việc chạy trong mức
độc lập không ràng buộc mà sử dụng chế độ cập nhật con trỏ phiên làm việc sẽ thu
được hiệu quả nếu đang chạy dưới chế độ độc lập tham khảo ổn định và sự bắt
buộc của mức độ độc lập tham khảo ổn định được áp dụng)
Vậy áp dụng mức độc lập đọc không ràng buộc như thế nào vào ứng dụng đặt chỗ
phòng khách sạn của bạn. Bây giờ, khi khách hàng duyệt cơ sở dữ liệu để có được
danh sách các phòng để có thể đặt chỗ bạn sẽ có thể thực hiện thay đổi giá cho bất
kỳ phòng nào trong khách sạn trong bất kỳ ngày nào. Ngược lại, các khách hàng
khác có thể thực hiện hoặc hủy bỏ đặt chỗ cho bất kỳ phòng nào trong khách sạn
bao gồm cả phòng mà khách hàng đang tìm kiếm. Thêm vào đó, danh sách các
phòng cho khách hàng đầu tiên có thể chứa các bản ghi của các phòng mà các
khách hàng khác đang xử lý để đặt chỗ và các phòng này thực sự là không có giá
trị. Đặc tính này được mô phỏng trong Hình 5

Mặc dù các mức độc lập điều khiển đặc trưng ở mức phiên làm việc chúng thường
được cài đặt tại mức ứng dụng:
 Để nhúng các ứng dụng SQL, mức độc lập được xác định trước thời gian
biên dịch hoặc khi ứng dụng được buộc tới cơ sở dữ liệu (nếu sự ràng buộc
hoãn lại được sử dụng). Trong trường hợp này, mức độc lập được đặt sử
dụng lực chọn là ISOLATION của câu lệnh PRECOMPILE hoặc câu lệnh
BIND.
 Đối với các ứng dụng Open Database Connectivity (mở cơ sở dữ liệu liên
kết - ODBC) và Call Level Interface (gọi mức giao diện - CLI), mức độc
lập được đặt tại thời gian chạy ứng dụng bởi lời gọi hàm
SQLSetConnectAttr() với thuộc tính kết nối
SQL_ATTR_TXN_ISOLATION được xác định. (Mức độc lập cho các ứng
dụng ODBC/CLI có thể được cài đặt bằng cách gán giá trị cho từ khóa
TXNISOLATION trong tệp định dạng db2cli.ini; tuy nhiên cách tiếp cận
này không cung cấp khả năng phức tạp để thay đổi các mức độc lập cho các
phiên làm việc khác nhau trong một ứng dụng riêng biệt cho lần tiếp cận
đầu tiên
 Đối với các ứng dụng Java Database Connectivity (Kết nối cơ sở dữ liệu
Java - JDBC) và SQLJ, mức độc lập được cài đặt tại thời điểm chạy ứng
dụng thông qua lời gọi tới phương thức setTransactionIsolation() thông qua
giao diện kết nối java.sql của DB2.
Khi mà mức độc lập cho ứng dụng không được cài đặt khi sử dụng một trong các
phương thức này, mức độc lập tham chiếu ổn định được mặc định sử dụng. Cài đặt
mặc định này được áp dụng cho các câu lệnh DB2, các câu lệnh SQL và các thực
thi tập mã lệnh từ Command Line Processor (CLP) đặc biệt nhúng thêm SQL,
ODBC/CLI, JDBC và các ứng dụng SQLJ. Vì thế nó cũng có khả năng để xác
định mức độc lập cho xử lý để thực hiện từ Command Line Processor của DB2.
Trong trường hợp này, mức độc lập được đặt bằng cách thực thi câu lệnh
CHANGE ISOLATION trước khi thực hiện kết nối tới cơ sở dữ liệu được hình
thành.

kiện khóa chờ xử lý, phiên làm việc cố gắng để truy cập dữ liệu nguồn thực hiện
dừng xử lý một cách đơn giản cho đến khi phiên làm việc đang xử lý đã bị ngắt và
khóa không phù hợp được giải phóng. Các thuộc tính khóa
Tất cả các khóa đều có các thuộc tính khóa cơ bản sau:
 Đối tượng: Thuộc tính Đối tượng xác định dữ liệu nguồn đang được khóa.
Hệ quản trị cơ sở dữ liệu DB2 yêu cầu khóa trên dữ liệu nguồn như các
không gian bảng, các bảng, và các hàng khi cần.
 Kích cỡ: Thuộc tính kích cỡ để xác định kích thước vật lý của từng phần dữ
liệu được khóa. Khóa không phải luôn điều khiển cho toàn bộ dữ liệu
nguồn. Ví dụ, hiếm khi bạn cần ứng dụng thực hiện điều khiển xử lý trong
toàn bộ bảng, Hệ quản trị cơ sở dữ liệu DB2 có thể cho phép ứng dụng thực
hiện điều khiển thông qua hàng đặc biệt trong bảng.
 Thời gian tồn tại: Thuộc tính thời gian tồn tại xác định thời gian tồn tại
khi khóa được nắm giữ. Mức độc lập của phiên làm việc thường xuyên điều
khiển khoảng thời gian của khóa.
 Chế độ: Thuộc tính chế độ xác định kiểu của cách thức được phép truy cập
cho khóa như kiểu cho phép đối với các người sử dụng đang tồn tại như
trạng thái khóa. Các trạng thái khóa
Trạng thái của khóa xác định kiểu của truy cập được phép cho chính khóa như
kiểu của phần tử được phép đối với các người dùng xác định. Bảng 1 xác định
trạng thái khóa có thể sử dụng để mà tăng điều khiển.

Bảng 1. Các trạng thái khóa
Trạng thái khóa