7 Working with Data in a TimesTen Database

This chapter provides detailed information on the basic objects in a TimesTen database and simple examples of how you can use SQL to manage these objects. For more information about SQL, see the Oracle TimesTen In-Memory Database SQL Reference.

For information on how to issue SQL from within an application, see the appropriate TimesTen developer's guide.

This chapter includes the following topics:

Database overview

The following sections describe the main TimesTen database objects and features:

Database objects

A TimesTen database has the following permanent objects:

  • Tables. The primary objects of a TimesTen database are the tables that contain the application data. See "Understanding tables" for more information.

  • Materialized Views. Read-only tables that hold a summary of data selected from one or more "regular" TimesTen tables. See "Understanding materialized views" for more information.

  • Views. Logical tables that are based on one or more tables called detail tables. A view itself contains no data. See "Understanding views" for more information.

  • Indexes. Indexes on one or more columns of a table may be created for faster access to tables. See "Understanding indexes" for more information.

  • Rows. Every table consists of 0 or more rows. A row is a formatted list of values. See "Understanding rows" for more information.

  • System tables. System tables contain TimesTen metadata, such as a table of all tables. See "System Tables and Views" in the Oracle TimesTen In-Memory Database System Tables and Views Reference for more information.

  • Synonyms. Aliases for a database object. Synonyms are often used for security and convenience, because they can be used to mask object name and object owner. See "Understanding synonyms" for more information.

There are also many temporary objects, including prepared commands, cursors and locks.

Database users and owners

TimesTen authenticates user names with passwords. Applications should choose one UID for the application itself because by default the login name that is being used to run the application becomes the owner of objects in the database. If you omit the UID connection attribute in the connection string, TimesTen uses the current user's login name. TimesTen converts all user names to upper case characters. Ensure that you use the fully qualified name of a database object, for example owner.table_name, whenever you issue a SQL statement.

Users cannot access TimesTen databases as user SYS. TimesTen determines the user name by the value of the UID connection attribute, or if not present, then by the login name of the connected user. If a user's login is SYS, set the UID connection to override the login name.

Understanding tables

A TimesTen table consists of rows that have a common format or structure. This format is described by the table's columns.

The following sections describes tables, its columns and how to manage them:

Overview of tables

This section includes the following topics:

Column overview

When you create the columns in the table, the column names are case-insensitive.

Each column has the following:

  • A data type

  • Optional nullability, primary key and foreign key properties

  • An optional default value

Unless you explicitly declare a column NOT NULL, columns are nullable. If a column in a table is nullable, it can contain a NULL value. Otherwise, each row in the table must have a non-NULL value in that column.

The format of TimesTen columns cannot be altered. It is possible to add or remove columns but not to change column definitions. To add or remove columns, use the ALTER TABLE statement. To change column definitions, an application must first drop the table and then recreate it with the new definitions.

Inline and out-of-line columns

The in-memory layout of the rows of a table is designed to provide fast access to rows while minimizing wasted space. TimesTen designates each VARBINARY, NVARCHAR2 and VARCHAR2 column of a table as either inline or out-of-line.

  • An inline column has a fixed length. All values of fixed-length columns of a table are stored row wise.

  • A not inline column (also referred to as an out-of-line column) has a varying length. Some VARCHAR2, NVARCHAR2 or VARBINARY data type columns are stored out-of-line. Out-of-line columns are not stored contiguously with the row but are allocated. By default, TimesTen stores VARCHAR2, NVARCHAR2 and VARBINARY columns whose declared column length is > 128 bytes as out-of-line. In addition, all LOB data types are stored out-of-line. By default, TimesTen stores variable-length columns whose declared column length is <= 128 bytes as inline.

Most operations are slightly slower when performed on an out-of-line column instead of an inline column. There are several performance considerations when you use out-of-line columns instead of inline columns:

  • Accessing data is slower because TimesTen does not store data from out-of-line columns contiguously with the row.

  • Populating data is slower because TimesTen generates more logging operations.

  • Deleting data is slower because TimesTen performs more reclaim and logging operations. If you are deleting a large number of rows (100,000 or more) consider using multiple smaller DELETE FROM statements, or the DELETE FIRST clause. For more information, see "Avoid large DELETE statements".

The maximum sizes of inline and out-of-line portions of a row are listed in "Using the ttIsql tablesize command".

Default column values

When you create a table, you can specify default values for the columns. The default value you specify must be compatible with the data type of the column. You can specify one of the following default values for a column:

  • NULL for any column type

  • A constant value

  • SYSDATE for DATE and TIMESTAMP columns

  • USER for CHAR columns

  • CURRENT_USER for CHAR columns

  • SYSTEM_USER for CHAR columns

If you use the DEFAULT clause of the CREATE TABLE statement but do not specify the default value for one or more columns, those default values for those columns are NULL. See "CREATE TABLE" in the Oracle TimesTen In-Memory Database SQL Reference.

Table names

A TimesTen table is identified uniquely by its owner name and table name. Every table has an owner. By default, TimesTen defines the owner as the user who created the table. Tables created by TimesTen, such as system tables, have the owner name SYS or TTREP.

To uniquely refer to a table, specify both its owner and name separated by a period ("."), such as MARY.PAYROLL. If an application does not specify an owner, TimesTen looks for the table under the user name of the caller, then under the user name SYS.

A name is an alphanumeric value that begins with a letter. A name can include underscores. The maximum length of a table name is 30 characters. The maximum length of an owner name is also 30 characters. TimesTen displays all table, column and owner names to upper case characters. See "Names, Namespace and Parameters" in the Oracle TimesTen In-Memory Database SQL Reference for additional information.

Table access

Applications access tables through SQL statements. The TimesTen query optimizer automatically chooses the optimal way to access tables. It uses existing indexes or, if necessary, creates temporary indexes to speed up access. For improved performance, applications should explicitly create indexes for frequently searched columns because the automatic creation and destruction of temporary indexes incurs a performance overhead. For more details, see "Tune statements and use indexes". You can use optimizer hints (statement or transaction level) to tune the TimesTen execution plan for a specific application. For more information on optimizer hints, see "Use optimizer hints to modify the execution plan".

Primary keys, foreign keys and unique indexes

You can create a primary key on one or more columns to indicate that duplicate values for that set of columns should be rejected. Primary key columns must be declared NOT NULL. A table can have at most one primary key. TimesTen automatically creates a range index on the primary key to enforce uniqueness on the primary key and to improve access speeds through the primary key. Once a row is inserted, its primary key columns cannot be modified, except to change a range index to a hash index.

Note:

Indexes are discussed in "Understanding indexes".

Although a table may have only one primary key, additional uniqueness properties may be added to the table using unique indexes. See "CREATE INDEX" in the Oracle TimesTen In-Memory Database SQL Reference for more information.

