Chuẩn bị cho kỳ thi 730 cơ bản về DB2 9, Phần 6: Nhất quán dữ liệu ppt

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:


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

 Xác định các đặc trưng của các khóa DB2
 Xác định mức độc lập được sử dụng để đưa ra trạng tái


Các điều kiện tiên quyết
Để hiểu được một số vấn đề quan trọng của bài viết này, bạn nên tham gia vào các
phần sau:
 Đối tượng: Là bất kỳ cái gì trong cơ sở dữ liệu mà có thể được tạo ra hay
thực thi với SQL (Ví dụ: các bảng, các chỉ mục, các gói, ).
 Bảng: Là một cấu trúc logic được sử dụng để hiển thị dữ liệu như là một
tập hợp của các hàng không định thứ tự với một số cột xác định. Mỗi một
cột chứa một tập giá trị, trong đó mỗi giá trị là cùng kiểu với nhau (hoặc
kiểu con của kiểu dữ liệu cột); định nghĩa cột cho phép xác định cấu trúc
của bảng và các hàng của bảng chứa dữ liệu chính xác của bảng đó.
 Bản ghi: Thể hiện dữ liệu lưu trữ theo từng hàng trong bảng.
 Trường: Thể hiện của cột được lưu trong bảng.
 Giá trị: Xác định thành phần dữ liệu cái được tìm thấy tại mỗi hàng và cột
trong bảng cơ sở dữ liệu.
 Ngôn ngữ truy vấn cấu trúc (SQL): Là ngôn ngữ chuẩn được sử dụng để
định nghĩa các đối tượng và thực thi dữ liệu trong cơ sở dữ liệu quan hệ. Để
có nhiều thông tin hơn về SQL hãy xem bài viết thứ tư trong loạt bài viết
này.
 Bộ tối ưu hóa DB2: Là thành phần của bộ tiền biên dịch SQL
(precompiler) là cái được chọn để truy cập cho câu lệnh SQL Data
Manipulation Language (DML)(Ngôn ngữ xử lý dữ liệu) bằng việc mô hình
hóa giá trị thực thi của một số truy cập riêng biệt và được chọn như là một
cách với số chi phí cần thiết nhỏ nhất.


Các yêu cầu hệ thống

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:

 Các phiên làm việc (transactions)
 Các mức cô lập (iosolation levels)
 Các khóa (locks)


Các phiên làm việc và các khung phiên làm việc
Mỗi phiên làm việc (được biết như đơn vị công việc) là một dãy gồm một hoặc
nhiều các xử lý SQL được nhóm lại với nhau như một đơn vị riêng lẻ, phiên làm
việc thường được sử dụng để xử lý ứng dụng. Sự bắt đầu và kết thúc của phiên
làm việc được định nghĩa là tập hợp các điểm xác định của cơ sở dữ liệu; sẽ có hai
trường hợp hoặc là các xử lý SQL thực thi cho các cách phiên làm việc được áp
dụng cho cơ sở dữ liệu (được xử lý - committed) hoặc là các xử lý của SQL không
được thực hiện đầy đủ và bỏ qua (quay trở lại - rolled back).
Với việc nhúng các ứng dụng SQL và các tập mã lệnh (script) từ Command Center
(Trung tâm câu lệnh) hoặc trên Script Center (Trung tâm tập lệnh) hoặc Command
Line Processor (Xử lý dòng lệnh) các cách phiên làm việc được khởi tạo một cách
tự động cho lần đầu khi các câu lệnh SQL được thực thi, hay là sau khi kết nối đến
cơ sở dữ liệu thành công thì các phiên làm việc lúc này mới bị ngắt. Cho một lần
khởi tạo, phiên làm việc phải được ngắt bởi người dùng hoặc bởi ứng dụng đã
khởi động phiên làm việc đó trừ khi bộ xử lý biết trao quyền tự động (trong trường
hợp này mỗi một câu lệnh SQL cho phép xử lý được xem như một phiên làm việc
đơn lẻ khi đó xử lý được nhanh chóng thực hiện).
Trong hầu hết các trường hợp, các phiên làm việc được thực thi hoặc bằng câu
lệnh COMMIT hoặc bằng câu lệnh ROLLBACK. Khi câu lệnh COMMIT được
thực thi, tất cả các thay đổi tới cơ sở dữ liệu khi các phiên làm việc khởi tạo được
cố định có nghĩa là các thay đổi sẽ được lưu trữ tới đĩa. Khi câu lệnh
ROLLBACK được thực thi tất cả các thay đổi được tạo ra tới cơ sở dữ liệu khi
phiên làm việc được khởi tạo được quay lại và cơ sở dữ liệu được trả lại ở trạng
thái trước khi phiên làm việc được thực hiện. Trong một trường hợp khác dữ liệu
được đảm bảo trả lại trạng thái phù hợp khi hoàn thành phiên làm việc.

