At this article i will try to mention about Forms’ special triggers on various types. We will examine them in three sections; Form level triggers, Data block level triggers and Item level triggers.

Form Level Triggers;

When-New-Form-Instance: This trigger is called just after form is called. So you can do everything you need to do before the form starts. Be careful that this trigger is called only when the form is opened.

When-Form-Navigate: This trigger is helpful when you need to open a new form(as new program) from a from. This trigger is called when navigating between those forms.

Oracle Explain Plan Terms:

Table Access Full: Oracle reads every row in selected table. In terms of that there is no primary key or index defined with the columns that you use at your where clause Oracle makes full table access.

OPERATION                      OPTIONS         OBJECT_NAME

—————————— ————— ——————–

SELECT STATEMENT

TABLE ACCESS                   FULL            Students

Selecting With Primary Keys:  Primary key defines a row uniquely. By using table’s primary key at where clause Oracle makes Index RowID Unique Scan   in order to select unique row which reduces our total cost so much.

OPERATION                      OPTIONS         OBJECT_NAME
------------------------------ --------------- --------------------
SELECT STATEMENT
TABLE ACCESS                   BY INDEX ROWID  Students
INDEX                          UNIQUE SCAN     Students _PK

Selecting With Ununique Indexes: Ununique indexes reduces the cost of full table scan. But, of course if we have change to use primary keys we should use them. If we can’t we can use other non-unique indexes. The reducement of cost varies due to index’s definition. If the uniqueness of our index columns raises retrieval time will go down. Because of this reason, use the criteria that will catch the fastest index for that query.

OPERATION                      OPTIONS         OBJECT_NAME

—————————— ————— ——————–

SELECT STATEMENT

TABLE ACCESS                   BY INDEX ROWID  Students

INDEX                          RANGE SCAN      Students_IDX1

Efficiency of Join Statements:  We should be very careful at writing join statements. The column you choose the join plays very important role here. The most important thing we have to consider at creating joins is using indexed columns at where clause. Let’s assume that there is a table “StudentMarks” keeping marks of students for some particular lesson.For example phisics. The statement following retrievs  all the marks of the students having the name “ENGİN”. StudentMarks table does not have any foreign key at student column. İts only index column is mark.

select s.name,s.surname,m.mark
  from StudentMarks m, Students s
 where s.name = ‘ENGİN’

   and s.id = m.studentid

   and m.mark between 10000 and 30000

OPERATION                      OPTIONS         OBJECT_NAME

—————————— ————— ——————–

SELECT STATEMENT

NESTED LOOPS

TABLE ACCESS                   BY INDEX ROWID  Students

INDEX                          RANGE SCAN      Student_IDX2

TABLE ACCESS                   BY INDEX ROWID  StudentMarks

INDEX                          RANGE SCAN      StudentMarks_IDX3

All the columns are catched by range scan.

Choosing The Fastest Index: Indexes varies by the mean of cost. To query with minimum cost, we have to keep in mind the table’s count of rows. We should always give our priority to most sized table by the mean of choosing where clauses. Let’s take an example to examine this furter; 

select s.name,s.surname,m.mark
  from StudentMarks m, Students s
 where s.name = ‘ENGİN’

   and s.id = m.studentid

   and m.mark between 10000 and 30000

Will produce this plan:

OPERATION                      OPTIONS         OBJECT_NAME

—————————— ————— ——————–

SELECT STATEMENT

NESTED LOOPS

TABLE ACCESS                   BY INDEX ROWID  Students

INDEX                          RANGE SCAN      Students_IDX2

TABLE ACCESS                   BY INDEX ROWID  StudentMarks

INDEX                          RANGE SCAN      StudentMarks _IDX3

Oracle, tries to determine whether students or studentsmarks table is the best to index first. At the term oracle can not decide, Oracle starts indexing at the order of right to left at from clause. Be careful about this query. It is the same with the one above. But, at this query Oracle starts indexing with StudentMarks table.

 select s.name,s.surname,m.mark
  from Students s, StudentMarks m
 where s.name = ‘ENGİN’

   and s.id = m.studentid

   and m.mark between 10000 and 30000

This query produces this plan:

OPERATION                      OPTIONS         OBJECT_NAME

—————————— ————— ——————–

SELECT STATEMENT

NESTED LOOPS

TABLE ACCESS                   BY INDEX ROWID  StudentMarks

INDEX                          RANGE SCAN      StudentMarks _IDX3

TABLE ACCESS                   BY INDEX ROWID  Students

INDEX                          RANGE SCAN      Students_IDX2

StudentMarks.mark is queried first because we told Oracle to do so.

Utilizing Multiple Column Indexes

Utilizing Multiple Column Indexes: Multiple Column indexes uses more than one column for indexing. In order to use that index we have to search for the first column before we search second column in the index. To get more efficient queries from that indexes we have to choose index criteria more uniquely. Unique columns are also indexes. It is the best way to use unique indexes to get one specific row.

Oracle Explan Plan Terms

Whenever you read or write data in Oracle, you do so by issuing an SQL statement. One of Oracle’s task when it receives such a statement is to build a query execution plan. An execution plan defines how Oracle finds or writes the data. For example, an important decision that Oracle has to take is if it uses indexes or not. And if there are more indexes, which of these is used. All this is contained in an execution plan.

If one wants to explore such an execution plan, Oracle provides the SQL statement EXPLAIN PLAN to determine this.

The general syntax of EXPLAIN PLAN is:

explain plan for your-precious-sql-statement;

If you do an EXPLAIN PLAN, Oracle will analyze the statment and fill a special table with the Execution plan for that statement. You can indicate which table has to be filled with the following SQL command:

explain plan into table_name for your-precious-sql-statement;

If you omit the INTO TABLE_NAME clause, Oracle fills a table named PLAN_TABLE by default.

Whenever you read or write data in Oracle, you do so by issuing an SQL statement. One of Oracle’s task when it receives such a statement is to build a query execution plan. An execution plan defines how Oracle finds or writes the data. For example, an important decision that Oracle has to take is if it uses indexes or not. And if there are more indexes, which of these is used. All this is contained in an execution plan.

If one wants to explore such an execution plan, Oracle provides the SQL statement EXPLAIN PLAN to determine this.

The general syntax of EXPLAIN PLAN is:

explain plan for your-precious-sql-statement;

