Escolar Documentos
Profissional Documentos
Cultura Documentos
PL/SQL Security
3. PL/SQL SECURITY
1.
2.
What are locks? Explain Oracles default locking strategy (Implicit locking).
1. Oracle is a multi-user system and several users may access a table at the same time for
either viewing it or for manipulating it through INSERT, UPDATE and DELETE
commands.
2. In order to maintain the integrity of the database, Oracle uses a technique of concurrency
control through the mechanism of locking.
3. Thus, locks are mechanisms to ensure data integrity while allowing maximum concurrent
access to data.
4. This locking mechanism is fully automatic and does not require user intervention.
5. The Oracle engine automatically locks table data while executing SQL statements. This
type of locking is called Implicit locking.
Implicit Locking:
Implicit Locking is Oracles default locking strategy. Oracle has to decide on two issues:
1. Types of locks to be applied,
2. Level of lock to be applied.
Types of Locks:
The type of lock to be placed on a resource depends on the operation being performed on that
resource. The two types of operations on tables are:
mukeshtekwani@hotmail.com
mukeshtekwani@hotmail.com
What is Exclusive locking? What is the need for exclusive locking? What are the various
techniques for exclusive locking?
Exclusive Locks:
This lock is placed on a resource whenever a write operation
(INSERT/UPDATE/DELETE) is being performed.
Only one exclusive lock can be placed on a resource at a time. The first user who acquires
an exclusive lock will continue to be the sole owner of the resource and no other user can
acquire an exclusive lock on that resource.
Need for exclusive locking:
Although the Oracle engine has a default locking strategy, explicit locking is often needed.
The following example explains the need for explicit locking:
Consider two client computers (Client A and Client B) are entering sales orders. Each time a
sales order is prepared, the QOH of the product must be updated in the PRODUCTS_MSTR
table. If client A fires an UPDATE command on a record of the PRODUCTS_MSTR table,
then Oracle will implicitly lock the record so that no further data manipulation can be done by
any other user till the lock is released. The lock will be released only when Client A fires a
COMMIT or a ROLLBACK command.
In the mean time, if Client B tries to view the same record, the Oracle engine will display the
old data for the record as the transaction for that record has not been completed by Client A.
Thus, Client B is viewing wrong information.
In such a situation, Client A must explicitly lock the record so that no other user can access the
record even for viewing purposes till client A completes his transaction.
Such a lock that is applied by the user on a row, page or the entire table is called an explicit
lock. Explicit locking is user-defined strategy and it always overrides Oracles default locking
strategy.
Tables and rows can be explicitly locked by using either the SELECTFOR UPDATE
statement or the LOCK TABLE statement.
The SELECTFOR UPDATE statement:
This statement is used for acquiring exclusive row-level locks. This statement informs the
Oracle engine that data currently being used needs to be updated. It is followed by UPDATE
statements with a WHERE clause.
Example 1:
Two clients A and B are recording the transactions performed in a bank for a particular
account number simultaneously.
Client A fires the statement:
Client A> SELECT * FROM ACCT_MSTR WHERE ACCT_NO = SB7 FOR UPDATE;
When the above SELECT statement is fired, Oracles engine locks the record SB7. This lock
will be released only when Client A issues the COMMIT or ROLLBACK command.
Now Client B fires a SELECT statement which points to record SB7 which has already been
locked by Client A.
Client B> SELECT * FROM ACCT_MSTR WHERE ACCT_NO = SB7 FOR UPDATE;
mukeshtekwani@hotmail.com
The Oracle engine ensures that Client Bs SQL statement waits for lock to be released on
ACCT_MSTR by a COMMIT or ROLLBACK statement. In order to avoid unnecessary
waiting time, a NOWAIT option can be used to inform Oracle engine to terminate the SQL
command if the record has already been locked. In this case Oracle engine generates a
message for Client B stating that the resource is busy. So in order not to wait for an uncertain
period, Client B can issue the following query:
Client B> SELECT * FROM ACCT_MSTR WHERE ACCT_NO = SB7 FOR UPDATE
NOWAIT;
The SELCT FOR UPDATE clause cannot be used with the following:
DISTINCT and GROUP BY clauses.
SET OPERATORS and GROUP functions.
Using the LOCK TABLE statement:
Oracles default locking strategy can be overridden by creating a lock in a specific mode. This
is done with the LOCK TABLE clause:
LOCK TABLE <tablename> [,<tablename>]
In {ROW SHARE | ROW EXCLUSIVE | SHARE UPDATE | SHARE | SHARE ROW
EXCLUSIVE | EXCLUSIVE }
[NOWAIT ]
In this syntax:
<tablename> indicates the names of the tables / views to be locked.
IN decides what other locks on the same resource can exist simultaneously. E.g., if there is
an exclusive lock on the table, no other user can update rows on the table. It can have the
following values:
o EXCLUSIVE Query is allowed on the locked resource but other activities are not
permitted
o SHARE Queries are allowed on the table but does not allow updates on the table
o ROW EXCLUSIVE this lock is acquired when using the commands UPDATE,
INSERT, or DELETE.
o SHARE EXCLUSIVE they are used to look at the whole table, to carry out
selective updates, and to allow other users to look at rows in the table but not lock
the table or update the rows.
NOWAIT Indicates that the Oracle engine should immediately return to the user with a
message, if the resources are busy. If this clause is omitted the Oracle engine will wait till
the resources available.
RELEASING LOCKS:
Locks are released under the following circumstances:
The transaction is completed successfully using the COMMIT verb.
A ROLLBACK is performed.
A ROLLBACK to a savepoint will release locks after the specific savepoint. But row-level
locks are not released by rolling back to a savepoint.
5
What are the important properties of a transaction that a DBMS must ensure?
There are four important properties of transactions that a DBMS must ensure to
maintain data in the face of concurrent access and system failures:
mukeshtekwani@hotmail.com
1. Users should be able to regard the execution of each transaction as atomic: either all
actions are carried out or none are. Users should not have to worry about the effect of
incomplete transactions (say, when a system crash occurs).
2. Each transaction, run by itself with no concurrent execution of other transactions, must
preserve the consistency of the database. This property is called consistency, and the
DBMS assumes that it holds for each transaction. Ensuring this property of a transaction is
the responsibility of the user.
3. Users should be able to understand a transaction without considering the effect of other
concurrently executing transactions, even if the DBMS interleaves the actions of several
transactions for performance reasons. This property is sometimes referred to as isolation:
Transactions are isolated, or protected, from the effects of concurrently scheduling other
transactions.
4. Once the DBMS informs the user that a transaction has been successfully completed, its
effects should persist even if the system crashes before all its changes are reflected on disk.
This property is called durability.
The acronym ACID is sometimes used to refer to the four properties of transactions that we
have presented here: atomicity, consistency, isolation and durability.
6
Write a simple program to increase the salary of employees whose salaries are less than
the average salary by 10 percent. The program re-computes and prints out the average
salary if it exceeds 50000 after the above update.
DECLARE
avg_salary NUMBER;
BEGIN
SELECT avg(salary) INTO avg_salary FROM employee;
UPDATE employee SET salary = salary*1.1
WHERE salary < avg_salary;
SELECT avg(salary) INTO avg_salary FROM employee;
IF avg_salary > 50000 THEN
dbms_output.put_line (Average Salary is | | avg_salary);
END IF;
END;
/
Display the employee number for those employees whose salary is greater than their
supervisors salary.
DECLARE
emp_salary NUMBER;
emp_super_salary NUMBER;
emp_ssn CHAR (9);
emp_superssn CHAR (9);
CURSOR salary_cursor IS SELECT ssn, salary, superssn FROM employee;
BEGIN
OPEN salary_cursor;
LOOP
FETCH salary_cursor INTO emp_ssn, emp_salary, emp_superssn;
mukeshtekwani@hotmail.com
Write a program segment that gets a list of all the employees, increments each
employees salary by 10 percent, and displays the old and the new salary.
DECLARE
v_fname employee.fname%TYPE;
v_minit employee.minit%TYPE;
v_lname employee.lname%TYPE;
v_address employee.address%TYPE;
v_salary employee.salary%TYPE;
CURSOR EMP IS SELECT ssn, fname, minit, lname, salary FROM employee;
BEGIN
OPEN EMP;
LOOP
FETCH EMP INTO v_ssn, v_fname, v_minit, v_lname, v_salary;
EXIT WHEN EMP%NOTFOUND;
dbms_output.putline(SSN: | | v_ssn | | Old salary : | | v_salary);
UPDATE employee SET salary = salary*1.1
WHERE ssn = v_ssn;
COMMIT;
dbms_output.putline(SSN: | | v_ssn | | New salary : | | v_salary*1.1);
END LOOP;
CLOSE EMP;
END;
/
mukeshtekwani@hotmail.com