Đ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:

DEPT_ID (Mã
phòng)
DEPT_NAME (Tên
phòng)
100 PAYROLL
200 ACCOUNTING
500 MARKETING
Kết quả như vậy là bởi vì khi câu lệnh COMMIT đầu tiên được thực thi, nó tạo ra
bảng DEPARTMENT và chèn hai bản ghi vào bảng DEPARTMENT vĩnh viễn.
Một mặt khác, khi câu lệnh ROLLBACK đầu tiên được thực hiện thì bản ghi thứ
ba được chèn thêm vào bảng DEPARTMENT và đồng thời bảng được trả lại ở
trạng thái trước khi câu lệnh chèn thêm phần tử này được thực hiện. Cuối cùng,
khi câu lệnh COMMIT thứ hai được thực hiện thì thực hiện chèn thêm bản ghi thứ
tư xác định vào bảng DEPARMENT và cơ sở dữ liệu tiếp tục trả lại trạng thái phù
hợp.
Khi bạn nhìn thấy ví dụ này, lệnh xử lý xác nhận hoặc quay trở lại chỉ thực hiện
thay đổi phù hợp để tạo ra phiên làm việc cái mà câu lệnh commit hay câu lệnh
rollback thực hiện xử lý. Khi mà dữ liệu bị thay đổi không được xem xét thì các
người sử dụng và các ứng dụng khác luôn luôn không thể nhìn thấy chúng (tất
nhiên có một ngoại lệ cái mà sẽ được trình bày ở phần sau), và chúng có thể quay
lại kết quả đơn giản trước khi thực hiện xử lý quay trở lại. Tuy nhiên khi một dữ
liệu thay đổi được xem xét chúng trở lên có tác dụng với các người dùng và các
ứng dụng khác và có thể không mất thời gian di chuyển bởi xử lý quay trở lại.


Tác dụng của các phiên làm việc không thực hiện thành công
Chúng tôi đã trình bày điều gì xảy ra khi một phiên làm việc bị ngắt bởi câu lệnh
COMMIT hoặc câu lệnh ROLLBACK. Nhưng vấn đề gì xảy ra nếu hệ thống xảy
ra lỗi trước khi phiên làm việc có thể hoàn thành? Trong trường hợp này, Hệ quản
trị cơ sở dữ liệu DB2 sẽ quay lại tất cả các sự thay đổi không được xem xét để có

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

hàng của dữ liệu và Phiên làm việc 2 đọc đến dữ liệu đã bị thay đổi trước
khi Phiên làm việc 1 thực hiện được thao tác thay đổi đó. Nếu Phiên làm
việc 1 thực hiện quay lại làm thay đổi này, Phiên làm việc 2 sẽ đọc đến dữ
liệu tính toán mà thực tế không tồn tại.
 Đọc không lặp lại (Nonrepeatable read): Điều này xảy ra khi phiên làm
việc đọc đến một hàng hai lần nhưng dữ liệu thu được lại là khác nhau cho
từng lần đọc. Ví dụ: Phiên làm việc 1 đọc một hàng dữ liệu và Phiên làm
việc 2 thực hiện thay đổi hoặc xóa ngay chính hàng đó. Vì vậy khi Phiên
làm việc 1 thực hiện đọc lại chính hàng đó nó sẽ thu được các giá trị khác
so với trước (nếu hàng đã được cập nhật) hoặc cảnh báo hàng đó không tồn
tại (nếu hàng đã bị xóa).
 Không xảy ra (Phantom): Điều này xảy ra khi một hàng dữ liệu phù hợp