If you do an EXPLAIN PLAN, Oracle will analyze the statment and fill a special table with the Execution plan for that statement. You can indicate which table has to be filled with the following SQL command:

explain plan into table_name for your-precious-sql-statement;

If you omit the INTO TABLE_NAME clause, Oracle fills a table named PLAN_TABLE by default.

The Plan Table

The plan table is the table that Oracle fills when you have it explain an execution plan for an SQL statement. You must make sure such a plan table exists. Oracle ships with the script UTLXPLAN.SQL which creates this table, named PLAN_TABLE (which is the default name used by EXPLAIN PLAN). If you like, however, you can choose any other name for the plan table, as long as you have been granted insert on it and it has all the fields as here.

The fields (attributes) within the plan table

Arguably, the most important fields within the plan table are operation, option, object_name, id, and parent_id. The pair operation and object_name define what operation would be done on (or with) object_name. If an operation has an id which other operations have as parent_id, it means the other operations feed their result to the parent.

Possible values for operation are:

• DELETE STATEMENT
• INSERT STATEMENT
• SELECT STATEMENT
• UPDATE STATEMENT
• AND-EQUAL
• CONNECT BY
• CONCATENATION
• COUNT
• DOMAIN INDEX
• FILTER
• FIRST ROW
• FOR UPDATE
• HASH JOIN
• INDEX
• INLIST ITERATOR
• INTERSECTION
• MERGE JOIN
• MINUS
• NESTED LOOPS
• PARTITION,
• REMOTE
• SEQUENCE
• SORT
• TABLE ACCESS
• UNION
• VIEW

Option tells more about how an operation would be done. For example, the operation TABLE ACCESS can have the options: FULL or BY ROWID or many others. Full in this case means, that the entire table is accessed (takes a long time if table is huge) whereas BY ROWID means, Oracle knows where (from which block) the rows are to be retrieved, which makes the time to access the table shorter.

dbms_xplan

As of 9i, dbms_xplan can be used to format the plan table.

Operations

The following table is used to demonstrate EXPLAIN PLAN:

create table test_for_ep (a number, b varchar2(100));

Now, let’s explain the plan for selecting everything on that table:

delete plan_table;

explain plan for select /*+ rule */ * from test_for_ep where a = 5;

Displaying the execution plan

In order to view the explained plan, we have to query the plan table:

select
  substr (lpad(' ', level-1) || operation || ' (' || options || ')',1,30 ) "Operation",
  object_name                                                              "Object"
from
  plan_table
start with id = 0
connect by prior;

This statement is a simplified version of utlxpls.sql. utlxpls.sql is a script that Oracle ships.

Here’s the output of the explain plan:

SELECT STATEMENT ()
 TABLE ACCESS (FULL)           TEST_FOR_EP

First, take a look at the indention: TABLE ACCESS is indented right. In an explain plan output, the more indented an operation is, the earlier it is executed. And the result of this operation (or operations, if more than one have are equally indented AND have the same parent) is then feeded to the parent operation. In this case, TABLE ACCESS is made first, and its result feeded to SELECT STATEMENT (which is not an actual operation). Note the FULL in paranthesis in TABLE ACCESS: this means that the entire table is accessed.

Btw, sql*plus automatically explains the plan for you if autotrace is enabled.

Now, let’s create an index on that table:

create index test_for_ep_ix on test_for_ep (a);

And do the same select statement again:

delete plan_table;
explain plan for select /*+ rule */ * from test_for_ep where a = 5;

The plan is now:

SELECT STATEMENT ()
 TABLE ACCESS (BY INDEX ROWID) TEST_FOR_EP
  INDEX (RANGE SCAN)           TEST_FOR_EP_IX

Obviously, the index (TEST_FOR_EP_IX) is used first (most indented) then used for a TABLE ACCESS, second most indented, then the result is returned. The table access is not done by a full table scan but rather by using the data’s rowid.

INDEX

In the last example, Oracle employed an INDEX (RANGE SCAN). The RANGE SCAN basically means, that the index was used, but that it can return more than one row. Now, we create a unique index to see how this alters the explain plan:

create table test_for_ep (a number, b varchar2(100), constraint uq_tp unique(a));
 
delete plan_table;
explain plan for select /*+ rule */ * from test_for_ep where a = 5;

The explained plan is:

SELECT STATEMENT ()
 TABLE ACCESS (BY INDEX ROWID) TEST_FOR_EP
  INDEX (UNIQUE SCAN)          UQ_TP

INDEX (UNIQUE SCAN) means, that this index is used, and it sort of guarantees that this index returnes exactly one rowid. What happens, if we query the field not for equality but for greater than (a>5)?

explain plan for select /*+ rule */ * from test_for_ep where a > 5;

Here, we see that the index is used, but for a RANGE SCAN:

SELECT STATEMENT ()
 TABLE ACCESS (BY INDEX ROWID) TEST_FOR_EP
  INDEX (RANGE SCAN)           UQ_TP

If we only query fields of a table that are already in an index, Oracle doesn’t have to read the data blocks because it can get the relevant data from the index:

create table test_for_ep (a number, b varchar2(100), constraint uq_tp unique(a));
 
delete plan_table;
explain plan for select /*+ rule */ a from test_for_ep where a > 5 and a < 50;

Here’s the query execution planexecution plan. No table access anymore!

SELECT STATEMENT ()
 INDEX (RANGE SCAN)            UQ_TP

MERGE JOIN

See here. The first table’s join key is ba while the second table’s join key is aa.

create table test_for_ep_a (aa number, ab varchar2(100));
create table test_for_ep_b (ba number, bb varchar2(100));

Note, there are no indexes on both of the tables. Now, we join the tables on aa and ba:

explain plan for
  select /*+ rule */ a.aa from test_for_ep_a a, test_for_ep_b b where
  a.aa=b.ba and a.aa > 5;

As there are no indexes, both tables must be TABLE ACCESSed (FULL). After these accesses, their results are sorted.

SELECT STATEMENT ()
 MERGE JOIN ()
  SORT (JOIN)
   TABLE ACCESS (FULL)         TEST_FOR_EP_B
  SORT (JOIN)
   TABLE ACCESS (FULL)         TEST_FOR_EP_A

Note MERGE JOINs can only be used for equi joins, as is demonstrated in NESTED LOOPS

NESTED LOOPS

For each relevant row in the first table (driving table), find all matching rows in the other table (probed table).

See also here.

