Database files are normally stored in a proprietary binary format that can only be mounted by an instance of the relational database software that created them.

The purpose of the database instance is to to manage and deliver the data held within the database files for the users.

Modern Relational Database Management Systems (RDBMS) provide a declarative natural language abstraction layer called SQL to query the data held within the database, and provides ACID (atomicity, consistency, isolation, durability) based transactions as a key feature and benefit over other alternatives for data storage.

Oracle constraints are defined as the rules to preserve the data integrity in the application. These rules are imposed on a column of a database table, so as to define the basic behavioral layer of a column of the table and check the sanctity of the data flowing into it.

The data which violates the rule, fails to pass the constraint layer and oracle raises a predefined exception. The integrity layer can be further expanded programmatically through triggers and validation subprograms as per the application requirements and standards.

Constraints establish an underlying business nature of data like its uniqueness, its references, NULL behavior or domain oriented limits. The key milestones achieved by the usage of constraints are:

• Validate NULL property of the data
• Validate uniqueness of the data
• Validate referential integrity of the data

CREATE TABLE NN_DEMO
(A NUMBER CONSTRAINT CONS_NN_DEMO_A NOT NULL);

CREATE TABLE NN_DEMO (A NUMBER NOT NULL);

CREATE TABLE NN_DEMO
(A NUMBER,
NAME VARCHAR2(100),
CONSTRAINT CONS_NN_DEMO_A NOT NULL(A))
/

CREATE TABLE UNIQUE_DEMO_COL 2 (ID NUMBER, NAME VARCHAR2(100) UNIQUE);

INSERT INTO UNIQUE_DEMO_COL VALUES(1,'Name 1');

INSERT INTO UNIQUE_DEMO_COL VALUES(2,'Name 1');

CREATE TABLE UNIQUE_DEMO (ID NUMBER, NAME VARCHAR2(100),
CONSTRAINT UN_UNIQUE_DEMO_ID UNIQUE(ID));

SELECT constraint_name, constraint_type, index_name from user_constraints
where table_name='UNIQUE_DEMO';

CREATE TABLE UNIQUE_DEMO 2 (ID NUMBER, NAME VARCHAR2(100));

CREATE UNIQUE INDEX IDX_UNIQUE_DEMO ON UNIQUE_DEMO(ID);

ALTER TABLE UNIQUE_DEMO ADD CONSTRAINT UN_UNIQUE_DEMO_ID UNIQUE(ID);

SELECT constraint_name, constraint_type, index_name from user_constraints
where table_name='UNIQUE_DEMO';

ALTER TABLE [TABLE NAME] ADD PRIMARY KEY [COLUMN NAME]

CREATE TABLE PK_DEMO_1 2 (ID NUMBER PRIMARY KEY, NAME VARCHAR2(100));

SELECT CONSTRAINT_NAME, INDEX_NAME, GENERATED
FROM USER_CONSTRAINTS
WHERE TABLE_NAME='PK_DEMO_1';

CREATE TABLE PK_DEMO_2 2 ( ID NUMBER, NAME VARCHAR2(100),
CONSTRAINT PK_ID PRIMARY KEY(ID));

SELECT CONSTRAINT_NAME, INDEX_NAME, GENERATED FROM USER_CONSTRAINTS WHERE TABLE_NAME='PK_DEMO_2';

CREATE TABLE PK_DEMO_3 (ID NUMBER, NAME VARCHAR2(100));

ALTER TABLE PK_DEMO_3 ADD PRIMARY KEY (ID); Table altered.

SELECT CONSTRAINT_NAME, INDEX_NAME, GENERATED FROM USER_CONSTRAINTS WHERE TABLE_NAME='PK_DEMO_3';

SELECT * FROM FK_PARENT;

CREATE TABLE FK_DEMO_1 (CID NUMBER REFERENCES FK_PARENT(PID));

CREATE TABLE FK_DEMO_2 (CID NUMBER REFERENCES FK_PARENT(PID));

SELECT TABLE_NAME, CONSTRAINT_NAME, R_CONSTRAINT_NAME, DELETE_RULE, GENERATED FROM USER_CONSTRAINTS WHERE TABLE_NAME IN ('FK_DEMO_1','FK_DEMO_2');

CREATE TABLE CK_DEMO_1 (ID NUMBER, NAME VARCHAR2(100), EMPLOYED VARCHAR2(1) CHECK (EMPLOYED IN ('Y','N')) );

SELECT constraint_name, search_condition, generated from user_constraints
where table_name='CK_DEMO_1';

INSERT INTO CK_DEMO_1 VALUES (1, 'JOHN','Y');

INSERT INTO CK_DEMO_1 VALUES 2 (2, 'KATE','A');

CREATE TABLE CK_DEMO_1 (ID NUMBER, NAME VARCHAR2(100), EMPLOYED VARCHAR2(1),
CONSTRAINT CK_EMPLOYED_YN CHECK (EMPLOYED IN ('Y','N')) );

CREATE OR REPLACE FUNCTION CHECK_RANGE RETURN NUMBER
IS
BEGIN
RETURN 100;
END;
CREATE TABLE CK_DEMO_FUN 2 (ID NUMBER,
NAME VARCHAR2(100), AGE NUMBER CHECK (AGE < CHECK_RANGE));
)

ALTER TABLE [TABLE NAME] DROP CONSTRAINT [CONSTRAINT NAME]

SELECT * FROM CK_DEMO_1;

ALTER TABLE CK_DEMO_1 DISABLE CONSTRAINT CK_EMPLOYED_YN;

