OCA 09 - Managing Data and Concurrency

09 - Managing Data and Concurrency
By Muhammad Asghar Khan

Reference: OCA Oracle Database 11g - Admin I Exam Guide by John Watson
1/2
Agenda
Manage Data Using DML
Atomicity Consistency Isolation Durable Execution of DML Statement Transaction Control

Rollback Commit
EXERCISE 09-1: Manage Data Using DML Identify and Administer PL/SQL Objects
Procedures and Functions

http://asghars.blogspot.com
2/2
Agenda

Packages Database Triggers Exclusive Lock Shared Lock
Monitor and Resolve Locking Conflicts

EXERCISE 09-2: Detect and Resolve Lock Contention
1/11
DML commands change data in tables, they will also change data in indexes, but this is automatic RDBMS group one or more DML statements into transactions Any RDBMS must be able to pass the ACID test: it must guarantee atomicity, consistency, isolation, and durability Atomicity
Principle of atomicity states that either all parts of transaction must complete, or none of them complete
2/11
The rollback of an incomplete transaction is the reversal process Oracle guarantees atomicity through the use of undo segments
Consistency
The principle of consistency states that the results of a query must be consistent with the state of the database at the time the query started Through the use of undo segments Oracle guarantees that if a query succeeds, the result will be consistent
3/11
If your undo segments are incorrectly configured, the query may not succeed: there is a famous Oracle error, ORA-1555 snapshot too old, that is raised The principle of isolation states that an incomplete (that is, uncommitted) transaction must be invisible to the rest of the world Transaction isolation requires that the database must conceal transactions in progress from other users Oracle guarantees transaction isolation through use of undo segments
Isolation
4/11
Durable
The principle of durability states that once a transaction completes, it must be impossible for the database to lose it Oracle fulfils this requirement through the use of log files (online and archived redo log) For any DML operation, it is necessary to work on both data blocks and undo blocks, and also to generate redo: the A, C, and I of the ACID test require generation of undo; the D requires generation of redo Redo protects all block changes while undo segment is just another segment
Execution of DML Statement
5/11

Execution of DML statements involve the following steps: 1. An empty block or required blocks are checked in the database buffer cache, or copied into the database buffer cache from the datafiles 2. An empty or expired block of an undo segment is selected
1. 2.
For INSERT & UPDATE only a rowid is written to the undo block For a DELETE, the whole row (which might be several kilobytes) must be written to the undo block
3.
8
Locks are placed on rows and associated index keys that are going to be affected by the operation
6/11

4.

Then the redo is generated

The server process writes to the log buffer the change vectors that are going to be applied to the data blocks Generation of redo is applied both to table block changes and to undo block changes
5.
At last the DML statement is carried out in the database buffer cache
Transaction Control Rollback
If anything goes wrong, rollback of transactions in progress is completely automatic and is carried out by background processes
7/11
A manual rollback requires the user to issue the ROLLBACK command
10
In the case of an UPDATE, the pre-update versions of the columns, as stored in the block of undo segment, are used to construct another UPDATE command that will set the columns of the row in the table block back to their original values In case of INSERT Oracle retrieves the rowid of the inserted row from the undo block and uses it as the key for a DELETE statement on the table In case of DELETE, Oracle constructs a complete INSERT statement from the data in the undo block Then Oracle will issue a COMMIT that will commit both the original change and the rollback change, as one transaction
8/11
A rollback will itself generate more redo as it executes, perhaps rather more than the original statement A COMMIT involves nothing more than flushing the log buffer to disk, and flagging the transaction as complete DBWn does absolutely nothing during the commit When you say COMMIT, LGWR actually does write in real time: your session will hang until the write is complete The change vectors written to the redo log are all the change vectors: those applied to data blocks (tables and indexes) and those applied to undo segments
Commit