create table test_for_ep_a (aa number, ab varchar2(100));
create table test_for_ep_b (ba number, bb varchar2(100));
explain plan for
  select /*+ rule */ a.aa from test_for_ep_a a, test_for_ep_b b where
  a.aa > b.ba and a.aa > 5;

Note, there is no equi join to join test_for_ep_a and test_for_ep_b, (a.aa > b.ba)

SELECT STATEMENT ()
 NESTED LOOPS ()
  TABLE ACCESS (FULL)          TEST_FOR_EP_B
  TABLE ACCESS (FULL)          TEST_FOR_EP_A

Now, we put an index on TEST_FOR_EP_B and see how that influences our nested loop:

create table test_for_ep_a (aa number, ab varchar2(100));
create table test_for_ep_b (ba number, bb varchar2(100), constraint uq_ba unique(ba));
 
delete plan_table;
explain plan for
  select /*+ rule */ a.aa from test_for_ep_a a, test_for_ep_b b where
  a.aa > b.ba;

The plan is:

SELECT STATEMENT ()
 NESTED LOOPS ()
  TABLE ACCESS (FULL)          TEST_FOR_EP_A
  INDEX (RANGE SCAN)           UQ_BA

Interpreted, this means: TEST_FOR_EP_A is fully accessed and for each row, TEST_FOR_EP_B (or more accurately, its index UQ_BA) is probed. Thinking about it, this makes sense, doing the costly TABLE ACCESS once and use the index for each row. Then again, thinking about it, if TEST_FOR_EP_A is very small nad TEST_FOR_EP_B is large, this doesn’t make sense anymore. This is when the Cost Based Optimizer comes into play.

Sorts

Aggregate Sorts

Whenever a result set must be sorted, the operation is sort. If this sort is used to return a single row (for example max or min) the options is AGGREGATE. Consider the following example:

create table t_ep (
  w date,
  v number,
  x varchar2(40)
);
 
 
delete plan_table;
explain plan for select /*+ rule */ max(w) from t_ep where v=4;
SELECT STATEMENT ()
 SORT (AGGREGATE)
  TABLE ACCESS (FULL)          T_EP

Now: creating an index:

alter table t_ep add constraint uq_t_ep unique(v);
delete plan_table;
explain plan for select /*+ rule */ max(w) from t_ep where v=4;
SELECT STATEMENT ()
 SORT (AGGREGATE)
  TABLE ACCESS (BY INDEX ROWID) T_EP
   INDEX (UNIQUE SCAN)          UQ_T_EP

TKPROF

If you want to know, how much time an SQL statement acutally used, use TKPROF

ReferencesTop of Form

-          http://www.evolt.org/node/2986

Adam Patrick, Use Oracle’s Explain Plan to Tune Your Queries, August 24, 2000

-          http://www.adp-gmbh.ch/ora/explainplan.html

Oracle Explain Plan Terms:

Table Access Full: Oracle reads every row in selected table. In terms of that there is no primary key or index defined with the columns that you use at your where clause Oracle makes full table access.
OPERATION OPTIONS OBJECT_NAME
—————————— ————— ——————–
SELECT STATEMENT
TABLE ACCESS FULL Students
Selecting With Primary Keys: Primary key defines a row uniquely. By using table’s primary key at where clause Oracle makes Index RowID Unique Scan in order to select unique row which reduces our total cost so much.
OPERATION OPTIONS OBJECT_NAME
—————————— ————— ——————–
SELECT STATEMENT
TABLE ACCESS BY INDEX ROWID Students
INDEX UNIQUE SCAN Students _PK

Selecting With Ununique Indexes: Ununique indexes reduces the cost of full table scan. But, of course if we have change to use primary keys we should use them. If we can’t we can use other non-unique indexes. The reducement of cost varies due to index’s definition. If the uniqueness of our index columns raises retrieval time will go down. Because of this reason, use the criteria that will catch the fastest index for that query.
OPERATION OPTIONS OBJECT_NAME
—————————— ————— ——————–
SELECT STATEMENT
TABLE ACCESS BY INDEX ROWID Students
INDEX RANGE SCAN Students_IDX1

Efficiency of Join Statements: We should be very careful at writing join statements. The column you choose the join plays very important role here. The most important thing we have to consider at creating joins is using indexed columns at where clause. Let’s assume that there is a table “StudentMarks” keeping marks of students for some particular lesson.For example phisics. The statement following retrievs all the marks of the students having the name “ENGİN”. StudentMarks table does not have any foreign key at student column. İts only index column is mark.
select s.name,s.surname,m.mark
from StudentMarks m, Students s
where s.name = ‘ENGİN’
and s.id = m.studentid
and m.mark between 10000 and 30000

OPERATION OPTIONS OBJECT_NAME
—————————— ————— ——————–
SELECT STATEMENT
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID Students
INDEX RANGE SCAN Student_IDX2
TABLE ACCESS BY INDEX ROWID StudentMarks
INDEX RANGE SCAN StudentMarks_IDX3

All the columns are catched by range scan.

Choosing The Fastest Index: Indexes varies by the mean of cost. To query with minimum cost, we have to keep in mind the table’s count of rows. We should always give our priority to most sized table by the mean of choosing where clauses. Let’s take an example to examine this furter;

select s.name,s.surname,m.mark
from StudentMarks m, Students s
where s.name = ‘ENGİN’
and s.id = m.studentid
and m.mark between 10000 and 30000

Will produce this plan:
OPERATION OPTIONS OBJECT_NAME
—————————— ————— ——————–
SELECT STATEMENT
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID Students
INDEX RANGE SCAN Students_IDX2
TABLE ACCESS BY INDEX ROWID StudentMarks
INDEX RANGE SCAN StudentMarks _IDX3
Oracle, tries to determine whether students or studentsmarks table is the best to index first. At the term oracle can not decide, Oracle starts indexing at the order of right to left at from clause. Be careful about this query. It is the same with the one above. But, at this query Oracle starts indexing with StudentMarks table.
select s.name,s.surname,m.mark
from Students s, StudentMarks m
where s.name = ‘ENGİN’
and s.id = m.studentid
and m.mark between 10000 and 30000

This query produces this plan:
OPERATION OPTIONS OBJECT_NAME
—————————— ————— ——————–
SELECT STATEMENT
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID StudentMarks
INDEX RANGE SCAN StudentMarks _IDX3
TABLE ACCESS BY INDEX ROWID Students
INDEX RANGE SCAN Students_IDX2