INSERT INTO CK_DEMO_1 VALUES (3, NEL','A');

SELECT * FROM CK_DEMO_1;

ALTER TABLE CK_DEMO_1 ENABLE CONSTRAINT CK_EMPLOYED_YN;

DELETE FROM CK_DEMO_1 WHERE EMPLOYED='A';

ALTER TABLE CK_DEMO_1 ENABLE CONSTRAINT CK_EMPLOYED_YN; Table altered.

Data Pivoting, one of the ways to implement and achieve above purposes, can evolve multiple views with varying combinations of columns as rows and vice versa.
Oracle supports data pivoting through Pivot aggregate operators, which can be used in SQL statements. Oracle 11g introduced two new keywords PIVOT and UNPIVOT in support of this operation. While the PIVOT operation refers to the conversion of rows into columns, UNPIVOT implies the reverse operation.

Prior to the induction of the Pivot operator, such cross tabular reports used to get generated through workaround SQLs using self joins. While it achieved the purpose in small database, it proved to be nightmare in large enterprise data warehouse database systems. Performance used to be the most cursed area where high volume of data was multi folded on self joins.

PIVOT

Pivot operator transposes an aggregated row of a table into a column. The distinct row values become the columns in the output and aggregated column value places itself under the appropriate pivoted column. The syntax of Pivot operator is as below.

Syntax explanation

• [XML] – optional clause to convert the pivoted data into XML
• PIVOT_CLAUSE uses an aggregate function on one of the column of the table. This is the data which places itself against the pivoted column accordingly.
• PIVOT_FOR_CLAUSE and PIVOT_IN_CLAUSE specify a column and its distinct values which are to be pivoted. In a transposed report, the distinct values of the pivoted column appear as the header in the output. Both are mandatory clauses, so distinct values of the column must be in hand.

Examples and illustrations

A retail firm maintains the track of customer sales in three products (Product_A, Product_B, Product_C) for the months of January, February and March. The sales data is collected for three privileged customers C1, C2 and C3.

The relational table CUST_SALES stores the data for each customer against each product in each month. The table data is as below

Now, we shall pivot the table data to give a new analytic dimension. Refer the below cases.

Case 1: Customer sales in each month for each product

PRODUCT_ID column of the CUST_SALES table has been pivoted in the below query. Now observe the beauty and intelligence of Pivot operator; it retains the positions of remaining columns (i.e. CUSTOMER_ID and MONTH) and formats the sales data in accordance with the pivoted column. Also note that the PRODUCT_ID is no more a column but its distinct values i.e. Prod A, Prod B,

Prod C are transposed as the column header in the query output.

In the above query, note the aggregated function, FOR clause and IN clause of Pivot operator.

Now, check the Explain Plan of the pivot query.

The plan generated shows the pivot specific optimization of the SQL query in HASH GROUP BY function.

Case 2: Customer sales for each product in each month

Now, changing the angle of perception by replacing PRODUCT_ID with the MONTH at the header level. Distinct values of MONTH appear as column in the query output.

In the query, note that if the value(s) of the pivoted column had to have a customized title for better readability, the same can be specified using “AS” keyword. In the CUST_SALES table, abbreviated values of the MONTH column have been replaced with their complete names.

Similarly, if MONTH column has to be made as key analysis column, CUSTOMER can be raised to column header. Sales data would automatically find its place in the new matrix.

UNPIVOT

Unpivot operator functions just at the opposite principle of Pivot. Very rare occasions exist when an element is created along with its anti counterpart. Unpivot brings data in pivoted form back to the normal form. Its syntax and usage is same as that of Pivot.
Syntax

Here, UNPIVOT_CLAUSE is not an aggregated column, but an arbitrary column name, which appears in the query to accommodate the values of unpivoted columns.
UNPIVOT_FOR_CLAUSE is also an arbitrary column name to hold the unpivoted columns values.
UNPIVOT_IN_CLAUSE defines the distinct values of the columns to be unpivoted.

Illustration

CUST_SALES_MONTH is the table which holds the data in binary format, to denote whether a product has been consumed by a customer in a specific month or not. It looks more like a spreadsheet.

Now, Unpivot operator can be used here to break the CUST_SALES_MONTH table into rows to show only CUSTOMER_ID, PRODUCT_ID, MONTH and its corresponding sales. Check the query below:

Now observe the output.

For each customer and product, the „month‟ column is repetitive to list the corresponding „month_count‟ value. The UNPIVOT_FOR_CLAUSE and UNPIVOT_IN_CLAUSE are responsible to have columns of the table listed as value under MONTH column.

The UNPIVOT_CLAUSE (here, MONTH_COUNT) specifies fetches the corresponding value of the unpivoted column and places at correct position alongside its customer_id, product_id and month. This demonstrates the power intelligence of UNPIVOT operator.

The explain plan for the above query shows the UNPIVOT operation for the conversion of column headers as row values.

Applications of Pivoting

We have already seen the benefits of Pivot operator. On need basis, data can be pivoted in the required format. Still, from developers perspective, I would mention an application derived from the previous ones.

Conversion of columns to rows and vice versa.

For example, you have a test data of known values, which is required in rows. One way is to combine all the separate SELECT statements using UNION operator as below:

Unpivot operator eases this overhead in efficient and simple way. Check the query below.

Conclusion

Pivot and Unpivot have made an impactful entry into the SQL language. They have set aside the cumbersome work around solutions and efficiently transpose the data of a relational table.

A cursor is a pointer, which points towards a pre allocated memory location in the SGA. For transparent understanding, it is a handle or gateway adopted by Oracle to execute a SQL query. The memory location to which it points is known as Context area. Oracle associates every SELECT statement with a cursor to hold the query information in this context area.

Cursor follows a defined execution cycle to execute the SQL statement associated with it. The article describes the Oracle cursors and their usage.

There are two types of cursors: Implicit cursors and explicit cursors.

Implicit Cursors

Oracle server processes every SQL statement in a PL/SQL block as an implicit cursor. All the DML statements (INSERT, UPDATE or DELETE) and SELECT query with INTO or BULK COLLECT clauses are candidates for implicit cursors.

Whenever a SQL statement is executed, Oracle automatically allocates a memory area (known as context area) in Oracle database PGA i.e. Process Global Area. This allocated memory space is the query work area which holds the query related information.

For implicit cursor, the complete execution cycle is internally handled and maintained by the oracle server. For developers, implicit cursor appears to be an abstract concept. Only thing which is physically available and visible to them is the cursor status flags and information. Cursor attributes reveal the cursor related information and status. Following are the cursor attributes available

• SQL%ROWCOUNT – Number of rows returned/changed in the last executed query. Applicable for SELECT as well as DML statement
• SQL%ISOPEN – Boolean TRUE if the cursor is still open, else FALSE. For implicit cursor it is FALSE only
• SQL%FOUND – Boolean TRUE, if the cursor fetch points to a record, else FALSE
• SQL%NOTFOUND – Inverse of SQL%FOUND. The flag is set as FALSE when the cursor pointer does not point to a record in the result set.

These attributes are set at the different stages of execution cycle and retained in the context area.

Example Code [1]: The PL/SQL block below shows an implicit cursor created by SELECT statement.

Above example code contains a SELECT query in the executable section of the anonymous PL/SQL block. It executes successfully because the query returns scalar output. Having being the query returning multiple rowed result set, it would end up raising an exception and hence, abnormal termination.

The above coding practice carries its own pros and cons. If the SELECT query is expected and framed to written a single row, SELECT with INTO clause is performance efficient.

But, implicit cursor runs serious threat to the application, when it returns zero or multiple rows. Zero rows returning implicit cursor raises NO_DATA_FOUND exception, while multiple rows one raises TOO_MANY_ROWS exception. Check the exception situations in the below screen dumps.

Explicit cursors are best suited in situations where number of records in the result set is not known. It not only avoids the exception threat but also well indents the coding standards.

Single and Multiple row Implicit cursors

Oracle 11g identifies a different categorization basis of implicit cursors. Implicit cursors, based on number of rows affected by the cursors, can be categorized as single row implicit cursors and multiple row implicit cursors. All SELECT statements and DML statements which affect single row, processed within PL/SQL block are classified as Single row implicit cursors. All DML statements and cursor FOR loops, which affect multiple rows fall under the category of multiple row implicit cursors.

Example Code [2]: The PL/SQL block below contains single SELECT statement which selects salary of a single employee. Since, it returns a single row output, it demonstrates the construction of single row implicit cursor.

Example Code [3]: In the PL/SQL block below, UPDATE statement recalculates the salary of all employees in the company. As the DML statement affects multiple rows, it demonstrates a multiple row implicit cursor.

Explicit Cursor

These cursors are explicitly declared in the DECLARE section of the block. They possess a specific name and a static SELECT statement attached to them. Explicit cursors are manually executed by the developers and follow complete execution cycle.

Explicit cursor information is also captured in cursor attributes, which are set during the cursor processing and reveal essential information about the cursors. These attributes, as listed below, are same as that in implicit cursors but specific to the cursors.

• CURSOR%ROWCOUNT
• CURSOR%ISOPEN
• CURSOR%FOUND
• CURSOR%NOTFOUND

Cursor Execution Cycle

The key steps in the cursor execution cycle are OPEN, FETCH and CLOSE. But it would be worth expanding the complete execution cycle for better understanding about the processing of a cursor. A cursor execution cycle refers to the stages which a cursor follows to process and execute the query. The phases of cursor execution are listed below.

I shall explain the activity carried out by the server in the key phases.

OPEN stage

• PGA memory allocation for cursor processing
• Parsing of SELECT statement
• Variable binding
• SELECT Query execution
• Move the record pointer to the first record

FETCH stage

The record, to which the record pointer points, is pulled from the result set. The record pointer moves only in the forward direction. The FETCH phase lives until the last record is reached.

CLOSE stage

After the last record of the result set is reached, cursor is closed, and allocated memory is flushed off and released back to SGA. Even if an open cursor is not closed, oracle automatically closes it after the execution of its parent block.

Setting of cursor attributes during cursor execution cycle

The cursor attributes, listed above, are set at different stages of this cycle. The table below captures the stage wise value of the status flags.

Syntax and illustration

Cursor definition
CURSOR [CURSOR NAME] IS
[SELECT QUERY]

Opening a Cursor
OPEN [CURSOR NAME]

Fetching records from the cursor
FETCH [CURSOR NAME] INTO [LIST OF VARIABLES]

Closing a cursor
CLOSE [CURSOR NAME]

Example Code [4] – The PL/SQL block below declares a cursor, which select employee name, job id and salary for the employees with employee id 100. Note the opening, fetching and closing of the cursor. Here cursor returns a single record.

Example Code [5]: When cursor result set contains multiple records, it has to be iterated to fetch each of them. The PL/SQL code below declares a cursor which selects employee details from department 10. A normal loop is used to iterate the result set and display the results.

Cursor FOR loops

Explicit cursor processing can also be done using cursor FOR Loops. Cursor FOR loops improvise upon the performance and code interactivity by their implicit actions. Implicitly, they create variables, which can be accessed through cursor index. Even, cursor execution steps are implicitly carried out by them.

Example Code [6]: The above example code [5] can be rewritten using cursor FOR loop as below.

Employee JOHN with Job function of MGR draws 2300 per month
Employee KATE with Job function of TECH draws 5500 per month
PL/SQL procedure successfully completed.

Dynamic Cursor FOR Loops

Cursor FOR loops, as illustrated above, can be extended to include subqueries as dynamic cursors. This implies that the cursors would not be declared in the DECLARE section, but would be implicitly created when a subquery is attached to the FOR loop. I shall rewrite the cursor in Example Code [5] for loop as below.

Example Code [7]

Parameterized Cursors

Hard coding of values in the application programming has never been the persistent mode of programming. If you analyze the cursors used in the above example codes for demonstration purpose,
each one of them contains hardcoded value. Parameterized cursors provide cut to the problem by enabling programmer to pass parameter to the cursors. This reduces code redundancy, enhances code reusability and visibility in the program. The same cursor can be reopened for a different value and hence, different result set.

Example Code [8]: The cursor used in example code [5] can be redefined by introducing a
parameter.

Illustrations

Using FOR UPDATE clause in cursor

In a multiple user application environment, application must be robust enough to overcome the locking scenarios. In Oracle, FOR UPDATE OF clause is used to lock a set of rows in a session. This concept can be used in explicit cursors also to impose exclusive row level lock on all the rows contained by the cursor query result set. These rows will remain locked until the session issues ROLLBACK or COMMIT.

FOR UPDATE OF allows a programmer to specify the column names which are more intend to change in other sessions. Nevertheless, the rows would be locked to protest updates against all the columns, but still OF list provides flexibility to make note of ‘update prone’ columns.

Oracle provides WHERE CURRENT OF clause to update or delete the rows which are locked by the FOR UPDATE OF cursor in the session. The clause identifies the row to be updated and thus, prevents coding for row identification from the cursor result set.

Example Code [9]: The PL/SQL block below updates the salary of all employees working in department 30.

Exceptions with cursors

INVALID_CURSOR and CURSOR_ALREADY_OPEN are the two exceptions which are raised, when oracle optimizer encounters aberrant cursor.

The exception INVALID_CURSOR is raised when programmer attempts to operate a non allowed operation on the cursor. If the operation points to a cursor which does not exist, or which does not points to any SQL context area, the INVALID exception is raised.

Example Code [10a]: Demonstrating INVALID_CURSOR exception

Example Code [10b]: Demonstration of CURSOR_ALREADY_OPEN exception

Conclusion

I have made a sincere effort to familiarize you all with the world of cursors, which would be justified with the interest of readers and visitors. The codes and explanations are based on self hands on and observations.

Triggers are automatically invoked at a defined event and timing without any explicit calls. The logic embedded within the trigger and invocation must be well directed and synchronized to maintain database purity.

Oracle 11g made remarkable enhancements in Database Triggers. These enhancements and additions have transformed triggers into a logical, stable, and comprehensive database platform. In the past versions, developers used to face issues under certain conditions as listed below.

• Multiple triggers for single timing
• Mutating table confrontation
• Control the trigger execution by enabling and disabling it

Introduction of compound triggers which triggers different logic at different timings, guaranteed execution sequence of triggers and enable/disable functionalities make the PL/SQL a more efficient language and require less coding.

The article projects the transformations undergone by database triggers in 11g release of Oracle.

Trigger Enhancements

Setting the Trigger order

Earlier, if a DML event demands multiple triggering actions without altering the existing code, developers used to create multiple triggers for same timing and event. For example, a table EMPLOYEE can have two AFTER UPDATE OF EMPLOYEE FOR EACH ROW triggers.

Such activity was possible since Oracle 8i, but usually the trigger timing determines the order of its execution but the aforesaid baffling situation gives the complete privilege to the database server to determine the execution order of the triggers i.e. random execution. It remained a ‘crossed fingers’ situation for the developers to predict the execution order. Unsorted execution of DML triggers can produce unexpected results where setting or initializations of parameters are involved.

Now, oracle has released the flexibility to set the sequence of execution of triggers for the same triggering event and timing. Two new keywords FOLLOWS and PRECEDES have been introduced to force the triggers to follow set execution order.

Example Syntax [1]

Example Code [1]: Demonstrate the use of FOLLOWS keyword

Now, the triggers would be executed in the set order. This ensures the logical and sorted execution of modular logic in the application.

DISABLED Triggers

Prior to Oracle 11g, by default all triggers used to get created in ENABLED state. In real time production systems, this behavior had rooted out reluctant and unavoidable issues. Suppose the database support team applies a production patch, which contains a new trigger script. Upon execution, the trigger script raises error due to some missing reference. If somehow the trigger could have been only created with compilation errors, but not on live association with the event [table], the error could be resolved out.

Oracle 11g resolves such scenarios by allowing a trigger to be created in DISABLED state. Note that state is not at all new for triggers. Earlier too, a trigger can be disabled using ALTER TRIGGER command. Oracle 11g has widened this feature by taking it at creation level. A disabled trigger can be enabled at any point of time in the program.

Example Code [2]: Demonstration of DISABLED trigger

DML triggers are now faster

DML Triggers in Oracle 11g are comparatively faster than their counterparts in earlier versions. The performance can be clearly measured by running a trigger separately in 10g and 11g and recording their execution time. I have executed a trigger T_CHECK_ORDER in Oracle 10g and 11g separately. Their execution time upon operation is recorded as 153

Figuire shows the reduction in execution time of the DML triggers in Oracle 11g.

New Language Features

 Compound Triggers

Compound triggers are another new tool in the kit to support reduced coding and interactivity. It combines all four triggering events into a single piece of code. Besides the coding efficiency, it tackles some bigger issues in the picture.

• Mutating table (ORA-04091) scenarios
• Suppose an EACH ROW triggers do some transaction in some other table using new values.

 Imagine the situation when dealing with millions of data and double transaction for each row through trigger action would cause huge losses to performance.

Earlier, workaround solutions do existed for the above problems, but with loads of complex coding using collections and multiple triggers. It used to become nightmare for developers to simulate and test such scenarios.

Compound triggers readily deal with all above scenarios in an efficient and interactive manner. The new trigger feature not only boosts up the performance during bulk operations, but also holds the state of its variables and member constructs till the execution of the statement. They are reset only at the beginning of new statement. Note that compound trigger is an optional feature. Separate DML triggers for different timing can still be created in earlier fashion.

On the lower side, compound triggers are only available for DML triggers. DDL and system level triggers still follow the old convention. In addition, condition based and autonomous compound triggers are not supported. An important point to mention here is the exception handling. It has to be handled explicitly in all the timing blocks, and not in the trigger body.

Syntax

The compound trigger syntax contains the man body and four blocks representing four timings associated with DML events. Note the COMPOUND TRIGGER keyword to differentiate with the other database triggers.

 Usage guidelines

1. Each timing handler block must appear only once in the compound trigger body
2.  All timing handler blocks are optional
3. Compound Trigger metadata can be captured in USER_TRIGGERS view. The new columns added are as below:

A new trigger type ‘COMPOUND’ would be updated for compound triggers. Based on availability of the timing block in the trigger body,

Illustrations of Compound Triggers

 Compound trigger as performance savior

I shall site a scenario where concurrent loading into a table is achieved through Compound trigger. Bulk loading uses an associative array to hold the data to be loaded. The loading is done after the statement execution completes. Refer the trigger code below

Example Code [3]: Compound trigger to implement bulk loading

–Inserting test data into ORDERS table

To be noticed, the simultaneous insertion process has been carried out in bulk. This pulls up the performance to a major extent. If the same insert operation have had used conventional row level trigger, it would have shrunk the performance by 1000 insert statements.

Resolving Table mutation scenarios

Mutating table scenarios have been hovering over the multi-user based applications for a long time. Several times, tedious workaround solutions and unreliability has forces the architects to modify the design, so as to avoid table mutation during parallel real time processing. Compound triggers in Oracle 11g provide concrete logic base to deal with such scenarios. The trigger example below shows how they handle and achieve such events.

Before moving to the solution, first I will simulate the table mutation scenario.

The row level trigger TRG_INS_ORDERS on ORDERS table will display the updated item code.

The table remains in the floating state, when the trigger TRG_INS_ORDERS tries to select and display the changed value. Such situations are well handled using compound triggers. Check the example below.

First release of Oracle 11g facilitated the developers with multiple enhancements and language features. The introduction of advanced core database concepts and language features has taken Oracle from instrumental to advisory level. With the market stake of more than 90% in database industry, Oracle provides a reliable, flexible and scalable database solution.

The article lists down the major SQL language additions and enhancements, which were inducted during 11g release. I hope my efforts would be justified with the note of thanks.

New Additions

I shall project some of the key additions in SQL side. The selection of these features out of many is based upon their relevance and level of criticality in a real time application environment.

Read only tables

Oracle 11g database categorizes tables based on their transactional behavior; they can be READ ONLY or READ WRITE. A READ ONLY table remains passive against all DML operations, selective DDL operations, and flashback activities. The permissible actions on a READ ONLY table includes selection, indexing, enforce constraints, rename, and dropping.

With the addition of this category, Oracle added another obvious category as READ WRITE. A table, which is open for all transactional activities, falls under this category. The category can be toggled over at any point of time in the session using ALTER TABLE command.

A table would be created in conventional manner but it can be altered to READ ONLY mode.

Example Syntax [1]

Example Code [1]

The below ALTER TABLE statement switches back the table mode to READ WRITE.

The behavior of READ ONLY table is illustrated in the below screen shot.

READ ONLY tables are extremely useful in tightening the security at user level. Earlier, the same objective was achieved by a statement level DML trigger or a check constraint in ‘disable validate’ state. But READ ONLY table provides a simple and reliable technique to impose DML restriction on a table.

SQL Result Cache

Result caching is one of the most eye catching features in Oracle 11g. It has been introduced in both SQL and PL/SQL. In PL/SQL, it is practiced in stored functions. In SQL, a query result can be cached in the session server cache using a new optimizer hint RESULT_CACHE. Upon subsequent executions of the same query with same set of parameters, the result would be fetched directly from the cache and not by re-executing the query. Server Result Cache is the new component of SGA, whose sizing can be done based on MEMORY_TARGET (0.25%), SGA_TARGET (0.5%), or SHARED_POOL_SIZE (1%).

Four new initialization parameters are required to be set to enable result cache feature on the server side. The parameters are depicted in the below diagram.

Taking above parameters into consideration, we shall run a SQL query with RESULT_CACHE hint and generate the explain plan.

Example Code [2]

The explain plan shows the RESULT CACHE operation with the CACHE ID ‘6pvpvvjg0kkcr67422t1kfyrgs6’. This cache id is a unique id to identify the cached result of the query. It can be queried in V$RESULT_CACHE_OBJECTS to check the status and the SELECT statement associated with it.

Virtual columns

In the earlier versions of Oracle, virtual columns used to exist but they were internally created and maintained by Oracle. The collection columns were categorized by Oracle server as Virtual Columns because of their data storage logic.

With 11g release, Oracle allows user to explicitly create virtual columns in a table. These virtual columns are associated with an expression, which always generate the value for the virtual column. The expression must be build using the non virtual columns of the same table or a stored function of deterministic type.

Example Syntax [2]

In the above syntax, the keyword GENERATED ALWAYS and VIRTUAL are optional, while AS is the mandatory one. The optional keywords improve the virtual column definition readability.

Note that the data type of the virtual column is also optional. If it is not explicitly specified, it attains the return data type of the expression.

Example Code [3]

The virtual property of a column can be queried in VIRTUAL_COLUMN of USER_TAB_COLS table. During insertion also, the non virtual columns must be explicitly specified. Since virtual column value is generated during runtime, it has to be excluded during insertion; else it raises ORA-54013 exception which reads as ‘ORA-54013: INSERT operation disallowed on virtual columns’.

Update operations are not allowed on the virtual columns. Any attempt to do so would raise exception ORA-54017 which reads as ORA-54017: UPDATE operation disallowed on virtual columns’.

Creation of virtual columns using Deterministic functions

If the virtual column expression has to contain a user defined function, it must be of DETERMINISTIC type. For other functions, oracle raises ORA-30553 exception which says ORA-30553: The function is not deterministic.

Introduction: The EXISTS operator

EXISTS is a Comparison operator, which is used to check and match records between two queries on correlation basis and returns a BOOLEAN output (TRUE or FALSE). The two queries are designated as the Outer or Parent query and the Sub query.

Note: NOT EXISTS is the negation format of EXISTS.

Example Syntax [1]

Legends: Parent Query in RED, Subquery in GREEN.

Illustration: Consider a scenario where only those employees have to be listed who enjoy the membership of Company Club. Employee and Company Club are two separate entities and are connected through an attribute ‘Employee Id’. The above scenario can be read as the ‘Employees who exist in Company Club’. Practically, it can be done in multiple ways with varying performance stats and scope of extension. The Oracle EXISTS operator can suitably fit into such scenarios which require the check for existence of a parent query record in a subquery.

Example Code [1] achieves it with the use of EXISTS operator.

Example Code [1]

Examples

Example Code [2]: SELECT using EXISTS

Scenario: Display the employee details who are working in New York area.

Example Code [3]: UPDATE using EXISTS

Scenario: Update the commission of black listed employees to zero.

Example Code [4]: DELETE using EXISTS

Scenario: Delete the employee details from EMP_ARCHIVE table whose age has crossed 60.

Example Code [5]: INSERT using EXISTS

Scenario: Add employee details to EMP_ARCHIVE table who are working in New York area.

Performance guidelines with EXISTS operator

Amazingly, even operator use in SQL statement makes difference in performance of the query. [NOT] EXISTS operator gives best performance when the subquery i.e. driven query contains huge volume of data. The reason is that it follows the principle of ‘At least found’ in queries. It is set to TRUE, if at least one record is found in the subquery correlating with the main driving query, and stops further scanning of the table. Unlike other comparison operators like [NOT] IN, LIKE and others, which returns data for comparison, [NOT] EXISTS return BOOLEAN output.

Illustration: We have ORDERS and PREV_ANN_ORDERS table, which contains current month orders and cumulative previous years’ orders respectively. PREV_ANN_ORDERS contains millions of sales records. We shall try to query the ORDERS which are not yet moved to previous years’ sales data.

Refer to the Example Code [6a] and [6b]

Example Code [6a]

Execution Plan
———————————————————-

If the same query would have used NOT IN operator to achieve the same result, Explain Plan would
reflect the bite in performance as shown in Example Code [6b].

Example Code [6b]

Execution Plan
———————————————————-

Explanation: The EXPLAIN PLAN in Example Code [6a] and [6b] shows quite big difference in ‘Cost’ and ‘Bytes’. The query in Example Code [6a] uses [NOT] EXISTS operator consumes less cost (in step 0) and is relatively faster than the query in Example Code [6b]. In addition, note the difference in the ‘bytes’ returned in step 4 of the Execution Plans. Since EXISTS returns Boolean value, it shows 8 bytes in

Explain Plan [6a], while the IN query returns 893648 bytes of data in Explain Plan [6b].

A Comparative Study: IN versus EXISTS

Oracle IN operator and EXISTS operator work for the same purpose i.e. they both check for record correlation between the main query and the sub query. Often, database professionals get interested in debating over the performance of two operators in various scenarios. In this section, we shall compare the working of IN and EXISTS operator.

Before coming on comparative note, we shall have quick walkthrough on IN operator. IN operator can be used in SQL queries in two ways. Firstly, as an INLIST operator, this provides list of fixed values for comparison. Secondly, as a subquery comparator, this uses a subquery to check for record correlation.

Now, we shall execute a simple SQL query in Oracle 9i version and check the difference in their Execution Plans. The query in Example Code [7] and [8] displays the Employee details who are Active member of Company Club.

Example Code [7]

Fig 1: Explain plan for Example Code [7]

Example Code [8]

Fig 2: Explain plan for Example Code [8]

Note the difference between the Explain Plans in Fig (1) and (2) in ‘Consistent gets’ head. Prior to the introduction of CBO (Cost Based Optimizer), Oracle server which used Rule Based Optimizer, used to identify considerable difference between IN and EXISTS operator.

Usually it is worth mentioning as thumb rule that when subquery does the major filtering, IN is more efficient. In other cases, when outer query does the major filtering, EXISTS enhances the query performance.

With the introduction of CBO, the difference has been significantly reduced. The performance orientation with IN operator has been strengthened to match up with EXISTS operator. In major cases, EXISTS and IN show the same TKPROF and EXPLAIN PLAN results. The SQL queries, which use table of huge data volume, are the only candidate to mark the difference between the two.

Now, we shall execute the above queries in Oracle 11g R2 and observe the difference.

Example Code [9]

Fig 3: Explain plan for Example Code [9]

Example Code [10]

Fig 4: Explain plan for Example Code [10]

Explain Plan for the two queries shows no difference at all.

Above analysis puts forth the point that optimizer is decisive over the performance in the SQL statements which use IN or EXISTS operator.

Introduction

Oracle introduced Sequences in its sixth release (Oracle 6) to serve the purpose of auto generation of continuous numbers in database.

It properly fits into the situations where an entity has to be uniquely identified with a numeric id. For instance, a real time billing process must recognize a unique Bill Id.

Here, manual assignment of Bill Numbers might end up in deadlock and confusion by carrying high risk of id duplication and replication. Oracle Sequences efficiently resolves these situations by generating non recurring numbers in defined order and limit.

Note that it can generate only numeric values. Applications using alphanumeric ids have to embed their own business logic to generate the same.

Auto generation process: Flashback

We shall take a small tour of how the things worked out before Oracle introduced Sequences.

For generating record numbers,

Example Code [1]:

INSERT INTO ORDERS (ID, ORDER_CODE, ORDER_DATE, ORDER_QTY)
VALUES ((SELECT MAX (ID) + 1 FROM ORDERS), ‘DBA’, SYSDATE, 10);

Above INSERT statement shows the generation of ID column values in the ORDERS table. It first selects the maximum ID in ORDERS table and adds 1 to it to generate ID value for the current record.

It is not commendable method where multiple ongoing transactions are involved. This method carries high risk of locking in simultaneous sessions and gap in ID values. IDs for uncommitted transactions would be skipped as unconsidered for henceforth records, thus leading to duplication of ID values.

The Oracle Sequence: Creation and Usage of Object

A sequence can be created following the below Example Syntax [1].

Example Syntax [1]

As a pre-requisite, a user must possess CREATE SEQUENCE system privilege to create a sequence. If user is required to create sequence for another user, he must have CREATE ANY SEQUENCE system privilege. These privileges must be granted from the DBA to the user.

Note that unlike other database object definitions, no REPLACE option available for a sequence.

I shall explain the clauses used in the syntax as below.

• [SEQUENCE NAME] – The Name of the sequence. It shares its namespace with Tables, normal and materialized views, synonyms, procedures, functions, packages, and object types. None of the mentioned objects can carry the same name.
• [START WITH n] – This clause specifies the starting point of the sequence. This clause can be used as the minimum value of the sequence. But interestingly, it can also specify a point of start between minimum and maximum value of the sequence. It can contain any value within the limit of 1.0000E+27.
• [INCREMENT BY n] – This clause specifies the incremental difference between the two numbers. It can be any definite value except zero. By default, Oracle server treats its value as 1. It can contain any value within the limit of 1.0000E+28.
• [MAXVALUE n] – This clause specifies the maximum value attainable by the sequence. It must be greater than MINVALUE and START WITH values.
• [NOMAXVALUE] – This clause is the default specification for Maximum value of the sequence. If the clause is specified, the maximum value of a sequence is 1.0000E+28.
• [MINVALUE n] – The clause specifies the minimum value of a sequence. It cannot exceed the START WITH value and MAXVALUE.
• [NOMINVALUE] – This clause is the default specification of Minimum value of the sequence.
• [CYCLE | NOCYCLE] – This clause adds cyclic behavior to a sequence. The sequence recycles the values once the MAXVALUE is reached. It is least relevant if sequence is used as Primary key generator. NOCYCLE is the default behavior.

Note: For a cyclic sequence, the sequence must be capable to generate more values than the cache count specified.

Example Code [2]

ERROR at line 1: ORA-04013: number to CACHE must be less than one cycle.

In addition, CYCLE avoids run out conditions in sequences by providing roll over support.

[CACHE n| NOCACHE] – This clause directs Oracle server to cache ‘n’ values of a sequence. Its value is 20 by default. NOCACHE is the default behavior of the sequence.

[{ORDER n | NOORDER}] – This clause ensures that sequence values are generated in order. Generally, it is least usable clause in sequence definition but they are helpful in applications which use sequence as timestamp value. All sessions using same sequence share the same cache to fetch the values. NOORDER is the default behavior of the sequence.

All the clauses specified above are optional clauses.

Examples and illustrations

Example Code [3]: Creation of a sequence SEQ_TST. Note that it is the simplest workable non-cyclic sequence whose start value is 1 and moves forward with the increment of 1.

Sequence created.

Example Code [4]: The sequence below shows that a sequence can maximum generate values up to 1.0000E+28. Further generation of numbers from the sequence leads to Run Out condition. Note that the sequence is created with NOCYCLE option.

Sequence created.

*

ERROR at line 1:

ORA-08004: sequence STT.NEXTVAL exceeds MAXVALUE and cannot be instantiated

Applications of Sequences

Auto generation of numbers is the primary objective of a Sequence. It meets the below goals in an application.

Note that if a row is inserted into a table using the sequence generator and the transaction is rolled back, the sequence number would be lost and cannot be retrieved back. This is known as sequence gapping.

Referencing Sequence in PL/SQL

In Oracle PL/SQL, NEXTVAL and CURRVAL are the two pseudo columns in Oracle which are used to access the sequence values. NEXTVAL generates the new value of the sequence while CURRVAL displays the current value of the sequence.

Example Syntax [2]:

Note that each call to NEXTVAL generates a new value of the sequence while CURRVAL can be called multiple numbers of times as it returns the current value of the sequence without modifying the sequence structure.

In SQL *Plus, they can be selected using SELECT statement to get the inline or current value of the sequence. In PL/SQL block, Oracle 11g made considerable modifications in accessing a sequence.

Sequence Enhancements in Oracle 11g

Prior to 11g release, a sequence value must be fetched through a SELECT statement in a memory variable as shown in Example code [5]

Example Code [5]

Oracle 11g allows using NETXVAL and CURRVAL as PL/SQL construct. Refer the example code [6] as below

Example Code [6]

Sequence Usage Notes

 In a database session, CURRVAL function cannot be the operated before NEXTVAL as first operation on the sequence. This implies that first operation on a sequence in a session must be NEXTVAL. CURRVAL returns the last cached (generated) value of the sequence by the current session. Once, NEXTVAL fetches the sequence value in a session, CURRVAL is ready for use. Refer the Example Code [7] to illustrate above point.

Example Code [7]

Sequence created.

*ORA-08002: sequence sq_customers.CURRVAL is not yet defined in this session

A Sequence can be referenced in INSERT and UPDATE statements using CURRVAL and NEXTVAL pseudo columns. Refer the Example Code [8].

Example Code [8]

1 row inserted.

10 rows updated.

 NEXTVAL generates a new number from the sequence only once for the current row. For multiple subsequent references of the NEXTVAL operation on the same sequence in the same record, it returns same number. Refer the Example Code [9] below.

Example Code [9]

A1 A2 A3 A4
———- ———- ———- ———-
101 101 101 101

 A Sequence cannot be used in Static statement queries. Static queries include subqueries, view definitions, SELECT statements with DISTINCT, GROUP BY or ORDER BY clause, and queries using SET operators. Additionally, it can also be not used in WHERE clause, CHECK constraints, and DEFAULT value specifications.

Example Code [10]

Modifying the Sequence behavior

Except the START WITH value, all the clause specifications in a sequence definition are subject to change at any moment. A user can ALTER the sequence definition only if he owns the sequence or enjoys ALTER ANY SEQUENCE system privilege. The Example Syntax [3] shows the modifiable clauses of a sequence in ALTER.

Example Syntax [3]

Example Code [11]

A sequence SEQ_TST is created with default Minimum and Maximum value. A user can alter the sequence to modify the minimum and maximum value for the sequence.

SQL> SELECT MIN_VALUE, MAX_VALUE, LAST_NUMBER FROM USER_SEQUENCES WHERE SEQUENCE_NAME = ‘SEQ_TST’;

MIN_VALUE MAX_VALUE LAST_NUMBER
———- ———- ———–
1 1.0000E+28 1

Sequence altered.

MIN_VALUE MAX_VALUE LAST_NUMBER
———- ———- ———–
1 10 1

Dropping the sequence

A sequence can be dropped from the database using DROP command. DROP is a DDL command which is used to remove database objects from the schema.

Example Syntax [4]

A user dropping a sequence in his schema required DROP SEQUENCE system privilege. To drop a sequence owned by another user, a user must possess DROP ANY SEQUENCE system privilege.

Sequence Cache

To achieve better performance in database applications, sequence values can be cached in SGA for faster generation and retrieval of numbers. By default, Oracle server caches 20 values of an Oracle sequence. CACHE option in a sequence definition enables caching of specified number (n) of sequence values.

The ALTER command in Example Code [11] increases the cache size of the sequence to 100. Oracle server allocates 100 sequence values in cache. Once the cache flushes out all the values, it is repopulated with new set of 100 sequence numbers.

Example Code [12]

Sequence Metadata

Oracle server maintains sequence metadata in [ALL | USER] _SEQUENCES data dictionary views. While USER_SEQUENCES stores the metadata only for the sequences, which can be accessed by the specific user, ALL_SEQUENCES maintains the data about all the sequences accessed by the user.

Introduction

Oracle 11g Release 2 is the latest release of Oracle in 11g series. Unlike the last release 10g which was more stable and bug free version of 9i, 11g was focused on fresh features, coding enhancements and advanced performance features. Understanding these features is equally important for Oracle professionals for below reasons:

1. Analyze the impact of new features in current database installations
2. Formulate and implement new coding enhancements to replace workaround solutionsEnhance efficiency of database systems in terms of performance, security, and data storage and estimate future management strategies
3. Enhance efficiency of database systems in terms of performance, security, and data storage and estimate future management strategies

Oracle 11g: A tour

To the surprise of Database professionals, Oracle 11g no longer keeps PL/SQL as a pure procedural language. Now PL/SQL is efficient to implement Object Oriented Concepts, thus making it comparable to other programming languages like C++ and JAVA. Similarly, it appears amazing to discover the change in code compilation technique from Interpreted to Native.

Other notable changes is the deprecation of SQL Plus, numerous Enterprise Manager enhancements, code performance enhancements, and adherence to the latest coding standards which make Oracle 11g a uniquely Developer friendly product.

Oracle 11g introduced new features and enhancements in below areas:

• Performance Improvements
• Enhancements to improvise the usability and compatibility of PL/SQL as a language
• Include earlier workaround implementations as language features

I shall make a fair effort to describe some of these features which are necessary from a Developer’s perception and are relatively, important part of applications.

Introductory Enhancements

Deprecation of SQL Plus – Oracle has deprecated the use of SQL Plus (isqlplus and sqlplusw) since Oracle 11g. Besides SQL *Plus, Oracle Workflow, Oracle Enterprise Manager JAVA console, and Oracle Data Mining Scoring Engine are also part of deprecated components from Oracle 11g. Nevertheless, Oracle 11g supports SQL plus through command line and recommends the use of SQL Developer.

Compiler enhancements (Real Native Compilation) – Oracle 11g PL/SQL compiler is no more dependent on third part C compiler but it can use PL/SQL source code to directly generate the native code. This improves compilation time and results in faster execution. The newly added

PLSQL_CODE_TYPE parameter must be set for native compilation. It can be set as INTERPRETED or COMPILER system or object level. Refer the Example code (1) to switch to NATIVE compiler.

An object can natively compiled using ALTER command at object level. Refer Example code (2).

In terms of performance, it is twice as fast as C native compiler.

Case sensitive Passwords – Passwords are made case sensitive with Oracle 11g. They introduced two additional parameters SEC_CASE_SENSITIVE_LOGON, SEC_MAX_FAILED_LOGIN_ATTEMPTS to strengthen the database password security.

Fresh Additional Features

Read Only Tables – In Oracle 11g, a table can be set READ ONLY mode to restrict write operations on the table. A table can be altered to toggle over READ ONLY and READ WRITE modes. Refer Example code (3) and (4).

Example code: (3)

Example code: (4)

Invisible Indexes – Oracle 11g provides flexibility in query performance testing by introducing Invisible Indexes. An Invisible Index can be created to check its effect on the query performance. It can be converted to VISIBLE mode for auto consideration by the optimizer, if it makes major performance impact. An initialization parameter OPTIMIZER_USE_INVISIBLE_INDEXES must be set to TRUE in the session to direct optimizer to use an Invisible Index. Alternatively, using INDEX hint, it can be enforced in the execution plan and query performance can be tested. Example code (5)creates an Invisible Index and SQL query in Example code (6) uses it through a hint to fetch the data.

Example code: (5)

Example code: (6)

If the index usage makes considerable impact on the query performance, the invisible index can be altered to VISIBLE mode. Refer Example code (7).

Example code: (7)

A VISIBLE index can be switched back to INVISIBLE mode using the ALTER statement as shown in Example code (8)

Example code: (8)

Virtual Columns – Oracle 11g allows a user to create virtual columns in a table whose values are derived automatically from other actual columns of the same table. They show same behavior as other columns in the table in terms of indexing and statistics. Currently, Oracle does not support LOB and RAW values in virtual columns.

Example Syntax: (1)

Here, GENERATED ALWAYS and VIRTUAL are optional keywords, but included for more clarity.

A table ORDERS is created with ORDER_VAL_ANN as virtual column, whose value is derived from ORDER_VAL column of the ORDERS table. Refer Example code (9).

Example code: (9)

Result Cache in SQL and PL/SQL – Oracle 11g has introduced a new SGA component (Shared Pool) as Result Cache to retain SQL and PL/SQL results for same set of inputs.

For subsequent executions of the same function, Oracle server directly fetches the result set contained in Result Cache rather than undergoing complete execution process. Logically caching of frequent queries and their result set saves execution time and results in better performance.

Note that it gets invalidated if function definition, or any dependent object undergoes a change.

Fig (1): Graphical comparison of performance upgrade due to Result Caching feature in Oracle 11g

Bar chart in Fig (1) shows the impact of Query performance comparison between Oracle 10g and Oracle 11g. Note that Query result caching has reported 25% growth in performance.

Size of result cache is determined by RESULT_CACHE_MAX_SIZE parameter whose value depends on MEMORY_TARGET (0.25%), SGA_TARGET (0.5%), and SHARED_POOL_SIZE (1%) parameters. It can be increased at SYSTEM level but cannot exceed 75% of the shared pool.

Result Cache Mode: Result Cache feature operates in two modes namely, MANUAL (default mode) and FORCE. In MANUAL operation mode, RESULT_CACHE has to be explicitly specified for Oracle to cache the results. In FORCE operation mode, all query result sets are forcibly cached in shared pool until NO_RESULT_CACHE hint is used in the query.

Result Cache in SQL: In SQL, Result cache can be done using a new hint RESULT_CACHE. The SQL statement in Example code (10) returns average salary of each department and caches the result set.

Example code: (10)

Result Cache in PL/SQL: In PL/SQL functions, Result Cache can be achieved by including an additional RESULT_CACHE clause in the function definition. It is optionally followed by RELIES_ON to specify the dependent tables.

The function F_GET_SAL in Example code (11) returns the salary of an employee, whose employee id is passed as a parameter. Note that the return value would be retained by the cache memory for the same set of input i.e. employee id.

Example code: (11)

Compound Trigger – Oracle 11g introduces Compound Triggers to deal with multiple problems. Being only a DML triggers, it not only it saves lot of code writing, but also resolves the issue where same set of session variables share common data and the famous mutating table error(ORA-04091). In compound trigger logic, all timing point logics are clubbed in one single body. As shown in the
below syntax, order of timing points must be retained.

Example Syntax: (2)

An additional timing point INSTEAD OF EACH ROW can be included for view triggers.

Set trigger firing order using FOLLOWS – Oracle 11g enables user to control the order of trigger execution. If multiple triggers are created for the same timing point and event on the same table, it order of execution can be set using FOLLOWS clause. FOLLOWS clause in a trigger specifies that the current trigger would follow the execution of specified triggers.

Example Syntax: (3)

Creating a trigger in DISABLED mode- Prior to Oracle 11g, a trigger can be created in ENABLED mode only. Oracle 11g provides flexibility to create a Trigger in DISABLED mode also. They remain deactivated until they are enabled.

Example Syntax: (4)

Secure Files to handle Large Objects- Handling of Large Objects has always been an unbounded area in Oracle. Oracle 11g has brought major changes by calling LOB storage as Secure Files. These are completely different from previous LOB data which would be now categorized under Basic Files. SecureFile(s) primarily focuses on performance, space consumption and security of objects. This provides storage scalability and object organization manageability. SecureFile usage policy can be enabled by setting DB_SECUREFILE parameter at SYSTEM level as shown in Example Syntax (5).

Example Syntax: (5)

Example Syntax (6) shows how to store LOBs as SecureFile.

Example Syntax: (6)

Storage parameters are CHUNK, [ENABLE | DISABLE] STORAGE IN ROW, [CACHE |NOCACHE], RETENTION, PCTVERSION, and [LOGGING | NOLOGGING].

Oracle 11g also introduces additional advanced features exclusively for SecureFile(s). These features are Deduplication, Compression and Encryption. These features can be applied individually or independently, but Oracle server follows the hierarchy as Deduplication, Compression and Encryption.

Partitioning Enhancements – Partitioning was first introduced in Oracle 8 release to achieve scalability and effective data maintenance. Over the period of time, it has emerged as one of the strongest feature for Large Scale Data Warehouses. In earlier version of Oracle, the most common type of Partitioning method used was Range Partitioning. Each Oracle release brings a considerable enhancement in Table Partitioning methods and features.

Oracle 11g introduces below additional partitioning strategies.

•  Extended composite partitioning strategies – Imposing multiple partitioning methods likeList-Range combination
• Virtual column based partitioning – Partition based on Virtual Column is known as Virtual Colum Based Partitioning
• Interval Partitioning – Extension of Range Partitioning.
• REF Partitioning – The Child table follows the same Partitioning scheme as specified for the parent node through PK-FK.

Program Inlining (A new PLSQL_OPTIMIZE_LEVEL) – Program inlining refers to replacing of the program call with a copy of the program. There can be selective scenarios in cumbersome applications where subprogram inlining improves performance. Prior to Oracle 11g, PLSQL_OPTIMIZE_LEVEL initialization parameter had 1 and 2 as admissible values to make decision over optimizer level. Oracle 11g introduces additional value ‘3’ in the bracket, which directs the optimizer to inline the subprograms at high priority. Note that optimizer does not performs any inlining at level 1, while logical inlining of subprograms at level 2. At level 3, optimizer inlines all the subprograms calls.

A new pragma PRAGMA INLINE has been introduced to specify whether a subprogram call has to be inlines or not. It intakes two parameters namely, subprogram name and [YES | NO].

Regular Expression enhancement REGEXP_COUNT – Oracle 11g adds REGEXP_COUNT as the latest member in the regular expression family. It is used to count the occurrence of a character or string expression in another string.

New Analytic Functions – Below new Analytic functions were introduced

• LISTAGG – Prior to Oracle 11g, conversion of rows into columns using a delimiter was done by
  workaround solution using XMLAGG or DECODE function. Now, Oracle 11g has introduced
• LISTAGG analytic function to aggregate the result set in multiple rows into one single column.. NTH_VALUE – The nth value range in a column can be determined using NTH_VALUE function.

Coding Enhancements

Fast DML triggers – In Oracle 11g, DML triggers have shown performance upgrade by 25%.

Default Value in Table ALTER command – In the Oracle version earlier than 11g, if a table has to be altered to add a column, the very next step was to update the existent rows to some default value.

Oracle 11g allows providing DEFAULT value for a column during table alteration. This has resolved the overhead of updating column with default value.

Example Syntax: (7)

Sequence Assignment – Prior to Oracle 11g, sequence assignment to a number variable could be done through a SELECT statement only. This was the gray area which could have degraded performance due to context switching from PL/SQL engine to SQL engine. Oracle 11g has transformed this feature of Sequence assignment to a PL/SQL construct. Refer the Example code (12) which demonstrates the Sequence assignment as a PL/SQL construct.

Example code: (12)

Functions in SQL-Named Notation – In Oracle 11g, functions can now be called using Named, Positional and Mixed notation while calling from SQL SELECT statement. For example,

A function F_SUMNUM in Example code (13) accepts two parameters to add them and print the result. Note that it uses Mixed notation of parameter passing in the Function call.

Example code: (13)

CONTINUE in FOR LOOP – Prior to Oracle 11g, if a value in an iterating loop has to be ignored,
NULL operation was assigned. Refer the code snippet in Example code (14a)

Example code: (14a)

Oracle 11g identified it as bad code practice to assign NULL operation to the compiler. CONTINUE
statement can be used to direct the pointer to continue its iteration if it matches the ignore condition.
Refer the Example code (14b).

Example code: (14b)

WHEN OTHERS compile time warning – Oracle 11g discourages the use of WHEN OTHERS generic exception as it suppresses the important exceptions in the program. In oracle 11g, such code would raise a warning PLW-06009. Note that this is a PL/SQL warning and not an exception. Program continues the execution but traces the coding standard failure.

New data types– Oracle 11g has designed a new data type SIMPLE_INTEGER, SIMPLE_FLOAT, and SIMPLE_DOUBLE keeping in view the hardware requirements and expectations with an Integer value. They are compatible with the native compilation feature of Oracle 11g, which makes supports their faster implementation.

SIMPLE_INTEGER restricts NULL values and provide number range from -2147483648 to 2147483647. Similarly, the other two data types avoid NULL check and data overflow checks, thereby enhancing performance to a notable extent.

Native Dynamic SQL enhancements – Oracle 11g saw through multiple changes in Dynamic SQL
implementation. Few of them are listed below.

• EXECUTE IMMEDIATE, DBMS_SQL.PARSE() and Ref Cursors can accept String SELECT statements as CLOB. This lifts the 32kb sizing restrictions from SQL statements to be dynamically executed.
• DBMS_SQL cursor and a Ref cursor are inter convertible

SKIP LOCKED for locked tables – Oracle 11g introduced SKIP LOCKED clause to query the records from the table which are not locked in any other active session of the database. This looks quite similar to exclusive mode of locking. The SQL statement in Example code (15) queries the unlocked records from EMP table

Example code: (15)

IGNORE_ROW_ON_DUPKEY_INDEX Hint for INSERT Statements – In Oracle 11g, the INSERT statements which use other table to load the data can make use of the hint IGNORE_ROW_ON_DUPKEY_INDEX to avoid the unique key conflict with the existing row. It ignores the unique key violation during insertion. It is similar to handling of DUP_VAL_ON_INDEX exception, but comparatively it is slower than a single INSERT statement and carries the overhead of creating a PL/SQL block.

DATABASE_ROLE constant for SYS_CONTEXT – A new parameter is introduced in USERENV namespace which returns the database role currently used by the Oracle server. Possible values of DATABASE_ROLE constant are PRIMARY, PHYSICAL STANDBY, LOGICAL STANDBY, and SNAPSHOT STANDBY.

Example code: (16)

Recursive common table expressions – In Oracle 11g, recursive common table expression (CTE) algorithm can be used for multiple utilities on hierarchical data. It can be used as number generator, data of bills of material, chasing many to many relationship data and interestingly Sudoku puzzle.

CTE algorithm is as below.

1.  Split the CTE expression into anchor and recursive members.
2. Run the anchor member(s) creating the first invocation or base result set (T0).
3. Run the recursive member(s) with Ti as an input and Ti+1 as an output.
4. Repeat step 3 until an empty set is returned.
5. Return the result set. This is a UNION ALL of T0 to Tn.

NO_DATA_NEEDED new exception – For parallel access and pipelined table functions, ORA-06528 exception was included in predefined exception list as NO_DATA_NEEDED.

Encrypted Tablespace – Encryption of Tablespace was introduced with Oracle 10g version but was deprecated due to multiple existing issues. Tablespace encryption in Oracle 11g extends the concept of Transparent Data Encryption and resolves the limitations of range scan and primary key issues. A new tablespace can be created in Encrypted form, with all of its tables and indexes in Encrypted form.

Available Encryption algorithms are:

• AES192 Advanced Encryption Standard (the default).
• 3DES168 Triple Data Encryption Standard 168-bit encryption
• AES128(Default) Advanced Encryption Standard 128-bit encryption
• AES256 Advanced Encryption Standard 256-bit encryption

Example Syntax: (8)

Tablespace specification for GTT – Oracle 11g provides provision to specify tablespace for Global Temporary tables. In earlier versions, GTT used to consume current user’s default temporary tablespace.

In Example code (16), a global temporary table G_ORDERS is created on GTT_TEMP tablespace.

Example code: (16)

More areas of Miscellaneous Interest

Restore Points in Database – In Oracle 11g, similar to SAVEPOINT in TCL commands, a RESTORE POINT can be created in the Database for a particular SCN or till a timestamp. Example code (17) and (18) show creation of RESTORE POINTS by SCN and TIMESTAMP

Example code: (17)

Example code: (18)

Fine Grained Dependency Tracking – Starting from Oracle 11g Release 1, concept of dependency is enhanced to a much granular level by magnifying logical dimension of the referenced object. If the changes to the referenced object make no consequence on the dependent object, the status of dependent object would remain VALID. This saves time which was earlier consumed in compiling the INVALID units after making any change in the referenced object. In 11g, this feature is majorly implemented for Views and Triggers.

Advanced Compression Option – Oracle 11g can now efficiently compress Structured/Unstructured data, back up data (RMAN), Data pump export files, and network transport data. Having first introduced in Oracle 9i, data compression feature shows major impact on costs, storage system, and memory usage. Oracle 11g takes ahead this feature by aiming to reduce the space occupied by data for OLTP as well as warehouse databases. The graph in Fig (2) demonstrates the differences between Oracle 10g and Oracle 11g on Advanced Compression.

Fig (2) Graphical comparison of Storage, Query Time, CPU overhead between Oracle 10g and Oracle 11g

Compression can be achieved for tablespaces, tables, partitions by associating [NOCOMPRESS |COMPRESS], COMPRESS FOR DIRECT LOAD OPERATIONS, and COMPRESS FOR ALL OPERATIONS options with the definition.

Example Syntax: (9)

Apart from storage and cost advantages, compression also leaves an impact on performance by reducing disk I/O and buffer cache memory, thereby speeding up table scans. But on the other hand, it also carries a minimal overhead on CPU which less than 3%.

Conclusion

I hope my effort to familiarize the Developer’s world with Oracle 11g is satisfactory. We shall discuss above features in detail in my upcoming articles on Oracle 11g, with more code snippets, help texts and descriptions.

These are a few questions that are just about guaranteed to come up during the initial stages of the project:

How do I get a record set from Oracle using a stored procedure?

Using a REF_CURSOR you can return a record set/cursor from a stored procedure.

Why don’t stored procedure work the same as in SQL Server?

In most cases you just use straight SQL and do not need a stored procedure. In Oracle, using cursors and adhoc SQL is the way. In SQL Server, using cursors and adhoc SQL is to be avoided (generally speaking, there are no absolutes).  Why you need to use a stored procedure for a SQL statement in Oracle must be fully explored. I am not saying you don’t need one, but the reason is not because that is the way you do it in SQL Server.

Please do not even start coding until you have read the following documents:

• Oracle Concepts
• 2 Day Developer’s Guide