ORACLE8i New Features

Transportable Tablespaces

Here comes another wonderful feature in the new release of Oracle 8.1.5.
Transportable tablespaces are a lot like cutting a piece of the database and pasting it
to another database. Well, you don't need to actually cut it, you can always make a
copy of the part of the database and add it to another database.

Introduction and Performing violation checks

The concept is to just copy the datafiles and move the dictionary information to the
new server. Since you are exporting only the data dictionary information, the time
required to move data between databases is much faster than using the regular
import/export. Remember to connect as sys or sysdba while exporting or importing
the data dictionary information.

The granularity, at which we can move pieces of a database, using this concept, is a
tablespace. You can move as many tablespaces as you want in one shot. But the
tablespaces must meet certain criteria.

The tablespaces must be self-contained, meaning all the objects in the

tablespace must be contained wholly in the tablespace
The source and the target database must be on the same platform, you can
move between sun & sun but not sun & NT.
The source and target must have same database block size.
The same tablespace name should not already be in use, by the target
database.

You can check whether a tablespace is self-contained or not through a PL/SQL

package DBMS_TTS. To check whether tablespaces TSP1 and TSP2 are in violation
execute

DBMS_TTS.TRANSPORT_SET_CHECK('TSP1,TSP2', TRUE);

where TSP1, TSP2 are the tablespace names and TRUE specifies that the oracle
server also take the constraints, foreign keys etc., into consideration. If it is FALSE
the procedure does not bother about the constraints, and raises an error whenever
you refer these objects in the destination database.

Now query the view TRANSPORT_SET_VIOLATIONS. This view lists all the objects
and tablespace which is not self-contained. If there is no such tablespace, this view
will be empty.

Export Tablespace Data Dictionary Info

Set the tablespaces to READ ONLY by issuing the following commands.

OracleSource.net 2003 All Rights Reserved

alter tablespace tsp1 read only;
alter tablespace tsp2 read only;

Now export the tablespaces using the export utility that is provided with the oracle
server. This exports only metadata info pertaining to the tablespaces. Other options
like Triggers=y, Grants=y and constraints=y can be used to copy the respective
objects.

exp TRANSPORT_TABLESPACE=y TABLESPACES=tsp1,tsp2 FILE=export.dmp

set the tablespaces on the source database back to read write after the export.

alter tablespace tsp1 read write;

alter tablespace tsp2 read write;

Copy Files to New Location and Import Data Dictionary

Copy the export.dmp and the data files for these tablespaces into the destination
server using any OS utility. On the destination database invoke the import utility to
add the tablespaces to the new database. Once the files have been added, set the
tablespaces to read write.

imp TRANSPORT_TABLESPACE=y DATAFILES='/d01/t1.dbf','/d01/t2.dbf'

TABLESPACES=tsp1,tsp2 FILE=export.dmp

alter tablespace tsp1 read write;

alter tablespace tsp2 read write;

If you want to change the ownership of the the objects, you can mention TOUSER
and FROMUSER options. If you don't specify these options, imp tries to create the
objects under the same user from the source database. If the user doesn't exists on
the destination database, import will fail.

Function Basesd Indexes

One of the many new features in Oracle 8i is the Function-Based Index (we will
refrain from using FBI, but only just). This allows the DBA to create indexes on
functions or expressions; these functions can be user generated pl/sql functions,
standard SQL functions (non-aggregate only) or even a C callout.

A classic problem the DBA faces in SQL Tuning is how to tune those queries that use
function calls in the where clause, and result in indexes created on these columns
not to be used.

Example

Standard B-Tree index on SURNAME with cost based optimizer

create index non_fbi on sale_contacts (surname);

analyze index non_fbi compute statistics;

OracleSource.net 2003 All Rights Reserved

analyze table sale_contacts compute statistics;
SELECT count(*) FROM sale_contacts
WHERE UPPER(surname) = 'ELLISON';

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1 Bytes=17)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF 'SALES_CONTACTS' (Cost=3 Card=16 Bytes=272)

Now we use a function based index

create index fbi on sale_contacts (UPPER(surname));