StudentMarks.mark is queried first because we told Oracle to do so.

Utilizing Multiple Column Indexes
Utilizing Multiple Column Indexes: Multiple Column indexes uses more than one column for indexing. In order to use that index we have to search for the first column before we search second column in the index. To get more efficient queries from that indexes we have to choose index criteria more uniquely. Unique columns are also indexes. It is the best way to use unique indexes to get one specific row.
Oracle Explan Plan Terms
Whenever you read or write data in Oracle, you do so by issuing an SQL statement. One of Oracle’s task when it receives such a statement is to build a query execution plan. An execution plan defines how Oracle finds or writes the data. For example, an important decision that Oracle has to take is if it uses indexes or not. And if there are more indexes, which of these is used. All this is contained in an execution plan.
If one wants to explore such an execution plan, Oracle provides the SQL statement EXPLAIN PLAN to determine this.
The general syntax of EXPLAIN PLAN is:
explain plan for your-precious-sql-statement;

If you do an EXPLAIN PLAN, Oracle will analyze the statment and fill a special table with the Execution plan for that statement. You can indicate which table has to be filled with the following SQL command:
explain plan into table_name for your-precious-sql-statement;
If you omit the INTO TABLE_NAME clause, Oracle fills a table named PLAN_TABLE by default.

Whenever you read or write data in Oracle, you do so by issuing an SQL statement. One of Oracle’s task when it receives such a statement is to build a query execution plan. An execution plan defines how Oracle finds or writes the data. For example, an important decision that Oracle has to take is if it uses indexes or not. And if there are more indexes, which of these is used. All this is contained in an execution plan.
If one wants to explore such an execution plan, Oracle provides the SQL statement EXPLAIN PLAN to determine this.
The general syntax of EXPLAIN PLAN is:
explain plan for your-precious-sql-statement;
If you do an EXPLAIN PLAN, Oracle will analyze the statment and fill a special table with the Execution plan for that statement. You can indicate which table has to be filled with the following SQL command:
explain plan into table_name for your-precious-sql-statement;
If you omit the INTO TABLE_NAME clause, Oracle fills a table named PLAN_TABLE by default.
The Plan Table
The plan table is the table that Oracle fills when you have it explain an execution plan for an SQL statement. You must make sure such a plan table exists. Oracle ships with the script UTLXPLAN.SQL which creates this table, named PLAN_TABLE (which is the default name used by EXPLAIN PLAN). If you like, however, you can choose any other name for the plan table, as long as you have been granted insert on it and it has all the fields as here.
The fields (attributes) within the plan table
Arguably, the most important fields within the plan table are operation, option, object_name, id, and parent_id. The pair operation and object_name define what operation would be done on (or with) object_name. If an operation has an id which other operations have as parent_id, it means the other operations feed their result to the parent.

Possible values for operation are:
• DELETE STATEMENT
• INSERT STATEMENT
• SELECT STATEMENT
• UPDATE STATEMENT
• AND-EQUAL
• CONNECT BY
• CONCATENATION
• COUNT
• DOMAIN INDEX
• FILTER
• FIRST ROW
• FOR UPDATE
• HASH JOIN
• INDEX
• INLIST ITERATOR
• INTERSECTION
• MERGE JOIN
• MINUS
• NESTED LOOPS
• PARTITION,
• REMOTE
• SEQUENCE
• SORT
• TABLE ACCESS
• UNION
• VIEW

Option tells more about how an operation would be done. For example, the operation TABLE ACCESS can have the options: FULL or BY ROWID or many others. Full in this case means, that the entire table is accessed (takes a long time if table is huge) whereas BY ROWID means, Oracle knows where (from which block) the rows are to be retrieved, which makes the time to access the table shorter.
dbms_xplan
As of 9i, dbms_xplan can be used to format the plan table.
Operations
The following table is used to demonstrate EXPLAIN PLAN:
create table test_for_ep (a number, b varchar2(100));
Now, let’s explain the plan for selecting everything on that table:
delete plan_table;
explain plan for select /*+ rule */ * from test_for_ep where a = 5;

Displaying the execution plan
In order to view the explained plan, we have to query the plan table:
select
substr (lpad(‘ ‘, level-1) || operation || ‘ (‘ || options || ‘)’,1,30 ) “Operation”,
object_name “Object”
from
plan_table
start with id = 0
connect by prior id=parent_id;
This statement is a simplified version of utlxpls.sql. utlxpls.sql is a script that Oracle ships.
Here’s the output of the explain plan:
SELECT STATEMENT ()
TABLE ACCESS (FULL) TEST_FOR_EP
First, take a look at the indention: TABLE ACCESS is indented right. In an explain plan output, the more indented an operation is, the earlier it is executed. And the result of this operation (or operations, if more than one have are equally indented AND have the same parent) is then feeded to the parent operation. In this case, TABLE ACCESS is made first, and its result feeded to SELECT STATEMENT (which is not an actual operation). Note the FULL in paranthesis in TABLE ACCESS: this means that the entire table is accessed.
Btw, sql*plus automatically explains the plan for you if autotrace is enabled.
Now, let’s create an index on that table:
create index test_for_ep_ix on test_for_ep (a);
And do the same select statement again:
delete plan_table;
explain plan for select /*+ rule */ * from test_for_ep where a = 5;
The plan is now:
SELECT STATEMENT ()
TABLE ACCESS (BY INDEX ROWID) TEST_FOR_EP
INDEX (RANGE SCAN) TEST_FOR_EP_IX
Obviously, the index (TEST_FOR_EP_IX) is used first (most indented) then used for a TABLE ACCESS, second most indented, then the result is returned. The table access is not done by a full table scan but rather by using the data’s rowid.
INDEX
In the last example, Oracle employed an INDEX (RANGE SCAN). The RANGE SCAN basically means, that the index was used, but that it can return more than one row. Now, we create a unique index to see how this alters the explain plan:
create table test_for_ep (a number, b varchar2(100), constraint uq_tp unique(a));