với điều kiện tìm kiếm không được khởi tạo thực hiện lần thứ nhất nhưng
lại được thực hiện trong lần xử lý sau. Ví dụ: Phiên làm việc 1 đọc một tập
các hàng phù hợp với một số điều kiện tìm kiếm và Phiên làm việc 2 chèn
thêm hàng mới cũng phù hợp với điều kiện tìm kiếm trong Phiên làm việc
1. Nếu Phiên làm việc 1 thực hiện lại thao tác xử lý thì kết quả thu được
một tập các hàng là có sự khác biệt so với các hàng đã thực hiện lần trước.
Để duy trì tính ổn định của cơ sở dữ liệu và tính toàn vẹn của dữ liệu thì khi cho
phép nhiều ứng dụng cùng truy cập đến cùng một dữ liệu tại cùng một thời điểm
thì phải đảm bảo tính thống nhất. Một trong các cách mà DB2 cho phép thống
nhất cơ sở dữ liệu đó là sử dụng các mức độc lập, cái mà cho phép xác định dữ
liệu được sử dụng như thế nào trong một phiên làm việc hoặc tính độc lập từ các
phiên làm việc khác trong khi phiên làm việc đầu tiên thực hiện. DB2 sử dụng các
mức độc lập sau cho phép thống nhất sử dụng dữ liệu:
 Đọc lặp lại (Repeatable read)
 Đọc ổn định (Read stability)
 Tham khảo ổn định (Cursor stability)
 Đọc không được xem xét (Uncommitted read)
Mức độ độc lập đọc lặp lại cung cấp tất cả các trường hợp đặc biệt để làm giảm

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ý) để

thay đổi trạng thái của phòng để cập nhật vào cơ sở dữ liệu khi mà thực hiện yêu
cầu xử lý của khách hàng. Tương tự, những khách hàng khác không thể thực hiện
hay hủy bỏ giao dịch nếu như một phòng nào đó đã được đăng ký thuê rồi. Tuy
nhiên bạn có thể cho phép thay đổi giá phòng cho bất kỳ phòng nào khi mà khách
hàng chưa đăng ký thuê phòng. Điều đó có nghĩa là, các khách hàng khác có thể
thực hiện hay hủy bỏ việc đặt phòng cho bất kỳ phòng nào trong khi phòng đó
chưa được đăng ký thuê. Đặc trưng này được mô tả ở trong hình 2.

Hình 2. Ví dụ của mức độc lập đọc lặp lại



Mức độc lập của đọc ổn định
Mức độc lập của đọc ổn định không bị giới hạn như mức đọc lặp lại; vì thế nên
không thể có sự độc lập hoàn toàn từ một phiên làm việc tới các phiên làm việc
khác. Mức độc lập đọc ổn định được giả định cung cấp khả năng đọc các bản ghi
dư thừa và không lặp lại. Khi mức độc lập này được sử dụng chỉ các dòng được
khôi phục chính xác hoặc được sửa chữa bởi chính phiên làm việc đó được khóa
lại. Vì vậy, nếu phiên làm việc quét 1,000 dòng để khôi phục 10 dòng, khóa chỉ
yêu cầu và nắm giữ 10 dòng đã được khôi phục đó chứ không phải khóa hết 1,000
dòng đã quét. Với kết quả này, nếu cùng câu lệnh SELECT được thực hiện hai hay
nhiều lần trong cùng một phiên làm việc thì tập kết quả có thể không giống nhau
cho mỗi lần thực hiện.
Khi với mức độc lập đọc lặp lại, phiên làm việc được chạy dưới mức độc lập đọc
ổn định có thể khôi phục tập các hàng và thực thi bất kỳ thao tác xử lý nào trong
số đó cho đến khi bị ngắt. Các phiên làm việc được ngăn lại từ thực thi cập nhật
hay xử lý xóa có thể bị ảnh hưởng bởi tập các hàng được khôi phục từ chính phiên
làm việc cũng như do phiên làm việc tồn tại, tuy nhiên các phiên làm việc khác có
thể thực thi việc chèn vào các thao tác xử lý. Nếu một dòng được chèn vào phù
hợp với điều kiện lựa chọn của truy vấn bởi chính phiên làm việc xử lý đó thì các

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