11
9/11
DBWn writes only a few dirty buffers to disk; when a checkpoint is signaled, it writes all dirty buffers to disk So in principle, your database on disk is corrupted: the datafiles may well be storing uncommitted work, and be missing committed changes
The COMMIT and ROLLBACK statements does not apply to DDL When you create a table, you are in fact doing a transaction against data dictionary tables: like SYS.TAB$ and SYS.COL$ and then the command concludes with a COMMIT
12 http://asghars.blogspot.com
10/11
Therefore; executing one or more DML commands followed by a DDL command will commit the whole lot: the DML statements as well as the DDL statement, this is called auto-commit or implicitcommit Another situation when auto-commit is happened, On Windows when you exit (EXIT) from a user process such as SQL*Plus This is because built into the SQL*Plus EXIT command there is a COMMIT statement If you click in the top-right corner of the SQL*Plus window, the transaction will be rollback
11/11

The behavior of SQL*Plus on other platforms may well be different; the only way to be sure is to test it There is a SQL*Plus command SET AUTOCOMMIT ON
14
1/4
EXERCISE 09-1: Manage Data Using DML
Open two SQL*Plus sessions and connect as SYSTEM

2nd Session
Step 1st Session 1
Results are the same
15
2/4

Step 1st Session 3 2nd Session
Results differ because transaction isolation conceals the changes
16
3/4

Results are the same in both sessions 7
17
4/4

10
11
12
Oh The DDL statement committed the DELETE, so it cant be rolled back.

1/7
Identify and Administer PL/SQL Objects
PL/SQL is Oracles proprietary 3GL that runs within the database You can use it to retrieve and manipulate data with SQL, while using procedural constructs such as IF...THEN...ELSE or FOR or WHILE The PL/SQL code can be stored on a client machine and sent to the server for execution, or it can be stored within the database as a named block of code Code stored remotely, or ad hoc code issued at the SQL*Plus prompt, is anonymous PL/SQL
2/7
Anonymous PL/SQL is less efficient than stored PL/SQL and also causes problems with source code management, as the code may be distributed across many machines Some of the commonly used PL/SQL objects are: Procedures and Functions
A procedure is a block of code that carries out some action. It can, optionally, be defined with a number of arguments
20
3/7
The arguments can be IN arguments, meaning that they are used to pass data into the procedure, or OUT arguments, meaning that they are modified by the procedure and after execution the new values are passed out of the procedure Arguments can also be IN-OUT, where the one variable serves both purposes To run a procedure, either call it from within a PL/SQL block or use the interactive EXECUTE command A function is similar in concept to a procedure, but it does not have OUT arguments and cannot be invoked with EXECUTE. It returns a single value, with the RETURN statement
21
4/7
Functions are generally used for relatively simple operations Following code creates and invoke a procedure
22
5/7
Packages

Packages group related procedures and functions together A package consists of two objects: a specification and a body A package specification lists the functions and procedures in the package. It can also define variables and constants accessible to all the procedures and functions in the package The package body contains the PL/SQL code that implements the package
23
6/7
To create a package specification, use the CREATE PACKAGE command
To invoke a packaged procedure, you must prefix the procedure name with the package name
Database Triggers
Database triggers are a special category of PL/SQL object which runs (or fires) automatically, when a particular action is carried out, or a certain situation arises
24
7/7

Some of the common triggers are; DML triggers, DDL triggers, Database operation (SERVERERROR,LOGON, LOGOFF,STARTUP,SHUTDOWN,SUSPEND) There are numerous uses for triggers:
Auditing users actions Executing complex edits Security Enforcing complex constraints
It is impossible to run a trigger by any means other than its triggering event
25
1/5
Serialization of concurrent access is accomplished by record and table locking mechanisms Locking in an Oracle database is completely automatic Problems only arise if software tries to interfere with the automatic locking mechanism with poorly written code Exclusive Lock
In exclusive lock the first session to request the lock on the row/table gets it, and any other sessions requesting write access must wait
26
2/5
The lock is held until the transaction completes Shared lock can be taken on the same object by many sessions Shared locks are taken on whole tables, it would not make any sense to take a shared lock on one row The purpose of taking a shared lock on a table is to prevent another session acquiring an exclusive lock on the table Exclusive locks on tables are only required to execute DDL statements
Shared Lock

