• Aucun résultat trouvé

A Transaction, Step by Step

Dans le document Oracle Essentials Oracle Database 11g (Page 100-103)

This simple example illustrates the complete process of a transaction. The example uses the EMP table of employee data, which is part of the traditional test schema shipped with Oracle databases. In this example, an HR clerk wants to update the name of an employee. The clerk retrieves the employee’s data from the database, updates the name, and commits the transaction.

The example assumes that only one user is trying to update the information for a row in the database. Because of this assumption, it won’t include the steps normally taken by Oracle to protect the transaction from changes by other users, which are detailed in Chapter 8.

The HR clerk already has the employee record on-screen and so the database block containing the row for that employee is already in the database buffer cache. The steps from this point would be:

1. The user modifies the employee name on-screen and the client application sends a SQL UPDATE statement over the network to the server process.

2. The server process looks for an identical statement in the shared SQL area of the shared pool. If it finds one, it reuses it. Otherwise, it checks the statement for syntax and evaluates it to determine the best way to execute it. This processing of the SQL statement is called parsing and optimizing. (The optimizer is described in more detail in Chapter 4.) Once the processing is done, the state-ment is cached in the shared SQL area.

3. The server process copies the old image of the employee data about to be changed to a rollback segment and to a redo seqment. The rollback segment changes are part of the redo. This may seem a bit odd, but remember that redo is generated forall changes resulting from the transaction. The contents of the rollback seg-ment have changed because the old employee data was written to the rollback segment for undo purposes. This change to the contents of the rollback segment is part of the transaction and therefore part of the redo for that transaction.

4. Once the server process has completed this work, the process modifies the data-base block to change the employee name. The datadata-base block is stored in the database cache at this time.

Oracle at Work | 81 5. The HR clerk commits the transaction.

6. The Log Writer (LGWR) process writes the redo information for the entire transaction from the redo log buffer to the current redo log file on disk. When the operating system confirms that the write to the redo log file has successfully completed, the transaction is considered committed.

7. The server process sends a message to the client confirming the commit.

The user could have canceled or rolled back the transaction instead of committing it, in which case the server process would have used the old image of the employee data in the rollback segment to undo the change to the database block.

Figure 3-8 shows the steps described here. Network traffic appears as dotted lines.

Figure 3-8. Steps for a transaction SGA

LGWR

Datafiles Control FIles

Redo Logs Redo Log

Buffer Shared Pool Database Buffer Cache

Client

NETWORK 6

5 Commit 7 Committed!

Redo to disk

1 Update

Server

Save undoand updateemp name

Reuse or proc

ess SQL Redo for changes

3 2 4

82

Chapter 4

CHAPTER 4

Oracle Data Structures

4

In the previous chapters, we examined some distinctions between the different com-ponents that make up an Oracle database. For example, we pointed out that the Oracle instance differs from the files that make up the physical storage of the data in tablespaces, that youcannot access the data in a tablespace except through an Ora-cle instance, and that the instance itself isn’t very valuable without the data stored in those files.

The instance is the logical entity used by applications and users, separate from the physical storage of data. In a similar way, the actual tables and columns are logical entities within the physical database. The user who makes a request for data from an Oracle database probably doesn’t know anything about instances and tablespaces, but does know about the structure of her data, as implemented with tables and columns.

To fully leverage the power of Oracle, you must understand how the Oracle database server implements and uses these logical data structures, the topic of this chapter.

Datatypes

Thedatatypeis one of the attributes for acolumnor a variable in a stored procedure.

A datatype describes and limits the type of information stored in a column, and can limit the operations that you can perform on columns.

Youcan divide Oracle datatype support into three basic varieties: character datatypes, numeric datatypes, and datatypes that represent other kinds of data. You can use any of these datatypes when you create columns in a table, as with this SQL statement:

CREATE SAMPLE_TABLE(

char_field CHAR(10), varchar_field VARCHAR2(10), todays_date DATE)

You also use these datatypes when you define variables as part of a PL/SQL procedure.

Datatypes | 83

Dans le document Oracle Essentials Oracle Database 11g (Page 100-103)