1 – CACHE
NOTE
You cannot issue CREATE CACHE as an independent statement.
It is a clause allowed only as part of a CREATE DATABASE or
IMPORT statement.
You can also create a row cache using the ADD CACHE clause
of the ALTER DATABASE statement.
Creates a row cache that allows frequently referenced rows
to remain in memory even when the associated page has been
transferred back to disk. This saves in memory usage because
only the more recently referenced rows are cached versus caching
the entire buffer.
See the ALTER DATABASE statement and the CREATE DATABASE
statement for more information regarding the row cache areas.
1.1 – Environment
You can use the CREATE CACHE clause only within a CREATE DATABASE
or IMPORT statement. You can use the ADD CACHE clause only within
the ALTER DATABASE statement.
1.2 – Format
CREATE CACHE <row-cache-name> -+-+----------------------+-+->
| +-> row-cache-params1 -+ |
| +-> row-cache-params2 -+ |
+------------ <------------+
add-row-cache-clause =
---> ADD CACHE <row-cache-name> -+-+----------------------+-+->
| +-> row-cache-params1 -+ |
| +-> row-cache-params2 -+ |
+-------------<------------+
row-cache-params1 =
--+-> ALLOCATION IS <n> -+--+-----------+----------------+->
+-> EXTENT IS <n> -----+ +-> BLOCK --+ |
| +-> BLOCKS -+ |
+-> CACHE SIZE IS <n> -+----> ROW --+------------------+
| +----> ROWS -+ |
+-> CHECKPOINT -+> UPDATED ROWS TO -+> BACKING FILE -+-+
| | +> DATABASE -----+ |
| +> ALL ROWS TO BACKING FILE ---------+ |
+-> LARGE MEMORY IS ----+-+-> ENABLED --+--------------+
+-> ROW REPLACEMENT IS -+ +-> DISABLED -+ |
+-> LOCATION IS --> <directory-spec> ------------------+
+-> NO LOCATION ---------------------------------------+
row-cache-params2 =
--+-> NUMBER OF -+-> RESERVED -+-> ROWS IS <n> --------------+->
| +-> SWEEP ----+ |
+-> ROW LENGTH IS <n> -+-------------+---------------------+
| +----> BYTE --+ |
| +----> BYTES -+ |
| |
+-> ROW SNAPSHOT IS --+-> ENABLED rs-opt -+---------------+
| +-> DISABLED --------+ |
| |
+-> SHARED MEMORY IS --+----> SYSTEM -------------------+--+
+----> PROCESS --+-------------+-+
| |
+-> RESIDENT -+
rs-opt =
--+-------------------------------+--->
+-> (CACHE SIZE IS <n> ROWS) ---+
1.3 – Arguments
1.3.1 – ALLOCATION
Syntax options:
ALLOCATION IS n BLOCK | ALLOCATION IS n BLOCKS
Specifies the initial allocation of the row cache file (.rdc) to
which cached rows are written.
If the ALLOCATION clause is not specified, the default allocation
in blocks is approximately 40 percent of the CACHE SIZE for this
cache.
This clause is ignored if the row cache is defined to checkpoint
to the database.
1.3.2 – CACHE
Creates a row cache.
1.3.3 – CACHE_SIZE
Syntax options:
CACHE SIZE IS n ROW | CACHE SIZE IS n ROWS
Specifies the number of rows allocated to the row cache. As the
row cache fills, rows more recently referenced are retained in
the row cache while those not referenced recently are discarded.
Adjusting the allocation of the row cache helps to retain
important rows in memory. If not specified, the default is 1000
rows.
1.3.4 – CHECKPOINT
Syntax options:
CHECKPOINT ALL ROWS TO BACKING FILE
CHECKPOINT UPDATED ROWS TO BACKING FILE
CHECKPOINT UPDATED ROWS TO DATABASE
Specifies the source records and target for checkpoint operations
for the row cache. If ALL ROWS is specified, then the records
written during each checkpoint operation are both the modified
and the unmodified rows in the row cache. If UPDATED ROWS is
specified, then just the modified rows in the row cache are
checkpointed each time.
If the target of the checkpoint operation is BACKING FILE, then
the row cache server (RCS) process writes the row cache entries
to the backing (.rdc) files. The row cache LOCATION, ALLOCATION,
and EXTENT clauses are used to create the backing files. Upon
recovery from a node failure, the database recovery process is
able to repopulate the row caches in memory from the rows found
in the backing files.
If the target is DATABASE, then the updated rows (only UPDATED
ROWS is allowed) are written back to the database. The row
cache LOCATION, ALLOCATION, and EXTENT clauses are ignored. Upon
recovery from a node failure, the database recovery process has
no data on the contents of the row cache. Therefore, it does not
repopulate the row caches in memory.
This CHECKPOINT clause overrides the database-level CHECKPOINT
clause.
1.3.5 – EXTENT
Syntax options:
EXTENT IS n BLOCK | EXTENT IS n BLOCKS
Specifies the file extent size for the row cache file (.rdc).
If the EXTENT clause is not specified, the default number of
blocks is CACHE SIZE * 127 for this cache.
This clause is ignored if the row cache is defined to checkpoint
to the database.
1.3.6 – LOCATION
Syntax options:
LOCATION IS directory-spec
Specifies the name of the directory to which row cache
information is written. The database system generates a file
name (row-cache-name.rdc) automatically for each row cache at
checkpoint time. Specify a device name and directory name only,
enclosed within single quotation marks. By default, the location
is the directory of the database root file. These .rdc files are
permanent database files.
This LOCATION clause overrides a previously specified location at
the database level.
This clause is ignored if the row cache is defined to checkpoint
to the database.
1.3.7 – NO_LOCATION
Removes the location previously specified in a LOCATION IS clause
for the row cache. If you specify NO LOCATION, the row cache
location becomes the directory of the database root file.
This clause is ignored if the row cache is defined to checkpoint
to the database.
1.3.8 – NUMBER_OF_RESERVED_ROWS
Syntax options:
NUMBER OF RESERVED ROWS IS n
Specifies the maximum number of cache rows that each user can
reserve for insertion into the cache. Processes reserve, or
allocate, entries in a cache to be used when inserting rows into
the cache. To improve efficiency, multiple entries are reserved
at one once. Once a user's reserved list becomes depleted, Oracle
Rdb attempts to reserve another group of entries. The default is
20 rows.
This value is also used when searching for available slots in a
row cache. The entire row cache is not searched on the initial
pass. This value specifies the maximum number of rows that are
searched for a free slot. If at least one free slot is found, the
insert operation can proceed. If no free slots are found in this
initial search, Oracle Rdb continues searching through the cache
until it finds a free slot.
1.3.9 – NUMBER_OF_SWEEP_ROWS
Syntax options:
NUMBER OF SWEEP ROWS IS n
Specifies the number of modified rows that will be written from
the row cache back to the database by the row cache server (RCS)
process during a sweep operation. When the RCS is notified that
a cache is "full" of modified data, the RCS starts a sweep to
make space available in the cache for subsequent transactions
to be able to insert rows into the cache. Oracle Corporation
recommends that you initially specify the number of sweep rows
to be approximately 5 percent of the total number of rows in
the cache. Then monitor performance and adjust the number of
sweep rows, if necessary. Allowable values must be in the range 2
through 524288. If not specified, the default is 3,000 rows.
1.3.10 – ROW_LENGTH
Syntax options:
ROW LENGTH IS n BYTES
Specifies the length of each row allocated to the row cache. Rows
are not cached if they are too large for the row cache. area. The
ROW LENGTH is an aligned longword rounded up to the next multiple
of 4 bytes.
The maximum row length in a row cache is 65535 bytes.
When the name of the cache matches the name of an existing
logical area, ADD CACHE will calculate ROW LENGTH from the size
of the table row, or the size of the index node (for SORTED
RANKED, or UNIQUE SORTED indices). This cache is known as a
logical area cache.
1.3.11 – ROW_REPLACEMENT
Syntax options:
ROW REPLACEMENT IS ENABLED | ROW REPLACEMENT IS DISABLED
Specifies whether or not Oracle Rdb replaces rows in the cache.
When ROW REPLACEMENT IS ENABLED, rows are replaced when the
row cache becomes full. When ROW REPLACEMENT IS DISABLED, rows
are not replaced when the row cache is full. The type of row
replacement policy depends upon the application requirements for
each cache.
The default is ENABLED.
1.3.12 – ROW_SNAPSHOT_IS_DISABLED
Disables storing snapshot copies of rows within the cache.
1.3.13 – ROW_SNAPSHOT_IS_ENABLED
The ROW SNAPSHOT IS ENABLED (CACHE SIZE IS n ROWS) option enables
storage of snapshot copies of rows within the cache and specifies
the number of snapshot "slots" to allocate for the cache.
The default for new caches, and existing caches is to have this
feature disabled.
If you do not specify the CACHE SIZE clause for the ROW SNAPSHOT
IS ENABLED option, Oracle Rdb creates a cache that can contain up
to 1000 snapshot rows.
1.3.14 – SHARED_MEMORY
Syntax options:
SHARED MEMORY IS SYSTEM | SHARED MEMORY IS PROCESS
Determines whether cache global sections are created in system
space or process space. The default is SHARED MEMORY IS PROCESS.
When you use cache global sections created in the process
space, you and other users share physical memory and the OpenVMS
operating system maps a row cache to a private address space for
each user. As a result, all users are limited by the free virtual
address range and each use a percentage of memory in overhead. If
many users are accessing the database, the overhead can be high.
When many users are accessing the database, consider using the
SHARED MEMORY IS SYSTEM clause. This gives users more physical
memory because they share the system space of memory and there is
none of the overhead associated with the process space of memory.
1.3.15 – SHARED_MEMORY_IS_PROCESS_RESIDENT
The SHARED MEMORY clause determines whether database root global
sections (including global buffers when enabled) or whether the
cache global sections are created in system space or process
space. The RESIDENT option extends the PROCESS option by making
the global section memory resident.
1.4 – Examples
Example 1: Creating a row cache
This example creates a database, creates a row cache, and assigns
the row cache to a storage area.
SQL> CREATE DATABASE FILENAME test_db
cont> ROW CACHE IS ENABLED
cont> CREATE CACHE test1
cont> CACHE SIZE IS 100 ROWS
cont> CREATE STORAGE AREA area1
cont> CACHE USING test1;
SQL> SHOW CACHE
Cache Objects in database with filename test_db
TEST1
SQL> SHOW CACHE test1
TEST1
Cache Size: 100 rows
Row Length: 256 bytes
Row Replacement: Enabled
Shared Memory: Process
Large Memory: Disabled
Window Count: 100
Reserved Rows: 20
Sweep Rows: 3000
No Sweep Thresholds
Allocation: 100 blocks
Extent: 100 blocks
SQL> SHOW STORAGE AREA area1
AREA1
Access is: Read write
Page Format: Uniform
Page Size: 2 blocks
Area File: SQL_USER1:[DAY.V70]AREA1.RDA;1
Area Allocation: 402 pages
Area Extent Minimum: 99 pages
Area Extent Maximum: 9999 pages
Area Extent Percent: 20 percent
Snapshot File: SQL_USER1:[DAY.V70]AREA1.SNP;1
Snapshot Allocation: 100 pages
Snapshot Extent Minimum: 99 pages
Snapshot Extent Maximum: 9999 pages
Snapshot Extent Percent: 20 percent
Extent : Enabled
Locking is Row Level
Using Cache TEST1
No database objects use Storage Area AREA1
Example 2: Creating and modifying various caches
1 The cache named CUSTOMER_STATUS is created with a row length
of 577 bytes with 88000 cache "slots" for storage of live
database rows and 7000 slots for storage of snapshot copies of
rows. This cache is also configured to be memory- resident.
2 The cache named MACHINE_FLOW_IDX_1 is created with a row
length of 430 bytes with 5000 cache slots for storage of live
database rows and 12000 slots for storage of snapshot copies
of rows. This cache is set to disallow replacement of rows in
the cache.
3 The cache named SALES_CALLS is created with a row length of
160 bytes with 3000 cache "slots" for storage of live database
rows and, using the default because an explicit count was not
specified, 1000 slots for storage of snapshot copies of rows.
4 The cache named CUSTOMER_ORDER does not specify "ROW SNAPSHOT
IS ENABLED" so no snapshot row copies will be stored in this
cache.
5 The cache named "SALES" is modified to disable storage of
snapshot rows in cache.
6 The cache named "CLEARING" is modified to enable storage
of snapshot rows in the cache with a snapshot cache size of
12,345 rows.
SQL> ALTER DATABASE FILENAME HDB_DB
1 ADD CACHE CUSTOMER_STATUS
ROW LENGTH IS 577 BYTES
CACHE SIZE IS 88000 ROWS
ROW SNAPSHOT IS ENABLED (CACHE SIZE IS 7000 ROWS)
SHARED MEMORY IS PROCESS RESIDENT
2 ADD CACHE MACHINE_FLOW_IDX_1
ROW LENGTH IS 430 BYTES
CACHE SIZE IS 5000 ROWS
ROW REPLACEMENT IS DISABLED
ROW SNAPSHOT IS ENABLED (CACHE SIZE IS 12000 ROWS)
3 ADD CACHE SALES_CALLS
ROW LENGTH IS 160 BYTES
CACHE SIZE IS 3000 ROWS
ROW SNAPSHOT IS ENABLED
4 ADD CACHE CUSTOMER_ORDER
ROW LENGTH IS 760 BYTES
CACHE SIZE IS 9000 ROWS
CHECKPOINT UPDATED ROWS TO DATABASE
5 ALTER CACHE SALES
ROW SNAPSHOT IS DISABLED
6 ALTER CACHE CLEARING
ROW SNAPSHOT IS ENABLED (CACHE SIZE IS 12345 ROWS);
SQL> SHOW CACHE CUSTOMER_STATUS
CUSTOMER_STATUS
Cache Size: 88000 rows
Row Length: 580 bytes
Row Replacement: Enabled
Shared Memory: Process Resident
Large Memory: Disabled
Window Count: 100
Working Set Count: 10
Reserved Rows: 20
Allocation: 100 blocks
Extent: 100 blocks
Snapshot in Cache: Enabled
Snapshot Cache Size: 7000 rows
SQL> SHOW CACHE MACHINE_FLOW_IDX_1
MACHINE_FLOW_IDX_1
Cache Size: 5000 rows
Row Length: 432 bytes
Row Replacement: Disabled
Shared Memory: Process
Large Memory: Disabled
Window Count: 100
Working Set Count: 10
Reserved Rows: 20
Allocation: 100 blocks
Extent: 100 blocks
Snapshot in Cache: Enabled
Snapshot Cache Size: 12000 rows
SQL> SHOW CACHE SALES_CALLS
SALES_CALLS
Cache Size: 3000 rows
Row Length: 160 bytes
Row Replacement: Enabled
Shared Memory: Process
Large Memory: Disabled
Window Count: 100
Working Set Count: 10
Reserved Rows: 20
Allocation: 100 blocks
Extent: 100 blocks
Snapshot in Cache: Enabled
Snapshot Cache Size: 1000 rows
SQL> SHOW CACHE CUSTOMER_ORDER
CUSTOMER_ORDER
Cache Size: 9000 rows
Row Length: 760 bytes
Row Replacement: Enabled
Shared Memory: Process
Large Memory: Disabled
Window Count: 100
Working Set Count: 10
Reserved Rows: 20
Allocation: 100 blocks
Extent: 100 blocks
Row cache: checkpoint updated rows to database
2 – CATALOG
Creates a name for a group of schemas in a multischema database.
2.1 – Environment
You can use the CREATE CATALOG statement:
o In interactive SQL
o Embedded in host language programs to be precompiled
o As part of a procedure in an SQL module
o In dynamic SQL as a statement to be dynamically executed
2.2 – Format
CREATE CATALOG --> <catalog-name> -+
+---------------------------------+
+-+-------------------------------+->
+---> create-schema-statement -++
+-+-> schema-element -+--------+
+---------<---------+
catalog-name =
-+------> <name-of-catalog> --------------+->
| |
+-> " -> <alias>.<name-of-catalog> ->" -+
schema-element =
-+-> create-collating-sequence-statement -+->
+-> create-domain-statement -------------+
+-> create-index-statement --------------+
+-> create-sequence-statement -----------+
+-> create-storage-map-statement --------+
+-> create-table-statement --------------+
+-> create-trigger-statement ------------+
+-> create-view-statement ---------------+
+-> grant-statement ---------------------+
2.3 – Arguments
2.3.1 – alias.name-of-catalog
Specifies an optional name for the attach to the database. Always
qualify the catalog name with an alias if your program or your
interactive SQL statements refer to more than one database.
Separate the name of the catalog from the alias with a period,
and enclose the qualified name within double quotation marks.
2.3.2 – catalog-name
The name of the catalog definition you want to create. Use any
valid SQL name that is unique among all catalog names in the
database. For more information on catalog names, see the User_
Supplied_Names HELP topic.
2.3.3 – create-schema-statement
For more information, see the CREATE SCHEMA statement.
2.3.4 – schema-element
One or more CREATE statements or a GRANT statement. For more
information, see the CREATE SCHEMA statement.
2.4 – Examples
Example 1: Creating a catalog for a database using an alias
This example shows how an interactive user could attach to the
sample database called personnel and create a catalog in that
database. (You must use the personnel sample database created
with the multischema attribute for this example.) Using an
alias, the user distinguishes the personnel database from other
databases that may be attached later in the same session.
SQL> ATTACH 'ALIAS CORPORATE FILENAME personnel -
cont> MULTISCHEMA IS ON';
SQL> --
SQL> -- SQL creates a default catalog called RDB$CATALOG in
SQL> -- each multischema database.
SQL> --
SQL> SHOW CATALOG;
Catalogs in database personnel
"CORPORATE.RDB$CATALOG"
SQL> --
SQL> -- The SET QUOTING RULES 'SQL99' statement allows the use of
SQL> -- double quotation marks, which SQL requires when you
SQL> -- qualify a catalog name with an alias.
SQL> --
SQL> SET QUOTING RULES 'SQL99';
SQL> CREATE CATALOG "CORPORATE.MARKETING";
SQL> --
SQL> SHOW CATALOG;
Catalogs in database personnel
"CORPORATE.MARKETING"
"CORPORATE.RDB$CATALOG"
Example 2: Creating a catalog in the database with the default
alias
This example shows a CREATE CATALOG clause used in an interactive
CREATE DATABASE statement. In this example, the user creates a
database without specifying an alias. Because the user is not
attached to any other databases, the new database becomes the
default alias.
SQL> CREATE DATABASE FILENAME inventory
cont> MULTISCHEMA IS ON
cont> CREATE CATALOG PARTS
cont> CREATE SCHEMA PRINTERS AUTHORIZATION DAVIS
cont> CREATE TABLE LASER EXTERNAL NAME IS DEPT_2_LASER
cont> (SERIAL_NO INT, LOCATION CHAR)
cont> CREATE SCHEMA TERMINALS AUTHORIZATION DAVIS
cont> CREATE TABLE TERM100 EXTERNAL NAME IS DEPT_2_TERM100
cont> (SERIAL_NO INT, LOCATION CHAR);
SQL> SHOW CATALOG;
Catalogs in database with filename inventory
PARTS
RDB$CATALOG
SQL> show schemas;
Schemas in database with filename inventory
PARTS.PRINTERS
PARTS.TERMINALS
RDB$SCHEMA
3 – COLLATING_SEQUENCE
Identifies a collating sequence that has been defined using the
OpenVMS National Character Set (NCS) utility. Use the CREATE
COLLATING SEQUENCE statement to identify collating sequences
other than the database default collating sequence that you plan
to use with certain domains. (The default collating sequence for
a database is established by the COLLATING SEQUENCE IS clause in
the CREATE SCHEMA statement; if you omit that clause at database
definition time, the default sequence is ASCII.)
You must enter a CREATE COLLATING SEQUENCE statement specifying a
collating sequence before you enter the name of that sequence in
any of the following statements:
o CREATE DOMAIN . . . COLLATING SEQUENCE
o DROP COLLATING SEQUENCE
o ALTER DOMAIN . . . COLLATING SEQUENCE
o SHOW COLLATING SEQUENCE
3.1 – Environment
You can use the CREATE COLLATING SEQUENCE statement:
o In interactive SQL
o Embedded in host language programs to be precompiled
o As part of a procedure in an SQL module
o In dynamic SQL as a statement to be dynamically executed
3.2 – Format
CREATE COLLATING SEQUENCE <sequence-name> --+
+-----------------------------------------+
+--+-------------------------------------+--+
+-> STORED NAME IS <stored-name> -----+ |
+-------------------------------------------+
+--+-----------------------------------+-+
+-> COMMENT IS --+-> '<string>' --+-+ |
+------ / <------+ |
+----------------------------------------+
+----> <ncs-name> +-----------------------+->
+-> FROM <library-name> +
3.3 – Arguments
3.3.1 – COMMENT_IS
Adds a comment about the collating sequence. SQL displays the
text when it executes a SHOW COLLATING SEQUENCE statement in
interactive SQL. Enclose the comment within single quotation
marks (') and separate multiple lines in a comment with a slash
mark (/).
3.3.2 – FROM library name
Specifies the name of an NCS library other than the default. The
default NCS library is SYS$LIBRARY:NCS$LIBRARY.
3.3.3 – ncs-name
Specifies the name of a collating sequence in the default NCS
library, SYS$LIBRARY:NCS$LIBRARY, or in the NCS library specified
by the library-name argument.
The collating sequence can be either one of the predefined NCS
collating sequences or one that you defined yourself using NCS.
3.3.4 – sequence-name
Specifies the name by which the collating sequence named in
the ncs-name argument is known to the schema. The ncs-name and
sequence-name arguments can be the same.
3.3.5 – STORED_NAME_IS
Specifies a name that Oracle Rdb uses to access a collating
sequence created in a multischema database. The stored name
allows you to access multischema definitions using interfaces,
such as Oracle RMU, the Oracle Rdb management utility, that
do not recognize multiple schemas in one database. You cannot
specify a stored name for a collating sequence in a database that
does not allow multiple schemas.
3.4 – Example
Example 1: Creating a French collating sequence
The following example creates a collating sequence using
the predefined collating sequence FRENCH. It then shows the
defined collating sequence by using the SHOW COLLATING SEQUENCE
statement.
SQL> CREATE COLLATING SEQUENCE FRENCH FRENCH;
SQL> --
SQL> SHOW COLLATING SEQUENCE
User collating sequences in schema with filename SQL$DATABASE
FRENCH
Example 2: Create a Spanish collating sequence specifying more
than one comment
SQL> CREATE COLLATING SEQUENCE SPANISH_COL
cont> COMMENT IS 'first comment' / 'second comment'
cont> SPANISH;
SQL> SHOW COLLATING SEQUENCE SPANISH_COL;
SPANISH_COL
Comment: first comment
second comment
4 – DATABASE
Creates database system files, metadata definitions, and user
data that comprise a database. The CREATE DATABASE statement
lets you specify in a single SQL statement all data and privilege
definitions for a new database. (You can also add definitions to
the database later.) For information about ways to ensure good
performance and data consistency, see the Oracle Rdb7 Guide to
Database Performance and Tuning.
The many optional elements of the CREATE DATABASE statement
make it very flexible. In its simplest form, the CREATE DATABASE
statement creates database system files, specifies their names,
and determines the physical characteristics of the database.
Using the optional elements of the CREATE DATABASE statement, you
can also specify:
o Whether the database created with CREATE DATABASE is multifile
(separate database root file and storage area data file) or
single file (combined database root file and storage area
data file). Multifile databases can have many storage areas
for user data, all separate from the database root file
created by the CREATE DATABASE statement. Multifile databases
include CREATE STORAGE AREA clauses in the CREATE DATABASE
statement to create multiple storage area files for enhanced
performance.
The presence or absence of a CREATE STORAGE AREA clause in
a CREATE DATABASE statement determines whether the database
is single file or multifile. To create a multifile database,
you must include a CREATE STORAGE AREA clause in the CREATE
DATABASE statement. To create a single-file database, do not
include a CREATE STORAGE AREA clause in the CREATE DATABASE
statement.
o Values for various database root file parameters that override
the system defaults. Database root file (.rdb) parameters
describe characteristics of the database root file. Database
root file parameters affect the entire database, whether it is
a single-file or a multifile database.
o Values for storage area parameters that override system
defaults. Storage area parameters describe characteristics of
the database storage area files. In a single-file database,
because the storage area data file is combined with the
database root file, storage area parameters apply to a single
storage area and affect the entire database. In a multifile
database, storage area parameters specify defaults for the
main storage area, RDB$SYSTEM, and for any subsequent CREATE
STORAGE AREA clauses within the CREATE DATABASE statement.
o Any number of database elements. Database elements are a
CREATE CATALOG statement, a CREATE STORAGE AREA clause, or
a GRANT statement. The CREATE DATABASE statements that create
single-file databases cannot include a CREATE STORAGE AREA
clause because this is specific to multifile databases. The
CREATE DATABASE statements that create multifile databases
must include at least one CREATE STORAGE AREA clause.
Unlike the same statements outside a CREATE DATABASE
statement, database elements do not use statement terminators.
The first statement terminator that SQL encounters ends the
CREATE DATABASE statement. Later CREATE or GRANT statements
are not within the scope of the CREATE DATABASE statement.
o The database default character set and national character set.
For information regarding identifier character sets, database
default character sets, and national character sets, see the
Character_Sets HELP topic.
4.1 – Environment
You can use the CREATE DATABASE statement:
o In interactive SQL
o Embedded in host language programs to be precompiled
o As part of a procedure in an SQL module
o In dynamic SQL as a statement to be dynamically executed
4.2 – Format
CREATE DATABASE -+------------------++
+-> ALIAS <alias> -+|
+------------ <-----------------------+
++-----------------------------++------------------------------+-+
+++-> root-file-params-1 ---++++++-> storage-area-params-1 -+++ |
|+-> root-file-params-2 ---+| |+-> storage-area-params-2 -+| |
|+-> root-file-params-3 ---+| +-------------- <------------+ |
|+-> root-file-params-4 ---+| |
+----------- <--------------+ |
+-------------------------- <------------------------------------+
++--------------------+--+-----------------------+--------->
+-> character-sets --+ ++-> database-element -++
+-------- <-----------+
root-file-params-1 =
-+-> FILENAME <db-attach-spec> -++----------------------++->
+-> PATHNAME <path-name> ----++-> literal-user-auth -+|
+-> attach-options -------------------------------------+
+-> COLLATING SEQUENCE <collation-name> -----+ |
| +-------------------<---------------------+ |
| ++-----------------------------------+----+ |
| +-> COMMENT IS ---+-> '<string>' --++ | |
| +------- / <-----+ | |
| +-------------------<---------------------+ |
| +--> <ncs-name> -+-----------------------+-----------+
| +-> FROM <library-name> + |
+-> NUMBER OF USERS -------> <number-users> ------------+
+-> NUMBER OF BUFFERS -----> <number-buffers> ----------+
+-> NUMBER OF CLUSTER NODES ----> <number-nodes> --+ |
| +--------------------------------------------+ |
| ++----------------------------------------+-------+
| +> ( -+-> SINGLE ---+-> INSTANCE --> ) --+ |
| +-> MULTIPLE -+ |
+-> NUMBER OF RECOVERY BUFFERS -> <number-buffers> -----+
+-> BUFFER SIZE IS -> <buffer-blocks> --> BLOCKS -------+
db-attach-spec =
--+----------------+-> <file-spec> --->
+-> <node-spec> -+
node-spec =
-+-> <nodename> -+-------------------+-+->
| +-> <access-string> + |
+------------------ :: <--------------+
access-string =
-+-> " <user-name> <password> " --+->
+-> " <VMS-proxy-user-name> " ---+
literal-user-auth =
---> USER '<username>' -+------------------------+-->
+-> USING '<password>' -+
attach-options =
-+-> DBKEY -+-> SCOPE IS -+-> ATTACH -------+-----------------------+->
+-> ROWID -+ +-> TRANSACTION --+ |
+-> MULTISCHEMA IS -+-> ON --+-------------------------------------+
| +-> OFF -+ |
+-> PRESTARTED TRANSACTIONS ARE -+-> ON --+------------------------+
| +-> OFF -+ |
+-+-------+-> RESTRICTED ACCESS -----------------------------------+
+-> NO -+
root-file-params-2 =
-+-> global-buffer-params -----------------------------------------+->
+-> SNAPSHOT IS ----+-----> ENABLED -+-> IMMEDIATE +-+-----------+
| | +-> DEFERRED -+ | |
| +-----> DISABLED -----------------+ |
+-> DICTIONARY IS ---+---> REQUIRED -------+----------------------+
| +---> NOT REQUIRED ---+ |
+-> ADJUSTABLE LOCK GRANULARITY IS -+-> ENABLED -> alg-options -+-+
| +-> DISABLED ---------------+ |
+-> LOCK TIMEOUT INTERVAL IS <number-seconds> SECONDS ------------+
+-> SEGMENTED STRING -+-> STORAGE AREA IS <area-name> ------------+
+-> LIST -------------+ |
+-> DEFAULT ----------+ |
+-> PROTECTION IS ---+---> ANSI --+-------------------------------+
| +---> ACLS --+ |
+-> RESERVE <n> +-> CACHE SLOTS ----+-----------------------------+
| +-> JOURNALS -------+ |
| +-> STORAGE AREAS --+ |
| +-> SEQUENCES ------+ |
+-+-> SET ---+-> TRANSACTION MODES --> ( -+-> txn-modes -+-> ) ---+
+-> ALTER -+ +----- , <-----+
global-buffer-params=
--> GLOBAL BUFFERS ARE -+-> ENABLED --+--------------+
+-> DISABLED -+ |
+----------------------------------------------------+
+---------------------------------------------------+--->
+> ( -++-> NUMBER IS <number-glo-buffers> ----++> ) +
|+-> USER LIMIT IS <max-glo-buffers> ---+|
|+-> PAGE TRANSFER VIA --+-> DISK ---+--+|
|| +-> MEMORY -+ |
|+-> LARGE MEMORY IS --+--> ENABLED --+--+
| +--> DISABLED -+ |
+------------------- , <----------------+
alg-options =
--+------------------------------+-->
+-> ( --> COUNT IS <n> --> ) --+
txn-modes =
-+-+-------+-+-> READ ONLY -----------------+-->
| +-> NO -+ +-> READ WRITE ----------------+
| +-> BATCH UPDATE --------------+
| +-> SHARED ----+--+----------+-+
| +-> PROTECTED -+ +-> READ --+ |
| +-> EXCLUSIVE -+ +-> WRITE -+ |
+-------------> ALL -----------------------+
+-------------> NONE ----------------------+
root-file-params-3 =
-+> CARDINALITY COLLECTION IS -------------------------++> ENABLED -+-+
+> CARRY OVER LOCKS ARE ------------------------------++> DISABLED + |
+> GALAXY SUPPORT IS ---------------------------------+ |
+> LOCK PARTITIONING IS ------------------------------+ |
+> LOGMINER SUPPORT IS -------------------------------+ |
+> METADATA CHANGES ARE ------------------------------+ |
+> STATISTICS COLLECTION IS --------------------------+ |
+> WORKLOAD COLLECTION IS ----------------------------+ |
+> SYSTEM INDEX -+-> COMPRESSION IS -+-> ENABLED ---+-----+----------+
| | +-> DISABLED --+ | |
| +-> ( -+-> system-index-options -+-> ) --+ |
| +---------- , <-----------+ |
+> prestarted-transaction-params ------------------------------------+
+> SECURITY CHECKING IS --> security-checking-options ---------------+
+> SYNONYMS ARE ENABLED ---------------------------------------------+
+> NOTIFY IS -+-> ENABLED --> notify-options -+---------------------+
+-> DISABLED --------------------+
system-index-options =
-+-> COMPRESSION IS --------------------------------++- ENABLED -++->
+-> PREFIX CARDINALITY COLLECTION IS --------------++> DISABLED +|
+-> PREFIX CARDINALITY COLLECTION IS ENABLED FULL ---------------+
+-> TYPE IS SORTED --+-----------+-------------------------------+
+-> RANKED -+
prestarted-transaction-params =
-> PRESTARTED TRANSACTIONS ARE -++--> ENABLED -++----------------------------++>
|+--> ON -----++->(prestart-trans-options) -+|
+-+-> DISABLED --+----------------------------+
+-> OFF -------+
prestart-trans-options =
-+---------------------------------+->
+-> WAIT <n> SECONDS FOR TIMEOUT -+
+-> WAIT <n> MINUTES FOR TIMEOUT -+
+-> NO TIMEOUT -------------------+
security-checking-options =
-+-> EXTERNAL -+------------------------------------------------++->
| +-> ( -> PERSONA SUPPORT IS -+-> ENABLED --+> ) -+|
| +-> DISABLED -+ |
+-> INTERNAL -+-----------------------------------------------+-+
+-> ( -> ACCOUNT CHECK IS -+---> ENABLED --+> ) +
+---> DISABLED -+
notify-options =
--+-----------------------------------------------------+-->
+--> ( ALERT OPERATOR -+--> operator-class -+-- ) --+
+--------- + <---------+
root-file-params-4 =
-+-> ASYNC BATCH WRITES ARE +> ENABLED -> async-bat-wr-options -+---+->
| +> DISABLED ------------------------+ |
++------------+-> ASYNC PREFETCH IS --+ |
|+> DETECTED -+ +-------------------+ |
| +-+-> ENABLED ---> async-prefetch-options +------+
| +-> DISABLED ---------------------------+ |
+-> ROW CACHE IS -+-> ENABLED --+-+----------------------+---------+
| +-> DISABLED -+ +-> row-cache-options -+ |
+-+------+-> INCREMENTAL BACKUP SCAN OPTIMIZATION -----------------+
| +> NO -+ |
+-> MULTITHREAD AREA ADDITIONS ----> multithread-options ----------+
+-> RECOVERY JOURNAL -> ( -> ruj-options -> ) ---------------------+
+-> OPEN IS -+> MANUAL --------------------------------------------+
| +> AUTOMATIC -+--------------------------------------++
| +->(WAIT <n> -> MINUTES -> FOR CLOSE) -+|
+-> SHARED MEMORY IS -+-> SYSTEM -------------------+--------------+
+-> PROCESS -+-------------+--+
+-> RESIDENT -+
asynch-bat-wr-options =
-+----------------------------->-------------------------------+->
+ ( ++-> CLEAN BUFFER COUNT IS <buffer-count> BUFFERS --++> ) +
|+-> MAXIMUM BUFFER COUNT IS <buffer-count> BUFFERS +|
+------------------- , <-----------------------------+
async-prefetch-options =
--+-----------------------------------------------------------+>
+-> ( -+-+-> DEPTH IS <number-buffers> BUFFERS -----+--+> )-+
| +-> THRESHOLD IS <number-buffers> BUFFERS -+ |
+----------------- , <--------------------------+
row-cache-options =
-> ( -++-> CHECKPOINT -+-> ALL ROWS TO BACKING FILE -----------+-++-> ) -->
|| +-> TIMED EVERY <n> SECONDS ------------+ ||
|| +-> UPDATED ROWS TO -+-> BACKING FILE -++ ||
|| +-> DATABASE -----+ ||
|+-> LOCATION IS --> <directory-spec> ---------------------+|
|+-> NO --+--> LOCATION --------+--------------------------+|
|| +--> SWEEP INTERVAL --+ ||
|+-> NUMBER OF SWEEP ROWS IS <n> --------------------------+|
|+-> SWEEP INTERVAL IS <n> SECONDS ------------------------+|
+-------------------------- , <-----------------------------+
multithread-options =
---+-----------------------------------------+-->
+-> ( --+-> ALL AREAS -----------+--> ) --+
+-> LIMIT TO <n> AREAS --+
ruj-options =
-+-> LOCATION IS --> <directory-spec> -+-->
+-> NO LOCATION ----------------------+
+-> BUFFER MEMORY IS -+-> LOCAL ------+
+-> GLOBAL -----+
storage-area-params-1 =
--+-> ALLOCATION IS ---> <number-pages> --> PAGES -----+->
+-> CACHE USING <row-cache-name> --------------------+
+-> NO ROW CACHE ------------------------------------+
+-> extent-params -----------------------------------+
+-> INTERVAL IS --> <number-data-pages> -------------+
+-> LOCKING IS --+-> ROW --+--> LEVEL ---------------+
| +-> PAGE -+ |
+-> PAGE FORMAT IS +-> UNIFORM -+--------------------+
| +-> MIXED ---+ |
+-> PAGE SIZE IS ----> <page-blocks> --> BLOCKS -----+
extent-params =
--+-> EXTENT IS -+-> ENABLED -------------------++-->
| +-> DISABLED ------------------+|
| +-> <extent-pages> --> PAGES --+|
| +-> (extension-options) -------+|
+---------------------<------------------------+
extension-options =
---> MINIMUM OF <min-pages> PAGES, --+
+------------------------------------+
+--> MAXIMUM OF <max-pages> PAGES, --+
+------------------------------------+
+--> PERCENT GROWTH IS <growth> ------->
storage-area-params-2 =
--+-> CHECKSUM CALCULATION IS -----------+--+-> ENABLED --+-+->
+-> SNAPSHOT CHECKSUM CALCULATION IS --+ +-> DISABLED -+ |
+-> SNAPSHOT ALLOCATION IS --> <snp-pages> ----> PAGES ---+
+-> SNAPSHOT EXTENT IS -+-> <extent-pages> ----> PAGES --++
| +-> (extension-options) ---------+|
+-> SNAPSHOT FILENAME --> <file-spec> --------------------+
+-> THRESHOLDS ARE ( <val1> +-----------------------+> ) -+
| +> ,<val2> -+----------++ |
| +> ,<val3> + |
+------------------------------<--------------------------+
character-sets =
-+-+--> DEFAULT CHARACTER SET <support-char-set> --+-+->
| +--> NATIONAL CHARACTER SET <support-char-set> -+ |
| +--> IDENTIFIER CHARACTER SET <names-char-set> -+ |
| +--> DISPLAY CHARACTER SET <support-char-set> ----+
+---------------------- <---------------------------+
database-element =
-+-> create-cache-clause -----------------+-->
+-> create-catalog-statement ------------+
+-> create-collating-sequence-statement -+
+-> create-domain-statement -------------+
+-> create-function-statement -----------+
+-> create-index-statement --------------+
+-> create-module-statement -------------+
+-> create-procedure-statement ----------+
+-> create-sequence-statement -----------+
+-> create-schema-statement -------------+
+-> create-storage-area-clause ----------+
+-> create-storage-map-statement --------+
+-> create-table-statement --------------+
+-> create-trigger-statement ------------+
+-> create-view-statement ---------------+
+-> grant-statement ---------------------+
4.3 – Arguments
4.3.1 – ADJUSTABLE_LOCK_GRANULARITY
Syntax options:
ADJUSTABLE LOCK GRANULARITY IS ENABLED
ADJUSTABLE LOCK GRANULARITY IS DISABLED
Enables or disables whether or not the database system automatically
maintains as few locks as possible on database resources. The
default is ENABLED and results in fewer locks against the database.
However, if contention for database resources is high, the automatic
adjustment of locks can become a CPU drain. Such databases can trade
more restrictive locking for less CPU usage by disabling adjustable
lock granularity.
4.3.2 – alias
Specifies the alias for the implicit database declaration
executed by the CREATE DATABASE statement. An alias is a name for
a particular attach to a database that identifies that database
in subsequent SQL statements.
NOTE
If you attach to a database using an alias, you must use
that alias in subsequent statements to qualify the names of
elements in that database.
If you omit the FILENAME argument from the database root file
parameters, SQL also uses the alias as the file name for the
database root file and creates the root file in the current
default directory. (SQL generates a syntax error if you include
a disk or directory specification in the alias clause.) You must
specify either the FILENAME or alias argument.
Schema elements in the CREATE DATABASE statement do not need to
use the alias, however, they cannot specify any other alias.
The alias clause is optional. The default alias in interactive
SQL and in precompiled programs is RDB$DBHANDLE. In the SQL
module language, the default is the alias specified in the
module header. Using the default alias (either by specifying
it explicitly in the ALIAS clause or omitting the ALIAS clause)
declares the database as the default database. Specifying a
default database means that statements outside the CREATE
DATABASE statement that refer to the default database do not
need to use an alias.
If a default database was already declared, and you specify the
default alias in the ALIAS clause (or specify any alias that was
already declared), the results depend on the environment in which
you issue the CREATE DATABASE statement.
o In interactive SQL, you receive a prompt asking if you want
to override the default database declaration. Unless you
explicitly override the default declaration, the CREATE
DATABASE statement fails.
SQL> -- Assume a default database has been declared:
SQL> --
SQL> -- Now create a database without an alias.
SQL> -- SQL asks if you want to override the default:
SQL> CREATE DATABASE FILENAME test;
This alias has already been declared.
Would you like to override this declaration (No)? NO
%SQL-F-DEFDBDEC, A database has already been declared with the default
alias
o In embedded SQL or in the SQL module language, specifying
an already-declared alias in the CREATE DATABASE statement
generates an error when you precompile the program or compile
the module.
o In dynamic SQL, specifying an already-declared alias overrides
the earlier declaration.
For more information about default databases, see the User_
Supplied_Names HELP topic.
4.3.3 – ALL_AREAS
Specifies that all storage areas be created and initialized in
parallel.
All storage areas are created asynchronously. If you are creating
a large number of storage areas, you may exceed process quotas,
resulting in the database creation failing.
4.3.4 – ALLOCATION n pages
The number of database pages allocated to the database initially.
SQL automatically extends the allocation to handle the loading of
data and subsequent expansion. Pages are allocated in groups of
3. An ALLOCATION of 25 pages would actually provide for 27 pages.
The default is 700 pages. If you are loading a large database, a
large allocation helps to prevent fragmented files.
4.3.5 – ALTER_TRANSACTION_MODES
Enables the modes specified, leaving the previously defined or
default modes enabled. For example, if the only transaction
mode you want to disable are batch updates, use the following
statement:
SQL> CREATE DATABASE FILENAME mf_personnel
cont> ALTER TRANSACTION MODES (NO BATCH UPDATE);
If not specified, the default transaction mode is ALL.
4.3.6 – ASYNC_BATCH_WRITES
Syntax options:
ASYNC BATCH WRITES ARE ENABLED | ASYNC BATCH WRITES ARE DISABLED
Specifies whether asynchronous batch-writes are enabled or
disabled.
Asynchronous batch-writes allow a process to write batches of
modified data pages to disk asynchronously (the process does not
stall while waiting for the batch-write operation to complete).
Asynchronous batch-writes improve the performance of update
applications without the loss of data integrity.
By default, batch-writes are enabled. For more information about
when to use asynchronous batch-writes, see the Oracle Rdb7 Guide
to Database Performance and Tuning.
You can enable asynchronous batch-writes by defining the logical
name RDM$BIND_ABW_ENABLED.
4.3.7 – ASYNC_PREFETCH
Syntax options:
ASYNC PREFETCH IS ENABLED | ASYNC PREFETCH IS DISABLED
Specifies whether or not Oracle Rdb reduces the amount of time
that a process waits for pages to be read from disk by fetching
pages before a process actually requests the pages.
Prefetch can significantly improve performance, but it may
cause excessive resource usage if it is used inappropriately.
Asynchronous prefetch is enabled by default. For more information
about asynchronous prefetch, see the Oracle Rdb7 Guide to
Database Performance and Tuning.
You can enable asynchronous prefetch by defining the logical name
RDM$BIND_APF_ENABLED.
4.3.8 – BUFFER_SIZE
Specifies the number of blocks SQL allocates per buffer. You need
to specify an unsigned integer greater than zero. The default
buffer size is 3 times the PAGE SIZE value (6 blocks for the
default PAGE SIZE of 2).
The buffer size is a global parameter and the number of blocks
per page (or buffer) is constrained to less than 64 blocks
per page. The page size can vary by storage area for multifile
databases, and the page size should be determined by the sizes of
the records that will be stored in each storage area.
When choosing the number of blocks per buffer, choose a number so
that a round number of pages fits in the buffer. In other words,
the buffer size is wholly divisible by all page sizes for all
storage areas in your multifile database. For example, if you
have three storage areas with page sizes of 2, 3, and 4 blocks
each respectively, choosing a buffer size of 12 blocks ensures
optimal buffer utilization. In contrast, choosing a buffer size
of 8 wastes 2 blocks per buffer for the storage area with a page
size of 3 pages. Oracle Rdb reads as many pages as fit into the
buffer; in this instance it reads two 3-block pages into the
buffer, leaving 2 wasted blocks.
4.3.9 – CACHE_USING
Assigns the named row cache as the default for all storage areas
in the database. All rows stored in an area, whether they consist
of table data, segmented string data, or special rows such as
index nodes, are cached.
You must create the row cache before terminating the CREATE
DATABASE statement. For example:
SQL> CREATE DATABASE FILENAME test_db
cont> ROW CACHE IS ENABLED
cont> CACHE USING test1
cont> CREATE CACHE test1
cont> CACHE SIZE IS 100 ROWS
cont> CREATE STORAGE AREA area1;
You can override the database default row cache by either
specifying the CACHE USING clause after the CREATE STORAGE AREA
clause or by later altering the database and storage area to
assign a new row cache. Only one row cache is allowed for each
storage area.
If you do not specify the CACHE USING clause or the NO ROW CACHE
clause, NO ROW CACHE is the default for the database.
4.3.10 – CARDINALITY_COLLECTION
Syntax options:
CARDINALITY COLLECTION IS ENABLED
CARDINALITY COLLECTION IS DISABLED
Specifies whether or not the optimizer records cardinality
updates in the system table. When enabled, the optimizer collects
cardinalities for the table and non-unique indexes as rows are
inserted or deleted from tables. The update of the cardinalities
is performed at commit time, if sufficient changes have accumulated,
or at disconnect time.
In high update environments, it may be more convenient to
disable cardinality updates. If you disable this feature, you
should manually maintain the cardinalities using the RMU Analyze
Cardinality command so the optimizer is given the most accurate
values for estimation purposes.
Cardinality collection is enabled by default.
4.3.11 – CARRY_OVER_LOCKS
Syntax options:
CARRY OVER LOCKS ARE ENABLED | CARRY OVER LOCKS ARE DISABLED
Enables or disables carry-over lock optimization. Carry-over
locks are enabled by default.
While attached to the database, a process can have some active
locks (locks attached to the database) and some carry-over
locks (locks requested in earlier transactions that have not
been demoted). If a transaction needs a lock it has currently
marked as carry-over, it can reuse the lock by changing it to an
active lock. The same lock can go from active to carry-over to
active multiple times without paying the cost of lock request and
demotion. This substantially reduces the number of lock requests
if a process accesses the same areas repeatedly.
As part of the carry-over lock optimization, a NOWAIT transaction
requests, acquires, and holds a NOWAIT lock. This signals other
processes accessing the database that a NOWAIT transaction exists
and causes Oracle Rdb to release all carry-over locks. If NOWAIT
transactions are noticeably slow when executing, you can specify
CARRY OVER LOCKS ARE DISABLED with the ALTER DATABASE or CREATE
DATABASE statement.
This feature is available as an online database modification.
4.3.12 – CHECKPOINT_TIMED
Syntax option:
CHECKPOINT TIMED EVERY n SECONDS
For the row-cache-options clause, specifies the frequency with
which the row-cache server (RCS) process checkpoints the contents
of the row caches back to disk. The RCS process does not use the
checkpoint frequency options of the FAST COMMIT clause.
The frequency of RCS checkpointing is important in determining
how much of an .aij file must be read during a recovery operation
following a node failure. It also affects the frequency with
which marked records get flushed back to the database for those
row caches that checkpoint to the database. The default is every
15 minutes (900 seconds).
4.3.13 – Checkpoint Rows
Syntax options:
CHECKPOINT UPDATED ROWS TO BACKING FILE
CHECKPOINT UPDATED ROWS TO DATABASE
CHECKPOINT ALL ROWS TO BACKING FILE
Specifies the default source and target during checkpoint
operations for all row caches. If ALL ROWS is specified, then the
source records written during each checkpoint operation are both
the modified and the unmodified rows in a row cache. If UPDATED
ROWS is specified, then just the modified rows in a row cache are
checkpointed each time.
If the target of the checkpoint operation is BACKING FILE,
then the RCS process writes the source row cache entries to
the backing (.rdc) files. The row cache LOCATION, ALLOCATION,
and EXTENT clauses are used to create the backing files. Upon
recovery from a node failure, the database recovery process is
able to repopulate the row caches in memory from the rows found
in the backing files.
If the target is DATABASE, then updated row cache entries
are written back to the database. The row cache LOCATION,
ALLOCATION, and EXTENT clauses are ignored. Upon recovery from
a node failure, the database recovery process has no data on the
contents of the row cache. Therefore, it does not repopulate the
row caches in memory.
The CHECKPOINT clause of the CREATE CACHE, ADD CACHE, or ALTER
CACHE clause overrides this database-level CHECKPOINT clause.
4.3.14 – CHECKSUM_CALCULATION
Syntax options:
CHECKSUM CALCULATION IS ENABLED
CHECKSUM CALCULATION IS DISABLED
This option allows you to enable or disable calculations of page
checksums when pages are read from or written to the storage area or
snapshot files.
The default is ENABLED.
NOTE
Oracle Corporation recommends that you leave checksum
calculations enabled, which is the default.
With current technology, it is possible that errors may occur
that the checksum calculation can detect but that may not
be detected by either the hardware, firmware, or software.
Unexpected application results and database corruption may occur
if corrupt pages exist in memory or on disk but are not detected.
Oracle Corporation recommends performing checksum calculations,
except in the following specific circumstances:
o Your application is stable and has run without errors on the
current hardware and software configuration for an extended
period of time.
o You have reached maximum CPU utilization in your current
configuration. Actual CPU utilization by the checksum
calculation depends primarily on the size of the database
pages in your database. The larger the database page, the
more noticeable the CPU usage by the checksum calculation may
become.
NOTE
Oracle Corporation recommends that you carefully evaluate
the trade-off between reducing CPU usage by the checksum
calculation and the potential for loss of database integrity
if checksum calculations are disabled.
Oracle Rdb allows you to disable and, subsequently, re-enable
checksum calculation without error. However, once checksum
calculations have been disabled, corrupt pages may not be
detected even if checksum calculations are subsequently re-
enabled.
4.3.15 – CLEAN_BUFFER_COUNT
Syntax options:
CLEAN BUFFER COUNT IS buffer-count BUFFERS
Specifies the number of buffers to be kept available for
immediate reuse.
Oracle Rdb maintains the number of buffers at the end of a
process' least recently used queue of buffers for replacement.
The default is five buffers. The minimum value is one; the
maximum value can be as large as the buffer pool size.
You can override the number of clean buffers by defining the
logical name RDM$BIND_CLEAN_BUF_CNT. For information about how to
set the values, see the Oracle Rdb7 Guide to Database Performance
and Tuning.
4.3.16 – COLLATING_SEQUENCE
Specifies a default collating sequence to be used for all CHAR
and VARCHAR columns in the database. SQL uses the default
collating sequence if you do not specify a collating sequence
in subsequent CREATE DOMAIN statements.
Collation-name is a name of your choosing; you must use this name
in any COLLATING SEQUENCE clauses that refer to this collating
sequence for operations on this database.
4.3.17 – COMMENT
Syntax option:
COMMENT IS 'string'
Adds a comment about the collating sequence. SQL displays the
text when it executes a SHOW COLLATING SEQUENCE statement in
interactive SQL. Enclose the comment in single quotation marks
(') and separate multiple lines in a comment with a slash mark
(/).
4.3.18 – COUNT IS n
Specifies the number of levels on the page lock tree used to
manage locks. For example, if you specify COUNT IS 3, the fanout
factor is (10, 100, 1000). Oracle Rdb locks a range of 1000 pages
and adjusts downward to 100 and then to 10 and then to 1 page
when necessary.
If the COUNT IS clause is omitted, the default is 3. The value of
n can range from 1 through 8.
4.3.19 – create-cache-clause
See the CREATE CACHE clause for more details.
4.3.20 – create-catalog-statement
See the CREATE CATALOG statement for details.
If you want to specify a CREATE CATALOG statement in a CREATE
DATABASE statement, you must first specify a MULTISCHEMA IS ON
clause in the same CREATE DATABASE statement.
The CREATE CATALOG statement is committed immediately and cannot
be rolled back. Before you specify the CREATE CATALOG statement,
the following conditions must be true:
o The database is enabled for multischema.
o No transactions are active.
o The catalog alias must be the same as the database alias.
For information about enabling the database for multischema, see
the User_Supplied_Names HELP topic.
4.3.21 – create-collating-sequence-statement
See the CREATE COLLATING_SEQUENCE statement for details.
If you want to specify a collating sequence in a CREATE DOMAIN
statement embedded in a CREATE DATABASE statement, you must first
specify a CREATE COLLATING SEQUENCE statement in the same CREATE
DATABASE statement.
4.3.22 – create-domain-statement
See the CREATE DOMAIN statement for details.
You cannot use the FROM path-name clause when embedding a
CREATE DOMAIN statement in a CREATE DATABASE statement. You
can, however, issue a separate CREATE DOMAIN statement following
the CREATE DATABASE statement. You can also describe the domain
directly in the CREATE DATABASE statement.
If you want to specify a collating sequence in your embedded
CREATE DOMAIN statement, you must first specify a CREATE
COLLATING SEQUENCE statement in the same CREATE DATABASE
statement.
4.3.23 – create-function-statement
A CREATE FUNCTION statement. See the CREATE Routine statement for
details.
4.3.24 – create-index-statement
See the CREATE INDEX statement for details.
4.3.25 – create-module-statement
See the CREATE MODULE statement for details.
4.3.26 – create-procedure-statement
A CREATE PROCEDURE statement. See the CREATE Routine statement
for details.
4.3.27 – create-schema-statement
See the CREATE SCHEMA statement for details.
The schema you create must have the same alias as the catalog and
database that contain the schema, or they must share the default
alias.
4.3.28 – create-sequence-statement
See the CREATE SEQUENCE statement for details.
4.3.29 – create-storage-area-clause
See the CREATE STORAGE_AREA statement for more details.
4.3.30 – create-storage-map-statement
See the CREATE STORAGE_MAP statement for details.
4.3.31 – create-table-statement
See the CREATE TABLE statement for details.
You cannot use the FROM path-name clause when embedding a CREATE
TABLE statement in a CREATE DATABASE statement. You can, however,
issue a separate CREATE TABLE statement following the CREATE
DATABASE statement. You can also describe the table directly in
the CREATE DATABASE statement.
The CREATE TABLE statements in a CREATE DATABASE statement can
refer to domains not yet created, provided that CREATE DOMAIN
statements for the domains are in the same CREATE DATABASE
statement.
4.3.32 – create-trigger-statement
See the CREATE TRIGGER statement for details.
4.3.33 – create-view-statement
See the CREATE VIEW statement for details.
4.3.34 – database-element
Database elements are a CREATE STORAGE AREA clause, any of the
CREATE statements (except CREATE DOMAIN . . . FROM path-name and
CREATE TABLE . . . FROM path-name), or a GRANT statement.
4.3.35 – DBKEY_SCOPE
Syntax options:
DBKEY SCOPE IS ATTACH | DBKEY SCOPE IS TRANSACTION
Controls when the database key of a deleted row can be used again
by SQL. This setting is not a database root file parameter, but
a characteristic of the implicit database attach executed by
the CREATE DATABASE statement. Thus, the DBKEY SCOPE clause in a
CREATE DATABASE statement takes effect only for the duration of
the session of the user who entered the statement.
o The default DBKEY SCOPE IS TRANSACTION means that SQL can
reuse the database key of a deleted table row (to refer to a
newly inserted row) as soon as the transaction that deleted
the original row completes with a COMMIT statement. (If the
user who deleted the original row enters a ROLLBACK statement,
then the database key for that row cannot be used again by
SQL.)
During the connection of the user who entered the CREATE
DATABASE statement, the DBKEY SCOPE IS TRANSACTION clause
specifies that a database key is guaranteed to refer to the
same row only within a particular transaction.
o The DBKEY SCOPE IS ATTACH clause means that SQL cannot use the
database key again (to refer to a newly inserted row) until
all users who have attached with DBKEY SCOPE IS ATTACH have
detached from the database.
Also it only requires one process to attach with DBKEY
SCOPE IS ATTACH to force all database users to assume this
characteristic.
o Oracle Corporation recommends using DBKEY SCOPE IS TRANSACTION
to prevent excessive consumption of storage area space by
overhead needed to support DBKEY SCOPE IS ATTACH, and to
prevent performance problems when storing new rows.
During the connection of the user who entered the CREATE
DATABASE statement, the DBKEY SCOPE IS ATTACH clause specifies
that a database key is guaranteed to refer to the same row
until the user detaches from the database.
For more information, see the DBKEY HELP topic.
4.3.36 – DEFAULT_CHARACTER_SET
Specifies the database default character set for this database.
For a list of allowable character set names, see Supported
Character Sets.
4.3.37 – DEFAULT_STORAGE_AREA
Specifies a default storage area to which all user data and
unmapped indexes are stored. The DEFAULT STORAGE AREA parameter
separates user data from the system data, such as system tables.
RDB$SYSTEM is the default area if you do not specify a default
storage area.
In addition to user data, Oracle Rdb stores the following system
tables in the default storage area:
o RDB$INTERRELATIONS
o RDB$MODULES
o RDB$ROUTINES
o RDB$PARAMETERS
o RDB$QUERY_OUTLINES
o RDB$SEQUENCES
o RDB$PROFILES
o RDB$GRANTED_PROFILES
o RDB$TYPES
o RDB$TYPE_FIELDS
o RDB$WORKLOAD
o RDB$OBJECT_SYNONYMS
o RDB$SYNONYMS
o RDB$CATALOG_SCHEMA
For information on moving these system tables to other
storage areas, see the Oracle Rdb Guide to Database Design and
Definition.
The DEFAULT STORAGE AREA parameter must reference an existing
storage area. You must create the storage area using the CREATE
STORAGE AREA clause in the same CREATE DATABASE statement as the
DEFAULT STORAGE AREA parameter.
4.3.38 – DEPTH buffers option
Syntax option:
DEPTH IS number-buffers BUFFERS
Specifies the number of buffers to prefetch for a process.
The default is one-quarter of the buffer pool, but not more than
eight buffers. You can override the number of buffers specified
in the CREATE or ALTER DATABASE statements by using the logical
name RDM$BIND_APF_DEPTH.
You can also specify this option with the DETECTED ASYNC PREFETCH
clause.
4.3.39 – DETECTED_ASYNC_PREFETCH
Syntax options:
DETECTED ASYNC PREFETCH IS ENABLED
DETECTED ASYNC PREFETCH IS DISABLED
Specifies whether or not Oracle Rdb reduces the amount of time that
a process waits for pages to be read from disk.
By using heuristics, detected asynchronous prefetch determines if
an I/O pattern is sequential in behavior even if sequential I/O
is not actually executing at the time. For example, when a LIST
OF BYTE VARYING column is fetched, the heuristics detect that
the pages being fetched are sequential and asynchronously fetches
pages further in the sequence. This avoids wait times when the
page is really needed.
Detected asynchronous prefetch is enabled by default.
4.3.40 – DICTIONARY
Syntax options:
DICTIONARY IS REQUIRED | DICTIONARY IS NOT REQUIRED
Specifies whether or not definition statements issued for the
database must also be stored in the repository. If you specify
REQUIRED, any data definition statements issued after a DECLARE
DATABASE statement that does not use the PATHNAME argument fails.
If you omit the PATHNAME clause from the database root file
parameters in the CREATE DATABASE statement, SQL generates an
error if you also specify DICTIONARY IS REQUIRED.
The default is DICTIONARY IS NOT REQUIRED.
4.3.41 – DISPLAY_CHARACTER_SET
Specifies the character set encoding and characteristics expected
of text strings returned back to SQL from Oracle Rdb.
4.3.42 – EXTENT clause
Syntax options:
EXTENT IS ENABLED | EXTENT IS DISABLED
Enables or disables extents. Extents are enabled by default.
You can encounter performance problems when creating hashed
indexes in storage areas with the mixed page format if the
storage area was created specifying the wrong size for the area
and if extents are enabled. By disabling extents, this problem
can be diagnosed early and corrected to improve performance.
4.3.43 – EXTENT pages
Syntax options:
EXTENT IS extent-pages PAGES| EXTENT IS (extension-options)
Specifies the number of pages of each storage area file extent.
For more information, see the SNAPSHOT EXTENT argument.
4.3.44 – FILENAME file spec
The file specification associated with the database.
You can omit the FILENAME clause if you specify the ALIAS clause.
If you omit the FILENAME clause, the file specification uses the
following defaults:
o Device: the current device for the process
o Directory: the current directory for the process
o File name: the alias, if any was specified; otherwise omitting
the FILENAME clause generates an error
Use either a full file specification or a partial file
specification.
You can use a logical name for all or part of a file
specification.
If you use a simple file name, SQL creates the database in the
current default directory. Because the CREATE DATABASE statement
may create more than one file with different file extensions, do
not specify a file extension with the file specification.
The file specification may contain an OpenVMS remote node
specification. Oracle Rdb must be installed on that remote node
so that the CREATE DATABASE statement can be executed remotely.
Note that all other file specifications in the command (storage
areas, snapshot files, recovery journal location, and so on) must
be specified using the logical names and device names relative to
that remote node.
The number and type of files created using the file specification
in the FILENAME clause depend on whether you create a multifile
or single-file database.
o In multifile CREATE DATABASE statements (any that include
CREATE STORAGE AREA clauses), SQL uses the file specification
to create up to three files:
- A database root file with an .rdb file extension
- A storage area file, with an .rda file extension, for the
main storage area, RDB$SYSTEM, (unless the CREATE DATABASE
statement contains a CREATE STORAGE AREA RDB$SYSTEM clause,
which overrides this file specification)
- A snapshot file, with an .snp file extension, for the
main storage area, RDB$SYSTEM (unless the CREATE DATABASE
statement contains a CREATE STORAGE AREA RDB$SYSTEM clause,
which overrides this file specification)
o In single-file CREATE DATABASE statements (any that omit the
CREATE STORAGE AREA clause), SQL uses the file specification
to create two files:
- A combined root and data file with an .rdb file extension
- A snapshot file with an .snp file extension
If you create a single-file database, you cannot later create
additional data and snapshot files with ALTER DATABASE . . .
ADD STORAGE AREA statements. If you want to change a database
from a single-file to a multifile database, you must use the
EXPORT and IMPORT statements.
4.3.45 – FROM library name
Specifies the name of an NCS library other than the default
library. The default NCS library is SYS$LIBRARY:NCS$LIBRARY.
4.3.46 – GALAXY_SUPPORT
Syntax options:
GALAXY SUPPORT IS ENABLED|GALAXY SUPPORT IS DISABLED
Allows global memory to be shared in an OpenVMS Galaxy
configuration. Galaxy support is disabled by default.
OpenVMS Galaxy is a software architecture for the OpenVMS Alpha
operating system that enables multiple instances of OpenVMS to
execute cooperatively in a single computer. An instance refers
to a copy of the OpenVMS Alpha operating system. As an extension
of the existing OpenVMS cluster support within Oracle Rdb, Oracle
Rdb provides support for databases opened on multiple instances
(or nodes) within a Galaxy system to share data structures in
memory. Within an Oracle Rdb Galaxy environment, all instances
with an open database share:
o Database root objects (for example, TSN blocks and SEQ blocks)
o Global buffers (if enabled)
o Row caches and Row Cache Server process (RCS) (if enabled)
4.3.47 – GLOBAL_BUFFERS
Syntax options:
GLOBAL BUFFERS ARE ENABLED | GLOBAL BUFFERS ARE DISABLED
Specifies that Oracle Rdb maintains one global buffer pool
per VMScluster node for each database. By default, Oracle Rdb
maintains a local buffer pool for each attach. For more than one
attach to use the same page, each must read it from disk into
its local buffer pool. A page in the global buffer pool may be
read by more than one attach at the same time, although only one
process reads the page from the disk into the global buffer pool.
Global buffering provides improved performance because I/O is
reduced and memory is better utilized.
NOTE
If GALAXY SUPPORT is enabled, then a single global buffer
pool is shared by all Galaxy nodes.
4.3.48 – grant-statement
See the GRANT statement for details.
4.3.49 – IDENTIFIER_CHARACTER_SET
Specifies the identifier character set for user-supplied database
object names, such as table names and column names. The character
set must contain ASCII characters. See the Oracle Rdb SQL
Reference Manual for a list of allowable character sets.
4.3.50 – INCREMENTAL_BACKUP_SCAN_OPTIMIZATION
Syntax option:
INCREMENTAL BACKUP SCAN OPTIMIZATION
NO INCREMENTAL BACKUP SCAN OPTIMIZATION
Specifies whether Oracle Rdb checks each area's SPAM pages or each
database page to find changes during incremental backup.
If you specify INCREMENTAL BACKUP SCAN OPTIMIZATION, Oracle Rdb
checks each area's SPAM pages and scans the SPAM interval of
pages only if the SPAM transaction number (TSN) is higher than
the root file backup TSN, which indicates that a page in the SPAM
interval has been updated since the last full backup operation.
Updates in the SPAM interval result in an extra I/O.
Specify INCREMENTAL BACKUP SCAN OPTIMIZATION if your database has
large SPAM intervals or infrequently occurring updates, and you
want to increase the speed of incremental backups.
If you specify NO INCREMENTAL BACKUP SCAN OPTIMIZATION, Oracle
Rdb checks each page to find changes during incremental backup.
Specify the NO INCREMENTAL BACKUP SCAN OPTIMIZATION clause if
your database has frequently occurring updates, uses bulk-load
operations, or does not use incremental backups, or if you want
to improve run-time performance.
The default is INCREMENTAL BACKUP SCAN OPTIMIZATION.
4.3.51 – INTERVAL
Specifies the number of data pages between space area management
(SPAM) pages in the storage area file, and therefore the maximum
number of data pages each space area management page will manage.
The default, and also the minimum interval, is 216 data pages.
The first page of each storage area is a space area management
page. The interval you specify determines where subsequent space
area management pages are to be inserted, provided there are
enough data pages in the storage file to require more space area
management pages.
You cannot specify the INTERVAL storage area parameter for
single-file databases, and you cannot specify INTERVAL unless
you also explicitly specify PAGE FORMAT IS MIXED.
Oracle Rdb calculates the maximum interval size based on the
number of blocks per page and returns an error message if you
exceed this value. For example, when the page size is 2 blocks,
the maximum interval is 4008 pages. If you try to create a
storage area with the interval set to 4009, Oracle Rdb returns
the following error message:
%RDB-E-BAD_DPB_CONTENT, invalid database parameters in the database parameter
block (DPB)
-RDMS-F-SPIMAX, spam interval of 4009 is more than the Rdb maximum of 4008
-RDMS-F-AREA_NAME, area NEW
For more information about setting space area management
parameters, see the Oracle Rdb Guide to Database Maintenance.
4.3.52 – LARGE_MEMORY
Syntax options:
LARGE MEMORY IS ENABLED | LARGE MEMORY IS DISABLED
Specifies whether or not large memory is used to manage the row
cache. Very large memory (VLM) allows Oracle Rdb to use as much
physical memory as is available.
Use the LARGE MEMORY IS ENABLED clause only when both of the
following are true:
o You have enabled row caching.
o You want to cache large amounts of data, but the cache does
not fit in the virtual address space.
The default is the LARGE MEMORY IS DISABLED clause.
4.3.53 – LIMIT TO n AREAS
Specifies the number of storage areas to be created in parallel.
The number of areas should be smaller than the current process
file open quota. The number of areas can range from between 1 and
the number of storage areas being created.
4.3.54 – LIST_STORAGE_AREA
Specifies the name of the storage area to be used for table
columns defined through SQL with the LIST OF BYTE VARYING data
type.
You can specify the LIST STORAGE AREA parameter for multifile
databases only.
By default, columns with the LIST OF BYTE VARYING data type are
stored in the RDB$SYSTEM storage area. If you specify a different
storage area in this clause, the CREATE DATABASE statement must
include a CREATE STORAGE AREA clause defining that area. For
information about creating multiple list storage areas for a
table, see the CREATE STORAGE_AREA clause.
NOTE
If you plan to store lists with segments of widely varying
sizes, you should specify a MIXED page format area just
for list storage. (Do not assign tables and indexes to the
area.)
The database system looks for free space in an area when it
stores each segment of a segmented string. If size varies
significantly among the different segments of the lists
that you plan to store, the interval and threshold values
that the database system automatically sets for page format
areas you specify as UNIFORM can make storing lists time-
consuming. For a mixed page format area, you can customize
interval and thresholds values to reduce the amount of time
that the database system spends looking for free space when
it stores different segments of the same segmented string.
The following example shows valid syntax for the LIST STORAGE
AREA clause:
SQL> CREATE DATABASE FILENAME test
cont> LIST STORAGE AREA IS registry_area
cont> CREATE STORAGE AREA RDB$SYSTEM FILENAME maintenance_area
cont> CREATE STORAGE AREA registry_area FILENAME registry_area;
SQL> CREATE STORAGE MAP registry_map
cont> STORE LISTS IN registry_area;
4.3.55 – literal-user-auth
Specifies the user name and password for access to databases,
particularly remote database.
This literal lets you explicitly provide user name and password
information in the CREATE DATABASE statement.
4.3.56 – LOCATION IS directory spec
Specifies the name of the backing store directory to which row
cache information is written. The database system generates a
file name (row-cache-name.rdc) automatically for each row cache
at checkpoint time. Specify a device name and directory name
only, enclosed within single quotation marks. The file name is
the row-cache-name specified when creating the row cache. By
default, the location is the directory of the database root file.
These .rdc files are permanent database backing store files.
The LOCATION clause of the CREATE CACHE, ADD CACHE, or ALTER
CACHE clause overrides this location, which is the default for
the database.
This clause is ignored if the row cache is defined to checkpoint
to the database.
4.3.57 – LOCK_PARTITIONING
Syntax options:
LOCK PARTITIONING IS ENABLED | LOCK PARTITIONING IS DISABLED
Specifies whether more than one lock tree is used for the
database or all lock trees for a database are mastered by one
database resource tree.
When partitioned lock trees are enabled for a database, locks for
storage areas are separated from the database resource tree and
all locks for each storage area are independently mastered on the
VMScluster node that has the highest traffic for that resource.
OpenVMS determines the node that is using each resource the most
and moves the resource hierarchy to that node.
You cannot enable lock partitioning for single-file databases.
You should not enable lock partitioning for single-node systems,
because all lock requests are local on single-node systems.
By default, lock partitioning is disabled.
4.3.58 – LOCK_TIMEOUT_INTERVAL
Syntax option:
LOCK TIMEOUT INTERVAL IS number-seconds SECONDS
Specifies the number of seconds for processes to wait during a
lock conflict before timing out. The number of seconds can be
between 1 and 65,000 seconds.
Specifying 0 is interpreted as no lock timeout interval being
set. It is not interpreted as 0 seconds.
The lock timeout interval is database-wide; it is used as the
default as well as the upper limit for determining the timeout
interval. For example, if the database definer specified LOCK
TIMEOUT INTERVAL IS 25 SECONDS in the CREATE DATABASE statement,
and a user of that database specified SET TRANSACTION WAIT 30
or changed the logical name RDM$BIND_LOCK_TIMEOUT_INTERVAL to
30, SQL uses the interval of 25 seconds. For more information,
see the SET_TRANSACTION statement and the Oracle Rdb7 Guide to
Distributed Transactions.
4.3.59 – LOCKING level
Syntax options:
LOCKING IS ROW LEVEL | LOCKING IS PAGE LEVEL
Specifies page-level or row-level locking as the default for the
database. This clause provides an alternative to requesting locks
on records. You can override the database default lock level
at the storage area level. The default is ROW LEVEL, which is
compatible with previous versions of Oracle Rdb.
When many records are accessed in the same area and on the same
page, the LOCKING IS PAGE LEVEL clause reduces the number of lock
operations perfomed to process a transaction; however, this is at
the expense of reduced concurrency. Transactions that benefit
most with page-level locking are of short duration and also
access several database records on the same page.
Use the LOCKING IS ROW LEVEL clause if transactions are long in
duration and lock many rows.
The LOCKING IS PAGE LEVEL clause causes fewer blocking ASTs
and provides better response time and utilization of system
resources. However, there is a higher contention for pages and
increased potential for deadlocks and long transactions may use
excessive locks.
Page-level locking is never applied to RDB$SYSTEM or the DEFAULT
storage area, either implicitly or explicitly, because the lock
protocol can stall metadata users.
You cannot specify page-level locking on single-file databases.
4.3.60 – LOGMINER_SUPPORT
Syntax options:
LOGMINER SUPPORT IS ENABLED|LOGMINER SUPPORT IS DISABLED
Allows additional information to be written to the after-image
journal file to allow the use of the RMU Unload After_Image
command. See Oracle RMU Reference Manual for more details.
Logminer support is disabled by default.
The LOGMINER SUPPORT clause allows the continuous mode for
LogMiner to be enabled and disabled.
o LOGMINER SUPPORT IS ENABLED (CONTINUOUS)
Enables continuous LogMiner.
o LOGMINER SUPPORT IS ENABLED (NOT CONTINUOUS)
Disables continuous LogMiner, but leaves LogMiner enabled.
o LOGMINER SUPPORT IS DISABLED
Disables LogMiner, including disabling continuous LogMiner.
4.3.61 – MAXIMUM_BUFFER_COUNT
Specifies the number of buffers a process will write
asynchronously.
The default is one-fifth of the buffer pool, but not more than 10
buffers. The minimum value is 2 buffers; the maximum value can be
as large as the buffer pool.
You can override the number of buffers to be written
asynchronously by defining the logical name RDM$BIND_BATCH_MAX.
For information about how to set the values, see the Oracle Rdb7
Guide to Database Performance and Tuning.
4.3.62 – MAXIMUM extent pages
Syntax option:
MAXIMUM OF max-pages PAGES
Specifies the maximum number of pages of each extent. The default
is 9999 pages.
4.3.63 – METADATA_CHANGES
Syntax options:
METADATA CHANGES ARE ENABLED | METADATA CHANGES ARE DISABLED
Specifies whether or not data definition changes are allowed
to the database. This attribute becomes effective at the
next database attach and affects all ALTER, CREATE, and DROP
statements (except ALTER DATABASE, which is needed for database
tuning) and the GRANT, REVOKE, TRUNCATE TABLE, COMMENT ON and
RENAME statements. For example:
SQL> CREATE DATABASE FILENAME sample
cont> METADATA CHANGES ARE DISABLED;
SQL> CREATE TABLE t (a INTEGER);
SQL> DISCONNECT ALL;
SQL> ATTACH 'FILENAME sample';
SQL> CREATE TABLE s (b INTEGER);
%RDB-E-NO_META_UPDATE, metadata update failed
-RDMS-E-NOMETADATA, metadata operations are disabled
The METADATA CHANGES ARE DISABLED clause prevents data definition
changes to the database. If you specify this clause in the
CREATE DATABASE statement, system index compression is implicitly
enabled.
The METADATA CHANGES ARE ENABLED clause allows data definition
changes to the database by users granted the DBADMIN privilege.
METADATA CHANGES ARE ENABLED is the default.
4.3.64 – MINIMUM extent pages
Syntax option:
MINIMUM OF min-pages PAGES
Specifies the minimum number of pages of each extent. The default
is 99 pages.
4.3.65 – MULTISCHEMA
Syntax options:
MULTISCHEMA IS ON | MULTISCHEMA IS OFF
Specifies the multischema attribute for the database. You must
specify the multischema attribute for your database to create
multiple schemas and store them in catalogs. Each time you attach
to a database created with the multischema attribute, you can
specify whether you want multischema naming enabled or disabled
for subsequent statements. For more information on multischema
naming, see the User_Supplied_Names HELP topic.
If you prefer to access a database created with the multischema
attribute as though it were single-schema database, you can turn
off multischema naming using the MULTISCHEMA IS OFF clause in the
ATTACH or DECLARE ALIAS statement.
If you have turned off the multischema attribute, you can enable
it again using the MULTISCHEMA IS ON clause in the ATTACH or
DECLARE ALIAS statement. You can use multischema naming only
when you are attached to a database that was created with the
multischema attribute. For more information, see the ATTACH
statement.
Multischema naming is disabled by default.
4.3.66 – MULTITHREAD_AREA_ADDITIONS
Specifies whether Oracle Rdb creates all storage areas in
parallel, creates a specified number in parallel, or creates
areas serially.
This clause lets you determine the number of storage areas
to be created in parallel, possibly saving time during the
initial database creation. However, if you specify a large
number of storage areas and many areas share the same device,
multithreading may cause excessive disk head movement, which may
result in the storage area creation taking longer than if the
areas were created serially. In addition, if you specify a large
number of storage areas, you may exceed process quotas, resulting
in the database creation failing.
This setting is not saved as a permanent database attribute. It
is used only during the execution of the CREATE DATABASE, ALTER
DATABASE, or IMPORT statements.
If you do not specify the MULTITHREAD AREA ADDITIONS clause, the
default is to create one storage area at a time. If you specify
the MULTITHREAD AREA ADDITIONS clause, but do not specify an
option, the default is all areas are created in parallel.
4.3.67 – NATIONAL_CHARACTER_SET
Specifies the database national character set when you create a
database. For a list of allowable national character set names,
see Supported Character Sets.
4.3.68 – ncs-name
The OpenVMS National Character Set (NCS) utility provides a
set of predefined collating sequences and also lets you define
collating sequences of your own. In the default NCS library,
SYS$LIBRARY:NCS$LIBRARY, ncs-name is the name of a collating
sequence or ncs-name is the name of the collating sequence in
the NCS library specified by the library-name argument. (In most
cases, it is simplest to make the collating sequence name the
same as the ncs-name, for example, CREATE DATABASE . . . COLLATING
SEQUENCE IS SPANISH SPANISH.) The COLLATING SEQUENCE clause
accepts both predefined and user-defined NCS collating sequences.
If you omit the COLLATING SEQUENCE clause in the CREATE DATABASE
statement at database definition time, the default sequence is
the DEC Multinational Character Set (MCS).
4.3.69 – NO_LOCATION
This is a subclause of other clauses and has different effects,
depending upon the clause in which it is used, as follows:
o In the row-cache-options clause
Removes the location previously specified in a LOCATION IS
clause for the row cache. If you specify NO LOCATION, the
row cache location becomes the directory of the database root
file.
The LOCATION clause of the CREATE CACHE, ADD CACHE, or ALTER
CACHE clause overrides this location, which is the default for
the database.
o In a CREATE CACHE, ADD CACHE, or ALTER CACHE clause (row-
cache-params1 clause)
Removes the location previously specified in a LOCATION IS
clause for the row cache backing file. If you specify NO
LOCATION, the row cache location becomes the directory of
the database root file.
This clause is ignored if the row cache is defined to
checkpoint to the database.
4.3.70 – NO_ROW_CACHE
Specifies that the database default is not to assign a row cache
to all storage areas in the database. You cannot specify the NO
ROW CACHE clause if you specify the CACHE USING clause.
Alter the storage area and name a row cache to override the
database default. Only one row cache is allowed for each storage
area.
If you do not specify the CACHE USING clause or the NO ROW CACHE
clause, NO ROW CACHE is the default for the database.
4.3.71 – NOTIFY
Syntax options:
NOTIFY IS ENABLED | NOTIFY IS DISABLED
Specifies whether system notification is enabled or disabled.
When the system notification is enabled, the system is notified
(using the OpenVMS OPCOM facility) in the event of events such as
running out of disk space for a journal.
If you specify the NOTIFY IS ENABLED clause and do not specify
the ALERT OPERATOR clause, the operator classes used are CENTRAL
and CLUSTER. To specify other operator classes, use the ALERT
OPERATOR clause.
The NOTIFY IS ENABLED clause replaces any operator classes set by
the RMU Set After_Journal Notify command.
The default is disabled.
4.3.72 – NUMBER global buffers
Syntax option:
NUMBER IS number-glo-buffers
Specifies the default number of global buffers to be used on
one node when global buffers are enabled. This number appears as
"global buffer count" in RMU Dump command output. Base this value
on the database users' needs and the number of attachments. The
default is the maximum number of attachments multiplied by 5.
NOTE
Do not confuse the NUMBER IS parameter with the NUMBER OF
BUFFERS IS parameter. The NUMBER OF BUFFERS IS parameter
determines the default number of buffers Oracle Rdb
allocates to each user process that attaches to the
database. The NUMBER OF BUFFERS IS parameter applies to, and
has the same meaning for, both local and global buffering.
The NUMBER IS parameter has meaning only within the context
of global buffering.
You can override the default number of user-allocated buffers by
defining a value for the logical name RDM$BIND_BUFFERS. For more
information, see the Oracle Rdb7 Guide to Database Performance
and Tuning.
Although you can change the NUMBER IS parameter on line, the
change does not take effect until the next time the database is
opened.
4.3.73 – NUMBER_OF_BUFFERS
Specifies the number of buffers SQL allocates for each attach
to this database. This number is displayed as the "default
database buffer count" in the output from the RMU Dump command.
The default buffer count applies to local and global buffers.
Specify an unsigned integer greater than or equal to 2 and less
than or equal to 32,767. The default is 20 buffers.
4.3.74 – NUMBER_OF_CLUSTER_NODES
Syntax option:
NUMBER OF CLUSTER NODES number-nodes
Sets the upper limit on the maximum number of VMS cluster nodes
from which users can access the shared database. The default
is 16 nodes. The range is 1 to 96 nodes. The actual maximum
limit is the current VMS cluster node limit set by your system
administrator.
The Oracle Rdb root file data structures (.rdb) are mapped to
shared memory. Each such shared memory copy is known as an Rdb
instance. When there is only one copy of shared memory containing
root file information, several optimizations are enabled to
reduce locking and root file I/O during database activity. To
enable these optimizations, specify NUMBER OF CLUSTER NODES 1, or
use the SINGLE INSTANCE clause.
MULTIPLE INSTANCE means that the Oracle Rdb root file data
structures are mapped on different system and are kept consistent
through disk I/O. Such systems can not benefit from single
instance optimizations. MULTIPLE INSTANCE is the default.
4.3.75 – NUMBER_OF_RECOVERY_BUFFERS
Specifies the number of buffers allocated to the automatic
recovery process that Oracle Rdb initiates after a system or
process failure. This recovery process uses the recovery-unit
journal (.ruj) file.
Specify an unsigned integer greater than or equal to 2 and less
than or equal to 32,767. The default value for the NUMBER OF
RECOVERY BUFFERS parameter is 20 buffers. If you have a large,
multifile database and you are working on a system with a large
amount of memory, specify a large number of buffers. This result
is faster recovery time. However, make sure your buffer pool does
not exceed the amount of memory you can allocate for the pool.
if the number of buffers is too large for the amount of memory on
your system, the system may be forced to perform virtual paging
of the buffer pool. This can slow performance time because the
operating system must perform the virtual paging of the buffer
pool in addition to reading database pages. You may want to
experiment to determine the optimal number of buffers for your
database.
Use the NUMBER OF RECOVERY BUFFERS option to increase the number
of buffers allocated to the recovery process.
SQL> CREATE DATABASE FILENAME personnel
cont> NUMBER OF RECOVERY BUFFERS 150;
This option is used only if the NUMBER OF RECOVERY BUFFERS value
is larger than the NUMBER OF BUFFERS value. For more information,
see the Oracle Rdb Guide to Database Maintenance.
4.3.76 – NUMBER_OF_SWEEP_ROWS
Syntax option:
NUMBER OF SWEEP ROWS IS n
Specifies the number of modified rows that will be written from
the row cache back to the database by the row cache server (RCS)
process during a sweep operation. When the RCS is notified that
a cache is "full" of modified data, the RCS starts a sweep to
make space available in the cache for subsequent transactions
to be able to insert rows into the cache. Oracle Corporation
recommends that you initially specify the number of sweep rows
to be approximately 5 percent of the total number of rows in
the cache. Then monitor performance and adjust the number of
sweep rows, if necessary. Allowable values must be in the range 2
through 524288. If not specified, the default is 3,000 rows.
4.3.77 – NUMBER_OF_USERS
Specifies the maximum number of users allowed to access the
database at one time. The default is 50 users. After the maximum
is reached, the next user who tries to invoke the database
receives an error message and must wait. The maximum number of
users you can specify is 16368, and the minimum is 1 user.
Note that "number of users" is defined as the number of active
attachments to the database. Thus, if a single process runs
one program but that program performs 12 attach operations, the
process is responsible for 12 active users as defined by this
argument.
4.3.78 – OPEN
Syntax options:
OPEN IS MANUAL | OPEN IS AUTOMATIC
Specifies whether or not the database must be explicitly opened
before users can attach to it. The default, OPEN IS AUTOMATIC,
means that any user can open a previously unopened or a closed
database by attaching to it and executing a statement. The
OPEN IS MANUAL option means that a privileged user must issue
an explicit OPEN statement through Oracle RMU, the Oracle
Rdb management utility, before other users can attach to the
database.
The OPEN IS MANUAL option limits access to databases. You must
have the DBADM privilege to attach to the database.
You receive an error message if you specify both OPEN IS
AUTOMATIC and OPEN IS MANUAL options.
You can modify the OPEN IS option through the ALTER DATABASE
statement.
4.3.79 – PAGE_FORMAT
Syntax options:
PAGE FORMAT IS UNIFORM | PAGE FORMAT IS MIXED
Specifies the on-disk structure for the storage area.
o The default is PAGE FORMAT IS UNIFORM and creates a storage
area data file that is divided into clumps. Clump size, which
is derived from buffer size, is 3 pages by default. A set
of clumps forms a logical area that can contain rows from
a single table only. For more information on uniform page
formats, see the Oracle Rdb7 Guide to Database Performance and
Tuning.
Uniform page format storage areas generally give the best
performance if the tables in the storage area are subject to a
wide range of queries.
o The PAGE FORMAT IS MIXED clause creates a storage area with
a format that lets rows from more than one table reside on
or near a particular page of the storage area data file. This
is useful for storing related rows from different tables on
the same page of the data file. For storage areas subject to
repeated queries that retrieve those related rows, a mixed
page format can greatly reduce I/O overhead if the mix of
rows on the page is carefully controlled. However, mixed page
format storage areas degrade performance if the mix of rows
on the page is not suited for the queries made against the
storage area.
NOTE
The main storage area created by the CREATE DATABASE
statement, called RDB$SYSTEM, must have uniform pages. If
you specify PAGE FORMAT IS MIXED as a default storage area
parameter, SQL generates a warning message and overrides
that default when it creates the RDB$SYSTEM storage area.
4.3.80 – PAGE_SIZE
Syntax option:
PAGE SIZE IS page-blocks BLOCKS
The size in blocks of each database page. Page size is allocated
in 512-byte blocks. The default is 2 blocks (1024 bytes). If your
largest row is larger than approximately 950 bytes, allocate more
blocks per page to prevent fragmented rows. If you specify a page
size larger than the buffer size, an error message is returned.
4.3.81 – PAGE_TRANSFER
Syntax options:
PAGE TRANSFER VIA DISK | PAGE TRANSFER VIA MEMORY
Specifies whether Oracle Rdb transfers (flushes) pages to disk or
to memory.
When you specify PAGE TRANSFER VIA MEMORY, processes on a single
node can share and update database pages in memory without
transferring the pages to disk. It is not necessary for a process
to write a modified page to disk before another process accesses
the page.
The default is to DISK. If you specify PAGE TRANSFER VIA MEMORY,
the database must have the following characteristics:
o The NUMBER OF CLUSTER NODES must equal one, or SINGLE INSTANCE
must be specified in the NUMBER of CLUSTER NODES clause.
o GLOBAL BUFFERS must be enabled.
o After-image journaling must be enabled.
o FAST COMMIT must be enabled.
If the database does not have these characteristics, Oracle Rdb
will perform page transfers via disk.
For more information about page transfers, see the Oracle Rdb7
Guide to Database Performance and Tuning.
4.3.82 – PATHNAME path name
The repository path name for the repository directory where the
database definition is stored.
Specify one of the following:
o A full repository path name, such as CDD$TOP.SQL.DEPT3
o A relative repository path name, such as DEPT3
o A logical name that refers to a full or relative repository
path name
If you use a relative path name, CDD$DEFAULT must be defined
as all the path name segments preceding the relative path name.
For example, define CDD$DEFAULT as CDD$TOP.SQL, and then use the
relative path name DEPT3.
SQL> SHOW DICTIONARY
The current data dictionary is CDD$TOP.SQL
SQL> CREATE DATABASE ALIAS PERSONNEL PATHNAME DEPT3;
There is no default path name. If you do not specify a repository
path name for the database, SQL does not store database
definitions in the repository. Subsequent data definitions cannot
use the repository. However, Oracle Rdb recommends that you do
specify a repository path name when you create a database. For
more information, see the Oracle Rdb SQL Reference Manual.
If you use the PATHNAME argument and your system does not have
the repository, SQL ignores the argument.
When you use the PATHNAME argument, the repository associates
the path name with the file specification exactly as given in the
CREATE DATABASE statement. If that file specification is a file
name, not a logical name, you cannot alter or delete the database
by specifying the path name unless the database root file is in
the current, default working directory.
4.3.83 – PERCENT extent growth
Syntax option:
PERCENT GROWTH IS growth
Specifies the percent growth of each extent. The default is 20
percent growth.
4.3.84 – PRESTARTED_TRANSACTIONS
Syntax options:
PRESTARTED TRANSACTIONS ARE ENABLED
PRESTARTED TRANSACTIONS ARE DISABLED
Enables or disables the prestarting of transactions.
Note that the keyword ON, available in previous versions, is
synonymous with ENABLED, and the OFF keyword is synonymous with
the DISABLED keyword.
This clause is used to establish a permanent database setting for
prestarted transactions. In prior versions, this clause was only
used to temporarily set the mode for prestarted transaction for
the implicit attach performed by the CREATE DATABASE and IMPORT
DATABASE statements.
The prestart-trans-options can be one of the following clauses:
o WAIT n SECONDS FOR TIMEOUT
The n represents the number of seconds to wait before
aborting the prestarted transaction. Timing out the prestarted
transaction may prevent snapshot file growth in environments
where servers stay attached to the database with long periods
of inactivity.
o WAIT n MINUTES FOR TIMEOUT
The n represents the number of minutes to wait before aborting
the prestarted transaction.
o NO TIMEOUT
This is the default for a prestarted transaction.
Syntax options:
PRESTARTED TRANSACTIONS ARE ON | PRESTARTED TRANSACTIONS ARE OFF
4.3.85 – PROTECTION
Syntax options:
PROTECTION IS ANSI | PROTECTION IS ACLS
Specifies whether the database root file will be invoked with
ACL-style or ANSI/ISO-style privileges. If no protection clause
is specified, the default is ACL-style privileges.
For ACL-style databases, the access privilege set is order-
dependent. When a user tries to perform an operation on a
database, SQL reads the associated access privilege set, called
the access control list (ACL), from top to bottom, comparing
the identifier of the user with each entry. As soon as SQL finds
a match, it grants the rights listed in that entry and stops
the search. All identifiers that do not match a previous entry
"fall through" to the entry [ *,*] (equivalent to the SQL keyword
PUBLIC). The default access for PUBLIC is NONE.
See the GRANT statement and the REVOKE statement for more
information on ACL-style privileges.
For ANSI/ISO-style databases, the access privilege set is
not order-dependent. The user matches the entry in the access
privilege set; gets whatever privileges have been granted on the
database, table, or column; and gets the privileges defined for
PUBLIC. A user without an entry in the access privilege set gets
only the privileges defined for PUBLIC. There is always an access
privilege entry for PUBLIC, even if that entry has no access to
the database, table, or column.
ANSI/ISO-style databases grant access to the creator when an
object is created. Because only the creator is granted access
to the newly created object, additional access must be granted
explicitly.
See the GRANT_ANSI statement and the REVOKE_ANSI statement for
more information on ANSI/ISO-style privileges.
You can change the PROTECTION IS parameter by using the IMPORT
statement. See the IMPORT statement for more information.
4.3.86 – RECOVERY_JOURNAL_(BUFFER_MEMORY)
Syntax options:
BUFFER MEMORY IS LOCAL
BUFFER MEMORY IS GLOBAL
Specifies whether RUJ buffers will be allocated in global or local
memory.
The RUJ buffers used by each process are normally allocated in
local virtual memory. With the introduction of row caching, these
buffers now can be assigned to a shared global section (global
memory) on OpenVMS, so that the recovery process can process this
in-memory buffer and possibly avoid a disk access.
You can define this buffer memory to be global to improve row
caching performance for recovery. If row caching is disabled,
then buffer memory is always local.
4.3.87 – RECOVERY_JOURNAL_(LOCATION)
Syntax options:
RECOVERY JOURNAL (LOCATION IS directory-spec)
Specifies the location in which the recovery-unit journal (.ruj)
file is written. Do not include node names, file names, or
process-concealed logical names in the directory-spec. Single
quotation marks are required around the directory-spec. This
clause overrides the RDMS$RUJ logical name.
If this clause is omitted, then NO LOCATION is assumed.
Following is an example using this clause:
SQL> ALTER DATABASE FILENAME SAMPLE
cont> RECOVERY JOURNAL (LOCATION IS 'SQL_USER1:[DBDIR.RECOVER]')
See the Oracle Rdb Guide to Database Maintenance for more
information on recovery-unit journal files.
4.3.88 – RECOVERY_JOURNAL_(NO_LOCATION)
If you specify NO LOCATION, the recovery journal uses the
current user's login device and the directory [RDM$RUJ]. See
the Oracle Rdb Guide to Database Maintenance for more information
on recovery-unit journal files.
4.3.89 – RESERVE n CACHE SLOTS
Specifies the number of row caches for which slots are reserved
in the database.
You can use the RESERVE CACHE SLOTS clause to reserve slots in
the database root file for future use by the ADD CACHE clause
of the ALTER DATABASE statement. You can only add row caches if
row cache slots are available. Slots become available after a
DROP CACHE clause or a RESERVE CACHE SLOTS clause of the ALTER
DATABASE statement.
The number of reserved slots for row caches cannot be decreased
once the RESERVE clause is issued. If you reserve 10 slots and
later reserve 5 slots, you have a total of 15 reserved slots for
row caches
If you do not specify the RESERVE CACHE SLOTS clause, the default
number of row caches is one.
Reserving row cache slots is an offline operation (requiring
exclusive database access). See the CREATE CACHE clause for more
information.
4.3.90 – RESERVE n JOURNALS
Specifies the number of journal files for which slots are
reserved in the database. If your database is not a multifile
database, you cannot reserve additional slots later using the
ALTER DATABASE statement.
You must reserve slots before you can add journal files to the
database.
See the ALTER DATABASE statement for more information about
adding journal files and enabling the journaling feature.
The following SQL statements create a multifile database and
reserve 5 slots for future journal files.
SQL> CREATE DATABASE FILENAME test
cont> RESERVE 5 JOURNALS
cont> CREATE STORAGE AREA sa_one
cont> ALLOCATION IS 10 PAGES;
4.3.91 – RESERVE n SEQUENCES
Specifies the number of sequences for which slots are reserved in
the database. Sequences are reserved in multiples of 32. Thus, if
you specify a value less than 32 for n, 32 slots are reserved. If
you specify a value of 33, 64 slots are reserved, and so on.
You can use the RESERVE SEQUENCES clause to reserve slots in
the database root file for future use by the CREATE SEQUENCE
statement. Sequences can be created only if sequence slots are
available. Slots become available after a DROP SEQUENCE statement
or a RESERVE SEQUENCES clause of the ALTER DATABASE statement is
executed.
The number of reserved slots for sequences cannot be decreased.
If you do not specify the RESERVED SEQUENCES clause, the default
number of sequence slots is 32.
4.3.92 – RESERVE n STORAGE AREAS
Specifies the number of storage areas for which slots are
reserved in the database. The number of slots for storage areas
must be a positive number greater than zero.
You can use the RESERVE STORAGE AREA clause to reserve slots
in the database root file for future use by the ADD STORAGE
AREA clause of the ALTER DATABASE statement. Storage areas can
be added only if there are storage area slots available. Slots
become available after a DROP STORAGE AREA clause or a RESERVE
STORAGE AREA clause.
The number of reserved slots for storage areas cannot be
decreased once the RESERVE clause is issued. If you reserve 5
slots and later reserve 10 slots, you have a total of 15 reserved
slots for storage areas.
If you do not specify the RESERVE STORAGE AREA clause, the
default number of storage areas is zero.
4.3.93 – RESTRICTED_ACCESS
Syntax option:
RESTRICTED ACCESS | NO RESTRICTED ACCESS
Restricts access to the database. This allows you to access the
database but locks out all other users until you disconnect from
the database. Setting restricted access to the database requires
DBADM privileges.
The default is NO RESTRICTED ACCESS.
4.3.94 – root-file-params
Parameters that control the characteristics of the database root
file or characteristics stored in the database root file that
apply to the entire database. You can specify these parameters
for either single-file or multifile databases.
Some database root file parameters specified in the CREATE
DATABASE statement cannot be changed with the ALTER DATABASE
statement. To change these database root file parameters,
you must use the EXPORT and IMPORT statements. See the EXPORT
statement and the IMPORT statement for information on exporting
and importing your database.
4.3.95 – ROW_CACHE
Syntax options:
ROW CACHE IS ENABLED | ROW CACHE IS DISABLED
Specifies whether or not you want Oracle Rdb to enable the row
caching feature.
When a database is created or is converted from a previous
version of Oracle Rdb without specifying row cache support, the
default is ROW CACHE IS DISABLED. Enabling row cache support does
not affect database operations until a row cache is created and
assigned to one or more storage areas.
When the row caching feature is disabled, all previously created
and assigned row cache definitions remain in existence for future
use when the row caching feature is enabled.
The following conditions must be true in order to use row caches:
o The number of cluster nodes is one
o After-image journaling is enabled
o Fast commit is enabled
o One or more cache slots are reserved
o Row caching is enabled
Use the RMU Dump Header command to check if you have met the
requirements for using row caches. The following command output
displays a warning for every requirement that is not met:
.
.
.
Row Caches...
- Active row cache count is 0
- Reserved row cache count is 1
- Sweep interval is 1 second
- Default cache file directory is ""
- WARNING: Maximum node count is 16 instead of 1
- WARNING: After-image journaling is disabled
- WARNING: Fast commit is disabled
.
.
.
4.3.96 – ROWID_SCOPE
Syntax options:
ROWID SCOPE IS ATTACH | ROWID SCOPE IS TRANSACTION
The ROWID keyword is a synonym for the DBKEY keyword. See the
DBKEY_SCOPE argument for more information.
4.3.97 – SECURITY_CHECKING
Traditionally, Oracle Rdb has performed security checking using
the operating system security layer (for example, the UIC and
rights identifiers of the OpenVMS operating system).
The access control list (ACL) information stored in the database
contains a granted privilege mask and a set of users represented
by a unique integer (for example, a UIC).
There are two modes of security checking:
1. SECURITY CHECKING IS EXTERNAL
This is the default. External security checking recognizes
database users (created with the SQL CREATE USER statement)
as operating system user identification codes (UICs) and roles
as special rights identifiers or groups. PERSONA support is
enabled or disabled as follows:
o SECURITY CHECKING IS EXTERNAL (PERSONA SUPPORT IS ENABLED)
Enables the full impersonation of an OpenVMS user. This
means the UIC and the granted right identifiers are used to
check access control list permissions.
o SECURITY CHECKING IS EXTERNAL (PERSONA SUPPORT IS DISABLED)
Disables the full impersonation of an OpenVMS user. Only
the UIC is used to check access control list permissions.
This is the default for a new database, or for a database
converted from a prior version of Oracle Rdb.
2. SECURITY CHECKING IS INTERNAL
In this mode, Oracle Rdb records users (username and UIC) and
roles (rights identifiers) in the database. The CREATE USER
and CREATE ROLE statements perform this action explicitly, and
GRANT will perform this implicitly. This type of database can
now be moved to another system and is only dependent on the
names of the users and roles.
o SECURITY CHECKING IS INTERNAL (ACCOUNT CHECK IS ENABLED)
The ACCOUNT CHECK clause ensures that Oracle Rdb validates
the current database user with the user name (such as
defined with an SQL CREATE USER statement) stored in the
database. This prevents different users with the same name
from accessing the database. Therefore, this clause might
prevent a breach in security.
The ACCOUNT CHECK IS ENABLED clause on OpenVMS forces the
user session to have the same user name and UIC as recorded
in the database.
o SECURITY CHECKING IS INTERNAL (ACCOUNT CHECK IS DISABLED)
If you specify the ACCOUNT CHECK IS DISABLED clause, then
a user with a matching UIC (also called a profile-id) is
considered the same as the user even if his or her user
name is different. This allows support for multiple OpenVMS
users with the same UIC.
4.3.98 – SEGMENTED_STRING_STORAGE_AREA
Another name for LIST STORAGE AREA.
4.3.99 – SET_TRANSACTION_MODES
Enables only the modes specified, disabling all other previously
defined modes. For example, if a database is to be used for read-
only access and you want to disable all other transaction modes,
use the following statement:
SQL> CREATE DATABASE FILENAME mf_personnel
cont> SET TRANSACTION MODES (READ ONLY);
If not specified, the default transaction mode is ALL.
Specifying a negated transaction mode or specifying NONE disables
all transaction usage. Disabling all transaction usage would be
useful when, for example, you want to perform major restructuring
of the physical database. Execute the ALTER DATABASE statement
to re-enable transaction modes or use Oracle RMU, the Oracle Rdb
management utility.
4.3.100 – SHARED_MEMORY_IS_PROCESS_RESIDENT
The SHARED MEMORY clause determines whether database root global
sections (including global buffers when enabled) or whether the
cache global sections are created in system space or process
space. The RESIDENT option extends the PROCESS option by making
the global section memory resident.
4.3.101 – SHARED_MEMORY
Syntax options:
SHARED MEMORY IS SYSTEM | SHARED MEMORY IS PROCESS
Determines whether database root global sections (including
global buffers when enabled) are created in system space or
process space. The default is PROCESS.
When you use global sections created in the process space, you
and other users share physical memory and the OpenVMS operating
system maps a row cache to a private address space for each user.
As a result, all users are limited by the free virtual address
range and each use a percentage of memory in overhead. If many
users are accessing the database, the overhead can be high.
4.3.102 – SNAPSHOT_ALLOCATION
Syntax option:
SNAPSHOT ALLOCATION IS snp-pages PAGES
Changes the number of pages allocated for the snapshot file. The
default is 100 pages. If you have disabled the snapshot file, you
can set the snapshot allocation to 0 pages.
4.3.103 – SNAPSHOT_CHECKSUM_ALLOCATION
Syntax option:
SNAPSHOT CHECKSUM ALLOCATION IS ENABLED
SNAPSHOT CHECKSUM ALLOCATION IS DISABLED
See the CHECKSUM ALLOCATION clause for details.
4.3.104 – SNAPSHOT_IS_ENABLED
Syntax options:
SNAPSHOT IS ENABLED IMMEDIATE | SNAPSHOT IS ENABLED DEFERRED
Specifies when read/write transactions write database changes
they make to the snapshot file used by read-only transactions.
The default is ENABLED IMMEDIATE and causes read/write
transactions to write copies of rows they modify to the snapshot
file, regardless of whether or not a read-only transaction is
active.
The ENABLED DEFERRED option lets read/write transactions
avoid writing copies of rows they modify to the snapshot file
(unless a read-only transaction is already active). Deferring
snapshot writing in this manner improves the performance for
the read/write transaction. However, read-only transactions that
attempt to start after an active read/write transaction starts
must wait for all active read/write users to complete their
transactions.
4.3.105 – SNAPSHOT_EXTENT
Syntax options:
SNAPSHOT EXTENT IS extent-pages
SNAPSHOT EXTENT IS (extension-options)
Specifies the number of pages of each snapshot or storage area file
extent. The default extent for storage area files is 99 pages.
Specify a number of pages for simple control over the extension.
For greater control, and particularly for multivolume databases,
use the MINIMUM, MAXIMUM, and PERCENT GROWTH extension options
instead.
If you use the MINIMUM, MAXIMUM, and PERCENT GROWTH parameters,
you must enclose them in parentheses.
4.3.106 – SNAPSHOT_FILENAME
Provides a separate file specification for the storage area
snapshot file. The SNAPSHOT FILENAME argument can only be used
with a multifile database.
In a multifile database, the file specification is used for the
RDB$SYSTEM storage area snapshot file, unless the CREATE DATABASE
statement contains a CREATE STORAGE AREA RDB$SYSTEM clause that
contains its own SNAPSHOT FILENAME clause.
Do not specify a file extension other than .snp to the snapshot
file specification. Oracle Rdb will assign the extension .snp
to the file specification, even if you specify an alternate
extension.
If you omit the SNAPSHOT FILENAME argument, the .snp file gets
the same device, directory, and file name as the database root
file.
4.3.107 – SNAPSHOT_IS_DISABLED
Specifies that snapshot writing is disabled. Snapshot writing
is enabled by default. If you specify the SNAPSHOT IS DISABLED
option, you cannot specify either of the SNAPSHOT IS ENABLED
options, and you cannot back up the database on line. You can,
however, continue to set snapshot options in the event that you
will enable snapshots in the future. SQL warns you of a possible
conflict in the setting of snapshot options while snapshots are
disabled, but SQL will execute the statement.
4.3.108 – SNAPSHOT_IS_ENABLED
Syntax options:
SNAPSHOT IS ENABLED IMMEDIATE | SNAPSHOT IS ENABLED DEFERRED
Specifies when read/write transactions write database changes
they make to the snapshot file used by read-only transactions.
The default is ENABLED IMMEDIATE and causes read/write
transactions to write copies of rows they modify to the snapshot
file, regardless of whether or not a read-only transaction is
active.
The ENABLED DEFERRED option lets read/write transactions
avoid writing copies of rows they modify to the snapshot file
(unless a read-only transaction is already active). Deferring
snapshot writing in this manner improves the performance for
the read/write transaction. However, read-only transactions that
attempt to start after an active read/write transaction starts
must wait for all active read/write users to complete their
transactions.
4.3.109 – STATISTICS_COLLECTION
Syntax options:
STATISTICS COLLECTION IS ENABLED
STATISTICS COLLECTION IS DISABLED
Specifies whether the collection of statistics for the database is
enabled or disabled. When you disable statistics for the database,
statistics are not displayed for any of the processes attached to
the database. Statistics are displayed using the RMU Show Statistics
command.
The default is STATISTICS COLLECTION IS ENABLED. You can disable
statistics using the ALTER DATABASE and IMPORT statements.
For more information on the RMU Show Statistics command, see the
Oracle RMU Reference Manual.
You can enable statistics collection by defining the logical
name RDM$BIND_STATS_ENABLED. For more information about when to
use statistics collection, see the Oracle Rdb7 Guide to Database
Performance and Tuning.
4.3.110 – storage-area-params
Parameters that control the characteristics of database storage
area files. You can specify most storage area parameters for
either single-file or multifile databases, but the effect of the
clauses differs.
o For single-file databases, the storage area parameters
specify the characteristics for the single storage area in
the database.
o For multifile databases, the storage area parameters specify
a set of default values for any storage areas created by
the CREATE DATABASE statement that do not specify their own
values for the same parameters. The default values apply to
the RDB$SYSTEM storage area, plus any others named in CREATE
STORAGE AREA database elements.
The CREATE STORAGE AREA clauses in a CREATE DATABASE statement
can override these default values. The default values do
not apply to any storage areas created later with the ALTER
DATABASE statement.
4.3.111 – SWEEP_INTERVAL
Syntax option:
SWEEP INTERVAL IS n SECONDS
Specifies the interval, in seconds, between each Record Cache
Server (RCS) sweep. Allowable values must be in the range from 1
second to 3600 seconds (1 hour). The default is 1.
The Record Cache Server (RCS) is a detached server process
automatically invoked by the monitor when row caching is active.
A sweep is one full pass through all active row cache areas to
write modified rows back to the database storage areas.
4.3.112 – SYSTEM_INDEX_(COMPRESSION_IS_._._._)
This clause allows the database creator choose compressed system
indexes. The default is SYSTEM INDEX (COMPRESSION IS DISABLED).
If enabled Oracle Rdb uses run-length compression, which
compresses any sequences of two or more spaces from text data
types or two or more binary zeros from non-character data
types. Compressing system indexes results in reduced storage
and improved I/O. Unless your applications frequently perform
concurrent data definition, you should compress system indexes.
Once you create a database specifying the SYSTEM INDEX
(COMPRESSION IS . . . ) clause, you only can change it using the
EXPORT and IMPORT statements. You cannot alter the database to
change the compression mode.
The clause SYSTEM INDEX COMPRESSION IS is identical to this
clause and is retained for compatibility with older versions
of Oracle Rdb.
4.3.113 – SYSTEM_INDEX_(PREFIX_CARDINALITY_COLLECTION_IS_._._._)
This clause allows the database creator to adjust the prefix
cardinality collection for system indices. Refer to the CREATE
INDEX Statement for more details on these clauses. The default is
PREFIX CARDINALITY COLLECTION IS ENABLED.
4.3.114 – SYSTEM_INDEX_(TYPE_IS_._._._)
This clause allows the database creator choose between SORTED or
SORTED RANKED indices for system table. The default is SORTED.
SORTED RANKED indices have advantages in space usage and reduced
CPU during DDL operations for those system indices with many
duplicates.
4.3.115 – SYNONYMS_ARE_ENABLED
Adds the optional system table RDB$OBJECT_SYNONYMS that is
used for the CREATE SYNONYM, ALTER . . . RENAME TO and RENAME
statements. The default if omitted is disabled.
4.3.116 – THRESHOLD pages option
Syntax option:
THRESHOLD IS number-pages PAGES
This number represents the number of sequential buffer accesses
that must be detected before prefetching is started. The default
is four buffers.
If you specify the THRESHOLD option, you must have also specified
the DETECTED ASYNC PREFETCH clause. You receive an error if you
attempt to specify the THRESHOLD option with the ASYNC PREFETCH
clause.
4.3.117 – THRESHOLDS values
Syntax options
THRESHOLDS ARE ( val1 [,val2 [,val3] ] )
Specifies one, two, or three threshold values. The threshold
values represent a fullness percentage on a data page and
establish four possible ranges of guaranteed free space on the
data pages. When a data page reaches the percentage defined by a
given threshold value, the space area management (SPAM) entry for
the data page is updated to reflect the new fullness percentage
and its remaining free space.
The default thresholds are 70, 85, and 95 percent. If you
specify only one or two values, unspecified values default to
100 percent.
You cannot specify the THRESHOLDS storage area parameter for
single-file databases, and you cannot specify THRESHOLDS unless
you also explicitly specify PAGE FORMAT IS MIXED. To specify
thresholds for uniform storage areas, use the CREATE STORAGE MAP
statement.
For more information about setting space area management
parameters, see the Oracle Rdb Guide to Database Maintenance.
4.3.118 – USER username
Syntax option:
USER 'username'
A character string literal that specifies the operating system
user name that the database system uses for privilege checking.
This clause also sets the value of the SYSTEM_USER value
expression.
4.3.119 – USER_LIMIT
Syntax option:
USER LIMIT IS max-glo-buffers
Specifies the maximum number of global buffers each attach
allocates. Because global buffer pools are shared by all
attachments, you must define an upper limit on how many global
buffers a single attach can allocate. This limit prevents a user
from defining the RDM$BIND_BUFFERS logical name to use all the
buffers in the global buffer pool. (The behavior of RDM$BIND_
BUFFERS which depends on whether you are using local or global
buffers, is explained in the Oracle Rdb7 Guide to Database
Performance and Tuning.)
The user limit cannot be greater than the total number of global
buffers. The default is 5 buffers. The user limit appears as
"maximum global buffer count per user" in RMU Dump command
output.
Decide the maximum number of global buffers a process can
allocate per attach by dividing the total number of global
buffers set by the NUMBER IS clause by the total number of
attachments for which you want to guarantee access to the
database. For example, if the total number of global buffers is
200 and you want to guarantee at least 10 attachments access to
the database, set the maximum number of global buffers per attach
to 20.
In general, when you use global buffers, you should set the
maximum global buffer count per user higher than the default
database buffer count. For maximum performance on a VMScluster
system, tune the two global buffer parameters on each node in
the cluster using the RMU Open command with the Global_Buffers
qualifier.
Although you can change the USER LIMIT IS parameter on line, the
change does not take effect until the next time the database is
opened.
The NUMBER IS and USER LIMIT IS parameters are the only two
buffer parameters specific to global buffers. They are,
therefore, in effect on a per node rather than a per process
basis.
4.3.120 – USING password
Syntax option:
USING 'password'
A character string literal that specifies the user's password for
the user name specified in the USER clause.
4.3.121 – txn-modes
Specifies the transaction modes for the database.
Mode Description
ALL All modes are enabled.
NONE No modes are enabled.
Transaction Types
[NO]READ Allows read-only transactions on the database.
ONLY
[NO]READ Allows read/write transactions on the database.
WRITE
[NO] BATCH Allows batch-update transactions on the database.
UPDATE This mode executes without the overhead, or
security, or a recovery-unit journal file.
The batch-update transaction is intended for
the initial loading of a database. Oracle Rdb
recommends that this mode be disabled.
Reserving Modes
[NO] SHARED Allows tables to be reserved for shared mode. That
[READ | is, other users can work with those tables.
WRITE]
[NO] Allows tables to be reserved for protected mode.
PROTECTED That is, other users can read from those tables.
[READ |
WRITE]
[NO] Allows tables to be reserved for exclusive access.
EXCLUSIVE That is, other users are prevented access to those
[READ | tables, even in READ ONLY transactions.
WRITE]
ALL Allows other users to work with all tables.
NONE Allows no access to tables.
For detailed information about the txn-modes, see the SET_
TRANSACTION statement.
4.3.122 – WAIT option
Syntax option:
WAIT n MINUTES FOR CLOSE
Specifies the amount of time that Oracle Rdb waits before
automatically closing a database. If anyone attaches during that
wait time, the database is not closed.
The default value for n is zero (0) if the WAIT clause is
not specified. The value for n can range from zero (0) to
35,791,394. However, Oracle Rdb does not recommend using large
values.
4.3.123 – WORKLOAD_COLLECTION
Syntax options:
WORKLOAD COLLECTION IS ENABLED | WORKLOAD COLLECTION IS DISABLED
Specifies whether or not the optimizer records workload
information in the system table RDB$WORKLOAD. The WORKLOAD
COLLECTION IS ENABLED clause creates this system table if it
does not exist. If you later disable workload collection, the
RDB$WORKLOAD system table is not deleted.
A workload profile is a description of the interesting table
and column references used by queries in a database workload.
When workload collection is enabled, the optimizer collects
and records these references in the RDB$WORKLOAD system table.
This work load is then processed by the RMU Analyze Statistics
command which records useful statistics about the work load.
These workload statistics are used by the optimizer at run time
to deliver more accurate access strategies.
Workload collection is disabled by default.
4.4 – Examples
Example 1: Creating a single-file database
This command file example creates a single-file database that
contains one table, EMPLOYEES, made up of domains defined within
the CREATE DATABASE statement. The EMPLOYEES table has the same
definition as that in the sample personnel database.
For an example that creates a multifile version of the personnel
database, see the CREATE STORAGE_AREA.
SQL> -- By omitting a FILENAME clause, the database root file
SQL> -- takes the file name from the alias:
SQL> CREATE DATABASE ALIAS personnel
cont> --
cont> -- This CREATE DATABASE statement takes default
cont> -- database root file and storage area parameter values.
cont> --
cont> -- Create domains.
cont> -- Note that database elements do not terminate with semicolons.
cont> --
cont> CREATE DOMAIN ID_DOM CHAR(5)
cont> --
cont> CREATE DOMAIN LAST_NAME_DOM CHAR(14)
cont> --
cont> CREATE DOMAIN FIRST_NAME_DOM CHAR(10)
cont> --
cont> CREATE DOMAIN MIDDLE_INITIAL_DOM CHAR(1)
cont> --
cont> CREATE DOMAIN ADDRESS_DATA_1_DOM CHAR(25)
cont> --
cont> CREATE DOMAIN ADDRESS_DATA_2_DOM CHAR(20)
cont> --
cont> CREATE DOMAIN CITY_DOM CHAR(20)
cont> --
cont> CREATE DOMAIN STATE_DOM CHAR(2)
cont> --
cont> CREATE DOMAIN POSTAL_CODE_DOM CHAR(5)
cont> --
cont> CREATE DOMAIN SEX_DOM CHAR(1)
cont> --
cont> CREATE DOMAIN DATE_DOM DATE
cont> --
cont> CREATE DOMAIN STATUS_CODE_DOM CHAR(1)
cont> --
cont> -- Create a table:
cont> --
cont> CREATE TABLE EMPLOYEES
cont> (
cont> EMPLOYEE_ID ID_DOM
cont> CONSTRAINT EMP_EMPLOYEE_ID_NOT_NULL
cont> NOT NULL
cont> NOT DEFERRABLE,
cont> LAST_NAME LAST_NAME_DOM,
cont> FIRST_NAME FIRST_NAME_DOM,
cont> MIDDLE_INITIAL MIDDLE_INITIAL_DOM,
cont> ADDRESS_DATA_1 ADDRESS_DATA_1_DOM,
cont> ADDRESS_DATA_2 ADDRESS_DATA_2_DOM,
cont> CITY CITY_DOM,
cont> STATE STATE_DOM,
cont> POSTAL_CODE POSTAL_CODE_DOM,
cont> SEX SEX_DOM,
cont> CONSTRAINT EMP_SEX_VALUES
cont> CHECK (
cont> SEX IN ('M', 'F') OR SEX IS NULL
cont> )
cont> NOT DEFERRABLE,
cont> BIRTHDAY DATE_DOM,
cont> STATUS_CODE STATUS_CODE_DOM,
cont> CONSTRAINT EMP_STATUS_CODE_VALUES
cont> CHECK (
cont> STATUS_CODE IN ('0', '1', '2')
cont> OR STATUS_CODE IS NULL
cont> )
cont> NOT DEFERRABLE
cont> )
cont> --
cont> -- End CREATE DATABASE by specifying a semicolon:
cont> ;
Example 2: Creating a database not using the repository
The following example:
o Creates the database root file acct.rdb in the default working
directory
o Creates the snapshot file acct.snp in the default working
directory
o Does not store the database definition in the repository
o Enables writing to the snapshot file
o Sets the allocation of the snapshot file to 200 pages
SQL> CREATE DATABASE ALIAS acct
cont> FILENAME acct
cont> SNAPSHOT IS ENABLED IMMEDIATE
cont> SNAPSHOT ALLOCATION IS 200 PAGES;
Example 3: Creating a database with the snapshot file disabled
This statement creates a database root file and, to save disk
space, disables snapshot writing and sets the initial allocation
size to 1.
SQL> CREATE DATABASE ALIAS PERS
cont> FILENAME personnel
cont> SNAPSHOT IS DISABLED
cont> SNAPSHOT ALLOCATION IS 1 PAGES;
Example 4: Creating a database with ANSI/ISO-style privileges
This statement creates a database in which all ANSI/ISO-style
privileges are granted to the creator of the database, WARRING,
and no privileges are granted to the identifier [*,*], the PUBLIC
identifier.
SQL> CREATE DATABASE ALIAS EXAMPLE
cont> FILENAME ansi_test
cont> PROTECTION IS ANSI;
SQL>
SQL> SHOW PROTECTION ON DATABASE EXAMPLE;
Protection on Alias EXAMPLE
[SQL,WARRING]:
With Grant Option: SELECT,INSERT,UPDATE,DELETE,SHOW,CREATE,ALTER,DROP,
DBCTRL,OPERATOR,DBADM,SECURITY,DISTRIBTRAN
Without Grant Option: NONE
[*,*]:
With Grant Option: NONE
Without Grant Option: NONE
Example 5: Creating a database with a German collating sequence
This statement creates a database named LITERATURE and specifies
a collating sequence named GERMAN (based on the GERMAN collating
sequence defined in the NCS library).
SQL> CREATE DATABASE FILENAME literature
cont> COLLATING SEQUENCE GERMAN GERMAN;
SQL> SHOW COLLATING SEQUENCE
User collating sequences in schema with filename LITERATURE
GERMAN
Example 6: Creating a database with global buffers
This statement creates a database named parts.rdb.
SQL> CREATE DATABASE ALIAS PARTS FILENAME parts
cont> GLOBAL BUFFERS ARE ENABLED (NUMBER IS 110, USER LIMIT IS 17);
Example 7: Creating a database specifying the database default
and national character sets
The following SQL statements create a database specifying the
database default character set of DEC_KANJI and the national
character set of KANJI. Use the SHOW DATABASE statement to see
the database settings.
SQL> SET DIALECT 'SQL99';
SQL> CREATE DATABASE FILENAME mia_char_set
cont> DEFAULT CHARACTER SET DEC_KANJI
cont> NATIONAL CHARACTER SET KANJI
cont> IDENTIFIER CHARACTER SET DEC_KANJI;
SQL> --
SQL> SHOW CHARACTER SET;
Default character set is DEC_MCS
National character set is DEC_MCS
Identifier character set is DEC_MCS
Literal character set is DEC_MCS
Display character set is UNSPECIFIED
Alias RDB$DBHANDLE:
Identifier character set is DEC_KANJI
Default character set is DEC_KANJI
National character set is KANJI
See the SHOW for information on the SHOW CHARACTER SETS
statement.
Example 8: This example demonstrates how to:
o Create a multifile database
o Reserve slots for journal files, storage areas, and row caches
o Restrict access to the database for the current session
o Enable system index compression, row caching, and workload
collection
o Disable statistics and cardinality collection
o Specify a default storage area
o Specify ROW as the lock-level default for the database
o Delay closing the database
o Create and assign a row cache to a storage area
o Specify the location of the recovery-unit journal file
SQL> CREATE DATABASE FILENAME sample
cont> SNAPSHOT IS DISABLED
cont> RESERVE 10 JOURNALS
cont> RESERVE 10 STORAGE AREAS
cont> RESERVE 5 CACHE SLOTS
cont> SYSTEM INDEX COMPRESSION IS ENABLED
cont> ROW CACHE IS ENABLED
cont> WORKLOAD COLLECTION IS ENABLED
cont> RESTRICTED ACCESS
cont> STATISTICS COLLECTION IS DISABLED
cont> CARDINALITY COLLECTION IS DISABLED
cont> LOCKING IS ROW LEVEL
cont> DEFAULT STORAGE AREA IS area1
cont> OPEN IS AUTOMATIC (WAIT 5 MINUTES FOR CLOSE)
cont> RECOVERY JOURNAL (LOCATION IS 'SQL_USER1:[DAY]')
cont> CREATE CACHE cache1
cont> CACHE SIZE IS 1000 ROWS
cont> ROW LENGTH IS 1000 BYTES
cont> CREATE STORAGE AREA area1
cont> CACHE USING cache1;
SQL>
SQL> SHOW DATABASE *;
Default alias:
Oracle Rdb database in file sample
Multischema mode is disabled
Number of users: 50
Number of nodes: 16
Buffer Size (blocks/buffer): 6
Number of Buffers: 20
Number of Recovery Buffers: 20
Snapshots are Disabled
Carry over locks are enabled
Lock timeout interval is 0 seconds
Adjustable lock granularity is enabled (count is 3)
Global buffers are disabled (number is 250, user limit is 5,
page transfer via disk)
Journal fast commit is disabled
( checkpoint interval is 0 blocks,
checkpoint timed every 0 seconds,
no commit to journal optimization,
transaction interval is 256 )
AIJ File Allocation: 512
AIJ File Extent: 512
Statistics Collection is DISABLED
Unused Storage Areas: 10
Unused Journals: 10
System Index Compression is ENABLED
Restricted Access
Journal is Disabled
Backup Server: Manual
Log Server: Manual
Overwrite: Disabled
Notification: Disabled
Asynchronous Prefetch is Enabled (depth is 5)
Asynchronous Batch Write is Enabled (clean buffers 5, max buffers 4)
Lock Partitioning is DISABLED
Incremental Backup Scan Optim uses SPAM pages
Shutdown Time is 60 minutes
Unused Cache Slots: 5
Workload Collection is Enabled
Cardinality Collection is Disabled
Metadata Changes are Enabled
Row Cache is Enabled (Sweep interval is 1 second,
No Location)
Detected Asynch Prefetch is Enabled (depth is 4, threshold is 4)
Default Storage Area AREA1
Mode is Open Automatic (Wait 5 minutes for close)
RUJ File Location SQL_USER1:[DAY]
Database Transaction Mode(s) Enabled:
ALL
Dictionary Not Required
ACL based protections
Storage Areas in database with filename sample
RDB$SYSTEM List storage area.
AREA1 Default storage area.
Journals in database with filename sample
No Journals Found
Cache Objects in database with filename sample
CACHE1
SQL> SHOW CACHE cache1;
CACHE1
Cache Size: 1000 rows
Row Length: 1000 bytes
Row Replacement: Enabled
Shared Memory: Process
Large Memory: Disabled
Window Count: 100
Reserved Rows: 20
Sweep Rows: 3000
Reserving Slots for Sequences
No Sweep Thresholds
Allocation: 100 blocks
Extent: 100 blocks
Example 9: Reserving Slots for Sequences
SQL> CREATE DATABASE FILENAME many_sequences
cont> RESERVE 320 SEQUENCES;
Example 10: Creating a Database with a Row Cache
SQL> create database
cont> filename SAMPLE
cont> snapshot is disabled
cont> reserve 10 journals
cont> reserve 10 storage areas
cont> reserve 5 cache slots
cont> system index (compression is enabled, type sorted ranked)
cont> row cache is enabled
cont> workload collection is enabled
cont> restricted access
cont> default storage area is AREA1
cont> open is automatic (wait 5 minutes for close)
cont>
cont> create cache CACHE_AREA1
cont> shared memory is process
cont> row length is 1000 bytes
cont> cache size is 204 rows
cont> checkpoint all rows to backing file
cont>
cont> create storage area AREA1
cont> page format is UNIFORM
cont> cache using CACHE_AREA1
cont> ;
SQL>
SQL> show database *
Default alias:
Oracle Rdb database in file SAMPLE
Multischema mode is disabled
Number of users: 50
Number of nodes: 16
Buffer Size (blocks/buffer): 6
Number of Buffers: 20
Number of Recovery Buffers: 20
Snapshots are Disabled
Carry over locks are enabled
Lock timeout interval is 0 seconds
Adjustable lock granularity is enabled (count is 3)
Global buffers are disabled (number is 250, user limit is 5,
page transfer via disk)
Journal fast commit is disabled
( checkpoint interval is 0 blocks,
checkpoint timed every 0 seconds,
no commit to journal optimization,
transaction interval is 256 )
AIJ File Allocation: 512
AIJ File Extent: 512
Statistics Collection is ENABLED
Unused Storage Areas: 10
Unused Journals: 10
Unused Cache Slots: 5
Unused Sequences: 32
Restricted Access
Journal is Disabled
Backup Server: Manual
Log Server: Manual
Overwrite: Disabled
Notification: Disabled
Asynchronous Prefetch is Enabled (depth is 5)
Asynchronous Batch Write is Enabled (clean buffers 5, max buffers 4)
Lock Partitioning is DISABLED
Incremental Backup Scan Optim uses SPAM pages
Shutdown Time is 60 minutes
Workload Collection is Enabled
Cardinality Collection is Enabled
Metadata Changes are Enabled
Row Cache is Enabled
Row cache: No Location
Row cache: checkpoint updated rows to backing file
Detected Asynch Prefetch is Enabled (depth is 4, threshold is 4)
Default Storage Area AREA1
Mode is Open Automatic (Wait 5 minutes for close)
No RUJ File Location
recovery journal buffers are in local memory
Database Transaction Mode(s) Enabled:
ALL
Shared Memory: Process
Large Memory: Disabled
Security Checking is External
System Index Compression is ENABLED
System Index:
Type is sorted ranked
Prefix cardinality collection is enabled
Logminer support is disabled
Galaxy support is disabled
Prestarted transactions are enabled
Dictionary Not Required
ACL based protections
Storage Areas in database with filename SAMPLE
AREA1 Default storage area
RDB$SYSTEM List storage area.
Journals in database with filename SAMPLE
No Journals Found
Cache Objects in database with filename SAMPLE
CACHE_AREA1
5 – DOMAIN
Creates a domain definition.
A domain defines the set of values, character set, collating
sequence, and formatting clause that a column in a table can
have. The CREATE DOMAIN statement specifies the set of values by
associating a data type with a domain name.
There are two ways to specify a domain definition:
o With a domain name, data type, and any combination of the
following optional clauses:
- Default value
- Stored name
- Collating sequence
- Formatting clauses such as EDIT STRING or QUERY HEADER
o With the FROM clause and a repository path name that refers to
a field already defined in the repository
When the CREATE DOMAIN statement executes, SQL adds the domain
definition to the database.
If you attached to the database with the PATHNAME specification,
the domain definition is also added to the repository.
You can refer to a domain instead of an SQL data type in the
CREATE and ALTER TABLE statements, and in formal parameter
declarations in functions and procedures. If the domain has to
change, you need only change that one domain definition (using
the ALTER DOMAIN statement) to change all the tables. This
ability makes it easier to keep applications consistent.
A domain can be referenced in the following locations:
o CREATE, ALTER and DROP DOMAIN statements
o CREATE and ALTER TABLE statements as the data type for a
column
o CREATE and ALTER MODULE statements as the data type of a
routine parameter, or the data type of declared variable
o CREATE FUNCTION statement as the data type of a function
parameter or function result
o CREATE PROCEDURE statement as the data type of a procedure
parameter
o CREATE and ALTER SYNONYM statement as the base object for a
synonym
o as the datatype of a CAST expression
o as a data type of a DECLARE variable statement in interactive
SQL
o as the source in the EDIT USING clause of the SELECT and PRINT
statements in interactive SQL. The EDIT STRING is inherited
from that domain.
5.1 – Environment
You can use the CREATE DOMAIN statement:
o In interactive SQL
o Embedded in host language programs to be precompiled
o As part of a procedure in an SQL module
o In dynamic SQL as a statement to be dynamically executed
5.2 – Format
CREATE DOMAIN -+
+--------------+
+-> <domain-name> +-----------------------------------++
| +-> STORED NAME IS <stored-name> ---+|
|+-----------------------------------------------------+
|++-> IS data-type -+-+----------------------------+---+
| +-> AS data-type -+ +--> DEFAULT value-expr -----+ |
| +--------------------------------------------------+
| +-+--------------------------------------------+-+
| +-> COLLATING SEQUENCE IS <collation-name> --+ |
| +-> NO COLLATING SEQUENCE -------------------+ |
| +------------------------------------------------+
| +-+----------------------+-+------------------------++->
| +-> domain-constraint -+ ++> sql-and-dtr-clause -++|
| +---------<------------+ |
+-> FROM -> <path-name> +----------------->----------+---+
+-> DATABASE ALIAS <alias> --+
domain-name =
-+---------------------------+-> <name-of-domain> --->
+-+-> <schema-name> -+-> . -+
+-> <alias> -------+
data-type =
--+-> char-data-types ---------------------------+-->
+-> TINYINT --------------+-----+----------+---+
+-> SMALLINT -------------+ +-> (<n>) -+ |
+-> INTEGER --------------+ |
+-> BIGINT ---------------+ |
+-> LIST OF BYTE VARYING -+ |
+-> DECIMAL -++-----------------------------+--+
+-> NUMERIC -++-> ( -> <n> +----------+-> ) + |
| +-> , <n> -+ |
+-> FLOAT -+----------+------------------------+
| +-> (<n>) -+ |
+-> REAL --------------------------------------+
+-> DOUBLE PRECISION --------------------------+
+-> date-time-data-types ----------------------+
char-data-types =
-+-> CHAR -------------++------------++--------------------------------+-+->
+-> CHARACTER --------++-> ( <n> ) -++-> CHARACTER SET char-set-name -+ |
+-> CHAR VARYING -----+ |
+-> CHARACTER VARYING + |
+-> VARCHAR --+> ( <n> ) ---+--------------------------------+----------+
+-> VARCHAR2 -+ +-> CHARACTER SET char-set-name -+ |
+-> LONG VARCHAR ------------------------------------------------------+
+-> NCHAR --------------+-+------------+--------------------------------+
+-> NATIONAL CHAR ------+ +-> ( <n> ) -+ |
+-> NATIONAL CHARACTER -+ |
+-> NCHAR VARYING --------------+-+------------+------------------------+
+-> NATIONAL CHAR VARYING ------+ +-> ( <n> ) -+ |
+-> NATIONAL CHARACTER VARYING -+ |
+-> RAW -> ( <n> ) -----------------------------------------------------+
+-> LONG -+--------+----------------------------------------------------+
+-> RAW -+
date-time-data-types =
--+-> DATE -+----------+-----------------+-->
| +-> ANSI -+ |
| +-> VMS ---+ |
+-> TIME ---> frac --------------------+
+-> TIMESTAMP --> frac ----------------+
+-> INTERVAL ---> interval-qualifier --+
interval-qualifier =
--+-> YEAR ---> prec --+-------------+-----------------+->
| +-> TO MONTH -+ |
+-> MONTH --> prec ----------------------------------+
+-> DAY ----> prec --+-------------------------------+
| +-> TO -+-> HOUR ---------------+
| +-> MINUTE -------------+
| +-> SECOND -> frac -----+
+-> HOUR ---> prec --+-------------------------------+
| +-> TO -+-> MINUTE -------------+
| +-> SECOND -> frac -----+
+-> MINUTE -> prec --+-------------------------------+
| +-> TO SECOND ------> frac -----+
+-> SECOND -> seconds-prec --------------------------+
literal =
--+-> numeric-literal ----+--->
+-> string-literal -----+
+-> date-time-literal --+
+-> interval-literal ---+
domain-constraint =
--+----------------------------------------------------+---->
+-> CHECK ( predicate ) -+--------------------------++
+-> constraint-attributes -+
sql-and-dtr-clause =
-+-> QUERY HEADER IS -+> <quoted-string> +------------------+->
| +------ / <--------+ |
+-> EDIT STRING IS <quoted-string> ------------------------+
| |
+-> QUERY NAME FOR -+-> DTR --------+-> IS <quoted-string> +
| +-> DATATRIEVE -+ |
+-> DEFAULT VALUE FOR -+-> DTR --------+-> IS <literal> ---+
| +-> DATATRIEVE -+ |
+-> NO QUERY HEADER ---------------------------------------+
+-> NO EDIT STRING ----------------------------------------+
+-> NO QUERY NAME ----+--> FOR -+-> DTR --------+----------+
+-> NO DEFAULT VALUE -+ +-> DATATRIEVE -+ |
+-> COMMENT IS -+-> <quoted-string> -+---------------------+
+------ / <----------+
5.3 – Arguments
5.3.1 – char-data-types
A character type. See the Data_Types HELP topic for more
information on data types.
5.3.2 – character-set-name
A valid character set.
5.3.3 – COLLATING_SEQUENCE
Specifies a collating sequence for the named domain.
The OpenVMS National Character Set (NCS) utility provides a
set of predefined collating sequences and also lets you define
collating sequences of your own. The COLLATING SEQUENCE clause
accepts both predefined and user-defined NCS collating sequences.
Before you use the COLLATING SEQUENCE clause in a CREATE DOMAIN
statement, you must first specify the NCS collating sequence for
SQL using the CREATE COLLATING SEQUENCE statement. The sequence-
name argument in the COLLATING SEQUENCE clause must be the same
as the sequence-name in the CREATE COLLATING SEQUENCE statement.
5.3.4 – COMMENT_IS
Adds a comment about the domain. SQL displays the text of the
comment when it executes a SHOW DOMAIN statement. Enclose the
comment in single quotation marks ( ') and separate multiple
lines in a comment with a slash mark (/).
5.3.5 – DATABASE ALIAS alias
In the FROM path-name clause, specifies the name for an attach
to a particular database. SQL adds the domain definition to the
database referred to by the alias.
If you do not specify an alias, SQL adds the domain definition to
the default database. See the User_Supplied_Names HELP topic for
more information on default databases and aliases.
5.3.6 – date-time-data-types
A data type that specifies a date, time, or interval. See the
Data_Types HELP topic for more information about date-time data
types.
5.3.7 – DEFAULT value-expr
Provides a default value for a domain.
You can use any value expression including subqueries,
conditional, character, date/time, and numeric expressions as
default values. See Value Expressions for more information about
value expressions.
For more information about NULL, see the NULL_Keyword HELP topic.
The value expressions described in Value Expressions include
DBKEY and aggregate functions. However, the DEFAULT clause is
not a valid location for referencing a DBKEY or an aggregate
function. If you attempt to reference either, you receive a
compile-time error.
If you do not specify a DEFAULT for a column, it inherits the
DEFAULT from the domain. If you do not specify a default for
either the column or domain, SQL assigns NULL as the default
value.
5.3.8 – domain-constraint
Creates a constraint for the named domain.
Specify a domain constraint when you create a domain to limit
which values can be stored in columns based on the domain. Domain
constraints specify that columns based on the domain contain only
certain data values or that data values can or cannot be null.
Use the CHECK clause to specify that a value must be within a
specified range or that it matches a list of values. When you
specify a CHECK clause for a domain constraint, you ensure that
all values stored in columns based on the domain are checked
consistently.
5.3.9 – domain-name
The name of a domain you want to create. The domain name must be
unique among domain names in the schema. You can qualify it with
an alias or (in multischema databases only) a schema name.
5.3.10 – FROM pathname
Specifies the repository path name of a repository field
definition. SQL creates the domain using the definition from
this field and gives the domain the name of the field definition.
Creating a domain based on a repository domain definition is
useful when many applications share the same definition. Changes
to the common definition can be automatically reflected in all
applications that use it.
You can create a domain using the FROM path-name clause only if
the field definition in the repository was originally created
using the repository CDO utility. For instance, you cannot create
a domain using the FROM path-name clause if the definition was
created in the repository as part of an SQL session. Oracle
Rdb requires that the field names referenced in the VALID IF
expression of the CDO utility match the name of the global field
being defined or changed.
NOTE
Changes by other users or applications to the field
definition in the repository will affect the domain
definition once the database is integrated to match the
repository with an INTEGRATE DATABASE . . . ALTER FILES
statement.
You can use the FROM path-name clause only if the database was
attached specifying PATHNAME. You can specify either a full
repository path name or a relative repository path name.
You cannot specify formatting clauses when you use the FROM path-
name form of the CREATE DOMAIN statement.
You cannot use the FROM path-name clause when embedding a CREATE
DOMAIN statement in a CREATE DATABASE statement.
5.3.11 – data-type
Syntax options:
IS data-type
AS data-type
A valid SQL data type. See the Data_Types HELP topic for more
information on data types.
5.3.12 – NO_COLLATING_SEQUENCE
Specifies that this domain uses the standard default collating
sequence, that is, ASCII. Use the NO COLLATING SEQUENCE clause to
override the collating sequence defined for the database in the
CREATE DATABASE or ALTER DATABASE statement.
5.3.13 – sql-and-dtr-clause
Optional SQL and DATATRIEVE formatting clause. See the DATATRIEVE
HELP topic for more information on formatting clauses.
5.3.14 – STORED_NAME_IS
Specifies a name that Oracle Rdb uses to access a domain created
in a multischema database. The stored name lets you access
multischema definitions using interfaces, such as Oracle RMU,
the Oracle Rdb management utility, that do not recognize multiple
schemas in one database. You cannot specify a stored name for a
domain in a database that does not allow multiple schemas. For
more information about stored names, see the User_Supplied_Names
HELP topic.
5.4 – Examples
Example 1: Creating a domain for a standard EMPLOYEE_ID
definition
The following example creates the domain ID_DOM, which will be a
standard definition of columns for the employee ID:
SQL> CREATE DOMAIN ID_DOM CHAR(5)
SQL> COMMENT IS
cont> 'standard definition of employee id';
Example 2: Creating a domain for standard date
The following example creates the domain STANDARD_DATE_DOM, which
includes the edit string DD-MMM-YYYY:
SQL> CREATE DOMAIN STANDARD_DATE_DOM DATE
cont> EDIT STRING IS 'DD-MMM-YYYY'
SQL> COMMENT IS
cont> 'standard definition for complete dates';
Example 3: Creating domains with default values
The following example creates two domains: ADDRESS_DATA2_DOM and
WORK_STATUS_DOM. The ADDRESS_DATA2_DOM domain has a default value
of NULL; the WORK_STATUS_DOM domain has a default value of 1 to
signify full-time work status.
SQL> CREATE DOMAIN ADDRESS_DATA2_DOM CHAR(20)
cont> DEFAULT NULL;
SQL> --
SQL> CREATE DOMAIN WORK_STATUS_DOM SMALLINT
cont> DEFAULT 1;
Example 4: Basing a domain on a repository field definition
The following example illustrates using the repository as a
source for the definition in a CREATE DOMAIN statement:
$ SQL$
SQL> ATTACH 'PATHNAME CDD$TOP.SQL.RDB.TEST.DATE';
SQL> CREATE DOMAIN FROM DOMAIN_TEST;
SQL> SHOW DOMAIN
User domains in database with pathname
SYS$COMMON:[CDDPLUS]SQL.RDB.TEST.DATE;1
DOMAIN_TEST BIGINT
Example 5: Creating a domain with a collating sequence
The following example creates a domain with the predefined NCS
collating sequence SPANISH. Note that you must first execute the
CREATE COLLATING SEQUENCE statement:
SQL> --
SQL> CREATE COLLATING SEQUENCE SPANISH SPANISH;
SQL> CREATE DOMAIN LAST_NAME_SPANISH CHAR(14)
cont> COLLATING SEQUENCE IS SPANISH;
SQL> --
SQL> SHOW DOMAIN LAST_NAME_SPANISH
LAST_NAME_SPANISH CHAR(14)
Collating sequence: SPANISH
Example 6: Creating a domain using the database default character
set
For each of the following examples, assume the database was
created specifying the database default character set as DEC_
KANJI and the national character set as KANJI.
The following example creates the domain DEC_KANJI_DOM using the
database default character set:
SQL> SHOW CHARACTER SET;
Default character set is DEC_KANJI
National character set is KANJI
Identifier character set is DEC_KANJI
Literal character set is DEC_KANJI
Alias RDB$DBHANDLE:
Identifier character set is DEC_KANJI
Default character set is DEC_KANJI
National character set is KANJI
SQL> CREATE DOMAIN DEC_KANJI_DOM CHAR(8);
SQL> SHOW DOMAIN
User domains in database with filename MIA_CHAR_SET
DEC_KANJI_DOM CHAR(8)
Because the CREATE DOMAIN statement does not specify a character
set, Oracle Rdb defines the domain using the database default
character set. The database default character set does not
display with the SHOW DOMAIN statement.
An equivalent statement to the previous CREATE DOMAIN statement
is:
SQL> CREATE DOMAIN DEC_KANJI_DOM CHAR(8) CHARACTER SET DEC_KANJI;
Example 7: Creating a domain using the national character set
The following example creates the domain KANJI_DOM using the
NCHAR data type to designate use of the national character set:
SQL> CREATE DOMAIN KANJI_DOM NCHAR(8);
SQL> SHOW DOMAIN
User domains in database with filename MIA_CHAR_SET
DEC_KANJI_DOM CHAR(8)
KANJI_DOM CHAR(8)
KANJI 8 Characters, 16 Octets
When a character set other than the default is specified, the
SHOW DOMAIN statement displays the character set associated with
the domain.
Two statements equivalent to the previous CREATE DOMAIN statement
are:
SQL> CREATE DOMAIN KANJI_DOM NATIONAL CHAR(8);
SQL> CREATE DOMAIN KANJI_DOM CHAR(8) CHARACTER SET KANJI;
Example 8: Creating a domain constraint
The following example creates a domain constraint:
SQL> -- The SET DIALECT 'SQL99' statement sets the default date format
SQL> -- to the ANSI/ISO SQL standard format.
SQL> --
SQL> SET DIALECT 'SQL99';
SQL> --
SQL> -- The following domain ensures that any dates inserted into the database
SQL> -- are later than January 1, 1900:
SQL> --
SQL> CREATE DOMAIN TEST_DOM DATE
cont> DEFAULT NULL
cont> CHECK (VALUE > DATE'1900-01-01' OR
cont> VALUE IS NULL)
cont> NOT DEFERRABLE;
SQL>
SQL> -- The following example creates a table with one column based on the
SQL> -- domain TEST_DOM:
SQL> --
SQL> CREATE TABLE DOMAIN_TEST
cont> (DATE_COL TEST_DOM);
SQL> --
SQL> -- SQL returns an error if you attempt to insert data that does not
SQL> -- conform to the domain constraint:
SQL> --
SQL> INSERT INTO DOMAIN_TEST
cont> VALUES (DATE'1899-01-01');
%RDB-E-NOT_VALID, validation on field DATE_COL caused operation to fail
6 – FUNCTION
Creates an external function as a schema object in an Oracle Rdb
database.
The CREATE FUNCTION statement is documented under the CREATE
Routine. For complete information on creating an external
function definition, see the CREATE Routine Help topic.
7 – INDEX
Creates an index for a table. An index allows direct access to
the rows in the table to avoid sequential searching.
You define an index by listing the columns in a table that make
up the index. You can define more than one index for a table. The
index can be made up of one column, or two or more columns. An
index made up of two or more columns is called a multisegmented
index.
Optional arguments to the CREATE INDEX statement let you specify:
o The type of index structure (hashed, sorted nonranked, or
sorted ranked)
o The names of a storage area or storage areas that contain the
index
o Physical characteristics of a sorted index structure, such as
index node size and the initial fullness percentage of each
node
o Compression characteristics, including compressed key suffixes
for text indexes and integer column compression for smallint
or integer numeric columns
o Compression of space characters from text data types and of
binary zeros from nontext data types
o Thresholds for the logical storage areas that contain the
index
o A comment for the index definition
o Whether logging to the .ruj and .aij files is enabled or
disabled for the create index operation
7.1 – Environment
You can use the CREATE INDEX statement:
o In interactive SQL
o Embedded in host language programs to be precompiled
o As part of a procedure in an SQL module
o In dynamic SQL as a statement to be dynamically executed
7.2 – Format
CREATE -+-----------+-> INDEX <index-name> ------------------+
+-> UNIQUE -+ |
+------------------------------------------------------------+
+--+-----------------------------------+-> ON <table-name> --+
+-> STORED NAME IS <stored-name> ---+ |
+----------------------------- <-----------------------------+
+> ( +> <column-name> --+
| +--------------+
| +-+-------------++-----------------------------+-+- ) -+
| +> ASCENDING -++> SIZE IS <n> ---------------+ | |
| +> DESCENDING ++> MAPPING VALUES <l> TO <h> -+ | |
+---------------------- , <--------------------------+ |
+------------------------------ <-------------------------------+
++----------------+-+----------------------------+-----------+
+-> type-clause -+ +-> index-attributes-clause -+ |
+------------------------------<-----------------------------+
++-----------------------+-------------------------------------->
+-> index-store-clause -+
type-clause =
-> TYPE IS +> HASHED +-------------+------------------------------+>
| +> ORDERED ---+ |
| +> SCATTERED -+ |
+> SORTED +-----------------------------------------+-+|
+> RANKED -+-----------------------------++ ||
+> DUPLICATES ARE COMPRESSED -+ ||
+---------------------------------------------+|
+-+-----------------------+--------------------+
+> sorted-index-clause -+
sorted-index-clause =
--+-+-> NODE SIZE <number-bytes> ----------+-+-->
| +-> PERCENT FILL <percentage> ---------+ |
| +-> USAGE -+-> UPDATE -+---------------+ |
| +-> QUERY --+ |
+------------------- <---------------------+
index-attributes-clause =
-+-+---------------------------------------------------------+-+->
| +-> ENABLE COMPRESSION rlc-attr -------------------------+ |
| +-> DISABLE COMPRESSION ----------------------------------+ |
| +-> threshold-clause -------------------------------------+ |
| +-> LOGGING ----------------------------------------------+ |
| +-> NOLOGGING --------------------------------------------+ |
| +-> COMMENT IS -+-> '<string>' -+-------------------------+ |
| | +------- / <----+ | |
| +-> PREFIX CARDINALITY COLLECTION IS -+-> ENABLED ------+-+ |
| | +-> ENABLED FULL -+ | |
| | +-> DISABLED -----+ | |
| +-> MAINTENANCE IS -+-> DISABLED -----------------+-------+ |
| +-> ENABLED -+--------------+-+ |
| +-> DEFERRED --+ |
| +-> IMMEDIATE -+ |
+---------------------------- <-------------------------------+
rlc-attr =
--+--------------------------------+--------->
+--> (MINIMUM RUN LENGTH <n> ) --+
index-store-clause =
STORE ----------------------+
+---------------------------+
++-> IN area-spec ---------------------------------------------+>
+-> USING -> ( -+--> <column-name> -+-> ) ----------+ |
+------- , <--------+ | |
+---------------------------------------------------+ |
++> IN area-spec -------------------------------------+ |
| +--------------------------------------------------+ |
| +-> WITH LIMIT OF -> ( -+--> <literal> -+-> ) ---+---+ |
| +------ , <-----+ | | |
+-----------------------<--------------------------+ | |
+--------------------------------------------------------+ |
++------------------------------------------------------------++
+-> OTHERWISE IN area-spec ----------------------------------+
threshold-clause =
--+-> THRESHOLD -+-> IS -+-> ( --> <val1> --> ) ---------+->
| +-> OF -+ |
| |
+-> THRESHOLDS -+-> ARE -+-----------+ |
+-> OF -+ | |
+----------------------------------+ |
+-> ( --> <val1> -+---------------------------+-> ) -+
+-> , <val2> -+-------------+
+-> , <val3> -+
area-spec =
--> <area-name> -+---------------------------------------------------+->
+-> ( -++-> threshold-clause ---------------++-> ) -+
|+-> LOGGING ------------------------+|
|+-> NOLOGGING ----------------------+|
|+-> PARTITION <name> ---------------+|
|+-> COMMENT IS -+--> 'string' ---+--+|
| +------- / <-----+ |
+---------------- , -----------------+
7.3 – Arguments
7.3.1 – ASCENDING
An optional keyword that causes SQL to create ascending index
segments. If you omit the ASCENDING or DESCENDING keyword,
ascending is the default.
7.3.2 – BUILD_ALL_PARTITIONS
This clause operates on an index in build-pending state (created
using MAINTENANCE IS ENABLED DEFERRED) and builds all incomplete
partitions. If the index is not in build-pending state then the
statement completes successfully with a warning.
No other clauses may appear in the same ALTER INDEX statement.
7.3.3 – BUILD PARTITION partition-name
This clause operates on an index in build-pending state (created
using MAINTENANCE IS ENABLED DEFERRED) and builds the named
partition. If the index is not in build-pending state then the
statement completes successfully with a warning.
No other clauses may appear in the same ALTER INDEX statement.
7.3.4 – column-name
The name of the column or columns that make up the index key.
You can create a multisegmented index key by naming two or more
columns, which are joined to form the index key. All the columns
must be part of the same table. Separate multiple column names
with commas.
NOTE
If column-name refers to a column defined as CHAR, VARCHAR
or LONG VARCHAR data type, the size of the column must be
less than or equal to 254 characters, or the SIZE IS clause
must be used.
7.3.5 – COMMENT IS 'string '
Adds a comment about the storage map definition for the index.
SQL displays the text of the comment when it executes a SHOW
INDEXES statement. Enclose the comment in single quotation marks
( ') and separate multiple lines in a comment with a slash mark
(/).
7.3.6 – DESCENDING
An optional keyword that causes SQL to create descending index
segments. If you omit the ASCENDING or DESCENDING keyword,
ascending is the default.
7.3.7 – DISABLE_COMPRESSION
Disables compression indexes.
If compression is disabled, no form of compression is used for
hashed indexes, and prefix compression or suffix compression is
used for sorted indexes. Prefix compression is the compression
of the first bytes of an index key that are common in consecutive
index keys. Prefix compression saves space by not storing these
common bytes of information. Conversely, suffix compression is
the compression of the last bytes from adjacent index keys. These
bytes are not necessary to guarantee uniqueness.
You cannot enable index compression using the ALTER INDEX
statement once you specified the DISABLE COMPRESSION clause of
the CREATE INDEX statement.
Index compression is disabled by default.
7.3.8 – DUPLICATES_ARE_COMPRESSED
Specifies that duplicates are compressed. If a sorted ranked
index allows duplicate entries, you can store many more records
in a small space when you compress duplicates, therefore,
minimizing I/O and increasing performance. Oracle Rdb uses
patented technology called byte-aligned bitmap compression
to represent the dbkeys for the duplicate entries instead of
chaining the duplicate entries together with uncompressed dbkeys.
Duplicates are compressed by default if you specify RANKED
without specifying the DUPLICATES ARE COMPRESSED clause.
You cannot use the DUPLICATES ARE COMPRESSED clause when you
create nonranked indexes or when you specify the UNIQUE keyword.
See the Oracle Rdb Guide to Database Design and Definition for
more information on sorted ranked B-tree indexes.
7.3.9 – ENABLE_COMPRESSION
Specifies that sorted and hashed indexes are stored in a
compressed form.
If compression is enabled, Oracle Rdb uses run-length compression
to compress a sequence of space characters (octets) from text
data types and binary zeros from nontext data types. Different
character sets have different representations of the space
character. Oracle Rdb compresses the representation of the space
character for the character sets of the columns comprising the
index values.
You cannot disable index compression using the ALTER INDEX
statement once you specified the ENABLE COMPRESSION clause of
the CREATE INDEX statement.
For more information on compressed indexes, see the Oracle Rdb
Guide to Database Design and Definition.
7.3.10 – IN area name
Associates the index directly with a single storage area. All
entries in the index are stored in the area you specify.
7.3.11 – index-name
The name of the index. You can use this name to refer to the
index in other statements. You must qualify the index name with
the authorization identifier if the schema is not the default
schema. When choosing a name, specify a valid name. See the User_
Supplied_Names HELP topic for more information.
7.3.12 – index-store-clause
A storage map definition for the index. You can specify a store
clause for indexes in a multifile database only. The STORE clause
in a CREATE INDEX statement allows you to specify which storage
area files are used to store the index entries:
o All index entries can be associated with a single storage
area.
o Index entries can be systematically distributed, or
partitioned, among several storage areas by specifying upper
limits on the values for a key in a particular storage area.
If you omit the storage map definition, the default is to store
all the entries for an index in the main default storage area.
You should define a storage area for an index that matches the
storage map for the table with which it is associated.
In particular, under the following conditions, the database
system stores the index entry for a row on or near the same data
page that contains the actual row:
o The storage areas for a table have a mixed page format.
o You specify an identical store clause for the index as exists
in the storage map for the table.
o The storage map for the table also names the index in the
PLACEMENT VIA INDEX clause.
Such coincidental clustering of indexes and rows can reduce I/O
operations. With hashed indexes and coincidental clustering, the
database system can retrieve rows for exact-match queries in one
I/O operation.
For sorted indexes, specifying an identical storage map reduces
I/O contention on index nodes.
7.3.13 – LOGGING
Syntax options:
LOGGING |NOLOGGING The LOGGING clause specifies that index nodes
and hash buckets be logged when written to the database. Logging
includes writing data and management records to the recovery-unit
journal file (.ruj) and after-image journal files (.aij). When
the NOLOGGING clause is specified then only a small number of
management records are logged in the recovery-unit journal file
(.ruj) and after-image journal files (.aij). See the Usage Notes
below for more information.
LOGGING and NOLOGGING can be specified per storage area
(partition) or as a default for the CREATE INDEX statement. The
LOGGING and NOLOGGING clauses are mutually exclusive; specify
only one. The LOGGING clause is the default.
7.3.14 – MAINTENANCE_IS_DISABLED
An index created using this clause is not maintained. The index
definition serves only as a template.
7.3.15 – MAINTENANCE_IS_ENABLED_DEFERRED
An index created using this clause does not contain index keys
for the current rows in the table. Until this index is built
(using ALTER INDEX . . . BUILD), the index is placed in a build-
pending state. Any table with a build-pending index can not be
updated using the INSERT, DELETE, or UPDATE statements.
7.3.16 – MAINTENANCE_IS_ENABLED_IMMEDIATE
This is the default behavior for CREATE INDEX.
7.3.17 – MAPPING_VALUES
l to h
A compression clause for all-numeric columns that translates the
column values into a compact, encoded form. You can mix mapped
and unmapped columns, but the most storage space is gained by
building indexes of multiple columns of data type SMALLINT or
INTEGER. Oracle Rdb attempts to compress all such columns into
the smallest possible space.
The l (low) through h (high) specifies the range of integers as
the value of the index key.
The Oracle Rdb SQL Reference Manual describes addiional
restrictions about this argument.
7.3.18 – MINIMUM_RUN_LENGTH
Specifies the minimum length of the sequence that Oracle Rdb
should compress. You cannot alter this value once you set it.
If you specify MINIMUM RUN LENGTH 2, Oracle Rdb compresses
sequences of two or more spaces or of two or more binary zeros
for single-octet character sets, and compresses one space or
one binary zero for multi-octet character sets. As it compresses
the sequences, Oracle Rdb replaces the sequence with the value
of the minimum run length plus 1 byte. If many of the index
values contain one space between characters in addition to
trailing spaces, use a minimum run length of 2, so that you do
not inadvertently expand the index beyond the 255-byte limit. If
you inadvertently expand the index beyond 255 bytes during index
creation, Oracle Rdb returns a warning message.
The default minimum run length value is 2. Valid values for the
minimum run length range from 1 to 127. Oracle Rdb determines
which characters are compressed.
7.3.19 – NODE_SIZE
The size in bytes of each index node.
The number and level of the resulting index nodes depend on:
o This number-bytes value
o The number and size of the index keys
o The value specified in the PERCENT FILL or USAGE clauses
If you omit the NODE SIZE clause, the default value is:
o 430 bytes if the total index key size is 120 bytes or less
o 860 bytes if the total index key size is more than 120 bytes
The index key size is the number of bytes it takes to represent
the column value in the sorted index.
See the Oracle Rdb SQL Reference Manual for details on
determining the valid range for a user-specified index node size.
7.3.20 – OTHERWISE IN area name
For partitioned storage maps only, specifies the storage area
that is used as the overflow partition. An overflow partition
is a storage area that holds any values that are higher than
those specified in the last WITH LIMIT TO clause. An overflow
partition holds those values that "overflow" the partitions that
have specified limits.
7.3.21 – PARTITION name
Names the partition. The name can be a delimited identifier.
Partition names must be unique within the index. If you do not
specify this clause, Oracle Rdb generates a default name for the
partition.
7.3.22 – PERCENT_FILL
Specifies the initial fullness percentage for each node in the
index structure being changed. The valid range is 1 percent to
100 percent. The default is 70 percent.
Both the PERCENT FILL and USAGE clauses specify how full an index
node should be initially. Specify either PERCENT FILL or USAGE,
but not both.
7.3.23 – PREFIX_CARDINALITY_COLLECTION_IS_DISABLED
This setting disables the cardinality collection and, instead,
uses a fixed scaling algorithm which assumes a well balanced
index tree.
7.3.24 – PREFIX_CARDINALITY_COLLECTION_IS_ENABLED
This is the default behavior for CREATE INDEX. The Oracle Rdb
optimizer collects approximate cardinality values for the index
columns to help in future query optimization. Note that no extra
I/O is incurred to collect these values and, therefore, adjacent
key values from other index nodes can not be checked. Hence, some
inaccuracy may be seen for these indexes. In most cases, this is
adequate for query optimizations.
7.3.25 – PREFIX_CARDINALITY_COLLECTION_IS_ENABLED_FULL
This setting requests that extra I/O be performed, if required,
to ensure that the cardinality values reflect the key value
changes of adjacent index nodes.
7.3.26 – REBUILD_ALL_PARTITIONS
This clause combines the TRUNCATE and BUILD actions into a single
function. No other clauses may appear in the same ALTER INDEX
statement.
7.3.27 – REBUILD PARTITION partition-name
This clause combines the TRUNCATE and BUILD actions into a single
function for the named partition. No other clauses may appear in
the same ALTER INDEX statement.
7.3.28 – SIZE IS n
A compression clause for text or varying text index keys that
limits the number of characters used for retrieving data. The n
specifies the number of characters of the key that are used in
the index.
NOTE
Although you can create a SIZE IS index and specify the
UNIQUE clause, truncating the index key values may make the
key values non-unique. In this case, the index definition or
insert or update statements fail.
7.3.29 – STORE IN area name
Associates the index directly with a single storage area. All
entries in the index are stored in the area you specify.
7.3.30 – STORE_USING
Specifies columns whose values are used as limits for
partitioning the index across multiple storage areas. You cannot
name columns not specified as index key segments.
If the index key is multisegmented, you can include some or all
the columns that are joined to form the index key. You must
specify the columns in the order in which they were specified
when the index key was defined. If you only include a subset
of the columns, you must include the leading segments of the
multisegmented index.
For example, if a CREATE INDEX statement specifies a
multisegmented index based on the columns LAST_NAME, FIRST_NAME,
and MIDDLE_INITIAL, then the USING clause must include the first
segment LAST_NAME, or the first two segments, LAST_NAME, and
FIRST_NAME, or all the segments of the index. This is true for
sorted indices only.
The database system uses the values of the columns specified in
the STORE USING clause as a key to determine in which storage
area an index entry associated with a new table row belongs.
There is no restriction for hashed scattered indexes. For hashed
ordered indexes, all segments listed, except the last segment
can be included. Also, HASHED ORDERED indexes have further
restrictions on the data type of the final column; it must be
a date/time or integer numeric data type.
7.3.31 – STORED_NAME_IS
Specifies a name that Oracle Rdb uses to access an index created
in a multischema database. The stored name allows you to access
multischema definitions using interfaces, such as Oracle RMU,
the Oracle Rdb management utility, that do not recognize multiple
schemas in one database. You cannot specify a stored name for
an index in a database that does not allow multiple schemas. For
more information about stored names, see the User_Supplied_Names
HELP topic.
7.3.32 – table-name
The name of the table that includes the index. The table must be
in the same schema as the index.
7.3.33 – threshold-clause
Specifies one, two, or three default threshold values for logical
areas that contain the index in storage areas with uniform
page formats. By setting threshold values, you can make sure
that Oracle Rdb does not overlook a page with sufficient space
to store compressed data. The threshold values (val1, val2,
and val3) represent a fullness percentage on a data page and
establish three possible ranges of guaranteed free space on the
data pages. For more information about logical area thresholds,
see the CREATE STORAGE_MAP.
If you use data compression, you should use logical area
thresholds to obtain optimum storage performance.
You cannot specify the thresholds for the storage map attribute
for any area that is a mixed page format. If you have a mixed
page format, set the thresholds for the storage area using the
ADD STORAGE AREA or CREATE STORAGE AREA clause of the ALTER
DATABASE, CREATE DATABASE, or IMPORT statements.
For more information about SPAM pages, see the Oracle Rdb Guide
to Database Design and Definition.
7.3.34 – TRUNCATE_ALL_PARTITIONS
This clause operates in a similar way to TRUNCATE TABLE, but just
on one index. The index is automatically set to MAINTENANCE IS
ENABLED DEFERRED (i.e. build-pending state) if it was currently
ENABLED IMMEDIATE. Otherwise is stays in a disabled state.
No other clauses may appear in the same ALTER INDEX statement.
7.3.35 – TRUNCATE PARTITION partition-name
This clause operates on just the named index partition. The index
is automatically set to MAINTENANCE IS ENABLED DEFERRED (that
is, build-pending state) if it was currently ENABLED IMMEDIATE.
Otherwise is stays in a disabled state.
No other clauses may appear in the same ALTER INDEX statement.
7.3.36 – TYPE_HASHED
Syntax options:
TYPE IS HASHED ORDERED | TYPE IS HASHED SCATTERED
Specifies that the index is a hashed index. If you specify
HASHED, you cannot use the NODE SIZE, PERCENT FILL, or USAGE
clauses. You can, however, specify if the data is ORDERED or
SCATTERED. SCATTERED is the default.
The TYPE IS HASHED SCATTERED clause is appropriate in situations
where data is not evenly distributed across storage areas. This
option places a record in a page that is chosen by applying a
hashing algorithm to the index key. As a result, the record
distribution pattern is not guaranteed to be even; therefore,
some pages may be chosen more often than others. The TYPE IS
HASHED SCATTERED clause is the default and is recommended unless
your data meets the following criteria for the TYPE IS HASHED
ORDERED clause:
o The last column of the index key must be one of the following
data types:
- TINYINT
- SMALLINT
- INTEGER
- BIGINT
- DATE (both ANSI and VMS)
- TIME
- TIMESTAMP
- INTERVAL
o The index must be ascending.
o The index must not be compressed or have mapping values.
The TYPE IS HASHED ORDERED clause is ideal for applications where
the index key values are evenly distributed across a given range.
This places a record in a page derived by applying an ordered
hashing algorithm to the index key. As a result, the distribution
pattern is guaranteed to follow the index key distribution. In
addition, if you know the range of values, you can size the
storage area and pages to minimize overflows. If the index
key values are not evenly distributed, use the TYPE IS HASHED
SCATTERED clause.
Hashed indexes must be stored in storage areas created with
mixed page format, which means they are valid only in multifile
databases.
Hashed indexes provide fast and direct access to specific rows
and are effective mainly for queries that specify an exact-match
retrieval on a column or columns that are also the key to a
hashed index. (For instance, SELECT EMPLOYEE_ID FROM EMPLOYEES
WHERE EMPLOYEE_ID = "00126", makes effective use of a hashed
index with EMPLOYEE_ID as the index key.)
In a hashed indexing scheme, the index key value is converted
mathematically to a relative page number in the storage area
of a particular table. A hash bucket is a data structure that
maintains information about an index key, and a list of internal
pointers, called database keys or dbkeys, to rows that contain
the particular value of the index key. To find a row using the
hashed index, the database system searches the hash bucket, finds
the appropriate dbkey, and then fetches the table row.
Hashed indexes are most effective for random, direct access when
the query supplies the entire index key on which the hashed index
is defined. For these types of access, I/O operations can be
significantly reduced. This is particularly useful for tables
with many rows and large indexes. For example, to retrieve a
row using a sorted index that is four levels deep, the database
system may need to perform five I/O operations. By using hashing,
the number of I/O operations is reduced to two, at most.
You can define a hashed index and a sorted index for the same
column. Then, depending on the type of query you use, the Oracle
Rdb optimizer chooses the appropriate method of retrieval. For
example, if your query contains an exact-match retrieval, the
optimizer uses hashed index access. If your query contains
a range retrieval, the optimizer uses the sorted index. This
strategy incurs the additional overhead of maintaining two
indexes, therefore, you need to consider the advantages of fast
retrieval against the disadvantages of updating two indexes for
every change to data.
See the Oracle Rdb Guide to Database Design and Definition for
a detailed discussion of the relative advantages of hashed and
sorted indexes.
7.3.37 – TYPE_IS_SORTED
Specifies that the index is a sorted, nonranked (B-tree) index.
If you omit the TYPE IS clause, SORTED is the default. Sorted
indexes improve the performance of queries that compare values
using range operators (like BETWEEN and greater than (>)). (For
example, SELECT EMPLOYEE_ID FROM EMPLOYEES WHERE EMPLOYEE_ID
> 200 is a query that specifies a range retrieval and makes
effective use of a sorted index.)
You can define a hashed index and a sorted index for the same
column. Then, depending on the type of query you use, the Oracle
Rdb optimizer chooses the appropriate method of retrieval. For
example, if your query contains an exact-match retrieval, the
optimizer may use hashed index access. If your query contains
a range retrieval, the optimizer uses the sorted index. This
strategy incurs the additional overhead of maintaining two
indexes; however, you need to consider the advantages of fast
retrieval against the disadvantages of updating two indexes for
every change to data.
See the Oracle Rdb Guide to Database Design and Definition for
more information on the relative advantages of hashed and sorted
indexes.
If you specify a SORTED index, you can optionally specify
NODE SIZE, PERCENT FILL, and USAGE clauses that control the
characteristics of the nodes in the index.
7.3.38 – TYPE_IS_SORTED_RANKED
Specifies that the index is a sorted, ranked (B-tree) index.
The ranked B-tree index allows better optimization of queries,
particularly queries involving range retrievals. Oracle Rdb can
make better estimates of cardinality, reducing disk I/O and lock
contention. Oracle Rdb recommends using ranked sorted indexes.
7.3.39 – UNIQUE
A keyword that specifies whether or not each value of the index
must be unique. If you try to store the same value twice in a
column or set of columns that have an index defined as UNIQUE,
SQL returns an error message the second time and does not store
or modify the row that contains the value. This is true for null
values as well as any other value.
If you specify UNIQUE, SQL checks as it executes the CREATE INDEX
statement to see if the table already contains duplicate values
for the index.
7.3.40 – USAGE
Syntax options:
USAGE UPDATE | USAGE QUERY
Specifies a PERCENT FILL value appropriate for update- or query-
intensive applications. The USAGE UPDATE clause sets the PERCENT
FILL value at 70 percent. The USAGE QUERY clause sets the PERCENT
FILL value at 100 percent.
7.3.41 – WITH_LIMIT_OF
Specifies the highest value for the index key that resides in a
particular storage area if ASCENDING is defined. If DESCENDING
is defined, the lowest value is specified for the index key that
resides in a particular storage are. For multicolumn index keys,
specify a literal value for each column.
The number of literals in the list must be the same as the number
of columns in the USING clause. Repeat this clause to partition
the entries of an index among multiple storage areas. The data
type of the literals must agree with the data type of the column.
For character columns, enclose the literals in single quotation
marks.
If you are creating a multisegmented index using multisegmented
keys and the STORE USING . . . WITH LIMIT clause, and if the
values for the first key are all the same, then set the limit
for the first key at that value. This ensures that the value of
the second key determines the storage area in which each row is
stored.
7.4 – Examples
Example 1: Creating a simple table index
This statement names the index (EMP_EMPLOYEE_ID) and names the
column to serve as the index key (EMPLOYEE_ID).
The UNIQUE argument causes SQL to return an error message if a
user tries to store an identification number that is already
assigned.
SQL> CREATE UNIQUE INDEX EMP_EMPLOYEE_ID ON EMPLOYEES
cont> (EMPLOYEE_ID);
Example 2: Creating an index with descending index segments
This statement names the index (EMP_EMPLOYEE_ID) and names
the column to serve as the descending index key (EMPLOYEE_ID
DESCENDING).
The DESCENDING keyword causes the keys to be sorted in descending
order. If you do not specify DESCENDING or ASCENDING, SQL sorts
the keys in ascending order.
SQL> CREATE UNIQUE INDEX EMP_EMPLOYEE_ID ON EMPLOYEES
cont> (EMPLOYEE_ID DESCENDING);
Example 3: Creating a multisegmented index
SQL> CREATE INDEX EMP_FULL_NAME ON EMPLOYEES
cont> (LAST_NAME,
cont> FIRST_NAME,
cont> MIDDLE_INITIAL);
This statement names three columns to be used in the index EMP_
FULL_NAME. SQL concatenates these three columns to make the
multisegmented index.
Example 4: Creating a compressed numeric index
SQL> CREATE INDEX YEAR1_IND ON DEGREES
cont> (YEAR_GIVEN ASCENDING MAPPING VALUES 1950 TO 1970);
This statement creates ascending index segments for the YEAR_
GIVEN column in the DEGREES table, compressing the year values.
Example 5: Creating a truncated text index
SQL> CREATE INDEX COL_NAME_IND ON COLLEGES
cont> (COLLEGE_NAME SIZE IS 20);
This statement creates a compressed index, COL_NAME_IND, on the
COLLEGES table so that the number of octets from the COLLEGE_NAME
column that are used as a key cannot exceed 20 octets.
Example 6: Creating an index in a uniform storage area with
thresholds.
SQL> ALTER DATABASE FILENAME mf_personnel
cont> ADD STORAGE AREA UNIFORM1 PAGE FORMAT IS UNIFORM;
SQL> ALTER DATABASE FILENAME mf_personnel
cont> ADD STORAGE AREA UNIFORM2 PAGE FORMAT IS UNIFORM;
SQL> ATTACH 'FILENAME mf_personnel';
SQL> CREATE UNIQUE INDEX EMP_THRESHOLDS ON EMPLOYEES (EMPLOYEE_ID)
cont> TYPE IS SORTED
cont> STORE USING (EMPLOYEE_ID)
cont> IN RDB$SYSTEM (THRESHOLDS ARE (60,75,90))
cont> WITH LIMIT OF ('00200')
cont> IN UNIFORM1 (THRESHOLD IS (65))
cont> WITH LIMIT OF ('00400')
cont> OTHERWISE IN UNIFORM2
cont> (THRESHOLD OF (90));
%RDB-W-META_WARN, metadata successfully updated with the reported warning
-RDMS-W-IDXCOLEXIST, an index with this column list already exists
SQL> --
SQL> SHOW INDEX EMP_THRESHOLDS
Indexes on table EMPLOYEES:
EMP_THRESHOLDS with column EMPLOYEE_ID
No Duplicates allowed
Type is Sorted
Key suffix compression is DISABLED
Node size 430
Store clause: STORE USING (EMPLOYEE_ID)
IN RDB$SYSTEM (THRESHOLDS ARE (60,75,90))
WITH LIMIT OF ('00200')
IN UNIFORM1 (THRESHOLD IS (65))
WITH LIMIT OF ('00400')
OTHERWISE IN UNIFORM2
(THRESHOLD OF (90))
This statement uses the STORE clause to partition the index into
different uniform page format storage areas and apply thresholds.
In Examples 7 and 8, the table COLOURS in the database MIA_CHAR_
SET is defined as:
SQL> CREATE TABLE COLOURS
cont> (ENGLISH MCS_DOM,
cont> FRENCH MCS_DOM,
cont> JAPANESE KANJI_DOM,
cont> ROMAJI DEC_KANJI_DOM,
cont> KATAKANA KATAKANA_DOM,
cont> HINDI HINDI_DOM,
cont> GREEK GREEK_DOM,
cont> ARABIC ARABIC_DOM,
cont> RUSSIAN RUSSIAN_DOM);
Example 7: Creating a simple table index using the octets
character length, which is the default
SQL> SET CHARACTER LENGTH 'OCTETS';
SQL> CREATE INDEX COLOUR_INDEX ON COLOURS (JAPANESE SIZE IS 4)
cont> TYPE IS SORTED;
SQL> SHOW INDEX COLOUR_INDEX;
Indexes on table COLOURS:
COLOUR_INDEX with column JAPANESE
size of index key is 4 octets
Duplicates are allowed
Type is Sorted
The previous statement creates a compressed index key of 4
octets.
Example 8: Creating an index using the CHARACTERS character
length
SQL> SET CHARACTER LENGTH 'CHARACTERS';
SQL> CREATE INDEX COLOUR_INDEX_2 ON COLOURS (JAPANESE SIZE IS 4)
cont> TYPE IS SORTED;
SQL> SHOW INDEX COLOUR_INDEX_2;
Indexes on table COLOURS:
COLOUR_INDEX_2 with column JAPANESE
size of index key is 4 characters
Duplicates are allowed
Type is Sorted
The previous statement creates a compressed index key of 4
characters.
Example 9: Creating an index that enables compression
The following example shows how to create an index and enable
compression with a minimum run length of 2:
SQL> CREATE INDEX EMP_NDX ON EMPLOYEES
cont> (EMPLOYEE_ID SIZE IS 4)
cont> ENABLE COMPRESSION (MINIMUM RUN LENGTH 2);
SQL> SHOW INDEX EMP_NDX;
Indexes on table EMPLOYEES:
EMP_NDX with column EMPLOYEE_ID
size of index key is 4
Duplicates are allowed
Type is Sorted
Compression is ENABLED (Minimum run length 2)
Example 10: Using the Index Attributes Clause
SQL> CREATE UNIQUE INDEX JOB_JOB_CODE
cont> ON JOBS (
cont> JOB_CODE
cont> ASC)
cont> TYPE IS SORTED
cont> THRESHOLDS ARE (75,83,90)
cont> ENABLE COMPRESSION
cont> NOLOGGING
cont> COMMENT IS 'Used for translation of job codes';
%RDB-W-META_WARN, metadata successfully updated with the reported warning
-RDMS-W-DATACMIT, unjournaled changes made; database may not be recoverable
SQL> -- SQL returned this message because the NOLOGGING attribute
SQL> -- was set.
Example 11: Creating an Index and Displaying the Default Node
Size
SQL> -- Create a simple table upon which to define
SQL> -- some indexes
SQL>
SQL> CREATE TABLE TEST_INDEX_TABLE
cont> (A CHAR(70),
cont> B INTEGER);
SQL>
SQL> -- Default value is 430 bytes
SQL>
SQL> CREATE UNIQUE INDEX TEST_INDEX_DEF
cont> ON TEST_INDEX_TABLE (A, B)
cont> TYPE IS SORTED
cont> USAGE UPDATE;
SQL>
SQL> SHOW TABLE (INDEX) TEST_INDEX_TABLE
Information for table TEST_INDEX_TABLE
TEST_INDEX_DEF with column A
and column B
No Duplicates allowed
Type is Sorted
Compression is DISABLED
Node size 430
Percent fill 70
Example 12: Naming Partitions
SQL> -- Alter mf_personnel database to add three slots
SQL> -- for storage areas and then add three storage areas.
SQL> ALTER DATABASE FILENAME MF_PERSONNEL
cont> RESERVE 3 STORAGE AREAS;
%RDMS-W-DOFULLBCK, full database backup should be done to ensure future recovery
SQL> ALTER DATABASE FILENAME MF_PERSONNEL
cont> ADD STORAGE AREA WAGE_LOW;
SQL> ALTER DATABASE FILENAME MF_PERSONNEL
cont> ADD STORAGE AREA WAGE_MID;
SQL> ALTER DATABASE FILENAME MF_PERSONNEL
cont> ADD STORAGE AREA WAGE_HIGH;
SQL> ATTACH 'FILENAME MF_PERSONNEL.RDB';
SQL> -- Create an index on the JOBS table and name the partitions
SQL> CREATE INDEX WAGE_CLASS_IDX ON JOBS (WAGE_CLASS)
cont> TYPE IS SORTED
cont> STORE USING (WAGE_CLASS)
cont> IN WAGE_LOW (PARTITION WAGE_LOW) WITH LIMIT OF ('1')
cont> IN WAGE_MID (PARTITION WAGE_MID) WITH LIMIT OF ('3')
cont> OTHERWISE IN WAGE_HIGH (PARTITION WAGE_HIGH);
Example 13: Creating a Large Index Partitioned Across Many
Storage Areas
First, create the database definition:
SQL> CREATE INDEX ... MAINTENANCE IS ENABLED DEFERRED ...;
Next submit batch jobs to build each partition in parallel. For
example, each batch job would execute a script similar to the
following:
ATTACH 'filename testdatabase';
SET FLAGS 'index_stats';
ALTER INDEX TRANSACTIONS_INDEX BUILD PARTITION PART_1;
COMMIT;
Finally, after the batch jobs have completed, the database
administrator must make the index active for query usage by
changing the maintenance mode to ENABLED IMMEDIATE. A BUILD
ALL PARTITIONS clause could be added in case any step failed
(possibly due to resource limitations or a failed node).
SQL> SET FLAGS 'index_stats';
SQL> SET TRANSLATION READ WRITE RESERVING...FOR EXCLUSIVE WRITES;
SQL> ALTER INDEX ... BUILD ALL PARTITIONS;
SQL> ALTER INDEX ... MAINTENANCE IS ENABLED IMMEDIATE;
SQL> COMMIT;
This scheme has several advantages over issuing a CREATE INDEX
statement directly:
o The build actions can be run in parallel, which allows
better resource usage (read and sort fewer rows), and reduced
execution time for the index creation.
o The partitions being processed are relatively small when
compared to the full index and, therefore, smaller quantities
of data will be processed. This will result in smaller .ruj
files and less AIJ file space for these transactions.
o Each build partition runs in a separate transaction, can
easily be repeated if a step fails, and does not require
repeating the entire CREATE INDEX statement.
o If any steps have failed, they will also be repeated by the
BUILD ALL PARTITIONS clause included in the script.
8 – MODULE
Defines a module as an object in an Oracle Rdb database. Stored
with the module are its functions and procedures. A function or
procedure written in SQL that resides with the data in a database
is called a stored function or stored procedure. Likewise, a
module stored in a database is called a stored module. A stored
routine refers to either a stored procedure or stored function.
You invoke a stored procedure with the CALL statement from a
simple statement procedure in embedded SQL, SQL module language,
or interactive SQL or with the CALL statement from within a
compound statement.
You invoke a stored function by specifying the function name in a
value expression.
SQL uses the concept of a module as its mechanism for storing,
showing, deleting, and granting and revoking privileges on stored
routines within a database. This means you cannot store, delete,
or grant and revoke privileges on individual stored routines.
Should you need to remove a stored routine, use the DROP FUNCTION
routine-name CASCADE or DROP PROCEDURE routine-name CASCADE
syntax.
In general, SQL operates on modules, not stored routines.
However, there are a few exceptions: DROP FUNCTION, DROP
PROCEDURE, RENAME, SHOW FUNCTION, SHOW PROCEDURE, and CALL. The
SHOW FUNCTION statement displays information about functions.
The SHOW PROCEDURE statement displays individual procedures in a
stored module. The CALL statement can invoke only a single stored
procedure.
8.1 – Environment
You can use the CREATE MODULE statement in a simple statement
procedure:
o In interactive SQL
o Embedded in host language programs to be precompiled
o As part of a procedure in an SQL module
o In dynamic SQL as a statement to be dynamically executed
8.2 – Format
CREATE MODULE -> <module-name> +---------------------------------+-+
+-> STORED NAME IS <stored-name> -+ |
+------------------------------------<-----------------------------+
+-+-------------------+---+----------------------------+-----------+
+-> LANGUAGE SQL ---+ +-> AUTHORIZATION <auth-id> -+ |
+------------------------------------------------------------------+
++---------------------------------+-+--------------------+--------+
+-> COMMENT IS -+-> 'string' ---+-+ +-> declare-clause --+ |
+------ / <-----+ |
+------------------------------------------------------------------+
+-+-> routine-clause ---+--> END MODULE --->
+-------- <-----------+
declare-clause =
--+-+-> declare-transaction-statement -----------+-+-->
| +-> declare-local-temporary-table-statement -+ |
| +-> declare-variable-statement --------------+ |
+----------------------<-------------------------+
routine-clause =
-+> PROCEDURE <procedure-name> +-+-------------------> -----------++
+> FUNCTION <function-name> --+ +> STORED NAME IS <stored-name> -+|
+----------------------------------------- <-----------------------+
+---+--------------------> ---------------------+---+
+--> ( -+----------------------------+-- ) -+ |
++-> parameter-decl --------++ |
+----------- , <-----------+ |
+---------------------------------------------------+
++----------------------------++----------------------+---------+
+> RETURNS result-data-type -++---> function-attr ---+ |
+------------------------------------------ <-------------------+
++--------------------------------+-> ; -+-> compound-statement -----+> ; -->
+> routine-attr -----------------+ +-> compound-use-statement -+
+-> external-body-clause ---+
parameter-decl =
--+----------++---------------------++-> data-type -----+---+
+-> IN ----++-> <parameter-name> -++-> <domain-name> -+ |
+-> OUT ---+ |
+-> INOUT -+ |
+------------------------------<--------------------------+
+-+---------------------+-+-----------------------+-------+
+-> mechanism-clause -+ +-> DEFAULT value-expr -+ |
+---------------------------------------------------------+
+--+--------------------------------+------------------------->
+-> COMMENT IS -+-> 'string' ---++
+------ / <-----+
function-attr =
-++--------+-+-> VARIANT -------++->
|+-> NOT -+ +-> DETERMINISTIC -+|
+--> LANGUAGE SQL --------------+
routine-attr =
--+-> COMMENT IS --+-> 'string' --+-+-->
| +------ , <----+ |
+-> USAGE IS -+-> LOCAL ---+------+
+-> GLOBAL --+
8.3 – Arguments
8.3.1 – AUTHORIZATION auth id
A name that identifies the definer of a module and is used to
perform privilege validation for the module. the User_Supplied_
Names HELP topic for information about using authorization
identifiers.
8.3.2 – COMMENT_IS
Adds a comment about the module, routine, and parameter. SQL
displays the text of the comment when it executes a SHOW MODULE,
SHOW FUNCTION, or SHOW PROCEDURE statement. Enclose the comment
in single quotation marks (') and separate multiple lines in a
comment with a slash mark (/).
8.3.3 – compound-statement
Allows you to include more than one SQL statement in a stored
routine. See the Compound_Statement HELP topic for more
information.
8.3.4 – compound-use-statement
Allows you to include one SQL statement in a stored routine. See
the Compound_Statement HELP topic for more information.
If you are defining a stored function, the simple statement must
be the RETURNS clause.
8.3.5 – data-type
A valid SQL data type. Specifying an explicit data type is an
alternative to specifying a domain name. See the Data_Types HELP
topic for more information on data types.
8.3.6 – decl-local-temp-table-statement
Declares a local temporary table for the module. See the DECLARE
LOCAL_TEMPORARY_TABLE statement for more information.
8.3.7 – declare-transaction-statement
Declares a transaction for the module. Only one declare-
transaction-statement is permitted for each module. If omitted,
an implicit DECLARE TRANSACTION READ WRITE is used. See the
DECLARE TRANSACTION statement for more information.
8.3.8 – declare-variable-statement
Declares a global variable for the module. See the statement
DECLARE Variable for more information.
8.3.9 – DEFAULT value-expr
Specifies the default value of a parameter for a function or
procedure defined with mode IN. If you omit this parameter or if
the Call statement argument list or function invocation specifies
the DEFAULT keyword, then the value-expr specified with this
clause is used. The parameter uses NULL as the default if you do
not specify a value expression explicitly.
8.3.10 – DETERMINISTIC
Syntax options:
DETERMINISTIC | NOT DETERMINISTIC
The clause controls the evaluation of an external function in the
scope of a query:
o NOT DETERMINISTIC
Specifying the NOT DETERMINISTIC clause forces evaluation
of corresponding functions (in scope of a single query)
every time the function appears. If a function can return a
different result each time it is invoked, you should use the
DETERMINISTIC clause.
o DETERMINISTIC
Specifying the DETERMINISTIC clause can result in a single
evaluation of corresponding function expressions (in scope
of a single query), and the resulting value is used in all
occurrences of the corresponding function expression. When you
use the DETERMINISTIC clause, Oracle Rdb evaluates whether or
not to invoke the function each time it is used.
For example:
SELECT * FROM T1 WHERE F1() > 0 AND F1() < 20;
If you define the F1 function as DETERMINISTIC, the function
F1() may be evaluated just once depending on the optimizer. If
you define the F1 function as NOT DETERMINISTIC, the function
F1() is evaluated twice.
DETERMINISTIC is the default.
The DETERMINISTIC or NOT DETERMINISTIC clause is not allowed on
procedure definitions.
8.3.11 – domain-name
The name of a domain created in a CREATE DOMAIN statement. For
more information about domains, see the CREATE DOMAIN statement.
8.3.12 – DEFAULT value-expr
Specifies the default value of a parameter for a function or
procedure defined with mode IN. If you omit this parameter or if
the Call statement argument list or function invocation specifies
the DEFAULT keyword, then the value-expr specified with this
clause is used. The parameter uses NULL as the default if you do
not specify a value expression explicitly.
8.3.13 – FUNCTION function-name
A user-supplied name that you give to a function in a module. The
name you specify must be unique within the database definition.
8.3.14 – IN parameter name
Specifies the parameter modes used in the procedure. The IN
parameter names the parameter that is read into the routine,
however is never set and cannot be written to.
The IN parameter is the only mode allowed for functions.
Each parameter name must be unique within the routine.
8.3.15 – INOUT parameter name
Specifies the parameter modes used in the procedure. The INOUT
parameter names a parameter that inputs data (is read) as well as
receives data (is set). The INOUT parameter is a parameter that
is modified.
Each parameter name must be unique within the procedure.
You cannot use the INOUT parameter mode for stored functions.
8.3.16 – LANGUAGE_SQL
The LANGUAGE keyword and the SQL argument signify that the
procedures in a module are to be invoked by SQL statements, not a
host language program.
With unstored procedures, the LANGUAGE keyword specifies the name
of a host language; this identifies the host language in which
the program calling a module's procedures is written.
Beginning with Oracle Rdb Release 7.1, this clause is optional.
8.3.17 – module-name
A user-supplied name that you assign to a module.
See the User_Supplied_Names HELP topic for more information on
user-supplied names.
8.3.18 – OUT parameter name
Specifies the parameter modes used in the procedure. The OUT
parameter names the parameter into which data is being sent. The
OUT parameter is set, but never read.
Each parameter name must be unique within the procedure.
You cannot use the OUT parameter mode for stored functions.
8.3.19 – parameter-decl
Specifies the parameters and parameter modes used in a stored or
external routine.
8.3.20 – PROCEDURE procedure-name
A user-supplied name that you give to a procedure in a module.
The name you specify must be unique within the database
definition.
8.3.21 – RETURNS result data type
Specifies the data type or domain of the result of the function
invocation. This clause is only valid when defining a function.
You can only use the RETURNS clause when defining a function.
8.3.22 – routine-clause
The definition of a stored function or stored procedure created
in a module.
8.3.23 – STORED_NAME_IS
Specifies a name that Oracle Rdb uses to access a module
procedure or function created in a multischema database. Or
specifies a name that Oracle Rdb uses to access a procedure or
a function created in a stored module.
8.3.24 – USAGE_IS
Specifies how the function or procedure can be called:
o USAGE IS GLOBAL indicates that the function or procedure can
be called outside the current module. This is the default.
o USAGE IS LOCAL specifies that the routine is restricted to
references within the module. This clause is provided for
compatibility with CREATE MODULE but is not allowed for CREATE
FUNCTION or CREATE PROCEDURE.
8.3.25 – VARIANT
Syntax options:
VARIANT | NOT VARIANT
These clauses are synonyms for the DETERMINISTIC and NOT
DETERMINISTIC clauses. The DETERMINISTIC clause indicates that
the same inputs to the function will generate the same output.
It is the same as the NOT VARIANT clause. The NOT DETERMINISTIC
clause indicates that the output of the function does not depend
on the inputs. It is the same as the VARIANT clause.
This clause is deprecated. Use DETERMINISTIC instead.
8.3.26 – variant-clause
Syntax options:
DETERMINISTIC | NOT DETERMINISTIC
The clause controls the evaluation of an external function in the
scope of a query:
o NOT DETERMINISTIC
Specifying the NOT DETERMINISTIC clause forces evaluation
of corresponding functions (in scope of a single query)
every time the function appears. If a function can return a
different result each time it is invoked, you should use the
DETERMINISTIC clause.
o DETERMINISTIC
Specifying the DETERMINISTIC clause can result in a single
evaluation of corresponding function expressions (in scope
of a single query), and the resulting value is used in all
occurrences of the corresponding function expression. When you
use the DETERMINISTIC clause, Oracle Rdb evaluates whether or
not to invoke the function each time it is used.
For example:
SELECT * FROM T1 WHERE F1() > 0 AND F1() < 20;
If you define the F1 function as DETERMINISTIC, the function
F1() may be evaluated just once depending on the optimizer. If
you define the F1 function as NOT DETERMINISTIC, the function
F1() is evaluated twice.
DETERMINISTIC is the default.
The DETERMINISTIC or NOT DETERMINISTIC clause is not allowed on
procedure definitions.
8.4 – Examples
Example 1: Creating a stored module and stored procedure
The following example shows how to create a stored module and
stored procedure using interactive SQL:
SQL> CREATE MODULE testmod LANGUAGE SQL
cont> PROCEDURE testproc;
cont> COMMIT;
cont> END MODULE;
SQL> SHOW MODULE testmod
Module name is: TESTMOD
Source:
TESTMOD LANGUAGE SQL
Owner is:
Module ID is: 1
Example 2: Creating a stored module with SQL module language
The following code fragment shows how to create a stored module
as part of a procedure in a nonstored module:
PROCEDURE create_them
SQLCODE;
CREATE MODULE my LANGUAGE SQL AUTHORIZATION smith
PROCEDURE p1 ( :x CHAR(5) );
BEGIN
INSERT INTO s (snum) VALUES (:x);
END;
PROCEDURE p2 ( :y SMALLINT );
BEGIN
SELECT STATUS INTO :y FROM s LIMIT TO 1 ROW;
END;
PROCEDURE p3 (:x INT, :y SMALLINT );
BEGIN
INSERT INTO s (snum) VALUES (:x);
SELECT STATUS INTO :y FROM s WHERE snum = :x;
END;
PROCEDURE p4 (:x CHAR(5), :y CHAR(20) );
BEGIN
INSERT INTO s (snum,sname) VALUES (:x, :y);
SELECT sname INTO :y FROM s WHERE snum = :x;
END;
END MODULE;
Example 3: Creating a stored module containing a stored routines
SQL> CREATE MODULE utility_functions
cont> LANGUAGE SQL
cont> --
cont> -- Define a stored procedure.
cont> --
cont> PROCEDURE trace_date (:dt DATE);
cont> BEGIN
cont> TRACE :dt;
cont> END;
cont> --
cont> FUNCTION mdy (IN :dt DATE) RETURNS CHAR(10)
cont> COMMENT 'Returns the date in month/day/year format';
cont> BEGIN
cont> IF :dt IS NULL THEN
cont> RETURN '**/**/****';
cont> ELSE
cont> CALL trace_date (:dt);
cont> RETURN CAST(EXTRACT(MONTH FROM :dt) AS VARCHAR(2)) || '/' ||
cont> CAST(EXTRACT(DAY FROM :dt) AS VARCHAR(2)) || '/' ||
cont> CAST(EXTRACT(YEAR FROM :dt) AS VARCHAR(4));
cont> END IF;
cont> END;
cont> END MODULE;
Example 4: Using a stored function in a SELECT statement
SQL> SELECT mdy(job_end), job_end
cont> FROM job_history WHERE employee_id = '00164';
JOB_END
**/**/**** NULL
9/20/1981 20-Sep-1981
2 rows selected
Example 5: Using declared local temporary tables in stored
procedures
SQL> -- The following table must exist in order to execute the following
SQL> -- queries.
SQL> --
SQL> CREATE TABLE payroll
cont> (employee_id CHAR(5),
cont> hours_worked INTEGER,
cont> hourly_sal REAL,
cont> week_date CHAR(10));
SQL> COMMIT;
SQL> --
SQL> -- Create the module containing a declared local temporary table.
SQL> --
SQL> CREATE MODULE paycheck_decl_mod
cont> LANGUAGE SQL
cont> DECLARE LOCAL TEMPORARY TABLE module.paycheck_decl_tab
cont> (employee_id ID_DOM,
cont> last_name CHAR(14) ,
cont> hours_worked INTEGER,
cont> hourly_sal INTEGER(2),
cont> weekly_pay INTEGER(2))
cont> ON COMMIT PRESERVE ROWS
cont> --
cont> -- Create the procedure to insert rows.
cont> --
cont> PROCEDURE paycheck_ins_decl;
cont> BEGIN
cont> INSERT INTO module.paycheck_decl_tab
cont> (employee_id, last_name, hours_worked, hourly_sal, weekly_pay)
cont> SELECT p.employee_id, e.last_name,
cont> p.hours_worked, p.hourly_sal,
cont> p.hours_worked * p.hourly_sal
cont> FROM employees e, payroll p
cont> WHERE e.employee_id = p.employee_id
cont> AND p.week_date = '1995-08-01';
cont> END;
cont> --
cont> -- Create the procedure to count the low hours.
cont> --
cont> PROCEDURE low_hours_decl (:cnt INTEGER);
cont> BEGIN
cont> SELECT COUNT(*) INTO :cnt FROM module.paycheck_decl_tab
cont> WHERE hours_worked < 40;
cont> END;
cont> END MODULE;
SQL> --
SQL> -- Call the procedure to insert the rows.
SQL> --
SQL> CALL paycheck_ins_decl();
SQL> --
SQL> -- Declare a variable and call the procedure to count records with
SQL> -- low hours.
SQL> --
SQL> DECLARE :low_hr_cnt integer;
SQL> CALL low_hours_decl(:low_hr_cnt);
LOW_HR_CNT
2
SQL> --
SQL> -- Because the table is a declared local temporary table, you cannot
SQL> -- access it from outside the stored module that contains it.
SQL> --
SQL> SELECT * FROM module.paycheck_decl_tab;
%SQL-F-RELNOTDCL, Table PAYCHECK_DECL_TAB has not been declared in module or
environment
Example 6: Creating a stored procedure containing a simple
statement
SQL> CREATE MODULE a
cont> LANGUAGE SQL
cont> PROCEDURE new_salary_proc
cont> (:id CHAR (5),
cont> :new_salary INTEGER (2));
cont> UPDATE salary_history
cont> SET salary_end = CURRENT_TIMESTAMP
cont> WHERE employee_id = :id;
cont> END MODULE;
Example 7: Declaring a Global Variable to Exchange Information
Between Two Routines
SQL> CREATE MODULE sample
cont> LANGUAGE SQL
cont> DECLARE :iter_count INTEGER
cont> PROCEDURE set_iter (IN :val INTEGER)
cont> COMMENT IS 'Validate the iteration count and assign'
cont> / 'to a global variable.';
cont> BEGIN
cont> IF (:val IS NULL) OR (:val < 1) THEN
cont> SIGNAL 'XXXXX'; --illegal value
cont> ELSE
cont> SET :iter_count =:val;
cont> TRACE 'Iteration count set to ', :val;
cont> END IF;
cont> END;
cont> FUNCTION GET_ITER ()
cont> RETURNS INTEGER
cont> COMMENT IS 'Trace the value used and then return the'
cont> / 'value from the global variable.';
cont> BEGIN
cont> TRACE 'Using iteration count ', :iter_count;
cont> RETURN :iter_count;
cont> END;
cont> END MODULE;
Example 8: Using a cursor implemented by external routines
This example uses multiple external routines to manage a table
cursor in the external routine database environment. This
management includes the OPEN, FETCH and CLOSE of a single cursor.
Several domains are defined so that parameter data types can be
consistently defined in the database that contain the application
and also the database upon which the cursor is open.
create domain SQLSTATE_T char(5);
create domain STATUS_CODE char(1);
create domain STATUS_NAME char(8);
create domain STATUS_TYPE char(14);
The external function interface is contained within a single
CREATE MODULE statement. This module also contains the
application in a single stored SQL procedure.
create module EX
language SQL
-- These procedure define the interface to the external
-- routines that implement the transaction and cursor operations
--
procedure EX_START_READ_TXN
(inout :ss sqlstate_t);
external location 'TEST$SCRATCH:EX.EXE'
language general
general parameter style
comment is 'start a READ ONLY transaction';
procedure EX_COMMIT
(inout :ss sqlstate_t);
external location 'TEST$SCRATCH:EX.EXE'
language general
general parameter style;
procedure EX_OPEN_CURSOR
(inout :ss sqlstate_t);
external location 'TEST$SCRATCH:EX.EXE'
language general
general parameter style
comment is 'find all rows in WORK_STATUS order by STATUS_CODE';
procedure EX_CLOSE_CURSOR
(inout :ss sqlstate_t);
external location 'TEST$SCRATCH:EX.EXE'
language general
general parameter style;
procedure EX_FETCH_CURSOR
(inout :ss sqlstate_t,
out :s_code STATUS_CODE, out :s_code_ind integer,
out :s_name STATUS_NAME, out :s_name_ind integer,
out :s_type STATUS_TYPE, out :s_type_ind integer);
external location 'TEST$SCRATCH:EX.EXE'
language general
general parameter style;
-- This SQL procedures implements a simple application
--
procedure WORK_STATUS
comment is 'Use an external cursor to fetch all rows in the'
/ 'WORK_STATUS table';
begin
declare :s_code STATUS_CODE;
declare :s_name STATUS_NAME;
declare :s_type STATUS_TYPE;
declare :s_code_ind, :s_name_ind, :s_type_ind integer;
declare :ss sqlstate_t;
-- start a read-only transaction on the PERSONNEL database
call EX_START_READ_TXN (:ss);
if :ss ^= '00000' then
SIGNAL :ss;
end if;
-- open the cursor on the work-status table
call EX_OPEN_CURSOR (:ss);
if :ss ^= '00000' then
SIGNAL :ss;
end if;
-- now loop and fetch all the rows
FETCH_LOOP:
loop
call EX_FETCH_CURSOR (:ss,
:s_code, :s_code_ind,
:s_name, :s_name_ind,
:s_type, :s_type_ind);
case :ss
when '02000' then
-- no more rows to fetch
leave FETCH_LOOP;
when '00000' then
begin
-- we have successfully fetched a row, so display it
trace 'Status Code: ', case when :s_code_ind < 0
then 'NULL'
else :s_code
end;
trace 'Status Name: ', case when :s_name_ind < 0
then 'NULL'
else :s_name
end;
trace 'Status Type: ', case when :s_type_ind < 0
then 'NULL'
else :s_type
end;
trace '***';
end;
else
-- signal will implicitly leave the stored procedure
SIGNAL :ss;
end case;
end loop;
-- close the cursor
call EX_CLOSE_CURSOR (:ss);
if :ss ^= '00000' then
SIGNAL :ss;
end if;
-- commit the transaction
call EX_COMMIT (:ss);
if :ss ^= '00000' then
SIGNAL :ss;
end if;
end;
end module;
The external procedures for this this example are written using
the SQL module language. However, any language with embedded SQL,
such as C, could have been used.
module EX
language GENERAL
parameter colons
-- EX: Sample application
-- Process the WORK_STATUS table using a table cursor
--
declare alias filename 'PERSONNEL'
declare c cursor for
select status_code, status_name, status_type
from WORK_STATUS
order by status_code
procedure EX_START_READ_TXN
(sqlstate);
begin
-- abort any stray transactions
rollback;
-- start a READ ONLY transaction
set transaction read only;
end;
procedure EX_COMMIT
(sqlstate);
commit work;
procedure EX_ROLLBACK
(sqlstate);
rollback work;
procedure EX_OPEN_CURSOR
(sqlstate);
open c;
procedure EX_CLOSE_CURSOR
(sqlstate);
close c;
procedure EX_FETCH_CURSOR
(sqlstate,
:s_code STATUS_CODE,
:s_code_ind integer,
:s_name STATUS_NAME,
:s_name_ind integer,
:s_type STATUS_TYPE,
:s_type_ind integer);
fetch c
into :s_code indicator :s_code_ind,
:s_name indicator :s_name_ind,
:s_type indicator :s_type_ind;
procedure EX_DISCONNECT
(sqlstate);
disconnect default;
When run the application calls the external procedures to open
the cursor and fetch the rows and display them using the TRACE
statement.
SQL> set flags 'trace';
SQL>
SQL> call WORK_STATUS ();
~Xt: Status Code: 0
~Xt: Status Name: INACTIVE
~Xt: Status Type: RECORD EXPIRED
~Xt: ***
~Xt: Status Code: 1
~Xt: Status Name: ACTIVE
~Xt: Status Type: FULL TIME
~Xt: ***
~Xt: Status Code: 2
~Xt: Status Name: ACTIVE
~Xt: Status Type: PART TIME
~Xt: ***
SQL>
Oracle recommends that the cursors be closed, and the external
routines database environment be disconnected before the calling
session is disconnected. This can be achieved by using NOTIFY
routines.
For example, the external procedure that starts the transaction
could be modified as shown below to declare a NOTIFY routine (EX_
RUNDOWN) that when called would close the cursors, rollback the
transaction and disconnect from the database.
procedure EX_START_READ_TXN
(inout :ss sqlstate_t);
external location 'TEST$SCRATCH:EX.EXE'
language general
general parameter style
notify EX_RUNDOWN on BIND
comment is 'start a READ ONLY transaction';
The BIND notification ensures that EX_RUNDOWN will be called
during the DISCONNECT of the caller and allow the transaction to
be rolled back and the session disconnected. ROLLBACK or COMMIT
will implicitly close any open cursors, unless the cursor were
defined as WITH HOLD. In this case it is important to also close
that cursor. Code similar to the following (in C) could implement
this rundown routine.
#include <string.h>
#include <stdio.h>
#define RDB$K_RTX_NOTIFY_ACTV_END 2
#define SQLSTATE_LEN 5
void sql_signal ();
void EX_CLOSE_CURSOR (char sqlstate [SQLSTATE_LEN]);
void EX_DISCONNECT (char sqlstate [SQLSTATE_LEN]);
void EX_ROLLBACK (char sqlstate [SQLSTATE_LEN]);
extern void EX_RUNDOWN
(int *func_code,
int *u1, /* U1, U2, U3 are currently unused */
int *u2, /* and are reserved for future use */
int *u3)
{
char sqlstate [SQLSTATE_LEN];
if (*func_code == RDB$K_RTX_NOTIFY_ACTV_END)
{
/* we are running down this external routine, so
* close the cursor
*/
EX_CLOSE_CURSOR (sqlstate);
if (memcmp ("00000", sqlstate, SQLSTATE_LEN) != 0
&& memcmp ("24000", sqlstate, SQLSTATE_LEN) != 0)
/* we expect success or maybe 24000 (bad cursor state)
*/
sql_signal ();
/* rollback the transaction
*/
EX_ROLLBACK (sqlstate);
if (memcmp ("00000", sqlstate, SQLSTATE_LEN) != 0
&& memcmp ("25000", sqlstate, SQLSTATE_LEN) != 0)
/* we expect success or maybe 25000 (bad transaction state)
*/
sql_signal ();
/* disconnect from the database
*/
EX_DISCONNECT (sqlstate);
if (memcmp ("00000", sqlstate, SQLSTATE_LEN) != 0)
/* we expect success or maybe 25000 (bad transaction state)
*/
sql_signal ();
}
}
The application can be compiled and built using this fragment of
DCL code:
$ create ex.opt
symbol_vector = (EX_START_READ_TXN = procedure)
symbol_vector = (EX_COMMIT = procedure)
symbol_vector = (EX_ROLLBACK = procedure)
symbol_vector = (EX_OPEN_CURSOR = procedure)
symbol_vector = (EX_CLOSE_CURSOR = procedure)
symbol_vector = (EX_FETCH_CURSOR = procedure)
symbol_vector = (EX_DISCONNECT = procedure)
symbol_vector = (EX_RUNDOWN = procedure)
psect_attr = RDB$MESSAGE_VECTOR,noshr
psect_attr = RDB$DBHANDLE,noshr
psect_attr = RDB$TRANSACTION_HANDLE,noshr
sql$user/library
$
$ cc EX_RUNDOWN
$ sql$mod EX
$ link/share EX,EX_RUNDOWN,EX/option
9 – OUTLINE
Creates a new query outline and stores this outline in the
database.
A query outline is an overall plan for how a query can be
implemented and may contain directives that control the join
order, join methods, index usage (or all of these) the optimizer
selects when processing a query. Use of query outlines helps
ensure that query performance is highly stable across releases of
Oracle Rdb.
9.1 – Environment
You can use the CREATE OUTLINE statement only in interactive SQL.
9.2 – Format
CREATE OUTLINE <outline-name> -+--------------------------------++
+> STORED NAME IS <stored-name> -+|
+------------------------- <-------------------------------------+
++-> FROM --> ( --> <sql-query> --> ) ----------+---------+
+-> on-clause ---------------------------------+ |
+-> ID 'id-number' ----------------------------+ |
+------------------------------ <-----------------------+
+-----+------------++--------------------------------+--+
+> MODE mode ++> AS ---+>( -> query-list -> )--+ |
+> USING + |
+--------------------------- <----------------------------+
++-----------------------------+--------------------------+
+> COMPLIANCE -+-> MANDATORY -+ |
+-> OPTIONAL --+ |
+--------------------------- <----------------------------+
++-------------------------------------------------------++
+> EXECUTION OPTIONS --> ( --> execution-options --> ) -+|
+--------------------------- <----------------------------+
++--------------------------------+----------------------------->
+> COMMENT IS --+-> 'string' ---++
+----- / <------+
on-clause =
---> ON --+-> PROCEDURE -+-+-> ID proc-id ----+-+->
+-> FUNCTION --+ +-> NAME <name> ---+ |
+-> COLUMN ------+-----> <name> ------+
+-> CONSTRAINT --+
+-> TRIGGER -----+
+-> VIEW --------+
query-list =
---+-> QUERY (source) ----------+---------->
+-------------<--------------+
source =
-+-+-------------+--+-> table-access --------------+--+-------->
| +-> FLOATING -+ +-> ORDERED ---+--> (source) --+ |
| +-> UNORDERED -+ | |
| +-> subquery-list -------------+ |
| +--------------------------------------------------+
| +-> JOIN BY -+--> CROSS ------+--- TO -----+--+
| | +--> MATCH ------+ | |
| | +--> ANY METHOD -+ | |
| +-> UNION WITH ----------------------------+ |
+------------------------<----------------------+
table-access =
---> <table-name> -+-------------------------+-> context --+
+-> MODULE <module-name> -+ |
+----------------------------------------------------------+
+-> ACCESS --> PATH ---+------------------------------+--->
+--> ANY ----------------------+
+--> SEQUENTIAL ---------------+
+--> DBKEY --------------------+
+--> ROWID --------------------+
+--> NO INDEX -----------------+
+--> INDEX -+> <index-name> --++
+------ , <-------+
subquery-list =
---+-> SUBQUERY (source) -------+---------->
+-------------<--------------+
execution-options =
-+-> ANY --------+------>
+-> NONE -------+
+-> FAST FIRST -+
+-> TOTAL TIME -+
9.3 – Arguments
9.3.1 – ACCESS_PATH
Syntax options:
ACCESS PATH ANY
ACCESS PATH SEQUENTIAL
ACCESS PATH DBKEY
ACCESS PATH ROWID
ACCESS PATH NO INDEX
See also ACCESS_PATH_INDEX. Specifies the access path to use to
retrieve data from the underlying database table. The following
table lists the valid access paths.
Path Meaning
ANY Indicates that the optimizer may choose the most
appropriate method.
SEQUENTIAL Indicates that sequential access should be used.
DBKEY Indicates the access by database key should be
used.
ROWID Indicates the access by database key should be
used.
NO INDEX Indicates that any access path not requiring
an index can be used. NOINDEX is accepted as a
synonym for NO INDEX.
There is no default access path. An access path must be specified
for each database table specified within a query outline
definition.
9.3.2 – ACCESS_PATH_INDEX
Specifies that data should be retrieved using the specified index
or list of indexes. If more that one index can be used, then
separate each index name with a comma.
Any index name specified should indicate an existing index
associated with the table with which the access method is
associated.
9.3.3 – AS query list
Provides the main definition of an outline.
This clause is only required when creating an outline using the
ID id-number clause.
9.3.4 – COMMENT_IS
Adds a comment about the outline. SQL displays the text when it
executes a SHOW OUTLINES statement in interactive SQL. Enclose
the comment in single quotation marks ( ') and separate multiple
lines in a comment with a slash mark (/).
9.3.5 – COMPLIANCE
Syntax options:
COMPLIANCE MANDATORY | COMPLIANCE OPTIONAL
Specifies the compliance level for this outline.
MANDATORY indicates that all outline directives such as table
order and index usage should be followed as specified. If the
optimizer is unable to follow any outline directive, an exception
is raised.
OPTIONAL indicates that all outline directives are optional and
that if they cannot be followed, no exception should be raised.
If OPTIONAL is specified, the strategy chosen by the optimizer
to carry out the underlying request may not match the strategy
specified within the outline.
Use MANDATORY when the strategy that the optimizer chooses must
be followed exactly as specified from version to version of
Oracle Rdb even if the optimizer finds a more efficient strategy
in a future version of Oracle Rdb.
The default is COMPLIANCE OPTIONAL.
9.3.6 – context
Specifies the context number for this table. Specify an unsigned
integer. This number is allocated to the table by the optimizer
during optimization. Context numbers are unique within queries.
9.3.7 – EXECUTION_OPTIONS
Specifies options that the optimizer should take into account
during optimization. The following table lists the valid options.
Option Meaning
ANY Indicates that the optimizer can choose any
optimization method
FAST FIRST Indicates that the optimizer can use FAST FIRST
optimization if and when appropriate
NONE Indicates that optional optimizations should not
be applied
TOTAL TIME Indicates that the optimizer can use TOTAL TIME
optimization if and when appropriate
The default is EXECUTION OPTIONS (ANY).
9.3.8 – FLOATING
Specifies that the following data source should be considered to
be floating and that the order of the data source relative to the
other data sources within the same level is not fixed.
9.3.9 – FROM sql query
Enables an outline to be created directly from an SQL statement.
If the AS clause is not specified, the sql-query is compiled and
the resulting outline is stored. If the AS clause is specified,
the sql-query provides an alternate means of specifying the ID.
If the USING clause is specified, the sql-query is optimized
using the designated outline as a starting point.
The only statement accepted as an sql-query in the FROM clause is
a SELECT statement. Do not end the sql-query with a semicolon.
9.3.10 – ID id number
Specifies the internal hash identification number of the request
to which this outline should be applied. Specify a 32-byte string
representing a 32-hexadecimal character identification code. The
internal hash identification code is generated by the optimizer
whenever query outlines are created by the Oracle Rdb optimizer
during optimization.
You can optionally specify the MODE clause. You are required to
specify the AS clause. You cannot specify the USING clause with
the ID id-number clause.
9.3.11 – JOIN_BY
Syntax options:
JOIN BY CROSS
JOIN BY MATCH
JOIN BY ANY METHOD
Specifies the method with which two data sources should be joined.
The following table lists the valid methods.
Method Meaning
CROSS Indicates that a cross strategy should be used
MATCH Indicates that a match strategy should be used
ANY METHOD Indicates that the optimizer can choose any method
to join the two data sources
NOTE
The match join strategy requires that an equivalent join
column exist between the inner and outer context of the
join order. If the query for which the outline is created
does not have an equivalent join column, then the optimizer
cannot use the match join strategy specified in the outline.
There is no default join method.
9.3.12 – MODE mode
Mode is a value assigned to an outline when it is generated by
the optimizer. The default mode is 0. Specify a signed integer.
If you create multiple outlines for a single query, the outlines
cannot have the same outline mode. When more than one outline
exists for a query, you can set the RDMS$BIND_OUTLINE_MODE
logical name to the value of the outline mode for the outline you
want the optimizer to use. For example, if you have a query that
runs during the day and at night and you created two outlines for
the query, you could keep the default outline mode of 0 for the
outline to be used during the day, and assign an outline mode of
-1 for the outline to be used at night. By setting the RDMS$BIND_
OUTLINE_MODE logical name to -1 at night, the appropriate outline
is run at the appropriate time.
Valid values for modes are -2,147,483,648 to 2,147,483,647.
Positive mode values are reserved for future use, so it is
recommended that you specify a value between 0 and -2,147,483,648
for the mode value.
9.3.13 – MODULE module name
Associates an outline with a declared local temporary table by
qualifying the table name with the name of the stored module. In
order to apply the outline to the declared local temporary table,
the keyword MODULE is required.
9.3.14 – ON_COLUMN
Syntax options:
ON COLUMN name
Generates an outline for the specified columns DEFAULT, COMPUTED
BY or AUTOMATIC expression. This is a partial outline which will
be used when the column is referenced. If a column has both an
AUTOMATIC UPDATE AS clause and a DEFAULT expression, then only
one outline is created for the AUTOMATIC clause.
9.3.15 – ON_CONSTRAINT
Syntax options:
ON CONSTRAINT name
Generates an outline definition for the specified constraint.
9.3.16 – ON_FUNCTION
Syntax options:
ON FUNCTION ID proc-id | ON FUNCTION NAME name
Generates an outline definition for the specified stored
function.
9.3.17 – ON_PROCEDURE
Syntax options:
ON PROCEDURE ID proc-id | ON PROCEDURE NAME name
Generates an outline definition for the specified stored
procedure.
9.3.18 – ON_TRIGGER
Syntax options:
ON TRIGGER name
Generates an outline definition for the specified trigger.
9.3.19 – ON_VIEW
Syntax options:
ON VIEW name
Generates an outline definition for the specified view.
9.3.20 – ORDERED
Specifies that all nonfloating data sources within the
parentheses should be retrieved in the order specified. Join
items in the group are placed adjacently.
9.3.21 – outline-name
The name of the new query outline. The name has a maximum length
of 31 characters.
9.3.22 – QUERY
Specifies that the data sources within the parentheses belong to
a separate query.
9.3.23 – SUBQUERY
Specifies that the data sources within the parentheses belong to
a separate subquery.
9.3.24 – table-name
Specifies the name of a database table.
9.3.25 – UNION_WITH
Specifies the union of two data sources.
Either a join or union method must be specified between all data
sources with the exception of QUERY source blocks.
NOTE
When a join method appears immediately before an ordered
or unordered group, the join method is associated with the
first join item named in the group.
The union strategy is only valid for queries that use the UNION
operator, and all queries that specify the UNION operator must
use the union strategy.
9.3.26 – UNORDERED
Specifies that all data sources within the parentheses should be
considered floating and that no order is implied. Join items in
the group are placed adjacently.
9.3.27 – USING query list
Specifies the outline to be used for compilation of the contents
of the FROM and ON clauses.
You cannot use this clause with the ID id-number clause.
9.4 – Examples
Example 1: Creating an outline named AVAILABLE_EMPLOYEES
SQL> CREATE OUTLINE available_employees
cont> ID '09ADFE9073AB383CAABC4567BDEF3832' MODE 0
cont> AS (
cont> QUERY (
cont> --
cont> -- Cross the employees table with departments table first.
cont> --
cont> employees 0 ACCESS PATH SEQUENTIAL JOIN BY MATCH TO
cont> departments 3 ACCESS PATH INDEX dept_index JOIN BY MATCH TO
cont> SUBQUERY (
cont> job_fitness 2 ACCESS PATH INDEX job_fit_emp, job_fit_dept
cont> JOIN BY CROSS TO
cont> SKILLS 4 ACCESS PATH ANY
cont> ) JOIN BY MATCH TO
cont> SUBQUERY (
cont> major_proj 1 ACCESS PATH ANY JOIN BY CROSS TO
cont> education 6 ACCESS PATH ANY
cont> ) JOIN BY CROSS TO
cont> research_projects 5 ACCESS PATH ANY UNION WITH
cont> --
cont> -- Always do the union with employees table last
cont> --
cont> employees 7 ACCESS PATH ANY
cont> )
cont> )
cont> COMPLIANCE OPTIONAL
cont> COMMENT IS 'Available employees';
Example 2: Creating an outline using the FROM clause
SQL> CREATE OUTLINE degrees_for_emps_over_65
cont> FROM
cont> (SELECT e.last_name, e.first_name, e.employee_id,
cont> d.degree, d.year_given
cont> FROM employees e, degrees d
cont> WHERE e.birthday < '31-Dec-1930'
cont> AND e.employee_id = d.employee_id
cont> ORDER BY e.last_name)
cont> USING
cont> (QUERY
cont> (SUBQUERY
cont> (degrees 1 ACCESS PATH SEQUENTIAL
cont> JOIN BY CROSS TO
cont> employees 0 ACCESS PATH ANY
cont> )
cont> )
cont> )
cont> COMPLIANCE OPTIONAL
cont> COMMENT IS 'Outline to find employees over age 65 with college degrees';
SQL> --
SQL> SHOW OUTLINE degrees_for_emps_over_65
DEGREES_FOR_EMPS_OVER_65
Comment: Outline to find employees over age 65 with college degrees
Source:
-- Rdb Generated Outline : 13-NOV-1995 15:28
create outline DEGREES_FOR_EMPS_OVER_65
id 'B6923A6572B28E734D6F9E8E01598CD8'
mode 0
as (
query (
subquery (
DEGREES 1 access path sequential
join by cross to
EMPLOYEES 0 access path index EMPLOYEES_HASH
)
)
)
compliance optional ;
Example 3: Creating an outline using the ON FUNCTION clause
SQL> CREATE OUTLINE out1
cont> ON FUNCTION NAME function1;
SQL> COMMIT;
SQL> SHOW OUTLINE out1
OUT1
Source:
-- Rdb Generated Outline : 2-FEB-1996 15:46
create outline OUT1
id '264A6DDADCB483AE5B2CDF629C9C8C0F'
mode 0
as (
query (
subquery (
EMPLOYEES 0 access path index EMPLOYEES_HASH
)
)
)
compliance optional ;
Example 4: Creating an outline on a procedure that accesses a
declared local temporary table (see the CREATE MODULE statement
for the stored procedure and temporary table definition)
SQL> CREATE OUTLINE outline1
cont> ON PROCEDURE NAME paycheck_ins_decl
cont> MODE 0
cont> AS (
cont> QUERY (
cont> module.paycheck_decl_tab MODULE paycheck_decl_mod
cont> 0
cont> ACCESS PATH SEQUENTIAL
cont> )
cont> )
cont> COMPLIANCE OPTIONAL;
SQL> SHOW OUTLINE outline1
OUTLINE1
Source:
create outline OUTLINE1
mode 0
as (
query (
PAYCHECK_DECL_TAB MODULE PAYCHECK_DECL_MOD 0
access path sequential
)
)
compliance optional ;
Example 5: New Output from Query Outlines
SQL> BEGIN
cont> DECLARE :x INTEGER;
cont> -- Assignment
cont> SET :x = (SELECT COUNT(*) FROM TOUT_1);
cont> -- Delete statement
cont> DELETE FROM TOUT_1;
cont> -- Update statement
cont> UPDATE TOUT_1
cont> SET a = (SELECT AVG(a) FROM TOUT_2)
cont> WHERE a IS NULL;
cont> -- Singleton Select
cont> SELECT a INTO :x
cont> FROM TOUT_1
cont> WHERE a = 1;
cont> -- Trace (nothing if TRACE is disabled)
cont> TRACE 'The first value: ', (SELECT a FROM TOUT_1 LIMIT TO 1 ROW);
cont> END;
The query outline generated by Oracle Rdb appears with comments
after the QUERY keyword in the outline.
-- Rdb Generated Outline : 29-MAY-1997 23:17
create outline QO_C11395E6020C6FFA_00000000
id 'C11395E6020C6FFA5A183A6CCE7C1F33'
mode 0
as (
query (
-- Set
subquery (
TOUT_1 0 access path sequential
)
)
query (
-- Delete
subquery (
TOUT_1 0 access path sequential
)
)
query (
-- Update
subquery (
subquery (
TOUT_2 1 access path sequential
)
join by cross to
subquery (
TOUT_1 0 access path sequential
)
)
)
query (
-- Select
subquery (
TOUT_1 0 access path sequential
)
)
query (
-- Trace
subquery (
TOUT_1 0 access path sequential
)
)
)
compliance optional ;
10 – PROCEDURE
Creates an external procedure as a schema object in an Oracle Rdb
database.
The CREATE PROCEDURE statement is documented under the CREATE
Routine. For complete information on creating an external
procedure definition, see the CREATE Routine Help topic.
11 – PROFILE
Creates a profile that extends a user definition within the
database with special attributes that control transactions
and resource usage. When a user attaches to the database using
ATTACH, CONNECT or SET SESSION AUTHORIZATION, they will either
load their assigned profile definition or inherit the default
profile (if defined).
11.1 – Environment
You can use the CREATE PROFILE statement:
o In interactive SQL
o Embedded in host language programs
o As part of a procedure in an SQL module or other compound
statement
o In dynamic SQL as a statement to be dynamically executed
11.2 – Format
CREATE -+--> PROFILE --> <profilename> -------------+--+-> profile-options -+->
+--> DEFAULT PROFILE -+--------------------++ +---------<----------+
+> ALIAS aliasname -+
profile-options =
--+-> COMMENT IS -+-> char-literal --+--------------------+>
| +------- / <-------+ |
+-> DEFAULT TRANSACTION --> txn-options ----------------+
+-> TRANSACTION MODES --> (txn-modes) ------------------+
+-> LIMIT -+-+-> ROWS limit-value --------------------+++
| | +-> TIME limit-value -----+-+-----------++||
| | +-> CPU TIME limit-value -+ +-> SECONDS + ||
| | +-> MINUTES + ||
| +-------------------- <---------------------+|
+-> NO -+> DEFAULT TRANSACTION --+----------------------+
+> TRANSACTION MODES -+-+
+> LIMIT-+-> CPU TIME -+
+-> ROWS ---+
+-> TIME ----+
limit-value =
--+-> positive-integer-literal -+->
+-> UNLIMITED ----------------+
+-> DEFAULT ------------------+
11.3 – Arguments
11.3.1 – ALIAS aliasname
When attached to multiple databases, the aliasname is required to
direct the CREATE command to the appropriate database.
11.3.2 – COMMENT_IS
This optional clause can be used to add several lines of comment
to the profile object. The comment is displayed by the SHOW
PROFILES statement. Enclose the comment in single quotation marks
(') and separate multiple lines in a comment with a slash mark
(/).
11.3.3 – DEFAULT_PROFILE
Creates the special profile RDB$DEFAULT_PROFILE. This profile
will be used by any user who is not assigned a profile using the
PROFILE clause of CREATE or ALTER PROFILE.
11.3.4 – DEFAULT_TRANSACTION
DEFAULT TRANSACTION provides a default transaction for the user.
By default, Oracle Rdb starts a READ WRITE transaction if none is
explicitly started. Use the DECLARE TRANSACTION or START DEFAULT
TRANSACTION statement to make use of this definition. You can
override this clause with a DECLARE or SET TRANSACTION statement.
NOTE
Oracle Rdb does not permit the RESERVING or EVALUATING
clauses to appear in the default transaction.
11.3.5 – LIMIT_CPU_TIME
Syntax options:
LIMIT CPU TIME | NO LIMIT CPU TIME
LIMIT CPU TIME sets the maximum CPU time that can be used by the
query compiler. The keyword DEFAULT indicates that no value is
defined by this profile and is equivalent to NO LIMIT CPU TIME.
If a numeric value or the keyword UNLIMITED is specified then
this value will be used even when the SET QUERY LIMIT CPU TIME
statement is present in the session, or when the logical name
RDMS$BIND_QG_CPU_TIMEOUT is defined.
NO LIMIT CPU TIME is the default. Units can be specified as
seconds or minutes.
11.3.6 – LIMIT_ROWS
Syntax options:
LIMIT ROWS | NO LIMIT ROWS
LIMIT ROWS sets the maximum number of rows that can be returned
by a query started by the user. The keyword DEFAULT indicates
that no value is defined by this profile and is equivalent to NO
LIMIT ROWS.
If a numeric value or the keyword UNLIMITED is specified then
this value will be used even when the SET QUERY LIMIT ROWS
statement is present in the session, or when the logical name
RDMS$BIND_QG_REC_LIMIT is defined.
NO LIMIT ROWS is the default.
11.3.7 – LIMIT_TIME
Syntax options:
LIMIT TIME | NO LIMIT TIME
LIMIT TIME sets the maximum elapsed time that can be used by the
query compiler. The keyword DEFAULT indicates that no value is
defined by this profile and is equivalent to NO LIMIT TIME.
If a numeric value or the keyword UNLIMITED is specified then
this value will be used even when the SET QUERY LIMIT TIME
statement is present in the session, or when the logical name
RDMS$BIND_QG_TIMEOUT is defined.
NO LIMIT TIME is the default. Units can be specified as seconds
or minutes.
11.3.8 – TRANSACTION_MODES
Syntax options:
TRANSACTION MODES | NO TRANSACTION MODES
TRANSACTION MODES provides the list of allowable transactions
for this user. Please see the SET TRANSACTION MODES clause of the
CREATE DATABASE and ALTER DATABASE statements for more details of
txn-modes.
The transaction modes specified may include modes disabled
for all database users by CREATE, IMPORT, or ALTER DATABASE
statements. However, only the subset allowed by both profile and
database settings will be used. For instance, if the database
specifies (READ ONLY, SHARED READ, PROTECTED READ) and the
profile specifies (READ ONLY, SHARED), the session will be
allowed the subset (READ ONLY, SHARED READ).
11.4 – Examples
Example 1
The following example specifies the allowed transaction modes for
any user assigned this profile.
SQL> CREATE PROFILE DECISION_SUPPORT
cont> COMMENT IS 'limit transactions used by report writers'
cont> TRANSACTION MODES (NO READ WRITE, READ ONLY);
Example 2
This example shows the use of the LIMIT clauses to set boundaries
for standard database users.
SQL> create profile STANDARD_USER
cont> limit rows 10000
cont> limit time 10 minutes
cont> limit cpu time 20 seconds;
SQL> show profile STANDARD_USER;
STANDARD_USER
Limit rows 10000
Limit time 10 minutes
Limit CPU time 20 seconds
SQL> alter profile STANDARD_USER
cont> limit time 60 minutes;
12 – ROLE
Creates a role to which privileges and other roles can be
granted. A role can be granted to a user or another role. For
example, you can create a role for members of a department.
When a user leaves the department, the departmental role can
be revoked from that user and thus exclude that user's access to
the departmental data.
12.1 – Environment
You can use the CREATE ROLE statement:
o In interactive SQL
o Embedded in host language programs
o As part of a procedure in an SQL module or other compound
statement
o In dynamic SQL as a statement to be dynamically executed
12.2 – Format
CREATE ROLE ---> <role-name> ----------------------+
+---------------------<----------------------------+
+-----+--------------------------------+-----------+
+--> IDENTIFIED EXTERNALLY ------+ |
+--> NOT IDENTIFIED -------------+ |
+--------------------<-----------------------------+
+-----+----------------------------------+----------->
+--> COMMENT IS --+-> 'string' --+-+
+------ / <----+
12.3 – Arguments
12.3.1 – COMMENT IS 'string'
Adds a comment about the role. SQL displays the text of the
comment when it executes a SHOW ROLES statement. Enclose the
comment in single quotation marks (') and separate multiple lines
in a comment with a slash mark (/).
12.3.2 – IDENTIFIED_EXTERNALLY
The IDENTIFIED EXERNALLY clause indicates that SQL should inherit
the roles defined by the facilities of the operating system,
such as rights identifiers. When a session is started, any role
that is defined externally is established as part of the current
user's profile.
12.3.3 – NOT_IDENTIFIED
Indicates that the role is used only with the database. The
database must have SECURITY CHECKING IS INTERNAL set before using
this clause.
12.3.4 – role-name
A user-supplied name that you assign to the role. The special
roles BATCH, DIALUP, INTERACTIVE, LOCAL, NETWORK, and REMOTE are
reserved names that cannot be specified as a role-name.
12.4 – Examples
Example 1: Creating a Role
SQL> ALTER DATABASE FILENAME 'mf_personnel.rdb'
cont> SECURITY CHECKING IS INTERNAL;
SQL> ATTACH 'FILENAME mf_personnel.rdb';
SQL> CREATE ROLE WRITER;
SQL> SHOW ROLES;
Roles in database with filename mf_personnel.rdb
WRITER
Example 2: Creating Roles and Granting Privileges to Those Roles
SQL> ALTER DATABASE FILENAME mf_personnel.rdb
cont> SECURITY CHECKING IS INTERNAL;
SQL> -- Create a role for employees in the payroll department
SQL> ATTACH 'FILENAME MF_PERSONNEL.RDB';
SQL> CREATE ROLE PAYROLL
cont> COMMENT IS 'This role allows access to various tables'
cont> / 'and procedures for use by the PAYROLL dept.';
SQL> -- Create another role for a subset of employees.
SQL> CREATE ROLE ANNUAL_LEAVE
cont> COMMENT IS 'This role is granted to PAYROLL personnel'
cont> / 'who adjust the annual leave data';
SQL> -- Grant EXECUTE privilege on module and ALL privilege on table
SQL> -- SALARY_HISTORY to all employees to whom the PAYROLL role has
SQL> -- been granted. Grant EXECUTE privilege on module LEAVE_ADJUSTMENT
SQL> -- only to those employees who have been granted both the PAYROLL
SQL> -- and ANNUAL_LEAVE roles.
SQL> GRANT EXECUTE ON MODULE PAYROLL_UTILITIES TO PAYROLL;
SQL> GRANT ALL ON TABLE SALARY_HISTORY TO PAYROLL;
SQL> GRANT EXECUTE ON MODULE LEAVE_ADJUSTMENT
cont> to PAYROLL, ANNUAL_LEAVE;
SQL> -- User STUART joins the personnel department. Grant him
SQL> -- the PAYROLL and ANNUAL_LEAVE roles so that he can
SQL> -- perform all functions in the payroll department.
SQL> CREATE USER STUART
cont> IDENTIFIED EXTERNALLY
SQL> GRANT PAYROLL, ANNUAL_LEAVE TO STUART;
SQL> -- User STUART is promoted to supervisor and thus
SQL> -- no longer needs access to the objects controlled by
SQL> -- the ANNUAL_LEAVE role. Revoke that role from user
SQL> -- STUART.
SQL> REVOKE ANNUAL_LEAVE FROM STUART;
Example 3: Creating roles explictly using CREATE ROLE and
implicitly using GRANT
This examples demonstrates creating roles that match an OpenVMS
rights identifiers. The CREATE ROLE statement is used first,
and then the GRANT statement. GRANT issues a warning message to
alert the database administrator of the side-effect of the GRANT
statement.
SQL> create database
cont> filename SAMPLE
cont> security checking is internal;
SQL> show roles;
Roles in database with filename sample
No Roles found
SQL> create role dba_mgr identified externally;
SQL> show roles;
Roles in database with filename sample
DBA_MGR
SQL> grant saldb_user to smith;
%RDB-W-META_WARN, metadata successfully updated with the reported warning
-RDMS-W-PRFCREATED, some users or roles were created
SQL> show roles;
Roles in database with filename sample
DBA_MGR
SALDB_USER
SQL>
13 – Routine
Creates an external routine definition as a schema object in an
Oracle Rdb database. External routine refers to both external
functions and external procedures. A routine definition stores
information in the database about a subprogram (a function or
procedure) written in a 3GL language. The routine definition and
the routine image are independent of each other, meaning one can
exist without the other. However, to invoke an external routine,
you need both the routine definition and routine image.
SQL can invoke an external function from anywhere you can specify
a value expression. External procedures are invoked using the
CALL Compound_Statement.
13.1 – Environment
You can use the CREATE FUNCTION and CREATE PROCEDURE statements:
o In interactive SQL
o Embedded in host language programs to be precompiled
o As part of a procedure in an SQL module
o In dynamic SQL as a statement to be dynamically executed
13.2 – Format
CREATE -+-> FUNCTION ---+-> <external-routine-name> ---------+
+-> PROCEDURE --+ |
+----------------------------<-----------------------------+
+-+--------------------------------+-----------------------+
+-> STORED NAME IS <identifier> -+ |
+----------------------------<-----------------------------+
+-> ( -+-----------------------+-> ) ----------------------+
++-> parameter-list --+-+ |
+-------- , <--------+ |
+----------------------------<-----------------------------+
+-+-------------------+--> --+------------------+-> ; --> -+
+-> returns-clause -+ +-> LANGUAGE SQL --+ |
|
+----------------------------<-----------------------------+
+----> external-body-clause ---------------------------------->
parameter-list =
-+----------+-+-------------------+-+-> data-type -----+----------+
+-> IN ----+ +> <parameter-name> + +-> <domain-name> -+ |
+-> OUT ---+ |
+-> INOUT -+ |
+-----------------------------------------------------------------+
+-+---------------------------+--+---------------------+----------+
+-> DEFAULT value-expr -----+ +-> mechanism-clause -+ |
+------------------------------<---------------------------------+
++---------------------------------+------------------------------->
+-> COMMENT IS -+-> 'string' ---+-+
+------ / <-----+
mechanism-clause =
----> BY --+-> DESCRIPTOR -+--->
+-> LENGTH -----+
+-> REFERENCE --+
+-> VALUE ------+
external-body-clause =
--> EXTERNAL --+------------------------------+-------------+
+-> NAME <external-body-name> -+ |
+----------------------------------- <----------------------+
++-----------------------------+-> LANGUAGE language-name --+
+-> external-location-clause -+ |
+----------------------------------<------------------------+
++-> PARAMETER STYLE GENERAL -+-----------------------------+
+-> GENERAL PARAMETER STYLE -+ |
+-----------------------------------<-----------------------+
++----------------------------+------------------------------>
+-> external-body-clause-2 --+
external-body-clause-2 =
---+--+-> COMMENT IS -+-> '<string> ' -+----+--+-->
| | +------ / <------+ | |
| +-> bind-site-clause -----------------+ |
| +-> bind-scope-clause ----------------+ |
| +-> notify-clause --------------------+ |
| +-> CALLED ON NULL INPUT -------------+ |
| +-> RETURNS NULL ON NULL INPUT -------+ |
| +-> USAGE IS -+-> LOCAL ---+----------+ |
| | +-> GLOBAL --+ | |
| +-+--------+--+-------------------+---+ |
| +-> NOT -+ +-> VARIANT --------+ |
| +-> DETERMINISTIC --+ |
+---------------------- <-------------------+
external-location-clause =
---+--> DEFAULT LOCATION ------------+-------------------------+
+--> LOCATION '<image-location>' -+ |
+-------------------------------<-----------------------------+
+-+----------------------------->--------------------------+-->
+--> WITH --+-> ALL -----+--> LOGICAL_NAME TRANSLATION --+
+-> SYSTEM --+
language-name =
--+-> ADA -----+-->
+-> C -------+
+-> COBOL ---+
+-> FORTRAN -+
+-> PASCAL --+
+-> GENERAL -+
bind-site-clause =
--> BIND ON --+--> CLIENT --+--> SITE --->
+--> SERVER --+
bind-scope-clause =
---> BIND SCOPE --+-> CONNECT ------+-->
+-> TRANSACTION --+
notify-clause =
-> NOTIFY notify-entry-name --> ON -+-+-> BIND ---------+-+->
| +-> CONNECT ------+ |
| +-> TRANSACTION --+ |
+--------- , <--------+
13.3 – Arguments
13.3.1 – bind-site-clause
Syntax options:
BIND ON CLIENT SITE | BIND ON SERVER SITE
Selects the execution model and environment for external routine
execution.
CLIENT site binding causes the external routine to be activated
and executed in the OpenVMS database client (application)
process. This is the default binding. This binding offers
the most efficient execution characteristics, allows sharing
resources such as I/O devices, and allows debugging of external
routines as if they were part of the client application. However,
this binding may suffer from address space limitations. Because
it shares virtual memory with the database buffers, this binding
is restricted to the client process system user environment, and
prohibits external routine execution in cases of an application
running with elevated privileges.
SERVER site binding causes the external routine to be activated
in a separate process from the database client and server. The
process is started on the same node at the database process.
This binding offers reasonable execution characteristics, a
larger address space, a true session user environment, and has
no restrictions regarding client process elevated privileges.
However, this binding does not permit sharing resources such
as I/O devices with the client (in particular, there is no
connection to the client interactive terminal), and debugging
of routines is generally not possible.
13.3.2 – bind-scope-clause
Syntax options:
BIND SCOPE CONNECT | BIND SCOPE TRANSACTION
Defines the scope during which an external routine is activated
and at what point the external routine is deactivated. The
default scope is CONNECT.
o CONNECT
An active routine is deactivated when you detach from the
database (or exit without detaching).
o TRANSACTION
An active routine is deactivated when a transaction is
terminated (COMMIT or ROLLBACK). In the event that a
transaction never occurs, the scope reverts to CONNECT.
13.3.3 – COMMENT_IS
A description about the nature of the parameter or external
routine. SQL displays the text of the comment when you execute
a SHOW FUNCTION or SHOW PROCEDURE statement. Enclose the comment
in single quotation marks (') and separate multiple lines in a
comment with a slash (/).
13.3.4 – DEFAULT value-expr
Specifies the default value of a parameter for a function or
procedure defined with mode IN. If you omit this parameter or if
the Call statement argument list or function invocation specifies
the DEFAULT keyword, then the value-expr specified with this
clause is used. The parameter uses NULL as the default if you do
not specify a value expression explicitly.
13.3.5 – DETERMINISTIC
Syntax options:
DETERMINISTIC | NOT DETERMINISTIC
The clause controls the evaluation of an external function in the
scope of a query:
o NOT DETERMINISTIC
Specifying the NOT DETERMINISTIC clause forces evaluation
of corresponding functions (in scope of a single query)
every time the function appears. If a function can return a
different result each time it is invoked, you should use the
DETERMINISTIC clause.
o DETERMINISTIC
Specifying the DETERMINISTIC clause can result in a single
evaluation of corresponding function expressions (in scope
of a single query), and the resulting value is used in all
occurrences of the corresponding function expression. When you
use the DETERMINISTIC clause, Oracle Rdb evaluates whether or
not to invoke the function each time it is used.
For example:
SELECT * FROM T1 WHERE F1() > 0 AND F1() < 20;
If you define the F1 function as DETERMINISTIC, the function
F1() may be evaluated just once depending on the optimizer. If
you define the F1 function as NOT DETERMINISTIC, the function
F1() is evaluated twice.
DETERMINISTIC is the default.
The DETERMINISTIC or NOT DETERMINISTIC clause is not allowed on
procedure definitions.
13.3.6 – external-body-clause
Identifies key characteristics of the routine: its name, where
the executable image of the routine is located, the language in
which the routine is coded, and so forth.
13.3.7 – external-body-name
The name of the external routine. If you do not specify a name,
SQL uses the name you specify in the external-routine-name
clause.
This name defines the routine entry address that is called for
each invocation of the routine body. The named routine must exist
in the external routine image selected by the location clause.
Unquoted names are converted to uppercase characters.
13.3.8 – external-location-clause
Syntax options:
DEFAULT LOCATION
LOCATION 'image-location'
A file specification referencing the image that contains the
routine body and optional notify entry points.
13.3.9 – external-routine-name
The name of the external routine. The name must be unique among
external and stored routines in the schema and can be qualified
with an alias or, in a multischema database, a schema name.
13.3.10 – FUNCTION
Creates an external function definition.
A function optionally accepts a list of IN parameters, always
returns a value, and is referenced by name as an element of a
value expression.
13.3.11 – GENERAL_PARAMETER_STYLE
This is synonymous with PARAMETER STYLE GENERAL and is
deprecated.
13.3.12 – language-name
The name of the host language in which the external routine
was coded. You can specify ADA, C, COBOL, FORTRAN, PASCAL, or
GENERAL. The GENERAL keyword allows you to call routines written
in any language.
13.3.13 – LANGUAGE_SQL
Names the language that calls the routine.
13.3.14 – mechanism-clause
Defines the passing mechanism. The following list describes the
passing mechanisms.
o BY DESCRIPTOR
Allows passing character data with any parameter access mode
to routines compiled by language compilers that implement the
OpenVMS calling standard.
o BY LENGTH
The LENGTH passing mechanism is the same as the DESCRIPTOR
passing mechanism.
o BY REFERENCE
Allows passing data with any parameter access mode as a
reference to the actual data.
This is the default passing mechanism for parameters. This
is also the default passing mechanism for a function value
returning character data.
o BY VALUE
Allows passing data with the IN parameter access mode to a
routine as a value and allows functions to return a value.
This is the default passing mechanism for a function value
returning noncharacter data.
13.3.15 – notify-clause
Specifies the name of a second external routine called (notified)
when certain external routine or database-related events occur.
This name defines the routine entry address that is called, for
each invocation of the notify routine. The named routine must
exist in the external routine image selected by the location
clause.
The events of interest to the notify routine are ON BIND, ON
CONNECT, and ON TRANSACTION. Multiple events can be specified.
The following describes the events and scope of each event:
BIND Routine activation to routine deactivation
CONNECT Database attach to database disconnect
TRANSACTION Start transaction to commit or roll back
transaction
13.3.16 – parameter-list
The optional parameters of the external routine. For each
parameter you can specify a parameter access mode (IN, OUT, and
INOUT), a parameter name, a data type, and a passing mechanism
(by DESCRIPTOR, LENGTH, REFERENCE, or VALUE).
The parameter access mode (IN, OUT, and INOUT) is optional and
specifies how the parameter is accessed (whether it is read,
written, or both). IN signifies read only, OUT signifies write
only, and INOUT signifies read and write. The parameter access
mode defaults to IN.
Only the IN parameter access mode may be specified with
parameters to an external function. Any of the parameter access
modes (IN, OUT, and INOUT) may be specified with parameters to an
external procedure.
The optional parameter name is prefixed with a colon (:).
The parameter name must be unique within the external routine
parameters.
The data type is required and describes the type of parameter
using either an SQL data type or a domain name.
You cannot declare a parameter as the LIST OF BYTE VARYING data
type.
13.3.17 – PARAMETER_STYLE_GENERAL
Passes arguments and returns values in a manner similar to the
OpenVMS convention for passing arguments and returning function
values.
13.3.18 – PROCEDURE
Creates an external procedure definition.
A procedure optionally accepts a list of IN, OUT, or INOUT
parameters, and is referenced by name in a CALL statement.
13.3.19 – RETURNS
Describes a function (returned) value. You can specify a data
type and a passing mechanism (BY DESCRIPTOR, LENGTH, REFERENCE,
or VALUE). The function value is, by definition, an OUT access
mode value.
The data type is required and describes the type of parameter
using either an SQL data type or a domain name.
You cannot declare a function value as the LIST OF BYTE VARYING
data type.
13.3.20 – STORED_NAME_IS
The name that Oracle Rdb uses to access the routine when defined
in a multischema database. The stored name allows you to access
multischema definitions using interfaces that do not recognize
multiple schemas in one database. You cannot specify a stored
name for a routine in a database that does not allow multiple
schemas. For more information about stored names, see Stored
Names.
13.3.21 – USAGE_IS
Specifies how the function or procedure can be called:
o USAGE IS GLOBAL indicates that the function or procedure can
be called outside the current module. This is the default.
o USAGE IS LOCAL specifies that the routine is restricted to
references within the module. This clause is provided for
compatibility with CREATE MODULE but is not allowed for CREATE
FUNCTION or CREATE PROCEDURE.
13.3.22 – VARIANT
Syntax options:
VARIANT | NOT VARIANT
These clauses are synonyms for the DETERMINISTIC and NOT
DETERMINISTIC clauses. The DETERMINISTIC clause indicates that
the same inputs to the function will generate the same output.
It is the same as the NOT VARIANT clause. The NOT DETERMINISTIC
clause indicates that the output of the function does not depend
on the inputs. It is the same as the VARIANT clause. This clause
is deprecated. Use DETERMINISTIC instead.
13.4 – Examples
Example 1: System provided integer absolute value routine
SQL> CREATE FUNCTION IABS (IN INTEGER BY REFERENCE)
cont> RETURNS INTEGER BY VALUE;
cont> EXTERNAL NAME MTH$JIABS
cont> LOCATION 'SYS$SHARE:DPML$SHR.EXE'
cont> LANGUAGE GENERAL
cont> PARAMETER STYLE GENERAL
cont> NOT DETERMINISTIC;
SQL> --
SQL> SELECT IABS(-33) FROM JOBS LIMIT TO 1 ROW;
33
1 row selected
Example 2: Using the NOT DETERMINISTIC clause, instead of the
DETERMINISTIC clause
The first CREATE FUNCTION statement in the following example
creates a function with the DETERMINISTIC clause. The
DETERMINISTIC clause indicates to Oracle Rdb that the function
would return the same result no matter how many times it is
called. Because the argument is a string literal (and could never
change), Oracle Rdb optimizes the entire function call so that it
is not called in subsequent select statements.
SQL> -- Create a function with a DETERMINISTIC clause.
SQL> CREATE function DO_COM (IN VARCHAR(255) BY DESCRIPTOR)
cont> RETURNS INTEGER;
cont> EXTERNAL NAME LIB$SPAWN
cont> LOCATION 'SYS$SHARE:LIBRTL.EXE'
cont> LANGUAGE GENERAL
cont> PARAMETER STYLE GENERAL
cont> DETERMINISTIC;
SQL> --
SQL> -- Use a SELECT statement to pass a string literal to the function.
SQL> --
SQL> -- Because Oracle Rdb optimizes functions with the DETERMINISTIC
SQL> -- clause, and the function is passed a string literal,
SQL> -- Oracle Rdb does not call the function from subsequent
SQL> -- statements.
SQL> --
SQL> SELECT DO_COM('WRITE SYS$OUTPUT "HELLO"'), employee_id FROM employees
cont> LIMIT TO 5 ROWS;
HELLO
DO_COM EMPLOYEE_ID
1 00164
1 00165
1 00166
1 00167
1 00168
5 rows selected
SQL> --
SQL> -- Use the NOT DETERMINISTIC clause to create the function:
SQL> --
SQL> CREATE function DO_COM (IN VARCHAR(255) BY DESCRIPTOR)
cont> RETURNS INTEGER;
cont> EXTERNAL NAME lib$SPAWN
cont> LOCATION 'SYS$SHARE:LIBRTL.EXE'
cont> LANGUAGE GENERAL
cont> PARAMETER STYLE GENERAL
cont> NOT DETERMINISTIC;
SQL> SELECT DO_COM('WRITE SYS$OUTPUT "HELLO"'), EMPLOYEE_ID FROM EMPLOYEES
cont> LIMIT TO 5 ROWS;
HELLO
HELLO
DO_COM EMPLOYEE_ID
1 00164
HELLO
1 00165
HELLO
1 00166
HELLO
1 00167
1 00168
5 rows selected
Example 3: External function and external procedure definition
The following example demonstrates:
o An external function and an external procedure
o Both CLIENT SITE and SERVER SITE binding
o BIND SCOPE
o A NOTIFY routine and events
o SQL callback using embedded SQL and SQL module language
o SQL$PRE options required when using callback
o Linker options required when using callback
In this example, a new column is added to the EMPLOYEES table in
the MF_PERSONNEL database. External routines are used to set this
column to spaces and to the SOUNDEX value corresponding to the
various employee names. Transaction control at the application
level (in this instance, in SQL) in conjunction with a notify
routine demonstrates how the actions of the external routines can
be affected by actions of the application.
The space-filling is performed by an external function, CLEAR_
SOUNDEX, (written in C) containing embedded SQL, which opens
another instance of the MF_PERSONNEL database and leaves it open
until deactivated.
The SOUNDEX name-setting is performed by an external procedure
(written in FORTRAN), assisted by a notify routine (written in
FORTRAN) which performs the database connection and transaction
control. All the database operations are performed by SQL module
language routines. The procedure also opens another instance
of the MF_PERSONNEL database, which is disconnected by the
notify routine when the routine is deactivated at the end of the
transaction. Display statements executed by the notify routine
serve to demonstrate the progress of the database operations.
SQL> ATTACH 'FILENAME MF_PERSONNEL';
SQL> --
SQL> -- Add the new column SOUNDEX_NAME to the EMPLOYEES table.
SQL> --
SQL> ALTER TABLE EMPLOYEES ADD SOUNDEX_NAME CHAR(4);
SQL> --
SQL> -- Define the CLEAR_SOUNDEX function.
SQL> --
SQL> CREATE FUNCTION CLEAR_SOUNDEX ()
cont> RETURNS INTEGER BY VALUE;
cont> EXTERNAL NAME CLEAR_SOUNDEX
cont> LOCATION 'CLEAR_SOUNDEX.EXE'
cont> LANGUAGE C PARAMETER STYLE GENERAL NOT DETERMINISTIC
cont> BIND ON SERVER SITE BIND SCOPE CONNECT;
SQL> --
SQL> -- Define the ADD_SOUNDEX_NAME procedure.
SQL> --
SQL> CREATE PROCEDURE ADD_SOUNDEX_NAME
cont> (INOUT INTEGER BY REFERENCE);
cont> EXTERNAL NAME ADD_SOUNDEX_NAME
cont> LOCATION 'ADD_SOUNDEX.EXE'
cont> LANGUAGE FORTRAN PARAMETER STYLE GENERAL
cont> BIND ON CLIENT SITE BIND SCOPE TRANSACTION
cont> NOTIFY ADD_SOUNDEX_NOTIFY ON BIND, TRANSACTION;
SQL> --
SQL> COMMIT;
SQL> DISCONNECT ALL;
SQL> EXIT;
Example 4: The CLEAR_SOUNDEX.SC program written in C
/* Set the soundex_name column to spaces, return any error as function value */
static int state = 0;
extern int clear_soundex () {
exec sql include sqlca ;
exec sql declare alias filename MF_PERSONNEL;
if (state == 0) {
exec sql attach 'filename MF_PERSONNEL';
state = 1;
}
exec sql set transaction read write;
if (SQLCA.SQLCODE < 0)
return SQLCA.SQLCODE;
exec sql update employees set soundex_name = ' ';
if (SQLCA.SQLCODE < 0)
return SQLCA.SQLCODE;
exec sql commit;
if (SQLCA.SQLCODE < 0)
return SQLCA.SQLCODE;
return 0;
}
Example 5: Compiling, creating a linker options file, and linking
the CLEAR_SOUNDEX program
$ SQL$PRE/CC/NOLIST/SQLOPT=ROLLBACK_ON_EXIT CLEAR_SOUNDEX.SC
$ CREATE CLEAR_SOUNDEX.OPT
SYMBOL_VECTOR = (CLEAR_SOUNDEX=PROCEDURE)
PSECT_ATTR=RDB$MESSAGE_VECTOR,NOSHR
PSECT_ATTR=RDB$DBHANDLE,NOSHR
PSECT_ATTR=RDB$TRANSACTION_HANDLE,NOSHR
$ LINK/SHARE=CLEAR_SOUNDEX.EXE -
CLEAR_SOUNDEX.OBJ, SQL$USER:/LIBRARY, -
CLEAR_SOUNDEX.OPT/OPT
SYMBOL_VECTOR = (CLEAR_SOUNDEX=PROCEDURE)
PSECT_ATTR=RDB$MESSAGE_VECTOR,NOSHR
PSECT_ATTR=RDB$DBHANDLE,NOSHR
PSECT_ATTR=RDB$TRANSACTION_HANDLE,NOSHR
Example 6: The ADD_SOUNDEX.FOR program written in FORTRAN
C Set the soundex values, returning any error in the IN/OUT parameter
SUBROUTINE ADD_SOUNDEX_NAME (ERROR)
CHARACTER ID*5,LAST*14,SX_NAME*4
INTEGER ERROR
ERROR = 0
ID = '00000'
10 CALL GET_NAME (ID, LAST, ERROR)
IF (ERROR .NE. 0) GO TO 80
CALL MAKE_SOUNDEX_NAME (LAST, SX_NAME)
CALL SET_SOUNDEX_NAME (ID, SX_NAME, ERROR)
IF (ERROR .EQ. 0) GO TO 10
80 IF (ERROR .EQ. 100) ERROR = 0
90 RETURN
END
C Perform database connection and transaction operations for notify events
SUBROUTINE ADD_SOUNDEX_NOTIFY (FUNC, RSV1, RSV2, RSV3)
INTEGER FUNC, RSV1, RSV2, RSV3, SQLCODE
SQLCODE = 0
GO TO (10,20,5,5,30,40,50),FUNC
5 TYPE *,'*** ADD_SOUNDEX_NOTIFY bad func ***'
GO TO 90
10 TYPE *,'*** ADD_SOUNDEX_NOTIFY activate ***'
CALL ATTACH_DB (SQLCODE)
IF (SQLCODE .NE. 0) GO TO 80
GO TO 90
20 TYPE *,'*** ADD_SOUNDEX_NOTIFY deactivate ***'
CALL DETACH_DB (SQLCODE)
IF (SQLCODE .NE. 0) GO TO 80
GO TO 90
30 TYPE *,'*** ADD_SOUNDEX_NOTIFY start tran ***'
CALL START_TRAN (SQLCODE)
IF (SQLCODE .NE. 0) GO TO 80
GO TO 90
40 TYPE *,'*** ADD_SOUNDEX_NOTIFY commit tran ***'
CALL COMMIT_TRAN (SQLCODE)
IF (SQLCODE .NE. 0) GO TO 80
GO TO 90
50 TYPE *,'*** ADD_SOUNDEX_NOTIFY rollback tran ***'
CALL ROLLBACK_TRAN (SQLCODE)
IF (SQLCODE .NE. 0) GO TO 80
GO TO 90
80 CALL SQL_SIGNAL ()
90 RETURN
END
C A 'substitute' SOUNDEX routine for demonstration purposes only
SUBROUTINE MAKE_SOUNDEX_NAME (NAME, SOUNDEX_NAME)
CHARACTER NAME*(*),SOUNDEX_NAME*4
SOUNDEX_NAME(1:1)=NAME(1:1)
IV = ICHAR(NAME(1:1))+22
SOUNDEX_NAME(2:2)=CHAR(MOD(IV,10)+48)
SOUNDEX_NAME(3:3)=CHAR(MOD(IV/10,10)+48)
SOUNDEX_NAME(4:4)=CHAR(IV/100+48)
RETURN
END
Example 7: The ADD_SOUNDEXM.SQLMOD module
-- Support for set soundex routine
MODULE ADD_SOUNDEX
LANGUAGE FORTRAN
PARAMETER COLONS
PROCEDURE ATTACH_DB (SQLCODE);
ATTACH 'FILENAME MF_PERSONNEL';
PROCEDURE DETACH_DB (SQLCODE);
DISCONNECT DEFAULT;
PROCEDURE START_TRAN (SQLCODE);
SET TRANSACTION READ WRITE;
PROCEDURE COMMIT_TRAN (SQLCODE);
COMMIT;
PROCEDURE ROLLBACK_TRAN (SQLCODE);
ROLLBACK;
PROCEDURE GET_NAME (:ID CHAR(5), :LASTNAME CHAR(14), SQLCODE);
SELECT EMPLOYEE_ID, LAST_NAME INTO :ID, :LASTNAME
FROM EMPLOYEES WHERE EMPLOYEE_ID > :ID LIMIT TO 1 ROW;
PROCEDURE SET_SOUNDEX_NAME (:ID CHAR(5), :SX_NAME CHAR(4), SQLCODE);
UPDATE EMPLOYEES SET SOUNDEX_NAME = :SX_NAME WHERE EMPLOYEE_ID = :ID;
Example 8: Compiling, creating the linker options file, and
linking the FORTRAN and SQL module language programs
$ FORTRAN/NOLIST ADD_SOUNDEX.FOR
$ SQL$MOD ADD_SOUNDEXM.SQLMOD
$ CREATE ADD_SOUNDEX.OPT
SYMBOL_VECTOR = (ADD_SOUNDEX_NAME=PROCEDURE)
SYMBOL_VECTOR = (ADD_SOUNDEX_NOTIFY=PROCEDURE)
PSECT_ATTR=RDB$MESSAGE_VECTOR,NOSHR
PSECT_ATTR=RDB$DBHANDLE,NOSHR
PSECT_ATTR=RDB$TRANSACTION_HANDLE,NOSHR
$ LINK/SHARE=ADD_SOUNDEX.EXE -
ADD_SOUNDEX.OBJ, ADD_SOUNDEXM.OBJ, SQL$USER:/LIBRARY, -
ADD_SOUNDEX.OPT/OPT
SYMBOL_VECTOR = ADD_SOUNDEX_NAME
SYMBOL_VECTOR = ADD_SOUNDEX_NOTIFY
PSECT_ATTR=RDB$MESSAGE_VECTOR,NOSHR
PSECT_ATTR=RDB$DBHANDLE,NOSHR
PSECT_ATTR=RDB$TRANSACTION_HANDLE,NOSHR
Example 9: Using the routines with interactive SQL
$ SQL
SQL> ATTACH 'FILENAME MF_PERSONNEL';
SQL> --
SQL> DECLARE :ERROR INTEGER;
SQL> --
SQL> SELECT EMPLOYEE_ID,SOUNDEX_NAME FROM EMPLOYEES
cont> LIMIT TO 3 ROWS;
EMPLOYEE_ID SOUNDEX_NAME
00165 NULL
00190 NULL
00187 NULL
3 rows selected
SQL> COMMIT;
SQL> --
SQL> BEGIN
cont> SET :ERROR = CLEAR_SOUNDEX ();
cont> END;
SQL> PRINT :ERROR;
ERROR
0
SQL> --
SQL> SELECT EMPLOYEE_ID,SOUNDEX_NAME FROM EMPLOYEES
cont> LIMIT TO 3 ROWS;
EMPLOYEE_ID SOUNDEX_NAME
00165
00190
00187
3 rows selected
SQL> COMMIT;
SQL> --
SQL> SET TRANSACTION READ ONLY;
SQl> BEGIN
cont> SET :ERROR = 0;
cont> CALL ADD_SOUNDEX_NAME (:ERROR);
cont> END;
*** ADD_SOUNDEX_NOTIFY activate ***
*** ADD_SOUNDEX_NOTIFY start tran ***
SQL> PRINT :ERROR;
ERROR
0
SQL> COMMIT;
*** ADD_SOUNDEX_NOTIFY commit tran ***
*** ADD_SOUNDEX_NOTIFY deactivate ***
SQL> --
SQL> SELECT EMPLOYEE_ID,SOUNDEX_NAME FROM EMPLOYEES
cont> LIMIT TO 3 ROWS;
EMPLOYEE_ID SOUNDEX_NAME
00165 S501
00190 O101
00187 L890
3 rows selected
SQL> COMMIT;
SQL> --
SQL> BEGIN
cont> SET :ERROR = CLEAR_SOUNDEX ();
cont> END;
SQL> PRINT :ERROR;
ERROR
0
SQL> --
SQL> SET TRANSACTION READ ONLY;
SQL> BEGIN
cont> SET :ERROR = 0;
cont> CALL ADD_SOUNDEX_NAME (:ERROR);
cont> END;
*** ADD_SOUNDEX_NOTIFY activate ***
*** ADD_SOUNDEX_NOTIFY start tran ***
SQL> PRINT :ERROR;
ERROR
0
SQL> ROLLBACK;
*** ADD_SOUNDEX_NOTIFY rollback tran ***
*** ADD_SOUNDEX_NOTIFY deactivate ***
SQL> --
SQL> SELECT EMPLOYEE_ID,SOUNDEX_NAME FROM EMPLOYEES
cont> LIMIT TO 3 ROWS;
EMPLOYEE_ID SOUNDEX_NAME
00165
00190
00187
3 rows selected
SQL> COMMIT;
14 – SCHEMA
Creates a new schema in the current default catalog of a
multischema database.
NOTE
Use of the CREATE SCHEMA statement to create a database is
a deprecated feature. If you specify physical attributes of
a database such as the root file parameters, you receive an
informational message, but SQL creates the database anyway.
SQL> CREATE SCHEMA FILENAME TEST SNAPSHOT IS DISABLED;
%SQL-I-DEPR_FEATURE, Deprecated Feature: SCHEMA (meaning DATABASE)
If you do not specify any physical attributes, you may
receive an error message noting that you must enable
multischema naming.
SQL> CREATE SCHEMA PARTS
%SQL-F-SCHCATMULTI, Schemas and catalogs may only be referenced with
multischema enabled
A schema is a group of definitions within a database. The CREATE
SCHEMA statement lets you specify in a single SQL statement all
data and privilege definitions for a new schema. You can also add
definitions to the schema later.
A database, in addition to schema definitions, includes database
system files and user data. If you need to specify any physical
database characteristics such as the database root file or
storage area parameters, use the CREATE DATABASE statement. See
the CREATE DATABASE statement for more information.
You can specify any number of optional schema elements to the
CREATE SCHEMA statement. Schema elements are any of the CREATE
statements (except CREATE STORAGE AREA, CREATE DOMAIN . . . FROM
path-name, and CREATE TABLE . . . FROM path-name) or a GRANT
statement.
These statements require statement terminators, except when they
are part of a CREATE SCHEMA or CREATE DATABASE statement. When
you use these statements within a CREATE SCHEMA statement, use a
statement terminator on the last schema element only. The first
statement terminator that SQL encounters ends the CREATE SCHEMA
statement. Later CREATE or GRANT statements are not within the
scope of the CREATE SCHEMA statement.
14.1 – Environment
You can use the CREATE SCHEMA statement:
o In interactive SQL
o Embedded in host language programs to be precompiled
o As part of a procedure in an SQL module
o In dynamic SQL as a statement to be dynamically executed
14.2 – Format
CREATE SCHEMA -+-> <schema-name> -------------------------+-+
+-> AUTHORIZATION <auth-id> ---------------+ |
+-> <schema-name> AUTHORIZATION <auth-id> -+ |
+--------------------------------------------+
+-+-------------------------+--------------->
+-+--> schema-element --+-+
+----------<----------+
schema-name =
--+---------------------------------------------+
+------> <catalog-name> --------------+->. ---+
+-> " -> <alias>.<catalog-name> ->" --+ |
| +-----------------------------------------+
| +--------------> <name-of-schema> ------+->
+-> " -> <alias>.<name-of-schema> ->" ------+
schema-element =
-+-> create-collating-sequence-statement -+->
+-> create-domain-statement -------------+
+-> create-index-statement --------------+
+-> create-sequence-statement -----------+
+-> create-storage-map-statement --------+
+-> create-table-statement --------------+
+-> create-trigger-statement ------------+
+-> create-view-statement ---------------+
+-> grant-statement ---------------------+
14.3 – Arguments
14.3.1 – AUTHORIZATION auth id
If you do not specify a schema name, the authorization identifier
specifies the default schema.
If you want to comply with the ANSI/ISO 1989 standard, specify
the AUTHORIZATION clause without the schema name. Specify both
the AUTHORIZATION clause and the schema name to comply with the
current ANSI/ISO SQL standard.
14.3.2 – create-collating-sequence-statement
See the CREATE COLLATING_SEQUENCE statement for details.
If you want to specify a collating sequence in a CREATE DOMAIN
statement embedded in a CREATE SCHEMA statement, you must first
specify a CREATE COLLATING SEQUENCE statement within the same
CREATE SCHEMA statement.
14.3.3 – create-domain-statement
See the CREATE DOMAIN statement for details.
You cannot use the FROM path-name clause when embedding a CREATE
DOMAIN statement in a CREATE SCHEMA statement. You can, however,
issue a separate CREATE DOMAIN statement following the CREATE
SCHEMA statement. You can also describe the domain directly
within the CREATE SCHEMA statement.
If you want to specify a collating sequence in your embedded
CREATE DOMAIN statement, you must first specify a CREATE
COLLATING SEQUENCE statement within the same CREATE SCHEMA
statement.
14.3.4 – create-function-statement
See the CREATE Routine statement for details.
14.3.5 – create-index-statement
See the CREATE INDEX statement for details.
14.3.6 – create-module-statement
See the CREATE MODULE statement for details.
14.3.7 – create-procedure-statement
See the CREATE Routine statement for details.
14.3.8 – create-sequence-statement
See the CREATE SEQUENCE statement for details.
14.3.9 – create-storage-map-statement
See the CREATE STORAGE_MAP statement for details.
14.3.10 – create-table-statement
See the CREATE TABLE statement for details.
You cannot use the FROM path-name clause when embedding a CREATE
TABLE statement in a CREATE SCHEMA statement. You can, however,
issue a separate CREATE TABLE statement following the CREATE
SCHEMA statement. You can also describe the table directly within
the CREATE SCHEMA statement.
The CREATE TABLE statements in a CREATE SCHEMA statement can
refer to domains not yet created, provided that CREATE DOMAIN
statements for the domains are in the same CREATE SCHEMA
statement.
14.3.11 – create-trigger-statement
See the CREATE TRIGGER statement for details.
14.3.12 – create-view-statement
See the CREATE VIEW statement for details.
14.3.13 – grant-statement
See the GRANT statement for details.
14.3.14 – schema-element
Some CREATE statements or a GRANT statement.
14.3.15 – schema-name
Specifies the name of the schema created by the CREATE SCHEMA
statement.
You can qualify the schema name with either a catalog name or the
catalog name qualified by the alias. You must enclose the alias
and catalog name in double quotation marks and separate them with
a period. You must issue the SET QUOTING RULES statement before
you specify the alias and catalog name pair, or SQL issues an
error message about the use of double quotation marks.
For information on qualifying schema names with aliases and
catalog names, see the User_Supplied_Names HELP topic.
14.4 – Example
Example 1: Creating a schema within a multischema database
The following interactive statements create a database that
contains a schema within a catalog. You issue the CREATE SCHEMA
statement alone or as part of a CREATE DATABASE statement.
SQL> SET DIALECT 'SQL99';
SQL> CREATE DATABASE ALIAS PERS_ALIAS FILENAME personnel MULTISCHEMA IS ON;
SQL> CREATE CATALOG "PERS_ALIAS.ADMIN";
SQL> CREATE SCHEMA "PERS_ALIAS.ADMIN".PAYROLL;
SQL> SHOW SCHEMAS;
Schemas in database PERS_ALIAS
"PERS_ALIAS.ADMIN".PAYROLL
"PERS_ALIAS.RDB$CATALOG".RDB$SCHEMA
15 – SEQUENCE
Creates a sequence. A sequence is a database object from
which multiple users can generate unique integers. You can use
sequences to automatically generate primary key values.
15.1 – Environment
You can use the CREATE SEQUENCE statement:
o In interactive SQL
o Embedded in host language programs
o As part of a procedure in an SQL module or other compound
statement
o In dynamic SQL as a statement to be dynamically executed
15.2 – Format
CREATE SEQUENCE <sequence-name> ------------------+
+--------------------<----------------------------+
+---+---------------->-------------------------+--+
+---> STORED NAME IS ----> <stored-name> --+ |
+--------------------<----------------------------+
+-+------------------>-------------------------+-->
+-+-+---> sequence-attributes --------+-+----+
| +---> START WITH <numeric-value> -+ |
+------------------<------------------+
sequence-attributes =
--+--> INCREMENT BY <numeric-value> ---------+->
+--> sequence-range -----------------------+
+--> CYCLE --------------------------------+
+--> NOCYCLE ------------------------------+
+--> CACHE <numeric-value> ----------------+
+--> NOCACHE ------------------------------+
+--> ORDER --------------------------------+
+--> NOORDER ------------------------------+
+--> RANDOMIZE ----------------------------+
+--> NORANDOMIZE --------------------------+
+--> RESTART WITH -------------------------+
+--> WAIT ---------------------------------+
+--> NOWAIT -------------------------------+
+--> DEFAULT WAIT -------------------------+
+--> COMMENT -+-------+--+-> '<string>' -+-+
+-> IS -+ +------ / <-----+
sequence-range =
-+-> MINVALUE -+-+--> <numeric-value> -+--+-->
+-> MAXVALUE -+ +--> TINYINT ----+ |
| +--> SMALLINT ---+ |
| +--> INTEGER ----+ |
| +--> BIGINT -----+ |
+-> NOMINVALUE --------------------------+
+-> NOMAXVALUE --------------------------+
15.3 – Arguments
15.3.1 – CACHE
Syntax options:
CACHE numeric-value | NOCACHE
The CACHE clause specifies how many values of the sequence Oracle
Rdb should preallocate and keep in memory for faster access. The
numeric value must be between 2 and 2147483647.
You cannot cache more values than will fit in a given cycle of
sequence numbers; thus, the maximum value allowed for the CACHE
clause must be less than the value resulting from the following
formula:
(MAXVALUE-MINVALUE)/ABS(INCREMENT)
The SET FLAGS option SEQ_CACHE can be used to override the
setting of CACHE at runtime. See the SET_FLAGS statement for
more details.
A cache for a given sequence is populated at the first request
for a number from that sequence, and whenever a value is
requested when the cache is empty. If a system failure occurs,
or when the cache is released any unfetched values will be
discarded. The maximum number of lost values is equal to the
current cache size. This may be the value specified by CACHE or
by the SET FLAGS SEQ_CACHE option.
The NOCACHE clause specifies that values will be allocated one
at a time. This will require more I/O to the Rdb root file than
using a CACHE value.
By default, Oracle Rdb caches 20 sequence values.
15.3.2 – COMMENT IS 'string '
Adds a comment about the sequence. SQL displays the text of the
comment when it executes a SHOW SEQUENCE statement. Enclose the
comment in single quotation marks (') and separate multiple lines
in a comment with a slash mark (/).
15.3.3 – CYCLE
Syntax options:
CYCLE | NOCYCLE
The CYCLE clause specifies that the sequence is to continue
generating values after reaching either the MINVALUE or MAXVALUE.
After an ascending sequence reaches the MAXVALUE, the sequence
starts again from its MINVALUE. After a descending sequence
reaches its MINVALUE, the sequence starts again at its MAXVALUE.
The NOCYCLE clause specifies that the sequence should not
continue generating values after reaching either its minimum
or maximum value. An error is generated if an attempt is made to
increment the sequence beyond its limits. The NOCYCLE clause is
the default.
15.3.4 – INCREMENT BY numeric-value
Specifies the size of the increment and the direction (ascending
or descending) of the sequence. This numeric value must be in the
range -2147483648 through 2147483647, excluding 0. The absolute
value must be less than the difference of MAXVALUE and MINVALUE.
A negative value specifies a descending sequence; a positive
value specifies an ascending sequence. By default, the numeric
value is 1.
15.3.5 – MAXVALUE
Syntax options:
MAXVALUE numeric-value | NOMAXVALUE
The MAXVALUE clause specifies the maximum signed quadword
(BIGINT) value that the sequence can generate. The numeric value
must be between -9223372036854775808 and 9223372036854775808. The
MAXVALUE must be equal to or greater than the value specified for
the START WITH clause and greater than the value specified with
the MINVALUE clause. The NOMAXVALUE clause specifies that the
maximum value for an ascending sequence is 9223372036854775808
(plus the cache size) and -1 for a descending sequence.
The NOMAXVALUE clause is the default.
15.3.6 – MAXVALUE integer
Syntax options:
MAXVALUE TINYINT
MAXVALUE SMALLINT
MAXVALUE INTEGER
MAXVALUE BIGINT
SQL allows the keyword TINYINT, SMALLINT, INTEGER and BIGINT
to follow MAXVALUE instead of a numeric value. This allows easy
range setting for sequences used with these data types. The value
supplied will be the largest positive value that can be assigned
to this data type.
15.3.7 – MINVALUE
Syntax options:
MINVALUE numeric-value | NOMINVALUE
The MINVALUE clause specifies the minimum signed quadword
(BIGINT) value that the sequence can generate. The numeric
value must be equal to or greater than -9223372036854775808. The
MINVALUE must be less than or equal to the value specified with
the START WITH clause and less than the value specified with the
MAXVALUE clause. The NOMINVALUE clause specifies that the minimum
value for an ascending sequence is 1, and -9223372036854775808
(plus the cache size) for a descending sequence.
The NOMINVALUE clause is the default.
15.3.8 – MINVALUE integer-value
Syntax options:
MINVALUE TINYINT
MINVALUE SMALLINT
MINVALUE INTEGER
MINVALUE BIGINT
SQL allows the keyword TINYINT, SMALLINT, INTEGER and BIGINT
to follow MINVALUE instead of a numeric value. This allows easy
range setting for sequences used with these data types. The value
supplied will be the smallest negative value that can be assigned
to this data type.
15.3.9 – ORDER
Syntax options:
ORDER | NOORDER
The ORDER clause specifies that sequence numbers are guaranteed
to be assigned in order for each requesting process, thus
maintaining a strict history of requests. The NOORDER clause
specifies that sequence numbers are not guaranteed to be
generated in order of request.
The NOORDER clause is the default.
15.3.10 – RANDOMIZE
Syntax options:
RANDOMIZE | NORANDOMIZE
The RANDOMIZE clause specifies that the sequence numbers are to
be returned with a random value in the most significant bytes
of the BIGINT value. This allows unique values to be generated
that have a random distribution. When you specify the NORANDOMIZE
clause, sequence numbers are close in value to others created at
the same time.
The advantage of the RANDOMIZE clause is that updates to columns
of a sorted index to which these values are written occur in
different locations in the index structure. This may improve
concurrent access for large indexes as leaf nodes in different
parts of the index can be updated independently. In contrast,
the sequence numbers generated when you specify the NORANDOMIZE
clause (which are likely to be close in numeric value to other
sequences) result in index updates that occur in the same or
nearby index nodes, which may lead to contention in one part of
the sorted index.
The full range of values in the BIGINT value returned for the
sequence are used; therefore, the NOMAXVALUE and NOMINVALUE
clauses must be specified (or defaulted to) for the sequence
definition. The most significant bits of the BIGINT value
are set to a randomly generated positive value. A generated
distinct value is returned in the least significant 32 bits so
that uniqueness is guaranteed. If you also specify the CYCLE
clause, then only the least significant 32 bits are cycled. When
a query is performed on the column RDB$NEXT_SEQUENCE_VALUE in
the RDB$SEQUENCES table, only the generated value of the least
significant bits is returned, because the most significant bits
are not assigned until the NEXTVAL pseudocolumn is referenced.
If you specify RANDOMIZE, you cannot also specify ORDER,
MAXVALUE, or MINVALUE. The NORANDOMIZE clause is the default.
15.3.11 – sequence-name
The name of the sequence that you want to create. Use a name that
is unique among all sequence, synonym, table, and view names in
the database, or in the schema if you are using a multischema
database. Use any valid SQL name.
15.3.12 – START WITH numeric-value
Specifies the initial numeric value to be used for the sequence.
This value must be in the range specified by (or defaulted to)
the other sequence attribute clauses. Valid values are in the
range -9223373036854775808 to 9223372036854775807.
If omitted, the START WITH value defaults to the value of
MINVALUE for ascending sequences and MAXVALUE for descending
sequences.
15.3.13 – STORED NAME IS stored-name
Specifies a name that Oracle Rdb uses to access a sequence
created in a multischema database. The stored name allows you to
access multischema definitions using interfaces, such as Oracle
RMU, that do not recognize multiple schemas in one database. You
cannot specify a stored name for a sequence in a database that
does not allow multiple schemas.
15.3.14 – WAIT
Syntax options:
WAIT | NOWAIT | DEFAULT WAIT
Specifies what wait state is used when a reference to NEXTVAL
is used. A reference to NEXTVAL for a sequence may require
synchronization with other users of the sequence. When you
specify DEFAULT WAIT, the wait state (WAIT or NOWAIT) of the
current transaction is used. This may mean that no waiting is
performed during a NOWAIT transaction.
If you specify WAIT (the default) for the sequence, then
regardless of the wait state set for the current transaction, all
synchronization waits for the next value. This is the recommended
setting if the application uses NOWAIT transactions. The current
WAIT timeout interval defined for the transaction or database is
used.
If you specify NOWAIT for the sequence, then regardless of the
current transaction setting, all synchronization does not wait
for the next value.
15.4 – Examples
Example 1: Creating a Sequence
SQL> -- This example creates a new sequence using the default
SQL> -- values for NOMINVALUE, NOMAXVALUE, INCREMENT BY 1, NOCYCLE,
SQL> -- and CACHE 20. The START WITH value is set to 147.
SQL> -- Allyn Stuart will be assigned an EMPLOYEE_ID value of 147.
SQL> -- Nick Jones will be assigned an EMPLOYEE_ID of 148.
SQL> --
SQL> CREATE SEQUENCE EMPID START WITH 00147;
SQL> -- Use NEXTVAL to fetch a sequence number for the primary key column.
SQL> INSERT INTO EMPLOYEES
cont> (EMPLOYEE_ID, LAST_NAME, FIRST_NAME)
cont> VALUES (EMPID.NEXTVAL, 'STUART', 'ALLYN')
cont> RETURNING EMPLOYEE_ID;
EMPLOYEE_ID
147
1 row inserted
SQL> -- Use CURRVAL to reuse the EMPLOYEE_ID value for the foreign key columns
SQL> -- in the associated tables.
SQL> INSERT INTO SALARY_HISTORY
cont> (EMPLOYEE_ID, SALARY_AMOUNT,SALARY_START, SALARY_END)
cont> VALUES (EMPID.CURRVAL, 35000, '6-FEB-1998', NULL)
cont> RETURNING EMPLOYEE_ID;
EMPLOYEE_ID
147
1 row inserted
SQL> INSERT INTO JOB_HISTORY
cont> (EMPLOYEE_ID, DEPARTMENT_CODE, JOB_START, JOB_END)
cont> VALUES (EMPID.CURRVAL, 'ENGR', '6-FEB-1998', NULL)
cont> RETURNING EMPLOYEE_ID;
EMPLOYEE_ID
147
1 row inserted
SQL> INSERT INTO EMPLOYEES
cont> (EMPLOYEE_ID, LAST_NAME, FIRST_NAME)
cont> VALUES (EMPID.NEXTVAL, 'JONES ', 'NICK ')
cont> RETURNING EMPLOYEE_ID;
EMPLOYEE_ID
148
1 row inserted
16 – STORAGE_AREA
NOTE
You cannot issue CREATE STORAGE AREA as an independent
statement. It is a clause allowed only as part of a CREATE
DATABASE or IMPORT statement.
You can also create a storage area using the ADD STORAGE
AREA clause of the ALTER DATABASE statement.
Creates additional storage areas in a multifile database. Storage
areas are data and snapshot files that are associated with
particular tables in a multifile database.
A CREATE STORAGE AREA clause specifies the names for the storage
area files and determines their physical characteristics.
Subsequent CREATE STORAGE MAP statements associate the storage
area with particular tables in the database.
16.1 – Environment
You can use the CREATE STORAGE AREA clause only within a CREATE
DATABASE or IMPORT statement.
16.2 – Format
CREATE STORAGE AREA -+-> <area-name> -+-+-------------------------++
+-> RDB$SYSTEM --+ +-> FILENAME <file-spec> -+|
+-------------------------------------------------------------+
++------------------------------+-+->
+-+-+-> storage-area-params-1 -+ |
| +-> storage-area-params-2 -+ |
+--------------- <-------------+
storage-area-params-1 =
--+-> ALLOCATION IS ---> <number-pages> --> PAGES -----+->
+-> CACHE USING <row-cache-name> --------------------+
+-> NO ROW CACHE ------------------------------------+
+-> extent-params -----------------------------------+
+-> INTERVAL IS --> <number-data-pages> -------------+
+-> LOCKING IS --+-> ROW --+--> LEVEL ---------------+
| +-> PAGE -+ |
+-> PAGE FORMAT IS +-> UNIFORM -+--------------------+
| +-> MIXED ---+ |
+-> PAGE SIZE IS ----> <page-blocks> --> BLOCKS -----+
extent-params =
--+-> EXTENT IS -+-> ENABLED -------------------++-->
| +-> DISABLED ------------------+|
| +-> <extent-pages> --> PAGES --+|
| +-> (extension-options) -------+|
+---------------------<------------------------+
extension-options =
---> MINIMUM OF <min-pages> PAGES, --+
+------------------------------------+
+--> MAXIMUM OF <max-pages> PAGES, --+
+------------------------------------+
+--> PERCENT GROWTH IS <growth> ------->
storage-area-params-2 =
--+-> CHECKSUM CALCULATION IS -----------+--+-> ENABLED --+-+->
+-> SNAPSHOT CHECKSUM CALCULATION IS --+ +-> DISABLED -+ |
+-> SNAPSHOT ALLOCATION IS --> <snp-pages> ----> PAGES ---+
+-> SNAPSHOT EXTENT IS -+-> <extent-pages> ----> PAGES --++
| +-> (extension-options) ---------+|
+-> SNAPSHOT FILENAME --> <file-spec> --------------------+
+-> THRESHOLDS ARE ( <val1> +-----------------------+> ) -+
| +> ,<val2> -+----------++ |
| +> ,<val3> + |
+------------------------------<--------------------------+
16.3 – Arguments
16.3.1 – ALLOCATION_PAGES
Syntax option:
ALLOCATION IS number-pages PAGES
The number of database pages initially allocated to the storage
area. Rdb will automatically extend this allocation to account
for internal structure pages, such as SPAM (spage management)
pages. For example, an allocation of 25 will be increased to 27
as shown in this example:
SQL> alter database filename MF_PERSONNEL
cont> add storage area DOC_EXAMPLE
cont> page format is uniform
cont> allocation 25;
SQL> attach 'filename MF_PERSONNEL';
SQL> show storage area DOC_EXAMPLE
DOC_EXAMPLE
Access is: Read write
Page Format: Uniform
Page Size: 2 blocks
Area File: USER_DISK:[DOC.DATABASES]DOC_EXAMPLE.RDA;1
Area Allocation: 27 pages
Extent: Enabled
Area Extent Minimum: 99 pages
Area Extent Maximum: 9999 pages
Area Extent Percent: 20 percent
Snapshot File: USER_DISK:[DOC.DATABASES]DOC_EXAMPLE.SNP;1
Snapshot Allocation: 100 pages
Snapshot Extent Minimum: 99 pages
Snapshot Extent Maximum: 9999 pages
Snapshot Extent Percent: 20 percent
Locking is Row Level
No Cache Associated with Storage Area
No database objects use Storage Area DOC_EXAMPLE
16.3.2 – CACHE USING row cache name
Assigns the named row cache to the specified storage area. All
rows stored in this area, whether they consist of table data,
segmented string data, or special rows such as index nodes, are
cached if those rows fit in the cache.
If the row cache does not exist, you must create the row cache
before terminating the CREATE DATABASE statement. For example:
SQL> CREATE DATABASE FILENAME test_db
cont> ROW CACHE IS ENABLED
cont> CREATE STORAGE AREA area1
cont> CACHE USING test1
cont> CREATE CACHE test1
cont> CACHE SIZE IS 100 ROWS
cont> ROW LENGTH IS 200 BYTES;
Only one row cache is allowed for each storage area.
NO ROW CACHE is the default for a storage area.
16.3.3 – CHECKSUM_CALCULATION
Syntax options:
CHECKSUM CALCULATION | SNAPSHOT CHECKSUM CALCULATION
This option allows you to enable or disable calculations of page
checksums when pages are read from or written to the storage or
snapshot area files.
The default is ENABLED.
NOTE
Oracle Corporation recommends that you leave checksum
calculations enabled; which is the default.
With current technology, it is possible that errors may occur
that the checksum calculation can detect but that may not
be detected by either the hardware, firmware, or software.
Unexpected application results and database corruption may occur
if corrupt pages exist in memory or on disk but are not detected.
Oracle Corporation recommends performing checksum calculations,
except in the following specific circumstances:
o Your application is stable and has run without errors on the
current hardware and software configuration for an extended
period of time.
o You have reached maximum CPU utilization in your current
configuration. Actual CPU utilization by the checksum
calculation depends primarily on the size of the database
pages in your database. The larger the database page, the
more noticeable the CPU usage by the checksum calculation may
become.
NOTE
Oracle Corporation recommends that you carefully evaluate
the trade-off between reducing CPU usage by the checksum
calculation and the potential for loss of database integrity
if checksum calculations are disabled.
Oracle Rdb allows you to disable and, subsequently, re-enable
checksum calculation without error. However, once checksum
calculations have been disabled, corrupt pages may not be
detected even if checksum calculations are subsequently re-
enabled.
16.3.4 – EXTENT
Syntax options:
EXTENT ENABLED | EXTENT DISABLED
Enables or disables extents. Extents are ENABLED by default.
You may encounter performance problems when creating hashed
indexes in storage areas with the mixed page format if the
storage area was created specifying the incorrect size for
the area and if extents are enabled. By disabling extents,
this problem can be diagnosed early and corrected to improve
performance.
16.3.5 – EXTENT_IS
Syntax options:
EXTENT IS extent-pages PAGES | EXTENT IS (extension-options)
Specifies the number of pages of each storage area file extent.
See also the description under the SNAPSHOT EXTENT argument.
16.3.6 – FILENAME file spec
Provides an explicit file specification for storage area files.
The CREATE STORAGE AREA clause creates two files: a storage area
file with a file extension of .rda, and a snapshot file with a
file extension of .snp. If you omit the FILENAME argument, the
file specification takes the following defaults:
o Device: the current device for the process
o Directory: the current directory for the process
o File name: the name specified for the storage area
Neither the file specification for the storage area nor the
snapshot file may contain a node specification.
The file specification is used for both the storage area and
snapshot files that comprise the storage area (unless you use the
SNAPSHOT FILENAME argument to specify a different file for the
snapshot file). Because the CREATE STORAGE AREA clause can create
two files with different file extensions, do not specify a file
extension with the file specification.
You may use a logical name for all or part of a file
specification.
One benefit of a multifile database is that its files can reside
on more than one disk. If you want storage area files to reside
on another disk, you must specify the FILENAME argument with a
full file specification.
However, you may choose to create a multifile database even
if your main purpose in creating the storage area is not to
distribute storage area files across more than one disk. For
instance, a multifile database enables you to:
o Take advantage of hashed indexes. Hashed indexes require a
storage area with mixed page format and cannot be stored in
the RDB$SYSTEM storage area.
o Set attributes such as page size to better correspond with
tables that will be stored in the storage area.
16.3.7 – INTERVAL
Syntax options:
INTERVAL IS number-data-pages
Specifies the number of data pages between SPAM pages in the
storage area file, and thus the maximum number of data pages each
SPAM page manages. The default, and also the minimum interval,
is 216 data pages. The first page of each storage area is a SPAM
page. The interval you specify determines where subsequent SPAM
pages are to be inserted if there are enough data pages in the
storage file to require more SPAM pages.
You cannot specify the INTERVAL storage area parameter unless you
also explicitly specify PAGE FORMAT IS MIXED.
Oracle Rdb calculates the maximum INTERVAL size based on the
number of blocks per page, and returns an error message if you
exceed this value. For example, when the page size is 2 blocks,
the maximum INTERVAL is 4008 pages. If you try to create a
storage area with the INTERVAL set to 4009, Oracle Rdb returns
the following error message:
%RDB-E-BAD_DPB_CONTENT, invalid database parameters in the database parameter
block (DPB)
-RDMS-F-SPIMAX, spam interval of 4009 is more than the Rdb maximum of 4008
-RDMS-F-AREA_NAME, area NEW
For more information about setting space area management
parameters, see the Oracle Rdb Guide to Database Maintenance.
16.3.8 – LOCKING level
Syntax options:
LOCKING IS ROW LEVEL | LOCKING IS PAGE LEVEL
Specifies if locking is at the page or row level for the storage
area. This clause provides an alternative to requesting locks on
records. Specifying a lock level when you create a storage area
overrides the database default lock level. The default is ROW
LEVEL.
When many records are accessed in the same area and on the same
page, the LOCKING IS PAGE LEVEL clause reduces the number of lock
operations performed to process a transaction; however, this is
at the expense of reduced concurrency because these pages' locks
are held until COMMIT/ROLLBACK. Transactions that benefit most
with page-level locking are of short duration and also access
several database records on the same page. However, to guarantee
consistency of the data in the absence of row locking these page
level locks must be held until the transaction ends with COMMIT
or ROLLBACK.
Use the LOCKING IS ROW LEVEL if transactions are long in duration
and lock many rows.
The LOCKING IS PAGE LEVEL clause causes fewer blocking ASTs
and provides better response time and utilization of system
resources. However, there is a higher contention for pages and
increased potential for deadlocks and long transactions may use
excessive locks.
Page-level locking is never applied to RDB$SYSTEM or the DEFAULT
storage-area, either implicitly or explicitly, because the
locking protocol can stall metadata users.
You cannot specify page-level locking on single-file databases.
16.3.9 – MAXIMUM_PAGES
Syntax options:
MAXIMUM OF max-pages PAGES
Specifies the maximum number of pages of each extent. The default
is 9,999 pages.
16.3.10 – MINIMUM_PAGES
Syntax options:
MINIMUM OF min-pages PAGES
Specifies the minimum number of pages of each extent. The default
is 99 pages.
16.3.11 – NO_ROW_CACHE
Specifies that a row cache is not assigned to the specified
storage area in the database. You cannot specify the NO ROW CACHE
clause if you specify the CACHE USING clause.
Alter the storage area and name a row cache with the CACHE USING
clause to assign a row cache to the storage area or to override
the database default. Only one row cache is allowed for each
storage area.
16.3.12 – PAGE_FORMAT
Syntax options:
PAGE FORMAT IS UNIFORM | PAGE FORMAT IS MIXED
Specifies the on-disk structure for the storage area.
o The default is PAGE FORMAT IS UNIFORM. A storage area with
uniform page format is a file that is divided into groups of n
pages, called clumps, where n equals the buffer size divided
by the page size. Both buffer size and page size are user
specified values. By default, the buffer size is 6 blocks,
and the page size is 1024 bytes or 2 blocks long, resulting
in clumps of three pages. The PAGE FORMAT IS UNIFORM argument
creates a storage area file that is divided into clumps. A set
of clumps forms a logical area that can contain rows from a
single table or index only.
Uniform page format storage areas generally give the best
performance if the tables in the storage area are likely to be
subject to a wide range of queries.
o The PAGE FORMAT IS MIXED argument creates a storage area with
a format that allows rows from more than one table to reside
on or near a particular page of the storage area file. This
is useful for storing related rows from different tables on
the same page of the data file. For storage areas subject to
repeated queries that retrieve those related rows, a mixed
page format can greatly reduce input/output overhead if the
mix of rows on the page is carefully controlled. However,
mixed page format storage areas degrade performance if the mix
of rows on the page is not suited for the queries made against
the storage area.
For more information on the relative advantages and disadvantages
of uniform and mixed storage areas, see the Oracle Rdb Guide to
Database Maintenance.
16.3.13 – PAGE SIZE blocks
Syntax options:
PAGE SIZE IS page-blocks BLOCKS
The size in blocks of each data page in the storage area. Page
size is allocated in 512-byte blocks. The default is 2 blocks
(1024 bytes). If your largest row is larger than approximately
950 bytes, allocate more blocks per page to prevent fragmented
rows. If you specify a page size larger than the buffer size, an
error message is returned.
16.3.14 – PERCENT_GROWTH
Syntax options:
PERCENT GROWTH IS growth
Specifies the percent growth of each extent. The default is 20
percent growth.
16.3.15 – SNAPSHOT_ALLOCATION
Syntax options:
SNAPSHOT ALLOCATION IS snp-pages PAGES
Specifies the number of pages allocated for the snapshot file.
The default is 100 pages.
16.3.16 – SNAPSHOT_EXTENT
Syntax options:
SNAPSHOT EXTENT IS extent-pages | SNAPSHOT EXTENT IS (extension-
options)
Specifies the number of pages of each snapshot or storage area
file extent. The default extent for storage area files is 100
pages.
Specify a number of pages for simple control over the extension.
For greater control, and particularly for multivolume databases,
use the MIN, MAX, and PERCENT GROWTH extension options instead.
If you use the MIN, MAX, and PERCENT GROWTH parameters, you must
enclose them in parentheses.
16.3.17 – SNAPSHOT_FILENAME
Syntax options:
SNAPSHOT FILENAME file-spec
Provides a separate file specification for the snapshot file. The
SNAPSHOT FILENAME argument can only be specified with multifile
databases.
This argument lets you specify a different file name, device,
or directory for the snapshot file created by the CREATE STORAGE
AREA clause. Do not specify a file extension other than .snp to
the file specification. Oracle Rdb assigns the extension .snp
to the file specification, even if you specify an alternate
extension.
If you omit the SNAPSHOT FILENAME argument, the snapshot file
gets the same device, directory, and file name as the storage
area file.
16.3.18 – STORAGE_AREA
Specifies the name of the storage area you want to create. The
name cannot be the same as any other storage area definition in
the database.
16.3.19 – STORAGE_AREA_RDB$SYSTEM
Specifies that you want the CREATE STORAGE AREA clause to
override the default characteristics for the main storage area,
RDB$SYSTEM, in a new database.
The RDB$SYSTEM storage area contains database system tables and
indices. If an alternate DEFAULT STORAGE AREA is not assigned
then this area may also contain unmapped user tables and indices.
16.3.20 – THRESHOLDS values
Syntax options:
THRESHOLDS ARE ( val1 [,val2 [,val3] ] )
Specifies one, two, or three threshold values for mixed format
pages. The threshold values represent a fullness percentage on a
data page and establish three possible ranges of guaranteed free
space on the data pages. When a data page reaches the percentage
defined by a given threshold value, the space area management
(SPAM) entry for the data page is updated to reflect the new
fullness percentage and its remaining free space.
The default threshold values for mixed areas, if not specified,
are (70,85,95), which indicates that the nominal record size
should be used for SPAM threshold calculations. Oracle Rdb never
stores a record on a page at the third threshold. The value you
set for the highest threshold can be used to reserve space on the
page for future record growth.
When only val1 is specified, this is equivalent to (val1, 100,
100). When val1 and val2 are specified, this is equivalent to
(val1, val2, 100). The trailing, unspecified thresholds default
to 100 percent. For example, THRESHOLDS ARE (40) would appear as
(40, 100, 100).
You cannot specify the THRESHOLDS storage area parameter unless
you also explicitly specify PAGE FORMAT IS MIXED.
For more information about setting space area management
parameters, see the Oracle Rdb Guide to Database Maintenance.
16.4 – Examples
Example 1: Defining a multifile database
This example shows the definition of a database and storage areas
for a multifile database.
SQL> -- Note that there is no semicolon before
SQL> -- the first CREATE STORAGE AREA clause.
SQL> CREATE DATABASE ALIAS MULTIFILE_EXAMPLE
cont> FILENAME 'DB_DATA01:[DB.DATA]MULTIFILE_EXAMPLE'
cont> CREATE STORAGE AREA EMPID_LOW
cont> FILENAME 'DB_DATA02:[DB.DATA]EMPID_LOW'
cont> ALLOCATION IS 10 PAGES
cont> -- Notice that the snapshot file resides on a
cont> -- different disk than the storage area file. This
cont> -- strategy reduces disk input/output bottlenecks:
cont> SNAPSHOT FILENAME 'DB_SNAP03:[DB.SNAP]EMPID_LOW'
cont> SNAPSHOT ALLOCATION IS 10 PAGES
cont> --
cont> CREATE STORAGE AREA EMPID_MID
cont> FILENAME 'DB_DATA04:EMPID_MID'
cont> ALLOCATION IS 10 PAGES
cont> SNAPSHOT FILENAME 'DB_SNAP05:[DB.SNAP]EMPID_MID'
cont> SNAPSHOT ALLOCATION IS 10 PAGES
cont> --
cont> CREATE STORAGE AREA EMPID_OVER
cont> FILENAME 'DB_DATA06:[DB.DATA]EMPID_OVER'
cont> ALLOCATION IS 10 PAGES
cont> SNAPSHOT FILENAME 'DB_SNAP07:[DB.SNAP]EMPID_OVER'
cont> SNAPSHOT ALLOCATION IS 10 PAGES
cont> --
cont> CREATE STORAGE AREA HISTORIES
cont> FILENAME 'DB_DATA02:[DB.DATA]HISTORIES'
cont> ALLOCATION IS 10 PAGES
cont> SNAPSHOT FILENAME 'DB_SNAP03:[DB.SNAP]HISTORIES'
cont> SNAPSHOT ALLOCATION IS 10 PAGES
cont> --
cont> CREATE STORAGE AREA CODES
cont> FILENAME 'DB_DATA04:[DB.DATA]CODES'
cont> ALLOCATION IS 10 PAGES
cont> SNAPSHOT FILENAME 'DB_SNAP05:[DB.SNAP]CODES'
cont> SNAPSHOT ALLOCATION IS 10 PAGES
cont> --
cont> CREATE STORAGE AREA EMP_INFO
cont> FILENAME 'DB_DATA08:[DB.DATA]EMP_INFO'
cont> ALLOCATION IS 10 PAGES
cont> SNAPSHOT FILENAME 'DB_SNAP09:[DB.SNAP]EMP_INFO'
cont> SNAPSHOT ALLOCATION IS 10 PAGES
cont> --
cont> -- End the CREATE DATABASE statement:
cont> ;
Example 2:
This example shows how to set page-level and row-level locking on
storage areas from both the database level and from the storage
area level.
SQL> CREATE DATABASE FILENAME sample
cont> LOCKING IS PAGE LEVEL
cont> --
cont> -- All storage areas will default to page-level locking unless
cont> -- explicitly set to row-level locking.
cont> --
cont> CREATE STORAGE AREA RDB$SYSTEM
cont> FILENAME sample_system
cont> --
cont> -- You cannot specify page-level locking on RDB$SYSTEM. RDB$SYSTEM
cont> -- always defaults to row-level locking.
cont> --
cont> CREATE STORAGE AREA HASH_AREA
cont> FILENAME sample_hash
cont> PAGE FORMAT IS MIXED
cont> --
cont> -- HASH_AREA defaultS to page-level locking.
cont> --
cont> CREATE STORAGE AREA DATA_AREA
cont> FILENAME sample_data
cont> LOCKING IS ROW LEVEL
cont> --
cont> -- DATA_AREA is explicitly set to row-level locking.
cont> --
cont> ;
SQL> SHOW STORAGE AREAS (ATTRIBUTES) *
Storage Areas in database with filename sample
RDB$SYSTEM
List storage area.
Access is: Read write
Page Format: Uniform
Page Size: 2 blocks
.
.
.
Extent : Enabled
Locking is Row Level
HASH_AREA
Access is: Read write
Page Format: Mixed
Page Size: 2 blocks
.
.
.
Extent : Enabled
Locking is Page Level
DATA_AREA
Access is: Read write
Page Format: Uniform
Page Size: 2 blocks
.
.
.
Extent : Enabled
Locking is Row Level
See the SHOW statement for information on the SHOW STORAGE AREAS
statement.
Example 3: Creating and assigning a row cache to a storage area
SQL> create database
cont> filename SAMPLE_DB
cont> reserve 2 cache slots
cont> row cache is enabled
cont> default storage area is AREA1
cont> create cache CACHE1
cont> cache size is 1000 rows
cont> row length is 1000 bytes
cont> create storage area AREA1
cont> cache using CACHE1
cont> ;
SQL> show cache CACHE1
CACHE1
Cache Size: 1000 rows
Row Length: 1000 bytes
Row Replacement: Enabled
Shared Memory: Process
Large Memory: Disabled
Window Count: 100
Working Set Count: 10
Reserved Rows: 20
Allocation: 100 blocks
Extent: 100 blocks
SQL> show storage area AREA1
AREA1
Access is: Read write
Page Format: Uniform
Page Size: 2 blocks
Area File: USER_DISK:[DOC.DATABASES]AREA1.RDA;1
Area Allocation: 702 pages
Extent: Enabled
Area Extent Minimum: 99 pages
Area Extent Maximum: 9999 pages
Area Extent Percent: 20 percent
Snapshot File: USER_DISK:[DOC.DATABASES]AREA1.SNP;1
Snapshot Allocation: 100 pages
Snapshot Extent Minimum: 99 pages
Snapshot Extent Maximum: 9999 pages
Snapshot Extent Percent: 20 percent
Locking is Row Level
Using Cache CACHE1
Database objects using Storage Area AREA1:
Usage Object Name Map / Partition
---------------- ------------------------------- -------------------------------
Default Area
17 – STORAGE_MAP
Associates a table with one or more storage areas in a multifile
database. The CREATE STORAGE MAP statement specifies a storage
map that controls which lists or rows of a table are stored in
which storage areas.
In addition to creating storage maps, the CREATE STORAGE MAP
statement has options that control:
o Which index the database system uses when inserting rows in
the table
o Whether or not the rows of the table are stored in a
compressed format
o Whether or not partitioning keys can be modified.
o Whether the table is partitioned vertically, horizontally, or
both.
o Whether logging is enabled or disabled for the duration of
this operation
17.1 – Environment
You can use the CREATE STORAGE MAP statement:
o In interactive SQL
o Embedded in host language programs to be precompiled
o As part of a procedure in an SQL module
o In dynamic SQL as a statement to be dynamically executed
17.2 – Format
CREATE STORAGE MAP <map-name> --+
+------------------------------+
++-----------------------------------+-+
+-> STORED NAME IS <stored-name> ---+ |
+--------------------------------------+
+> FOR <table-name> ++-------------------------------------++-+
| |++> ENABLE -+> COMPRESSION -----------+| |
| ||+> DISABLE + || |
| |+-> PLACEMENT VIA INDEX <index-name> -+| |
| |+-> partition-updatable-clause -------+| |
| |+-> threshold-clause -----------------+| |
| |+-> LOGGING ---------------------------+ |
| |+-> NOLOGGING -------------------------+ |
| |+-> COMMENT IS -+-> '<string>' ---+----+ |
| | +-------- / <-----+ | |
| +-----------------<---------------------+ |
| +---------------------------------------------------------+
| +-+----------------------+-+------------------------------->
| +-> partition-clause --+ |
+> store-lists-clause ---------+
partition-updatable-clause =
---> PARTITIONING IS -+-> NOT UPDATABLE -+-->
+-> UPDATABLE -----+
threshold-clause =
--+-> THRESHOLD -+-> IS -+-> ( --> <val1> --> ) ---------+->
| +-> OF -+ |
| |
+-> THRESHOLDS -+-> ARE -+-----------+ |
+-> OF -+ | |
+----------------------------------+ |
+-> ( --> <val1> -+---------------------------+-> ) -+
+-> , <val2> -+-------------+
+-> , <val3> -+
partition-clause =
-+> STORE -+------------------++--------------------+> store-clause -+>
| +> columns-clause -++> store-attributes -+ |
+------------------------------- <----------------------------------+
columns-clause =
-> COLUMNS --> ( -+-> <column-name> -+-> ) -->
+-------- , <------+
store-attributes =
--+-+-+-> ENABLE --+-> COMPRESSION -+-+-->
| | +-> DISABLE -+ | |
| +-> thresholds-clause ----------+ |
| +-> VERTICAL PARTITION <name> --+ |
+--------------- <------------------+
store-clause =
---+-> IN area-spec ------------------------+-->
+-> across-clause -----------------------+
+-> using-clause ------------------------+
area-spec =
--> <area-name> -+---------------------------------------------------+->
+-> ( -++-> threshold-clause ---------------++-> ) -+
|+-> LOGGING ------------------------+|
|+-> NOLOGGING ----------------------+|
|+-> PARTITION <name> ---------------+|
|+-> COMMENT IS -+--> 'string' ---+--+|
| +------- / <-----+ |
+---------------- , -----------------+
across-clause =
---> RANDOMLY ACROSS ---+
+----------------------+
+-> ( -+> area-spec --+--> ) -->
+----- , <-----+
using-clause =
---> USING ---> ( -+-> <column-name> -+-> ) ------------------+
+-------- , <------+ |
+--------------------------------------------------------------+
++-> IN area-spec -> WITH LIMIT OF --> ( +-> <literal> -+> ) +-+
| +------ , <----+ | |
+--------------------------<--------------------------------+ |
+--------------------------<----------------------------------+
++------------------------------------------------+------------->
+> OTHERWISE IN area-spec -----------------------+
store-lists-clause =
---> STORE LISTS ---+
+------------------+
+-+-> IN -+-> area-spec ---------------+---+----------->
| +-> ( +> area-spec -> ) ----++ |
| +------ , <-----------+ |
| +---------------------------------------+
| +-+------------------------>-----------------------+
| +-> FOR -> ( -+-> <table-name> ---------+-> ) -+ |
| +-> <table-name.col-name> + | |
| +-------- , <-------------+ | |
| +--------------------------------------+ |
| +---+------------>----------+------------+
| +-> FILL RANDOMLY -----+ |
| +-> FILL SEQUENTIALLY --+ |
+----------------------------<-----------------------+
17.3 – Arguments
17.3.1 – across-clause
Associates the table with two or more storage areas.
17.3.2 – COMMENT IS 'string'
Adds a comment about the storage map. SQL displays the text of
the comment when it executes a SHOW STORAGE MAPS statement.
Enclose the comment in single quotation marks (') and separate
multiple lines in a comment with a slash mark (/).
17.3.3 – COMPRESSION option
Syntax options:
ENABLE COMPRESSION | DISABLE COMPRESSION
Specifies whether the rows for the partition are compressed or
uncompressed when stored. You can enable or disable compression
on each vertical partition. You enable compression to conserve
disk space, but there is a small CPU overhead for inserting and
retrieving compressed rows.
If you omit this clause, the default compression is that which
was specified for the storage map before the first STORE COLUMNS
clause. The default is ENABLE COMPRESSION.
17.3.4 – FILL
Syntax options:
FILL RANDOMLY | FILL SEQUENTIALLY
Specifies whether to fill the area set randomly or sequentially.
Specifying FILL RANDOMLY or FILL SEQUENTIALLY requires a FOR
clause. When a storage area is filled, it is removed from the
list of available areas. Oracle Rdb does not attempt to store
any more lists in that area during the current database attach.
Instead, Oracle Rdb starts filling the next specified area.
When a set of areas is filled sequentially, Oracle Rdb stores
lists in the first specified area until that area is filled.
If the set of areas is filled randomly, lists are stored
across multiple areas. This is the default. Random filling is
intended for read/write media, which will benefit from the I/O
distribution across the storage areas.
The keywords FILL RANDOMLY and FILL SEQUENTIALLY can only be
applied to areas contained within an area list.
17.3.5 – FOR (table name)
Specifies the table or tables to which this list storage map
applies. The named table must already be defined. If you want to
store lists of more than one table in the storage area, separate
the names of the tables with commas. For each area, you can
specify one FOR clause and list of table names.
17.3.6 – FOR (table name.col name)
Specifies the name of the table and column containing the list
to which this storage map applies. Separate the table name and
the column name with a period (.). The named table and column
must already be defined. If you want to store multiple lists
in the storage area, separate the table name and column name
combinations with commas. For each area, you can specify one FOR
clause and a list of column names.
17.3.7 – LOGGING
Syntax options:
LOGGING | NOLOGGING
The LOGGING clause specifies that rows written to the table
during the current transaction (the transaction in which this
table was created) be logged when written to the database.
Logging includes writing data and management records to the
recovery-unit journal file (.ruj) and after-image journal files
(.aij). When the NOLOGGING clause is specified then only a small
number of management records are logged in the recovery-unit
journal file (.ruj) and after-image journal files (.aij). See the
Usage Notes below for more information.
LOGGING and NOLOGGING can be specified per storage area
(partition) or as a default for the CREATE STORAGE MAP statement.
The LOGGING and NOLOGGING clauses are mutually exclusive; specify
only one. The LOGGING clause is the default.
17.3.8 – OTHERWISE_IN
For partitioned storage maps only, specifies the storage area
that is used as the overflow partition. An overflow partition is
a storage area that holds any values that are higher than those
specified in the WITH LIMIT OF clause. An overflow partition
holds those values that exceed the highest specified limits.
17.3.9 – partition-clause
Defines vertical partitioning, horizontal partitioning, or both
for the specified table.
Horizontal partitioning means that you divide the rows of the
table among storage areas according to data values in one or more
columns. Vertical partitioning means that you divide the columns
of the table among storage areas. A given storage area will then
contain only some of the columns of a table. You can combine both
horizontal and vertical partitions in a single map.
Vertical partitioning reduces disk I/O operations by placing
frequently used data in one area, so that you can read and update
those portions of the table in a single disk I/O operation.
See the Oracle Rdb Guide to Database Design and Definition for
more information regarding partitioning.
17.3.10 – PARTITION name
Names the partition. The name can be a delimited identifier if
the dialect or quoting rules are set to SQL92 or SQL99. Partition
names must be unique within the storage map. If you do not
specify this clause, Oracle Rdb generates a default name for
the partition.
17.3.11 – PARTITIONING_IS_NOT_UPDATABLE
Specifies that the value of the partitioning key cannot be
modified and that the row is always stored in the storage area
based on the partitioning criteria in the STORE USING clause. The
partitioning key is the column or list of columns specified in
the STORE USING clause.
Specifying the PARTITIONING IS NOT UPDATABLE clause allows Oracle
Rdb to quickly retrieve data because the partitioning criteria
can be used when optimizing the query.
To update columns that are partitioning keys in a NOT UPDATABLE
storage map, you must delete the rows and then reinsert the rows
to ensure that they are placed in the correct location.
If you specify the PARTITIONING clause, you must also specify the
STORE USING clause when defining a storage map.
If the PARTITIONING clause is not specified, UPDATABLE is the
default.
See the Oracle Rdb Guide to Database Design and Definition for
more information regarding partitioning.
17.3.12 – PARTITIONING_IS_UPDATABLE
Specifies that the partitioning key can be modified. The
partitioning key is the column or list of columns specified in
the STORE USING clause.
If you modify a row in an UPDATABLE storage map, the row is not
moved to a different storage area even if the new value of the
partitioning key is not within the limits of original storage
area. As a result, Oracle Rdb must consider all storage areas
specified in the STORE USING clause when retrieving a row.
If you specify the PARTITIONING clause, you must also specify the
STORE USING clause when defining a storage map.
If the PARTITIONING clause is not specified, UPDATABLE is the
default.
See the Oracle Rdb Guide to Database Design and Definition for
more information regarding partitioning.
17.3.13 – PLACEMENT_VIA_INDEX
Directs the database system to store a column in a way that
optimizes access to that column by the indicated path. Oracle Rdb
chooses a target page for any columns being stored by rules that
take into account the type of index named (sorted or hashed),
the type of storage areas involved (uniform or mixed), and how
indexes and tables are assigned to storage areas.
For a hashed index, Oracle Rdb calculates the page containing
the hashed index node that points to the column. If that page is
within the same storage area in which the column will be stored,
it is used as the target page for storing the column. If that
page is not within the same storage area in which the column
is to be stored, Oracle Rdb chooses a target page in the same
relative position within the appropriate storage area (if it is a
mixed storage area) or a page in a clump reserved for that table
(if it is a uniform storage area).
For a sorted index, Oracle Rdb finds the database key of the next
lowest row to the one being stored and uses the page number in
the database key as the target page.
17.3.14 – STORAGE_MAP
Specifies the name of the storage map you want to create. The
name cannot be the same as any other definition in the database.
17.3.15 – store-clause
The storage map definition. The store-clause in a CREATE STORAGE
MAP statement lets you specify which storage area files are used
to store rows from the table.
o All rows of a table can be associated with a single storage
area.
o Rows of a table can be randomly distributed among several
storage areas.
o Rows of a table can be systematically distributed, or
partitioned, among several storage areas by specifying upper
limits on the values for a column in a particular storage
area. This is called horizontal partitioning.
o Columns of a table can be partitioned among storage areas.
This is called vertical partitioning.
If you omit the storage map definition, the default is to store
all the rows for a table in the default storage area. See the
CREATE and IMPORT DATABASE statements for information on the
default storage area.
17.3.16 – STORE_COLUMNS
Syntax option:
STORE COLUMNS (column-name)
Lists the columns which will be stored in the subsequent map.
Multiple STORE COLUMNS clauses may appear in a map to spread
across multiple storage areas. A column name may only appear
in one STORE COLUMNS clause. A final STORE clause can appear to
provide a location for all remaining unspecified columns.
17.3.17 – STORE IN area name
Associates the table directly with a single storage area. All
rows in the table are stored in the area you specify.
17.3.18 – STORE_LISTS_IN
Directs the database system to store the lists from tables in a
specified storage area or in a set of areas. You can create only
one storage map for lists within each database.
You must specify the default storage area for lists in the STORE
LISTS clause. The default list storage area contains lists from
system tables as well as lists not directed elsewhere by the
STORE LISTS clause. You can also use the LIST STORAGE AREA clause
of the CREATE DATABASE statement to specify a default storage
area for lists. If you do not use the STORE LISTS clause and do
not specify a list storage area in the CREATE DATABASE statement,
Oracle Rdb uses the default storage area as the default list
storage area. The following example directs Oracle Rdb to place
all lists in the LISTS storage area unless otherwise specified in
a storage map:
SQL> CREATE DATABASE FILENAME mf_personnel
SQL> LIST STORAGE AREA IS LISTS
SQL> CREATE STORAGE AREA LISTS;
The accompanying storage map statement must also specify the
LISTS storage area as the default storage area.
SQL> CREATE STORAGE MAP LISTS_MAP
cont> STORE LISTS IN LISTS1 FOR (EMPLOYEES.RESUME)
cont> IN LISTS;
You can use an area set to specify that data is to be distributed
across several areas. The following example shows how you can
store data in three storage areas (LISTS1, LISTS2, and LISTS3)
for two different columns in TABLE1. The default list storage
area is LISTS1.
CREATE STORAGE MAP LISTS_MAP
STORE LISTS IN (LISTS1,LISTS2,LISTS3) FOR (TABLE1.COL1,TABLE1.COL2)
IN LISTS1;
You can store lists from different tables in the same area. The
following example shows how you can store data from TABLE1,
TABLE2, and TABLE3 in the LISTS storage area. The default list
storage area is RDB$SYSTEM.
SQL> CREATE STORAGE MAP LISTS_MAP -- to direct the list data to area LISTS
cont> STORE LISTS IN LISTS FOR (TABLE1, TABLE2, TABLE3)
cont> IN RDB$SYSTEM;
Alternatively, you can store lists from each table in unique
areas. The following example shows list data from TABLE1 being
stored in the LISTS1 storage area and list data from TABLE2 being
stored in the LISTS2 storage area. The default list storage area
is RDB$SYSTEM.
CREATE STORAGE MAP LISTS_MAP
STORE LISTS IN LIST1 FOR (TABLE1)
IN LIST2 FOR (TABLE2)
IN RDB$SYSTEM;
You can also specify that different columns from the same table
go into different areas. The following example shows data from
different columns in TABLE1 being stored in either LISTS1 or
LISTS2. The default list storage area is RDB$SYSTEM.
CREATE STORAGE MAP LISTS_MAP
STORE LISTS IN LISTS1 FOR (TABLE1.COL1)
IN LISTS2 FOR (TABLE1.COL2)
IN RDB$SYSTEM;
17.3.19 – STORE_RANDOMLY_ACROSS
Syntax option:
STORE RANDOMLY ACROSS (area-name)
As rows are inserted in the table, they are distributed randomly
across the storage areas named in the list. You must name at
least two storage areas in this clause.
17.3.20 – STORE_USING
Syntax option:
STORE USING (column-name) IN area-name
The database system compares values in the columns to the values
in the WITH LIMIT OF clause to determine placement of rows
inserted into the table. See the Oracle Rdb SQL Reference Manual
for further information.
Use RMU EXTRACT to have the store using expression expanded. See
Example 9.
17.3.21 – STORED_NAME
Specifies a name that Oracle Rdb uses to access a storage map
created in a multischema database. The stored name allows you
to access multischema definitions using interfaces that do not
recognize multiple schemas in one database. You cannot specify a
stored name for a storage map in a database that does not allow
multiple schemas. For more information on stored names, see the
User_Supplied_Names HELP topic.
17.3.22 – THRESHOLD clause
Specifies one, two, or three default threshold values for logical
areas in storage areas with uniform format pages. The threshold
values (val1, val2, and val3) represent a fullness percentage on
a data page and establish three possible ranges of guaranteed
free space on the data pages. When a data page reaches the
percentage defined by a given threshold value, the space area
management (SPAM) entry for the data page is updated to reflect
the new fullness percentage and its remaining free space.
Oracle Rdb never stores a record at the third threshold. The
value you set for the highest threshold can be used to reserve
space on the page for future record growth.
When only val1 is specified, this is equivalent to (val1, 100,
100). When val1 and val2 are specified, this is equivalent to
(val1, val2, 100). The trailing, unspecified thresholds default
to 100 percent. For example, THRESHOLDS ARE (40) would appear as
(40, 100, 100).
If no thresholds are specified for the area, the default is
(0,0,0). This causes the SPAM algorithm to set thresholds based
on the nominal record length for the logical area; for example,
the node size for the index or the uncompressed length of the row
for a table.
You cannot specify the thresholds for the storage map attribute
for any area that is a mixed page format. If you have a mixed
page format, set the thresholds for the storage area using the
ADD STORAGE AREA or CREATE STORAGE AREA clause of the ALTER
DATABASE, CREATE DATABASE, or IMPORT statements.
17.3.23 – VERTICAL PARTITION name
Names a vertical partition. The name can be a delimited
identifier if the dialect or quoting rules are set to SQL92 or
SQL99. Partition names must be unique within the storage map. If
you do not specify this clause, Oracle Rdb generates a default
name for the partition.
17.3.24 – using-clause
Specifies columns whose values are used as limits for
partitioning the table horizontally across multiple storage
areas.
17.3.25 – WITH_LIMIT_OF
Specifies the maximum values that the columns named in the USING
clause can have when rows are initially stored in the specified
storage area. Repeat this clause to partition the rows of a table
among multiple storage areas.
The number of literals listed must be the same as the number of
columns in the USING clause. The data type of the literals must
agree with the data type of the column. For character columns,
enclose the literals in single quotation marks.
The values in the WITH LIMIT OF clause only affect placement of
rows when they are initially stored. If UPDATE statements change
data in a row so that values in columns named in the USING clause
exceed values specified in the WITH LIMIT OF clause, the row is
not moved into a different storage area.
17.4 – Examples
Example 1: Defining storage maps for a multifile database
This example shows the definition of storage maps for a multifile
database. The tables named in the CREATE STORAGE MAP statements
have the same definitions as those in the sample database.
See the CREATE STORAGE_AREA clause for an example of a CREATE
DATABASE statement with CREATE STORAGE AREA clauses that create
the storage areas referred to in this example.
SQL> -- Declare the database as the default:
SQL> ATTACH 'FILENAME multifile_example';
SQL> --
SQL> CREATE STORAGE MAP EMPLOYEE_MAP FOR EMPLOYEES
cont> STORE USING (EMPLOYEE_ID)
cont> IN EMPID_LOW WITH LIMIT OF ('00200')
cont> IN EMPID_MID WITH LIMIT OF ('00500')
cont> OTHERWISE IN EMPID_OVER;
SQL> --
SQL> CREATE STORAGE MAP RESUME_MAP
cont> STORE LISTS IN EMP_INFO FOR (TABLE1, TABLE2, TABLE3)
cont> IN RDB$SYSTEM;
SQL> --
SQL> CREATE STORAGE MAP JOB_HISTORY_MAP FOR JOB_HISTORY
cont> STORE IN HISTORIES;
SQL> --
SQL> CREATE STORAGE MAP SALARY_HISTORY_MAP FOR SALARY_HISTORY
cont> STORE IN HISTORIES;
SQL> --
SQL> CREATE STORAGE MAP JOBS_MAP FOR JOBS
cont> STORE IN CODES;
SQL> --
SQL> CREATE STORAGE MAP DEPARTMENTS_MAP FOR DEPARTMENTS
cont> STORE IN CODES;
SQL> --
SQL> CREATE STORAGE MAP COLLEGES_MAP FOR COLLEGES
cont> STORE IN CODES;
SQL> --
SQL> CREATE STORAGE MAP DEGREES_MAP FOR DEGREES
cont> STORE IN EMP_INFO;
SQL> --
SQL> CREATE STORAGE MAP WORK_STATUS_MAP FOR WORK_STATUS
cont> STORE IN HISTORIES;
SQL> --
SQL> --
SQL> -COMMIT;
SQL> --
Example 2: Defining storage maps that place and override
thresholds on uniform storage areas
SQL> CREATE DATABASE FILENAME birdlist
cont> CREATE STORAGE AREA AREA1
cont> CREATE STORAGE AREA AREA2
cont> CREATE STORAGE AREA AREA3
cont> CREATE STORAGE AREA AREA4
cont> CREATE TABLE SPECIES
cont> ( GENUS CHAR (30),
cont> SPECIES CHAR (30),
cont> COMMON_NAME CHAR (40),
cont> FAMILY_NUMBER INT (3),
cont> SPECIES_NUMBER INT (3)
cont> )
cont> CREATE INDEX I1 ON SPECIES (FAMILY_NUMBER)
cont> CREATE TABLE SIGHTING
cont> ( SPECIES_NUMBER INT (3),
cont> COMMON_NAME CHAR (40),
cont> CITY CHAR (20),
cont> STATE CHAR (20),
cont> SIGHTING_DATE DATE ANSI,
cont> NOTES_NUMBER INT (5))
cont> CREATE INDEX I2 ON SIGHTING (SPECIES_NUMBER)
cont> CREATE TABLE FIELD_NOTES
cont> ( WEATHER CHAR (30),
cont> TIDE CHAR (15),
cont> SPECIES_NUMBER INT (3),
cont> SIGHTING_TIME TIMESTAMP(2),
cont> NOTES CHAR (500),
cont> NOTES_NUMBER INT (5))
cont> CREATE INDEX I3 ON FIELD_NOTES (NOTES_NUMBER)
cont> ;
SQL> --
SQL> -- The following CREATE STORAGE MAP statements place and
SQL> -- override thresholds on uniform storage area.
SQL> --
SQL> -- Note that the default threshold clause for the
SQL> -- storage map is not enclosed in parentheses, but each
SQL> -- threshold clause associated with a particular area is.
SQL> --
SQL> CREATE STORAGE MAP M1 FOR SPECIES
cont> THRESHOLDS ARE (30, 50, 80)
cont> ENABLE COMPRESSION
cont> PLACEMENT VIA INDEX I1
cont> STORE
cont> IN AREA1
cont> (THRESHOLD (10) );
SQL> --
SQL> CREATE STORAGE MAP M2 FOR SIGHTING
cont> THRESHOLD IS (40)
cont> STORE
cont> RANDOMLY ACROSS (
cont> AREA1 (THRESHOLD OF (10) ),
cont> AREA2 (THRESHOLDS ARE (30, 50, 98) ),
cont> AREA3
cont> );
SQL> --
SQL> CREATE STORAGE MAP M3 FOR FIELD_NOTES
cont> THRESHOLDS OF (50,70,90)
cont> STORE
cont> USING (SPECIES_NUMBER, NOTES_NUMBER)
cont> IN AREA1
cont> (THRESHOLDS OF (20, 80, 90) )
cont> WITH LIMIT OF (30, 88)
cont> IN AREA2
cont> WITH LIMIT OF (40, 89)
cont> IN AREA3
cont> WITH LIMIT OF (50, 90)
cont> OTHERWISE IN AREA4
cont> (THRESHOLDS ARE (20, 30, 40));
SQL> --
SQL> SHOW STORAGE MAP *;
User Storage Maps in database with filename birdlist
M1
For Table: SPECIES
Placement Via Index: I1
Partitioning is: UPDATABLE
Store clause: STORE
IN AREA1
(THRESHOLD (10) )
Partition information for storage map:
Compression is: ENABLED
Partition: (1) SYS_P00062
Storage Area: AREA1
M2
For Table: SIGHTING
Partitioning is: UPDATABLE
Store clause: STORE
RANDOMLY ACROSS (
AREA1 (THRESHOLD OF (10) ),
AREA2 (THRESHOLDS ARE (30, 50, 98) ),
AREA3
)
Partition information for storage map:
Compression is: ENABLED
Partition: (1) SYS_P00063
Storage Area: AREA1
Partition: (2) SYS_P00064
Storage Area: AREA2
Partition: (3) SYS_P00065
Storage Area: AREA3
M3
For Table: FIELD_NOTES
Partitioning is: UPDATABLE
Store clause: STORE
USING (SPECIES_NUMBER, NOTES_NUMBER)
IN AREA1
(THRESHOLDS OF (20, 80, 90) )
WITH LIMIT OF (30, 88)
IN AREA2
WITH LIMIT OF (40, 89)
IN AREA3
WITH LIMIT OF (50, 90)
OTHERWISE IN AREA4
(THRESHOLDS ARE (20, 30, 40))
Partition information for storage map:
Compression is: ENABLED
Partition: (1) SYS_P00066
Storage Area: AREA1
Partition: (2) SYS_P00067
Storage Area: AREA2
Partition: (3) SYS_P00068
Storage Area: AREA3
Partition: (4) SYS_P00069
Storage Area: AREA4
SQL> --
SQL> ROLLBACK;
Example 3: Creating a storage map that stores lists
This example creates a storage map that stores lists on specific
storage areas.
SQL> CREATE DATABASE FILENAME test
cont> CREATE STORAGE AREA LISTS1 PAGE FORMAT IS MIXED
cont> CREATE STORAGE AREA LISTS2 PAGE FORMAT IS MIXED
cont>
cont> CREATE TABLE EMPLOYEES
cont> (EMP_ID CHAR(5),
cont> RESUME LIST OF BYTE VARYING);
SQL> --
SQL> CREATE STORAGE MAP LISTS_MAP
cont> STORE LISTS IN
cont> (LISTS1,LISTS2) FOR (EMPLOYEES.RESUME)
cont> FILL SEQUENTIALLY
cont> IN RDB$SYSTEM;
Example 4: Creating an alternate map
This example following storage map shows an alternate mapping for
the EMPLOYEES table in the same MF_PERSONNEL database.
SQL> create storage map EMPLOYEES_MAP
cont> for EMPLOYEES
cont> placement via index EMPLOYEES_HASH
cont> -- store the primary information horizontally partitioned
cont> -- across the areas EMPIDS_LOW, EMPIDS_MID and EMPIDS_OVER
cont> -- disable compress because these columns are accessed often
cont> store
cont> columns (EMPLOYEE_ID, LAST_NAME,
cont> FIRST_NAME, MIDDLE_INITIAL)
cont> disable compression
cont> using (EMPLOYEE_ID)
cont> in EMPIDS_LOW
cont> with limit of ('00200')
cont> in EMPIDS_MID
cont> with limit of ('00400')
cont> otherwise in EMPIDS_OVER
cont>
cont> -- place all the address information in EMP_INFO
cont> -- make sure these character columns are compressed
cont> -- to remove the trailing spaces
cont> store
cont> columns (ADDRESS_DATA_1, ADDRESS_DATA_2, CITY, STATE,
cont> POSTAL_CODE)
cont> enable compression
cont> in EMP_INFO
cont>
cont> -- the remaining columns get
cont> -- written randomly over these areas
cont> store
cont> enable compression
cont> randomly across (SALARY_HISTORY, JOBS);
Example 5: Disabling logging and naming horizontal and vertical
partitions
SQL> CREATE DATABASE FILENAME birdlist
cont> CREATE STORAGE AREA AREA1
cont> CREATE STORAGE AREA AREA2
cont> CREATE STORAGE AREA AREA3
cont> CREATE STORAGE AREA AREA4
cont> CREATE STORAGE AREA AREA5
cont> CREATE STORAGE AREA AREA6
cont> CREATE STORAGE AREA AREA7
cont> CREATE STORAGE AREA AREA8
cont> CREATE TABLE SPECIES
cont> ( GENUS CHAR (30),
cont> SPECIES CHAR (30),
cont> COMMON_NAME CHAR (40),
cont> FAMILY_NUMBER INT (3),
cont> SPECIES_NUMBER INT (3)
cont> )
cont> CREATE INDEX I1 ON SPECIES (FAMILY_NUMBER)
cont> CREATE TABLE SIGHTING
cont> ( SPECIES_NUMBER INT (3),
cont> COMMON_NAME CHAR (40),
cont> CITY CHAR (20),
cont> STATE CHAR (20),
cont> SIGHTING_DATE DATE ANSI,
cont> NOTES_NUMBER INT (5))
cont> CREATE INDEX I2 ON SIGHTING (SPECIES_NUMBER)
cont> CREATE TABLE FIELD_NOTES
cont> ( WEATHER CHAR (30),
cont> TIDE CHAR (15),
cont> SIGHTING_TIME TIMESTAMP(2),
cont> NOTES CHAR (500),
cont> NOTES_NUMBER INT (5),
cont> SPECIES_NUMBER INT (3))
cont> CREATE INDEX I3 ON FIELD_NOTES (NOTES_NUMBER);
SQL> --
SQL> -- Note that the default threshold clause for the
SQL> -- storage map is not enclosed in parentheses, but each
SQL> -- threshold clause associated with a particular area is enclosed
SQL> -- in parentheses.
SQL> --
SQL> CREATE STORAGE MAP M1 FOR SPECIES
cont> THRESHOLDS ARE (30, 50, 80)
cont> ENABLE COMPRESSION
cont> PLACEMENT VIA INDEX I1
cont> NOLOGGING
cont> COMMENT IS 'Storage Map for Species'
cont> STORE
cont> IN AREA1
cont> (THRESHOLD (10),
cont> PARTITION AREA1,
cont> COMMENT IS 'Partition is AREA1');
SQL> --
SQL> CREATE STORAGE MAP M2 FOR SIGHTING
cont> THRESHOLD IS (40)
cont> STORE
cont> RANDOMLY ACROSS (
cont> AREA1 (THRESHOLD OF (10),
cont> PARTITION AREA1),
cont> AREA2 (THRESHOLDS ARE (30, 50, 98),
cont> PARTITION AREA2),
cont> AREA3 (PARTITION AREA3)
cont> );
SQL> --
SQL> CREATE STORAGE MAP M3 FOR FIELD_NOTES
cont> THRESHOLDS OF (50,70,90)
cont> STORE COLUMNS (WEATHER, TIDE, SIGHTING_TIME)
cont> VERTICAL PARTITION WEATHER_TIDE_SIGHTINGTIME
cont> USING (SPECIES_NUMBER, NOTES_NUMBER)
cont> IN AREA1
cont> (THRESHOLDS OF (20, 80, 90) )
cont> WITH LIMIT OF (30, 88)
cont> IN AREA2
cont> WITH LIMIT OF (40, 89)
cont> IN AREA3
cont> WITH LIMIT OF (50, 90)
cont> OTHERWISE IN AREA4
cont> (THRESHOLDS ARE (20, 30, 40))
cont> STORE COLUMNS (NOTES, NOTES_NUMBER, SPECIES_NUMBER)
cont> VERTICAL PARTITION NOTES_NOTESNUM_SPECIESNUM
cont> USING (SPECIES_NUMBER)
cont> IN AREA5
cont> (THRESHOLDS OF (20, 80, 90) )
cont> WITH LIMIT OF (30)
cont> IN AREA6
cont> WITH LIMIT OF (40)
cont> IN AREA7
cont> WITH LIMIT OF (50)
cont> OTHERWISE IN AREA8
cont> (THRESHOLDS ARE (20, 30, 40));
Example 6: Creating a storage map for a table containing data
SQL> -- Create table, insert data, and then create a storage map.
SQL> --
SQL> CREATE TABLE MAP_TEST2 (a INTEGER, b CHAR(10));
SQL> INSERT INTO MAP_TEST2 (a, b) VALUES (2, 'Second');
1 row inserted
SQL> CREATE STORAGE MAP MAP_TEST2_MAP FOR MAP_TEST2
cont> STORE IN RDB$SYSTEM;
SQL> INSERT INTO MAP_TEST2 (a, b) VALUES (22, 'Second2');
1 row inserted
SQL> COMMIT;
SQL> SELECT *,DBKEY FROM MAP_TEST2;
A B DBKEY
2 Second 90:809:0
22 Second2 90:809:1
2 rows selected
SQL>
SQL> -- Now alter the storage map and
SQL> -- place it in a different storage area.
SQL>
SQL> ALTER STORAGE MAP MAP_TEST2_MAP
cont> STORE IN TEST_AREA2;
SQL> COMMIT;
SQL> SELECT *,DBKEY FROM MAP_TEST2;
A B DBKEY
2 Second 91:11:0
22 Second2 91:11:1
2 rows selected
SQL>
Example 7: Invalid attempts to create a storage map
SQL> -- Create table, insert data, and then
SQL> -- create a storage map with invalid attributes.
SQL>
SQL> CREATE TABLE MAP_TEST3 (a INTEGER, b CHAR(10));
SQL> CREATE INDEX MAP_TEST3_INDEX ON MAP_TEST3 (a);
SQL> INSERT INTO MAP_TEST3 (a, b) VALUES (3, 'Third');
1 row inserted
SQL>
SQL> CREATE STORAGE MAP MAP_TEST3_MAP FOR MAP_TEST3
cont> STORE IN TEST_AREA1; -- Must be the default area.
%RDB-E-NO_META_UPDATE, metadata update failed
-RDMS-F-RELNOTEMPTY, table "MAP_TEST3" has data in it
-RDMS-E-NOCMPLXMAP, can not use complex map for non-empty table
SQL>
SQL> CREATE STORAGE MAP MAP_TEST3_MAP for MAP_TEST3
cont> PLACEMENT VIA INDEX MAP_TEST3_INDEX -- Can't use placement.
cont> STORE IN RDB$SYSTEM;
%RDB-E-NO_META_UPDATE, metadata update failed
-RDMS-F-RELNOTEMPTY, table "MAP_TEST3" has data in it
-RDMS-E-NOCMPLXMAP, can not use complex map for non-empty table
SQL>
SQL> CREATE STORAGE MAP MAP_TEST3_MAP FOR MAP_TEST3
cont> DISABLE COMPRESSION -- Can't change compression.
cont> STORE IN RDB$SYSTEM;
%RDB-E-NO_META_UPDATE, metadata update failed
-RDMS-F-RELNOTEMPTY, table "MAP_TEST3" has data in it
-RDMS-E-NOCMPLXMAP, can not use complex map for non-empty table
SQL>
SQL> CREATE STORAGE MAP MAP_TEST3_MAP for MAP_TEST3
cont> THRESHOLDS ARE (50, 60, 70) -- Can't change thresholds.
cont> STORE IN RDB$SYSTEM;
%RDB-E-NO_META_UPDATE, metadata update failed
-RDMS-F-RELNOTEMPTY, table "MAP_TEST3" has data in it
-RDMS-E-NOCMPLXMAP, can not use complex map for non-empty table
SQL>
SQL> CREATE STORAGE MAP MAP_TEST3_MAP FOR MAP_TEST3
cont> STORE ACROSS (RDB$SYSTEM, TEST_AREA2);-- Can't use more than one area.
%RDB-E-NO_META_UPDATE, metadata update failed
-RDMS-F-RELNOTEMPTY, table "MAP_TEST3" has data in it
-RDMS-E-NOCMPLXMAP, can not use complex map for non-empty table
SQL>
SQL> CREATE STORAGE MAP MAP_TEST3_MAP for MAP_TEST3
cont> STORE COLUMNS (a) in RDB$SYSTEM -- Can't vertically partition.
cont> STORE COLUMNS (b) in TEST_AREA2;
%RDB-E-NO_META_UPDATE, metadata update failed
-RDMS-F-RELNOTEMPTY, table "MAP_TEST3" has data in it
-RDMS-E-NOCMPLXMAP, can not use complex map for non-empty table
Example 8: Using the RMU Extract command to display WITH LIMIT OF
expressions
The WITH LIMIT OF clauses of the STORE clause are converted
to Boolean expressions that are used by Oracle Rdb to direct
inserted data to the correct storage area. You can use the RMU
Extract command to display these Boolean expressions. Use the
Item=STORAGE_MAP and Option=FULL qualifiers as shown in the
following example.
$ RMU/EXTRACT-
_$ /ITEM=STORAGE_MAP-
_$ /OPTION=(MATCH:EMPLOYEES_MAP%,NOHEADER,FULL,FILENAME_ONLY) -
_$ DB$:MF_PERSONNEL
set verify;
set language ENGLISH;
set default date format 'SQL92';
set quoting rules 'SQL92';
set date format DATE 001, TIME 001;
attach 'filename MF_PERSONNEL.RDB';
create storage map EMPLOYEES_MAP
for EMPLOYEES
comment is
' employees partitioned by "00200" "00400"'
placement via index EMPLOYEES_HASH
store
using (EMPLOYEE_ID)
-- Partition:
-- (EMPLOYEE_ID <= '00200')
in EMPIDS_LOW
with limit of ('00200')
-- Partition:
-- (EMPLOYEE_ID <= '00400')
in EMPIDS_MID
with limit of ('00400')
otherwise in EMPIDS_OVER;
commit work;
Example 9: SQL Mapping Routine
This example shows the SQL mapping routine created by the CREATE
STORAGE MAP statement that matches the WITH LIMIT OF clause for
the storage map.
SQL> create table EMPLOYEES (
cont> EMPLOYEE_ID CHAR (5),
cont> LAST_NAME CHAR (14),
cont> FIRST_NAME CHAR (10),
cont> MIDDLE_INITIAL CHAR (1),
cont> ADDRESS_DATA_1 CHAR (25),
cont> ADDRESS_DATA_2 CHAR (25),
cont> CITY CHAR (20),
cont> STATE CHAR (2),
cont> POSTAL_CODE CHAR (5),
cont> SEX CHAR (1),
cont> BIRTHDAY DATE VMS,
cont> STATUS_CODE CHAR (1));
SQL>
SQL> create storage map EMPLOYEES_MAP
cont> for EMPLOYEES
cont> comment is
cont> ' employees partitioned by "00200" "00400"'
cont> store
cont> using (EMPLOYEE_ID)
cont> in EMPIDS_LOW
cont> with limit of ('00200')
cont> in EMPIDS_MID
cont> with limit of ('00400')
cont> otherwise in EMPIDS_OVER;
SQL>
SQL> commit work;
SQL>
SQL> show system modules;
Modules in database with filename MF_PERSONNEL
RDB$STORAGE_MAPS
SQL>
SQL> show system functions;
Functions in database with filename MF_PERSONNEL
EMPLOYEES_MAP
SQL>
SQL> show system function EMPLOYEES_MAP;
Information for function EMPLOYEES_MAP
Function ID is: -2
Source:
return
case
when (:EMPLOYEE_ID <= '00200') then 1
when (:EMPLOYEE_ID <= '00400') then 2
else 3
end case;
Comment: Return value for select partition - range 1 .. 3
Module name is: RDB$STORAGE_MAPS
Module ID is: -1
Number of parameters is: 1
Parameter Name Data Type Domain or Type
-------------- --------- --------------
INTEGER
Function result datatype
Return value is passed by value
EMPLOYEE_ID CHAR(5)
Parameter position is 1
Parameter is IN (read)
Parameter is passed by reference
Example 10: Using Storage Area Attributes in a LIST Storage Map
The following example shows the use of storage area attributes in
a LIST storage map. The storage area attributes must immediately
follow the storage area name (as in table storage maps).
SQL> create database
cont> filename 'DB$:MULTIMEDIA'
cont>
cont> create storage area PHOTO_AREA1
cont> filename 'DB$:PHOTO_AREA1'
cont> page format UNIFORM
cont>
cont> create storage area PHOTO_AREA2
cont> filename 'DB$:PHOTO_AREA2'
cont> page format UNIFORM
cont>
cont> create storage area TEXT_AREA
cont> filename 'DB$:TEXT_AREA'
cont> page format UNIFORM
cont>
cont> create storage area AUDIO_AREA
cont> filename 'DB$:AUDIO_AREA'
cont> page format UNIFORM
cont>
cont> create storage area DATA_AREA
cont> filename 'DB$:DATA_AREA'
cont> page format UNIFORM
cont> ;
SQL>
SQL> create table EMPLOYEES
cont> (name char(30),
cont> dob date,
cont> ident integer,
cont> photograph list of byte varying (4096) as binary,
cont> resume list of byte varying (132) as text,
cont> review list of byte varying (80) as text,
cont> voiceprint list of byte varying (4096) as binary
cont> );
SQL>
SQL> create storage map EMPLOYEES_MAP
cont> for EMPLOYEES
cont> enable compression
cont> store in DATA_AREA;
SQL>
SQL> create storage map LISTS_MAP
cont> store lists
cont> in AUDIO_AREA
cont> (thresholds are (89, 99, 100)
cont> ,comment is 'The voice clips'
cont> ,partition AUDIO_STUFF)
cont> for (employees.voiceprint)
cont> in TEXT_AREA
cont> (thresholds is (99)
cont> ,partition TEXT_DOCUMENTS)
cont> for (employees.resume, employees.review)
cont> in (PHOTO_AREA1
cont> (comment is 'Happy Smiling Faces?'
cont> ,threshold is (99)
cont> ,partition PHOTOGRAPHIC_IMAGES_1)
cont> ,PHOTO_AREA2
cont> (comment is 'Happy Smiling Faces?'
cont> ,threshold is (99)
cont> ,partition PHOTOGRAPHIC_IMAGES_2)
cont> )
cont> for (employees.photograph)
cont> fill randomly
cont> in RDB$SYSTEM
cont> (partition SYSTEM_LARGE_OBJECTS);
SQL>
SQL> show storage map LISTS_MAP;
LISTS_MAP
For Lists
Store clause: STORE lists
in AUDIO_AREA
(thresholds are (89, 99, 100)
,comment is 'The voice clips'
,partition AUDIO_STUFF)
for (employees.voiceprint)
in TEXT_AREA
(thresholds is (99)
,partition TEXT_DOCUMENTS)
for (employees.resume, employees.review)
in (PHOTO_AREA1
(comment is 'Happy Smiling Faces?'
,threshold is (99)
,partition PHOTOGRAPHIC_IMAGES_1)
,PHOTO_AREA2
(comment is 'Happy Smiling Faces?'
,threshold is (99)
,partition PHOTOGRAPHIC_IMAGES_2)
)
for (employees.photograph)
fill randomly
in RDB$SYSTEM
(partition SYSTEM_LARGE_OBJECTS)
Partition information for lists map:
Vertical Partition: VRP_P000
Partition: (1) AUDIO_STUFF
Fill Randomly
Storage Area: AUDIO_AREA
Thresholds are (89, 99, 100)
Comment: The voice clips
Partition: (2) TEXT_DOCUMENTS
Fill Randomly
Storage Area: TEXT_AREA
Thresholds are (99, 100, 100)
Partition: (3) PHOTOGRAPHIC_IMAGES_1
Fill Randomly
Storage Area: PHOTO_AREA1
Thresholds are (99, 100, 100)
Comment: Happy Smiling Faces?
Partition: (3) PHOTOGRAPHIC_IMAGES_2
Storage Area: PHOTO_AREA2
Thresholds are (99, 100, 100)
Comment: Happy Smiling Faces?
Partition: (4) SYSTEM_LARGE_OBJECTS
Fill Randomly
Storage Area: RDB$SYSTEM
SQL>
SQL> commit;
18 – SYNONYM
Creates an alternate name or synonym for an existing database
object. The object may be a domain, function, module, procedure,
sequence, another synonym, table, or view.
Once defined, the synonym can be used in any query or data
definition language statement in place of the referenced object.
However, the SHOW commands do not accept synonyms. Use the SHOW
SYNONYM statement to determine if the name is a synonym.
18.1 – Environment
You can use the CREATE SYNONYM statement:
o In interactive SQL
o Embedded in host language programs
o As part of a procedure in an SQL module or other compound
statement
o In dynamic SQL as a statement to be dynamically executed
18.2 – Format
CREATE -+---------------+-+-----------+---+
+-> OR REPLACE -+ +-> PUBLIC -+ |
+------------------ <--------------------+
+-> SYNONYM <synonym-name> FOR -+----------------+-+
+-> object-type -+ |
+---------------------- <--------------------------+
+-> <object-name> -+-----------------------------------------+->
+-> COMMENT IS -+-> ' <quoted-string> ' -++
+--------- / <-----------+
object-type =
-+-> DOMAIN ----+->
+-> FUNCTION --+
+-> MODULE ----+
+-> PROCEDURE -+
+-> SEQUENCE --+
+-> SYNONYM ---+
+-> TABLE -----+
+-> VIEW ------+
18.3 – Arguments
18.3.1 – COMMENT IS 'quoted-string'
This optional clause can be used to add several lines of comment
to the synonym object. The comment is displayed by the SHOW
SYNONYM statement.
18.3.2 – FOR object-name
The name of the database object for which the synonym is
required. This name must exist for an object in the database. If
the optional object type is omitted, then Oracle Rdb will search
the database for an object with this name.
18.3.3 – object-type
Syntax options:
DOMAIN
FUNCTION
MODULE
PROCEDURE
SEQUENCE
SYNONYM
TABLE
VIEW
These optional object types can be used when the referenced
object name is not unique within the database. For instance,
Oracle Rdb allows a domain and a table to both be called MONEY.
Therefore, to create a synonym for the table MONEY, you must use
the FOR TABLE clause so that it is uniquely identified.
18.3.4 – OR_REPLACE
Instructs SQL to replace any synonym of this name if it exists.
If it does not exist, a new synonym is created. This shorthand
allows replacement of an existing synonym while maintaining
all the dependencies established by query and DDL usage of this
synonym.
18.3.5 – PUBLIC
This optional clause is provided for compatibility with the
Oracle database server. It is currently not used by Oracle
Rdb. Its presence or absence may be used by future releases.
Oracle Corporation recommends you use the PUBLIC keyword in
applications.
18.3.6 – synonym-name
The name of the synonym you want to create. The synonym name
must be unique within all domains, tables, views, functions,
procedures, modules, sequences, and synonyms within the database.
You may qualify it with an alias.
18.4 – Examples
Example 1: Using the Default Alias
SQL> CREATE SYNONYM emps FOR employees;
Example 2: Using an Explicit Alias for the Synonym
SQL> CREATE SYNONYM db1.emps FOR employees;
Example 3: Using an Explicit Alias for the Referenced Object
SQL> CREATE SYNONYM emps FOR db1.employees;
Example 4: Using the Alias Explicitly
SQL> CREATE SYNONYM db1.emps FOR db1.employees;
Example 5: Using the Table Type
SQL> CREATE SYNONYM cash FOR table money
cont> COMMENT IS 'use a different name to avoid confusion with'
cont> / 'the domain MONEY';
Example 6: Using Multiple Synonyms
SQL> CREATE TABLE t_employees_0001 (...);
SQL> CREATE SYNONYM employees FOR t_employees_0001;
SQL> CREATE SYNONYM emps FOR employees;
19 – TABLE
Creates a temporary or persistent base table definition. A table
definition consists of a list of definitions of columns that make
up a row in the table.
Persistent base tables are tables whose metadata and data are
stored in the database beyond an SQL session. The data can be
shared by all users attached to the database.
Temporary tables are tables whose data is automatically deleted
when an SQL session or module ends. The tables only materialize
when you refer to them in an SQL session and the data is local
to an SQL session. You can also specify whether the data is
preserved or deleted at the end of a transaction within the
session; the default is to delete the data. The data in temporary
tables is private to the user. There are three types of temporary
tables:
o Global temporary tables
o Local temporary tables
o Declared local temporary tables (see the DECLARE LOCAL_
TEMPORARY_TABLE for additional information)
The metadata for a global temporary table is stored in the
database and persists beyond the SQL session. Different SQL
sessions can share the same metadata. The data stored in the
table cannot be shared between SQL sessions. However, the data
can be shared between modules in a single SQL session. The data
does not persist beyond an SQL session.
The metadata for a local temporary table is stored in the
database and persists beyond the SQL session. Different SQL
sessions can share the same metadata. The data stored in the
table cannot be shared between different modules in a single SQL
session or between SQL sessions. The data does not persist beyond
an SQL session or module.
Because temporary tables are used only to hold the user's data,
which is not shared among users, no locks are needed and the data
can be modified in a read-only transaction.
See the Oracle Rdb Guide to Database Design and Definition for
more information on temporary tables.
Information tables are special read-only tables that can be
used to retrieve database attributes that are not stored in the
existing relational tables. Information tables allow interesting
database information, which is currently stored in an internal
format, to be displayed as a relational table.
When you define a table, you can also define table constraints. A
constraint specifies a condition that restricts the values that
can be stored in a table. Constraints can specify that columns
contain:
- Only certain values
- Primary key values
- Unique values
- Values that cannot be null
There are several ways to specify a table definition in the
CREATE TABLE statement:
o Directly by naming the table, its columns and associated
data types, default values (optional), constraint definitions
(optional), and formatting clauses.
You can define constraints on persistent base tables and
global temporary tables only.
o Indirectly by providing a path name for a repository record
definition that specifies the table name, columns, and data
types.
o Indirectly by providing another table as a model in inheriting
the columns, datatypes and NOT NULL constraints.
SQL allows you to specify the default character data type or the
national character data type when defining table columns.
19.1 – Environment
You can use the CREATE TABLE statement:
o In interactive SQL
o Embedded in host language programs to be precompiled
o As part of a procedure in an SQL module
o In dynamic SQL as a statement to be dynamically executed
19.2 – Format
CREATE -+---------------------------+-> TABLE --------+
+-> INFORMATION ------------+ |
+-> GLOBAL -+-> TEMPORARY --+ |
+-> LOCAL --+ |
+---------------------- <------------------------------+
++-> FROM <path-name> -+-------------------+-----------------------+
| +-> ALIAS <alias> --+ |
+-> <table-name> -+-------------------------------+-> table-body -+
+-> STORED NAME IS stored-name -+ |
+---------------------<------------------------------------------+
+-+--------------------------------+->
+-+--> create-table-attributes -++
+---------------<-------------+
create-table-attributes =
---+-> COMMENT IS --+-> 'quoted-string' -+------+->
| +-------- / ---------+ |
+-> COMPRESSION IS -+-> ENABLED ---+---------+
| +-> DISABLED --+ |
+-> DISABLE --+-> cre-enable-disable --------+
+-> ENABLE ---+ |
+-> LOGGING ---------------------------------+
+-> NOLOGGING -------------------------------+
+-> ON COMMIT -+-> DELETE ----+-> ROWS ------+
+-> PRESERVE --+
table-body =
-+-> (column-constraint-list) ---------------------------------+->
| |
+-> LIKE <other-table-name> --+------------------------------++
+--> (column-constraint-list) -+
cre-enable-disable =
-+-> ALL CONSTRAINTS ---------------------+->
+-> CONSTRAINT <constraint-name> --------+
+-> PRIMARY KEY -------------------------+
+-> UNIQUE ( -+- <column-name> +-> ) ----+
+------- , <-----+
col-definition =
--> <column-name> --+
+---------------+
+---> column-type ---+--------------------------+-+--+
| +->DEFAULT value-expr | | |
| +->column-identity --------+ | |
+---> COMPUTED BY value-expr ---------------------+ |
+-------------------------<--------------------------+
+-+--------------------+----------------+
+-> col-constraint --+ |
+--------------------------<------------+
++------------------------+-----+-----------------------+->
+-> comment-is-clause --+ +-> sql-and-dtr-clause -+
column-constraint-list =
--+--+-> col-definition -------+-----+->
| +-> table-constraint -----+ |
+---------------- , <--------------+
column-identity =
--> IDENTITY --+--------------------------------------------------+-->
+- ( <start-with> --+----------------------+-> ) --+
+-> , <increment-by> --+
column-type=
--+-> data-type -----------------------------------+-->
+-> <domain-name> -------------------------------+
+-> references-clause ---------------------------+
+-> AUTOMATIC --+-----------+--> AS value-expr --+
+-> INSERT -+
+-> UPDATE -+
data-type =
-+-> char-data-types -----------------------------------------+-->
+-> TINYINT --------------+-----+------------+---------------+
+-> SMALLINT -------------+ +-> ( <n> ) -+ |
+-> INTEGER --------------+ |
+-> BIGINT ---------------+ |
+-> FLOAT ----------------+ |
+-> NUMBER -+----------------------------------+-------------+
| +-> ( -+-> <p> -+-+----------+-> ) + |
| +-> * ---+ +-> , <d> -+ |
+-> LIST OF BYTE VARYING --+------------+--+--------------+--+
| +-> ( <n> ) -+ +-> AS BINARY -+ |
| +-> AS TEXT ---+ |
+-> DECIMAL -++------------------------------+---------------+
+-> NUMERIC -++-> ( --> <n> +----------+-> ) + |
| +-> , <n> -+ |
+-> REAL ----------------------------------------------------+
+-> DOUBLE PRECISION ----------------------------------------+
+-> date-time-data-types ------------------------------------+
char-data-types =
-+-> CHAR -------------++------------++--------------------------------+-+->
+-> CHARACTER --------++-> ( <n> ) -++-> CHARACTER SET char-set-name -+ |
+-> CHAR VARYING -----+ |
+-> CHARACTER VARYING + |
+-> VARCHAR --+> ( <n> ) ---+--------------------------------+----------+
+-> VARCHAR2 -+ +-> CHARACTER SET char-set-name -+ |
+-> LONG VARCHAR ------------------------------------------------------+
+-> NCHAR --------------+-+------------+--------------------------------+
+-> NATIONAL CHAR ------+ +-> ( <n> ) -+ |
+-> NATIONAL CHARACTER -+ |
+-> NCHAR VARYING --------------+-+------------+------------------------+
+-> NATIONAL CHAR VARYING ------+ +-> ( <n> ) -+ |
+-> NATIONAL CHARACTER VARYING -+ |
+-> RAW -> ( <n> ) -----------------------------------------------------+
+-> LONG -+--------+----------------------------------------------------+
+-> RAW -+
date-time-data-types =
--+-> DATE -+----------+-----------------+-->
| +-> ANSI -+ |
| +-> VMS ---+ |
+-> TIME ---> frac --------------------+
+-> TIMESTAMP --> frac ----------------+
+-> INTERVAL ---> interval-qualifier --+
col-constraint=
---+---------------------------------++
+-> CONSTRAINT <constraint-name> -+|
+------------------------------------+
+-> PRIMARY KEY -----------------+
+-> UNIQUE ----------------------+
+-> NOT NULL --------------------+
+-> NULL ------------------------+
+-> CHECK (predicate) -----------+
+-> references-clause -----------+
+------------>-------------------+
+-------------<------------------+
+----+----------------------------+-->
+--> constraint-attributes --+
references-clause =
REFERENCES <referenced-table-name> -+
+-----------------<----------------+
+-+--------------------->-------------------+->
+-> ( -+> <referenced-column-name> +-> ) -+
+----------- , <------------+
sql-and-dtr-clause =
-+-> QUERY HEADER IS -+> <quoted-string> +-------------------+->
| +------ / <--------+ |
+-> EDIT STRING IS <quoted-string> -------------------------+
| |
+-> QUERY NAME FOR -+-> DTR --------+-> IS <quoted-string> -+
| +-> DATATRIEVE -+ |
+-> DEFAULT VALUE FOR -+-> DTR --------+-> IS literal ----+
+-> DATATRIEVE -+
literal =
--+-> numeric-literal ----+--->
+-> string-literal -----+
+-> date-time-literal --+
+-> interval-literal ---+
+-> dbkey-literal ------+
table-constraint =
---+---------------->------------------+----+
+-> CONSTRAINT <constraint-name> ---+ |
+------------------------------------------+
+--> table-constraint-clause --------------+
+------------------------------------------+
+---+---------------------------+------------->
+-> constraint-attributes --+
table-constraint-clause =
-+----------------------------------------------+-->
+-> PRIMARY KEY -> ( -+-> <column-name> -+> ) -+
| +------- , <-------+ |
+-> UNIQUE -> ( -+> <column-name> +-> ) -------+
| +------- , <-----+ |
+-> CHECK (predicate) -------------------------+
+-> FOREIGN KEY -> ( -+> <column-name> +-> ) + |
+------- , <-----+ | |
+-----------------------<------------------+ |
+-> references-clause ------------->---------+
constraint-attributes =
-+-> DEFERRABLE -------------+------------------------------+-+->
| +-> INITIALLY +-> IMMEDIATE --++ |
| +-> DEFERRED ---+ |
+-> NOT DEFERRABLE ---------+-------------------------+------+
| +-> INITIALLY IMMEDIATE --+ |
+-> INITIALLY IMMEDIATE ----+-------------------+------------+
| +-> DEFERRABLE -----+ |
| +-> NOT DEFERRABLE -+ |
+-> INITIALLY DEFERRED -----+-------------------+------------+
+-> DEFERRABLE -----+
19.3 – Arguments
19.3.1 – ALIAS alias
Specifies a name for an attach to a particular database. SQL adds
the table definition to the database referred to by the alias.
If you do not specify an alias, SQL adds the table definition to
the default database. See the User_Supplied_Names HELP topic for
more information on default databases and aliases.
19.3.2 – AUTOMATIC
Syntax options:
AUTOMATIC AS value-expr
AUTOMATIC INSERT AS value-expr
AUTOMATIC UPDATE AS value-expr
These AUTOMATIC column clauses allow you to store special
information when data is inserted into a row or a row is updated.
For example, you can log application-specific information to
audit activity or provide essential values, such as time stamps
or unique identifiers for the data.
The assignment of values to these types of columns is managed by
Oracle Rdb. The AUTOMATIC INSERT clause can be used to provide
a complex default for the column when the row is inserted; it
cannot be changed by an UPDATE statement. The AUTOMATIC UPDATE
clause can be used to provide an updated value during an UPDATE
statement. The unqualified AUTOMATIC clause specifies that the
value expression should be applied during both INSERT and UPDATE
statements. The column type is derived from the AS value-expr;
using CAST allows a specific data type to be specified. However,
this is not required and is rarely necessary.
You can define an AUTOMATIC INSERT column to automatically
receive data during an insert operation. The data is stored like
any other column, but the column is read-only. Because AUTOMATIC
columns are treated as read-only columns, they cannot appear in
the column list for an insert operation nor be modified by an
update operation. AUTOMATIC UPDATE columns can have an associated
default value that will be used when the row is inserted.
19.3.3 – char-data-type
A valid SQL character data type. See the Data_Types HELP topic
for more information on character data types.
19.3.4 – character-set-name
A valid character set name.
19.3.5 – CHECK predicate
Specifies a predicate that column values inserted into the
table must satisfy. See the Predicates HELP topic for details
on specifying predicates.
Predicates in CHECK column constraints can refer directly only to
the column with which they are associated.
19.3.6 – col-constraint
A constraint that applies to values stored in the associated
column.
SQL allows column constraints and table constraints. The five
types of column constraints are PRIMARY KEY, UNIQUE, NOT NULL,
CHECK, and FOREIGN KEY constraints. The FOREIGN KEY constraints
are created with the REFERENCES clause.
You can define a column constraint on persistent base tables and
global temporary tables only.
19.3.7 – col-definition
The definition for a column in the table. SQL gives you two ways
to specify column definitions:
o By directly specifying a data type to associate with a column
name
o By naming a domain that indirectly specifies a data type to
associate with a column name
Either way also allows options for specifying default values,
column constraints, and formatting clauses.
19.3.8 – column-name
The name of a column you want to create in the table. You need to
specify a column name whether you directly specify a data type in
the column definition or indirectly specify a data type by naming
a domain in the column definition.
19.3.9 – COMPUTED_BY
Specifies that the value of this column is calculated from values
in other columns and constant expressions.
If your column definition refers to a column name within a value
expression, that named column must already be defined within the
same CREATE TABLE statement. See the Value_Expressions HELP topic
for information on value expressions.
Any column that you refer to in the definition of a computed
column cannot be deleted from that table unless you first delete
the computed column.
SQL does not allow the following for computed columns:
o UNIQUE constraints
o REFERENCES clauses
o PRIMARY KEY constraints
o DEFAULT clause
o IDENTITY clause
o Default value for DATATRIEVE
For example, if the FICA_RATE for an employee is 6.10 percent of
the employee's starting salary and the group insurance rate is
0.7 percent, you can define FICA_RATE and GROUP_RATE columns like
this:
SQL> CREATE TABLE payroll_detail
cont> (salary_code CHAR(1),
cont> starting_salary SMALLINT(2),
cont> fica_amt
cont> COMPUTED BY (starting_salary * 0.061),
cont> group_rate
cont> COMPUTED BY (starting_salary * 0.007));
When you use this type of definition, you only have to store
values in the salary_code and starting_salary columns. The FICA
and group insurance deduction columns are computed automatically
when the columns fica_amt or group_rate are selected.
19.3.10 – COMPRESSION_IS
Syntax options:
COMPRESSION IS ENABLED | COMPRESSION IS DISABLED
Specifies whether run-length compression is enabled or disabled
for rows inserted into the base or temporary table.
In some cases, the data inserted into a table may not compress
and so incur only overhead in the row. This overhead is used
by Rdb to describe the sequence of uncompressible data. Use
COMPRESSION IS DISABLED to prevent Rdb from attempting the
compression of such data.
Any storage map which specifies the ENABLE COMPRESSION or DISABLE
COMPRESSION clause will override this setting in the table.
The COMPRESSION IS clause is not permitted for INFORMATION
tables.
The default is COMPRESSION IS ENABLED.
19.3.11 – constraint-attributes
Although the constraint attribute syntax provides 11 permutations
as required by the SQL99 standard, they equate to the following
three options:
o INITIALLY IMMEDIATE NOT DEFERRABLE
Specifies that evaluation of the constraint must take place
when the INSERT, DELETE, or UPDATE statement executes. If
you are using the SQL99, SQL92, MIA, ORACLE LEVEL1, or ORACLE
LEVEL2 dialect, this is the default.
o INITIALLY IMMEDIATE DEFERRABLE
Specifies that evaluation of the constraint may be deferred
(using the SET CONSTRAINT ALL statement or the SET TRANSACTION
statement with the EVALUATING clause), but by default it
is evaluated after the INSERT, DELETE, or UPDATE statement
executes. See the SET_ALL_CONSTRAINTS statement for more
information.
o INITIALLY DEFERRED DEFERRABLE
Specifies that evaluation of the constraint can take place
at any later time. Unless otherwise specified, evaluation of
the constraint takes place as the COMMIT statement executes.
You can use the SET ALL CONSTRAINTS statement to have all
constraints evaluated earlier. See the description of the SET
ALL CONSTRAINTS statement for more information.
If you are using the default SQLV40 dialect, this is the
default constraint attribute. When using this dialect, Oracle
Rdb displays a deprecated feature message for all constraints
defined without specification of one of the constraint
attributes.
19.3.12 – CONSTRAINT
Specifies a name for a column or table constraint. The name is
used for a variety of purposes:
o The RDB$INTEG_FAIL error message specifies the name when an
INSERT, UPDATE, or DELETE statement violates the constraint.
o The ALTER TABLE table-name DROP CONSTRAINT constraint-name
statement specifies the name to delete a table constraint.
o The SHOW TABLE statements display the names of column and
table constraints.
o The EVALUATING clause of the SET TRANSACTION and DECLARE
TRANSACTION statements specifies constraint names.
o The ENABLE and DISABLE clauses of the ALTER and CREATE TABLE
statements specify constraint names.
o The ALTER CONSTRAINT statement specifies constraint names.
o The DROP CONSTRAINT statement
The CONSTRAINT clause is optional. If you omit the constraint
name, SQL creates a name. However, Oracle Rdb recommends that
you always name column and table constraints. If you supply a
constraint name with the CONSTRAINT clause, it must be unique
in the database or in the schema if you are using a multischema
database.
19.3.13 – data-type
A valid SQL data type. Specifying an explicit data type to
associate with a column is an alternative to specifying a domain
name. See the Data_Types HELP topic for more information on data
types.
19.3.14 – date-time-data-types
A data type that specifies a date, time, or interval. See the
Data_Types HELP topic for more information about date-time data
types.
19.3.15 – DEFAULT value-expr
Provides a default value for a column if the row that is inserted
does not include a value for that column.
You can use any value expression including subqueries,
conditional, character, date/time, and numeric expressions as
default values. See Value Expressions for more information about
value expressions.
For more information about NULL, see the NULL_Keyword HELP topic.
The value expressions described in Value Expressions include
DBKEY and aggregate functions. However, the DEFAULT clause is
not a valid location for referencing a DBKEY or an aggregate
function. If you attempt to reference either, you receive a
compile-time error.
If you do not specify a default value, a column inherits the
default value from the domain. If you do not specify a default
value for either the column or domain, SQL assigns NULL as the
default value.
19.3.16 – domain-name
The name of a domain created in a CREATE DOMAIN statement. SQL
gives the column the data type specified in the domain. For more
information on domains, see the CREATE DOMAIN statement.
For most purposes, you should specify a domain instead of an
explicit data type.
o Domains ensure that all columns in multiple tables that serve
the same purpose have the same data type. For example, several
tables in the sample personnel database refer to the domain
ID_DOM.
o A domain lets you change the data type for all columns that
refer to it in one operation by changing the domain itself
with an ALTER DOMAIN statement.
For example, if you want to change the data type for the
column EMPLOYEE_ID from CHAR(5) to CHAR(6), you need only
alter the data type for the domain ID_DOM. You do not have to
alter the data type for the column EMPLOYEE_ID in the tables
DEGREES, EMPLOYEES, JOB_HISTORY, or SALARY_HISTORY, nor do you
have to alter the column MANAGER_ID in the DEPARTMENTS table.
However, you might not want to use domains when you create tables
if:
o Your application must be compatible with Oracle RDBMS.
o You are creating intermediate result tables that do not need
the advantages of domains.
19.3.17 – enable-disable-clause
Allows you to enable or disable all constraints, specified
constraints, a primary key, or a unique column name, as described
in the following list. By default, table and column constraints
added during a create table operation are enabled.
o DISABLE ALL CONSTRAINTS
All table and column constraints for this table are disabled.
No error is raised if no constraints are defined on the table.
o ENABLE ALL CONSTRAINTS
All and column constraints for this table are enabled. No
error is raised if no constraints are defined on the table.
o DISABLE CONSTRAINT constraint-name
The named constraint is disabled. The named constraint must be
a table or column constraint for the table.
o ENABLE CONSTRAINT constraint-name
The named constraint is enabled. The named constraint must be
a table or column constraint for the table.
o DISABLE PRIMARY KEY
The primary key for the table is disabled.
o ENABLE PRIMARY KEY
The primary key for the table is enabled.
o DISABLE UNIQUE (column-name)
The matching UNIQUE constraint is disabled. The columns listed
must be columns in the table.
o ENABLE UNIQUE (column-name)
The matching UNIQUE constraint is enabled. The columns listed
must be columns in the table.
19.3.18 – FOREIGN_KEY
The name of a column or columns that you want to declare as a
foreign key in the table you are defining (referencing table).
You cannot declare a computed column as a foreign key.
19.3.19 – FROM pathname
Specifies the repository path name of a repository record
definition. SQL creates the table using the definition from this
record and gives the table the name of the record definition.
You can create a table using the FROM path-name clause only if
the record definition in the repository was originally created
using the repository Common Dictionary Operator (CDO) utility.
For instance, you cannot create a table using the FROM path-name
clause if the record definition was created in the repository as
part of an SQL session.
If the repository record contains a nested record definition, you
cannot create a table based on it.
Creating a table based on a repository record definition is
useful when many applications share the same definition. Changes
to the common definition can be automatically reflected in all
applications that use it.
NOTE
Changes by other users or applications to the record
definition in the repository affect the table definition
once the database is integrated to match the repository
with an INTEGRATE DATABASE . . . ALTER FILES statement. If
those changes include deleting records or fields on which
tables or table columns are based, any data in the dependent
table or table column is lost after the next INTEGRATE
DATABASE . . . ALTER FILES statement executes.
You can use the FROM clause only if the database was attached
specifying PATHNAME. You can specify either a full repository
path name or a relative repository path name.
You cannot define constraints or any other table definition
clauses, such as DATATRIEVE formatting clauses, when you use
the FROM path-name form of the CREATE TABLE statement. This
restriction does not prevent you from using an ALTER TABLE
statement to add them later.
You cannot use the FROM path-name clause when embedding a CREATE
TABLE statement within a CREATE DATABASE statement.
19.3.20 – IDENTITY
Specifies that the column is to be a special read-only identity
column. INSERT will evaluate this column and store a unique value
for each row inserted. Only one column of a table may have the
IDENTITY attribute. Rdb creates a sequence with the same name as
the current table.
See ALTER SEQUENCE and CREATE SEQUENCE for more information.
19.3.21 – increment-by
An integer literal value that specifies the increment for the
sequence created for the IDENTITY column. A negative value
creates a descending sequence, and a positive value creates an
ascending sequence. A value of zero is not permitted. If omitted
the default is 1, that is an ascending sequence.
19.3.22 – INFORMATION
Specifies that the table definition is an information table.
Information tables are reserved for use by Oracle Corporation.
19.3.23 – LIKE other-table-name
Allows a database administrator to copy the metadata for
an existing table and create a new table with similar
characteristics. An optional column list can be used to add extra
columns and contraints to this table. The referenced table must
exist in the same database as the table being created.
Syntax options:
LOGGING | NOLOGGING
The LOGGING clause specifies that the CREATE TABLE statement
should be logged in the recovery-unit journal file (.ruj) and
after-image journal file (.aij).
The NOLOGGING clause specifies that the CREATE TABLE statement
should not be logged in the recovery-unit journal file (.ruj) and
after-image journal file (.aij).
The LOGGING clause is the default.
19.3.24 – NOT_NULL
Restricts values in the column to values that are not null.
19.3.25 – ON_COMMIT
Syntax options:
ON COMMIT PRESERVE ROWS | ON COMMIT DELETE ROWS
Specifies whether data is preserved or deleted after a COMMIT
statement for global or local temporary tables only.
The default, if not specified, is ON COMMIT DELETE ROWS.
19.3.26 – PRIMARY_KEY
A primary key constraint defines one or more columns whose values
make a row in a table different from all others. SQL requires
that values in a primary key column be unique and not null;
therefore, you need not specify the UNIQUE and NOT NULL column
constraints for primary key columns.
You cannot specify the primary key constraint for a computed
column.
When used as a table constraint this clause must be followed by
a list of column names. When used as a column constraint this
clause applies to the named column of the table.
19.3.27 – references-clause
Specifies the name of the column or columns that are a unique
key or primary key or in the referenced table. When the
REFERENCES clause is used as a table constraint, the column names
specified in the FOREIGN KEY clause become a foreign key for the
referencing table.
When used as the column type clause, specifies that the type
of the column be inherited from the PRIMARY KEY or UNIQUE index
referenced. Both the data type and domain are inherited.
19.3.28 – REFERENCES referenced table name
Specifies the name of the table that contains the unique key
or primary key referenced by the referencing table. To declare
a constraint that refers to a unique or primary key in another
table, you must have the SQL REFERENCES or CREATE privileges to
the referenced table.
19.3.29 – referenced-column-name
For a column constraint, the name of the column that is a
unique key or primary key in the referenced table. You cannot
use a computed column as a referenced column name. For a table
constraint, the referenced column name is the name of the column
or columns that are a unique key or primary key in the referenced
table. If you omit the referenced-column-name clause, the primary
key is selected by default. The number of columns and their data
types must match.
19.3.30 – sql-and-dtr-clause
Optional SQL formatting clause.
If you specify a formatting clause for a column that is based on
a domain that also specifies a formatting clause, the formatting
clause in the table definition overrides the one in the domain
definition.
19.3.31 – start-with
An integer literal value that specifies the starting value for
the sequence created for the IDENTITY column. If omitted the
default is 1.
19.3.32 – STORED_NAME_IS
Specifies a name that Oracle Rdb uses to access a table created
in a multischema database. The stored name allows you to access
multischema definitions using interfaces, such as Oracle RMU,
the Oracle Rdb management utility, that do not recognize multiple
schemas in one database. You cannot specify a stored name for
a table in a database that does not allow multiple schemas. For
more details about stored names, see the User_Supplied_Names HELP
topic.
19.3.33 – table-constraint
A constraint definition that applies to the whole table.
SQL allows column constraints and table constraints. The four
types of table constraints are PRIMARY KEY, UNIQUE, CHECK, and
FOREIGN KEY constraints.
A column must be defined in a table before you can specify the
column in a table constraint definition.
You can define a table constraint on persistent base tables and
global temporary tables only.
19.3.34 – table-name
The name of the table definition you want to create. Use a name
that is unique among all table, sequence, view and synonym names
in the database, or in the schema if you are using a multischema
database. Use any valid SQL name. (See the User_Supplied_Names
HELP topic for more information on user-supplied names.)
19.3.35 – temporary_tables
Syntax options:
CREATE GLOBAL TEMPORARY TABLE | CREATE LOCAL TEMPORARY TABLE
Specifies that the table definition is either a global or local
temporary table.
19.3.36 – UNIQUE
Specifies that values in the associated column must be unique.
You can use either the UNIQUE or PRIMARY KEY keywords to define
one or more columns as a unique key for a table.
You cannot specify the UNIQUE constraint for a computed column or
for a column defined with the LIST OF BYTE VARYING data type.
19.4 – Examples
Example 1: Creating new tables with primary and foreign keys
In this example, the CREATE TABLE statement is used to create
the EMPLOYEES_2, SALARY_HISTORY_2, and WORK_STATUS_2 tables in
the personnel database. It specifies column definitions based on
domain definitions for the entire database.
The FOREIGN KEY constraint specified in the SALARY_HISTORY_2
table must match the PRIMARY KEY constraint specified in the
EMPLOYEES_2 table.
Note also that the CHECK constraint specified is a table
constraint because it is separated by commas from the column to
which it refers. In this case, a column constraint on EMPLOYEE_ID
would have the same effect because it refers only to the single
column EMPLOYEE_ID.
Because the dialect is SQL99, the default for constraint
evaluation time is NOT DEFERRABLE.
SQL> -- *** Set Dialect ***
SQL> --
SQL> SET DIALECT 'SQL99';
SQL> --
SQL> -- *** Create tables ***
SQL> --
SQL> CREATE TABLE WORK_STATUS_2
cont> (
cont> STATUS_CODE STATUS_CODE_DOM
cont> CONSTRAINT WS2_STATUS_CODE_PRIMARY
cont> PRIMARY KEY,
cont> STATUS_NAME STATUS_NAME_DOM,
cont> STATUS_TYPE STATUS_DESC_DOM
cont> );
SQL> --
SQL> CREATE TABLE EMPLOYEES_2
cont> (
cont> EMPLOYEE_ID ID_DOM
cont> CONSTRAINT E2_EMPLOYEE_ID_PRIMARY
cont> PRIMARY KEY,
cont> LAST_NAME LAST_NAME_DOM,
cont> FIRST_NAME FIRST_NAME_DOM,
cont> MIDDLE_INITIAL MIDDLE_INITIAL_DOM,
cont> ADDRESS_DATA_1 ADDRESS_DATA_1_DOM,
cont> ADDRESS_DATA_2 ADDRESS_DATA_2_DOM,
cont> CITY CITY_DOM,
cont> STATE STATE_DOM,
cont> POSTAL_CODE POSTAL_CODE_DOM,
cont> SEX SEX_DOM
cont> CONSTRAINT EMPLOYEE_SEX_VALUES
cont> CHECK (
cont> SEX IN ('M', 'F') OR SEX IS NULL
cont> ),
cont> BIRTHDAY DATE_DOM,
cont> STATUS_CODE STATUS_CODE_DOM
cont> CONSTRAINT E2_STATUS_CODE_FOREIGN
cont> REFERENCES WORK_STATUS_2 (STATUS_CODE),
cont> CONSTRAINT EMP_STATUS_CODE_VALUES_2
cont> CHECK (
cont> STATUS_CODE IN ('0', '1', '2')
cont> OR STATUS_CODE IS NULL
cont> )
cont> );
SQL> --
SQL> CREATE TABLE SALARY_HISTORY_2
cont> (
cont> EMPLOYEE_ID ID_DOM
cont> CONSTRAINT SH2_EMPLOYEES_ID_FOREIGN
cont> REFERENCES EMPLOYEES_2 (EMPLOYEE_ID),
cont> SALARY_AMOUNT SALARY_DOM,
cont> SALARY_START DATE_DOM,
cont> SALARY_END DATE_DOM
cont> );
SQL>
Example 2: Creating a table with many SQL data types
The following example is an excerpt from the sample program sql_
all_datatypes created during installation of Oracle Rdb in the
Samples directory. For a variety of languages, sql_all_datatypes
illustrates how you declare program variables to match a variety
of data types, and how you can specify those variables in SQL
statements when you store and retrieve column values or null
values.
This example shows the CREATE TABLE statement from the sql_all_
datatypes program.
EXEC SQL CREATE TABLE ALL_DATATYPES_TABLE
(
CHAR_COL CHAR(10),
SMALLINT_COL SMALLINT,
SMALLINT_SCALED_COL SMALLINT (3),
INTEGER_COL INTEGER,
INTEGER_SCALED_COL INTEGER (2),
QUADWORD_COL QUADWORD,
QUADWORD_SCALED_COL QUADWORD (5),
REAL_COL REAL,
DOUBLE_PREC_COL DOUBLE PRECISION,
DATE_COL DATE,
VARCHAR_COL VARCHAR(40)
);
Example 3: Specifying default values for columns
The following example illustrates the use of default values
for columns. Each salesperson enters his or her own daily sales
information into the DAILY_SALES table.
SQL> --
SQL> CREATE TABLE DAILY_SALES
cont> --
cont> -- The column SALESPERSON is based on LAST_NAME_DOM and
cont> -- the default value is the user name of the person who
cont> -- enters the information:
cont> (SALESPERSON LAST_NAME_DOM DEFAULT USER,
cont> --
cont> -- Typical work day is 8 hours:
cont> HOURS_WORKED SMALLINT DEFAULT 8,
cont> HOURS_OVERTIME SMALLINT,
cont> GROSS_SALES INTEGER );
SQL> --
SQL> -- Insert daily sales information accepting the
SQL> -- default values for SALESPERSON and HOURS_WORKED:
SQL> --
SQL> INSERT INTO DAILY_SALES
cont> (HOURS_OVERTIME, GROSS_SALES )
cont> VALUES
cont> (1, 2499.00);
1 row inserted
SQL> SELECT * FROM DAILY_SALES;
SALESPERSON HOURS_WORKED HOURS_OVERTIME GROSS_SALES
KILPATRICK 8 1 2499
1 row selected
Example 4: Violating a constraint indirectly with the DELETE
statement
Constraints prevent INSERT statements from adding rows to a table
that do not satisfy conditions specified in the constraint.
Constraints also prevent DELETE or UPDATE statements from
deleting or changing values in a table if the deletion or change
violates the constraint on another table in the database. The
following example illustrates that point:
SQL> -- TEST has no constraints defined for it, but it is subject to
SQL> -- restrictions nonetheless because of the constraint specified
SQL> -- in TEST2:
SQL> CREATE TABLE TEST
cont> (COL1 REAL);
SQL>
SQL> CREATE TABLE TEST2
cont> (COL1 REAL,
cont> CHECK (COL1 IN
cont> (SELECT COL1 FROM TEST))
cont> );
SQL> COMMIT;
SQL>
SQL> INSERT INTO TEST VALUES (1);
1 row inserted
SQL> INSERT INTO TEST2 VALUES (1);
1 row inserted
SQL> COMMIT;
SQL> -- This DELETE statement will fail because it will cause COL1 in
SQL> -- TEST2 to contain a value without the same value in COL1 of TEST:
SQL> DELETE FROM TEST WHERE COL1 = 1;
1 row deleted
SQL> COMMIT;
%RDB-E-INTEG_FAIL, violation of constraint TEST2_CHECK1 caused operation to
fail
Example 5: Evaluating constraints at verb time
Deferrable constraints are not evaluated until a transaction
issues a COMMIT statement. You can specify that constraints be
evaluated more frequently with the EVALUATING clause of the SET
TRANSACTION statement.
SQL> create table TEST
cont> (col1 integer,
cont> col2 integer
cont> constraint C2
cont> unique
cont> deferrable
cont> );
SQL>
SQL> insert into TEST (col1, col2) values (1, 2);
1 row inserted
SQL> commit;
SQL>
SQL> /*
***> This INSERT will violate the constraint as shown by
***> the error during COMMIT
***> */
SQL> insert into TEST (col1, col2) values (1, 2);
1 row inserted
SQL> commit;
%RDB-E-INTEG_FAIL, violation of constraint C2 caused operation to fail
-RDB-F-ON_DB, on database USER_DISK:[DOC.DATABASES]MF_PERSONNEL.RDB;1
SQL> /*
***> The COMMIT failed, so we will ROLLBACK
***> */
SQL> rollback;
SQL>
SQL> /*
***> You can change the evalution time using the EVALUATING
***> clause of SET TRANSACTION
***> */
SQL> set transaction read write evaluating C2 at verb time;
SQL> insert into TEST (col1, col2) values (1, 2);
%RDB-E-INTEG_FAIL, violation of constraint C2 caused operation to fail
-RDB-F-ON_DB, on database USER_DISK:[DOC.DATABASES]MF_PERSONNEL.RDB;1
SQL> rollback;
20 – TRIGGER
Creates triggers for a specified table. A trigger defines the
actions to occur before or after the table is updated (by a write
operation such as an INSERT, DELETE, or UPDATE statement). The
trigger is associated with a single table, takes effect at a
specific time for a particular type of update, and causes one or
more triggered actions to be performed. If the trigger specifies
multiple actions, each action is performed in the order in which
it appears within the trigger definition.
With triggers, you can define useful actions such as:
o Cascading deletes
Deleting a row from one table causes additional rows to be
deleted from other tables that are related to the first table
by key values.
o Cascading updates
Updating a row in one table causes additional rows to be
updated in other tables that are related to the first table
by key values. These updates are commonly limited to the key
fields themselves.
o Summation updates
Updating a row from one table causes a value in a row of
another table to be updated by being increased or decreased.
o Hidden deletes
Causing rows to be deleted from a table by moving them to a
parallel table that is not otherwise used by the database.
NOTE
Combinations of table-specific constraints and appropriately
defined triggers, by themselves, are not sufficient to
guarantee that database integrity is preserved when the
database is updated. If integrity is to be preserved,
table-specific constraints and triggers must be used in
conjunction with a common set of update procedures that
ensure completely reproducible and consistent retrieval and
update strategies.
The CREATE TRIGGER statement adds the trigger definition to the
physical database.
A triggered action consists of an optional predicate and some
triggered statements. If specified, the predicate must evaluate
to true for the triggered statements in the action to execute.
Each triggered statement is executed in the order in which it
appears within the triggered action clause.
The triggered statement can be:
o A DELETE statement
o An UPDATE statement
o An INSERT statement
o A CALL statement
o A SIGNAL statement
o A TRACE statement
o An ERROR statement
20.1 – Environment
You can use the CREATE TRIGGER statement:
o In interactive SQL
o Embedded in host language programs to be precompiled
o As part of a procedure in an SQL module
o In dynamic SQL as a statement to be dynamically executed
20.2 – Format
CREATE TRIGGER --> <trigger-name> ------+
+---------------------------------------+
+-+-----------------------------------+-+
+-> STORED NAME IS <stored-name> ---+ |
+------------------<--------------------+
++-> BEFORE -+-+-> INSERT --------------------------------+-+
+-> AFTER --+ +-> DELETE --------------------------------+ |
+-> UPDATE --+--------------------------+--+ |
+--> OF -+> <column-name> ++ |
+--- , <---------+ |
+----------------------------<------------------------------+
+-> ON <table-name> +-----------------------++-> triggered-action -+>
+-> referencing-clause -++----------<----------+
referencing-clause =
REFERENCING -++-> OLD AS --> <old-correlation-name> -++->
|+-> NEW AS --> <new-correlation-name> -+|
+------------------<---------------------+
triggered-action =
--+---------------------+-> ( -+> triggered-statement -+-> ) -+
+-> WHEN (predicate) -+ +----------- , <--------+ |
+----------- ; <--------+ |
+---------------------------<------------------------------+
+-+------------------------+------------------------------->
+-> FOR EACH ROW --------+
+-> FOR EACH STATEMENT --+
triggered-statement =
--+-> call-statement ---+-->
+-> delete-statement -+
+-> ERROR ------------+
+-> insert-statement -+
+-> signal-statement -+
+-> trace-statement --+
+-> update-statement -+
20.3 – Arguments
20.3.1 – call-statement
Specifies the stored procedure to invoke. You can only call
procedures with IN parameters. Operations on the triggering table
are not permitted due to possible side effects and recursive
calls.
20.3.2 – column-name
The name of a column within the specified table to be checked for
deletion, modification, or insertion. Use this argument only with
UPDATE triggers.
20.3.3 – delete-statement
Specifies the row of a table that you want to delete. If you
specify CURRENT OF cursor-name with the WHERE clause of the
DELETE statement, you receive an error message because the cursor
is not visible to the CREATE TRIGGER statement.
20.3.4 – ERROR
Provides the following message:
RDMS-E-TRIG_ERROR, Trigger 'trigger_name' forced an error.
A triggered ERROR statement cancels the DELETE, UPDATE, or INSERT
statement that invoked the trigger.
20.3.5 – FOR_EACH
Syntax options:
FOR EACH ROW | FOR EACH STATEMENT
Specifies whether the triggered action is evaluated once per
triggering statement, or for each row of the subject table that
is affected by the triggering statement.
If you specify FOR EACH STATEMENT, then the triggered action
is evaluated only once, and row values are not available to the
triggered action.
The FOR EACH STATEMENT clause is the default.
20.3.6 – insert-statement
Specifies the new row or rows you want to add to a table.
20.3.7 – old-correlation-name
A temporary name used to refer to the row values as they existed
before an UPDATE operation occurred. If you do not specify the
FOR EACH ROW clause, this correlation name cannot be referred to
in the triggered statement.
20.3.8 – new-correlation-name
A temporary name used to refer to the new row values to be
applied by the UPDATE operation. If you do not specify the FOR
EACH ROW clause, this correlation name cannot be referred to in
the triggered statement.
20.3.9 – referencing-clause
Lets you specify whether you want to refer to the row values as
they existed before an UPDATE operation occurred or the new row
values after they are applied by the UPDATE operation. Do not use
this clause with INSERT or DELETE operations.
You can specify each option (OLD AS old-correlation-name or NEW
AS new-correlation-name) only once in the referencing clause.
20.3.10 – signal-statement
Specifies that the signaled SQLSTATE status parameter is to be
passed back to the application or SQL interface and that the
current routine and all calling routines are to be terminated.
This provides a more complete error mechanism than is provided by
the ERROR clause.
20.3.11 – STORED_NAME_IS
Specifies a name that Oracle Rdb uses to access a trigger created
in a multischema database. The stored name allows you to access
multischema definitions using interfaces, such as Oracle RMU,
the Oracle Rdb management utility, that do not recognize multiple
schemas in one database. You cannot specify a stored name for a
trigger in a database that does not allow multiple schemas. For
more information on stored names, see the User_Supplied_Names
HELP topic.
20.3.12 – table-name
The name of the table for which this trigger is defined.
20.3.13 – trace-statement
Allows applications to add triggers to log information when trace
logging is active.
20.3.14 – triggered-action
Consists of an optional predicate, some triggered statements, and
an optional frequency clause. If specified, the predicate must
evaluate to true for the triggered statements in the triggered
action clause to execute. Each triggered statement is executed in
the order in which it appears within the triggered action clause.
20.3.15 – triggered-statement
Updates the database or generates an error message.
20.3.16 – update-statement
Specifies the row of a table that you want to modify. If you
specify CURRENT OF cursor-name with the WHERE clause of the
UPDATE statement, you receive an error message because the cursor
is not visible to the CREATE TRIGGER statement.
20.3.17 – WHEN predicate
Describes the optional condition that must be satisfied before
the associated triggered statements are executed. This predicate
cannot refer to any host language variable.
To avoid ambiguity between columns and external function
callouts, use parentheses around the predicate in the WHEN
clause.
20.4 – Examples
Example 1: Defining a cascading delete trigger
The following SQL procedure shows a trigger from the sample
personnel database that deletes rows in several tables before
deleting a row in the EMPLOYEES table. Each associated employee
row (from the tables that have foreign keys referring to the
primary key in the employee row) is deleted. The employee
identification number being deleted (00164) belongs to an
employee who is also a manager; therefore, the MANAGER_ID column
in the DEPARTMENTS table is set to null, as specified by the
trigger.
SQL> SET TRANSACTION READ WRITE;
SQL> --
SQL> -- Display the EMPLOYEE_ID_CASCADE_DELETE trigger
SQL> -- in the sample database:
SQL> --
SQL> SHOW TRIGGER EMPLOYEE_ID_CASCADE_DELETE
EMPLOYEE_ID_CASCADE_DELETE
Source:
EMPLOYEE_ID_CASCADE_DELETE
BEFORE DELETE ON EMPLOYEES
(DELETE FROM DEGREES D WHERE D.EMPLOYEE_ID =
EMPLOYEES.EMPLOYEE_ID)
FOR EACH ROW
(DELETE FROM JOB_HISTORY JH WHERE JH.EMPLOYEE_ID =
EMPLOYEES.EMPLOYEE_ID)
FOR EACH ROW
(DELETE FROM SALARY_HISTORY SH WHERE SH.EMPLOYEE_ID =
EMPLOYEES.EMPLOYEE_ID)
FOR EACH ROW
! Also, if an employee is terminated and that employee
! is the manager of a department, set the manager_id
! null for that department.
(UPDATE DEPARTMENTS D SET D.MANAGER_ID = NULL
WHERE D.MANAGER_ID = EMPLOYEES.EMPLOYEE_ID)
FOR EACH ROW
SQL> --
SQL> -- The EMPLOYEES table has a value of '00164'
SQL> -- in the EMPLOYEE_ID column:
SQL> --
SQL> SELECT * FROM EMPLOYEES E WHERE E.EMPLOYEE_ID = '00164';
EMPLOYEE_ID LAST_NAME FIRST_NAME MIDDLE_INITIAL
ADDRESS_DATA_1 ADDRESS_DATA_2 CITY
STATE POSTAL_CODE SEX BIRTHDAY STATUS_CODE
00164 Toliver Alvin A
146 Parnell Place Chocorua
NH 03817 M 28-Mar-1947 1
1 row selected
SQL> --
SQL> --
SQL> -- The DEGREES table has two values of '00164'
SQL> -- in the EMPLOYEE_ID column:
SQL> --
SQL> SELECT * FROM DEGREES D WHERE D.EMPLOYEE_ID = '00164';
EMPLOYEE_ID COLLEGE_CODE YEAR_GIVEN DEGREE DEGREE_FIELD
00164 PRDU 1973 MA Applied Math
00164 PRDU 1982 PhD Statistics
2 rows selected
SQL> --
SQL> --
SQL> -- The JOB_HISTORY table has the value of '00164' in
SQL> -- several rows in the EMPLOYEE_ID column:
SQL> --
SQL> SELECT * FROM JOB_HISTORY JH WHERE JH.EMPLOYEE_ID = '00164';
EMPLOYEE_ID JOB_CODE JOB_START JOB_END DEPARTMENT_CODE
SUPERVISOR_ID
00164 DMGR 21-Sep-1981 NULL MBMN
00228
00164 SPGM 5-Jul-1980 20-Sep-1981 MCBM
00164
2 rows selected
SQL> --
SQL> --
SQL> -- The SALARY_HISTORY table has a value of '00164'
SQL> -- in several rows in the EMPLOYEE_ID column:
SQL> --
SQL> SELECT * FROM SALARY_HISTORY SH WHERE SH.EMPLOYEE_ID = '00164';
EMPLOYEE_ID SALARY_AMOUNT SALARY_START SALARY_END
00164 $26,291.00 5-Jul-1980 2-Mar-1981
00164 $51,712.00 14-Jan-1983 NULL
00164 $26,291.00 2-Mar-1981 21-Sep-1981
00164 $50,000.00 21-Sep-1981 14-Jan-1983
4 rows selected
SQL> --
SQL> --
SQL> -- The DEPARTMENTS table has a value of '00164'
SQL> -- in the MANAGER_ID column:
SQL> --
SQL> SELECT * FROM DEPARTMENTS D WHERE D.MANAGER_ID = '00164';
DEPARTMENT_CODE DEPARTMENT_NAME MANAGER_ID
BUDGET_PROJECTED BUDGET_ACTUAL
MBMN Board Manufacturing North 00164
NULL NULL
1 row selected
SQL> --
SQL> --
SQL> -- Test the trigger by deleting the row with a value of '00164'
SQL> -- in the EMPLOYEE_ID column from the EMPLOYEES table:
SQL> --
SQL> DELETE FROM EMPLOYEES E WHERE E.EMPLOYEE_ID = '00164';
1 row deleted
SQL> --
SQL> -- The row with a value of '00164' in the EMPLOYEE_ID column
SQL> -- was deleted from the EMPLOYEES table:
SQL> --
SQL> SELECT * FROM EMPLOYEES E WHERE E.EMPLOYEE_ID = '00164';
0 rows selected
SQL> --
SQL> -- The rows with a value of '00164' in the EMPLOYEE_ID column
SQL> -- were deleted from the DEGREES table:
SQL> --
SQL> SELECT * FROM DEGREES D WHERE D.EMPLOYEE_ID = '00164';
0 rows selected
SQL> --
SQL> -- The rows with a value of '00164' in the EMPLOYEE_ID
SQL> -- column were deleted from the JOB_HISTORY table:
SQL> --
SQL> SELECT * FROM JOB_HISTORY JH WHERE JH.EMPLOYEE_ID = '00164';
0 rows selected
SQL> --
SQL> -- The rows with a value of '00164' in the EMPLOYEE_ID
SQL> -- column were deleted from the SALARY_HISTORY table:
SQL> --
SQL> SELECT * FROM SALARY_HISTORY SH WHERE SH.EMPLOYEE_ID = '00164';
0 rows selected
SQL> --
SQL> -- The value of '00164' in the MANAGER_ID column was set to null
SQL> -- in the DEPARTMENTS table:
SQL> --
SQL> SELECT * FROM DEPARTMENTS D WHERE D.DEPARTMENT_CODE = 'MBMN';
DEPARTMENT_CODE DEPARTMENT_NAME MANAGER_ID
BUDGET_PROJECTED BUDGET_ACTUAL
MBMN Board Manufacturing North NULL
NULL NULL
1 row selected
SQL> --
SQL> ROLLBACK;
Example 2: Defining a trigger that performs an update
Before the STATUS_CODE column in WORK_STATUS table is updated,
the STATUS_CODE_CASCADE_UPDATE trigger in the following SQL
procedure updates the associated rows in the EMPLOYEES table. The
REFERENCING clause specifies OLD_WORK_STATUS as the correlation
name for the values in the WORK_STATUS table before the UPDATE
statement executes, and NEW_WORK_STATUS as the correlation
name for the values in the WORK_STATUS table after the UPDATE
statement executes.
SQL> -- Display the STATUS_CODE_CASCADE_UPDATE trigger in
SQL> -- the sample database:
SQL> --
SQL> SHOW TRIGGER STATUS_CODE_CASCADE_UPDATE
STATUS_CODE_CASCADE_UPDATE
Source:
STATUS_CODE_CASCADE_UPDATE
BEFORE UPDATE OF STATUS_CODE ON WORK_STATUS
REFERENCING OLD AS OLD_WORK_STATUS
NEW AS NEW_WORK_STATUS
(UPDATE EMPLOYEES E
SET E.STATUS_CODE = NEW_WORK_STATUS.STATUS_CODE
WHERE E.STATUS_CODE = OLD_WORK_STATUS.STATUS_CODE)
FOR EACH ROW
SQL> --
SQL> -- Change the STATUS_CODE column with a value of 2 to a value of 3:
SQL> --
SQL> UPDATE WORK_STATUS WS SET STATUS_CODE="3" WHERE STATUS_CODE="2";
1 row updated
SQL> --
SQL> -- The trigger changes any STATUS_CODE column in the EMPLOYEES table
SQL> -- with a value of 2 to a value of 3. Therefore, no rows are
SQL> -- selected for the first query that follows, but several are selected
SQL> -- for the second query:
SQL> --
SQL> SELECT * FROM EMPLOYEES E WHERE E.STATUS_CODE = "2";
0 rows selected
SQL> --
SQL> SELECT * FROM EMPLOYEES E WHERE E.STATUS_CODE = "3";
EMPLOYEE_ID LAST_NAME FIRST_NAME MIDDLE_INITIAL
ADDRESS_DATA_1 ADDRESS_DATA_2 CITY
STATE POSTAL_CODE SEX BIRTHDAY STATUS_CODE
00165 Smith Terry D
120 Tenby Dr. Chocorua
NH 03817 M 15-May-1954 3
00178 Goldstone Neal NULL
194 Lyons Av, Colebrook
NH 03576 M 25-Apr-1952 3
.
.
.
00358 Lapointe Jo Ann C
70 Tenby Dr. Chocorua
NH 03817 F 24-Feb-1931 3
12 rows selected
SQL> --
SQL> ROLLBACK;
Example 3: Defining a trigger that updates a sales summary
The following example defines a trigger that updates a monthly
sales total after each daily sale is made.
SQL> --
SQL> -- Create the table to keep track of monthly sales:
SQL> CREATE TABLE MONTHLY_SALES
cont> ( SALES_AMOUNT INTEGER);
SQL> --
SQL> -- Create the table to keep track of sales made today:
SQL> CREATE TABLE DAILY_SALES
cont> ( SALES_AMOUNT INTEGER);
SQL> --
SQL> -- Assume that $250.00 of sales have been made during the current month:
SQL> INSERT INTO MONTHLY_SALES
cont> (SALES_AMOUNT) VALUES (250);
1 row inserted
SQL> --
SQL> -- After adding a new value to the SALES_AMOUNT column in
SQL> -- DAILY_SALES table, SQL updates the SALES column in
SQL> -- the MONTHLY_SALES table with the amount of the new sale:
SQL> CREATE TRIGGER UPDATE_SALES_TOTAL_ON_NEW_SALE
cont> AFTER INSERT ON DAILY_SALES
cont> (UPDATE MONTHLY_SALES M
cont> SET M.SALES_AMOUNT = M.SALES_AMOUNT + DAILY_SALES.SALES_AMOUNT)
cont> FOR EACH ROW;
SQL> --
SQL> -- The following statement records a new $5.00 sale for today:
SQL> INSERT INTO DAILY_SALES
cont> (SALES_AMOUNT) VALUES (5);
1 row inserted
SQL> --
SQL> -- The value for the SALES_AMOUNT column of the DAILY_SALES table
SQL> -- is $5.00 and the value of the SALES_AMOUNT column of the
SQL> -- MONTHLY_SALES table is $255.00:
SQL> SELECT * FROM DAILY_SALES;
SALES_AMOUNT
5
1 row selected
SQL> --
SQL> SELECT * FROM MONTHLY_SALES;
SALES_AMOUNT
255
1 row selected
SQL> --
SQL> -- When a new $9.00 sale is made, the values in the two rows of the
SQL> -- SALES_AMOUNT column of the DAILY_SALES table are $5.00 and $9.00
SQL> -- and the value of the SALES_AMOUNT column of the MONTHLY_SALES
SQL> -- table is $264.00:
SQL> INSERT INTO DAILY_SALES
cont> (SALES_AMOUNT) VALUES (9);
1 row inserted
SQL> --
SQL> SELECT * FROM DAILY_SALES;
SALES_AMOUNT
5
9
2 rows selected
SQL> --
SQL> SELECT * FROM MONTHLY_SALES;
SALES_AMOUNT
264
1 row selected
SQL> --
SQL> ROLLBACK;
SQL> --
Example 4: Defining a trigger that sets column values to null
Before the STATUS_CODE column in the WORK_STATUS table is
deleted, this trigger causes the associated WORK_STATUS columns
in the EMPLOYEES table to be set to null.
SQL> CREATE TRIGGER STATUS_CODE_ON_DELETE_SET_NULL
cont> BEFORE DELETE ON WORK_STATUS
cont> (UPDATE EMPLOYEES E SET E.STATUS_CODE = NULL
cont> WHERE E.STATUS_CODE = WORK_STATUS.STATUS_CODE)
cont> FOR EACH ROW;
SQL> --
SQL> -- Delete any row in the WORK_STATUS table where the STATUS_CODE
SQL> -- column has a value of 1:
SQL> DELETE FROM WORK_STATUS WS WHERE WS.STATUS_CODE = "1";
1 row deleted
SQL> --
SQL> -- This trigger sets the STATUS_CODE column value to null in many
SQL> -- rows in the EMPLOYEES table:
SQL> SELECT * FROM EMPLOYEES E WHERE E.STATUS_CODE IS NULL;
EMPLOYEE_ID LAST_NAME FIRST_NAME MIDDLE_INITIAL
ADDRESS_DATA_1 ADDRESS_DATA_2 CITY
STATE POSTAL_CODE SEX BIRTHDAY STATUS_CODE
00416 Ames Louie A
61 Broad st. NULL Alton
NH 03809 M 13-Apr-1941 NULL
00374 Andriola Leslie Q
111 Boston Post Rd. NULL Salisbury
NH 03268 M 19-Mar-1955 NULL
.
.
.
00200 Ziemke Al F
121 Putnam Hill Rd. NULL Winnisquam
NH 03289 M 27-Oct-1928 NULL
88 rows selected
SQL> ROLLBACK;
Example 5: Defining a trigger that prevents deletion of a row
that exists in two tables
Suppose that a user wants to delete only those rows in the JOB_
HISTORY table that do not also exist in the JOBS table. This is
difficult to do with constraints because a row can exist in one
table with a key number that does not exist in the other table.
The following statement creates a trigger that causes an error
when the user tries to delete a row that exists in table JOB_
HISTORY.
SQL> CREATE TRIGGER DELETE_GUARD
cont> BEFORE DELETE ON JOB_HISTORY
cont> WHEN EXISTS (SELECT JOBS.JOB_CODE FROM JOBS
cont> WHERE JOBS.JOB_CODE=JOB_HISTORY.JOB_CODE)
cont> (ERROR) FOR EACH ROW;
SQL> --
SQL> -- Now attempt a deletion that violates the trigger.
SQL> --
SQL> DELETE FROM JOB_HISTORY WHERE JOB_CODE = 'DMGR';
%RDB-E-TRIG_INV_UPD, invalid update; encountered error condition
defined for trigger
-RDMS-E-TRIG_ERROR, trigger DELETE_GUARD forced an error
-RDB-F-ON_DB, on database DISK1:[DEPT3.SQL]MF_PERSONNEL.RDB;1
Example 6: Defining a trigger that saves audit information
SQL> -- Create new table to record changes made to
SQL> -- EMPLOYEES table
SQL> CREATE TABLE AUDIT_TRAIL
cont> (LOG DATE VMS,
cont> PERSON CHAR(31),
cont> TBL_NAME CHAR(10),
cont> OPER CHAR(1));
SQL> COMMIT;
SQL> -- Create a trigger so that each time
SQL> -- an INSERT operation is performed,
SQL> -- a record is stored in the AUDIT_TRAIL table.
SQL> CREATE TRIGGER EMPS_TRIGGER
cont> AFTER INSERT
cont> ON EMPLOYEES
cont> (INSERT INTO AUDIT_TRAIL
cont> VALUES (CURRENT_TIMESTAMP,
cont> CURRENT_USER, 'EMPLOYEES', 'I'))
cont> FOR EACH STATEMENT;
SQL> -- The AUDIT_TRAIL table currently has no records.
SQL> SELECT * FROM AUDIT_TRAIL;
0 rows selected
SQL> -- Insert a record into EMPLOYEES
SQL> INSERT INTO EMPLOYEES
cont> (EMPLOYEE_ID, LAST_NAME)
cont> VALUES ('00964', 'FRENCH');
1 row inserted
SQL> -- See if trigger updated the AUDIT_TRAIL table.
SQL> SELECT * FROM AUDIT_TRAIL;
LOG PERSON TBL_NAME OPER
17-JUN-2003 15:04:31.43 STEWART EMPLOYEES I
1 row selected
Example 7: Using TRACE as a trigger action
SQL> set flags 'TRACE';
SQL> create table M_TABLE (a integer, b integer);
SQL>
SQL> create trigger T_A
cont> after insert on M_TABLE
cont> (trace 'in a trigger: ' || cast(M_TABLE.a as varchar(10)))
cont> for each row;
SQL>
SQL> insert into M_TABLE (a, b) values (1, 10);
~Xt: in a trigger: 1
1 row inserted
SQL>
Example 8: Using SIGNAL as a trigger action
SQL> create table M_TABLE (a integer, b integer);
SQL>
SQL> create trigger T_A
cont> after insert on M_TABLE2
cont> when (M_TABLE2.a is not null)
cont> (signal '12345' ('in a trigger: '
cont> || cast(M_TABLE2.a as varchar(10))))
cont> for each row;
SQL>
SQL> insert into M_TABLE2 (a, b) values (1, 10);
%RDB-E-SIGNAL_SQLSTATE, routine "T_A" signaled SQLSTATE "12345"
-RDB-I-TEXT, in a trigger: 1
SQL>
Example 9: Using CALL as a trigger action
SQL> create module M_MODULE
cont> language SQL
cont>
cont> procedure M_K (in :a int);
cont> trace 'called from a trigger: ' || cast(:a as varchar(10));
cont>
cont> end module;
SQL>
SQL> create table M_TABLE (a integer, b integer);
SQL>
SQL> create trigger T_A
cont> after insert on M_TABLE
cont> (call M_K (M_TABLE.a))
cont> for each row;
SQL>
SQL> insert into M_TABLE (a, b) values (1, 10);
~Xt: called from a trigger: 1
1 row inserted
SQL>
21 – USER
Creates a special security profile entry to identify a database
user. That user can be granted roles, which in turn provide
access to database objects.
21.1 – Environment
You can use the CREATE USER statement:
o In interactive SQL
o Embedded in host language programs
o As part of a procedure in an SQL module or other compound
statement
o In dynamic SQL as a statement to be dynamically executed
21.2 – Format
CREATE USER --+---> <username> ----> IDENTIFIED EXTERNALLY --+-----+
+---> PUBLIC ----------------------------------+ |
+------------------------------------------------------------------+
+-------------+-------------------------------+-------------------->
+---> create-user-opts ---------+
create-user-opts =
-+-> ACCOUNT --+->LOCK ---+---------------------+-->
| +->UNLOCK -+ |
+-> COMMENT IS -+-> '<string>' --+-------------+
| +------- / <-----+ |
+-> NO PROFILE -------------------------------+
+-> PROFILE <profile_name> --------------------+
21.3 – Arguments
21.3.1 – ACCOUNT lock-option
Syntax options:
ACCOUNT LOCK | ACCOUNT UNLOCK
The ACCOUNT LOCK clause disables access to the database by the
user for whom the CREATE USER statement is being applied. The
ACCOUNT UNLOCK clause allows that user access to the database.
The ACCOUNT UNLOCK clause is the default.
21.3.2 – COMMENT IS 'string'
Adds a comment about the user. SQL displays the text of the
comment when it executes a SHOW USERS statement. Enclose the
comment in single quotation marks (') and separate multiple lines
in a comment with a slash mark (/).
21.3.3 – IDENTIFIED_EXTERNALLY
Indicates that the user will be authenticated through the
operating system.
21.3.4 – PROFILE
Syntax options:
PROFILE | NOPROFILE
Identifies a new profile for assignment to the user. The
specified profile name must be the name of an existing profile.
NOPROFILE is the default behavior and indicates that no special
restrictions are applied to this user.
21.3.5 – PUBLIC
Explicitly creates a PUBLIC security profile entry in the
database.
21.3.6 – username
The name of the user to add to the database. This must match the
name of an existing OpenVMS username.
21.4 – Examples
Example 1: Creating a New User and Locking Her Account
SQL> CREATE USER munroy IDENTIFIED EXTERNALLY
cont> ACCOUNT LOCK
cont> COMMENT IS 'User munroy starts job on'/
cont> 'May 1, 2003. Unlock when she starts';
Example 2: Adding a profile to a user
This example creates a new profile that defines the DEFAULT
transaction and then assigns a profile while creating a new user.
The next time the user attaches to the database the START DEFAULT
TRANSACTION statement will use the defined profile instead of the
standard READ ONLY default.
SQL> create profile READ_COMMITTED
cont> default transaction read write isolation level read committed wait 30;
SQL> show profile READ_COMMITTED
READ_COMMITTED
Default transaction read write wait 30
Isolation level read committed
SQL> create user JAIN identified externally profile READ_COMMITTED;
SQL> show user JAIN;
JAIN
Identified externally
Account is unlocked
Profile: READ_COMMITTED
No roles have been granted to this user
22 – VIEW
Creates a view definition. A view is a logical structure that
refers to rows stored in other tables. Data in a view is not
physically stored in the database. You can include in a view
definition combinations of rows and columns from other tables and
view definitions in the schema. You define a view by specifying a
select expression, that:
o Names the criteria for selecting the tables, rows, and columns
for the view
o Specifies a set of columns from those tables
When the CREATE VIEW statement executes, SQL adds the view
definition to the physical database. If you declared the schema
with the PATHNAME argument, the definition is also stored in the
repository.
22.1 – Environment
You can use the CREATE VIEW statement:
o In interactive SQL
o Embedded in host language programs to be precompiled
o As part of a procedure in an SQL module
o In dynamic SQL as a statement to be dynamically executed
22.2 – Format
CREATE VIEW --> <view-name> -------------------------+
+--------------------------------------------------+
++-----------------------------------+-------------+
+-> STORED NAME IS <stored-name> ---+ |
+----------------------------------------------------+
++------------------------>------------------------+-+
+-> ( -+-> <column-name> -+--------------+-+-> ) -+ |
| +----------------+ | | |
| ++-+------------------------+-+-+ | |
| | +-> sql-and-dtr-clause --+ | | |
| +-------------<--------------+ | |
+----------------- , <--------------+ |
+----------------------------------------------------+
+-> AS select-expr ---+------------------------+-->
+-> check-option-clause -+
select-expr =
-+-+-> select-clause ------------+-+------+
| +-> ( select-expr ) -----------+ | |
| +-> TABLE table-ref ----------+ | |
+------ select-merge-clause <-------+ |
+------------------- <-------------------+
+-+--------------------+--+------------------+--+--------------------+->
+-> order-by-clause -+ +-> offset-clause -+ +-> limit-to-clause -+
sql-and-dtr-clause =
-+-> QUERY HEADER IS -+> <quoted-string> +-------------------+->
| +------ / <--------+ |
+-> EDIT STRING IS <quoted-string> -------------------------+
| |
+-> QUERY NAME FOR -+-> DTR --------+-> IS <quoted-string> -+
| +-> DATATRIEVE -+ |
+-> DEFAULT VALUE FOR -+-> DTR --------+-> IS literal ----+
+-> DATATRIEVE -+
check-option-clause =
WITH CHECK OPTION --+----------------------------------+-->
+-> CONSTRAINT <check-option-name> +
22.3 – Arguments
22.3.1 – check-option-clause
A constraint that places restrictions on update operations made
to a view. The check option clause ensures that any rows that are
inserted or updated in a view conform to the definition of the
view. Do not specify the WITH CHECK OPTION clause with views that
are read-only.
22.3.2 – column-name
A list of names for the columns of the view. If you omit column
names, SQL assigns the names from the columns in the source
tables in the select expression.
However, you must specify names for all the columns of the view
in the following cases:
o The select expression generates columns with duplicate names.
o The select expression uses statistical functions or arithmetic
expressions to create new columns that are not in the source
tables.
22.3.3 – CONSTRAINT
Specify a name for the WITH CHECK OPTION constraint. If you omit
the name, SQL creates a name. However, Oracle Rdb recommends that
you always name constraints. If you supply a name for the WITH
CHECK OPTION constraint, the name must be unique in the schema.
The name for the WITH CHECK OPTION constraint is used by the
INTEG_FAIL error message when an INSERT or UPDATE statement
violates the constraint.
22.3.4 – select-expr
A select expression that defines which columns and rows of the
specified tables SQL includes in the view. The select expression
for a nonmultischema database can name only tables in the same
schema as the view. A select expression for a multischema
database can name a table in any schema in the database; the
schema need not be in the same catalog as the view being created.
See the Select_Expressions HELP topic for more information on
select expressions.
22.3.5 – sql-and-dtr-clause
Optional SQL and DATATRIEVE formatting clauses. See the
DATATRIEVE HELP topic for more information on formatting clauses.
22.3.6 – STORED_NAME_IS
Specifies a name that Oracle Rdb uses to access a view created
in a multischema database. The stored name allows you to access
multischema definitions using interfaces, such as Oracle RMU,
the Oracle Rdb management utility, that do not recognize multiple
schemas in one database. You cannot specify a stored name for
a view in a database that does not allow multiple schemas. For
more details about stored names, see the User_Supplied_Names HELP
topic.
22.3.7 – view-name
Name of the view definition you want to create. When choosing a
name, follow these rules:
o Use a name that is unique among all view and table names in
the schema.
o Use any valid SQL name (see the User_Supplied_Names HELP topic
for more information).
22.4 – Examples
Example 1: Defining a view based on a single table
This example shows a view definition that uses three columns from
a single table, EMPLOYEES.
SQL> CREATE VIEW EMP_NAME
cont> AS SELECT
cont> FIRST_NAME,
cont> MIDDLE_INITIAL,
cont> LAST_NAME
cont> FROM EMPLOYEES;
SQL> --
SQL> -- Now display the rows from the view just created.
SQL> SELECT * FROM EMP_NAME;
FIRST_NAME MIDDLE_INITIAL LAST_NAME
Alvin A Toliver
Terry D Smith
.
.
.
Example 2: Defining a view that does not allow you to insert or
update rows that do not conform to the view's definition
This example shows a view definition using the WITH CHECK OPTION
clause.
SQL> CREATE VIEW ADMN_VIEW
cont> AS SELECT * FROM JOB_HISTORY
cont> WHERE DEPARTMENT_CODE = 'ADMN'
cont> WITH CHECK OPTION CONSTRAINT ADMN_VIEW_CONST;
SQL> -- You cannot insert a row that does not
SQL> -- conform to the view definition.
SQL> --
SQL> INSERT INTO ADMN_VIEW (DEPARTMENT_CODE) VALUES ('MBMN');
%RDB-E-INTEG-FAIL, violation of constraint ADMN_VIEW_CONST-
caused operation to fail
Example 3: Defining a view based on multiple tables
You can also define a view using more than one table.
SQL> CREATE VIEW CURRENT_SALARY
cont> AS SELECT
cont> E.LAST_NAME,
cont> E.FIRST_NAME,
cont> E.EMPLOYEE_ID,
cont> SH.SALARY_START,
cont> SH.SALARY_AMOUNT
cont> FROM
cont> SALARY_HISTORY SH, EMPLOYEES E
cont> WHERE
cont> SH.EMPLOYEE_ID = E.EMPLOYEE_ID
cont> AND
cont> SH.SALARY_END IS NULL ;
This example defines a view from the EMPLOYEES and SALARY_HISTORY
tables. It uses the select expression to:
o Choose the columns derived from each table. Because no column
names are specified before the select expression, the columns
inherit the names from the source tables.
o Join the tables and limit the view to current salaries.
Example 4: Defining a view with local column names
SQL> CREATE VIEW EMP_JOB
cont> ( CURRENT_ID,
cont> CURRENT_NAME,
cont> CURRENT_JOB,
cont> SUPERVISOR )
cont> AS SELECT
cont> E.EMPLOYEE_ID,
cont> E.LAST_NAME,
cont> J.JOB_TITLE,
cont> JH.SUPERVISOR_ID
cont> FROM
cont> EMPLOYEES E,
cont> JOB_HISTORY JH,
cont> JOBS J
cont> WHERE
cont> E.EMPLOYEE_ID = JH.EMPLOYEE_ID
cont> AND
cont> JH.JOB_CODE = J.JOB_CODE
cont> AND
cont> JH.JOB_END IS NULL ;
This view definition:
o Specifies local names for the columns in the view.
o Joins the EMPLOYEES and JOB_HISTORY tables. This join links
rows in the EMPLOYEES table to rows in the JOB_HISTORY table.
o Joins the JOB_HISTORY and JOBS tables. This join lets the view
contain job titles instead of job codes.
o Uses the JH.JOB_END IS NULL expression. This clause specifies
that only the current JOB_HISTORY rows, where the JOB_END
column is null, should be included in the view.
The following query uses the view defined in the previous
example:
EXEC SQL
DECLARE X CURSOR FOR
SELECT CURRENT_ID, CURRENT_NAME, CURRENT_JOB, SUPERVISOR
FROM EMP_JOB
END-EXEC
EXEC SQL
OPEN X
END-EXEC
PERFORM WHILE SQLCODE NOT = 0
EXEC SQL
FETCH X
INTO :ID, :NAME, :JOB, :SUPER
END-EXEC
END PERFORM
EXEC SQL
CLOSE X
END-EXEC
Example 5: Defining a view with a calculated column
This example shows a view definition that derives a column
through a calculation based on a column in an base table.
SQL> CREATE VIEW SS_DEDUCTION
cont> ( IDENT,
cont> SALARY,
cont> SS_AMOUNT )
cont> AS SELECT
cont> E.EMPLOYEE_ID,
cont> SH.SALARY_AMOUNT,
cont> SH.SALARY_AMOUNT * 0.065
cont> FROM
cont> SALARY_HISTORY SH, EMPLOYEES E
cont> WHERE
cont> SH.EMPLOYEE_ID = E.EMPLOYEE_ID
cont> AND
cont> SH.SALARY_END IS NULL ;
Each time the view column SS_AMOUNT is selected, it computes a
new value from the SALARY_AMOUNT column of the SALARY_HISTORY
table.
Example 6: Defining a view dependent on another view
This example creates a view, DEPENDENT_VIEW, that refers to
the CURRENT_JOB view in its definition to include current job
information for employees in the engineering department.
SQL> CREATE VIEW DEPENDENT_VIEW
cont> AS SELECT * FROM CURRENT_JOB
cont> WHERE DEPARTMENT_CODE = 'ENG';