delete plan_table;
explain plan for select /*+ rule */ * from test_for_ep where a = 5;
The explained plan is:
SELECT STATEMENT ()
TABLE ACCESS (BY INDEX ROWID) TEST_FOR_EP
INDEX (UNIQUE SCAN) UQ_TP
INDEX (UNIQUE SCAN) means, that this index is used, and it sort of guarantees that this index returnes exactly one rowid. What happens, if we query the field not for equality but for greater than (a>5)?
explain plan for select /*+ rule */ * from test_for_ep where a > 5;
Here, we see that the index is used, but for a RANGE SCAN:
SELECT STATEMENT ()
TABLE ACCESS (BY INDEX ROWID) TEST_FOR_EP
INDEX (RANGE SCAN) UQ_TP
If we only query fields of a table that are already in an index, Oracle doesn’t have to read the data blocks because it can get the relevant data from the index:
create table test_for_ep (a number, b varchar2(100), constraint uq_tp unique(a));

delete plan_table;
explain plan for select /*+ rule */ a from test_for_ep where a > 5 and a 5;
As there are no indexes, both tables must be TABLE ACCESSed (FULL). After these accesses, their results are sorted.
SELECT STATEMENT ()
MERGE JOIN ()
SORT (JOIN)
TABLE ACCESS (FULL) TEST_FOR_EP_B
SORT (JOIN)
TABLE ACCESS (FULL) TEST_FOR_EP_A
Note MERGE JOINs can only be used for equi joins, as is demonstrated in NESTED LOOPS

NESTED LOOPS
For each relevant row in the first table (driving table), find all matching rows in the other table (probed table).
See also here.
create table test_for_ep_a (aa number, ab varchar2(100));
create table test_for_ep_b (ba number, bb varchar2(100));
explain plan for
select /*+ rule */ a.aa from test_for_ep_a a, test_for_ep_b b where
a.aa > b.ba and a.aa > 5;
Note, there is no equi join to join test_for_ep_a and test_for_ep_b, (a.aa > b.ba)
SELECT STATEMENT ()
NESTED LOOPS ()
TABLE ACCESS (FULL) TEST_FOR_EP_B
TABLE ACCESS (FULL) TEST_FOR_EP_A
Now, we put an index on TEST_FOR_EP_B and see how that influences our nested loop:
create table test_for_ep_a (aa number, ab varchar2(100));
create table test_for_ep_b (ba number, bb varchar2(100), constraint uq_ba unique(ba));

delete plan_table;
explain plan for
select /*+ rule */ a.aa from test_for_ep_a a, test_for_ep_b b where
a.aa > b.ba;
The plan is:
SELECT STATEMENT ()
NESTED LOOPS ()
TABLE ACCESS (FULL) TEST_FOR_EP_A
INDEX (RANGE SCAN) UQ_BA
Interpreted, this means: TEST_FOR_EP_A is fully accessed and for each row, TEST_FOR_EP_B (or more accurately, its index UQ_BA) is probed. Thinking about it, this makes sense, doing the costly TABLE ACCESS once and use the index for each row. Then again, thinking about it, if TEST_FOR_EP_A is very small nad TEST_FOR_EP_B is large, this doesn’t make sense anymore. This is when the Cost Based Optimizer comes into play.
Sorts
Aggregate Sorts
Whenever a result set must be sorted, the operation is sort. If this sort is used to return a single row (for example max or min) the options is AGGREGATE. Consider the following example:
create table t_ep (
w date,
v number,
x varchar2(40)
);

delete plan_table;
explain plan for select /*+ rule */ max(w) from t_ep where v=4;
SELECT STATEMENT ()
SORT (AGGREGATE)
TABLE ACCESS (FULL) T_EP
Now: creating an index:
alter table t_ep add constraint uq_t_ep unique(v);
delete plan_table;
explain plan for select /*+ rule */ max(w) from t_ep where v=4;
SELECT STATEMENT ()
SORT (AGGREGATE)
TABLE ACCESS (BY INDEX ROWID) T_EP
INDEX (UNIQUE SCAN) UQ_T_EP
TKPROF
If you want to know, how much time an SQL statement acutally used, use TKPROF

References

- http://www.evolt.org/node/2986
Adam Patrick, Use Oracle’s Explain Plan to Tune Your Queries, August 24, 2000
- http://www.adp-gmbh.ch/ora/explainplan.html

EXECUTE IMMEDIATE StatementThe EXECUTE IMMEDIATE statement executes a dynamic SQL statement or anonymous PL/SQL block. You can use it to issue SQL statements that cannot be represented directly in PL/SQL, or to build up statements where you do not know all the table names, WHERE clauses, and so on in advance. For more information, see “Using the EXECUTE IMMEDIATE Statement in PL/SQL”.

Syntax

Description of the illustration execute_immediate_statement.gif

Keyword and Parameter Description

bind_argument

An expression whose value is passed to the dynamic SQL statement, or a variable that stores a value returned by the dynamic SQL statement.

BULK COLLECT

Stores result values in one or more collections, for faster queries than loops with FETCH statements. For more information, see “Reducing Loop Overhead for DML Statements and Queries with Bulk SQL”.

collection_name

A declared collection into which select_item values are fetched. For each select_item, there must be a corresponding, type-compatible collection in the list.

host_array_name

An array (declared in a PL/SQL host environment and passed to PL/SQL as a bind variable) into which select_item values are fetched. For each select_item, there must be a corresponding, type-compatible array in the list. Host arrays must be prefixed with a colon.

define_variable

A variable that stores a selected column value.

dynamic_string

A string literal, variable, or expression that represents a single SQL statement or a PL/SQL block. It must be of type CHAR or VARCHAR2, not NCHAR or NVARCHAR2.

INTO …

Used only for single-row queries, this clause specifies the variables or record into which column values are retrieved. For each value retrieved by the query, there must be a corresponding, type-compatible variable or field in the INTO clause.

record_name

A user-defined or %ROWTYPE record that stores a selected row.

returning_clause

Returns values from inserted rows, eliminating the need to SELECT the rows afterward. You can retrieve the column values into variables or into collections. You cannot use the RETURNING clause for remote or parallel inserts. If the statement does not affect any rows, the values of the variables specified in the RETURNING clause are undefined. For the syntax of returning_clause, see the “RETURNING INTO Clause”.

USING …

Specifies a list of input and/or output bind arguments. The parameter mode defaults to IN.

Usage Notes

Except for multi-row queries, the dynamic string can contain any SQL statement (without the final semicolon) or any PL/SQL block (with the final semicolon). The string can also contain placeholders for bind arguments. You cannot use bind arguments to pass the names of schema objects to a dynamic SQL statement.