không thể truy cập đến bằng cách sử dụng chỉ mục. Mỗi khi được yêu cầu, dòng
khóa sẽ tồn tại trong quá trình cho đến khi con trở được thay thế hoặc cho đến
phiên làm việc bị ngắt. (Nếu con trỏ được thay thế vị trí, khóa được cầm trên hàng
trước được giải phóng và khóa mới được yêu cầu cho hàng mà con trỏ đang đặt tại
vị trí đó). Hơn thế, nếu phiên làm việc đang làm việc thực hiện sửa bất kỳ hàng
nào được khôi phục thì các phiên làm việc khác cũng không được phép cập nhật
hoặc xóa hàng đó cho đến khi chính phiên làm việc đó ngắt thậm chí con trỏ soạn
thảo có thể cũng không được đặt trên chính dòng được sửa chữa. Như là các mức
độc lập đọc lặp lại và các mức độc lập đọc ổn định, các phiên làm việc sử dụng
mức độc lập tham khảo ổn định (được cho là mặc định sử dụng) sẽ không nhìn
thấy sự thay đổi của các hàng khác bởi các phiên làm việc khác cho đến khi những
thay đổi này được thực hiện hoàn thành.
Nếu chương trình đặt phòng khách sạn đang chạy dưới mức độ độc lập tham khảo
ổn định thì thao tác xử lý nào được thực hiện. Khi khách hàng duyệt qua cơ sở dữ
liệu để có được danh sách các phòng trống để đặt phòng và sau đó hiển thị thông
tin về mỗi phòng trong danh sách đảm bảo mỗi phòng được đăng ký tại mỗi thời
điểm khác nhau khi đó bạn có thể thay đổi thông tin cho bất kỳ phòng nào trong
khách sạn ngoại trừ phòng mà khách hàng đang xem tại vị trí hiện tại (để xác định
ngày đặt phòng). Ngược lại, các khách hàng khác sẽ có thể tạo ra hoặc hủy bỏ việc
đặt phòng cho bất kỳ phòng nào trong khách sạn ngoại trừ phòng mà khách hàng
đang tìm kiếm (để xác định ngày đặt). Tuy nhiên, không phải bạn hoặc khách hàng
khác sẽ có thể thực hiện bất kỳ cái gì với phòng mà khách hàng đầu tiên đang tìm
kiếm. Khi khách hàng đầu tiên hiển thị thông tin về phòng khác trong danh sách,
bạn và các khách hàng khác sẽ có thể sửa chữa phòng mà người khách đầu tiên đã
tìm kiếm; Tuy nhiên không một ai sẽ có thể được phép để thay đổi phòng mà
khách hàng đầu tiên đang tìm kiếm. Vấn đề này được thể hiện trong Hình 4.

Hình 4. Ví dụ của mức độc lập tham chiếu ổn định

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

Hình 5. Ví dụ của mức độc lập đọc không ràng buộc



Lựa chọn mức độc lập thích hợp
Mức độc lập được sử dụng có thể ảnh hưởng như thế nào để hỗ trợ giải quyết vấn
đề mâu thuẫn cơ sở dữ liệu và thực hiện các ứng dụng mâu thuẫn ra sao. Đơn giản
như có nhiều hạn chế khi mức độc lập được sử dụng ví dụ như vẫn còn một chút
mâu thuẫn - đó là sự thực hiện cho một số ứng dụng có thể làm giảm hiệu quả khi
họ phải đợi để khóa trên các nguồn để phát hành. Vì vậy bạn phải quyết định xem
mức độ độc lập nào được sử dụng? Cách tốt nhất là xác định các kiểu của trường
hợp đặc biệt có thể không được chấp nhận và sau đó lựa chọn mức độc lập thích
hợp để ngăn chặn các trường hợp đặc biệt này xảy ra:
 Sử dụng mức độc lập đọc lặp lại nếu bạn đang thực thi một lượng lớn các