analyze index fbi compute statistics;
analyze table sale_contacts compute statistics;
SELECT count(*) FROM sale_contacts WHERE UPPER(surname) = 'ELLISON';

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=17)
1 0 SORT (AGGREGATE)
2 1 INDEX (RANGE SCAN) OF 'FBI' (NON-UNIQUE) (Cost=2 Card=381 Bytes=6477)

The function-based index has forced the optimizer to use index range scans
(retuning zero or more rowids) on the surname column rather than doing a full table
scan (non-index lookup). Optimal performance does vary depending on table size,
uniqueness and selectivity of columns, use of fast full table scans etc. Therefore try
both methods to gain optimal performance in your database.

It is important to remember that the function-based B*Tree index does not store the
expression results in the index but uses an "expression tree". The optimizer performs
expression matching by parsing the expression used in the SQL statement and
comparing the results against the expression-tree values in the function-based
index. This comparison IS case sensitive (ignores spaces) and therefore your
function-based index expressions should match expressions used in the SQL
statement where clauses.

Init.ora Parameters

The following parameter must be set in your parameter file:

QUERY_REWRITE_INTEGRITY = TRUSTED
QUERY_REWRITE_ENABLED = TRUE
COMPATIBLE = 8.1.0.0.0 (or higher)

Grants

Grants To create function-based indexes the user must be granted CREATE INDEX
and QUERY REWRITE, or alternatively be granted CREATE ANY INDEX and GLOBAL
QUERY REWRITE. The index owner must have EXECUTE access on the function used
for the index. If execute access is revoked then the function-based index will be
"disabled" (see dba_indexes).

Disabled Indexes

OracleSource.net 2003 All Rights Reserved

If your function-based index has a status of "disabled" the DBA can do one of the
following:
a) drop and create the index (take note of its current settings)
b) alter index enable, function-based indexes only, also use disable keyword as
required
c) alter index unusable.

Queries on a DISABLED index fail if the optimizer chooses to use the index.Here is an
example ORA error:
ERROR at line 1: ORA-30554: function-based index MYUSER.FBI is disabled.

All DML operations on a DISABLED index also fail unless the index is also marked
UNUSABLE and the initialization parameter SKIP_UNUSABLE_INDEXES is set to true.

Some more Examples

CREATE INDEX expression_ndx

ON mytable ((mycola + mycolc) * mycolb);

SELECT mycolc FROM mytable

WHERE (mycola + mycolc) * mycolb <= 256;

..or a composite index..

CREATE INDEX example_ndx

ON myexample (mycola, UPPER(mycolb), mycolc);

SELECT mycolc FROM myexample

WHERE mycola = 55 AND UPPER(mycolb) = 'JONES';

Restriction & Rule Summary

The following restrictions apply to function based indexes. You may not index:
a) LOB columns
b) REF
c) Nested table column
d) Objects types with any of the above data types.

Function-based indexes must always follow these rules:

a) Cost Based optimizer only, must generate statistics after the index is created
b) Can not store NULL values (function can not return NULL under any circumstance)
c) If a user defined pl/sql routine is used for the function-based index, and is
invalidated, the index will become "disabled"
d) Functions must be deterministic (always return the same value for a known input)
e) The index owner must have "execute" access on function used in the function-
based index. Revocation of the privilege will render the index "disabled"
f) May have a B-Tree and Bitmap index type only
g) Can not use expressions that are based on aggregate functions, ie. SUM, AVG etc.
h) To alter a function-based index as enabled, the function used must be valid,
deterministic and the signature of the function matches the signature of the function
when it was created.

OracleSource.net 2003 All Rights Reserved

Index Organized Table

When you create an index on a table, a separate storage area is allocated to store
the B-Tree Structure, another B-Tree object is created related to the table. In an
index-organized table the data for the table is held in its associated index.

Rather than having a row's rowid as the second element of the index entry, the
actual data row is stored in the B*-tree index. Changes to the table data, such as
adding new rows, updating rows, or deleting rows, result only in updating the index.

How to create an Index Organized Table

You can use the CREATE TABLE statement, but you have to provide certain other
parameters.

CREATE TABLE emp_dept