You can place all bind arguments in the USING clause. The default parameter mode is IN. For DML statements that have a RETURNING clause, you can place OUT arguments in the RETURNING INTO clause without specifying the parameter mode, which, by definition, is OUT. If you use both the USING clause and the RETURNING INTO clause, the USING clause can contain only IN arguments.

At run time, bind arguments replace corresponding placeholders in the dynamic string. Every placeholder must be associated with a bind argument in the USING clause and/or RETURNING INTO clause. You can use numeric, character, and string literals as bind arguments, but you cannot use Boolean literals (TRUE, FALSE, and NULL). To pass nulls to the dynamic string, you must use a workaround. See “Passing Nulls to Dynamic SQL”.

Dynamic SQL supports all the SQL datatypes. For example, define variables and bind arguments can be collections, LOBs, instances of an object type, and refs. Dynamic SQL does not support PL/SQL-specific types. For example, define variables and bind arguments cannot be BOOLEANs or index-by tables. The only exception is that a PL/SQL record can appear in the INTO clause.

You can execute a dynamic SQL statement repeatedly using new values for the bind arguments. You still incur some overhead, because EXECUTE IMMEDIATE re-prepares the dynamic string before every execution.

The string argument to the EXECUTE IMMEDIATE command cannot be one of the national character types, such as NCHAR or NVARCHAR2.

Oracle has presented us so many libraries that we can use in order to accomplish our tasks. But, sometimes you need more. Because of this reason Oracle give Java support. You can use your Java classes at Oracle pl/sql scripts. As an example please look at following code sections;

Giving Grants;
Firstly, you have to give Java privilidges to your user.

GRANT JAVASYSPRIV TO SOMEUSERNAME;
GRANT JAVAUSERPRIV TO SOMEUSERNAME;

Creating Java Class;

Then after you have to write your java code at DB on Java section.

create or replace and compile java source named engin as
public class deneme
{
public static String entry(String x)
{
return “engin_” + x;
}
}

Registering Java Class

This code registers our Java Class function deneme.entry as firstjava on pl/sql

CREATE OR REPLACE FUNCTION firstjava (
file IN VARCHAR2) RETURN VARCHAR2
AS LANGUAGE JAVA
NAME ‘deneme.entry(java.lang.String)
return java.lang.String’;

Example Procedure

CREATE OR REPLACE Procedure engin_tesst
aa varchar2(100);
IS
begin
aa:=firstjava(‘c:\temp\temp.sql’);
dbms_output.put_line(aa);
END;

Test Script

begin
engin_tesst;
end;

Result: c:\temp\temp.sqlaaa

What is J2ME?

J2ME stands for Java 2, Micro Edition. It is a stripped-down version of Java targeted at devices which have limited processing power and storage capabilities and intermittent or fairly low-bandwidth network connections. These include mobile phones, pagers,wireless devices and set-top boxes among others.

A Sample Wireless Stack would consist of:

• Profiles
• Configurations
• Java Virtual Machines
• Host Operating System

What is a J2ME Configuration?

A configuration defines the minimum Java technology that an application developer can expect on a broad range of implementing devices.

J2ME Connected, Limited Device Configuration (CLDC)

• specifies the Java environment for mobile phone, pager and wireless devices
• CLDC devices are usually wireless
• 160 – 512k of memory available for Java
• typically has limited power or battery operated
• network connectivity, often wireless, intermittent, low-bandwidth (9600bps or less)

J2ME Connected Device Configuration (CDC)

• describes the Java environment for digital television set-top boxes, high end wireless devices and automotive telematics systems.
• device is powered by a 32-bit processor
• 2MB or more of total memory available for Java
• network connectivity, often wireless, intermittent, low-bandwidth (9600bps or less)

These two configurations differ only in their respective memory and display capabilities.

What is a J2ME Profile?

A specification layer above the configuration which describes the Java configuration for a specific vertical market or device type.

J2ME Profiles

J2ME Mobile Information Device Profile (MIDP)

• this is the application environment for wireless devices based on the CLDC
• contains classes for user interface, storage and networking

J2ME Foundation Profile, Personal Basis, Personal and RMI profiles

• these are profiles for devices based on the CDC, which are not addressed in this tutorial

Virtual Machines

The CLDC and the CDC each require their own virtual machine because of their different memory and display capabilities. The CLDC virtual machine is far smaller than that required by the CDC and supports less features. The virtual machine for the CLDC is called the Kilo Virtual Machine (KVM) and the virtual machine for the CDC is called the CVM.

Tools

First make sure that you have the Java 2 SDK, Standard Edition (J2SE SDK), version 1.4.2 (or later). This is essential for development. If you haven’t installed it, download it and install it from here http://java.sun.com/j2se/downloads/index.html.
You absolutely MUST have the J2SE SDK installed before you install the Java Wireless Toolkit as you will be needing the tools it contains (such as javac) to compile and run your MIDlets.

Then download the J2ME Wireless Toolkit (WTK) which is available free from Sun here – http://java.sun.com/products/j2mewtoolkit/. I’m going to assume that you’ll be installing this in the C:\j2mewtk\ directory, if you use another directory, just modify the paths accordingly.

Paths

Java needs to know where all your files are, so we need to add the location of the Java binaries to the system path.

Windows 95/98

Go to Start->Run. Type in command. Then type

SET PATH=%PATH%;C:\j2mewtk\bin

You should also edit your C:\autoexec.bat file to include this line, so you don’t have to enter it every single time you restart your computer. After you’ve done this, you should be able to run the tools included in the Java Wireless Toolkit from any directory on your system.

Windows 2000/XP

• Go to Control Panel -> System.
• Click on the Advanced Tab
• Click on the Environment Variables button
• Double-click the PATH variable in the System variables box
• At the end of the Variable value field, add the path to your J2ME WTK installation – for me this is something like C:\j2mewtk
• If you had to install the J2SE SDK too, it’s a good idea to add the path for that – for me this is C:\j2sdk1.4.2_03 and C:\j2sdk1.4.2_03\bin. Here’s what my screen looked like.

A good way to test if this worked is to type the preverify command without any arguments in the command line. You should see something like this on your screen.

C:\> preverify
Usage: PREVERIFY.EXE [options] classnames|dirnames …

where options include:
-classpath
Directories in which to look for classes
-d Directory in which output is written
@ Read command line arguments from a text file.

Application Development