Note:

Columns of a primary key must be NOT NULL; however, a unique index can be built on columns declared as NOT NULL.

A table may also have one or more foreign keys through which rows correspond to rows in another table. Foreign keys relate to a primary key or uniquely indexed columns in the other table. Foreign keys use a range index on the referencing columns. See "CREATE TABLE" in the Oracle TimesTen In-Memory Database SQL Reference for more information.

System tables

In addition to tables created by applications, a TimesTen database contains system tables. System tables contain TimesTen metadata such as descriptions of all tables and indexes in the database, as well as other information such as optimizer plans. Applications may query system tables just as they query user tables. Applications may not directly update system tables. TimesTen system tables are described in the "System Tables and Views" chapter in the Oracle TimesTen In-Memory Database System Tables and Views Reference.

Note:

TimesTen system table formats may change between releases of TimesTen.

Working with tables

To perform any operation that creates, drops or manages a table, the user must have the appropriate privileges, which are described along with the syntax for all SQL statements in the "SQL Statements" chapter in the Oracle TimesTen In-Memory Database SQL Reference.

This section includes the following topics:

Creating a table

To create a table, use the SQL statement CREATE TABLE. The syntax for all SQL statements is provided in the Oracle TimesTen In-Memory Database SQL Reference. TimesTen converts table names to upper case characters.

Example 7-1 Create a table

The following SQL statement creates a table, called customer, with two columns: cust_id and cust_name of two different data types.

Command> CREATE TABLE customer (cust_id TT_INTEGER, cust_name VARCHAR2(50));

Example 7-2 Create a table with a hash index

This example creates a table, called customer, with the columns: cust_id, cust_name, addr, zip, and region. The cust_id column is designated as the primary key, so that the CustId value in a row uniquely identifies that row in the table, as described in "Primary keys, foreign keys and unique indexes".

The UNIQUE HASH ON custId PAGES value indicates that there are 30 pages in the hash index. This means that the expected number of rows in the table is 30 * 256 = 7680. If the table ends up with significantly more rows than this, performance can be degraded, and the hash index should be resized. For more details on pages in a hash index, see information for SET PAGES in the "ALTER TABLE" section in the Oracle TimesTen In-Memory Database SQL Reference. For details on how to size pages in a hash table, see "Size hash indexes appropriately".

Command> CREATE TABLE customer
(cust_id NUMBER NOT NULL PRIMARY KEY, 
cust_name CHAR(100) NOT NULL, 
addr CHAR(100), 
zip NUMBER, 
region CHAR(10)) 
UNIQUE HASH ON (cust_id) PAGES = 30;

Dropping a table

To drop a TimesTen table, call the SQL statement DROP TABLE.

Example 7-3 Drop a table

The following example drops the table customer.

Command> DROP TABLE customer;

Estimating table size

Increasing the size of a TimesTen database can be done on first connect. To avoid having to increase the size of a database, it is important not to underestimate the eventual database size. Use the ttSize utility to estimate table size.

The following example shows that the ttSize utility estimates the rows, inline row bytes, size of any indexes on the table, and the total size of the table:

% ttSize -tbl pat.tab1 mydb

Rows = 2

Total in-line row bytes = 17524
Indexes:

 Index PAT adds 6282 bytes
  Total index bytes = 6282

Total = 23806

You can also calculate the size of an existing table with the ttIsql tablesize command. For more information, see "Using the ttIsql tablesize command".

Implementing aging in your tables

You can define an aging policy for one or more tables in your database. An aging policy refers to the type of aging and the aging attributes, as well as the aging state (ON or OFF). You can specify one of the following types of aging policies: usage-based or time-based. Usage-based aging removes least recently used (LRU) data within a specified database usage range. Time-based aging removes data based on the specified data lifetime and frequency of the aging process. You can define only one type of aging for a specified table.

You can define an aging policy for a new table with the CREATE TABLE statement. You can add an aging policy to an existing table with the ALTER TABLE statement if the table does not already have an aging policy defined. You can change the aging policy by dropping aging and adding a new aging policy.

You cannot specify aging on the following types of tables:

  • Global temporary tables

  • Detail tables of materialized views

You can also implement aging in cache groups. See "Implementing aging in a cache group" in the Oracle TimesTen Application-Tier Database Cache User's Guide.

Note:

There is no support to specify aging policies for tables within TimesTen Scaleout. See "Comparison between TimesTen Scaleout and TimesTen Classic" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for details.

This section includes the following topics:

Usage-based aging

Usage-based aging enables you to maintain the amount of memory used in a database within a specified threshold by removing the least recently used (LRU) data.

Define LRU aging for a new table by using the AGING LRU clause of the CREATE TABLE statement. Aging begins automatically if the aging state is ON.

Call the ttAgingLRUConfig built-in procedure to specify the LRU aging attributes. The attribute values apply to all tables in the database that have an LRU aging policy. If you do not call the ttAgingLRUConfig built-in procedure, then the default values for the attributes are used.

Note:

The ttAgingLRUConfig built-in procedure requires that the user have ADMIN privilege if you want to modify any attributes. You do not need any privileges for viewing existing attributes. For more information, see "Built-In Procedures" in the Oracle TimesTen In-Memory Database Reference.

The following table summarizes the LRU aging attributes:

LRU Aging Attribute Description
LowUsageThreshhold The percent of the database PermSize at which LRU aging is deactivated.
HighUsageThreshhold The percent of the database PermSize at which LRU aging is activated.
AgingCycle The number of minutes between aging cycles.

If you set a new value for AgingCycle after an LRU aging policy has already been defined, aging occurs based on the current time and the new cycle time. For example, if the original aging cycle is 15 minutes and LRU aging occurred 10 minutes ago, aging is expected to occur again in 5 minutes. However, if you change the AgingCycle parameter to 30 minutes, then aging occurs 30 minutes from the time you call the ttAgingLRUConfig procedure with the new value for AgingCycle.

If a row has been accessed or referenced since the last aging cycle, it is not eligible for LRU aging. A row is considered to be accessed or referenced if one of the following is true:

  • The row is used to build the result set of a SELECT statement.

  • The row has been flagged to be updated or deleted.

  • The row is used to build the result set of an INSERT SELECT statement.

You can use the ALTER TABLE statement to perform the following tasks:

  • Enable or disable the aging state on a table that has an aging policy defined by using the ALTER TABLE statement with the SET AGING {ON|OFF} clause.

  • Add an LRU aging policy to an existing table by using the ALTER TABLE statement with the ADD AGING LRU [ON|OFF] clause.

  • Drop aging on a table by using the ALTER TABLE statement with the DROP AGING clause.

Call the ttAgingScheduleNow built-in procedure to schedule when aging starts. For more information, see "Scheduling when aging starts".