(
EMP_ID number,
DEPT_ID number,
NAME varchar2(250),
ADDRESS varchar2(250),
CITY varchar2(250),
STATE char(2),
constraint PK_EXP_DEPT primary key (EMP_ID, DEPT_ID)
)
ORGANIZATION INDEX TABLESPACE index_tblspace;

The ORGANIZATION INDEX clause identifies the table as an IOT.

Differences Between IOT and Regular Tables

Regular Table IOT

Rowid is the Unique Identifier
Physical Rowid
Rowid Based Access
Unique Constraints allowed
Can be stored in a cluster
Can contain both LONG and LOB
Replication Supported
Primary key is the unique Identifier
Logical Rowid
Primary Key based access
Unique Constraints Not Allowed
Cannot be stored in a cluster
Can Contain LOBs but not LONG
Replication Not Supported

Benefits of IOT

1. Since you are not storing the index keys separately the space required is less.

2. Optimizer does not need to read two locations. The data can be found in one
structure.

3. Since the data is organized based on the primary key, applications that use
primary key to fetch the data performs well.

OracleSource.net 2003 All Rights Reserved

Locally Managed Tablespaces

Like any other object, the data dictionary manages space allocation to a tablespace.
That means Oracle updates the appropriate tables in the data dictionary whenever
an extent is allocated or freed for reuse. Oracle also stores rollback information
about each update of the dictionary tables. Because dictionary tables and rollback
segments are part of the database, the space that they occupy is subject to the
same space management operations as all other data. This method of space
management is called extent management by the data dictionary. These tablespaces
are also called as Dictionary managed tablespaces. This was the only option available
prior to release 8.1. In Oracle release 8.1 and above you have an option to manage
the space allocation called extent management by the tablespace

Locally Managed Tablespaces

A tablespace that can manage extent allocation by itself is called locally managed
tablespace. These tablespaces maintain a bitmap in each datafile to keep track of the
freed or used status of blocks in that datafile. Each bit in the bitmap corresponds to a
block or a group of blocks. When an extent is allocated or freed for reuse, Oracle
changes the bitmap values to show the new status of the blocks. These changes do
not generate rollback information because they do not update tables in the data
dictionary (except for special cases such as tablespace quota information).

Extent Allocation

Locally managed tablespaces can have uniform extent sizes or variable extent sizes
that are determined by the system. Any of the options, UNIFORM or AUTOALLOCATE
can be mentioned while creating the tablespace. For UNIFORM extents you can
specify an extent size. The default size is 1MB. For AUTOALLOCATE extents you can
specify the size of the initial extent and Oracle determines the optimal size of the
additional extents, with a minimum extent size of 64KB. That is why these are called
system-managed extents.

How Extents are Allocated

Oracle looks for free space to allocate to a new extent by first determining a
candidate datafile in the tablespace and then searching the datafile's bitmap for the
required number of adjacent free blocks. If that datafile does not have enough
adjacent free space, Oracle looks in another datafile. When extents are deallocated,
Oracle modifies the bitmap in the datafile.

Create A Locally Managed Tablespace

CREATE TABLESPACE tbs1

DATAFILE 'file1.dbf'
EXTENT MANAGEMENT LOCAL
UNIFORM SIZE 256K;

Advantages

OracleSource.net 2003 All Rights Reserved

1.Local management of extents avoids recursive space management operations,
which can occur in dictionary managed tablespaces.

2. Local management of extents automatically tracks adjacent free space,

eliminating the need to coalesce free extents.

3. Reliance on data dictionary is reduced.

Notes

1.Temporary tablespaces that manage their extents locally can only use UNIFORM
extent allocation.

2.For permanent tablespaces the default extent size for system managed extents is
64KB.

3. The storage parameters NEXT, PCTINCREASE, MINEXTENTS, MAXEXTENTS, and

DEFAULT STORAGE are not valid for locally managed tablespaces.

Materialized Views

This article deals with Materialized views and helps you realize the potential of Oracle
8i in Data Warehousing and DSS Solutions. These views work by pre-calculating the
aggregate operations and the optimizer will transparently rewrite the query to use
these views.

Introduction

Materialized views are stored summaries of queries containing precomputed results.

Materialized views greatly improve data warehouse query processing.The existence
of a materialized view is transparent to SQL applications, so a DBA can create or
drop materialized views at any time without affecting the validity of SQL applications.