27
3/5
To execute DML on rows, a session must acquire exclusive locks on the rows to be changed, and shared locks on the tables containing the rows
The exclusive lock prevents another session from interfering with the row, and the shared lock prevents another session from changing the table definition with a DDL statement Requests for locks are queued
Lock contention arises when a session requests a lock on a row or object and cannot get it
4/5
The causes of lock contention may be the nature of the business, a user updates a row and then does not commit the change To detecting and resolve lock contention, Database home pagePerformance tabAdditional Monitoring Links sectionInstance Locks link Blocking locks are the locks that are causing sessions to hang To terminate a session, either use Database Control, or the ALTER SYSTEM KILL SESSION command
5/5

A special case of lock contention is the deadlock Deadlock is a position where two sessions block each other in such a fashion that both will hang, each waiting for the other to release its lock Deadlocks are not the DBAs problem; they are caused by bad program design and resolved automatically by the database itself Information regarding deadlocks is written out to the alert log, with full details in a trace file

1.
1/4
Using SQL*Plus, connect to database in two sessions as user SYSTEM Create a table to be used for this exercise
2.
3.
In your first session, lock all the rows in the INTEGERS table
31

4.
2/4
In your second session, attempt to update a row. The session will hang Connect to your database as user SYSTEM with database control Navigate to the Performance tab from the database home page, and then the Database Locks link in the Additional Monitoring Links section
5.
6.
32
3/4 EXERCISE 09-2: Detect and Resolve Lock Contention 7. Observe that the second SYSTEM session is shown as waiting for an EXCLUSIVE lock. Select the radio button for the first blocking session and click Kill Session
8.
In the confirmation window, click Show SQL, Click Return and Yes to execute the KILL SESSION command
33

9.
4/4
Returning to your SQL*Plus sessions, you will find that the second session is now working, but that the first session can no longer run any commands
34

OCA 09 - Managing Data and Concurrency

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

OCA 09 - Managing Data and Concurrency

Caricato da

Copyright:

Formati disponibili

09 - Managing Data and Concurrency

By Muhammad Asghar Khan

Manage Data Using DML

Atomicity Consistency Isolation Durable Execution of DML Statement Transaction Control

Procedures and Functions

Packages Database Triggers Exclusive Lock Shared Lock

Monitor and Resolve Locking Conflicts

EXERCISE 09-2: Detect and Resolve Lock Contention

Manage Data Using DML

Manage Data Using DML

Manage Data Using DML

Manage Data Using DML

Execution of DML Statement

Manage Data Using DML

Manage Data Using DML

Then the redo is generated

Transaction Control Rollback

Manage Data Using DML

A manual rollback requires the user to issue the ROLLBACK command

Manage Data Using DML

Manage Data Using DML

Manage Data Using DML

Manage Data Using DML

EXERCISE 09-1: Manage Data Using DML

Open two SQL*Plus sessions and connect as SYSTEM

Step 1st Session 1

Results are the same

EXERCISE 09-1: Manage Data Using DML

Results differ because transaction isolation conceals the changes

EXERCISE 09-1: Manage Data Using DML

Results are the same in both sessions 7

EXERCISE 09-1: Manage Data Using DML

Oh The DDL statement committed the DELETE, so it cant be rolled back.

Identify and Administer PL/SQL Objects

Identify and Administer PL/SQL Objects

Identify and Administer PL/SQL Objects

Identify and Administer PL/SQL Objects

Identify and Administer PL/SQL Objects

Identify and Administer PL/SQL Objects

To create a package specification, use the CREATE PACKAGE command

Identify and Administer PL/SQL Objects

Monitor and Resolve Locking Conflicts

Monitor and Resolve Locking Conflicts

Monitor and Resolve Locking Conflicts

Monitor and Resolve Locking Conflicts

Monitor and Resolve Locking Conflicts

EXERCISE 09-2: Detect and Resolve Lock Contention

EXERCISE 09-2: Detect and Resolve Lock Contention

EXERCISE 09-2: Detect and Resolve Lock Contention

Potrebbero piacerti anche