, , ,

Transaction Control

One of the great benefits Oracle provides you is the ability to make changes in database using SQL statements and then decide later whether we want to save or discard them. Oracle enables you to execute a series of data-change statements together as one logical unit of work, called a transaction, that’s terminated when you decide to save or discard the work. A transaction begins with your first executable SQL statement. Some advantages for offering transaction processing in Oracle include the following:

  • Transactions enable you to ensure read-consistency to the point in time a transaction began for all users in the Oracle database.
  • Transactions enable you to preview changes before making them permanent in Oracle.
  • Transactions enable you to group logically related SQL statements into one logical unit of work.

Transaction processing consists of a set of controls that enable a user issuing an insert, update, or delete statement to declare a beginning to the series of data-change statements he or she will issue. When the user has finished making the changes to the database, the user can save the data to the database by explicitly ending the transaction. Alternatively, if a mistake is made at any point during the transaction, the user can have the database discard the changes made to the database in favor of the way the data existed before the transaction.
The commands that define transactions are as follows:

  1. Set transaction Initiates the beginning of a transaction and sets key features. This command is optional. A transaction will be started automatically when you start SQL*Plus, commit the previous transaction, or roll back the previous transaction.
  2. Commit Ends the current transaction by saving database changes and starts a new transaction.
  3. Rollback Ends the current transaction by discarding database changes and starts a new transaction.
  4. Savepoint Defines breakpoints for the transaction to enable partial rollbacks.
  5. Locks

Set transaction

This command can be used to define the beginning of a transaction. If any change is made to the database after the set transaction command is issued but before the transaction is ended, all changes made will be considered part of that transaction. The set transaction statement is not required, because a transaction begins under the following circumstances:

  • As soon as you log onto Oracle via SQL*Plus and execute the first command
  • Immediately after issuing a rollback or commit statement to end a transaction
  • When the user exits SQL*Plus
  • When the system crashes
  • When a data control language command such as alter database is issued

By default, a transaction will provide both read and write access unless you override this default by issuing set transaction read only. You can set the transaction isolation level with set transaction as well. The set transaction isolation level serializable command specifies serializable transaction isolation mode as defined in SQL92. If a serializable transaction contains data manipulation language (DML) that attempts to update any resource that may have been updated in a transaction uncommitted at the start of the serializable transaction, the DML statement fails. The set transaction isolation level read committed command is the default Oracle transaction behavior. If the transaction contains DML that requires row locks held by another transaction, the DML statement waits until the row locks are released
Commit
The commit statement in transaction processing represents the point in time where the user has made all the changes he or she wants to have logically grouped together, and because no mistakes have been made, the user is ready to save the work. The work keyword is an extraneous word in the commit syntax that is designed for readability.
Issuing a commit statement also implicitly begins a new transaction on the database because it closes the current transaction and starts a new one. By issuing a commit, data changes are made permanent in the database. The previous state of the data is lost. All users can view the data, and all savepoints are erased. It is important also to understand that an implicit commit occurs on the database when a user exits SQL*Plus or issues a data-definition language (DDL) command such as a create table statement, used to create a database object, or an alter table statement, used to alter a database object.
The following is an example:
SQL> COMMIT;
Commit complete.
SQL> COMMIT WORK;
Commit complete.
Rollback
  If you have at any point issued a data-change statement you don’t want, you can discard the changes made to the database with the use of the rollback statement. The previous state of the data is restored. Locks on the affected rows are released. After the rollback command is issued, a new transaction is started implicitly by the database session. In addition to rollbacks executed when the rollback statement is issued, implicit rollback statements are conducted when a statement fails for any reason or if the user cancels a statement with the CTRL-C cancel command. The following is an example:
SQL> ROLLBACK;
Rollback complete
Savepoint
In some cases involving long transactions or transactions that involve many data changes, you may not want to scrap all your changes simply because the last statement issued contains unwanted changes. Savepoints are special operations that enable you to divide the work of a transaction into different segments. You can execute rollbacks to the savepoint only, leaving prior changes intact. Savepoints are great for situations where part of the transaction needs to be recovered in an uncommitted transaction. At the point the rollback to savepoint so_far_so_good statement completes in the following code block, only changes made before the savepoint was defined are kept when the commit statement is issued:
UPDATE products
SET quantity = 55
WHERE product# = 59495;
SAVEPOINT so_far_so_good;
//Savepoint created.
UPDATE spanky.products
SET quantity = 504;
ROLLBACK TO SAVEPOINT so_far_so_good;
COMMIT;

Locks
The final aspect of the Oracle database that enables the user to employ transaction processing is the lock, the mechanism by which Oracle prevents data from being changed by more than one user at a time. Several different types of locks are available, each with its own level of scope. Locks available on a database are categorized into table-level locks and row-level locks.
A table-level lock enables only the user holding the lock to change any piece of row data in the table, during which time no other users can make changes anywhere on the table. A table lock can be held in any of several modes: row share (RS), row exclusive (RX), share (S), share row exclusive (SRX), and exclusive (X). The restrictiveness of a table lock’s mode determines the modes in which other table locks on the same table can be obtained and held.
A row-level lock gives the user the exclusive ability to change data in one or more rows of the table. However, any row in the table that is not held by the row-level lock can be changed by another user
Tip
An update statement acquires a special row-level lock called a row-exclusive lock, which means that for the period of time the update statement is executing, no other user in the database can view or change the data in the row. The same goes for delete or insert operations. Another update statement—the select for update statement—acquires a more lenient lock called the share row lock. This lock means that for the period of time the update statement is changing the data in the rows of the table, no other user may change that row, but users may look at the data in the row as it changes.

/by
, , ,

DELETE Statement

The DELETE statement allows you to delete a single record or multiple records from a table.
The syntax for the DELETE statement is:
    DELETE FROM table
    WHERE predicates;
Example #1 : Simple example
Let’s take a look at a simple example:
    DELETE FROM suppliers
    WHERE supplier_name = ‘IBM’;
This would delete all records from the suppliers table where the supplier_name is IBM. You may wish to check for the number of rows that will be deleted. You can determine the number of rows that will be deleted by running the following SQL statement before performing the delete.
Example #2 : More complex example
You can also perform more complicated deletes.
You may wish to delete records in one table based on values in another table. Since you can’t list more than one table in the FROM clause when you are performing a delete, you can use the EXISTS clause.
For example:
    DELETE FROM suppliers
    WHERE EXISTS
      ( select customers.name
         from customers
         where customers.customer_id = suppliers.supplier_id
         and customers.customer_name = ‘IBM’ );
This would delete all records in the suppliers table where there is a record in the customers table whose name is IBM, and the customer_id is the same as the supplier_id.
/by
, , ,

Merge into in SQL

The merge command syntax is
merge into table1
using table2 on (join_condition)
when matched update set col1 = value
when not matched insert (column_list) values (column_values).
The statement components work in the following way:
1. In the merge into table1 clause, you identify a table into which you would like to update data in an existing row or add new data if the row doesn’t already exist as table1.