To change aging from LRU to time-based on a table, first drop aging on the table by using the ALTER TABLE statement with the DROP AGING clause. Then add time-based aging by using the ALTER TABLE statement with the ADD AGING USE clause.

Note:

When you drop LRU aging or add LRU aging to tables that are referenced in commands, TimesTen marks the compiled commands invalid. The commands need to be recompiled.

Time-based aging

Time-based aging removes data from a table based on the specified data lifetime and frequency of the aging process. Specify a time-based aging policy for a new table with the AGING USE clause of the CREATE TABLE statement. Add a time-based aging policy to an existing table with the ADD AGING USE clause of the ALTER TABLE statement.

The AGING USE clause has a ColumnName argument. ColumnName is the name of the column that is used for time-based aging, also called the timestamp column. The timestamp column must be defined as follows:

  • ORA_TIMESTAMP, TT_TIMESTAMP, ORA_DATE or TT_DATE data type

  • NOT NULL

Your application updates the values of the timestamp column. If the value of this column is unknown for some rows and you do not want the rows to be aged, then define the column with a large default value. You can create an index on the timestamp column for better performance of the aging process.

Note:

You cannot add or modify a column in an existing table and then use that column as a timestamp column because you cannot add or modify a column and define it to be NOT NULL.

You cannot drop the timestamp column from a table that has a time-based aging policy.

If the data type of the timestamp column is ORA_TIMESTAMP, TT_TIMESTAMP, or ORA_DATE, you can specify the lifetime in days, hours, or minutes in the LIFETIME clause of the CREATE TABLE statement. If the data type of the timestamp column is TT_DATE, specify the lifetime in days.

The value in the timestamp column is subtracted from SYSDATE. The result is truncated the result using the specified unit (minute, hour, day) and compared with the specified LIFETIME value. If the result is greater than the LIFETIME value, then the row is a candidate for aging.

Use the CYCLE clause to indicate how often the system should examine the rows to remove data that has exceeded the specified lifetime. If you do not specify CYCLE, aging occurs every five minutes. If you specify 0 for the cycle, then aging is continuous. Aging begins automatically if the state is ON.

Use the ALTER TABLE statement to perform the following tasks:

  • Enable or disable the aging state on a table with a time-based aging policy by using the SET AGING {ON|OFF} clause.

  • Change the aging cycle on a table with a time-based aging policy by using the SET AGING CYCLE clause.

  • Change the lifetime by using the SET AGING LIFETIME clause.

  • Add time-based aging to an existing table with no aging policy by using the ADD AGING USE clause.

  • Drop aging on a table by using the DROP AGING clause.

Call the ttAgingScheduleNow built-in procedure to schedule when aging starts. For more information, see "Scheduling when aging starts".

To change the aging policy from time-based aging to LRU aging on a table, first drop time-based aging on the table. Then add LRU aging by using the ALTER TABLE statement with the ADD AGING LRU clause.

Aging and foreign keys

Tables that are related by foreign keys must have the same aging policy.

  • If LRU aging is in effect and a row in a child table is recently accessed, then neither the parent row nor the child row is deleted.

  • If time-based aging is in effect and a row in a parent table is a candidate for aging out, then the parent row and all of its children are deleted.

  • If a table has ON DELETE CASCADE enabled, the setting is ignored.

Scheduling when aging starts

Call the ttAgingScheduleNow built-in procedure to schedule the aging process. The aging process starts as soon as you call the procedure unless there is already an aging process in progress, in which case it begins when that aging process has completed.

When you call ttAgingScheduleNow, the aging process starts regardless of whether the state is ON or OFF.

The aging process starts only once as a result of calling ttAgingScheduleNow does not change the aging state. If the aging state is OFF when you call ttAgingScheduleNow, then the aging process starts, but it does not continue after the process is complete. To continue aging, you must call ttAgingScheduleNow again or change the aging state to ON.

If the aging state is already set to ON, then ttAgingScheduleNow resets the aging cycle based on the time ttAgingScheduleNow was called.

You can control aging externally by disabling aging by using the ALTER TABLE statement with the SET AGING OFF clause. Then use ttAgingScheduleNow to start aging at the desired time.

Use ttAgingScheduleNow to start or reset aging for an individual table by specifying its name when you call the procedure. If you do not specify a table name, then ttAgingScheduleNow starts or resets aging on all of the tables in the database that have aging defined.

Aging and replication

For active standby pairs, implement aging on the active master database. Deletes that occur as a result of aging are replicated to the standby master database and the read-only subscribers. If a failover to the standby master database occurs, aging is enabled on the database after its role changes to ACTIVE.

For all other types of replication schemes, implement aging separately on each node. The aging policy must be the same on all nodes.

If you implement LRU aging on a multimaster replication scheme used as a hot standby, LRU aging may provide unintended results. After a failover, you may not have all of the desired data because aging occurs locally.

Understanding views

A view is a logical table that is based on one or more tables. The view itself contains no data. It is sometimes called a non-materialized view to distinguish it from a materialized view, which does contain data that has already been calculated from detail tables. Views cannot be updated directly, but changes to the data in the detail tables are immediately reflected in the view.

A view is basically a SQL statement that is stored in a database which enables you to treat the results of a SQL query as a table itself. TimesTen generates the results of a view every time you query that view, so a view always has the latest data results. You can query a view just like you would query a regular table.

A materialized view enables you to precompute expensive SQL operations. There are cases where primarily read-only databases can increase the speed of their SELECT operations by precomputing the results of queries and storing them in a materialized view. The downside in this case is that the materialized view requires additional storage space. Keep in mind that when you perform DML operations on the detail tables of a materialized view, these DML operations are more resource intensive and more storage is required to store the materialized view rows. If you use too many materialized views on a table, this may reduce the performance of that table.

To perform any operation that creates, drops or manages a view, the user must have the appropriate privileges, which are described along with the syntax for all SQL statements in the "SQL Statements" chapter in the Oracle TimesTen In-Memory Database SQL Reference.

This section includes the following topics:

Creating a view

To create a view, use the CREATE VIEW SQL statement. The syntax for all SQL statements is provided in the "SQL Statements" chapter in the Oracle TimesTen In-Memory Database SQL Reference.

CREATE VIEW ViewName AS SelectQuery;

This selects columns from the detail tables to be used in the view.

For example, create a view from the table t1:

Command> CREATE VIEW v1 AS SELECT * FROM t1;

Now create a view from an aggregate query on the table t1:

Command> CREATE VIEW v1 (max1) AS SELECT max(x1) FROM t1;

The SELECT query in the CREATE VIEW statement