Materialized views improve query performance by precalculating expensive join and

aggregation operations on the database prior to execution time and storing these
results in the database. The query optimizer can make use of materialized views by
automatically recognizing when an existing materialized view can and should be used
to satisfy a request. It then transparently rewrites the request to use the
materialized view. Queries are then directed to the materialized view and not to the
underlying detail tables or views. Rewriting queries to use materialized views rather
than detail relations results in a significant performance gain.

Materialized views can be refreshed automatically whenever the data is changed in

the underlying tables. The refresh method can be incremental (fast refresh) or
complete. Incremental method re-populates only the changed data. Complete
method truncates and rebuilds the view. The refresh process can be enabled by
adding the REFRESH clause while creating the materialized view. You can suppress
the refresh process for the entire life of the view.

Example 1 :

OracleSource.net 2003 All Rights Reserved

The following statement creates and populates a materialized view
SALES_BY_MONTH_BY_STATE. The materialized view will be populated with data as
soon as the statement executes successfully, and subsequent refreshes will be
accomplished by reexecuting the materialized view's query.

CREATE MATERIALIZED VIEW sales_by_month_by_state

TABLESPACE my_ts
PARALLEL (10)
ENABLE QUERY REWRITE
BUILD IMMEDIATE
REFRESH COMPLETE AS
SELECT t.month, g.state, SUM(sales) AS sum_sales
FROM fact f, time t, geog g
WHERE f.cur_date = t.cur_date
AND f.city_id = g.city_id
GROUP BY month, state;

The fact table stores the actual data about the sales by month and state, time table
has the day,month, year dimenstions and geog stores the state names. This view is
built and populated with data immediately.

Lets asssume that you asked oracle to calculate the same values in a query and if
query_rewrite is allowed on your server, the optimizer will automatically use the
values in the above precomputed view.

NOTES:

1. Set QUERY_REWRITE_ENABLE=TRUE in init.ora

2. Set JOB_QUEUE_PROCESSES=1 ( 1 or more based on your requirements).

RESTRICTIONS:

1. Materialized views consume storage space. Be aware to provide storage

parameters according to the data it holds.

2. There cannot be any set functions like UNION, MINUS in the underlying query for
materialized views.

Temporary Tables

Here is another feature I found interesting that was introduced in Oracle 8i.
Temporary tables, yep temporary tables. You may say, whats the big deal, I was
creating temporary tables from before, whats new now. These temporary tables have
a global definition. When a user inserts rows in a session, those rows are only visible
to that session and the rows are only available until the transaction or the session is
ended based on how the table has been defined. Confused....Read On...

Temporary Tables

OracleSource.net 2003 All Rights Reserved

Oracle 8i introduces a new concept called global temporary tables. This version only
provides global temporary tables and local tables are expected in the future. These
are like normal tables but the segment is created only when the data is inserted and
hence temporary in nature.

create global temporary table dbatest

( c1 number, c2 number);

The above statement creates a table whose definition is visible to all the sessions but
the data is visible to only the session that has created it. Temporary tables can be
used by developers to store session / transaction specific data that can be discarded
as soon as the session/transaction ends. When a truncate is issued on this table,
only data related to that particular session is truncated.

The above code creates a table named dbatest. When data is inserted into this table
the data persists either at the session or transaction level based on how "On
Commit" parameter is specified. On commit can be specified as "delete rows" or
"preserve rows". Delete Rows seems to be the default.

Create global temporary table dbatest

(
c1 number,
c2 number
) on commit delete rows;

In the above table, as soon as the user ends the transaction by issuing a commit
statement, the data in the temporary table is deleted ( truncated ).

Create global temporary table dbatest

(
c1 number,
c2 number
) on commit preserve rows;

The above statement causes the creation of a table that will keep its rows even after
the transaction is committed. If the user inserts rows into the above table and then
commits the data, the data that was inserted will exist until the session is ended.

Restrictions

Temporary tables cannot contain nested tables or varray types or they cannot be
partitioned, index-organized or clustered. They cannot be used in parallel DML or
parallel queries and distributed transactions are not supported on these tables.

OracleSource.net 2003 All Rights Reserved