RNDr. Michal Kopecký, Ph.D. Department of Software Engineering, Faculty of Mathematics and Physics, Charles University in Prague

Size: px

Start display at page:

Download "RNDr. Michal Kopecký, Ph.D. Department of Software Engineering, Faculty of Mathematics and Physics, Charles University in Prague"

Evangeline Lewis
6 years ago
Views:

1 course: Database Applications (NDBI026) WS2015/16 RNDr. Michal Kopecký, Ph.D. Department of Software Engineering, Faculty of Mathematics and Physics, Charles University in Prague

2 Transactions Transactional Processing Creating triggers Using Triggers Explicit Locking Privileges Privileges Overview Granting Privileges Revoking Privileges M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 2

4 Allows enclose more logically related statements into one atomic operation RDBMS will then ensure, that operations are either completely done and their effects permanently stored in the database or none of them is done and the database state remains intact. Statements according to ANSI SQL-92 COMMIT [WORK] commits transaction ROLLBACK [WORK] rolls transaction back M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 4

5 At he end of the transaction all data in the database has to be in consistent state Integrity constraints have not to be violated Checked either immediately in time of each actualization or at the end of the transaction Each integrity constraint in the database has two flags: DEFERRABLE and DEFERRED [CONSTRAINT cons_name] cons_definition [INITIALLY {DEFERRED IMMEDIATE}] [[NOT] DEFERRABLE] If both flags are switched on, checking is done at the end of transaction just before COMMIT is performed. If the constraint is violated, the ROLLBACK is performed instead. M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 5

6 Oracle automatically starts transactions with first operation that changes data after end of previous transaction. Transactions cannot be nested (If necessary, procedures, functions and triggers can be executed in independent transactions) Some client applications / consoles / frameworks allows autocommit settings to issue commit after each statement. M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 6

7 MS SQL starts transactions explicitly by START TRANSACTION [name :var] The transaction is finished by: COMMIT TRANSACTION [name :var] ROLLBACK TRANSACTION [name :var] Transactions can be nested Out of transactions all statements are automatically committed by the server M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 7

8 SAVEPOINTs It is possible to create named checkpoints, that can serve to partial rollbacks of transactions Suitable for situations where one logical operation can be achieved by more ways and if one fails we want to try another way. Respectively, when one operation can be repeated later after failure S1 M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 8

9 Oracle uses standard syntax SAVEPOINT name; ROLLBACK [WORK] TO SAVEPOINT name; MS SQL uses proprietary syntax SAVE TRANSACTION name :var ROLLBACK TRANSACTION name :var M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 9

11 By default each user has access only to his/her own objects (tables, views, procedures, functions, etc.), i.e. to objects defined in the own schema. Access to other objects has to be explicitly allowed using GRANT statement. Granted privilege can be later removed using REVOKE statement M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 11

12 GRANT {ALL [PRIVILEGES] privilege [, ]} ON object TO {PUBLIC username rolename } [, ] [WITH GRANT OPTION] M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 12

Privileges: SELECT INSERT UPDATE ALTER EXECUTE WITH GRANT OPTION Grantee can spread obtained privilege further to other users If the grantee loses the privilege in

13 Privileges: SELECT INSERT UPDATE ALTER EXECUTE WITH GRANT OPTION Grantee can spread obtained privilege further to other users If the grantee loses the privilege in the future, the privilege is transitively revoked from all users whom he/she granted it M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 13

14 GRANT SELECT, INSERT ON Employee TO SCOTT; GRANT ALL EXCEPT DROP ON Department TO SCOTT WITH GRANT OPTION; GRANT SELECT ON Employee TO PUBLIC; SCOTT can select data in my table Employee and update existing rows SCOTT can do anything but drop the table, and can grant those privileges to other users Anyone is allowed to read (select) data from the table M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 14