The SELECT query used to define the contents of a materialized view is similar to the top-level SQL SELECT statement described in "SQL Statements" in the Oracle TimesTen In-Memory Database SQL Reference, with the following restrictions:

  • A SELECT * query in a view definition is expanded at view creation time. Any columns added after a view is created do not affect the view.

  • The following cannot be used in a SELECT statement that is creating a view:

  • DISTINCT

  • FIRST

  • ORDER BY

  • Arguments

  • Temporary tables

  • Each expression in the select list must have a unique name. A name of a simple column expression would be that column's name unless a column alias is defined. RowId is considered an expression and needs an alias.

  • No SELECT FOR UPDATE or SELECT FOR INSERT statements can be used on a view.

  • Certain TimesTen query restrictions are not checked when a non-materialized view is created. Views that violate those restrictions may be allowed to be created, but an error is returned when the view is referenced later in an executed statement.

Dropping a view

The DROP VIEW statement deletes the specified view.

The following statement drops the cust_order view:

Command> DROP VIEW cust_order;

Restrictions on views and detail tables

Views have the following restrictions:

  • When a view is referenced in the FROM clause of a SELECT statement, its name is replaced by its definition as a derived table during SQL compilation. The content of the derived table is said to be materialized, but this materialization is temporary and only exists for the duration of the SQL statement. For example, if both the view and the referencing select specify aggregates, the view is materialized before its result can be joined with other tables of the select.

  • A view cannot be dropped with a DROP TABLE statement. You must use the DROP VIEW statement.

  • A view cannot be altered with an ALTER TABLE statement.

  • Referencing a view can fail due to dropped or altered detail tables.

Understanding materialized views

The following sections describes materialized views and how to manage them:

Overview of materialized views

A materialized view is a read-only table that maintains a summary of data selected from one or more regular TimesTen tables. The TimesTen tables queried to make up the result set for the materialized view are called detail tables.

Note:

Materialized views are not supported on cache tables.

Figure 7-1 shows a materialized view created from detail tables. An application updates the detail tables and can select data from the materialized view.

The synchronous materialized view, updates the result set data from the detail tables at the time of the detail table transaction. Every time data is updated in the detail tables, the result set is updated. Thus, the materialized view is never out of sync with the detail tables. However, this can affect your performance. A single transaction, the user transaction, executes the updates for both the detail table and any materialized views.

Working with materialized views

This section includes the following topics:

Creating a materialized view

To create a materialized view, use the SQL statement CREATE MATERIALIZED VIEW.

Note:

In order to create a materialized view, the user must have the appropriate privileges, which are described along with the syntax for all SQL statements in the "SQL Statements" chapter in the Oracle TimesTen In-Memory Database SQL Reference.

If the owner has these privileges revoked for any of the detail tables on which the materialized view is created, the materialized view becomes invalid. See "Object privileges for materialized views" in the Oracle TimesTen In-Memory Database Security Guide.

When creating a materialized view, you can establish primary keys and the size of the hash table in the same manner as described for tables in "Primary keys, foreign keys and unique indexes".

The materialized view examples are based on the following two tables:

Command> CREATE TABLE customer 
(cust_id INT NOT NULL, 
cus_name CHAR(100) NOT NULL, 
addr CHAR(100), 
zip INT, 
region CHAR(10), 
PRIMARY KEY (cust_id));

CREATE TABLE book_order 
(order_id INT NOT NULL, 
cust_id INT NOT NULL, 
book CHAR(100), 
PRIMARY KEY (order_id), 
FOREIGN KEY (cust_id) REFERENCES customer(cust_id));

The following sections provide details and examples for creating materialized views:

Creating a synchronous materialized view

A synchronous materialized view is automatically updated each time the detail tables are updated. You can create a synchronous materialized view with the CREATE MATERIALIZED VIEW statement.

The following creates a synchronous materialized view, named sample_mv, that generates a result set from selected columns in the customer and book_order detail tables described above.

Command> CREATE MATERIALIZED VIEW sample_mv AS 
SELECT customer.cust_id, cust_name, order_id, book 
FROM customer, book_order 
WHERE customer.cust_id=book_order.cust_id;
The SELECT query in the CREATE MATERIALIZED VIEW statement

The SELECT query used to define the contents of a materialized view is similar to the top-level SQL SELECT statement described in "SQL Statements" in the Oracle TimesTen In-Memory Database SQL Reference with some restrictions, which are described in "CREATE MATERIALIZED VIEW" in the Oracle TimesTen In-Memory Database SQL Reference.

Dropping a materialized view

To drop any materialized view, issue the DROP VIEW statement.

The following statement drops the sample_mv materialized view.

Command> DROP VIEW sample_mv;

The syntax for all SQL statements is provided in the "SQL Statements" chapter in the Oracle TimesTen In-Memory Database SQL Reference.

Restrictions on materialized views and detail tables

A materialized view is a read-only table that cannot be updated directly. This means a materialized view cannot be updated by an INSERT, DELETE, or UPDATE statement, nor can it be updated by replication, XLA, or the cache agent.

For example, any attempt to update a row in a materialized view generates the following error:

805: Update view table directly has not been implemented

Readers familiar with other implementations of materialized views should note the following characteristics of TimesTen materialized views:

  • Detail tables can be replicated, but materialized views cannot.

  • Neither a materialized view nor its detail tables can be part of a cache group.

  • You cannot create a foreign key to reference a table or another materialized view. Regular tables cannot use a foreign key to refer to a materialized view.

  • To drop a materialized view must use the DROP VIEW statement.

  • You cannot alter a materialized view. You must use the DROP VIEW statement and then create a new materialized view with a CREATE MATERIALIZED VIEW statement.

  • Materialized views must be explicitly created by the application.

  • The TimesTen query optimizer does not rewrite queries on the detail tables to reference materialized views. Application queries must directly reference views, if they are to be used.

  • There are some restrictions to the SQL used to create materialized views. See "CREATE MATERIALIZED VIEW" in the Oracle TimesTen In-Memory Database SQL Reference for details.

Performance implications of materialized views

The performance of UPDATE, INSERT, and DELETE operations may be impacted if the updated table is referenced in a materialized view. The performance impact depends on many factors, such as the following:

  • Nature of the materialized view: How many detail tables, whether outer join or aggregation, are used.

  • Which indexes are present on the detail table and on the materialized view.

  • How many materialized view rows are affected by the change.

A materialized view is a persistent, up-to-date copy of a query result. To keep the materialized view up to date, TimesTen must perform "materialized view maintenance" when you change a materialized view's detail table. For example, if you have a materialized view named V that selects from tables T1, T2, and T3, then any time you insert into T1, or update T2, or delete from T3, TimesTen performs "materialized view maintenance."

Materialized view maintenance needs appropriate indexes just like regular database operations. If they are not there, materialized view maintenance performs poorly.