2. In the using table2 clause, you identify a second table from which rows will be drawn in order to determine if the data already exists as table2. This can be a different table or the same table as table1. However, if table2 is the same table as table1, or if the two tables have similar columns, then you must use table aliases to preface all column references with the correct copy of the table. Otherwise, Oracle will return an error stating that your column references are ambiguously defined.
In the on (join_condition) clause, you define the join condition to link the two tables together. If table2 in the using clause is the same table as table1 in the merge into clause, or if the two tables have similar columns, then you must use table aliases or the table.column syntax when referencing columns in the join or filter conditions. Otherwise, Oracle will return an error stating that your column references are ambiguously defined.
3. In the when matched then update set col1 = value clause, you define the column(s) Oracle should update in the first table if a match in the second table is found. If table2 in the using clause is the same table as table1 in the merge into clause, or if the two tables have similar columns, then you must use table aliases or the table.column syntax when referencing columns in the update operation. Otherwise, Oracle will return an error stating that your column references are ambiguously defined.
4. In the when not matched then insert (column_list) values (value_list) clause, you define what Oracle should insert into the first table if a match in the second table is not found. If table2 in the using clause is the same table as table1 in the merge into clause, or if the two tables have similar columns, then you must use table aliases or the table.column syntax to preface all column references in column_list. Otherwise, Oracle will return an error stating that your column references are ambiguously defined.
Example
Consider the following scenario. Say you manage a movie theater that is part of a national chain. Everyday, the corporate headquarters sends out a data feed that you put into your digital billboard over the ticket sales office, listing out all the movies being played at that theater, along with showtimes. The showtime information changes daily for existing movies in the feed.
merge into movies M1
using movies M2 on (M2.movie_name = M1.movie_name and M1.movie_name = ‘GONE WITH THE WIND’)
when matched then update set M1.showtime = ‘7:30 PM’
when not matched then insert (M1.movie_name, M1.showtime) values (‘GONE WITH THE WIND’,’7:30 PM’);

/by
, , ,

UPDATE Statement

Data manipulation on Oracle tables does not end after you add new records to your tables. Often, the rows in a table will need to be changed. In order to make those changes, the update statement can be used.
The UPDATE statement allows you to update a single record or multiple records in a table.
The syntax for the UPDATE statement is:
    UPDATE table
    SET column = expression
    WHERE predicates;
Example #1 – Simple example
Let’s take a look at a very simple example.
    UPDATE suppliers
    SET name = ‘HP’
    WHERE name = ‘IBM’;
This statement would update all supplier names in the suppliers table from IBM to HP.
Example #2 – More complex example
You can also perform more complicated updates.
You may wish to update records in one table based on values in another table. Since you can’t list more than one table in the UPDATE statement, you can use the EXISTS clause.
For example:
    UPDATE suppliers    
    SET supplier_name =     ( SELECT customers.name
    FROM customers
    WHERE customers.customer_id = suppliers.supplier_id)
    WHERE EXISTS
      ( SELECT customers.name
        FROM customers
        WHERE customers.customer_id = suppliers.supplier_id);Whenever a supplier_id matched a customer_id value, the supplier_name would be overwritten to the customer name from the customers table.
/by
, , ,

INSERT Statement

The INSERT statement allows you to insert a single record or multiple records into a table.
The general syntax for an insert statement is insert into tablename (column_list) values (valuesl_list), where tablename is the
name of the table you want to insert data into, column_list is the list of columns for which you will define values on the record being added, and values_list is the list of those values you will define. The datatype of the data you add as values in the values list must correspond to the datatype for the column identified in that same position in the column list.
The syntax for the INSERT statement is:

INSERT INTO table_name
(column-1, column-2, … column-n) VALUES (value-1, value-2, … value-n);

Example 1:
INSERT INTO  XX_PO_HEADERS_ALL
(PO_ID, PO_NUMBER, SUPPLIER_NAME) VALUES(6, 10, ‘ARCODA’)
Example 2:
you may not necessarily need to define explicit columns of the table. You only need to do that when you don’t plan to populate every column in the record you are inserting with a value.
insert into employee
values (‘02039′,’WALLA’,’RAJENDRA’,60000,’01-JAN-96′,’604B’);
Example 3:
INSERT INTO suppliers
(supplier_id, supplier_name) SELECT account_no, name FROM customers WHERE city = ‘Newark’;
Example 4:
The following is an example of how you might insert 3 rows into the suppliers table in Oracle.
INSERT ALL
INTO  XX_PO_HEADERS_ALL(PO_ID, PO_NUMBER, SUPPLIER_NAME) VALUES(4, 10, ‘ARCODA’)
INTO  XX_PO_HEADERS_ALL(PO_ID, PO_NUMBER, SUPPLIER_NAME) VALUES(5, 10, ‘ARCODA’)
Select * from dual

/by