Quản lý transaction và khóa

Transaction trong SQL server Để hoàn thành các yêu cầu của 4 tính chất ACID trên, SQL Server cung cấp các chức năng sau:  Quản lý Transaction Transaction management  Khoá Lo

Trang 1

Quản lý transaction và khoá

Trang 3

Khái quát về Transaction

 Transaction là 1 chuỗi các thao tác (action) được thực thi như 1 đơn vị công việc riêng

lẻ (single logical unit of work).

 Các thao tác chủ yếu của 1 transaction:

 Đọc (Read) một đối tượng CSDL Ký hiệu transaction T đọc đối tượng O là R T (O)

 Viết (Write) vào một đối tượng CSDL Ký hiệu transaction T viết vào đối tượng O là

Trang 4

 Transaction phải bao hàm 4 thuộc tính cơ bản (ACID) sau:

 A tomicity: một transaction phải là 1 đơn vị công việc nguyên tử; hoặc tất cả các sửa đổi dữ liệu đều được thực thi hoặc không 1 sửa đổi nào được thực thi.

 C onsistency: Khi hoàn tất, transaction phải cho dữ liệu ở tình trạng ổn định.

 I solation : Những chỉnh sửa được làm bởi

transaction hiện hành phải được cô lập khỏi những chỉnh sửa được làm bởi các transaction hiện hành khác

 D urability: sau khi 1 transaction hoàn tất, ảnh hưởng của nó sẽ cố định lâu dài trong hệ thống.

Trang 5

Các giai đoạn thực thi 1

 Khi ứng dụng hoàn tất thành công mọi sửa đổi,

CSDL sẽ chuyển về lại trạng thái nhất quán Mọi sửa đổi sẽ trở thành cố định trong CSDL.

 Khi CT ứng dụng gă êp lỗi, thì nó sẽ hủy bỏ mọi lê ênh sửa đổi dữ liê êu và đưa CSDL trở về lại trạng thái nhất quán trước khi giao tác bắt đầu

Trang 6

 Các DBMS thường không thể tự hiểu được

các phép câ êp nhâ êt nào sẽ được nhóm thành 1 giao tác Người dùng phải tự định biên cho

giao tác, nếu không DBMS sẽ xem toàn bô ê

chương trình là 1 giao tác

Trang 7

Transaction trong SQL server

 Để hoàn thành các yêu cầu của 4 tính chất

ACID trên, SQL Server cung cấp các chức

năng sau:

 Quản lý Transaction (Transaction management)

 Khoá (Locking)

 Ghi nhật ký (Logging)

 Transaction log – là nhật ký được duy trì bởi

chính SQL Server để quản lý tất cả các

transaction

 Explicit transaction – là 1 transaction mà việc khởi động và kết thúc transaction đó đều được định nghĩa một cách tường minh

Trang 8

Các dạng transaction

 Trong SQL server có 3 dạng transaction:

 Giao tác tường minh (explicit transaction):

được khai báo bằng lêênh BEGIN TRANSACTION

và kết thúc bằng lêênh Commit hay Rollback

 Giao tác ngầm định (implicit transaction): giao tác mới sẽ tự đôêng bắt đầu ngay khi giao tác trước đó hoàn tất và phải được hoàn tất tường minh bằng lêênh Commit hay Rollback.

 Giao tác tự đôêng chuyển giao (autocommit transaction): mỗi môêt lêênh được xem như 1 giao tác.

Trang 9

Định nghĩa transaction

BEGIN TRAN[SACTION] [transaction_name]

Dùng để đánh dấu việc bắt đầu của 1

transaction