All update, insert, or delete statements on detail tables have execution plans, as described in "The TimesTen Query Optimizer". For example, an update of a row in T1 initiates the first stage of the plan where it updates the materialized view V, followed by a second stage where it updates T1.

For fast materialized view maintenance, you should evaluate the plans for all the operations that update the detail tables, as follows:

  1. Examine all the WHERE clauses for the update or delete statements that frequently occur on the detail tables. Note any clause that uses an index key. For example, if the operations that an application performs 95 percent of the time are as follows:

    UPDATE T1 set A=A+1 WHERE K1=? AND K2=?
    DELETE FROMT2 WHERE K3=?
    

    Then the keys to note are (K1, K2) and K3.

  2. Ensure that the view selects all of those key columns. In this example, the materialized view should select K1, K2, and K3.

  3. Create an index on the materialized view on each of those keys. In this example, the view should have two indexes, one on (V.K1, V.K2) and one on V.K3. The indexes do not have to be unique. The names of the view columns can be different from the names of the table columns, though they are the same in this example.

With this method, when you update a detail table, your WHERE clause is used to do the corresponding update of the view. This allows maintenance to be executed in a batch, which has better performance.

The above method may not always work, however. For example, an application may have many different methods to update the detail tables. The application would have to select far too many items in the view or create too many indexes on the materialized view, taking up more space or more performance than you might wish. An alternative method is as follows:

  1. For each table in the materialized view's FROM clause (each detail table), check which ones are frequently changed by UPDATE, INSERT and CREATE VIEW statements. For example, a materialized view's FROM clause may have tables T1, T2, T3, T4, and T5, but of those, only T2 and T3 are frequently changed.

  2. For each of those tables, make sure the materialized view selects its rowids. In this example, the materialized view should select T2.rowid and T3.rowid.

  3. Create an index on the materialized view on each of those rowid columns. In this example, the columns might be called T2rowid and T3rowid, and indexes would be created on V.T2rowid and V.T3rowid.

With this method, materialized view maintenance is done on a row-by-row basis, rather than on a batch basis. But the rows can be matched very efficiently between a materialized view and its detail tables, which speeds up the maintenance. It is generally not as fast as the first method, but it is still good.

Understanding indexes

Indexes are auxiliary data structures that greatly improve the performance of table searches. You can use the Index Advisor to recommend indexes for a particular SQL workload. For more details, see "Using the Index Advisor to recommend indexes".

Indexes are used automatically by the query optimizer to speed up the execution of a query. For information about the query optimizer, see "The TimesTen Query Optimizer".

You can designate an index as unique, which means that each row in the table has a unique value for the indexed column or columns. Unique indexes can be created over nullable columns. In conformance with the SQL standard, multiple null values are permitted in a unique index, which enables a unique index to have multiple rows with the same set of values.

When sorting data values, TimesTen considers null values to be larger than all non-null values. For more information on null values, see "Null values" in the Oracle TimesTen In-Memory Database SQL Reference.

To perform any operation that creates, drops, or alters an index, the user must have the appropriate privileges, which are described along with the syntax for all SQL statements in the "SQL Statements" chapter in the Oracle TimesTen In-Memory Database SQL Reference.

The following sections describe how to manage your index:

Overview of index types

TimesTen provides three types of indexes to enable fast access to tables. You can create up to 500 range or hash indexes on a table.

  • Range Indexes. Range indexes are useful for finding rows with column values within a certain range. You can create range indexes over one or more columns of a table.

    Range indexes and equijoins can be used for equality and range searches, such as greater than or equal to, less than or equal to, and so on. If you have a primary key on a field and want to see if FIELD > 10, then the primary key index does not expedite finding the answer, but a separate index will.

    See the "CREATE INDEX" section of the Oracle TimesTen In-Memory Database SQL Reference for more information on how to create range indexes.

  • Hash Indexes. Hash indexes are useful for equality searches. A hash index is created with either of the following:

    • You can create a hash index or a unique hash index on one or more columns of a table or materialized view with the CREATE INDEX statement.

    • You can create a unique hash index on the primary key of a table during table creation with the CREATE TABLE... UNIQUE HASH ON statement.

    See the "CREATE INDEX" and "CREATE TABLE" sections of the Oracle TimesTen In-Memory Database SQL Reference for details on creating hash indexes. For an example of how to create a hash index, see Example 7-4. For details on how to size a hash table, see "Size hash indexes appropriately".

    Note:

    Hash indexes are faster than range indexes for exact match lookups, but they require more space than range indexes. Hash indexes can only be used for exact value lookups. Hash indexes cannot be used if the SQL query returns a range of values. Also, hash indexes are not useful for sorting values that come from a table scan.

    Range indexes are optimized for in-memory data management and provide efficient sorting by column value.

    TimesTen may create temporary hash and range indexes automatically during query processing to speed up query execution.

Note:

Alternatively, you can perform lookups by RowID for fast access to data. For more information, see "ROWID data type" in the Oracle TimesTen In-Memory Database SQL Reference.

Creating an index

To create an index, issue the SQL statement CREATE INDEX. TimesTen converts index names to upper case characters.

Every index has an owner. The owner is the user who created the underlying table. Indexes created by TimesTen itself, such as indexes on system tables, are created with the user name SYS or with the user name TTREP for indexes on replication tables.

Note:

You cannot create an index on LOB columns.

Example 7-4 Create an index

The following creates an index ixid over column cust_id of table customer.

Command> CREATE INDEX ixid ON customer (cust_id);

The following creates a unique hash index on the customer table as part of the table creation:

Command> CREATE TABLE customer 
(cust_id NUMBER NOT NULL PRIMARY KEY, 
cust_name CHAR(100) NOT NULL, 
addr CHAR(100), 
zip NUMBER, 
region CHAR(10)) 
UNIQUE HASH ON (cust_id) PAGES = 30;

The following creates a nonunique hash index on the customer table over the customer name:

Command> CREATE HASH INDEX custname_idx ON customer(cust_name);

For more examples on the different indexes and how to create them, see "CREATE INDEX" and "ALTER TABLE" in the Oracle TimesTen In-Memory Database SQL Reference.

Altering an index

You can use the ALTER TABLE statement to add (or change) a primary key constraint to use either a range or hash index.

Note:

You cannot alter an index to be transformed from a hash to a range index or from a range to a hash index if it was created with the CREATE INDEX statement.

You can change a primary key constraint to use a range index instead of a hash index with the USE RANGE INDEX clause of the ALTER TABLE statement; you can change a primary key constraint to use a hash index instead of a range index with the USE HASH INDEX of the ALTER TABLE statement. See "ALTER TABLE" in the Oracle TimesTen In-Memory Database SQL Reference.

Dropping an index

To uniquely refer to an index, an application must specify both its owner and name. If the application does not specify an owner, TimesTen looks for the index first under the user name of the caller, then under the user name SYS.