MIDlets vs Applets

MIDlets are applets for mobile phones. Just like applets, they run in a protected sandbox – the KVM – but unlike applets, they are extremely limited. MIDP 1.0 is currently found on most Java-capable phones and is fairly restrictive. As an example – the KVM doesn’t allow you to process floating point numbers yet and MIDlets written for MIDP 1.0 can’t access anything outside of the sandbox without proprietary APIs from phone manufacturers. So, put your dreams of developing the ultimate MIDlet with hooks into every part of your phone OS on the backburner for a while. If you want to find out exactly how limited MIDP 1.0 is, you should probably read the spec here. Once you’ve done that you might want to check out  with that spec. For the time being we’re going to write our first MIDlet – a full-featured “Hello MIDlet” application.

Simple HelloMIDlet

We’re going to use a program called Ktoolbar from the JAVA WTK which we installed earlier.

• Go to Start->Programs->J2ME Wireless Toolkit 2.1->KToolbar.
• Click on the New Project button and name your project HelloProject and your MIDlet HelloMidlet. You should see something like this.
• Once you press Create Project, KToolbar will create a bunch of directories for your project in the apps subdirectory. We’re going to ignore most of them for the moment and focus on a few important onesC:\j2mewtk\apps\HelloProject - the main directory for your project
  C:\j2mewtk\apps\HelloProject\bin - where Ktoolbar stores .jar, .jar and manifest.mf files
  C:\j2mewtk\apps\HelloProject\classes - where the class files are stored
  C:\j2mewtk\apps\HelloProject\src - where the source .java files are stored
• Now, fire up your favourite text editor – I like Textpad- and type in the following code/* Hello Midlet – your first program*/
  import javax.microedition.lcdui.*;
  import javax.microedition.midlet.*;public class HelloMidlet
  extends MIDlet
  implements CommandListener {
  private Form mMainForm;

  public HelloMidlet() {
  mMainForm = new Form(“HelloMidlet”);
  mMainForm.append(new StringItem(null, “Hello, MIDP! \n\nYou and me – we’re gonna make sweet MIDlets together! “));
  mMainForm.addCommand(new Command(“Exit”, Command.EXIT, 0));
  mMainForm.setCommandListener(this);
  }

  public void startApp() {
  Display.getDisplay(this).setCurrent(mMainForm);
  }

  public void pauseApp() {}

  public void destroyApp(boolean unconditional) {}

  public void commandAction(Command c, Displayable s) {
  notifyDestroyed();
  }
  }

• Save this file as HelloMidlet.java in the C:\j2mewtk\apps\HelloProject\src
• Go back to KToolBar – then click on Build and then Run – you should see something like this.
• Click on the Launch softkey in the emulator to get your MIDlet to say hello. You’ve just written your first MIDlet!

Provisioning

Okay, now how do I get my code onto my phone?

Once you’ve created your lovely little MIDlet and ensured that everything worked smoothly in the emulator, the next step is to get it running on an actual device. Provisioning is the name given to the process of deploying your application in such a way that it is easily downloaded and installed on the device.

1. Over The Air (OTA) Provisioning

OTA provisioning allows users to download your application wirelessly using the WAP browsers built into their phones. To begin, we need to take a look at the Java Application Descriptor (JAD) file that is created when you package a MIDlet using the J2ME Wireless Toolkit. The JAD file stores information about your application and lets you modify various parameters of the MIDlet suite such as where the icon resource can be found, which MIDlets are included and where you can download the full version of the application. To edit a JAD file using the Wireless Toolkit, open your project, then click on Settings. This will open up a new window with a number of tabs – API Selection, Required, Optional, User Defined, MIDlets, Push Registry and Permissions.

1. API SelectionThis is where you choose which version of MIDP your application will use and which optional packages (JSRs) are included. The default is set to JTWI (Java Technology for the Wireless Industry) which allows you to use MIDP 2.0 as well as MMAPI and other exciting things. If you’re having any problems with your application on your device try changing this to MIDP 1.0.
2. RequiredThis tab includes various options which are essential for packaging a MIDlet suite. The MIDlet-Jar-URL attribute is where we will define the location of the packaged JAR file to be downloaded to the device.
3. OptionalThis tab includes optional parameters for your MIDlet – such as the path to the icon for the entire suite, a description and a MIDlet-Info-URL parameter.
4. User DefinedThis tab includes user defined variables that your MIDlet can use – such as a common URL that you don’t want to hard wire into the source code.
5. MIDletsThis tab manages all the settings for the MIDlets within your suite. At the very least you need to have one file here. This is also where you set the path to the MIDlet’s icon resource.
6. Push RegistryThis lets you configure the Push Registry which allows your MIDlet to listen and act on information received from a remote source. MIDP 2.0 Only.
7. PermissionsUnder MIDP 1.0, applications could only access libraries packaged inside the suite – this was called the sandbox model. MIDP 2.0 introduces the concept of trusted applications which allow access beyond the sandbox. This section allows you to specify which APIs are accessible.

For our purposes – the most important property is the MIDlet-Jar-URL within the Required tab. Here are the steps you need to take:

1. Create a folder on your web serverHopefully you have an account with a web provider – login to that account and create a directory for your MIDlets to live and be served from. I created the directory http://uberthings.com/mobile/midlets. Once you’ve got that, you need to make a few changes to allow your server (assumed to be Apache) to serve JAD and JAR files correctly. Go to the root of your account and edit or create your .htaccess file. Add these lines:AddType text/vnd.sun.j2me.app-descriptor jad
   AddType application/java-archive jar

   Save this file. If you’re not using Apache, ensure that your MIME types include the above two settings.

2. Specify the MIDlet-Jar-URLClick on Settings then go to the Required Tab. In the MIDlet-Jar-URL field, fill in the absolute URL of your JAR file. This will normally be something like http://mydomain/mydir/HelloProject.jar. For my server, this was http://www.uberthings.com/mobile/midlets/HelloProject.jar.
3. Package your MIDletClick on Project->Package->Create Package. This will create a .jar and a .jad file in your applications bin folder. For my application – this was c:\j2mewtk\apps\HelloProject\bin\HelloProject.jar and c:\j2mewtk\apps\HelloProject\bin\HelloProject.jad.
4. Upload the packaged MIDlet suiteUpload the JAR and JAD files that the packaging operation created to the folder you created earlier.
5. Test with your deviceOpen the WAP browser on your phone and point it to the URL of the JAD file. Using my example, this would be http://uberthings.com/mobile/midlets/HelloProject.jad. Your device should then prompt you to download and install the MIDlet. Carry it around and show it off to all your friends!