COMMIT [TRAN[SACTION] [transaction_name] Hay

COMMIT WORK

 Dùng để đánh dấu việc kết thúc của 1

transaction tường minh

Trang 10

Chuyển giao tự động các

transaction –

Autocommit Transactions Mode chuyển giao tự động (Autocommit mode) là

mode quản lý transaction mặc định của SQL Server.

 Một lệnh (statement) được chuyển giao (committed) nếu nó thực hiện thành công hay sẽ trả ngược về lại ban đầu (roll back) nếu nó gặp lỗi.

 Lệnh BEGIN TRANSACTION vượt quyền mode tự

động chuyển giao (autocommit) mặc định

 SQL Server trở về lại mode autocommit khi

transaction tường minh đã được chuyển giao

(commit) hay trả ngược về đầu (roll back), hay khi mode transaction ngầm định bị tắt.

Trang 12

Làm thế nào để quay về lại trước những thay đổi

ROLLBACK [TRAN[SACTION]

[transaction_name |savepoint_name ]

D ùng để quay ngược một transaction tường minh hay ngầm định về lại điểm bắt đầu, hay về điểm dừng (save-point) bên trong 1 transaction

Trang 13

Ví dụ

BEGIN TRANSACTION

USE Pubs

UPDATE Titles

SET Royalty = Royalty + 20

WHERE type LIKE 'busin%'

IF (SELECT MAX(Royalty) FROM Titles WHERE Type LIKE 'busin%') >$25

BEGIN

ROLLBACK TRANSACTION PRINT 'Transaction Rolled back' END

ELSE

BEGIN

COMMIT TRANSACTION PRINT 'Transaction Committed' END

Trang 14

Tạo điểm dừng cho 1 TRANSACTION

 Lệnh SAVE TRANSACTION dùng để đặt 1 điểm dừng (save point) bên trong 1 transaction Điểm dừng chia transaction thành các phần khác nhau sao cho transaction có thể quay về lại điểm

dừng này nếu 1 phần của transaction bị loại bỏ có điều kiện.

 Cú pháp

SAVE TRAN[SACTION]

{savepoint_name }

Trang 15

Thực thi một transaction với điểm dừng

Trang 16

Thực thi một transaction với điểm dừng

Trang 17

Sử dụng các transactions

 Việc nhóm 1 số lớn các lệnh hay batch vào trong cùng 1 transaction có thể cản trở việc thực thi hệ thống.

 Nếu COMMIT và BEGIN không nằm trong

cùng 1 batch, khi lỗi xảy ra, một số batch sẽ vẫn tiếp tục thực thi Điều này có thể làm cho dữ liệu không nhất quán (inconsistency).

 Các tài nguyên được dùng trong transaction sẽ được giải phóng chỉ khi transaction được hoàn tất

Trang 18

Các lệnh không hợp lệ

 Rollback (quay về) phải có khả năng “undo”,

vì vậy các lệnh sau không được dùng:

 CREATE DATABASE, ALTER DATABASE

 CREATE TABLE, ALTER TABLE, TRUNCATE TABLE

Trang 19

Tính cô lập và bài toán đồng thời

Isolation and Concurrency Problems

 Khi 1 số user chỉnh sửa dữ liê êu có thể làm ảnh hưởng đến các user khác đang xem hay chỉnh sửa cùng dữ liê êu Các user này đang truy xuất dữ liê êu đồng thời

(accessing the data concurrently)

 Nếu DBMS không kiểm soát tính đồng thời

(concurrency control) thì sẽ xảy ra các hiê êu ứng sau:

 Mất cập nhật (Lost updates).

 Phụ thuộc chưa được chuyển giao (Uncommitted dependency).

 Phân tích không nhất quán (Inconsistent analysis).

 Đọc ảo (Phantom reads)

Trang 20

Tổn thất cập nhật

Lost Updates

 Các câ êp nhâ êt sẽ bị mất khi hai hay nhiều giao tác chọn cùng 1 hàng và cùng câ êp nhâ êt hàng đó Các giao tác không biết về nhau Câ êp nhâ êt cuối sẽ viết chồng lên các

câ êp nhâ êt được các giao tác khác thực hiê ên.

 Ví dụ: trước khi 2 giao tác thực hiê ên, số

dư tài khoản x là 100$ Giao tác T1 rút $10, giao tác T2 nạp thêm $100 , nếu hai giao tác thực hiê ên đồng thời thì có thể số dư tài khoản sẽ không phải là $190 (xem hình)

Trang 21

Ví dụ Tổn thất cập nhật

t1 Begin tran 100 t2 Begin tran Read(sodux) 100 t3 Read(sodux) sodux=sodux+100 100 t4 sodux=sodux-10 Write(sodux) 200 t5 Write(sodux) Commit 90

Trang 22

Mối quan hệ chưa được chuyển giao

Uncommitted Dependency (Dirty Read)

 Xảy ra khi giao tác thứ hai chọn 1 hàng đang được câ êp nhâ êt bởi 1 giao tác khác Giao tác thứ hai đọc dữ liê êu lúc chưa được chuyển giao và có thể bị thay đổi bởi giao tác đang thực hiê ên viê êc câ êp nhâ êt

 Ví dụ: hai giao tác T3 và T4 thực hiê ên đồng thời T3 rút

$10, T4 gửi thêm $100 nhưng lại hủy bỏ sau đó

Trang 23

Ví dụ về mối quan hệ chưa được chuyển giao

Trang 24

Phân tích không nhất quán

Inconsistent Analysis (Nonrepeatable Read)

 Xảy ra khi giao tác thứ hai truy xuất cùng 1

hàng nhiều lần và dữ liê êu mỗi lần đọc mỗi

khác Phân tích không nhất quán tương tự như mối quan hê ê chưa được chuyển giao, mô êt giao tác khác đang thay đổi dữ liê êu trong khi giao tác thứ hai đọc dữ liê êu

 Ví dụ: giao tác T5 và T6 thực hiê ên đồng thời

T5 rút tiền, còn T6 tính tổng số dư của 3 tài

khoản x,y,z Khi kết thúc 2 giao tác, kết quả

của T6 không chính xác, lẽ ra là $175 thay vì

$185

Trang 25

Ví dụ về mối quan hệ chưa được chuyển giao

Thời

x

Sô dư y

Sô dư z

sum

t2 Begin tran Sum=0 100 50 25 0 t3 Read(sodux) Read(sodux) 100 50 25 0 t4 sodux=sodux-10 sum=sum+sodux 100 50 25 100 t5 Write( sodux) Read(soduy) 90 50 25 100 t6 Read(soduz) sum=sum+ soduy 90 50 25 150

t8 Write( soduz) 90 50 35 150 t9 Commit Read(soduz) 90 50 35 150

Trang 26

Kiểm soát tương tranh

(Concurrency control)

 Khi nhiều người cố gắng cùng lúc chỉnh sửa dữ liê êu trong 1 DB thì hê ê thống kiểm soát cần phải được thực thi sao cho những sửa đổi được làm bởi người này thì không ảnh hưởng bất lợi đến người khác Kiểm soát này được gọi là

concurrency control.

 Có 2 hình thức kiểm soát tương tranh

 Pessimistic concurrency control (kiểm soát tương tranh bi quan)

 Optimistic concurrency control (kiểm soát tương tranh lạc quan)

Trang 27

 Khi người dùng thực hiê ên 1 thao tác tạo ra 1 khóa, các người dùng khác không thể thực thi thao tác nào có xung đô êt với khóa cho đến khi chủ của khóa giải

Trang 28

đã có, thì sẽ gây ra lỗi, người dùng nhâ ên được thông báo transaction bị roll back và cần bắt đầu lại

 Thường dùng cho môi trường ít có cạnh tranh dữ

liê êu, nơi mà chi phí roll back mô êt transaction thấp hơn chi phí khóa dữ liê êu khi đọc

Trang 29

Kiểm soát tương tranh trong SQL

server

 Microsoft SQL Server hỗ trợ cả hai loại Người dùng xác định loại kiểm soát bằng cách chọn các mức cô lâ êp transaction (transaction

isolation level) hay các tùy chọn concurrency trên cursor

 Mức cô lâ êp dùng để xác định mức đô ê mà 1

transaction bị cô lâ êp khỏi viê êc chỉnh sửa tài nguyên hay dữ liê êu từ mô êt transaction khác

Trang 30

Kiểm soát tương tranh trong SQL

server

 Kiểm soát các mức cô lâ êp transaction bao gồm:

 Có cần khóa dữ liêêu đọc hay không và loại khóa gì được yêu cầu.

 Khóa đọc nên giữ trong bao lâu

 Thao tác đọc có đang tham chiếu đến các hàng bị chỉnh sửa bởi 1 transaction khác hay không:

 Bị chăăn cho đến khi khóa đôăc quyền ( exclusive lock) trên hàng đó được giải phóng

 Khôi phục phiên bản đuợc công nhâăn của hàng đó vào thời điểm mà lêănh hay transaction bắt đầu

 Đọc dữ liêău đã được chỉnh sửa dù chưa được commit

Trang 31

Các mức cô lập transaction

(transaction isolation level)

 Chọn mức cô lâ êp cho transaction sẽ không làm ảnh hưởng đến các khóa đang có để

tránh dữ liê êu bị sửa đổi

 Mô êt transaction luôn nhâ ên khóa đô êc quyền

trên bất kỳ dữ liê êu nào mà nó sửa đổi và sẽ giữ khóa cho đến khi transaction hoàn tất

 Mức cô lâ êp càng thấp thì người dùng càng có nhiều khả năng truy xuất dữ liê êu đồng thời, nhưng cũng gây ra nhiều ảnh hưởng tương tranh và ngược lại

Trang 32

Các mức cô lập

 Để chọn mức cô lâ êp thích hợp thì phải cân đối giữa yêu cầu bảo toàn dữ liê êu của ứng dụng với chi phí của mỗi mức cô lâ êp.

 Mức cô lâ êp cao nhất là tuần tự hóa

(serializable)

 Mức cô lâ êp thất nhất là cho phép đọc dữ liê êu chưa được commit (read uncommitted).

Trang 33

Bốn mức cô lập theo chuẩn

ISO

1. Read uncommitted : mức thấp nhất,

transaction bị cô lâ êp chỉ đủ để bảo đảm các dữ liê êu bị lỗi vâ êt lý không được đọc mà thôi

2. Read committed: mức mă êc định của

Database Engine

3. Repeatable read

4. Serializable: mức cao nhất, các transaction

hoàn toàn bị cô lâ êp khỏi các transaction khác

Trang 34

Các mức cô lập của SQL server DB Engine

1. READ UNCOMMITTED: các lê ênh có thể đọc các

hàng bị chỉnh sửa bởi các transaction khác dù chưa được commit

2. READ COMMITTED: các lê ênh không thể đọc dữ

liê êu đã bị sửa đổi nhưng chưa commit bởi các transaction khác

3. REPEATABLE READ: các lê ênh không thể đọc

dữ liê êu đã bị sửa đổi bởi các transaction khác

và không có transaction nào có thể sửa đổi dữ liê êu đã được đọc bởi transaction hiê ên hành cho đến khi transaction hiê ên hành hoàn tất.

Trang 35

Các mức cô lập của SQL server DB Engine

4. SNAPSHOT: dữ liê êu được đọc bởi bất kỳ

lê ênh nào trong 1 transaction thì sẽ đuợc giữ giống như lúc bắt đầu transaction.

5. SERIALIZABLE

Trang 36

Lệnh thay đổi mức cô lập

SET TRANSACTION ISOLATION LEVEL { READ UNCOMMITTED

| READ COMMITTED

| REPEATABLE READ

| SNAPSHOT

| SERIALIZABLE } [ ; ]

Trang 37

Ví dụ

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ

GO

BEGIN TRANSACTION

SELECT * FROM publishers

SELECT * FROM authors

COMMIT TRANSACTION

Trang 38

Khóa - Locking

 Khóa (Locking) là 1 cơ chế được dùng bởi SQL Server Database Engine để đồng bô ê hóa viê êc

truy xuất đồng thời cùng 1 dữ liê êu từ nhiều

người dùng khác nhau

 Trước khi 1 transaction có được sự phụ thuô êc vào trạng thái hiê ên hành của 1 dữ liê êu nào đó, ví dụ như đọc hay sửa đổi dữ liê êu thì nó phải tự

bảo vê ê để không bị ảnh hưởng bởi mô êt

transaction khác đang sửa đổi cùng 1 dữ liê êu Để làm được điều này, transaction sẽ yêu cầu 1 khóa cho dữ liê êu đó

Trang 39

Cơ chế khóa

 Transaction sẽ không được cấp khóa nếu nó gây

xung đô êt với mode của khóa đang được cấp cho dữ liê êu đó bởi 1 transaction khác, khi đó Database

Engine sẽ dừng transaction có yêu cầu khóa này lại cho đến khi khóa đầu tiên được giải phóng

 Các ứng dụng thường thì không yêu cầu khóa trực

tiếp Khóa được quản lý nô êi bô ê bởi trình lock

manager Khi DB Engine xử lý 1 lê ênh SQL, trình query processor sẽ xác định xem tài nguyên (resources) nào cần được truy xuất, cần loại khóa nào tùy theo kiểu

truy xuất và mức cô lâ êp transaction được chọn Query processor sẽ yêu cầu khóa thích hợp từ lock

manager Khóa sẽ được cấp nếu không có xung đô êt với các khóa của các transaction khác

Trang 40

Cấp độ khóa – Lock

 Việc khoá ở mức càng nhỏ, ví dụ ở mức các hàng của bảng, làm tăng tính đồng thời, nhưng có phí tổn cao bởi vì nhiếu khoá được tạo ra nếu nhiều hàng được khoá

 Việc khoá ở mức càng lớn, chẳng hạn mức bảng, sẽ gây ra lãng phí khi xét đến tính đồng thời vì việc khoá

cả bảng sẽ hạn chế việc truy xuất đến bất kỳ phần

nào của bảng đó, nhưng chi phí sẽ giảm bởi vì chỉ có

Trang 41

Các tài nguyên mà DB engine có thể khóa

 RID (row identifier): mã ID của hàng được dùng để khóa mức hàng

 Key: dùng để khóa 1 hàng trong bảng index

 Page: khóa 1 trang 8KB, có thể là trang index hay dữ liêêu

 Extent: khóa 1 nhóm 8 trang liên tiếp nhau

 Table: khoá cả bảng bao gồm cả dữ liêêu và index

 File: khóa 1 file của CSDL

 Application: khóa các tài nguyên được dùng cho 1 ứng dụng

 Database: khóa cả 1 CSDL

Trang 42

Các kiểu Lock – Lock modes

( không làm thay đổi hay câ êp nhâ êt dữ liê êu) 

cho phép các transaction đồng thời cùng đọc

chung 1 tài nguyên

thể được câ êp nhâ êt  phòng tránh deadlock xảy

ra khi nhiều transaction cùng đọc, cùng khóa, sau đó lại muốn câ êp nhâ êt dữ liê êu

 Exclusive (X) : được dùng cho thao tác sửa đổi dữ liê êu như lê ênh INSERT, UPDATE hay DELETE Bảo đảm lả nhiều lê ênh câ êp nhâ êt không thể thực

Trang 43

Các kiểu Lock – Lock

modes

 Trong transaction repeatable read hay serializable,

transaction đọc dữ liê êu, chiếm được khóa S để khóa tài nguyên lại, sau đó sửa đổi dữ liê êu, cần chuyển khóa sang X Nếu cả 2 transaction đều có khóa S trên cùng

1 tài nguyên, sau đó cả hai đều đồng thời cùng muốn sửa đổi dữ liê êu Viê êc chuyển đổi khóa từ S sang X sẽ phải đợi vì khóa X của 1 transaction này không tích

hợp được với khóa S của transaction khác Cả hai sẽ cùng phải đợi

 Để tránh deadlock, khóa U sẽ được dùng Chỉ có 1

transaction chiếm được khóa U mà thôi, và khi

transaction chỉnh sửa dữ liê êu thì khóa U sẽ được

chuyển đổi thành khóa X

Tiêu đề	Quản lý transaction và khóa
Trường học	Đại học Quốc gia Hà Nội
Chuyên ngành	Quản lý hệ thống thông tin, Cơ sở dữ liệu
Thể loại	Báo cáo môn học
Năm xuất bản	2023
Thành phố	Hà Nội

Định dạng
Số trang	52
Dung lượng	0,94 MB