truy vấn và bạn không muốn các phiên làm việc có thể xảy ra đồng thời để
tạo ra các thay đổi có thể làm cho cùng một truy vấn mà trả lại các kết quả
khác nhau nếu chạy nhiều lần
 Sử dụng mức độc lập đọc ổn định khi bạn muốn một số mức của sự thống
nhất giữa các ứng dụng mà lúc đó bạn muốn các hàng đủ điều kiện cho
phần còn lại ổn định trong suốt quá trình thực hiện phiên làm việc xác định.
 Sử dụng mức độc lập tham chiếu ổn định khi bạn muốn có được sự thống
nhất tối đa giữa các ứng dụng mà lúc đó bạn không muốn các truy vấn có
thể nhìn thấy dữ liệu không được xem xét.
 Sử dụng mức độc lập đọc không xem xét nếu bạn thực thi truy vấn trên các
bảng/các hướng nhìn/các cơ sở dữ liệu hoặc mà không có vấn đề gì khi truy
vấn trả lại các giá trị không được xem xét.


Xác định mức độc lập để sử dụng

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.

Với DB2 UDB phiên bản 8.1 và phiên bản sau đó nữa, khả năng để xác định mức
độ độc lập cho từng truy vấn xác định để chạy được cung cấp thông qua mệnh đề
WITH [RR | RS | CS | UR] gắn liền với câu lệnh SQL SELECT. Câu lệnh
SELECT đơn giản được sử dụng kèm mệnh đề WITH có dạng như sau:
SELECT * FROM EMPLOYEE WHERE EMPID = '001' WITH RR

Nếu bạn có ứng dụng cần để chạy trong mức độc lập ít giới hạn trong phần lớn
thời gian (để hỗ trợ thống nhất tối đa) nhưng chứa một số truy vấn mà bạn không
nhìn thấy một số hạn chế, mệnh đề này cung cấp phương thức chính xác có thể
được sử dụng để hỗ trợ bạn nhận được đối tượng cần.

Khóa - Locks
Công việc được khóa như thế nào
Trong phần Sự thống nhất và các mức độc lập, bạn nhìn thấy các phiên làm việc
độc lập của DB2 từ các phiên làm việc khác sử dụng khóa (lock). Khóa là một cơ
chế được sử dụng để liên kết dữ liệu nguồn với từng phiên làm việc đơn với mục
đích điều khiển làm thế nào các phiên làm việc khác tương tác với nguồn trong khi
dữ liệu nguồn vẫn liên kết với phiên làm việc gốc. (Phiên làm việc mà dữ liệu
được liên kết được khóa và được gọi là hold khóa hay own khóa.) Hệ quản trị cơ
sở dữ liệu DB2 sử dụng khóa để ngăn chặn các phiên làm việc từ việc truy cập dữ
liệu không được xem xét bởi các phiên làm việc khác (trừ khi mức độc lập đọc
không xem xét được sử dụng) và ngăn chặn việc chỉnh sửa các hàng bởi các phiên
làm việc khác khi mà phiên làm việc hiện tại sử dụng mức độ độc lập giới hạn.
Mỗi lần khóa được yêu cầu nó sẽ giữ phiên làm việc này cho đến khi phiên làm
việc này bị ngắt; tại thời điểm này khóa được giải phóng và dữ liệu nguồn được
chuyển sang có tác dụng với các phiên làm việc khác.
Nếu một phiên làm việc cố gắng truy cập tới dữ liệu nguồn theo cách mà không
phù hợp với khóa được giữ bởi phiên làm việc khác (chúng tôi sẽ tìm kiếm khóa
phù hợp ngắn hơn), phiên làm việc đó phải đợi cho đến khi phiên làm việc đang
xử lý được kết thúc. Điều này được biết như sự kiện khóa chờ (lock wait). Khi sự

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

Các đối
tượng
được áp
dụng
Mô tả
Không tập trung
(Intent None - IN)

Các
không
gian bảng
và các
bảng
Khóa có thể đọc dữ liệu trong bảng đã được khóa
(bao gồm dữ liệu không được xem xét) nh
ưng không
thể thay đổi được dữ liệu này. Trong chế độ này,
khóa sở hữu không yêu cầu các khóa ở mức độ hàng
vì thế các ứng dụng tồn tại có thể đọc và thay đổi dữ
liệu trên bảng.