ch17.oltp.ps.pdf

7/30/2019 ch17.oltp.ps.pdf

1/14

Ch. 17: OLTP (OnLine Transaction Processing) Concepts

Learning Goals: Data management in OLTP Applications

OLTP Applications and their Characteristics

* Examples

* Units of work, Thruput, concurrency

* Performance issue (1000 TPS) : out of scope

* Correctness issue : database consistency

- despite bad interleavings, failure (partial execution)

* Architecture of OLTA

Basic Concepts

* Simplified Model of transactions

- Concurrency => Correctness issue (bad interleaving, failures)

* Simplified Model of TP Monitor

Desirable Properties of Transactions: ACID

Schedules, recoverability, serializability (test, usage)


2/14

2

OLTP Applications and their Characteristics

Transaction = a business deal (e.g. a sale)

Transaction Processing = book-keeping about transactions

* $60B industry [G. Held of Tandem, 93]

* Airlines: researvation system

* Banking: ATM, electronic fund transfer, Home banking

* Securities: NY Stock Exchange, NASDAQ: 200 Million/day

- Chicago board of trade (futures) - 140 Million/day

* Telecommunications: call billing, operator services

* Point-of-sale and Retail: credit cards/checks, sales

* Manufacturing: Just-In-Time inventory control

* Student Access System, SAS, (500,000 calls/week), ..


3/14

3

Characteristics:

Consistent on-line database- despite failures, interleavings etc.

Small work units - e.g. transfer, deposit, withdaraw

High throughput = #transactions per second (TPS)

High Concurrecncy = #units overlapping a given unit

Ex. List wrok units, throughput and concurency for NYSE and SAS:

* NYSE: 200M/day, 5 sec. each :: >2000 TPS, 10K overlaps/unit

* SIS: 100K/day, 1 minute each:: >1 TPS, 50 overlaps each unit


4/14

4

Units of Work (transactions)

Relationship to organizational workflow and forms

* Decompose work into special units

* Often a form represents one unit of work

* Ex. Bank: Forms for deposit, withdraw, transfer, report, ...

- Point-of-sale: purchase, return, ...

- Airline reservation: reserve, cancel, ...

Informal properties of Work Units

* Small: 1 - 30 I/Os and 10K-1M instructions

* Independent: open a file, update a record, close the file

* Single function: e.g. build B+tree index to a file

* Recoverable: failure between a bank transfer

Q? Which of the following are individual transactions?

* A visit to an ATM / bank , A purchase at a retail store

* a SQL query, an ODBC call, A C program w/ embedded SQL

Types: on-line vs. batch; conversational vs. non-conversational.


5/14

5

17.1-2 Simplified Model of Transactions

Transaction = execution of a user program accessing database

* multiuser database, interleaved concurrent user programs

Transaction: operations and states

* 17.1.2 Database Operations: Ex. Fig. 17.2, pp 530

- read_item(X): read database item X into program variable X

- write_item(X), begin-trans, ....* 17.2 Transaction states and other operations (Fig. 17.4, pp 535)

- States: active, partially committed, committed, failed, terminated

- Ops: begin/end transaction, commit, abort, read/write

17.1.3 Why Concurrency Control is needed?

* Problems due to interleaved concurrent transactions:

- Lost update, Temporary update [Fig. 17.3, pp 531-2

- Unrepeatable read, incorrect summary, ...

17.1.4 Why Recovery is needed? (Avoid partial execution)

* Goal: either all actions in a transaction are completed or

- has no effect whatsoever on database or other transactions

* Failure types (pp 533): Catastrophe, system(hw / disk / OS),

- transaction error/exception, rollback due to concurrency control

* 17.2: Use system log, commit points


6/14

6

17.3-4 Characterizing Transactions and Schedules

Desirable Properties (ACID)

* Atomicity: performed all actions or none

* Consistency Preserving: moves database across consistent states

* Isolation: Ts updates are not visible to other Ts before commit

* Durability: committed changes to DB are permanent

! Schedule of concurrently exceuting interleaved transactions

- =Trace from database

" Def. schedule S (T1, ..., Tn) = an ordering of operations of Ti, s.t.

- order of operations of Ti in S = order of operations in Ti, forall Ti.

* ordering could be total or partial.

* Ex. Fig. 17.3(a), (b) :: shorthand ri(X), wj(Y), ci, aj, ...

* Committed projection: C(S) = operations from committed Ts


7/14

7

17.4.1 Exercises

#

Q1? How many schedules are possible for Xactions in 17.14 & 17.17

$

Q2? Count number of schedules for T1, ..., Tn,

- Where Ni = number of operations in Ti, N = N1 + N2 + ... + Nn

%

Q3? Design a representation for the space of (partial) schedules

& Q4? Design a algorithm to enumerate the (partial) schedules

' A1: 17.14: (9!)/(6!*3!) = 84 ::: 17.17: (13!)/(5!*4!*4!) = 90900

(

A2: The ordering of Ni actions within Ti preserved =>

- lose (Ni!) permutations for each valid schedule

* #schedules S(T1, ..., Tn) = N! / (N1! * N2! * ... Nn!)

- = #permutations / ((#permutation in T1)*...*(... in Tn))

) A3: Representation = Tree

* Nodes at level k = { Sk : partial schedule of length k }

- Root = empty schedule, leafs = complete schedules

* Edge from a S(k) to a S(k+1) : Max.#Children = #Ts = n

0 A4: General idea = tree traversal

* BFS - take a S(k) and generate a S(k+1) for each non-empty Ti

- Start =

* DFS - recursion, a recursive call for each non-empty Ti

- Base case = no remaining actions


8/14

8

17.4.2 Recoverability Properties of Schedules

1

reads_from(Ti, Tj, S)= Ti reads from Tj in S iff- (wj(X)(cj (cj restore before image of X

3 Ex. Identify the level of recoverability for following schedules

* Sd: r1(X), w1(X), r2(X), r1(Y), w2(X), w1(Y), c1, c2

* Sc: r1(X), w1(X), r2(X), r1(Y), w2(X), c2, a1

* Se: r1(X), w1(X), r2(X), r1(Y), w2(X), w1(Y), a1

* Sg: r1(X), w1(X), r1(Y), w1(Y), c1, r2(X), w2(X), c2

* Sc not recoverable, Sd, Se recoverable, Se has cascaded rollback

- Sg is strict


9/14

9

17.5 Correctness/ Serializability of Schedule (S)

4

Why is serializability interesting?

* It is the characterization of "correctness", legal interleavings

5 Serial, Non-serial and serializable schedules (Fig. 17.5, pp 542)

* Serial S: no interleaving, i.e. all actions Ti together in S

* Nonserial S: interleaving, for some Ti, all actions are not together

* Serializable S, if S is eqv. to some serial schedule of same Ts

- used as correctness measure

6 Conflict Serializable(S) iff conflict-equivalent(S, a serial schedule)

7 Equivalence of schedules S1, S2

* Result eqv.: if they produce the same final state of DB

- not enough for correctness, see Fig. 17.6 (pp 543)

* Conflict eqv. order of any two conflicting operation is identical

- or or

* View Eqv. (17.5.4)


10/14

10

17.5.2 Testing Conflict serializability (Algo. 17.1, pp 545)

8

1. Construct precedence graph

* Nodes = transactions T1, T2, ..., Tn

* Edges = conflists (read/write, write/read, write/write)

- (Ti --> Tj) if before(wi(X),rj(X)) in S

- (Ti --> Tj) if before(rj(X),wi(X)) in S

- (Ti --> Tj) if before(wj(X),wi(X)) in S

9

2. No cycle in predence graph(S) IFF conflict serializable(S)

@ Q? Is this algorithms correct?

* Proof: No cycle => construct an eqv. serial schedule

A Q?Can this algorithme be used in OLTP?

* Q? Can interleaving be scheduled? When does a schedulebegin/end?

- What a new Tk arrives during the algorithms run?

* Practices: Use simple protocols like locking (Ch. 18)

- Protocol for Ti, checks local to Ti/data-items, (not global).


11/14

11

Exercises

B

Ex. Consider the schedule in Fig. 17.5 and Fig. 17.6 (pp 542-3)

* Classify schedules in Fig. 17.5 as serial, serialable, nonserial

* Find pairs of eqv. schdules under (i) result eqv., (ii) conflict eqv.

C Ex. Fig. 17.5 : check schedules C and D for serializability.

* Solution and conflict graphs in Fig. 17.7 (pp 546)

D Ex. Fig. 17.8 (pp 547) check serilizability of schedules E anf F

* Solution and graphs in Fig. 17.9


12/14

12

Components of an OLTP Application

* [User] -- [Forms, Menus, UI] -- input messages -->

* --> [Client program: group messages, add actions* ] -->

- extra actions for logging, commit etc. (see TPC-A debit-credit )

* --> transaction, i.e. request for a group of actions on DB/files -->

* --> [ TP monitor : forward/deny/ delay requests ] -->sequence of

actions

- check configuration spec, other active transactions

* --> [Server routines: carry out actions ] --> actions against

DB/files

E Other Components:

* Forms management system

* Configuration specification facility

* Application configuration= system catalog, max. #processes, max

#transactions, SubItem2

F Ex. Identify the following components in a banking ATM / SIS/ ...

* Forms/Menus - welcome, user identification, command-list, ...

* Transactions, i.e. message groups - withdraw, deposit, transfer, ...

* Additional actions added: start_trans, log, commit/abort,

end_trans


13/14

13

Architecture of OLTA

G

Four pieces: client, server, config. spec., TPM

H

Architecture 1: Single process single thread: one process / user

* + simple secure TP, - overhead of memory/context switch

* concurrency control/recovery by OS/file system/DB

I Architecture 2: Single process/many threads

* One process for all users, one thread/user

* All I/O request via TPM, TPM does context switch for sync. I/O

* Complex TPM but less overheads

* DB transaction and Client program/TPM transaction may differ!

- in unit of lock granulairuty / recovery

P Architecture 3: Client / server

* Client may be single threaded or multi-threaded

* Server may be single threaded or multi-threaded

* Middleware: name server, message queues, IPC, ...


14/14

14

Components of the TP Monitor, and Transactions

Q

Three Components

* --> [ Transaction Scheduler ] --> request grant/deny/delay

* --> [ Resource/Data Manager] --> carry out actions tentatively

* --> [Commit Manager] --> abort/commit tentative actions

R Debit-Credit Xact [A = account#, B= branch#, T = teller#]

* try{read 100 bytes from terminal;

* start_trans();

- A.account_balance =+ delta;

- rewtrite new balance to account A;

- log A, T, B, delta, timestamp

- T.teller_balance =+ delta;

- B.branch_balance =+ delta

* commit_trans(); /* onerror(){ put in batchfile / abort(); } */

* write 200 bytes to terminal;}

ch17.oltp.ps.pdf

Documents