The book aims to be a sure selection for the Associate level Oracle professionals aspiring for Professional level. The topics covered and demonstrated are in line with the Oracle University prescription for Oracle Professional certification, which justify the version updates to be advanced and not complex. The book is under publication from Packt publishers and all set for its release in May, 2012.

The OCP 1Z0-146 certification is the second milestone for the Associate level Oracle professionals. The journey from Associate to Professional level enhances your reliability and credibility with the Oracle technology, catalyzes your employability, and job effectiveness.

Apart from focusing the certification preparation, the book contains ample demonstrations and best programming practices, which can be employed in day-to-day assignments.

The book aims to cover the advanced features of PL/SQL, which are required to design and optimize the PL/SQL code. The recapitulation of PL/SQL programming and advanced features like collections, external procedures, server side result caching, implementing VPD to enforce row level security, handling large objects and SecureFiles build up a concrete platform for a PL/SQL professional. Apart from the programming, the book makes instrumental recommendations on the usage of development tool SQL Developer, employing best practices in database environments and safeguarding the vulnerable areas in PL/SQL code to avoid code injection.

The book gives a deeper insight to transform the readers from mid-level programmers to professional database designers. The advanced concepts covered through this book would surely agitate the readers to dig upon and explore more on the topics.

The book is on pre sales on Packt’s website, Amazon and all leading technical book distributors. Book details are as below:

ISBN(10): 1849687226
ISBN(13): 978-1-84968-722-5

Place your order from the below links

Buy from Packt Publishing

Buy from Amazon

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 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.

This is what I found so far:

• LocalDB
• Sequences
• SQL users without Instance logins
• File Tables
• THROW statement
• Support for up to 15,000 partitions
• Columnstore indexes
• User-defined server roles
• Default schemas for a Windows NT Group
• ad-hoc query paging for SELECT statements
• Support for importing and exporting Spatial data types natively using the SSMS Import/Export utility. For those of you wondering, this is a SSMS client enhancement and in my testing export/import of spatial tables worked between two SQL 2008 R2 databases where it would error on any table containing a spatial data type using the SSMS 2008 R2 client. Thank you SQL Dev Team.

New Functions:

Still wishing for:

The topics listed below should confirm your suspicion that there is significant learning and study required to understand Exadata. Outside of the Oracle Database software (which is the same) there is a lot more complexity to operate an Exadata Machine over a tradtional database server running on Linux, UNIX, Windows. Now I know why Oracle had to change the Exadata marketing from an “appliance” to a “machine”.

I plan to update these notes once the proof of concept is complete and I fully understand all the nuances of Exadata. Until then, consider this a list of topics and source of suggested resources for further study.

Exadata Infrastructure Components

• Database Servers
• Storage Servers
• InfiniBand
• Flash Cache
• CELLBOOT USB Flash Drive

Exadata Software Components

• Oracle Automatic Storage Management (ASM)
• Oracle Real Application Clusters (RAC). Not required but sales will say it is.
• Oracle Database
• Linux Logical Volume Manager (LVM)

Connectivity

• Database Servers connect to Storage Servers using the Intelligent Database protocol (iDB) implementing the “function shipping” architecture.
• iDB use the Reliable Datagram Sockets (RDS) protocol. RDS is designed for low latency and low overhead using less significantly less CPU when compared to UDP and TCP.
• iDB is based on libskgxp.

Exadata Database Servers

• No storage devices are presented to the OS on the Exadata database servers.

Exadata Storage Servers

• Storage Indexes contain min and max values for up to eight columns.
• Storage Indexes are 1MB (default) units. Identify locations where the data is not “Reverse Index”. Best for sorted data.

Exadata Smart Scan (Offloading)

• Column Projection
• Predicate Filtering
• Storage Indexes
• Bloom Filters
• SQL Functions (most single row functions can be offloaded)
• Compression and Decompression
• Encryption/Decryption

Smart Scans not available on:

• Clustered tables
• Index Organized Tabes (IOTs)
• When ROWDEPENDENCIES is enabled

Compression Types

Basic

• Compression unit is a single Oracle block. 0% PCTFREE

OLTP (Advanced Compression)

• Compression same as basic but uses symbol table to replace repeating values. 10 % PCTFREE for updates

Hybrid Columnar Compression (Exadata Storage Only)

• QUERY LOW uses LZO compression (4x)
• QUERY HIGH uses ZLIB compression (6x)
• ARCHIVE LOW uses ZLIP compression (7x)
• ARCHIVE HIGH uses bzip2 compression (12x)

Compression should not be used on tables or partitions where data is updated due to contention.

Exadata Backup and Recovery

• RMAN incremental backups benefit from the storage servers filtering out unchanged blocks.

Recommended Reading:

• Expert Oracle Exadata
• Achieving Extreme Performance with Oracle Exadata (Osborne ORACLE Press Series)
• A Technical Overview of the Oracle Exadata Database Machine and Exadata Storage Server 
• Oracle Exadata Price List

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.

However, we take security very seriously and have performed the necessary response to protect our visitors.

At this time we have notified Google of our actions, and are waiting for Google to perform another scan to give dbanotes.com a clean bill of health.

As of Sunday, Sept. 4, 2011, if you get the following browser malware warning you may safely choose to ignore it.

What was our response to the Security Exploit ?
We rebuilt the entire dbanotes.com site from scratch. New database, new WordPress installation, new Theme installation, and a clean import of all content from backup.

If you still feel you are at risk of getting malware from visiting dbanotes.com, I encourage you to wait until Google removes the official malware warning.

Thank you for your continued support.

Regards,
dbanotes.com

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.