Example 7-5 Drop an index

The following drops the index named ixid.

Command> DROP INDEX ixid;

To drop a TimesTen index, issue the DROP INDEX SQL statement.

Note:

All indexes in a table are dropped automatically when the table is dropped.

Estimating index size

Increasing the size of a TimesTen database can be done on first connect. Use the ttSize utility to estimate database size, including any indexes. Correctly estimating the size of a database helps you to avoid having to resize the database in the future.

The following example shows that the ttSize utility estimates the rows, inline row bytes, size of any indexes on the table, and the total size of the table:

% ttSize -tbl pat.tab1 mydb

Rows = 2

Total in-line row bytes = 17524
Indexes:

 Index PAT adds 6282 bytes
  Total index bytes = 6282

Total = 23806

Using the Index Advisor to recommend indexes

The right set of indexes can make a difference in query performance. The Index Advisor can be used to recommend indexes for improving the performance of a specific SQL workload. The Index Advisor is intended for read-intensive complex queries. The use of the Index Advisor is not recommended for a write-intensive workload.

The Index Advisor evaluates a SQL workload and recommends indexes that can improve the performance for the following: joins, single table scans, and ORDER BY or GROUP BY operations. The Index Advisor does not differentiate tables that are used for specific intentions, such as the base table for a materialized view or as a table within a cache group. As long as the table is used in queries in the SQL workload, the Index Advisor may recommend indexes on that table.

The Index Advisor generates the CREATE statement for each recommended index, which you can choose to issue. A database administrator should review each CREATE statement recommended for new indexes before they are applied since the Index Advisor may recommend the following:

  • Indexes that are duplicates of existing indexes.

  • Indexes for tables or columns of tables that are created and dropped during a SQL workload. However, you could add the CREATE statement for the recommended index in the SQL workload after the DDL that creates the tables or columns of tables and before they are dropped.

  • Indexes that cannot be created, such as a unique index for a data set where the data is not unique. In this case, you should ignore this recommendation.

  • Index creation options where you can create an index as either a UNIQUE or non-unique index. The Index Advisor suggests both index types. You can only create one of the indexes as both suggested indexes have the same index name. While the optimizer thinks that the UNIQUE index is better for the specified workload, you can choose to create the non-unique index. Consider creating the UNIQUE index if the column only contains unique values. Consider creating the non-unique index if the column contains non-unique value.

The Index Advisor does not cover the following:

  • It does not optimize for memory use.

  • It does not consider maintenance costs.

  • It does not recommend that existing indexes be dropped if they are not useful.

  • It does not recommend indexes for global temporary tables.

The recommended steps to use the Index Advisor are as follows:

Prepare for executing the Index Advisor

Before you execute the Index Advisor, you should optionally perform the following:

  1. Since the Index Advisor relies on the query plan, set any relevant optimizer hints that you would use for the SQL workload before enabling the Index Advisor and running the workload. For more details on optimizer hints, see "Use optimizer hints to modify the execution plan".

  2. Update statistics for tables included in the SQL workload and force statements to be re-prepared during the capture. This provides the most up-to-date statistics for the data collection and causes the statements to be re-prepared based on the latest statistics.

Update statistics for tables included in the SQL workload with one of the following built-in procedures: ttOptUpdateStats, ttOptEstimateStats, or ttOptSetTblStats. In the built-in procedures, set the invalidate parameter to 1 to invalidate all commands that reference the indicated tables and force these commands to be automatically prepared again when re-executed. This ensures that statistics are up to date.

  • The ttOptUpdateStats built-in procedure provides a full update of all statistics for the tables. However, it can be time consuming.

  • The ttOptEstimateStats evaluates statistics based upon a small percentage of rows in the indicated tables.

  • The ttOptSetTblStats sets the statistics to known values provided by you.

Note:

For more information on these built-in procedures, see "ttOptUpdateStats", "ttOptEstimateStats", and "ttOptSetTblStats" in the Oracle TimesTen In-Memory Database Reference.

The following example estimates statistics for all tables for the current user by evaluating a random sample of ten percent of the rows in these tables. It also invalidates all commands already prepared that reference these tables.

Command> call ttOptEstimateStats ( '', 1, '10 PERCENT' );

Capture the data used for generating index recommendations

Call the ttIndexAdviceCaptureStart and ttIndexAdviceCaptureEnd built-in procedures to capture the information needed by the Index Advisor to generate index recommendations, as follows:

  1. Call the ttIndexAdviceCaptureStart built-in procedure to start the process to collect index information.

  2. Run the SQL workload.

  3. Call the ttIndexAdviceCaptureEnd built-in procedure to end the index information collection process.

Note:

After the data collection process ends, you can retrieve the index recommendations as described in "Retrieve index recommendations and data collection information".

When you call the ttIndexAdviceCaptureStart built-in procedure to initiate the data collection process, provide the following:

  • In the captureLevel parameter, specify whether the index information is to be collected for the current connection or for the entire database. You can execute multiple connection-level captures concurrently for independent connections without conflict. A database-level capture can take place in parallel with a connection-level capture. Since there is no conflict between a database-level and a connection-level capture, any outstanding connection-level captures that are already in progress when a database-level capture is initiated completes as intended. However, an error is returned if you initiate a second request for a database-level capture while the first is still active; an error is also returned if a second request for a connection-level capture from the same connection is initiated while the first connection-level capture is still active.

    If you invoke ttIndexAdviceCaptureStart for a database-level capture, any outstanding connection-level captures that are already in progress complete.

  • The captureMode parameter designates that you want the data collection performed on one of the following scenarios:

    • Perform the collection of index information using the current execution of the SQL workload.

    • Base the collection of index information not on a current execution of the SQL workload, but on existing computed statistics and query plan analysis. In this scenario, the SQL statements have been prepared, but not executed. This mode can only be executed with a connection-level capture.

To complete the capture, call the ttIndexAdviceCaptureEnd built-in procedure that ends either an active connection-level capture from the same connection or an active database-level capture. Completing a database-level capture requires the ADMIN privilege.

If a connection fails during a capture, the following occurs:

  • If the capture is a connection-level capture, the capture ends and all associated resources are freed.

  • If the capture is a database-level capture, the capture continues until another user with ADMIN privileges connects and invokes the ttIndexAdviceCaptureEnd built-in procedure to end a database-level capture.

If temporary space becomes full during a capture, an active capture ends and the data collected during the capture is saved.

Note:

Execute ttIndexAdviceCaptureDrop to free the temporary space after a capture. See "Drop data collected for the index advisor and finalize results" for more information on ttIndexAdviceCaptureDrop.

The following example starts a collection for the Index Advisor at the connection-level for the current execution of a SQL workload:

Command> call ttIndexAdviceCaptureStart(0,0);

The following example ends the collection for the connection-level capture:

Command> call ttIndexAdviceCaptureEnd(0);

Note:

For more information on these built-in procedures, see "ttIndexAdviceCaptureStart" and "ttIndexAdviceCaptureEnd" in the Oracle TimesTen In-Memory Database Reference.

Retrieve index recommendations and data collection information

  1. Call the ttIndexAdviceCaptureInfoGet built-in procedure to retrieve data collection overview information for the Index Advisor.

  2. Call the ttIndexAdviceCaptureOutput built-in procedure to retrieve the recommended indexes.

    Note:

    These built-in procedures retrieve the data collection overview and Index Advisor recommendations. Execute either or both for the data you want.
  3. After a DBA has evaluated the recommended index creation statements, apply the desired index creation recommendations.

Retrieve data collection information with ttIndexAdviceCaptureInfoGet

The ttIndexAdviceCaptureInfoGet built-in procedure retrieves information about the data collected for the Index Advisor. For both a connection-level capture and a database-level capture, only a single row is returned.

Note:

The database-level capture row can only be returned to a user with ADMIN privileges.

The ttIndexAdviceCaptureInfoGet built-in procedure captures data if:

  • The data capture was started and has not ended.

  • A previous capture that was started and stopped, and the data was not deleted.

Note:

If no capture is in progress or no data exists, then no rows are returned.

The rows returned include the following information:

  • The capture state: Returns 0 if a capture is completed. Returns 1 if a capture is still in progress.

  • The connection identifier, if appropriate.

  • The capture level and mode set for this capture.

  • The number of prepared and executed statements during the capture interval.

  • The time that the capture was started and stopped.

The following shows capture information for a completed connection-level capture for 363 prepared statements and 369 executed statements:

Command> call ttIndexAdviceCaptureInfoGet();
< 0, 1, 0, 0, 363, 369, 2012-07-27 11:44:08.136833, 2012-07-27 12:07:35.410993 >
1 row found.

Note:

For more details and syntax for this built-in procedure, see "ttIndexAdviceCaptureInfoGet" in the Oracle TimesTen In-Memory Database Reference.
Retrieve index recommendations with ttIndexAdviceCaptureOutput

The ttIndexAdviceCaptureOutput built-in procedure retrieves the list of index recommendations from the last recorded capture at the specified level (connection or database-level). The list contains the CREATE statement for each recommended index.

To request index recommendations for a connection-level capture, execute ttIndexAdviceCaptureOutput with captureLevel set to 0 in the same connection that initiated the capture. For a database-level capture, execute ttIndexAdviceCaptureOutput with captureLevel set to 1 in a connection where the user has ADMIN privilege.

The returned row contains:

  • stmtCount - The number of times the index would be useful to speed up the executed SQL workload.

  • createStmt - The executable statement that can be used to create the recommended index. All database object names in these statements are fully qualified.

The following example provides the CREATE statement for an index called PURCHASE_i1 on the HR.PURCHASE table, which would be useful 4 times for this SQL workload.

CALL ttIndexAdviceCaptureOutput();
< 4, create index PURCHASE_i1 on HR.PURCHASE(AMOUNT); >
1 row found. 

Note:

For more information and syntax for this built-in procedure, see "ttIndexAdviceCaptureOutput" in the Oracle TimesTen In-Memory Database Reference.

Drop data collected for the index advisor and finalize results

After you have applied the CREATE statements for the new indexes that have been approved by the DBA, you can drop the captured data collected for the Index Advisor. The ttIndexAdviceCaptureDrop built-in procedure drops the existing data collected for the specified captureLevel, which can either be a connection or database-level capture.

Call ttIndexAdviceCaptureDrop(0);

You must call this built-in procedure twice to drop both a connection-level and database-level capture. You may not invoke this built-in procedure while a capture at the same level is in progress.

Note:

For more information and syntax for this built-in procedure, see "ttIndexAdviceCaptureDrop" in the Oracle TimesTen In-Memory Database Reference.

You can repeat the steps in "Prepare for executing the Index Advisor" and "Retrieve index recommendations and data collection information" until a SQL workload is executed with no more index recommendations. You can keep updating the statistics for the tables on which the new indexes were applied and re-execute the Index Advisor to see if any new indexes are now recommended.

Example using Index Advisor built-in procedures

The following shows the flow of a data collection for a SQL workload and the resulting index advice provided by the Index Advisor built-in procedures.

Command> call ttOptUpdateStats();

Command> call ttIndexAdviceCaptureStart();

Command> SELECT employee_id, first_name, last_name FROM employees;
< 100, Steven, King >
< 101, Neena, Kochhar >
< 102, Lex, De Haan >
< 103, Alexander, Hunold >
< 104, Bruce, Ernst >
...
< 204, Hermann, Baer >
< 205, Shelley, Higgins >
< 206, William, Gietz >
107 rows found.

Command> SELECT MAX(salary) AS MAX_SALARY 
FROM employees 
WHERE employees.hire_date > '2000-01-01 00:00:00';
< 10500 >
1 row found.

Command> SELECT employee_id, job_id FROM job_history 
WHERE (employee_id, job_id) NOT IN (SELECT employee_id, job_id 
FROM employees);
< 101, AC_ACCOUNT >
< 101, AC_MGR >
< 102, IT_PROG >
< 114, ST_CLERK >
< 122, ST_CLERK >
< 176, SA_MAN >
< 200, AC_ACCOUNT >
< 201, MK_REP >
8 rows found.

Command> WITH dept_costs AS 
(SELECT department_name, SUM(salary) dept_total 
FROM employees e, departments d 
WHERE e.department_id = d.department_id 
GROUP BY department_name), 
avg_cost AS 
(SELECT SUM(dept_total)/COUNT(*) avg 
FROM dept_costs) 
SELECT * FROM dept_costs 
WHERE dept_total > 
(SELECT avg FROM avg_cost) 
ORDER BY department_name;
< Sales, 304500 >
< Shipping, 156400 >
2 rows found.

Command> call ttIndexAdviceCaptureEnd();

Command> call ttIndexAdviceCaptureInfoGet();
< 0, 1, 0, 0, 9, 6, 2012-07-27 11:44:08.136833, 2012-07-27 12:07:35.410993 >
1 row found.

Command> call ttIndexAdviceCaptureOutput();
< 1, create index EMPLOYEES_i1 on HR.EMPLOYEES(SALARY); >
< 1, create index EMPLOYEES_i2 on HR.EMPLOYEES(HIRE_DATE); >
2 rows found.

Command> call ttIndexAdviceCaptureDrop();

Understanding rows