2. Cable / Bluetooth

If you’ve got a Bluetooth adaptor or a USB cable which connects directly to your phone, you can use this to quickly test your packaged midlet.

Windows XP/2000: Browse to the bin folder of your project, right click on the .jar file and select Send To->Bluetooth->YOURDEVICE.
MacOS X: Click on the Bluetooth icon in the menu bar, choose Send File. Send it to your device.
This should send a message to your phone which will install the MIDlet once opened. This should work on most Nokia Series 60 phones (3650, 6600, N-Gage etc).

Today, i had a problem while trying to use a clob value at my dynamic sql. Let me explain the problem further;

Development IDE : Oracle Forms

Failed Function: forms_ddl

I was trying to give forms_ddl function a clob value which includes ‘insert into …_table (…) values(…)’ format insert sql. Everything was working fine. But then i had to insert a clob value that is more than 4000 character(As you know the biggest varchar2 value can be 4000 characters), then it failed to insert. I had a lot of research about this and i found out the problem lying behind it. It was the character limit. Forms_ddl function only takes 4000 character of sql and truncates if it comes more than 4000. 

So, after researching i found out a usage which i will share with you. Please take a careful look at the code section below.

declare

   c3 integer;

   c3_tmp integer;

   str varchar2(4000);

   tmp clob;– the value to be inserted

begin 

  c3 := dbms_sql.open_cursor;– opens a cursor for us to execute our sql command
  
  
  dbms_sql.parse(c3, str, 1);– this statement parses our sql. str is the parameter which our sql statements included.   

    –Other parameters can be used same.
 

  dbms_sql.bind_variable(c3, ‘:values’, tmp);–binding variable :values into our dynamic sql and telling Oracle  ———–that :values := tmp. By the help of this statement we do not have to write all the clob value into our dynamic sql. So —no character limit will effect this statement.

  c3_tmp := dbms_sql.execute(c3);– This statement executes our sql. Everything works fine.

  commit;

end;

–str is the string which is like ‘insert into … (column_names) values(values–but one of them is a clob value which is declared like a bind variable :values)’

example;

str := ‘insert into users_table (op_id,PlacesVisited) values (‘EOZER’,:values)’

this sql statement script can be used to insert user_table a clob value with bind variable.

SYSDATE

Sysdate represents current date and time in Oracle. 

Example;

select sysdate from dual

Result;

29/06/2009 1:41:10 PM

ADD_MONTHS

This function adds specified amount of months to date given. Its usage and results are like this;

declare

  x date;

begin

           x  :=  ’25/10/2009′;

           x := add_months(x,1);

           dbms_output.putline(x);

end;

Result;

25/11/2009

MONTHS_BETWEEN

This function is used to get the months between two date values given. The only detail with this function is that this function returns a float value. Because of this reason you can either use this value directly, truncate it, floor it, ceil it or round it. It is up to your usage.

Example;

select months_between(‘25/10/2009′,’26/12/2009′) from dual

Result;

-1.03225806451613

This value tells us that first date is past according to second date and more than one months are between these dates.

Date Format

To change the date format of our session we can use this Oracle DB command;

ALTER SESSION SET NLS_DATE_FORMAT = ‘DD/mm/YYYY HH24:MI:SS’;

This code changes our date time format to example given;

Result

25/10/2009 15:12:42

Date Formats Ex

There are so many date formats at Oracle that can be used. If you ask why we need this formats it is clear for me to say that you will absolutely need this formats in order to show your values correctly to en user.

You could want to show current date like this; ‘25/10/2009′ or like this ‘25-10-2009′ or just with numbers ‘25102009′. Every companies has their own styles of coding. Date formats are one of them. One company could tell you that they want you to show every dates at dd/mm/yyyy format.  If you do not format your dates each time you parse it to this format it can work fine at first. But, whenever someone tries to change machine’s NLS settings to another values then you are having problem. To avoid this kind of situations you should be using date formats for following situations;

        – When you are parsing date value to a string value (varchar…);

                 * You can use to_char(date,’format’)–date and format are in varchar format.

                 example;

                 select to_char(sysdate,’dd/mm,yyyy’) from dual;

                 Retuns

                  29/06,2009

                 Example 2

                 select to_char(sysdate,’day-mon-year’) from dual

                 Retuns

                 mon-june-two thousand nine

                   You can convert your date values at any format you want. As in the second example you can convert date values to human language format.  It takes this formats from NLS(Language) settings.

           – When you want to convert char to date;

                    * You can use to_date function

                     Example

                     declare

                           x date;

                     begin

                             x := to_date(‘25/10/2009′,’dd/mm/yyy’) ;

                     end;

                     Warning: Although Oracle recognises your computer’s date format automatically to keep your software portable you should specify format parameter each time you use it.

NEXT_DAY

This function returns the first date that the day of week specified comes.

Example;

SELECT NEXT_DAY(‘27/06/2009′, ‘MON’) FROM dual;

Returns

29/06/2009

ROUND

 
This function round the date value given. It uses the standard rounding rules. Rounds to nearest date.

Example

SELECT ROUND(TO_DATE(‘27-11-01′),‘mm’) NEW_YEAR from dual

Returns

01/12/0001

Hello,

This is my first post on wordpress. I want to tell you about how to do debugging stuff on pl/sql developer at Oracle database.

Firstly, a database is needed to be connected. To do this, we have to add tns file at our C:\DevSuite10g\NETWORK\ADMIN\tnsnames.ora location. After making sure the tns file is correctly placed there, we can start working on pl/sql developer.

Open pl/sql developer program, select the database to connect, write your user id and password then click connect.

congratulations! You have successfully connected to database. You have two ways to open debug window. But i will tell you one. Click on the new button(with sheet picture at bottom of page), it shows a menu then select test window. Write down your code there then click start debuggin button. Program will work line by line. then you can implement your classical style debugging there.

The main diffrence between debugging on normal programming languages and pl/sql is that, at pl/sql you have to make sure what all the select statements returns. Because of this reason while debugging, get all the sql statement’s and its subqueries’ return values and calculate them correctly.

Don’t forget, the biggest mistakes at pl/sql programs are made by mistaken select statements.