15 CREATE ROLE Student; GRANT Student TO Novak; GRANT SELECT ON Emp TO Student; CREATE ROLE Seminar [IDENTIFIED BY passwd]; GRANT UPDATE, INSERT ON Emp TO Seminar; GRANT Student TO Seminar; Create new role Student Make Novak a member of Student role All students (members of Student role can select data from table Emp Further (password protected) role Seminar members can modify old data and create new data All Seminar members are Students and so have all their privileges M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 15

16 CREATE ROLE Student; GRANT Student TO Novak; GRANT SELECT ON Emp TO Student; Create new role Student Make Novak a member of Student role All students (members of Student role can select data from table Emp M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 16

17 Due to existence of roles and WITH GRANT OPTION modifier there can exist more than one path, granting particular permission to given user. The user is granted to do some activity until there exists at least one path allowing it in the database M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 17

18 SCOTT ALL SCOTT.Emp UPDATE INSERT ALL WITH G.O. SELECT Seminar Student NOVAK UPDATE DELETE WITH G.O. KOPECKY M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 18

19 Thanks to privileges it is possible to completely separate the owner of data (that can do anything with them) from users that manipulate them through applications (and that can be allowed to do only specified set of actions). So users can log using their own credentials and their own schemas and work with data they don t own. This way they can do only allowed actions that were explicitly assigned. Different users can have assigned different sets of allowed actions even they use the same application. They cannot disable triggers, see inappropriate data etc. M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 19

20 REVOKE {ALL [PRIVILEGES] privilege [, ]} ON object FROM {PUBLIC username rolename } [, ] M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 20

21 Using dot notation Schema_name.Object_name M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 21

22 Procedures, functions and triggers are by default executed with authorization, corresponding to the user, that owns them (defined them). It is similar to execution of program with setuid bit set in OS UNIX/Linux. It is useful for shielding the user from structure of tables he/she manipulates with. User that executes them need not have privileges to manipulate data in tables directly M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 22

23 Sometimes it is necessary to execute the procedure with different authorization In Oracle using clause AUTHID {CURRENT_USER DEFINER} CURRENT_USER ~ with privileges of the caller DEFINER ~ with privileges of the owner (default) In MS SQL using clause EXECUTE AS {CALLER SELF OWNER username } CALLER ~ with privileges of the caller SELF ~ with privileges of the user who creates the procedure (can differ from the owner) OWNER ~ with privileges of the owner (default) username ~ with privileges of given user M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 23

24 Example: CREATE OR REPLACE PROCEDURE p AUTHID CURRENT_USER AS ; CREATE OR REPLACE FUNCTION f RETURN NUMERIC AUTHID CURRENT_USER AS ; M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 24

25 Example: CREATE PROCEDURE p AS EXECUTE AS CALLER; CREATE FUNCTION f RETURNS NUMERIC AS EXECUTE AS CALLER; M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 25

26 Some operation is useful to execute some operation independently on the fact, if the rest of the work is committed or not For example, it is useful to journal tries to violate security rules in spite of the fact, that the operation failed and its effect will not be stored. In Oracle using PRAGMA AUTONOMOUS_TRANSACTION in the block declaration M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 26

27 Example: CREATE OR REPLACE PROCEDURE p AUTHID CURRENT_USER AS PRAGMA AUTONOMOUS_TRANSACTION; ; M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 27

28 It is necessary to take into account, that not only one instance of the database application runs on the data exclusively. Typically more (tens, hundreds and more) instances or more different applications share the same data at the same time. It is necessary to run correctly even under such conditions! M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 28

29 Taking care of correctness of data should be done as close to them as possible What can be done using integrity constraints definition should be implemented by them, as they are implemented with multi-user environment in mind What can be done then using triggers should be implemented in triggers Data checking, actualization of functionally dependent values, Procedures and functions for safe manipulation with data M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 29

30 Testing the uniqueness of columns values done other way than by UNIQUE / PRIMARY KEY integrity constraint will not probably work well The sequence of statements SELECT COUNT(*) FROM IF /* row doesn t exist */ INSERT INTO will not work if executed more times at the same time, all sessions can obtain the number of rows first and then write the same row twice or more times M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 30

31 Database engine should allow to set different levels of transaction isolation according to ANSI SQL READ UNCOMMITED Can appear: Dirty read, Nonrepeatable Read, Phantom Read READ COMMITED Can appear: Nonrepeatable Read, Phantom Read REPEATABLE READ Can appear : Phantom Read SERIALIZABLE M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 31

32 Dirty read - READ UNCOMMITED (transaction sees data changed but not committed by other transaction) Transaction 1 Transaction 2 UPDATE Account /* > 10100*/ SET Balance = Balance*1.01 WHERE Acc_Nr = ; ROLLBACK; SELECT Ballance /*10100*/ FROM Account WHERE Acc_Nr = ; M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 32

33 Non-repeatable read - READ UNCOMMITED, READ COMMITED (transaction reads the same data more times, each time with different value) Transaction 1 Transaction 2 UPDATE Account /* > 10100*/ SET Balance = Balance*1.01 WHERE Cis_Uctu = ; COMMIT; SELECT Balance /*10000*/ FROM Account WHERE Acc_Nr = ; SELECT Balance /*10100*/ FROM Account WHERE Acc_Nr = ; M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 33

34 Phantom read - READ UNCOMMITED, READ COMMITED, REPEATABLE READ (transaction executes SELECT more times, each time with different result set) Transaction 1 Transaction 2 INSERT INTO Account VALUES( , Standard ); COMMIT; SELECT * /*Without */ FROM Acount WHERE Acc_Type = Standard ; SELECT * /*Including */ FROM Account WHERE Acc_Type = Standard ; M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 34

35 Dirty read Non-repeatable read Phantom read READ UNCOMMITED READ COMMITED REPEATABLE READ SERIALIZABLE Read lock Write lock Range lock READ UNCOMMITED READ COMMITED REPEATABLE READ SERIALIZABLE M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 35

36 Oracle guaranties by default only consistency on individual statement level,which is equivalent to setting SET TRANSACTION ISOLATION LEVEL READ COMMITED The more strict isolation can be set by SET TRANSACTION ISOLATION LEVEL SERIALIZABLE which is usually suitable for short transaction, for long transaction it holds huge number of locks for long time. M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 36

37 Oracle physically supports only above mentioned levels READ COMMITED and SERIALIZABLE Other levels substituted by closest higher level MS SQL supports all levels of isolation M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 37

39 By default the locking of rows and tables is done by the RDBMS itself according to the isolation level set by statement SET TRANSACTION ISOLATION LEVEL In some cases it is necessary to lock some rows or tables explicitly to achieve highest level of consistency than the set one Setting isolation level permanently to SERIALIZABLE complicates the concurrent processing of data due to too pessimistic locking. M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 39

40 When to lock tables explicitly For example before critical mass update in the table or tables Migration to different structure Mass processing on the end of year Stock-taking... It can be also used as an synchronization primitive (semaphore) for mutual exclusion of more clients in critical section M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 40

41 When to lock rows explicitly For example before updating given row and/or associated rows in the child table Prevention of concurrent manipulation with Invoices and their rows M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 41

42 Row-level locking of all rows found by the SELECT statement SELECT FOR UPDATE [NOWAIT]; If the NOWAIT is used, the Oracle raises an exception ORA DECLARE ALREADY_LOCKED EXCEPTION; -- new exception -- assigning to standard system exception PRAGMA EXCEPTION_INIT(ALREADY_LOCKED,-54); BEGIN EXCEPTION WHEN ALREADY_LOCKED THEN ; END; M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 42

43 Row-level locking of all rows found by the SELECT statement SELECT FOR UPDATE [NOWAIT]; If the NOWAIT is not used, the transaction is blocked until existing locks are released. The deadlock can occur. In that case the exception ORA is thrown by the system. M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 43

44 Explicit locking of pages/rows found by SELECT statement: BEGIN TRAN[SACTION] SELECT WITH (lock_hints); NOLOCK do not {create shared locks respect existing locks} HOLDLOCK keep shared lock until end of transaction UPDLOCK/XLOCK create an update/exclusive lock and keep it until end of transaction READ[UN]COMMITTED, REPEATABLEREAD, SERIALIZABLE use the semantics as if given isolation level is set NOWAIT do not wait for locks and return an error M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 44

45 Explicit locking of pages/rows found by SELECT statement: BEGIN TRAN[SACTION] SELECT WITH (lock_hints); READPAST skips already locked rows instead of waiting or returning an error ROWLOCK use finer row-level locking instead of default pagelevel locks PAGLOCK use default page-level locking M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 45

46 Table can be locked in exclusive and/or shared mode. Table can be concurrently locked in shared mode in more sessions. Data can be read by any transaction. LOCK TABLE t IN {SHARED EXCLUSIVE} MODE [NOWAIT]; M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 46

47 Table can be locked in the exclusive and or shared mode using SELECT statement: BEGIN TRAN[SACTION] SELECT WITH (lock_requirements); TABLOCK shared table lock until end of statement, with HOLDLOCK until end of transaction TABLOCKX exclusive table lock until end of statement, with HOLDLOCK until end of transaction M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 47

Only implicit unlocking is available at the end of each transaction (strict two-phase locking protocol) COMMIT; Changes are committed and locks are released ROLLBACK; Changes are rolled back and

48 Only implicit unlocking is available at the end of each transaction (strict two-phase locking protocol) COMMIT; Changes are committed and locks are released ROLLBACK; Changes are rolled back and locks are released ROLLBACK TO SAVEPOINT name; resp. ROLLBACK TRANSACTION name :varname Rolls back changes since given savepoint and releases all corresponding locks M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 48

49 DECLARE CURSOR C(d NUMBER) IS SELECT * FROM Emp WHERE DeptNo=d FOR UPDATE NOWAIT; ALREADY_LOCKED EXCEPTION; PRAGMA EXCEPTION_INIT(ALREADY_LOCKED,-54); BEGIN FOR I IN LOOP BEGIN FOR R IN C(10) LOOP END LOOP; EXIT; -- Successful attempt EXCEPTION WHEN ALREADY_LOCKED THEN NULL; END; END LOOP; END; M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 49

50 BEGIN TRANS = COUNT(*) FROM tbl WITH ( TABLOCK, UPDLOCK, HOLDLOCK ) M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 50

52 For common aggregations there are clauses GROUP BY and HAVING together with aggregation functions MIN, MAX, AVG, COUNT, COUNT DISTINCT, in SQL They construct groups from rows with the same values of all mentioned columns (expressions) One group forms one row on output of the SELECT statement For these groups aggregation values are computed M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 52

53 Columns, used in the GROUP BY clause are often not independent. They can for example form a hierarchy Example: sales of goods: Columns: Region, City, Branch, Salesman forms gradual refinement of the place of the sale The management would like to know total sales revenues for individual regions, cities, branches, or even salesmen M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 53

54 One possibility is to use more aggregated queries and their concatenation using UNION ALL operator SELECT Region, City, Branch, Salesman, SUM(Price) FROM Sales GROUP BY Region, City, Branch, Salesman UNION ALL SELECT Region, City, Branch, NULL, SUM(Cena) FROM Sales GROUP BY Region, City, Branch UNION ALL M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 54

55 SQL-92 Entry defines extension GROUP BY ROLLUP (column 1, column 2, ) that computes such additional aggregations for higher levels Easy formulation of the query Higher consistency. When ISOLATION LEVEL < SERIALIZABLE is set, each part of the query can run separately M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 55

56 When GROUP BY ROLLUP over k columns/expressions is used, the groups are created for each combination of values in all k columns, in first k-1 columns, in first k-2 columns, etc. M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 56

57 SELECT Region, City, Branch, Salesman, SUM(Price) FROM Sales GROUP BY ROLLUP ( Region, City, Branch, Salesman ); REGION CITY BRANCH SALESMAN SUM(PRICE) Praha Praha Karlín Novák Praha Praha Karlín Dvořák Praha Praha Karlín Praha Praha Smíchov Malá Praha Praha Smíchov Praha Praha M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 57

58 If columns in GROUP BY clause are independent, sometimes it is useful to compute aggregations for all subsets of columns Example: sales of goods:: columns: Region, TypeOfGoods We need to know also total sums in individual Regions as well as total sums over individual types of goods. And of course the total revenue of the company. M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 58

59 Using the combination of more SELECT statement concatenated by UNION ALL is not effective. For k columns it is necessary to use 2 k subsets / SELECT statements M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 59

60 SQL-92 Entry defines extension GROUP BY CUBE (column 1, column 2, ) that creates all aggregation in one statement automatically M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 60

61 SELECT Region, TypeOfGoods, SUM(Price) FROM Sales GROUP BY CUBE (Region, TypeOfGoods); REGION TYPEOFGOODS SUM(PRICE) Prague Electro Prague Groceries Kladno Electro Liberec Groceries Prague Electro M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 61

62 GROUP BY GROUPING SETS Allows define combinations of columns for which aggregation are computed SELECT Column1, Column2, Column3, FROM TableName GROUP BY GROUPING SETS( (Column1, Column2, Column3), (Column1, Column2), (Column2, Column3) ); M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 62

63 Function GROUPING(column) {0,1} Returns information, if the column was or was not used in given aggregation Function GROUPING_ID(column, ) N Returns information, if columns were or were not used in given aggregation in form of bitmap M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 63

64 Example select region, category, sum(price) total, grouping(region) gr, -- {0 1} grouping(category) gc, -- {0 1} grouping_id(category) gidc, -- {0 1} grouping_id(category,region) gidcr -- {0 1}+{0 2} from sales group by cube (region, category); REGION CATEGORY TOTAL GR GC GIDC GIDCR =11 b Food =01 b Electro =01 b Brno =01 b Brno Electro =00 b Praha =01 b M. Kopecký Data Security - Transactions and Privileges (NDBI026, Lect. 5) 64

Module 15: Managing Transactions and Locks

Module 15: Managing Transactions and Locks Overview Introduction to Transactions and Locks Managing Transactions SQL Server Locking Managing Locks Introduction to Transactions and Locks Transactions Ensure