Rows are used to store TimesTen data. TimesTen supports several data types for fields in a row, including:

  • One-byte, two-byte, four-byte and eight-byte integers.

  • Four-byte and eight-byte floating-point numbers.

  • Fixed-length and variable-length character strings, both ASCII and Unicode.

  • Fixed-length and variable-length binary data.

  • Fixed-length fixed-point numbers.

  • Time represented as hh:mi:ss [AM|am|PM|pm].

  • Date represented as yyyy-mm-dd.

  • Timestamp represented as yyyy-mm-dd hh:mi:ss:ffffff.

The "Data Types" section in the Oracle TimesTen In-Memory Database SQL Reference contains a detailed description of these data types.

To perform any operation for inserting or deleting rows, the user must have the appropriate privileges, which are described along with the syntax for all SQL statements in the "SQL Statements" chapter in the Oracle TimesTen In-Memory Database SQL Reference.

The following sections describe how to manage your rows:

Inserting rows

To insert a row, issue INSERT or INSERT SELECT. You can also use the ttBulkCp utility.

Example 7-6 Insert a row in a table

To insert a row in the table customer, enter:

Command> INSERT INTO customer VALUES(23125, 'John Smith';

Note:

When inserting multiple rows into a table, it is more efficient to use prepared commands and parameters in your code. Create Indexes after the bulk load is completed.

Deleting rows

To delete a row, issue the DELETE statement.

Example 7-7 Delete a row

The following deletes all the rows from the table customer for names that start with the letter "S."

Command> DELETE FROM customer WHERE cust_name LIKE 'S%';

Understanding synonyms

A synonym is an alias for a database object. Synonyms are often used for security and convenience, because they can be used to mask object name and object owner. In addition, you can use a synonym to simplify SQL statements. Synonyms provide independence in that they permit applications to function without modification regardless of which object a synonym refers to. Synonyms can be used in DML statements and some DDL and TimesTen cache statements.

Synonyms are categorized into two classes:

  • Private synonyms: A private synonym is owned by a specific user and exists in the schema of a specific user. A private synonym shares the same namespace as other object names, such as table names, view names, sequence names, and so on. Therefore, a private synonym cannot have the same name as a table name or a view name in the same schema.

  • Public synonyms: A public synonym is owned by all users and every user in the database can access it. A public synonym is accessible for all users and it does not belong to any user schema. Therefore, a public synonym can have the same name as a private synonym name or a table name.

In order to create and use synonyms, the user must have the correct privileges, which are described in "Object privileges for synonyms" in the Oracle TimesTen In-Memory Database Security Guide.

After synonyms are created, they can be viewed using the following views:

  • SYS.ALL_SYNONYMS: describes the synonyms accessible to the current user. For more information, see "SYS.ALL_SYNONYMS" in the Oracle TimesTen In-Memory Database System Tables and Views Reference.

  • SYS.DBA_SYNONYMS: describes all synonyms in the database. For more information, see "SYS.DBA_SYNONYMS" in the Oracle TimesTen In-Memory Database System Tables and Views Reference.

  • SYS.USER_SYNONYMS: describes the synonyms owned by the current user. For more information, see "SYS.USER_SYNONYMS" in the Oracle TimesTen In-Memory Database System Tables and Views Reference.

Creating synonyms

Create the synonym with the CREATE SYNONYM statement. You can use the CREATE OR REPLACE SYNONYM statement to change the definition of an existing synonym without needing to drop it first. The CREATE SYNONYM and CREATE OR REPLACE SYNONYM statements specify the synonym name and the schema name in which the synonym is created. If the schema is omitted, the synonym is created in the user's schema. However, when creating public synonyms, do not provide the schema name as it is defined in the PUBLIC namespace.

In order to issue the CREATE SYNONYM or CREATE OR REPLACE SYNONYM statements, the user must have the appropriate privileges, as described in "Object privileges for synonyms" in the Oracle TimesTen In-Memory Database Security Guide.

  • Object types for synonyms: The CREATE SYNONYM and CREATE OR REPLACE SYNONYM statements define an alias for a particular object, which can be one of the following object types: table, view, synonym, sequence, PL/SQL stored procedure, PL/SQL function, PL/SQL package, materialized view, or cache group.

    Note:

    If you try to create a synonym for unsupported object types, you may not be able to use the synonym.
  • Naming considerations: A private synonym shares the same namespace as all other object names, such as table names and so on. Therefore, a private synonym cannot have the same name as a table name or other objects in the same schema.

    A public synonym is accessible for all users and does not belong to any particular user schema. Therefore, a public synonym can have the same name as a private synonym name or other object name. However, you cannot create a public synonym that has the same name as any objects in the SYS schema.

In the following example, the user creates a private synonym of synjobs for the jobs table. Issue a SELECT statement on both the jobs table and the synjobs synonym to show that selecting from synjobs is the same as selecting from the jobs table. Finally, to display the private synonym, the example executes a SELECT statement on the SYS.USER_SYNONYMS table.

Command> CREATE SYNONYM synjobs FOR jobs;
Synonym created.

Command> SELECT FIRST 2 * FROM jobs;
< AC_ACCOUNT, Public Accountant, 4200, 9000 >
< AC_MGR, Accounting Manager, 8200, 16000 >
2 rows found.
Command> SELECT FIRST 2 * FROM synjobs;
< AC_ACCOUNT, Public Accountant, 4200, 9000 >
< AC_MGR, Accounting Manager, 8200, 16000 >
2 rows found.

Command> SELECT * FROM sys.user_synonyms;
< SYNJOBS, TTUSER, JOBS, <NULL> >
1 row found.

For full details, more examples, and rules on creating or replacing a synonym, see the "CREATE SYNONYM" section in the Oracle TimesTen In-Memory Database SQL Reference.

Dropping synonyms

Use the DROP SYNONYM statement to drop an existing synonym from the database. A user cannot be dropped unless all objects, including synonyms, owned by this user are dropped.

For example, the following drops the public synonym pubemp:

Command> DROP PUBLIC SYNONYM pubemp;
Synonym dropped.

In order drop a public synonym or a private synonym in another user's schema, the user must have the appropriate privileges. For full details, more examples, and rules on creating or replacing a synonym, see the "DROP SYNONYM" section in the Oracle TimesTen In-Memory Database SQL Reference.

Synonyms may cause invalidation or recompilation of SQL queries

When a synonym or object is newly created or dropped, some SQL queries and DDL statements may be invalidated or recompiled. The following lists the invalidation and recompilation behavior for SQL queries and DDL statements:

  1. All SQL queries that depend on a public synonym are invalidated if you create a private synonym with the same name for one of the following objects:

    • private synonym

    • table

    • view

    • sequence

    • materialized view

    • cache group

    • PL/SQL object including procedures, functions, and packages

  2. All SQL queries that depend on a private synonym or schema object are invalidated when a private synonym or schema object is dropped.